Azure Guest OS Family 1 End of Life: June 2014

Customers with deployed application assets running in Windows Azure are actually running on an automatically provisioned VM under the covers that we patch and maintain if the customer doesn’t opt out.  The version of this underlying OS is referred to as the 'Guest OS Family' as it’s largely abstracted from an application’s deployment since its automatically provisioned and maintained by us behind the scenes.

OS Family 1 is associated with Windows Server 2008 SP2, Family 2 is Windows Server 2008 R2 SP1, OS Family 3 is Windows Server 2012, and OS Family 4 is Windows Server 2012 R2 – additional details are available on our Guest OS Matrix page.  Our support lifecycle policy states that we support, at a minimum, the last 2 OS Families.

Many customers I’ve spoken to are not aware that they have some responsibility with Azure Platform as a Service (PaaS) applications to ensure they maintain an environment that contains the latest operating system security patches and that is commercially supported.   When applications are built in Visual Studio, they are built against a specific version of the Azure SDK (latest versions available here) – which has an association with the OS Family the application will ultimately support being deployed into.  Details of the OS Families and the supported SDKs are below:

Once a selection has been made for the application, some decisions need to be made on how to maintain an update-to-date operating system hosting the deployment.  A couple of options available are outlined in this blog, officially on MSDN and summarized below.

1.   Specifying a specific OS Version and Family in the application’s service configuration file (.csdef) prior to deployment

• • Pros:
    • Provides direct control over the version of the underlying OS provisioned to host your application
    • Useful if your application has a specific binary compatibility requirement with a component of the Azure SDK or is perhaps using a 3rd party component that is supported by a specific version of Windows
  • Cons:
    • Requires thoughtful monitoring of Guest OS versions and family updates – The RSS Feed would be a good place to start
    • Monitoring Guest OS versions may defeat some of the benefits of using PaaS in the first place – creating an administrative burden to maintain the solution
    • If the underlying OS version (patch level) is not manually updated within the 60 day grace period, the application will be forcibly moved to the latest patch level to ensure the application is running on the most secure version (Family) of OS as discussed in this FAQ.

2. Specifying a specific OS Family (pinning to a version of the Windows OS) and allowing updates to be deployed automatically in the .csdef by specifying an OS version of “*”  This would be a preferred configuration to minimize

 <?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="IOTCloud" xmlns="https://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" 

 osFamily="4" osVersion="*" schemaVersion="2013-10.2.2">

• • Pros:
    • Provides direct control over the version of the underlying OS provisioned to host your application
    • Ensures your application is always running with the latest guest OS version (patch level) without any user/administrative intervention

• • Cons:
    • If your application is running with components having dependencies on the underlying OS; some security patches may impact the behavior of the operating system and require testing/validation. 
    • You are still required to ensure your application is running on a supported Guest OS Family and monitoring the End of Life (EOL) dates shown on the OS Support matrix.

So, with this explanation, the next question is how to determine whether or not your deployed solution is pined to a specific version and to determine what SDK is being leveraged by deployments in your Azure subscriptions.  One option is to leverage the Azure REST APIs for service management to extract details for each deployment. 

My preferred method is to use PowerShell!  The script below (you can download here) will walk through all of the subscriptions and deployments in associated with a given organizational or user account:

foreach($subscription in Get-AzureSubscription) {

    Select-AzureSubscription -SubscriptionName $subscription.SubscriptionName

    $deployments=get-azureService | get-azureDeployment -ErrorAction Ignore | where {$_.SdkVersion -NE ""}

    $deployments | ft @{Name="SubscriptionName";Expression={$subscription.SubscriptionName}},

        ServiceName, SdkVersion, Slot,

        @{Name="osFamily";Expression={(select-xml -content $_.configuration -xpath "/ns:ServiceConfiguration/@osFamily" -namespace $namespace).node.value }},

        osVersion, Status, URL

}

Understanding the output

The script above will emit tabular details on each of your subscriptions as shown in the following image:

Details on the important fields are provided below:

• SDKVersion:
  • This is the detected version of the Azure SDK your application is using – important as older SDKs may not be supported with later Guest OS Families
• Slot:
  • PaaS Applications can have either a production or staging slot – each could have different versions of the OS or SDK referenced.
• OSFamily:
  • If specified, the version will appear hear.  If unspecified, the OS Family will be select based on the SDK version referenced in code.  (In my case, SDK 2.2 can only run on OS Family 4; and is the version of the OS provisioned under the covers.)  The default OSFamily was previously 1 if unspecified.
• OSVersion:
  • This is where you can see if your deployments are ‘pinned’ to a specific version of the OS Family.  If anything other than “*” appears hear, you would have manually maintain the version and ensure that the deployment is running on one of the latest 2 versions.

Action to take

Should you have any instances running anything less than SDK version 1.3; your deployment is likely running on an OS Family 1 instance.  You should be receiving e-mails if you have a deployment in this state sent to the service administrator of the Azure subscription in addition to seeing a banner in the Azure portal instructing you to take action prior to June 1st.