Many companies, which use Office 365, especially Exchange Online, often do one thing during the onboarding phase:
The companies import contacts into their Office 365 tenant, in order to feed the Global Address List (GAL) with users and contacts, which the already onboarded users can then address via the GAL.
This setting is also helpful, when a multinational company decides to go for Office 365 (Exchange Online), where all users are not in one single Active Directory, but there is a multi-forest AD construct established. The migration or onboarding of all users is usually not a task within a couple of weeks, but months or years. Therefore, the use of contacts, which are imported into the Office 365 tenant, is useful for the already migrated users, so that the GAL is already populated from the beginning on during the migration process. This is always a requirement for the management board, because these kind of users are not in favor of remembering the contact information of all their colleagues.
The administrators usually have to fulfill the following steps for creating contacts from user objects originated in a different AD forest, which cannot be synchronized at first:
- Export user objects and relevant attributes from AD forests
- Import these objects as MailContacts (via O365 admin portal or PowerShell – New-MailContact)
When the contacts are created in the O365 tenant and the users then have to be synchronized from the local AD, this will cause an error in Azure AD Connect. But why? SMTP match is a supported method of joining a local user object with a cloud object, if the SMTP address matches (which is usually the case when creating contacts in O365).
But there is a significant problem: The type of the contact, which was created in O365 – the MailContact
This is the default object type, when a contact is created via the O365 admin portal.
The following graphic should illustrate the problem:
In the AADConnect synchronization service, you will get the following error message: “InvalidSoftMatch”, which is described here: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sync-errors
So what is the solution to this? The answer is easy: Replace the MailContact objects with MailUser objects. This can either be done by GUI or automated via PowerShell (Remove-MSOLContact followed by New-MailUser). This leads to the fact that if the user then gets created in the local AD and therefore gets synchronized via the Azure AD Connect service, the AD user gets merged via the SMTP soft-match mechanism and the MailUser in the AAD gets converted to a synchronized AD user:
So therefore: heads up when creating contact objects, if the contacts represent users, which eventually get synchronized via AADConnect sooner or later.