Fix RPC_E_INVALID_STD_NAME (0x80010122) SPN Error

I know seeing 0x80010122 with that “principal name is not a valid Microsoft standard (msstd) name” message is annoying, especially when you're in the middle of setting up a service like SQL Server or Exchange. It almost always comes down to a misconfigured Service Principal Name (SPN). Let's fix it right now.

Immediate Fix: Delete and Re-register the SPN

Open Command Prompt as Administrator on a domain controller or a machine with RSAT tools installed.
Run this command to list all SPNs for the affected service account (e.g., svc_sql):
```
setspn -L svc_sql
```
You'll see a list like:
Registered ServicePrincipalNames for CN=svc_sql,CN=Users,DC=contoso,DC=com:
MSSQLSvc/sql01.contoso.com:1433
MSSQLSvc/sql01
Look for any SPN that seems wrong. The error 0x80010122 usually means the SPN is missing the service class or has a malformed name. For example, host/sql01 instead of MSSQLSvc/sql01.contoso.com:1433.
Delete the bad SPN with:
```
setspn -D MSSQLSvc/sql01 svc_sql
```
Replace MSSQLSvc/sql01 with whatever malformed SPN you saw.
Re-register the correct SPN. For SQL Server, the correct format is:
```
setspn -A MSSQLSvc/sql01.contoso.com:1433 svc_sql
```
Replace sql01.contoso.com with your server's FQDN, and :1433 with the actual port your service listens on.
Verify with setspn -L svc_sql again. You should now see the properly formatted SPN.
Restart the service (like SQL Server or the Exchange RPC Client Access service).

After you restart, the error should be gone. If the service still complains, wait a minute for Kerberos to update – domain replication can take a short while.

Why This Works

The error 0x80010122 kicks in when Windows tries to resolve a principal name for Kerberos authentication, and the SPN doesn’t match the Microsoft Standard (msstd) format. The msstd format is basically serviceclass/host:port – no extra slashes or missing parts. If you have a duplicate SPN or one that’s just plain wrong (like host/myapp instead of HTTP/myapp.contoso.com), Kerberos gives up and throws this error. Deleting the bad one and adding the correct one clears it up.

A lot of people skip the port number, thinking “it’s the default, so it’s fine.” Don’t do that. Windows expects the port if the service registers it. Even if the service uses the default port, include it. You’ll save yourself an hour of head-scratching.

Less Common Variations of This Issue

Case 1: The SPN Is Registered on the Wrong Object

Sometimes the SPN gets attached to a computer account instead of the service account. Check with setspn -L computername$. If you see your service SPN there, delete it from the computer and add it to the proper service account:

setspn -D MSSQLSvc/sql01.contoso.com:1433 sql01$
setspn -A MSSQLSvc/sql01.contoso.com:1433 svc_sql

Case 2: Duplicate SPNs

Run setspn -X to check for duplicates. If the output lists more than one account with the same SPN, delete the duplicate from the wrong account. Duplicate SPNs cause Kerberos to fail with vague errors – but sometimes you get 0x80010122.

Case 3: The Service Is Using NetBIOS Instead of FQDN

If your application connects to the server using a short name like SQL01 instead of sql01.contoso.com, the SPN must match. Register an SPN for the NetBIOS name too:

setspn -A MSSQLSvc/sql01 svc_sql

Prevention for Next Time

Use a dedicated service account – never let services run under NetworkService or LocalSystem unless absolutely necessary. Those accounts auto-register SPNs, and when things go wrong, they’re harder to clean up.
Document your SPNs – keep a list of every SPN and which account owns it. I use a simple text file, but even a spreadsheet works.
Run setspn -X regularly – throw it into a weekly scheduled task. Duplicate SPNs are the #1 cause of weird Kerberos errors, and catching them early is easy.
Test SPN registration after any service reinstall – if you rebuild a server or change its name, the old SPN lingers. Clean it up manually.

That’s it. The fix is quick, and now you know why it happens. If you run into a case where the error persists after all this, check your DNS – missing A records for the server’s FQDN will also break Kerberos, though you’d see a different error code. But 9 times out of 10, 0x80010122 is a bad SPN.