Preparing for Windows 9 with dualboot

As most of you know, Microsoft will announce Windows 9 om September 30th 2014 which is in 2 weeks as I write this. Now I am very excited about this product and considering there hasn’t been any information about the new features yet I predict a lot of testing when the technical preview (really Microsoft, just call it a beta) is released to the public.

So how do we test this new operating system?

The initial thought is to use a hypervisor, like Hyper-V, and create VM’s with Win9 on, but imo that really isn’t a very good way to try the client OS. Therefore I wanted to share my approach which is to initially install Windows 9 on a VHDX file and set it in a dualboot configuration with my Windows 8.1 system which I’m currently using. Unless I find something that tells me otherwise, Windows 9 will shortly be my main OS. There are 2 big advantages to running this in a VHDX with dualboot instead of a vm:

  1. You get a much more true test how the OS will run on your hardware since it actually reaches your physical hardware with the exception of hard drive which is virtual. I find this particularly important when testing a client OS.
  2. You can by all means and purposes replace you current installation but it is still very easy to fall back to should something occur, or if you just have to get some files that you haven’t backed up or put into the cloud

So now that I have convinced you all on why this is a good idea I will show you how to easily do it. In the procedure below I’m using Windows 8.1 to mimic the Windows 9 iso since it’s not available until 2 weeks from now.

There are 3 stages for getting a VHDX file in dualboot with your existing 8.1 installation:

  1. Create a vhdx file
  2. Apply the new Windows image to the vhdx file
  3. Set up the boot configuration


Create the vhdx file.

Here I create a dynamically expanding 40GB vhdx file on the folder c:\boot on my C:\ drive.

Create the folder to store the vhdx file, C:\boot in this example

open an elevated commandprompt and type the following

create vdisk file=c:\boot\win9.vhdx type=expandable maximum=40960
attach vdisk
list disk

Verify that the VHD is selected by the star on the left

create partition primary
format fs=ntfs quick

Now the vhdx fine has a formatted and active partition, in this case it was mounted as E:


Apply the new Windows image to the vhdx file

Now that the vhdx file is ready, you mount up your newly downloaded Windows 9 iso, in this case it’s mounted as D:

First you have to pick the SKU you want from the iso. Note the name and Index#  from this command (Again Windows 8.1 is used in this example)

dism /get-imageinfo /imagefile=d:\sources\install.wim


Now I see I can either install Windows 8.1 or 8.1 Pro. Since I want 8.1 Pro so I must apply Index 1 to my vhdx

dism /apply-image /imagefile=d:\sources\install.wim /index:1 /applydir:e:\

Wait for the operation to complete


Set up the boot configuration

The vhdx file is ready but not set up as a boot option on your computer so we still work in the elevated commandprompt.
Add the vhdx to the boot menu

bcdboot e:\windows

To check you boot configuration

bcdedit /enum

The boot configuration

Notice that the description is the same which makes it confusing but the device tells us which is the vhdx-file. Also the vhdx file is the default boot option.

If you want your current installation as default boot then simply run

bcdedit /default {current}

And last I want to change the desciption to tell them apart, which hopefully won’t be necessary with the genuine Windows 9 iso.

bcdedit /set {b42c4225-3dc5-11e4-94b6-c190548f218f} description “Windows 9”

After you run bcdedit /enum again you should see something like this


Finally we are ready to test this, simply reboot your computer and you should see the new and improved boot menu in Windows 8.1

The boot menu

Make sure you check out “Change defaults or choose other options”, lots of neat stuff there.

Final words: Yes, I am perfectly aware of all the tools that can do this for you, but you won’t improve you skills in diskpart, dism og bcdedit by using those tools. The best way to improve in something is to work with it.

Hyper-V backup using Windows Server Backup

A new feature in Windows Server 2012 is that Windows Server Backup (WSB) now has Hyper-V support, meaning you can use it to take backup of and restore virtual machines running on Hyper-V. This provides a complete backup and restore solution out-of-the-box which can prove to be good enough in some environments, particularly in the SMB market.

Install Windows Server Backup

To install Windows Server Backup you can use

  • Server Manager – Added as a feature under “”Add/Remove Roles and Features”
  • Command Line – Run “start /w ocsetup WindowsServerBackup”
  • Powershell (2012) – Run “Add-WindowsFeature Windows-Server-Backup”
  • Powershell (2008 R2) – Run “Import-Module ServerManager” and then “Add-WindowsFeature -Name Backup-features -IncludeAllSubFeature”

Nice 2 know about Windows Server Backup 

  1. WSB uses VSS (Volume Shadow copy Service) to create a .VHDX file which contains a snapshot of the virtual machines that is backed up. This also enables WSB to take full backup of and flush the transaction logs of VSS-aware databases like Active Directory and Microsoft Exchange when you select “VSS full backup”, this is not selected by default.
  2. WSB uses VSS to manage the backup versions, and since VSS is pr-volume this makes WSB unable to maintain several versions of a backup job when you backup to a network share. A backup to a network share will overwrite the previous backup. If you backup to you locally connected drive you can have several versions.
  3. When you backup a VM you get a warning saying the VM will be put in saved state while the backup runs. This is not the case. The VM will continue to run uninterrupted and no one will notice you are backing it up.

Backing up a VM

“wbadmin start backup” is the primary command to backup you vm’s and I won’t go through all the options and switches but there are a few examples.

To backup a VM named “Server1” to the disk mapped as Y, run the following command:

wbadmin start backup -backuptarget:Y: -hyperv:Server1

To backup a VM named “Server1” to a shared folder, run the following command:

wbadmin start backup -backuptarget:\\server2\backup -hyperv:Server1

To backup a VM named “DC1” to a the mapped as Y and flush the transaction logs of AD, run the following command:

wbadmin start backup -backuptarget:Y: -hyperv:DC1 -vssFull

Restore a VM

“wbadmin start recovery” is the primary command to recover a VM from backup. Recovering a VM is slightly more trickier than backing it up, but I have never heard of a backup product where a restore is easier than taking a backup. The command has several options and switches but I’ll stick to the basic ones in this post.

The restore procedure involves finding the version of your backups you want to restore, then which items within that version before the restore itself. To begin with you find your backup versions with the following command

wbadmin get versions


This will provide a list for the backups taken from the local machine. Look for the field “Version Identifier” which you need in the next command. Then we take a look what resides in this backup version with the next command

wbadmin get items -version:(version identifier)


Here you see I have a VM named “LAB2-PC2” that I am able to restore from this backup. To do so I have to grab the “vm identifier” value and the backup version number from before and run the following command

wbadmin start recovery -itemtype:hyperv -version:(version identifier) -items:(VM identifier)


Notice the warnings that it will delete the VM if it still exists and restore the VM from the backup. Also you have to verify the network settings of the VM after the restore. As mentioned this command has a numerous options for restoring to alternate locations and such so I would suggest that you go exploring with “wbadmin -?” or have a look at

Restore a single file or folder

WSB only provides a snapshot og the vm and you have to restore the entire vm or nothing at all. But if you just need to restore a file or a folder, then locate the .VHDX file in the backup and mount in disk manager and extract the files from there. Alternatively you can restore on another hyper-v host and boot it up ther to extract the files.

Final words

I’ll keep this short and straight to the point: TEST YOUR BACKUP!

Longer version: I’m convinced one of the more common failures among IT is that people does not try a proper restore until the day they need it the most. I can’t express how important it is that you test your backups and try a restore. Create a restore procedure and write it down! When the day comes that you need it, you will thank yourself that you did.

Thank you for reading, hopefully you have enjoyed it.

Hyper-V limits

A quick list of the limitations to Hyper-V as of Windows 2008 R2:

Hyper-V host:

  • Virtual CPUs: 512
  • Maximum Memory:  32GB (standard), 2TB (enterprise and datacenter)
  • VMs pr host: 384
  • Storage: Limited only by Windows
  • Network Interface Cards: Limited only by Windows

Virtual Machine:

  • Virtual CPUs: 4 (if the host has at least 4)
  • Maximum Memory: 64GB
  • IDE drives: 4 (Remember the vm must boot from a IDE-attached VHD file)
  • SCSI drives: 256 (up to 4 scsi-controllers with up to 64 drives each)
  • VHD limit: 2 TB
  • Total storage (VHDs): 520 TB (260 drives on 2 TB each) + any pass-though drives
  • Pass-through drives: Number and size limited by Windows only
  • Virtual Network Interface Cards: 12 (8 synthetic and 4 legacy)

Hyper-V virtual hardware options

In the Hyper-V console you can find a few options regarding the virtual hardware of each vm and there are several nice features you all should know about. Let’s begin with synthetic and emulated devices.

Emulated devices (aka legacy devices) are the more traditional virtual hardware which is supported by pretty much any OS out of the box. It still uses CPU cycles on the host to emulate a hardware and transfer its I/O. The synthetic devices (aka Enlightened devices) are new virtual hardware designed to be much more efficient on virutal machines than emulated devices. It performs way better as it transfers I/O directly to the vmbus instead of emulating a device in between, but the operating system needs the Hyper-V integration software to detect synthetic devices. In short, emulated has better compatibility but synthetic gives better performance.

This explaines why the harddrive containing the OS in a vm must be an IDE drive. IDE drives in Hyper-V are emulated at boot, but can transition seamlessly into synthetic devices. SCSI controllers are synthetic only and is therefore not visible for the guest OS until the Hyper-V drivers has been loaded. In performance there are no practical difference between an IDE drive and a SCSI drive in Hyper-V, but you can hot-add disks on the SCSI controller.

While we’re on virtual hard drives. The VHD files can be set up in 3 different ways in Hyper-V: Fixed size, dynamically expanding, and differencing disks.

  1. A fixed size VHD will allocate all space when the file is created, so if you create a 50GB fixed size VHD the files will be 50GB in size even if it only conaints “free space”. The advantages is that this file will unlikely be fragmented and perform slightly better than dynamically expanding disks. Fixed size disks are recommended for production environments. The obvious downside is that you always will allocate space which isn’t spent.
  2. Dynamically expanding on the other hand will only allocate the space which is used by data inside it, and allows you to utilize the storage capasity much better. Though these drives doesn’t perform as well as fixed drives since it has to spend disk writes to expand the file when data is added. Also you will likely end up with defragmented VHD files. But for testing purposes this is a very good option to increase what’s called the “vm density” (I smell a later blog post about that). Just be very careful that the VHD files has space to grow or you risk bringing all your vm down all of a sudden when your physical drive has no space for growth.
  3. Differencing disks is that you set up a “parent disk” and then create other “child disks” that uses the parent as a reference. All changes from parent disks are stored in the children. This configuration is seldom used for other than testing purposes as failure on the parent disk will make all children disks unusable.

In addition we have pass-through disks which connects a volume directly to the vm and not as a vhd-file. This gives by far the best performance, but the disk is completely assigned that particular vm and can’t be accessed by any other vm or the host.

RemoteFX is a new feature in Windows Server 2008 R2 Service Pack 1. It is a virtual display adapter that enables what Microsoft calls “Rich desktop experience”, which means high-end graphics in a vm and over RDP. The graphics are virtulized in the display adapter. This requires support in the graphics driver and you’ll usually need an enterprise version display adapter from Nvidia or ATI.

The amount of memory assigned to a vm can either be static, or as of Windows Server 2008 R2 SP1 it can be dynamic. By selecting dynamic memory you can assign amout of memory the vm shall have at boot, and the maximum amount of memory it can allocate. There is also a slidebar used to determine the priority the vm has when several vms has to assign memory between themselves.

CPU Cores is prettystraightforward. It is the amout of logical CPU cores the vm has installed. I’ll come back to about the pros and cons of assigning a vm one or more cpu cores. Here you can also reserve CPU power to the vm so it’s guaranteed some resources, and you can also limit the amount of CPU power by percentage the vm can load the host with.

The VHD file

A short but nice tip: VHD files are virtual harddrives used most commonly in hyper-v, but you can mount them natively in Win7 and later and you can also boot from them. This provides a very easy to implement a dual-boot configuration for testing purposes.

1. Boot up your Windows 7 media
2. After you’ve chosen your language/keyboard settings, press shift+F10 which opens a command prompt
3. Locate your internal harddrive (D: in this example)
4. Type diskpart and press Enter
5. Type create vdisk file=”d:\vhd\win7.vhd” type=fixed maximum=40960 and press enter. This will create a fixed size vhd file of 40GB located on the d:\vhd folder (which you must create beforehard). If you want to, you can use a dynamically expandable file by replacing “fixed” with “expandable”.
6. Type select vdisk file=”d:\vhd\win7.vhd” and press Enter
7. Type attach vdisk and press Enter
8. Type exit and press Enter to exit diskpart and once again to exit the commandprompt. Continue the Windows installation.
9. When you come to the select partition screen you should see a disk drive representing the vhd file, and you can choose that as the installation target. The warning message can be ignored.
10. Windows will automatically create the boot-menu entries with the new installation as the default choice.

Unlike running this in a virtual machine, installing windows in a vhd and booting from it gives it direct control of the hardware. So a Windows Server 2008 R2 installed like this is able to run Hyper-V just fine. You do however lose other abilities like bitlocker encryption and hibernate.