How to add a NIC to an Azure Virtual Machine (ARM)

Hi all,

In this short post, I will show you how to add a  NIC (third, fourth…) to an Azure virtual machine under Azure Resource Manager and using Azure Powershell.

Before continuing, keep in mind:

– Not all the virtual machines sizes support multiple NICs. Check if your VM size is supported (

– The VM should already have at least two NICs. It’s not supported to pass from a single NIC VM to multiple NIC VM and vice versa

If you are creating the VM with multiple NICs (Use this post to do it), the resource group to which you are deploying the VM must contain only [multiple NIC]’s VM types. In other words, you cannot create a VM with multiple NICs in a resource group containing [single NIC]’s VMs It seems that this limitation was removed

– The VM will be rebooted when adding a virtual NIC

– You can use Azure CLI, Azure API or Powershell to make this operation. The portal does not provide a way to add a  NIC.

– In this post I’m using Azure Powershell 1.0. If you are using the 0.9.8 or prior, remove the ‘Rm’ suffix from your commands and change the mode to ResourceManager


This is easy, only two steps:

  1. Create a new Virtual NIC
  2. Attach the VNIC to the virtual machine

1- Create a new Virtual NIC

The first step is to create a Virtual NIC to associate it later to to the virtual machine. You will need to provide the following information:

  • The  Name of the virtual NIC to be created : $NICName
  • The Resource Group Name where the VNIC will be created : $NICResourceGroup
  • The location/region where the VNIC will be created, of course it has to match the VNET/Subnet location : $Location
  • The subnet ID to which you will connect the VNIC, you can get it via Powershell (See my example below) : $SubnetID
  • The IP address you want to assign to the NIC : $IPAddress


# Get the VNET to which to connect the NIC
$VNET = Get-AzureRmVirtualNetwork -Name ‘VnetV2’ -ResourceGroupName ‘RGNetworkV2’
# Get the Subnet ID to which to connect the NIC
$SubnetID = (Get-AzureRmVirtualNetworkSubnetConfig -Name ‘VNETV2Subnet01’ -VirtualNetwork $VNET).Id
# NIC Name
$NICName = ‘A3VM-NIC3’
#NIC Resource Group
$NICResourceGroup = ‘RG’
#NIC creation location
$Location = ‘north europe’
#Enter the IP address
$IPAddress = ‘’

#–> Create now the NIC Interface

New-AzureRmNetworkInterface -Name $NICName -ResourceGroupName $NICResourceGroup -Location $Location -SubnetId $SubnetID -PrivateIpAddress $IPAddress


2-  Attach the VNIC to the Virtual Machine

The second and last step is to associate the created VNIC to to the virtual machine. You will need to provide the following information:

  • The virtual machine Name : $VMname
  • The Virtual machine resource Group : $VMRG


$VMname = ‘VMname’
$VMRG =  ‘VM-RG’

#Get the VM
$VM = Get-AzureRmVM -Name $VMname -ResourceGroupName $VMRG

#Add the second NIC
$NewNIC =  Get-AzureRmNetworkInterface -Name $NICName -ResourceGroupName $NICResourceGroup
$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $NewNIC.Id

# Show the Network interfaces

#we have to set one of the NICs to Primary, i will set the first NIC in this example
$VM.NetworkProfile.NetworkInterfaces.Item(0).Primary = $true

#Update the VM configuration (The VM will be restarted)
Update-AzureRmVM -VM $VM -ResourceGroupName $VMRG

Azure : Virtual machine resizing consideration



This post is under review as things probably changed, and some configurations are supported by now.

You can refer to this Microsoft blog, where they explain the re-sizing considerations :

[ ]


Hi all,

After reading a blog post from one of my preferred bloggers, I noticed that there is a topic which is poorly documented, and  maybe, it’s an interesting idea to write about it : Resizing an Azure virtual machine.

After long hours of testing using the Azure Classic Portal, Azure portal (Preview) and Azure Powershell, I was finally able to get these results.

The following tables show all the resizing configuration paths:

From Basic  A-SeriesSnap 2015-10-11 at 11.51.52

Snap 2015-10-08 at 00.24.50


From Standard  A-SeriesSnap 2015-10-08 at 00.25.04

Snap 2015-10-08 at 00.25.27


From D-SeriesSnap 2015-10-08 at 00.25.44

Snap 2015-10-08 at 00.26.02


From Dv2-Series

Snap 2015-10-08 at 00.36.53

Snap 2015-10-11 at 12.53.26


From DS-SeriesSnap 2015-10-08 at 00.44.59

Snap 2015-10-08 at 00.45.11


From Standard A8/19/10/A11Snap 2015-10-08 at 00.26.57

Snap 2015-10-08 at 00.27.38

* The Azure preview portal may give you the possibility to resize the VM to a unsupported size. But this will not work

Important notes

  • When you resize a VM to an unsupported size (via the Preview portal),  the resize operation may  succeed  and the Azure notification will show a success notification. The new size is even reported on the VM configuration blade. However, the VM will never start even if the notification tab shows that it is.


Snap 2015-10-08 at 00.55.54

Snap 2015-10-08 at 01.03.02

  • Even with Powershell, a resizing operation may report success, but even if the VM starts, you will not be able to connect to it

Snap 2015-10-07 at 23.12.12

  • If the resizing operation is not supported and you are using the  Azure Service Management stack
    • If you make a tentative of a  non supported resize operation from PowerShell
      • A similar error message will be thrown : Compute.CannotUpgradeDeploymentToNewRoleSize : Unable to upgrade the deployment. The requested VM size ‘New VM size’ may not be available in the resources supporting the existing deployment. Please try again later, try with a different VM size or smaller number of role instances, or create a deployment under an empty hosted service with a new affinity group or no affinity group binding

Snap 2015-10-07 at 23.11.14

      • An event will appear on the notification window on the Preview Portal

Snap 2015-10-07 at 21.38.38

    • If you try to choose an unsupported size from the preview portal, the sizes will show grayed out. And the following info will be shown : This pricing tier is not available in the selected virtual machine’s domain name

Snap 2015-10-06 at 23.52.22

    • If you try to deploy a virtual machine to a cloud service that already contains a non-compatible VM sizes (Ex : You want to deploy a D-Series VM to a Cloud Service containing A-Series VMs), the Classic Portal VM creation wizard will prevent you from completing the creation operation : The cloud service you’ve selected doesn’t support the virtual machine size selected in the previous step

Snap 2015-10-06 at 23.51.24

  • If the resizing operation is not supported and you are using the  Azure Resource Management stack
    • When resizing the VM using the Preview portal, the Size will show grayed out and the following information will be shown : This size is not available on this Virtual Machine

Snap 2015-10-07 at 00.21.28


    • Resizing an ARM Virtual Machine from Powershell is not yet supported (I wonder when they are planning to add it !!)
    • There is no Cloud Service concept with Azure Resource Manager, VMs and resources are deployed within a Resource Group. A resource Group can hold a mix of resources and VMs with different sizes.


Additional information

  • Microsoft is stating on its official documentation (Though it comes from an MSDN discussion) that you may not be able to make some resize operations even if it’s supported by design. This is due to hardware limitations.

Some of the physical hosts in Azure data centers may not support larger virtual machine sizes, such as A5 – A11. As a result, you may see the error message Failed to configure virtual machine or Failed to create virtual machine when resizing an existing virtual machine to a new size; creating a new virtual machine in a virtual network created before April 16, 2013; or adding a new virtual machine to an existing cloud service. See the topic Error: “Failed to configure virtual machine” on the support forum for workarounds for each deployment scenario.

Snap 2015-10-11 at 12.42.43

The verdict

During this post, we saw that -in simple words- we cannot resize a virtual machine on Azure as expected. What we expect today from the ‘Cloud’, is a flexible Scale UP/ Scale Down and Scale In/ Scale Out features. Unfortunately, only the latter is provided by Azure, that means we can only scale the number of deployed VMs as expected (Via Auto-scale for example), but when it’s a matter of scaling UP/Down a virtual machine, we are faced to some limits. And the only choice is to recreate the virtual machine under the new Size/Series. I hope Microsoft will figure out a new way to enhance that.


Azure : Create an URL Rewrite Azure Web App

Azure Web apps provide a rapid and easy way to deploy web applications and publish them on Internet or attach them to your Azure virtual network, so they can be accessed by users.

In this post i will detail how to create an Azure Web app which the purpose is to make URL Rewrites.

Example :

–> The solution is to use an URL rewrite solution, which will redirect the simple URL to the composed URL. We can achieve this using an Azure Web app.

The following are the steps which will be conducted during this walk-through:

  1. Create an Azure Web app
  2. Configure the Azure Web app
  3. Create the URL Rewrite Configuration file
  4. Upload the configuration file to the Azure Web app
  5. Create a Public CNAM DNS record which redirect the Simple URL to the Azure Web App URL

1- Create an Azure Web app

Connect to the Azure portal and sign in using a subscription Admin account

NB : I’m using the Azure preview portal but the classic portal can be used too.

Go to New + –> Web + Mobile –> Web App


The Web app creation wizard will show


Type the following information :



Example value

Web app

A suffix for the Web App public URL.

This will compose be the Public URL Name for this web app. It will be appended to ‘’, so choose a significant suffix. This suffix is public, that means, you may enter a suffix which is already used by another customer. I recommend including your enterprise name within the suffix since it’s hard that someone else used it.

The CNAM  that will be configured later will resolve to  this Public URL

Suffix : MyAzureURLrewrite

Public URL :


Choose the Subscription where to place this Web app France LAB – SAMIR FARHAT

Resource Group

Choose and Existent Resource Group or Create a new Resource Group for this Web app MyAzureURLrewriteRG

Now, click on App Service Plan



You can create a new Service Plan or use an existent Service Plan

To simplify the description, a Service Plan defines the properties of the underlying compute resources that hold your Web App. Consider the service plans  as different machines with different performances level. A service plan can host one or more Web apps (just like a machine can hold one or more IIS websites)

If you decide to create a new Service Plan, click Create New

Type the Flowing Information



Example value

App Service plan

Choose a name for your service plan MyBasicPlan


Choose a location where to place this Service Plan (This where the Web App will be hosted too) North Europe

Pricing Tier

This allow you to choose between the different tiers. You can look here (Azure Service Plans tiers Pricing) for more information about the Service Plan tiers

NB: You can upgrade from one tier to another when needed

B1 Basic

Now, you can click on Create. You web app will start deploying.


2- First Configuration steps for the Web App

Go to Browse ALL –> Web Apps and select the Created Web App


2.1- Verify that the Web App is published

Click on the Web App URL. You will be redirected to the Web App. A page with the ‘This web app has been successfully created‘ should appear.


2.2- Add custom domain and SSL Certificate

Because you will not use the in the real life, and use instead, a custom URL containing your domain prefix (, we should declare which domains will be targeted on this Web app and which SSL Certificate will be used.

Go to All settings –> Custom domains and SSL



2.2.1- Add an External domain

Click on Bring External Domains


Add your domains prefixes. Example :

NB : As mentioned on the wizard, Azure must verify that you are the owner of this domain name. So you should create a CNAME in a public DNS provider that match your domain to the the Web app public URL ( –> or –>

2.2.2- Add the SSL certificate for the domain

Now that you successfully added your domains to the Web app configuration, you should bind a certificate which will secure your website when it’s accessed via URLs which contains your domain name.


In our case, we want to redirect to this Web App ( So the user accessing this web app will tape in the browser. The certificate have to match the the requested URL, that means

Click on Upload Certificate and upload a Certificate that match your requested URL. The certificate must be of the PFX format (with the Private Key)


NB : If you will use this Web app as a redirect service for many URLs, this web App will receive requests on many names (, ,…), so to avoid uploading many certificates, you can use a wildcard certificate * (*

2.3- Setup the FTP parameters

Now, we need to configure the FTP user credentials in order to be able to connect (using FTP or GIT) to the Web App content.

Go to All settings –> Deployment Credentials




Example value

FTP/deployment user name

Type the User Name you would use. The user name can contain only letters numbers, hyphens and underscores, and must start with a letter. samirfarhat


Type a complex password **************

Confirm password

Retype the password *************

3- Configure the URL rewrite

After completing the previous steps, we can configure the URL rewrite service. The following steps will be conducted:

  1. Prepare the redirection configuration file
  2. Upload it to the Web application

3.1- Prepare the redirection configuration file

Download the following file (Web.config)

  • Open it with a text editor (Notepad or Notepad++)


  • Change the following information :



Example value


Type an identification name for this URL to be redirected SimpleURL


Type the URL of the application to which you want make redirect (the composed URL)


Type the URL on which the Web app will receive the request, the simple URL (You must respect the format, a ‘.’ is replaced by ‘\.’) SimpleURL\.samirfarhat\.com
  • Save the file and keep the same name (web.config)

NB: If you have more than one URL to redirect, just add a new rule to the same file, by copying/pasting the Rule ‘section’


3.2- Upload the configuration file to the Web App

We will use FTP to connect and upload files to the Web app.

You can use the Windows Explorer or a FTP client like Filezilla (Download Filezilla)

In my Example i will use the Windows Explorer.

  • On the Web App blade, locate the FTP hostname and copy thr URL (You can use the copy shortcut)


  • Open a Windows Explorer window and paste the copied URL. You will be prompted for the FTP credentials. Enter the credentials you already configured on the previous steps.


  • Go to site/wwwroot/ and paste the web.config file


  • You successfully created an URL rewrite Web app on Azure

NB: You may have to restart the Web App

4- Create the Public DNS CNAM record

This is the final step, you should now create a public DNS record which will redirect the desired URL ( to the Azure Web app URL (


The following is the content of the web config file.

<rule name=”SimpleURL” patternSyntax=”ECMAScript” stopProcessing=”true”>
<match url=”(.*)” />
<action type=”Redirect” url=”” appendQueryString=”false” redirectType=”Permanent” />
<add input=”{HTTP_HOST}” pattern=”SimpleURL\.samirfarhat\.com” />

Migration paths from VMware to Microsoft Azure (Classic and ARM)

Hi all,

This page describes and presents the different approaches that an enterprise can think about when deciding to Migrate workloads from on-premise VMware platform to Azure. This page is a high level description where the different concepts will be explained, and a comparison will be conducted.

NB : This post also includes the possible actions (when applicable) to make in order to migrate the workloads to the Azure Resource Manager stack (IaaS V2)

1- What are the migration paths

There are many migration paths which can be used, but each one have it’s own advantages and disadvantages. The following table shows the different paths that will be discussed in this article:

  • Extend the application roles to Azure
  • Manual upload of the Virtual Machine’s virtual hard disks to Azure
  • Use MVMC (Microsoft Virtual Machine Converter)
  • Use Azure Site Recovery

2- Migration paths description

In this section, the different migration paths presented on 1- What are the migration paths. will be detailed, and the advantages and disadvantages of each one will be presented.

2.1- Extend the application roles to Azure

2.1.1- Description

This this the first path that can be took to migrate workloads to Azure. It depends on the application itself, and it’s not related to the OS underlying stack (Physical, Virtual, VMware or Hyper-V…).

This approach is only possible for application and workloads that supports high Availability or Load Balancing over multiple instances, and usually does not require using third party tools.


Active Directory Domain Services : If you have one domain controller, you can add an additional domain controller to your topology. This way, users or resources using these DCs can authenticate on either the first or the second DC. The migration path will be the following .

  1. Add a second domain controller on Azure
  2. Verify that users, servers and the other resources can successfully authenticate using the domain controller on Azure
  3. Transfer the FSMO roles to the Azure DC
  4. Stop the on-premise DC

–> This way, you migrated the ADDS infrastructure to Azure, in a transparent way, with zero downtime.

The following are the general steps that can be followed for any application that supports extending:

  1. Create 1 or more virtual machines in Azure. These VMs will hold the application roles that will be extended. The OS and VM configuration depends on the application.
  2. Extend the application role to the (or more) virtual machine in Azure
  3. Verify that the new server in Azure is operational and can handle the application services and requests. (A test plan should be run)
  4. Plan a transition step to ‘cut’ the on-premise server. This way, only Azure servers are requesting the application services.

The following ‘services’ can generally support this migration path:



Web services (IIS, Apache…)

The Web services generally support Load Balancing. Extending a Web service farm is usually supported.

Clustered services

Generally, any service which supports clustering (SQL Server, DHCP, Hadoop…) can use this migration path.

Multi-instances roles

They generally requested via a ‘weight’ or ‘priority’ mechanism. We can mention as examples: Domain Controllers, DNS servers…0

2.1.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:



  • Does not require resort to third-party tools
  • Zero or near-zero downtime
  • Fast and guaranteed rollback
  • Different extension method for each type application
  • Need specialized people, for each product to be extended
  • Change of the application configuration
  • Not applicable for standalone applications

2.2- Manual upload of the Virtual Machine’s virtual hard disks to Azure

2.2.1- Description

This this the second path that can be took to migrate workloads to Azure. This time, it doesn’t depend on the application.

This approach is applicable for both virtual and physical servers. And may need prerequisites prior to start the migration itself.

The next paragraph describes the different steps to successfully migrate workloads using this method:

Physical servers

  1. The physical server disks should be converted to the VHD format. There are two possible manners to do it :
    1. Use Disk2VHD : This tool can make an online conversion of physical server’s disks to  VHD files format. The obtained VHDs are a consistent point-in-time snapshots of the converted volumes. (Only for Windows supported operating systems, Linux operating systems are not supported)
    2. Convert the whole Physical server to a virtual machine. There are two ways to finally obtain the desired VHD format
      1. If your target virtualization stack is VMWare :
        1. You can use VMware vCenter Converter. This tool will allow the P2V (Physical to Virtual)  conversion of you physical server to a VMWare virtual machine.
        2. You should convert your VMDK disks to the VHD format. This can be done via several ways :
          • If you have a Hyper-V virtualization platform: You can make a V2V conversion of the VMware virtual machines to Hyper-V virtual machines. That way, you will obtain the desired VHD format. The following blog (Link1, Link2) describes the way to convert VMWare VMs to Hyper-V VMs
          • You can convert directly VMDK virtual hard disks to the VHD format using conversion tools like MVMC (Link1, Link2) or third-party tools like Starwind V2V converter (Link1). But i recommend using MVMC
      2. If your target virtualization stack is Hyper-V : Use MVMC to make a P2V conversion toward a a Hyper-V server (Only for Windows supported operating systems, Linux operating systems are not supported). Choose the VHD format for the disks type.
  2. Upload the machine VHD files to Azure. The best two options to use:
    1. For fixed VHD files format : Use AzCopy
    2. For  dynamic or fixed VHD files format : Use Add-AzureVHD powershell command. Follow this blog to optimize the usage of this tool
  3. Creation of the virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.

Virtual machines

  1. The goal is to obtain the virtual machines disks under VHD format
    1. If your virtualization stack is VMWare: You should convert your VMDK disks to the VHD format. This can be done via several ways :
      1. If you have a Hyper-V virtualization platform: You can make a V2V conversion of the VMware virtual machines to Hyper-V virtual machines. That way, you will obtain the desired VHD format. The following blog (Link1, Link2) describes the way to convert VMWare VMs to Hyper-V VMs
      2. You can convert directly VMDK virtual hard disks to the VHD format using conversion tools like MVMC (Link1, Link2) or third-party tools like Starwind V2V converter (Link1). But i recommend using MVMC
    2. If your virtualization stack is Hyper-V : Hyper-V supports 2 formats : VHD and VHDx
      1. If your virtual machines disks format are VHDx : You should convert the VHDx files to VHD. For that you can the powershell command Convert-VHD
      2. If your virtual machines disks format are VHD : No steps to be done
  2. Upload the machine VHD files to Azure. The best two options to use:
    1. For  fixed VHD files format : Use AzCopy
    2. For  dynamic or fixed VHD files format : Use Add-AzureVHD powershell command. Follow this blog to optimize the usage of this tool
  3. Create a  virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.
2.2.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:



  • Does not require a change to the application configuration
  • Does not require application experts
  • Fast and guaranteed rollback
  • Applicable for standalone workloads
  • May take long time (Conversion + Upload = Hours)
  • Require server downtime (hours)
  • Several prerequisites
  • Manual process
  • Not  supported for all Operating Systems

2.3- Use Microsoft Virtual Machine Converter (MVMC)

2.3.1- Description

This this the third path that can be took to migrate workloads to Azure.

This approach is applicable only for virtual machines residing on supported VMWare hosts (ESX/VSphere/VCenter)

The next paragraph describes the different steps to successfully migrate workloads using this method:

NB : Because the current version of MVMC (3.1) does not support Azure Resource Manager storage containers, extra steps will be conducted to successfully make the migration. These steps will be marked with green color.

  1. Install the MVMC tool on a server which ‘preferably’ belongs to the same network as the VCenter server. The following details the installation prerequisites (Link1). You can download MVMC from the following link (Link2)
  2. Make the following steps as prerequisites to use MVMC to migrate VMWare VMs to Azure. The most important step is to upload a management certificate to Azure (Link1)
  3. Create a classic (V1 Azure Service Management) storage account where the VHDs will be uploaded. This storage account will be used as an intermediate during the migration
  4. There are two options which can be used to convert VMWare virtual machines : Using the MVMC graphical wizard, or use the MVMC cmdlets.
    1. Use the MVMC GUI : Follow this link and follow the steps to connect to a VCenter/ESX server and convert/upload  VMware Virtual machine VHDs to the already created storage account in step 3 (VMWare to Azure using MVMC GUI)
    2. Use the MVMC cmdlets : The following document contains a sample script which can be used to convert and migrate  VMware virtual machines to Azure. Download the MVMC_cmdlets.doc from the following link (MVMC_cmdlets.doc)
  5. Move the uploaded virtual hard disks from the temporary classic storage account (created on step 3) to the target storage account (ARM) where the virtual machine storage should reside. The move can be easily done via few steps using the Start-AzureStorageBlabCopy Azure powershell command. Use the ‘Initiating an Asynchronous Copy Request (authenticated source)‘ section (Copy VHDs between Azure BLOBs). You should install Azure Powershell as a prerequisite (Downland Azure Powershell)
  6. Create a  virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.
  7. Delete the VHDs residing on the classic storage account

NB: MVMC can be used with MAT (Microsoft Automation Toolkit) to make bulk conversion operations. Look the Microsoft Automation Toolkit section on this page (MVMC with MAT)

2.3.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:



  • Does not require a change to the application configuration
  • Does not require application experts
  • Fast and guaranteed rollback
  • Applicable for standalone workloads
  • Optimal for low scale migration
  • May take long time (Conversion + Upload = Hours)
  • May require server downtime (hours)
  • Extra steps  due to lack of  ARM storage accounts support
  • Manual process (though can be automated)
  • Not optimal for an Enterprise migration path


2.4- Use Azure Site Recovery

2.4.1- Description

This this the fourth path that can be took to migrate workloads to Azure.

This approach is applicable only for virtual machines residing on supported VMWare hosts (ESX/VSphere/VCenter), and for physical servers.

This method is the most complicated method deploy, but once deployed, it will me a one-click solution to easly migrate workloads to Azure.

NB : Azure Site Recovery  does not currently support Azure Resource Manager, hence it will not be possible to use it with Azure IaaS V2. In the meanwhile, the same steps are applicable when it will be supported in few months (Mid Q4 2015)

In this description, i will highlight the necessary steps to use Azure Site Recovery as a migration solution from VMWare to Azure (But the same steps apply to Hyper-V/Physical). For a detailed explanation, you can refer the Microsoft official documentation (Migrate VMWare to Azure using Azure Site Recovery) What is ASR and what are its components

ASR is an Azure Service which can be used to migrate/protect different kind of workloads from a source site to a target site. For a complete list of Sources and Targets, visit this page : Azure Site Recovery Overview

The following pictures shows the components involved on a ASR protection/Migration of workloads to Azure.


(Image Credit  : Microsoft)

The following components should be used and installed on-premise and on Azure in order to enable workloads protection (Table copied from Migrate VMWare to Azure using Azure Site Recovery)




Configuration server

Deploy as a Azure standard A3 virtual machine in the same subscription as Site Recovery.

You set up in the Site Recovery portal

This server coordinates communication between protected machines, the process server, and master target servers in Azure. It sets up replication and coordinates recovery in Azure when failover occurs.

Master target server

Deploy as Azure virtual machine — Either a Windows server based on a Windows Server 2012 R2 gallery image (to protect Windows machines) or as a Linux server based on a OpenLogic CentOS 6.6 gallery image (to protect Linux machines).

Three sizing options are available – Standard A4, Standard D14 and Standard DS4.

The server is connected to the same Azure network as the configuration server.

You set up in the Site Recovery portal

It receives and retains replicated data from your protected machines using attached VHDs created on blob storage in your Azure storage account.

Select Standard DS4 specifically for configuring protection for workloads requiring consistent high performance and low latency using Premium Storage Account.

Process server

Deploy as an on-premises virtual or physical server running Windows Server 2012 R2

We recommend it’s placed on the same network and LAN segment as the machines that you want to protect, but it can run on a different network as long as protected machines have L3 network visibility to it.

You set it up and register it to the configuration server in the Site Recovery portal.

Protected machines send replication data to the on-premises process server. It has a disk-based cache to cache replication data that it receives. It performs a number of actions on that data.

It optimizes data by caching, compressing, and encrypting it before sending it on to the master target server.

It handles push installation of the Mobility Service.

It performs automatic discovery of VMware virtual machines.

On-premises machines

On-premises virtual machines running on a VMware hypervisor, or physical servers running Windows or Linux.

You set up replication settings that apply to virtual machines and servers. You can fail over an individual machine or more commonly, as part of a recovery plan containing multiple virtual machines that fail over together.

Mobility service

Installs on each virtual machine or physical server you want to protect

Can be installed manually or pushed and installed automatically by the process server when protection is enabled for the server.

The Mobility service send data to the Process Server as part of initial replication (resync.) Once the server reaches a protected state(after resync is completed) the Mobility service performs an in-memory capture of writes to disk and sends it to the Process Server. Application consistency for Windows servers is achieved using the VSS framework.

Azure Site Recovery vault

Set up after you’ve subscribed to the Site Recovery service.

You register servers in a Site Recovery vault. The vault coordinates and orchestrates data replication, failover, and recovery between your on-premises site and Azure.

Replication mechanism

Over the Internet—Communicates and replicates data from protected on-premises servers and Azure using a secure SSL/TLS communication channel over a public internet connection. This is the default option.

VPN/ExpressRoute—Communicates and replicates data between on-premises servers and Azure over a VPN connection. You’ll need to set up a site-to-site VPN or an ExpressRoute connection between the on-premises site and your Azure network.

You’ll select how you want to replicate during Site Recovery deployment. You can’t change the mechanism after it’s configured without impacting protection on already protected servers.

Neither option requires you to open any inbound network ports on protected machines. All network communication is initiated from the on-p ASR replication mechanism

This section explains how to migrate a  VMware virtual machine to Azure using ASR. I will highlight the high level steps, explaining the End to End process:


(Image Credit  : Microsoft)

A- Create the Azure Site Recovery vault

The first step is to create an Azure Site Recovery vault. A vault is just a container which will be targeted later for your replication mechanism. After creating the vault, a storage account (GRS type) will be created, it will store the replicated data.

B- Set up the configuration server component on Azure

The configuration server is a server residing on your Azure subscription. As explained on  ‘ What is ASR and what are its components’, the configuration server  coordinates communication between protected machines, the process server, and master target servers in Azure. It sets up replication and coordinates recovery in Azure when failover occurs. An standard A3 virtual machine is recommended for this component. This server should added to the already created vault

C- Set up the Master Target component on Azure
Now, an Azure VM should be created to hold the master target role. Disks will be attached to this VM, and each disk will receive data from its analogue disk on-premise. So if you are migrating a VM with N disks, the VM should support at least N+1 data disks (Be aware that the maximum supported data disks per VM is limited by its size and series, look to Azure Virtual Machine Sizes). If the Master Target VM reaches the maximum data disks count, you can add a second Master Target VM or upgrade the current size to a size which support the data disks count (N+1)

D- Set up the Process Server component on-premise

A server must be created on-premises and hold the Process server component. It’s recommended to create the server on the same network than the ESX infrastructure. This server with be registered with the Configuration server. It’s recommended to install VMWare VSphere CLI 5.5.0

E- Check the components server updates

It’s highly recommended to install the last windows updates on the component servers

F- Create protection groups

On the Azure portal, create a protection group and configure the default replication settings. We will add later the virtual machines to be migrated to this protection group. One protection group can include multiple virtual machines.

G- Set up the replication for the virtual machines

For each VMware virtual machine to protect, the Mobility Service agent will be installed. Then, the VM will be added to the protection group already created. The Properties for the target virtual machine in Azure can be configured (Name, IP…)

H- Planned Failover

After the initial replication completes, we can make a planned failover. A failover plan should be created which will include the failover properties (one or more VMs, order…)

NB: A planned failover will cause downtime. In fact, the source machine is stopped, the delta between hard disks is synchronized to have an exact clone of the source machine.

I- Validate migration

Once the virtual machine is running on Azure, verify its connectivity with on-premise.

2.4.3- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:



  • Does not require a change to the application configuration
  • Does not require application experts
  • Fast and guaranteed rollback
  • Applicable for standalone workloads
  • Enterprise grade solution
  • Minimal downtime
  • Can be used to failback to on-premise
  • Can use VPN, ExpressRoute or Public internet for replication
  • Need deployment of different components
  • Not free*

* The protection of a virtual machine is free for the first 31 days (The Initial replication and failover time will always be less than 31 days), so the ASR service is considered free for a migration path. However, the Master Target and the process server will use Azure compute and storage resources, which will be accounted on the bill.

3- Migration paths comparison

In this final section, i will present a summary comparison table comparing the different migration options discussed in this post.

Migration path


Require a migration platform


Manual Effort



Reverse Migration

Depend on the Application

Extend the application to Azure









Manual upload of VHDs



























* Only If the source virtual machines are not under the VHD format

** Depends on the data to be uploaded to Azure and on the outbound bandwidth

4- Which migration path to choose

The following table describes my ‘personal’ recomdantions toward which migration path to choose

Migration path

When ?

Extend the application to Azure

  • Downtime is not permitted
  • Simple to accomplish

Manual upload of VHDs

  • Long downtime is permitted
  • Few machines to be migrated


  • Long downtime is permitted
  • Few machines to be migrated
  • Minimize manual steps


  • Long-term solution (Enterprise soution)
  • Continous machine migration
  • Minimal downtime needed
  • Postpone the migration decision*

* Once the initial replication is completed, you can decide whether or not to failover the virtual machine to Azure. The VM will keep replicating with the on-premise server until you decide to make the failover.

Microsoft is reducing D-Series pricing

Hi all,

A fast flash info, Microsoft is reducing its D-Series prices starting October 1, 2015.

Snap 2015-09-15 at 10.43.09

(Picture Credit : Microsoft)

This is good news since the prices are decreasing at a good rate : Around 20 % in north Europe

Snap 2015-09-15 at 10.43.25

( Picture Credit : Microsoft) D-Series prices in North Europe Region

This makes using D-Series advantageous since they offer best CPU performances.

I’m really optimist for what coming, since this is the what we expect from the Public Cloud Platforms : Prices should decrease

Azure Active Directory integration with Salesforce Sandbox

The main goal of this blog is to show how to integrate Salesforce Sandbox environment with Azure Active Directory, using the Windows Azure AD single Sign-On configuration option.

Before continuing, you should meet the following requirements:

  • A valid Azure Active Directory Subscription
  • A Sandbox environment on Salesforce .com with a System Admin user on this environment.

NB: In this blog, i used the ‘.uisandbox’ as a suffix. You should replace it by the suffix attributed to your sandbox platform

1- Why do not use the same integration procedure with Salesforce (non-Sandbox) ?

A question one may ask is why not use the same Azure Active Directory integration procedure with a (non-Sandbox) Salesforce environment (Described here in a Microsoft Article). The reason is simple : When you get a Salesforce Sandbox environment, your Salesforce production user accounts are cloned to  the Salesforce Sandbox environment (Automatically on the refresh process), but a ‘.uisandbox’ suffix is added to the UserName for each user. This is intentional since a user will know that he is using a Sandbox environment and to avoid confusion just by looking to his username. The email address is also modified to a strange format : Example : –> I personally recommend modifying the email address of a user to match its real email address, but it’s not a must. So, the integration procedure for a production SalesForce environment is not valid for the Sandbox one (The users identifiers changed) . A tuning must be brought in order to achieve the integration. This is the blog’s purpose.


There is an Official Microsoft article about configuring salesforce ‘sandbox’ environment with Azure AD, but, it seems that the content is not accurate and you will not be able to successfully configure the integration.

2- How this will work ?

It’s simple. Thanks to the Azure Active Directory new SAML attributes option (Currently In preview) , we will tell Azure Active Directory to add, every time that an authentication is requested, the suffix ‘.uisandbox’ to the UserName claim. Great !

3- Steps for Integrating Salesforce Sandbox environment with Azure Active Directory

3.1- Configure the Salesforce ‘Sandbox’ application on Azure AD

Where : Azure Management portal

A- Deploy the Salesforce sandbox application

First, connect to the Azure Management portal with an Active Directory tenant administrator account. Go to Active Directory –> Domain Name –> Applications and Click on the Add button

Snap 2015-09-07 at 11.37.03

Choose Add an application form the gallery

Snap 2015-09-07 at 11.37.44

On the Search bar, type salesforce. Choose the Salesforce Sandbox. Type a Display Name for this application (Example : MySalesforceSandbox) and click Okay

Snap 2015-09-07 at 11.39.41

Wait for the application to be successful added. Now we can begin configuring our SSO with Azure AD

B- Configure Single Sign-ON

In this phase, we will configure Azure AD to ‘accept’ authentication requests from Salesforce. In other words, we will configure Azure AD as an identity Provider for Salesforce ‘sandbox’.

Click on Configure Single sign-ON

Snap 2015-09-07 at 11.42.29

Select ‘Microsoft Azure AD single sign-On’

Snap 2015-09-07 at 17.04.57

Type the Sign ON URL. The sign-on URL is the Salesforce ‘custom’ Sandbox domain URL. Go to step ‘3.2.A- Create and switch to a custom domain’ if you are not aware of this information. The URL must begin with https:// and ends with

Snap 2015-09-07 at 17.14.08

This step is very important, since it contains ‘required information’ for setting up the SAML settings in Salesforce. Keep the following information:

  • Download the Certificate in a local location. You can name it ‘AzureADSalesforcesandboxsso.cert’
  • Save the following URL to a text file for example (Of course you can retrieve them later)
    • Issuer URL
    • Remote Login URL
    • Remote Logout URL

Snap 2015-09-07 at 17.16.11

Click Next

Type an Email address to receive information about SSO events with this application.

Snap 2015-09-07 at 17.16.47

This phase is completed, now we will pass to the next step, a very crucial configuration.

C- Change the SAML attributes claims to match the Salesforce ‘Sandbox’ users settings

Go to Attributes (Even if this feature is currently on preview, it works as expected)

Snap 2015-09-07 at 17.24.23

The goal is tell Azure AD that the Name it will receive during the SAML handshake, is not the UserName is AzureAD, but it’s a concatenation of the UserName is AzureAD and the ‘.uisandbox’ expression.

For this, we will edit the ‘’ attribute like the following.

Click on the Edit symbol for the ‘’ attribute

Snap 2015-09-07 at 17.28.43

Change it like the following:

Attribute Value : Join()

STRING1 : User.userPrincipalName

String2 : uisandbox

Separator : .

Snap 2015-09-07 at 17.29.51

Click OK then Click Apply Changes

NB: In my example, I used the Name as a claim attribute, you can use the email address if you want. But, you have to also to change it in the SAML settings configuration on salesforce on Step ‘3.2.B- Create a new SAML SSO settings’

3.2- Configure the Salesforce ‘Sandbox’ SSO on Salesforce

Where : Salesforce Sandbox portal

Go to and login with a ‘sandbox’ user account (This user must have System Admin rights on this environment). NB: As discussed, The sandbox user account by default ends with .uisandbox

Snap 2015-09-07 at 11.46.11

A- Create and switch to a custom domain

First step to do is to switch to the sandbox domain if it’s already created, or create a new domain for your environment (For users not familiar with Salesforce domains, a Salesforce domain is just a domain name to be used when connecting to your Salesforce environment, this will make you use a domain name like ‘’ instead of ‘’).

Go to Setup –> Domain Management –> Domains

Snap 2015-09-07 at 12.01.02

If you did not already  created a domain, create a new one.

Now, go to Setup –> Domain Management –> My Domain and login to your domain by clicking on Click here to login

Snap 2015-09-07 at 12.52.42

Once connected, you will be switched to the custom domain

Snap 2015-09-07 at 12.52.58

B- Create a new SAML SSO settings

Now, it’s the main part, where we will configure the settings that will allow the SSO to Azure AD and the matching between the user in Azure AD and in the Salesforce ‘sandbox’.

Go to Setup –> Security Controls –> Single Sign-On Settings and click New

Snap 2015-09-07 at 12.54.12

You will have to provide the following information:

Snap 2015-09-08 at 16.58.03




Name A name for your SSO configuration (Will be shown for users so choose a descriptive  Name) AzureADSSOSandbox
API Name Used by SalesForce, keep it the same as the Name AzureADSSOSandbox
Identity Provider Certificate The Certificate that you bring from the Azure AD SSO configuration (AzureADSSOSalesforce.cert) AzureADSSOSalesforce.cert
Entity Id Used by Salesforce, need to set it to
Issuer Paste here the Issuer URL got from Azure ADD SSO configuration wizard
Request Signing Certificate Which Certificate to use to sign the request Default Certificate
Request Signature Method The method for the Request signing certificate RSA-SHA1
Assertion Decryption Certificate If your assertion is encrypted, choose a certificate to decrypt it with. Otherwise, choose Assertion not encrypted Assertion not encrypted
SAML Identity Type Which identity type will be used Assertion contains User’s username
SAML Identity Location Where the identity is located Identity is in an Attribute element
Attribute Name Which attribute will be used. In our configuration, the name will contain the name that will match the user name in Salesforce ‘sandbox’. In fact, we have to set this attribute in Azure AD to add the ‘.uisandbox’ suffix to the user name
Name ID Format leave it blank
Service Provider Initiated Request Binding HTTP POST
Identity Provider Login URL Paste here the Identity Provider Login URL copied from the Azure AD SSO config wizard
Identity Provider Logout URL Paste here the Identity Provider Logout URL copied from the Azure AD SSO config wizard
Custom Error URL Leave it blank
User Provisioning Enabled Check this box if you want to enable the User Provisioning feature on Azure AD

C- Enable the SSO settings for the ‘salesforce’ domain

This is the last step in this configuration walkthrough. We have now to enable the configured SSO authentication for the ‘salesforce’ sandbox domain.

Go to Go to Setup –> Domain Management –> Domains

Select your ‘sandbox’ domain and click Edit

Snap 2015-09-04 at 12.18.06

Affect the SSO configuration which was created during the previous steps to this domain then click Save


  • You can affect more than one SSO configuration to your domain
  • If you uncheck the ‘Login page’, users will not be able to use local ‘salesforce’ users to login to the domain

3.3- Test the configuration

Now, we can test our configuration.

First, you must assign users or groups to be be authorized to use this application (to use the Azure AD Authentication).

In Azure AD, go to the Application –> Users and Groups. Choose the ‘All Users’ or ‘Groups’ filter and assign the desired users.

Snap 2015-09-07 at 18.08.43

Now connect to the ‘Salesforce’ sandbox URL (sign-on URL ie your Salesforce ‘sandbox’ domain name ). And choose your ‘AzureAD SSO’ that you already configured.

Snap 2015-09-07 at 18.10.52

You have successfully logged using SSO to Salesforce ‘sandbox’ environment.

ADFS : Error when joining a server to a FARM

Hi all,

During an ADFS farm extension that I’m making for my customer, I have followed all the documented TechNet documentation regards the network prerequisites (flow and ports).  But unfortunately, was not enough !

Existing and target architecture

The existing architecture is a 2 members ADFS 3.0 FARM, load balanced via a hardware load balancer. We also had 2 load balanced WAP (Web Application Proxy) severs for ‘proxying’ external connections.


The goal is to add 2 additional ADFS Federation servers and 2 WAP servers on the secondary datacenter. In our case, we are using Azure as the datacenter extension.


The two sites (On-premise and Azure) are connected via a VPN connection that will be soon upgraded to an Express route circuit for more performances and availability. Connection between the two sites is filtered via a on-premise firewall and Azure NSG. So understanding the firewall requirement for the ASDFS servers communication is mandatory in our case. This post does not discuss the ADFS extension itself bit an issue you may encounter during the server join step.

The Microsoft documentation shows that the only ports used for the communication between two ADFS servers are the following : Honestly, you will not fond the answer anywhere :/






ADFS server

ADFS server

tcp 443
Internet WAP server (or VIP) tcp 443,49443
WAP server ADFS server (or VIP) tcp 443,49443


Adding the server to the FARM

After authorizing this port, I added the ADFS role and begin adding the server to the existing FARM.

Obviously I received the following error:

Snap 2015-07-21 at 14.31.29

Unable to retrieve conflict information from the primary server

The specified dns name of the primary federation server could not be resolved. Verify that the DNS name is correct, and that the ADFS service is running on the primary federation server and try again.

I checked every thing : Ping tests, telnet tests, DNS tests… Still unable to add the server. Finally I decided to install wiresharjk to look what the server is trying to do during the configuration phase.

Look to the result:

Snap 2015-07-21 at 14.31.59

Yes, the server is trying to communicate with the ADFS primary server on port 80

I asked the network team to authorize traffic on this port, and it worked like a charm.

So to add the 80 port to the port requirements:





ADFS server

ADFS server

tcp 443, 80*
Internet WAP server (or VIP) tcp 443,49443
WAP server ADFS server (or VIP) tcp 443,49443

* Try first to  open the port from t’’he server you want to join’ to the ‘ADFS primary server’ (not both direction). I think this port is used just for a connectivity test or to initiate the connection than the traffic is switched to 443

Azure Virtual Machines introduction

This post aims to introduce Microsoft Azure IaaS (Virtual Machines service) to folks who were not involved from the beginning with Azure and who would like to rapidly understand how it works, and if it can convince them start or even think use it. In this post, I will not detail the IaaS features in Microsoft Azure, since we have hundreds of them, and there is books and long articles describing in details the Azure fundamentals.

This post is divided like below:

  1. Introduction : I will rapidly introduce the Azure Virtual Machines service (IaaS)
  2. Components : This is the principal part of this post, I will detail the components and bricks of the Azure Virtual Machines services. It will help you understand how the Azure IaaS can be used and what to consider before deciding to go with the Azure Virtual Machines service.
  3. Networking : I will explain the networking concept in Azure
  4. Storage : I will explain the storage concept in Azure
  5. Pricing : I will explain how the Azure pricing works
  6. Design considerations : I will put some design considerations and must-remember points
  7. Further Reading : I will post some interesting resources and readings to go deep and dive into Azure.


Azure Virtual Machines is one of the central features of Azure’s IaaS capabilities. Azure Virtual Machines supports the deployment of Windows Server or Linux virtual machines (VMs) in a Microsoft Azure datacenter. You have total control over the configuration of the VM. You are responsible for all server software installation, configuration, and maintenance, as well as operating system patches. All the resources are running within the Microsoft Datacenters, the only link to them will be networking. Think of it like you have your own datacenter in another location or region from you on-premise. You create all your workloads there and you access them remotely. The only difference here is :

– The Datacenter belongs to Microsoft

– All the underlying management, updates, maintenance are  Microsoft’s responsibility (Hardware, Networking, Cooling, Power…)

– The physical security are Microsoft responsibility

The result is : Microsoft offers you a feature ( A service) that enables you to create virtual machines and use them freely, just like they were yours, and they are yours.

I would loved to continue introducing the Azure Virtual machines feature, because it’s amazing and very interesting. I will dedicate a full post just for discussing the ‘what and why ‘about Public Cloud Platforms (Iaas Offer) and is it reasonable to go forward toward this new concept.



The compute component is the heart of Azure VM. Compute mean  the virtual machine resources : CPU, Memory and Operating System

When you create a virtual machine in Azure, you will choose first the VM configuration : Hardware and Software (Example : I want to deploy a Windows Server 2012 R2 Datacenter VM with 4 GB of RAM and 2 CPU). Look that I’m not mentioning the storage configuration (OS disk size, number and size of data disks). This is intentionally and will be explained further.

Azure does not give you the possibility of freely choosing the hardware configuration. In fact, Azure exposes predefined templates to choose from. These templates are classified into Virtual Machine series and sizes. The complete Virtual Machine sizes list can be found here and it’s regularly updated by Microsoft in case of a change. LINK1 : Azure Virtual Machine Series and Sizes

The Virtual Machines in Azure can be classified by :


The tier is a categorization of the virtual machine type. There are two Tier types in Azure : Basic tier and Standard tier. Basic tier VMs are generally used for test/dev and less important VMs. Basic Tier VMs are spreadly used for production environment. The difference resides in the following things:

– Basic Tier VMs do not support Azure load balancing capabilities (you cannot load balance traffic between two basic VMs using the Azure load balancing feature)

– Basic Tier VMs do not support the Azure ‘Autoscale’ feature. ‘Autoscale’ allows Azure to automatically scale the number of virtual machines to meet resource requirements (CPU usage for example) and then scale down by shutting down VMs when scale conditions are no longer crossed

– Not all the hardware configurations are given with the Azure Basic tier VMs. Advanced hardware configurations (more and faster CPU, more and faster memory, more disks, faster temporary disks,  more performance…) are just provided with Standard tier VMs

– Basic VMs data disks IOPS is capped a 300 IOPS per disk, less than the 500 IOPS for the standard tier ( storage will explained in details  later in this article)


The series is classification to help the customer rapidly find and choose between tens of virtual machines types. It’s like the classification that we find in car vendors : Mercedes Class A, B, C, E and S or BMW  Series 1, 3, 5 and 7 Smile. Till today, there are 4 Azure Virtual Machines Series : The A-Series, D-Series, DS-Series and G-Series:

  • A-series: A-Series presents ‘normal’ and ‘classic’ virtual machine class. They are intended to the majority of workloads. Only the A-Series provide the Basic tier classification
  • D-Series: D-Series presents enhanced VM’s underlying hardware. VMs are provisioned on  top of better physical servers using faster processors, faster disk cache and more storage support. They provide also the capability of using offloading network technologies to communicate over a low latency, high throughput network in Azure.    LINK2 : D-Series Virtual Machines Sizes
  • DS-series: DS-series is the only Azure VM series that let you benefit form the Azure Premium Storage (Storage in Azure will be discussed later). It mainly intended for workloads that need high performance and low latency  storage.
  • G-series: This is the last announced Azure Series, it provides powerful VM’s hardware configurations (High specifications). Underlying hardware  uses better CPU and memory brands. It is mainly intended for giant workloads (can provide hundreds of GB of RAM). LINK 3 : G-Series Virtual Machines Sizes


The Size of a virtual machine means its hardware configuration. In Azure, the hardware configuration counts 4 elements :

CPU : The virtual processor count

Memory : The amount of RAM allocate do the virtual machine

Temporary or Local storage : The size of a temporary storage allocated to the virtual machine. It’s an attached disk that can be used for storing temporary (volatile) data during the virtual machine running time. The content is lost in any case the virtual machine is stopped (Planned or unplanned)

Number of supported data disks : Each virtual machine size has a maximum data disk count. For example, you can attach a maximum of 4 data disks (Data VHDs) to a Standard A2 VM while you can attach 16 to a A4 VM. This is very important since the maximum size of a data disk is 1 TB (1023 MB), for example you cannot have have a 5 TB volume using an A2 VM (4 disks of 1 TB with stripping will give you a maximum of 4 TB volume)

Operating system

Microsoft provides a wide range of operating system images. Both Windows and Linux are supported. In addition, pre-configured images can be found like Windows + SQL or Linux + Apache. Images can be found on the Azure VM ‘Library’ or on the VM depot. Moreover, Azure allows you to bring your VMs and run them in Azure. You can upload VHDs to Azure and then use and deploy them (Of course, the VM OS need to be supported by Azure). There is no maintained link that list the supported operating systems in Azure. However, till the writing time of this article, here the actual supported OS :

Cloud Service

When you create a virtual machine in Azure, this virtual machine is provisioned as part of a cloud service. Several virtual machines can be part of the same cloud service, this will let you create load balanced services between virtual machines. You will not be able to use Azure ILB (Internal Load Balancing) if your VMs are not within the same cloud service and the same virtual network

Important notice : With the introduction of Azure Resource Manager that goes GA on  June 30 (ARM GA Announcement) for a set of Azure features, Cloud Services are no longer needed if you use the ARM stack for your VM deployments.

Load Balancing

Azure provides load balancing features for its virtual machines services. You can  use the load balancing features to distribute traffic between VMs whether these VMs are internet facing or not. The load balancing features can load balance level 4 traffic and support only tcp and udp traffic. As discussed earlier, the load balancing is only supported on VMs part of the same cloud service. The following link gives a good description of the Azure Load Balancing feature LINK 5 : Azure load balancing

Important notice : With the introduction of Azure Resource Manager that goes GA on  June 30 (ARM GA Announcement) for a set of Azure features, Cloud Services are no longer needed if you use the ARM stack for your VM deployments.

Affinity groups

Affinity groups are a way to point to a fixed set of physical servers located near each other in the same region. In the past, affinity groups were a requirement for creating virtual networks (VNets). At the time, the network manager service that managed VNets could only work within a set of physical servers or scale unit. Recent architectural improvements have increased the scope of network management to a region. As a result of these architectural improvements, affinity groups are no longer recommended or required for virtual networks. The use of affinity groups for VNets is being replaced by regions. Virtual networks that are associated with regions are called regional VNets. Affinity groups are deprecated, this is why I will not explain their usability.

Availability Set

There are two types of Azure platform events that can affect the availability of the virtual machines: planned maintenance and unplanned maintenance. Planned maintenance does not generally affect the availability of the Azure virtual machines, but my sometimes require you to reboot your VMs. Unplanned maintenance may not be referred to maintenance but to unplanned service disruption caused generally by the underlying hardware failure. To guarantee the Azure SLA (actually 99.95 % service time), it’s highly recommended to always create highly available workloads that can be achieved by redundant services. Clustering, Built-in clustering and Load balancing are sort of high availability paths. However, it’s important to guarantee, that at a given time, a set of highly available VMs (clustered, Load balanced…) are not under the same fault domain (A fault domain is a set of resources that share the same Single-point-of-failure), this is why the Availability Set configuration was provided. Two or more VMs under the same ‘availability set’ will be placed on different fault domains. In case of planned or unplanned maintenance, at least one VM is guaranteed to be kept up and running. VMs must be under the same cloud service to be able to join an availability set configuration. More information can be found here LINK 6 : Azure virtual machines high availability

To resume

When you plan to create a virtual machine in Azure, you need to know the target virtual machine specification and then choose between the different Tier/Series/Size. Keep in mind the following points:

  • You can at anytime change the virtual machine type. You can scale up or scale down (from a hardware configuration perspective) the configuration at any time. But you need to respect the target VM’s type requirements. For example, you cannot change from a DS-Series to another series if you are using Premium Storage or you cannot pass from an A4 VM with 16 disks to an A3 VM, because A3 supports a maximum of 8 data disks. You can rarely encounter issues with the VM configuration changes, you can refer to this post for more information LINK 5 : Azure VMs sizes considerations
  • Only few Azure VMs support more than one network adapter : [ 4 NICs : A4, A7, A9, D4, D13, G4] [2 NICS : A3, A6, A8, D3, D12, G3]
  • VM pricing depends on the three classification: Tier, Series and Size. The more the configuration and options are better, the more the VM is expensive (Pricing will be discussed later in this post)
  • Notice that the storage usage and network throughput is not part of the VMs classification, and hence on pricing. Storage and network usage are billed separately
  • For all your ‘normal’ virtual machines that do not require load balancing and special performance, use the Basic tier VMs : It’s more affordable



Virtual Networks

Virtual networks (VNets) are used in Azure to provide a layer of security and isolation to your services. VMs and services that are part of the same virtual network can access each other. By default, services outside the virtual network cannot connect to services within the virtual network. You can, however, configure the network to allow access to external services:

  • A virtual network is a closed logical network boundary ( It’s like a network in a physical network architecture)
  • 2 virtual networks cannot natively communicates even if they are within the same region. A Vnet to Vnet connection must be configured to let they communicate (Using VPN)
  • All traffic within the same virtual network is by default permitted. However, Azure provides a security layer that let you configure ACLs between virtual machines or  subnets (will be discussed later)
  • VLANs are not supported nor understood by virtual networks, in fact Azure virtual networks are layer 3 networks for the tenant perspective.
  • Only tcp, udp and icmp protocols are supported within Azure virtual networks
  • Virtual networks support cross premises connection : You will be able to connect you on-premises network to an Azure virtual network for example
  • Virtual Networks are regional scoped, and hence, your virtual network can span all the datacenters within the same region (In the past, Virtual Network are datacenter scoped, and you can be in the situation when you want to provision a virtual machine on the same region but you can’t connect it to a virtual network, even if it created on the same region)

You can read the TechNet FAQ for more information: LINK 6 : Azure Virtual Networks FAQ


When creating a virtual network the following information should be provided :

– Location [Mandatory] : In which region the virtual network will be created

– DNS Servers [Optional] : Azure will be responsible for assigning the IP addresses for your VMs (Of course it will pick up IP addresses from a pool that you provide). You can hence provide the DNS servers that will be configured for this virtual network and that the VMs within it will use. DNS servers are configured per virtual network.

– Address Space [Mandatory] : Each created virtual network must be configured with at least one virtual network address space. The virtual network address spaces contain the IP addresses fields that this virtual network  provides. You cannot assign a virtual machine, an IP address that is not included in the virtual network address spaces ranges (Imagine like you are defining a network on your switch where you assign it a network address)

– Subnet [Mandatory] : The Address Space range cannot be used directly by Azure. At least one subnet must be defined per Address Space. You can choose to divide the address space into several subnets or use a single subnet per address space (a subnet range that will fit the entire virtual space).

NB: Azure Virtual Networks support both Public and Private IP addresses ranges (CIDR notation), this will permit you to bypass the RFC-1918 limitation. However, cross-premises virtual networks (that will be connected to on-premise or to another virtual network using VPN or Express route) must respect the RFC1918 IP ranges. In other words, only the Cloud-Only virtual networks can use non RFC-1918 IP addresses

When creating a virtual machine, you can choose to connect it to a virtual network, and choose which subnet will be used to pick up an IP address from. Azure will configure this IP address for your VM, and it will appear as a static IP address on your guest OS (Not a DHCP_reservation-like). On the same time this IP address is not static, that means it can be cases where the IP address will change. Discussing the cases and how to fix  permanently and IP address will be discussed later in the Design considerations

Cross-Premise connection

Azure provides different ways for interconnecting the Azure virtual network to the local on-premise network. The following are the actual options provided by Microsoft:

  • Site-to-Site VPN : S2S VPNs can be established between an Azure Virtual Network and an On-premise network (called Local Network). The S2S VPN is established between two parties, between an Azure Gateway and on-premise VPN device. Establishing a site to site VPN will allow your on-premise resources to communicate with your Azure resources. Actually, Microsoft provides 3 Azure gateways that offer different features and different prices. On-premises VPN devices should  respect the minimum gateway requirements presented here. Microsoft also maintain a lit of known compatible devices
  • Point-to-Site VPN : Azure supports establishing VPNs from a client perspective. A Point to Site VPN will allow individual clients to connect from anywhere to the Azure resources. actually, only Windows clients can establish a point to site VPN to Azure
  • ExpressRoute: Azure ExpressRoute enables you to create private connections between Azure datacenters and infrastructure that’s on  premises. ExpressRoute do not use public internet to transmit  data. Unlike VPNs, ExpressRoute uses a private circuit. ExpressRoute offers many benefits specially  speed and SLA. For additional information, you can read more here LINK7 : Azure ExpessRoute

Security in Azure Networking

Azure provides different options to secure the inter and intra communication within the Azure virtual networks. However, there are many considerations to better chose which option to use :

  • When a virtual machine is created and connected to a virtual network, it is able to communicate with all the virtual machines within the same virtual network.
  • When a virtual machine is created and connected to a virtual network, external inbound connections (external to the virtual network) are not allowed except for two services (configured by default) : Remote Desktop Connection and Remote PowerShell. Allowing/Denying inbound traffic is conducted via two options :
    • Endpoint : An endpoint is a mapping relation between  two ports, a Public port and a Private Port. The Public port is the port on which the virtual machine will listen for traffic from external networks, the Private port is the port on which the service is really listening on the virtual machine. The Public/Private couple is a port redirection rule. Of course Public and Private ports can be the same.
    • ACL : When an Endpoint is configured for a virtual machine (Example :  Public Port A, Private Port A), an access rule is automatically added to the access rule list for that virtual machine allowing external communication on that Public port. To limit access from different external sources, access rules can be added to limit the inbound connection form defined sources.  Access rules can be explicit allow or explicit deny rules (Example : Allow only inbound connections on Public Port A from the external subnet and Deny inbound connections on Public Port A from the external subnet  ).

The following link shows how to set up endpoints for Azure virtual machines  LINK8 : Azure VM’s Endpoints. More information about Azure Virtual Machine’s security can also found here

There is another option that was added and that leverage more flexibility that the Endpoints and ACL concepts. In fact, as discussed, Endpoints are only applicable for external inbound traffic. The second feature allow you to create rules within the virtual network. It’s called Network Security Groups (NSG).

NSG is a powerful feature that allows you to :

  • Define security rules for a single virtual machine
  • Define security rules for a virtual network subnet

To resume, you can create ACLs using a 5   pattern (Source IP, Source port, Destination IP, Destination port, protocol) and apply them to a single virtual machine or to an entire subnet. This is similar to rules that you define for an inter-VLAN communications. This permits the creation of different security zones within the same virtual network (like a DMZ zone). NSG is supported with the local networks (On-Premise networks). The following link describes better the Azure Network Security Groups feature. LINK 9 : Azure Network Security Groups


By default, any virtual machine that is connected to a virtual network can access Internet. If you do not specify DNS server names on your virtual network configuration, default Azure DNS servers will be configured to permit name resolution. If your virtual network uses custom DNS servers, those DNS servers should resolve internet names if internet access is desired. If you want to restrict internet connection on your virtual network, you can use Network Security Groups to set per VM or per subnet denying rules.


Storage is the third key component  in the Azure IaaS infrastructure. Storage includes any sort of service where we can store data (Tenant data). There are many storage services in Azure (Look here for the complete documentation)  but for an Iaas perspective only one or two services are involved : Blob storage and File storage.

Blob Storage

To avoid reinventing the wheel, I picked up the following introduction from this link. Azure Blob storage is a service for storing large amounts of unstructured data, such as text or binary data, that can be accessed from anywhere in the world via HTTP or HTTPS. You can use Blob storage to expose data publicly to the world, or to store application data privately.

Common uses of Blob storage include:

  • Serving images or documents directly to a browser
  • Storing files for distributed access
  • Streaming video and audio
  • Performing secure backup and disaster recovery
  • Storing data for analysis by an on-premises or Azure-hosted service

There are tow types o Blob storage:

  • Block blob storage : For streaming and storing documents, videos, pictures, backups, and other unstructured text or binary data.
  • Page blob storage : Optimized for random read and write operations, page blobs are ideal for VHD images. This blob type is used for the virtual machine storage and will be discussed on this section

Page Blob storage is commonly used to store Azure virtual machine files including operating system disks and data disks. There are two types of storage provided for virtual machines today : The Standard Storage and the Premium Storage. The difference between the two types is performance.

  • To be able to use the storage, a storage account need to be created. The storage account is just an account that permits you access the Azure storage. Each storage type (Standard or Premium) needs a different storage account. So to be able to use both storage types, two storage accounts should be owned. You can have more than one storage account per subscription and the maximum is 100.
  • Like any Azure resource, the storage account is region limited. You can’t provision a VM in a region and its storage resource in another region
  • Azure storage offers different redundancy options categorized into 4 variants : LRS, ZRS, GRS and RA-GRS. The following Link provides description for each variant. The minimum redundancy in Azure is LRS which creates 3 copies of the data on the same facility.
  • Standard Storage : Storage performance is limited in term of IOPS an throughput. The reference IO UNIT size is 8 KB. The maximum IOPS per disk (VHD) is 300 for a basic tier and 500 for a standard tier, the maximum throughput is 60 MB/s. Of course higher IOPS and throughput can be achieved using disk aggregation (stripping). This link explains more the IOPS and throughput for Azure storage. LINK10 : Azure Storage IOPS and throughput
  • Premium Storage : Storage performance is the main key of this storage type that let you achieve 64.000 IOPS an more than 512 MB/s  per virtual machine. More detailed information can be found on the following link LINK 11 : Azure Premium Storage overview
  • Blob storage can be accessed via the Azure PowerShell or Azure Storage APIs for common management tasks.

File Storage

File storage is a new Azure storage service (In preview till the writing time of this post). File storage offers shared storage for applications using the standard SMB 2.1 protocol. Microsoft Azure virtual machines and cloud services can share file data across application components via mounted shares, and on-premises applications can access file data in a share via the File storage API. Applications running in Azure virtual machines or cloud services can mount a File storage share to access file data, just as a desktop application would mount a typical SMB share. Any number of Azure virtual machines or roles can mount and access the File storage share simultaneously. Since a File storage share is a standard SMB 2.1 file share, applications running in Azure can access data in the share via file I/O APIs. Developers can therefore leverage their existing code and skills to migrate existing applications. IT Pros can use PowerShell cmdlets to create, mount, and manage File storage shares as part of the administration of Azure applications. This guide will show examples of both.

Common uses of File storage include:

  • Migrating on-premises applications that rely on file shares to run on Azure virtual machines or cloud services, without expensive rewrites
  • Storing shared application settings, for example in configuration files
  • Storing diagnostic data such as logs, metrics, and crash dumps in a shared location
  • Storing tools and utilities needed for developing or administering Azure virtual machines or cloud services

More information can be found here LINK 12 : Azure File storage overview


This section describes the pricing basics for the Azure IaaS components. Pricing is a very important when designing the Azure platform, since in the Azure model, the components granularity can let you create different similar designs with different costs. You should be aware of every components that you will include in your design, to perfectly estimate the total platform cost.

Compute Pricing

  • Each virtual machine type has a cost. The cost is for compute resources (Not storage and Network) and depends on the 3-Tuple : (Tier, Series, Size). Check the following link for the most recent Virtual Machine pricing LINK 13 : Azure Virtual Machines price list
  • The consumption is calculated in a per-minute usage. So if you use you VM for 1 hour, you will be charged for 60 minutes, if you use it for 30 seconds, you will be charged for 1 minute
  • Prices are different from a region to another. In general, the most expensive is in the Australia and Brazil regions
  • A virtual machine is always billed unless it’s deleted or Deallocated (stopped and deallocated)
  • Storage and network resources are billed separately.  The temporary storage shipped with the virtual machine is however free.
  • There are taxes applied to the virtual machine usage. These taxes are not included in the Azure virtual machine prices, and are added separately to the bill. I have no idea how these taxes are calculated. I will be glad if someone leave me a comment with this precious, hidden information
  • For the Azure virtual machine pricing details, follow this link. LINK 13 : Azure virtual machine pricing

Storage Pricing

  • Virtual machine storage (except the temporary disk) is  billed in a per GB/Month basis. For example, if you use 100 GB in the first 15 days, and 0 GB in the second 15 days, you will be billed for the usage of 50 GB per month. Every day, Azure will pick up a value of the consumed storage for that day. By the end of the month, these value will be used to calculate the monthly usage value ( DAY1 + DAY2 + … + DAY30)/30
  • Storage cost depends on the location (Region) and the redundancy type. The more the storage is redundant, the more it’s expensive ( LRS > ZRS > GRS < RA-GRS)
  • The storage cost decrease with storage consumption. The more you use storage, the cheaper the GB/month pricing unit will be
  • Only really consumed storage is billed. For example, if you create a 200 GB vhd, with only 50 GB content, only 50 GB will be billed by the end of the month.
  • Storage transactions are billed. Every write/read operation is charged. The actual price is a fixed amount per 100.000 transactions. The question is why ? The answer is : Imagine a person copying 50 GB of data to a location, and leaving it till the end of the month, and another person, copying 50 GB of data to a location, but everyday, it replaces them by 50 GB of new data. At the end of the month, the two persons used 50 GB of data, but it’s clearly that the second one was continuously soliciting the storage subsystem, and hence, amortizing the system. It’s obvious to charge it a way more than the first one.
  • Premium storage billing is different from the standard storage billing, you should be aware of the difference :

For the Azure storage pricing details, follow this link. LINK 15 : Azure storage pricing

Network Pricing

  • Network traffic and data transfer inside the same Azure region is free (Intra-VNET, Inter-VNET in the same region)
  • Microsoft will charge outbound data transfers(Egress data), that means that data leaving the Azure datacenters will be charged. Inbound data (Data uploaded to Azure) is free. The first outbound 5 GB of data is free.
  • Like the other pricing models, prices decrease with usage increase.
  • Prices are different from one zone to another. Prices in Zone1 are lower than Zone 2, which prices are lower than Zone 3. Of course, things can change on the future, and it will change.
  • In addition to the data transfer charge, there are charges applied to the IP addresses that may be assigned to virtual machines and related services (Per hour basis)
      • PIP : PIP addresses are not free, and are charged per hour basis (however, one PIP costs around 3 Euros per month, per VM)
      • VIP : VIP is free. But if you want to have multiple VIP for the same cloud service (up to 5 VIP), you can have them at a nominal charge, at the same cost then PIP.
      • Reserved IP: If you want to reserve the VIP address (set it to static), the first 5 will be free and additional reserved VIP will be charged. Even unused reserved IP addresses will be charged too (For example you reserve an IP and you don’t use it for a service)
      • Address remap : Address remap is free if you remap up to 100 address per month. If you cross this limit, a fee will be applied per additional remap (remap mean that you assign an IP already assigned to a cloud service to another cloud service)
  • When you establish a cross-premise connection using VPN or a Vnet-to-Vnet connection, an Azure gateway is used. There are many Azure gateway types that offer different performances and scalability values and with different costs. The following link shows the Azure gateway types. Pricing can be found in this link
  • Express Route : Azure ExpressRoute enables you to create private connections between Azure datacenters and infrastructure that’s on your premises or in a colocation environment. ExpressRoute connections do not go over the public Internet, and offer more reliability, faster speeds, lower latencies and higher security than typical connections over the Internet. Express route has many advantages:
    • Detected circuit between Azure and on-premise
    • Private circuit that do not go through internet
    • SLA (Availability and performances)
  • There is a hidden information that is not exposed to Azure users, but will add a little dollars to you bill. It’s the tax cost. In fact, a tax applyes when using Azure (or in genral any service). The tax cost is not included in the features or services pricing and added later to the bill. Unfortunately, Microsoft do not provide information about how much this tax is really is. (Look for this TechNet thread)

Express route pricing can be found here

For the Azure network pricing details (Data transfers), follow this link. LINK 16 : Azure data transfers pricing

For the Azure network pricing  details (IP addresses), follow this link. LINK 17 : Azure IP addresses pricing

Design Consideration ad recommendations

This section will describe some design considerations and recommendations when planning to use Azure IaaS and specially Virtual Machines.

Design Consideration:


  • There are 3 virtual machine states: Running, Stopped (Allocated) and Stopped (Unallocated)
      • Running: This is when the virtual machine is up and running : All the virtual machine resources are billed —-> Compute, Network and Storage
      • Stopped (Allocated) : This is when the virtual machine is stopped using the operating system (The machine is stopped from inside the operating system) —-> All the virtual machine resources are billed : Compute, Network and Storage
      • Stopped (Unallocated) : This when the virtual machine is stopped using the Azure portal shutdown button or Azure PowerShell/API —-> Only the storage used by the VM is billed
  • Always start with the minimal virtual machine size that fit your needs. You can upgrade the virtual machine configuration, later needed
  • High availability (fault domain and upgrade e domain to achieve SLA)


  • By default, a dynamic IP address is picked from  the virtual network’s IP pool is assigned to any provisioned virtual machine. This IP address is dynamic, that means it ‘may’ change in some conditions (Look HERE). Its’ recommended to set the IP address to static via the following option:
      • Set the IP address to static during the virtual machine provisioning : Only with PowerShell on the Azure management portal or via the portal in the Azure Preview portal
      • Set the IP address to static after the virtual machine creation : Only with PowerShell on the Azure management portal or via the portal in the Azure Preview portal (You can use the following script to fix an IP address for a single virtual machine or this one for a group of virtual machines)
  • If you  plan to use cross-premises connection with Azure, the address space and subnets of your virtual network must be within the RC1918 IP addresses ranges
  • Network security groups is the best option for creating security zones in your virtual networks. Security groups allow you to create ACL rules inter and intra-subnet. NSG and Endpoints are not supported together, you should use either one or the other.
  • You should carefully prepare your virtual network design, in fact, changing the network design of an existing Azure platform is not straight forward and require downtime.
  • You cannot change the IP address of a Virtual Machine without downtime (VM reboot)
  • You can move a VM within the same virtual network between subnets (Require reboot). But you cannot change the virtual network without rebuilding the virtual machine (You should delete the virtual machine and rebuild it using its VHDs)
  • For cross-premises connection using VPN, if you plan (And I think it always will be) to connect more than one site or P2S clients, you must use dynamic routing, that means your on-premise VPN devises must support dynamic routing.
  • Azure virtual machines do not support acting as Layer 3 (IP) gateways or routers. You cannot for example use a 2-NIC virtual machine as a software router. Read here more about Multi-NIC Azure VMs
  • There are different IP addresses types in Azure, you should be aware of them
      • Internal IP address : Also known as DIP, This is the private internal IP address of the virtual machine, this is the local IP address assigned to a virtual machine from the VNet’s address space pool. This IP address cannot be reached from the external network. This IP address is by default dynamic unless you set it to static (See below)
      • Internal virtual IP address  : Also know as LIB. When we say virtual, we say load balancer. The internal virtual IP address is an IP address assigned by the Azure Internal load balancer to be used by internal services to access load balanced workloads. Look to the Load Balance feature described earlier in this post. Internal virtual IP address  is not reachable from external network
      • External virtual IP address : Also know as VIP. This is the IP address of load balanced services that can be accessed from the external network, and can only target the same cloud service. This VIP is dynamic but since it’s public, it’s highly recommended to set it to static. Microsoft allows you to reserve up to 5 VIP by subscription, we call them reserved VIP.
      • Instance level IP : Also know as PIP. This is a public IP that can be directly be assigned to a virtual machine. This will permit you to directly access a virtual machine from the external network without the need of configuring endpoints. Microsoft allows you to reserve up to 5 PIP by subscription


  • To obtain the desired IOPS/Throughput on the data disks, you can use disks stripping. Today, Microsoft recommends using Storage Spaces inside an Azure virtual machine for disk aggregation.
  • Using and managing Premium storage is only possible via the Azure preview portal. If you want to deploy DS-Series, you should use the Azure preview portal
  • As discussed below (Storage section), to obtain the desired IOPS/Throughput with the Premium storage, you should select the adequate VM_Size/P_Disk couple, otherwise you will not achieve the desired performance. Do not forget that each virtual machine size (DS-Series) has a maximum IOPS/Throughput limit. In addition, each P-disk type has also a maximum IOPS/Throughput


Managing Azure and specially Azure virtual machines is today possible via the Azure management portals:

  • Azure Management portal ( : This is the classic portal, where you can make almost all the management tasks. There are many actions and features that you can’t do/use via this portal. You will have to use the second portal
  • Azure portal ( : This is the new metro-style portal. Even if it’s actually in preview, you can make all the management tasks using it.

–> I personally use and recommend using the new Azure portal since (surprisingly unlike the community), since :

  • The classic management portal will be deprecated with time, and one day, you will use it anyway. So it’s a good idea to start and take the habitude and the hand on it.
  • It’s more oriented to touch screen, tablets and phones.
  • Many features are only possible via this portal : DS-Series virtual machines, resetting VM passwords, RBAC…
  • IaaS V2 (ARM objects) can only be shown and used on the new portal
  • I personally like colorful portals Smile

Azure service Quota and limits :

Further reading

We live in the internet Era, and thanks to search engines like Bing and Google, nothing cannot be not found. If you want to learn more about Azure, where to go:

  1. There is two Microsoft free eBooks that you can download right here : The first to read is Microsoft Azure Essentials: Fundamentals of Azure. The second  is Introducing Windows Azure for IT Professionals. Although the latter dates from October 2013, it contains many useful labs to begin manipulating Azure
  2. Microsoft Azure blog :  For whom who want to be stay always tuned about the last Azure updates and news, this is the official Microsoft Azure blog
  3. You favorite search engine + the Key word : This is my preferred and  most used learning method


The goal of this post is to demystify the Azure virtual machines service and Ito explain the different relayed features and components. The information provided are just a start point, and may become deprecated on few months (some of them of course). Azure is under continuous enhancements and fast features growth. I highly recommend you to always check the Microsoft links for the last updates and news. Do not hesitate at asking your questions via the comments, I will be glad to answer, wherever I have the answer.

Azure Active Directory Connect Health : Installation guide

Hi all,

Microsoft released Azure Active Directory Connect Health, an Azure service that allow you to monitor and gain insight into the on-premises identity infrastructure. It will provide you with precious information like alerts, performance, infrastructure configuration…

AAD Connect Healt Logo

AAD Connect Health logo

This blog post will guide you through a complete installation step by step. AAD Connect health supports both ADFS 2.0 and 3.0. This post is applicable to both versions, but steps are conducted on a Windows 2012 R2 server (ADFS 3.0). There are extra steps for ADFS 2.0 that will be explained and detailed.

NB : Until the writing time of this blog, Azure Active Directory Connect Health is in Public Preview version. Active Directory Federation Services is the only service that can be monitored with Azure AD Connect Health. This includes AD FS servers, AD FS Proxy servers, and Web Application Proxy servers. Microsoft will be adding additional services to Azure AD Connect Health during the preview with future updates. I have no information about the final release date.

Azure AD Connect Health is now GA

This blog will be organized like the following:

Introduction : I will introduce Azure AD Connect Health

Requirements : I will present the different requirements to prepare to be able to use Azure AD Connect health

Deployment : I will present and detail the different steps to successfully deploy Azure AD Connect Health



Azure AD Connect Health is an Azure Service. It’s running and maintained in Azure. It’s agent based. Agents have to be installed on the servers to be monitored. Those agents will collect information and send them back to the Azure endpoints. The Azure AD Connect Health view and configuration panes  are accessed via the Azure Preview portal.



  • Azure Active Directory Premium license

You should own an Azure Active Directory Premium license to be able to use Azure AD Connect Health. To verify that your Azure Active Directory license is premium, connect to the Azure portal (, sign in and go the Directory View (AzureDirectory). Go to the LICENSES tab and look to your LICENCE PLANS. Verify that your LICENCE PLAN includes the Azure Active Directory Premium feature (The following picture shows the LICENSES tab view, and we can see that the License plan is EMS (Enterprise Mobility Suite), that includes AAD Premium.

Snap 2015-04-30 at 16.34.40

(Picture Credit: SAMIR FARHAT)

  • Azure AD Global administrator account and assigned license

The user account you will use to register the AAD Connect health agents must be part of the global administrator role, on your Azure Active Directory Premium tenant. In addition, it must be assigned a license.

To verify that your account is a global administrator , connect to the Azure portal (, sign in and go the Directory View (AzureDirectory). Go to the USERS. Find your user account and enter its Properties.  Verify that the Organization role is set to Global Admin. If not, tell your Azure Active Directory administrator to add you to this role, or to provide you with a Global admin account.

Snap 2015-05-02 at 18.02.48

(Picture Credit: SAMIR FARHAT)

To verify that the user account is assigned a license,  Go to the LICENSES tab, enter the Properties of your License Plan, select All users, and find the user account. Verify that the Assignment Status is Enabled. If not, you can assign it a license using the Assign button on the bottom of the page.

Snap 2015-05-02 at 18.13.57

(Picture Credit: SAMIR FARHAT)

  • AAD Connect Health Agent requirement : For ADFS servers, ADFS auditing must be enabled to use Usage Analytics

To be able to use Usage Analytics for ADFS, ADFS auditing must be enabled on the ADFS Federation servers. Enabling Auditing is not applicable on ADFS Proxy servers and ADFS Web Application servers. If you have a load balanced ADFS farm, some configuration will be  made only on the Primary server (I will note it), so if it’s your case, connect first to the Primary server.

|||| The following steps should be done on all your ADFS federation farm servers (or in the unique federation server if you are not in a farm configuration)

Logon to your ADFS federation server with a domain user with local administrative privileges. Open the Local Security Policy console (SECPOL.mmc)

Snap 2015-04-30 at 14.53.07

(Picture Credit: SAMIR FARHAT)

Navigate to the Security Settings\Local Policies\User Rights Assignment folder, and then double-click Generate security audits.

Snap 2015-04-30 at 14.54.34

(Picture Credit: SAMIR FARHAT)

On the Local Security Setting tab, verify that the AD FS service account is listed. If it is not present, click Add User or Group and add it to the list, and then validate by clicking OK

 Snap 2015-04-30 at 14.55.05

(Picture Credit: SAMIR FARHAT)

Open a command prompt with elevated privileges and run the following command to enable auditing: auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable

Snap 2015-04-30 at 14.56.12

(Picture Credit: SAMIR FARHAT)

Verify that the command was successfully executed.

|||| The following steps should be done on the primary  ADFS federation  server (if you are in a farm configuration) or in the unique federation server if you are not in a farm configuration

Open the AD FS Management snap-in by going to  Server Manager, Tools. Select AD FS Management

Snap 2015-04-30 at 14.56.47

(Picture Credit: SAMIR FARHAT)

Go to the Actions pane, click Edit Federation Service Properties

Snap 2015-04-30 at 15.36.18

(Picture Credit: SAMIR FARHAT)

In the Federation Service Properties dialog box, click the Events tab. Check the Success audits and Failure audits check boxes and validate by clicking OK

Snap 2015-04-30 at 15.36.35

(Picture Credit: SAMIR FARHAT)

Now, you can locate the ADFS audit logs. Open Event Viewer, Go to Windows Logs and select Security, On the right, click Filter Current Logs.

Snap 2015-04-30 at 15.37.08

(Picture Credit: SAMIR FARHAT)

Under Event Source, select AD FS Auditing then click OK

Snap 2015-04-30 at 15.37.35

(Picture Credit: SAMIR FARHAT)

If your ADFS server is processing requests, you will see events logged and scrolling

Snap 2015-04-30 at 15.37.46

(Picture Credit: SAMIR FARHAT)

  • Allowing Azure endpoints (websites) on Internet Explorer

|||| The following steps should be done on all your ADFS  servers : Federation servers, Proxy servers and WAP servers

AAD connect health agents communicates with Azure services via different endpoints (During installation and registration). If Internet Explorer Enhanced Security is enabled, add the following websites on the IE trust Zone.

Open Internet Explorer, go to Internet Options, Security, Trusted Sites and click Sites

Snap 2015-05-03 at 23.02.37

(Picture Credit: SAMIR FARHAT)

Add the Azure sites to the trusted list then click Close

Snap 2015-04-30 at 15.42.39

(Picture Credit: SAMIR FARHAT)

|||| Inbound connection to Azure Endpoints services

AAD Connect Health agents will communicate with Azure services endpoints. You must be sure that all your ADFS servers can reach the following targets :

  • DNS: * – TCP Port: 5671 (New)
  • https://*
  • https://*
  • |||| Update .NET Framework, Windows Management Framework and Internet Explorer (Only For Windows Server 2008 R2 SP1 ie ADFS 2.0)

    This steps are only applicable if you are using ADFS 2.0 on top of Windows Server 2008 R2 SP1. 3 steps are required if they not already done :

    • Update the .NET Framework to version 4.5 : You can download the offline .NET Framework 4.5 installer HERE 
    • Update the Windows Management Framework to version 4 : Powershell version 4.0 is mandatory for the AAD connect health agents. Powershell 4.0 comes with Windows Management Framework  version 4.  You can download the Windows Management Framework 4.0 HERE. Please read carefully the system requirements before proceeding.
    • Update Internet Explorer to version 10 or later : If your IE version is not already IE 10 or 11, then you should update it to Internet Explorer 11. Download HERE

    NB :  Each update discussed below will require the server reboot, so install them in one shot to  reboot your server only once

    Agents installation and configuration

    After preparing your environment to AAD Connect Health (See requirements below), you can install the agents and configure them to communicate with Azure.

    Tip : Install your agents and configure them in a the order you want to see your servers in. In fact, the first registered server will appear first on the Azure AAD Connect Health portal. Ordering the servers is not possible in the current release (Public Preview)

    • First download the agent source and copy it to all your ADFS servers. You can get the agent from HERE.
    • Install the agent on your ADFS server

    Snap 2015-04-30 at 15.46.01

    (Picture Credit: SAMIR FARHAT)

    • Verify that the three following services are present on the Services list. The services state should be ‘Stopped’ and set to ‘Automatic’

    | Microsoft AD Health Diagnostic Agent

    | Microsoft AD Health Insights Service

    | Microsoft AD Health Monitoring Service

    Snap 2015-04-30 at 15.47.03

    (Picture Credit: SAMIR FARHAT)

    • Now, open an elevated Powershell window, and run the following command : Register-ADHealthAgent. A Signing in window will prompt you for your Azure AD credentials (Global Admin account). Just a tip : The credentials will only be used to register the host with Azure, it will not be used for further authentication. The registration process will generate a certificate to be used for the agent authentication with Azure.

    Snap 2015-04-30 at 15.52.00

    (Picture Credit: SAMIR FARHAT)

    You should check that the registration was successful.

    Snap 2015-04-30 at 16.38.28

    (Picture Credit: SAMIR FARHAT)

    Proceed with the agents installation on the remaining servers.

    Adding Azure Active Directory Connect Health to the Azure portal

    To verify and to begin using the AAD Connect Health on the Azure portal, you can check my next blog post : Azure Active Directory Connect Health : User Guide

Azure Active Directory Connect Health : User guide

Azure Active Directory Connect Health enables you to monitor, get reports and usage insights about the services you monitor with. This post aims to see how to access and use the AD Connect Health portal.


– Only users within the Global Admin role of the Azure Active Directory tenant can gain access to Azure Active Directory Connect Health feature. Till this time, RBAC feature is only provided for Azure Subscriptions, without a subscription, you cannot assign users to Azure User roles.

– Access to the Azure Directory Connect Health is only possible via the Azure Preview Portal (Azure Preview Portal)


Connect and sign in to the Azure Preview Portal with an account part of the Global Admin Azure AD role. The first step is to deploy the Azure Active Directory Connect Health service to your portal. Go to NEW > Identity > Azure AD Connect Health > Create

Snap 2015-05-07 at 12.12.38

(Picture Credit : SAMIR FARHAT)

The Connect Health tile will be added to the Start Board panel (Home).

Snap 2015-05-07 at 12.15.36

(Picture Credit : SAMIR FARHAT)

Now you can click it to access to the Connect Health service. You will land on the Azure Active Directory Connect Health welcome blade.

Azure AD Connect Health  blades

On the Welcome blade, we can find 3 main sections : Summary, Services and Configure.

Snap 2015-05-07 at 12.26.30

(Picture Credit : SAMIR FARHAT)


The Summary section contains a Quick Start button. It will lead you to a blade where you can get (download) the Azure AD Connect health agent, access to the Azure AD Connect health documentation and provide feedback to the relative Azure team

Snap 2015-05-07 at 12.26.43

(Picture Credit : SAMIR FARHAT)


The Configure button will permit you to access the blade to configure two options:

  • Allow the agents automatic update : By default this option is enabled (ON). Agents installed on managed servers will be updated automatically when new versions are available.
  • Allow Microsoft to access the tenant’s health information : This option is disabled by default. It will permit to Microsoft to access the heath information to help you troubleshoot some issues in case of support. Disable it in case you are not in a ongoing support with Microsoft.

Snap 2015-05-07 at 12.26.58

(Picture Credit : SAMIR FARHAT)


This is the main button to access the information and the main blades. It gives you a view of the services being managed by AD Connect Health. In my case, only ADFS services are managed. Click on the service to access the next blade.

Snap 2015-05-07 at 14.53.47

(Picture Credit : SAMIR FARHAT)

Hint : Due  to the continuous improvements of the Azure portal, you can reduce or maximize the blades. This will permit you to focus on the blade your are working on

The blade exposes 4 sections: Overview, Operations, Monitoring and Usage Analytics

Overview : This button will take you to the next blades where you can access each monitored servers details like alerts, monitoring information, properties and so on.

Operations : This button will lead you to the Alerts blade where you can access each server alert and related information.

Monitoring : This button will open the blade where you can see each server monitoring information

Usage Analytics : This blade will provide you with  some usage information related to your managed services

Hint: Using the Overview button, you will access the operations and Monitoring information too (The same information). The difference is that using the Overview button, you will select first the server, then access its related information (per server). The Operations and Monitoring buttons will group all the servers on the same chart and graphic (that can be filtered later). On the next sections, I will use the Overview blade to show the Operations information, and use the Monitoring blade to show the monitoring information.

How to  use  the blades to access the information


Click on the Overview button, the Server List blade will  open. Choose a server to access to. At this stage, normally you will have a similar view.

Snap 2015-05-07 at 15.25.37

(Picture Credit : SAMIR FARHAT)

So how to use this view ?


This blade will provide you with different information about the server like the Operating System, the hardware configuration and the AAD connect Health agents version

Snap 2015-05-07 at 15.37.27

(Picture Credit : SAMIR FARHAT)

Missing QFEs

This blade will show you the installed QFEs (Quick Fix Engineering ie updates) and warn you whenever a required or recommended QFE is not installed

Snap 2015-05-07 at 15.37.46

(Picture Credit : SAMIR FARHAT)


The Operations blade is the Alerts blade, it will show you the active and resolved alerts. You should know that AAD Connect Health automatically resolves alerts.

Snap 2015-05-07 at 15.38.04

(Picture Credit : SAMIR FARHAT)

You can customize the time range by clinking on the Time Range button on top of the blade. Until this public preview version, the only possible periods to choose are : 6 hours, 24 hours and one week. The 24 hours is the default value

Snap 2015-05-07 at 15.38.16

(Picture Credit : SAMIR FARHAT)

If you click on an alert (Active or resolved), a new blade will be expanded to show you information like the alert state, rising time, the alert description. In addition, it will give you a fix proposition if applicable.

Snap 2015-05-07 at 15.38.29

(Picture Credit : SAMIR FARHAT)


Click on the monitoring button to access the Monitoring Blade

Snap 2015-05-07 at 17.19.45

(Picture Credit : SAMIR FARHAT)

This view will provide you the following information:

  • Token Requests / second
  • ADFS Private Bytes
  • Outstanding Token Requests (Proxy)
  • Rejected Token Requests / Second (Proxy)
  • TCP Connections Established
  • Token Request Latency (Proxy)
  • Used Memory (%)
  • Used Processor (%)

It will give you the Min, Max and Average value of these metrics during a period of time.

You can filter which Server to include on the graphic. On the left top corner of the blade, click the Filter Button.

Snap 2015-05-07 at 17.29.45

(Picture Credit : SAMIR FARHAT)

Select only the server or servers to include on the Monitoring blade.

Snap 2015-05-07 at 17.29.54

(Picture Credit : SAMIR FARHAT)

You can place your mouse on any point of the curve to see the exact value at this time. You should know that the values are caught every 30 minutes, And that, the values between are just an interpolation

Snap 2015-05-07 at 17.32.44

(Picture Credit : SAMIR FARHAT)

You can edit the displayed metric and the time range by right clicking anywhere on the graph and choosing Edit Chart

Snap 2015-05-07 at 17.48.18

(Picture Credit : SAMIR FARHAT)

Usage Analytics

The usage analytics blade provide you with very interesting information about the ADFS usage. It’s more granular that the Monitoring feature and adds specific details about the service (ADFS in our case)

You can via this blade, display a combination of the following metrics/grouping:

Snap 2015-05-07 at 18.01.16

(Picture Credit : SAMIR FARHAT)

For example you can display the total requests by Server or by Relying Party.

To achieve this, right click anywhere on the graph and click Edit Chart. Choose the desired chart.

Snap 2015-05-07 at 18.04.26

(Picture Credit : SAMIR FARHAT)

The graph will automatically be updated. And a nice view will be shown. Just admire the ‘landscape’. You can even use the Filter button to filter which grouping element to display. If you  hover the circle, It will permit you to zoom  every hovered element.

Snap 2015-05-07 at 18.09.11

(Picture Credit : SAMIR FARHAT)

Here we go. This was a simple user guide of AAD Connect Health. As noted before, this still a preview version and this post may not be accurate with the final version.