Microsoft has made a couple pretty big changes to how UPN syncs and how soft matching works when syncing to Azure AD.

Synchronization of UPN Updates for Licensed/Managed Users

Historically Microsoft has blocked all updates to UserPrincipalName via Sync from On-premises if the User is managed (non-federated) and has been assigned a license. This behaviour is described under scenario 2 of article User names in O365, Azure or Intune don’t match on the on-premises UPN or alternate login ID (in the process of being updated).

This feature changes that behaviour, allowing the update to be processed. This has been enabled by default in tenants created after June 15, 2015 but tenants created before June 15, 2015 now have the option to opt-in to this behaviour by running the PowerShell cmdlet:

Note: Unfortunately, this does not affect the federated domain to federated domain rename restriction described in scenario 3 of this article https://support.microsoft.com/en-us/kb/2669550.

UserPrincipalName Soft Match (Preview)

When this feature is enabled the normal soft-match logic still applies, but if we fail to match on the primary SMTP Microsoft will fall back and attempt a match based on UserPrincipalName instead. This is particularly useful for customers who need to match on-prem Active Directory accounts with existing accounts created in the cloud, but are not using Exchange Online and therefore generally don’t have a reason or means to set SMTP in the cloud.

The documentation for this feature is coming soon, but the customer can enable this feature by running the PowerShell cmdlet

Identity Synchronization and Duplicate Attribute Resiliency

Duplicate Attribute Resiliency is a feature in Azure Active Directory designed to eliminate friction caused by UserPrincipalName and ProxyAddress conflicts when running one of Microsoft’s synchronization tools. The UserPrincipalName and ProxyAddress attributes are generally required to be unique across all User, Group, or Contact objects in a given Azure Active Directory directory.

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 will assign a placeholder value. The format of these temporary values is

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.

For more information about this, see https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsyncservice-duplicate-attribute-resiliency/

Written by Misha Hanin

Trusted Business & Technology Advisor, Solutions Managing Director & Senior Solutions Architect at iRangers International Inc. with more than 25 years of experience in the field of information technology, infrastructure analysis and design, implementing innovative and leading technologies for International companies around the globe in public and private sectors.

Over the years I was able to develop very strong technical and engineering skills which helped me to earn trusted advisor status with our clients. As one of the nearly 500 trained Microsoft Certified Masters (MCM) in The World (during 10 years existence of MCM program, just about 500 people in The World participated in this very intensive training), I have a winning track record in building and bringing projects to operational and measurable success.

I am honored to have been awarded Microsoft Most Valuable Professional (MVP). This award is given to "exceptional, independent community leaders who share their passion, technical expertise, and real-world knowledge of Microsoft products with others."