Say What?

Well, what I 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, I also wanted to try out a few things that were on my Azure bucket list:

– create classic ASM Resources through the new ARM Portal —> this blog post
– use the new VNET peering between a VNET in ASM and a VNET in ARM
– get comfortable with the latest release of Azure Site Recovery (v2)

I moved away from ASM since the arrival of the new (back then preview) portal, so I first need to create some resources and as mentioned before, this will all take place in the new portal, just to see what I’m running into.
The ASM design contains 2 Web VM’s and 1 SQL server in a Cloud Service where the Web servers are load balanced for 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, RGs are new and specific to ARM and hence not known in the old portal.

After that the network has been deployed, I have also added another subnet to the address space to host the SQL server.

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 is noticable, is that I have selected the new F1 VM size for my 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, wich 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 noticed that I added an HHTP endpoint for the  Cloud Service (and its load balancer), but I 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 myself easy I choose to select a SQL SKU from the Azure marketplace,
which will result in a prepared and functional SQL server.

note 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 I 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, I still needed to add my application settings and data to the servers.
To do so, I have 2 PowerShell DSC scripts that automate this proces, but even while the new portal shows the option to use ‘VM Extentions’, this will fail upon you as this is not supported on ASM VMs, so in my case I had to do this manually.

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

Conclusion
What I would like to have seen here 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 created with what is specified.
Personal conclusion of this first part is that the new portal is good to look at ASM resources, but using it to deploy ASM resources still needs some improvements … As ASM is planned to be phased out, I don’t think MSFT will put a lot of effert in optimizing this further.

Stay tuned for the second part of the blog!

part 2: create the recovery vault