There is some limitation of setting up VMs (virtual machines) using the new Azure portal http://portal.azure.com

Let me explain some of these limitations now. Oh and I better mention that CSP licensing is all ARM ONLY! In other words, with CSP licensing there is no link to ASM at all, it doesn’t even give you the option of selecting (classic) in brackets.

ARM Load Balancer:

Creating virtual machines in the new Azure portal only allows you to create a new VM with an NSG (Network Security Group). If you want to create a VM with an ARM based load balancer, you need to create the ARM based load balancer first as a separate step.

Let me quickly explain the sister to the Azure ARM load balancer – the NSG. The NSG performs the same functionality of the ARM load balancer by way of inbound NAT rules (endpoints) and is available in both ASM and ARM. The NSG is an easy option for the vast majority of customers as it’s deployable via the new Azure portal and via anything else, however in the instance of the NSG, even though you can apply the same NSG to multiple VMs, it’s more suited to a single VM as you can’t seem to break up the NAT rules specific to each VM behind the same NSG.

The ARM load balancer on the other hand is the closest match to the old ASM (Azure Service Management) based Cloud Service and provides the same functionality as the NSG by way of NAT rules. However, the ASM/ARM load balancer is not supported on the basic family of VMs, which means you can only use the NSG for basic VMs. Also you can’t setup a new ARM based VM with a load balancer in the new Azure portal – it leaves other setup options such as JSON or PowerShell.

Scary eh!

Just when you thought this is scary enough, the load balancer also incorporates:

• Frontend IP configuration, Backend address pool and the optional health probe
• Both Inbound NAT Rules and Load Balancer Rules

What is the difference? Frontend IP configuration is the IP configuration in front of the load balancer on the internet side which includes a PIP. The Backend address pool is a conglomerate of virtual machines that form the pool of VMs behind the load balancer. Of course, this only means something when it comes to using load balancer rules. If you are simply copying the ASM setup of having more than one virtual machine behind a cloud service and both VMs in an availability set, then the ARM load balancer is simply just a glorified firewall in which you can forget about load balancer rules and use Inbound NAT rules only.

There is the option of using a Network Security Group as well with an ARM based resource group. However, it seems there’s a limitation with the NSG where you can’t map different ports with inbound NAT rules, e.g. a high port from outside 65476 which maps to 3389 internally. The way to take care of port translation is to use the ARM based load balancer as the firewall, pretending and treating it like the ASM based cloud service for the benefit of NAT rules without using it for the purposes of actual load balancing.

New VMs with custom VHD (disks):

The other big limitation of the new Azure portal is the fact that you can’t create virtual machines from existing VHD disks like you could with the ASM classic portal. This means that you only are left with the option to create a new VM using an existing disk with the aid of PowerShell.

$vm = New-AzureRMVMConfig -VMName 'VMName' -VMSize 'VMSize'
$vm = Set-AzureRMVMOSDisk -VM $vm -Name 'DiskName' -VhdUri' DiskURI' -CeateOption attach -Windows
New-AzureRmVM -ResourceGroupName 'ResourceGroupName' -Location 'AzureRegion' -VM $vm