You're most likely to see ERROR_DS_CROSS_REF_BUSY (0X0000219A) when you try to add or modify a naming context (NC) in Active Directory, and the domain controller tells you that a cross-reference with the same name is already in use locally. This often happens during a failed domain rename, after a botched removal of an application partition, or when a lingering crossRef object points to a partition that no longer exists. I've seen it pop up in environments where someone tried to create a new application partition with a name that matches an old, half-deleted one.
The root cause is simple: Active Directory stores pointers to naming contexts in objects called crossRef. When you create an application partition or a domain, AD creates a crossRef for it. If that object gets stuck or duplicated, the local DC sees it as "busy" and refuses to create another one with the same distinguished name. It's not a permissions issue or a network problem—it's a stale object sitting in the configuration partition.
What to check before you start
Make sure you have administrative credentials on the domain controller where you're running these commands. You'll also want to do this during a maintenance window, because you'll be making changes to the configuration partition that replicate to all DCs. If you have multiple DCs, you need to clean this up on the DC that's throwing the error, but the fix will replicate.
Step 1: Find the cross-reference that's causing the conflict
Open an elevated Command Prompt (run as Administrator) and run:
repadmin /showattr . "CN=Partitions,CN=Configuration,DC=yourdomain,DC=com" /subtree /filter:"(objectClass=crossRef)" /attrs:cn,distinguishedNameReplace yourdomain,DC=com with your actual domain DN. You'll see a list of all crossRef objects. Look for one that matches the name you're trying to create. It might have a weird GUID in its DN or a name that looks like the partition you're adding. Write down the full distinguished name of that crossRef object.
After running this, you should see a table with entries. If you don't see any crossRef with that name, then the issue is something else—check step 4.
Step 2: Delete the stale cross-reference
Now you're going to remove that crossRef object. Use ntdsutil for this—don't try to delete it with ADSI Edit unless you're absolutely sure, because ntdsutil handles the cleanup better.
ntdsutil
partition management
connections
connect to server localhost
quit
list
This shows you all the naming contexts on the server. Find the one that matches the crossRef you found in step 1. If it's there, select it and delete it:
select CN=YourNamingContext,CN=Partitions,CN=Configuration,DC=yourdomain,DC=com
deleteType quit twice to exit ntdsutil. After you delete it, you should see a confirmation message. Wait a few minutes for replication to settle.
Step 3: Recreate the cross-reference (if needed)
If you actually need that naming context—like an application partition—you can now create it again. Use ntdsutil again or dnscmd if it's a DNS partition. The exact command depends on what you're creating, but for an application partition, you'd use:
ntdsutil
partition management
create NC CN=YourPartition,DC=yourdomain,DC=com localhost
quit
quitAfter running that, you should see a success message. Then verify it shows up in the list.
Step 4: If it's still failing—force KCC and check replication
Sometimes the crossRef isn't the actual problem. The error can also appear if the Knowledge Consistency Checker (KCC) hasn't caught up. Run this to force it:
repadmin /kccThen check replication status:
repadmin /showreplLook for any lines that say "last attempt failed" or "last success" that is older than a few hours. If you see failures, you might have a deeper replication issue. Common causes: DNS misconfiguration, a DC that's been offline for a long time, or a lingering tombstone. Check event logs for NTDS Replication events (Event ID 1988, 2042) to see if a lingering object is the culprit.
Still stuck? Check for lingering objects
If repadmin /showrepl shows errors, run a lingering object check on all DCs:
repadmin /removelingeringobjects <DCName> <NamingContext> /advisory_modeRun it first in advisory mode to see what it finds. If it lists objects, run it again without /advisory_mode to remove them. Then retry your original operation.
In my experience, 90% of the time the fix is just deleting that stale crossRef object. The other 10% is DNS. So if you've followed steps 1–3 and it's still failing, check that all DCs can resolve each other's names correctly. Run nltest /dsgetdc:yourdomain on each DC to confirm they're talking to each other.
One last thing: if you're in a multi-domain forest, make sure you're not trying to create a partition that overlaps with an existing naming context. That's a common mistake that produces this exact error.