If you’re an admin for a Microsoft 365 account, you probably received an email from the Microsoft Message Center titled “Configuration Change in Name parameter for Exchange Online.” The email states that Microsoft will be changing the way the Name attribute functions in Azure AD/MS 365. Unfortunately, the email and associated documentation doesn’t do a good job of explaining the reasoning and implications of the change. Here’s what is going on.
Why the Change?
The Name attribute in Active Directory prior to the change is synced to and stored in Azure AD under the Name attribute. Normally, this would seem like there is no problem. However, there is an underlying issue that is caused by the way Azure AD is designed on the back-end. You see, all objects in an Azure AD/MS 365 tenant are stored in a single OU. But you can have objects in numerous OUs in Active Directory. The problem occurs when you have two objects that are in different OUs, but have the same value in the Name attribute, like you see below:
Note that both objects have the same Name attribute, but different CN values (They’re in different OUs in Active Directory) When the two objects are synced to Azure AD, however, they both have to go into the same OU, and when the Azure AD version of the object is created, it will use the Name attribute to generate the Azure AD CN value for the object. This can keep one of the objects from syncing to Azure AD, since the Name attribute has to be unique for the entire Azure AD Tenant, not just the OU. As a result, Azure AD Connect will fail to sync one of the objects and you’ll get a non-unique attribute alert in Azure AD.
What is Microsoft Doing?
For any objects created in Azure AD following the change, the Name attribute in Azure AD will be populated with the object’s External Directory Object ID (EDOID). The EDOID is unique and is synced to the on-prem msDS-ExternaleDirectoryObjectID attribute. The EDOID is unique both on-prem and in the cloud. This attribute is really only used heavily by Microsoft Exchange when it’s running in Hybrid mode to bind an on-prem AD account to a cloud-based Mailbox. MS chose to use EDOID for the Name attribute in the cloud because of its uniqueness and use in MS Exchange on-prem. However, in order to use EDOID for the Name attribute, Azure AD Connect has to stop syncing that attribute from the on-prem AD. As such, MS is changing the how the sync rules in Azure AD Connect are set up to exclude the Name attribute. This means the Name attribute is ignored entirely during sync.
With the Name attribute no longer syncing, MS will also be updating the way remote mailbox creation works in Exchange Hybrid environments. Prior to the change, the Name value had to be filled out in the New Remote Mailbox wizard (in ECP) and the new-remotemailbox cmdlet in Exchange PowerShell. Exchange Server should no longer require this attribute to be entered, and the value will be generated to match DisplayName (if it doesn’t already).
How Does this Affect My Work?
Since the Name attribute will no longer sync, the Name attribute on-prem will no longer match. This means any scripts that make use of the Name attribute directly need to be changed to use a different attribute in most cases (generally a good practice anyway. UPN is a better attribute to use in scripts, IMO). The only exception is here is if the script is pulling the name attribute from an existing object like in the below case:
1 | get-mailbox | select name |
In that situation, the name attribute will equal whatever value is obtained from get-mailbox. If, however, you do this:
1 | get-mailbox -identity 'bob henry' |
the script won’t work properly in the cloud on new objects because the Name attribute in the cloud will be the EDOID value, which is a long, unique string of letters and numbers and not “bob henry.”
What Do I Need to Do?
If you are not using Exchange Hybrid (or the on-prem ECP) to create mailboxes and you aren’t using a manually entered Name value in your script, you don’t have to change anything.
If you are in Exchange Hybrid, you need to be aware of the change to how remote mailboxes are created, but won’t really need to change anything. The on-prem Name attribute will be automatically derived from the DisplayName value and used to generate the CN value as before. You’ll also need to note that changes to the Name attribute will no longer sync, so on-prem changes won’t impact cloud objects. Note that this change will not apply to existing Azure AD objects. You don’t have to change the Name value on-prem or in the cloud and it won’t be changed automatically. Only new objects will have this change applied, so you’ll likely have objects that have the Name derived from DisplayName as well as objects that have Name populated with the EDOID value. That may be a little confusing, but shouldn’t impact operations.
If you have scripts that use a manually entered Name value to work with cloud-based objects, you need to change those scripts to use a different Mailbox ID value, like UPN or email address.
