![Screen snip of a successful Windows 11 Enterprise KMS Activation](/sites/default/files/2024-07/fixed.png)
Manually Pointing Windows Activation At Alternate KMS Host
- Matt Zaske
- July 08, 2024
- 4 minutes
If you work with a lot of disparate dev and test devices across different domains, tenants, etc., you might run into the sort of Windows activation issue I encounter. In particular, when I'm doing dev/test work using physical hardware in my lab space (for things like OSD or OSDCloud), these machines wind up managed by my dev/test tenants/environments, and thus not pointing at our production KMS server for Windows activation.
Normally and for super short-term testing, this isn't an issue. Windows provides ample time to do most things within the grace period but once in a while I need to either extend that grace period or do something that is interrupted by not having Windows activated, usually modifying or testing certain settings as a user (not automated).
Quick disclaimer: This information is provided as-is and assumes you have valid and legal Windows licenses for the hardware in question. It is NOT provided to circumvent normal activation processes or obtain a Windows license for unauthorized devices/hardware.
The Root Problem
We have a KMS server for our regular production environment. It's well-protected behind the corporate firewall and for pretty much every use case it works as designed. Unfortunately, testing from my lab environment on a separate domain breaks the requisite access.
To the user it's simply shown/displayed as this:
![Snip of the user/client interface indicating Windows activation in an error state.](/sites/default/files/inline-images/error.png)
Problem 1: It's Always DNS
The crux of my issue is related to DNS. Ideally the proper fix for this would include creating or adjusting the proper DNS entries to point at the correct KMS. However, due to our environment (and really, the incredibly small number of times this ever crops up) it's not worth going through the trouble.
But DNS itself wouldn't be enough to fix this on its own...
Problem 2: KMS Access Requires VPN Connectivity
Even if DNS were all set, from my lab environment devices would need network connectivity to the KMS, and in that case it requires the VPN. This means one more thing to be "in the middle" of bridging this solution.
The Solution: Manually Point at a KMS Host
I'm ignoring the VPN portion of the problem, because that's a separate unavoidable issue; when I need to fix this activation issue for a test device, I will have to install the VPN client separately and connect before any of the following steps are completed. You probably will too.
Step 1: Identify the Proper KMS Host
I did this with a simple nslookup
command from a normal unaffected host:
nslookup -type=all _vlmcs._tcp
As you can see from the screenshot below, it will provide the KMS hostname (and port). In particular, you want the value of svr hostname
:
![Snip of command prompt response to looking up KMS host](/sites/default/files/inline-images/step1.png)
Step 2: Set the KMS Host
Again, this is a relatively simple command, but something I have to look up every time (much of the reason why I'm writing this post—for myself). From an elevated command prompt, run the following:
cscript slmgr.vbs -skms yourkms.domain.tld
Within a second you'll see the confirmation of the host change:
![Snip of command prompt response to setting the KMS host](/sites/default/files/inline-images/step2.png)
Step 3: Trigger Activation
I always run this from an elevated command prompt, just because I'm there. But it should be successful to invoke from the client UI as well once the KMS host has been set:
cscript slmgr.vbs -ato
This part can take a short bit of time while Things Happen, but if you have connectivity to the KMS and all the other normal requisite bits are in place (as they would be save for this DNS thing), you should see success:
![Snip of command prompt response to activation](/sites/default/files/inline-images/step3.png)
Check the Client UI!
I always have it open behind the command prompt, so it auto-updates the content, but it too should inform you that Windows is happily activated!
![Snip of the user/client interface indicating Windows activation is successful](/sites/default/files/inline-images/fixed.png)
This is Rare, but Happens
I wrote this mostly for the reference of Future Me, but I have had it crop up just enough times over the last year or so that rather than go digging to all the disparate places on the Internet I wanted to write one quick succinct guide to the short-term fix.
An activation via this method will behave like any other KMS activation and will require re-authorization at some point in the future (determined by your KMS settings), but to date I've never needed to re-up a dev/test device...because they've been refreshed or otherwise in a production setting (and no longer affected by the core problem)! Good luck!