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 13 April, the Exchange development groupannounced a change that took a small chunk out of the product history. Microsoft wants to change the format of the Name and DistinguishedName attributes for mailboxes to make them more unique and plans to use the external directory object identifier instead.
When Microsoft released Exchange 4.0 in 1996, the X.400 and X.500 standards still had a huge influence on the e-mail world. 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. Mail extension objects Exchange Online always have these values in the LegacyDn property, where you will find something like this:
Exchange Online has its own form of unique names, which always serve as unique identifiers for objects. Here is an example:
The CN (common name) part comes from the mailbox name. The organisational unit entities identify the Microsoft 365 and Exchange Online client, while the domain controller entities assign the path to the Outlook.com domain controller that Exchange Online connected to when the mailbox was created.
Making synchronisation more fun
What Microsoft is now saying is that the format used for unique names Exchange Online needs to change. They have encountered situations where conflicts have occurred when objects sync from Azure Active Directory to Exchange Online. When they thought about how the conflicts occurred, they decided that a better source of uniqueness was needed.
Microsoft is proposing to change the generation of the Name property for mail extension objects from its current base(MailNickName or Alias) to use the external directory object identifier pointing to the Azure AD account that owns the object. Let's explore what this means.
Use of unique identifiers
All Azure AD objects have unique identifiers (GUIDs). When you create an account Microsoft 365 with a Exchange Online license, Exchange Online takes the MailNickName property of the account and uses it for the mailbox name and alias properties. For example, if you create a new account with a username of Sue.P.Pickett@office365itpros.com, the Azure account properties AD include:
- GivenName: Sue
- Last name: Pickett
- MailNickName: Sue.P.Pickett
- Mail: Sue.P.Pickett@office365itpros.com
- UserPrincipalName: Sue.P.Pickett@office365itpros.com
- ObjectId: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3
WhenExchange Online creates a mailbox, it takes the MailNickName value and uses it to create the alias, name and unique name of the mailbox. The first two properties have the same value as MailNickName, while the unique name becomes :
In addition, Exchange Online writes the ObjectId of the Azure account AD to the ExternalDirectoryObjectId property of the mailbox. You can use this value to search for a mailbox, as in :\
Microsoft's proposed change means thatExchange Online will use the Azure account identifier AD for the mailbox name and as the CN part of the unique name. As a result, we end up with:
Since an Azure account identifier AD is unique in Microsoft 365, the mailbox properties Exchange will also be unique and will solve the synchronization problems. In fact, you can write the account identifier to the Name property of a mailbox today if you wish:
When you update the Name property, Exchange updates the unique name of the mailbox so that the CN part of the name matches the value assigned to the Name property.
Unique names and Exchange Online
Unique names exist only in Exchange Online. No trace of them exists in the Azure object properties AD, because the link between Azure AD and Exchange Online is via the external directory object identifier. This property exists for all Exchange Online objects 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 their blog, they added an update saying that, based on feedback, they will delay the change and give a new schedule at the end of April. I think this is reasonable. While I'm not worried about the use of object identifiers in unique names, the Name property is a bit different because Exchange Online exposes it more often. For example, if you look at who manages a distribution group, this output doesn't look right:
And the list of user mailboxes with Get-Recipient looks strange:
While checking who has the Send as permission for a shared mailbox becomes more of a chore:
The user interfaces Exchange and Microsoft 365 mask the switchover because they can take GUIDs and resolve them into "pretty" values such as display names (Figure 1).
Any potential problems will arise in administration scripts that use the Name or DistinguishedName properties and expect the values returned by Exchange Online to follow a certain format. Scripts (such as this one for reporting distribution lists and their managers) that resolve values to retrieve full names are not affected by the change.
As with any proposed change to something that has been in use for a very long time, there are bound to be outliers that arise and need to be resolved. I think the Exchange developers are on the right track in looking for unique anchors for synchronisation. I just hope they can do it without causing too much disruption to customers.