The Building Blocks of Service Templates within Virtual Machine Manager by David Stoker

The Building Blocks of Service Templates within Virtual Machine Manager by David Stoker

  • Comments 2
  • Likes

The Building Blocks of Service Templates within Virtual Machine Manager
by David Stoker

imageHaving worked with customers early in the System Center 2012 Virtual Machine Manager Technology Adoption Program (TAP), I’ve been asked several times how does one effectively build Service Templates? The goal is to first create standardized “buildingimage blocks” which can then be used to quickly build Service Templates by selecting the various components from an existing menu. Think of it as ordering from a restaurant menu:

“I’ll take the medium hardware profile, Windows Server 2008 R2 Enterprise, the Contoso.com domain, the Web Server role and the Stock Trader Shopping Cart Web Deploy application package…and I’ll take four of these please…”

The First Building Block – Base OS Image

In the past, the basic OS Image wasn’t so basic. Just about every application and OS setting desired had to be included in the OS Image. With System Center 2012, this all changes…

First, you start with as basic an OS Image as possible. Only include core OS settings and security patches. I’d only recommend deploying a third-party application within the OS Image if it is common to every VM AND it requires very infrequent updates. For environments standardized on Windows Server 2008 R2, we typically start with two fully patched OS Images in the Virtual Hard Disk (VHD) format:

1) Windows Server 2008 R2 (choose your edition)

2) Windows Server 2008 R2 with SQL Server 2008 R2 sysprepped following this guide (http://technet.microsoft.com/en-us/library/ee210664.aspx).

Once built, simply upload the VHD files to the VMM Library. For VMware environments, import the vCenter VM Template into VMM.

The Second Building Block – Hardware Profiles

Next, we want to create a set of reusable Hardware Profiles. These define cloud capability settings such as Hyper-V, ESX Server or XenServer as well as hardware settings such as virtual CPU, memory, video adapter (including Microsoft’s RemoteFX 3D adapters for your VDI solution), SCSI adapters, availability, etc. Additionally, we identify how many network adapters are needed for each Hardware Profile but don’t connect the network just yet.

I usually start with 3-4 Hardware Profiles: Small, Medium, Large and SQL. Since SQL usually requires a unique memory configuration, I find a dedicated SQL Hardware Profile works well in most environments.

Note that we don’t actually attach any virtual hard disks to the Hardware Profile; that will come later.

The Third Building Block – OS Profiles

We also want to create a set of reusable OS Profiles. As with VMM 2008 R2, OS Profiles define the computer naming conventions, local admin account, product key, time zone, domain/workgroup settings, etc… New to System Center 2012 VMM, the OS Profile now includes the ability to add Roles and Features to Windows Server 2008 R2 and newer guest operating systems.

I recommend creating OS Profiles for common deployment scenarios such as File Servers, Application Servers and Web Servers. It’s usually a good idea to create a generic OS Profile to handle one-off scenarios as well.

The Fourth Building Block – Application Profiles

New to VMM, Application Profiles are designed specifically to enable the deployment of SQL Server Data-tier applications, Virtual applications and Web applications along with supporting application scripts. However, you can deploy just about any application via a generic Pre-Install script. If it can be silently installed without a reboot, I’ve found that it can usually be installed via an Application Profile.

I usually create “starter” Application profiles which deploy the Server App-V and Web Deploy clients. These allow easy updates when creating Service Templates as the prep work to deploy the Server App-V or Web Deploy package can be consistently applied to all Service Templates. I additionally recommend creating Application profiles for commonly deployed applications.

The Fifth Building Block – SQL Server Profiles

Also new to VMM, SQL Server Profiles complete the two-step SQL Server sysprep process. This includes SQL Server instance name, security settings, remote connectivity settings and service account settings just to name a few. At a minimum, I recommend creating one SQL Server Profile.

Connecting the Building Blocks with VM Templates

The OS Image, Hardware Profile and OS Profiles are combined to create VM Templates, which in turn are used to create Service Templates. You can optionally add Application Profiles and SQL Server Profiles to VM Templates. I find this valuable if I frequently create different Service Templates with a common Application Profile, but these profiles can be selected directly in the Service Template Designer as well.

The goal here is to create multiple options including hardware and core OS settings that take a basic OS Image and deploy a variety of standard VM configurations thus minimizing the OS Image creation and management process.

Time to Build the Service Template…

Now that all of the building blocks are in place, we can quickly create Service Templates. It is recommended to deploy every VM from a Service Template (even single-tier, single VM deployments) as this enables updates to the Service to take advantage of the release management capabilities built into System Center 2012.

In the Service Template Designer, you can name your Service Template, select the number of tiers and simply drag those previously created VM Templates over top of a tier as need to set the proper OS Image, Hardware Profile and OS Profile settings. You can also easily add Application Profiles and SQL Server Profiles at this time in addition to any other applications in the VMM Library. The goal here is to make the final Service Template creation process very simple by selecting various components from a list of previously created items.

Finally, remember how we never connected the virtual network adapter to a logical network in the Hardware Profile? In most Private Cloud deployments several logical networks exist, which makes it an inefficient choice to create one or more Hardware Profiles for every logical network. One of my favorite “quick” features in VMM is the Connector tool within the Service Template Designer. Simply add a Logical Network to the Service Template and use the Connector tool in the ribbon to connect these two objects. In a four-tier Service Template I recently created, this little feature took only 6 steps to connect all of the virtual network adapters (and saved me 14 repetitive steps)…

David Stoker
US Private Cloud Center of Excellence Lead
Microsoft Services |
dstoker@microsoft.com

Go Social with Private Cloud Architecture!
Private Cloud Architecture blog
Private Cloud Architecture Facebook page
Private Cloud Architecture Twitter account
Private Cloud Architecture LinkedIn Group
Private Cloud TechNet forums
TechNet Private Cloud Solution Hub
Private Cloud on the TechNet Wiki

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Excellent structured recipe for service templates.

  • Our dc naming conventions typically include a reference to the app (tenant) abbreviation and tier of service (web/app/db).  This is creating quite a bit of sprawl within the environment with respect to templates.  Is there anyway to dynamically assign this or should we go back to the drawing board?