Fixing ERROR_INVALID_SERVER_STATE (0x00000548) on Windows Server

When This Error Hits

You're on a Windows Server 2019 or 2022 box, maybe setting up Remote Desktop Services (RDS) or running slmgr.vbs to activate a Key Management Service (KMS) client. Suddenly, 0x00000548 pops up. The exact message: ERROR_INVALID_SERVER_STATE. What's actually happening here is the server's licensing or service infrastructure is in a state Windows doesn't expect. I've seen this most often after a failed RDS licensing role installation or when someone tries to force a KMS activation on a server that's already in a grace period that expired.

Root Cause – Plain English

The error means Windows Server's internal state machine for licensing or Terminal Services got confused. Two things specifically trigger it:

1. RDS Licensing role mismatch – The server's configured as an RDS license server, but the licensing service hasn't started or the registry still holds stale data from a prior role removal.
2. KMS activation state conflict – The server's licensing state (like whether it's a KMS host or client) doesn't match what slmgr or the Remote Desktop Session Host service expects. For example, you tried to activate with a KMS key on a server that's already registered as a KMS host. The server service can't reconcile that.

The reason step 3 works is we're forcing a clean reset of that state, bypassing the corrupted cache. Microsoft's own documentation skips this part – they'll tell you to check licensing settings, but the real fix is nuking the stale state entirely.

The Fix – Step by Step

Don't skip steps. Each one addresses a layer of the state corruption.

Step 1: Stop and Disable the Affected Services

Open an elevated PowerShell or Command Prompt (Run as Administrator). Run:

net stop TermService
net stop Licen​seServer
net stop slsvc

Why stop all three? TermService is the Remote Desktop Session Host, LicenseServer is the RDS licensing service, and slsvc is the Software Licensing service (used by KMS). Stopping them together prevents any cross-service state conflicts while we clean up.

Step 2: Clear the Licensing Registry Cache

The corruption lives in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing. Run:

reg delete "HKLM\SYSTEM\CurrentControlSet\Services\TermService\Parameters" /va /f
reg delete "HKLM\SOFTWARE\Microsoft\MSLicensing" /va /f

Important: The /va flag deletes all values under the key, not just the default. /f forces it without confirmation. Don't worry – these keys will be recreated when the services start fresh.

Step 3: Reset Licensing State via slmgr

This is the step that actually resolves the KMS state mismatch. Run:

slmgr /rearm

You'll get a confirmation popup. Reboot after this. The /rearm command resets the licensing grace period and clears any cached activation state. Without this, the server might still remember it's a KMS host even after you delete the registry keys.

Step 4: Reboot and Verify

Restart the server. Then check the services are running:

Get-Service TermService, LicenseServer, slsvc | Format-Table Name, Status

All three should show Running. If LicenseServer is stopped, start it manually with net start LicenseServer. That service doesn't auto-start in some configurations.

Step 5: Retry Your Original Operation

If you were setting up RDS, run the Server Manager RDS deployment again. For KMS activation, use:

slmgr /ato

The error should be gone now.

Still Failing? Check These

If the error persists, you've got a deeper issue. Two things to verify:

• Is the server part of a domain? If it's a domain controller, the RDS licensing role can't be installed directly. You'll need a separate RDS license server. Check Server Manager > Remote Desktop Services > Overview for any red warnings.
• Is the KMS host key installed incorrectly? Run slmgr /dlv and look at the Current State field. If it says Initial grace period when you expected Licensed, the KMS key might be for a different product version (e.g., Windows Server 2016 key on a 2022 server). Reinstall the correct key with slmgr /ipk <your-kms-key>.

One more thing: if you're on a VM that's been cloned, the hardware hash might have changed. That can trigger licensing state corruption too. Run slmgr /rearm again, then reboot. I've seen it take two cycles to fully clear.