To better combat software piracy, Microsoft introduced License Activation with Windows XP/Server 2003; however, activation was pretty much implied and automatic if you had volume license keys. When these keys, generated for individual organizations, inevitably leaked to the general public, Microsoft added activation on volume license keys with the release of Windows Vista / Server 2008. In the current incarnation of Activation, volume licensees have two choices for handling license activation: externally, just like all the retail customers do, and internally, with a key management server.
As an end result, when a customer logs into the Volume Licensing portal at Microsoft, all their products (requiring activation) should present two types of license keys: MAK (multiple activation key) and KMS (key management server).
This is relevant to the virtualization world because we not only use our favorite hypervisor to run Windows guests, we tend to do it for lots of them, leading us to decide which key should be used to activate a guest. And as with all options, there are pros and cons and a whole lot of “it depends” when seeking advice on the best option to select. Also, you’re at liberty to choose for
every single guest in the environment; it’s not an all-or-nothing proposition. What fun!
Rather than being an exhaustive resource on which licensing type to use, the intention of this article is to distill down some of the most salient pro/con points for both models, and (hopefully) bring some light to a subject that might just be a bit of a black box.
MAK vs. KMS
The first, most significant difference between the two types of keys is the location of the actual activation. MAK activation is confirmed with servers hosted by Microsoft. In the ideal scenario, this happens quickly via Internet connection. In other cases, an administrator calls into Microsoft with an activation request code and receives an activation code that must be manually input into the guest. Under KMS, one or more servers in
your environment provide activation (via network) to your guests rather than from Microsoft. KMS activation, however, has an important caveat: Microsoft has established activation request minimums that must be met for the KMS server to function. In the case of Server OS, the minimum is five (5) unique requests; for Desktop OS, the minimum is twenty-five (25).
Another big difference is what the keys can activate. In broad terms, a single KMS key server in the environment can simultaneously activate many different OS versions and editions, while a MAK typically works on only the version and edition for which it is generated.
Next is the longevity of activation. In the case of the MAK, once the OS is activated, you’ll never have to activate it again. However, this is a broad generalization. Microsoft has a complicated and (mostly) undocumented algorithm for triggering re-activation requests. These usually only occur when large-scale hardware changes are made to the system, but for most virtual machine environments, this is a rare occurrence. A machine activated with KMS must periodically check in with the licensing server, even when there are no changes to the hardware, and renew its activation. The KMS check-in is also used to maintain the count of activated systems under the KMS server’s purview. If the threshold isn’t maintained, the KMS server stops (re)activating guests, and you start seeing non-compliance warnings in your environment.
While the previous difference might immediately suggest that you use MAK for all instances, the final big difference between the two is found in key re-use limits. With MAK, there’s a fixed limit. With KMS, it’s essentially limitless. The fixed limit varies, and it’s based on the number of licenses acquired in the volume license when the key is being generated. For small environments, even with data center licensing for unmetered guest OS use, I commonly see keys with only 45 activations. Once that key’s activation count is reached, you must request new keys from the Volume Licensing Service Center. While MAK’s limitations might be fine in the infrastructure VMs, the activation limit makes it totally unsuitable for virtual desktop (VDI) environments using non-persistent desktop functionality because it’s far too easy to burn through the allotted activations in those environments.
Guidelines
Microsoft, of course, has plenty of information, guidelines, and recommendations for which licensing model you use. Personally, I find that they have too much information, and it’s hard to cut through it all to get a set of concrete recommendations. While I’m not able to speak with the authority of Microsoft itself, I’ll give the following advice and guidelines as a longtime VMware admin:
- If you have data center licensing for your virtualized OSes, use KMS. A perk of that data center license is the ability to spin up as many VMs with Windows as your infrastructure can support. This means that if you implement KMS, you don’t have to even think about license keys and activation. Stand up a small VM with Server Core (all the tools for working with KMS are command line, so you don’t gain anything by having a full GUI) to act as your KMS server. Register the KMS with DNS and activate at least five (5) additional servers to get it triggered. Every VM you provision in the environment can now take advantage of that KMS server, and you won’t have to worry about activation.
- If you don’t have data center licensing, but you do have at least five Windows servers plus enough churn in your environment that you regularly add and remove VMs (staying at or under your maximum allowed guest count), you should seriously consider KMS. This is simply to avoid the challenge of getting new keys issued when your current one no longer activates.
- If you have specific, tightly controlled license counts for your VMs, and for the sake of compliance you can’t have the wrong version or edition running in your environment, stick with MAK. It gives you a great deal of precision for what gets activated. KMS allows multiple versions and, depending on the key, multiple editions to be activated without much oversight.
- Physical devices that leave the network for any amount of time should be activated with MAK. That’s right. KMS and MAK are not just decisions for your virtual environment. Physical systems, including laptops, should be included in the calculus. If they’re out of touch from an activating KMS for too long, they’ll de-activate, which will eventually result in calls to the help desk.
- As indicated in the differences above, any VDI environment should use KMS, even if you use MAK for the remainder of the infrastructure. Conventional wisdom dictates that all VDI environments contain at least 25 active desktops, to maintain the KMS trigger. But even when pursuing a proof of concept for VDI with a dozen or fewer desktops, it’s possible to trick the KMS into thinking that there are more active machines in the environment than there actually are. But I’ll save that post for another day.
