Jun
Protecting Your KMS
Does your business allow non-company equipment on your network?
Do you know if all of your physical ports are secured?
Afraid of authorizing a non-company Windows PC?
These are only a couple of reasons you need to protect the volume license keys and KMS server(s) from rogue authorizations. Microsoft has a document, Using Server Isolation to Protect the Key Management Service (KMS), available for download.
If you haven’t looked it over, you need to.
If you have read it and can’t figure it out, it’s because the document slightly outdated and the directions are incorrect. The document appears it was written for a Windows 2003 server without having the Group Policy Management Console (gpmc.msc) or a Vista machine without the Remote Server Administration tools installed. If you haven’t installed these tools yet, you really should. Vista RSAT Windows 7 RSAT.
After reading the document I created a test OU and move my KMS server and a couple of clients into the object. I then launched a remote desktop session to the KMS server and logged in locally to my client machines. I then proceed through the directions, double check everything and deploy the policy.
I open a command prompt on the clients and run gpupdate /force, and both the user and computer policies update successfully. I go to my KMS server and run gpupdate /force and after several seconds the sessions starts trying to reconnect. Not good, not good at all.
I turn my attention to the clients and run the resultant set of policy (rsop.msc) and find that the policy is being ignored. I tried pinging the KMS server and received no response. Something is definitely wrong here. I verify both the KMS server and client are in the same OU and that the policy is configured as written in the document.
Well it turns out the document was WRONG!!
The WMI filter in the document reads:
Select * from Win32_OperatingSystem where Version >= ‘6’
The correct WMI filter should be:
SELECT Version, ProductType FROM Win32_OperatingSystem WHERE Version >= ‘6′
I update the policy with the correct WMI filter and update the clients. Using my virtual machine console, I login to the KMS server and find it was unable to connect to the network. Knowing that that the policy change the firewall rules, I open the services console (services.msc) and disable Windows Firewall. A few seconds later network connectivity is restored, the group policy gets updated and I restart the firewall.
And things are as they should be. Computers not in the domain can’t communicate with the server, those in the domain can and the server can see everything.


