Configure Settings for the Windows Azure Guest OS
Updated: April 4, 2013
The Windows Azure guest operating system (Guest OS) is the operating system that runs on the virtual machine (VM) that hosts a web role or worker role instance in Windows Azure. Windows Azure supports three Guest OS families.
The 3.x versions are substantially compatible with Windows Server 2012.
The 2.X versions are substantially compatible with Windows Server 2008 R2 or R2 SP1.
The 1.X versions are substantially compatible with Windows Server 2008 SP2.
The Windows Azure Guest OS is updated at periodic intervals, with the goal of resolving known security vulnerabilities and providing the most up-to-date runtime environment for Windows Azure. The releases include the patches provided by the Microsoft Security Bulletin.
Two options are available for updating the Guest OS:
Configure the service for automatic Guest OS update - With this option, Windows Azure automatically updates your virtual machines running worker and web roles when a new Guest OS release of the same family becomes available. This is the default behavior, and the recommended method.
Note Automatic updating from one Windows Azure Guest OS family to another is not supported. Guest OS updates do not apply to VMRole and Windows Azure Virtual Machines because each uses VHD images that contain custom operating systems.
Manually update the Guest OS – You can manually choose the Guest OS version running in your VM. You should be aware that older Guest OS versions will be deprecated in the future thus forcing you to update at a later time. Refer to Windows Azure Guest OS Releases and SDK Compatibility Matrix for more information.
The following how-to topics describe how to update the Guest OS:
Both automatic and manual Guest OS updates occur as an in-place update. This means that your service's VMs (each of which corresponds to a single role instance) are updated one update domain at time. An update domain is a virtual grouping of VMs for the purpose of minimizing the impact to your service during an update. When an update begins, the role instances within the first update domain are taken offline, the OS updated, and role restarted. The update then proceeds to the next update domain.