Thursday, April 8, 2010

Creating a Windows 7 or Server 2008 R2 image for VM deployment

Creating a Windows 7 image for deployment to a virtual machine is not as straightforward as you might think. If you simply perform a standard installation, image that to a WIM with ImageX and then attempt to deploy that image, you will be left with a system that requires that the boot manager be recreated.

Just in case anyone is confused as to why the boot partition is there, it's so that you can use bitlocker to encrypt your system drive on the fly.  Bitlocker needs the unencrypted boot partition to work.

If you create a VM and insert your Windows 7 media and proceed to click Next through the entire installation wizard you will end up with a system that is actually installed on two partitions and not deployed back from WIM without requiring repair.

One tool that can be used is the Wim2Vhd tool. This is useful if you meet the client requirements and have a way to import the resulting VHD into a new VM. It performs the required repair for you.

However, I would like to avoid the situation of needing to perform the BCDBoot repair all together.

Say that you want to use ImageX (from the Windows Automated Installation Kit ) to image the Windows 7 installation to a WIM and then deploy that Windows 7 image to other virtual systems. I do not want to repair each and every time – I want to build the reference system in a way that this is not required.

The key is to prevent the default Windows 7 installation behavior of creating a System Reserved partition (which contains the necessary boot loader files) and a separate partition where the OS is installed (where there are no boot loader files).

Method One – pre-partition the virtual disk:

This is the most direct approach; in the end nothing looks unusual.

1. Create the VM from a template

2. Boot to WinPE (or mount the disk to another (helper) VM)

(An alternative to this is to boot using the installation media.  At the "Install Windows" screen (the first screen of the installer) type Shift+F10 to open a command prompt)

3. Run diskpart

a. List disk

b. Select the disk

c. Create a primary partition (you must use the entire volume)

d. Make the partition Active

e. Format the volume


f. Exit

4. Power off the VM ( or detach the virtual disk from the helper vm)

5. Attach the Windows 7 installation ISO

6. Boot to the ISO

7. Begin the installation wizard

8. Select a “Custom” installation

9. At the “Where do you want to install Windows” screen accept the volume that was previously formatted


10. Complete the wizard

11. Apply all installations and patches to your VM

12. Prepare your VM with sysprep

13. Boot the VM to WinPE

14. Create your VM image using ImageX.

Method Two – confuse the installation wizard:

I could not think of a better title for this, because really what you are doing is messing with the options allowed in the installation wizard until you get the behavior you want.

1. Create the VM from a template

2. Attach the Windows 7 installation ISO

3. Boot to the ISO

4. Begin the installation wizard

5. Select a “Custom” installation

6. At the “Where do you want to install Windows” screen

a. Select the virtual disk

b. Select “Drive options (advanced)”

c. Select “New”


d. The default should be the entire volume – Select “Apply”


e. Acknowledge the warning

f. Select and Delete Partition 2


g. Acknowledge the warning

h. Select and Extend the System Reserved partition


i. The default should be the entire volume – Select “Apply”


j. Acknowledge the warning

k. Select Next

7. Complete the wizard

8. Apply all installations and patches to your VM

9. Prepare your VM with sysprep

10. Boot the VM to WinPE

11. Create your VM image using ImageX.

The primary difference between the results of the two methods is:

· Method Two results in a deployed image where the C: volume name is “System Reserved”

Method One:

Method Two:



Tuesday, April 6, 2010

BOOTMGR is missing - Repairing a Windows 7 or 2008 R2 image after VM deployment

Deploying a Windows 7 image to a virtual machine is not as straightforward as you might think.
The primary issue resides in how the reference Windows 7 system is installed.
If you create a VM and insert your Windows 7 media and proceed to click Next through the entire installation wizard, you will have a working Windows 7 installation, that can be templated, it can be copied, you can do just about anything you like to it – as long as all copies involve the entire virtual disk.
Say that you want to use ImageX to image the Windows 7 installation and then deploy that Windows 7 image to other virtual systems.
If all that you did was click Next through the installation wizard or you did not customize your unattend.xml at all – you actually have a VM that has been installed with two volumes – a System Reserved volume and the volume where the actual system is installed.
The standard process is that you boot your system into the WinPE environment and you use ImageX /capture to create a WIM from a particular volume. Note the word “volume.” ImageX is a volume based tool, not a disk based tool.
The problem comes when we try to deploy this image. We boot into ImageX and /apply – then we reboot the virtual machine and we end up with the error: “BOOTMGR is missing”
The boot manager resides on the System Reserved volume, that is the extra partition that is created but was not captured by ImageX.
According to Microsoft TechNet documentation How to Perform Common Deployment Tasks with Virtual Hard Disks we need to use BCDBoot.exe to “configure the boot entry in the BCD store to be on the volume inside the VHD.” If you follow the link, the portion that we are concerned with is: “Prepare a VHD image to boot inside a virtual machine.”
To repair the VM where the image we need some type of recovery environment. We can get to a prompt to fix the applied image by any of the following ways: Boot to a WinPE 3.0 ISO, Boot to a Recovery Console using the OS installation media, attach the virtual disk to another known working Windows virtual machine.
For my example I have used the Windows Automated Installation Kit and created a WinPE 3 ISO. However, in testing I first simply attached the failing virtual disk to a working VM and performed the same commands. I also found references that booting into the Recovery Console of the installation media also works, but I did not test this. It is important to note that if you use WinPE the bit-ness of your WinPE image must match the bit-ness of the OS in the VM (32-bit to 32-bit / 64-bit to 64-bit).
The repair process:
1. Boot the virtual machine into WinPE (or attach the virtual disk to a running VM).

(An alternative to this is to boot using the installation media.  At the "Install Windows" screen (the first screen of the installer) type Shift+F10 to open a command prompt)

2. Discover the drive letter assigned to the virtual disk that is failing to boot.
3. Execute the following command (pay attention to use the correct drive letter – in my example “C:” is the letter that was assigned to the virtual disk, the WinPE system volume is “X:”).
C:\windows\system32\bcdboot C:\windows /s C:
4. Simply type “exit” to cause WinPE to shutdown and reboot into the VM. If the virtual disk was mounted in another VM, then power off the VM and detach the virtual disk before booting the imported VM.

Thursday, March 11, 2010

WireShark broke XP Mode

I know right now, that Ben Armstrong over at MSFT is reading this post and I have no idea what he is thinking to himself except I am sure that it is something along the line of - “no, it didn’t”  [but I made him look  ;-)  ]

And, technically, he is right, it really didn’t but the initial perception is that it did.

Okay, the background – XP Mode is the new Win7 feature which is actually the new VPC 7 (VirtualPC 7 – not VirtualPC 2007) with a pre-built Windows XP VM (that you have a legal license for as long as you run it in this intended way).

That means that there is a virtualization engine running on your system, one that interacts with your processor, one that takes RAM, and one that owns (PWNs - your networking stack.

And it is actually some interesting side behavior that caused me installing WireShark on Win7 to break the networking in my XP Mode VM.

When an XP Mode application is closed – it really isn’t.  When an XP Mode Desktop is closed – it really isn’t.  The XP Mode operating system is simply put into a paused / saved state by VPC – kind of like hibernation.

The side effect is that the OS in the XP Mode VM is rarely rebooted or cleanly shut down (as we all know that XP likes to be).  So if things change we are in the automatic thinking of reboot.  that takes a bit more.

Anyway, back to networking and desktop virtualization engines.

What happened is that in the act of installing WireShark – I moved the networking stack away from VPC7 – thus my XP Mode VM can no longer connect through the virtual networking layer that I had it configured to use.

Yes, I installed WireShark (it added WinPCap) and I used it and went along my merry way.  All was fine until the next morning.  I maximized my XP Mode application (which was running along happily in the background the entire time, during the installation of WireShark and all) and boom, it cannot connect to its back-end server.

Hmm, I open the full XP Mode desktop – IE cannot get out either.

Well darn, I know I need to reboot my Win7 machine (I really know that is what I have to do).  But, first I try the futile hope of shutting down and restarting the XP Mode VM.  Futile yes, and a waste of my time.  The result was as expected, not networking love for my XP Mode VM.

So, I try to logon to my XP Mode VM as the local administrator – hmm… no love, I try a second time - I get an error that the system is busy with an existing Terminal Server session.  Okay, I bet it is tearing down my previous logon attempt and resetting the listener in the VM.

But, I can’t log in to the silly VM to shut it down and I need it powered off.

Time to “Disable Integration Features” – Now, I can logon as the local administrator of the XP Mode VM.

…time passes…  That was NOT fun.  I had to attempt to logon to the XP Mode VM multiple (4) times, each time I did the VM went straight into the mode of installing updates and shutting down.

Mind you, I have been working on PowerShell and WSMAN for the past few weeks.  I have all kinds of IE Tabs and windows open, documents, PowerShell Plus, etc.  I really don’t want to reboot – but I run Visual Studio in my XP Mode VM (I hate all the baggage that Visual Studio installs in my client – not good for testing).

In the end, yes the reboot of the entire system solved the problem.

The moral of the story – If you have a virtualization engine and you mess with the networking stack, plan to reboot, you will be broken until you do.

Tuesday, March 9, 2010

Just because you can - should you?

This is a question that all administrators must ask themselves at any point in time.

I have know quite a few very creative IT folks in my time, and we can all come up with very clever ideas, combinations, and adaptations of technologies.

Part of my role is to question why.  It is actually part of my job.

I frequently come across things I read by folks and I just think to myself, why the heck would you do _that_?  Just because you can? 

When I worked as an administrator I quickly learned the user dictum:  “Because they can, they will”

Yes, this is generally said in a demeaning way, referring to users, when administrators talk to each other, to their managers, or to folks that write software.

I still say this over and over to the developers I work with.  Generally framed with a statement like:  “If you don’t want them to do that..” or “Of course I entered 300 characters into that field” or “there was no error checking to stop me”.

Think about that as you apply technology or attempt to break technology.  It is all about the intent.

Are you intending to break it?  Do you just not know any better / or not understand it?

If you don’t understand it, then read and ask questions.

As a person who tests software – I absolutely say, yes do it.  But do it in a controlled and smart way.  Pay attention to the entire environment, not just the buttons you are clicking on.

It is usually the greater environment where the real bug exists.