Fixing Office 365 DirSync account matching issues

Recently I had to fix some issues with DirSync. For some reason (there were some cloud users created before DirSync was enabled) there were duplicate users, because DirSync failed to match the already present cloud user and the corresponding AD (Active Directory) user. There were also accounts that failed to sync and thus failed to sync all attributes properly.

If there is already a cloud account and there is need for a synced account, you can create an AD account in DirSynced OU’s. But be sure to create the user with a full UPN matching the one in Office 365 and SMTP addresses that are present on the Cloud account. With the next sync it should match both accounts. If not, it fails matching and you end up with either duplicate accounts (one cloud user and a DirSynced user with the same name/lastname/displayname) or get an InvalidSoftMatch.

When UPN/SMTP matching failed you can merge those accounts again by setting the ImmutableID on the Office 365 account (MsolUser) which is derived from the AD user’s ObjectGuid. You can only add this attribute to Office 365 accounts. After this is set, DirSync should match the accounts correctly.

So, how did I resolve this? See below:

When there are duplicates:

    • Remove user from DirSync (move to OU which is not synced, will only work when OU Filtering is used. If not, disable DirSync…).
    • Perform DirSync.
    • Remove duplicate synced user (NOT cloud user):
      • Remove-MSOLuser -UserPrincipalName <UPN> -RemoveFromRecycleBin
      • Add ImmutableID from AD user to Cloud user
        • $guid = (get-Aduser <username>).ObjectGuid
          $immutableID = [System.Convert]::ToBase64String($guid.tobytearray())
        • Connect to AD Azure (Connect-MSOLService when AD Azure Powershell Module is installed).
        • Set-MSOLuser -UserPrincipalName <clouduserUPN> -ImmutableID $immutableID
        • It’s possible that the clouduserUPN must be changed to the <tenant> format. It should be changed by DirSync to correspond with the AD UPN.
        • See also
    • Place account back in correct (synced) AD OU.
    • Manually kick off a sync on the DirSync Server if you don’t want to wait (up to 3 hours with default settings):
      • C:\Program Files\Windows Azure Directory Sync\DirSyncConfigShell.psc1
      • Start-OnlineCoexistenceSync

In my case it didn’t always match the accounts and was required to perform a Full DirSync (on DirSync server):

    • Via MIISClient, Management Agents:
      • C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\missclient.exe
    • Be sure to be member of local group “FIMSyncAdmins”
      Names might be different depending on DirSync version
    • On the Windows Azure Active Directory Connector:
      • Properties>Run>Full Import Delta Sync
    • on the Active Directory Connector:
      • Properties>Run>Full Import Full Sync
  • Note that a Full Sync can take a long time if you have a lot of objects. Furthermore, changes can take a while to propagate in Office 365.
  • It might be necessary to edit an attribute (Description, office etc. Something that is synced), and then perform a (normal) sync.

When you have an InvalidSoftMatch (SMTP Address matching doesn’t work because SMTP address already exists in Cloud):

Within the MIISClient.exe on the DirSync server, you can check for errors. In this case the account wasn’t properly matched:


  • Add ImmutableID from AD user to Cloud user:
    • $guid = (get-Aduser <username>).ObjectGuid
    • $immutableID = [System.Convert]::ToBase64String($guid.tobytearray())
    • Connect to AD Azure (Connect-MSOLService when AD Azure Powershell Module is installed)
    • Set-MSOLuser -UserPrincipalName <clouduserUPN> -ImmutableID $immutableID
    • It’s possible that the clouduserUPN must be changed to the <tenant> format. It should be changed by DirSync to correspond with the AD UPN.
    • See also
  • Then perform a sync as described in the previous section.

In my case these procedures resolved my issues. But as always, use this information at your own risk. Best to make sure that you don’t end up in a situation like this Winking smile

See also:

One or more objects don’t sync when using the Azure Active Directory Sync tool

How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization


  • Cor

    Nice article mate! Still valid only with different cmdline’s and DirSync is replaced ;). How’s it going anyway?

  • Q

    Sync’d a full AD and one user duplicated. Couldn’t figure it out but this article saved me.
    I also had to change the users UPN to the onmicrosoft account to link the GUID so I guess that was causing the problem from some reason.

    Any idea if this works when users have been synced to a different AD in the past and trying to sync to a new AD?

    Thank you!

  • Crayg

    I have tried this but keep getting an error inside powershell 3 when trying to run the cmdlet… The ‘<' operator is reserved for future use.

    How do I get around this so I can ImmutableID?

    • Jim

      Are you adding the “<" to the user name on the command line? If your = = guid = (get-Aduser joesmith).ObjectGuid


      Set-MSOLuser -UserPrincipalName -ImmutableID $immutableI

  • This complete article is stolen from the original without any references.
    WTF dude?! Reported to EU MVP leads.

    • Hi, thank you for bringing this to my attention.
      However, you might want to check publication date of both posts. My post predates the one you found and aligns better with the dates found in the screenshot.

    • FYI: I’ve contacted my MVP lead regarding this issue as well.

  • Thanks for this article which I found really useful kicking off my project to migrate a bunch of users using hard matching. I created a script which covered my needs and thought perhaps your readers may find useful. It’s available on my blog here


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.