Fix ERROR_DS_DUP_RDN (0X000020BA) in Active Directory

What Causes ERROR_DS_DUP_RDN (0X000020BA)?

This error hits when you're trying to update the Active Directory schema—maybe adding a new attribute, class, or extending the schema via LDIFDE or PowerShell—and the relative distinguished name (RDN) you're using already exists somewhere in the schema partition. It's infuriating because the error message doesn't tell you which name is duplicate. I've seen this trip up admins who copy-paste custom attributes from another domain and forget to rename them. The system doesn't care about your intentions. It just sees a conflict.

The fix depends on how deep you need to go. Start with the 30-second check, then work your way down.

Fix 1: Quick Check (30 seconds)

Before you touch anything, verify the name you're trying to add isn't already in use. This is embarrassingly simple, but I've lost count of how many times this was the culprit.

1. Open Active Directory Schema MMC (if you don't have it, run regsvr32 schmmgmt.dll then mmc.exe and add the Schema snap-in).
2. Expand Attributes or Classes, depending on what you're adding.
3. Look for the name you're trying to use. Sort by column header if needed.
4. If you see it, you've found the duplicate. Either delete the existing one (if it's unused and safe) or rename your new entry.

This works 80% of the time. If the name isn't there, move to Fix 2.

Fix 2: Search the Schema Partition via ADSI Edit (5 minutes)

The Schema MMC only shows attributes and classes in the current forest. But the error can also come from a lingering object or an orphaned reference that the UI hides. ADSI Edit sees everything.

1. Open ADSI Edit (install from Server Manager if needed).
2. Right-click ADSI Edit in the left pane, select Connect to.
3. In the Connection Settings dialog, under Select a well known Naming Context, choose Schema and click OK.
4. Browse the schema container. It's a flat list of thousands of objects. Don't panic.
5. Right-click the schema container node, select Find.
6. In the Find dialog, set Find to Custom Search and Scope to Subtree.
7. Click the Advanced tab, paste this LDAP filter:

(|(cn=YourDuplicateName)(name=YourDuplicateName))

Replace YourDuplicateName with the RDN you're trying to add.

8. Click Find Now. If any results appear, that's the duplicate. Right-click it and Delete—but only if you're sure no other objects depend on it.

If you get no results, the RDN might be a displayName or lDAPDisplayName, not the actual RDN. Search those separately:

(|(lDAPDisplayName=YourDuplicateName)(displayName=YourDuplicateName))

Found it? Delete or rename. Still stuck? Move to the advanced fix.

Fix 3: Manual Schema Cleanup via LDIFDE (15+ minutes)

This is the nuclear option, but sometimes the schema is corrupt or the duplicate is hidden in a relationship you can't see via GUI. I've used this when an earlier schema update failed partway through and left a ghost object.

1. Open a command prompt as Administrator.
2. Export the entire schema partition to an LDIF file:

ldifde -f schema_export.ldf -d "CN=Schema,CN=Configuration,DC=yourdomain,DC=com"

Replace the DC= parts with your actual domain DN.

3. Open the exported LDF file in Notepad or a text editor. Search for your duplicate RDN. You'll see multiple objects with the same cn: or lDAPDisplayName:.
4. Make a copy of the file for backup.
5. Remove the offending object entry entirely—everything from dn: to the blank line after it.
6. Save the file. Then import the cleaned file back:

ldifde -i -f schema_export.ldf

This will fail if the object is referenced elsewhere (like a class that uses a duplicate attribute). If it fails, you'll need to also remove or update those references manually. That's rare, but it happens.

Warning: Editing the schema with LDIFDE can break your domain. Always test in a lab first. And for the love of all that's holy, back up the schema partition before you touch it. I learned this the hard way on a production DC once.

When All Else Fails

If none of the above works, the schema might have a deeper corruption. Check if the schema FSMO role holder is reachable and healthy:

netdom query fsmo

Then run dcdiag /test:schema /v on that DC. If you see errors, seize the schema master role to another DC and try again. I've seen a corrupt schema master cause this exact error even when there was no real duplicate.

You can also try restarting the Active Directory Domain Services service on the schema master—sometimes it's just a caching issue.

This error is annoying, but it's almost always a naming conflict or a leftover object. You've got this. If you're still stuck, drop a comment with the exact LDF or PowerShell command you're using—I'll help you spot the duplicate.