Active Directory class not defined error 0x000020B3 fix

When this error hits

You're in Active Directory Users and Computers (ADUC) or maybe using PowerShell to create a user, group, or computer. You fill in the fields, click OK, and get hit with:

ERROR_DS_OBJ_CLASS_NOT_DEFINED
0X000020B3
The specified class is not defined.

I see it most after someone extends the schema with Exchange, Skype for Business, or a third-party app like an LAPS update that didn't finish. Also happens when someone runs a script and the class name has a typo — like typing 'user' when it should be 'User' (case matters in some LDAP queries).

Root cause

The class name you're trying to use doesn't exist in the schema. The AD schema is like a database of definitions for every object type (user, group, computer, etc.). When the class name isn't there, AD refuses to create the object. It's not a permissions issue — it's a missing definition.

Common triggers:

• Schema update from Exchange 2016 or 2019 that failed halfway
• Running an old LDIFDE script with a typo in the class name
• Manually editing schema with ADSI Edit and deleting a class by accident
• Domain controller at different schema versions — happens after a new DC joins an old domain

The fix — step by step

1. Check which class is missing. Open Event Viewer on your DC, look under Windows Logs > Directory Service. The error event ID 1450 or 1168 usually shows the exact class name that's undefined. Write it down.
2. Verify schema existence. Open ADSI Edit (if not installed, add it via Server Manager > Tools). Connect to 'Default naming context' or 'Schema' — depends on what you're creating. For a user object, browse CN=Schema,CN=Configuration,DC=yourdomain,DC=com. Find the class name from step 1. If it's missing, you found your problem.
3. Re-run the schema extension. If the error came after an Exchange or LAPS install, go back and run the schema prep again. For Exchange, run setup.exe /PrepareSchema /PrepareAD from an elevated command prompt. For LAPS, run Update-LapsSchema in PowerShell. This re-adds the missing class.
4. If no extension was recent, check if you have multiple DCs on different schema versions. Run Get-ADObject -Filter * -SearchBase "CN=Schema,CN=Configuration,DC=domain,DC=com" -Properties objectVersion | Select-Object Name to see all classes. Look for a class name that's blank or shows 'CNF' (conflict) — that's a replication problem. Fix it by forcing replication: Repadmin /syncall /AdeP.
5. Manual fix as last resort. If a class is actually missing and you know the definition, use ADSI Edit to add it. Right-click the Schema container > New > Object > Choose 'classSchema'. Fill in cn (class name), governsID (OID), and subclassOf. This is dangerous — one typo breaks AD. Only do this if you have the exact OID from Microsoft docs. Backup the schema first with ntdsutil.

What to check if it still fails

• Replication lag: run Repadmin /showrepl to see if all DCs got the schema update. If one DC is behind, force replication or wait for it.
• Schema cache: AD caches schema for performance. After adding a class, restart the Active Directory Domain Services service on the DC you're working on. Run net stop ntds && net start ntds (this kicks users out, so do it in a maintenance window).
• Double-check the class spelling. Case-sensitive in LDAP queries is rare but happens with some tools. Use exactly the name from the schema.
• Check for schema conflicts: run repadmin /showattr . "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" /filter:"(cn=*)" /atts:cn and look for duplicate or missing entries.
• If you're still stuck, promote a new DC, transfer the schema master role to it, and re-run the schema extension from scratch. That clears most corruption.

This error is annoying but usually fixable in 10 minutes. The biggest mistake is jumping into ADSI Edit and guessing — that's how you break a domain. Stick to re-running the failed schema update, and you'll be fine.