What is Azure Private Link?

Azure Private Link is a technology designed to provide private connectivity to selected PaaS services, customer-owned and partner offered services.

Private Link allows you to access services over a private endpoint deployed into your virtual network. All traffic privately traverses the Microsoft global backbone, eliminating any exposure to the public internet and increasing security.

With no need for additional network resources such as gateways, NAT devices and public IP address network complexity is also reduced.

There are two key components of Azure Private Link:

  • Private Endpoint – a network interface connected to your virtual network, assigned with a private IP address. It is used to connect privately and securely to a service powered by Azure Private Link or a Private Link Service that you or a partner might own.
  • Private Link Service – your own service, powered by Azure Private Link that runs behind an Azure Standard Load Balancer, enabled for Private Link access. This service can be privately connected with and consumed using Private Endpoints deployed in the consumer’s virtual network.

Benefits of Private Link

  • The service can be used to connect virtual networks with overlapping address spaces
  • Secures access to services over the Microsoft backbone
  • Allows private access to services running in Azure from on-premise or peered networks
  • The service can connect to resources running in other regions offering global reach
  • Ability to enable private link access to your services
  • Supports various PaaS, partner and customer-owned services

An up to date list of services that support Private Link and region availability can be found here.

How do Private Endpoints differ to Service Endpoints?

One key difference between the technologies is that although a Service Endpoint can be restricted to only accept access from a specific virtual network, it is still accessed over a public endpoint. This is in contrast to a Private Endpoint which is created with a private IP.

Service endpoints are also only locked down to a specific service, not a specific resource. Whereas with Private Link, the private endpoint allows more granular access to the specific sub-resource.

Creating a Private Endpoint

Private Link Center is the management tool used for creating and managing Private endpoints and Private link services. In the search bar at the top of the Azure portal type private link, then select the service from the dropdown menu.

To begin creating a private endpoint, select Private endpoints from the left menu. Then from the top ribbon click + Add to open the Create a private endpoint wizard.  

The first thing we need to do is name the endpoint instance and define where it is to be created. Not only geographically in terms of the region but also in which subscription and resource group.

Now we need to define which resource and sub-resource the private endpoint allows access. Selecting a resource in your own directory is done using drop-down menus. Initiating a connection request to a resource in another tenancy is achieved using the resource ID or alias.

In this example, we are configuring the Private Endpoint to provide access to Blob storage. File Shares, Queues or Tables will not inherit the same access permissions. This enables us to be prescriptive and secure resources to a level not possible using Service Endpoints.

The next step is to configure the virtual network and subnet where the endpoint will be deployed.

It is also advised that a private DNS record is created and used when accessing the service via the endpoint. This can either be hosted by your own DNS solution or integrated with an Azure private DNS zone.

To make testing in this example easier, we will choose to integrate with an Azure private DNS zone.

The penultimate step is to define any tags before clicking Review + Create.

Assuming that validation passes successful, the final step is for us to click on Create to kick off the deployment process.

Browsing to the newly created endpoint, we can see from the overview page details such as its network interface, the virtual network and subnet its connected, FQDN and assigned private IP address (

Jumping to the storage account the endpoint was linked with and expand the Firewall and virtual network tab. We see that the only access allowed is for trusted Microsft services.

Switching to the Private endpoint connections tab, we should be able to see listed the private endpoint that’s just been created. If configured correctly, the connection state should appear as Approved.  

Now everything has been configured, we can go ahead and test access to the storage account is only allowed through our private endpoint.

From a virtual machine connected to the same virtual network, open a PowerShell console and enter nslookup The command-line utility outputs DNS details including the IP address registered with the DNS name. In our example, the IP address output matches the private address assigned to our endpoint.

Another way to test the endpoint is working as expected is by using Azure Storage Explorer that can be downloaded here.

Open Azure Storage Explorer, right-click Storage Accounts and then select Connect to Azure storage from the popup menu. Enter the connection string that can be copied from the Access Key blade of the storage account and then click on Connect.

We now have access to blob containers and the ability to create, browse, edit and delete.

When associating a resource and sub-resources to the endpoint, we selected Blob within the storage account. Due to the increased granularity that Private Endpoints offer when attempting to browses File Shares, Queues or Tables, access fails as expected.

For completeness, let’s run Azure Storage Explorer on a machine that’s not connected to the same virtual network. Now when attempting to connect to the storage account, this action fails with the following error message.

To learn more about Azure Private Link, head over to Microsoft docs:

Azure Networking

Test Network Speed and Latency to Azure

Just a quick post to mention one of the many Azure tools out there. This one in particular is for the network admin who have the need or are just interested in checking network connection speed and latencies to the Azure data centres.

TestLat001 comes with a number of useful tests and is ideal during the project planning stage. For example, when planning to migrate a LOB application to Azure, which region would offer the best user experience.

Features include:

Latency Test
This test allows administrators to test network latency to Azure Storage in worldwide data centres.

CDN Test
This is currently unavailable do to attackers.

Upload Speed Test
This test makes it possible to checkout upload speeds to Azure Blob Storage located in different worldwide data centres.

Large File Upload Speed Test
This test allows administrators to test large file uploads to Azure Blob Storage, again in worldwide data centres, with additional upload options.

Download Speed Test
As the title suggests, this test monitors download speeds from different data centres when downloading a 100MB file.

Live Streaming Latency Test
Test latency from remote Azure Media Services live streaming.

Cloud Region Finder
Cloud Region Finder enables you to quickly lookup cloud and region information of application deployment, try it by entering url or ip address now! Currently Azure, AWS, AliCloud are supported.

Traffic Manager Test
Demonstrates the capability’s of Azure Traffic Manger.

Azure Online Tools available.
Additional Azure Online Tools.

A short but hopefully interesting post and well worth a quick visit! 🙂


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 🙂


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.



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


Azure VPN Gateway High Performance SKU

I have recently been involved in work that required me to change the Azure VPN Gateway SKU from Default to High Performance. This wasn’t something I was aware of so I a spent a little time investigate it. It turns out that Microsoft announced the ability to change the SKU at TechEd Europe 2014, a little gem that I had obviously missed!

When using a standard Site-to-Site VPN the SKU can be configured as

  • Default throughput 80Mbps with the maximum of 10 S2S tunnels
  • High Performance throughput 200Mbs with the maximum of 30 S2S tunnels

If using ExpressRoute these speeds are increased to

  • Default throughput 500Mbps with the maximum of 10 S2S tunnels
  • High Performance throughput 1000Mbps with the maximum of 30 S2S tunnels

It does come at a cost and in my view perhaps not as good value for money for most deployments as the default SKU. However it might well be the right fit for customers without a datacentre presence or reluctant to buy into Express route at this time.

At the time of writing this post the approximate costs are

  • Standard = £.053 for 24 hours (max 80mbs)
  • High Performance = £7.19 for 24 hours (max 200mbs)

NOTE: Data transfer and inter-VNet traffic rates remains unchanged

As with most things funky in Microsoft Azure, this is currently configured via PowerShell and requires at least version 0.8.12

To create a High Performance Gateway

New-AzureVNetGateway –VNetName vNetName –GatewayType DynamicRouting –GatewaySKU HighPerformance

To update the Gateway SKU to High Performance

Resize-AzureVNetGateway –VNetName vNetName –GatewaySKU HighPerformance

NOTE: Changing the Gateway SKU is not a quick process and changing it in my demo environment took approximately 45 minutes to an hour.

To change the Gateway SKU from High Performance back to Default

Resize-AzureVNetGateway –VNetName VNetName –GatewaySKU Default

Perhaps not for everyone but as its possible to revert back to the default SKU at anytime, it could be something that is used for short periods to help with abnormal data transfers.

For more information on this, check out these links.

Azure Virtual Network Gateway Improvements
Crank Up Your Azure VPN with the New High-Performance Azure VPN Gateway!
Taking new Azure High Performance Gateway for a Test Drive


Creating Self-Signed Root and Client Certificates

Recently I have found the need to create Self-Signed Certificates increase whilst working with Microsoft Azure. One example of this is when configuring a point-to-site VPN and another has been when installing ADFS in demo environments.

There are a number of ways that this can be achieved but I have found the easiest way to create a certificate is to use the makecert tool that is included in Microsoft’s Visual Studio.


To create a Self-Signed Root Certificate:

Open the Visual Studio Express desktop Tools CMD line as Administrator

At the command prompt run the following command changing “RootCertificateName” to the name that you want to use for the certificate.

makecert -sky exchange -r -n "CN=RootCertificateName" -pe -a sha1 -len 2048 -ss My "RootCertificateName.cer"


makecert -sky exchange -r -n "" -pe -a sha1 -len 2048 -ss My "c:\temp\"

The command creates and installs a Root Certificate in the Personal Certificate store and also creates a corresponding .cer file that you can use to upload to the Azure Management Portal if required.

NOTE: Having created a root certificate from which client certificates will be generated, it is advisable to export this certificate along with its private key and keep somewhere safe.


To generate a Self-Signed Client Certificate:

Open the Visual Studio Express desktop Tools CMD line as Administrator

At the command prompt run the following command changing “RootCertificateName” to that of the root certificate created above and “ClientCertificateName” to the name of the required client certificate.

makecert.exe -n "CN=ClientCertificateName" -pe -sky exchange -m 96 -ss My -in "RootCertificateName" -is my -a sha1


makecert.exe -n "" -pe -sky exchange -m 96 -ss My -in "" -is my -a sha1

The result will be a client certificate named “ClientCertificateName” in your Personal Certificate store.

NOTE: Microsoft recommendation when working with point-to-site VPN is that you create unique client certificates for each computer that you want to connect to the virtual network.


Exporting the Client Certificate:

The final stage to the process is to export the client certificate from your Personal Certificate store so it can be then installed on the client machine that requires it.

To export the client certificates, first of all open certmgr.msc

Right click on the client certificate that you want to export, click all tasks, and then click export.

Exporting the Client Certificate with the private key will create a .pfx file in the location that you specify during the export process. As before make sure to record the password that you set for this certificate.

Finally, copy the .pfx file to the client computer and double click to install. During the install leave the location unmodified and input the password when required.


ADFS 3.0 Error on Server 2012 R2

I have deployed various ADFS servers in production environments and this error is something that until recently I had not seen. I had quickly installed a couple of ADFS servers into my test environment ready for some planned demos when I came across it.

It turned out to be something silly that I had missed, but I thought it would be worth mentioning just in case someone else encountered it.

With ADFS installed and configured, its time to verify the federation service metadata. Normally this looks like the XML file in the screen shot at the end of this post but on this occasion it displayed the following output instead.

AddressThe e-mail address of the userGiven NameThe given name of the username……………..


It turned out that in my haste, I had over looked the following step from the Microsoft ADFS installation guide.

Make sure to configure your browser settings to trust the federation server role by adding your federation service name (for example, to the browser’s local intranet zone. This will enable seamless sign-in using Windows Integrated Authentication.

Recommended Action

Configuring IE to trust the federation server role is a fairly simple task. The first step to the process in to select Tools | Internet Options | Security Tab | Local Intranet.

From this window, click on the Sites button.

Finally, from the next popup click on the Advanced button. Add the federated service name to the list of trusted websites, then close down all the various windows.

NOTE: For the purposes of my test environment I added the whole address space for the domain to the trusted websites. Normally this would have been the individual service name of

After adding the federated service name to the list of trusted Websites, everything looks as it should!



Assigning static IP to an Azure VM

As cheap as Microsoft Azure is, keeping cost down is one of the main concerns to any organisation. One of the ways to do this when running IaaS in the cloud, is to power off virtual machines when they are not required.

When stopped, Azure VMs will remain in one of two different states:

Stopped (StayProvisioned)
Stopped (Deallocated)
Stopping a VM from within the guest OS or by using the Stop-AzureVM with the -StayProvisioned switch will power the VM off but leave it in the StayProvisioned state. This will leave any allocated resources attached to that VM,  such as its network adapter.

Stop-AzureVM -ServiceName "myservice1" -Name "MyVM" -StayProvisioned

In this state, IP addresses assigned via DHCP stay assigned to the VM for when its next powered up. Initially this sounds great, but whilst in this state, although the VM is stopped, the resources that remain attached are incurring billing.

However, a virtual machine stopped using the SHUT DOWN button from the Azure Portal


or by using the Stop-AzureVM without the -StayProvisioned switch, powers off the VM and places it into a Deallocated state.

Stop-AzureVM -ServiceName "myservice1" -Name "MyVM"

In this state its resources are not reserved and released back to the Azure fabric. When it comes time to power the VM back up, all recourses are reprovisioned including the network adapter and an new IP address. The benefit of a VM in the Deallocated state is that it will not incur any billing, the downside is that it could have a different IP address the next time it starts up.

So how do we achieve the best of both worlds?

Since the release of PowerShell cmdlets for Windows Azure version 0.7.3 released at February 12, 2014  it is possible to glue a static IP-address to a particular virtual machine. So even if a VM is not running for a while and in the Deallocated state, it will receive it’s originally assigned IP-address at boot.

To test if an IP address is already in use in the subnet

Test-AzureStaticVNetIP -VNetName "TechKB ADFS Virtual Network" -IPAddress


To assign a static IP address

Get-AzureVM -ServiceName CloudServiceName -Name VMName | Set-AzureStaticVNetIP -IPAddress | Update-AzureVM


To remove a statically assigned IP address

Get-AzureVM -ServiceName CloudServiceName -Name VMName | Remove-AzureStaticVNetIP | Update-AzureVM


The following PowerShell code lists all virtual machines, their cloud service, and whether they have an assigned, reserved IP address.

Get-AzureVM | Select-Object -Property Name, ServiceName, @{Name='ReservedIP';Expression={(Get-AzureStaticVNetIP -VM $_ ).IPAddress}} | Format-Table -AutoSize


And that’s all for this post, hope it help!