Being able to move Managed Disks and Images, VMs and Snapshots in Azure across Resource Groups and Subscriptions is a MAJOR organizational improvement and time saver.
To get this new functionality in your Azure subscription, you’ll need to register the feature via PowerShell – be sure to do BOTH registrations – once for the feature, and register again for the Computer RP:
Register-AzureRmProviderFeature -FeatureName ManagedResourcesMove -ProviderNamespace Microsoft.Compute
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute
For example, we’ve been able to easily reorganize important but aged snapshots all into one resource group, cleaning up unnecessary Resource Group sprawl and consolidating some vital resources. The snapshots can still be moved across subscriptions and resource groups via PowerShell, but it helps to visually have them all in the same container.
An Azure service principal is a security identity used by applications, services, and automation tools to access designated Azure resources. The service principal is a ‘user identity’ (username and password) with an assigned role/permissions in Azure Active Directory (AAD). The service principal should only need to do specific things, unlike a general user identity. In this example, a new Service Principal will be created in AAD and assigned to an Azure Resource Group. Read here for the steps to register a new Service Principal using the Azure ARM Portal
1. #Login to Azure Subscription
Connect-AzureRmAccount -Subscription <Your Subscription Name>
2. #Declare Variables
$subscriptionId = <YOUR SUBSCRIPTION ID>
$tenantId = <YOUR TENANT ID>
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String 'YOUR SECURE PASSWORD OF CHOICE'
Being able to quickly swap out the OS disk of an Azure VM is a feature that means VMs don’t have to be ‘killed’ and rebuilt when there is a problem or a need for major revisioning of the VM. A backup OS managed disk, or a new OS managed disk, or an ‘earlier’ OS managed disk version can be applied in situ to the provisioned VM. We keep a repository of key versions of OS and Data disk snapshots that can be quickly turned into unattached managed disks when needed for fixing a VM.
#1. Login to Azure
The 3 overview steps to creating (or restoring) an Azure virtual machine (VM) from a stored snapshot of another VMs Operating System (OS) virtual hard disks (vhd).
- Create a Snapshot (already created for this exercise)
- Create Managed disks from Operating System (OS) and Data Disk Snapshots
- Create a VM from the Managed OS Disk and add data disk
This post shows how to create a VM in a new resource group, from disk snapshots. We will be attaching the new managed OS Disk to the VM with PowerShell while the VM is created. The data disk will be attached after the VM is created. Note in the diagram below, that after creating the managed disks, we will also need to add 4 more Azure resources for the new VM to be accessible:
- Network Interface
At the time of writing this, moving/migration of VMs with managed disks to a new Azure Subscription, is not supported in Azure. It is possible however, to move managed snapshots of a VM’s vhds to another Azure subscription, and then ‘reconstruct’ the VM using the OS and data disks snapshots or managed disks. The VM object itself is just metadata running the vhds (The Move option for both snapshots or managed disks displays in the Azure portal, but we found that the portal Move option does not work for our various Azure Accounts and Subscriptions.(See screen shot below).) The Move operations of snapshots or managed disks can be done easily via PowerShell.
Why move managed disks to another subscription? For example, once a Dev/Test environment is proven, the typical procedure is to migrate the IaaS infrastructure to an Enterprise Subscription for a production environment. Also, moving copies of snapshots out of the main subscription is beneficial for data retention in case of Disaster Recovery or accidental deletions.
A work around for this current limitation – not being able to move/migrate a VM, is to move the managed snapshot(s) to a new Subscription, and then create new managed disks of OS and data vhds for VM in another subscription. It is also possible to migrate a copy of a snapshot or a managed disk into a Storage Account as a page blob to be used by other subscriptions or even other Azure accounts. Read about moving Snapshots to a Storage Account
Unsuccessful Snapshot Move In ARM Portal:
While the option to Move to another subscription is shown on the snapshot blade, validation of the process failed giving the error that this subscription is not ‘registered to use Microsoft.Computer/ManagedResourcesMove feature…but a snap shot can easily be copied to another subscription via PowerShell.
Azure Snapshots of managed virtual hard drives (vhds) are stored in Resource Groups (as opposed to ‘unmanaged’ Snapshots being stored in storage accounts). While it is possible to move the managed snapshots to another subscription using PowerShell, there are advantages to having a copy of crucial core snapshots readily available and protected as a Page Blobs in a Storage Account.
With PowerShell, copies of the Snapshots can be exported to an Azure Storage Account to be able to:
- Maintain a separated set of crucial snapshot copies that cannot be deleted by accident, helpful as another Disaster Recovery point
- Quickly & easily copy Snapshots to a different Azure account or subscription using Microsoft Azure Storage Explorer and then create new managed disks and VMs in the different Account or subscription
- At the time of this writing, VMs with managed disks cannot be moved from one Azure region to another. The workaround is to export a snapshot of the VMs managed disks to a storage account in a different region, and then re-create the VM with the managed disk(s) in a Resource Group in the different region. Read more here.
1. #Login to Azure Portal (read here for a slick way to select the correct subscription context)
Working in Hyper-V before moving all of our resources from physical servers in datacenters to Azure IaaS or PaaS, we regularly took new snapshots of Virtual Machines (VMs) before testing major development changes, adding Windows updates, testing new application settings etc., to allow us to easily revert to the previous state of the VM if desired. In Azure, snapshots are taken of the virtual disks (vhd), not the VM instance itself. Snapshots are full, read-only copies of the vhds. A new VM is created with new managed disks created from stored snapshots of OS data disks; data disk snapshots are turned into managed data disks and then attached to a VM.
An Azure snapshot of a data or operating system (os) vhd can be used:
- For custom backup/restore of a VMs vhds
- For troubleshooting disk problems.
- To create a copy of production servers for use in development, or the opposite, copy a dev environment into production mode.
- To quickly duplicate a fresh VM instance. For example, we use specific single-tier and double-tier web server/sql server environments that need to be reproduced for various testing scenarios. A new ‘exact copy’ environment, with all accounts and applications in place, can be ready for access within 5 minutes if necessary, using stored Azure Snapshots of the OS and data disks. These are considered ‘specialized’ disks…
- To create a ‘repository’ of prepared OS and data disks for use in creating multiple VM copies.
- To create a dr backup repository of snapshots in a different region or subscription (or both), in case of accidental deletion of key OS or data disks.
- Backing up a VM before making a major change – although it is not possible to revert the VM to the previous state, the VM can be deleted and using the saved snapshots > create new managed OS and data disks > create a new VM using the previous VMs Nic, etc.
With multiple Azure subscriptions within a single Azure account, it is crucial to be logged into the correct Azure subscription (AzureRM Context), to be able to access the Azure resources within a specific subscription, via PowerShell (POSH). There is a default subscription that is set to open with each new POSH session. If this default subscription isn’t the preferred working subscription, you will have to select the correct subscription for every new POSH session.
With the Azure Context Autosave feature (added Sept 2017), it is possible that after setting the subscription for the current session, you can have the Azure credentials, account and subscription information saved and automatically loaded when you open a new POSH window – by using the Enable-AzureRmContextAutosave cmdlet
And for easy subscription selection, I recently found these simple POSH cmdlets here, to be able to brilliantly select the correct Azure Subscription by clicking on the list of Azure subscriptions in the Azure Windows account. No copying and pasting of subscription ID, name and/or tenant ID required!
Azure’s Point-to-Site (P2S) VPN gateway connection creates a secure connection to an Azure virtual network’s (VNet) resources from an individual client computer. A VPN gateway is created on its own subnet in an Azure VNet, and then configured to allow P2S connections. No VPN physical device is required and there are minimal, if any, changes required to be made to the on-prem network. A P2S VPN connection is established by starting it from the client computer. It is possible to also route a P2S VPN through a secure Azure VPN Gateway – but the software VPN Gateway is within the Azure subscription, not in the on-prem network.
The P2S VPN network connection is outlined in a red box in this diagram – note that P2S and Site to Site (S2S) VPN Gateways can co-exist within an On-Prem network with Azure Express Route:
The latest version of PowerShell, version 5.1 was released for WS2012R2, WS2012, W8.1, W2008R2, W7 SP1 on 1/19/2017. The WMF 5.1 version of PowerShell is already running in WS2016 and W10 machines.
Install and Configure
WS2016 and W10: