System Center 2012 Configuration Manager R2– Virtual Hard Disk feature

Virtual Hard Disks. It’s a rather odd inclusion in the pantheon of updates that come in System Center 2012 Configuration Manager R2, but curiously, it fits well and opens up a door for creating bespoke VHD’s built directly from custom task sequence. These VHD’s can then be moved by whatever means to a Hyper-V host for usage in a Virtual Machine, or provisioned to VMM directly using the ConfigMgr Consoles upload to VMM function. Along with PowerShell support, this is a combination leading to automated-VM-build heaven!

To make all of this happen you’ll need a few things at the system you’ll be creating the VHD’s from:

  • The Hyper-V role enabled and Console installed
  • Configuration Manager 2012 R2 Console installed.
  • Virtual Machine Manager Console installed (Optional) if you want to upload to VMM
  • A Configuration Manager 2012 R2 Site server
  • Operating System Image Package already setup in ConfigMgr and available on a Distribution Point
  • Lots of fast disk space where the action is kicked off, and where the resulting VHD will be stored  – With the Windows 8 install.wim I ended up with a 3.2GB stand alone bootable media ISO file and a resulting 9GB VHD file

When using this feature there’s a few things to note:

  • There’s a new log in the Adminconsole\AdminUILog folder called DeployToVHD which reports the progress of VHD creation
  • The currently logged in users AppData\Local\Temp folder is used to temporarily store the ISO, and the resulting VHD from the build until it is ready to be moved to its final destination

Stripping down what happens, it basically goes like this:

  • A custom task sequence is created by a ConfigMgr Administrator that’s specifically used for Virtual Hard Disks, which has been configured with an Operating System Image and Boot Image. The task sequence is entirely customisable
  • The ConfigMgr Administrator kicks off VHD creation using PowerShell or the ConfigMgr Console
  • Stand-alone bootable media is generated (as an ISO file) from the Task Sequences referenced content
  • A new VHD is created
  • A new VM is created and given 2GB of memory
  • The VHD and the ISO are attached to the new VM
  • The VM is switched on and boots off the ISO
  • The Operating System installs and the VM shuts down
  • ConfigMgr moves the VHD to it’s final destination
  • ConfigMgr deletes the VM and cleans up the temporary files and we’re done

Starting off with the assumption that you have everything to make this happen, ready, let’s create that Task Sequence specifically designed for handling Virtual Hard Disks:

Open the ConfigMgr Console, go to the Software Library, Operating System, Task Sequences and from the Ribbon select Create Task Sequence

Select Install an existing image package to a virtual hard disk option and then Select Next

image

Give the new Task Sequence a name, and specify which boot image it should use and Select Next

image

This is the Apply Windows Settings step in the Task Sequence, populate with your image package, product key and local administrator password then Select Next:

image

The OS could be joined to a domain at this point, I’ve opted for a workgroup as I’m not going to use the resulting VHD, Select Next:

image

Simply choose the built-in ConfigMgr Client Package or use your own, Select Next:

image

I’ve deployed no applications in this Task Sequence, Select Next:

image

We get the usual summary, which we can commit to by Selecting Next:

image

Finish up by Selecting Close and we’re done creating the Task Sequence that will be used during VHD creation.

image

The resulting Task Sequence looks like this:

image

We have a usable Task Sequence, note that final step, Shutdown Computer, it invokes shutdown –s –t 300 so that the VM powers off as ConfigMgr expects once the build is completed.

The next step is to give creating the VHD a go. Before we do that, note that this Task Sequence is wide open for customisation. By all means modify and treat it as a template to provision the same customised OS time and again while using Task Sequence Variables (OSDComputerName) to make each build unique. You could produce several templates to meet the requirements for both desktop and server OS’s and provision a new OS on-the-fly from the Console or via PowerShell commands with little administrative effort.

Let’s carry on and produce a new VHD from this Task Sequence.

From the Console, Software Library, expand Operating Systems, Select Virtual Hard Disks and from the Ribbon or a right-click Select Create Virtual Hard Disk:

Punch in a destination UNC where the VHD will be stored and Select Next:

Once you’re done entering a UNC Select Next:

image

When entering in your path be aware that there is no relationship between a VHD and Package or Application content, although you will end up seeing VHD’s referenced in the Console and it will have a PackageID it does not enter the content stores, it will not be placed on a Distribution Point as traditional content. Similar to how a Task Sequence is not content and yet has a PackageID.

That Task Sequence we made for creating a VHD, Select Browse and locate it, once done Select Next:

image

Since we are about to build stand alone bootable media resulting in an bootable ISO file, ConfigMgr will need to source the content referenced in the Task Sequence. As long as you have your content on the DP it should be as simple as highlighting it and selecting Add, once done Select Next:

image

At this point you can enter Task Sequence variables, and in the shot below I’ve specified OSDComputerName to brand the OS with a machine name. Do the same or leave empty, then Select Next:

image

Summarisation, read, Select Next or go back and correct any mistakes:

image

Now the real activity begins. In the shot below it shows the creation of the stand alone bootable media in ISO form:

image

The new log called DeployToVHD gives us the command being used to generate the stand alone bootable media ISO which is done using CreateMedia.exe, and in the shot above and below we see it is parked, waiting for the executable to return back from its task. This step needs to produce a large ISO containing all the Task Sequence’s referenced content, and depending on your setup, it can take a long time and thrash the disk:

image

While all this is happening you can peek and see the ISO being generated, check out your logged on users AppData\Local\Temp folder and look for another folder prefixed with _TSMDEDIA. This is the bootable stand-alone media files being generated in readiness for packing down into an ISO:

image

Once the ISO has been built, we see further activity in the log and Wizard around creating the VHD file, creating a new VM, configuring the VM with 2GB of memory and attaching both the bootable ISO and the VHD to the new VM. The VM is then started, at which point ConfigMgr goes dormant and waits for the VM to execute the final step in the task sequence, Shutdown Computer, as its trigger to proceed.

image

There doesn’t seem to be any way to change the VM’s initial settings, such as how many CPU’s or how much Memory is going to be allocated, what type of disk is to be used. The VM is discarded once the VHD has been built so you can configure this in a new VM that the VHD is attached too, but this memory constraint should be noted for those exotic builds demanding more memory.

We can see using Hyper-V’s Console Connection tool that the VM is happily building Windows 8.

image

Once the VM is built, and stops, the process of removing it from the Hyper-V host and moving the VHD off to its final destination begins

The Wizard then let’s us know it all went well. I found that even if there was Task Sequence failure, and if I stopped the VM, the process would continue rather than failing, so be mindful of the Task Sequences build status. Select Close.

image

Finally the temporary files are cleared up and the VHD becomes available in the ConfigMgr Console. Note its PackageID and the path to the source:

image

It’s all over now, but if we look in the DeployToVhd log again, the lead up to the VHD being moved to its final destination is shown:

image

The VHD is now ready to be shipped off to a Hyper-V server, or uploaded to VMM using the ConfigMgr Console.

There is automation beyond the upload to VMM, we also get a set of new PowerShell commands for VHD’s which can be invoked:

  • Get-CMVhd
  • New-CMVhd
  • Remove-CMVhd
  • Set-CMVhd

Using New-CMVhd we can automate the generation of a VHD which can then be used to provision a new VM. Very nice.

If you run the ConfigMgr Console as an Administrator and then Connect via Windows PowerShell like so:

image

Then type in the following, while changing the settings to appropriate values for your environment:

New-CMVhd -Name PSTestVHD -Path \\cm12r2\pkgsource\Vhd\PSTestVHD.VHD -TaskSequencePackageId S0100031 -Distri
butionPointServerName cm12r2.cmlab.com

You’ll end up with a VHD.

So to summarise, from a Hyper-V server with the ConfigMgr and Hyper-V consoles installed we are able to throw together a bunch of VHD’s built from custom Task Sequences, which can then be either manually moved to a Hyper-V server and attached to a new VM, or uploaded to Virtual Machine Manager so that the disk can be used to build a new VM. That’s some slickness right there. I’m really liking this feature!

There’s more, you can also schedule Patches to be injected into the VHD. So let’s cover that a bit.

We can inject CBS based (OS) patches using the same feature we’d use to patch Operating System Images (WIM files), Scheduled Updates. The steps are like-for-like except IMAGEX mounts the VHD instead of a WIM file. As with patching of a WIM the VHD will be backed up.

Let’s do that just to see what happens when patching a VHD:

From the ConfigMgr Console go find your VHD and from the Ribbon select Schedule Updates.

It detects OS and Architecture from the VHD and provides a list of patches that are applicable, I’ve selected just one to get through the guide but obviously you’d select all the necessary patches and Select Next:

image

We can schedule this to occur at another point in time, handy for carry out this disk IO intensive task while the Site server is idle, but I’ve opted to run as soon as possible so choose the same. Also un-tick Continue on error, best to not have any half-baked patch install in the VHD, then finally Select Next

image

Note that I’ve left the Update distribution points with the image option on, no content will go on the Distribution Points so it is a redundant property, Select Next:

image

Summarisation, Select Next:

image

We’re done!

Go take a look at the Offline Service Manager manager log file on the Site server, you’ll see it is handling the update of this VHD, it may take a moment to get under way, but when it does the VHD is copied locally to the Site server, it is then patched, the original at the destination is renamed to become the backup and the new patched VHD is copied back to the destination.

As I said above these are CBS based OS patches so you won’t find Office or Application patches in the list, these will need to go on via ConfigMgr or another route after the VHD is put to use.

Other than being aware of large files possibly going over the network, and doubling up of content at the destination due to the backup file, creating VHD’s is a pretty straightforward process.

Overall I like this feature, it’s quite a cleverly written one, leveraging existing components such as Hyper-V, ADK and VMM, and the Scheduled Updates feature. And, with the option to mingle with the System Center product family via Virtual Machine Manager, and quite possibly due to the PowerShell, via Orchestrator too, we get some serious reach for managing VHD generation. Nice.

email

Written by , Posted .