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.
Just as it is the case today, two specific attributes of tenant admin accounts (Phone number and Mobile phone number) will not be editable from Exchange Online after this feature is released. Because those can be used to validate password changes, Admin needs to modify them directly in AAD.
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.
For deleted items, incremental property updates are synced to EXO, however same will not be synced to AAD until the deleted item is restored as per guidance mentioned here. Once deleted item is restored, dual-write syncs incremental updates that happened to the item during deleted state on best effort basis.
For Groups, sync from EXO to AAD by Dual-write is supported only for group with RecipientTypeDetails (RTD) as MailNonUniversalGroup, MailUniversalDistributionGroup, and MailUniversalSecurityGroup. Groups with other RTD, e.g., ExchangeSecurityGroup, DynamicDistributionGroup are not supported.
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
How to know if this has rolled out to your tenant?
To find out if this change has already rolled out to your tenant, you can run the following CMDlet; note that if the value does not display for your tenant at all, you can interpret that as “False”:
PS C:\Users\admin> Get-OrganizationConfig | fl IsDualWriteEnabled
IsDualWriteEnabled : False
Audit log entries with actions by “Microsoft Substrate Management”?
Once dual-write is enabled on your tenant, as part of dual-write operations, you will see audit log entries with actions taken by “Microsoft Substrate Management”. “Microsoft Substrate Management” is a service principal used by Exchange Online during dual-writing operations to AAD. These audit log entries refer to create/update/delete operations executed by EXO to AAD. These entries are informational in nature do not require any action.
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!
Microsoft
