Fix ERROR_DS_CANT_CACHE_CLASS 0x000020D2 in AD

I got a call from a SMB client last week—their domain controller started throwing ERROR_DS_CANT_CACHE_CLASS (0x000020D2) after they applied a schema extension for a third-party app. Their HR software suddenly couldn't query AD, and the event logs lit up with this error. The trigger here is almost always a schema update that either didn't finish cleanly or hit a replication snag. You'll see it in the Directory Service log with source NTDS or SAM.

What's actually happening

Active Directory caches class definitions (like user, group, computer) in memory for performance. When you extend the schema—adding new classes or attributes—the DC needs to rebuild that cache. If it can't, usually because the schema version in the registry doesn't match what's in the database, or a replication cycle was interrupted, you get this error. The DC basically says, "I know this class exists, but I can't store it in the cache."

Fix it in 4 steps

Reboot the Domain Controller
Sounds simple, but it clears the cache and forces a fresh load from the schema partition. I've seen this alone fix the error when it's just a stale cache from a partial schema update. Do this first—it takes 2 minutes and saves you the deeper steps.
Check and repair schema replication
Open Command Prompt as Administrator and run:
```
repadmin /syncall /AdeP
```
Look for any failures. If you see replication errors, fix those first—fix the root before patching the leaf. Also run:
```
dcdiag /test:Replications
```
If replication is healthy, move to step 3.
Update the schema cache via Ntdsutil
This is the core fix. Open Command Prompt as Administrator and run:
```
ntdsutil
schema cache
clear cache
q
q
```
This clears the in-memory schema cache and forces AD to reload it from the directory database. After this, restart the NTDS service or reboot the DC.
Verify schema version matches
Open Regedit and go to:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
```
Check the value of Schema Version. It should match the schema version in your forest (usually 69 for Windows Server 2019/2022). If it's wrong, you've got a corrupt schema—that's a bigger issue and might need a forced schema reload from a backup or a forest recovery.

If it still fails

If the error persists after the above, check the Microsoft-Windows-ActiveDirectory_DomainService operational log for event ID 1168 or 1925. These point to a schema file (schema.ini) that's missing or corrupt. You might need to reapply the schema update from a clean ADSI Edit connection—delete the faulty class and re-add it. But honestly, that's rare. In most cases, steps 1 and 3 do the trick.

Pro tip: If you're running multiple DCs, make sure all of them have replicated the schema change before you try to use the new class. I've seen this error pop up on a DC that was lagging behind replication by 30 minutes.

One last thing—if you're using a third-party app that modified the schema (like Exchange, Lync, or some HR software), check their documentation for a schema update rollback or reapply procedure. Sometimes their own schema objects cause the cache to choke.