Tag Archives: Azure Iaas

#Azure : Large Virtual Machines Scale Sets


In general, virtual machines scale sets provide auto scalability based on the need. With the normal scale sets, you can have a deployment of 0-100 VMs. But if you have requirements to deploy large scale set of more than 100 VMs then you can opt for large virtual machine scale sets. The basic difference between two is placement group. Placement group in virtual machine scale set is nothing but kind of availability set that maintains its own fault and update domains. This placement groups in virtual machine scale sets have been defined by a parameter “singlePlacementGroup” that has two values either “true” or “false”, if this value is set to “true” then scale set will have a single placement group and the number of virtual machine can be between 0-100, and if the value of “singlePlacementGroup” parameter has been set to “false” then scale set will have multiple placement groups and the number of virtual machine can be between 0-1000.

There is one most important consideration for large VM scale sets i.e. storage. If you choose to go with large VM scale sets then you use managed disks and don’t define your own storage accounts. In VM scale sets, if you don’t go with managed disk then you require multiple storage account i.e. 1 for every 20 VMs but in case of large scale sets you leverage managed disks that simplifies your overhead of managing multiple storage accounts.

Let see how to do it.

Login to the Azure portal and search for “scale” in the azure market place and select the “Virtual machine scale set”.

In the Virtual machine scale set panel, select “Create” to create a new Virtual machine scale set.

In the “create virtual machine scale set” fill the basics information.

Virtual machine scale set name = Enter the scale set name for your virtual machine scale set deployment.

Operating system disk image = Select the operating disk image from drop-down.

Subscription = select your subscription.

Resource group = Create a new resource group or select the existing one.

Location = Select the Azure region from drop-down.

User name = Enter the username that will be used for virtual machines.

Password = Enter the password for the user name.

Confirm password = Re-enter the password to confirm.

Scroll down and fill the required details under “Instances and Load Balancer”.

Instance count = Enter to VMs count between 0 – 100. If you enter any number more than 100 and up to 1000, all the configuration settings will be disable except instance size. As explained above, large-scale sets with more than 100 VMs use managed disk by default and deployment of these large-scale sets take place across multiple placement groups.

Instance size = Select the VM size based on your requirement.

Enable scaling beyond 100 instances = By default “No”, if you select “Yes” then rest of the settings will be disabled as described under instance count. Select “Yes” for large Virtual Machines Scale Sets.

Autoscale = By default disabled but if you enable this feature then you need to define the conditions for the auto scaling.

If Autoscale enabled, fill the required details.

Autoscale

Minimum number of VMs = Enter the minimum number of VMs that required in this scale set.

Maximum number of VMs = Enter the maximum number of VMs that required in this scale set.

Scale out

CPU threshold (%) = Enter the cpu threshold after that VM will be added.

Number of VMs to increase by = Enter the number of VMs that will added when your running VMs reach defined cpu threshold.

Scale in

CPU threshold (%) = Enter the cpu threshold after that VM will be removed.

Number of VMs to decrease by = Enter the number of VMs that will removed when your running VMs reach defined cpu threshold.

Once filled all the details, click on create to start the deployment process.

Apart from these configuration settings, you need to consider following while planning for large VM scale sets.

Limit of 1000 VMs only applicable if you use Azure Marketplace images otherwise you can scale up to 300 VMs if you use your own customize image.

When designing network for large VM scale sets using a single subnet, make sure that your subnet has enough IP addresses for all the VMs. As a best practice, reserve 20% more ip addresses than what you need to support large scale sets.

Azure Load Balancer Standard SKU work with large scale sets because of multiple placement group while scale sets with 100 VMs can leverage basic Load Balancer.

Layer 7 load balancers and application gateways don’t need any specific configuration for large scale sets.

Make sure you are defining fault domain for the VMs that should not be in same fault domain, by default VMs will be speeded across fault and update domain in a specific placement group but that doesn’t mean that two VMs (for ex: these two VMs are required all the times) will not be deployed on same hardware. Use Azure resource explorer and go to the instance view of scale set and verify the fault domain and placement group Ids for the specific VMs.

Make sure you have enough vCPU quota to support large number of VMs in a large VM scale set, otherwise request to increase your vCPU quota.

You can convert your Virtual Machine Scale Set from a single placement group (1-100 VMs) to multiple placement group (1-1000 VMs) using Azure Resource Explorer but not vice-versa. You may not get the option to upgrade to large VM scale sets if you are using old version of the Microsoft.Compute API.

#Azure : Virtual Machines Scale Sets


Microsoft Azure virtual machines scale sets are a next step in high availability and scalability of virtual machines. Virtual machine high availability can be achieved by availability sets in Microsoft Azure. Microsoft Azure virtual machines scale sets are a group of an identical compute resources deployed in multiple availability sets. It is a true scalable model of auto-scaling that can target large-scale services with big compute, large data and containerized workloads. As these virtual machine scale sets leverage multiple availability sets in the background, therefore scale operations are tacitly balanced across fault and update domains. These scale sets use five fault domains and five update domains in each availability set. Each virtual machine scale sets can host 0-1000 VMs based on platform images, and 0-300 VMs based on custom images.

To define autoscale configuration for consistent application performance, many permutation and combination can be used. Very common rules are compute, memory, and disk I/O utilization. Apart from these common rule of performance metrics, auto scaling of VMs can also depend on application response, or a fixed scheduled.

Note: Virtual Machines scale sets can also be deployed with availability zones.

Now, let me explain you how does this auto scaling works behind the scene. When a new VM added to the scale set, a VM instance Id will be provided to each VM that is unique within a scaleset. When you add or remove a virtual machine from the scale set, the existing Id doesn’t go anywhere. For Example: In a virtual machine scale set you have 10 VMs, if your 2 VMs removed from the scale set based on the configuration and need, and then after some time 5 VMs are added based on the load then new VMs will have Instance id 10, 11, 12, 13, 14 in an incremented manner and these VMs will be balanced across fault and update domains to maintain maximum availability.

Let see how to do it.

Login to the Azure portal and search for “scale” in the azure market place and select the “Virtual machine scale set”.

In the Virtual machine scale set panel, select “Create” to create a new Virtual machine scale set.

In the “create virtual machine scale set” fill the basics information.

Virtual machine scale set name = Enter the scale set name for your virtual machine scale set deployment.

Operating system disk image = Select the operating disk image from drop-down.

Subscription = select your subscription.

Resource group = Create a new resource group or select the existing one.

Location = Select the Azure region from drop-down.

User name = Enter the username that will be used for virtual machines.

Password = Enter the password for the user name.

Confirm password = Re-enter the password to confirm.

Scroll down and fill the required details under “Instances and Load Balancer”.

Instance count = Enter to VMs count between 0 – 100. If you enter any number more than 100 and up to 1000, all the configuration settings will be disabled except instance size. As large-scale sets with more than 100 VMs use managed disk by default and deployment of these large-scale sets take place across multiple placement groups.

Instance size = Select the VM size based on your requirement.

Enable scaling beyond 100 instances = By default “No”, if you select “Yes” then rest of the settings will be disabled as described under instance count.

Use managed disks = By default “Yes”.

Public IP address name = Define name of the public IP address that will be used for load balancer, which will be placed in front of the scale set.

Public IP allocation method = By default dynamic but Static can be selected.

Domain name label = Domain name label for the load balancer in front of the scale set.

Autoscale = By default disabled but if you enable this feature then you need to define the conditions for the auto scaling.

If Autoscale enabled, fill the required details.

Autoscale

Minimum number of VMs = Enter the minimum number of VMs that required in this scale set.

Maximum number of VMs = Enter the maximum number of VMs that required in this scale set.

Scale out

CPU threshold (%) = Enter the cpu threshold after that VM will be added.

Number of VMs to increase by = Enter the number of VMs that will added when your running VMs reach defined cpu threshold.

Scale in

CPU threshold (%) = Enter the cpu threshold after that VM will be removed.

Number of VMs to decrease by = Enter the number of VMs that will removed when your running VMs reach defined cpu threshold.

Once filled all the details, click on create to start the deployment process.

As you observed that in the entire process, virtual network and storage account was not asked anywhere because virtual machine scale sets take care of it behind the scene based on the configuration. Therefore, you don’t have to really worry about it.

#Azure : Step-by-step Availability Sets


In my previous post, I had explained about the high availability configuration for Azure virtual machines, Availability Sets, Fault domains and Update domains. In this blogpost, I’ll cover step-by-step configuration using Azure Portal. Availability Set configuration can be done in two ways, either by creating and configuring it in early stage based on your application architecture or set it up while creating a first VM for each tier and add rest of the same tier VMs to the respective availability set.

I am going to explain, how to create and configure availability set in advance.

Login to the Azure Portal and select “+ Create a resource”.

In the Azure Market Place, search for Availability Set.

From the search results, select “Availability Set”.

In the Availability Set panel, select create.

In the create availability set panel, define the parameters.

Name: Enter the name of the availability set.

Subscription: Select the subscription.

Resource group: Either create a new one or select an existing one based on your requirement.

Location: Select the location.

Fault domains: Select the number of fault domains, by default it is two but for specific Azure regions you can select up to three fault domains.

Update domains: Select the number of update domains, by default it is five but you go up to 20 update domains in each availability sets.

Use managed disks: Select Yes (by default) if you would like to use managed disk for all the VMs that will be create in this availability set otherwise “No”.

Once, you have filled all the details based on your requirement then select “create” to start the deployment of availability sets.

Wait for few seconds, your availability set will be created. Now, you can go head and create your VMs using this availability set.

While creating a virtual machine you get both the options, either select the existing availability set or create a new one.

If you select the “+ Create new” then again you have to fill the same details as filled earlier then select “OK”.

Once you created an availability set, you will not able to modify it and the same concept applies to VM as well. If you have created a VM as part of the availability set then you can’t come out or change the availability set until you delete and recreate it.

#Azure : Virtual Machines High Availability


High availability is crucial for any production environment either it is in on-premises datacenter or in cloud. If you will go in detail of high availability, you will observer that HA can be achieved in the following levels from compute perspective:

Hardware level

Hypervisor/VM level

Operating System level

 

In this blogpost, I’ll cover high availability options available in MS Azure. First, make it clear that OS level HA has no difference between on-premises or in cloud. Now, let me provide the overview of H/W, and Hypervisor/VM level HA in on-premises datacenter or private cloud.

Hardware level HA: Dual or Quad processor, dual power supply, multi memory channel, multiple network slots, and multiple PCI card slots etc.

Hypervisor/VM level: All type 1 hypervisors provide high-availability configuration options like operating systems. Once, you configure HA for the hypervisor the VM can be created on top of that and hypervisor HA configuration maintains the availability for guest VMs if any host goes down.

Apart from the H/W and hypervisor level, all the datacenter components can be configured in high available mode such as multiple racks and power supply units etc. but when it comes to public cloud you can’t define the above configurations by your-self. However, cloud service provider does all these configurations for you in advance and to simply the things for you it just provides an availability feature.

Microsoft Azure provides “Availability Set” to provide high-availability at the VM level. This availability set feature takes care of both planned and unplanned failures. To define these planned and unplanned failures, availability set allows you to configure update domain and fault domains.

In simple words, availability set is a logical grouping of two or more virtual machines. When you setup the availability set keep the following principles in your mind:

Setup an availability set for one type of VMs. For example, in 3 tier application architecture create different availability sets for each tier.

For high availability of VMS, create multiple VMs in an availability set.

Attach load balancer with availability sets. It helps you to divide the load among the VMs.

Now, let me explain you update domain and fault domain.

Update domain: An update domain allows VMs to maintain availability during planned maintenance. Each update domain contains set of virtual machines and associated physical hardware that can be updated and rebooted at the same time. It allows Azure to perform incremental or rolling upgrades across a deployment. Once, you create an availability set then you can observe that there are five update domains by default set but you can configure up to twenty update domains.

Fault domain: A fault domain allows VMs to maintain availability during unplanned hardware failures, network outages, power failures and software updates. Fault domain describes the datacenter level components such as network switches and power supply serving a single rack can become a single point of failure for one rack or multiple racks. To avoid these circumstance, VMs in an availability set can have at least two fault domains. Many Azure region only supports two fault domains while other Azure regions can have maximum three fault domains.

If you would like to setup an availability set, follow the step by step availability sets blogpost.

#Azure : Virtual Machine Configuration


When you have decided to use Azure IaaS virtual machines based on your requirements, you need to look at the configuration. Resource group is required to create any resource in Microsoft Azure. Let see the configuration of virtual machine.

Login to the Microsoft Azure Portal and select “+ create a resource”. Select compute and then select OS that needs to be deployed as part of the VM. In my case, I am deploying “Windows Server 2016 Datacenter”.

In the first step, define settings as required.

Name = Name of the virtual machine, same name will be applied as a host name.

VM disk type = Either HDD or SSD

User name = Default administrator name

Password = Password for the administrative user name

Confirm password = Confirm password for the administrative user name

Subscription = Select subscription from where the VM cost will be deducted

Resource group = Either “Create new” or “Use existing”

Location = Select the location of your Azure Region

Windows license = Select “Yes” if you have windows license otherwise “No”

Finally select “OK”

In the second step, select the VM size based on your requirement. You can short the VM size by selecting disk type, vCPUs and Memory.

In the third step, configure optional features.

High Availability = If you are deploying multiple VMs in the HA mode, create an “Availability set” and define fault & update domain as needed.

Storage = If you would like to use disk managed by Microsoft, select “Yes” in “Use managed disks” option. Otherwise select “No”, if you select “No” then you need to define a storage account.

Network = Select virtual network for the VM. If you don’t have any then a new will be created for you by default but still you can define your virtual network and use the same.

Subnet = select subnet, an ip to the VM will be assigned from this subnet

Public IP address = Use public ip address, if you want to access this VM directly through the internet. Otherwise you can select “None” here.

Network security group = Use network security group, if you would like to access or deny network traffic on the VM level.

Extensions = If you need to use any extensions as part of the VM deployment then add extensions such as PowerShell DSC, Custom Script Extension etc.

Auto-shutdown = Either “On” or “Off” and define the time and time zone based on your needs.

Notification before shutdown = Either “On” or “Off”

Monitoring = Either “Enabled” or “Disabled” for boot and guest OS diagnostics. If you enable the diagnostics then you need to use a storage account. This diagnostics user account either you can create or use the existing one.

Backup = Either “Enabled” or “Disabled”. If you enable backup option then you need to define “Recovery Services vault”, Resource group (for recovery service vault) and backup policy.

Once done select OK.

In the fourth step, review all the configuration and select “Create” to start the deployment process.

Wait for couple of minutes, your VM will be available for use. If you would like to reuse the VM configuration as-is or would like to reuse the VM configuration with customization then “Download template and parameters” for future deployments.

#AzureAD : Application Proxy


I believe many of you have heard about reverse proxy multiple times in your IT career. If anytime you had published any web application through reverse proxy, you can easily understand the complexity and pain behind it. To publish a web application, you would have been worked with multiple teams for fulfilling security, network and DMZ requirements. Azure AD makes it quite simple for us, you just need to enable, download and install application proxy, and finally publish your internal web application. To use this application proxy server, you need a Windows server with either Windows Server 2012 R2 or Windows Server 2016 operating system and keep this VM as a standalone machine. So now, let’s have a look how to do it.

Login to the Azure Portal from application proxy VM and go to Azure Active Directory and then go to the Application proxy to download connector.

A web browser will open, select terms and condition and download the tool.

Once tool is downloaded, run the tool and agree to the license terms and condition and click on Install.

Now, AAD Application Proxy Connector installation will start.

Login to the Azure AD through your AAD admin account to complete the installation.

Now, installation will progress further and will finish in few minutes.

Now, go to the Azure portal and enable application proxy.

Once it is done, you will be able to find your application proxy server in active status.

Now, It is a time to publish your internal application. Therefore, go to the Enterprise applications under Azure AD.

Click in “On-premises application”.

Enter your internal url and save the settings. However, you should note down the external url to access this application.

Select Assign a user for testing.

Add users and define their roles and click on Assign.

Once, you are done please wait for some time. Now access your application from the internet by using the external url. You can also publish this app through myapps portal, the way we publish enterprise apps from the gallery.

Now, you can see that I am able to access my intranet portal. (I am not a developer, however I tried to modify the default IIS page )

If you have MFA enabled for your users, you can leverage an additional layer of security for your internal web applications as well.

#Azure – Resource groups, Access control (IAM)


Resource groups in Microsoft Azure is a logical container and help customers to manage multiple resources in constructive manner. When you deploy multiple resources in a logical container then it is necessary to consider the security measures as well. Resource groups provide an option to manage the access control through Access control (IAM).

It offers multiple pre-defined RBAC (role based access control) roles. When you create a new subscription first time in Microsoft Azure, by default azure creates and associates it with an automatically created azure active directory. For example if I create my subscription with email address xyz@hotmail.com then an azure active directory with xyzhotmail will be created in the background. Going forward you can add multiple subscriptions into it.

However, once you are logged in to the Microsoft Azure then you can switch between the directories if you have multiple. But keep a note in your mind that one subscription belongs to only one directory in azure while one directory can belongs to multiple subscription.

RBAC roles can be assigned to the users and groups that are part of the associated azure active directory. Groups can be created in azure active directory while users either can be created in azure active directory or can be associated with their public email addresses.

Here is the list and their one line descriptions provided by Microsoft Azure.

Role name

Description

API Management Service Contributor

Can manage API Management service and the APIs

API Management Service Operator Role

Can manage API Management service, but not the APIs themselves

API Management Service Reader Role

Read-only access to API Management service and APIs

Application Insights Component Contributor

Can manage Application Insights components

Automation Operator

Able to start, stop, suspend, and resume jobs

Backup Contributor

Can manage backup in Recovery Services vault

Backup Operator

Can manage backup except removing backup, in Recovery Services vault

Backup Reader

Can view all backup management services

Billing Reader

Can view all billing information

BizTalk Contributor

Can manage BizTalk services

ClearDB MySQL DB Contributor

Can manage ClearDB MySQL databases

Contributor

Can manage everything except access.

Data Factory Contributor

Can create and manage data factories, and child resources within them.

DevTest Labs User

Can view everything and connect, start, restart, and shutdown virtual machines

DNS Zone Contributor

Can manage DNS zones and records

Azure Cosmos DB Account Contributor

Can manage Azure Cosmos DB accounts

Intelligent Systems Account Contributor

Can manage Intelligent Systems accounts

Logic App Contributor

Can manage all aspects of a Logic App, but not create a new one.

Logic App Operator

Can start and stop workflows defined within a Logic App.

Monitoring Reader

Can read all monitoring data

Monitoring Contributor

Can read monitoring data and edit monitoring settings

Network Contributor

Can manage all network resources

New Relic APM Account Contributor

Can manage New Relic Application Performance Management accounts and applications

Owner

Can manage everything, including access

Reader

Can view everything, but can’t make changes

Redis Cache Contributor

Can manage Redis caches

Scheduler Job Collections Contributor

Can manage scheduler job collections

Search Service Contributor

Can manage search services

Security Manager

Can manage security components, security policies, and virtual machines

Site Recovery Contributor

Can manage Site Recovery in Recovery Services vault

Site Recovery Operator

Can manage failover and failback operations Site Recovery in Recovery Services vault

Site Recovery Reader

Can view all Site Recovery management operations

SQL DB Contributor

Can manage SQL databases, but not their security-related policies

SQL Security Manager

Can manage the security-related policies of SQL servers and databases

SQL Server Contributor

Can manage SQL servers and databases, but not their security-related policies

Classic Storage Account Contributor

Can manage classic storage accounts

Storage Account Contributor

Can manage storage accounts

Support Request Contributor

Can create and manage support requests

User Access Administrator

Can manage user access to Azure resources

Classic Virtual Machine Contributor

Can manage classic virtual machines, but not the virtual network or storage account to which they are connected

Virtual Machine Contributor

Can manage virtual machines, but not the virtual network or storage account to which they are connected

Classic Network Contributor

Can manage classic virtual networks and reserved IPs

Web Plan Contributor

Can manage web plans

Website Contributor

Can manage websites, but not the web plans to which they are connected

Source: Microsoft

Now, you should know how the permission works here. There are three basic RBAC roles that apply to all resource types.

Owner: As suggested by name itself, full access to all the resources and has rights to manage the delegation for others.

Contributor: who can read, write/create and manage but can’t delegate rights to others.

Reader: who can view existing resources but can’t make any changes.

Now, let’s look at the inheritance of the resources. Same as other Microsoft technologies, permission inheritance works in a downwards manner here.

It means Subscription à Resource groups à Resources.

If pre-defined RBAC roles do not fulfill your requirement then you can create your own custom roles through Azure PowerShell, Azure CLI and the Rest API.

#Azure – Base Operating System


Microsoft Azure supports multiple base operating system for VMs. There are many other supported scenarios where you get the base OS with application from the portal itself or you can use your customize image either for base OS only or base OS with application. In this blogpost, I’ll cover the list of base operating systems available for VMs.

List of supported operating systems in Microsoft Azure:

Operating Systems

Provided By

Pricing

Window Server 2016 (Datacenter, Datacenter – Sever Core, Nano Server, with Containers)

Microsoft

Free*

Windows Server 2012 R2 (Datacenter, Essentials)

Microsoft

Free*

Windows Server 2012 Datacenter

Microsoft

Free*

Windows Server 2008 R2 SP1

Microsoft

Free*

Ubuntu Server

Canonical

Free*

Red Hat Enterprise Linux 7

Red Hat

$0.06/hour

SUSE Linux Enterprise Server

SUSE

Free*

Debian Linux

Credativ

Free*

Oracle Linux 7

Oracle

BYOL

CentOS-based 7.3

Rogue Wave Software

Paid

Container Linux by CoreOS

CoreOS

Free*

Free BSD 10.3

Microsoft

Paid

Clear Linux OS

Clear Linux Project

BYOL

Open SUSE Leap 42.2

SUSE

Paid

Windows 7 Enterprise N with SP1 (x64)

Microsoft

Paid

Windows 8.1 Enterprise N (x64)

Microsoft

Paid

 

Free*: OS Price has included with VM pricing.

BYOL: Bring your own license

Paid: Additional OS cost will be added.

 

Note: The above information is true at present when I am writing this blog. List can be modified any time by Microsoft and therefore it doesn’t guarantee any accuracy for future use.

#Azure – Resource Group


Microsoft Azure is one of the leading cloud platform and growing continuously. This post will cover the resource group concept, which is integral part of any resource in Azure IaaS. Microsoft Azure platform has been spread across multiple geographical locations and once you create any resource in MS Azure IaaS, basically it belongs to a particular region that you had selected at the time of deployment.

In layman’s language, resource group is nothing but it is just like a logical container that makes your life easier after deployment of multiple resources. Let’s take an example of virtual machine. When you create a virtual machine, you can observe that it is a combination of multiple resources such as compute, storage, networking etc. In case of traditional datacenter you can touch and feel these items but in case of virtual machine you can presume that your cpu cores and memory is your compute, virtual hard disks are your storage and virtual networks are your networking components. As you know each resource in a virtual machine gives complement to another resource and for us it is advisable to keep all of them in a single pool for better interaction. Once you create these resources such as storage account or virtual network, you specify a resource group and location. If you have an existing resource group then the location will be selected by default as per the resource group.

Now, let’s discuss the same thing in technical language. A resource groups allows you to create and manage multiple resources in a single container so that you can manage them easily by grouping them together. A resource group facilitates that all the resources in a resource group belongs to same region, where the resource group was located but you can still change the resource location if you want. This feature make sure that multiple resources are located nearby to each other to provide better performance. With the help of resource group, you can easily deploy, update, and delete multiple resources within the resource group by a single or few clicks. Resource group provides you an ability to secure your resources by configuring user and administrator roles through “Access control (IAM)”. There are many other cool features such as policies, monitoring etc. that you can explore by playing with it.

Therefore now let’s see how to create a resource group.

Go to the https://portal.azure.com and click on “Resource groups”.

Click on “Add” to create a new resource group.

Fill the required information such as “Resource group name”, select “Subscription” and select “Resource group location”.

Once resource group has been created, you can see multiple options such as “Access control”, “Resource costs”, “Policies” etc.

To understand better, you can take an example of cluster/pool. Multiple components such as VMs, storage pools and virtual networks make a single cluster/pool and if you need to manage these multiple components, it is better always to keep them in a single place called resource group so that you can have a single view from the application point of view such as cluster manger and from the baseline infrastructure point of view as well that is resource group. Now, you should start playing with it to learn more about each option given under resource group.

#Skype4b: Key planning considerations for SfB on Azure IaaS Part III


Part I and Part II of this blog post series covers basic of key designs considerations, typical server configuration in traditional datacenter environment, Azure IaaS nomenclature and mapping Azure IaaS components with traditional datacenter. This part of the blog post covers the limitation of Azure IaaS for Skype for Business Server.

First, let me describe the Skype for Business role wise limitations.

Skype for Business Server Role Limitations on Azure IaaS
Front End Technically feasible
Back End Supported
Mediation Technically not feasible
Director Technically feasible
Persistent Chat Technically feasible
Video Interop Technically not feasible
Edge Technically not feasible

Supported: Server role such as Back End server is fully supported because it uses SQL server in the background and SQL server is a supported application on Azure IaaS.

Technically feasible: Technically feasible server roles are those server role that can be deployed but there is no performance study data exist.

Technically not feasible: Technically not feasible server role are those server roles their recommended configuration can’t be met on Azure IaaS. However, technically you may deploy these roles on Azure IaaS VM.

Above mentioned “technically not feasible” server roles are lacking technically because of network configuration most of the time. As everybody knows that Lync/Skype for Business is network intensive application and network requirement are little complex for Skype for Business deployment. Following are the key limitations in Skype for Business deployment on Azure IaaS:

  • All the VMs type doesn’t support more than one NIC. If you don’t select right VM in the beginning, you will have to redeploy the VM to support more than one NIC.
  • Azure IaaS doesn’t support multiple VNet for single VM.
  • Quality of Services can’t be configured as you can’t access Network switch deployed in Azure datacenter.
  • Enterprise Voice can’t be configured.
  • Video Integration Server configuration is difficult if you have Skype for Business infra on Azure IaaS.

Though, these functionality may be enabled in future but as of now not available. Therefore, Microsoft doesn’t recommend or support Lync / Skype for Business deployment on Azure IaaS.