From ASM to ARM – A real world migration

Developer Support

This post is provided by Senior Application Development Manager, Mark Pazicni, who walks us through an Azure migration exercise to move a legacy deployment in ASM to a modern deployment in ARM.

Migrating from Azure Service Management (ASM) to Azure Resource Manager (ARM) can be a daunting task, but hopefully this post will outline some common pitfalls and help you plan a smooth migration. This post does not outline every issue that could occur so you still need to validate for your own migration. This is simply a starting point for a real-world migration scenario.

For those that would like to explore outlined migration strategies here are a few links to existing strategies:

• ASM2ARM
• Platform Supported Migration
• MigAz

For those that want to run the native commands and use the “out of the box” PowerShell commands this post is for you. We will primarily be looking at the command Move-​Azure​Virtual​Network.

Pre-Requisites

ASM Subscription Limits

Checking your subscriptions limits is a very important first step when looking at migrating to ARM. That is because during the migration process you will effectively need to have double the capacity, even though you will not be double the actual artifacts will be having two management systems reporting the same artifact.

Common limits to review before migration (this is not an exhaustive list)

• Cores
• Storage accounts
• Cloud services
• Reserved IPs
• Data Source per backup vault

ARM Subscription Limits

• Load Balancer
• Cores
• Public IP Address
• Static IP Address
• Network Interface

Execution Steps

Setup

Prepare Phase

During this phase, this command tries to identify any artifacts that may have an issue during validate/commit. So you may have to run this command multiple times and mitigate each issue before moving to the next phase.

Common Issues found during Prepare and how to fix them:

• VMs xxxx in HostedService xxxx has Boot Diagnostics enabled, and is using a premium storage account. Please disable Boot Diagnostics feature for the VMs before continuing with migration. You can re-enable boot diagnostics in the Resource Manager stack after the migration is complete.
  • This is pretty self-explanatory.  Simply disabling the “Boot Diagnostics” and re-enabling it after migration mitigates this error.
• VM xxxx in HostedService xxxx contains Extension VMSnapshot which is currently not supported for Migration. Please uninstall it from the VM and add it back using Azure Resource Manager after the Migration is Complete.
  • Creating a simple PowerShell Script to ununinstall the VMSnapshot extensions is the easiest fix for this error
• Migration is not supported for Deployment xxxx in HostedService xxxx because it has multiple Availability Sets.
  • During the migration hosted services and limited to 1 or less Availability Sets are limited to therefore you will need to most additional Availability Sets and/or VM to separate hosted services.
• Migration is not supported for Deployment xxxx in HostedService xxxx because it has VMs that are not part of the Availability Set even though the HostedService contains one.
  • During migration, all VMs but belong to an Availability Set, simply moving all the VMs that are causing this error into one Availability Set will mitigate this issue.
• VM xxxx in HostedService xxxx contains Extension Monitoring reporting Handler Status : NotReady. Hence, the VM cannot be migrated. Please ensure that the Extension handler status being reported is Ready or uninstall it from the VM and retry migration.,Additional Details: Message=Enable failed for plugin (name: Microsoft.Azure.Security.Monitoring, version 3.3.0.0) with exception Command C:\Packages\Plugins\Microsoft.Azure.Security.Monitoring\3.3.0.0\AsmExtension.exe of Microsoft.Azure.Security.Monitoring has exited with Exit code: 6 Code=1009.
  • This error is because the Security Monitoring extension cannot be validated on the VM, simply by having the extension re-installed because of resizing of the server and any other such task, should re-install the extension and fix this error.
• VM xxxx in HostedService xxx contains Extension Monitoring reporting Handler Status: NotReady. Hence, the VM cannot be migrated. Please ensure that the Extension handler status being reported is Ready or uninstall it from the VM and retry migration.,Additional Details: Message=Uninstalling (name: Microsoft.Azure.Security.Monitoring, version: 3.2.2.0). Code=0.
  • This error is because the Security Monitoring extension cannot be validated on the VM, simply by having the extension re-installed because of resizing of the server and any other such task, should re-install the extension and fix this error.

Artifacts that will not migrate that you may want to look at converting ahead of time:

• Converting ACL to NSG
• Gateway Handling – either looking at getting your subscription whitelisted, otherwise you may have to have your gateway re-created post migration.
• Remediate Express Router – either moving the Express Route Circuit to ARM ahead of time and just marking it as ASM compatible, or look at moving it post migration.

Validate Phase

During this phase, this command creates artifacts in the Azure Resource Manager (ARM) that are pointers to the Azure artifacts currently running that are part of the Azure Virtual Network. Because of this, it is crucial that you have enough limits to have double the artifacts listed. While there are not duplicate artifacts running in Azure, their duplicate points in both ASM and ARM. Also during this phase, the artifact definitions are locked, you cannot start, stop, restart or otherwise make any changes via PowerShell or Portal once this phase is started and until you either commit or abort.

Abort Phase

During this phase, this command will rollback any artifacts created in ARM. This will also release the lock on the artifact definitions in ASM, so that you can make changes or fix any errors that showed up during the validate phase.

Commit Phase

During this phase, the command will commit the ARM artifact definitions and begin deleting the ASM definitions.

Please note at the time of this post, there was a known issue in which you would have to run multiple commit commands because of timeout issue when committing the definitions.

Additional Steps

Storage Account(s) – Move-​Azure​Storage​Account

Additional Links

ASM to ARM Scripts

Azure Service Management (ASM) – https://manage.windowsazure.com

Azure Resource Manager (ARM) – https://portal.azure.com

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality.  Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.

Developer Support App Dev Customer Success Account Manager, Microsoft Developer Support

Follow