AD Cross-Reference 0X000020B6: Fix Conflict

Cause 1: Stale cross-reference left over from a failed domain rename or trust setup

This is the most common trigger. You or someone in your org tried to rename a domain, set up a cross-forest trust, or add a crossRef partition, and the process halfway failed. The directory service created the cross-reference object but never finished the job. Now every time you retry, you get 0X000020B6.

The fix is to manually remove that leftover cross-reference. You'll need ADSI Edit, which is part of the Remote Server Administration Tools (RSAT) or available directly on a domain controller.

1. Open ADSI Edit. On a domain controller, go to Start > Run, type adsiedit.msc, and press Enter. If you don't have it, install the Active Directory module from Server Manager.
2. Connect to the Configuration container. In the left pane, right-click ADSI Edit, choose Connect to. In the dialog, select Configuration from the dropdown under Select a well-known Naming Context. Click OK.
3. Navigate to the Cross-References container. Expand the tree: Configuration [server.domain.com] > CN=Configuration,DC=domain,DC=com > CN=Partitions. You should see a list of CN=... objects—these are cross-references.
4. Find the duplicate or stale entry. Look for the cross-reference that matches the domain or partition you're trying to add. It's usually named CN=<domainFQDN>, like CN=child.domain.com. The cn attribute holds the DNS name. If you see two entries with the same name, one is stale.
5. Delete the stale cross-reference. Right-click the object, choose Delete. Confirm the deletion. After clicking Delete, you should see a confirmation dialog asking if you're sure. Click Yes.
6. Close ADSI Edit and retry your operation. Go back to your domain rename, trust creation, or partition addition. It should now proceed without the 0X000020B6 error.

One real-world scenario: I had a client trying to add a child domain after a failed rendom /execute. The crossRef was sitting there for three months. Removing it via ADSI Edit took thirty seconds.

Cause 2: An orphaned cross-reference from a decommissioned domain controller

When you demote a domain controller, especially if you force-deleted it or it died hard, sometimes the cross-reference objects in the Partitions container don't get cleaned up. You end up with a reference to a domain that no longer exists.

The fix is the same as above—use ADSI Edit—but you need to confirm which crossRef is truly dead.

1. Open ADSI Edit and connect to the Configuration container, same as before.
2. Navigate to CN=Partitions under the Configuration naming context.
3. Examine each crossRef. Look at the dnsRoot attribute. Double-click each candidate object. In the Attribute Editor, find dnsRoot. If the domain controller for that domain is gone, or the domain itself is gone, this crossRef is orphaned.
4. Check the msDS-NC-Replica-Locations attribute. This lists the servers that host this partition. If the list is empty or points to a server that no longer exists, you've found your culprit. After viewing the attribute, you should see a multivalued path like CN=NTDS Settings,CN=DC01,CN=Servers,CN=SiteName,CN=Sites,CN=Configuration...—if that server is gone, delete the crossRef.
5. Delete the orphaned crossRef. Right-click and delete it.
6. Force replication to all domain controllers: run repadmin /syncall /AdeP in an elevated command prompt. This ensures the deletion is propagated.

Don't skip the replication step. I've seen admins delete the object locally but the error persisted on other DCs because the change hadn't replicated.

Cause 3: Competing cross-references from a misconfigured application partition

Some apps (like Exchange, Skype for Business, or DNS management tools) create their own application partitions. If you manually added a crossRef for the same partition name, or the app created one and then you tried to add another with the same DNS name, you'll hit 0X000020B6.

The fix here is to identify which crossRef is the legitimate one and remove the extra.

1. Open ADSI Edit and connect to the Configuration container.
2. Go to CN=Partitions again.
3. Sort by cn or dnsRoot. You're looking for two (or more) objects with the same dnsRoot value. One might be an application partition like DC=DomainDnsZones,DC=domain,DC=com and the other is a domain crossRef.
4. Check the systemFlags attribute. For a domain crossRef, systemFlags typically has a value of 1 (meaning it's a domain partition) or 3 (domain partition with GC). For application partitions, it's 0 or 2. If you see a duplicate dnsRoot where one is an app partition and the other is a domain crossRef, the domain one is usually the one you want to keep. Delete the app partition crossRef if it's the duplicate.
5. Delete the extra crossRef. Right-click and delete the object you don't need.

Be careful: deleting the wrong crossRef can break DNS resolution or application functionality. If you're unsure, back up the partition object first—use ldifde -f backup.ldf -d "CN=Partitions,CN=Configuration,DC=domain,DC=com" to export everything.

Quick-reference summary table

Bottom line: 0X000020B6 is almost always a cleanup problem. The directory is protecting itself from duplicate entries. Your job is to find the ghost crossRef and remove it. ADSI Edit is your best friend here. Once you've cleared it, the operation will go through like nothing happened.