Introduction To Windows Activation
Ever since Microsoft decided to tighten its grip on the way in which its software is provisioned, product activation became a part of every Windows administrators agenda.
Stepping up from Windows Server 2003 to Windows Server 2008, Microsoft has introduced two changes to the activation process (or in its official name: Windows Product Activation):
- Volume License customers are no longer exempt from performing activation; customers unwilling or unable to activate products online must use the newly introduced Key Management Service (more on KMS coming right up)
- The Activation we knew from Windows XP/2003 in which the Windows is provided with a product key during installation which is later verified online (or by phone) is still available in Windows 2008 and has been labeled as Multiple Key Activation (MAK). In addition to MAK, Microsoft introduced a new activation method in which Windows periodically checks-out a license from a centralized Key Management Service (KMS) which is good for only 180 days. After the initial activation, Windows will contact the KMS server every 7 days to restart the 180 days countdown.
It is important to understand that both methods are designed to control (read:limit) the number of Windows activations performed by the customers based on the number of licenses purchased from Microsoft by requiring that each copy of Windows be activated for the particular hardware that its loaded onto.
This means two things:
- Each new Windows installation must be activated – even if it on the same hardware configuration (click here for Microsofts definition of “hardware configuration”).
- When an existing copy of Windows is migrated between hardware configurations it must be re-activated.
That’s hardly news, why does it suddenly relate to AWS?
Traditionally, the only way to launch Windows Instances was from one of the AWS provided AMIs (or a user-created derivative thereof). These AMIs were pre-configured to include a number of features such as paravirtualized drivers, the EC2 Configuration Service as well as numerous other configuration defaults which went largely unnoticed.
One such configuration was Windows Activation – does anyone recall ever activating or fiddling with the activation configuration of his EC2 Instance? Every time we provisioned a new Instance, or re–sized an existing one the – Windows OS would just boot-up normally without ever as much as mentioning the need for any Activation. This silent background configuration effectively crossed Windows Activation from the administrators to–do list when dealing with EC2 Instances.
With the recent introduction of the “VM import” feature that allows us to import an existing Virtual Machine – AWS has essentially opened the door for Windows instances that are 100% built and configured by customers from scratch (with the exception of drivers injected during the import process); and with this newfound freedom comes a wave of new problems and miss–configurations.
Focusing On The Problem At Hand
As previously mentioned, moving a copy of Windows from one hardware configuration to another will trigger Windows to require a new activation – and migrating from a VMware virtual machine to EC2 Instance definitely fits this bill. Trying to activate Windows at this point will result in one of the following:
- If using Multiple Activation Key: It is possible to re–activate this Windows copy online, but doing so will consume one activation from our online activations quota that is tracked by Microsoft (once that quota is reached – online activation will no longer be permitted).
- If using Key Management Services: Our new Instance will attempt to access the same internal activation server it had and will probably fail (unless connected via VPN).
It’s worth mentioning that in both cases we are attempting to Activate Windows using our existing Windows licenses; why should we consume our internal product licenses when the base Windows license is included in the EC2 hourly rate?
The Solution: AWS’s Key Management Services
In order to address this exact problem (and make good on the proposition that the base Windows costs are covered in the EC2 hourly rate) – AWS is providing us with their own Key Management Services to simply offload the license management from EC2 customers.
In order to successfully activate our Instance using AWS’s KMS we need to perform the following actions from within our Instance:
- Synchronize the Instance’s Windows clock with that of the AWS KMS server. The easiest way of achieving that is by configuring the Instance to synchronize against time.windows.com by going to the “Date and Time” settings from the control panel, select the “Internet Time tab” and set to synchronize with “time.windows.com”. It’s important to click on the “Update Now” button in order to avoid error code 0xC004F06C when attempting to activate.
- Configure our Instance to activate against one of AWS’s KMS servers from the table below by using the slmgr.vbs tool:
slmgr.vbs /skms
slmbr.vbs /ato
| US East (N.Virginia): |
ec2-174-129-233-152.compute-1.amazonaws.com ec2-174-129-233-141.compute-1.amazonaws.com |
| US West (N.California): |
ec2-204-236-129-123.us-west-1.compute.amazonaws.com ec2-204-236-129-122.us-west-1.compute.amazonaws.com |
| EU (Ireland): |
ec2-79-125-16-172.eu-west-1.compute.amazonaws.com ec2-79-125-16-108.eu-west-1.compute.amazonaws.com |
| Asia Pacific (Singapore): |
ec2-175-41-130-16.ap-southeast-1.compute.amazonaws.com ec2-175-41-130-20.ap-southeast-1.compute.amazonaws.com |
Conclusion
In this post we’ve discussed the potential for misconfiguration that can result from importing an Instance to AWS and continued to discuss in-depth the issue of Windows activation for EC2 Instances.
We’ve concluded with a step-by-step instructions on how to leverage AWS’s free activation service in order to offload any maintenance (and fee) that is associated with the base Windows licensing.
Happy Activations!