Fix ERROR_DS_CANT_REMOVE_CLASS_CACHE (0X000020D4)

Active Directory throws this when a class is stuck in the schema cache. The fix is restarting the NTDS service or rebooting the DC, then retrying the removal.

I know this error is infuriating—you try to remove a schema class, and Active Directory just digs its heels in. You're not alone; this tripped me up the first time I ran into it during a domain controller upgrade. The good news? The fix is usually straightforward, and you don't need to rebuild the schema.

The Immediate Fix: Clear the Schema Cache

The class is stuck in the in-memory schema cache on the domain controller you're working against. The cache refreshes automatically, but not fast enough for you, right? So you force it.

Option 1: Restart the NTDS Service (Quickest)

On the DC where you're running the removal (or the one that holds the schema master), open an elevated PowerShell or Command Prompt:

net stop ntds && net start ntds

That stops and starts the Active Directory Domain Services. Wait a minute for the cache to repopulate. Then retry the class removal using your original method (ADSI Edit, PowerShell, or ldifde).

Option 2: Reboot the Domain Controller

If restarting the service doesn't clear it—or if you can't stop the service because it's hosting critical FSMO roles—reboot the DC. Yes, it's blunt, but it forces a full cache rebuild. I've seen cases where a service restart wasn't enough, especially on Server 2019 with lingering objects.

Why This Works

The schema cache is an in-memory copy of the schema that every DC holds. When you try to remove a class, the directory service checks the cache first. If the class is still there (because the cache hasn't refreshed), it throws 0X000020D4. Restarting the service or the machine invalidates that cache, forcing a fresh load from the directory database. Once the cache no longer holds the class, the removal can proceed.

Less Common Variations

Sometimes the fix isn't that simple. Here are a few sneaky variants I've hit in the field:

Variant 1: The Class Is Still Referenced

Even if the cache is fresh, you'll get this error if another class or attribute still references the one you're trying to remove. Check for auxiliary classes or possible superiors that point to it. Use ADSI Edit to browse the schema partition (CN=Schema,CN=Configuration,DC=...) and look at the possSuperiors or systemPossSuperiors attributes. You might need to remove those references first.

Variant 2: Replication Lag Across DCs

If you're deleting the class on a DC that isn't the schema master, the deletion needs to replicate to the master first. If replication is broken or slow, the cache on your target DC might still show the class. Run repadmin /replsummary to check for errors. Fix replication, then try again.

Variant 3: The Class Is a System Class

Some classes are marked as system and can't be removed without flipping a flag. If the class is defined by Microsoft (like user or computer), you can't remove it—you'd have to deactivate it instead. That's a different error, but I've seen people confuse the two. Use dsadd or ADSI Edit to set isDefunct to TRUE if you just want to hide it.

Variant 4: Permissions or Rights Issues

If you're not a Schema Admins member, the deletion will fail but might throw this error instead of a clear access denied. Double-check your group membership. You need Schema Admins, not just Domain Admins.

Prevention: Stop It From Happening Again

This error is almost always self-inflicted. Here's how to stay clear:

Plan schema changes during maintenance windows. If you're mid-change, the cache might not refresh for a few minutes. Don't rush.
Always target the schema master for schema modifications. It avoids replication lag confusion.
Check class references before attempting removal. Use LDP or ADSI Edit to inspect the class's auxiliaryClass and mayContain attributes. If anything points to it, you'll hit this error.
Keep a rollback script. Export the class definition before deleting it. If something breaks, you can re-import it.

One more thing: if you're on Server 2008 R2 or earlier, this error is rarer because the schema cache refreshes differently. But if you're still on those versions, you've got bigger problems—upgrade.

So there you go. Restart the service, retry, and if that fails, dig into references and replication. You'll be done in ten minutes, not an all-nighter.