Encrypting guest virtual machines is another layer of protection you can add in Hyper-V. Why would an admin want to do this? Because while encrypting the Hyper-V Host itself can protect against stolen physicaldisks, enabling BitLocker inside your virtual machines protects against stolen virtual disks as well (e.g. if an attacker were to gain access to an online Hyper-V host and export the VHDX files).

As I mentioned in my previous post, I wouldn’t recommend this option unless you have Windows Server 2016. The reason is, Hyper-V in Windows Server 2016 is the first time we’ve been able to enable a virtualTPM (vTPM) in guest virtual machines. In earlier versions, admins who wanted to encrypt their guest virtual machines had a couple of workarounds, and there were problems with each of them.

2012 R2 Work-Around #1: Require a startup password / PIN

Nothing inherently wrong with this I suppose, but it means that every reboot (due to updates or otherwise) would require someone to key in the password, or suspend BitLocker and then reboot. If this process were scripted, as I’ve seen in a few cases, it can really put a damper on the protections BitLocker has to offer.

Most people don’t realize this, but when the Windows OS is booted, BitLocker is essentially off and the data on your disk is fully accessible. BitLocker is an encryption technology meant to protect against loss/theft, and it makes it difficult or practically impossible for someone to boot the device with an alternate OS (Linux, etc.) and read/copy the data from the disk.

Therefore, by suspending BitLocker, the next reboot would occur without requiring a password, meaning that disks could be taken from the host server, and booted elsewhere, without that protection kicking in. So much for full disk encryption.

So if you’re going to enable a startup password, that’s fine, just don’t do that other thing (e.g. scripting automatic reboots w/ suspension).

2012 R2 Work-Around #2: Attach a floppy disk as VHD to be your startup key

This method is even less secure. With BitLocker, a key  can be stored on a floppy or USB disk, which is then inserted in order to allow the computer to boot. Since you can permanently affix a VHD file to the virtual server, some people have done this to get around the need for entering a password each time. Again, terrible idea. The VHD for this key is not itself encrypted, so anyone with access to this system or the small VHD key file would pwn the virtual machine in pretty short order.

How Windows Server 2016 Solves this with vTPM

Enter Windows Server 2016. Open the Hyper-V Manager and check out the settings on any VM. There is a new Security option on the left menu of choices.  Here we can enable the virtual TPM chip.

Note: this is available on Gen2 virtual machines only.

If you enable it, then inside your VM, you will have access to the same protection that your host server enjoys, with a real TPM.  If you try to export the VHD and run it somewhere else, it will do you no good without the corresponding BitLocker key. Similar to if you were to remove physical drives from a computer where the TPM chip resides. Check out the Device Manager, it looks just like a physical server/computer:

Cool, huh?  Now you can setup BitLocker in your virtual machines exactly the same way you do for your host server, or other physical computers.

But what about Generation 1 virtual machines, for example VHD’s that were imported from a previous version of Hyper-V such as 2008 R2 or 2012 R2?

Using BitLocker in Generation 1 VM’s

If you open the settings of a VM that is Gen1, you will notice the Security area is still there, but it looks a little bit different. No vTPM option, but we can “Add Key Storage Drive.” While this technically isn’t as secure as a vTPM, it does offer admins a way to encrypt the VM using BitLocker, with better protection than just attaching a VHD as a floppy disk (which as I mentioned is a terrible idea).

Even though the key storage drive gets attached to the virtual controller as though it were a VHD, you will not find any references to it on the Hyper-V host with the rest of your VHD files. Nevertheless, inside the VM, you will be able to see the small disk become available in Disk Management.

Note: Since this VM does not have a TPM, you will also need to enable the Group Policy we have talked about before, and then select the Key Storage Drive to store your key.

If you’d like to see a detailed write-up on configuring this from here on out, I’ll refer you to this article, by Microsoft MVP Aidan Finn.