It is has become very common across most organizations that they set up an Office 365 tenancy or Azure tenancy without configuring integration with their own on-premises Active Directory or another scenario an organization has been brought by another company. The end-users are then given cloud-only accounts until such a time where they can be fully integrated. In going down this road it can potentially cause a number of issues that need to be resolved by either soft matching or hard matching the on-premises AD User with the Cloud Account.
How do I soft match?
Soft matching is driven by the SMTP Address of the user account and usually, the UPN matches the SMTP Address. So in the diagram below that, I have created you can see I have captured the two scenarios organizations move their on-premises identities to Azure Active Directory. What I have also done is put a deliberate mistake into the images, can you spot what it is?
So User D and Cloud D are the same users but the UPN is different, why have I done this? This is to explain the behavior that will happen if the account cannot be correct identified with its cloud account. User A to C will all synchronize successfully and correctly however, User D will not succesfully be synchronized as the UPN that doesn’t match Cloud D. While this isn’t a bad issue for this scenario but if you were actioning at scale, I hope you are ready for a host of complaints from users.
Its is important to ensure that the SMTP Addresses on-premises vs. the cloud but please be aware there are limitations like in any Microsoft product
SMTP matching limitations
The SMTP matching process has the following technical limitations:
- SMTP matching can be run on user accounts that have a Microsoft Exchange Online email address. For mail-enabled groups and contacts, SMTP matching (Soft match) is supported based on proxy addresses. For detailed information, refer to the “Hard-match vs Soft-match” section of the following Microsoft Azure article:
Azure AD Connect: When you have an existent tenant
Note This doesn’t mean the user must be licensed for Exchange Online. This means that a mailbox that has a primary email address must exist in Exchange Online for SMTP matching to work correctly.
- SMTP matching can be used only one time for user accounts that were originally authored by using Office 365 management tools. After that, the Office 365 user account is bound to the on-premises user by an immutable identity value instead of a primary SMTP address.
- The cloud user’s primary SMTP address can’t be updated during the SMTP matching process because the primary SMTP address is the value that is used to link the on-premises user to the cloud user.
- SMTP addresses are considered unique values. Make sure that no two users have the same SMTP address. Otherwise, the sync will fail and you may receive an error message that resembles the following: Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:firstname.lastname@example.org;]. Correct or remove the duplicate values in your local directory.
Hard-match works in a simalar way but uses the ImmutableID of the user accounts. This is unique value that each account has, so to hard match the on-premises ImmutableID to the cloud account would mean that you modify every single Cloud account with the correct on-premises account value. I know this from experience as I had to do just that for one of my customers and created a powershell script to enable the change.
The Author – Blogabout.Cloud