Changing an Azure Virtual Network connection from site-to-site VPN to ExpressRoute

With more businesses becoming reliant on the cloud and on-premises datacenters being extended to Azure, ExpressRoute is becoming ever more popular. For customers that already have in place a site-to-site VPN, one of the first things to do after the ExpressRoute circuit has been previsioned is to switch the virtual network connection from a site-to-site VPN to the ExpressRoute circuit.

The following article works through the various steps involved in this process, including:

  • Checking the status of the ExpressRoute circuit
  • Updating the Virtual Network configuration
  • Linking ExpressRoute to the Virtual Network

NOTE: Migrating an existing virtual network from a site-to-site VPN to an ExpressRoute circuit will cause a short amount of lost connectivity between your on-premises network and your virtual network.

If like me you have access to multiple Azure subscriptions, the first thing to do is check you are in the right one. Using the cmdlet below we can pull back the details for the subscription that we are currently working in.

Get-AzureSubscription -Current

To change subscriptions if required use:

Select-AzureSubscription -SubscriptionID "Subscription ID"

Once working in the correct subscription it is time to import the ExpressRoute PowerShell module. The module doesn’t load by default when PowerShell is run but it is found on the local drive and was installed by the Azure PowerShell installer.

To import the module run:

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


Checking the status of the ExpressRoute circuit

It is now possible to check that the ExpressRoute circuit has been provisioned correctly and is in the correct state. Use the Get-AzureDedicatedCircuit cmdlet to pull back information about the current circuits.

Before its possible to assign this circuit to a virtual network we need to make sure that the ServiceProviderProvisioningState is Provisioned and that the Status is Enabled. Once this is the case the circuit is ready!


Updating the Virtual Network configuration

The first thing we need to do to is update the configuration of the virtual network gateway. To do this we need to first remove the current gateway which will then allow us to make configuration changes. This can be done via the portal and clicking on the Delete Gateway button or by using the Remove-AzureVNETGateway PowerShell cmdlet.

The next step in configuring the virtual network involves resizing the existing gateway subnet. The site-to-site gateway supports a maximum size of a /29 subnet whereas the ExpressRoute gateway supports a minimum gateway subnet size of /28. As always this can be done either in the management portal or via PowerShell.

After resizing the gateway subnet but before recreating a new gateway, we need to configure the virtual network for an ExpressRoute connection. To do this open the virtual network configuration tab and check the Use ExpressRoute checkbox in the management portal then click save.

The final step in upgrading the virtual network configuration is to create a new Gateway. From within the management portal click the CREATE GATEWAY button to recreate the gateway.

Once the gateway has completed provisioning, the final stage is to link the virtual network to your existing ExpressRoute circuit.

Linking ExpressRoute to the Virtual Network

At this point we can double check the ExpressRoute circuit is still in the correct state,  then finally link the circuit with the virtual network.


$Vnet = "VirtualNetwork-1"
$ServiceKey = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
New-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet


A full listing of ExpressRoute PowerShell Cmdlets can be found in this Microsoft article Azure ExpressRoute PowerShell Cmdlets

That’s it for this post, hope its of some help 🙂


August Updates to Azure Backup


Yesterday (24th August 2015) Microsoft announced the addition of new features to Azure Backup’s support for Azure IaaS VMs.

Some of the new features include:

  • Improved data disk limits with the support for 16 data disks in addition to the OS disk per VM
  • Improved retention and flexibility with terms up to 99 years and flexible customisation of retention choices
  • Enhanced monitoring and reporting
  • Ability to configure protection of offline VMs, cancel in-progress jobs and more.

In addition, Microsoft continue to push how reliable and simple Azure backup can be, advertising how a basic VM backup can be achieved in three simple steps.

To read more on this and see the full feature list, check out this Azure blog Azure Backup update – New features in IaaS VM backup support


Adding Partner of Record to an Azure subscription

If you have been working with O365 for some time, one thing you would have come across would be the ability to add your company as the Partner of Record for your customers O365 tenancy.  This setting has made it across to Azure and it’s now possible to add yourself as Partner of Record within an Azure subscription. As you would imagine, it’s very straightforward to make this change.

1. The first step is to browse to and login.

2. Then click on the Subscriptions tab followed by the subscription that you wish to update the settings.

3. From here you will see the following menu displayed down the right hand side of the page.


4. Select Partner Information from the menu, this will popup the Partner Information dialog box.


5. Type your MPN ID into the Microsoft Partners ID box and click on the check to finalise the update.

I would recommend updating this wherever possible, however, although there is no impact on support or services that your customer get from Microsoft, it’s important to make sure they are happy for you to be the Partner of Record for their subscription. Longer term not only will it allow you to keep up to date with any communications between Microsoft and your customer but there are plans moving forward for Microsoft to use this to allow your customers Azure consumption to count towards competencies and so forth.

NOTE: This is being rolled out gradually and you may find the option is currently greyed out or missing in older subscriptions.


Using Network Security Groups in Azure to create a DMZ

More and more enterprises are extending their datacentre to the cloud and making use of these resources to deploy ever more complex solutions. As with on-premises infrastructure, it is quite often necessary to setup up different security zones in the cloud i.e. Trusted and DMZ.

On-premises we tend to deploy firewall appliances which are used to achieve this segmented networking infrastructure. However when deploying infrastructure to Azure, this option is not available to administrators. Microsoft Azure allows administrators to control the traffic in subnets using the Network Security Group (NSG) feature. Using an NSG makes it possible to create a subnet with restricted access from the other Azure subnets and also on-premises network.

Network security groups give the ability to configure rules and control inbound and outbound network traffic that can then be assigned to a single VM or a whole subnet and all the VMs within it.

The main reason I have used NSGs has been when deploying ADFS to Azure. A typical deployment has two domain controllers, two ADFS servers and single ADSync server in a trusted subnet and then two WAP servers in the DMZ subnet.

For example:

Azure NSG

Configuring Network Security Groups is currently via Azure PowerShell as shown below.

Deploying a Network Security Group:

The first thing to do when deploying a Network Security Group is to create a default NSG. Use the PowerShell command below giving it a name, location and a label for the NSG.

New-AzureNetworkSecurityGroup -Name "WAP-HTTPS" -Location "North Europe" -Label "Security group for DMZ Subnet"

Once the NSG has been created we can display the default rules that have been associated with it.

View the NSG details:

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" -Detailed


The next step is to add any inbound rules to the NSG that we require. That is inbound traffic to the subnet that the NSG will be assigned to later. In this example it is inbound traffic to the subnet that will be used as the DMZ and house the WAP servers. These rules are not limited to allow but also deny rules.

Create Inbound NSG Rules:

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound RDP from ALL Internal Networks" -Type Inbound -Priority 101 -Action Allow -SourceAddressPrefix 'VIRTUAL_NETWORK'  -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '3389' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound HTTPS from Internet" -Type Inbound -Priority 110 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix "DMZ Subnet" -DestinationPortRange '443' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound RDP from Internet" -Type Inbound -Priority 111 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix "DMZ Subnet" -DestinationPortRange '3389' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Deny Inbound traffic to Trusted Subnet" -Type Inbound -Priority 200 -Action Deny -SourceAddressPrefix 'VIRTUAL_NETWORK'  -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '*' -Protocol '*'

Once all the inbound rules have been created its time to add outbound rules. Again this is outbound traffic from the subnet being used as the DMZ in this example.

Create Outbound Rules:

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Outbound HTTPS from DMZ Subnet" -Type Outbound -Priority 100 -Action Allow -SourceAddressPrefix 'VIRTUAL_NETWORK'  -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '443' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Deny Outbound traffic from DMZ Subnet" -Type Outbound -Priority 200 -Action Deny -SourceAddressPrefix 'VIRTUAL_NETWORK'  -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '*' -Protocol '*'

Once again at this stage we can use the ‘Get-AzureNetworkSecurityGroup’ cmdlet with the -Detailed switch as above to get a screen output of the rules now configured in the NSG.


The final step to the configuration is to assign the NSG to our DMZ subnet. This subnet is where the inbound and outbound rules will apply once the NSG has bound to the subnet.

Add the SG to the backend subnet:

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName "vNET" -SubnetName "DMZ Subnet"

NOTE: When making changes to an NSG, if they don’t appear to take effect immediately, allow plenty of time before making any further changes. It’s my experience that people can change good configuration, assuming what they have configured is not working.



Updating the Template Image of an Azure RemoteApp Collection

Following on from the post Using an Azure Virtual Machine as an Azure RemoteApp Template here is a short article on how to update the template image of an Azure RemoteApp collection.


A new corporate image has been provisioned with the latest Windows updates and a number of new corporate applications. This has been converted into a RemoteApp Template Image which now requires deploying to remote users. How do you update the Template Image of a collection without provisioning a new collection and reconfigure user access?

Updating the Template Image of a RemoteApp collection is a very easy process and can be achieved either via the GUI or PowerShell.

Using the GUI:

Browse to the RemoteApp service and select the collection that requires the Image updating. From the bottom menu click the Update button to initialise the Update RemoteApp collection Template Image wizard.

Once the Update RemoteApp collection Template Image wizard appears, select the new Template Image from the dropdown menu. Then choose how connected users are to be managed during the Image update.

There are two options:

  • Give users 60 minutes after the update. Selecting this option will send a popup message to all active users as soon as the RemoteApp collection has been updated, telling them to save their work and log off and back on. Any users that fail to follow the notice are automatically logged off after 60 minutes. Users can immediately log back on.
  • Sign users out immediately. Selecting this option will log off all users automatically without any warning as soon as the RemoteApp collection has been updated with the new template image. Users can immediately log back on. NOTE: If you choose this option, users might lose data.

Finally click on the tick icon to begin the update.

Once the RemoteApp collection has been updated with the new Template Image, open the collection and publish any new applications using the normal processes.


Via PowerShell:

To update the Template Image of a collection, use the following PowerShell command altering the RemoteApp collection name to the one that you wish to update and the name of the new Template Image.

Update-AzureRemoteAppCollection -Name <CollectionName> -ImageName <TemplateImage> -ForceLogoffWhenUpdateComplete

The RemoteApp PowerShell module has recently been updated with lots of new and updated cmdlets offering better administration. Below is a list of the cmdlets available since the latest update.

Basic RemoteApp Collection cmdlets:

  • New-AzureRemoteAppCollection
  • Get-AzureRemoteAppCollection
  • Set-AzureRemoteAppCollection
  • Update-AzureRemoteAppCollection
  • Remove-AzureRemoteAppCollection
  • Add-AzureRemoteAppUser
  • Get-AzureRemoteAppUser
  • Remove-AzureRemoteAppUser
  • Get-AzureRemoteAppSession
  • Disconnect-AzureRemoteAppSession
  • Invoke-AzureRemoteAppSessionLogoff
  • Send-AzureRemoteAppSessionMessage
  • Get-AzureRemoteAppProgram
  • Get-AzureRemoteAppStartMenuProgram
  • Publish-AzureRemoteAppProgram
  • Unpublish-AzureRemoteAppProgram
  • Get-AzureRemoteAppCollectionUsageDetails
  • Get-AzureRemoteAppCollectionUsageSummary
  • Get-AzureRemoteAppPlan

RemoteApp virtual network cmdlets:

  • New-AzureRemoteAppVNet
  • Get-AzureRemoteAppVNet
  • Set-AzureRemoteAppVNet
  • Remove-AzureRemoteAppVNet
  • Get-AzureRemoteAppVpnDevice
  • Get– AzureRemoteAppVpnDeviceConfigScript
  • Reset-AzureRemoteAppVpnSharedKey

RemoteApp template image cmdlets:

  • New-AzureRemoteAppTemplateImage
  • Get-AzureRemoteAppTemplateImage
  • Rename-AzureRemoteAppTemplateImage
  • Remove-AzureRemoteAppTemplateImage

Other RemoteApp cmdlets:

  • Get-AzureRemoteAppLocation
  • Get-AzureRemoteAppWorkspace
  • Set-AzureRemoteAppWorkspace
  • Get-AzureRemoteAppOperationResult


Hope this was of interest, even if short! 🙂


Event Update #001


With many of the recent events slowly drawing to a close, I thought it worth making note of some of the ones I will be involved with during the second half of the year.

Transform the Datacentre Workshop with Microsoft

  • The Microsoft Cloud Platform Vision
  • What’s coming in Windows Server and System Center 2016
  • Build your Private Cloud with Windows Server and Hyper-V
  • Build your Hybrid Cloud With Microsoft Azure
  • Manage your Hybrid Cloud with Microsoft System Center and Operations Management Suite

Transform the Datacentre Workshop with Microsoft

Azure Round Table Workshop

The Azure round table events have been very successful and we have had lots of positive feedback. For this reason new dates and locations have been added to the current schedule. This workshop is high level and starts with an overview of the Azure platform and then concentrates around some of the key areas that we believe offer the most value to customers. Numbers dependant, we are usually able to adjust the contents depending on attendees areas of interest.

  • Extending your private cloud with Microsoft Azure
    • Azure Overview
    • IaaS
    • Recovery Services (DR/Backup)
    • RemoteApp
    • StorSimple
    • Web App
  • Mobilise your workforce with Enterprise Mobility Suite
    • Microsoft Azure Active Directory Premium
    • Microsoft Intune
    • Microsoft Azure Rights Management

NEW Azure Webinar

For anyone who is unable to attend the round table events, a new Azure webinar is being offered which can be better tailored towards your enterprise requirements.

To find out more on these events and others checkout Latest News and Events



Using an Azure Virtual Machine as an Azure RemoteApp Template

RemoteAppProvisioning Azure RemoteApp collections requires the administrator to us a preconfigured Server 2012 R2 image. In the same way as with RDS on-premises the image is preinstalled and configured with all of the applications that are to be published to the remote users.

There are three image sources an administrator can currently use when provisioning a collection.

  • Use one of the preconfigured images Microsoft makes available
  • Create an image from a virtual machine built on-premises
  • Create an image from a virtual machine running in Azure

The preconfigured images that Microsoft offer are great for having a quick PoC up and working in a matter of a couple of hours but the recommended option if creating your own is to use an Azure VM.

It goes without saying that plenty of planning should be done when looking to move forward with a production RemoteApp deployment. It is a great Azure service and there are improvements being made all the time but as with everything there are currently some limitations to work with.

For example:

A single user can currently only be assigned to a single collection. Therefore splitting applications such as Office and other LOB applications across multiple collections is not always going to be possible. (I could be wrong but if on-premises RDS is anything to go by, one reason for this could be that a user profile disk can only be used in a single collection and not across multiple.)

As with anything Azure, things change rapidly but as of today, RemoteApp limitations to be aware of during the design phase are:

Resource Default limit
Collections per user 1
Published apps per collection 100
Paid collections 3 (you can request an increase)
Paid template images 25
Users – basic tier 400 (default)/ 800 (maximum)
Users – standard tier 250 (default)/ 500 (maximum)
Concurrent connections across all collections in a subscription 5000 (you can request an increase)
User data storage (UPD) per user per collection 50 GB
Idle timeout 4 hours
Disconnected timeout 4 hours

** Currently timeouts cannot be managed by GPO or configured by the administrator. They are only managed by the RemoteApp service.

More information about RemoteApp and other Azure Service Limits, Quotas, and Constraints can be found by following this link Azure Subscription and Service Limits, Quotas, and Constraints

Building a RemoteApp Template image in Azure:

There are two steps to creating a RemoteApp Template from an Azure VM.

  1. Create a Azure Virtual Machine image with all preinstalled and configured applications
  2. Import the Virtual Machine image in as an Azure RemoteApp Template

Creating a Azure Virtual Machine image

1. Create an Azure Virtual Machine using the “Windows Server Remote Desktop Session Host” image from the Azure Virtual Machine Gallery. This image contains the Windows Server 2012 R2 operating system with the Remote Desktop Session Host (RD Session Host) role installed and meets all the Azure RemoteApp Template image requirements.

2. Connect to the virtual machine and install and configure all of the applications that you plan to publish later on. (Check the image creation tips at the end of this post.)

3. Now all applications have been installed and configured as required, the image needs to be validated. Because the VM was created using the RDSH image from the Azure Virtual Machine Gallery, we have the luxury of double clicking on the “ValidateRemoteAppImage” shortcut on the desktop. This script validates the virtual machine is ready to be used as a RemoteApp image and checks that it is configured in line with all RemoteApp pre-requisites. If all checks pass successfully, the script even offers the option to run SYSPREP for you!

If the script reports back errors, make sure they are resolved before continuing to SYSPREP the image. 

To manually SYSPREP the virtual machine open an elevated command prompt and run the following:

C:\Windows\System32\sysprep\sysprep.exe /generalize /oobe /shutdown

(Do not use the /mode:vm switch even though this is a virtual machine)

4. Once SYSPREP has run and the VM has been shut down, capture the VM as a virtual machine image. To do this, select the correct VM from the list and click the capture button on the bottom menu.

5. When the capture wizard appears, give the image a name, description and check the box to say that SYSPREP has been run on the virtual machine. Doing this will remove the VM once it has been converted to an image. The final step to the process is to click on the tick to begin the import.

Once complete the image will appear under the virtual machine images tab.


Importing the Azure Virtual Machine image in as an Azure RemoteApp Template

1. Browse to the RemoteApp service and the TEMPLATE IMAGES tab at the top. If it’s the first image in the library click on IMPORT OR UPLOAD TEMPALTE IMAGE to open up the next wizard.

If an image already exists, click on the + on the bottom menu bar to begin adding a new image.

2. Select Import an image from your Virtual Machine library (Recommended).

3. Select the Virtual Machine image from the drop down list and check the box to confirm that all the correct steps were taken in creating the virtual machine image.

4. Give the RemoteApp template image a name and location and finish by clicking on the tick button.

When imported, the RemoteApp Template Image is available to the administrator when creating a new RemoteApp collection.

It is possible as mentioned earlier in the post to upload an image that has been created on-premises and I may cover this in a later post, but using an Azure Virtual Machine is a much easier process and Microsoft recommended approach.

The following are a few tips that Microsoft suggest to use when creating the Template image:

  • Check all applications to be published have start menu shortcuts. This will make publishing the applications much simpler later.
  • Disable automatic software updates for published applications.
  • Install the RDSH role before installing applications to ensure that any issues with application compatibility are discovered before the image is uploaded to RemoteApp. (This is already the case with the Azure RDSH gallery image)
  • Create a local user i.e. sysadmin and add them to the local administrators group and Remote Desktop.
  • Scheduled tasks do persist after SYSPREP.
  • Disable automatic software updates for published applications.
  • Never store data on instances (c:\ drive).

That’s it for this post, its quite a long one but hope people find it useful. 🙂


Azure RemoteApp Webinar Recordings

Customer interest in Azure seems to have gone through the roof in the past few months which has been great! The down side of this has been I have been distracted from updating as much as normal. Initially most of the interest appeared to be in Azure Backup and AzureAD but this has now extended to include Site Recovery, ADFS in Azure IaaS, StorSimple and especially RemoteApp with its recent updates.

More blog posts are on the way shortly but to keep things ticking over, here is a quick RemoteApp post for today. If  you are interested in Azure RemoteApp, follow the link below to find a great list of recorded Microsoft webinars well worth a checking out!

RemoteApp Webinars

UPDATE: Microsoft have added this great set of RemoteApp Core Skills videos to the MVA.

Microsoft Virtual Academy – Azure RemoteApp Core Skills


Reserved Public IP Addresses in Microsoft Azure

I have been involved in a number of ADFS deployments in Azure over the past few months and one thing that has had to be taken into consideration was the fact that by default Azure creates a cloud service with a dynamic public VIP.

This is especially an issue when creating the web application proxy cloud service. If for some reason the cloud service were to stop (i.e. funds run out) and the resources be deallocated the public VIP associated with the external HTTPS load balancer would be lost. If the cloud service were to be restarted, it would be allocated a different public VIP meaning the external DNS records for the ADFS service would be wrong. Depending on the TTL of the DNS record, any updates could take some time to filter through and cause the service to be unavailable.

To prevent this happening Microsoft have made it possible to request Reserved IP addresses although a few things should be kept in mind.

  • Reserved IPs can only be used for VMs and Cloud Services.
  • You can use PowerShell or the Azure Management REST API to request a reserved IP from a particular region. The Azure Portal does not currently allow you to do this.
  • Up to 20 Reserved IP addresses can be requested per subscription, however only the first 5 are free after which they are charged.

Create and assign a Reserved VIP to the Subscription

New-AzureReservedIP –ReservedIPName MyReservedPublicIP –Location “North Europe”


List the Reserved VIP assigned to the Subscription



Once an IP is reserved, it remains associated to your subscription until you delete it. To delete the reserved IP shown above, run the following PowerShell command:

Remove-AzureReservedIP -ReservedIPName "MyReservedIP"


Historically it has been essential to request a reserved IP before creating a cloud service or VM to which it will ultimately be assigned during their creation. If this had not been thought of at the point of the initial deployment, this could result in the need to tear down the environment and redeploy.

Thankfully this has now changed and its possible to convert a Dynamically assigned VIP to a Reserved public VIP. In this example I have created a cloud service called “techkbtest” the screenshot below shows the dashboard of the cloud service and the Public (VIP) address of currently dynamically assigned to it.


The snippet below shows the reserved VIP currently assigned to the subscription. Obviously the list is empty because at this point the public VIP assigned to the cloud service above is still dynamic.


Using the command below a request can not only made for a reserved IP but also that the dynamic VIP currently assigned to the cloud service “techkbttest” is used and converted.

New-AzureReservedIP -ReservedIPName "WasDynamicNowReservedIP" -Location "North Europe" -ServiceName "techkbtest"


Now when viewing any reserved VIP associated with the subscription, the newly created reservation is listed with the original Public VIP which has been associated with the cloud service all along.

For clarification, looking back to the dashboard of the cloud service shows that the Public (VIP) has definitely not changed.


It is now a lot easier to retrospectively change between dynamic and reserved VIP, however its still good practice to establish if this is required during the design phase and configure this from the beginning.

The following PowerShell creates a cloud service, requests a reserved IP, deploys a VM into the cloud service and finally binds the reserved IP to the cloud service.

$CSName = "Cloud-Service-Name"
New-AzureService -ServiceName $CSName -Location "North Europe"
New-AzureReservedIP –ReservedIPName WAPReservedIP –Location “North Europe”
$image = ""
$VMName = "Virtual-Machine-Name"
$AVSet = "Availability-Set"
$Subnet ="Subnet"
$VNetwork = "Virtual-Network"
$IP = ""
$dns1 = New-AzureDns -Name 'Google1' -IPAddress ''
$dns2 = New-AzureDns -Name 'Google2' -IPAddress ''
$vm1 = New-AzureVMConfig -Name $VMName -InstanceSize "Small" -AvailabilitySetName $AVSet -Image $image | set-AzureSubnet -SubnetNames $Subnet | set-AzureStaticVNetIP -IPAddress $IP
$pwd = "Pass1234"
$un = "MyAdmin"
$vm1 | Add-AzureProvisioningConfig -Windows -AdminUserName $un -Password $pwd
$vm1 | New-AzureVM -ServiceName $CSName -VNetName $VNetwork -DnsSettings $dns1,$dns2 -ReservedIPName WAPReservedIP

Additional Links

Reserved IP Overview
Azure Subscription and Service Limits, Quotas, and Constraints
Convert Existing Dynamic VIP to Reserved IP Addresses in Azure



Error 422 and 276 when deploying a Web Application Proxy Server

When deploying a Web Application Proxy server connecting to a AD FS 2012 R2 farm, the WAP server reports sporadic 422 and 276 errors.

  • Error 442: Unable to retrieve proxy configuration data from the Federation Service
  • Error 276: The federation server proxy was not able to authenticate to the Federation Service

Recommended Action:

The solution that I have found to be the most common, has been to bind the SSL certificate used for the ADFS service to a fallback or wildcard address. Follow these steps on all your ADFS 3.0 servers to add the fallback binding:

Make sure that you have installed all available updates for Windows Server 2012R2 after adding and configured the ADFS STS or WAP Proxy role.

  1. Open a Command Prompt as administrator
  2. To list all current SSL certificate bindings run the following command:
    netsh http show sslcert
  3. Mark and copy the ‘Certificate Hash’ value to notepad
  4. Mark and copy the ‘Application ID’ value to notepad
    (The Application ID is what will associate the binding with ADFS 3.0 (for the internal STS servers) and WAP (for the ADFS Proxy).
  5. Now run the following commmand, where you insert the noted ‘Certificate Hash’ and ‘Application ID’ values from above:
    netsh http add sslcert ipport= certhash=Insert_Certificate_Hash_Here appid={Insert_Application_ID_here}
  6. Restart machine and repeat steps for remaining ADFS 3.0 machines.

It’s also worth thinking about doing the same thing to WAP servers that use any kind of external load balancing.

Default application IDs:

  • ADFS: {5d89a20c-beab-4389-9447-324788eb944a}
  • WAP: {f955c070-e044-456c-ac00-e9e4275b3f04}

NOTE: If these changes are made, when the ADFS service certificate is renewed, these thumbprints will also need to be updated!

For further information checkout these links:

How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2
Understanding and fixing Proxy Trust CTL Issues with AD FS 2012 R2 and Web Application Proxy