We are all aware of the lag between the evolution of the Windows Server platform and the System Center suite. It always takes some time from when a new feature in Windows Server is released, before it is supported in the System Center products. Now, it seems, this applies to Windows Azure as well. Consider the following…

Recently I did a Windows Azure project for a customer which included the introduction of System Center App Controller 2012 SP1 in their environment. They were already using System Center Virtual Machine Manager 2012 SP1 to manage their Hyper-V hosts. We specifically wanted to use App Controller to be able to easily migrate VMs from on-premise Hyper-V into Windows Azure IaaS.

To add an Azure subscription to App Controller you need access to the subscription ID (obtained from the Azure portal e.g.) and a management certificate in PFX format, i.e. you need access to both the private and public keys of the certificate. This certificate needs to already be registered in the subscription. I my case adding the two subscriptions the customer used presented no problems. However, when I came back a few weeks later more instances had been created in the subscriptions and now we had the following error in App Controller under the Public Clouds heading:

* Service unavailable

The first I checked was the status of the App Controller Windows Azure Provider (cmazure) service. This Windows service is responsible for communicating with the Windows Azure platform through the REST API. On my server the service was not running. I started the service and refreshed App Controller, but got the same error. Checking the service status again I found that it had crashed!

The first remedy I tried was updating the App Controller installation with the System Center Service Pack 1 Update Rollup 2 (KB2802159). That did not prevent the cmazure service from crashing but now I had a new error in the App Controller console:

* Requested value ‘A6’ was not found.

A6 and A7 are the IDs of the new HighMemory SKUs introduced in Windows Azure back in April 2013. They are higher memory variants of the Large and Extra Large SKUs respectively. My next move was to check if App Controller knew about these newer SKUs. But first I had to determine if one of my subscriptions in Windows Azure were in fact using any A6 or A7 instances, and if so, remove that subscription. To do this I logged on to the portal, and it was indeed the case. One of the subscriptions had two A6 machines.

I deleted that subscription from App Controller so that I could test my theory that the reason for the error was that App Controller did not know about A6 and A7. Here is a screenshot of deploying a new VM to Azure from App Controller:

As you can see, the Instance size list does not contain the A6 and A7 SKUs. Mystery solved!

This case was very surprising to me in several respects. First, it seems strange that App Controller keeps its own definition files of what is available in Windows Azure (a platform that is updated every 4-6 weeks) instead for dynamically downloading that information on demand and caching it. Secondly it seems like bad code when the introduction of a new instance SKU actually crashes a Windows service. Surly that exception could easily be handled in the code.