My non-persistent desktop fail to activate, where is my KMS host?
In this short article I will show you what I think is a bug in Microsoft Windows 2012R2, where you KMS host disappears of the radar for the clients. If it is a bug is to be seen but everything looks that way so far, we will need to continue to monitor the environment and see if it will happen again. Let me describe what the symptoms are when KMS is unreachable and how you can solve it.
So let’s first take a quick look into the environment so that you know what we got running here. It’s a Microsoft Windows 2012R2 environment, so far no other operating systems of Microsoft are deployed and if we can keep it that way we are happy. We got a couple of SQL failover cluster running on Microsoft SQL 2014 and of course a KMS host, hosted on microsoft Windows 2012R2. All this to support a VDI environment running on VMware Horizon 7. Two Pods in two datacenters running Windows 10 with Apex or NVIDIA cards to support this customer. The Horizon environment is running on VMware of course and controlled by VMware NSX and Palo Alto firewalls.
So what happened that triggered us to look a the KMS issue? Today my task was education to administrators of the new environment. The last weeks I, together with co-workers build the environment and it was time to get the customer in on it so they can install their apps and make it their own.
One of the administrator told me that the CAD/CAM desktop pool was in error state, taking a deeper look it showed that it had issues with activating licenses. VMware Horizon 7 uses Quickprep to prepare the desktops and this pool is a non-persistent desktop pool which is refreshed every logoff.
So the Desktops didn’t get past the license activation, a feature we got running for weeks already which never gave any issue so far. That was the symptom an error with the dektop pool about activation.
So next up you investigate as at this point I had no idea whether it was KMS related or Network related. So I happen to have a vm deployed that was not yet domain joined and not activated (I presumed). Joined the desktop to the domain and tried to execute slmgr.vbs /ato which came back with an error. Yes, we got a error, perhaps strange to read but an error is good as you now have something to hold on to.
The error was “0x8007237B DNS entry does not exist”.
What do you mean it does not exist, of course the DNS entry exists.
So connect to the DNS server and search for the DNs entry, look under Forward lookup zones/zone name/_TCP. So the entry is gone, that’s pretty weird as no one is working in this environment as me and I didn’t delete anything here.
Next up is the KMS host and seeing whether it is still functional, did some checks there like running command slmgr.vbs /dli and saw the number of registration and also so there were no failed ones. The issue was not at the KMS host it was somewhere in between. Tried a restart but the entry never did come back so the only solution we could think of was adding the entry ourself.
So Right click in the _TCP screen and choose “Other record type“, browse down to “Service Location (SRV)” and click on “Create Record”
At the field service you fill in “_VLMCS“, in the protocol field “_TCP” and in the Port number field “1688“.
Enter the FQDN of the KMS server and click OK. The entry is there and it is time to test.
At the client side you enter “slmgr.vbs /ato” after you did a “IPConfig /flushdns” and a “IPconfig /registerDNS” and everything will start working again. for the clients that were activated a grace period was active so they will get the DNS update in the next sequence.
The solution is simple but feels more like a workaround to me. I still can’t get around why this entry suddenly was gone. I feel it is a bug as it happened just like that with no one on the systems. I did a quick search on the internet and found more people with issues about KMS entries, so my bug idea stays.
Hope this helps you in fixing it if you run into it.