Fix ERROR_DS_BAD_NAME_SYNTAX 0x208F in Active Directory

You're running dsadd user, importing a CSV with csvde, or pushing users into AD with PowerShell, and the whole thing blows up with ERROR_DS_BAD_NAME_SYNTAX (0X0000208F). The message says the object name has bad syntax, which is the least helpful sentence Microsoft ever shipped. Nine times out of ten it means one of three things: a comma in a name field, a leading or trailing space, or a Unicode character that snuck in from a copy-paste out of Outlook or Excel.

I've seen this fire on a bulk import of 400 contractors where exactly one row had a trailing space in the cn column. The whole import died on that row. Took twenty minutes to find with the right filter. Let's get you there faster.

What actually causes 0x208F

Active Directory enforces name rules at the schema level. When you create or rename an object, the DC validates the name against a set of reserved characters and formatting rules. If the name fails, the directory returns ERROR_DS_BAD_NAME_SYNTAX. Common triggers:

Reserved characters in the CN or OU name. AD blocks " / \ [ ] : ; | < > + = , at the start or end of a relative distinguished name (RDN).
Leading or trailing spaces. AD trims them internally, but the LDAP client that sent the request still sees a mismatch, and validation fails hard.
Unescaped commas or plus signs in a DN. If your distinguished name is CN=Smith, John,OU=Sales,DC=contoso,DC=com, the parser reads John as a new RDN. You need to escape it as CN=Smith\, John.
Non-ASCII characters. Smart quotes from Word, non-breaking spaces (U+00A0) from web pages, and zero-width joiners from Teams chat all trip this.
Bad OU path in your script. A typo like OU=Users,,DC=contoso,DC=com gives the LDAP parser a double comma and it bails.

That's the root cause in plain English: AD's LDAP layer is strict, and your string has something in it that LDAP doesn't allow in that position. The error code is the DC saying "I can't even parse this, let alone store it."

Fix it — numbered steps

Find the offending row or object. If you're importing from CSV, filter for non-printable characters first. In PowerShell:
```
Import-Csv .\users.csv | Where-Object {
  $_.Name -match '[^\x20-\x7E]' -or
  $_.Name -match '^\s|\s$' -or
  $_.Name -match '[\\/:;\[\]"|<>+=]'
} | Format-List
```
Anything that drops out of that filter is a suspect. Fix it in the source file, not in your script.
Trim and normalize the name. Before you call New-ADUser, clean the string:
```
$clean = ($raw.Trim() -replace '\s+', ' ')
New-ADUser -Name $clean -SamAccountName $raw.Replace(' ','').ToLower()
```
That strips leading and trailing whitespace and collapses interior double spaces, which is a sneaky cause of 0x208F on display names.
Escape reserved characters in DNs. If you're building a distinguished name from scratch, escape the special ones. Backslash before the character:
```
$dn = "CN=$($name -replace '([,=+<>#;"\\])','\\$1'),OU=Sales,DC=contoso,DC=com"
```
Or skip DN construction entirely and use -Identity with the SamAccountName and -Path with the OU. Way less error-prone.
Check the OU path for typos. This one bites people who copy paths out of ADUC. In the GUI, a comma is a delimiter. In your script, it has to be a literal comma between RDNs with no double commas, no trailing comma, and no space after the comma (unless the space is part of the RDN). Test the path first:
```
Get-ADOrganizationalUnit -Identity "OU=Sales,DC=contoso,DC=com"
```
If that throws, your path is the problem, not the name.

Rerun the operation. For a single object, delete the partially-created entry (AD sometimes leaves a stub) and try again:

Remove-ADObject -Identity "CN=Bad Object,OU=Sales,DC=contoso,DC=com" -Recursive -Confirm:$false
New-ADUser -Name "John Smith" -SamAccountName jsmith -Path "OU=Sales,DC=contoso,DC=com"

If it still fails

Work backwards through these checks:

Is the DC actually reachable and healthy? Run dcdiag /test:advertising on the target DC. A replication-stalled DC can return odd errors, including name syntax, when the schema cache is stale.
Are you on the right DC? If you have multiple sites, target a specific DC with New-ADUser -Server dc02.contoso.com. I've chased this error for an hour only to find the offending DC had a corrupted schema index.
Check the name against AD's actual rules. Microsoft's list of forbidden characters lives in the schema docs. The short list: \ / " [ ] : ; | = , + * ? < > and any control character.
Look at the raw bytes. If a name looks fine visually but still fails, dump the hex. A non-breaking space (0xA0) looks exactly like a regular space in every editor I've used:

[System.Text.Encoding]::UTF8.GetBytes($name) -join ' '

You'll see 194 160 where a normal space would be 32. That's your culprit. Replace it and the import sails through.

Sources of bad characters are almost always Excel, Outlook smart quotes, or copy-paste from a browser. If your data comes in through a form, sanitize it at intake. Don't wait for AD to reject it.

One more thing worth knowing: the same error code shows up when you rename an OU and include a character AD reserves at the RDN level. The fix is identical — strip or escape, then retry. If you scripted it, Rename-ADObject with a quoted string and a -Server flag makes the intent obvious and the failure mode readable.