Fix ERROR_DS_SYNTAX_MISMATCH 0X000020C0 in AD Schema

This error pops up when you try to update an AD schema attribute with the wrong syntax type. The fix is to match the syntax of the existing attribute.

Quick answer for pros

Check the attributeSyntax and oMSyntax values of the attribute in the schema. The update must use the exact same syntax the attribute was created with. If it's a new attribute, use the syntax you defined when adding it.

What's this error about?

You're looking at ERROR_DS_SYNTAX_MISMATCH (hex 0x000020C0). This happens when you try to change an Active Directory schema attribute's syntax — like its data type — and Windows tells you the new syntax doesn't match the old one. The culprit here is almost always a mismatch between the attributeSyntax and oMSyntax values. I've seen this mostly when someone tries to modify an existing attribute using ADSI Edit or a custom script, but they use the wrong syntax OID.

For example, trying to change a string attribute (syntax 2.5.5.12) to an integer (syntax 2.5.5.9) will throw this error. The schema is strict — you can't change the data type of an attribute that already has values in the directory.

Step-by-step fix

Identify the problematic attribute
Open ADSI Edit and connect to the Schema partition. Expand CN=Schema,CN=Configuration,DC=yourdomain,DC=com. Find the attribute that failed. Look at its attributeID value.
Check current syntax values
Right-click the attribute, go to Properties. Look for attributeSyntax and oMSyntax. Note them down.
Match the syntax in your update
If you're using a script (like PowerShell or LDIFDE), make sure the new values you're setting for attributeSyntax and oMSyntax exactly match the existing ones. You can't change the syntax of an attribute that's already been used. If it's a new attribute, reference the schema documentation for the correct OID.
Revert the failed change
If you ran a script that partially applied, undo it. Use ADSI Edit to manually set the attribute back to its original syntax values. If you can't, restore from a schema backup.
Test the fix on a non-production DC first
Always validate schema changes in a lab environment. Schema updates are replicated and can brick your domain if done wrong.

Alternative fixes if the main one fails

Use LDIFDE with correct syntax

dn: CN=MyAttribute,CN=Schema,CN=Configuration,DC=domain,DC=com
changetype: modify
replace: attributeSyntax
attributeSyntax: 2.5.5.12
-
replace: oMSyntax
oMSyntax: 64
-

Make sure attributeSyntax and oMSyntax are paired correctly. For example, 2.5.5.12 (Unicode string) must have oMSyntax of 64. If you mix them up, you'll get the same error.

Check for schema cache issues

Sometimes the schema cache is stale. Run this command on the DC holding the schema master:

repadmin /syncall /AdeP

Then force schema reload by restarting the Active Directory service (doesn't affect normal operations) or reboot the DC.

Create a new attribute instead

If you must change the syntax and the attribute has no values yet, you can delete it and re-create it with the right syntax. But be careful — if the attribute is referenced anywhere (like in an LDAP filter or application), delete it carefully. Use ADSI Edit to delete it, then add a new one with the correct syntax.

Prevention tip

Always document the exact syntax of custom schema attributes when you create them. Store the attributeSyntax and oMSyntax values somewhere safe. If you're using a script to update attributes, validate the syntax against the existing value before running it. A simple PowerShell check like Get-ADObject -Identity "CN=MyAttribute,CN=Schema,..." -Properties attributeSyntax, oMSyntax saves you headaches. Also, never modify schema attributes that are part of the base AD schema — Microsoft doesn't support that. Stick to custom attributes only.