What's Actually Happening Here
You're seeing ERROR_DS_ATT_SCHEMA_REQ_SYNTAX (0X000020E0) when trying to modify an Active Directory attribute—usually during a schema extension or a custom attribute creation. The error means the attribute schema object exists but its attributeSyntax attribute is missing or invalid. The reason step 3 works is because we're directly writing the missing syntax OID into the schema partition.
I've seen this after a botched ldifde import or when a schema update from a third-party app (like Exchange or Skype for Business) gets interrupted mid-commit. A domain controller that's offline during replication can also orphan these syntax values.
1. The 30-Second Fix: Verify the Exact Attribute
Open an elevated PowerShell prompt or Command Prompt on any domain controller. Run this:
repadmin /showattr . "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" /filter:"(CN=YourBrokenAttribute)" /atts:attributeSyntax
Replace YourBrokenAttribute with the attribute name from the error details. If it returns nothing for attributeSyntax, you've confirmed the problem. If it shows a syntax OID (like 2.5.5.12), the issue might be elsewhere—check oMSyntax and oMObjectClass too.
Real-world trigger: This crops up most often after a schema update for an LOB app that uses custom attributes. The vendor's LDIF file sometimes omits the syntax line.
2. The 5-Minute Fix: Repadmin Replication Check
Before touching anything, rule out replication delays. Run:
repadmin /replsum /bysrc /bydest /errorsonly
If you see replication failures, fix those first—schema changes won't apply correctly across a broken replication topology. Use repadmin /syncall /AdeP to force a sync.
Next, check if the missing syntax is isolated to one DC:
repadmin /showattr DC2 "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" /filter:"(CN=YourBrokenAttribute)" /atts:attributeSyntax
Compare output between DCs. If only one DC lacks the syntax, the real fix is to replicate from a healthy DC—see the advanced section below.
3. The 15+ Minute Fix: ADSI Edit Repair
This is where we fix the root cause. You'll need to be a member of Schema Admins.
- Open ADSI Edit (from Server Manager > Tools or run
adsiedit.msc). - Right-click ADSI Edit > Connect to, select Configuration, and pick the domain controller that has the missing syntax (or just use any DC if the issue is forest-wide).
- Navigate to
CN=Schema,CN=Configuration,DC=yourdomain,DC=com. - Find the broken attribute object—sort by CN or use Find.
- Right-click the attribute > Properties.
- Locate
attributeSyntaxin the list. If it's blank or missing, click Edit and enter the correct OID.
Which syntax OID to use? Here are the common ones:
| Data Type | attributeSyntax OID |
|---|---|
| Unicode String | 2.5.5.12 |
| Integer | 2.5.5.9 |
| Boolean | 2.5.5.8 |
| Distinguished Name | 2.5.5.1 |
| Octet String (Binary) | 2.5.5.10 |
| Object Identifier (OID) | 2.5.5.2 |
Don't guess here. If you don't know the original syntax, check the attribute's oMSyntax value—it's a numeric code that maps to the syntax. For example, oMSyntax=27 maps to attributeSyntax 2.5.5.12 (Unicode String). A quick reference: oMSyntax 18 = Numeric String (2.5.5.6), oMSyntax 20 = Octet String (2.5.5.10), oMSyntax 22 = IA5 String (2.5.5.5).
After editing, close ADSI Edit and run repadmin /syncall /AdeP to push the fix to all DCs. Then test your attribute modification again—the error should be gone.
When to Just Delete and Recreate
If the attribute is custom (not from Microsoft or a major vendor) and you've got its original LDIF definition, it's often faster to delete it via ADSI Edit and re-add it with a clean import. Right-click the attribute in ADSI Edit, choose Delete, then run:
ldifde -i -f yourattribute.ldif -c "CN=Schema,CN=Configuration,DC=X" #SchemaNamingContext
I've done this at least a dozen times. It's less error-prone than guessing the syntax OID from oMSyntax if you're unsure.
Final Check
After applying a fix, verify with:
dcdiag /test:schema /v
If it passes, you're good. If not, the attributeSyntax mismatch might be deeper—check the schemaIDGUID and objectCategory too. But honestly, 9 times out of 10, the issue is exactly what's described here: a missing or null syntax value in the attribute's schema object.