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.