As part of continued improvements to the Exchange Online service we are releasing an improvement to the User object management experience.
Today, when you create or modify user’s properties via Exchange Admin Center (EAC), Exchange Online PowerShell or other API, the change replicates to Azure Active Directory (AAD) through a sync mechanism which can take some time to complete. Simply put, you might not see the result of your change in AAD for a while.
This “back-sync” mechanism (as you may have heard it referred to) from Exchange Online to AAD has served us well for many years making sure the data in both directories (which sometimes includes an on-premises directory if you have AAD Connect or Exchange Hybrid enabled) remains in sync. This sync mechanism provides key functionality that AAD and Exchange Online depend upon.
However, this back-sync mechanism can sometimes become slow (due to various reasons that we won’t go into here (we suspect it's someone called Dave in building 30)). If that happens, changes might not appear in AAD in a timely manner. This prevents admins from seeing a properly updated graph view in AAD or making additional changes like licensing or UPN changes (these changes mastered in AAD vs. mastered in EXO).
The Exchange Online and AAD teams have worked together to provide a new mechanism to synchronize the changes that originate in EXO and need to replicate to AAD without relying on the current back-sync mechanism.
Once this improvement is deployed to your tenant, when you make user object changes in Exchange the changes will now be dual-written to AAD and EXO. The end result is that the replication of those properties should be close to immediate and changes made in EXO will immediately reflect in AAD when the cmdlet completes successfully.
Note that this implies that there is now an AAD dependency when making such management changes. If AAD is unavailable for some reason when we attempt this dual-write you may see errors when executing an Exchange cmdlet or management action. This error will reference AAD. Note, that this change should be transparent to all the Exchange management operations you are doing today. There is absolutely no need to change your scripts or your usage of EAC or other Exchange APIs. You may see new errors, but they should be treated the same as you do today: re-run the cmdlet. If the issue persists when you open a support ticket, just mention that the error in Exchange is due to AAD and support should be able to help you redirect to the correct teams.
Here is an example of the cmdlet error that you might see. You can always get more detailed information if you get the full error trace:
[MultiTenant\BL0PR00MB0354] PS C:\Users\chsun> set-mailbox testDareen@dualwritetesting.onmicrosoft.com -CustomAttribute1 "demo test" An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online. However, it failed. The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information. + CategoryInfo : NotSpecified: (:) [Set-Mailbox], UnableToWriteToAadException + FullyQualifiedErrorId : [Server=BL0PR00MB0354,RequestId=6669e8ca-2919-450f-93d7-5757b75bef45,TimeStamp=3/15/2019 9:07:01 PM] [FailureCategory=Cmdlet-UnableToWriteToAadException] B6FABBF,Microsoft.Exchange.Management.RecipientT asks.SetMailbox + PSComputerName : bl0pr00mb0354.namprd00.prod.outlook.com
We hope you agree that this change is a good thing. We really want your admin and management experience to be as efficient and useful as possible, and this change eliminates one issue we were aware of that caused some pain.
Please do let us know what you think in the comments section below, and we hope you notice the improvement!
The Exchange Team
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.