OS Version on Windows Azure

December 05, 2010 (Last Modified: December 05, 2010)

One of the many options you have when deploying to Azure is what Azure OS version your Azure Service should run on. In Azure you have a choice between the OS Family (which currently means Windows Server 2008 SP2 or Windows Server 2008 R2) and the OS Version. I feel that this is slightly confusing because I’d normally say that the 2008 R2 was the version of the OS as compared to say, Windows Server 2003. In the case of Azure the version relates to the Windows Azure Guest OS, or the additional Azure specific bits that are loaded on the top of the OS Family when an instance is provisioned by Azure for your code to run on (I’m not 100% sure when this combination is set up, so it may not happen at provisioning time).

You configure this choice in the Service Configuration file as attributes on the ServiceConfiguration element. The choice you make covers ALL of the roles in your service. So, for example, you can’t have one role running on one OS and a second role running on another.

<ServiceConfiguration serviceName="MyAzureService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" 
osFamily="1" osVersion="*">

...
</ServiceConfiguration>

The values for these attributes can be read about in the docs. It’s important to note that the OS Family and Version also have a tie in with what SDK you used to create your service, so make sure to check out the compatibility matrix as well. You must specify a value for the OS Family, but the OS version can be set to * (which is the default). This translates to “I want the newest one”, which means that as new guest OS versions are released your service will be updated. They update this using the same mechanism that you might use if you did a rolling update on your service, meaning they will upgrade each update domain one at a time taking the roles offline, applying the new OS version, redeploying and bringing the instances back online.

Note that if you set the OS Version to * it will do the upgrades for you automagically; however, you will NOT be upgraded to a new OS Family without input from you. You can read more about this process on the MSDN docs. The docs also show how you can update these values directly from the management portal as well.

I wanted to blog about this because, as the docs will tell you the value of * for the guest level OS is a best practice*.*** Quote: “You can specify that Windows Azure should automatically upgrade the guest OS when a new version becomes available. Automatically upgrading the guest OS is a recommended best practice.”

Part of the benefit of the Platform as a Service (PaaS) model of cloud computing is that you no longer are concerned with patches and OS level updates. The service provider makes sure that the correct security patches are applied and that the recommended OS updates are installed. That being said, I’d like to suggest you take a moment to really decide on the behavior you want when you deploy your application and if this automatic update is the right choice for you.

For example, I don’t know too many enterprise shops that have Windows Update turned on for each server in their data center. Most of them have hooks set up to push patches out to the servers after they have been tested to determine if any of them interfere with the operations of the servers and applications the data center supports. Granted, you want to have this testing done quickly, especially with regards to security related patches, but you still want to make sure that you don’t break an application your company depends on by rolling out a patch.

In my opinion having your own data center servers running Windows Update would be similar to setting the OS Version to * in Azure. You are making the choice that the update can happen without your having time to test it out in the staging environment. I’m not saying this is bad, I’m just saying you need to be aware of the choice that is being made.

Taking the approach of updating to the Guest OS Version on your own does remove some of the benefit that PaaS gives you; however, you should weigh that against possible breaking changes that may be caused by an update and how that will affect your business/application. Doing the updates yourself means making sure as new versions come out that you do a full test of your code (hopefully automated as much as possible with tests) against the new OS level in staging, then updating the configuration to do the update in production. This could be done as part of a rollout of new features, or on it’s own. Depending on size of your code or application this can also be very time consuming, hence while the automatic updates sound really nice.

In conclusion, I’d suggest that you think about how you want your upgrade process for OS versions to work. You could choose the automatic route and you may never see an issue at all, or you might get bit once in a while, it really is impossible to predict. It is completely up to you and your needs that will determine the route you need to go, but it is a decision that should be made consciously.

After saying all of this, Microsoft does point out in their docs that they do reserve the right to patch an OS for some security related threats without input from you, or ability for you to opt out. If you think about it this makes sense. If a security hole is found that someone can manipulate and take over the computer I’d want all the servers in my own data center patched immediately, and want the same for my assets in Azure as well.