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):

1. 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)
2. 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:

1. Each new Windows installation must be activated – even if it on the same hardware configuration (click here for Microsofts definition of “hardware configuration”).
2. When an existing copy of Windows is migrated between hardware configurations it must be re-activated.

Introduction and example

EC2 Instances are booted either from the “Instance Store” (a process in which the AMI is copied from S3 onto an ephemeral boot device) or from EBS volumes (in which case the boot device is an EBS created from a snapshot of existing EBS volume serving as a template).

While the two types differ in many aspects, there is difference thing that really draws everyone attention: Instance Store Instances will Terminate upon shutdown (planned or unplanned) whereas EBS backed Instances have the ability to enter a Stopped state similarly to physical computers - when we turn it off it doesn’t disappear; it stays inactive until it is powered back on.

While the added persistency offered by EBS-backed volumes has many benefits - there are situations where the non-persistent nature of Instance Store Instances can be very convenient…

For example: in the past, I found myself provisioning individual all-in-a-box environments to various business partners for demo or development purposes.

In these scenarios I found it very convenient to instruct them to shut down the OS when done (or alternately rig the said Instance to shut itself down at a certain date) - thereby causing the Instance to Terminate; freeing any compute resources it was consuming and ending any charges it was incurring as such.

Note that this is not an airtight solution as we humans tend to forget Instances running and/or the Instance OS may fail to properly shut itself down but it is simple, readily available and best of all - does not require any kind of AWS account access or communication from the said Instance, completely containing the contents of the Instance for security purposes.