Mailbox Permissions Lists GUID

Starting in early November 2022, something strange happened!

Exchange Online admins are now starting to see GUIDs in mailbox permissions instead of meaningful names of delegatees:

If you switch to Exchange Online PowerShell you’ll see the same information:

PS C:\> Get-RecipientPermission alexander.ruiz
Identity       Trustee                               AccessControlType AccessRights Inherited
--------       -------                               ----------------- ------------ ---------
Alexander Ruiz NT AUTHORITY\SELF                     Allow             {SendAs}     False
Alexander Ruiz hans.c.orsted@azure.skrubbeltrang.com Allow             {SendAs}     False
Alexander Ruiz amy.cooper@azure.skrubbeltrang.com    Allow             {SendAs}     False
Alexander Ruiz Marketing                             Allow             {SendAs}     False
Alexander Ruiz Sales                                 Allow             {SendAs}     False
Alexander Ruiz emil.hansen@azure.skrubbeltrang.com   Allow             {SendAs}     False
Alexander Ruiz 79252acd-e474-408f-b78c-533591f80c82  Allow             {SendAs}     False

What happened here???

A Half-Baked Breaking Change in Exchange Online

The problem seen above is related to the announcement “Change in naming convention of user’s Name parameter”:

https://techcommunity.microsoft.com/t5/exchange-team-blog/change-in-naming-convention-of-user-s-name-parameter/bc-p/3672755

This change was announced on April 13th, 2022, and unfortunately, much of the information seems to be out of touch with reality.

The Rollout Date Was Never Clear and is Still Misleading

Microsoft has never published an exact rollout date for this change.

According to the latest update (as of November 10th, 2022), Microsoft has “paused the rollout of this feature until January 2023.”

According to the announcement, the change “will be rolled out in a phased manner.”

Nevertheless, it seems that this change has hit a lot of tenants (if not everybody) around the first week of November 2022:

Easy365Manager clients have reported this change is now in effect.
We see it in our own tenant.
Lots of commenters on the announcement are confirming the change has been rolled out in their production tenant.

The Scope of the Change is Not Correct

The scope of the change has been announced (in the announcement title) as only affecting user accounts.

Also, it was announced as only affecting the Name and DistinguishedName attributes:

When you look at objects created after Microsoft rolled out the change, you’ll see this is not the complete picture:

The change also affects Groups and Contacts.
The change affects additional attributes: Id and Identity.

Consider the following output of a distribution group created on 10th of November 2022 and synchronized to Azure AD/Exchange Online:

PS C:\> Get-Group management | fl Name,DisplayName,DistinguishedName,Id,Identity
Name              : 79252acd-e474-408f-b78c-533591f80c82
DisplayName       : Management
DistinguishedName : CN=79252acd-e474-408f-b78c-533591f80c82,OU=e365m.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR09A010,DC=PROD,DC=OUTLOOK,DC=COM
Id                : 79252acd-e474-408f-b78c-533591f80c82
Identity          : 79252acd-e474-408f-b78c-533591f80c82

You will see similar results on any user or group created and synchronized after this change has been implemented.

How to Resolve the GUID

Currently, Microsoft will resolve the GUID for user delegatees when you retrieve mailbox permissions. But for permissions delegated to groups, you’re now stuck with a GUID.

This makes it very hard to manage mailbox permissions efficiently.

You’ll need a roundtrip to PowerShell and use the Get-Recipient CmdLet to obtain the DisplayName of the GUID shown in your mailbox permissions:

PS C:\> (Get-Recipient 79252acd-e474-408f-b78c-533591f80c82).DisplayName
Management

This will not exactly increase the productivity of your Helpdesk.

Microsoft Takes a Lot of Heat

As seen in the comments section of this announcement, a lot of people are not impressed with the way this change has been communicated and implemented.

It will be interesting to see if Microsoft will fix the showing of GUIDs in the mailbox permissions assigned to groups. And how long time it will take.

Also, this change is bound to lead to a lot of time wasted by IT admins that will be taken by surprise by GUIDs dripping into their Name, ID, and Identity attributes over time when new users are created.

I’ll let the Microsoft community be the judge of this work:

(from the comments section of the change announcement)