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...

Installing Red Hat Enterprise Linux 5.5 on a Multipath Device

Note: Most, if not all, of the tips I'm providing in this post are available in Red Hat or IBM documentation.  It took me awhile to find it though, so I thought it may be nice to save for a quick reference.

This week, our team was tasked with installing Red Hat Enterprise Linux (RHEL) 5.5 on an IBM server.  This server connects to two different drives provided by a DS8100 storage system, and has two paths to each drive.  In our first attempt to install RHEL, we had to use the text-based installer since this server does not have a video card, which made this entire process a little more fun.

In going through the installer, it detected the two paths to each of our two drives, so instead of showing just the two drives it showed four (counting each path as an individual drive).  We went through the motions and targeted one of the drives it detected for the install.  Unfortunately, when we rebooted the machine, it didn't see that drive as a bootable device, marking our first defeat.

To make things a little easier on ourselves, we decided to go with the recommended graphical installer.  How did we do this without a video card, you may ask?  With our friend, VNC.  If you're interested in using VNC to connect to your install, the documentation mentions the TigerVNC client, so that's what we went with.  In order to get the installer to start a VNC server, you need to add the following option at boot when prompted:
boot: linux vnc
You'll be prompted to configure the IP address for the server to run VNC on the machine, but once it's up and running you will be presented with the display to connect to.

Now that we had a graphical installer to work with, we were feeling much better and went through another install.  It failed.  So, we tried again testing various disk layouts.  They failed.  We made a few more attempts before the end of the day, but just couldn't get this installer to lay down a bootable OS on the drive.

In the back of my mind, I was thinking it had to do with multipath aspect.  If we could somehow get this installer to only see two drives, instead of four, maybe our luck would change.  After doing a little research through the Red Hat documentation, I discovered that if you try to install to a multipath device, it's probable that it will fail and/or it won't be bootable.  The key to solving this problem: adding just one additional boot parameter.  So, in the end, our boot parameters looked like:
boot: linux vnc mpath
Then, in the installer, it detected two multipath devices, we installed the OS to the first multipath device, and like magic, we had a working installation of RHEL 5.5!

The following section only applies if you are running an IBM Storage System, specifically something in the DS6000 or DS8000 series.  So, if that doesn't apply to you, feel free to move along :)

After the install, there were a couple additional steps to make sure multipath was configured correctly for our DS8100 system.  You will need to make sure the following packages are installed:
device-mapper
device-mapper-multipath

Next, you'll need the multipath config file from the IBM website (currently located on this page in the section labeled "Device Mapper Multipath Configuration File for ESS DS6000 DS8000 and SVC".  Make sure you grab the one for the RHEL 5 Platform).  After obtaining multipath.conf, back up your existing one under /etc/multipath.conf and then simply copy this one into the /etc directory.  In order to get my system to recognize the new config, I had to run the following command:
multipath -r
You can then confirm that the drives are discovered with the following command:
multipath -l


Hopefully this post will save you a little bit of time and heartache!