Fix ERROR_DS_ROOT_CANT_BE_SUBREF (0X00002086)

Quick answer for advanced users

The root DN you're passing to Add-ADObject or dsadd is already a naming context in your forest. You can't make a crossRef that points to the same partition. Fix the nCName attribute to a proper child DN, or clean up duplicate crossRef entries.

Context: what's actually happening here

This error pops up when you're working with Active Directory's Partitions container (CN=Partitions,CN=Configuration,DC=...) and trying to add a crossRef object. The weird hex code 0X00002086 maps to "The specified root object cannot be a subreference." What that means in plain English: you told AD that some distinguished name (DN) is a naming context (a root object), but that DN is already a sub-part of another naming context in the forest.

For example, if your forest has a domain DC=contoso,DC=com and you try to create a crossRef for DC=contoso,DC=com itself, that's fine — it's the root. But if you try to create a crossRef for something like DC=sub,DC=contoso,DC=com without that sub domain existing as a real domain, AD sees it as a subreference of the parent partition. That's a no-go. The root object (the naming context) must be exactly that — a root, not a child of another partition.

The most common real-world trigger: someone runs a script that auto-creates crossRef entries for every folder in a file server, accidentally using the wrong DN syntax. Or a badly written synchronization tool tries to replicate application partitions and duplicates the domain DN.

Fix steps (the order matters)

Step 1: Verify the exact DN that causes the error

Run this on a domain controller as Domain Admin:

dsquery * CN=Partitions,CN=Configuration,DC=contoso,DC=com -filter "(cn=YourPartition)" -attr cn nCName

If you see a result where the nCName value is the same as an existing domain DN but with extra RDN (relative distinguished name) parts, that's the problem. Example: DC=contoso,DC=com exists, but your entry has DC=stuff,DC=contoso,DC=com.

Step 2: Delete the conflicting crossRef

dsrm "CN=BadPartition,CN=Partitions,CN=Configuration,DC=contoso,DC=com" -noprompt

Replace the CN with the actual name from step 1. The -noprompt flag skips confirmation. Don't delete valid domain partitions — only the ones you added manually or that the bad script created.

Step 3: Re-create the crossRef with a valid root DN

If you actually need a new application partition (like for DNS or custom directory data), use a DN that doesn't start with an existing domain's DC= root. For example:

dsadd cn AppPartition1,CN=Partitions,CN=Configuration,DC=contoso,DC=com -attr nCName "DC=AppPartition1,DC=contoso,DC=com" msDS-NC-Replica-Locations "CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=contoso,DC=com"

Notice the nCName is DC=AppPartition1,DC=contoso,DC=com — it's a unique root under the forest, not a sub-DN of an existing domain.

Step 4 (only if using PowerShell)

If you used New-ADObject, the same DN rules apply. The -path parameter must point to the Partitions container. The -name is the CN. Set the nCName attribute correctly in the -OtherAttributes hashtable. Example:

New-ADObject -Name "MyPartition" -Type crossRef -Path "CN=Partitions,CN=Configuration,DC=contoso,DC=com" -OtherAttributes @{nCName="DC=MyPartition,DC=contoso,DC=com"; msDS-NC-Replica-Locations='...'}

Alternative fixes if the main one fails

Repair a corrupt crossRef with ADSI Edit

1. Open ADSI Edit. Connect to the Configuration partition (CN=Configuration,DC=...).
2. Navigate to CN=Partitions. Find the bad crossRef object.
3. Right-click → Properties. Edit the nCName attribute. Change it to a valid root DN that isn't a child of any existing partition.
4. Click OK and close. Error 0X00002086 should stop appearing.

The reason this works: you're directly editing the LDAP attribute instead of using cmdlets that might enforce extra schema validation.

Clear the cache on your domain controller

Sometimes the error sticks around because AD caches the bad entry. Reboot the DC. Or run:

repadmin /syncall /AdeP

This forces replication and flushes stale objects.

Prevention tip

Never create crossRef entries for DNs that are sub-paths of existing domain or application partitions. Always use a unique top-level DC= component. If you're automating this, add a check in your script that compares the nCName against all existing partition roots. Here's a PowerShell one-liner for that:

$existing = Get-ADObject -Filter 'objectClass -eq "crossRef"' -SearchBase 'CN=Partitions,CN=Configuration,DC=contoso,DC=com' -Properties nCName | Select -ExpandProperty nCName

Then check $existing -contains "DC=YourNewRoot,DC=contoso,DC=com" before creating. If it returns true, you're about to duplicate a root. Don't do that. Skip the creation or rename your partition.