In this step-by-step post, I will show you how to enable and configure BitLocker to provide at rest encryption inside of a Generation 1 virtual machine using Key Storage Drive on Windows Server 2016 (WS2016) Hyper-V hosts.
Enabling Key Storage Drive
The easy part of deploying this solution for Generation 1 virtual machines is to enable Key Storage Drive in the settings of the virtual machine.
If you are curious, like I was, you’ll probably look for this new disk. You will not find a virtual floppy or hard disk file in the storage of the virtual machine. However, when you start up the virtual machine, sign in, and start Disk Management, you will find that a new 42MB disk was added.
Prepare the Disk
You can quickly prepare the disk using Disk Management or Diskpart. I prefer to use Disk Management:
- Initialize the disk with the MBR partition style.
- Bring the disk online.
- Create a new simple volume, filling the disk.
- Format the drive with an available volume letter, such as K or Z.
- Use NTFS as the file system and clearly label the volume, such as Key Storage Drive.
Local or Group Policy
By default, BitLocker requires you to have a TPM chip. Generation 2 virtual machines support virtual TPM (vTPM) on WS2016 Hyper-V, but Generation 1 virtual machines do not. Instead, Key Storage Drive does the equivalent of storing the keys on a USB drive, but in our case, it’s the 42MB virtual volume that we just formatted in Disk Management.
We need to configure Group or Local Policy to enable BitLocker without the presence of a TPM chip in the virtual machine. My machine is not domain joined, so I will use the Local Group Policy Editor (GPEDIT.MSC). You should use Group Policy Objects (GPOs) to configure domain-joined virtual machines. The required setting can be found at Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\. The setting is Require Additional Authentication At Startup, which must be enabled and configured as shown in the screenshot below:
Remember to force a local/group policy update in the guest OS of the virtual machine by running GPUPDATE /FORCE.
We will use PowerShell to enable the BitLocker feature in the guest OS of the virtual machine, and then run a second cmdlet to start the encryption process.
First, we will enable the BitLocker feature (and all the management pieces) and perform a reboot automatically; remove the -Restart flag if you want to delay the reboot until later, but you will need to reboot to encrypt the disks:
Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart
You can then encrypt the C: drive of your virtual machine using PowerShell; note that Z: is my key storage drive:
Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath Z:
You can re-run the Enable-BitLocker cmdlet to specify other volumes to encrypt in the virtual machine. I added a data volume (E:) to the virtual machine and encrypted it as follows:
Enable-BitLocker E: -StartupKeyProtector -StartupKeyPath Z: -UsedSpaceOnly
Note that the -UseSpaceOnly cmdlet must be used on thinly provisioned storage, but this also speeds up the initial encryption by only encrypting volume space after it is written to.
You can query the progress of the initial encryption of your virtual machine’s disks by running: Get-BitLockerVolume in the guest OS.
If you want to test out how well your Key Storage Drive and BitLocker solution is working, shutdown the virtual machine. Double-click one of the encrypted VHD/X files and see if you can browse it – you should not be able to browse the file system as you would with a non-encrypted volume in a VHD/X file.
Deleting the Key Storage Drive
If you have anything of value in the virtual machine, then do not delete the key storage drive. Doing so will result in a virtual machine that will not start and you will not be able to recover the data from the disk.