First service pack for Windows 7 and Windows Server 2008 R2

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

It’s not news that there will be a service pack for Windows 7 and Server 2008 R2.  We don’t know when it will come (and I’ve been asked not to speculate…) – and we don’t know if there will be a public beta but there will be a service pack.

Here’s what Microsoft has announced so far:

  • The same service pack will be applicable for Windows server and client – i.e. for Windows 7 and Server 2008 R2 (just as with Vista/Server 2008 service packs).
  • SP1 will enable two key new features for Windows Server 2008 R2: Dynamic Memory for Hyper-V, allowing for dynamically adjusting RAM allocation between virtual machines; and RemoteFX, which is an enhancement for RDP for rich media and 3D.
  • For Windows 7, there are no significant changes in SP1 – it’s effectively an update rollup – there is no need to wait for service pack 1 before deploying!

Desktop virtualisation shake-up at Microsoft

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

What an afternoon… for a few days now, I’ve been trying to find out what’s the big announcement from Microsoft and Citrix in the desktop virtualisation hour webcast later today. I was keeping quiet until after the webcast but now the embargo has lifted, Microsoft has issued a press release, and the news is all over the web:

  • Coming in Windows Server 2008 R2 service pack 1 (for which there is no date announced, yet) will be the dynamic memory functionality that was in early releases of Hyper-V for Windows Server 2008 R2 but was later pulled from the product.  Also in SP1 will be a new graphics acceleration platform, known as RemoteFX, that is based on desktop-remoting technology that Microsoft obtained in 2008 when it acquired Calista Technologies, allowing for rich media content to be accessed over the remote desktop protocol, enabling users of virtual desktops and applications to receive a rich 3-D, multimedia experience while accessing information remotely..
  • Microsoft and Citrix are offering a “Rescue for VMware VDI” promotion, which allows VMware View customers to trade in up to 500 licenses at no additional cost, and the “VDI Kick Start” promotion, which offers new customers a more than 50 percent discount off the estimated retail price.
  • There are virtualisation licensing changes too: from July, Windows Client Software Assurance customers will no longer have to buy a separate license to access their Windows operating system in a VDI environment, as virtual desktop access rights now will be a Software Assurance (SA) benefit – effectively, if you have SA, you get Windows on screen, no matter what processor it is running on!  There will also be new roaming usage rights and Windows Client Software Assurance and new Virtual Desktop Access (the new name for VECD) customers will have the right to access their virtual Windows desktop and their Microsoft Office applications hosted on VDI technology on secondary, non-corporate network devices, such as home PCs and kiosks.
  • Citrix will ensure that XenDesktop HDX technology will be interoperable with and will extend RemoteFX within 6 months.
  • Oh yes, and Windows XP Mode (i.e. Windows Virtual PC) will no longer requires hardware virtualisation technology (although, frankly, I find that piece of news a little less exciting as I’d really like to see Virtual PC replaced by a client-side hypervisor).

Windows Server 2008 R2 Hyper-V crash turns out to be an Intel driver issue

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few weeks ago, I rebuilt a recently decommissioned server to run as an infrastructure test and development rig at home.  I installed Windows Server 2008 R2, enabled the Hyper-V role and all was good until I started to configure my networks, during which I experienced a “blue screen of death” (BSOD) – never a good thing on your virtualisation host, especially when it does the same thing again on reboot:

“Oh dear, my freshly built Windows Server 2008 R2 machine has just thrown 3 BSODs in a row… after running normally for an hour or so :-(“

The server is a Dell PowerEdge 840 (a small, workgroup server that I bought a couple of years ago) with 8GB RAM and a quad core Xeon CPU.  The hardware is nothing special – but fine for my infrastructure testing – and it had been running with Windows Server 2008 Hyper-V since new (with no issues) but this was the first time I’d tried R2. 

I have 3 network adapters in the server: a built in Broadcom NetXtreme Gigabit card (which I’ve reserved for remote access); and 2 Intel PRO/100s (for VM workloads).  Ideally I’d use Gigabit Ethernet cards for the VM workload too, but this is only my home network and they were what I had available!

Trying to find out the cause of the problem, I ran WhoCrashed, which gave me the following information:

This was likely caused by the following module: efe5b32e.sys
Bugcheck code: 0xD1 (0x0, 0x2, 0x0, 0xFFFFF88002C4A3F1)
Error: DRIVER_IRQL_NOT_LESS_OR_EQUAL
Dump file: C:\Windows\Minidump\020410-15397-01.dmp
file path: C:\Windows\system32\drivers\efe5b32e.sys
product: Intel(R) PRO/100 Adapter
company: Intel Corporation
description: Intel(R) PRO/100 Adapter NDIS 5.1 driver

That confirmed that the issue was with the Intel NIC driver, which sounded right as, after enabling the Hyper-V role, I connected an Ethernet cable to one of the Intel NICs and got a BSOD each time the server came up. If I disconnected the cable, no BSOD.  Back to the twitters:

“Does anyone know of any problems with Intel NICs and Hyper-V R2 (that might cause a BSOD)?”

I switched the in-box (Microsoft) drivers for some (older) Intel ones.  That didn’t fix things, so I switched back to the latest drivers.  Eventually I found that the issue was caused by the checkbox for “Allow management operating system to share this network adapter” and that,  if the NIC is live and I selected this, I could reproduce the error:

“Found the source of yesterday’s WS08R2 Hyper-V crash… any idea why enabling this option http://twitpic.com/11b64y would trip a BSOD?”

Even though I could work around the issue (because I don’t want to share a NIC between the parent partition and the children anyway – I have the Broadcom NIC for remote access) it seemed strange that this behaviour should occur.  There was no NIC teaming involved and the server was still a straightforward UK installation (aside from enabling Hyper-V and setting up virtual networks). 

Based on suggestions from other Virtual Machine MVPs I also:

  • Flashed the NICs to the latest release of the Intel Boot Agent (these cards don’t have a BIOS).
  • Updated the Broadcom NIC to the latest drivers too.
  • Attempted to turn off Jumbo frames but the the option was not available in the properties so I could rule that out.

Thankfully, @stufox (from Microsoft in New Zealand) saw my tweets and was kind enough to step in to offer assistance.  It took us a few days, thanks to timezone differences and my work schedule, but we got there in the end.

First up, I sent Stu a minidump from the crash, which he worked on with one of the Windows Server kernel developers. They suggested running the driver verifier (verifier.exe) against the various physical network adapters (and against vmswitch.sys).  More details of this tool can be found in Microsoft knowledge base article 244617 but the response to the verifier /query command was as follows:

09/02/2010, 23:19:33
Level: 000009BB
RaiseIrqls: 0
AcquireSpinLocks: 44317
SynchronizeExecutions: 2
AllocationsAttempted: 152850
AllocationsSucceeded: 152850
AllocationsSucceededSpecialPool: 152850
AllocationsWithNoTag: 0
AllocationsFailed: 0
AllocationsFailedDeliberately: 0
Trims: 41047
UnTrackedPool: 141544
 
Verified drivers:
 
Name: efe5b32e.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 0
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 0
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 0
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 0
 
Name: ndis.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 6
CurrentNonPagedPoolAllocations: 1926
PeakPagedPoolAllocations: 8
PeakNonPagedPoolAllocations: 1928
PagedPoolUsageInBytes: 984
NonPagedPoolUsageInBytes: 1381456
PeakPagedPoolUsageInBytes: 1296
PeakNonPagedPoolUsageInBytes: 1381968
 
Name: b57nd60a.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 3
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 3
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 188448
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 188448
 
Name: vmswitch.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 1
CurrentNonPagedPoolAllocations: 18
PeakPagedPoolAllocations: 2
PeakNonPagedPoolAllocations: 24
PagedPoolUsageInBytes: 108
NonPagedPoolUsageInBytes: 50352
PeakPagedPoolUsageInBytes: 632
PeakNonPagedPoolUsageInBytes: 54464

To be honest, I haven’t a clue what half of that means but the guys at Microsoft did – and they also asked me for a kernel dump (Dirk A D Smith has written an article at Network World that gives a good description of the various types of memory dump: minidump; kernel; and full). Transmitting this file caused some issues (it was 256MB in size – too big for e-mail) but it compressed well, and 7-zip allowed me to split it into chunks to get under the 50GB file size limit on Windows Live SkyDrive.  Using this, Stu and his kernel developer colleagues were able to see that there is a bug in the Intel driver I’m using but it turns out there is another workaround too – turning off Large Send Offload in the network adapter properties.  Since I did this, the server has run without a hiccup (as I would have expected).

“Thanks to @stufox for helping me fix the BSOD on my Hyper-V R2 server. Turned out to be an Intel device driver issue – I will blog details”

It’s good to know that Hyper-V was not at fault here: sure, it shows that a rogue device driver can bring down a Windows system but that’s hardly breaking news – the good thing about the Hyper-V architecture is that I can easily update network device drivers.  And, let’s face it, I was running enterprise-class software on a workgroup server with some old, unsupported, hardware – you could say that I was asking for trouble…

Why Windows Server User Group meetings are a bit like London buses

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

There’s a saying in the UK when multiples of something come along at the same time… “like London buses… nothing and then three at once” (based on the principle of bunching, for high frequency services – incidentally, that’s an alien concept where I live – we’re lucky if the bus shows up at all…).

Anyway, back to the point – hot on the heels of the Windows Server User Group (WSUG) meeting with Joey Snow, Mark Parris has arranged a second meeting to co-incide with the Microsoft UK TechDays – this time it’s on 13 April 2010 at Microsoft’s Offices in London (map and directions) and the speaker will be Dan Pearson, from David Solomon’s Expert Seminars.

Dan was formerly a Senior Escalation Lead at Microsoft, where he worked in the Windows Base OS team supporting Microsoft customers. Dan will be talking about Windows crash dump analysis as well as Windows performance troubleshooting and analysis.

Check out the event registration site for more details.

User group meeting (Windows Server User Group)

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few weeks ago, I blogged about Microsoft’s UK TechDays and mentioned that the Windows Server User Group was planning to run an evening event that week.

Now we’re ready to announce the details: whilst he was at the MVP Summit last month, Mark Parris managed to persuade Joey Snow to come along and speak to us on the evening of 12 April 2010 at Microsoft’s Offices in London (map and directions).  Joey is a technical evangelist for the Worldwide Developer and Platform Evangelism team at Microsoft focusing on Windows Server, IIS and SQL Server and he’ll be presenting on Windows Server 2008 R2’s new BranchCache functionality in as well as migrating server roles to Windows Server 2008 R2.

Check out the event registration site for more details.

Announcing the Windows Server User Group (WSUG)

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Back in 2008, I set up a LinkedIn group after the UK Windows Server User Group’s leader, Scotty McLeod, was involved in a tragic accident and it was originally intended to provide a temporary workaround until we got the Windows Server Team site up and running again.

Towards the end of last year Mark Parris and I had a conversation around combining the UK Active Directory User Group with the UK Windows Server User Group. The reasoning behind this was that Windows Server User Group meetings had become few and far between, meanwhile the Active Directory User Group is an active community. At the same time Active Directory touches almost every component of Windows Server (it does, after all, account for five of the Windows Server roles) and the division between Windows Server content and Active Directory content was becoming very blurred.

Consequently, the two user groups will now merge to become collectively known as the Windows Server User Group (WSUG).

Mark has set up a new website and forums and, whilst they still require some work, they share credentials and support both traditional user/password authentication and OpenID.

Meanwhile the LinkedIn group will still exist, but I’m honestly not sure that it provides any value and I would encourage members to sign up at the WSUG website, where we are trying to build an active Windows Server community with discussion forums and in-person meetings (generally held at Microsoft offices in the UK).

Twitter users can also follow @windowsserverug for event announcements, etc.

Please let us know what you would like to see on the forums and, if you would like to get more involved, please get in touch with either Mark Parris or myself.  You can find our contact details on the WSUG site.

Migrating infrastructure services to a Windows Server 2008 R2 computer

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Having built a low-power server to run my home infrastructure, I need to get moving on decommissioning the old virtual machines so I can turn off the Dell PowerEdge 840 that runs them.

The first step was to migrate the Active Directory Domain Services from my existing Windows Server 2003 R2 SP2 installation to the new Windows Server 2008 R2 machine:

  1. On the 2003 DC, insert the 2008 R2 DVD and open a command prompt.
  2. Locate adprep.exe (or adprep32.exe if running on a 32-bit architecture – I was already running 64-bit) in the \support\adprep folder (note the changed file location between Windows Server 2008 and 2008 R2 – it used to be in \sources\adprep) and run the following commands (theres more detail on these actions in Daniel Petri’s article on Windows Server 2008 ADprep):
    • adprep /forestprep (on the schema master for the forest)
    • adprep /domainprep (on the infrastructure master for each domain, after making sure that the domain is in at least Windows 2000 native mode)
    • adprep /domainprep /gpprep (on the infrastructure master for each domain)
    • adprep /rodcprep (if read only domain controllers are required in a Windows Server 2003 forest)
  3. After this, I ran dcpromo.exe on the new server, promoting it to a domain controller in the existing forest/domain, electing to make the server a DNS server and a Global Catalog server at the same time.
  4. With the new server running as a DC, I needed to transfer the FSMO roles.  I did this by following the advice in Microsoft knowledge base article 324801 to: register scmmgmnt.dll; run the Active Directory Schema and transfer the Schema Master role; run Active Directory Domains and Trusts and transfer the Domain Naming Master role; run Active Directory Users and Computers and transfer the RID Master, PDC Emulator and Infrastructure Master Roles.  Incidentally, even though I did this with the GUI tools, Adam Bell outlines a much smarter method to transfer FSMO roles using PowerShell.
  5. After checking that the new server’s DNS service successfully performed simple and recursive lookups (on the Monitoring tab in the DNS Server properties) then switching the new server’s primary DNS server to use itself (rather than the old DC), I ran dcpromo.exe on the 2003 server to demote it to a normal domain member, before ensuring that all computers were using the new (2008 R2) DNS server and removing the role from the 2003 computer.
  6. With Active Directory and DNS migrated, the last major service to move was DHCP (I do have some other services running on a separate server: TFTP, phone directory web service, etc. running on another server but they are application services really – this post will concentrate on the infrastructure).  This is pretty straightforward (details can be found on the Microsoft Enterprise Networking team blog) and involves a couple of commands – one to export from the 2003 R2 server and another to import on the 2008 R2 server:
    • netsh dhcp server export filename all
    • netsh dhcp server import filename all
  7. After confirming that the DHCP service was running on the target with all entries transferred, I stopped the DHCP Server service on the source (net stop "DHCP Server"), and renewed a client IP address (by starting up a PC, but running ipconfig /renew would have been as effective) to check that renewals worked before restarting the service (net start "DHCP Server"), deauthorising the original DHCP server and removing the DHCP role.
  8. If I was using the Encrypted File System or the server was a Terminal Services Licensing Server there would be some extra steps (not for me).
  9. Finally, with all services removed from the 2003 machine, I shut it down, deleted the virtual machine files from the host server, and removed the computer account from Active Directory, which can now have the forest and domain functional levels raised if necessary, as I’m completely free from legacy domain controllers.

John Craddock whiteboards DirectAccess and Active Directory Recycle Bin

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I spent yesterday evening at an Active Directory User Group (ADUG) meeting where John Craddock presented on IPv6 and DirectAccess (repeating two of John’s TechEd Europe 2009 sessions).  I have to admit that, at times, I struggled to keep up as the technology went deep but it was extremely worthwhile.  I hope to find the time to write some blog posts to summarise some of key points from the evening; however John also has two 10 minute videos on the Dutch site NGN, in which he “whiteboards” Direct Access and Active Directory Recycle Bin.  These are worth a few minutes of your time to get a quick overview of two new technologies in Windows Server 2008 R2.

Windows native boot from VHD roundup

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

This is the first of several planned posts based on knowledge gained at Tech·Ed last week – but this one is necessarily brief. Mark Minasi, who presented the session that this content is based on, owns the copyright on the materials he presented (although Microsoft still distributed them to delegates). Consequently, I can’t write his session up as fully as I would like; however this post captures some of the key points (along with some narrative of my own) as I see nothing that’s not already in the public domain (and some of which has already been written about on this blog). The value in Mark’s presentation was that it pulled together various items of information into one place and explained it in a way that was simple to follow – consequently I’m not repeating the full details, just the high level overview, with some extra links where I feel they add value (Mark seems like a decent fellow – he’s only trying to protect his income and I suspect the real problem would be if I presented his materials as my own – I’m sure he would understand the fine line I’m attempting to walk here):

  • The session was titled “How Windows Storage is Changing: Everything is going VHD (CLI302)” and that’s pretty spot on – the virtual hard disk (.VHD) file format allows an entire disk partition (but not a whole drive with multiple partitions) to be packaged in a single file complete with folder structure and NTFS permissions: Microsoft’s Storage Server uses .VHD files for iSCSI targets; Windows Backup has been able to perform completed PC backups to .VHD files since Vista; and with Windows 7 we have the ability to natively boot Windows from a VHD file. Just to be clear – this is not client/server virtualisation (as in with a hypervisor) – this is storage virtualisation (presenting the VHD container as as a logical volume, stored on a physical disk).
  • To understand native .VHD booting, it’s useful to understand recent changes in the boot process: boot.ini is no more – instead we have a Boot Configuration Database (BCD) and a system reserved partition (incidentally, that’s the same one that is used for BitLocker, and is automatically created in Windows 7, with no drive letter assigned).
  • Running Windows Backup from the command line with wbadmin.exe requires the use of the -allcritical switch to ensure that the System Reserved partition is backed up.
  • As Mike Kolitz described back in May, access to .VHD file contents from Windows 7 and Server 2008 R2 is provided by a completely new mini-port driver in the storage stack for VHD files. This VHD driver enables requests to files in the VHD to be sent to the host NTFS file system on the physical partition where the VHD file is located. VHD operations can also be performed on a remote share.
  • The steps for creating a .VHD file, attaching (mounting) it, assigning a drive letter and formatting the volume can be found in my previous post on running Windows from a USB flash drive (as well as elsewhere on the ‘net).
  • The diskpart.exe command can be used to view the details of the VHD once mounted (detail disk) and it will be identified as a Msft Virtual Disk SCSI Disk Device.
  • The System Reserved Boot Partition may populated using the bcdboot.exe command. After this partition has been created, the remainder can be partitioned and formatted, then a pre-configured .VHD can be copied to the second (non-system) partition. After editing the BCD and rebooting, the physical drive will be something like D: or E: (depending on the presence of optical drives) and the .VHD will be C:.
  • There are various methods for creating a pre-configured .VHD, including booting a reference PC from Windows PE and using imagex.exe (from the Windows Automated Installation Kit) to capture the disk contents to a .WIM file, then mounting the target .VHD and deploying the .WIM image to it. Alternatively, there is a SysInternals tool called Disk2VHD.
  • The changes to the BCD are also documented in a previous post on this site but Mark also highlighted the existence of the [locate] parameter instead of specifying a drive manually (James O’Neill uses it in his post on booting from VHD and the joy of BCDEdit).
  • There are GUI tools for editing the BCD, but bcdedit.exe is worth getting to know:

    “The GUI BCDEdit commands are rather like having a 3 metre ladder for a 5 metre wall” … “Step into the light, come to the command line, in the command line there is freedom my friends.”

    [Mark Minasi at TechEd Europe 2009]

  • Booting from VHD is a great feature but it does have its limitations: for instance I can’t use it on my everyday notebook PC because the current release doesn’t support hibernation or BitLocker.
  • To finish up his presentation, Mark demonstrated an unsupported method for installing Windows directly to .VHD: Run Windows setup and press shift and F10 to break out into a command prompt; wipe and partition the hard drive, creating and attach a new .VHD; ignore Windows setup’s protests that it can’t be installed to the .VHD – click the Next button anyway and it should work (although it may be patched in a future release).

Finally, if the contents of this post are interesting, this blog recently featured two guest posts from my friend and colleague, Garry Martin that build on the concepts described above: in the first post, Garry described the process for booting Windows 7 from VHD on a Windows XP system; the second went deep into an unsupported, but nevertheless useful, method for booting Windows 7 or Server 2008 R2 from a VHD on removable media… perhaps a USB flash drive? There are also some useful links in Mike Ormond’s post on native VHD booting and Jon Galloway has a whole bunch of tips even if he is still searching for his virtual machine nirvana.

Native VHD boot Windows 7 or Server 2008 R2 from an external USB drive

Posted on By Garry Martin
This content is 15 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Guest Post
Are you excited about Native VHD Boot for Windows 7 (Enterprise or Ultimate) and Windows Server 2008 R2 but wish you could use an external USB drive to store the .VHD files? Well unfortunately it isn’t officially supported but, if that doesn’t worry you too much, you might find this post interesting…

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 (0x3), 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 (0x0).

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 – Microsoft 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:

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.

From an elevated command prompt, run the following command:

CSCRIPT WIM2VHD.WSF /WIM:”M:\Sources\SERVER\install.wim” /SKU:SERVERENTERPRISE /VHD:”M:\BootVHDs\W2K8R2ENT.vhd” /SIZE:50176 /DISKTYPE:DYNAMIC

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:

DISKPART
SELECT VDISK FILE=”M:\BootVHDs\W2K8R2ENT.vhd”
ATTACH VDISK
LIST VOLUME
SELECT VOLUME 8
ASSIGN LETTER=R
EXIT

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:

DISM /IMAGE:R: /Set-SysLocale:en-GB
DISM /IMAGE:R: /Set-UserLocale:en-GB
DISM /IMAGE:R: /Set-InputLocale:409:00000409
DISM /IMAGE:R: /Set-TimeZone:”GMT Standard Time”

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:

REG LOAD HKLM\TEMP R:\WINDOWS\SYSTEM32\CONFIG\SYSTEM
REG ADD HKLM\TEMP\ControlSet001\services\usbccgp /v Group /t REG_SZ /d “Boot Bus Extender” /f
REG ADD HKLM\TEMP\ControlSet001\services\usbccgp /v Start /t REG_DWORD /d 0 /f
REG ADD HKLM\TEMP\ControlSet001\services\usbehci /v Group /t REG_SZ /d “Boot Bus Extender” /f
REG ADD HKLM\TEMP\ControlSet001\services\usbehci /v Start /t REG_DWORD /d 0 /f
REG ADD HKLM\TEMP\ControlSet001\services\usbhub /v Group /t REG_SZ /d “Boot Bus Extender” /f
REG ADD HKLM\TEMP\ControlSet001\services\usbhub /v Start /t REG_DWORD /d 0 /f
REG ADD HKLM\TEMP\ControlSet001\services\usbohci /v Group /t REG_SZ /d “Boot Bus Extender” /f
REG ADD HKLM\TEMP\ControlSet001\services\usbohci /v Start /t REG_DWORD /d 0 /f
REG ADD HKLM\TEMP\ControlSet001\services\USBSTOR /v Group /t REG_SZ /d “Boot Bus Extender” /f
REG ADD HKLM\TEMP\ControlSet001\services\USBSTOR /v Start /t REG_DWORD /d 0 /f
REG ADD HKLM\TEMP\ControlSet001\services\usbuhci /v Group /t REG_SZ /d “Boot Bus Extender” /f
REG ADD HKLM\TEMP\ControlSet001\services\usbuhci /v Start /t REG_DWORD /d 0 /f
REG ADD HKLM\TEMP\ControlSet001\services\FsDepends\Parameters /v VirtualDiskExpandOnMount /t REG_DWORD /d 4 /f
REG UNLOAD HKLM\TEMP

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.

PSEXEC –i –d –s C:\Windows\System32\cmd.exe

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:

INIFILE R:\Windows\inf\usb.inf [StandardHub.AddService] StartType = 0 ; SERVICE_BOOT_START
INIFILE R:\Windows\inf\usb.inf [StandardHub.AddService] LoadOrderGroup = Boot Bus Extender
INIFILE R:\Windows\inf\usb.inf [CommonClassParent.AddService] StartType = 0 ; SERVICE_BOOT_START
INIFILE R:\Windows\inf\usb.inf [CommonClassParent.AddService] LoadOrderGroup = Boot Bus Extender
INIFILE R:\Windows\inf\usbport.inf [EHCI.AddService] StartType = 0 ; SERVICE_BOOT_START
INIFILE R:\Windows\inf\usbport.inf [EHCI.AddService] LoadOrderGroup = Boot Bus Extender
INIFILE R:\Windows\inf\usbport.inf [OHCI.AddService] StartType = 0 ; SERVICE_BOOT_START
INIFILE R:\Windows\inf\usbport.inf [OHCI.AddService] LoadOrderGroup = Boot Bus Extender
INIFILE R:\Windows\inf\usbport.inf [UHCI.AddService] StartType = 0 ; SERVICE_BOOT_START
INIFILE R:\Windows\inf\usbport.inf [UHCI.AddService] LoadOrderGroup = Boot Bus Extender
INIFILE R:\Windows\inf\usbport.inf [ROOTHUB.AddService] StartType = 0 ; SERVICE_BOOT_START
INIFILE R:\Windows\inf\usbport.inf [ROOTHUB.AddService] LoadOrderGroup = Boot Bus Extender
INIFILE R:\Windows\inf\usbstor.inf [USBSTOR.AddService] StartType = 0 ; SERVICE_BOOT_START
INIFILE R:\Windows\inf\usbstor.inf [USBSTOR.AddService] LoadOrderGroup = Boot Bus Extender
INIFILE R:\Windows\inf\brmfcsto.inf [USBSTOR.AddService] StartType = 0 ; SERVICE_BOOT_START
INIFILE R:\Windows\inf\brmfcsto.inf [USBSTOR.AddService] LoadOrderGroup = Boot Bus Extender

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:
DEL /Q R:\Windows\inf\usb.pnf
DEL /Q R:\Windows\System32\DriverStore\FileRepository\usb.inf_amd64_neutral_e2b28ecac19a29af\usb.pnf
DEL /Q R:\Windows\winsxs\amd64_usb.inf_31bf3856ad364e35_6.1.7600.16385_none_26ed589d28235a16\usb.pnf
DEL /Q R:\Windows\inf\usbport.pnf
DEL /Q R:\Windows\System32\DriverStore\FileRepository\usbport.inf_amd64_neutral_5a41ca742f7973cc\usbport.pnf
DEL /Q R:\Windows\winsxs\amd64_usbport.inf_31bf3856ad364e35_6.1.7600.16385_none_19b7511a1d3ea7fd\usbport.pnf
DEL /Q R:\Windows\inf\usbstor.pnf
DEL /Q R:\Windows\System32\DriverStore\FileRepository\usbstor.inf_amd64_neutral_c301b770e0bfb179\usbstor.pnf
DEL /Q R:\Windows\winsxs\amd64_usbstor.inf_31bf3856ad364e35_6.1.7600.16385_none_a47b405db18421ea\usbstor.pnf
DEL /Q R:\Windows\inf\brmfcsto.pnf
DEL /Q R:\Windows\System32\DriverStore\FileRepository\brmfcsto.inf_amd64_neutral_2d7208355536945e\brmfcsto.pnf
DEL /Q R:\Windows\winsxs\amd64_brmfcsto.inf_31bf3856ad364e35_6.1.7600.16385_none_7fe64f7a6167bcf6\brmfcsto.pnf
COPY /Y R:\Windows\inf\usb.inf R:\Windows\System32\DriverStore\FileRepository\usb.inf_amd64_neutral_e2b28ecac19a29af
COPY /Y R:\Windows\inf\usb.inf R:\Windows\winsxs\amd64_usb.inf_31bf3856ad364e35_6.1.7600.16385_none_26ed589d28235a16
COPY /Y R:\Windows\inf\usbport.inf R:\Windows\System32\DriverStore\FileRepository\usbport.inf_amd64_neutral_5a41ca742f7973cc
COPY /Y R:\Windows\inf\usbport.inf R:\Windows\winsxs\amd64_usbport.inf_31bf3856ad364e35_6.1.7600.16385_none_19b7511a1d3ea7fd
COPY /Y R:\Windows\inf\usbstor.inf R:\Windows\System32\DriverStore\FileRepository\usbstor.inf_amd64_neutral_c301b770e0bfb179
COPY /Y R:\Windows\inf\usbstor.inf R:\Windows\winsxs\amd64_usbstor.inf_31bf3856ad364e35_6.1.7600.16385_none_a47b405db18421ea
COPY /Y R:\Windows\inf\brmfcsto.inf R:\Windows\System32\DriverStore\FileRepository\brmfcsto.inf_amd64_neutral_2d7208355536945e
COPY /Y R:\Windows\inf\brmfcsto.inf R:\Windows\winsxs\amd64_brmfcsto.inf_31bf3856ad364e35_6.1.7600.16385_none_7fe64f7a6167bcf6
EXIT

For x86 builds only:
DEL /Q R:\Windows\inf\usb.pnf
DEL /Q R:\Windows\System32\DriverStore\FileRepository\usb.inf_x86_neutral_e24d8d3fec6e4567\usb.pnf
DEL /Q R:\Windows\winsxs\x86_usb.inf_31bf3856ad364e35_6.1.7600.16385_none_cacebd196fc5e8e0\usb.pnf
DEL /Q R:\Windows\inf\usbport.pnf
DEL /Q R:\Windows\System32\DriverStore\FileRepository\usbport.inf_x86_neutral_ba59fa32fc6a596d\usbport.pnf
DEL /Q R:\Windows\winsxs\x86_usbport.inf_31bf3856ad364e35_6.1.7600.16385_none_bd98b59664e136c7\usbport.pnf
DEL /Q R:\Windows\inf\usbstor.pnf
DEL /Q R:\Windows\System32\DriverStore\FileRepository\usbstor.inf_x86_neutral_83027f5d5b2468d3\usbstor.pnf
DEL /Q R:\Windows\winsxs\x86_usbstor.inf_31bf3856ad364e35_6.1.7600.16385_none_485ca4d9f926b0b4\usbstor.pnf
DEL /Q R:\Windows\inf\brmfcsto.pnf
DEL /Q R:\Windows\System32\DriverStore\FileRepository\brmfcsto.inf_x86_neutral_39ae61431a44cded\brmfcsto.pnf
DEL /Q R:\Windows\winsxs\x86_brmfcsto.inf_31bf3856ad364e35_6.1.7600.16385_none_23c7b3f6a90a4bc0\brmfcsto.pnf
COPY /Y R:\Windows\inf\usb.inf R:\Windows\System32\DriverStore\FileRepository\usb.inf_x86_neutral_e24d8d3fec6e4567
COPY /Y R:\Windows\inf\usb.inf R:\Windows\winsxs\x86_usb.inf_31bf3856ad364e35_6.1.7600.16385_none_cacebd196fc5e8e0
COPY /Y R:\Windows\inf\usbport.inf R:\Windows\System32\DriverStore\FileRepository\usbport.inf_x86_neutral_ba59fa32fc6a596d
COPY /Y R:\Windows\inf\usbport.inf R:\Windows\winsxs\x86_usbport.inf_31bf3856ad364e35_6.1.7600.16385_none_bd98b59664e136c7
COPY /Y R:\Windows\inf\usbstor.inf R:\Windows\System32\DriverStore\FileRepository\usbstor.inf_x86_neutral_83027f5d5b2468d3
COPY /Y R:\Windows\inf\usbstor.inf R:\Windows\winsxs\x86_usbstor.inf_31bf3856ad364e35_6.1.7600.16385_none_485ca4d9f926b0b4
COPY /Y R:\Windows\inf\brmfcsto.inf R:\Windows\System32\DriverStore\FileRepository\brmfcsto.inf_x86_neutral_39ae61431a44cded
COPY /Y R:\Windows\inf\brmfcsto.inf R:\Windows\winsxs\x86_brmfcsto.inf_31bf3856ad364e35_6.1.7600.16385_none_23c7b3f6a90a4bc0
EXIT

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:

DISKPART
SELECT VDISK FILE=”M:\BootVHDs\W2K8R2ENT.vhd”
DETACH VDISK
CREATE VDISK FILE=”M:\BootVHDs\W2K8R2ENT_DIFF.vhd” PARENT=”M:\BootVHDs\W2K8R2ENT.vhd”
SELECT VDISK FILE=”M:\BootVHDs\W2K8R2ENT_DIFF.vhd”
ATTACH VDISK
LIST VOLUME
SELECT VOLUME 8
ASSIGN LETTER=R
EXIT

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:

BOOTSECT /NT60 M: /FORCE /MBR
BCDBOOT R:\WINDOWS /S M:
BCDEDIT /STORE M:\BOOT\BCD /COPY {default} /d “Windows Server 2008 R2 Enterprise”
BCDEDIT /STORE M:\BOOT\BCD /SET {5aaa2c7a-a627-11de-83c7-001372bf1815} DEVICE VHD=[LOCATE]\BootVHDs\W2K8R2ENT_DIFF.vhd
BCDEDIT /STORE M:\BOOT\BCD /SET {5aaa2c7a-a627-11de-83c7-001372bf1815} OSDEVICE VHD=[LOCATE]\BootVHDs\W2K8R2ENT_DIFF.vhd
BCDEDIT /STORE M:\BOOT\BCD /SET {5aaa2c7a-a627-11de-83c7-001372bf1815} DETECTHAL ON

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 and you may even find another guest post documenting those particular adventures…

[MW: Sounds great Garry! Looking forward to it]