Thus far we covered the steps necessary to capture a system image with Hyper-V installed, and how to install Windows and Hyper-V at the same time without dealing with system images at all.

Let's take a step back and talk about system images again.  Images are a great way to deploy a customized version of Windows to many different workstations or servers without having to go through the effort of configuring each system independently of each other.

Even if you're just setting Windows Vista or Windows Server 2008 up from a DVD, you're still using an image to do the installation.  If you look on the DVD in the \sources folder, you'll find a file called install.wim.  WIM stands for Windows IMage, and it's an actual image of a real Windows installation that Setup applies directly to your hard drive (and then manipulates a bit, but that's a different story).

You can also make your own WIM files using the imagex.exe tool that ships with the Windows AIK, which I'll link to again. 

The cool thing about WIMs (and there are actually many, but I'm just going to stick with the one that's relevant to this post) is that - using imagex.exe - you can mount a WIM as a folder on your Win6 (that's Vista and Server 2008)-based system and copy files to or from it, then save your changes.

So what does this have to do with Hyper-V installation?

Well, hang on...  there's more that we need to talk about.

With Windows Vista and Windows Server 2008, some really cool work was done to make the operating systems more servicable.  I'm not really in a position to go into all the details, but one of the absolute coolest side effects was the ability to service a Windows installation without actually booting it, which is called Offline Servicing. 

No, really... what does this have to do with Hyper-V installation?

Hyper-V RC0 ships as a hotfix, which means that you can use the Offline Servicing features of the servicing stack to integrate it with any Windows Server 2008 image that you've got.  (This includes the retail media, as well as any image that you made yourself.  For best results, you should only use images that have been sysprep'd, or are otherwise generalized.)

Assuming you're using WIMs, here's how to do it.

1. Download the Hyper-V RC0 hotfix (it could actually be any hotfix packaged into an MSU)
   
2. Extract the CAB file from the MSU you just downloaded, just like we talked about in Part 2.  There's also a KB article that describes the process.
   
3. Open an elevated AIK Tools Command Prompt (because you've installed the AIK, right?).
   
4. Create a folder to use as a mount point for your WIM (I typically use C:\mnt).
   
5. Run:
   imagex /mountrw <path to WIM> <WIM Image Index> C:\mnt
   (A WIM can have multiple images inside of it, so you need to specify which image you want to deal with.  To get a list of images and their indexes, use imagex /info <path to WIM>)
   
6. Run:
   start /w pkgmgr /ip /m:<path to CAB extracted from the MSU> /o:c:\mnt;c:\mnt\windows /s:%temp%
   
7. Check the return code by running:
   echo %errorlevel%
   
   If it's anything but 0, there was a failure while applying the update.
   
8. Run:
   imagex /unmount /commit c:\mnt

And there you have it.  The next time you apply that image, your Windows installation will have the Hyper-V RC0 bits already present in the package store.  That's different than having the role enabled, though.  You'll still need to enable it (which can be automated using parts of the unattend fragments provided in Part 2), but when you do, you'll have RC0 from the beginning).

Picture it:  Sicily, 1914.  You've got a bunch of Servers that you need to install and configure Windows Server 2008 and Hyper-V RC0 on.  You don't feel like messing around with Sysprep.  What do you do?

Well, since none of these things existed in 1914, you're probably pretty safe, but that doesn't really help anyone right now, does it?

What you need, is a way to do an unattended installation of Windows and Hyper-V so you don't have to sit there the whole time and type commands when the system is ready for you.  Lucky for you, we've already thought of that. 

Before you begin, I strongly recommend that you download the Windows AIK for Windows Server 2008 and Windows Vista SP1.  The AIK contains tools and documentation specifically for helping administrators just like you to roll-out Windows on a large scale.  With the AIK, you'll get a nifty little tool that will help you build unattended installation files (formerly called sysprep.inf, now called unattend.xml).  You can download it here.

Assumptions

• For the purposes of this post, I'm going to assume that you already have an unattend.xml file you plan on using to answer questions at install-time.  In the body of this post, I'll only be providing XML fragments for you to drop into your answer file as necessary.  But, just to make sure that everyone gets the information they way, I'll attach a complete and working answer file (except for the product key, of course), which you can find at the bottom of this post.
  
• You're dealing with enabling the Hyper-V role on x64 servers, and you want to apply the RC0 patch.
  
• You're going to be using a USB key with your Windows installation media to do the unattended installation.  You could just as easily create a custom install DVD with the unattend file and the RC0 QFE on it.  It's up to you, but I'm just going to stick with the steps for a USB key.

The Steps

• Download the Hyper-V RC0 patch.  (We're assuming you're doing this on the server, so we're working with x64 packages only.)  It's over on the Microsoft Download Center, which is right over here.  Download the MSU, and save it to your local machine.
  
• Create a working directory on your local machine.  I prefer to call mine C:\extract.
  
• From an elevated command prompt, run the following command:
  expand -F:* <MSU file that you just downloaded> C:\extract
  
• If you look in C:\extract, you should see two CAB files.  Ignore the one named WSUSSCAN.CAB - it's the other one that you're interested in.  Copy it to the root of your USB key.
  
• Open up your unattend.xml file and add one of the following fragments right after the <unattend /> element, but before any of the <settings /> elements
  
  <!-- fragment for Server Full -->
  <servicing>
      <package
          action="configure">
          <assemblyIdentity
              name="Microsoft-Windows-Foundation-Package"
              version="6.0.6001.18000"
              processorArchitecture="amd64"
              publicKeyToken="31bf3856ad364e35" 
              language="" />
          <selection
              name="Microsoft-Hyper-V"
              state="true" />
          <selection
              name="Microsoft-Hyper-V-Management-Clients"
              state="true" />
      </package>
      <package
          action="install">
          <assemblyIdentity
              name="Package_for_KB949219"
              version="6.0.1.2" 
              processorArchitecture="amd64"
              publicKeyToken="31bf3856ad364e35"
              language="neutral" />
          <source
              location="E:\Windows6.0-KB949219-x64.cab" />
      </package>
  </servicing>
  
  -or-
  
<!-- fragment for Server Core -->
<servicing>
    <package
        action="configure">
        <assemblyIdentity
            name="Microsoft-Windows-ServerCore-Package"
            version="6.0.6001.18000"
            processorArchitecture="amd64"
            publicKeyToken="31bf3856ad364e35" 
            language="" />
        <selection
            name="Microsoft-Hyper-V"
            state="true" />
    </package>
    <package
        action="install">
        <assemblyIdentity
            name="Package_for_KB949219"
            version="6.0.1.2" 
            processorArchitecture="amd64"
            publicKeyToken="31bf3856ad364e35"
            language="neutral" />
        <source
            location="E:\Windows6.0-KB949219-x64.cab" />
    </package>
</servicing>


• Make sure you change the location of the CAB file to point to your USB Key drive (this takes some doing, depending on your hard drive configuration).
  
• Save the unattend.xml file to your USB key as "autounattend.xml".
  
• Go test it out.  Pop a Windows installation DVD into one of your servers and plug in the USB Key that you copied all of your unattend files to.  If you had the unattend file answer all of the questions during setup, the installation should just start without you having to do anything.
  
• Once you're at the desktop of your new Windows installation, go check in the Programs applet in the Control Panel.  If you look at installed updates, you should see KB949219 - the Hyper-V RC0 QFE.

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.  A KB article that describes all of these things is in the works, but I thought I'd get this out in the open as soon as possible.  Once the KB is available, I'll provide a link to it here.

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.

As you may have heard, we've shipped Hyper-V RC0.  Sorry for the lack of posts - it seems like I'm always on vacation when we ship a major release like this, so my posts lag a few days behind.

Installing Hyper-V isn't exactly a difficult task, but if you have to do it on multiple machines, installing Windows, installing Hyper-V and then applying the RC0 patch can be a bit time consuming.   The purpose of this series of posts is to offer a few different ways to help you speed up your Hyper-V deployments.

Here are the major topics I'm planning to post about:

• Sysprep and Hyper-V
• Unattended Installation of Windows and Hyper-V RC0
• Integrated Installation - The Beauty of the Win6 servicing stack

If you've got any other suggestions for topics, please let me know.

In an earlier post, I said that you should install Windows Server 2008 RC1 with Hyper-V Beta if you’re getting error 61658 while trying to install the Integration Components in Windows Server 2003.

And you should.

But some people are still seeing it.  If you happen to be one of them, here’s why:

You probably didn’t really install Windows Server 2008 RC1 with Hyper-V Beta; you probably installed Windows Server 2008 RC1, which contained the Hyper-V CTP.

I won’t go into the reason behind having two similarly named releases so close together because I wasn’t involved in that discussion, so any attempt to explain it would be pure speculation on my part.  Needless to say, the situation we find ourselves in is that there is a Windows Server 2008 that has our beta bits in it, and one that has our old CTP bits.

If you’ve yet to install any build of RC1, you can get a link to download the one that has Hyper-V Beta here.

If you’ve already installed it and you’re curious as to whether or not you’ve got the CTP or the Beta bits of Hyper-V, you can easily tell.  If you had to double-click on any MSU files to get the role to show up in Server Manager, you have the CTP release.

After Blogging Mint:

I don’t know if anyone else out there ever saw these videos, but when I was in High School, my physics class had to watch some lectures given by a man named Paul G. Hewitt.  While describing miscellaneous laws of physics, he would commonly prove the law via some demonstration, then ask his class "HC?" which stood for "How come?"

My "Here’s why" series of posts wasn’t exactly inspired by Professor Hewitt, but I’ve yet to write a post without thinking about those videos in some way, so I consider them to be a sort of tip of the hat.

To continue my "here’s why" series of posts, I figured I’d talk about something else that a lot of our users have run into - the infamous disappearing mouse when you try to use a Hyper-V guest while TS’d (that’s Terminal Services - or Remote Desktop) into the host machine.

Here’s the scenario:  You’ve got a VM that you need to use, so you TS into your host machine, start up the Hyper-V Management Tool, connect to your VM and try to use it.  Suddenly, your mouse doesn’t work anymore, so you try to release it using the CTRL-ALT-Left Arrow hotkey.  That doesn’t work.  Now you can’t even use the mouse on your host operating system.

If you close your TS session and restart it, you get your mouse back, but this happens each time you try to control your guest.

Some of you are probably saying "Yes - that happens to me all the time, and it’s annoying!"  Others may think I’m making it up, since they’ve never had this problem.

So, here’s what’s going on.   There are two modes of mouse operation when we’re dealing with Virtual Machines:  integrated and relative, as discussed by Ben Armstrong here. 

When you TS into the host machine, your mouse is running in integrated mode.  When you’re using a VMConnect window to control a VM, the mouse runs in relative mode (with one important caveat, which I will come to later on).  When you mix integrated and relative mode, you get badness.

So what is a humble system administrator or virtualization enthusiast to do?

There are a few work-arounds:

• Run Windows Server 2008 as a guest.  No, seriously.  The Hyper-V Integration Components are built into Windows Server 2008, so it will simply work in this configuration out of the box.
• Install the Integration Components for your guest operating system.  This is the caveat I was talking about earlier, and is the primary reason why some of you have quite possibly never seen this.   If you have the ICs installed and running, the mouse is running in integrated mode, and works flawlessly over TS.
• TS directly into the guest operating system.  If there are no ICs available for your chosen guest OS, you can use TS (or any other remote control application, really) to control the guest directly.  This assumes, of course, that the VM is exposed to the same network as the machine you’re controlling it from.
• Use the actual, physical console of the host machine.  If you take TS out of the picture, you won’t have this problem.
• Remote Administration tools for Hyper-V.  These aren’t available yet, but in our final release, we’ll provide a way for you to install the Hyper-V Manager tools on Windows Vista, so you won’t actually have to run them on a server.