Systems Inside: Migrate Azure Portal ASM to Resource Manager ARM

Today I will show you how to migrate your Azure Service Management (ASM) virtual machines to the ARM (Azure Resource Manager) environment. In this new structure the IAAS service has become more complete and malleable in creation, you can create a virtual machine with two network cards and move that same network card to another machine without having to create everything again. This freedom of movement of resources between virtual machines has made the Azure administration service much easier.

So, let's Start!

The ASM model was very closed unlike the model in ARM, as we can see in the figure below:

Along with the virtual machines I will migrate the virtual networks, Cloud Services, Public IP Addresses, VPN and VNET-to-VENT configurations in "one shot". I mean, all the migration at the same time (With MigAZ its different).

In the new portal you can use tools like WAF (Web Application Firewall) and NSG GUI (Network Security Groups) among other appliances. All the new stuff are coming only for ARM portal. So, be ready for migration!

In this post I will show you how to migrate using two different approaches and technologies. One is using only Azure Powershell and the other is using MigAZ, not supported by Microsoft, but as far as I know it was the only tool available a few months ago.

The tools available at the moment: (I'm only going to describe Powershell and MigAZ)

I'm not actually present you the Advantages of eah one, but you can see that on the following link:
https://cmatskas.com/options-for-migrating-azure-vms-from-asm-v1-to-arm-v2/

Lets start with Powershell! And then with MigAZ.

PowerShell Migration

Supported resources for migration

Virtual Machines
Availability Sets
Cloud Services
Storage Accounts
Virtual Networks
VPN Gateways
Express Route Gateways (in the same subscription as Virtual Network only)
Network Security Groups
Route Tables
Reserved IPs

Supported scopes of migration

Migration of virtual machines. Only in cloud services (NOT in a virtual network)
Migration of virtual machines (in a virtual network)
Storage accounts
Unattached resources (Network Security Groups, Route Tables & Reserved IPs)

Not Supported

Unassociated virtual machine disks
Virtual machine images
Endpoint ACLs
Virtual network with both ExpressRoute Gateway and VPN Gateway
ExpressRoute with authorization links
Application Gateway (remove before migration)
Virtual networks using VNet Peering
Role Based Access Control (RBAC)
Multiple subnets associated with a VM
Virtual machines that belong to a virtual network but don't have an explicit subnet assigned
Virtual machines that have alerts, Autoscale policies
XML VM extensions (BGInfo 1.*, Visual Studio Debugger, Web Deploy, and Remote Debugging)
Cloud services that contain web/worker roles
Virtual networks that contain App Service environments
Virtual networks that contain Azure AD Domain services
Virtual networks that contain Azure RemoteApp deployments

Validate the Migration

The validate operation is the first step in the migration process. The goal of this step is to analyze data in the background for the resources under migration and return success/failure if the resources are capable of migration.

You select the virtual network or the hosted service (if it’s not a virtual network) that you want to validate for migration.+

If the resource is not capable of migration, the Azure platform lists all the reasons for why it’s not supported for migration.

Prepare the Migration

The prepare operation is the second step in the migration process. The goal of this step is to simulate the transformation of the IaaS resources from classic to Resource Manager resources and present this side by side for you to visualize.

If the resource is not capable of migration, the Azure platform stops the migration process and lists the reason why the prepare operation failed.
If the resource is capable of migration, the Azure platform first locks down the management-plane operations for the resources under migration. For example, you are not able to add a data disk to a VM under migration.

Abort the Migration

Abort is an optional step that you can use to revert your changes to the classic deployment model and stop the migration. This operation cannot be executed after you have triggered the commit operation

Commit the Migration

After you finish the validation, you can commit the migration. Resources do not appear anymore in classic and are available only in the Resource Manager deployment model. The migrated resources can be managed only in the new portal.

Requirements

Uninstall BGInfo extension in the new portal or by powershell

Get-AzureVM -ServiceName "cloudservice" -name "vmname" | Set-AzureVMBGInfoExtension | Update-AzureVM

$VM1 = Get-AzureVM -ServiceName "cloudservice" -Name "vmname"

Set-AzureVMBGInfoExtension -VM $VM1 –Uninstall -ReferenceName "BGInfo" | Update-AzureVM

Uninstall Protection Agent in the new portal or by powershell

$VM1 = Get-AzureVM -ServiceName "cloudservice" -Name "vmname"

Set-AzureVMExtension -VM $VM1 –Uninstall -ReferenceName "VMSnapshot" -ExtensionName "VMSnapshot" -Publisher "Microsoft.Azure.RecoveryServices" -Version "1.0" | Update-AzureVM

You can see more details on the following link:

http://www.itgeekrambling.co.uk/azure-migrating-asm-to-arm-removing-extensions/

Unregister and delete protected content in the Vault containers (if you have any)

In backup vault, go to Protected Items tab and select the VM. Click on Stop Protection. Leave Delete associated backup data option unchecked. In the Azure portal, go to the Extensions menu for the VM and uninstall the VMSnapshot/VMSnapshotLinux extension. After the migration you have to recreate the Vault and all the Backup Jobs.

Disable automation (if you have). You don't want to migrate several virtual machines and in the meantime all of them are rebooting or changing types because you had an automation script.

Take note of all the Virtual Machines Endpoints before migration because you will lose visibility of them after migration.

1. Connect to Azure

Install the latest version of Azure PowerShell --> http://aka.ms/webpi-azps

Get-ModulePowerShellGet -list | Select-Object Name,Version,Path

Install-Module AzureRM

Import-Module AzureRM

Get-Module AzureRM -list | Select-Object Name,Version,Path

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Ensure that you are co-administrator for the subscription in Azure Classic portal

Login-AzureRmAccount

Get-AzureRMSubscription | Sort SubscriptionName | Select SubscriptionName

Select-AzureRmSubscription –SubscriptionName "NAME"

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

Now sign in to your account for the classic ASM model (continue only if the result of previous command is Registered)

Add-AzureAccount

Get-AzureSubscription | Sort SubscriptionName | Select SubscriptionName

Select-AzureSubscription –SubscriptionName "NAME"

Make sure you have enough Azure Resource Manager Virtual Machine cores in the Azure region of your current deployment or VNET

Get-AzureRmVMUsage -Location "REGION"

2. Migration of virtual machines. Only in cloud services without VNET

Select your Service

Get-AzureService | ft Servicename

$serviceName = "CLOUD_SERVICE"

$deployment = Get-AzureDeployment -ServiceName $serviceName

$deploymentName = $deployment.DeploymentName

Validate to see if there are any issues

$validate = Move-AzureService -Validate -ServiceName $serviceName -DeploymentName $deploymentName -CreateNewVirtualNetwork

$validate.ValidationMessages

Prepare the migration

Move-AzureService -Prepare -ServiceName $serviceName -DeploymentName $deploymentName -CreateNewVirtualNetwork

After the Prepare operation succeeds with either of the preceding options, query the migration state of the VMs. Ensure that they are in the Prepared state.

$vmName = "VM_NAME"

$vm = Get-AzureVM -ServiceName $serviceName -Name $vmName

$vm.VM.MigrationState

Commit (if everithing looks good on the new portal) or Abort the operation

Move-AzureService -Abort-ServiceName $serviceName -DeploymentName $deploymentName

Move-AzureService -Commit -ServiceName $serviceName -DeploymentName $deploymentName

NOTE: This procedure will create a new VNET for the migrated virtual machine. You can add or change it after migration succeeded.

NOTE: This is an idempotent operation. If it fails, it is recommended that you retry the operation. If it continues to fail, create a support ticket.

3. Migration of virtual machines with VNET

Select your Network Name (VNET). All the virtual machines associated with this network will be migrated

$vnetName = "NETWORK_NAME"

Validate to see if there are any issues

Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName | select -expandproperty validationmessages

Prepare the migration

Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName

If you get this error, please retry the operation and check if you have the latest Powershell tools:

Move-AzureVirtualNetwork : XrpVirtualNetworkMigrationError : Template ITSSRV-SQL04-Template deployment failed.
CorrelationId=51369df7-a3be-4dd4-a46e-9b6feba731de

At line:1 char:1

+ Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : CloseError: (:) [Move-AzureVirtualNetwork], ComputeCloudException

+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.Network.MoveVirtualNetworkCommand

Virtual Machines that are not in a classic Virtual Network are stopped deallocated in this phase of migration. If all the resources are OK in the new portal you can commit. If you see any issues, you can always abort the migration and go back to the classic deployment model. After you go back, the Azure platform will open the management-plane operations on the resources so that you can resume normal operations on those VMs in the classic deployment model.

Commit or Abort the operation

Move-AzureVirtualNetwork -Abort-VirtualNetworkName $vnetNamePS

Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName

NOTE: This is an idempotent operation. If it fails, it is recommended that you retry the operation. If it continues to fail, create a support ticket.

4. Storage Accounts

After all the IaaS resources have been migrated, you should migrate the associated storage accounts.

Validate of there are disks not attached to any VM. If preceding command returns disks then ensure that virtual machines to which these disks are attached are migrated before migrating the storage account.

Get-AzureDisk | where-Object {$_.MediaLink.Host.Contains($storageAccountName)} | Select-Object -ExpandProperty AttachedTo -Property DiskName | Format-List -Property RoleName, DiskName

Get-AzureDisk | where-Object {$_.MediaLink.Host.Contains($storageAccountName)} | Format-List -Property DiskName

If above command returns disks then delete these disks using following command

Remove-AzureDisk -DiskName 'DISK_NAME'

Verify if there are any images on the storages

Get-AzureVmImage | Where-Object { $_.OSDiskConfiguration.MediaLink -ne $null -and $_.OSDiskConfiguration.MediaLink.Host.Contains($storageAccountName)} | Select-Object -Property ImageName, ImageLabel

Get-AzureVmImage | Where-Object {$_.DataDiskConfigurations -ne $null -and ($_.DataDiskConfigurations | Where-Object {$_.MediaLink -ne $null -and $_.MediaLink.Host.Contains($storageAccountName)}).Count -gt 0 } | Select-Object -Property ImageName, ImageLabel

If there are, delete all the VM images returned by above commands using preceding command:

Remove-AzureVMImage -ImageName 'IMAGE_NAME'

Migrate the storage account (one by one)

$storageAccountName = 'STORAGE_ACCOUNT_NAME'

Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName

Move-AzureStorageAccount -Abort -StorageAccountName $storageAccountName

Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName

All done! Your IaaS infrastructure is now migrated to the new Portal. All the items in the old portal are gone. Happy Azure!

5. Notes

You need to create new NSG (Network Security Groups) for all the endpoints and for all the Virtual Machines that you took note before. So if you have ports 80and 443 open in one Virtual Machine in classic mode you will need to create a NSG with that ports. The old Endpoint are not visible on the ARM portal

Everything that is migrated will be in a dedicated Resource Group called "*-Migrated". You can change afterwords the Resource Group. No, you can't rename RG yet... This powershell commands can let you move resources between RG:

$reource = Get-AzureRmResource -ResourceName azdcs0102 -ResourceGroupName RG-Migrated

Move-AzureRmResource -DestinationResourceGroupName azproef01 -ResourceId

$resource.ResourceId

Create a recovery services vault and configure backup on the migrated virtual machine using Backup action on top of vault dashboard. Recreate all the Backup jobs that you had in the old portal

Activate Automation if you disabled it before migration.

List of some common errors are described in this Microsoft article: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/migration-classic-resource-manager-errors

MigAZ Migration

You can download the latest version in https://github.com/Azure/migAz

As I'm writing, the version is 2.2.3.0

One of the peculiarities of this application is that it can migrate ASM to ARM and ARM to ARM. So you can use it to migrate IaaS resources from one ARM subscription to another.

This tool is Open Source and its operation is very simple, it uses Service Manager REST API, to collect all the information of Network, Storage and VMs and after this, all this data is exported to a .json file so that it can be deployed In the ARM model.

Supported resources for migration

Virtual Machines
Availability Sets
Cloud Services
Storage Accounts
Virtual Networks
Public IPs
Load Balancers

Supported scopes of migration

Migrate ASM to ARM
Migrate ARM to ARM
Only Virtual Machines, VNETs and Storage accounts
Only VNETs
Only Storage Accounts
Combination of resources

Not Supported

All that is not listed is not supported

Requirements

Windows 8 or Windows Server 2012, or later
.Net Framework 4.0 or higher
Latest Azure PowerShell Module --> http://aka.ms/webpi-azps
Login credentials at source Azure subscription
Login credentials at destination Azure subscription
Stop all the Virtual Machines to be migrated! Because this tool will create a snapshot and then migrate the data between Blobs. The disks of the source virtual machines are copies using a one-time-only snapshot. If customers are still using the source virtual machines after the copy, then data will be lost during the switchover.

1. Change options and Connect

Change the naming suffixes (this is optional but very useful). If you don't change any, the names will be the same in the ARM portal.

As you can see, there is also a option to build an empty environment on the ARM portal. This is very useful if you want to replicate your configuration or to test something. The option for select all dependencies is enabled by default. So, if you migrate a VM, it will automatically select the storage account and VNET of the VM.

Connect using the Classic ASM credentials and select the Tenant and Subscription

2. Select Resources to Migrate

Select Virtual Machines, Storage, VNETs or the entire ASM portal

Change the proprieties of the Virtual Machine

Name of the new Resource Group and Location

Target VNET and Subnet

If you choose several VMs to migrate, be careful with all the options, mainly the storage accounts.

3. Export the configurations and Execute

Export to a defined location. You will have a .json file with all the ASM configurations and it will open a web page with all the command that you will need to execute. Let's see for instance this one:

Login-AzureRmAccount -SubscriptionId 'SUBS' -TenantId 'XXX'

Select-AzureRmSubscription -SubscriptionId 'SUBS'

Create new Resource Groups

New-AzureRmResourceGroup -Name "RES_GROUP" -Location "westeurope"

Create all the Resources that you selected

New-AzureRmResourceGroupDeployment -TemplateFile "export.json" -ResourceGroupName "RES_GROUP"

This will result in an error. This is expected since the disks are not copied yet.

Copy disks between Blobs

& '<Location_Of_MigAZ>\BlobCopy.ps1' -ResourcegroupName "RES_GROUP" -DetailsFilePath "copyblobdetails.json" -StartType StartBlobCopy

& '<Location_Of_MigAZ>\BlobCopy.ps1' -ResourcegroupName "RES_GROUP" -DetailsFilePath "copyblobdetails.json" -StartType MonitorBlobCopy

The disks start copying do ARM portal:

This can take several hours. You can expect like 500MB in one minute. So you can transfer 1TB in 33 hours. This speeds may vary! One thins is for sure, it will only transfer blocks of data and not empty blocks. So if you have 1TB of disk and only using 200GB, it will only trsnafer 200GB.

Again, create all the Resources that you selected, but this time with the disks already copied

New-AzureRmResourceGroupDeployment -TemplateFile "export.json" -ResourceGroupName "RES_GROUP"

Very that everything is OK on the new Portal. Start a VM and see that everything is working.

4. Post-Migration

Because the tool creates a Load Balancer matching each Cloud Service, after the migration is complete, you need to change the DNS records that were pointing to the Cloud Service DNS name or IP to point to the new Load Balancer DNS name or IP
The Public IP address change, so you will need to reconfigure the On-Premises VPN. Same for VNET-to-VNET configurations
You can keep the .JSON file as a backup
The MigAZ copy files, so you will have all the data replicated between portals. You must delete all the Classic resources already migrated.

All these tools are still very recent, feel free to give opinions and feedback on your migrations.

That's it!

Paginas

24 May 2017

Migrate Azure Portal ASM to Resource Manager ARM - Powershell & MigAZ