1. New Deployment: For a new deployment, auto-upgrade mode is chosen by default on the portal.

2. Existing Deployment: If you already have a service with a fixed osVersion, you can change the mode to Auto-upgrade on the portal by :

a. Clicking on OS Settings

b. Changing the OS upgrade mode on the OS Settings page

3. Current OS of your deployment

You can easily find out the version of the OS that your service is running on the portal.

NOTE: If your service is not using the latest available OS, you will get a warning about it on the portal, like so:

Today we released the Windows Azure guest OS Auto-upgrade feature to help you keep your service running on the latest operating system available for Windows Azure. The platform automatically upgrades your service to use the latest OS whenever it becomes available without you have to worry about it. This helps you keep your service running on the most secure OS available for Windows Azure with no extra effort.

When you create a new service on Windows Azure and do not specify a particular OS Version to use in your Service Configuration file (.cscfg), your service will be created in auto-upgrade mode. For an existing service you can choose to change mode from Manual to Auto using this new feature set.

This feature is currently available via an attribute in the Service Configuration (.cscfg) file. It will soon be available even more conveniently on the Developer Portal.

What is OS Upgrade?

In Windows Azure, instances of your service run in a Virtual Machine, with an operating system installed on it. The operating system in use today is a customized OS designed for the Windows Azure environment and is substantially compatible with Windows Server 2008 SP2.

We try to keep this OS updated with the latest security fixes released for Microsoft Windows Server OS and that are applicable to Windows Azure Operating System as well. We release an updated version of the Windows Azure OS, roughly on a monthly schedule. The list of OS releases can be found here.

OS upgrade support till now

Up till now, users had the ability to perform an OS Upgrade for their service in a manual mode, by using the osVersion attribute in Service Configuration (.cscfg) file.

1.       New Deployment: When a service is deployed for the first time the user can specify the osVersion attribute in their .cscfg file. E.g.

<?xml version="1.0" encoding="utf-16"?>

<ServiceConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" serviceName="" osVersion="WA-GUEST-OS-1.1_201001-01" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">

…

</ServiceConfiguration>

If nothing is specified, the platform picks the latest OS available at the time of deployment and fixes the services on this OS. E.g. a new service deployed before today with osVersion would be fixed to use version WA-GUEST-OS-1.2_202003-01.

2.       Existing Deployment: To upgrade the OS for an existing deployment, the user will need to perform a configuration update with a new value for the osVersion attribute

When the user requests an OS upgrade, the platform performs a regular In-Place upgrade of the service, by walking the upgrade domains.

The new OS Auto-upgrade feature

With the new feature coming online today, users can set up their service for OS auto-upgrades very simply by using the same Service Configuration (.cscfg) based mechanism.

1.       New Deployment

You can use the configuration file to set the auto-upgrade mode.

<?xml version="1.0" encoding="utf-16"?>

<ServiceConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" serviceName="" osVersion="*" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">

…

</ServiceConfiguration>

If the osVersion attribute is not specified, the service is put into auto-upgrade mode by default.

2.       Existing Deployment: If you already have a service with a fixed osVersion, you can change the mode to Auto-upgrade by updating the configuration for your service with osVersion = “*”.

Service Management APIs

With this new feature, we are also introducing a couple of additions to Service Management APIs

1.       Getting the OS Version for your Service

The GetDeployment API now supports getting the OSVersion of your service.

Given below is the output from CSManage tool to get the version of the OS for my service:

>csmanage /view-deployment /hosted-service:td-tnv1-we   /slot:production

Using certificate: CN=SUMITM2.redmond.corp.microsoft.com

Getting Deployment

Name:7dce3813-eb2c-4101-af21-752e9785d9c2

Label:td-tnv2-we

Url:http://td-tnv1-we.cloudapp.net/

Status:Running

DeploymentSlot:Production

PrivateID:cefbd53a10fa4593891eb671f84c2469

UpgradeDomainCount:1

RoleList contains 2 item(s).

    RoleName: Thumbnails_WorkerRole

    OperatingSystemVersion : WA-GUEST-OS-1.3_201004-01

    RoleName: Thumbnails_WebRole

   OperatingSystemVersion : WA-GUEST-OS-1.3_201004-01

RoleInstanceList contains 2 item(s).

    RoleName: Thumbnails_WorkerRole

    InstanceName: Thumbnails_WorkerRole_IN_0

    InstanceStatus: Ready

    RoleName: Thumbnails_WebRole

    InstanceName: Thumbnails_WebRole_IN_0

    InstanceStatus: Ready

Operation ID: 84cad57a5a1f41b18228226bfef1ad26

HTTP Status Code: OK

StatusDescription: OK

2.       Getting a list of OSs available on Windows Azure.

The APIs support getting a list of guest operating system version available. Here’s the documentation for the API.

Given below is the output from CSManage tool to get the list of OSes using the APIs. The output shows that there are 4 releases of the OS available. All of them are available as choices for the osVersion attribute (IsActive = True). One of these (WA-GUEST-OS-1.3_201004-01) is the latest release available (IsDefault = True).  If the service was on auto-upgrade mode, it would be running on the latest OS release currently.

>csmanage.exe /list-operating-systems

Using certificate: CN=<EDITED>

Listing OperatingSystems

OperatingSystemList contains 4 item(s).

Operating System Version:WA-GUEST-OS-1.0_200912-01

Operating System Label:Windows Azure Guest OS 1.0 (Release 200912-01)

Operating System IsDefault:False

Operating System IsActive:True

Operating System Version:WA-GUEST-OS-1.1_201001-01

Operating System Label:Windows Azure Guest OS 1.1 (Release 201001-01)

Operating System IsDefault:False

Operating System IsActive:True

Operating System Version:WA-GUEST-OS-1.2_201003-01

Operating System Label:Windows Azure Guest OS 1.2 (Release 201003-01)

Operating System IsDefault:False

Operating System IsActive:True

Operating System Version:WA-GUEST-OS-1.3_201004-01

Operating System Label:Windows Azure Guest OS 1.3 (Release 201004-01)

Operating System IsDefault:True

Operating System IsActive:True

Operation ID: 2be9091a155347aab9d57e86f09f82a7

HTTP Status Code: OK

StatusDescription: OK

 And what better time to be at it than today, when Windows Azure announced the general availability for the platform in 21 countries.

 I am also pleased to announce the release the February 2010 (v1.1) release of the Tools and SDK today. This release supports a couple of new features in the platform, namely Windows Azure Drives and OS Versions.

Windows Azure Drive is available in Beta form and the SDK allows you to use it in your simulation environment as well as in the production cloud today. In order to take advantage of Windows Azure Drive in your application, you need to choose the right version of the Guest Operating System for your application. This SDK now allows you to specify the OS Version as an attribute in your .cscfg file.

You can find more information on the supported Guest OS versions in the Windows Azure Guest OS Versions and SDK Compatibility Matrix.  

Happy developing!

In this post we will create a new Cloud Service project using and look at the wiring that is done automatically to make Windows Azure Diagnostics, and specifically simple logging, work.  

Simple Logging in a new Cloud Service project

1.       Open Visual Studio as Administrator

2.       Click on File | New | Project…

3.       Select Visual C# | Cloud Service | Windows Azure Cloud Service

4.       In the ‘New Cloud Service Project’ wizard select ‘ASP.Net Web Role’ and ‘Worker Role’ and click OK.

5.       In Solution Explorer, expand the References in WebRole1. A reference  to Microsoft.WindowsAzure.Diagnostics.dll has been added. This is the dll that exposes the diagnostics configuration and management APIs.

6.       Open WebRole.cs in WebRole1 project.

7.       A new using statement that has been added to this file

        This brings in the Windows Azure Diagnostics name space into the role.

8.       Going further down in WebRole.cs, the following line of code is found in WebRole.OnStart() method.

This line of code starts up the Diagnostic Monitor, mentioned in my earlier post. This is the component that runs along with the role and is responsible for the collection of diagnostic data on the node.

This line of code passes in the configuration setting name that is equal to the connection string for the storage account that Diagnostic Monitor needs to use to transfer the diagnostic data to.

NOTE: The configuration setting name can be any name that define in the *.cscfg file.

9.       Open up ServiceDefinition.cscfg to see what the connection string looks like.

The default VS template sets up the connection string name as ‘DiagnosticsConnectionString’ and the value as ‘UseDevelopmentStorage=true’. This particular connection string sets up Diagnostics Monitor to use Development Storage account. 

The connection string can be changed to point to a cloud storage account as well as shown below

   <ConfigurationSettings>

          <Setting name="DiagnosticsConnectionString"    

             value="DefaultEndpointsProtocol=https;AccountName=<ACCOUNT_NAME>;AccountKey=<ACCOUNT_KEY>"/>

       </ConfigurationSettings>

10.   Step 5-9 are applicable for the worker role in the project as well.

11.   Open Web.config in the Web Role project. The following following section has been added to web.config

This adds the Diagnostic Monitor Trace Listener to the role such that Trace() calls made in the application are collected by Diagnostic Monitor as well.

NOTE: The same section is added to the worker role’s app.config.

12.   With Steps 5-11 all the wiring needed to generate and collect simple logs  with Trace() APIs is done. In the current project, some sample TraceLine() calls that have already been added.

13.   To illustrate the transfer of logs add the following lines in WebRole.cs file.  We will delve deeper into the transfer mechanism in a subsequent post.

 For now it is sufficient to know that this code sets up the configuration of simple logs such that they are automatically transferred every minute to the storage account that was configured in Step 9.

a.       Add the following ‘using’ statements

b.      Add the following lines to OnStart() method

          public override bool OnStart()

          {

              //DiagnosticMonitor.Start("DiagnosticsConnectionString");

              DiagnosticMonitorConfiguration dmc =          DiagnosticMonitor.GetDefaultInitialConfiguration();

              dmc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);

              dmc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

              DiagnosticMonitor.Start("DiagnosticsConnectionString", dmc);

          }

c.       Add the following method to the WebRole class

           public override void Run()

           {

              int count = 0;

              for (; ; )

              {

                 count++;

                 Trace.WriteLine("Message: " + count, "Information");

                 Thread.Sleep(TimeSpan.FromSeconds(10));

              }

           }

14.   Hit F5 to start debugging the project. The logs from the WebRole are shown in Development Fabric.

15.   To see the collection of these logs in the storage account (Development Storage in this example), lets open up the account in a storage viewer tool. For this example we will use the Cloud Storage Studio tool from Cerebrata.

What’s next

We have looked at all wiring that has already been done to integrate Windows Azure Diagnostics in a cloud service project. We have also looked at how simple Windows Azure logs work. Next time we will explore more types of diagnostics data  can be collected for the service, e.g. Performance Counters, Failed Request Logs, etc.

Today I wanted to talk about the new Windows Azure Diagnostic feature that we have introduced with the SDK.

Starting with PDC08 we provided a basic logging system which consisted of the following:

• RoleManager.WriteToLog() API that let you perform simple logging in your service, and
• ‘Copy Logs’ button the Windows Azure Developer Portal that enabled you to transfer all those logs from the instances of your service into your Windows Azure storage account.

Why something new?

There are a number of diagnostic scenarios that go beyond simple logging. Over the past year we received a lot of feedback from customers regarding this as well. We designed Windows Azure Diagnostics to address some of those scenarios, e.g.

• Detecting and troubleshooting problems
• Performance measurement
• Analytics and QoS
• Capacity planning
• And more…

Based on the feedback we received we wanted to keep the simplicity of the initial logging API but enhance the feature to give users more diagnostic data about their service and to give users more control of their diagnostic data. The November 2009 marks our initial release of the Diagnostics feature.

What’s new?

Let me first talk a little about what is available as part of this new feature.

• Perform simple logging using the standard System.Diagnostics.Trace APIs
• Collect the following types of diagnostics data
  • IIS Logs
  • Failed Request Logs
  • Performance Counters
  • Windows Event Logs
  • Application crash dumps
• APIs to configure the collection of data
• Transfer the collected data from your service to your storage account on an On Demand or a scheduled basis.

What is the architecture?

The Diagnostic feature is architected to be decoupled from the Windows Azure platform to enable users to have control over the diagnostic data that they need for their service, without the platform adding any more layers in between.

The following schematic gives a general idea of how the Diagnostic feature is architected.

The gist of the diagram above is: Diagnostics Monitor (the small blue boxes in the role instances above) running as part of each instance of each role of the service collects diagnostics data as configured by the user and persists it in the user’s Windows Azure Storage account, as configured by the user, on an on-demand basis or at a regular scheduled interval.

Full Trust

The implementation of Windows Azure Diagnostics feature requires the roles to be run in full trust. In other words enableNativeCodeExecution attribute needs to be true for your roles in ServiceDefinition.csdef. With the November 2009 release of Windows Azure Tools and SDK, default value for this attribute is true .

Diagnostic Configuration

Configuration tells the diagnostics infrastructure which particular data types is the user interested in collecting. Once a data type is enabled, the infrastructure starts collecting the data locally on the VM of any given instance. On the desktop it is collected on the local disk.

This configuration can be defined in 2 ways:

• Role Startup: The user can define what she needs to collect for a particular role at role start up time.
• After startup: The user can modify the configuration of the running service by using Diagnostic Management API from outside the cloud (e.g. through a client side tool on the user’s desktop). This can be done without bringing the service down.

How do I use this?

Now that we have gone over the feature broadly, it’s time to write some code. I will go over the APIs and tools available for developers to leverage this feature in their code in the next post. For now, I need to do my rounds at PDC :).