0X0000217B

Fix ERROR_DS_NAME_NOT_UNIQUE (0X0000217B) in Active Directory

Windows Errors Intermediate 👁 8 views 📅 May 28, 2026

This error means AD found duplicate names for objects that should be unique. Here's the fix chain: start with a simple LDAP search, then clean up duplicates.

What triggers this error

You'll hit 0X0000217B when Active Directory can't create or rename an object because the name already exists somewhere it shouldn't. Common scenarios: trying to add a computer account that matches an existing user, renaming a group to a name that another group has, or a replication conflict where two DCs created the same object. The culprit here is almost always a stale object lingering in a deleted objects container or a naming collision across OUs.

Don't bother rebuilding the domain or forcing authoritative restore — that's overkill. The fix is targeted and takes 10-20 minutes max.

Quick fix (30 seconds): Identify the duplicate

Open a command prompt as admin. Run this LDAP query against your domain controller:

dsquery * domainroot -filter "(&(objectClass=*)(name=YOUR_OBJECT_NAME))" -attr distinguishedName objectClass

Replace YOUR_OBJECT_NAME with the name that's causing the error. If it returns more than one object — there's your duplicate. Write down both DNs. If it returns nothing, you're probably dealing with a tombstoned object or a conflict from replication. Move to the moderate fix.

Moderate fix (5 minutes): Clean up with ADSI Edit

ADSI Edit is your scalpel here. Don't use ADUC — it hides too much.

  1. Open ADSI Edit from Administrative Tools (or run adsiedit.msc).
  2. Right-click ADSI Edit and choose "Connect to...". Under "Select a well known naming context", pick "Configuration". Click OK.
  3. Navigate to: CN=Configuration,DC=yourdomain,DC=comCN=ServicesCN=Windows NTCN=Directory Service.
  4. Look for objects with the duplicate name — they'll often show up as "CNF:" (conflict) or "orphaned" entries.
  5. Right-click the duplicate you don't want and delete it. Confirm the warning.
  6. Now also check the Deleted Objects container. Connect to the domain naming context: in ADSI Edit connect again, but this time choose the domain NC and check "View deleted objects". Then navigate to CN=Deleted Objects,DC=yourdomain,DC=com.
  7. Find the same-name object, right-click, delete it.

This resolves 80% of cases. Still broken? Go advanced.

Advanced fix (15+ minutes): ntdsutil tombstone cleanup

If the name is stuck in a tombstoned state or replication hasn't fully removed the duplicate, use ntdsutil.

  1. Open an admin command prompt.
  2. Run ntdsutil.
  3. Type metadata cleanup.
  4. Type connections.
  5. Type connect to server yourDC.yourdomain.com (replace with your domain).
  6. Type quit.
  7. Type select operation target.
  8. Type list domains, then select domain 0 (or whichever number matches your domain).
  9. Type list sites, select the site your DC is in, then list servers in site, then select server 0.
  10. Type quit twice to go back to ntdsutil root.
  11. Type remove selected server — only if you're certain the duplicate server is dead. Otherwise skip this step.
  12. Still in ntdsutil, type authoritative restore.
  13. Type restore object \"CN=YourObject,OU=Path,DC=domain,DC=com\". This forces the object to replicate as authoritative.

If the error still persists after this, you likely have a lingering object from a DC that was restored from backup improperly. Run repadmin /removelingeringobjects against the affected DC.

Final sanity check

After cleanup, verify with repadmin /replsummary that replication is healthy. Then try your original operation again — create or rename the object. It should work now. If not, check event viewer for 1988 events (lingering object warnings) and run the cleanup again.

I've seen this error twice in the last year — both times it was a stale computer account from a reimaged machine with the same name. The quick fix caught it both times. Start small.

Was this solution helpful?