AD cache missing naming context – fix for error 0x20E5

You'll see ERROR_DS_CANT_FIND_NC_IN_CACHE (0X000020E5) when a domain controller tries to look up a naming context – usually during cross-domain authentication or LDAP referral – but can't find it in its own in-memory partition table. The real-world trigger: a user from a trusted forest tries to access a resource, or you attempt an LDAP query that crosses domain boundaries, and the DC serving the request hasn't fully replicated the naming context from its partner. I've seen this most often right after adding a new domain or application partition, before replication finishes.

What's actually happening here

Active Directory stores partitions (naming contexts) in a cache for fast lookups. The cache lives in the LSASS process. When the DC boots, it loads this cache from the database. If a new naming context gets added (e.g., a new domain in the forest, or an application partition like CN=MyPartition,DC=Contoso,DC=com), the cache doesn't automatically refresh – it only updates on a scheduled time or when the DC restarts. So if a client or another DC asks for a naming context that the local DC knows about in its ntds.dit but hasn't cached yet, you get 0x20E5.

The fix

Skip the rabbit hole of searching for corrupt database records. The fix is to force the DC to rebuild its cache. Here's how.

1. Open an elevated command prompt on the affected DC.
2. Run ntdsutil, then type activate instance ntds and hit Enter. This tells ntdsutil to target the local AD database.
3. At the ntdsutil: prompt, type ldap policies then connections then connect to server localhost. You're now connected to the local LDAP server.
4. Still in connections, type clear cached values. This purges the in-memory naming context cache. The DC will reload it on next LDAP bind or referral request.
5. Type q twice to return to the ntdsutil root, then quit.
6. Wait 60 seconds, then test. Run repadmin /showrepl to confirm replication is healthy, then try the failing operation again.

Why step 3 works

The clear cached values command under ldap policies forces LSASS to drop its cached partition list. The next time an LDAP request hits the server, it re-reads the actual naming contexts from the database. That picks up any newly added partitions that weren't loaded at boot. The reason we connect to localhost is because ntdsutil needs an LDAP session to issue the cache-clear operation – it's not just a local registry hack.

If it still fails

If clearing the cache doesn't fix it, the naming context might literally not exist in the database. Check with repadmin /showrepl * /nc – this lists all naming contexts known to this DC. If yours is missing, you need to force replication from a partner that has it. Run repadmin /syncall /AdeP to pull all partitions from all partners. Still missing? The partition was never created, or the DC was removed from the replication topology. Use ADSI Edit to verify the partition exists in the Configuration partition (CN=Partitions,CN=Configuration,...).

One more thing: if you're running Windows Server 2008 R2 or older, the clear cached values command didn't exist. For those, you have to restart the NetLogon service or reboot the DC. On modern versions (2012 R2 and later), the ntdsutil method above is clean and doesn't require a restart.