Manually match On Premise AD-user to existing Office365 user


Have you ever been in the situation where there is a mismatch/no match between AD users and O365 users? If so, you know it’s not easy to fix it. If not, this article can save you a lot of time, when you are in that situation.


You probably wonder how you get there. Well, multiple scenario’s are possible: an existing O365 tenant that needs to be synced with Active Directory, a failed installation of Azure AD Connect, a move of Azure AD Connect that doesn’t go well or simply bad configuration to start with.


When that’s the case, it is possible that the users in AD are not syncing with the corresponding user in O365. Even worse, a second account is created with the suffix. What now?

In theory: just set the ObjectGUID of the AD user as ImmutableID of the O365 user and job done. But we all know that in IT, the theory and executing the theory is not the same.


First of all, the ObjectGUI needs to be retrieved from AD. If we check the attributes of a user, we can find this easily:


Only problem: it’s not in the correct format. O365 won’t accept this format, so we need another way to retrieve this attribute: LDIFDE.

LDIFDE is a tool to export/import data from/in Active Directory. More info about can be found on So let’s use the following command to export our user:

ldifde -d “DistinguishedName of the user” -f “c:\temp\exporteduser.txt”

If we check the exported file and look for the ObjectGUID, we can see it’s in another format:

And that is the format we need to set the ImmutableID in O365.


To set the ImmutableID in O365, execute the following command (after making connection to O365) in PowerShell:

set-msoluser -userprincipalname -ImmutableID xxx

Change the “xxx” with the ObjectGUID retrieved from the textfile. Now the user in AD will be synced with the user in O365.


Note: this probably won’t work from the first time. Whenever you have a mismatch, there is a change that the ImmutableID from the textfile is already set to a user. When you trying to set the ImmutableID, you will receive following error:

To find which O365 users has that ImmutableID, execute following command:

Get-MsolUser -All | Where-Object {$_.ImmutableID -eq “SV+BWQuSnU6tbIK1OqTBAg==”}

Note2: be aware that O365 also has deleted users, that doesn’t show up with the command above. To find out if the ImmutableID is set to a deleted user (most of the times the ImmutableID will be already set to a deleted user and the above command won’t return any results), execute the followin command:

Get-MsolUser -All -ReturnDeletedUsers | Where-Object {$_.ImmutableID -eq “SV+BWQuSnU6tbIK1OqTBAg==”}

This will give you the same result, but for the deleted users. Hard delete the user in Office 365 and you can set the ImmutableID for the correct user.

Note3: if you have a lot of users to do, it’s pretty easy to script this!




Print Friendly, PDF & Email

14 comments on “Manually match On Premise AD-user to existing Office365 user”

  1. Phil says:

    this is EXACTLY what I needed! fixed my issue. THANK YOU.

  2. David says:

    Arne, I assume this only works if the objectguid is the source anchor? -Thanks

  3. Luke says:

    Incredible!!! – After reddit surfing, google surfing, trying everything and beating my head against the wall – THIS IS EXACTLY what I needed! Thank you a million for sharing this.

  4. Jojo says:


  5. Daniel van Dijk says:

    Great article Arne, worked like a charm!

  6. Hunter says:

    This was very helpful. Has anyone created a successful script for this?

  7. Troy Hedgepeth says:

    This post is AWESOME! Even Microsoft had trouble solving this issue. But your guide had it done for me on two users in just a short period of time. You can believe I documented it too!
    Thank you,

  8. John says:

    For anyone running into this issue, I wrote a script to re-link users for an ou to Azure AD. In my case, I moved all users from the ou I wanted to re-sync to Temp, ran the script, moved users back to the desired ou and re-ran the sync.

    Import-Module ActiveDirectory

    $user = $null

    $Path = “c:\temp\exporteduser.txt”

    # Load all users in the specified ou
    $users = Get-ADUser -SearchBase “ou=Temp,dc=somedomain,dc=com” -Filter *

    # Connect to Azure AD

    # Make sure Soft Match is enabled (It should be enabled by default after 2016)
    Set-MsolDirSyncFeature -Feature EnableSoftMatchOnUpn -Enable $True

    # Iterate through users and link their guid as Immutable ID in Azure
    ForEach($user in $users)
    $distinguishedName = $user.distinguishedName

    # Write the user data to a temp file with the guid in the correct format for AzuerAD
    ldifde -d $distinguishedName -f $Path

    # Find the objectGUID in the ouput file
    $guidLine = Select-String -Path $Path -Pattern ‘objectGUID’
    $lineLenght = $guidLine.ToString().Length
    $guidStart = $guidLine.ToString().IndexOf(“objectGUID:: “) + 13
    $guid = $guidLine.ToString().Substring($guidStart, $lineLenght – $guidStart)

    Write-Host “Setting Immutable ID: ” $guid ” for User: ” $user.UserPrincipalName

    # Update the Immutable Id in Azure AD so the on premise user will match on sync
    set-msoluser -userprincipalname $user.userPrincipalName -ImmutableID $guid

    # force a resync with Azuer AD
    Start-ADSyncSyncCycle -PolicyType Delta

    Write-Host User re-link complete

  9. gabriel says:

    I managed to perform the hard match successfully but it is updating my cloud upn by adding @onmicrosoft and adding a different domain.
    Example: onprem: user1@contoso.orh
    – export objectguid
    – upload cloud immutableid
    – disable softmatch
    – enable hardmatch
    – run sync
    – cloud upn become:

    why is changing the upn?

  10. Henric Strömgren says:

    thank you for thinking of others! this is what Internet is for! when nothing else worked this worked like a charm.

  11. John C says:

    Arne. You’ve just saved someones job! 😉

    Thank you.

    FYI for all not in the know the Distinguished name is the one that looks like this “CN=NameOfUser,OU=Users etc”

    Can be found in advanced attributes when you remove the filters.

    1. James says:

      Hey John,

      Is there something I need to do prior to running the LDIFDE command? when entering (this is an example) ldifde -d “CN=user,OU=example,OU=Users,OU=MyBusiness,DC=dc,DC=local” -f “c:\temp\exporteduser.txt” i’m getting “No log files were wrtitten. In order to generate a log file, please specify the log file path via the -j option.” Much appreciated

      1. James says:

        Disregard! thank you

  12. Giovanni Pisati says:

    Arne, you have saved my poor career. I had exactly the same error of the duplicate accounts created in AAD. It was not easy, but following your guide I was able to re-associate the ImmutableID and then my account started syncing.
    Thanks and keep on with the excellet work

Leave a Reply

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