AzureFest: Open Source Presentation

Undoubtedly by now you have heard of AzureFest, with any luck you have been out to one of the events [if you live in the GTA]. For the rest of you, that haven’t been able to experience the event, I wanted to take the opportunity to introduce you to what AzureFest is and why you might be interested in the event itself.

Windows Azure Data Center Locations

What is AzureFest?

At it’s core AzureFest is a talk that focuses on a few barriers to Windows Azure Adoption including Pricing, Registration, Platform Confusion and Coding/Deployment. This is not your Grandma’s Windows Azure Presentation, It includes both a lecture and a hands on component which is rare for a Community Event.

Why Talk Pricing?

Simple, pricing is the first question that I get asked at the end of every presentation that I’ve done to date, so why not talk about it first?  Pricing goes hand-in-hand with the Platform, which means not only do you get to understand what the Windows Azure Platform consists of, but you also get an understanding of what it will cost as well. Finally, It would be rather irresponsible not to talk about the costs of Windows Azure when the first Hands-on-Lab is a walkthrough of the registration process.

What Will I Learn?

Besides the Overview of the Platform and the Pricing Strategies, each attendee who participates in the Labs will learn:

  • How to Register for a Windows Azure Platform Subscription
  • How to Create, Manage, Configure and Leverage a SQL Azure Database
  • How to Create and Configure a Windows Azure Storage Service Account
  • How to Create & Deploy a Project to Windows Azure Compute

Attendees will also learn some of the gotcha’s around the Tool Installation/Configuration Process and some strategies on how to debug your cloud based solutions both on premise [using the Compute Emulator] and “In The Cloud”.

Windows Azure CDN Locations

Bonus… We’re giving it away!

In the spirit of growing adoption of the Windows Azure Platform within Canada [or any country for that matter], ObjectSharp is releasing the content as an Open Source Presentation. This means it is FREE for anyone to download, learn and/or deliver.

If you are interested in doing an AzureFest presentation in your area, download the Resources for AzureFest. The resources include:

  • An AzureFest Slide Deck
  • Hands-on-Lab Kit [Ready to deploy cspkg and cscfg files]
  • Modified NerdDinner Source Code for Hands-on-Lab

If you have specific questions about delivering an AzureFest presentation, or need clarification on the content, please direct your questions to me via twitter.

Windows Azure Role Startup Life Cycle

As you begin to deploy applications to Windows Azure you may find that the application being deployed needs more functionality than is provided on the Windows Azure Guest OS Base Image [Read: How to Change the Guest OS on Windows Azure]. This is possible to do as of Windows Azure SDK 1.3, this is called a Startup Task, also introduced with SDK 1.3 was the concept of Full IIS Support which now takes priority over the legacy [but still functional] Hosted Web Core Deployment Model [Read: New Full IIS Capabilities: Differences from Hosted Web Core].

Much like an ASP.NET Web Forms Developer Learns the ASP.NET Page Life Cycle, it’s important for a Developer that is building applications for Windows Azure to know the Role Startup Life Cycle when they are deciding between creating Startup scripts and leveraging the Windows Azure VM Role.

Windows Azure Role Startup Players

There are a few players in the Role Startup process on Windows Azure [SDK 1.3]. Please note that I am only calling out the players in the Full IIS Support Process [This is not Hosted Web Core].

Startup Tasks

In Windows Azure a startup task is a Command-Line Executable file that gets referenced in the Cloud Service Definition file (.csdef). When a deployment is uploaded to Windows Azure a component of the Windows Azure Platform called the Fabric Controller reads the Definition file to allocate the necessary resources for your Deployment. Once the environment is set up the Fabric Controller initializes the Role Startup Process.

To best understand startup tasks lets dive into the “Task” Element of the Cloud Service Definition file.

<ServiceDefinition name="MyService" xmlns="">
   <WebRole name="WebRole1">
         <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple">

CommandLine Attribute

This is the name of the file to be executed when the startup task runs. How this script or executable process is run in the role is left up to the executionContext and the taskType.

ExecutionContext Attribute

The executionContext for a startup task defines the level of permissions that the script or executable file is able to run at within a particular role. There are two types of Execution Contexts:

  1. Limited: Runs the script/executable at the same permission level of the role runs at.
  2. Elevated: Runs the script/executable with Administrative privileges.

TaskType Attribute

The taskType for a startup task defines how a startup task process is executed. The TaskType is a key contributor to the length of your startup process. The reasoning behind this is the different task types execute either Synchronously or Asynchronously. Obviously the Synchronous task execution will take longer to execute so be cautious of the length of your installations as startup tasks should not execute any longer than 5 minutes. Here are the three different types of Startup tasks:

  • Simple (Default): (Synchronous) The Task is launched and the Instance is Blocked until the task completes. [Note: If the task fails, the instance is blocked and will fail to start]
  • Background: (Asynchronous) This starts the Task process and continues the Role startup. [Note: Fire and Forget. Be sure to Log these processes for debugging]
  • Foreground: (Asynchronous) The task is executed but doesn’t allow the Role to shutdown until the foreground tasks exit.


The IISConfigurator process is an executable file that you’ll find in both the Compute Emulator as well as the Windows Azure Environment in the Cloud. IISConfigurator.exe is responsible for iterating through the Sites Node to add and configure the necessary Websites [, Virtual Directories & Applications], Ports and Host Headers within IIS. I wrote a post previously that talked about IISConfigurator.exe in the context of the Compute Emulator.

[Web/Worker]Role.cs : RoleEntryPoint

Within a Web or Worker Role you will find a class that inherits from RoleEntryPoint. RoleEntryPoint exposes 3 events OnStart, Run and OnStop, these methods are used to perform tasks over the lifecycle of the Role. I will explain these events in more detail later on in this post.

Windows Azure Startup Life Cycle

Let’s take a look at the Process that Windows Azure takes when it’s deploying our Hosted Service.

The Entire process is kicked off when you upload your Cloud Service Package and Cloud Service Configuration to Windows Azure. [It is a good practice to upload your deployments into Blob Storage in order to Deploy your applications. This allows you keep versions of your Deployments and keep copies on hand incase the Hosted Service needs to be rolled back to a previous version].

Next the Fabric Controller goes to work searching out the necessary Hardware for your Application as described in the Cloud Service Definition. Once the Fabric Controller has found and allocated the necessary resources for your Hosted Service, the appropriate Guest OS Image is deployed to the Server and initializes the Guest OS Boot Process.

Flow Chart: Windows Azure Startup Life Cycle

This is where things begin to get interesting.

If the current Role contains a Startup node in the Cloud Service Definition the Role begins executing each Task in the same Sequence in which they are ordered in your Cloud Service Definition. Depending on the TaskType [explained above] these startup tasks may run Synchronously [simple] or Asynchronously [background, foreground].

When the ‘Simple’ [Synchronous] startup tasks complete execution the role begins its next phase of the Role Startup Life Cycle. In this phase of the Life Cycle the IISConfigurator Process is executed Asynchronously, at the same time [or not too long after] the OnStart event is fired.

Once the OnStart event Completes, the Role should be in the Ready State and will begin accepting requests from the Load Balancer. At this point the Run event is fired. Even though the Run event isn’t present in the WebRole.cs code template you are able to override the event and provide some tasks to be executed. The Run event is most used in a worker role which is implemented as an infinite loop with a  periodic call to Thread.Sleep if there is no work to be done.

After a long period of servicing requests there will most likely come a time when the role will be recycled, or may no longer be needed and shut down. This will fire the OnStop event, to handle any Role clean up that may be required such as moving Diagnostics data or persisting files from the scratch disk to Blob Storage. Be aware that the OnStop method does have a time restriction, so it is wise to periodically transfer critical data while your role is still healthy and not attempting to shut down.

After the OnStop Event has exited [either code execution completes, or times out] the Role begins the stopping process and terminates the Job Object. Once the Job Object is terminated the role is restarted and once again follows the process explained above of the Startup Life Cycle. This is important to know as it is possible for your Startup Tasks to be executed multiple times on the same Role, for this reason it is important that your startup tasks be Idempotent.

Issues that may Arise during the Startup Life Cycle

As Software Developers we are all aware of what some call the “Happy Path” this is a term that is used to describe a process that goes exactly as planned. However, in the real world, no process is iron clad and we need to be aware of situations that may go awry.

Here is a quick list of potential issues during the Startup Life Cycle:

  • Startup Tasks may fail to Execute
  • Startup Tasks may never Complete
  • IISConfigurator.exe may overwrite Startup Task based modifications to IIS
  • IISConfigurator.exe and OnStart might end up in a race condition
  • Startup Tasks and OnStart may end up in a race condition
  • Startup Process might not be idempotent

How to Avoid Race Conditions in Role Startup

There are a number of things you can do to help avoid Race Conditions within your startup Process. This is typically done by placing checks and balances around the resources that will be affected by the specific item in the startup process. The other thing that could be done is to create a VM Role.

The VM Role is a Windows Server 2008 R2 Image on a VHD which you configure with all the components you need installed on your Role. You will also need to install the Windows Azure Integration Components and perform a generalization with sysprep.

The VM Role is a good approach if:

  1. Your startup tasks are starting to effect your deployment time
  2. Application installations are Error-prone
  3. Application installation requires manual interaction.

I will cover more on the VM Role in other blog post, as it’s a large enough topic on it’s own.

Once you have configured your VM Role instance it is uploaded to the cloud by using the csupload command-line tool, or using the Cloud Tools in Visual Studio. This new VM Role image you created can now be Provisioned in place of one of Microsoft’s Guest OS Images. It is good to note that startup tasks are not supported in the VM Role as it is assumed the image is uploaded as required.


Knowing the Life Cycle of what you’re working on is very important. It’s that one piece of context that you can always come back to in order to regain a little more clarity in a situation.

Happy Clouding!

Special Thanks to: Steve Marx, David Murray, Daniel Wang, Terri Schmidt, Adam Sampson & [my failover twin] Corey Sanders [from the Windows Azure Team] for taking the time out of their busy schedules to ensure this information is both accurate and complete.

[Update: May 31, 2011]

Kevin Williamson, an Engineer on the Windows Azure Cloud Engineering Team, has posted some additional guidance on the Architecture of a Windows Azure Role. This Guidance is quite detailed an may provide you with some more in-depth information on the different components of a Windows Azure Role.


Cloud Aware Configuration Settings


This code has been updated to be more Fluent in it’s Construction.


In this post we will look at how to write a piece of code that will allow your Application to be Environment aware and change where it receives it’s connection string when hosted on Windows Azure.

Are you looking to get started with Windows Azure? If so, you may want to read the post “Get your very own Cloud Playground” to find out about a special offer on Windows Azure Deployments.

State of Configuration

In a typical ASP.NET application the obvious location to store a connectionString is the Web.config file. However when you deploy to Windows Azure the web.config gets packed within the cspkg File and is unavailable for configuration changes without redeploying your application.

Windows Azure does supply an accessible configuration file to store configuration settings such as a connectionString. This file is the cscfg file and is required to upload a Service to Windows Azure. The cscfg file is definitely where you will want to place the majority of your configuration settings that need to be modified over the lifetime of your application.

I know you’re probably asking yourself, what if I want to architect my application to work both On-Premise and in the Cloud on one Codebase? Surprisingly, this is possible and I will focus on a technique to allow a Cloud focused application to be deployed on a Shared Hosting or On-Premise Server without the need to make a number of Code Changes.

Obviously this solution does fit within a limited scope, and you may also want to consider architecting your solution for cost as well as portability. When building a solution on Windows Azure, look into leveraging the Storage Services as part of a more cost effective solution.

Cloud Aware Database Connection String

One of the most common Configuration Settings you would like to be “Cloud-Aware” is your Database Connection String. This is easily accomplished in your application code by making a class that can resolve your connection string based on where the code is Deployed.

How do we know where the code is deployed you ask? That’s rather simple, Windows Azure Provides a static RoleEnvironment Class which exposes a Property IsAvailable which only returns true if the Application is running in either Windows Azure itself or the Windows Azure Compute Emulator.

Here is a code snippet that will give you a rather good idea:

Let’s take a moment to step through this code to get a better understanding of what the class is doing.

As you can see the class is declared as static and exposes one static property, this property will either grab the Configuration Setting that is required for the particular environment the Application is Deployed on.

If the connectionString variable has not been previously set a conditional statement is evaluated on the RoleEnvironment.IsAvailable Property. If the condition is found to be true the value of connectionString is retrieve from the CSCFG file by calling a static method of the RoleEnvironment class GetConfigurationSettingValue this searches through the Cloud Service Configuration file for a Value on a Setting with the Name “ApplicationData”.

If the RoleEnvironment.IsAvaliable Property evaluates false, the application is not hosted in the Cloud and the ConnectionString will be collected from the web.config file by using the System.Configuration.ConfigurationManager class.

The same technique can be used to resolve AppSettings by accessing the AppSettings NameValueCollection from the ConfigurationManager class.

Beyond The Basics

There are a few other things you may come across when creating your Cloud Aware application.

Providers, Providers, Providers

ASP.NET also contains a powerful Provider model which is responsible for such things as Membership (Users, Roles, Profiles). Typically these settings are configured using string look-ups that are done within the web.config file. This is problematic because we don’t have the ability to change the web.config without a redeployment of our Application.

It is possible to use the RoleEntryPoint OnStart method to execute some code to programmatically re-configure the Web.config, but that can be both a lengthy process as well as a very error  prone way to set your configuration settings.

To handle these scenarios you will want to create a custom provider and provide a few [well documented] configuration settings within your Cloud Service Configuration file that are used by Convention.

One thing to note when using providers is you are able to register multiple providers, however you can only provide so much information in the web.config file. In order to make your application cloud aware you will need to wrap the use of the provider objects in your code with a check for RoleEnvironment.IsAvailable so you can substitute the proper provider for the current deployment.

Something to Consider

Up until now we’ve been trying to [or more accurately managed to] avoid the need to recompile our project to deploy to the Cloud. It is possible to package your Application into a Cloud Service Package without the need to recompile, however if you’re building your solution in Visual Studio there is a good chance the Application will get re-compiled before it is Packaged for a Cloud Deployment.

With this knowledge under your belt it enables a unique opportunity for you to remove a large amount of conditional logic that needs to be executed at runtime by handing that logic off to the compiler.

Preprocessor Directives are a handy feature that don’t get leveraged very often but are a very useful tool. You can create a Cloud Deployment Build Configuration which supplies a “Cloud” Compilation Symbol. Leveraging Preprocessor Conditional logic with this Compilation Symbol to wrap your logic that switches configuration values, or Providers in your application can reduce the amount of code that is executed when serving the application to a user as only the appropriate code will be compiled to the DLL. To Learn more about Preprocessor Directives see the first Programming Article I had written.


With a little bit of planning and understanding the application you are going to be building some decisions can be made really early to plan for an eventual cloud deployment of an application without the need for an abundance of code being written during the regular development cycle nor is there a need to re-write a large portion of your application if you would like to build the functionality in once the Application is ready for Cloud Deployment. With this said there are still obvious improvements to be gained by leveraging the Cloud Platform to it’s full Potential. Windows Azure has a solid SDK which is constantly and consistently iterated on to provide developers with a rich development API.

If you want to leverage more of Windows Azure’s offerings it is a good idea to create a wrapper around Microsoft’s SDK so you will be able to create a pluggable architecture for your application to allow for maximum portability from On-Premise to the Cloud and ultimately between different cloud providers.

Happy Clouding!

Cloud Cover Show Visit

While I was at MVP Summit 2011, I was invited to join Steve Marx and Wade Wegner on my favourite Channel 9 Program – Cloud Cover Show. The show featured Corey Sanders from the Windows Azure Fabric Controller Team, he talks about his role in the Windows Azure VMRole.

It was great to be able to provide the tip of the week, which I chose to highlight Microsoft Research Project – [Windows] Azure Throughput Analyzer.

The [Windows] Azure Throughput Analyzer is a tool that can be used to test the performance of transactions to Windows Azure Storage Services from your On-Premise Application.

Enjoy the Show…

Do you want to Develop on Windows Azure without a Credit Card?
The Cloud Cover Show now gives you the ability to do so, head over
to Windows Azure Pass and use the promo-code: cloudcover

Installing PHP on Windows Azure leveraging Full IIS Support: Part 3

Update: The Windows Azure PowerShell CmdLets have added the necessary bootstrap information in order to set up PHP on Windows Azure Cloud Services. Download the Windows Azure PowerShell CmdLets.

In my last two posts in this series [Part 1, Part 2] we have created a Start-up script to install PHP on our Windows Azure Web Role, we have created the necessary Cloud Service Definition and Cloud Service Configuration files.

In this post we’ll look at how to use the command-line tools for Windows Azure to Package our Deployment and how to deploy that package to the Windows Azure Platform Portal.

Packaging a Windows Azure PHP Deployment

I know what you’re thinking “Hold up, we need to package our deployment? What ever happened to good old FTP?”

FTP works great for a single point of access, but we’re looking to be able to rapidly deploy our application across many servers in a matter of minutes. Microsoft uses these packages for just that purpose, rapid deployment.

What is the Cloud Service Package (.cspkg)

The Cloud Service Package is essentially a Compressed file which holds your application, the Cloud Service Definition and a number of other files required by Windows Azure. These files are encrypted by the tool incase the package is intercepted when being transported over HTTP.

You are able to leave the cspkg unencrypted using one of two methods. I would suggest using the Environment Variable [setting _CSPACK_FORCE_NOENCRYPT_ to true], mostly due to the fact that there is a good chance you won’t be using MS Build for your PHP Application.

Setting an Application Variable

Open the Control Panel. Find and Click on System.

set environment variables

Click on the Advanced System Settings link in the Right hand Menu. This will open the System Properties Dialog.


Click on Environment Variables…


Then on New…


Creating a Build Script to Automate Deployment Packaging

As a developer, it is a good idea to optimize repetitive tasks in order to be more productive. One of these optimization points that you should be looking at is Build Automation. With PHP being a Scripting Language and does not need to be compiled this is a very simple thing to accomplish. Here is how simple your “Build Script” can be.

cspack ServiceDefinition.csdef

In our previous post we added the Windows Azure Command-Line Tool Path to our System Path. This enables the above script to execute the tools and create the Cloud Service Package.

To make your build script more powerful, you could add some additional functionality like executing a powershell script which leverages the Windows Azure Powershell CommandLets to deploy your latest Build to your Staging Environment in Windows Azure.

Deploying your Service Package to Windows Azure

There are many different means to getting your Windows Azure Project in to the Cloud. Once you’ve had a chance to evaluate the different methods I would suggest using the method that you find most suitable for you.

Here is a list of different methods of Deploying to Windows Azure:

Note: Barry Gervin and I have put together a video on how to deploy using the Windows Azure Platform Portal.

  • Deploying using Visual Studio

Test Startup Scripts Locally using RDP

As developers we all know that testing will always win out over trial and error, this is no different when creating a startup script for Windows Azure. Be sure to save yourself from pulling out your hair by testing you’re the executable files that will be called by your start-up tasks by RDPing into a Compute Instance.

I’ve created a few blog posts that will aid you in setting up RDP into Windows Azure:

Note: Installers that have a “Quiet Install” option (/q) in their command-line switches, are your absolute best friend. Otherwise, trying to mimic a users acceptance to a Eula or other dialog is rather difficult. WebPI allows us to accept a Eula with a switch (/AcceptEula)

The Ultimate Windows Azure Development VM

As a Software Developer we have many options when it comes to the tools that we put in our tool belt. One thing that I’ve found exceptionally useful over the years are Virtual Machines, not only Virtual Machines, but having a tailored environment to what you’re Developing.

With my focus on the Cloud I thought it would be useful to continue the trend of Building out a Virtualized Environment that’s Tailored to my work that I’m doing in the Windows Azure Platform. I’ve compiled a list of the Tools and SDKs in which I have found the most useful while working on projects for Windows Azure.

Operating System

  • Windows 7 [SP1]
  • Windows Server 2008 R2 [SP1]

Note: Windows Server 2008 R2 is a Handy OS to have on a Virtual Machine within your environment if you expect to have to use the VM Role in Windows Azure.

Desktop Backgrounds

Windows Add-Ons

Development Environment




Assessment & Optimization

Management & Debugging



Code Samples