ERROR_DS_SRC_NAME_MISMATCH (0x00002124) Fix

Quick Answer

Run ntdsutil on the destination domain controller to clean stale cross-ref objects, then retry the move.

What’s Actually Happening Here

This error shows up when you try to move an object (user, group, or computer) from one Active Directory domain to another using tools like ADMT or PowerShell’s Move-ADObject. The destination domain controller looks up the object’s current location via a cross-reference object—a pointer that tells it where the source domain lives. But the source domain recently went through a rename (or you’re using a legacy DNS alias for the source domain), and the cross-reference in the destination points to the old name. The destination sends a referral to the source using that old name; the source responds “that’s not my name,” and the move fails with 0x00002124.

In plain terms: the destination has an outdated address for the source, like mailing a letter to someone at their old apartment. The error code’s wording—“source and destination do not agree on the object’s current name”—is Microsoft’s way of saying the referral path is broken.

Fix Steps

1. Identify the stale cross-ref. Open an elevated command prompt on a domain controller in the destination domain. Run:
   repadmin /showrepl * /crossref
   Look for an entry whose Naming Context matches the source domain’s DNS name, but the Reference Domain is wrong or points to an old domain name.
2. Launch ntdsutil and select the stale cross-ref. Type:
   ntdsutil
metadata cleanup
select operation target
list naming context
   Note the index number of the source domain’s naming context. Then:
   select naming context [index]
   Replace [index] with that number.
3. Remove the stale cross-reference. Still in ntdsutil:
   remove selected naming context
   Confirm the removal. This deletes the pointer from the destination’s config partition—it doesn’t touch the source domain’s data.
4. Force replication and retry the move. Run:
   repadmin /syncall /AdeP
   on the destination DC. Wait 30 seconds, then retry your cross-domain move. It should now complete because the destination will discover the source domain fresh via DNS, picking up the correct name.

Alternative Fixes If Above Fails

1. Check DNS for stale records. If the cross-ref kept reappearing, the source domain’s DNS may have old _ldap._tcp.dc._msdcs.<domain> SRV records pointing to the old name. Delete them from the DNS zone on the source’s DNS server, then force replication.
2. Use ADSI Edit to manually fix the cross-ref. Connect to CN=Partitions,CN=Configuration,DC=<destination_domain>,DC=com. Find the crossRef object with nCName equal to the source domain’s DN. Update dnsRoot to match the source’s current DNS name. This is riskier—if you typo, you break replication. Stick with ntdsutil unless you’re comfortable.
3. Reboot the destination DC. Rarely, the KCC (Knowledge Consistency Checker) gets stuck. A reboot flushes its cache and forces a topology recalculation.

Prevention Tip

If you’re planning a domain rename, always update all cross-ref objects in every trusted domain before moving any objects. Run repadmin /syncall across the forest. And never manually edit a cross-ref’s DNS name via ADSI Edit unless you wrote the original value down—one wrong character and you’re rebuilding the partition table.