Azure AD Connect - procedure to change source of anchor from ObjectSID to Ms-DS-ConsistencyGUID

Occasional Contributor


We are an organization of + 1000 users with ADs (domain and subdomains) linked to Azure AD via Azure Ad Connect.


Currently the anchor source is ObjectSID, UPN = mail and Hybrid Exchange.


We would like to change it to MS-DS-ConsistencyGUID in order to be able to move objects easily between ADs without impacting the Azure AD accounts. (Or find a tested procedure)


We have found documentation about changing the anchor source for ObjectGUID attributes to MS-DS-ConsistencyGUID but not much for attributes other than ObjectGUID.


I have read and tested several ideas but nothing is 100% risk free.


For you, what is the best procedure to change this anchor source without loss of connection/identification for the end user (on Office 365 for example)?
BTW = Soft Delete is not an option unless we have no choice

8 Replies


The sourceAnchor attribute value cannot be changed after the object has been created in Azure AD and the identity is synchronized.

The sourceAnchor attribute can only be set during initial installation. If you rerun the installation wizard, this option is read-only. If you need to change this setting, then you must uninstall and reinstall. If the value for sourceAnchor is changed after the object has been exported to Azure AD, then Azure AD Connect sync throws an error and does not allow any more changes on that object before the issue has been fixed and the sourceAnchor is changed back in the source directory.


Please refer to MSDocument for details.

Exactly, in the end I opted for a re-match using a script to connect the Azure AD accounts with the newly created AD accounts.
This approach allowed me not to have to reinstall or to change the Azure AD connector and I had almost no downtime.
If you are interested in this solution please contact me for more details.

@GaetW Can you explain how you did this re-match with a script?  We have talked to MS in the past about changing the Source Anchor and they were unable to come up with any ideas other than rebuilding the entire Azure AD environment.  

@GaetW We did this previously because we were using extenstionAttribute1 because of multiple domains and trying to keep the source anchor consistent across multiple domains.


When we contacted MS about this, we got the following procedure (copied straight from the email we got back).  It will require a full disconnect of AADConnect.


  1. Turn off Directory Synchronization for Microsoft 365 via PowerShell
  2. Wait 72 hours to change the status of user accounts in the cloud from synced to Cloud Only
  3. During the 72 hours, obtain the following information:
    • Take note of all settings and configuration modifications in AzureAD Connect. This service resides on aadsyncserver
  4. Export all user ImmutableIDs to external CSV file for recovery if needed.
  5. Verify all users are cloud only, then delete all Immutable IDs from cloud users.
  6. Verify all users have a null Immutable ID.
  7. Uninstall AzureAD Connect on sync server.
  8. Reinstall AzureAD connect on sync server and configure using ms-ds-consistency-guid as new source anchor
    • In configuration, remove decommissioned domains – and
    • These domains are no longer in use in Azure.
  9. UPN and Primary SMTP Address of user accounts on-premise will soft-match with users in the cloud.
    • During this sync cycle, on-premise object will sync and obtain a new ImmutableID and place that new attribute in the correct location.

There is no downtime using this method. Just a temporary desync of objects for a weekend.


There is a risk of some passwords becoming unsynced as people reset or change passwords, but we mitigated this by requiring anyone who had a password change near our maintenance window to update it before we started. We also had a process to allow people to access both on-prem resources and office 365 if they did need a password reset.

I meant to @ you. I posted my reply with the steps.
Before proposing the solution, I invite you to test it because it depends on your ADDC configuration and your Azure Ad connect. As well as the architecture of your domains.
This solution works under the Azure AD connect version 1.XXX

The idea is to remap the Azure AD accounts present on the cloud with a user AD object present in another domain.

Prerequisite, your "new" domain must be known under Azure AD.
Our new AD user object will be remapped to the Azure AD account. The old one will remain in its domain before eventual decommissioning in order to be able to do a rollback if necessary.
Procedure :

Each new AD object has a SID object which is used for rematching.

Please make a backup of the old AD accounts and Azure AD accounts with the parameters SamAccount, Username, Mail, SID for AD and UserPrincipalName, ImmutableID, ObjectID for Azure under a CSV

It is advisable to temporarily stop your Azure AD sync in order not to launch a sync during your maipualtions. But if your CSV and powershell scripts are performing well, it is not necessary!

Procedure for an account
Retrieve the information of your New User Object
get-aduser -server XXXX -Filter {sAMAccountName -eq "SamAccount"} | Select-Object SamAccountName,SID, UserPrincipalName | Export-CSV -path C:{yourPath}
When you have your information you can already create the new ImmutableID which will allow the matching of the two accounts. To do this, we take the SID of our new user and we will parse it with the PowerShell command below then we will store the immutable ID in a separate CSV or on the same CSV
$userSid = $user.SID
$SidStrAc = $userSid.value
$ot = New-Object System.Security.Principal.SecurityIdentifier($SidStrAc)
$c = New-Object 'byte[]' $ot.BinaryLength
$c | %{ $out += $("\{0:x2}" -f $_) }
Now you have your ImmutableID linked to your new user

We'll move on to the rematching stage

1. Move your old USER to an OU not synchronized with AZure AD. By performing this step, your Azure AD account linked to your old AD account will be moved to the deleted user
2. Go to Azure AD and restore the account, will become Cloud Only (isolated from AD) but you will not lose any data - retention
3. Via powershell, you will now force the new immutable ID
Set-Msoluser -UserPrincipalName YOURUSERNAME -ImmutableID YOURNEWIMUTABLEID
4. Make sure the new immutableID is added to your azure Ad account
get-Msoluser -UserPrincipal YOURUSERNAME | Select-Object UserPrincipalName, ImmutableID, ObjectID
4.Go to your other ADDC and move your new account from a non-synchronized OU to a synchronized OU. force the sync if necessary
5. It is possible that your account will revert to delete user as the matching of the account on the azure ad sync database did not work correctly.
Don't panic, go back to Azure AD, restore your account again and re-sync your Azure AD.
6. If you need to change the userprincipal name do it now by forcing the new one with this command
Set-MsolUserPrincipalName -UserPrincipalName OLDUSERNAME -NewUserPrincipalName NEWUSERNAME

Known problems:
Problem matching boxes between Exchange ECP and Exchange Online after move.
To fix this you often have to rematch the information from your Exchange ECP and your Exchange Online which is often linked to the Archive under ECP.
Here is an article about this problem :
About Rollback procedure, if you have saved the immutable ID of your old account, redo the operation with this old immutable ID. This will remap the old AD user with the corresponding Azure AD account.
If you did not save the immutable ID of your old account, then you will have to rerun the parsing code of the SID attribute before launching the rematching procedure.