We recently encountered an SMTP matching error with a new Dirsync setup. The error occurred with a brand new on-premises domain for a customer that had several existing Office 365 user accounts "in the cloud". We were able to pair most of the new AD accounts with the existing 365 accounts automatically using
SMTP matching, by configuring the new users with the right UPNs and proxyAddresses attribute(s).
SMTP Matching Error
Unfortunately, a couple of the new accounts were refusing to be matched, leaving us with the Office 365 accounts unmatched and still "in the cloud". We also began getting error reports via email each time the sync ran, stating:
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
Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.
Here's a screenshot of the entire email (identifying info removed):
The problem was the links in the email weren't particularly helpful for solving the SMTP matching error in our case:
- The Directory Synchronization Troubleshooter was failing to run with no useful error.the
- The KB article (KB2647098) only suggests some ways to identify where the duplicate values arise (the email was suggesting the ProxyAddresses attribute). However, IdFix reported no problems, and we were unable to find duplicate attribute values based on the instructions.
- The final link takes you to a page about a new duplicate attribute resiliency feature, however, this wasn't yet rolled out for this 365 tenant, and we did not appear to have any duplicate attributes anyway.
We proceeded to get our Google-Fu on and found some helpful info from a few places which lead us to believe the issue, despite the "duplicate attribute values" errors being reported in the email, was actually related to the "immutableID" attribute on the 365 users.
What we found out:
- When accounts are "in the cloud", they don't have an immutableID.
- When accounts are DirSync'd their immutableID is derived from the users ObjectGUID attribute on the active directory.
- Where SMTP Matching was failing, the users already had immutableID, likely from a previous DirSync setup.
How we fixed it:
On the DirSync server we used the Azure Active Directory Module for PowerShell to connect to the Office365 tenant:
Connect-MsolService
We checked, and made a note of, the immutableID for the 365 user accounts:
Get-MsolUser -userprincipalname 365USERNAME | Select immutableid
We set the 365 users immutableID attribute to null:
Set-MsolUser -userprincipalname 365USERNAME -immutableid "$null"
We then forced a sync using the ADSync PowerShell module:
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta
Once this sync completed, we found the SMTP matching had worked correctly! The accounts were now DirSync'd. We checked the ImmutableID again; there was a new value. Using the following commands, we could see it matched ObjectGUID for the AD account (once converted):
$guid = (Get-ADUser ADUSERNAME).objectguid
[System.Convert]::ToBase64String($guid.ToByteArray())
Our Conclusion
SMTP Matching is fantastic for situations where you have accounts in the cloud which need to be converted to DirSync'd accounts but, if you have encounter failures, the error messages you receive may be misleading! It seems the immutableID attribute for the 365 accounts must be blank for SMTP matching to work, after which it will have a value which is derived from the AD accounts objectGUID.
Thanks to the following sites for providing the information we needed to get this sorted:
https://dirteam.com/dave/2014/08/15/fixing-office-365-dirsync-account-matching-issues/
http://www.thecloudtechnologist.com/dirsync-soft-matching-vs-hard-matching/
https://misstech.co.uk/2016/02/05/setting-the-immutableid-to-null/