Exchange Online Plans Changes to Make Mailbox Identification More Effective

Distinguished Names and Exchange History

Update November 18, 2022: Microsoft began the rollout of the change to make the Name parameter have the same value as the ExternalDirectoryObjectId (EDOID) in September. However, they have paused the rollout until January 2023. Some tenants have the feature now.

On April 13, the Exchange development group announced a change that took a little part away from the product’s history. Microsoft wants to alter the format of the Name and DistinguishedName attributes for mailboxes to make them more unique and plans to use the external directory object identifier (aka EDOID) instead.

When Microsoft launched Exchange 4.0 in 1996, the X.400 and X.500 standards still exerted a huge influence on the world of email. Because of this, the developers used X.500-like naming conventions within the Exchange directory store (DS), the forerunner of what became Active Directory when Windows 2000 launched in 1999 and Azure Active Directory later. X.500 objects use distinguished names as unique identifiers. To create an X.500 distinguished name, you concatenate attributes to form a path to the named entry. Exchange Online mail-enabled objects still have these values in the LegacyDn property, where you’ll find something like this:

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

Exchange Online has its own form of distinguished names, which still serve as unique identifiers for objects. Here’s 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 mailbox name. The OU (organization) entities identify the Microsoft 365 tenant and Exchange Online, while the DC entities give the path to the Outlook.com domain controller Exchange Online connected to when it created the mailbox.

Make Synchronization Happy

What Microsoft is now saying is that the format used for Exchange Online distinguished names needs to change. They have encountered situations where conflicts happened when objects synchronize from Azure Active Directory to Exchange Online. When they considered how the conflicts occurred, they decided that a better source of uniqueness is necessary.

Microsoft proposes to change the generation of the Name property for mail-enabled objects from its current basis (the MailNickName or Alias) to use the external directory object identifier pointing to the Azure AD account owning the object. Let’s explore what that means.

Using Unique Identifiers

All Azure AD objects have unique identifiers (GUIDs). When you create a new Microsoft 365 account with an Exchange Online license, Exchange Online takes the account’s MailNickName property and uses that for the mailbox name and alias properties. For example, if you create a new account with a username of Sue.P.Pickett@office365itpros.com, among the Azure AD account properties are:

• GivenName: Sue
• Surname: Pickett
• MailNickName: Sue.P.Pickett
• Mail: Sue.P.Pickett@office365itpros.com
• UserPrincipalName: Sue.P.Pickett@office365itpros.com
• ObjectId: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3

When Exchange Online creates a mailbox, it takes the MailNickName value and uses it to create the mailbox alias, name, and distinguished name. The first two properties have the same value as MailNickName, while the distinguished 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 Azure AD account ObjectId into the mailbox’s ExternalDirectoryObjectId property. You can use this value to find a mailbox, as in:

Get-ExoMailbox -Identity b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 -Properties Name

ExternalDirectoryObjectId : b67c8bd7-a8d3-4358-b42f-cd51821f7ba3
UserPrincipalName         : Sue.P.Pickett@office365itpros.com
Alias                     : Sue.P.Pickett
DisplayName               : Sue Pickett
Name                      : Sue.P.Pickett
DistinguishedName         : CN=Sue.P.Pickett,OU=Office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

Microsoft’s proposed change means that Exchange Online will use the Azure AD account identifier for the mailbox name and as the CN part of the distinguished name. Hence, we end up with:

Get-ExoMailbox -Identity b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 -Properties Name

ExternalDirectoryObjectId : b67c8bd7-a8d3-4358-b42f-cd51821f7ba3
UserPrincipalName         : Sue.P.Pickett@office365itpros.com
Alias                     : Sue.P.Pickett
DisplayName               : Sue Pickett
Name                      : b67c8bd7-a8d3-4358-b42f-cd51821f7ba3
DistinguishedName         : CN= b67c8bd7-a8d3-4358-b42f-cd51821f7ba3, OU=Office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

Because an Azure AD account identifier is unique within Microsoft 365, the properties of the Exchange mailbox will also be unique, and it solves the synchronization problems. In fact, you can write the account identifier into a mailbox’s Name property today if you want:

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

When you update the Name property, Exchange updates the mailbox’s distinguished name so that the CN part of the name matches the value assigned to the Name property.

Distinguished Names and Exchange Online

Distinguished names only exist within Exchange Online. No trace of them exists in Azure AD object properties because the link between Azure AD and Exchange Online is via the external directory object identifier. This property exists for all Exchange Online objects which have a corresponding object in Azure AD:

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

Microsoft says that the change will apply only to new mail-enabled objects. They don’t plan to retrospectively update older objects with the new naming scheme. When the new naming scheme rolls out, Microsoft says that they will stop the ability of administrators to update the mailbox Name property using cmdlets like Set-Mailbox and Set-User, which seems logical.

A Pause for Reflection

Soon after Microsoft posted their blog, they added an update saying that based on feedback, they will delay making the change and will give a new schedule at the end of April. I think this is reasonable. Although I’m not worried about using object identifiers in distinguished names, the Name property is a little different because Exchange Online exposes it more often. For instance, if you look at who manages a distribution group, this output doesn’t look right:

Get-DistributionGroup -Identity "Users External Email Monitoring" | ft ManagedBy

ManagedBy
---------
{bff4cd58-1bb8-4899-94de-795f656b4a18}

And listing user mailboxes with Get-Recipient looks odd:

Get-Recipient -RecipientTypeDetails UserMailbox

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

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 Services {bff4cd58-1bb8-4899-94de-795f656b4a18}

Exchange and Microsoft 365 user interfaces will hide the switchover because they can take the GUIDs and resolve them into “pretty” values like display names (Figure 1).

Any potential problems will arise in administrative scripts which use the Name or DistinguishedName properties and expect values returned by Exchange Online to follow a certain format. Scripts (like this one to report distribution lists and their managers) that resolve values to retrieve display names are unaffected by the change.

Like any modification proposed for something which has been in use for a very long time, there are bound to be some edge cases that turn up and need resolution. I believe the Exchange developers are on the right path to seek unique anchors for synchronization. I just hope that they can get there without causing too much upheaval for customers.

---

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.