In a
previous article, I wrote about the virtualization administrator’s interest in choosing between the two operating system activation methods Microsoft
® offers: Multiple Activation Keys (MAK) and Key Management Service (KMS). Although there are a lot of benefits to using KMS over MAK, one of the standout reasons for selecting MAK over KMS—at least for desktop OS—is the necessity of having at least 25 systems under activation. By the same token, however, using MAK in virtual desktop infrastructure (VDI) is problematic because of the hard limit for activations that Microsoft imposes on MAKs.
When you already have Key Management Service in the environment and have a sufficient number of physical systems to keep the KMS server activated, it’s pretty straightforward: KMS “just works” for VDI. Unfortunately, there are several other scenarios where you will have challenges either enabling the KMS server to activate desktops, or
keeping it activated later, due to a) the way you’re generating your VDI desktops, or b) the total of desktops you want running in your environment.
The KMS server keeps a record of the clients that request Activation; it identifies them uniquely by the “Client Machine ID” or CMID. This is
not the same as the SID, the Activation ID, or any other identifier or UUID visible on the client with the ‘slmgr.vbs’ command. The CMID is set during initial install, when license keys are modified, during the ‘sysprep’ generalization process (when ‘rearm’ is enabled, as it is by default), or during manual rearming.
So, where does one learn about this magical CMID? In the Event Viewer for the KMS server.
Every time a KMS client requests Activation, the KMS server caches the request and logs it in the Event Log. With a little experimentation (and the ability to roll back a VM to a previous state, thanks to snapshots!), you can see for yourself that the same VM will attempt to Activate with a different CMID after each sysprep (+rearm; longer to complete) or rearm (slmgr.vbs /rearm + reboot). Repeat the cycle with enough patience, and you end up with the Key Management Service server enabled and handing out Activation tokens.
1: Client is unable to Activate; not enough clients of the same type.
2: Server only shows 14 unique clients; must be >25 for desktop OS
Here’s the process:
- Create a new desktop OS machine.
- Snapshot it.
- Attempt to activate it (slmgr.vbs /ato) Note: it attempting to activate right after a restart, it may fail without the “count reported” error. Repeat activation attempts until you receive the correct failure message.
- Rearm it (slmgr.vbs /rearm).
- If rearming succeeds
- reboot it (shutdown /r /t 0)
- repeat steps 3-5 until rearm fails
- Revert to snapshot state.
- Repeat steps 3-6 until activation succeeds.
3: Success! I now have a working KMS server!
4: Sure enough, I have the minimum count.
Next Steps
Wait a minute. Next steps? Why would I need more steps? I have everything working!
Well, yes, but it’s not
permanent. If you turn around and spin up that 10-machine VDI proof-of-concept, it’ll be fine for the next 30 days. And then all the activations will stop working again. You’ll have to go back through this process to get the unique client count back above 25
because Key Management Service only retains active clients for 30 days. Those 10 machines in the POC will still be there—maybe, depending on how the VDI environment made unique copies—but the series of clients you faked-up will be gone. According to Microsoft (
https://technet.microsoft.com/en-us/library/ff793434.aspx), the CMID is placed in a cache representing the most recent 50 CMIDs. As long as the count of CMIDs stays above the minimum, the server continues to hand out Activations. When an active client requests a renewal of its Activation, the KMS server removes any old entry for the CMID and puts a new one in its place with the new date. Any CMID entries that age out of their 30-day validity period are automatically removed from the cache.
So, what’s the trick? How do we not only get this going more easily in the first place, but keep it going after the fact?
Hint: it involves automation…and we’ll go through one method in a future post.
