Migrating sourceAnchor from objectGUID to mS-DS-ConsistencyGuid: the pitfalls

What the sourceAnchor is, and why it must never change

Every user synchronised from on-premises Active Directory to Entra ID carries a sourceAnchor: a value that permanently ties the AD object to its Entra ID counterpart. In Entra ID you'll find it as the ImmutableID on the user object. The name gives it away — this value is supposed to stay the same for the entire life of an identity.

If the sourceAnchor does change, synchronisation no longer recognises the AD object and the cloud object as the same thing. The result: duplicate users, broken mailbox links, people locked out of their accounts, or sync errors that ripple across the whole environment. In environments we take over from other administrators, a badly chosen sourceAnchor is one of the most common time bombs we find.

The problem with objectGUID

Older installations of Azure AD Connect (now Entra Connect) default to the objectGUID attribute as the sourceAnchor. At the time that seemed reasonable: every objectGUID is guaranteed unique and never changes — as long as the object stays inside the same forest.

And that's exactly where it goes wrong. The objectGUID is issued by Active Directory itself and cannot be carried over:

• Cross-forest migrations: move a user to another forest (a merger, an acquisition, a domain consolidation) and the object gets a brand-new objectGUID in the new forest. The link to the existing Entra ID object breaks.
• AD rebuilds or restores: rebuild a domain and every object gets fresh GUIDs.
• Moving to a new AD environment: same story — new objects, new GUIDs, broken matches.

The mS-DS-ConsistencyGuid attribute solves this. It's a writable attribute you can take with you during a migration: copy the value onto the object in the new forest and the link to Entra ID survives. Microsoft has recommended mS-DS-ConsistencyGuid as the default for years, and new Entra Connect installations use it automatically. But environments that were set up on an older version often still run on objectGUID — until the day it bites.

How the migration works

The good news: Entra Connect supports switching from objectGUID to mS-DS-ConsistencyGuid as a built-in scenario, without re-matching existing objects.

The principle is simple. During the switch, Entra Connect writes each synchronised object's current objectGUID value into the (empty) mS-DS-ConsistencyGuid attribute in AD. The sourceAnchor value doesn't change — only the attribute it's read from. That's why every existing match stays intact. From that point on the value is portable: in a future forest migration you carry the attribute across and the identity stays linked.

The switch itself runs through the Entra Connect wizard: Configure → Configure Source Anchor. The wizard detects that objectGUID is in use and offers the migration to mS-DS-ConsistencyGuid.

Pitfall 1: write permissions for the connector account

Entra Connect needs to write the mS-DS-ConsistencyGuid attribute on every synchronised object. The AD connector account (the service account Connect uses to read and write in AD) doesn't always have that permission — especially when the account was once set up by hand with minimal rights.

Before migrating, verify the connector account has write access to mS-DS-ConsistencyGuid on all in-scope OUs. If the permission is missing, the wizard silently fails to stamp part of your objects and you end up with a half-finished migration: some objects with mS-DS-ConsistencyGuid populated, others without. That's painful to troubleshoot, because on the surface synchronisation just keeps running.

Pitfall 2: mS-DS-ConsistencyGuid is already in use

The attribute may already be populated. We see this in environments where a previous migration was done, where another identity product (Okta, or an earlier sync tool) claimed the attribute, or where administrators filled it manually for a hard match.

Inventory this up front. Objects whose existing value differs from their objectGUID deserve individual attention: if the differing value is correct (say, after an earlier cross-forest move), it must be preserved. If it's a leftover from something old, clean it up deliberately before running the wizard. A simple PowerShell inventory takes five minutes to set up and saves hours of head-scratching afterwards.

Pitfall 3: AD FS and the ImmutableID claim

If the environment still federates through AD FS, the ImmutableID is issued as a claim at sign-in, and the claim rules reference whichever attribute serves as the sourceAnchor. When Entra Connect manages the AD FS farm, the wizard updates the claim rules for you. When AD FS was set up manually — which in practice it usually was — you have to update the ImmutableID issuance rule to mS-DS-ConsistencyGuid yourself.

Forget this and AD FS keeps issuing the old claim after the migration, and federated sign-ins can break. Plan it as an explicit step, including a test with a pilot user.

Pitfall 4: multiple Connect servers and staging mode

If a staging server runs alongside the active Entra Connect server (recommended for any serious environment), both servers must carry the same sourceAnchor configuration. Update only the active server, and the day it fails, the staging server takes over with the old configuration — with everything that implies.

The same caution applies to multi-forest environments: the sourceAnchor choice applies to the whole installation, so confirm the attribute is available and writable in every forest.

Pitfall 5: the migration only pays off if the attribute travels

Switching to mS-DS-ConsistencyGuid is not a goal in itself — it's preparation for portability. In an actual cross-forest migration, the attribute genuinely has to move to the new object. Migration tools such as ADMT do not copy mS-DS-ConsistencyGuid by default; you must add it to the attribute inclusion list explicitly, or copy it afterwards with PowerShell.

Skip that, and Entra Connect will try to provision the new object as a brand-new user, leaving you with a manual hard-match exercise: setting the ImmutableID on the cloud object by hand. It works, but it's precisely the manual labour this migration was meant to eliminate.

The plan in short

1. Inventory: which sourceAnchor is in use today (check the Entra Connect configuration or Get-ADSyncGlobalSettings), and is mS-DS-ConsistencyGuid already populated anywhere?
2. Check permissions: write access for the connector account on mS-DS-ConsistencyGuid, across all synchronised OUs, in all forests.
3. Back up and export: export the current Connect configuration and record the existing ImmutableIDs for a sample of users.
4. Run the wizard on the active server: Configure → Configure Source Anchor.
5. Update AD FS (if applicable): the ImmutableID claim rules.
6. Update the staging server with the same configuration.
7. Verify: spot-check objects — is mS-DS-ConsistencyGuid populated with the objectGUID value, and is the ImmutableID in Entra ID unchanged? Test a federated sign-in if AD FS is in play.

From the field

We recently ran this migration in production environments, as groundwork for upcoming domain consolidations. The technical switch itself takes minutes; the real work is the inventory beforehand and checking the edge cases above. Do that homework and users won't notice a thing — which is exactly the point.

Is your environment (or your customer's) still on objectGUID? Don't wait until a migration or merger turns it into an emergency. This switch is one of the few pieces of technical maintenance you can do almost risk-free ahead of time — and it will save you days of work at the next AD change.