Getting Started With Azure Pack (Part 8)

If you would like to read the other parts in this article series please go to:

In the previous article in this series, I talked a little bit about virtual machine templates and the role that they play in Azure Pack. In this article, I want to walk you through the process of creating a VM template that your users can use to deploy their own virtual machines on demand.

As I mentioned in the previous article, a VM template is really just a mechanism for creating pre-configured virtual machines. Those of you who have worked in IT for a long time know that in the past there was a lot of effort put into keeping anything potentially dangerous out of the user’s hands. As an administrator, you would probably never allow a user to do something that could cause network problems or open up security holes.

Today things are a little bit different than they once were. Administrators are totally overworked. IT is short staffed, and the users… Well, they are as demanding as ever. They want whatever it is that they want, and they want it now. If you don’t give them what they want, then they are likely to go get it from a public cloud provider (this process is known as shadow IT).

The problem with shadow IT is that it allows the user to circumvent the IT department and put corporate resources in a public space that is beyond IT’s reach. There can be some pretty dire consequences to a user taking this sort of action, but if you happen to work in a regulated industry then a user’s reliance on shadow IT can expose the organization to some heavy penalties from regulators and potentially even to litigation from customers whose information was mismanaged.

I think it’s safe to say that most old school administrators probably aren’t crazy about the idea of letting users create their own virtual machines, but know that allowing the users to do so is one way to help minimize the chances of users taking things into their own hands and uploading sensitive data to an unauthorized public cloud.

So here is the big question… Imagine that you have come to accept the idea that you are going to have to let users build their own virtual machines. Should you hand them a Windows DVD and tell them to have fun, or would you feel better giving them a pre-configured operating system image that has certain safeguards in place? Hopefully you chose the preconfigured image.

This is what VM templates are all about. As I said before, a VM template is a mechanism for building pre-configured virtual machines. These pre-configured virtual machines can be fully patched and they have typically been hardened. For instance, you might embed a setting in the virtual machine’s local security policy that requires the Windows firewall to be enabled. Furthermore, the virtual machine might have anti-malware software preloaded. The point is that it is relatively safe to allow users to deploy their own virtual machines so long as you put some controls in place to make sure that those virtual machines are deployed and configured in a secure manner. VM templates can help you to do exactly that.

It is actually really easy to build a VM template. The first step in doing so is to create a model virtual machine. Every virtual machine that is created from the template VM will be configured just like the model VM.

Now before you move forward, there is something extremely important that you need to know. If you are going to create a VM template, then you MUST build the model VM from scratch. The reason for this is that the template creation process will destroy the model VM. I have actually seen people create a template from a production VM, only to have that VM destroyed in the process. The organization that did this ended up having to restore the production VM from backup.

Right now I’m sure that you are wondering why the template creation process is so destructive. Well, think about the way that the Windows operating system works. If you were to manually install identical copies of Windows onto two different physical servers, the two deployments would not be 100% identical. Sure, the system files and the basic configurations would be the same, but there are a few things within the Windows configuration that uniquely identify the Windows deployment. I am talking about things like the computer name, the IP address, and the various security identifiers and globally unique identifiers that are used by the operating system.

If you were to simply build a model VM, clone it, and then give everybody a copy of the clone then you would run into a lot of problems because you would have multiple identical copies of Windows on the network. The network would have no way of differentiating between one copy of the operating system and another.

To avoid this problem, the template creation process randomizes the model virtual machine. That’s a fancy way of saying that Windows strips everything from the operating system that makes it uniquely identifiable on the network. What is left is a generic copy of Windows.

Of course you can’t just deploy a generic copy of Windows. Remember all of that identification data that was stripped from the operating system? Well, Windows needs that data. It can’t function without it.

Microsoft has solved this problem by using a sort of mini setup process. When you install Windows manually, the Setup process asks you a few questions along the way. These questions vary depending on the version of Windows that you are installing, but you might be asked for your company name, your product key, etc.

The mini setup process puts this and other information into the operating system that is being deployed based on the template. Of course templates can be used to roll out huge numbers of operating systems and you really don’t want anyone to have to work through a manual deployment and configuration for hundreds of virtual machines. This is where something called the Guest OS Profile comes into play.

Those of you who have worked in IT for a long time might remember SYSPREP. For the uninitiated, SYSPREP was a command line tool that could randomize Windows in the way that I just described. In fact, SYSPREP still exists as a part of Windows today.

For those of you who remember SYSPREP, you will no doubt recall that SYSPREP allowed you to use an answer file. The answer file was just a text file that contained the answers to all of the questions that Windows asks during setup. For instance, the SYSPREP answer file might contain the Windows product key.

The guest OS profile that I mentioned a moment ago is just like a SYSPREP answer file. It contains data used for configuring a virtual machine. In this case, that data is used to configure virtual machines that have been spawned from a VM template. The only real difference between a SYSPREP answer file and a guest OS profile is that the guest OS profile can be configured through a GUI and stored in the Virtual Machine Manager library.


In this article, I have explained how VM templates and guest OS profiles work. In the next article in this series, I will show you how to build a VM template and a corresponding guest OS profile.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top