Update 19th June 2014: The tool is now available at http://gallery.technet.microsoft.com/Hyper-V-Network-VSP-Bind-cf937850

Cheers,
John.

The final part (at least for now, I’m hoping a guest author will write part 11) of this series on generation 2 virtual machines in Hyper-V re-visits conversion of a generation 1 virtual machine to a generation 2 virtual machine. Part 8 walked through the manual process, assuming it is possible. However, there is an easier way with a PowerShell script I wrote and recently released. Called Convert-VMGeneration.ps1, it can be downloaded from http://code.msdn.microsoft.com/ConvertVMGeneration. The script is intended to make life as simple as possible, reducing as many as reasonably possible manual post-migration fix-ups that may be required.

Convert-VMGeneration.ps1 is self-documenting – after downloading to a local drive, running get-help .\Convert-VMGeneration.ps1 –full will give you everything you need to know on how to use. I will assume that you have read part 8 of this series before use so you understand the three phases of conversion – capture, apply and clone.

A few tips worth mentioning:

• Run reagentc /disable in the guest operating system prior to shutting down and converting (if reagentc /info indicates it is enabled). After conversion, in the generation 2 virtual machine, run reagentc /enable. This makes life a lot easier in terms of the Windows Recovery Environment and (lack of) manual intervention.
• I strongly recommend you use the –Path parameter. Alternately, after a VM has been created, move the VM and its related storage to the right path using Hyper-V Manager. Note that if you subsequently perform a storage move, data-disks which were in use by the generation 1 virtual machine will no longer be valid from its perspective.
• For the first few times of use, you might want to specify the name of the temporary .WIM file using the –WIM parameter, combined with –KeepWIM. That’ll save some time if a failure occurs during the apply or clone phases as you’ll not need to redo the potentially time-consuming capture phase. Using the -WIM parameter also makes it easier if you are running short of disk space and want to use an alternate location.
• Be aware that you may not be able to start both the generation 1 and generation 2 virtual machines simultaneously (for example if they share a data VHDX). In reality, you really don’t want both machines on the network at the same time anyway. Be cautious of other implications too such as domain joined machine account passwords changing and so on.
• Perform a move of the VM and all its data to another path after migration and you’ve verified the functionality of the converted generation 2 virtual machine. This will make it much cleaner to delete the old generation 1 virtual machine and clean up any old files which may be lingering.
• The conversion performs a highly destructive step which completely wipes a disk. If everything is to plan, it’s the blank VHDX used as the boot disk for the generation 2 virtual machine. However, things could go wrong. For that reason, I strongly recommend you heed the warning (which cannot be suppressed) and make appropriate verifications. Should data loss occur for reasons such as coding error, no liability is assumed. If in doubt, export the generation 1 virtual machine, and import it onto a scratch box. Then do the conversion. That way, you are assured you will not lose anything important IF there is a bug.
• Similar to HVRemote which some of you may have used, this script is not supported or endorsed by Microsoft Corporation.
• Don’t close the PowerShell window while a conversion is in progress. Due to a bug in Windows, you may leave your system in a state whereby a drive letter is ‘leaked’ – it will be visible in Windows File Explorer, but unusable until the system is restarted. To cancel the script while it is progress, use Control-C and wait for it to clean-up instead.

Here’s an example of the conversion of a Windows Server 2012 virtual machine. The original virtual machine is highly available. The resulting generation 2 virtual machine will need to be made highly available after migration has completed.

Here’s an example where there are some (potential) issues to resolve. One is that there is an additional data partition on the boot disk for the source VM. Windows Recovery Environment was left enabled during the migration and will not operate correctly in the generation 2 virtual machine. Lastly, the original source boot disk was a differencing disk. Appropriate fix-ups may be required to mirror the configuration on the generation 2 virtual machine.

There are some VM configurations which aren’t handled, and the script will block the conversion:

• The VM is running. The reason is simply that you cannot reasonably expect an operating system to continue running correctly if the firmware is fundamentally changed from under it.
• Checkpoints (snapshots) are in use by the generation 1 virtual machine. The reasons partly relate to the above statement – an online checkpoint is equivalent to a running VM. While offline checkpoints could be converted in theory, there are further problems:
• The mount-diskimage cmdlet that the script uses under the covers does not support .AVHDX files which are used by checkpoints. Further, the time to do the conversion would be prohibitive – each checkpoint would have to done individually.
• Rebuilding the checkpoint tree with parent/child would be pretty much impossible – at best an individual offline checkpoint could be converted to a ‘standalone’ generation 2 virtual machine.
• Hyper-V replica is enabled. The reason was simply my time to validate this scenario. In theory it should work. Obviously replica would need to be re-enabled after the conversion. The workaround is to disable replica prior to conversion, or use the “-IgnoreReplicaCheck” parameter.
• When a guest cluster is configured in the generation 1 virtual machine using a shared VHDX. A highly available/clustered VM from the parent partition perspective works fine though. I am somewhat doubtful a guest cluster would come across cleanly, and have done no validation. The script hard blocks if any VHDX in the generation 1 virtual machine is shared.

I hope you find Convert-VMGeneration.ps1 useful. I’ll try to fix any bugs you report as time permits! A note for PowerShell aficionados reading the code – I make no apologies for my lack of PowerShell skills. This was the first time I’ve undertaken writing anything of reasonable complexity in PS. I’m sure there are many ways to make the code more powershellesque in efficiency.

So with that, I’ve reached the end of the planned parts of this series on generation 2 virtual machines in Hyper-V in Windows 8.1 and Windows Server 2012 R2. I hope you enjoyed them and found them and the conversion utility useful. As always, comments, questions and feedback are welcome.

Cheers,
John.

Cheers,
John.

This part of the series on generation 2 virtual machines in Hyper-V talks booting from CD/DVD. It’s not specific to Hyper-V, it’s more about PCAT and EFI, and the way in which Windows installation media is built.

Try the following – create a new generation 1 and generation 2 VMs with blank VHDXs, setting them both to boot from Windows 8 64-bit .ISO media, and start them.

Here’s what you’ll see in a generation 1 virtual machine (or PCAT physical system)

And here’s what you’ll see in a generation 2 virtual machine (or EFI physical system)

Before anyone comments, yes, we’re acutely aware that the generation 2 EFI boot loader messages persist on the screen and it can be a little confusing. Essentially what the generation 2 virtual machine did was:

• Attempt to boot from the CD SCSI device containing the Windows 8 ISO. This is where the ‘Press any key…’ message came from. As no key was pressed, we went to the next boot entry. (And this is where we didn’t clear the message from the EFI CD boot loader)
• I didn’t press F12 (in fact, this VM wasn’t connected to a network), so network boot failed
• The SCSI VHDX is raw with no partitioning or file system, so this too failed

So why did the generation 1 virtual machine start setup from the Windows media? The answer is simply that it’s the way Windows media is built, and it’s inconsistent between the PCAT and EFI loaders.

However, it’s relatively simple to solve if you want to avoid the press any key message. In fact, we almost have all the pieces from previous parts. In particular, part 4 where we injected keyboard drivers into the Windows 8 media.

If you loopback mount Windows 8 or 8.1 RTM media, and navigate to the \efi\microsoft\boot directory, you will see there are two versions of cdboot.efi

The default version, cdboot.efi prompts for a keypress. The unused version, cdboot_noprompt.efi doesn’t prompt.

So it’s fairly simple to create modified media which uses the noprompt version. First, copy the contents of the ISO to a working directory, rename cdboot.efi to cdboot_prompt.efi, and rename cdboot_noprompt.efi to cdboot.efi.

Do the same with efisys.bin and efisys_prompt.bin

Then re-use our oscdimg command (in an elevated deployment and imaging tools environment) from part 4 to recreate the media.

Simply attach this modified media to the generation 2 VM and restart it (and don’t press any keys, not that you will be prompted…)

The surprise awaits! It’s worth it – stay tuned for part 10.

Cheers,
John.

Forewarning, this is a very long article!

This part of the series on generation 2 virtual machines in Hyper-V talks about migration. Not “Live Migration”. Nor “Storage Migration”. Specifically it answers the question “Can I change the generation of a virtual machine, or migrate my existing guest operating system in a generation 1 virtual machine to generation 2?”

Let me answer it the short way first. No. There is no way in Hyper-V to change the generation of a virtual machine. Neither is there a means to migrate a generation 1 virtual machine to a generation 2 virtual machine. I could end the post there, but I guess my forewarning would have been a little premature…!

For those of you thinking – well what if I export a generation 1 virtual machine and import it as a generation 2 virtual machine after tweaking the export contents. My initial response would be that this is absolutely unsupported and does not work due to firmware differences among other things. Followed by a “good luck to you… taking the re-installation and application migration route may be quicker”

However, there is a longer answer which is supported in certain circumstances, due to the use of standard inbox tools and capabilities for deployment. Let’s rule out first what definitely cannot be migrated. The obvious categories are any virtual machine running a 32-bit guest operating system; any virtual machine not running Windows (although there may be other solutions I’m not aware of); any virtual machine running a version of Windows prior to Windows 8/Windows Server 2012.

So let’s drill in and do an example walkthrough of migrating a Windows 8 64-bit client guest operating system. I want to stress up front, the tools used here are absolutely NOT my area of expertise, so answers to any questions you might have will be few and far between. Also, it’s pretty in-depth and not for the feint-hearted to try.

For this example, I just used the defaults during the new virtual machine wizard, except increasing the memory to 1GB, to end up with a generation 1 virtual machine with one IDE attached boot disk, and a Windows 8 installation ISO inserted into an IDE attached DVD drive. No network is connected to the virtual machine, and no further storage is attached to a SCSI controller.

Here’s our unhappy VM who yearns to be a trendier generation. Let’s make him smile by migrating him to a generation 2 virtual machine. I want to emphasise also that the process I’m following below may NOT be perfect. In the screenshot, I have opened regedit to show that this is 64-bit Windows 8, and msinfo32 showing the BIOS mode is Legacy. The only other change to the VM from a default installation is the desktop background image.

Here’s the settings for this VM

And here’s the disk partition layout. Notice it’s a typical MBR style layout

At a high level, the steps I’m going to follow are:

• Disable the recovery environment
• Make a copy of the Windows image as installed
• Create a new VHDX
• Partition it in GPT format and make it bootable
• Put the copy of Windows we previously made onto the new disk
• Create a new generation 2 virtual machine and attach the new VHDX
• Fix up the recovery environment

Besides a couple of minor gotchas, none of the above is rocket science. However, what I’m going to entirely ignore are considerations such as:

• The source VM using a VHD (this should ‘just work’ actually following the same process, but changing VHDX to VHD where I refer to the source disk)
• The source VM being multi-boot
• The source VHDX having ‘unusual’ partitioning
• Data or other utility partitions, including the optional recovery partition containing a ‘restore’ WIM, on the source VHDX
• Any additional storage such as Fibre Channel or SCSI attached disks.
• Making the new VM mirror the source VM in regard to configuration, particularly advanced configuration such as networking. But to be honest, pretty much everything under this category is not covered in this post.
• Any form of disk encryption
• Shared VHDX or guest clustering
• Implications of replica
• Implications of checkpoints (snapshots)

The first thing I’m going to do is to disable the recovery environment on the source machine while it is running, by running the following command from an elevated command prompt (note DON’T do this on the parent partition, it’s inside the VM!):

reagentc /info

If the output indicates the Windows recovery environment (WinRE) is enabled, disable it.

reagentc /disable

The reasons for disabling it are due to tight coupling between BCD and the recovery environment configuration. It’s just much simpler to migrate the virtual machine when it is not configured. We will re-enable it once the virtual machine has been migrated.

Next, I’m going to cleanly shutdown the generation 1 virtual machine (I really hope you don’t need instructions for that….), and loopback mount its VHDX.

From an elevated PowerShell prompt where the VHDX resides, run:

mount-vhd –readonly .\migrateme.vhdx

At this point you could do some fancy PowerShell to find out what drive letter has popped up on your local machine as the Windows installation for the generation 1 virtual machine. In my case, I just used Explorer and can see it’s drive H:. The system partition was also given a drive letter, G:. If no drive letters are present, it could be policy on the parent partition, but you can use diskpart or diskmgmt.msc to assign letters and/or online the disk.

We’re going to use dism to capture the image. Note that you can use regular inbox dism for this, it doesn’t need to be the version of dism from the ADK which I used in a previous part of this series. From an elevated prompt, run the following replacing H: with the appropriate drive letter for the Windows Installation.

dism /capture-image /imagefile:captured.wim /name:”Captured” /capturedir=”H:\”

The next job is to create a new VHDX which we will partition in a format suitable for use by a generation 2 virtual machine (note that MBR is required for generation 1, GPT is strongly recommended for generation 2). I am going to use GPT, as should you.

This gets a little tricky for sizing purposes, especially when your source disk is almost full. From the disk partition layout above, the source VHDX is 127GB, and during operating system installation, Windows created a 350MB System Reserved partition.

In a typical GPT layout, you’d have a 300MB recovery environment tools partition, a 100MB ESP, a 128MB Microsoft reserved partition, and the remainder for the system. There may be other utility partitions such as for push button reset as found on an OEM type of installation. This means that the OS partition size is slightly smaller than on an MBR same size disk using the Windows defaults. http://technet.microsoft.com/en-us/library/hh824839.aspx has a lot more information on this.

For this exercise, I’m going to assume there is ample space on the source image. To make this even more apparent, I’m going to create the new VHDX as a 30GB disk. I’m also going loopback mount it, find the disk number it’s mounted at, and get a few free drive letters I can work with. You should of course do appropriate sizing! From the elevated PowerShell prompt, run the following:

# Create a new VHDX
New-VHD .\migrated.vhdx –dynamic –size 30gb

# Mount the new VHDX
Mount-DiskImage c:\working\migrated.vhdx

# And find the mounted VHDX
$Target = Get-DiskImage c:\working\migrated.vhdx

# And find the disk number of the mounted VHDX on the parent partition
($Target | Get-Disk).Number

# And get some available drive letters
ls function:[d-z]: -n | ?{ !(test-path $_) } | select -last 3

From the output of the above commands, in my case the drive number is 2, and the three drive letters are X:, Y: and Z:. (Note you can just use explorer to get spare drive letters, and there’s a few ways of finding the drive number of the new VHDX.)

Now it’s time to create a diskpart script to partition the new VHDX. It is REALLY IMPORTANT to make sure you insert the right disk number, otherwise you risk losing all data on another disk on your system. For that reason, I’m not even going to put a number in the script below in case someone comes along and runs it. Here’s my script using drive letters X:, Y: and Z:. Save it as dp.txt

select disk INSERT_YOUR_DISK_NUMBER_HERE
clean
convert gpt

create partition primary size=300
format quick fs=ntfs label="Windows RE tools"
assign letter=X
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001

create partition efi size=100
format quick fs=fat32 label=System
assign letter=Y
create partition msr size=128
create partition primary
format quick fs=ntfs label=Windows
assign letter=Z

list part

I expressly have not created a recovery image partition here. Please see the recommended configuration here: http://technet.microsoft.com/en-us/library/hh825686.aspx.

Next, partition your disk (again heed warning about the potential for data loss) by running the following from an elevated command prompt:

diskpart /s dp.txt

If all is good, you should see output similar to the following from the command prompt, and the drive letters showing up in Windows File Explorer.

At this point, we’re going to put or ‘apply’ the captured image from the source VHDX into the Windows partition on the new VHDX, drive letter Z: in my walkthrough. Run the following from an elevated command prompt:

dism /apply-image /imagefile:captured.wim /applydir:z:\ /index:1

This will take some time depending on the size of the capture image and your storage subsystem performance.

Now we need to configure the ESP (EFI System Partition) on the target VHDX. Run the following from an elevated command prompt, where Z: is the target Windows partition and Y: is the target ESP. To be safe, it would be prudent to running bcdboot from the source operating system, not the one on the parent partition, just in case of incompatibilities.

Z:\Windows\System32\bcdboot Z:\Windows /s Y: /f UEFI

At this point, let’s do a quick recap of where we are. We have

• Created a new VHDX
• Made it GPT and partitioned it.
• Put a copy of the original Windows installation onto it
• Created/configured a new BCD store to make the new Windows installation boot

A couple more things to do before we can see if the new VHDX actually works in a generation 2 VM. First we need to perform a workaround for a bug in Windows to avoid the drive letter for the ESP on the new VHDX persisting after an unmount. (If you don’t do this, the drive letter will persist and you’ll have to reboot your parent partition to get rid of it). Then we can unmount it. From an elevated PowerShell prompt run the following. Change NNNN to refer to the disk number of the new VHDX. PartitionNumber is 3 as that is where the ESP is based on our diskpart script from earlier. Y is the temporary drive letter (again in the diskpart script) we used for the ESP.

Remove-PartitionAccessPath –DiskNumber NNNN –PartitionNumber 3 –AccessPath Y:\
Dismount-DiskImage c:\working\migated.vhdx

Some of you may be asking why I even assigned a drive letter X: above as I didn’t touch the recovery partition. It’s more for completeness, and when I was also playing around with the recovery environment. You don’t need that drive letter to follow along.

As we no longer need from the source VHDX, we can dismount it by running the following from our elevated PowerShell prompt:

dismount-vhd .\migrateme.vhdx

Now we’ll create a new generation 2 VM using a similar configuration to the source VM, but attaching our migrated VHDX. I won’t walk you through that (as you all know how to do it…), but here it is:

Let’s fire it up and see what happens!

…The good news is that it boots.
…You see the spinny dots under the Hyper-V UEFI firmware logo
…The screen goes blank
…More spinny dots
…”Getting devices ready”

(Can you feel the tension building? J)

…”Getting ready”
…”Hi”
…“While we’re getting things ready”
…“Check out the new way to use Windows”
…”After your PC is Ready”

and so on until

SUCCESS!!! We can see the desktop background is from our original virtual machine. Let’s take a look in Windows Explorer and diskmgmt.msc to see:

We have had the nice side effect of having resized our Windows partition as well. Unfortunately Disk Management doesn’t show all partitions, so let’s open diskpart from an elevated command prompt to take a closer look.

Remember that the above process did not create a recovery partition for PBR. You should adjust the procedures above following ADK guidance if that is how you need the target virtual machine configured.

Remember also that we didn’t enable the recovery tools. We can see that it is configured by attempting to boot into RE.

Re-enabling is fairly straightforward. Here we enable RE, show it’s enabled and set the system to boot next time to RE.

reagentc /enable
reagentc /info
reagentc /boottore

And a reboot shows that the recovery environment is working.

What remains at this point is for you to mirror the virtual machine configuration such as advanced networking, processors, storage and so on from the source generation 1 virtual machine to the target generation 2 virtual machine.

So that’s it. Although somewhat involved, that is what it takes to convert a workload from generation 1 to generation 2. You may, of course, decide that a clean installation may be simpler.

The last thing I wanted to touch on was the inevitable question that some of you will no-doubt ask when manually walking through these steps on your own VM. The one of “I forgot to disable RE before migration – how do I fix it up?”. Below are my rough notes more than anything else, especially as sources of information on this are a little thin on the ground that I could find. But hopefully it will give you some good pointers on what to look. It certainly is possible to re-create the right entries manually. I’ve done it, but this isn’t a walkthrough as such. There is some tight coupling between the RE configuration held on the file-system and in BCD. Note that this method is UNSUPPORTED – the supported way is to go back to the start, run reagent /disable before starting the migration, and /enable once the migration is complete.

The first thing to know is when RE is configured, winre.wim is moved to the recovery tools partition. As we didn’t migrate that, it won’t be present in the Windows partition on the target. You can grab that from the source VHDX loopback mounted. It will be present under \Recovery\{GUID} or \Recovery\WindowsRE, generally in the system partition of a PCAT system. It will be in a hidden directory, and may be marked as a system file. Further, the partition is hidden so you will need to assign a drive letter. Let’s assume you have the source VHDX in my example loopback mounted to drives H: and I: this time (it was G: and H: during the earlier part of this walkthrough). The Windows installation is on drive I:, the System Reserved partition is on drive H:

Here’s how you would backtrack from a mounted VHDX of a generation 1 virtual machine which still has RE enabled. From the output of reagentc, you can determine the status (enabled), the location, and the BCD GUID.

From the location, we can use diskpart (even though we happen to already know it’s on drive H: ) to find the drive letter where the WinRE WIM file will be located.

And if we examine the H: drive, we can see WinRE.WIM is present, just in a hidden folder.

So that’s where you would grab winre.wim from. Put a copy (removing the system and hidden attribute using attrib –s –h) in \windows\system32\recovery on the new windows installation.

For completeness, go back to the screenshot of reagentc output which also lists the GUID for the BCD entry which we can examine using bcdedit pointing to the BCD database. There is an OSLoader entry present, which you can see is for PCAT due to the use of winload.exe, not winload.efi:

And if you look carefully where I’ve circled, the entry refers to another GUID. By default the first 8 digits are +1 in hex, so here you see the 8^th digit “F” for the GUID entry with the 8^th digit “E”. (This isn’t a requirement if you were to manually rebuild the BCD entries)

If you look at that other device entry, you can see it’s a ramdisk device.

And finally, the other piece of the puzzle is in the UTF-8 encoded file \windows\system32\recovery\reagent.xml.

I’ve circled a few things. One is the path to WinRE.wim. Next is some ID starting 313 which I’ll come to in a second. Offset is a partition byte offset, and if you go back to the diskpart screenshot above, you can see it’s where the recovery tools partition starts on the disk. And also the InstallState indicating it is on. What’s that ID? And why does WinreLocation have a null GUID in it? The answer is simple, it’s the disk ID of the disk on an MBR disk. On a GPT disk, the ID would be zero, and the GUID populated instead. (You can find disk IDs from diskpart, select disk n, detail disk.)

So now we know what we need to fix up in the migrated VHDX. Unfortunately reagentc is a little “temperamental” and needs a little coaxing (in other words, it tends to just fail without much information as to why). What you could do is manually recreate each of the BCD entries by hand, and recraft reagent.xml in notepad carefully to match. That (trust me having walked through it) is painful.

Bearing in mind that the new VHDX will not have any recovery BCD entries (OSLoader or Device), we will let reagentc do the work for us instead. We’ll do this inside the migrated VM. Keep a copy of reagent.xml, just in case, then with notepad (it’s not that friendly though as you will see), carefully edit reagent.xml to change the three circled values to look like the following:

Now you can simply use reagentc to enable WinRE (make sure you did copy winre.wim to the \windows\system32\recovery folder first). I’ll follow the same path to follow through what changes have been made. Reagent.xml now has a populated WinreBCD and WinreLocation, and InstallState is 1.

From the output above, confirming the GUID of the disk (starting daf2…) containing a hidden utility partition for recovery.

And the partition can be determine from the offset (135266304). I’m going to give the partition a drive letter temporarily (R:). You can remove this latter using the diskpart “remove” command.

Confirming the right files are in the \recovery\{GUID} path

And now examining the BCD store entries.

Notice again the “+1”, and that the path is to an EFI application for the loader.

So that’s pretty much how to convert from a generation 1 to a generation 2 virtual machine in circumstances where it is possible. For a much easier option, you might want to wait just a little longer :)  In the next part, part 9, I’ll talk about booting from ISO media.

Cheers,
John.

This part of the series on generation 2 virtual machines provides answers to general questions. Most, I provided to our writers a little while ago, and have since worked their way into official documentation at http://technet.microsoft.com/en-us/library/dn282285.aspx. Technet documentation can sometimes deliberately be a little sparse, so I’ve augmented some of the answers where appropriate. Some of these Q&As have already been mentioned in previous parts, but it makes sense to keep them all in one spot.

These are in no particular order.

Q: How can I do kernel debugging of a generation 2 virtual machine?

A: See part five for a detailed answer.

Q: During installation of Windows 8 64-bit or Windows Server 2012, the keyboard is not active

A: See part four for a detailed answer.

Q: Is RemoteFX supported by generation 2 virtual machines?

A: No. The reason is that there is a dependency on PCI in the RemoteFX stack. PCI is not present in generation 2 virtual machines, and it was not possible to remove this dependency in the timeframe and resources available for the Windows 8.1 release cycle.

Q: Why can’t I use a physical CD/DVD in a generation 2 virtual machine?

A: We dropped support for physical CD/DVD passthrough in generation 2 virtual machines as the majority of end users now use .ISO files, or build VMs from templates. Physical device support is also problematic in migration scenarios. The new SCSI DVD drive in generation 2 virtual machines supports features not supported by the IDE DVD drive such as hot-add remove, and is not limited to a maximum of four devices.

Q: Can I use .VHDs in a generation 2 virtual machine?

A: Without conversion, no. But see following Q&As also. VHDs are not supported in generation 2 virtual machines, only VHDX files are. You can convert an existing VHD used by a generation 1 virtual machine to a VHDX using the Convert-VHD cmdlet, and use that in certain scenarios in a generation 2 VM.

Q: Will a VHD converted to VHDX work in a generation 2 virtual machine?

A: If it is a data disk (ie not an OS bootable disk), then absolutely. If it is an OS bootable disk, then it can be used as a data disk but will not boot, even if the guest operating system is one which is supported by generation 2 virtual machines. A clean operating system installation is required in this scenario along with application migration.

Q: Can I attach a VHDX from a generation 2 virtual machine to a generation 1 virtual machine?

A: Absolutely. VHDX is just a disk container, so there is nothing stopping you attaching it as a data disk to a generation 1 virtual machine and using a different guest operating system to examine the contents. Of course, it requires that the guest operating system is aware of the file system in that VHDX.

Q: Can I perform a network installation in a generation 2 virtual machine using IPv6?

A: Absolutely. In an elevated PowerShell prompt, run Set-VMFirmware –VMName <Name of VM> -IPProtocolPreference IPv6. Note that this will change the protocol for ALL network adapters in the VM – you cannot for example have the VM attempt an IPv4 boot from the first network adapter, and IPv6 on the second network adapter.

Q: How can I programmatically determine the generation of a virtual machine?

A: See part one of this series for examples

Q: Can I still use a virtual floppy disk to contain an unattended install answer file in a generation 2 virtual machine?

A: No as floppy disk drive support is not present in generation 2 virtual machines. However, unattended installation supports alternate removable media including .ISO files which can be placed in a virtual DVD drive.

Q: Can I iSCSI boot a generation 2 virtual machine?

A: No, you can only boot from SCSI-attached disk, .ISO attached to a CD/DVD device, or from network

Q: Can I boot a generation 2 virtual machine from a virtual FC adapter?

A: No, you can only boot from SCSI-attached disk, .ISO attached to a CD/DVD device, or from network

Q: Can I use large VHDX files in generation 2 virtual machines.

A: Absolutely, all the way up to the limit of 64TB imposed by VHDX. Large VHDXs can be used as both boot and data disks.

Q: Can I “loopback mount” (ie expose in the parent partition) a VHDX used by a generation 2 virtual machine?

A: Absolutely. A VHDX is a file format and not tied to a specific virtual machine generation. As such, you can loopback mount a generation 2 virtual machines VHDX exactly the same as for a generation 1 virtual machine.

Q: Can I create a VHDX which can be used to boot both a generation 1 and 2 virtual machine?

A: Technically, this is possible. In fact, Windows to go in Windows 8 Enterprise used such a mechanism to craft a disk layout which works exactly in this way. However, there are limitations, not the least of which is that in the Hyper-V scenario, we have not tested this, neither is it supported. Some of the limitations include the inability to perform service pack installation or operating system upgrade. Additional side effects would be that duplicate BCD stores are required, and mirroring between them is not honoured. Hence some updates may be lost.

Q: Can I export a generation 2 virtual machine from a Windows 8.1/Windows Server 2012 R2 server, and import it into/start it on a machine running Windows 8 or Windows Server 2012 Hyper-V?

A: No, as generation 2 virtual machines are a new feature in Windows 8.1 & Windows Server 2012 R2.

Q: What is the dependency between UEFI in a generation 2 virtual machine and the physical platform firmware?

A: None. The firmware exposed in a Hyper-V virtual machine (mostly) has no correlation to the firmware on the physical platform. Hence there is no requirement for the physical server to have UEFI firmware or support Secure Boot to support both of these features in a generation 2 virtual machine.

Q: Do generation 2 virtual machines support Measured Boot?

A: No. But they support the closely related Secure Boot capability. Measured Boot has a dependency on a TPM (Trusted Platform Module) which is not present in a generation 2 (or generation 1 for that matter) virtual machine.

Q: Can I run <insert arbitrary UEFI application> in a generation 2 virtual machine?

A: Probably, although it is unsupported and untested. We don’t, for example, provide a UEFI shell or other applications which almost certainly would run in a generation 2 virtual machine, assuming that secure boot was disabled for that VM. The only “UEFI applications” (used loosely) we support in a generation 2 virtual machines are operating system loaders for supported operating systems.

Q: Where is Secure Boot setup mode for a generation 2 virtual machine?

A: We only support user mode. PK/KEK and the global db/dbx variables cannot be updated. See part six of this series for detailed information on Secure Boot.

Q: Where are NVRAM variables held?

A: On a physical UEFI platform, non-volatile memory is used to store variables. In Hyper-V, NVRAM variables are stored (for the most part, and part 6 has more information on Secure Boot variables) in the configuration file for the virtual machine. NVRAM variables include, but are not limited to, boot entries. Note this is quite different to generation 1 virtual machines.

Q: Can I use a passthrough (physical) disk in a generation 2 virtual machine?

A: Yes. However, we strongly recommend these are not used unless absolutely necessary. It is possible that passthrough disk support may be deprecated in a future release. In reality, the fixed VHDX file format has comparable I/O performance, so there really is little need for the use of a passthrough disk.

Q: What is the default generation of a new virtual machine?

A: The default generation is 1 so that we didn’t break backwards compatibility with existing scripts. In PowerShell, to create a generation 2 virtual machine, use “–Generation 2” as a parameter to New-VM.

Q: How can I change the generation of an existing virtual machine

A: This is not possible (at least inbox). Generally a clean install and application migration is required. This topic will be covered in a lot more detail in part eight.

Q: Is it possible to run both generation 1 and generation 2 virtual machines on the same server.

A: Absolutely. This is entirely possible and fully supported.

Q: Windows installation fails in a generation 2 virtual machine

A: Make sure your VM has the minimum amount of memory assigned according to the requirements of the operating system. (Unfortunately, creating a new virtual machine using the defaults in the new virtual machine wizard and the New-VM cmdlet is 512MB which is less than the required memory for Windows 8 and Windows 8.1 and their server counterparts.)

Q: Why don’t we support 64-bit Windows 7 or Windows Server 2008 R2 as a guest operating system in generation 2 virtual machines?

A: Certainly it is true that Windows 7 support UEFI, the first requirement for generation 2 virtual machines. However, Windows 7 has a hardware dependency on a Programmable Interrupt Controller (PIC) which is not present in generation 2 virtual machines. Even if Secure Boot is disabled, an attempt to install Windows 7 will result in an apparent hang at “Starting Windows” shortly after boot, consuming 100% VP utilisation. A similar effect to this will be seen if attempting a network install from a WDS server which has a Windows 7 era boot PE image – network boot will appear to hang as well. For that reason (along with the keyboard issue in Windows 8 PE) I strongly recommend any WDS server are upgraded to the Windows 8.1 PE boot image.

Q: When is Linux going to be supported in a generation 2 virtual machine

A: Linux support is being worked on as of writing. Currently, 64-bit versions of Windows 8 and 8.1, or Windows Server 2012 and Windows Server 2012 R2 are supported guest operating systems.

Q: I can install Windows 8 and 8.1 32-bit on my OEM UEFI computer. Why doesn’t it install in a generation 2 virtual machine?

A: See part one of this series. Our UEFI implementation is “Class 3” and does not have a Compatibility Support Module. In Hyper-V, 32-bit guest operating systems are only supported in generation 1 virtual machines.

Q: How many network adapters can a generation 2 virtual machine have?

A: Eight. Generation 2 virtual machines do not support legacy network adapters. (Note in generation 1 virtual machines, legacy network adapters are only recommended for use during network installation of the guest operating system)

Q: Will application “A” run the same in a generation 2 virtual machine as it does in a generation 1 virtual machine?

A: Yes. From a generic application perspective, there is no difference between VM generation. It’s no different to asking if the application will run the same on both an EFI and BIOS based physical machine.

Q: I use virtual switch extension “X” from vendor “Y”. Will it still work with generation 2 virtual machines?

A: Yes, switch extensions are entirely on the parent partition side. Switch extensions are agnostic of, and orthogonal to the virtual machine generation.

Q: How many SCSI storage devices can I attach to a generation 2 virtual machine?

A: A generation 2 virtual machine can have up to 4 SCSI controllers, each with 64 devices attached. Hence the maximum is 256. Note that this can be made up of any combination of VHDX, passthrough disk (see caveat in previous Q&As) or CD/DVD. Generation 2 virtual machines are not limited to four CD/DVD devices in the same way that generation 1 virtual machines are.

Q: Why doesn’t a newly created generation 2 VM boot from a Windows ISO automatically when a generation 1 VM did?

A: See part nine of this series. Sorry to keep you in suspense ;)

Q: What about performance comparisons between generation 1 and generation 2 virtual machines?

A: First the official answer. “Do not expect any performance differences between generation 1 and 2 virtual machines.” And this is certainly true at run-time when a guest workload is doing what it does, for both server and client operating systems. However, and explicitly NOT quoting numbers as they are not relevant, you may see increased performance in two areas.

1. During guest operating system boot. There are a couple of reasons for this. One is that our UEFI firmware initialises faster than our PCAT BIOS. Also in a generation 1 virtual machine, during the initial part operating system start, while the storage fast-path filter is not loaded in the guest, I/O is using emulation which has more overhead. Generation 2 virtual machines always use VMBus for I/O.
2. During guest operating system installation from ISO or network. For the same reasons as above, there is no emulation required.

Q: I’ve developed a WMI or PowerShell script using documented Hyper-V APIs. Will it work with generation 2 virtual machines?

A: Possibly! However, the modifications needed should be minor if they don’t work. The main areas where scripts may need modification:

• Take account of New-VM with the generation parameter and the corresponding attribute on Get-VM; In WMI it’s the VirtualSystemSubType field in the Msvm_VirtualSystemSettingData class you need to be aware of. See part one for more information.
• Anywhere you use Set-VMBios needs replacing with appropriate calls to Set-VMFirmware;
• Any references to legacy NIC will fail. Use a software based network adapter instead.
• References to IDE based storage will fail (eg Get-VMHardDiskDrive). Use the SCSI equivalent instead.

Q: What generation should I choose when creating a new virtual machine?

A: Well really this depends on too many things to be prescriptive. There is no single right answer and my answer below should be taken as non-exhaustive examples of thoughts you should have when making the choice.

In this answer, I’m constraining myself to just Hyper-V functionality. This means I will not be considering any higher level management layers, integration, processes, template/library, third party applications support (backup for example – does it support EFI systems?), public cloud, or any other IT infrastructure you may have in place. Nor am I considering heterogeneous virtualization environments, whether that means interoperability/interchange with previous versions of Hyper-V or any other virtualization platform. You should however NOT ignore any of these, or other potentially relevant consideration!

• Obviously, the guest operating system and architecture must be supported by generation 2 VMs.
• Consider the improvements to generation 2 VMs and see if you answer yes to any of these example questions: Is Secure Boot important to you? Is a reduced attack surface important to you? Are the performance characteristics mentioned above important to you? Do you require IPv6 network installation? Am I likely to need to expand the boot disk of a VM at run time?
• Consider the longer term direction Microsoft is going to move to (given we are more likely to invest in newer capabilities that are generation 2 specific in future releases). Does it make sense to embrace generation 2 VMs now knowing they will be with us for a long while to come?
• Consider the Hyper-V features you use. Unless the VM requires RemoteFX, everything you can do in a generation 1 VM, you can also do in a generation 2 VM.
• After that, it comes down to a case of the end-user scenario. I’ll give two broad examples – a generic server and a generic client role.
• Server: Windows Server 2008 was the last shipped version of Windows Server available in 32-bit. However, given Windows Server 2008 is not supported in generation 2 VMs, to all intents and purposes, for Windows Server, this means you are deploying a 64-bit operating system. There is little reason not to deploy Windows Server 2012 or 2012 R2 as a generation 2 VM with one exception. That being the case of replica to Windows Azure as generation 2 VMs are not currently supported by Windows Azure.
• Client: From a memory perspective, 64-bit operating systems tend to use more memory than their 32-bit counterparts. Hence your overall memory footprint may be more using generation 2 virtual machines. However, please remember the many advantages in 64-bit Windows which may well outweigh the additional memory requirements.

Q: OK, so I’ll move to generation 2. But am I going to have to go through the same in a future release with generation 3?

A: Well anything is possible, and as you know, I can’t talk about anything we haven’t released. However, the reason for generation 2 was to build a platform for the future, so they will be with us for a long while yet. As the underlying firmware is so different between generation 1 and generation 2, realistically it’s unlikely we would introduce a generation 3 unless there’s a UEFI replacement round the corner, or there’s some truly fundamental other hardware change we need to do to the virtual machine container. It’s reasonably safe to say moving to generation 2 will get you to the point where newer Hyper-V features in future releases are more likely to light up in generation 2 virtual machines, and less likely to be enabled for generation 1 virtual machines.

The next topic in this series is a big one. Start your coffee brewing now. It’s all about manually converting a generation 1 virtual machine to generation 2.

Cheers,
John.

This part of the series on generation 2 virtual machines in Hyper-V looks at a new feature – Secure Boot. Secure Boot is essentially a signature checking mechanism during the OS loader to validate that only approved components are allowed to be run. Secure Boot is defined as part of the UEFI specification. Hyper-V implements a subset which allows Windows 8 and Windows 8.1 with default policies to load in a virtual machine with Secure Boot enabled.

While I’m not going into huge detail about how Secure Boot works, it essentially comes down to the contents of four NVRAM variables, some of which are read-only, other read/write. (There are a few other variables in NVRAM too.) The four variables of relevance are:

PK

The public platform key. This contains the public half of the platform key pair, PK_pub, which allows the platform “owner” (think of this as the OEM, or in the Hyper-V case, Microsoft), who has the private half of the key, PK_priv. to change platform ownership or enroll a Key Exchange Key. In the physical world, the OEM will keep PK_priv private. This is no different in our implementation - the key pair was generated/signed by the Microsoft corporate PKI infrastructure and the private key secured appropriately.

KEK

The Key Exchange Key signature database. The keys in this database establish a trust relationship between the operating system and the platform firmware. In other words, if the operating system attempts to update the authenticated variables db or dbx using a SetVariable() call, the call must have a root of trust back to a certificate held in KEK. In the Hyper-V case, we have a single certificate in this database which allows updates from Windows Update to safely update db and dbx.

db

db is a essentially an allow list for operating system loaders. Any operating system which starts when secure boot is enabled must have a root of trust to a key in this database. In the RTM version of Windows 8.1, a single key is in this database which allows ‘PRSS’-signed builds of Windows 8 and Windows 8.1 to load. Don’t worry about the term PRSS. That’s an internal Microsoft term. Just suffice it to say that the builds of Windows which go out to customers are signed this way. Internal daily builds and milestone exit builds (such as Windows 8.1 Preview) are not signed the same.

dbx

dbx is the converse of db and is a disallow list. In the RTM version of Windows 8.1, no keys are in this database.

While a virtualization platform such as Hyper-V could model itself entirely on a physical platform for features, we don’t entirely for UEFI or secure boot. And with good reason. For example, we don’t support capsule updates (which don’t make sense as the firmware update can be done from the parent partition by updating the worker process). We don’t support authenticated variables outside of the secure boot namespace. We only support specific authenticated variables in the secure boot namespace. We don’t support time based authenticated variables. And potentially the one of most interest – we don’t support setup mode. Strictly, these also means we don’t have a fully compliant UEFI implementation.

So what is setup mode and why should you care? On a physical box, if no PK is enrolled, the system is said to be in setup mode. In this mode, no authentication is required to modify PK or KEK. Once the PK is enrolled, the firmware switches to user mode. (The actual mode is indicated by another UEFI variable, SetupMode.) By having setup mode, it allows the end user (or OEM) to specify exactly what operating systems can and cannot run when Secure Boot is enabled by pre-populating db/dbx, and (assuming those operating systems are signed appropriately) allow those operating systems to perform secure updates to db/dbx if there is a root of trust in the update chained to a key in KEK.

In Hyper-V, the firmware for a virtual machine is always in user mode. PK and KEK are pre-populated and cannot be changed. db and dbx are also prepopulated, but can be changed. In fact, db and dbx are a little more interesting in the Hyper-V case as this is where it differs somewhat from a physical platform.

On a physical platform, there is a single db and dbx. This is true also in Hyper-V from the perspective of a UEFI application, such as an operating system, running in a VM. However, from the perspective of the parent partition, there are actually two instances of db and dbx.

The first instance is global, non-transient and applies to all VMs. When a VM is powered on, regardless of any subsequent updates it might have securely made to db/dbx, the global contents are always present. The second instance is VM-local and transient. In reality, the local copies of db and dbx are held in the configuration file for the VM (as are other NVRAM variables such as those to define boot order and entries). What is actually projected into the VM is the union of the global and VM-local db and dbx variables.

Let’s take an example to make all this a little clearer. Let’s pretend that in a far-off parallel universe (bear with me here, and please no comments!), that Microsoft decides Windows 8 is, in-fact, malware, and should fail to boot on machines with Secure Boot enabled. A few things could be done to make this happen:

First the physical world:

• Microsoft could work with OEMs to update dbx to revoke the signature of the Windows 8 loader. Assuming the OEMs all agree, they build a new version of the firmware to be downloaded by customers, and pre-populate it on new machines coming off the factory floor.
• While most new machines bought from those OEMs off the shelf would be caught, for machines in end users hands, the end user would need to update their firmware. This is, a relatively rare occurrence in the real world for client, less so for server. (Which does remind me, I ought to update my machines as I know at least two are out of date….).
• Or it could be done as a capsule update (assuming the firmware supports such a mechanism) allowing the firmware to be updated safely in the DXE stage of UEFI startup.
• Or it could be done by an update through Windows Update to add the signature of Windows 8 to dbx. Remember from above, the (authenticated variable-) update must chain to a root of trust to a key in KEK. This will mostly be fine, as all Windows 8+ logo machines have KEK pre-populated such that this is viable. (Of course, remember advanced users could enter setup mode from firmware if the OEM supports this, and alter PK/KEK. So it’s not 100% reliable).
• Remember also that the end user could always re-flash their firmware to a previous version, removing the update; turn off Windows Update allowing Windows 8 to once again load with Secure Boot enabled; or remove the root of trust for the dbx Windows Update from KEK. Of course, none of these are good ideas!

And compare to the virtual world:

• Remember Hyper-V doesn’t entirely model itself on a physical machine. We have the VM which thinks it is a physical machine, and the parent partition running at a higher level of trust.
• So, an update from Windows Update running inside the guest would work, the same as for a physical platform.
• But, as PK, KEK and the global db/dbx are maintained by the parent partition which runs Windows, we can simply push out a regular update on the parent partition to add the Windows 8 signature to the binary containing the global copy of dbx. And here’s the important bit – this update does NOT need to chain to a root of trust to a key in KEK. In fact, we can push out an update which patches any of the global secure boot variables.

OK, that was a little more detail than I thought! Let’s get back to end-user land. Secure Boot is a simple on-off setting on a per-VM basis. For the most part, you won’t need to worry about it assuming you are running Windows 8 or Windows 8.1 (and the server counterparts) as a guest operating system. Here’s the salient points to take away.

• When you create a new virtual machine, Secure Boot is enabled by default. The default cannot be changed.
• The setting is on the Firmware tab of the VM settings
  
• Secure Boot can only be enabled or disabled while a VM is powered off
• The PowerShell equivalent to this checkbox is Set-VMFirmware –EnableSecureBoot On|Off
• (Get-VMFirmware $VM).SecureBoot will return the current setting
• When Secure Boot fails, it will typically look like this:
  
  (Nice logo by the way – yes, that was one of my Friday afternoon jobs for this release. I never did care much for that Windows Server 2003/2003 R2 era brick theme anyway. Sorry, marketing department!)
• Non-Windows guest operating systems will likely not work with Secure Boot enabled due to not having a root of trust back to a key present in KEK

In the next part, I’ll go through some FAQs about generation 2 virtual machines before getting onto the topic of migration from generation 1 to generation 2.

Cheers,
John.

This part of the series on generation 2 virtual machines in Hyper-V looks at kernel debugging using the serial port. It's spookily simple (it's Halloween!). If you don’t have any need for kernel debugging, skip to the next part.

In generation 1 virtual machines, one of the most common ways of attaching a kernel debugger to a guest operating system is using a COM port. However, in generation 2 virtual machines, there are no COM ports. Or are there….?

Well the answer is both yes, and no. By default, the answer is no. However, you can change this. For the following screenshots, I’m using a Windows 8 virtual machine (in fact using the media I created in the previous part which has the software based keyboard driver added). For example, here’s the settings for a typical generation 2 virtual machine where there is no COM port shown.

That is simply because Hyper-V Manager will never show COM ports regardless of whether they are present or not in a generation 2 VM. Let’s look at PowerShell instead:

Here you can see PowerShell believes there are two COM ports. However, if you look inside device manager in a guest operating system, you’ll notice that there really are no COM ports present as devices enumerated to the virtual machine. (I won’t include a screenshot, I did that in a previous part.)

While a VM is running, you can set a pipe path for a COM port, so let’s do that for COM1:

Again, if you were to look inside device manager in the guest, the COM1 port is still not present. However, if you shutdown and re-start the VM, you’ll notice that the COM ports are indeed now present.

The rest of this isn’t rocket science for those of you familiar with kernel debugging, except for one small thing which is relevant to generation 2 virtual machine (or more specifically UEFI based machines with Secure Boot enabled).

Using msconfig, here I’m enabling kernel debugging for the VM on COM1, but after hitting OK, you get the following error:

This is because policy in Windows dictates that Secure Boot and kernel debugging are incompatible. Hence, shut-down the virtual machine and disable Secure Boot in the firmware settings. (I’ll talk more about Secure Boot in the next part.)

Use msconfig again to enable kernel debugging which will succeed, then restart the VM. Using windbg on the parent partition, connect to the pipe

At which point you can break in as per normal kernel debugging

Onwards to part 6 and Secure Boot.

Cheers
John.

This part of the series on generation 2 virtual machines in Hyper-V looks a little more at the keyboard device. This has relevance if you are running Windows 8 or Windows Server 2012 as a guest operating system, and more specifically WinPE/WinRE from these operating systems. PE is used, for example, during Windows setup. In part one, I mentioned that we removed the emulated i8042 keyboard device from generation 2 virtual machines. That means the only keyboard device available is the software based keyboard.

Unfortunately… this is also where hindsight is a marvelous asset. In PE & RE environments, the software based keyboard driver is not present. It was a pure and simple oversight, and I’m probably as good a person to blame as anyone. (Not literally though please ;).) At the time, no-one had thought there might be a need for it to be present in the future. It simply didn’t affect any end user scenarios. Generation 2 virtual machines changed those assumptions.

So let’s take the case of when you are installing Windows 8 client into a generation 2 virtual machine booted from an ISO. It’s the retail version which requires a product key. Setup is built on WinPE, and without the software based keyboard driver, you can’t enter the product key. (Well I guess you can use the on-screen keyboard.) Obviously in the case of unattended installs, you can get around this. You would hit the same problem doing a network install where the WDS server boot image (again based on WinPE) provided to the VM is Windows 8/Windows Server 2012 based. If that is the case, update your boot image to 8.1 and the problem will go away. Another workaround is to do an initial boot to an ISO containing Windows 8.1 PE from where Windows 8/Windows Server 2012 can be launched.

Fortunately, it’s relatively easy to solve the above using standard servicing mechanisms, which is what I’ll walk through in this part.

I’m assuming your client or technician machine is Windows 8.1 with Hyper-V enabled (or you have access to a Windows Server 2012 R2 machine with Hyper-V enabled). To start with, grab the Windows Assessment and Deployment Kit for Windows 8.1 (otherwise known as the ADK) from http://www.microsoft.com/en-ie/download/details.aspx?id=39982. Note I have tried this on Windows 8 as well, using the Windows 8 version of the ADK, but with pre-release versions of Windows 8.1. It should still work though.

When installing the ADK, you can use the default options, although if you choose, you only need the ‘Deployment Tools’ option for this walkthrough.

Once installed, start an elevated “Deployment and Imaging Tools Environment” command prompt.

While it’s installing, grab an ISO of Windows 8 (or Windows Server 2012) and copy it locally to the machine where the ADK is installed. For this walkthrough, I’m using an en_us Windows 8 RTM ISO although the language should be irrelevant. (Thinking about it, I should have grabbed the en_gb ISO as I still get frustrated continually seeing “Favourites” misspelt!)

The next think you need is the CAB file which contains the Integration Service .CAB file for Windows 8.1. It is important to use the .CAB file from the final RTM build of Windows 8.1, not the version from Windows 8.1 preview to avoid driver signing issues and a conflict with the Secure Boot feature of generation 2 virtual machines. The CAB file can be found under \Windows\vmguest\support\amd64, named “Windows6.2-HyperVIntegrationServices-x64.cab”. Copy it to a working directory where the .ISO being modified is located.

Now you need to mount the .ISO as a local drive letter to extract the contents which you are soon going to be modifying. You can mount it by simply typing the name of the .ISO file at the command prompt, or using Windows File Explorer. Simply copy the contents, including sub-directories to a temporary directory. In my case, I’m using c:\working\extract. After copying, you can unmount the ISO from explorer by right clicking on the drive and selecting Eject.

Next job is to examine the Windows PE boot WIM image which will be in the sources sub-directory where you just extracted the .ISO contents. Use dism /get-imageinfo to do this. There is a little gotcha here, you need to use DISM from the ADK, not the one built into Windows to avoid “Error: 87” as shown below.

The output shows there are two images in the WIM file, both of which we are going to update. Using another temporary empty directory, in my case, c:\mount, mount one of the images in the above WIM. Again, using dism, we are going to use the /mount-image parameter. Note the use of the /index: parameter too to match each of the images in the WIM per the above screenshot.

Next we need to add the software-based keyboard driver from the CAB file we copied earlier. As the Hyper-V Integration Services are catalog signed, it is necessary to apply the complete package of the integration services rather than the single keyboard driver. This is done using the /add-package parameter to dism.

And finally, for this image, unmount it, remembering to commit the changes. This is done using dism with the /unmount-image and /commit parameters.

Here’s the raw commands for completeness

dism /get-imageinfo boot.wim
dism /mount-image /imagefile:boot.wim /index:1 /mountdir:c:\mount
dism /image:c:\mount /add-package /packagepath:Windows6.2-HyperVIntegrationServices-x64.cab
dism /unmount-image /mountdir:c:\mount /commit

Repeat the above three commands but mounting index 2 in the boot.wim file (which is the Windows Setup image) this time around.

At this point, you might also optionally want to update the recovery WIM in the media too. This is a tiny bit more complicated due to the fact that it’s a WIM inside a WIM. To do this, you need to mount install.wim rather than boot.wim to start with. For example below, you can see that the media I am using contains Windows 8 and Windows 8 Pro.

The mount of install.wim…

Information on winre.wim under \mount\windows\system32\recovery\winre.wim

Mounting the first (and only) image in WinRE.wim to a second mount temporary directory (c:\mount2)

Adding the integration services package (remember c:\mount2, not c:\mount)

Committing the package and unmounting (again remember c:\mount2)

And now unmounting the Windows 8 image itself from c:\mount committing the contents.

Repeat for each image inside install.wim.

At this point, you are ready to re-create the ISO which can be used for Operating System installation on both generation 1 (PCAT) and generation 2 (UEFI) virtual machines. We use oscdimg.exe from the ADK for this purpose. From the sources directory where the modified Windows media is extracted, run the following command (on one line)

Oscdimg
-m
-o
-u2
-udfver102
-bootdata:2
#p0,e,b<Path>\etfsboot.com
#pEF,e,b<Path>\efisys.bin
<Source Directory>
<Target>

These are the relevant parameters:

Note that using just etfsboot.com is not sufficient as this only puts a boot loader suitable for BIOS/PCAT based machines onto the ISO. More information can be found at http://support.microsoft.com/kb/947024. (This KB applies for Windows Server 2008, but can be used for Windows Server 2012/Windows 8 as well).

Using our previous working directories, here’s an example.

Phew! Let’s try it out in a new generation 2 virtual machine attaching and installing from the patched ISO.

Of course, you can also use the patched boot.wim file for use on a WDS server. However, I would recommend instead you put the Windows 8.1 PE and boot.wim on the WDS server instead as these contain the software keyboard driver already.

In the next part, I’ll talk about debugging as it relates to generation 2 virtual machines.

Cheers,
John.