Phidiax Tech Blog

There has been much discussion as of late relating to the changes in Azure and the eventual need to migrate Azure resources and VMs to that new model. I can understand the confusion if you have not heard of this change. I imagine that you have seen the “Check out the new portal” button at the top of the Azure management page. 

• The OLD Azure Portal - https://manage.windowsazure.com
• The NEW Azure Portal - https://portal.azure.com

Azure - New Resource Model

Keep in mind, this is not only a new portal experience, it is an entirely new model for Azure resources and is the long term model going forward. The new model is the Azure Resource Management (ARM) model (more here Azure Resource Manager Overview). Azure classic model, also known as Azure Service Management (ASM), is being deprecated. As a result, Azure users are being asked to deploy new resources in the newer model, whether those resources are virtual machines, applications, or storage resources.

Considering Migration - ASM to ARM

This poses a problem for users that already have resources created within the classic model. 

What will become of those resources?

Microsoft has a plan for the eventual migration of those resources for users that are in that predicament, but for those who are actively using Azure and are wishing to increase there resources within a given environment there is the dilemma of:

Do I create these new resources in the classic model and wait for this “migration” from Microsoft, or move the resources over before expansion of the my environment?

Azure ASM to ARM Tooling

There are some very effective tools that have been developed to assist with these types of migrations, and this blog will depict how to utilize for our efforts:

• ASM2ARM Tool GitHub Source: https://github.com/fullscale180/asm2arm

Scenario

In this scenario, the use case is as fllows:

• Migration FROM - Multiple VMs that exist in a single Virtual Network
• Migration TO - A single resource group in ARM

Azure ASM2ARM Usage - PreRequisites

The primary use of the ASM2ARM script is to provide the ability to move a single VM from the ASM model to the ARM model. There is attention to capture the virtual network settings and bring those over with the VM when the script is executed.

Previous to running the script there are a number of items that are required:

• Caveats: VMs cannot be in Affinity groups, they must be regionally located, i.e. West US, East US, etc.
• Install PowerShell 5.0 Production Preview or greater is a requirement for the script
• To execute PowerShell cmdlets you will need the Microsoft Azure PowerShell module. See Microsoft Azure Downloads to download the module.
• In ARM
• Create a resource group
• Create a storage account within the resource group
• If the VMs are configured with a virtual network:
• Create a virtual network within the resource group with the same name as the virtual network they exist in on the ASM environment and append "arm" to the end of the name, (ex. vnet1 is named vnet1arm)
• Create identical subnets as they exist within the new virtual network
• Know the login credentials for the VMs being moved

Launch PowerShell ISE as Administrator

Azure ASM2ARM Usage - Execution

Connect to your Azure accounts and set the subscriptions that you will use as default

#Import Azure module
Import-Module Azure

#Import AzureRM module
Import-Module AzureRM

#CD to local folder where git ASMtoARM was cloned
Import-Module .\asm2arm.psd1

#Connect to your AzureSM account
Get-AzureAccount

#List your Azure Subsciptions
Get-AzureSubscription

#Login to you AzureRM account
Login-AzureRMAccount

#set the default subscription that you want to use for ASM and ARM accounts
Select-AzureSubscription -SubscriptionId <SMsubid>
Select-AzureRmSubscription -SubscriptionId <RMsubid>

Access aside, you will begin to provision resources needed for this migration

#Create Azure Resource Group
New-AzureRmResourceGroup –Name <RGName> –Location <Regional Location>

#Create new storage account in the resource group you just created
New-AzureRmStorageAccount -ResourceGroupName <RGName> -Name <StorageAcctName> –Type <Storage Type> -Location <Regional Location>

Create a new Virtual network in ARM that is that same as the previous one in ASM - for the virtual network name use the same name and append "arm" to the end

#use this script to add a subnet to an existing

$VerbosePreference = "continue"

Write-verbose "Setting Environment Variables"

$ResourceGroup = "<RGName>"

$VNETName = "<Name_VNET>"

$SubnetName = "<Subnet-2>"

$SubnetPrefix = "<ex. 10.0.0.0/24>"

Write-verbose "Adding a New Subnet to an Existing ARM based Virtual Network"

$vnet   = Get-AzureVirtualNetwork -ResourceGroupName $ResourceGroup -Name $VNETName

$vnet | Add-AzureVirtualNetworkSubnetConfig -Name $SubnetName -AddressPrefix $SubnetPrefix | Set-AzureVirtualNetwork

Write-verbose "Output of the Subnet's Associated with the ARM based Virtual Network $VNETName"

$VNET1 = Get-AzureVirtualNetwork -ResourceGroupName $ResourceGroup -Name $VNETName

$VNET1

Write-Verbose "Successfully Executed the Script"

Run Migration Script - 1st Server

Prior to running the actual migration you need to stop the virtual machines in ASM that you wish to migrate.

Be sure to add the service names and VM name using lowercase, as VM names are used to create the DNS name in ARM. DNS names must conform to the following regular expression: ^[a-z][a-z0-9-]{1,61}[a-z0-9]$. -  https://msdn.microsoft.com/en-us/library/mt125866.aspx

#Migration script and parameters

$vm = Get-AzureVM –ServiceName <ASMCloudServiceName> –Name <VMName>

Add-AzureSMVmToRM -VM $vm –ResourceGroupName <RGName> -DiskAction CopyDisks –OutputFileFolder <Folder where JSON config files will be created> -AppendTimeStampForFiles –Deploy -Verbose

Upon completion of the migration test that you can access the VM via RDP.

Run Migration Script - 2nd Server, or additional Servers

For the second VM the settings are already in place so the only thing to change is the Cloud Service name and VM name and change the –DiskAction to NewDisk so that a new VHD file will be used and settings will not be duplicated against the already created configuration.

#Migration script and parameters

$vm = Get-AzureVM –ServiceName <ASMCloudServiceName> –Name <VMName>

Add-AzureSMVmToRM -VM $vm –ResourceGroupName <RGName> -DiskAction NewDisks –OutputFileFolder <Folder where JSON config files will be created> -AppendTimeStampForFiles –Deploy -Verbose 

All VMs should be created and exist within the new virtual network as they did in the ASM model.

I hope this helps with your migration process. Feel free to buzz us with any questions or comments.