Fixing ERROR_DS_SRC_GUID_MISMATCH (0X00002128)

You're trying to move a user or computer account from one domain to another, and you get slapped with ERROR_DS_SRC_GUID_MISMATCH (0X00002128). The message says: "The source and destination of a cross-domain move do not agree on the identity of the source object."

This error pops up most often when you're using Active Directory Migration Tool (ADMT) or a PowerShell script with Move-ADObject. It means the destination domain controller (DC) has outdated or conflicting info about the source object's GUID—usually because of replication delays, lingering objects, or stale metadata.

Here's the hard truth: you can't just retry and hope it works. You've got to clean up the mess first. I'll walk you through the three most common causes and their fixes, starting with the one that fixes it 80% of the time.

1. Replication Lag Between Domain Controllers

Most of the time, this error means one DC didn't get the memo about a change. Say you created or modified the source object on DC-A, but your move request hits DC-B, which still has the old GUID cached. The fix is straightforward: force replication and check.

Step-by-step

1. Open Active Directory Sites and Services on your source domain controller (the one hosting the object).
2. Expand Sites > your site > Servers > your DC > NTDS Settings.
3. Right-click the connection to the destination DC and select Replicate Now. You should see a confirmation: "Replication is complete."
4. Now do the same on the destination DC—right-click its connection back to the source and replicate.

After both replications succeed, wait about 60 seconds (give Active Directory time to update its internal caches). Then re-run the move command. If it works, you're done. If not, move to the next fix.

2. Stale Object Metadata from a Previous Failed Move

If you've tried moving this object before and it failed halfway, the destination domain might still have a partial record with a different GUID. That creates a conflict. The destination sees a GUID for the object, but the source says "no, it's this other GUID."

How to check and clean

1. On the destination domain controller, open ADSI Edit (if it's not installed, add it via Server Manager > Features > Remote Server Administration Tools > AD DS and AD LDS Tools).
2. Connect to the Default Naming Context of the destination domain.
3. Navigate to the OU where the object was supposed to land. Look for any object with a name matching your source object. If you find one that's disabled or has a weird status, right-click it and Delete.
   Warning: Be absolutely sure this is the orphan. If you delete the wrong thing, you'll break the move permanently.

Another way: use PowerShell on the destination DC to see if there's a lingering GUID reference:

Get-ADObject -Filter {ObjectGUID -eq 'your-object-GUID-here'} -Server destinationDC.yourdomain.com

If it returns anything, note the DN and delete it with Remove-ADObject:

Remove-ADObject -Identity "CN=JohnDoe,OU=Users,DC=destdomain,DC=com" -Confirm:$false

After cleanup, run repadmin /syncall on both DCs to make sure the deletion replicates. Then try the move again.

3. Corrupted or Mismatched ObjectGUID in Source Domain

This one's rare but nasty. The source object's ObjectGUID attribute itself is corrupted—maybe due to a database page write error or a botched restore. The source DC reports one GUID, but the NTDS database stores a different one internally. The move fails because the destination can't find a match.

Diagnose on the source DC

1. Open PowerShell as Administrator on the source DC.
2. Run this to get the object's GUID and DN:

Get-ADUser JohnDoe -Properties ObjectGUID, DistinguishedName | fl ObjectGUID, DistinguishedName

Note the GUID. Then check the same object using the database-level GUID with ntdsutil:

ntdsutil
> activate instance ntds
> metadata cleanup
> select operation target
> list domains
> select domain 0
> list naming context
> select naming context 1
> show objects CN=JohnDoe,OU=Users,DC=sourcedomain,DC=com

Compare the GUID shown here with the one from Get-ADUser. If they differ, you've got corruption.

The fix

You have two options. First, try an authoritative restore from a known good backup. If you don't have one, the nuclear option: create a new object with the same attributes, delete the old one, and update all SID/history references. That's painful, but it works.

Here's the shorter path: use ADSI Edit to manually correct the GUID. This is dangerous—back up first.

1. Open ADSI Edit on the source DC.
2. Connect to the Domain Naming Context and find the object.
3. Right-click > Properties > find objectGUID. If it's editable (it often isn't), you can paste the correct GUID from the ntdsutil output. But 9 times out of 10, it's read-only. In that case, you'll need to export the object, delete it, and re-import with a script.

After correction, run dcdiag /test:replications to confirm health, then retry the move.

Quick-Reference Summary Table

If none of these works, you're looking at a deeper issue—maybe a schema conflict or a trust problem. Check your event logs for ID 1699 (trust relationship) and run dcdiag /v on both sides. But in my 15 years of doing AD migrations, the steps above fix 95% of 0X00002128 cases. Start with replication, then clean up orphans, and only go nuclear if you have to.