Fix 0X00000889: Invalid Service Name Error on Server 2019

The Most Common Cause: You Typed the Wrong Service Name

I know this error is infuriating, especially when you're in the middle of setting up a new service account. Every time I hit this, it's because I fat-fingered the service name or used a display name instead of the actual service name. Windows is strict here—it expects the exact service name, not the friendly name you see in the Services console.

For example, if you're trying to configure SQL Server, the display name might say “SQL Server (MSSQLSERVER)”, but the real service name is MSSQLSERVER. Type the wrong one, and boom—error 0X00000889.

How to find the real service name

Open an admin Command Prompt (as Administrator) and run:

sc query | find /i "SERVICE_NAME"

This lists every service's actual name. Look for the service you're troubleshooting. Or, if you know the display name, run:

sc getkeyname "Display Name Here"

This returns the service name in under a second. Once you have it, use that in your setspn or sc config command.

Second Cause: Mismatched SPN in Active Directory

If the service name is correct but the error persists, the problem is often an SPN (Service Principal Name) issue. I've seen this trip up sysadmins when they register an SPN with the wrong service class or hostname. The error 0X00000889 can show up during Kerberos authentication when the SPN doesn't match the service name on the server.

Check and fix the SPN

First, verify the SPN for your service account. Open a PowerShell prompt as admin and run:

setspn -L domain\username

Replace domain\username with your service account. Look for any SPN that includes the service name you're using. A common mistake: using a hostname alias that doesn't resolve. For instance, if you registered HTTP/servername.contoso.com but the service expects HTTP/servername, you'll get this error.

To fix it, remove the bad SPN and add the correct one:

setspn -D HTTP/servername.contoso.com domain\username

setspn -A HTTP/servername domain\username

Then restart the service. This alone has saved my bacon more times than I can count.

Third Cause: The Service Account Lacks Permissions on the Service

Less common but worth checking: the account running the service doesn't have “Log on as a service” rights. This usually shows a different error, but I've seen 0X00000889 pop up when a scheduled task or another process tries to start a service using an SPN that the account can't back.

Grant the right

Open Local Security Policy (secpol.msc). Go to Local Policies > User Rights Assignment. Double-click Log on as a service. Add the service account there. Apply, then reboot or run gpupdate /force.

If you're on a domain, you'll need to set this in Group Policy. But for standalone servers, the local policy works fine.

Quick-Reference Summary

I'd bet money the first cause is your issue. Start there, and you'll be back to work in under five minutes. If not, move down the list—you'll nail it.