Amazon Banner

Friday, April 29, 2016

Configuring Bitlocker and TPM on Server 2012R2 Core

I've just finished configuring Bitlocker on a new server running Server Core 2012R2 with a TPM key protector.  I had to piece together bits from a few sources online to accomplish this, so I will bring together in this one post all of the steps I ended up using.

Here's a high level overview of the steps required:

  1. Check TPM status
  2. Enable & activate TPM if needed
  3. Take ownership of TPM
  4. Create Bitlocker recovery password
  5. Backup recovery password to Active Directory
  6. Enable Bitlocker using the TPM as the key protector

In order to do this, the server must have a TPM module installed.  Believe it or not, this is still not standard hardware for many servers.  For HP servers, a TPM add-on is available for about $50 as p/n 488069-B21.  If you do have to install a TPM, go into the BIOS and enable the TPM under the security settings, to save yourself some steps later.

Now comes the tricky part.  Powershell version 4 added some handy new cmdlets for managing the TPM.  Unfortunately, for some reason those cmdlets are not included in Server Core installs, so we have to resort to using WMI.  The Scripting Guy has a great blog post that gets into all of the details on this, written by guest blogger Stephane van Gulick, which my process was based on.

First, use WMI to get the Win32_TPM class, which contains all of the methods required for managing the TPM.  By assigning it to a variable $TPM, we can use the variable to call the methods we need.

$Tpm = Get-CIMClass -Namespace ROOT\CIMV2\Security\MicrosoftTpm -Class Win32_Tpm

EDIT 05/26/2017 : It may be necessary to use "Get-WMIObject" instead of Get-CIMClass in the above command.

Next, run the following commands to check the current status of the TPM.


$Tpm.IsEnabled().isenabled
$Tpm.IsActivated().isactivated
$Tpm.IsOwned().isOwned

Each of those commands will return a boolean true or false.  If the TPM isn't enabled, enable it using:


$Tpm.Enable()

Once the TPM is enabled and activated, it's time to take ownership.  If the TPM is already owned, it will need to be cleared first.  Then, prepare a TPM owner password to be used, and take ownership.


$tpm.Clear()
$password = 'P@ssword'
$tpmpassword = $tpm.ConvertToOwnerAuth($password).OwnerAuth
$tpm.TakeOwnership($tpmpassword)

Now the Trusted Platform Module is enabled, active, owned, and ready to store the Bitlocker key protector.  But before we can start encrypting the drive, the Bitlocker feature must be installed using 'install-windowsfeature'


Install-WindowsFeature Bitlocker

At this point, I tried to enable bitlocker using a TPM protector, but because our group policy settings require that a bitlocker recovery password be backed up to Active Directory, the command failed.

According to the documentation for Enable-Bitlocker, the there are several parameters which can be used to specify what type of key protector should be used.  While some of these parameters include multiple protectors, The TPMProtector and RecoveryPasswordProtector options are mutually exclusive, and cannot be combined.  Lucky for me, the documentation also includes this handy tip to point me in the right direction:
It is common practice to add a recovery password to an operating system volume by using the Add-BitLockerKeyProtector cmdlet, and then save the recovery password by using the Backup-BitLockerKeyProtector cmdlet, and then enable BitLocker for the drive. This procedure ensures that you have a recovery option.
Use the Add-BitlockerKeyProtector cmdlet to create the recovery password.  Then find the protector ID and use it to back up the recovery password to Active Directory using Backup-BitlockerKeyProtector.  (It may not be necessary to run Backup-BitlockerKeyProtector if group policy requires the password be backed up when created, but it won't hurt anything to back it up again just to be safe.)


add-bitlockerkeyprotector -mountpoint c: -recoverypasswordprotector
$BLV = Get-BitLockerVolume -MountPoint "C:"
Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

I ran Enable-Bitlocker again, but once again hit a snag:

Because my group policy also requires that OS drives encrypted with Bitlocker use a TPM protector, it appears that a TPM protector was assigned automatically when I added the Recovery Password protector.  Since the drive was already set up with a TPM protector, the enable command failed when it tried to add another. The Enable-Bitlocker command requires the use of one of the protector parameters though, so even though the required protectors were already present, I couldn't simply enable bitlocker using the existing protectors.  To work around that, I ran it again using the RecoveryPasswordProtector option.

Enable-BitLocker -recoverypasswordprotector -mountpoint c: -encryptionmethod AES256

Finally, bitlocker was successfully enabled.  Powershell helpfully provided the recovery password again and instructed me to save it in a safe place, and instructed me to restart the computer for a hardware test before encryption begins.  The restart can be avoided if necessary by using the -skiphardwaretest parameter, but I wouldn't recommend it.

One unfortunate result of my mis-steps along the way is that I ended up with 3 separate Recovery Password Protectors assigned to the drive, and all 3 backed up to AD.  I will need to do further testing to determine why the additional passwords were created, but I suspect it may have happened as a result of my failed attempts with the "enable-bitlocker" command.  If you know why this happened, or if you have any questions, please leave a comment below.

Thanks for reading!

Viewing Windows Update logs in Windows 10

For many years, dating back at least to Windows XP, Windows Update has kept a text format log in the Windows directory, which could provide useful information when troubleshooting update issues.  Beginning in Windows 10, this log file (C:\Windows\WindowsUpdate.log) Is no longer used.  If you look for it in the Windows directory, you'll see that the file is still there, but is only 275 bytes, compared to the 1-2MB log files of the past.  The contents of this file now explain that it isn't used anymore, and list a powershell command to get a readable windows update log:


As you can see, there is a simple solution in the form of a new powershell cmdlet.  Simply run "get-windowsupdatelog" in powershell, and wait.  You'll see various input and output files scroll by in the powershell window as it parses the new "ETW" (Event Tracing for Windows" formatted logs, located in "c:\windows\logs\windowsupdate\".  When the cmdlet finishes, it will create a new windowsupdate.log file on the desktop:


Note that get-windowsupdatelog uses publicly available symbols to decode the ETL files and create the text formatted log.  The first time you run the command, you may have to accept terms to access Microsoft's internet based symbol store.  

If you're running a preview build, this commnand may not be able to decode the output, as the symbols for most preview builds aren't made available publicly.  In that case, you'll still get a windowsupdate.log file on your desktop, but the information in it will be less than helpful:


For more information on reading the windows update logs in Windows 10, check out KB3036646.