Fix ERROR_DS_NAME_ERROR_NOT_FOUND (0x2116) in AD

Cause 1: Insufficient Rights to See the Object

The most common trigger for 0X00002116 is when the account running the name translation doesn't have read access to the target object. This happens all the time with service accounts running scripts or apps that call CrackName or LDAP queries. You'll see the error when the account lacks the List Contents or Read All Properties permission on the object or its parent OU.

How to fix it

1. Find the object in Active Directory Users and Computers (ADUC). Enable Advanced Features under View if you haven't.
2. Right-click the object → Properties → Security tab.
3. Add the account or group that's failing. Grant it at least Read permission (which includes List Contents).
4. If the object is nested in a locked-down OU, you might need to delegate read access at the OU level. Use the Delegation of Control Wizard or set permissions manually.

Real-world example: A monitoring tool running under svc_health suddenly started throwing 0x2116 after a security cleanup. The cleanup had stripped Authenticated Users from a sensitive OU. Adding the service account to a group with read access on that OU fixed it.

Don't just grant Full Control — that's overkill and security folks will yell at you. Read is enough for name resolution.

Cause 2: Stale or Tombstoned AD Object

Sometimes the object exists in one domain controller's cache but has been deleted or renamed on another. Name translation queries hit a DC that still has the old entry (lingering object) or the object is in the tombstone and your query doesn't include tombstone reanimation. This is especially common after a failed domain controller demotion or an authoritative restore gone wrong.

How to fix it

1. Check if the object actually exists. Run a quick LDAP query on the target DC:

dsquery user -name "username" -domain example.com

2. If it doesn't show up but you still get the error, check for lingering objects using repadmin /removelingering (careful — this is an advanced operation).
3. If the object is in the Deleted Objects container, you may need to reanimate it if it's within the tombstone lifetime (default 180 days). Use LDP or PowerShell with the ADReplication module.

Alternative fix: Restart the Netlogon service

On the machine running the query, a simple Netlogon restart often clears a cached negative entry. Run this as admin:

net stop netlogon && net start netlogon

This is the first thing I try when the error appears randomly for one user but others work fine. It's a five-second fix that often sticks.

Cause 3: DNS or Replication Lag

If the object is newly created or moved, the DC you're hitting might not have it yet. DNS points to a stale DC or replication hasn't caught up. You'll see this in multi-site environments where a user was just created on a DC in Site A but the app is querying a DC in Site B that hasn't received the update.

How to fix it

1. Check which DC is being used. Use nltest /dsgetdc:example.com to see the DC that responds.
2. Force replication from the source DC:

repadmin /syncall /AdeP

3. Confirm replication is healthy across all DCs:

repadmin /replsummary

If replication is broken, fix that first. Check DNS records for the DCs — a missing or wrong A record causes the client to pick the wrong DC. Use ipconfig /flushdns and nltest /dsregdns on the DC.

Also verify the SRV records are registered correctly:

nltest /dsquery -site Default-First-Site-Name

In one case, a client had a hardcoded DNS server that pointed to a retired DC. After removing that entry, the error vanished.

Quick Reference Table

That's the short list. In my experience, 8 out of 10 calls about 0x2116 trace back to permissions. Start there, and you'll save yourself a lot of head scratching.