Guest OS Profiles in System Center 2012 SP1 VMM: Build Your Private Cloud (Series)

http://mschnlnine.vo.llnwd.net/d1/inetpub/kevinremde/KROmniture.htmToday’s installment of our “Build Your Private Cloud in a Month” series is the second of a 5-part mini-series we’re calling “Deploying Private Cloud Workloads”.  This week we (Tommy Patterson, Blain Barton and I) are going to detail and demonstrate some of the key areas in System Center 2012 SP1 Virtual Machine Manager that support the foundational concepts and objects in your Private Cloud arsenal:

1. Hardware Profiles (Monday)
2. Guest OS Profiles (Tuesday) <—Today!
3. Application Profiles (Wednesday)
4. VM Templates (Thursday)
5. Service Templates (Friday)

To follow along, make sure you have installed a test lab with Windows Server 2012 and the Virtual Machine Manager component of System Center 2012 SP1.  (Click the links and download the evaluations, please.)

—

Today’s topic is Guest OS Profiles in System Center 2012 SP1 Virtual Machine Manager.

What is a Guest Operating System Profile?

Similarly to we discussed yesterday when I told you about Hardware Profiles, a Guest Operating System Profile “specifies the operating system settings that you want the virtual machine to use when a virtual machine is created and deployed.”  It’s a named definition that represents some desired configuration that can be applied to new virtual machine templates.

Notice that I didn’t say “you can apply a Guest Operating System Profile directly to a new virtual machine”.  These profiles are first associated with Virtual Machine Templates, from which virtual machines can then be created.  You won’t have an option to add a Guest OS Profile to a machine that you’re creating from scratch (unlike you could with the Hardware Profiles we talked about yesterday).

Why are Guest Operating System Profiles Useful?

Think of a scenario where you need to create many (several, dozens, hundreds, thousands) of virtual machines that all are pretty much going to be doing the same thing.  They all have the same OS, have similar names, administrator passwords, product keys.  They are all web servers which require various features of IIS to be installed.  They all join the same domain.  These items “in common” relating to the configuration of the virtual machine’s operating system are perfect reasons to use Guest OS Profiles.

IMPORTANT: Let’s consider what this implies.  Unlike other virtualization solutions that would require me to pre-build and install separate disk images containing various optional operating system configurations, each with roles and features installed differently, I now have the ability to use just one disk image, or one generic OS installation, and then apply different configuration choices dynamically, and at the time of VM creation and deployment.  We can define these differences in the Guest OS Profile section of the virtual machine’s properties as we’re creating them, and we can pre-build these Guest OS Profiles to represent those different machine options.  That’s huge.

How do I create a Guest Operating System Profile?

Guest Operating System Profiles are created in the Profiles area of the Library section in Virtual Machine Manager.

Right-Click on Guest OS Profiles to launch the creation of your new Guest OS Profile.

 

As you can see from the name and description, I’m creating a common Guest OS profile for Contoso’s web servers.

After you’ve given your profile a name, click on Guest OS Profile, and you can see all the areas we are going to potentially configure.  (I’ve collapsed all but the first area to make it easier to see what we’re talking about.)

The General Settings area allows you to configure the items you see here.  For example, the Guest Operating System selection you make here will shape how the rest of this configuration works for you.  For example, if I select Windows XP, I’m not going to be able to add Roles or Features.  It doesn’t make sense.

Expand the list to see the many choices that you have.  I’m going to leave “64-bit edition of Windows Server 2012 Standard” selected.

Under Identity Information…

…we can specify the name we want to give our computer.  This name is the actual machine name (and just not the VM name used in Hyper-V Manager or Virtual Machine Manager); which means it should probably be unique.  And which is why you have a wildcard ‘*’ option for allowing VMM to generate a new unique name with each new machine based on this Guest OS Profile. 

But that’s not the only option.   You can also use ### characters to set up a portion of a recognizable name to have a numeric incrementing value to make them unique.  In my case, I’m going to use Contoso-WEB-## to generate computers named Contoso-WEB-01, Contoso-WEB-02, and so on.

Under Admin Password…

…I’m going to use my pre-defined Run As account “Admin” to be configured and used as the administrator account on these new machines.  Notice that you also have the option of not specifying an account, or defining one for the local Administrator specifically here.

(For more information about Run As accounts in VMM, CHECK OUT THIS ARTICLE – Configuring Run As Accounts in VMM)

Click on Product Key…

…which is (you guessed it) where we can add a product key for this operating system.  This is optional.  And no.. I’m not going to show you my product key.  Sorry.

That “Product key provided by answer file.” option is greyed-out because I haven’t added an answer file under the Scripts section.  If I had done that, we could then check the box to grab the product key from that answer file.

Time Zone…

…is of course where we can set the time zone for this machine.  Personally, I’m partial to the BEST place to live: The GMT -6:00 Central Time Zone (US and Canada). 

Okay.. now let’s click on and expand Roles and Features.

This is where, in my opinion, things get really interesting.  We can actually pre-determine which roles and features are to be added to a machine.  If machines based on this Guest OS Profile are going to need certain .NET framework versions installed, or have IIS installed, I can define that here.  The image or installation that I base the deployment of these machines on doesn’t have to have these pre-loaded.

NOTE: the configuration of roles and features here is only used if this Guest OS Profile is used in a VM Template, which is in turn used in a Service Template.  You will get a warning reminding you of this if you configure these here, and then try to create a VM directly off of the VM Template.  The proper way to get this to work is to create a Service Template.  Even if you only have a one-machine Service Template, the deployment of the service will configure the roles and features you’ve specified (along with adding applications and SQL Server configurations, which we’ll talk about tomorrow); whether coming from the Guest OS Profile, or directly in the VM Template.

Click on and expand Networking.

This is where, if I choose, I can pre-define the domain membership that machines using this Guest OS Profile should have.  In my example I am again using my pre-configured Run As account “Admin” to join these machines to my Remde.home domain.

(For more information about Run As accounts in VMM, CHECK OUT THIS ARTICLE – Configuring Run As Accounts in VMM)

Finally, click on and expand Scripts.

Here is where I can point to an answer file that might have been built manually, or by using the Windows System Image Manager tool (a part of the Windows Assessment and Deployment Toolkit (ADK)).

The [GUIRunOnce] Commands…

 

…give you the powerful opportunity to add a command or script to be launched the first time a user logs on to machines based on this profile.  So, if there is further customization or other scripted installations that need to take place once the machine is first used, you can have that launched automatically by configuring it here.

When I finally click OK, I now have my new Guest OS Profile. 

Right-Click the new profile and select Properties to make changes or view other information about the profile.  For example, you have a Dependencies area…

…which shows you if there are any items that this profile is dependent upon.  (Hence the name.)  In my example I used the Admin RunAs account two times in the profile, so this is reminding me that that definition needs to remain in place for this Guest OS Profile to function properly.

The other new area is Access…

…which, like it did in Hardware Profiles, allows us to add self-service users or roles here to grant use-rights for this profile.

(For more information about Self-Service Users and Roles, CHECK OUT THIS ARTICLE on Configuring Self-Service in VMM

Creating a Virtual Machine Template

To use my new profile, I’ve created a new virtual machine template called Contoso-WEB-Server Template, which uses a modified version of the Hardware Profile we created yesterday, and the Guest OS Profile that I created just now.  In the creation of the VM, I also pointed to the Windows Server 2012 evaluation .VHD as the base image for this machine.  (You can start playing with this evaluation .VHD by choosing the “Download the Evaluation VHD” option on my Server 2012 evaluation download page.)

In the interest of keeping this blog post short (?!), I’m going to leave the details of working with VM Templates to my friend Tommy Patterson’s post this coming Thursday.

Creating a Virtual Machine

If you’re looking at the Templates area under Library, you can now create a new virtual machine by right-clicking on the template…

…and selecting Create Virtual Machine.

For the Virtual Machine’s Identity…

…I can leave it blank.  If you do that, it will create the name from what you’ve specified in the “Configure Operating System” area of the wizard (which, as you’ll see, we’re going to get from our newly created Guest OS Profile).

Click Next. 

For the Hardware Profile, I’ll select one that I recently created (based on the one we built yesterday). 

Click Next. 

For the Guest OS Profile, I’ll select our new Contoso Web Server Profile.

Click Next.

For the Destination, I’m going to put my new machine on a host.  Notice that I could also choose to deploy to a supporting Cloud, or to the library as a stored machine.

Click Next.

The Intelligent Placement algorithm kicks in and, for my machine, determines that there are only two of my three servers that are viable candidates to host my machine.  I’ll choose the first option.

Click Next.

Reviewing the settings let’s me see what the defaults were that are about to be assigned, and gives me an opportunity to change them.

For example, I had tested this deployment before, so the computer name ## was incremented higher than I wanted.  Otherwise things look good.

Click Next.  I’m going to leave the Add Properties alone.  I’m fine with those defaults.  Click Next again…

… and then click Create.

Several minutes later, you should have a new virtual machine!  Notice that it completed with warnings – mainly reminding me that because I used a VM Template (and not a Service Template) to directly create the virtual machine, it wasn’t able to modify the roles or features as I had specified in my Guest OS Profile.

When start up, connect to my machine, and log-on, I can see that it has joined the domain as I had configured in our Guest OS Profile…

…and all is as I expected!

For More Information

For more details, I recommend the following articles and locations for expanding your knowledge of System Center 2012 SP1, Virtual Machine Manager, and VMM Guest OS Profiles:

• System Center 2012 SP1 Infrastructure Management
• Virtual Machine Manager
• Virtual Machine Manager Datasheet (PDF download)
• “How to Create a Guest Operating System Profile”
• System Center 2012 SP1 Evaluation

—

Was this useful?  I hope so!  Let me know in the comments if you have any questions, concerns, clarifications, or cheap shots at me or Microsoft.  (Hit me with your best shot!  I can take it! )