Fix 0x211C ERROR_DS_WRONG_OM_OBJ_CLASS in AD

Active Directory schema update fails when OM-Object-Class doesn't match attribute syntax. Usually caused by bad LDAP modify operations or schema wizard bugs.

Quick answer: The OM-Object-Class attribute on the schema object doesn't match the syntax's expected value. Fix it by exporting the attribute to an LDIF file, correcting the value, and reimporting it.

That error code, 0x0000211C, shows up when you're adding or modifying an attribute in Active Directory's schema — usually via a script, an LDAP modify operation, or occasionally the Schema Manager MMC snap-in. The underlying cause is surprisingly narrow: the omObjectClass attribute on your attributeSchema object is wrong. Every attribute syntax in AD has a predefined OID that must appear in that field. If you set a string syntax (like DirectoryString, OID 2.5.5.12) but leave omObjectClass blank or point it to the OID for an integer (2.5.5.9), AD rejects the entire operation. I've seen this exact thing with custom PowerShell scripts that try to set omObjectClass to something like 2.5.5.10 when the syntax is actually a string.

This error also pops up when you import a schema extension from a vendor or a colleague who hand-edited an LDIF file. They might have copied an attribute from an old Windows 2003 server or mixed up the OIDs. The LDIF doesn't validate before import — AD only checks when it processes the change. And once it fails, you're stuck with a partially applied schema update, which is annoying.

Fix Steps

Identify the offending attribute. The error message usually names it. If not, check the Event Viewer under Directory Service. Look for event ID 1201 or similar. Note the LDAP display name (e.g., myCustomAttribute).

Export the attribute to an LDIF file. Use ldifde from an elevated command prompt on a domain controller:

ldifde -f attr.ldf -d "CN=myCustomAttribute,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -p subtree

Adjust the DN to match your attribute. If you don't know the exact path, search for it:

ldifde -f attr.ldf -d "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -r "(ldapDisplayName=myCustomAttribute)"

Open the LDIF file and check the omObjectClass line. It should be there. If it's missing, that's your problem — the syntax requires it. Look up the correct OID for your syntax. Common ones: DirectoryString (2.5.5.12), Integer (2.5.5.9), Boolean (2.5.5.8), OctetString (2.5.5.10), or LargeInteger (2.5.5.16). The attributeSyntax attribute in the same file tells you which syntax is set. For example, if attributeSyntax is 2.5.5.12, then omObjectClass must be 2.5.5.12 too. If it's 2.5.5.10 (OctetString), the correct omObjectClass OID is 2.5.5.10. Don't guess — use a reference table.
Fix the LDIF file manually. Edit that line to set the correct OID. If the line is missing, add it. The LDIF entry should look like:
```
omObjectClass: 2.5.5.12
```
Make sure you have no extra spaces or typos.
Reimport the LDIF. But first, you have to make the attribute writable. By default, schema objects are protected. Use ADSI Edit to open the Schema partition, right-click the attribute, go to Properties, and uncheck the "Protect object from accidental deletion" flag. Or use PowerShell:
```
Set-ADObject -Identity "CN=myCustomAttribute,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -ProtectedFromAccidentalDeletion $false
```
Then import:
```
ldifde -i -f attr.ldf
```
Re-enable protection. After the import succeeds, turn the flag back on to avoid future accidents.

If the Main Fix Doesn't Work

Sometimes the attribute already exists and is in a partial state. In that case, you can't just edit it — AD won't let you change omObjectClass on an existing attribute. You'll need to delete and recreate it.

Delete the attribute:

Use ADSI Edit to connect to the Schema partition.
Navigate to the attribute, right-click, and choose Delete.
If delete fails with an access denied error, you need to set the schemaUpdateAllowed registry key on the schema master. Open regedit, go to HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, create a DWORD named Schema Update Allowed, set it to 1, and reboot the DC. Then retry the delete.
After deletion, restart the AD DS service or reboot the DC to clear the cache.
Recreate the attribute using a clean LDIF or via the Schema Manager snap-in.

I've also seen this error if you're running the schema update on a non-schema master DC. The schema master must handle all changes. Check your operations masters with:

netdom query fsmo

Run the fixes on the schema master.

Prevention Tips

Don't hand-roll schema modifications unless you absolutely have to. If you're using a vendor's LDIF, validate it first by opening the file and cross-checking every omObjectClass against the attributeSyntax. A quick grep for missing lines helps:

findstr /n "omObjectClass" schema.ldf

If an attribute has a syntax, the omObjectClass must be present. The only exception is when the syntax is DirectoryString — some older tools omit it, but AD still requires it. Always set it.

Also, test schema changes in a lab environment first. I know that's a pain, but a single typo can corrupt your schema, and recovery from schema corruption isn't fun. Back up the schema partition before any change. You can use ntdsutil to snapshot the AD database, or at least use ldifde -f backup.ldf -d "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" to export the whole schema.

Last thing: don't run random schema updates from the internet. I've seen dozens of scripts that set omObjectClass to 2.5.5.0 or similar nonsense. Stick to Microsoft's official schema extensions or your own tested code.