Pages

Monday, March 21, 2011

Setting up KMS for Windows Activation on Server 2008 x64

We initially set up all of our Windows Servers using MAK keys.  For those not familiar, MAK keys are very simple: you copy them from your licensing agreement with Microsoft and paste them into Windows activation, and then you're done.  Simple right?  The only trouble with using MAK keys is that you can only use them a limited number of times before you need to call Microsoft to increase the number of times that you can use them.  In our Citrix environment, I regularly image about 10 servers at a time when we make changes -- so you can see how I'd chew up the limited number of activations very quickly.

Enter KMS.  With KMS, you need to set up one server on your network as a KMS host, and then all of your Windows machines can activate against it an unlimited number of times as KMS clients.  The only potential "gotcha" is that each of these KMS clients need to periodically check in with the KMS host to remain activated.  Since our Citrix farm is all on the same network and never gets shut down, this would not be a problem for us.  To understand more about KMS please check out this article.

Our current Citrix farm is installed on Server 2008 R2; however, the domain controller that I made to be the KMS host, is running Server 2008 x64.  Setting up the KMS host was pretty straightforward: Change the current license key to our KMS B license key (B is for Standard and Enterprise edition servers), and then restart the Software Licensing Service.  By default, if you have Dynamic DNS enabled, this should create some new records on your DNS server to let clients know where the KMS host is listening.  If you don't have Dynamic DNS enabled, you'll need to create these records manually.  Plenty of information on that and other fun KMS topics can be found in this article.

Now for the client side of things.  By default, Windows installations are KMS clients (I didn't know this before, so that's a fun fact) -- they will check in with the DNS server to see if there is a KMS host out there, and then try to activate against it (note: for Windows Server, the KMS host must receive at least 5 activation requests before it will start activating).  I had a little more work to do since I had previously entered our MAK key for activation.  In order to switch the server back to a KMS client, I had to type in the following command from an elevated command prompt:
slmgr.vbs /ipk KMSSetupKey


where KMSSetupKey is a key that is provided by Microsoft that is not part of a licensing agreement -- it's just a generic key.  I pulled the one I needed from this site.  Then, to attempt an activation, you can type in the following command from an elevated command prompt:
slmgr.vbs /ato


Unfortunately, my attempt was not very successful.  Instead, I was prompted with the error "The key management service is unavailable."  This can mean a number of different things, but to get to the bottom of it, I pulled up the Event Log on the KMS host and noticed the following error number: 0xC004F042, which according to this site of common activation errors, means that there is a mismatch of some kind between our KMS host and our KMS client.  After a bit of digging, I discovered that I needed to apply an update to our KMS host running Server 2008 x64 to allow KMS clients running 2008 R2 to activate against it.  If you are in need of this update, it is currently available here.


Now, that's not the end of the story.  After applying the update and rebooting the KMS host, I was still unable to activate our 2008 R2 Servers.  In order to complete the update process, you must install the Server 2008 R2 KMS host key using the same command (slmgr.vbs /ipk KMSSetupKey) as mentioned above, except you'll need to use the KMS key from your license agreement with Microsoft.  Then, I just needed to activate it (slmgr.vbs /ato) and restart the Software Licensing Service one more time.  Now we can activate R2 servers against our KMS host.


Next stop will be determining how this all affects my Altiris imaging process...

No comments: