Fix ERROR_DS_CANT_CACHE_ATT 0X000020D1 in Active Directory

This error is a pain, but you can fix it in under 5 minutes

You're staring at ERROR_DS_CANT_CACHE_ATT (0X000020D1) in your event logs or during an LDAP operation, and it's blocking something important—probably a schema update or a new attribute that just won't stick. I've been there. Let's skip the blame game and get this fixed.

The real fix: Force a cache refresh on the domain controller

This error almost always means the local DC's attribute cache is stale. The schema says the attribute exists, but the in-memory cache hasn't picked it up. Here's how you fix it:

Open an elevated Command Prompt on the affected domain controller.
Run repadmin /syncall /AdeP to pull the latest schema from the infrastructure master. Wait for it to finish—no errors means it's good.
Then run dcdiag /test:checksecurityerror /s:yourDomainControllerName to verify schema health.
Now the key step: net stop NTDS && net start NTDS. That restarts the Active Directory Domain Services service and forces a full cache rebuild. You'll have a few seconds of downtime on that DC—schedule this if you're in production.
After the restart, test with ldp.exe or a simple LDAP query against the attribute that was failing.

That's it. 9 times out of 10, the error vanishes after the service restart. I've seen this work on Windows Server 2012 R2 through 2022.

Why this works

AD uses a schema cache in memory to speed up attribute lookups. When you add or modify an attribute (like with a schema update via LDIFDE or a third-party app), the cache doesn't automatically refresh—it's designed to hold the old version until the next reboot or service restart. The error fires when a client or service tries to reference the new attribute but the cache says "never heard of it."

Had a client last month whose entire print queue management system died because of this. Their print server's driver attribute was added to the schema, but the domain controller's cache was stuck on the old definition. The fix was exactly what I described above. The sysadmin had been chasing GPOs and firewall rules for two hours before calling me.

Less common variations of the same issue

Sometimes the fix isn't that simple. Here are edge cases I've run into:

1. Schema master is unreachable

If repadmin /syncall fails with a connection error, the schema master may be down or the topology is broken. Check with netdom query fsmo to identify the schema master. If it's offline, seize the schema master role—I wrote a guide on that separately.

2. Partial attribute set is corrupt

In rare cases, the partial attribute set (PAS) itself is corrupt. You'll see this if multiple attributes fail to cache at once. Run dcdiag /test:frsevent /test:sysvolcheck to check for deeper issues. If you find corruption, you may need to rebuild the PAS using repadmin /syncall /APartialAttributeSet. Reboot after.

3. Third-party software hoses the schema

Seen this twice: an Exchange or Lync (Skype for Business) install botches the schema. The cache error pops on random attributes. In that case, re-run the schema update from the third party's setup, then do the cache refresh. Never skip that reboot.

How to prevent this from coming back

You don't want to see this error again. Here's what makes the difference:

Never modify the schema without restarting the domain controller. The official line says you don't need to, but I've seen too many cache issues to trust that. Reboot or restart NTDS after any schema change.
Use the infrastructure master for schema updates. Don't make schema changes on a random DC. Always target the schema master. It reduces replication latency and cache conflicts.
Monitor with dcdiag weekly. A quick dcdiag /test:ldapbind /test:frsevent /test:replications catches cache drift before it becomes a ticket.
Keep replication healthy. This error is often a symptom of a bigger replication problem. Use repadmin /showrepl to spot failing links. Fix those first, and this error follows.

That's the playbook. The next time you hit 0X000020D1, you'll know exactly what to do—restart the service, verify replication, and move on. No reinstall, no four-hour call with Microsoft Support.