Microsoft will release a new function to Office 365 and Azure Tenants.
A new feature called Duplicate Attribute Resiliency is being introduced in order to eliminate friction caused by duplicate UserPrincipalName and ProxyAddress conflicts when running one of Microsoft’s synchronization tools. This new feature is being rolled out across all of Azure Active Directory, and will be enabled for your tenant on starting at April. The new behavior that this feature enables is in the cloud portion of the sync pipeline, therefore it is client agnostic and relevant for any Microsoft synchronization product including Azure AD Connect, DirSync and MIM + Connector. Please read on to learn how this change impacts the way Azure Active Directory handles these specific certain types of Identity synchronization errors.
If there is an attempt to provision a new object with a UPN or ProxyAddress value that violates this uniqueness constraint, Azure Active Directory blocks that object from being created. Similarly, if an object is updated with a non-unique UPN or ProxyAddress, the update fails. The provisioning attempt or update is retried by the sync client upon each export cycle, and continues to fail until the conflict is resolved. An error report email is generated upon each attempt and an error is logged by the sync client.
New Behavior – with Duplicate Attribute Resiliency
- Instead of completely failing to provision or update an object with a duplicate attribute, Azure Active Directory “quarantines” the duplicate attribute which would violate the uniqueness constraint.
- If this attribute is required for provisioning, like UserPrincipalName, the service assigns a placeholder value. The format of these temporary values is “+<4digitnumber>@.onmicrosoft.com”.
- If the attribute is not required, like a ProxyAddress, Azure Active Directory simply quarantines the conflict attribute and proceeds with the object creation or update.
- Upon quarantining the attribute, information about the conflict is sent in the same error report email used in the old behavior. However, this info only appears in the error report one time, when the quarantine happens, it does not continue to be logged in future emails. Also, since the export for this object has succeeded, the sync client does not log an error and does not retry the create / update operation upon subsequent sync cycles.
The way all other types of errors are processed remains unchanged, this feature is only relevant for duplicate UserPrincipalName and ProxyAddress conflicts.
To read more about the behavior change along with identifying and resolving conflicts, please see this article: Identity synchronization and duplicate attribute resiliency
Also published on Medium.