ADMT fails: ERROR_DS_NO_CROSSREF_FOR_NC (0x000020AB)

You're migrating users from a Windows Server 2012 R2 domain to a 2019 domain with ADMT 3.2. Halfway through the migration, ADMT throws 0x000020AB — "The cross-reference for the specified naming context could not be found." Or maybe you're trying to join a new Windows 10 workstation to a child domain and get the same error. The trigger is almost always a stale Application Partition (also called a naming context) that points to a domain controller that's been decommissioned or is unreachable.

The root cause is simple: Active Directory keeps a list of all naming contexts (domains, configuration, schema, and Application Partitions) in the Partitions container under CN=Configuration. When a DC or domain is removed but the cross-reference object isn't cleaned up, the domain controller trying to process the migration or domain join can't resolve the newer naming context. ADMT or the NetLogon service then fails because it can't find a valid crossRef object.

What you'll need

• Domain Admin credentials in both source and target domains
• ADSI Edit (install via RSAT if not already there)
• Access to a domain controller in the target domain

Step-by-step fix

Step 1: Identify the problematic cross-reference

1. Open ADSI Edit on any DC in the target domain.
2. Right-click ADSI Edit → Connect to.... In the Connection Settings dialog, set Select a well known Naming Context to Configuration. Click OK.
3. Navigate to CN=Configuration,DC=yourdomain,DC=com → CN=Partitions.
4. Scroll through the list of CN=... objects. Look for any cross-reference (crossRef) that has a nCName attribute pointing to a domain or Application Partition that no longer exists. Common culprits: old child domains, deleted domains, or DNS zones that were migrated elsewhere.
5. Check the msDS-NC-Replica-Locations attribute — if it lists a DC that's been offline for months, that's your target.

Step 2: Delete the stale cross-reference

1. Right-click the stale crossRef object and select Delete. Confirm the dialog.
2. Wait 15 minutes for replication to propagate. Or force replication with repadmin /syncall /AdeP.

Step 3: Verify the fix

1. Run nltest /dsregdns from a client that was previously failing.
2. Try the ADMT migration or domain join again. If the error's gone, you're done.

Still failing? Check these

• SID filtering: On the target domain, run netdom trust /quarantine:No and verify the trust is bidirectional.
• DNS forwarders: Make sure the target DC can resolve the source domain's DNS. A missing forwarder can look like a cross-reference issue.
• ADMT service account: The account must be in the Domain Admins group of both domains and have Create Computer Objects rights in the target domain.

One last thing — don't bother rebuilding the cross-reference manually. If the name context truly doesn't exist anymore, recreating it will just cause replication conflicts. Delete and move on.

I've seen this exact error on Server 2016 and 2019 when people decomission a child domain without cleaning up the Partitions container. The fix above has never failed me. If it still breaks after these steps, check the Application event log for NTDS error 1450 or 1655 — those point to a deeper replication issue.