If you would like to read the other parts in this article series please go to:
In the previous article in this series, we finally finished creating a private cloud. Of course our private cloud doesn’t really do anything at this point. It is really nothing more than a collection of resources. Our goal now becomes making the private cloud useful.
As you may recall, our ultimate goal behind creating a private cloud is to enable self service provisioning of virtual machines. If an authorized user needs to create ten new virtual machines then you as the administrator should not have to manually create those ten virtual machines. Instead, you should be able to allocate a block of resources to the user and then give the user access to a collection of pre-built templates that the user can use to create the necessary virtual machine through a self-service interface. The whole process will be automated. Neither you nor the end user will have to manually configure the individual virtual machines. The virtual machines are generated from templates. The use of templates ensures that new virtual machines are always created in accordance with your corporate policies.
As you can see, templates are critical to the success of automated virtual machine deployments. Because templates (or service templates as they are referred to in Microsoft speak) play such an important role, I want to spend some time talking about them before we begin the template creation process.
It is easy to think of a service template as a mechanism for generating new virtual machines. In reality however, there doesn’t have to be a one to one relationship between service templates and virtual machines. Service templates can actually be used to create collections of virtual machines.
If you stop and think about it, it is becoming increasingly common for applications to be deployed in a distributed manner. Think of Exchange Server for instance. A single Exchange Server deployment might consist of a client access server, a mailbox server, and an edge transport server. If you were to create this type of Exchange Server deployment manually, it would take a considerable amount of time to work through the full configuration process. However, the entire process can be automated through service templates.
It is worth noting that service templates are not new to System Center 2012. They existed in previous versions as well. However, Microsoft has made two very important changes to service templates in System Center 2012.
First, when a virtual machine is generated from a service template, System Center maintains a relationship between the virtual machine and the service template. This makes it possible to go back and audit the VM at a later time to make sure that its configuration still matches the service template.
The other big change that Microsoft has made is that it is now possible to use a service template to perform configurations within a virtual machine. For example, a service template might instruct a virtual machine to install various roles and features.
Before we begin creating virtual machine templates, there are a number of concepts that you need to be familiar with. The first such concept is that of a hardware profile. A hardware profile is a special kind of library resource that contains the hardware specifications that will be used by a virtual machine (or in our case, a virtual machine template). For example, a hardware profile might specify the amount of memory and the CPU configuration for a virtual machine.
So why am I mentioning this right now? Well, as you will recall, our goal is to automate the virtual machine creation process. Not only do we want to automate the creation of virtual machines, but we want those virtual machines to be created in a consistent manner. The easiest way to ensure consistency is to build a collection of reusable parts that can aid in the virtual machine creation process. It is this reuse of parts that ensures consistency. As you have probably already guessed, one of the reusable parts that is used in the process is the hardware profile.
Another reusable part that you will need to be familiar with is the Guest OS Profile. The guest OS profile’s job is to specify operating system settings for a virtual machine. These configurations are applied to the virtual machine profile at the time that the virtual machine is created.
The concept of a guest OS profile probably sounds pretty simple (and it is). Because the concept is so simple however, it is easy to overlook the profound impact that guest OS profiles have on the virtual machine deployment process.
In the not too distant past, virtual machines were typically deployed from images. Although image based deployments worked, they created a considerable amount of administrative burden. For one thing, an administrator typically ended up having to keep track of a fairly large collection of images. More importantly however, images require constant maintenance and often have to be regenerated as a result of making changes to the image.
Guest OS profiles eliminate the tedious image management process. Rather than maintaining an entire library of custom deployment images, you can retain a generic image of the Windows Server installation media and then use the Guest OS Profile and the virtual machine template to configure the virtual machine at the time of deployment.
Other concepts that you will need to be familiar with include application profiles and service templates. I’m not going to spend a lot of time talking about application profiles and service templates right now because it will be a while before we need to use them . Even so, I wanted to at least mention them. As you have probably guessed, an application profile deals with an application’s configuration.
Service templates need a bit more explaining. As the name implies, a service template defines the configuration of a service. When it comes to System Center 2012 and a private cloud environment, a service can best be thought of as a function, or even as a distributed application.
Let me give you a more concrete example. Suppose that you were operating a multi-tenant private cloud and one of your tenants asked for messaging capabilities. Those messaging capabilities could be thought of as a service. In that particular case, the service is based on an application – Exchange Server.
So if services are related to applications, what makes service templates different from application profiles? Well, application profiles control an application’s configuration. Often times however, enterprise class applications such as Exchange Server make use of multiple servers and multiple application roles. Each application role would require a unique configuration.
In the case of Exchange Server, you might have an application profile for the mailbox server role and another application profile for the client access server role. The service template is what brings all of that together. Rather than having to deploy each required Exchange server individually, a service profile can be created that facilitates the creation of a series of Exchange Servers. In essence, a service profile allows a distributed application to be deployed in a single step rather than each application server having to be set up individually.
Now that I have talked about the roles that the various profiles and templates play, it’s time to get back to the configuration process. I will walk you through the process of creating a hardware profile in Part 7.
If you would like to read the other parts in this article series please go to:
Microsoft 365 is loaded with configurations, policies, and settings—some obvious, some buried. This Microsoft 365…
Setting PowerShell execution policies at the Group Policy level can greatly enhance your organization’s security.…
Ah, the good old days — when Exchange 2010 was king. But with each new…
The GDPR and the CCPA are both aimed at protecting privacy. Although many similarities exist…
Azure DevOps is fast becoming the next big thing. This Azure DevOps Quick Tip shows…