Over the past couple months, I began experimenting with using virtual disks for use with what are called Native Boot Virtual Drives, or what I like to call “Native VHD”. The technique allows one to use a virtual disk to boot the host operating system and does not require a hypervisor. This means that on systems with or without virtualization capability, you can use a virtual disk as the container for the host operating system. There are a few short-comings to using this technique that I will cover in this article; however, the benefits far outweigh the minor quirks in its’ implementation.
To explain what the faults are and how to overcome them, I would like to first review how a system partition layout is derived using the standard installation process and the effects of customizing the RE tools image.
When installing Windows to a new system using an ISO or DVD media, the installer will implement a default drive partition layout. It consists of a System and Windows volume with the recovery tools embedded within a hidden volume. While not often used, those recovery tools can be vital when a system refresh or repair is needed. They are included within a WIM file that happens to be a bootable image.
Figure 1: Default Partition Layout
While this layout works, I have found that if you have a need to customize the RE tools, the default size of the partition becomes a problem. In short, the shadow copy service (VSS) requires enough free space to do what it does. Customizing the RE Tools image can wreak havoc on that and the default partition size just does not allow much wiggle room for customization. Careful planning for the proper volume size is needed to allow VSS to function properly. You can find some insight on how to customize the RE tools in my previous article, “Windows RE & Bare Metal Recovery.” You may also find the partition size requirements on TechNet here in the subsection labeled “System Partitions.”
All of this is not so much a problem and easily fixed by adjusting the partition sizes. However, if you want to move to using a Native VHD file for the host operating system, there becomes a slight issue with the default installer. It simply does not know how to adjust the BCD store for the VHD loader and add the RE Tools. From my testing, it just simply ignores the Windows RE Tools partition, and embeds the recovery image into the operating system volume within the VHD file. That’s a big problem if you need to launch the recovery environment. I have a PowerShell script to solve this that can be implemented post installation, which will adjust the BCD store to point to the correct partition. I will provide that a little later, but first let’s look at the Native VHD, the benefits and how to set a system up to use it.
Introducing Native VHD:
This isn’t new, and was introduced a few years ago with Windows 7 along with the new boot loader environment or “BCD” store. However, it seems that not many people are utilizing this capability or just not discussing it much. Perhaps this is due to some strange fear of it or just the lack of radar attention. Either way, Microsoft has a nice description of the pros and cons of its use here and I’m finding it to be a great way to isolate the operating system.
Figure 2: Native VHD
I can easily access the host operating system just as if it were a single file while booting into the Windows Recovery Environment, or from a bootable USB. I can make a quick copy of the virtual drive to a network resource or external storage as it is just a single file. I do not need to be concerned with any locked, or hidden files that may be a part of the entire Windows file system such as Program Files, SYSVOL, or other obscure file system dependencies. Everything needed is contained in that single virtual drive. You may be able to experiment with it and lock the file as “read only,” link a differencing virtual disk to it and adjust the BCD to use that as the host OS. It is one option to ensure that any future changes will be made to the differencing file and not the originating virtual disk of your host. Another idea is to move the Windows Recovery Environment into a virtual disk, freeing the physical partition and allow a flexible recovery option. And finally, you could lock the differencing file, link another differencing virtual disk to it, and create a “chain” to test some new software or patch. If a problem occurs, no need to do a VSS rollback. Just simply break the link, enable “read/write” to the last link, adjust the BCD if you’ve changed the file name or path and you’re done. This may seem complex, but it isn’t and definitely beats backup restoration, refreshing or re-installing the operating system.
Figure 3: Theoretical Alternative
The idea of linking a differencing disk and moving the Windows RE Tools partition into a virtual drive is just a theory, I have not actually tried this yet, but I plan to use this. I see no reason why the system would not support it, as it is just simply a matter of adjusting the BCD store to point to the differencing VHD. This way, making modifications directly to my operating system without knowing that the Native VHD file is locked for only read is going to be difficult for any pervasive hack. It’s not impossible if the assailant is aware of this configuration; however, it just adds another level of difficulty and protection to my system as changes would transparently be applied to the differencing file and not the originating virtual disk.
Setting up the System:
So how then does one install the operating system to a Native VHD? You have a choice, you can either use your expert knowledge in creating an unattended installation script, or by briefly escaping the default installation process using Shift-F10. This is done when prompted to select a volume for installation. You will be able to manually construct the partition layout using DISKPART, create the VHD file, attach it and switch back to the installer, refresh the volume selection panel and choose the virtual disk. Yikes, if I had no idea how to do that I would be lost. Here’s a link to an excerpt from my auto unattended installation script which deals just with this portion the configuration.
Examine the contents of that file, and note that while I am using PowerShell to call commands, these calls can be made manually in DISKPART. PowerShell is not required here, it’s just a sample from my solution. You will need to decide a few things on your own, such as the names of the directory to hold the virtual disk (I called it “VMs” ), the name of the disk (ssVHD.vhdx), and the volume name within the virtual disk (named “Sentinel” in the sample) which will contain the operating system.
Note that I have made changes to the partition sizes which may or may not work for your needs, and that you will need to exit DISKPART to create the directory to store the virtual disk prior to its’ generation if you are doing this manually. It’s all in the script, just take a look and decide what works best for you.
The “quirk” in all of this besides getting the OS installed onto the Native VHD is to get the BCD store updated to reflect these changes and allow the Windows Recovery Environment boot option. The default installer doesn’t handle this very well and it must be done either through script or by hand. To figure this out, I did it by hand and have now translated this to a PowerShell script. Please read all of my notes in the following PowerShell script before attempting to execute it. I had a good idea of what was needed in my case, but you should familiarize yourself with what is happening before moving forward with it.
(This script should be executed “after” the operating system has been installed)
Page File Blues:
By default, the operating systems’ page file is of course installed on the operating system volume. I don’t like this, as it’s just another file reading and writing to a volume that in my mind should be rarely touched if only to be patched or read from to boot and execute specific tools and applications. The nice thing about implementing a Native VHD solution, is that you can move this page file “out” of the virtual disk onto your host volume. Following the rule of thumb related to page files, the space needed is approximately 1.5 times the amount of physical RAM available to the system depending on the role. In my example, I have configured the script for a system that has 4GB of RAM with a host volume size of 40GB and a Native VHD file of 32GB. This is plenty of extra space for the operating system to store the page file (up to 8GB). Just simply move the page file after installation to the host volume (which may or may not show up as the D:\ drive), or check to see if the installer was smart enough to move it automatically to the larger volume (40GB).
It would seem, that Disk Management treats these volumes as separate drives… in reality, the host volume contains the virtual disk. In my early tests, I attempted to “hide” the host volume for the Native VHD to prevent accidental use or viewing from Disk Management; however, this ended up being a failure in the long run. While I was able to get it working, it left no room for a my page file changes. I settled with the fact that the host volume would be visible and decided to make use of it for the paging. The following screen shot shows my Hyper-V Server using the Native VHD technique and as you can see the “host” volume size was increased to accommodate a larger page file as the system has 16GB of RAM.
Figure 4: Disk Management
There is an apparent issue with Windows Server Backup (WSB) that should be mentioned with the use of a Native VHD file. It would seem, that WSB will not backup both the host volume and the operating system virtual drive. You can only select one or the other with the tool to be added to the backup schedule. Otherwise, if you select the “Windows” volume (C:\ shown above), and try to select the system state or the “host” volume (D:\) you will presented with a pop-up preventing you from choosing those options to add to the schedule.
Figure 5: Nope, Wrong order apparently….
Figure 5: Not an option, at all…
However, if you first select the system state then choose the “Windows” volume (C:\) and just ignore the “host” volume, you will not have any problems adding this policy to the schedule. So that is a good option if you need to do a rollback and require the system state. You can then complete your continuity plan by implementing a separate backup plan that grabs the host volume if you like, or just simply copy the VHD file. I have chosen the latter option by creating an automated solution with Windows Recovery Environment.
One thing that I have not attempted yet is to manually create the policies using PowerShell, integrate them using Task Scheduler and completely bypass the WSB GUI tool. I may give this a try at some point, but for now this will do. For my situation, I honestly have no need to back up the host volume that contains the virtual disk as it is just going to provide scratch space for my paging.
Using the script to fix the BCD and enable the use of the Windows Recovery Environment has allowed me to find new ways to manage my host operating system with the use of a Native VHD. I’m finding that it can save time by avoiding the “start from scratch and re-install” headache by allowing me to replace that single VHD file with a backup copy. I no longer need to rely solely on a third party backup solution, or Windows Server Backup to keep a solid system image, I have one ready at hand on an external drive if needed. You can even setup an automated script to be launched in the Windows Recovery Environment to capture the virtual disk on a regular schedule with little effort outside of the normally scheduled Windows Server Backup. This provides a second option to restore my system that is within my control and lessens the dependency to other tools.
I hope you have found something of value in this article and got a chance to take a look at the example scripts I provided. Feel free to ask any questions or if you spot something odd, let me know and I’ll make corrections.