Category Archives: Windows Azure

New Windows Azure IaaS Training Courses Available

With the new year upon us we figured it would be a great time to announce new courses! We have recently added two new Windows Azure Infrastructure as a Service based courses that are immediately available for a dedicated onsite or remote class room style delivery.

Each course is two days in length, complete with hands on labs and a thorough introduction to Windows Azure Infrastructure Services (Virtual Machines and Virtual Networks). They are designed as “Jump Start” courses; meaning that they can quickly get students up to speed and proficient with the technology in a very short time period.


Windows Azure Training

Questions about the courses? Give us a call at: 866-833-3878 or email at info@opsgility.com.

Windows Azure – Disk Cleanup with Virtual Machines

In the latest Windows Azure Portal and PowerShell updates Microsoft has added some great functionality to manage disk cleanup with virtual machines.

Prior to these updates managing the cleanup of virtual machine disks was fairly painful. You either had to delete each disk one by one from the portal or use PowerShell code with some complex filtering and polling mechanism to remove them.

Deleting an Individual Virtual Machine and Disks from the Portal

In the portal when you select an individual virtual machine and on the bottom of the screen select Delete you are given two new options.

  • Keep the attached disks (doesn’t delete any disks)
  • Delete the attached disks (deletes all attached disks OS and Data)

delete vm windows azure portal

Deleting an Individual Virtual Machine and Disks from PowerShell

The equivelant functionality for the “Delete the attached disks” option from PowerShell is to append the -DeleteVHD parameter onto a call to Remove-AzureVM.

  Remove-AzureVM -ServiceName $serviceName -Name $vmName -DeleteVHD

Deleting all Virtual Machines and Disks in a Cloud Service from the Portal

If you need to remove all of the virtual machines and underlying disks in a specific cloud service you are covered too.
In the portal simply click CLOUD SERVICES on the left menu and find the cloud service hosting your virtual machines.

In the portal select a cloud service that contains virtual machines and on the bottom of the screen select Delete you are given three options.

  • Delete the cloud service and its deployments (deletes cloud service, all of the virtual machines (in the cloud service) and all disks attached to the virtual machines)
  • Delete all virtual machines (deletes all of the virtual machines (in the cloud service) but retains the disks)
  • Delete all virtual machines and attached disks (deletes all of the virtual machines in the cloud service and all of the disks but does not delete the cloud service)

portal delete cloud service and disks

To accomplish each of the tasks from PowerShell is straightforward.

Delete the cloud service and its deployments – equivalent PowerShell Code

Remove-AzureService -ServiceName $serviceName -DeleteAll

Delete all virtual machines (but not the cloud service or disks)

Remove-AzureDeployment -ServiceName $serviceName -Slot Production

Delete all virtual machines and attached disks (but not the cloud service)

Remove-AzureDeployment -ServiceName $serviceName -Slot Production -DeleteVHD

PowerShell for the rest
Finally, if you need to clean up disks that are no longer attached to virtual machines the PowerShell cmdlets come to the rescue.

Get-AzureDisk | where { $_.AttachedTo -eq $null } | select diskname, medialink

To delete an individual disk.

Remove-AzureDisk "disk name" -DeleteVHD

If you want to delete all of the disks that are not attached (be careful of this one – ensure you know what you are deleting before executing!).

Get-AzureDisk | where { $_.AttachedTo -eq $null } | Remove-AzureDisk -DeleteVHD

Summary
The ease of use of Windows Azure is getting better every day. What used to be a complex task (deleting disks after VM deletion) is now simplified without taking away the power that is available to the command line user. The Windows Azure team(s) are doing an amazingly good job of tackling tasks that were once difficult and making them much more manageable.

Calling the Windows Azure Management API from PowerShell

Most of the time using the Windows Azure PowerShell cmdlets will accomplish whatever task you need to automate. However, there are a few cases where directly calling the API directly is a necessity.

In this post I will walk through using the .NET HttpClient object to authenticate and call the Service Management API along with the real world example of creating a Dynamic Routing gateway (because it is not supported in the WA PowerShell cmdlets).

To authenticate to Windows Azure you need the Subscription ID and a management certificate. If you are using the Windows Azure PowerShell cmdlets you can use the built in subscription management cmdlets to pull this information.

 $sub = Get-AzureSubscription "my subscription" 
 $certificate = $sub.Certificate
 $subscriptionID = $sub.SubscriptionId

For API work my preference is to use the HttpClient class from .NET. So the next step is to create an instance of it and set it up to use the management certificate for authentication.

$handler = New-Object System.Net.Http.WebRequestHandler
 
# Add the management cert to the client certificates collection 
$handler.ClientCertificates.Add($certificate)  
$httpClient = New-Object System.Net.Http.HttpClient($handler)
 
# Set the service management API version 
$httpClient.DefaultRequestHeaders.Add("x-ms-version", "2013-08-01")
 
# WA API only uses XML 
$mediaType = New-Object System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/xml")
$httpClient.DefaultRequestHeaders.Accept.Add($mediaType)

Now that the HttpClient object is setup to use the management certificate you need to generate a request.

The simplest request is a GET request because any parameters are just passed in the query string.

# The URI to the API you want to call 
# List Services API: http://msdn.microsoft.com/en-us/library/windowsazure/ee460781.aspx
$listServicesUri = "https://management.core.windows.net/$subscriptionID/services/hostedservices"
 
# Call the API 
$listServicesTask = $httpClient.GetAsync($listServicesUri)
$listServicesTask.Wait()
if($listServicesTask.Result.IsSuccessStatusCode -eq "True")
{
    # Get the results from the API as XML 
    [xml] $result = $listServicesTask.Result.Content.ReadAsStringAsync().Result
    foreach($svc in $result.HostedServices.HostedService)
    {
        Write-Host $svc.ServiceName " "  $svc.HostedServiceProperties.Location 
    }
}

However, if you need to do something more complex like creating a resource you can do that as well.

For example, the New-AzureVNETGateway cmdlet will create a new gateway for your virtual network but it was written prior to the introduction of Dynamic Routing gateways (and they have not been updated since…).
If you need to create a new virtual network with a dynamically routed gateway in an automated fashion calling the API is your only option.

$vnetName = "YOURVNETNAME"
 
# Create Gateway URI
# http://msdn.microsoft.com/en-us/library/windowsazure/jj154119.aspx 
$createGatewayUri = "https://management.core.windows.net/$subscriptionID/services/networking/$vnetName/gateway"
 
# This is the POST payload that describes the gateway resource 
# Note the lower case g in <gatewayType - the documentation on MSDN is wrong here
$postBody = @"
<?xml version="1.0" encoding="utf-8"?>
<CreateGatewayParameters xmlns="http://schemas.microsoft.com/windowsazure">
  <gatewayType>DynamicRouting</gatewayType>
</CreateGatewayParameters>
"@
 
Write-Host "Creating Gateway for VNET" -ForegroundColor Green
$content = New-Object System.Net.Http.StringContent($postBody, [System.Text.Encoding]::UTF8, "text/xml")        
# Add the POST payload to the call    
$postGatewayTask = $httpClient.PostAsync($createGatewayUri, $content)
$postGatewayTask.Wait()
 
# Check status for success and do cool things

So there you have it.. When the WA PowerShell cmdlets are behind the times you can quickly unblock with some direct API intervention.

Try out Server 2012 R2 RTM in Windows Azure

It was announced today that MSDN/TechNet subscribers can now download Server 2012 R2 and Windows 8.1 RTM.. Fantastic news if you have access to MSDN or TechNet :)

As of 9/9/2013 Server 2012 R2 RTM is not available as an image in Windows Azure. You can either wait for them to add it OR if you have access to the RTM bits you can add it yourself.

Step 1: Login to MSDN or TechNet and download the ISO

Step 2: Download the Convert-WindowsImage.ps1 PowerShell script to convert the ISO from MSDN/TechNet into a bootable VHD.

Step 3: Mount the ISO to your machine (double click it in Win8)

Step 4: Run the following to create the VHD:

 .\Convert-WindowsImage.ps1 -SourcePath "E:\sources\install.wim" -Edition ServerStandard -VHDPath D:\Server2012R2.VHD

Step 5: Use the Windows Azure PowerShell Cmdlets to Upload the VHD

Add-AzureVHD -Destination "https://<yourstorage>.blob.core.windows.net/images/Server2012R2.vhd" -LocalFilePath "D:\Server2012R2.VHD" -NumberOfUploaderThreads 5

Step 6: Register as an image.

Add-AzureVMImage -ImageName "Server2012R2" -OS Windows  -MediaLocation "https://<yourstorage>.blob.core.windows.net/images/Server2012R2.vhd"

Now, back in the portal or from PowerShell you can provision a new Server 2012 R2 VM from your very own custom image. My bet is the Windows Azure team will have an RTM Image of Server 2012 R2 in the Image Gallery and avoid the need for these steps but until then you can try out 2012 R2 in the cloud :)

Connecting Clouds – Creating a site-to-site Network with Amazon Web Services and Windows Azure

Connecting Windows Azure to Amazon AWS

In this post I will show how you can use a Windows Azure Virtual Network (VNET) to create a site to site IPsec tunnel to connect to a Virtual Private Cloud (VPC) hosted in Amazon Web Services (AWS). Using this setup you can literally have workloads in each cloud with full VM to VM connectivity over a secure IPsec tunnel. This scenario could easily be used for failover, backup or even migration between providers. The software VPN solution I chose for testing is Open Swan.

Creating a VPC in Amazon AWS

Starting on the Amazon side create a virtual private cloud (VPC) which is the equivalent to a virtual network in Windows Azure.

VPC Creation Wizard – Single Public Subnet with Internet Gateway

create-vpc-wizard-rs

I’m choosing the 10.0.0.0/16 address space for the Amazon VPC network.

create-vpc-wizard-complete

Provision an EC2 instance that will be used to host Open Swan and be the Amazon side of the tunnel.

Launch Ubuntu 13.04 into the VPC Subnet

launch-ubuntu-instance-1

Specify the subnet of the VPC previously deployed and I would advise bumping up the instance size to Small from Micro.

launch-ubuntu-instance-2

Once the instance is created switch to the EC2 view and allocate a new Elastic IP. This will be the public IP address you will connect to the VM using SSH and the IP address your Windows Azure Virtual Network will connect to.

Click Yes Allocate on the new Elastic IP dialog.

allocate-elastic-ip

Select the instance from the drop down and click Yes Associate.

associate-elastic-ip-instance

Creating the Windows Azure Virtual Network

Before configuring the Open Swan service I need to create the other side of the network in Windows Azure. To establish the IPsec tunnel Open Swan needs the gateway IP address and authentication key which both from the Windows Azure Virtual Network.

Create a Windows Azure Virtual Network

create-vnet

Specify Data Center Location and VNET/Affinity Group Name

create-vnet-1

Check site-to-site VPN

create-vnet-2

Define the onsite network properties which in this case is the Amazon VPC Address Space and Elastic IP of the Open Swan Server

create-vnet-3

Define the Windows Azure Address Space. Ensure you add the Gateway Subnet.

create-vnet-4

Creating the Windows Azure Virtual Network Gateway

Once the Virtual Network is created open it and click create gateway -> and select static routing.

azure-create-gateway

Once the gateway is created you can get the gateway IP address and the authentication key and configure Open Swan on the Amazon side.
You will need the gateway IP and the key on the Amazon side.

azure-gateway-created

Configuring Open Swan in Amazon Web Services

Connect to the Open Swan VM

Switch to the instances view, select your instance and on the Actions menu click Connect.

Select Connect with a standalone SSH client.

connect-to-instance

Copy the SSH command (or use Putty using the instructions on the screen) to connect via SSH. I’m using the Windows SSH client that comes with GitBash for the record :)

connect-via-ssh

Once connected install and configure Open Swan for the VPN solution on the Amazon side.

Installing Open Swan

  sudo apt-get install openswan

Select NO for installing a certificate since we will be using key based authentication.

open-swan-install-1

The next steps require you to use a text editor to modify some configuration files. If you are rusty on using Linux editors like vi here is a handy cheat sheet: VI Cheat Sheet

Edit the ipsec.conf file

   cd /etc
   sudo vi ipsec.conf

Once open, enter edit mode by pressing: *i (in that order)

Replace the existing configuration with the following:

config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.0.0.0/16
      oe=off
 
include /etc/ipsec.d/*.conf

Exit and save the file by pressing: : x (in that order)

Change to the ipsec.d directory and create a new file named amznazure.conf.

  cd ipsec.d
  sudo vi amznazure.conf

Contents of amznazure.conf

conn amznazure
   authby=secret
   auto=start
   type=tunnel
   left=10.0.0.28
   leftsubnet=10.0.0.0/16
   leftnexthop=%defaultroute
   right=[WINDOWS AZURE GATEWAY IP]
   rightsubnet=172.16.0.0/16
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no

Notes about the above configuration:

  • left= is the local IP address of the Open Swan Server
  • leftsubnet= is the local address space of the servers in the VPC
  • right= is the IP Address of the Windows Azure VNET Gateway (replace with your own)
  • rightsubnet= is the address space of the Windows Azure Virtual Network

Once you have specified the configuration you need to specify the authentication key.

  cd /etc  
  sudo vi ipec.secrets

Add a line to the file in the following format (do not add the [] brackets):

10.0.0.28 [WINDOWS AZURE GATEWAY IP] : PSK "[WINDOWS AZURE GATEWAY KEY]"

Next, enable enable IP forwarding to the Open Swan VM:

sudo vi /etc/sysctl.conf

Then uncomment this line:

net.ipv4.ip_forward=1

Apply the changed network setting.

sudo sysctl -p /etc/sysctl.conf

Next, disable source / destination checking on the Open Swan server.

change-source-dest-check

disable-source-dest-check

Modify Security Groups to Allow Traffic from Windows Azure

In the Amazon management console select Security Groups and -> amzn-azure-group.

Add two custom UDP inbound rules – one for 500 and one for 4500 using the Windows Azure GW IP with /32 as the CIDR.

amzn-security-group

 sudo service ipsec restart

Windows Azure Virtual Network Connected to Amazon AWS Virtual Private Cloud

amzn-azvnet-connected

Configuring Routing

The reason the software VPN solution needs to be on the Amazon AWS side is because the AWS networking stack supports configuring routing tables where Windows Azure does not (yet I assume).

In the Amazon management console switch back to the VPC view and select route tables.

Select the route table associated with your VPC and add a new route to the 172.16.0.0/16 (Windows Azure Network) and that routes traffic through the instance ID of the Open Swan Server.

Updating Route Information

update-route-table

Creating Instances to Test Connectivity

Create an instance in AWS on the VPC Subnet.

launch-into-subnet

Launch an instance in Windows Azure on the Virtual Network created.

launch-into-vnet

One both instances are up you will need to enable the ICMP rule on each VM to test out connectivity using PING.

Pinging an Azure VM from an Amazon VM over the IPsec Tunnel

ping-from-amzn

Pinging an Amazon VM from an Azure VM over the IPsec Tunnel

ping-from-azure

That is it!

I can now deploy applications into Amazon AWS and Windows Azure and communicate between the two on a secure IPsec tunnel over the Internet.

Creating Highly Available Workloads with Windows Azure

In a recent update to the Windows Azure Management portal the Windows Azure team has added the capability to create and manage endpoint probes. While this functionality has always been available it was restricted only to the Windows Azure PowerShell Cmdlets. Having this ability in the management portal is a huge improvement for those seeking every tool at their disposal for improved availability.

In this post I’m going to show how you can take advantage of this new functionality in combination with availability sets to create a true highly available workload – in this case it will be a highly available web farm.

In the Windows Azure Management Portal create a virtual machine, select the Windows Server 2012 image and on the page asking for Availability Set select Create an Availability Set.

create-av-set

Create Availability Set

Once selected type in a name for your availability set. The name I’ve chosen is WEBAVSET.

Specifying an availability set ensures that Windows Azure will put members of the same availability set on different physical racks in the data center. This gives you redundant power and networking. This also tells Windows Azure that while performing host updates to not take down all nodes in the set at the same time so some of the nodes for your application will always be up and running.

Note: The only way to achieve 99.95% SLA with Windows Azure is by grouping multiple VMs performing the same workload into an availability set.

create-av-set2

On the last screen of the portal you can skip creating the HTTP Endpoint here. You will configure the load balancer in a later step.

create-web-3.

Once the first virtual machine is completed provisioning create another virtual machine using the same base image.

On the screen where you are asked about cloud services use the drop down list to select the previously created cloud service.
Note: Selecting an existing cloud service is another huge improvement in the portal UI – long requested!

Select the availability set drop down and you should see the AV Set name you created with the first VM. Select this AV set before proceeding.

create-web2

Once both virtual machines are provisioned they should both be in the same cloud service and availability set.

Same Cloud Service (same host name)
same-cs

Same Availability Set
same-av-set

Next configure each virtual machine for a workload to load balance. To keep it simple RDP into each VM and launch Server Manager -> Manage Roles and Features and add the Web Server role (IIS).

Once the Web Server role is installed on each server, open notepad to edit the default page (c:\Inetpub\wwwroot\IISStart.htm) to show which server is serving up traffic to verify load balancing is working.

Add the following HTML code to the page replacing VMNAME with the name of the VM you are on:

   <h1>VMNAME </h1>

Edited Page for webvm1
edit-page

Now to add the load balanced endpoints. Go back to the Windows Azure Management Portal and under the first VM (webvm1 in my case) select Endpoints at the top.
Then click Add towards the bottom of the screen.

New Endpoint Wizard
create-ep

Select HTTP from the Drop Down and Check Create a Load Balanced Set then click the next arrow.

Creating a Load Balanced HTTP Endpoint
create-ep2

Default TCP Probe Settings

The default load balancer probe settings are set to TCP. What this screen means is every 15 seconds the load balancer probe will attempt a TCP connect on the specified probe port. If it does not receive a TCP ACK Twice (Number of Probes) it will consider the node offline and will stop directing traffic to it. This alone is a huge benefit Windows Azure is giving you for free that was previously only available via the PS Cmdlets.

create-ep3

Configuring HTTP Probe Settings

Changing the probe type to HTTP gives you a bit more flexibility and power on what actions you can take. You can now specify a ProbePath property on the endpoint. The ProbePath is essentially a relative HTTP URL on your web servers that will respond with an HTTP 200 if the server is fine and ANY other response if the node will be taken out of rotation. This allows you to essentially write your own page that can check the state of the VM. Whether this is verifying disk space, data base or Internet connectivity the choice is yours.

For my simplistic example I’m just going to point this to the root of the site / so as long as IIS returns a HTTP OK (200) the server should be in the load balanced rotation.

create-ep4

Adding an endpoint to an existing load balanced set

Next add the load balanced endpoint on the second virtual machine by opening the VM in the Windows Azure Management Portal, click Endpoints at the top of the screen and Add at the bottom.
This time instead of creating a new endpoint select “Add Endpoint to an existing Load-Balanced Set”.

add-ep5

On the next screen select HTTP for the name and click the checkmark to add the endpoint.

add-ep6

A few additional details to be aware of with endpoint probes:

  • If a node is taken out of rotation, once it becomes responsive again the load balancer will automatically add it back to rotation.
  • The load balancer accesses the probe port using the internal IP address of the VM and not the public IP of the cloud service. This means the probe port does not have to be the same port as defined in the endpoint.
  • There are no credentials to be passed along with the load balancer requests. The ProbePath property for HTTP probes should always point to a url that can respond successfully with no authentication (for those of you deploying SharePoint you already know this).
  • To troubleshoot a load balanced endpoint with HTTP probes always check the web logs of the servers. The load balancer requests are obvious and if you see response codes anything other than a 200 you know why the node is out of rotation.

Verification

Browse to the cloud service to ensure the load balancer is behaving as expected. If working (and you followed my post) you should see both VMs come through if you hit F5 a few times.

Response from VM1
verification1

Response from VM2
verification2

Now the important part: Ensure that the load balancer does not direct traffic to a node that is down.

Pick a VM and click the Shutdown button in the Windows Azure Management Portal (at the bottom of the page for the VM).

Stopped VM
stopped-vm

Once the virtual machine is stopped refresh the site multiple times. You should not see a timed out response or a response from the VM you shut down.

How to do the same thing in PowerShell

For those of you that may have the need to spin up workloads like this often it is probably worth investing the time in learning PowerShell.
Here is a quick example of how the above process can be packaged up in a small script to automate all of the above steps.
Note: if you are new to WA PowerShell take a look at the Windows Azure PowerShell reference guide (very incomplete but good starting point).

# Retreived with Get-AzureVMImage | select ImageName
$img = "a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-Datacenter-201306.01-en.us-127GB.vhd"
 
$user = "mwasham"
$pwd = "some@pass123a1"
 
$vmname = "webvm"
$csname = "lbcloudsvc123a"
 
$av = "WEBAVSET"
 
$instances = 2
$vms = @()
 
# Loop to create N number of VMs
for($i=0; $i -lt $instances; $i++){
 
 $vmInstanceName = "$vmname-$i"
 # Compose a VM config with the load balanced endpoint and the correct av set
 
 $vms += New-AzureVMConfig -Name $vmInstanceName -InstanceSize Small -ImageName $img `
          -AvailabilitySetName $av |
          Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $pwd |
          Add-AzureEndpoint -Name "HTTP" -Protocol tcp -LocalPort 80 -PublicPort 80 `
            -LBSetName "LBHTTP" -ProbePort 80 -ProbeProtocol http -ProbePath "/" 
}
 
 
New-AzureVM -ServiceName $csname -Location "West US" -VMs $vms

Summary

In this post I showed how to take advantage of the new functionality in the Windows Azure Management Portal to add additional high availability to your web farm (or other multi-vm workload).

Set-AzureStorageAccount incorrectly sets Geo-Replication States

There has been a bug identified in the Set-AzureStorageAccount cmdlet that could inadvertently enable or disable your storage account geo-replication settings.
Those who have used this cmdlet should check the geo-replication for their accounts in the Azure Portal immediately.

Note: For more information on Geo-Replication in Windows Azure Storage please visit the following post: http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/introducing-geo-replication-for-windows-azure-storage.aspx

Scenario 1: Changing the label or description of your storage account without specifying -GeoReplicationEnabled will disable geo-replication

PS C:> Set-AzureStorageAccount -StorageAccountName mwweststorage -Label “updated label”

StorageAccountDescription : 
AffinityGroup             : 
Location                  : West US 
GeoReplicationEnabled     : False
GeoPrimaryLocation        : West US
GeoSecondaryLocation      : 
Label                     : "updated label"
StorageAccountStatus      : Created
StatusOfPrimary           : 
StatusOfSecondary         : 
Endpoints                 : {http://mwweststorage.blob.core.windows.net/, http://mwweststorage.queue.core.windows.net/, 

http://mwweststorage.table.core.windows.net/}

StorageAccountName        : mwweststorage
OperationDescription      : Get-AzureStorageAccount
OperationId               : 8dc5e76c-e8ac-460f-a76c-5a0c6f96e2c6
OperationStatus           : Succeeded

Scenario 2: Setting geo-replication to disabled in your storage account via PowerShell will actually enable it.

PS C:> Set-AzureStorageAccount -StorageAccountName mwweststorage -GeoReplicationEnabled $false -Label “disabled geo replication”

StorageAccountDescription : 
AffinityGroup             : 
Location                  : West US 
GeoReplicationEnabled     : True
GeoPrimaryLocation        : West US
GeoSecondaryLocation      : 
Label                     : "disabled geo replication"
StorageAccountStatus      : Created
StatusOfPrimary           : 
StatusOfSecondary         : 
Endpoints                 : {http://mwweststorage.blob.core.windows.net/, http://mwweststorage.queue.core.windows.net/, 

http://mwweststorage.table.core.windows.net/}

StorageAccountName        : mwweststorage
OperationDescription      : Get-AzureStorageAccount
OperationId               : 8dc5e76c-e8ac-460f-a76c-5a0c6f96e2c6
OperationStatus           : Succeeded

Mitigation Strategy:

  • From PowerShell
  • To enable: Pass GeoReplicationEnabled $true
  • To disable: Do not pass GeoReplicationEnabled
  • From the Windows Azure Management Portal
  • Click on your Storage Account
  • Click on Configure
  • Verify the geo-replication configuration

What are we in the Windows Azure PowerShell Team(s) doing about it?

We will be releasing an updated version of the current release (0.6.13) to include a fix in the Set-AzureStorageAccount cmdlet in the very near future.
This will be a BREAKING CHANGE. Note: We have determined a solution that will not be a breaking change.

Update – 4/23/2013

The Windows Azure PowerShell cmdlets have been updated with this fix. Please download the latest and verify your Storage Account settings.