Fix AD Name Translation Error 0X00002115

Quick answer

Check DNS resolution for your domain and the reachability of a domain controller. If those are fine, verify the target account exists and you have permissions to read it.

I've seen this error more times than I can count, usually on tooling that translates user or group names to security identifiers. It's a generic wrapper—the actual cause hides behind it. Nine times out of ten, it's DNS or a DC that's unreachable from the machine running the translation. The other tenth? Permissions or a stale object in AD.

Why this happens

The error surfaces when the DsCrackNames API—used by tools like netdom, dsget, and many admin scripts—can't resolve a name because it can't reach a domain controller to do the lookup. That could be a DNS failure (the DC's SRV records aren't found), a firewall blocking port 389 or 445, or the DC itself is down. It can also appear if the account you're running the query as doesn't have read access to the object in question, but that's rarer.

Fix steps

Test DNS for your domain
On the machine throwing the error, open Command Prompt as admin and run:
```
nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.com
```
Replace yourdomain.com with your actual AD domain. If you get a Non-existent domain or no SRV records, your DNS is broken. Check that the machine's DNS points to an internal DNS server (not your ISP's). Run ipconfig /all and verify the DNS server IPs.
Verify domain controller reachability
Pick a DC from the SRV list (or any known DC) and test basic connectivity:
```
ping dc01.yourdomain.comtelnet dc01.yourdomain.com 389
```
If ping fails, check network paths and firewalls. If telnet fails but ping succeeds, port 389 (LDAP) is blocked—that's a firewall or security policy issue.
Check DC health
On a domain controller (or with RSAT installed), run:
```
dcdiag /test:dnsnetdom query fsmo
```
These will flag common issues like DNS registration failures or FSMO role problems. If dcdiag shows errors, address those first—this error is often a symptom of a deeper DC issue.
Test with a known good name
Try translating a simple, existing account (like Administrator) using the same method that failed. If that works, the problem is with the specific name you're using. Double-check spelling, UPN vs SAM format, or that the account hasn't been deleted.
Check permissions
If the name is valid but you still get the error, the account running the query might lack read permissions on the object. Log in as a domain admin and retry. If it works, grant the service account the necessary read access.

Alternate fixes

If the above doesn't resolve it, try these—I've seen each work in specific scenarios:

Flush DNS and renew: Run ipconfig /flushdns, ipconfig /registerdns as admin, then retry. This helps after a network change or if the machine's DNS cache is stale.
Check time sync: Kerberos is picky about clock skew. Ensure the machine's time is within 5 minutes of the DC. Use w32tm /resync if needed.
Use the DC's IP instead of name: In some calls, you can specify the DC directly. For tools that allow it, point to the DC's IP address to bypass DNS. This isolates whether DNS is the culprit.
Restart the Netlogon service: On the affected machine, run net stop netlogon && net start netlogon. This re-establishes the secure channel to the DC and can clear transient issues.

Prevention tips

Keep DNS healthy: Regularly monitor DNS server health and ensure all DCs register their SRV records. Use dcdiag /test:dns as part of weekly maintenance.
Document your DCs: Maintain a list of domain controllers and their IPs. When troubleshooting, you can bypass DNS quickly.
Check permissions proactively: If you run custom scripts that do name translation, test them from a service account with minimal privileges. You'll catch permission errors early rather than at 2 AM during an outage.