Fix RPC_S_NO_PRINC_NAME (0X0000071E) on Windows Server

Quick Answer

Run setspn -A HOST/ServerName.domain.com ServerName and setspn -A HOST/ServerName ServerName on the server showing the error. Then restart the service or reboot.

Why This Happens

You're seeing error 0X0000071E (RPC_S_NO_PRINC_NAME) when a server tries to make an RPC call to another machine — often a domain controller or a file server. This is a Kerberos authentication failure. The RPC system looks up the target server's Service Principal Name (SPN) in Active Directory. If that SPN is missing, duplicated, or incorrect, Kerberos can't negotiate a ticket, and the call fails with this error.

I see this most often in mixed environments where servers were renamed, joined to a new domain, or when a service account's SPNs got corrupted. For example, you might hit this after migrating a file server from Server 2016 to Server 2022 without manually registering the new SPNs.

Here's the bad news: Windows doesn't always auto-register SPNs correctly when you rename a machine or change its domain membership. The real fix is to check and update the SPN list manually.

Step-by-Step Fix

1. Open Command Prompt as Administrator on the server that throws the error. Right-click Start, select Command Prompt (Admin) or Windows Terminal (Admin).
2. Check current SPNs for the server's computer account. Run: setspn -L ServerName. Replace ServerName with the actual hostname. You'll see a list of SPNs like HOST/ServerName.domain.com and HOST/ServerName. If both are missing, that's your problem.
3. Register the missing HOST SPNs. Run these two commands: setspn -A HOST/ServerName.domain.com ServerName and setspn -A HOST/ServerName ServerName. The -A flag adds the SPN. After each command, you should see a confirmation: Registering SPN for account... Succeeded.
4. Verify the SPNs were added. Run setspn -L ServerName again. You should now see both HOST entries in the list. If they show up, you're good.
5. Restart the RPC service on the local server. Open Services (services.msc), find Remote Procedure Call (RPC), right-click it, select Restart. This forces Windows to re-read the SPN cache. Wait 30 seconds after restart.
6. Reboot the server if the issue persists. A full reboot clears any stale Kerberos tickets and forces a fresh SPN lookup. I know it's annoying, but it works.
7. Test the RPC call again. Try whatever operation originally triggered the error — connecting to a share, running a remote management tool, or a scheduled task. If it completes without the error, you're done.

Alternative Fixes If the Main One Fails

• Check for duplicate SPNs. Run setspn -X from an elevated command prompt on any domain controller. This scans for duplicate SPNs across all accounts. If it finds duplicates for HOST/ServerName, delete the extra ones. Duplicates cause the same error because Kerberos doesn't know which account to trust.
• Manually fix SPN on the target server's computer account. Open Active Directory Users and Computers, find the computer object, right-click it, select Properties. Go to the Attribute Editor tab, find servicePrincipalName, and edit it. Add HOST/ServerName.domain.com and HOST/ServerName if they're missing. This is the nuclear option, but it's useful when setspn fails due to permissions.
• Use a reboot on both sides. If you're connecting from one server to another, reboot both machines. I've seen cases where the local server has valid SPNs but the remote server's Kerberos ticket cache is stale. A reboot clears everything.
• Check for time sync issues. Run w32tm /query /status on both machines. If the time offset is more than 5 minutes, Kerberos fails regardless of SPNs. Sync time using w32tm /resync on the domain controller, then on the member server.

How to Prevent This

Never rename a server after it's joined to the domain without manually updating its SPNs. If you must rename it, run setspn -R NewServerName from an elevated command prompt before rebooting. That command removes old SPNs and adds the new ones in one step.

Audit SPNs quarterly on critical servers. I set up a weekly script that runs setspn -L %COMPUTERNAME% on all domain controllers and file servers, then emails me the output. It's saved me more than once.

Use a dedicated service account for SQL Server or IIS instead of the computer account. Those services often break SPNs when the computer changes. A gMSA (Group Managed Service Account) handles SPNs automatically and never causes this error.

One last thing: if you're on Windows Server 2019 or 2022, make sure all domain controllers are running the same OS version. I've seen odd SPN behavior when a 2022 member server talks to a 2012 R2 DC. Upgrade those old DCs.