Table of Contents
Delegate Access and Mailbox Permissions Bring Us to Folder Permissions
Two recent posts about Outlook Mobile supporting delegate access to Exchange Online mailboxes and reporting mailbox permissions bring us to the topic of folder permissions. Outlook Mobile uses full access permission to access delegate mailboxes and the report captures this information. But Exchange Online has supported folder-level permissions for many years (here’s a 2006 blog based on Exchange 2003 SP2) and it’s common to find these permissions in use, especially with Outlook desktop.
Outlook Delegate Access
Folder-level permissions have been core to Outlook’s ability to satisfy the traditional manager-assistant work model where the assistant takes care of the manager’s inbox and calendar. This capability is still supported and documented today for Outlook ProPlus and Outlook 2019.
The option to assign delegate access to mailbox folders in Outlook ProPlus is in the backstage area (Figure 1). Alternatively, you can search for “delegates” and Outlook will find it for you.

Setting Outlook Delegate Permissions
Figure 2 shows delegates (left – none are listed because I’m in the process of assigning one) and folder permissions (right). In this case, I’ve selected a user to act as a delegate and chosen the permissions I wanted to assign. When ready, click OK to save the delegated permissions.

When someone assigns folder permissions to a delegate, Exchange Online creates and sends an automatic notification to the delegate to inform them that they can now open the folders (Figure 3).

The support article emphasizes that you should grant Folder visible permission on the root folder of the your mailbox to delegates. This is especially important if the delegate wants to access the delegated folders as shared folders in OWA. In Outlook, delegates should add the mailbox to their profile.
Steps to Script a Folder-Level Access Report
Just like it’s good advice to run a periodic check of mailbox permissions, it’s good to validate that everyone who is assigned permission over folders outside their own mailbox still need that permission. Exchange Online doesn’t come with a report to tell us what folder permissions are in place, so we need to do this with PowerShell.
The Get-MailboxPermission cmdlet fetches permissions for a mailbox. Its counterpart, Get-MailboxFolderPermission, does the same for a folder. Conceptually, the steps to create a report are straightforward:
- Find a set of mailboxes to check.
- Find the folders in each mailbox to check. Exchange Online mailboxes often hold hundreds of folders. We only need to check folders that are commonly delegated, like the Inbox, Sent Items, and Calendar.
- Fetch the permissions for each folder and extract delegated assignments to users who aren’t the mailbox owner.
- Report any delegated access to the selected folders.
You could use the Get-Mailbox, Get-MailboxFolderStatistics, and Get-MailboxFolderPermission cmdlets to create the report. To be a little different, I used the new REST cmdlets because an equivalent is available for each of the three cmdlets listed above (Get-ExoMailbox, Get-ExoMailboxFolderStatistics, and Get-ExoMailboxFolderPermission).
Differences in REST Cmdlets
Using the REST cmdlets means that things run faster, especially when you’re dealing with hundreds or thousands of mailboxes. This is important, especially when the cmdlets are all quite demanding in terms of system resources.
It’s also true that the Exchange Online Management module (which holds these cmdlets) is easier to use with modern authentication, which helps the transition away from basic authentication. Remote PowerShell will no longer support basic auth connections after October 13, 2020.
The downside is that sometimes the REST cmdlets return data in different formats to their Remote PowerShell counterparts. For example, after retrieving permissions for a folder with Get-MailboxFolderPermission, you might want to fetch the name of the delegated user. If the variable $Permission holds the retrieved permission, the name of the user is available as $Permission.User.DisplayName, but it’s $Permission.User with Get-ExoMailboxPermission. It’s the detail that counts when you move from one set of cmdlets to another!
CSV Output
You can grab a copy of the script from GitHub. Its output is a CSV file (Figure 4) that might reveal some interesting delegations. For instance, I found an entry for a user (Michael Harty) that no longer exists in my tenant.

Outlook Mobile to Support Folder-Level Permissions
Microsoft says that Outlook Mobile will support folder-level permissions in the future to remove the need to grant complete access to everything in a delegate mailbox. This is a good step forward that will be welcome by those who don’t really want to expose everything they have just to let someone else manage part of their email.
Using PowerShell like this proves that it’s a great skill for any Office 365 administrator to have. You can find out a lot more about using PowerShell to manage Office 365 in the Office 365 for IT Pros eBook. Join our happy band of subscribers today!
received errors on the script
It’s sad that you received errors. But think of it as an opportunity for you to debug and fix whatever problem you encountered. As you didn’t say what problem you met, we can’t do anything for you (no one in the Office 365 for IT Pros team is equipped with telepathy). And anyway, we write PowerShell to demonstrate principals, not as bullet-proof examples of how to write scripts. See https://office365itpros.com/2019/11/28/why-do-we-write-powershell-like-we-do/ for more detail on this point.
Reminds me something I wrote a while back but I haven’t updated my script for Exchange Online but I think it could help for tenant to tenant migrations as folder level permissions are often missed… depending on the tool that is… Thanks for the effort as always. https://practical365.com/preliminary-permission-clean-up-steps-for-a-successful-mailbox-migration/