Fix ERROR_DS_INVALID_NAME_FOR_SPN (0X0000216A) on Windows Server

If you're seeing ERROR_DS_INVALID_NAME_FOR_SPN (0X0000216A), you're likely in the middle of a domain controller promotion, a DC replication check, or trying to add a service account. The error message says it all: the host name you supplied for the SPN is garbage. Let's fix it.

What's actually happening

The Service Principal Name (SPN) is a unique identifier that Kerberos uses to map a service to an account. The host name part must follow RFC 4120, which means it can only contain letters, numbers, dots, and hyphens. No slashes. No underscores. No backslashes. No spaces. The real-world trigger is usually someone copying a host name from a log file that includes a trailing slash or a port number, like server01:8080 or //server01.

The fix: find the bad SPN and clean it

1. Open Active Directory Users and Computers (dsa.msc).
2. Go to View > Advanced Features (you must turn this on to see the Attribute Editor tab).
3. Find the computer or service account that's causing the error. If you don't know which one, use setspn -Q */* on a domain controller to dump all SPNs and look for anything with a bad format.
4. Right-click the object, go to Properties > Attribute Editor.
5. Scroll down to servicePrincipalName and click Edit.
6. You'll see the list of SPNs. Look for one with a slash, an underscore, a space, or a colon (port number). For example: HTTP/server01:443 or HOST/DC01-extra.
7. Select the bad entry and click Remove. Then add the corrected version. For a web service on port 443, the SPN should be just HTTP/server01.contoso.com (leave the port off, Kerberos doesn't use it).
8. Click OK twice to close the dialogs.
9. Run repadmin /replsummary or the operation that originally threw the error. It should complete without the 0X000216A error.

After you remove the bad SPN, you might need to wait for replication (if it's a multi-DC environment) or run setspn -S HTTP/server01.contoso.com domain\account to add the correct one.

Why this works

Active Directory validates the SPN format when it adds or modifies the attribute. If the host name contains an invalid character (like a slash or underscore), AD refuses to build the SPN and throws this error. By removing the offending entry and replacing it with a proper format, you allow Kerberos to authenticate the service correctly. The host name should be either the NetBIOS name (e.g., SERVER01) or the fully qualified domain name (e.g., server01.contoso.com). Never include a port, path, or protocol prefix.

Less common variations of the same issue

• Underscore in the host name: Some admins name their servers like DC_01. Windows host names can't have underscores, but if the SPN uses the NetBIOS name with an underscore, AD rejects it. The fix: rename the server or use the FQDN without the underscore.
• Trailing dot: Adding a dot at the end of the FQDN (like server01.contoso.com.) is technically valid in DNS but not in an SPN. Remove the trailing dot.
• SPN with a port number: Services like SQL Server often register SPNs with a port (e.g., MSSQLSvc/sql01.contoso.com:1433). That's actually correct for SQL, but if you're not using Kerberos delegation for that service, the port might trip validation on older servers. The workaround: register the SPN without the port and use the default port instead.
• Mixed-case or special characters: While AD is case-insensitive, some SPN types (like HOST or HTTP) expect lowercase service class. The host name itself can be uppercase or mixed, but if you use something like HTTP/Server%20Name, the %20 will fail. Use plain ASCII only.

How to prevent this from happening again

• Never manually type SPNs if you can avoid it. Use setspn -S instead of -A because -S checks for duplicates and validates the format automatically.
• Validate host names before you paste them into a SPN. Strip any port numbers, slashes, or extra characters. A quick check: the host name should pass ping -n 1 hostname without any errors.
• Use FQDNs for SPNs that need to work across domains. NetBIOS names are fine within a single domain but break in cross-forest trusts.
• Monitor SPN health with a weekly script that runs setspn -X (checks for duplicate SPNs) and setspn -Q */* | findstr /R "[^a-zA-Z0-9.-]" to catch any bad characters.

That's it. The error is straightforward once you know where to look. Keep your host names clean, skip the special characters, and you'll never see 0X000216A again.