Fix ERROR_DS_NOT_AUTHORITIVE_FOR_DST_NC (0X00002127)

When This Error Shows Up

You're running the Active Directory Migration Tool (ADMT) to move user or computer objects between domains—either within the same forest or across forests. The migration wizard completes the initial checks, then bombs out with a dialog box showing ERROR_DS_NOT_AUTHORITIVE_FOR_DST_NC (0X00002127). The exact text: “The destination of a cross-domain move is not authoritative for the destination naming context.”

This typically happens right after ADMT tries to submit the move operation to the destination domain controller. You might be on Windows Server 2016 or 2019, moving objects from a legacy domain to a new one. The error is immediate—no partial success, no lingering objects.

What's Actually Happening Here

Active Directory partitions the directory into naming contexts (NCs): the domain NC (your domain), the configuration NC, the schema NC, and maybe application partitions. When ADMT performs a cross-domain move, it sends the operation to a destination domain controller. That DC must be authoritative for the destination domain's naming context. In plain English: the DC you're targeting must host a writable copy of that domain's partition.

The error means the destination DC you connected to either:

Doesn't hold the domain NC for the target domain (maybe it's a global catalog server from another domain)
Holds a read-only copy (like a RODC)
Hasn't fully replicated the target domain NC yet (replication latency)

ADMT doesn't guess—it checks the DC's capabilities via LDAP and rejects it if the NC isn't present. The move fails before any changes hit the directory.

The Fix

Skip the fluff—you need to force ADMT to talk to a domain controller that's authoritative for the target domain. That means a writable DC in the destination domain itself. Here's the step-by-step.

Step 1: Identify a Writable DC in the Destination Domain

Open PowerShell on your migration server (or any machine with RSAT tools). Run:

Get-ADDomainController -Discover -DomainName "destination.domain.com" -ForceDiscover

This returns a DC that's a writable domain controller for the destination domain. The output shows the Hostname and Site. Pick one that's not a RODC—check IsReadOnly property: it must be False.

Step 2: Force ADMT to Use That DC

ADMT allows you to specify the destination domain controller via a command-line parameter or by editing the registry. The cleanest way is to use the /DESTDOMAINCONTROLLER switch when launching the wizard:

admt.exe migrate /DESTDOMAINCONTROLLER:dc01.destination.domain.com

If you're using the GUI, you can't specify this directly. Instead, set a registry value before running the wizard:

reg add HKLM\SOFTWARE\Microsoft\ADMT /v DestinationDC /t REG_SZ /d "dc01.destination.domain.com" /f

Now launch ADMT from the Start menu. The tool will pick up that registry entry and target the specified DC.

Step 3: Verify Replication Is Current

Even if you target the right DC, stale replication can cause this error. The DC must have a complete copy of the destination domain NC. Run this on the destination DC:

repadmin /syncall /AdeP destination.domain.com

Wait for it to complete without errors. Then check the NC status:

repadmin /showrepl destination.domain.com

Look for the domain NC (e.g., DC=destination,DC=domain,DC=com). It should show the last success timestamp as recent (within minutes, not hours).

Step 4: Retry the Move

With the correct DC targeted and replication confirmed, run ADMT again. The 0X00002127 error should be gone. If it persists, you've got a deeper issue—likely a firewall blocking LDAP calls to the destination DC on port 389 (or 636 for LDAPS). Check connectivity:

Test-NetConnection dc01.destination.domain.com -Port 389

What to Check If It Still Fails

FSMO role holder: The destination domain's PDC Emulator must be reachable. ADMT sometimes escalates operations to that FSMO role. If the PDC is offline, the move fails.
Cross-forest trust: If moving between forests, verify the trust is fully established and bidirectional. Run nltest /trusted_domains on both sides.
ADMT version mismatch: The source and destination servers must run the same ADMT version (3.2 is the last one from Microsoft). Mixing versions causes weird errors.
DNS resolution: The source DC must resolve the destination DC's hostname correctly. Use nslookup dc01.destination.domain.com from the source server.

This error is a hard stop from ADMT—it's designed to prevent corrupt moves. Once you point it at a writable, up-to-date destination DC, it'll pass through without issue.