Configure Settings for the Windows Azure Guest OS
Updated: December 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 different Guest OS families which are substantially compatible with major releases of Windows Server. Guest OS updates do not apply to VMRole and Windows Azure Virtual Machines because those features use VHD images that contain the actual operating systems.
The 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 MSRC patches provided by the Microsoft Security Bulletin. For a listing of the current supported Guest OS families see the Future, Current and Transitional Guest OS Versions
The Guest OS has two update settings:
Automatic - Windows Azure automatically updates the Guest OS when a new release of the same family becomes available. This is the default behavior, and the recommended method. However, Windows Azure does NOT automatically update one family to a later family. See Guest OS Family, Version and Release Explanation to understand the difference between versions and families.
Manual – You can manually choose a Guest OS version. Be aware that older Guest OS versions are retired thus forcing you to update your Guest OS. Refer to Windows Azure Guest OS Releases and SDK Compatibility Matrix for more information on the retirement policy and the state of various Guest OS families and versions.
The following topics describe how to configure Guest OS update settings:
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.