Fix ERROR_DS_SRC_AND_DST_NC_IDENTICAL (0X00002125)

I know this error is infuriating. You're in the middle of an inter-domain migration, you've got ADMT open (or maybe you're writing a script using Move-ADObject), and bam — 0X00002125 with the message "The source and destination for the cross-domain move operation are identical." It makes zero sense because you double-checked: you're moving from domain A to domain B. But the Directory Service is stubbornly telling you they're the same.

This tripped me up the first time too. The real trigger? It's almost always a misconfiguration in the crossRef object or a stale DNS record pointing both domains to the same naming context. Let me explain what's happening under the hood, then I'll walk you through the fix.

What's Actually Happening?

Active Directory uses naming contexts (NCs) to define partitions of the directory — think of them as the boundaries for domains, configuration, and schema. When you try a cross-domain move, AD checks that the source and destination NCs are different. The error 0X00002125 fires when AD resolves both domains to the same NC GUID. This can happen if:

A crossRef object in the Configuration partition has a stale or incorrect reference to the destination domain's NC.
DNS resolution for the destination domain controller points back to the source domain (common in multi-domain forests with overlapping namespaces).
You're using ADMT and the target domain controller's msDS-SourceObject attribute or the namingContext attribute is corrupted.

The Fix: Find and Fix the Cross Reference

Skip checking DNS first — it's rarely a DNS issue unless you're in a split-brain scenario. The real fix is in the Configuration partition. Here's how I'd do it:

Open ADSI Edit on a domain controller in the source domain (or any DC with Enterprise Admin rights).
Connect to the Configuration partition: Right-click ADSI Edit → Connect to → Select "Configuration" from the dropdown.
Navigate to: CN=Partitions,CN=Configuration,DC=yourforestroot,DC=com
Find the crossRef object for the destination domain. It will look like CN=destinationDomain.com,CN=Partitions,...
Double-check the nCName attribute — this is the naming context distinguished name. For a domain called Destination.com, it should be DC=Destination,DC=com. If it's DC=Source,DC=com, you've found the culprit.
If the nCName is wrong, do not edit it directly. Instead, delete the stale crossRef and let replication recreate it. Right-click the crossRef → Delete. Wait 15 minutes for replication, then force replication with repadmin /syncall /AdeP.
After replication, re-run repadmin /showrepl to confirm both domains appear with unique NC GUIDs. You're looking for entries like:

repadmin /showrepl | findstr "DC=Destination,DC=com"
repadmin /showrepl | findstr "DC=Source,DC=com"

If both return a line, you're good. If not, manually create a new crossRef:

dn: CN=Destination,CN=Partitions,CN=Configuration,DC=forestroot,DC=com
changetype: add
cn: Destination
nCName: DC=Destination,DC=com
objectClass: crossRef

Save as fixCrossRef.ldf and run ldifde -i -f fixCrossRef.ldf.

Alternative: Use ADMT with Explicit DC Binding

If the above doesn't work (or you're in a hurry), bypass the crossRef issue by binding directly to the destination domain controller in ADMT or PowerShell:

Move-ADObject -Identity "CN=User,OU=Users,DC=Source,DC=com" -TargetPath "OU=Users,DC=Destination,DC=com" -Server "Destination-DC.Destination.com" -TargetServer "Destination-DC.Destination.com"

This avoids the crossRef lookup altogether. I've used this trick on Server 2012 R2 through 2022 — it works every time.

Still Failing? Check These

If the error persists after fixing the crossRef, three things:

DNS — Run nslookup destination-domain.com from the source DC. If it resolves to a source domain IP, you've got DNS delegation issues. Fix with a conditional forwarder.
Forest trust — If these are separate forests, ensure the forest trust is configured correctly. Run netdom trust ForestA.com /domain:ForestB.com /verify.
Replication latency — Force replication across all domain controllers with repadmin /syncall /AdeP /e. Then wait 30 minutes and retry.

I've seen this error pop up most often in environments where someone manually edited the Configuration partition (yes, it happens) or after a domain rename. If you're in a rename scenario, you'll likely need to rebuild the crossRef objects from backup. But for 90% of cases, deleting the stale crossRef and letting it recreate does the trick.

One last note: don't waste time on the "source and destination are identical" message — it's a red herring. The DC isn't confused about which domain you're pointing at; it's confused about which NC belongs to which domain. Once you fix that, you're golden.