Deploying Native Boot VHDs [5]

The steps for deploying a native VHD boot are the same as if you are using a third party imaging solution, such as Ghost. Effectively, copying a VHD is a kind of third party imaging solution, in that it is not a directly supported deployment scenario for the Microsoft Deployment Toolkit, its predecessor Business Desktop Deployment, Windows Deployment Services, or System Center Config Manager. Ideally at least MDT would have task sequences added to automate the required steps, namely Sysprep and DISM.

Hence having used a third party imaging  scheme before, it took me little effort to get going with Native VHD deployment as we originally developed a Vista image using Ghost along with WSIM and Sysprep. The stage I didn’t get around to at that time was DISM, or possibly it was different under Vista. This time I have to use it because the network card driver for our particular target platform is one of those which is not included with Windows 7, and thus, out of the box, Windows 7 will not be able to search for drivers for the other hardware.

When we developed our first Vista image I had a buck both ways and also ImageX’d the PC so that I had this image available in case Ghost didn’t work out. As it happens, Native VHD deployment is like ImageX except that the stage of physically imaging the hard disk and reloading that image to target PCs is replaced by copying the VHD file to target PCs. ImageX has the advantage over Ghost of being file-based rather than disk-based, and various other things it can do like having multiple images stored efficiently in one WIM file due to single instanced storage. Native VHD on the other hand is like a partition, due to the fact that a VHD file is a virtual hard disk. When you deploy it, multiple VHDs can represent multiple partitions on the target system. Its strength lies in the fact that you don’t have to physically define and maintain partitions on the target computer’s hard disk, especially if you have more than one. Re imaging the target is as easy as booting up to a Windows PE command prompt and copying the new VHD file over the old.

Once you have sysprepped your VM with your deployment VHD attached to it (as this is an online step), the final step before deployment to target platforms is to perform offline servicing. This is what DISM does. Its name stands for Deployment Image Servicing and Management, and like other tools that you use in a Windows PE command prompt, such as Diskpart, it has been extended for Windows 7 to work with native boot VHD files as well as WIMs. Supposedly you can pass Dism an unattend.xml file that you set up with WSIM that has a driver path specified in the [2 offlineServicing] section. I wasn’t able to make this work, so I just copied the drivers to the local HDD and used the Add-Driver option instead. The use of DISM is pretty straightforward, although since it cannot work over network paths, you may need to copy your image file somewhere locally first (I recommend you also copy your unattend.xml file to the same directory):

  • Start the Deployment Tools Command Prompt by right clicking it and choosing “Run as administrator”.
  • Browse to the directory which contains the image you are performing offline servicing on.
  • You will need to use Diskpart first in order to map the  VHD to a drive letter.
    • Start Diskpart
    • At the Diskpart prompt, enter select vdisk file=<path_to_vhd>
    • Enter attach vdisk
    • Enter list vol to see if diskpart has assigned a drive letter to the file. If not, use the assign command to assign a drive letter. In this case drive letter F has been assigned. Typically you will find two extra drive letters automatically assigned: one for the boot drive partition, and one for the system partition.
    • Enter exit to quit Diskpart
  • Type in a command which starts with dism /image:<drive_path> followed by a servicing command.
    • For example: dism /image:F: /get-drivers will list the drivers already present.
    • To add drivers off a local path such as C:dism, enter a command like dism /image:F: /Add-Driver /Driver:C:dismIntel /recurse (Intel is where I have copied the driver files to).
    • After doing this you can use something like dism /image:F: /get-drivers to see what was installed.
    • The first time I tried this 198 driver packages were added to the image. SmileYMMV – You may wish to trim down your driver folders (These were only four devices in total). This number of drivers added 1.2 gigabytes (!) to the image size.
  • After using DISM, detach your VHD using more Diskpart commands before you copy it to the target platform.
    • Start Diskpart
    • Enter select vdisk file=<path_to_vhd> (or press the up and down arrows to recall the command that you entered when you used Diskpart earlier in the session)
    • Enter detach vdisk
    • Enter exit to quit Diskpart
  • Deploy and test. (I copied the VHD straight over the network from C:Dism on my MDT VM)

Eventually AIK is going to get installed on my tech server VM where all the setup files are local so that I don’t have to copy the files around each time I’m using DISM.

We have more or less finalised the process of imaging for our computers now. There is just a bit more tweaking and customising the image to get it all working properly before we deploy soon.