Fix ERROR_DS_NAME_UNPARSEABLE (0x0000209E) in AD

Quick answer

Run dsquery * -filter "(&(objectCategory=person)(objectClass=user))" -attr distinguishedName to validate your DN format, then ensure the name you're passing uses proper escaping for commas, slashes, and special characters.

What's really happening here

I've seen this error pop up more times than I'd like. ERROR_DS_NAME_UNPARSEABLE means Active Directory's name parsing engine—the part that translates a name string into a directory path—choked on what you gave it. It's not a network issue. It's not a permissions issue. The string itself is garbage to AD.

This usually happens in two scenarios: you're passing a user-entered name (like CN=Smith, John) through an API or PowerShell script, or you're using a tool like Netdom or Dsmod with a malformed distinguished name. I once spent an hour debugging a script that worked fine on Windows Server 2016 but broke on Server 2022 because the newer version's name validation got stricter with trailing spaces.

Fix steps

Check your name format — The most common cause: you're mixing up the name types. AD expects one of three formats: distinguished name (DN), canonical name, or UPN. If you pass a CN without the full DN, it throws this error. For example, CN=jsmith,CN=Users,DC=contoso,DC=com works. Just CN=jsmith doesn't.
Escape special characters — Commas, forward slashes, quotation marks, plus signs, and equals signs inside a name value must be escaped with a backslash. A user named O'Brien, Sarah needs to be CN=O\'Brien\, Sarah,CN=Users,DC=contoso,DC=com. Test this by copying the actual DN from Active Directory Users and Computers (check the Attribute Editor tab).
Validate with a simple query — Open an elevated Command Prompt or PowerShell and run:
```
dsquery * -filter "(&(objectCategory=person)(objectClass=user))" -attr distinguishedName -limit 1
```
This returns a known-good DN from your domain. Compare your input against that format character by character.
Check for leading/trailing whitespace — You wouldn't think a space at the end of a DN would break things, but it does. Trim your input strings before passing them. In PowerShell: $name = $name.Trim().
Use the proper API call — If you're coding against ADSI or LDAP, use IADsNameTranslate with the ADS_NAME_INITTYPE_GC flag (init type 3). This tells AD to use the Global Catalog for name resolution, which handles ambiguous names better. Here's the C++ snippet:
```
HRESULT hr = NameTranslate->Init(ADS_NAME_INITTYPE_GC, L"CN=jsmith,CN=Users,DC=contoso,DC=com");
```

Alternative fixes if the main steps don't work

Sometimes the issue isn't the syntax—it's the tool. Try these:

Use PowerShell's [ADSI] type accelerator instead of older tools. Example:
```
[ADSI]"LDAP://CN=jsmith,CN=Users,DC=contoso,DC=com"
```
If this works but Netdom fails, the problem is in the tool's name parser.
Check for schema conflicts — If you've extended the AD schema with custom attributes, some names might contain attribute identifiers that clash. Run repadmin /showobjmeta on the object to see if any attribute names look odd.
Test with a different name format — Instead of a DN, try the user's UPN (e.g., jsmith@contoso.com) or their SAM account name (CONTOSO\jsmith). If those work, stick with them. The error specifically relates to the name you used.
Update your domain controllers — I've seen this on Server 2012 R2 domain controllers that haven't been patched since 2019. The LDAP name validation logic got fixes in later cumulative updates. Install the latest Windows Update rollup on all DCs.

Prevention tip

Stop hardcoding names. Seriously. Every time you type a DN manually in a script, you're one typo away from this error. Use variables with validated input or query AD for the DN dynamically. For example, Get-ADUser -Identity $username | Select-Object -ExpandProperty DistinguishedName returns a guaranteed-clean DN. Apply that pattern everywhere and you'll never see 0x0000209E again.

Pro tip: If you're building an app that accepts user names, wrap your name translation calls in a try/catch block and log the exact input string. Nine times out of ten, the log shows a trailing comma or an unescaped slash that you'd never spot in the UI.