RPC_NT_NO_PRINC_NAME (0XC0020054) - Fix Fast

Cause 1: Missing or Duplicate SPN for the Service Account

This is the culprit 80% of the time. The RPC client looks for a Service Principal Name (SPN) for the target service. If it’s not there — or worse, there are duplicates — you get 0XC0020054. Happens after you move a service to a different account or rebuild a server without updating AD.

Run this on a domain-joined machine with RSAT tools installed. Open an elevated PowerShell:

setspn -T yourdomain.com -Q */*

Look for the service account that should own the SPN. A common example: your SQL Server service account missing MSSQLSvc/servername.domain.com. If the SPN is missing, register it:

setspn -A MSSQLSvc/servername.domain.com DOMAIN\someserviceaccount

If you see the same SPN listed multiple times under different accounts, that’s a duplicate. Remove the extra ones:

setspn -D MSSQLSvc/servername.domain.com DOMAIN\wrongaccount

Wait for AD replication (or force it with repadmin /syncall), then test. This fix resolves the issue instantly in most cases.

Cause 2: Kerberos Ticket Cache Corruption

Less common, but I’ve seen this after a failed domain join or a time sync glitch. The client caches a bad Kerberos ticket that doesn’t include the SPN. The error pops up sporadically, not consistently.

Fix: clear the ticket cache on the client machine. Open cmd as admin and run:

klist purge

Then force a new ticket by accessing the service. If that doesn’t work, also clear the cache on the server side — especially if it’s a file server or Exchange:

klist -li 0x3e7 purge

The 0x3e7 is the local system account’s logon session. You can verify time sync too — a skew over 5 minutes breaks Kerberos entirely. Run w32tm /query /status on both ends.

Cause 3: Misconfigured DNS or Name Resolution

If the SPN is set correctly but the client can’t resolve the server’s FQDN to the correct IP, the RPC call fails with this error. This happens more on workgroup machines or after network re-IPs.

Test with:

nslookup servername.domain.com

If it returns a wrong IP or fails, update DNS. Flush the client cache too:

ipconfig /flushdns

Also check the server’s hosts file at C:\Windows\System32\drivers\etc\hosts for stale entries. Remove any that map the FQDN to an old IP. This is rare but I’ve seen it after a migration where someone forgot to clean up.

If DNS looks fine, verify the server’s Kerberos delegation settings. The service account must be trusted for delegation if it’s impersonating a user. Go to AD Users and Computers, find the account, check the Delegation tab. Set “Trust this user for delegation to any service (Kerberos only)” unless you have specific constraints.

Quick-Reference Summary