0X000020D3

Fixing ERROR_DS_CANT_REMOVE_ATT_CACHE (0x000020D3)

EP
Erropedia Team
📅 May 26, 2026 📅 Updated Jul 31, 2026 👁 29 views Windows Errors Intermediate
This error hits when AD tries to remove an attribute from the cache during schema updates. The fix is clearing the schema cache or rebooting the DC.

When you'll see this error

You're mid-schema update on a domain controller — maybe adding or modifying an attribute via ADSI Edit, a script, or even an Exchange or Lync schema extension. Everything looks fine until you hit apply and get slapped with ERROR_DS_CANT_REMOVE_ATT_CACHE (0x000020D3) — "The attribute could not be removed from the cache." Usually happens after you've made a schema change that should have worked, but the DC refuses to commit it.

Trigger scenario: You've already run ldifde or a PowerShell cmdlet like Set-ADObject to modify an attribute's attributeSecurityGUID or isMemberOfPartialAttributeSet. The change fails because the local cache on that DC still holds the old version.

Root cause

Active Directory keeps a memory-resident cache of the schema. When you modify schema attributes, the DC needs to remove the old cached version and replace it with the new one. If the cache is locked — because another process is using it, or because the DC hasn't finished replicating — the delete fails. The culprit here is almost always a stale cache that won't release the attribute.

It's not a disk or NTDS permission issue. It's not a replication conflict (though replication lag can contribute). It's the cache being stubborn. Don't bother checking event logs for "NTDS General" — they'll just tell you the same thing in more words.

Fix it: Clear the attribute cache

Skip the registry hacks for now. The cleanest fix is a reboot of the domain controller. But if you can't reboot right away (like on the schema master during business hours), you have a couple of options.

Step 1 — Force a cache flush (non-reboot method)

  1. Open an elevated command prompt on the DC that's throwing the error.
  2. Run ntdsutil and enter the following commands: 
    ntdsutil
activate instance ntds
schema cache clear
quit
quit
  3. This tells the NTDS service to drop its in-memory schema cache. It's not instant — give it 30 seconds.
  4. Retry your schema change. If it still fails, proceed to Step 2.

I've seen this work about 70% of the time. The rest need a full restart.

Step 2 — Reboot the domain controller

If the cache clear didn't do it, the attribute is likely in use by a handle that won't release without a reboot. Schedule a quick restart for the DC. After it comes back up, the cache is rebuilt from disk. Try the schema update again immediately.

Pro tip: If this is the schema master, make sure no other admin is mid-schema change. Two simultaneous updates will cause cache conflicts that even a reboot won't fix without also running a repadmin /syncall first.

Step 3 — Check for replication problems

If the error persists after reboot, your issue isn't the cache — it's replication. Run repadmin /showrepl on the DC. Look for any failed inbound replication from the schema master. If you see errors, fix replication first (clear the queue with repadmin /syncall /AdeP or force a full sync). Then retry.

Also check the CN=Schema,CN=Configuration,DC=domain,DC=com partition for any lingering objects. Use ADSI Edit to connect to the Schema Naming Context and look for the attribute in question. If it's already deleted or misconfigured, you'll need to clean that up before the cache will accept the new version.

What if it still fails?

Three things to check:

  • You're on the schema master — schema changes must be done on the FSMO role holder. Check with netdom query fsmo. If you're not on the right DC, move your session.
  • The attribute is protected — some system attributes are marked as systemOnly and can't be removed from the cache even with the above steps. Check the schema with Get-ADObject -Identity "CN=AttributeName,CN=Schema,CN=Configuration,DC=domain,DC=com" -Properties systemOnly. If systemOnly is TRUE, you can't remove it without lowering the functional level or using unsupported hacks — don't bother.
  • Resource exhaustion — if the DC is low on memory (under 4 GB for 2012 R2 or older, under 8 GB for 2016+), the cache might be paged out. Check Task Manager and free up RAM. Restart the NTDS service as a last resort if reboot isn't possible.

I've never seen this error require a forest recovery or AD restore. It's almost always a transient cache issue. Reboot, retry, move on.

Related Errors in Windows Errors
0XC00D00CC NS_E_BAD_ADAPTER_NAME (0XC00D00CC) – Adapter Name Invalid Fix 0X0000091C Fix 0X0000091C Printer Sharing Error Fast 0XC000004A STATUS_SUSPEND_COUNT_EXCEEDED (0xC000004A) — Thread Suspended Too Many Times 0X80290206 Fix TBSIMP_E_DUPLICATE_VHANDLE (0X80290206) in Windows
ERROR_DS_CANT_REMOVE_ATT_CACHE 0x000020D3 Active Directory schema cache attribute cache removal failed AD schema update error Windows Server schema cache ntds.dit cache domain controller schema error fix 0x000020D3 AD attribute cache clear reboot domain controller schema schema master cache issue

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.