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.
This is the Export step in the process of generating and uploading self-signed Root and client certificates to Azure for authentication for a Point-to-Site VPN Gateway. The PowerShell to create the root and client certificates is found here.
After creating the self-signed root certificate, it must be exported so it can be uploaded to Azure for the P2S configuration. It is only necessary to export the generated client certificate if it is to be installed on another client/computer. It is automatically installed on the client/computer it was generated from. Instructions are given here for exporting both the .cer file and the client certificate.
Export .cer file from Root Certificate
Export Client Certificate
One way to move an on-premises Hyper-V Windows virtual machine (VM) with all its user accounts, policies and applications fully intact up to Azure, is to create a specialized disk of the VM’s operating system virtual hard disk (VHD). This specialized VHD is then uploaded to Azure, after being properly prepped to work in the Azure environment and attached to a new VM.
- Only Generation 1 Hyper-V VMs are supported on Azure. Keep this in mind when creating or are considering moving Hyper-V machines to Azure. A Generation 2 Hyper-V VM cannot be converted to a Generation 1 Hyper-V VM.
- The Hyper-V vhdx disk format must be converted to vhd, and the dynamically expanding property of the Hyper-V vhd changed to fixed-sized. This is done easily in PowerShell
- In Azure, the size of a managed or unmanaged VHD can be increased, but not decreased, so to speed the uploading time of the prepared VHD to Azure, make sure the Hyper-V VMs OS disk is as small as possible when the Hyper-VM is first created.
In the 2 sets of .vhdx drives converted to .vhd drives shown below:
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: