Azure SDK 1.4 Released

The Azure SDK has been released and is available here

The changes are as follows:

  • Resolved an issue that caused full IIS fail when the web.config file was set to read-only.
  • Resolved an issue that caused full IIS packages to double in size when packaged.
  • Resolved an issue that caused a full IIS web role to recycle when the diagnostics store was full.
  • Resolved an IIS log file permission Issue which caused diagnostics to be unable to transfer IIS logs to Windows Azure storage.
  • Resolved an issue preventing csupload to run on x86 platforms.
  • User errors in the web.config are now more easily diagnosable.
  • Enhancements to improve the stability and robustness of Remote Desktop to Windows Azure Roles.

One of the changes fixes the issue I blogged in CommunicationObjectFaultedException after checking an Azure project in to TFS

What is classed as a Storage transaction for billing purposes in Windows Azure?

The simple answer is that each REST call made to the Azure Storage Service is counted as a single transaction. This means that each time you query your table or check the size of a queue or upload a blob you will call the Azure Storage REST api and it will be classed as a transaction. It also means that if you are doing a full table query and you start to get continuation tokens you will get multiple transactions.

For a fuller description see the following blog post:

Add your own Claims to your ADFS Provider

Following on from my previous blog on “Creating your own identity provider …” The following changes can be made to add in your own claims.

Firstly in the App_DataCustomSecurityTokenService.cs file of your identity provider web site I changed the following code

outputIdentity.Claims.Add( new Claim( System.IdentityModel.Claims.ClaimTypes.Name, principal.Identity.Name ) );
if (principal.Identity.Name.Equals("Steve") == true)
outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "Administrator"));

outputIdentity.Claims.Add(new Claim("http://schemas.BlackMarble/Identity/Claims/Business",
"Black Marble"));

outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "User"));


The first parameter of the Claim constructor needs to be in the format of a namespace and I added this one up as it was an internal name we are using.
The second parameter of the Claim constructor is the value you want to pass through.
Next go to the appfabric portal and add in the following rule to your STS provider. You need to make sure that the schema string you have in your code matches the Input Claim Type you added in your rule.
Now you should be passing through the Business claim to your website. To get access to the claim use the following code:
using System.Threading;
using Microsoft.IdentityModel.Claims;

IClaimsPrincipal principal = (IClaimsPrincipal)Thread.CurrentPrincipal;
var business = "";
foreach (Claim claim in principal.Identities[0].Claims)
if (claim.ClaimType.Equals("http://schemas.BlackMarble/Identity/Claims/Business"))
business = claim.Value;

if (!String.IsNullOrEmpty(business))
// we have a claim value for School so lets display it
BusinessLabel.Text = business;
BusinessLabel.Text = "No business claim found";

Again, note that the claim type namespace is the same as you specified previously.

The following claims are passed through to my website:


Denial of Service and Windows Azure

A question I regularly get asked is whether there is any support in Azure for preventing Denial of Service (DOS) attacks or at least reducing the impact of the DOS attack. In a white paper written by Microsoft called “Security Best Practices For Developing Windows Azure Applications“ in June 2010 the following statement was made:

“Windows Azure’s load balancing will partially mitigate Denial of Service attacks from the Internet and internal networks. This mitigation is done in conjunction with the developer defining an appropriate Service Definition VM instance count scale-out. On the Internet, Windows Azure VMs are only accessible through public Virtual IP Addresses (VIPs). VIP traffic is routed through Windows Azure’s load-balancing infrastructure. Windows Azure monitors and detects internally initiated Denial of Service attacks and removes offending VMs/accounts from the network. As a further protection, the root host OS that controls guest VMs in the cloud is not directly addressable internally by other tenants on the Windows Azure network and the root host OS is not externally addressable.”

The following table shows the types of protection that are available (or planned)


Layer where mitigation is implemented

Nature of mitigation provided

(if specific to Windows Azure)

Application/Service-layer mitigation required

Is this issue higher risk or more complex in cloud deployments?

Denial of Service


Denial of Service attacks via network bandwidth saturation (packet flooding)


Load balancing & throttling in network infrastructure

None Required


Identification of botnets and malicious network traffic


Windows Azure Live Services monitors and investigates

None Required


Deep packet inspection for network attacks with known signatures

Platform (Not yet implemented)


None Required


Flooding of Web Role local storage or blob/table storage


Quotas, ACLs, Reduced privilege execution and flood monitoring protection

None Required


Request flooding at the customer code/app level

Web Role (Needs coding)


Implement application-level request throttling if necessary


My understanding is that there is support within Azure to stop someone from launching DOS attacks within Azure itself. It is difficult to stop a DOS attack on your site but there are things that can be done to minimise their impact. Bandwidth throttling and Load balancing are built in to the platform, but the developer has to code around issues at an application level for example implementing a back off policy when trying to access resources that are affected by DOS.

Windows Azure AppFabric CTP February release now available

Microsoft released on Thursday the latest CTP for Windows Azure AppFabric. Details of the release can be found here, in the AppFabric Team blog and in Wade Wegner’s blog


The CTP contains changes to the Caching service and the AppFabric portal is now in Silverlight. The changes are as follows:

  • New Silverlight-based LABS portal, bringing consistency with the production Windows Azure portal.
  • Ability to select either a 128MB or 256MB cache size.
  • Ability to dynamically upgrade or downgrade your cache size.
  • Improved diagnostics with client side tracing and client request tracking capabilities.
  • Overall performance improvements.

You can access the CTP by signing in to the AppFabric labs at

Retrieving Role Instance Count in Azure From a Different Role

When using the following code from a worker role the trace information shows that there are one worker role instance and zero web role instances

public override void Run()
while (true)
Trace.WriteLine(string.Format("WorkerRole Instances {0}",

Trace.WriteLine(string.Format("WebRole Instances {0}",

This is because an internal endpoint is required on the role in order for the role environment to be able to retrieve the instance count. So add a new end point to the webrole and set it as internal. Running the code again, then shows both roles with 1 instance running.

See the Role.Instances MSDN topic:

Windows Azure Training Kit Update

The Windows Azure Training Kit January update is available at:

The January 2011 update of the training kit includes the following updates:

  • [New demo script] Windows Azure Connect
  • [New demo script] Web and Worker Role Enhancements
  • [New demo script] Windows Azure Virtual Machine Roles
  • [New demo script] Rafiki
  • [New lab] Windows Phone 7 and The Cloud
  • [Improved] Visual Studio code snippets installation
  • [Fixes] Several bug fixes in demos and labs

Migrating an Existing Web Application to Windows Azure

Moving to Windows Azure is not as difficult as you might think. Using a basic MVC 2.0 web application created in Visual Studio 2010, the Azure tools within Visual Studio enable you to migrate the web side really easily.

Load your MVC 2.0 application into Visual Studio and right click on the solution in Solution Explorer and add a new project to this solution.


Select Windows Azure Project and enter a new project name.

When the next dialog appears, do not select any role and press OK.



In the Windows Azure project rigt click on the roles folder and select Add->Web Role Project in solution



Select the MVC project and press OK


You MVC web application should now be ready for deployment to azure. Hit F5 and make sure that the solution builds and runs in development fabric.

For most people this is not the end. There are a number of issues that you may need to resolve for example file access, database access, security and on premise integration. There are solutions for each of these and it depends upon what you are trying to achieve.

With data access, if you are currently using a SQL database and providing the database is not too complicated then it should just port across my running the same SQL scripts on your SQL azure database. You will then just need to change your connection string to point to SQL Azure rather than whatever database you are currently using.  To see the issues the TFS team had converting to the cloud see the PDC video

Information about setting up security using the Access Control Service can be seen in my earlier blog

File access can be done using Azure Drives if there is a lot of file access, but it may be easier to store the file as a single blob or migrate the data you are storing to able storage. I depends upon what you are using the files for.

Connectivity to on premise applications could be done a number of ways by using the service bus or Azure connect. Again it depends on what you are trying to connect to and how “real time” the connection needs to be. I will be putting together a comparison of the methods as soon as I get some free time.

CommunicationObjectFaultedException after checking an Azure project in to TFS

I suddenly started to get a CommunicationObjectFaultedException after I checked my azure code in to TFS


I could get it working by editing the web.config file manually, but it didn’t seem to matter what I actually changed!! It was the act of editing the web.config file that made it writable and it could therefore be written to by the development fabric. When comparing the files it looks like the machine key section is changed. Further investigation pointed me in the direction of the changes made in the Azure SDK 1.3 to support full IIS. During deployment “automatic configuration [of the machine key] occurs at the site-level, overriding any user-supplied value”. When the file is read-only the error occurs. Making the file writable fixes the problem.

The following links explain:

10 March 2011 : Update – Issue now fixed in Azure SDK 1.4. See Azure SDK 1.4 Released