Copy / clone a Virtual Machine in Microsoft Azure

Being able to copy or clone a virtual machine is a useful feature in many scenarios, e.g. create a customized base template, for test environments, and so forth.

I walked through two options:

These two options do not lead to the same result. Depending on what the use case it, the right one should be chosen.

At least there is one other option: Create a snapshot. But I haven’t tried that one.

Note: This post is part of a series of postings describing several aspects I found noticeable or good to know when I recently created a virtual machine in Microsoft Azure. “Notes and Observations when setting up a Virtual Machine in Microsoft Azure” gives an overview of all parts of the series.

Create (capture) a Virtual Machine Image

Capturing a virtual machine should be used for generalized VMs. It will create an image file which can be used to create new virtual machines based on it. The docs say that once the source VM is generalized, it cannot be restarted. This is only partially true, see below.

A precondition to capture a (Windows) VM is to run sysprep on the source VM. Beside other things, I noticed that some user-specific settings will be removed, like the taskbar settings (at least for local users). And in case the admin user of a new VM, based on the captured image, was named like the one of the source, all settings of this user were overridden.

Depending on the time it took to setup the source VM I think it is a good idea to create a backup before generalizing it. As sysprep is changing a few things, the result might not be what was expected. Having a backup (or snapshot) in place makes it easy to return to the non-generalized status (create a new VM) and will save time.

Struggle with Microsoft Store Apps

According to the docs, “Installing new Microsoft Store apps or updating your existing Microsoft Store apps before generalizing a Windows image will cause Sysprep to fail. “.

Microsoft suggests “… you should sideload updates to your line-of-business apps, provision offline-licensed Microsoft Store for Business apps for all users, or have end-users update their apps by using the Microsoft Store on their destination PCs ” instead of using the Microsoft Store to update your apps. Well …

Restart a generalized VM

The portal says that capturing will make the VM unusable and this cannot be undone. I have tested it, and it is true. You can’t even restore the VM by replacing the disks.

BUT: To be honest, it is not completely true.

As said above, one option I see is to restore the VM to a new virtual machine, in case a backup was created before executing sysprep (I recommend to do so!).

Having disaster recovery / replication enabled before generalizing, I was able to initiate a failover after generalizing the VM, deleted the source VM once the failover has completed, enabled replication of the target VM (the one that was created on the failover location), and did a failback once replication from the failover location to the source location completed. Well, this is probably an option, but maybe it’s easier to either create a new VM from a backup, or generalize a VM and create a new one from that image.

Cleanup of Source VM Resources

When creating an image of a VM (or capture it) via the portal, it is possible to let Azure delete the VM once the image is taken.

Delete VM when creating an Image

Unfortunately, this will delete the VM resource only. All related resources, like disks, public IP address, network, Recovery Services vault, …, will not be deleted (see my post “Resources found after Creation of a Virtual Machine in Microsoft Azure” to get an idea what else can be found). This needs to be done by yourself.

Restore to new Virtual Machine

Creating a copy of a VM by restoring it from a backup really creates a copy. That means, all settings, files, applications, … remain unchanged. For backup / restore I think it is worth to have a look at Microsoft’s Backup Best Practices.

What I did not checked is if recovering from a backup to a new virtual machine will also set a new SID.

Backup or Capture?

Creating a new VM from a backup instead from a captured VM to me has the main difference that users and user settings remain the same on the newly created VM. This might be an advantage or a disadvantage, depending on the use case.

I know that this view is incomplete, as sysprep is the only way officially supported by Microsoft to clone images, among others due to SID uniqueness (see this discussion and Mark Russinovich’s input on SID). But my intention was to become familiar with virtual machines in Microsoft Azure, not to become a sysprep expert 😉

Azure Resource Manager Templates

In case you want to automate deployments (of not just virtual machines) and use the practice of infrastructure as code, have a look at Azure Resource Manager templates. I have not tried that yet, but from reading the docs it looks promising. Lots of templates can be found at the Quickstart Template Gallery.

Links

Create a managed Image of a generalized VM
Backup Best Practices
Restore a Virtual Machine
Create a Snapshot of a Virtual Machine
Notes and Observations when setting up a Virtual Machine in Microsoft Azure
Azure Site Recovery
Resources found after Creation of a Virtual Machine in Microsoft Azure
sysprep documentation
The Machine SID Duplication Myth (and Why Sysprep Matters)
Changing SID on ReDeployed image – A new take on an old question
Azure Resource Mananger Quickstart Template Gallery
Azure Resource Manager templates