CloudStacking.com

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 administrator’s 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 it’s 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 Microsoft’s definition of “hardware configuration”).
2. 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 administrator’s 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 mis-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-activating 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:

1. 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.
2. 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 <RELEVANT_KMS_ADDRESS_FROM_THE_TABLE_BELOW>
slmbr.vbs /ato

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!

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.

So how can we set EBS backed Instances to auto-Terminate?

EBS-backed Instances default to entering the Stopped state upon shutdown (after all, supporting this state is the primary reason why we EBS-backed Instances were conceived!), but that’s configurable using the AWS API and command line tools.

There are two methods of changing this behavior (read: attribute) of the instance, called “Instance Initiated Shutdown Behavior”.

Method I: Configure during the initial creation of the Instance

When we provision an EBS-backed Instances through the RunInstances we can supply the shutdown behavior argument and specify it to terminate upon shutdown like in the following example using the EC2 command line tools:

ec2-run-instances  ami-12345678 --instance-initiated-shutdown-behavior terminate

Method II: Modifying an existing Instance

We can use the self-explanatory ModifyInstanceAttribute command on existing Instances

ec2-modify-instance-attribute i-12345678 --instance-initiated-shutdown-behavior terminate

Reverting back to Stop upon shutdown

Building on the previous method of modifying an existing Instance; we can also set the Instance to stop upon shutdown, thus reverting any previous setting to terminate.

Happy termination!

Update March 24th, 2011:
AWS now supports changing the shutdown behavior of the Instance through the web console – just right-click on your Instance and select the “Change Shutdown Behavior” option.

Cloud Computing, when exercised in all of it’s glory is about Services rather than Servers – this often facilitated by some form of task scheduling such as Message Queuing (click here to read my introduction to Amazon SQS and how to best leverage it for Cloud Computing).

In this paradigm, adding resources to the Service (again, Servers are irrelevant) is dome simply by adding more servers to our Service’s pool, rather than adding resources to any server in particular.

But not every deployment is a textbook example of Cloud Computing – and that’s fine.
Sometimes we have to deal with a component that simply can’t be distributed between servers (often the case with database servers), and sometimes we are running workloads so light that it really makes more sense to throw more resources at our single server rather than face the complexities of re-architecting our application to scale between multiple servers.

In this post we will discuss how to add resources by resizing a single EC2 Instance. [...] Continue Reading…

I commonly encounter the question whether an AWS instance can serve as a Virtualization host – be it Hyper-V, VMware or Xen.

And I can certainly understand the logic behind it – using Virtualization we could get so much more mileage out of our instances and theoretically drop the AWS costs even further down (more on that logic later).

In this post we’ll find out the answer for this question and discuss the reasons behind it. [...] Continue Reading…

Cloud Computing gets us access to incredible amount of compute resources right at our fingertips – just hanging there, ready to be picked.
Nonetheless, it is often overlooked that while provisioning new servers is incredible easy the trick is to get them to do something actually useful (a virgin OS happily idling in the cloud only generates expenses – not business value or revenue).

In this post we’ll discuss the art and science of making these configurations and customizations in order to get our cloud-provisioned servers to do whatever we actually want them to do (which should, in turn, manifest itself into business value). [...] Continue Reading…

Due to popular demand, I have created a page on this blog, describing what is Cloud Computing.
It is accessible on the top toolbar or through this link.

Now days, network-edge security is a well established practice – with firewalls providing IP based protection in every organization (and even in almost every home).

So it doesn’t surprise me that I am asked by customers and peers “what is the IP range of my EC2 machines”?

In this post we’ll do our very best to answer this question. [...] Continue Reading…

In a previous post, I’ve covered the basics of Message Queuing, and Amazon’s implementation of it: SQS (Simple Queue Service).

In this post we will dive deeper into the Amazon SQS architecture, review trade-offs that were made in order to allow it’s amazing scalability and discuss how to avoid the caveats that resulted from this architecture. [...] Continue Reading…

So whats Message Queuing anyway?
The beauty of electronic mail (or plain old snail mail for that matter) is that as the sender, you didn’t need to bother yourself with the the details of how your message reaches it’s destination.
After composing the message, all you need to do is just [...] Continue Reading…

S3 URL sharing: simply available
As S3 is a web-based file share, rather than a locally attached block device such as a SCSI disk or thumb drive.
Because it is (only) accessible via HTTP,  we can choose to direct web clients directly to it, instead of serving it from our web [...] Continue Reading…