Fix ERROR_DS_INVALID_ATTRIBUTE_SYNTAX (0x0000200B) in AD

When you'll see this error

This error hits when you're doing something that writes an attribute to Active Directory — like running a script that extends the schema, using ADSI Edit to add a custom attribute, or applying a Group Policy that references an attribute that doesn't exist yet. You'll see the full message: "The attribute syntax specified to the directory service is invalid." The error code is 0x0000200B (decimal 523).

I've seen this most often when someone's trying to add a new attribute to the schema through a PowerShell script or a third-party tool, and they pick the wrong syntax OID from the list. For example, you might think you need a Unicode string (syntax 2.5.5.1) but the attribute you're modifying expects an integer (syntax 2.5.5.9).

Root cause

Active Directory uses a strict schema. Every attribute has a defined syntax — like string, integer, boolean, or distinguished name. That syntax is tied to an OID (object identifier). When you try to create or modify an attribute, the directory service checks if the syntax OID you provided matches the attribute's expected syntax. If it doesn't, you get error 0x0000200B.

The real culprit is usually a mismatch between the attribute's attributeSyntax attribute and its oMSyntax (object-moved syntax). These two values must agree. For instance, a Unicode string uses attributeSyntax = 2.5.5.1 and oMSyntax = 64. If you set the oMSyntax to 27 (which is an integer), the directory service rejects it.

Fix it step by step

Step 1: Identify the failing attribute

First, you need to know which attribute is causing the problem. If you're using a script, check the error log or output — it usually names the attribute. If you're in ADSI Edit, you'll see the attribute name in the error dialog.

For example, if you ran a PowerShell script like this:

New-ADObject -Name "CustomAttribute" -Type "attributeSchema" -Path "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -OtherAttributes @{attributeSyntax="2.5.5.1"; oMSyntax="27"}

You'd get the error because attributeSyntax 2.5.5.1 (Unicode string) doesn't match oMSyntax 27 (integer). The script would fail with 0x0000200B.

Step 2: Check the correct syntax values

Here are the most common syntax pairs. Use this table to match them:

Important: If the attribute already exists in the schema, you can't change its syntax — you'd need to deactivate and recreate it. But if you're creating a new one, fix the values before creating it.

Step 3: Correct the attribute creation

If you're using PowerShell, fix the attributeSyntax and oMSyntax to match. For a Unicode string attribute, use:

New-ADObject -Name "CustomStringAttribute" -Type "attributeSchema" -Path "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -OtherAttributes @{attributeSyntax="2.5.5.1"; oMSyntax="64"; isSingleValued=$true; searchFlags=0}

After running the command, check in ADSI Edit that the attribute appears under CN=Schema. You should see it listed with the correct syntax.

If you're using ADSI Edit manually, right-click the schema container, choose New > Object, select attributeSchema, and fill in the fields. Double-check the syntax OID in the attributeSyntax field and the oMSyntax field — they must be consistent.

Step 4: Verify syntax with a query

To confirm you set it right, run this LDAP query against the schema:

Get-ADObject -Identity "CN=CustomStringAttribute,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -Properties attributeSyntax, oMSyntax

You should see output like:

attributeSyntax : 2.5.5.1
oMSyntax       : 64

What to check if it still fails

If you've matched the syntax correctly and the error persists, check these three things:

• Is the Schema Admin group membership correct? You need to be a member of Schema Admins to modify the schema. Run whoami /groups to confirm.
• Is the schema already extended? If someone already created the attribute with a different syntax, you'll get a conflict. Check if the attribute exists in CN=Schema before trying to create it again.
• Are you using the right domain controller? Schema updates replicate slowly. If you're modifying the schema on one DC and querying another, you might see stale data. Always make changes on the Schema Master FSMO role holder. Run netdom query fsmo to find it.

One last gotcha: If you're using a script that reads the schema first, make sure it's refreshing the connection. I've seen scripts cache old schema info and keep failing because they're looking at a cached version. Close and reopen the PowerShell session or ADSI Edit connection to clear the cache.