Azure – Migrating ASM to ARM – Removing extensions

So I’ve been looking at moving my VMs from their comfy home in “Classic” Azure to the new shiny world that is ARM.  Like most people I had a look at the videos online and read the MSDN blogs and guides.  As usual they do make it look so easy! well I am sure like me you always take those materials with a rather large grain of salt.

So begins my journey into moving VMs to ARM (Azure Resource Manager).  In this scenario I am migrating an entire VNET to ARM.  According to the MSDN it is a case of a few commands and away it goes!….hum

First off you need to connect to both ARM and ARM, save me typing all that out you can look here and follow Step 3.

Once you’re connected to your Azure resources the fun starts.

Ok, lets validate the current configuration to see what is broken/unhappy.

$vnetName = “VirtualNetwork”
$validate = Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName

After you run that, if like me, you’ll see lots of errors and warnings.

Azure ASM to ARM migration validation errors

In my case there was a list of extensions that were not supported by the migration process.  Interestingly one of these is the default extension for “classic” VMs and yet there is no mention of removing it an any of the MS documentation.  The extensions listed on my VM were

BGInfo – as mentioned, this is installed as default with classic VMs
Microsoft Monitoring Agent – Installed by Operation Management Suite
VMSnapshot – Installed as part of the Site Recovery/Backup service

Because none of these are supported either within the migration process or in ARM they need removing.  Simple I thought, after all how hard can it be!


A quick search around MSDN came up with the command for removing the BGInfo extension:

Get-AzureVM -ServiceName “cloudservice” -name “vmname” | Set-AzureVMBGInfoExtension -Disable -ReferenceName “BGInfo” | Update-AzureVM

Alas, it wasn’t going to be that easy and I was presented with this lovely error:

BadRequest: Cannot upgrade a resource extension reference BGInfo in Role vmname to state Disable.

BGInfo extension causing an error

Ok, lets tweak that command and run the following, tyring the “Uninstall” parameter now.

$VM1 = Get-AzureVM -ServiceName “cloudservice” -Name “vmname”
Set-AzureVMBGInfoExtension -VM $VM1 –Uninstall -ReferenceName “BGInfo” | Update-AzureVM

Alas that threw up an error as well, however this error (sorry I didn’t get a screenshot) mentioned a version 2.  Hummm I wonder…..quick query against the installed BGInfo extension

Get-AzureVM -ServiceName “cloudservice” -name “vmname” | Get-AzureVMBGInfoExtension

And this reveals that the BGInfo version is 1.*, right lets upgrade this chappy to version 2.0 and see if we can remove the blighter then.

Get-AzureVM -ServiceName “cloudservice” -name “vmname” | Set-AzureVMBGInfoExtension | Update-AzureVM

Once upgraded, I check the version again….ok, version 2.0

Successful upgrade of BGInfo extension

Right…now lets see if we can remove it

$VM1 = Get-AzureVM -ServiceName “cloudservice” -Name “vmname”
Set-AzureVMBGInfoExtension -VM $VM1 –Uninstall -ReferenceName “BGInfo” | Update-AzureVM

A-ha…got it this time

Successful removal of BGInfo from VM

A quick query of the VM to see that the extension has gone

Get-AzureVM -ServiceName “cloudservice” -name “vmname” | Get-AzureVMExtension

Reveals the BG extension has been removed.

Microsoft Monitoring Agent

Now this is installed by OMS so removing it I am assuming will break any history in OMS.  At the time of typing I’ve not confirmed if this is the case so please test before proceeding.

Get a list of extensions from the VM

Get-AzureVM -ServiceName “cloudservice” -name “vmname” | Get-AzureVMExtension

Finding detail of the OMS extension - Monitoring Agent

To remove this chappy just run the following:

$VM1 = Get-AzureVM -ServiceName “cloudservice” -Name “vmname”
Set-AzureVMExtension -VM $VM1 –Uninstall -ReferenceName “Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent” -ExtensionName “MicrosoftMonitoringAgent” -Publisher “Microsoft.EnterpriseCloud.Monitoring” -Version “1.*” | Update-AzureVM

That should see this extension removed from the VM.


The last extension to remove is this one.  Now this is part of the recovery services within Azure, this means you’ll need to remove the protection of the VM before running this.  Please refer here before proceeding.

Run the following

$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


Ok, my case I’ve removed the extensions that were flagged by the validation check.  Now when I run the check I see that “almost” everything passes

ARM migration validation check succeeds

The bottom warning we can ignore, the very last step before migrating the VNET is disconnecting the S2S VPN.  This can be done after the preparation command but must be done before the comit.  At least that is Microsoft’s advice.  I discovered that after running “Prepare” the old VNET was put in a “migrating” state and you can’t make changes.  In my case I ran the Move-AzureVirtualNetwork command with the -about switch then made the changes to the VNet and finally ran “Prepare” and “Commit”.

The top error relates to the state to the VM and it’s not in stable state, it’s reported as “RoleStateUnknown”.  Don’t panic, this is because we been ripping out all these extensions the worker processes haven’t caught up.  Give it 10 minutes or so and this error will resolve itself.

Ok, you’re all set to migrate…..good luck!



3 thoughts on “Azure – Migrating ASM to ARM – Removing extensions

  1. Andrew

    Great help! Thanks for sharing with us that are going through the same challenges!

  2. Pingback: The Migration: Getting started – Azureblog

    1. Rob Post author

      It’s been a long time since I set this up, the only thing I can suggest is if you are using MFA in your environment check that you’re using a valid app password. I do remember that email took a little while to start syncing, I can confirm this still works as a solution as I use it every day on my phone.


Leave a Reply

Your email address will not be published.