In the introduction to this series, I introduced you to my not-so-fictitious Client, which was using different toolsets for image creation and replication.
The question we are trying to answer (or at least provide clarity on), is: Should we create a custom image, or use the Azure Marketplace image?
Let’s dive into considering the Custom Image now.
Before we go into the steps that are involved with using Custom Images in Azure, let’s first level-set on the value.
When you create a custom image, you have complete and ultimate control over everything. Only want Security and Critical patches in your image? No problem. Want to pre-install all of your corporate security/monitoring/management agents? Check. Need to certify the image passes all of your security hardening measures? Go right ahead.
While there are of course opposite arguments to these points (which we will cover in the Marketplace Images section), the point is, if there is a business (or human) need to have this “full” control at this level, it’s available.
So, let’s say we’ve decided/determined that we want to use a Custom Image for all of our Azure Virtual Machine deployments. Now what?
Well, I’m not going to write out a literal step-by-step, but we’ll cover the general steps in a summarized way.
First, you will need to create this custom image, presumably in your datacenter on-premises. Maybe you’re using tools such as the Microsoft Deployment Toolkit (MDT), System Center Configuration Manager (SCCM), Packer, or some other tool. It doesn’t really matter which tool you choose. You start with the ISO, install it to a VM, install any tools, applications, agents, etc. that you may require as part of the base image. However, keep in mind that this makes the footprint of the image a lot heavier.
When creating an image, we, of course, have to sysprep and generalize the system. But, because we’re uploading this image for use in Azure, there are a bunch of additional steps we need to do, including setting the Windows configurations specific for Azure, resetting specific Windows Services to defaults, updating the Remote Desktop registry settings, configure the Windows Firewall rules, verify the VM is healthy, secure, and accessible with RDP, and finally, complete the recommended configurations.
So, it’s not just a simple laydown of the ISO, patch, install stuff, and then sysprep. There’s more to think about.
Next (after the standard sysprep/generalization step), depending on the type of environment you are building the image in (for example VMware), you will have to convert it into a VHD file format. The same thing can be said of a Hyper-V environment, even though the VHD format is native to Hyper-V. Why? Because most Hyper-V environment will be using the second generation (Gen2) VMs in Hyper-V, which utilize the new VHDX format. So either way, you will have to convert your image into the currently supported format in Azure, namely VHD.
Now with our image in VHD format, we need to upload it into Azure. This requires several steps and components as well. First, you will need an Azure Storage account to contain the VHD file. But, I want to use Managed Disk, you might say. Yes, but this is part of the process (we’ll get there). With your Azure Storage account in place, you then have to upload the VHD into the account. Once the VHD is present in the Storage account, we can now create a managed image from the uploaded VHD. With our Managed Image created, we can now, finally, create a VM from our managed image.
It’s just that “simple”.
To Be Aware
So, even though those are a lot of inter-connected steps and process, it’s not too bad. But, there are still a few things you should be aware of when using this method.
For example, you need to rinse and repeat all of these steps everytime, whenever there are updates/changes required to your base image. Depending on the number of OSes you have images for, this could create a lot of substantial work.
Another thing to be aware of, in comparison to options available in the Azure Marketplace (which will be covered next), is that your image size (i.e. the size of the OS disk) is set in stone. So in comparison to the Azure Marketplace images (which has a ‘small disk’ option), if you want to provide different OS disk sizing options, that means you’ll have to create yet another image (and repeat all the steps again).
I am also told (though I could not find any definitive documentation), that you are limited in using your Managed Image within not only the Azure subscription it is created in, but also within the Region it is stored in. If this is true, that means, for every Azure region that you want to deploy to using this custom image, you will need to copy, and maintain, the Managed Image; which means more operational overhead. Note: This limitation is removed if you are using the new Shared Image Gallery service.
Wow! So, that was a lot to consider. In the next part of this series, we will cover the Marketplace Image perspective.