Manually Pointing Windows Activation At Alternate KMS Host

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:

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:

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:

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:

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!

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!