Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 3

Reading Time: 4 minutes

In the first part of this series, I’ve explained how Azure AD Connect version 1.1.553.0 and beyond allows you to switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute , the benefits of doing so and what you may and may not expect when you make the switch.

Now that I’ve shown you the changes in Part 2 of this series, it’s time to see how you’d actually perform the switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute, when you come from a previous version of Azure AD Connect to version 1.1.561.0, or up. (since new installations of Azure AD Connect are automatically configured with mS-DS-ConsistencyGuid as the source anchor attribute).



Plan the switch

When you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute for Azure AD Connect, it will trigger a Full Synchronization cycle. With current Full Sync cycles as long as 42 hours for some organizations, it is important to plan the switch at a point in time, that does not bode a slew of changes in on-premises objects. During the Full Synchronization no other cycles may run; any changes you make will flow to Azure AD only after the next synchronization cycle(s).

Document the Azure AD Connect configuration

In case something goes wrong, it’s a nice feeling when you know how to recreate the Azure AD Connect configuration. Documentation also helps you to perform root cause analyses when something goes wrong, and formally sign off on the changes in synchronization rules.

The following lines of PowerShell code will help you achieve this goal:

Import-Module ADSync
Get-ADSyncServerConfiguration -Path "C:\Install\Docu"

Document the Active Directory Federation Services (AD FS configuration

When you utilize Active Directory Federation Services (AD FS) for your Azure AD authentication scenario, it’s also a good idea to document the AD FS configuration before and after you switch.

The AD FS Rapid Recreation Tool does the job.

Ensure you can restore your Azure AD Connect Installation(s)

Making backups may be considered to be the most important safety net some systems administrator will come up with. However, being able to restore your Azure AD Connect installation(s) is more important. Make sure you can, by performing a test restore.

Do the work

As I mentioned in part 1 of this series, when you make the switch, you’ll need to make the switch on all Azure AD Connect installation(s) in your environment. Don’t forget to make the switch on your Staging Mode servers, because the source anchor attribute is a per-Azure AD Connect setting.


Switch Azure AD Connects Source Anchor

Perform these steps:

  • Log on interactively to the Windows Server installation that runs Azure AD Connect.
  • Open Azure AD Connect using the link on the desktop or by searching for (part of) its name in the Start Screen and then clicking it in the search results.
  • Click the Configure button on the Welcome to Azure AD Connect screen.

Azure AD Connect - Additional tasks (click for original screenshot)

  • Click on Configure Source Anchor in the Additional tasks screen.
  • Click Next.
  • Enter the credentials of an Azure AD account with Global Admin privileges for the Azure AD tenant you’re synchronizing with. Perform multi-factor authentication when this is configured.

Azure AD Connect - Configure Source Anchor (click for original screenshot)

  • The Configure Source Anchor screen provides more information on the source anchor best practice and informs you that Azure AD Connect did not find any other application that uses the mS-DS-ConsistencyGUID attribute. Click Next.

Azure AD Connect - Ready to configure (click for original screenshot)

  • In the Ready to configure screen, click Configure.

If you can’t perform the Full Synchronization associated with the Source Anchor switch, deselect the Start the synchronization process when configuration completes. option. Run the full sync at a better time, but please be aware that all synchronization stops until you manually trigger the full synchronization,

Azure AD Connect - Configuration complete (click for original screenshot)

  • Click Exit in the Configuration complete screen.

Azure AD Connect performs the Full Synchronization cycle. Half an hour after this cycle ends, by default, it will perform a delta synchronization cycle.


Additional Tasks

Switch Staging Mode Servers

When you have Staging Mode Azure AD Connect installations, perform the same steps on these servers.

Document Azure AD Connect Changes

When you want to document your changes in Azure AD Connect, run the PowerShell cmdlets mentioned above again. A tool like the Azure AD Connect Configuration Diagrammer provides a quick overview of the changes in the Azure AD Connect configuration.



That’s all there is to know about switching from ObjectGUID to mS-DS-ConsistencyGUID as Azure AD Connect’s source anchor attribute for user objects.

Good luck! Duim omhoog

10 Responses to Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 3


    And still it would be nice to know how to change adfs 🙂 Not everyone uses the auto configuration for adfs. Also what to do when adfs is already present and not ad connect managed? Or are we getting a part 4 adfs 🙂 ? Futhermore thank you sir!


    In a cross-forest migration scenario where the source forest will be decommissioned, the source anchor must be changed from objectGUID to something like ms-ds-ConsistencyGUID not only for user objects but also for groups and contacts. I know this can be done in the Synchronization Rules Editor but is there any good documentation etc. you are aware of that details how to do this?

    • Hi Guillermo,

      I feel Roelf Zomerman has some good guidance on this:
      ImmutableID – mS-DS-ConsistencyGuid – ADConnect
      ImmutableID – mS-DS-ConsistencyGuid – AADSync

      Roelf is an Active Directory MCM and today works as a PFE at Microsoft Gulf.
      His blogpost refers to user objects (and thus also InetOrgPerson objects) only, but there might be sufficient guidance there for groups and contacts, too.

      Please note that Roelf's employment and my recommendation of his work will in no way imply support by Microsoft.


    Thank you very much.


    When making this change is it possible to do it on a staging server first? That way you could let the staging server perform it's full import/sync and then make it the active server which would hopefully reduce the amount of time your syncs are paused as it would only need to do a full export?

    • Hi Marc,

      Since Azure AD Connect in Staging Mode doesn't perform exports, it can't populate the mS-DS-ConsistencyGUID for objects in scope. The active server needs to perform the exports and , then, the Staging Mode server needs to be configured to use the same configuration as the actively synchronizing Azure AD Connect installation.


    I found in the Azure AD Connect: Design concepts article the following paragraph:

    "Only newer versions of Azure AD Connect (1.1.524.0 and after) stores information in your Azure AD tenant about the sourceAnchor attribute used during installation. Older versions of Azure AD Connect do not."

    Do you know how I can query this stored information from the AzureAD tenant ?

    • Hi Jens,

      According to the Graph Explorer (, the sourceanchor value seems to be stored in a user attribute called onPremisesImmutableId. You might be able to query this attribute using the Azure AD PowerShell Module and the Graph Explorer.

      In Azure AD Connect's Synchronization Service interface, the attribute is labeled as sourceAnchor in the Azure AD Management Agent (MA), though.


    Hi Sander,
    thanks for you answer but if I understand the quoted paragraph correctly there must be a global setting in the Azure AD tenant where the currently used sourceAnchor attribute is stored not only in the synchronized user objects. If I delete all synchronized users and uninstall Azure AD Connect and install it on another on premise server, during the initial connect to the still existing tenant the new Azure AD connect setup is able to determine that "ms-DS-ConsistencyGuid" is used as sourceAnchor. So there must be a global setting in the Azure AD tenant, but I dont know how to query it ?

    Best regards



    I know I'm bringing this 3 part series back from the dead, but we're still utilizing the objectGUID and would like to move to the mS-DS-ConsistencyGuid in the hopes it will resolve issues with recovery on soft deleted accounts/mailboxes similar to that discussed in Part 1.

    We just spoke with a Microsoft engineer with Premier support who stated we cannot do what you're describing without changing the ImmutableID to null on all accounts. There was a suggestion to do this: Get-MsolUser -All | Set-MsolUser -ImmutableId $null and he also walked through a couple other steps that was fairly daunting and not something I'd want to attempt in a production environment, and unfortunately I don't have a test environment for this sort of thing.

    At no point do you discuss any sort of complications or errors that may occur with syncing caused by issues with the ImmutableID. Could you shed some light on what his concerns were?

    I had already read through and was arguing with this engineer and we both had valid arguements. Towards the top it basically says you cannot change the SourceAnchor once established, and then towards the bottom it says, here's how you do this for an existing installation.

leave your comment

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