Changes Made to the Plans Exchange Online to make mailbox identification more efficient

 

Unique names and trade history

Microsoft announced in MC365786 (30 April) that it will start rolling out this change to tenants at the end of May.

On April 13, the development team Exchange announced a change that marked a small chapter in the product’s history. Microsoft wants to change the format of theNameandDistinguishedNameattributes for mailboxes to make them more unique and plans to use the external directory object identifier instead.

When Microsoft launched Exchange 4.0 in 1996, the X.400 and X.500 standards still exerted a tremendous influence on the world of email. For this reason, developers used X.500-style naming conventions in the Exchange Directory Store (DS), the precursor to what became Active Directory when Windows 2000 was released in 1999 and Azure Active Directory later. X.500 objects use unique names as unique identifiers. To create a unique X.500 name, you concatenate attributes to form a path to the named entry. Objects in the Messaging extension Exchange Online always have these values in theLegacyDn property, where you’ll find something like this:

o=ExchangeLabs/ou=Administration Group Exchange (FYDIBOHF23SPDLT)/cn=Recipients/cn=43bdc98a69d147568728728be0335b34-James Keane

Exchange Online has its own format for unique names, which always serve as unique identifiers for objects. Here is an example:

CN=James Keane,OU=office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

The CN (common name) portion comes from the name on the mailbox. Organizational unit entities identify the customer Microsoft 365 and Exchange Online, while the domain controller entities specify the path to the domain controller Outlook.com, to which Exchange Online connected to when the mailbox was created.

Making synchronisation more fun

What Microsoft is saying now is that the format used for unique names Exchange Online needs to change. They have encountered situations where conflicts have occurred when objects are synchronizedAzure Active Directory to Exchange Online. When they analyzed how the conflicts occurred, they concluded that a better mechanism for ensuring uniqueness was needed.

Microsoft proposes to change how the Name property is generated for messaging-extended objects from its current basis (MailNickNameorAlias) to use the external directory object identifier that points to the account Azure AD that owns the object. Let’s explore what this means.

Use of unique identifiers

All objects Azure AD have unique identifiers (GUIDs). When you create an account Microsoft 365 with an Exchange Online, Exchange Online retrieves the account’sMailNickNameproperty and uses it for the mailbox name and alias properties. For example, if you create a new account with the username [email protected], the account properties Azure AD include:

• GivenName: Sue
• Last name: Pickett
• MailNickName: Sue.P.Pickett
• Mail: [email protected]
• UserPrincipalName: [email protected]
• ObjectId: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3

WhenExchange Online creates a mailbox, it takes the valueof MailNickNameand uses it to create the alias, name, and unique name of the mailbox. The first two properties have the same value asMailNickName, while the unique name becomes:

CN=Sue. P. Pickett,OU=office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

In addition, Exchange Online writes the account's ObjectId Azure AD in theExternalDirectoryObjectIdproperty of the mailbox. You can use this value to search for a mailbox, such as in: \

Get-ExoMailbox -Identity b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 -Property Names ExternalDirectoryObjectId: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 UserPrincipalName: [email protected] Alias: Sue.P.Pickett DisplayName: Sue Pickett Name: Sue.P.Pickett Distinguished Name: CN=Sue.P.Pickett,OU=Office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

The change proposed by Microsoft means thatExchange Online will use the account identifier Azure AD for the mailbox name and as the CN part of the distinguished name. Consequently, we end up with:

Get-ExoMailbox -Identity b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 -Property Names ExternalDirectoryObjectId: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 UserPrincipalName: [email protected] Alias: Sue.P.Pickett DisplayName: Sue Pickett Name: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 Distinguished Name: CN= b67c8bd7-a8d3-4358-b42f-cd51821f7ba3, OU=Office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

Since an account identifier Azure AD is unique within Microsoft 365, the mailbox properties Exchange will also be unique and will resolve synchronization issues. In fact, you can set the account identifier in a mailbox’sNameproperty today if you wish:

Set-Mailbox -Identity b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 -Name b67c8bd7-a8d3-4358-b42f-cd51821f7ba3

When you update theName property, Exchange it updates the mailbox's unique name so that the CN part of the name matches the value assigned to theName property.

Unique names and Exchange Online

Unique names exist only in Exchange Online. There is no trace of them in the object properties Azure AD, because the link between Azure AD and Exchange Online is established via the external directory object identifier. This property exists for all Exchange Online that have a corresponding object in Azure AD :

• Mailboxes (all types - user, shared, room, group).
• Distribution lists (but not dynamic distribution lists or space lists).
• Email contacts.
• Email users.

Microsoft indicates that the change will only apply to new mail extension objects. They do not plan to retrospectively update older objects with the new naming scheme. When the new naming scheme is deployed, Microsoft says it will stop the ability of administrators to update the Mailbox Name property using cmdlets such as Set-Mailbox and Set-User, which seems logical.

A pause for reflection

Shortly after Microsoft published its blog post, they added an update stating that, based on feedback, they would delay the change and provide a new timeline by the end of April. I think that’s reasonable. Although I’m not concerned about the use of object identifiers in unique names, the Name property is a bit different because Exchange Online exposes it more frequently. For example, if you look at who manages a distribution group, this output doesn’t seem correct:

Get-DistributionGroup -Identity "External Monitoring of User Emails" | ft ManagedBy ManagedBy ——— {bff4cd58-1bb8-4899-94de-795f656b4a18}

And the list of user mailboxes with Get-Recipient looks strange:

Get-Recipient -RecipientTypeDetails UserMailbox RecipientType Name —- ————- bff4cd58-1bb8-4899-94de-795f656b4a18 UserMailbox Kim Akers UserMailbox Ben Owens UserMailbox Terry.Hegarty UserMailbox John.West UserMailbox 66b08473-dff2-4058-9170-0b4eab6e0987 User Mailbox b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 User Mailbox

While checking who has the Send as permission for a shared mailbox becomes more of a chore:

Get-EXOMailbox -Identity CServices -Properties GrantSendOnBehalfTo | ft DisplayName, GrantSendOnBehalfTo DisplayName GrantSendOnBehalfTo ———– ——————- Customer Service {bff4cd58-1bb8-4899-94de-795f656b4a18}

User Interfaces Exchange and Microsoft 365 hide the switching process because they can take GUIDs and resolve them into “pretty” values such as display names (Figure 1).

Any potential issues will arise in administrative scripts that use theNameorDistinguishedNameproperties and expect the values returned by Exchange Online follow a specific format. Scripts (such as this one for reporting distribution lists and their owners) that resolve values to retrieve full names are not affected by the change.

As with any proposed change to something that’s been in use for a very long time, there are bound to be edge cases that arise and need to be resolved. I think the developers Exchange are on the right track in their search for unique anchors for synchronization. I just hope they can pull it off without causing too much disruption for customers.