Well, what we mean with this title is that we will move some resources from the classic Azure portal (ASM) to the new portal (ARM) with Azure Site Recovery (ASR).

While doing this Proof of Concept, we will also try out a few other things that Azure made possible:

  • – create classic ASM Resources through the new ARM Portal
  • – use the new VNET peering between a VNET in ASM and a VNET in ARM

Create ASM resources through the ARM portal

The ASM design contains two Web VM’s and one SQL Server in a Cloud Service where the Web servers are load balanced on incoming HTTP requests.

Create the virtual network


Quick check in the old portal shows that the provided VNET name gets changed:

What we can see here is that during the creation, it has added some prefixes to the name we gave it:

group comes from ‘resource groups’

asm2arm is the name of the resource group

In the new portal, it’s mandatory to specify Resource groups (check the red asterisk next to resource group selection). However, Resource Groups are new and specific to ARM and hence not known in the old portal.

Create the Web VMs



Checking the VM names after deployment shows that this went well, it didn’t add any RG prefixes to the name.

What's noticeable, is that we have selected the new F1 VM size for the WebVM’s and in the classic portal it shows as A0 Shared.

So which one won? Lets go have a look inside the VM itself (drums please).

As you can see, the VM has 2GB of RAM, which is what the F1 Size has.

What IS different than using a ARM deployment is that during the network settings you must also specify a DNS name for your cloud service. 

Looking in the old portal shows that this Cloud Service is built:

Create the Load Balancer Set

If you paid attention to the deploy settings of WebVMs, you might notice that we added an HHTP endpoint for the  Cloud Service (and its load balancer), but we actually needed to remove this one to have a fully functional load balancing over both Web VMs.

This is how it goes if you want to create the LB for the CS in the new portal:

On WebVM1 select Load Balancer Set:


Result WebVM1:

Doing the same for WebVM2, but here we select the previously created LBset:

Create SQL Server

Secondly, we deploy our SQL server. To make it easy on ourself we choose to select a SQL SKU from the Azure marketplace, which will result in a prepared and functional SQL server.

Remark regarding the endpoints listed in ARM and what is actually set in ASM, in the output you see that the ports are mapped 1 on 1. However these settings are different in the old portal:

When you add endpoints in ASM, these are automatically open to the internet (with some NATing rules on them), especially for SQL ports this is not a preferred setting so we closed these down by setting an Access Control List on that:

Checking the SQL VM in the classic portal also shows that this specific VM must be resized through the new portal:

Configure the application

Now that we have all the compute available for our application, we still needed to add the application settings and data to the servers.

To do so, we have two PowerShell DSC scripts that automate this process, but even while the new portal shows the option to use ‘VM Extentions’. This will fail upon use as this is not supported on ASM VMs, so in this case we had to do this manually.

Remark: Trying out VM extentions on ASM VMs resulted in having difficulties when starting and stopping the VMs, multiple retries are required since this test.

Anyhow, the application is up and running and available through the Cloud Service DNS name we specified and web requests are load balancing between the two web servers:


What would be better is that when you select the ‘Classic’ deployment option during VM creation it would only show you the options that are available for ASM and that the naming of the VNET is consistent.

Conclusion of this first part could be that the new portal is good to look at ASM resources, but using it to deploy ASM resources still needs some improvements.