A few days ago, I was approached by some Executive Support colleagues. The had to handle a lot of mail items in shared mailboxes. One issue the came across, was the fact that they had to move items and delete folders, but couldn’t as the folders contained private items.
Note: Don’t get me started about the use case “Private Items”! It doesn’t gives you any security value as it’s only honored by a few clients!
Well, back to the topic…I’m aware of this behavior and there is also a KB article about this topic:
I know that this topic is really a topic with gets high attention.At the moment there is nothing available in Microsoft Graph, which would make it possible to manage objects in Exchange Online.
The few things, which exists, are more for end-user (e.g.: accessing their e-mails, calendar or tasks) and for auditing and reporting (e.g.: Security API). Nothing available for managing a mailbox permissions or attributes. Not even like simple CustomAttribute1-15.
Now Microsoft released a new Exchange Online PowerShell module: EXOv2.
Microsoft Graph is gaining more and more attention by developers. Also due to the fact of deprecation of Basic Authentication (please read more about this here!), many are shifting to the new protocol.
I welcome this change, but what I just came across is something I don’t like:
A colleague opened a ticket and complained about something is modifying his calendar items. So far, I saw this an easy task and used my Get-CalendarItems script, but I had to learn not everything is logged, when Microsoft Graph is used…
Update August, 12 2020
I got word that the multi-geo issue will be addressed. No ETA as of now. But at least for calendar items a fix is currently rolling out. Now the used AppID is logged:
The only drawback: Looks like every component team is doing their own thing. That’s why we don’t see proper entries on the item in the Sent Items folder.
This post is lingering around for a while as I thought it would be fixed some days. Unfortunately it wasn’t fixed as of today, so be aware in case you’re going to decommision your Exchange servers. In particular:
The need of removing databases can have multiple reasons. In my case it was the next logical step in our journey to Exchange Online.
Last weekend I run into an issue, where due to missing disk space availability my server run into back pressure.
Exchange has a feature, which will move the current mail queue file and the respective log files to another folder. This happens when transport service detects an issue with the current queue and is called QueueDatabaseRecoveryAction.
Microsoft announced first the deprecation of Basic Authentication for Exchange Online and EWS protocol starting Oct. 13, 2020 here.
Note: At this time this affected ONLY the protocol EWS for mailboxes on Exchange Online!
Later it was announced that this also happens for other protocols like Exchange Active Sync (EAS), POP, IMAP and PowerShell at the same time here, in order to improve security.
Looking at the protocols, you might wonder about REST. This was announced for REST API v1.0 shortly after the announcement for EWS here and highlighted again here.
With this, there is no doubt that Basic Authentication is dead for Exchange Online and Microsoft Graph and every vendor should look into alternatives for authentication AND also update their products. There are still way too many products without support of Modern Auth.
The deprecation of Basic Authentication raises a few questions:
How can I access mailboxes with my service account?
My application needs access to all or only a subset of calendars. How can I securely configure this?
I need to Send-As or Send-on-Behalf of recipients’ e-mail addresses. What do I have to configure?
In this post I’m trying to cover some scenarios and try to explain advantages and disadvantages.
Note: This article is ONLY covering OAuth and Exchange Online! I assume you’re using a Bearer token for authentication in your request!