Fix ERROR_DS_NAME_ERROR_NOT_UNIQUE (0x00002117) in Active Directory

This error is a pain — you try to translate a name in AD and it just says "not unique."

What's happening: you fed NameTranslate or a similar API a name like "jsmith" and it found two objects claiming that name. AD can't pick one, so it throws 0x00002117. The fix is usually straightforward.

The immediate fix — use a unique identifier

Don't use sAMAccountName or displayName if there's any chance of duplicates. Use the object's distinguished name (DN) or its objectGUID instead. These are guaranteed unique across the forest.

If you're writing PowerShell or C#:

# Wrong — might hit duplicates
$user = [ADSI]"LDAP://CN=John Smith,OU=Users,DC=contoso,DC=com"

# Right — use GUID
$user = [ADSI]"LDAP://<GUID=abc12345-6789-4def-...>"

If you can't change the caller, you need to clean the duplicate. Find it:

Get-ADUser -Filter {SamAccountName -eq "jsmith"} | Format-Table Name, DistinguishedName, ObjectGUID

Then remove or rename one of the duplicates. The reason step 3 works is that AD's name translation resolves names by searching the global catalog. When two objects have identical values for the attribute being searched, it returns this error instead of guessing.

Why this error happens

The underlying cause is almost always one of three scenarios:

1. Duplicate sAMAccountName or userPrincipalName — this shouldn't happen in a healthy forest, but a bad restore or replication conflict can create it.
2. Cross-forest name collisions — if you're using NameTranslate with ADS_NAME_TYPE_USER_PRINCIPAL_NAME, two forests may have the same UPN suffix and user name.
3. Stale objects from failed migrations — I've seen this after a partial ADMT migration where the source object wasn't removed.

What's actually happening here is that the DsCrackNames function (the underlying API call) searches the global catalog for the input name. If it finds more than one match, it returns ERROR_DS_NAME_ERROR_NOT_UNIQUE instead of picking one arbitrarily. Microsoft chose to fail safe rather than silently pick the wrong user.

Less common variations of the same issue

Sometimes the error appears with slightly different symptoms:

• Error 0x00002117 from LDP.exe — you try to bind with a display name and get this. Fix: use DN or GUID in the bind string.
• Error 8333 (win32 error code 0x208D) — same problem, different formatting. This is the raw Win32 error for ERROR_DS_NAME_ERROR_NOT_UNIQUE. You'll see it in event logs from AD replication or DNS registration.
• Error in Exchange or SharePoint when resolving a mailbox — these apps use name translation internally. The fix is the same: find the duplicate in AD and remove it.

Prevention — stop duplicates before they start

Three things you can do right now:

1. Enable duplicate name detection in AD. Run repadmin /syncall periodically and monitor for lingering objects. The real fix is catching this before it hits name translation.
2. Use a consistent naming convention that includes a unique numeric suffix (employee ID). This makes duplicates obvious during creation.
3. Set a uniqueness constraint on sAMAccountName using a custom LDAP policy. Not supported natively, but you can script a check in your provisioning workflow.

Skip the temporary workarounds — like modifying the caller to randomly pick one of the results. That's how you accidentally email the wrong user payroll data. Go find the duplicate and delete it.