Update (4/12/23): This feature was enabled in our worldwide and 21Vianet clouds in November 2022. All tenants in these clouds will see the changes. Rollout to our GCCH and DoD clouds has been paused until further notice. Please follow this space for any other updates.
We want to inform you about a change that we are working on. This change will be rolled out in a phased manner. The following is a more updated and detailed explanation of changes being implemented.
The Name parameter associated with a recipient within a tenant in Exchange Online should be unique. However, while we sync objects from Azure Active Directory to Exchange Online, the way Name parameter (system metadata) is being computed in the backend currently led to some system conflicts impacting reliability. We realized that the current method is not the best way to compute this parameter. Hence, we want to move away from the status quo to a more robust way of generating the Name parameter which is through ExternalDirectoryObjectId (EDOID) that ensures uniqueness in the system. All the long-term reliability enhancements in the backend would be done in line with this change.
EDOID value is unique. We’ll use this GUID as Name instead of synchronizing the Name from on-premises (when in Hybrid environment) or using the alias (if Name is not specified) to compute the Name parameter in Exchange Online. With this change the DistinguishedName (DN) value will also get impacted. To better understand how this will impact objects in a tenant where directory synchronization is enabled, consider the following example:
With this new change, when creating a new Office 365 (remote) mailbox from on-premises Exchange Admin Center, the Name field will no longer synchronize to Exchange Online.
Before changes are implemented:
DisplayName: Jeff Smith
Name: Jeff Smith
Alias: jsmith
DistinguishedName: CN= Jeff Smith,OU=(tenant).onmicrosoft.com, OU=Microsoft Exchange Hosted Organizations, DC=NAMP283A001, DC=PROD,DC=OUTLOOK, DC=COM
ExternalDirectoryObjectId: 12313c53-fff7-46d4-8b83-71fb317d1853
After changes are implemented:
DisplayName: Jeff Smith
Name: 12313c53-fff7-46d4-8b83-71fb317d1853
Alias: jsmith
DistinguishedName: CN= 12313c53-fff7-46d4-8b83-71fb317d1853, OU=(tenant).onmicrosoft.com, OU=Microsoft Exchange Hosted Organizations, DC=NAMP283A001, DC=PROD, DC=OUTLOOK, DC=COM
In this example, both the Name and DistinguishedName are updated with the EDOID value.
Note: This would also mean that any subsequent CN value change in Exchange on-premises will not be reflected in the object’s Name property in Exchange Online.
Will this change not allow modification of the Name property?
As a temporary workaround, customers can still use Exchange PowerShell cmdlets (New-MailUser, New-Mailbox, Set-User, Set-MailUser, Set-Mailbox with -Name parameter) to update* the Name property in Exchange Online. Since the cmdlets ensure uniqueness, it would allow the operation to succeed only when the passed Name is unique in the tenant.
*Updates to Name parameter using the above-mentioned cmdlets will only work for users created in Exchange Online. These cmdlets won’t work for users who are part of a hybrid environment.
How will the change impact new and existing users?
The updated naming logic would take effect during creation of new recipient objects (mailbox, user, group, contact) when the change is coming from AAD. However, if the recipient object is mastered in Exchange Online or is directly created there, then the Name which is given during creation will be honored. Since Id/Identity in Exchange Online is a field derived from DistiguishedName it will also reflect EDOID values going forward. If you want to uniquely identify a recipient, you can still use the value of Identity for all practical purposes. However, if visual representation of something similar to Name is preferred, it is advised to take dependency on alias/DisplayName instead. Lastly, existing users won’t get impacted in any way; they will continue to reflect the same Name as was before the change was implemented.
Please note that since we will start using EDOID as Name in Exchange Online, we shall stop allowing changes in CN to reflect in Name property in Exchange Online for all users (both new and existing).
We recommend that Administrators evaluate any scripts or other automation that may rely on the Name property and update them accordingly. Additionally, we also encourage Administrators to take dependency on DisplayName if GUID in Name parameter does not serve the purpose.
