While I was looking into some details for preparing my next Practical 365 article, I spotted a change in the way Exchange Online PowerShell returned mailbox permissions. Whereas previously we got a long list of “system” permissions, now only the relevant user-added entries were returned, making the list of permissions much shorter. Here’s an example:
Get-MailboxPermission sharedtest@michev.info
Identity User AccessRights
-------- ---- ------------
sharedtest NT AUTHORITY\SELF {FullAccess, ReadPermission}
sharedtest NT AUTHORITY\SELF {FullAccess, ExternalAccount, ReadPermission}
sharedtest vasil@michev.info {FullAccess}
And that’s all the details being returned currently, whereas few months back one would get the following, quite longer list:
Get-MailboxPermission sharedtest
Identity User AccessRights
-------- ---- ------------
sharedtest NT AUTHORITY\SELF {FullAccess, ReadPermission}
sharedtest NT AUTHORITY\SELF {FullAccess, ExternalAccount, ReadPermission}
sharedtest vasil@michev.info {FullAccess}
sharedtest EURPRD03\Administ... {FullAccess}
sharedtest EURPRD03\Domain A... {FullAccess}
sharedtest EURPRD03\Enterpri... {FullAccess}
sharedtest EURPRD03\Organiza... {FullAccess}
sharedtest NT AUTHORITY\SYSTEM {FullAccess}
sharedtest NT AUTHORITY\NETW... {ReadPermission}
sharedtest S-1-5-21-15893167... {ReadPermission}
sharedtest PRDTSB01\JitUsers {ReadPermission}
sharedtest EURPRD03\Administ... {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
sharedtest EURPRD03\Domain A... {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
sharedtest EURPRD03\Enterpri... {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
sharedtest EURPRD03\Organiza... {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
sharedtest EURPRD03\Public F... {ReadPermission}
sharedtest EURPRD03\Exchange... {FullAccess, ReadPermission}
sharedtest EURPRD03\Exchange... {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
sharedtest EURPRD03\Managed ... {ReadPermission}
The highlighted dozen or so entries all correspond to different Microsoft-managed accounts and background processes, and are of no relevance to us as “consumers” of the service. While being able to peek behind the curtain does add some value in few cases, most often this additional data can be regarded as useless. In fact, it was very common practice to filter out those entries entirely, including the default “NT AUTHORITY\SELF” one. Now, this is no longer needed.
But the improvements don’t stop here. While checking some additional mailboxes for permission entries, I noticed something odd in the output. Let’s see if you can spot it as well:
Get-MailboxPermission gosho
Identity User AccessRights
-------- ---- ------------
gosho NT AUTHORITY\SELF {FullAccess, ReadPermission}
Gosho2 NT AUTHORITY\SELF {FullAccess, ReadPermission}
So what do you think? We get two “NT AUTHORITY\SELF” entries, but that’s not uncommon – in fact the first example above also has two. What is different this time is the Identity value, which points to a different mailbox object altogether. So either the output is borked, or the cmdlet is returning entries across multiple mailboxes. YES!
In other words, the Get-MailboxPermission cmdlet now supports wildcards, which in turn makes it possible for us to return any and all permissions entries across the tenant in a single run, without having to use the pipeline! Meaning, the following is now possible:
Get-MailboxPermission *
which is effectively the analog of:
Get-Mailbox | Get-MailboxPermission
but should in theory run much faster. Well, as another example of theory meeting practice – this is currently NOT the case. Even if we ignore the fact that the wildcard variant seems to always error out on some entires (you can add -ErrorAction silentlycontinue to account for that), it’s actually taking a lot more time to complete. In my tests, it took nearly twice as much time as the pipeline variant.
Looking at the actual output though, you will notice that the wildcard variant returns tons of “system” mailboxes, such as the ones used to hold organizational settings, quarantine, arbitration mailboxes and what not. A short sample of those is shown on the screenshot below. As evident from the output, you will probably never care about these entries, so including them is probably an oversight on Microsoft’s part. Then again, it’s another opportunity to peek behind the curtain and see just how many services within Office 365 use Exchange Online mailboxes:
In turn, the total number of entries returned is four times larger compared to the “sanitized” variant you get when using the pipeline, which contributes to the perceived slowness. Add to that the delay caused by paging and whatever that BackEndLocatorException error is supposed to signify, and we have an explanation as to why this method takes more time to complete. Hopefully, these shortcomings will be addressed in the future, and we will be able to use a single call to Get-MailboxPermission in order to list all relevant permission entries within the tenant, much like we can do currently with Get-RecipientPermission (which also returns all the system mailboxes btw).
Now, currently I have no information as to whether using the Get-MailboxPermission in such manner is actually a supported scenario, so I would hold off updating my scripts just yet. As mentioned above, there are some obvious issues with the current implementation anyway, so probably it’s a good idea to wait for Microsoft to address those. Lastly, I wasn’t able to use the same method with the Get-EXOMailboxPermission cmdlet, so no idea whether it’s coming to the REST-based cmdlets.
Once I get more information, I will make sure to update this post and the good old how-to:
Update 03.2023: Looks like Microsoft pulled the plug on this, and the Get-MailboxPermission cmdlet no longer accepts wildcards:
[10:13:58][Login script]# Get-MailboxPermission * Write-ErrorMessage : ExB45496|Microsoft.Exchange.Configuration.Tasks.ManagementObjectAmbiguousException|'*' doesn't represent a unique recipient. At D:\Temp\tmpEXO_ehx22ufm.hjj\tmpEXO_ehx22ufm.hjj.psm1:1121 char:13 + Write-ErrorMessage $ErrorObject + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Get-MailboxPermission], ManagementObjectAmbiguousException + FullyQualifiedErrorId : [Server=VI1PR03MB4846,RequestId=fa845bc0-2501-9c84-cc4b-8da8390deb62,TimeStamp=Fri, 24 Mar 2023 09:12:23 GMT],Write-ErrorMessage