Hyper-V Installation Tricks - Part 1: Sysprep and Hyper-V

Updated for Hyper-V RTM

Before we jump right into this, I thought it would be best if we got a few things straight.  For the remainder of this post, everytime I say "sysprep," I'm referring to running Sysprep with the /generalize switch.  This is the best way to make sure that the Windows installation image that you capture and apply to other systems actually works when you put it on those other systems.

For more details on what Sysprep with and without the /generalize switch does, I encourage you to read the documentation, which I have conveniently provided a hyperlink to.

So, you're planning to sysprep a Windows Server 2008 box with Hyper-V installed?  Good choice.  I'm sure you'll be happy with the result, but there are few things that you'll have to do to make sure Hyper-V functions properly after you apply the image to a different computer. 

The purpose of sysprep is to make the system as generic as possible so that any image taken of a sysprep'd system can then be applied to different hardware.  Syspreping the system will destroy any super-specific information - like hardware IDs.  The next time that Windows installation boots up, all of the information is regenerated.

With Hyper-V, however, you'll need to do a little bit of work after the system boots back up for the first time.

First, the hypervisor will not be running , since the BCD (Boot Configuration Data) store has been generalized.  You'll need to run the following command to put the hypervisor launch directive back in the BCD store:

bcdedit /set hypervisorlaunchtype auto

Secondly, any virtual network switch that was set for external connectivity will revert to an internal-only switch.  This is because the physical NIC that the external switch was bound to doesn't technically exist after a sysprep.  You'll need to rebind the switch to a physical NIC if you want external connectivity again.

Thirdly, any disks that you have set to pass-thru (whether hard disks or CD/DVD ROM drives) will need to be set up again (this is also because of the hardware IDs).

If you have to do this on a lot of systems, I recommend that you take a look at our WMI API documentation and figure out how to do this programmatically, and then add commands to your unattend.xml file that run those scripts after the first boot on the new hardware.

I'll talk more about this in a future post.

Comments

• Anonymous
  March 25, 2008
  PingBack from http://msdnrss.thecoderblogs.com/2008/03/26/

• Anonymous
  March 26, 2008
  As you may have heard, we've shipped Hyper-V RC0 . Sorry for the lack of posts - it seems like I'm always

• Anonymous
  March 28, 2008
  I am feeling lazy today - but thankfully my colleagues have been working hard :-) Mike Kolitz has done

• Anonymous
  March 31, 2008
  To my knowledge there is no SYSPREP provider for Hyper-V and so I wonder if this approach is really supported by PSS? From my personal experience and from validating this approach with PSS many weeks ago myself (prior to this post) the results I got back from PSS was that this is not supported.

• Anonymous
  April 01, 2008
  @ Patrick: It's our job to communicate this to the PSS team.  I'll make sure we get the message out to them about what is and is not supported at RTM.

• Anonymous
  August 15, 2008
  I haven’t updated my three part series about different ways to install Hyper-V for our RTM release.