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)!

Windows Azure PowerShell Updates for IaaS GA

With the release of Windows Azure Virtual Machines and Virtual Networks into general availability the Windows Azure PowerShell team has been working feverishly to provide an even more powerful automation experience for deploying virtual machines in the cloud.

Remote PowerShell on Windows Azure – Automating Virtual Machines

One of the key requests we have heard from customers is to go beyond the current capabilities of automated infrastructure provisioning and allow the user to bootstrap a virtual machine as part of a fully automated deployment.

With this release we are announcing that Remote PowerShell will be enabled by default on Windows based virtual machines created with the latest version of the Windows Azure PowerShell Cmdlets.

Enabling Remote PowerShell allows a user to create a virtual machine and on boot immediately launch a script to bootstrap whatever configuration is desired. This could be installing and configuring Windows Roles and Features all the way to downloading and deploying an application or website. Authentication is over SSL for security and you can use your own certificate or we can even generate one for you. In addition to the bootstrapping abilities Remote PowerShell allows you to write powerful scripts for remote management and automation that can be ran at any time after the virtual machine is booted. The same scripts you use to manage your on-premises servers will work with your servers in Windows Azure. Of course, we do provide a switch to disable this functionality on boot if Remote PowerShell is not desired.

Installing Windows Server Features Automatically

In the example below the new -WaitForBoot parameter is used with New-AzureVM. This switch tells the cmdlet to wait for the virtual machine to be in the RoleReady (booted) state before continuing execution. Once the virtual machine is ready the script calls the Get-AzureWinRMUri cmdlet to retrieve the connection string to execute a remote script against the virtual machine. The script block passed to Invoke-Command installs the Web-Server IIS and the related management tools.

A PowerShell scripter could easily extend this script to automatically deploy a custom web application or service with just a few additional lines of code.

Installing Windows Features using Remote PowerShell

# Using this script installs the generated cert into your local cert store which allows 
# PowerShell to verify it is communicating with the correct endpoint. 
# This REQUIRES PowerShell run Elevated
. "C:\Scripts\WAIaaSPS\RemotePS\InstallWinRMCert.ps1" 

$user = ""
$pwd = ""
$svcName = ""
$VMName = "webfe1" 
$location = "West US"

$credential = Get-Credential 

New-AzureVMConfig -Name $VMName -InstanceSize "Small" -ImageName $image |
                Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $pwd |
                Add-AzureEndpoint -Name "http" -Protocol tcp -LocalPort 80 -PublicPort 80 |
                New-AzureVM -ServiceName $svcName -Location $location -WaitForBoot 

# Get the RemotePS/WinRM Uri to connect to
$uri = Get-AzureWinRMUri -ServiceName $svcName -Name $VMName 

# Using generated certs – use helper function to download and install generated cert.
InstallWinRMCert $svcName $VMName 

# Use native PowerShell Cmdlet to execute a script block on the remote virtual machine
Invoke-Command -ConnectionUri $uri.ToString() -Credential $credential -ScriptBlock {
    $logLabel = $((get-date).ToString("yyyyMMddHHmmss"))
    $logPath = "$env:TEMP\init-webservervm_webserver_install_log_$logLabel.txt"
    Import-Module -Name ServerManager
    Install-WindowsFeature -Name Web-Server -IncludeManagementTools -LogPath $logPath

Contents of InstallWinRMCert.ps1

function InstallWinRMCert($serviceName, $vmname)
    $winRMCert = (Get-AzureVM -ServiceName $serviceName -Name $vmname | select -ExpandProperty vm).DefaultWinRMCertificateThumbprint

    $AzureX509cert = Get-AzureCertificate -ServiceName $serviceName -Thumbprint $winRMCert -ThumbprintAlgorithm sha1

    $certTempFile = [IO.Path]::GetTempFileName()
    Write-Host $certTempFile
    $AzureX509cert.Data | Out-File $certTempFile

    # Target The Cert That Needs To Be Imported
    $CertToImport = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $certTempFile

    $store = New-Object System.Security.Cryptography.X509Certificates.X509Store "Root", "LocalMachine"

    Remove-Item $certTempFile

Image and Disk Mobility

Windows Azure is an open computing platform and allows for the movement of your virtual machine disks between on-premises and the cloud. There are two optimized cmdlets that enable either you to upload your VHD or download it.

Uploading a VHD

The first example shows how to upload a VHD to Windows Azure. This can be a bootable OS disk or simply a data disk (remove -OS Windows for data disks). After Add-AzureDisk is called you could use the New-AzureVMConfig cmdlet or the management portal to provision a virtual machine that boots off of the uploaded VHD.

$source = "C:\vmstorage\myosdisk.vhd"
$destination = "https://<yourstorage>"

Add-AzureVhd -LocalFilePath $source -Destination $destination -NumberOfUploaderThreads 5
Add-AzureDisk -DiskName 'myosdisk' -MediaLocation $destination -Label 'mydatadisk' -OS Windows 

Downloading a VHD

Not only can you upload a disk to Windows Azure but it is also easy to download a VHD as well! The example below shows how you can save a VHD to the local file system ready to run on a Hyper-V enabled system. (Note: a virtual machine should not write to the VHD at the same time you are trying to download it).

$source = "https://<yourstorage>"
$destination = "C:\vmstorage\myosdisk.vhd"
Save-AzureVhd -Source $source -LocalFilePath $destination -NumberOfThreads 5 

VMDK Conversion and Migration to Windows Azure

If you have VMWare based virtual machines that you would like to migrate you can use the Microsoft Virtual Machine Converter Solution Accelerator to convert the disks to VHDs and then use the Add-AzureVHD cmdlet to upload the VHD and create a virtual machine in Windows Azure from it.

Copying a VHD across Windows Azure Regions

# Source VHD (West US)
$srcUri = "http://<yourweststorage>"      

# Target Storage Account (East US)
$storageAccount = "<youreaststorage>"
$storageKey = "<youreaststoragekey>"

$destContext = New-AzureStorageContext  –StorageAccountName $storageAccount `
                                        -StorageAccountKey $storageKey  

# Container Name
$containerName = "vhds"

New-AzureStorageContainer -Name $containerName -Context $destContext

$blob = Start-AzureStorageBlobCopy -srcUri $srcUri `
                                   -DestContainer $containerName `
                                   -DestBlob "testcopy1.vhd" `
                                   -DestContext $destContext   
$blob | Get-AzureStorageBlobCopyState 

Enhanced Security -AdminUserName is required for Windows (Breaking Change)

In order to protect you from unwanted attacks from connections attempting to use the dictionary on your password, we have made it mandatory to supply a username.
This change affects the New-AzureQuickVM and the Add-AzureProvisioningConfig cmdlets used for VM creation. Each will have a new –AdminUserName parameter that is now required.
Make sure you can remember it but do not use obvious names like Administrator or Admin.

High Memory Virtual Machine Support

The latest version of the WA PowerShell Cmdlets now support the new higher memory SKU sizes of A6 and A7 for larger workloads. For more information about Windows Azure compute sizes see the following:


Managing Availability Sets on Deployed VMs

We have also added the ability to specify availability set configuration for groups of virtual machines for highly available configurations. Previously, this could only be set at deployment time or post deployment from the Windows Azure Management Portal. For more information on availability sets see the following article:

Get-AzureVM -ServiceName "mywebsite" | Where {$_.Name -like "*web*"} | 
    Set-AzureAvailabilitySet -AvailabilitySetName "wfe-av-set" |

Wrapping Up

I hope you are excited about the new features in the Windows Azure PowerShell Cmdlets. If you would like to try this yourself you will need a subscription, to download the WA PowerShell Cmdlets and a short read on getting started.

Michael Washam
Senior Program Manager – Windows Azure

How to provision a Linux VM in a VNET with PowerShell

Getting Started Links

# From Get-AzureVMImage 
$img = 'b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-12_04_1-LTS-amd64-server-20121218-en-us-30GB'
$user = 'somelinuxuser'
$pass = 'somelinuxpwd!'
$vnet = 'HybridVNET'
$ag = 'WestUSAG'
$svcname = 'mylinuxsvc1' 

New-AzureVMConfig -Name 'linuxfromps1' -ImageName $img -InstanceSize Small |
	Add-AzureProvisioningConfig -Linux -LinuxUser $user -Password $pass |
	Set-AzureSubnet -SubnetNames 'AppSubnet' | # Optional 
	New-AzureVM -ServiceName $svcname -VNetName $vnet -AffinityGroup $ag

Migrate a Virtual Machine to Windows Azure with PowerShell

In my previous post I show how you can use the Add-AzureVHD cmdlet to upload a VHD. I wanted to take it a bit further and show how you can use this new cmdlet in conjunction with the other PowerShell cmdlets to migrate and provision an entire virtual machine.

The script below uploads two VHDs; one for the Operating System Disk and one for an additional data disk. Once the VHDs are uploaded it then creates the disk entities using the Add-AzureDisk cmdlet and then proceeds to construct the virtual machine using the newly uploaded VHDs.

# Retrieve with Get-AzureSubscription 
$subscriptionName = '[MY SUBSCRIPTION]'  

# Retreive with Get-AzureStorageAccount 
$storageAccountName = '[MY STORAGE ACCOUNT]'   

# Specify the storage account location to store the newly created VHDs 
Set-AzureSubscription -SubscriptionName $subscriptionName -CurrentStorageAccount $storageAccountName 
# Select the correct subscription (allows multiple subscription support) 
Select-AzureSubscription -SubscriptionName $subscriptionName 

# Retreive with Get-AzureLocation 
$location = 'West US' 

# ExtraSmall, Small, Medium, Large, ExtraLarge
$instanceSize = 'Medium' 

# Has to be a unique name. Verify with Test-AzureService
$serviceName = '[UNIQUE SERVICE NAME]' 

# Server Name
$vmname1 = '[MY VM NAME]'

# Source VHDs
$sourceosvhd = 'C:\MyVHDs\AppServer1OSDisk.vhd'
$sourcedatavhd = 'C:\MyVHDs\AppServer1DataDisk.vhd'

# Target Upload Location 
$destosvhd = 'http://' + $storageAccountName + ''
$destdatavhd = 'http://' + $storageAccountName + ''

Add-AzureVhd -LocalFilePath $sourceosvhd -Destination $destosvhd 
Add-AzureVhd -LocalFilePath $sourcedatavhd -Destination $destdatavhd

Add-AzureDisk -OS Windows -MediaLocation $destosvhd -DiskName 'AppServer1OSDisk'
Add-AzureDisk -MediaLocation $destdatavhd -DiskName 'AppServer1DataDisk'

$migratedVM = New-AzureVMConfig -Name $vmname1 -DiskName 'AppServer1OSDisk' -InstanceSize 'Medium' |
					Add-AzureDataDisk -Import -DiskName 'AppServer1DataDisk' -LUN 0 |
					Add-AzureEndpoint -Name 'Remote Desktop' -LocalPort 3389 -Protocol tcp 
New-AzureVM -ServiceName $serviceName -Location $location -VMs $migratedVM 					

New Windows Azure PowerShell Update – December 2012

The Windows Azure PowerShell team has just put out an update. Currently, downloadable from: GitHub.

The first one I want to call out because it is close to my IaaS focused heart is Add-AzureVhd.

If you have had the pleasure of uploading VHDs for IaaS before using CSUpload you know the old tool was pretty cumbersome.

Now uploading VHDs for onboarding virtual machines is simple(r).

In it’s simplest form you simply specify the local path to the VHD and the destination storage account URL:

Select-AzureSubscription 'mysubscription' 
Add-AzureVhd -LocalFilePath 'D:\VMStorage\SP2013VM1.vhd' -Destination ''

Once the upload has completed you can add the VHD to the disk repository by using the following command:

Add-AzureDisk -DiskName 'SP2013VM1OS' -MediaLocation '' -OS Windows

If you wanted to upload only a data disk just omit -OS Windows.
This cmdlet also supports uploading differencing disks to patch VHDs in storage as well. You can specify -BaseImageUriToPatch as the target VHD to apply the differencing disk too.

Once the disk is loaded to boot the virtual machine from the disk simply specify the disk name when configuring the VM.


If you prefer to provision from PowerShell:

New-AzureVMConfig -DiskName 'SP2013VM1OS' -InstanceSize Medium -Name 'SP2013VM1' | 
	Set-AzureSubnet -SubnetNames 'AppSubnet' | 
	New-AzureVM -ServiceName 'sp2013svc1' -VNETName 'HybridVNET' -AffinityGroup 'WestUSAG'

One potential regression I do want to call out in the IaaS space is a change to Get-AzureVMImage

The below code formerly worked and now no longer returns a value..

# Previous functionality 
(Get-AzureVMImage)[1].ImageName # Returns a value
Get-AzureVMImage | Select ImageName # Returns value

If your scripts did something similar you will need to use

Get-AzureVMIMage | ft imagename 

Store the specific image in a variable for later use.

Another key set of additions to the Windows Azure PowerShell Cmdlets:

We finally have the ability to directly manage ServiceBus Namespaces from the command line. From a dev-ops perspective this one is HUGE.

  • New-AzureSBNamespace – Create a new Windows Azure ServiceBus namespace
  • Get-AzureSBLocation – Get the Windows Azure regions that may be used to create new Windows Azure
  • Get-AzureSBNamespace – Get information about existing Windows Azure ServiceBus namespaces
  • Remove-AzureSBNamespace – Delete a WindowsAzure ServiceBus namespace and all associated objects

Complete list of the cmdlets in the December release:
(Note the Windows Azure SQL Database cmdlets made it back into the official release in November)


To download the latest bits:
Latest PowerShell Bits

To file an issue:
File a bug

Deploying certificates with Windows Azure Virtual Machines and PowerShell

A common question around using the Windows Azure PowerShell cmdlets is how to deploy certificates with VMs? In this post I’ve put together two samples on how to do this on Windows and Linux VMs.

Windows VM Example

Select-AzureSubscription mysub 

$service = 'yourservicename1'
$location = 'West US'

## Cloud Service must already exist 
New-AzureService -ServiceName $service -Location $location

## Add Certificate to the store on the cloud service (.cer or .pfx with -Password)
Add-AzureCertificate -CertToDeploy 'D:\User-Data\development\Azure Samples\mlwdevcert.cer' -ServiceName $service

## Create a certificate setting for deploying the VM 'My' is the only supported store (goes into computer account)
$cert1 = New-AzureCertificateSetting -Thumbprint D7BECD4D63EBAF86023BB4F1A5FBF5C2C924902A -StoreName 'My'

## Create the VM passing the certificate setting in the provisioning config 
New-AzureVMConfig -ImageName '' -InstanceSize 'Small' -Name 'win2012cert' |
      Add-AzureProvisioningConfig -Windows -Password 'somepass@1' -Certificates $cert1 |
      New-AzureVM -ServiceName $service 

Linux VM Example

Select-AzureSubscription mysub 

$service = 'yourservicename1'
$location = 'West US'

## Cloud Service must already exist 
New-AzureService -ServiceName $service -Location $location

## Add Certificate to the store on the cloud service (.cer or .pfx with -Password)
Add-AzureCertificate -CertToDeploy 'D:\User-Data\development\Azure Samples\mlwdevcert.cer' -ServiceName $service

## Create a certificate in the users home directory
$sshkey = New-AzureSSHKey -PublicKey -Fingerprint D7BECD4D63EBAF86023BB4F1A5FBF5C2C924902A -Path '/home/mwasham/.ssh/authorized_keys'

New-AzureVMConfig -ImageName 'CANONICAL__Canonical-Ubuntu-12-04-amd64-server-20120528.1.3-en-us-30GB.vhd' -InstanceSize 'Small' -Name 'linuxwithcert' |
	Add-AzureProvisioningConfig -Linux -LinuxUser 'mwasham' -Password 'somepass@1' -SSHPublicKeys $sshKey |
	New-AzureVM -ServiceName $service 

Note: The -Certificates and -SSHPublicKeys parameters are arrays so they can accept multiple certificates.
-SSHPublicKeys $sshKey1,$sshKey2

For Linux there is also the -SSHKeyPairs parameter for passing a key pair instead of just the public key. -Certificates can handle both types on Windows.

Publishing and Synchronizing Web Farms using Windows Azure Virtual Machines

Deploying new web applications is pretty painless with Windows Azure Web Sites and “fairly” painless using Windows Azure PaaS style cloud services. However, for existing web apps that are being migrated to the cloud both solutions can require significant rewriting/re-architecture. That is where Windows Azure Infrastructure as a Service comes in. Running Virtual Machines allows you to have the economies of scale of using a cloud based solution and have full access to cloud services such as storage, service bus etc.. while not requiring you to re-architect your application to take advantage of these services.

Usually when you think of cloud computing with Infrastructure as a Service you think of a lot of manual work and management pain. While it is certainly a bit more work than a pure PaaS operation it is possible to lower that management burden using automation tools and techniques.

In this post I will walk through how to use Windows Azure Virtual Machines to create a web farm that you can directly publish to using Visual Studio Web Deploy. In addition to simple publishing I will also show how you can automatically synchronize web content across multiple virtual machines in your service to make web farm content synchronization simple and painless.

Step #1 – Image Preparation

Create a new virtual machine using either Windows Server 2008 R2 or Server 2012. On this machine install the Application Server and Web Server roles and enable ASP.NET).

TIP: Don’t forget to install the .NET Framework 4.0 if you are using Server 2008 R2.

For this solution you will also need the Windows Azure PowerShell Cmdlets on the web server. See this article for configuring your publish settings with the PS cmdlets.
I will use the cmdlets to discover the VM names in my web farm without having to manually keep track of them. This helps if you need the ability to grow and shrink your web farm at will without updating your synchronization scripts.

The tool I will use for content sync is Web Deploy 3.0. Download but do not install Web Deploy 3.0.

Web Deploy works by a starting a remote agent that listens for commands from either Visual Studio or the MSDeploy.exe client. By default it will listen on port 80. This default port configuration will not work in a load balanced environment.

To install on an alternate external port such as 8080:
C:\WebDeployInstall>msiexec /I webdeploy_amd64_en-us.msi /passive ADDLOCAL=ALL LISTENURL=http://+:8080/

Once installed you will need to configure a firewall rule to allow traffic in on port 8080 for publishing and synchronization.

Now that the image is configured you will sysprep the vm to remove any unique characteristics like machine names etc. Ensure you have Enter System-Out-Of-Box Experience, Generalize and Shutdown all selected.

Once the VM status is shown as shut down in the Windows Azure Management portal highlight the VM and click capture. This will be the customized image you can use to quickly provision new VMs for your web farm using the management portal or powershell.

Ensure you check I have sysprepped this VM and name the image WebAppImg and click the check mark button to capture the image.

Step #2 – Virtual Machine Deployment

Once the image has been created you can use the portal or the Windows Azure PowerShell cmdlets to provision the web farm.

Here is a PowerShell example of using the new image as the basis for a three VM web farm.

A few things to note: I have created a load balanced endpoint for port 80 but for 8080 I’m only selecting a single server.
This server will be the target server for publishing from Visual Studio that will then be used as the source server for publishing to the other nodes in the web farm.

$imgname = 'WebAppImg'
$cloudsvc = 'MyWebFarm123'
$pass = 'your password'

$iisvm1 = New-AzureVMConfig -Name 'iis1' -InstanceSize Small -ImageName $imgname |
	Add-AzureEndpoint -Name web -LocalPort 80 -PublicPort 80 -Protocol tcp -LBSetName web -ProbePath '/' -ProbeProtocol http -ProbePort 80 |
	Add-AzureEndpoint -Name webdeploy -LocalPort 8080 -PublicPort 8080 -Protocol tcp | 
	Add-AzureProvisioningConfig -Windows -Password $pass
$iisvm2 = New-AzureVMConfig -Name 'iis2' -InstanceSize Small -ImageName $imgname |
	Add-AzureEndpoint -Name web -LocalPort 80 -PublicPort 80 -Protocol tcp -LBSetName web -ProbePath '/' -ProbeProtocol http -ProbePort 80 |
	Add-AzureProvisioningConfig -Windows -Password $pass
$iisvm3 = New-AzureVMConfig -Name 'iis3' -InstanceSize Small -ImageName $imgname |
	Add-AzureEndpoint -Name web -LocalPort 80 -PublicPort 80 -Protocol tcp -LBSetName web -ProbePath '/' -ProbeProtocol http -ProbePort 80 |
	Add-AzureProvisioningConfig -Windows -Password $pass	
New-AzureVM -ServiceName $cloudsvc -VMs $iisvm1,$iisvm2,$iisvm3 -Location 'West US'

Once the VMs are provisioned RDP into iis1 by clicking connect in the management portal. This is where you will configure a PowerShell script that will run MSDeploy to synchronize content across the other servers.

Inside of the iis1 virtual machine create a new text file named sync.ps1 in a directory off of your root such as C:\SynchScript and paste the following in (ensuring that you update $serviceName with your cloud service name).

Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1'

$publishingServer = (gc env:computername).toLower()


Get-AzureVM -ServiceName $serviceName | foreach { 
    if ($_.Name.toLower() -ne $publishingServer) {
       $target = $_.Name + ":8080"
       $source = $publishingServer + ":8080"

       $exe = "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe"
       [Array]$params = "-verb:sync", "-source:contentPath=C:\Inetpub\wwwroot,computerName=$source", "-dest:contentPath=C:\Inetpub\wwwroot,computerName=$target";

        & $exe $params;

This script enumerates all of the virtual machines in your cloud service and attempts to run a web deploy sync job on them. If you have other servers in your cloud service like database etc.. you could exclude them by filtering on the VM name. Note: Web Deploy supports MANY more operations other than just synchronizing directories. Click here to find more information.

To enable content synchronization you will need to create a new scheduled task by going into Control Panel -> Administrative Tools -> Scheduled Tasks -> Create a new Task.

Accept the defaults for everything except when it gets to the action screen.

Program/Script: powershell.exe
Parameters: -File C:\WebDeployInstall\sync.ps1

Open the properties of the new task and you’ll need to modify the schedule to synchronize content fairly often so content isn’t out of sync during a publish.

Ensure you select Run Whether User Is Logged on or Not. You will need to provide an account for the task to run as. I’m choosing the administrator account because I am lazy. However, you could create new duplicate accounts on each of the VMs to use for synchronization.

Step #3 – Publishing with Visual Studio

Finally, to test the configuration create a new MVC app and tweak the code slightly to show the computer name.

Now right click on the project and select publish. In the drop down select new profile.

In the settings page add your cloud app url and append :8080 to it for the service URL.
Set the site/app name to Default Web Site
Set the Destination URL to your cloud app url (without :8080)

Finish the wizard and let Visual Studio publish.

When the web app first launches you may or may not see the new content. It may show the default IIS8 content. As soon as the scheduled task runs the content should sync across all of the servers.

Once it has synchronized press CTRL F5 a few times and you should see the content with the individual machine names to verify the load balancing is working.

In this post you have seen how you can configure a custom OS image that can be used to provision virtual machines for a web farm. You have then seen how you can use Web Deploy along with PowerShell to synchronize content published from Visual Studio across all of the servers in your farm.

Automation is great 🙂

HTTP Error Message: The location or affinity group East US specified for source image

If you run into the following error trying to create VMs with PowerShell:

New-AzureVM : HTTP Status Code: BadRequest – HTTP Error Message: The location or affinity group East US specified for source image MSFT__Windows-Server-2012-RC-June2012-v1-en-us-30GB.vhd is invalid. The source image must reside in same affinity group or location as specified for hosted service West US.

The problem is your storage account is in a different location/affinity group then the VNET you are deploying to. There may be other causes but I hit this one today and thought it was a strange enough message to blog it so I would remember 🙂