Windows Azure PowerShell June 2013 Update for IaaS and PaaS

The latest release of the Windows Azure PowerShell cmdlets has a huge amount of functionality for both Windows Azure Virtual Machines and significant improvements to Cloud Services.

Virtual Machine Updates

  • Virtual Machine Stop Billing Support
  • Endpoint Access Control List Support
  • Endpoint Support Improvements

Cloud Service Enhancements

  • Dynamically configure RDP per role or per service
  • Dynamically configure Diagnostics per role or per service

Virtual Machine Stop Billing

It was announced at TechEd today that in addition to the huge improvement of per-minute billing when you stop a Virtual Machine you will not be charged. This functionality was exposed in PowerShell as well in the Stop-AzureVM cmdlet. One caveat I want to mention is if you stop the last VM in a deployment you will lose your deployment’s virtual IP address. If you want to stop the last VM but not lose your IP a new switch has been added -StayProvisioned. Stop-AzureVM will prompt you with a warning if you try to stop the last VM (with -StayProvisioned you will continue to be billed).

Virtual Machine Endpoint Access Control Support

A significant improvement in the security of virtual machines is the ability to lock down an endpoint so that only a specified set of IP addresses can access it.

To specify ACLs during or after deployment from PowerShell you create a new ACL configuration object using New-AzureAclConfig and then modify it with Set-AzureAclConfig. The created ACL object is then specified to the *-AzureEndpoint cmdlet in the -ACL parameter.

Example – Setting an ACL for SSH

$acl = New-AzureAclConfig 

Set-AzureAclConfig -AddRule Permit -RemoteSubnet "" -Order 1 `
                            -ACL $acl -Description "Lock down SSH"

Get-AzureVM -ServiceName mwlinuxsvc1 -Name mwlinux | 
    Set-AzureEndpoint -Name ssh -Protocol tcp -PublicPort 22 `
                      -LocalPort 22 -ACL $acl | 

Virtual Machine Other Endpoint Improvements

It is not a well known fact that prior to this release it was not possible to perform an update on a load balanced endpoint set. The underlying API would not actually support it. In this release a new API was added that allowed for the direct modification of a load balanced endpoint set.

To support this in PowerShell a new cmdlet called Set-AzureLoadBalancedEndpoint was added.
This cmdlet supports modifying a load balanced endpoint for operations such as changing health probe settings or port settings. Best of all this cmdlet can be called directly against this service and doesn’t require updating each individual endpoint.

Example of enabling an http health probe on an existing load balanced endpoint.

Set-AzureLoadBalancedEndpoint -ServiceName $svc -ProbeProtocolHTTP `
                   -LBSetName "lbweb"  -ProbePath "/healthcheck" `
                    -ProbePort 80

Finally, a flag for enabling DirectServerReturn has been enabled on Add/Set Endpoint cmdlets. This flag allows you to enable DirectServerReturn on certain endpoints which in turn allows the server to respond directly to the client instead of funneling the response back through the load balanced.

Cloud Services – Enabling RDP and Diagnostics on Demand

A new concept called “Cloud Service Extensions” was recently added which allows certain code to be executed after a Cloud Service has been deployed. Currently, the only two extensions that have been published to date are RDP and Diagnostics.
The power of the extensions model is you do not have to repackage your application to enable/disable functionality like RDP and Diagnostics it can be done after the fact.

Both cmdlets support a -Role parameter which allows you to selectively enable or disable the extension.

Example of enabling RDP for all roles

$cred = Get-Credential 
Set-AzureServiceRemoteDesktopExtension -ServiceName $svc -Credential $cred

Example on removing RDP from all roles

Remove-AzureServiceRemoteDesktopExtension -ServiceName $svc 

A few things about the Cloud Service Extension architecture. The above example sets a default RDP configuration. So all roles will have the same user name / password. If you then called the cmdlet on an individual role the role would get its own settings. This is interesting when you remove the role specific settings because the default settings will still apply.
The cmdlets are smart enough to warn you of this behavior on use.

The other cmdlet that has been added is the Set-AzureServiceDiagnosticsExtension. It works exactly the same way but accepts a wadcfg.xml file that can configure diagnostics logging on the role or roles.

One final caveat – the RDP and Diagnostics extensions are not compatible with the legacy RDP and Diagnostics plugins that ship in the SDK. To take advantage of this dynamic behavior you will first need to remove the legacy plugins from your application and redeploy.

My Last Release 😦

Sadly, this is the last release that I will have direct involvement in as I accepted a new job outside of Microsoft working with an outstanding Microsoft and Windows Azure Partner – Aditi. However, I will still continue to stay in tune with the Windows Azure PowerShell cmdlets and blog religiously about them (and email bugs and feature requests!).

The WA PowerShell/Runtime team is outstanding and I expect some great things from them going forward from the PowerShell and Service Management API front (hopefully, some powerful new Cloud Service Extensions will make their way out of Redmond as well)!

Speaking at MMS 2013

If you will be attending MMS 2013 next week in Las Vegas and want to learn more about automating the cloud with the Windows Azure PowerShell Cmdlets please stop by my session!

WS-B311 Take Control of the Cloud with the Windows Azure PowerShell Cmdlets

In this session you will learn how to tame the simplest to most advanced Windows Azure deployments with the Windows Azure PowerShell cmdlets. Automate repetitive tasks and learn how build advanced reproducible deployments so you can save time and money while working in the cloud. The presenter will cover dev-ops scenarios with Virtual Machines and Cloud Services in this demo packed session.

New Role within Microsoft

I have a new job! 🙂

As of 1/28/2013 I will move over to the Windows Azure Runtime team as a Senior Program Manager. So instead of just talking about how great Windows Azure is I’ll have the opportunity to make it even better.

My initial focus will be on the Developer and IT Pro client experience. This will mean a lot of work focusing on Cloud Services(PaaS) and Virtual Machines(IaaS) usability and functionality. The first order of business is building improving upon the command line and SDK experience for our compute options.

I’m very open and interested in feedback so please let me know how I can help 🙂

Michael Washam
mwasham at

Upgrading Windows Azure Cloud Services to Server 2012 and .NET 4.5

In this post I’ll walk through the options for upgrading an existing Cloud Service using OS Family (1 or 2) to use Windows Server 2012 (OS Family 3) and .NET 4.5.

Traditionally, to upgrade a Cloud Service all that is required is to click the update button in the Windows Azure portal after uploading your updated package or publishing with Visual Studio. However, when changing OS Families from (1 or 2) to 3 you will receive the error saying “Upgrade from OS family 1 to OS family 3 is not allowed”. This is a temporary restriction on the update policy that we are working to remove in an upcoming release.

In the mean time there are two workarounds to updating your existing Windows Azure Cloud Service to run with .NET 4.5 and OS family 3 (Server 2012):

  • VIP Swap (recommended approach)
  • Delete and Re-deploy

Both have different pros/cons that are outlined in the table below. Detailed walkthroughs of both the options are provided below:

VIP Swap Fast and simple. Usual VIP swap restrictions apply.
Delete/Re-deploy Can make any change to the updated application. VIP swap restrictions do not apply. Loss of availability while the application is deleted and then redeployed. Potential change in the public IP address after the   redeployment.

Configuring Your Project for Upgrade

Step 1: Open the solution in Visual Studio.

In the example below the solution is named Sdk1dot7 and there are two projects. The first is an MVC Web Role project (MvcWebRole1) and the second is the Windows Azure Cloud Service project (Sdk1dot7).


Step 2: Upgrade the Project

Right click on the Cloud Service project  (Sdk1dot7) and select properties. Note in the picture below, the properties page shows that this project was built the June 2012 SP1 Windows Azure Tools version. Click the “Upgrade” button. After the upgrade, if you check this properties sheet again, it should show that the current Windows Azure Tools
version is October 2012.


Step 3: Open ServiceConfiguration.Cloud.cscfg: csu3

Change OSFamily from (1 or 2) to 3.


New Value: osFamily=”3″

Step 4: Modify the Web Role to use .NET 4.5

Open the properties sheet of the WebRole project by right-clicking the WebRole project and clicking on “Properties”.


In the “Application” tab look for the “Target framework” dropdown. It should show .NET 4.0.


Open the dropdown and select .NET 4.5. You’ll get a “Target Framework Change” dialog box, click “Yes” to proceed. The Target Framework should now read .NET 4.5.

Rebuild by hitting ‘F6’. You might get some build errors due to namespace clashes between some new libraries that have been introduced in .NET 4.5. These are easy enough to fix. If you cannot, feel free to add the comment and I’ll respond.

Deploying using VIP Swap

You can deploy from within Visual Studio or from the Windows Azure Portal. In this post, I’ll show the steps to deploy through the portal.

Step 1: Generate the .cspkg and .cscfg files for upload.

Right click on your Cloud Service project (Sdk1Dot7) and select Package:


After the packaging is complete, a file explorer window will open with the newly created .cspkg and .cscfg files for your Cloud Service.

Step 2: Uploading the Files to the Staging Slot using the Windows Azure Portal

Open the Windows Azure portal at and select your cloud service. Click on the “Staging” tab (circled in red in the accompanying picture below).

Once on the staging tab, click on the “Update” button on the bottom panel (circled in green in the accompanying picture below).


From there a dialog will open requesting the newly created files packaged from Visual Studio.

Select “From Local” button for both and upload  the files that were generated during packaging. Remember to check the “Update even if one or more roles contain single instance” if you have a single instance role. These options are circled in red in the picture below. Click on the check marked circle to proceed.


Step 3: Test the new deployment

At this point you will have your application running on OS family 3 and using .NET 4.5 in the staging slot and your original application using OS family 1/2 and .NET 4.0 in the production slot. Browse to the application by clicking the Site URL on the dashboard under the staging slot.

Step 4: Perform the VIP Swap to Production

On either the production or the staging tab, click on the “swap” button located in the bottom panel next to the update button (circled in green in the accompanying picture).


After this operation completes, you will have your application running on OS family 3 and using .NET 4.5 in place of the original application.

Deleting Your Deployment

The second option is to delete your deployment. This is not going to be the recommended approach for a production application because you will have downtime and there is a probability of losing the current IP address assigned to your VIP. This option is really only useful for dev/test where you do not want to go through the VIP swap life cycle or you are making changes to the cloud service that are restricted during an in-place upgrade using VIP swaps.

To delete your deployment open the Windows Azure portal at and select your cloud service. Click the “STOP” button in the bottom panel (circled in green in the accompanying picture). Click “yes” on the dialog box that pops up.


Once the service is deleted you can simply republish from Visual Studio or package and upload using Visual Studio + the management portal.

Windows Azure IaaS Webcast Series Part Two: Virtual Machine Networking Basics

This is part two of the Windows Azure IaaS Webcast Series. This webcast discusses connecting virtual machines together in a cloud service for direct network connectivity and also shows the basics of configuring load balanced endpoints.


If you missed it click here for: Part One Getting Started with Windows Azure Virtual Machines

Connecting Web or Worker Roles to a Simple Virtual Network in Windows Azure

In this post I’m going to show you how simple it is to connect cloud services to a virtual network.

Before I do that let me explain a couple of reason of why you would want to do this.

There are a few use cases for this.

Web or Worker Roles that need to:

  1. Communicate with a Virtual Machine(s)
  2. Communicate with other web or worker roles in a separate cloud service (same subscription and region though)
  3. Communicate to an on-premises network over a site to site VPN tunnel (not covered in this post)

In at least the first two cases you could accomplish the connectivity by opening up public endpoints on the cloud services and connecting using the public IP address. However, this method introduces latency because you are making multiple hops over each cloud service load balancer. Not to mention that there is a good chance that the endpoint you are trying to connect to would be more secure if it wasn’t exposed as a public endpoint. Connecting through a VNET is much faster and much more secure.

For this example I’m going to walk through a simple VNET that will accomplish the goal of connecting cloud services.

Step 1: Create an affinity group for your virtual network in the region where your cloud services will be hosted.

Step 2: Create a simple virtual network and specify the previously created affinity group along with a single subnet network configuration.

For the subnet details I am specifying which is a class B address space. I’m only carving one subnet ( out of the address space to keep things simple. Unless you need connectivity back to on-premises or are planning to lock down traffic between subnets when Windows Azure supports ACLs this will likely be a sufficient solution for simple connectivity.

Step 3: Deploy a Cloud Service to the VNET.

Unlike deploying a Virtual Machine you cannot specify virtual network settings on provisioning through the portal. The networking configuration goes inside of the .cscfg file of your Windows Azure deployment package.

To connect to this virtual network all you would need to do is paste the following below the last Role tag in your service configuration file (.cscfg) and deploy.

    <VirtualNetworkSite name="SimpleVNET" />
      <InstanceAddress roleName="MyWebRole">
          <Subnet name="AppSubnet" />

A few things to note about this configuration. If you have multiple roles in your deployment package you will need to add additional InstanceAddress elements to compensate. Another thing to point out is the purpose behind multiple subnets for each role. The idea is if you have an elastic service that has instances added/removed you could conceivably run out of addresses in the subnet you specify. If you specify multiple subnets to the role Windows Azure will automatically pull an address out of the next available subnet when the instance is provisioned if you run out of addresses from the first subnet.

Name resolution is another area to address. When deployed inside of a virtual network there is no default name resolution between instances. So if you are deploying a web role that will connect to a SQL Server running on a virtual machine you will need to specify the IP address of the SQL server in your web.config. For that specific scenario it would make sense to deploy the SQL VM first so you can actually get the internal IP address for your web app. It is of course possible to deploy your own DNS server in this environment. If you do you can specify the DNS server for your web/worker role instances with an additional XML configuration.

This would go right below the NetworkConfiguration element start tag:

        <DnsServer name="mydns" IPAddress=""/>

Finally, to make a truly connected solution you would want to deploy additional services such as VM or other cloud service/web worker roles to the VNET. The beauty of this configuration is every application deployed into this VNET will be on the same virtual network and have direct low latency and secure connectivity.

P.S. Virtual Network and Subnet Names are case sensitive in the configuration file.