Background

In order to get Native VHD Boot working from an external USB Disk, there are a few things we need to understand about device drivers and their load orders.

Setup and the PnP manager configure devices starting with the system root device, followed by the child devices of the root device, the children of those devices, and so on. To influence the driver load order outside of this sequence, we need to change the .INF files for the USB related drivers, specifying relevant values in the service-install-section, specifically the StartType and the LoadOrderGroup entries.

A PnP driver should have a start type of SERVICE_DEMAND_START (0×3), specifying that the PnP manager can load the driver whenever it finds a device that the driver services. USB drivers normally behave in this manner and have this start type.

However, if a driver is required to boot the machine (such as when, oh I don’t know, maybe attempting something like native VHD boot from an external USB drive), the drivers for the device should have a start type of SERVICE_BOOT_START (0×0).

On system boot, the operating system loader loads drivers of type SERVICE_BOOT_START before it transfers control to the kernel. These drivers are in memory when the kernel gets control. Boot-start drivers can use the .INF LoadOrderGroup entries to order their loading. You can see the List order at HKLM/SYSTEM/CurrentControlSet/Control/ServiceGroupOrder.

For Native VHD Boot from an external USB drive to work, we need to modify the behaviour of six device drivers:

• usbccgp - Microsoft USB Generic Parent Driver
• usbehci - Microsoft USB 2.0 Enhanced Host Controller Miniport Driver
• usbohci - USB Open Host Controller Miniport Driver
• usbuhci - Microsoft Universal Host Controller Miniport Driver
• usbhub - Microsoft USB Standard Hub Driver
• usbstor - USB Mass Storage Driver

The USB drivers have a LoadOrderGroup entry of Base, which is considerably down the list, and critically much later than we need to use them as a boot device. We therefore need to modify the LoadOrderGroup to something more appropriate that will be processed earlier in the boot cycle. There is some debate about the best entries to use for this purpose, and whilst it seems the below is technically most appropriate, I began this journey with all entries set to use Boot Bus Extender and have continued to use that without issue. However, you may want to try the settings below as an alternative:

• usbccgp - Boot Bus Extender
• usbehci - Boot Bus Extender
• usbohci - Boot Bus Extender
• usbuhci - Boot Bus Extender
• usbhub - System Bus Extender
• usbstor - SCSI Miniport

So, to enable Native VHD Boot from an external USB drive, we need to modify the StartType and LoadOrderGroup of each of those drivers, and critically, ensure that they don’t get reset to their defaults.

Requirements

You’ll need a computer running Windows 7 or Windows Server 2008 R2 and a suitable external USB drive to store your .VHD files and to create the necessary bootloader. You’ll also need the following tools:

• Windows Automated Installation Kit (WAIK) for Windows 7
• PsExec v1.96
• Windows Image to Virtual Hard Disk (WIM2VHD) Converter
• Horst Schaeffer’s INI File Tool

Process

Disclaimer: This is close to a step-by-step guide, but it assumes a certain level of technical knowledge and understanding. Hopefully I’ve made it as easy to follow and as painless as possible but tread carefully. To quote Scott Hanselman:

“This is some advanced stuff and you may lose a finger. No warranty express or implied.”

To begin with, we need to create our .VHD file. Mike Kolitz has created a fantastic script called WIM2VHD that takes much of the hard work out of this task for us. The example below uses a Windows Server 2008 R2 WIM file as source, and creates a 49GB Enterprise edition dynamically expanding .VHD file from it.

Now that we have created the .VHD file, we need to make some changes to the operating system contained within it. From the same elevated command prompt used for the previous command, we’ll use diskpart.exe to mount the .VHD. Note the use of LIST VOLUME so that we can see the correct volume number, select it, and assign a drive letter to it - you’ll need to change the number in SELECT VOLUME to match your environment:

At this stage, I use the offline servicing tool, dism.exe, to change the default language, keyboard layout and timezone to something more appropriate for the United Kingdom. You can obviously make other changes too if necessary:

Next, we need to make changes to the registry for each of the six USB device drivers. We’ll use the built in reg.exe command to do this. By default, when an operating system is launched from a dynamically expanding .VHD file using native VHD boot, it expands to its maximum size, reverting to its dynamic size when it is shutdown. I also modify the VirtualDiskExpandOnMount registry value to prevent this:

The next step is to modify the .INF files so that the operating system does not reset these values to their defaults at any point. As some of the files require SYSTEM permissions to modify them, we use the excellent SysInternals psexec.exe command to launch a command prompt in the SYSTEM security context.

From the resultant command window, we use Horst Schaeffer’s INI File Tool to modify any .INF files that might reset the device driver values to their defaults:

Now we delete the precompiled INF files, and copy our modified INF files to appropriate locations. Note that the file locations differ for x64 and x86 builds.

For x64 builds only:

For x86 builds only:

The next part is optional. It creates a differencing .VHD from the original file. The allows you to leave the base .VHD file intact and make all subsequent changes to the differencing .VHD instead. It’s a great way of building a base operating system image and then branching it for development work or testing. Once again, make sure you note the correct volume number when doing this. So, from the original elevated command prompt:

Now all that is left to do is to create a bootloader on the external USB disk and create an entry for our Native VHD Boot. When you BCDEDIT /COPY {default} below, note the resultant GUID that you are given and use that instead of the {5aaa2c7a-a627-11de-83c7-001372bf1815} listed in the example. So, continuing from the same command window:

And that’s it. Reboot your computer, select your external USB disk as your boot device, and you should see the entry you created above. Windows will start, perform the final stages of setup (rebooting a couple of times in the process) and you will be done.

I have personally used this method to store a large number of .VHD files (fixed, dynamic and differencing) and to use them to boot Windows 7 Enterprise and Ultimate in both x64 and x86 platform versions, and the various Windows Server 2008 R2 editions, and found it to be an extremely flexible option.

I’ve even had some success swapping the external USB disk between machines. It doesn’t always work (and to be honest, I haven’t had the time to look any deeper into why) but I’ve used the same native VHD boot instance on a Fujitsu Siemens Celsius H240, Lifebook T4210 and Lifebook S7220, swapping it backwards and forwards between machines and letting Windows manage the driver changes each time without issue.

I’ve also had success with native VHD boot using .VHD files created from Windows Backup and have recently started looking at using the files created from the SysInternals Disk2vhd tool too. Pop back sometime soon for those adventures...

Originally a guest post at Mark Wilson's blog.

Whilst this hasn’t been too much of a problem for the majority of the Architects I work with - after all, we’re fairly self-sufficient when it comes to supporting our environments and are infinitely capable of collectively dreaming up ever more creative workarounds for the things that don’t work - it isn’t a solution that’s manageable at scale.

Then, along came Windows 7 and Windows Server 2008 R2 and with them came the introduction of a great new feature - Native VHD Boot. With a little configuration, this has enabled us to leave the existing Windows XP corporate build in place, and to deploy a 32-bit or 64-bit Windows 7 (Enterprise or Ultimate) or 64-bit Windows Server 2008 R2 build side-by-side, crucially without having to make any changes to the Windows XP build or the existing disk partitioning scheme.

To achieve this, we created a new Windows 7 or Windows Server 2008 R2 bootloader, and “chained” the original Windows XP bootloader from it. At boot, this allows us to select a Native VHD Boot into, for example, a 64-bit Windows Server 2008 R2 Enterprise build, or to select the chained bootloader which allows us to boot into the corporate Windows XP build.

Of course, you’ll need to create your VHD-contained Windows 7 or Windows Server 2008 R2 OS build and put it to your local disk, and this post doesn’t go into that detail, but once you have done that, the steps below will allow you to create a new bootloader and chain your existing Windows XP corporate build from it.

To begin, boot your computer using your Windows 7 or Windows Server 2008 R2 installation media. When you reach the Install Windows screen, press Shift+F10 to run up a Command Prompt window.

To write the new Windows 7 or Windows Server 2008 R2 bootloader:

To create a BCD store from the Windows VHD:

To set up the Native VHD Boot:

To set up the legacy boot:

To put things back to normal, should you ever need to:

Originally a guest post at Mark Wilson's blog.