How can I reinstall BitLockered UEFI computers using network boot and System Center 2012 R2 Configuration Manager ?

Introduction

In previous posts I showed you how you can reinstall computers while retaining users data that were encrypted using BitLocker (full disc encryption), and achieving this via Network boot (PXE) while still encrypted using BitLocker, in other words, the task sequence was not started in Windows, but via PXE and the hard disc was locked.

The magic behind unlocking the drive involved communicating with the MBAM server to retrieve the RecoveryPassword in order to unlock the drive, and the whole process is described below and available for you to download.

CM12 in a Lab – The CM12 BitLocker FrontEnd HTA – video
CM12 in a Lab – The CM12 BitLocker FrontEnd HTA

Those type’s of scenarios would cover refreshing the Operating system from Windows XP to Windows 7 with BitLocker or even Windows 7 BitLockered to Windows 8.1 with BitLocker and works great as long as the computer BIOS (basic input output system) is in Legacy mode.

However, as there are more and more UEFI devices (like the Surface Pro 3), the need to refresh them with an UEFI operating system (Windows 7, 8 or 8.1) whilst still being encrypted with BitLocker was a challenge that I took on recently and here’s how I did it.

Update: Since writing this blog post i’ve updated and re-released the CM12 UEFI BitLocker HTA, details below, i’d recommend you use that task sequence instead of the one supplied here as it contains even more goodness.

CM12 in a Lab – The CM12 UEFI BitLocker FrontEnd HTA – Part 2. Installation
CM12 in a Lab – The CM12 UEFI BitLocker Frontend HTA – Part 1. The features.

Note: This method is more than likely not supported by Microsoft, however it works fine for Windows 8.1×64 in UEFI mode with Secure Boot enabled refreshed to Windows 8.1×64. If you want to refresh Windows 7×64 in UEFI mode then this will also work provided that you disable Secure boot.

The BitLockered UEFI disc problem

What exactly is the problem with UEFI in this scenario ? well, when you network boot (PXE) an UEFI system that is encrypted with BitLocker it will have a drive layout similar to the one below, three volumes (or four partitions depending on how you view it in diskpart) will show up.

From the screenshot above, you can see that one volume appears to have the drive letter C: and has an unknown File System (it’s actually the encrypted BitLocker drive) and another volume (NTFS) that shows up as Windows RE (which is a short label for Windows RE Tools, or the Windows recovery partition), and finally another volume which is the EFI one (FAT32).

Task sequences need to be able to write to the drive and want to write to NTFS drives (not FAT32). So the above drive layout is not ideal for a variety of reasons.

If you try and run any task sequence on the computer above it will most likely fail as the task sequence won’t be able to download any files to a suitable drive and you’ll see failures like the one below after selecting a task sequence.

“<![LOG[Failed to save environment to (80070057)]LOG]!><time=”19:41:50.372-60″ date=”12-19-2014″ component=”TSManager” context=”” type=”2″ thread=”1092″ file=”environmentlib.cpp:697″>
<![LOG[TS::Environment::SharedEnvironment.saveEnvironment(szPath), HRESULT=80070057 (e:\nts_sccm_release\sms\client\tasksequence\executionengine\executionenv.cxx,842)]LOG]!><time=”19:41:50.372-60″ date=”12-19-2014″ component=”TSManager” context=”” type=”0″ thread=”1092″ file=”executionenv.cxx:842″>
<![LOG[Failed to save the current environment block. This is usually caused by a problem with the program. Please check the Microsoft Knowledge Base to determine if this is a known issue or contact Microsoft Support Services for further assistance.
The parameter is incorrect. (Error: 80070057; Source: Windows)]LOG]!><time=”19:41:50.372-60″ date=”12-19-2014″ component=”TSManager” context=”” type=”3″ thread=”1092″ file=”executionenv.cxx:842″>
<![LOG[SaveEnvironment(), HRESULT=80070057 (e:\nts_sccm_release\sms\client\tasksequence\executionengine\executionenv.cxx,420)]LOG]!><time=”19:41:50.372-60″ date=”12-19-2014″ component=”TSManager” context=”” type=”0″ thread=”1092″ file=”executionenv.cxx:420″>
<![LOG[Failed to persist execution state. Error 0x(80070057)]LOG]!><time=”19:41:50.372-60″ date=”12-19-2014″ component=”TSManager” context=”” type=”2″ thread=”1092″ file=”executionenv.cxx:426″>
<![LOG[Failed to save execution state and environment to local hard disk]LOG]!><time=”19:41:50.372-60″ date=”12-19-2014″ component=”TSManager” context=”” type=”2″ thread=”1092″ file=”engine.cxx:249″>

”

The errors are highlighted in red in the screenshot below, but also note what it says about Volume C:\ having an unsupported file system (marked with a greeen box),

In other words, if you UEFI network boot a computer that is encrypted with BitLocker and with a default GPT Layout as per Configuration Manager 2012 R2, then no task sequence will be able to do a refresh (reinstall) scenario as the task sequence engine cannot write to the disk as the only suitable volume (the BitLocker volume) is locked and the other possibly suitable volume is the wrong type (Recovery). Recovery Partitions won’t show up as they are hidden.

The solution

To work around this issue I decided to fool the task sequence into thinking that the recovery drive (Windows RE Tools) was a primary partition instead of a recovery partition as the Windows RE Tools partition was the only other partition that was suitable for use (it was NTFS after all). In addition I swapped some drive letters around before rebooting using the unlocked BitLocker partition.

A quick look in Diskpart reveals the partition layout, notice how partition one is listed as Recovery, this is an actual partition type as detailed here.

You’ll notice that the Windows RE Tools partition here is 2GB in size, I’ve done that deliberately as I know we’ll be storing fairly large boot images here.

For your reference the default UEFI GPT layout in a Configuration Manager 2012 R2 task sequence is shown below

and the same partition setup is as follows in an MDT 2013 integrated task sequence in Configuration Manager 2012 R2

The only real difference between the two is the Partition name (label) for the recovery drive (for the Configuration Manager step its labelled as Windows and the MDT 2013 step it’s labelled as Windows RE Tools). In addition, the MDT Recovery partition is set as a Primary partition instead of Recovery (this is a known bug since MDT 2012 Update 1 with a workaround described in the release notes).

The Format and Partition Disk Step that I use in the task sequence here, contains the following settings, notice that the Windows RE Tools partition is set to Recovery and that it is 2GB in size.

As the testing I’ve done is using the task sequence attached above which uses a MDT task sequence created in Configuration Manager 2012 R2, the corresponding scripts will look for recovery partitions with the label Windows RE Tools but you can easily change them to suit your needs. In addition, I expect that the Windows RE Tools partition type is correctly set as Recovery in your task sequence (instead of Primary).

There are two scripts involved:

ReassignOSDiskandAssignWindowsReTools.vbs
ChangeWindowsReTools.ps1

The ReassignOSDiskandAssignWindowsReTools.vbs script must be run before the task sequence downloads anything, and the ChangeWindowsReTools.ps1 occurs directly after the Setup Windows and ConfigMgr step (in Windows…).

The first script can be run from a network share directly (as that does not require downloading) or injected into the boot wim. In this guide we will use a network share, however you might decide that adding the script to your boot image is less intrusive and quicker.

Step 1. Download the Scripts

Download the following zip, once done unzip it somewhere useful and place the ReassignOSDiskandAssignWindowsReTools.vbs script on a network share. Place the ChangeWindowsReTools.ps1 powershell script in a package and distribute it to your distribution points.

BitLocker_Refresh_In_UEFI_Network_boot.zip 3.34KB 249 downloads

If you want a copy of the task sequence I used for this it’s attached below

The CM12 UEFI BitLocker FrontEnd HTA.zip 281.6KB 249 downloads

Step 2. Modify the task sequence

Directly after the Initialization step, insert a new group by clicking on the drop down Add and choose New Group

name the new group If UEFI and BitLockered as shown below

Click on the options tab and click on Add Condition so that it’s set to If All the conditions are true:,

next add a WMI Query to check for the following

SELECT * FROM Win32_LogicalDisk where DriveType = '3' and FileSystem != 'NTFS' and FileSystem != 'FAT32'

and finally check that the computer is in UEFI mode with the following Task sequence variable _SMSTSBootUEFI = True as shown below

Next add a new step, a Connect to Network Folder step. The share you are connecting to must contain the ReassignOSDiskandAssignWindowsReTools.vbs script.

Fill in the appropriate details for example as shown below, make sure the user specified has READ access to the share.

and next create a Run Command Line step which basically runs our script as shown below

cscript.exe "z:\ReassignOSDiskandAssignWindowsReTools.vbs"

Now that we’ve added the first script, we need to add the second. So Scroll down to the Setup Windows and ConfigMgr step and add a New Group, give it a suitable name like Revert Windows RE Tools as shown below

Next click on the Options tab and check for _SMSTSBootUEFI = True and DeploymentType = Refresh as shown below

and finally we need to add a Run PowerShell Script step which runs our PowerShell script as shown below, this script basically sets our Windows RE Tools drive back to the correct type (Recovery) and cleans out any Configuration Manager temp files found before removing the drive letter.

Step 3. Start testing !

The recovery password of a successfully encrypted BitLocker computer should be stored in the MBAM database and can be viewed in the MBAM database as shown below, you must verify that the RecoveryPassword for the test computer is in the database prior to testing. To get the values into your MBAM database quickly, apply the following registry key on the BitLocker protected computer.

NoStartupDelay.zip 286bytes 160 downloads

Once the recovery key’s are present you’ll be able to verify the values via

manage-bde -protectors -get c:

on the encrypted computer and compare it with the following table in the MBAM database RecoveryAndHardwareCore.Keys, if the values don’t match then don’t bother continuing until they do match. (You can restart the BitLocker Management Client Service to speed things up).

Below is a query you can use if you want to find keys added to the MBAM database after a certain date

use [MBAM Recovery and Hardware];
select a.Id, a.Name, b.VolumeId, c.RecoveryKeyId, c.RecoveryKey, c.LastUpdateTime from RecoveryAndHardwareCore.machines a
inner join RecoveryAndHardwareCore.Machines_Volumes b ON a.Id = b.MachineId
inner join RecoveryAndHardwareCore.Keys c ON b.VolumeId = c.VolumeId
where c.LastUpdateTime >= '2014-12-20'

The RecoveryKey is retrieved from the MBAM database using the following method.

Once done, we can monitor the PXE process by PXE booting a computer that is in UEFI mode and encrypted using BitLocker, as you can see here, the C:\ drive is protected by BitLocker Drive Encryption

Select and then start your new task sequence, once it starts it will connect to our network share and then run the script

At this point the HTA displays and we can actually do things, like select a Refresh (reinstall) scenario, this wouldn’t have been possible without our script which has converted the Windows RE Tools recovery drive to a primary allowing the task sequence write to it (download files from the distribution point and then store them in a temp folder called _SMSTaskSequence).

notice how the partition type ID and GPT attributes are set for a Primary disc (they were set to Recovery previously), in addition, the Windows RE Tools has a drive letter, and OSDisk has swapped to N:

If you didn’t quite get the above, then check out the GPT Partition ID’s listed below for comparison

Primary

PARTITION_BASIC_DATA_GUID
ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

Recovery

PARTITION_MSFT_RECOVERY_GUID
de94bba4-06d1-4d40-a16a-bfd50179d6ac

At this point the drive letters are changed again as per the normal drive reassignment hack in the CM12 BitLocker FrontEnd HTA, in addition, the OSDisk has changed from a filesystem of Unknown (encrypted with BitLocker) to NTFS after unlocking the drive whild still in WinPE, the unlocking of the drive was done via a call to our MBAM server’s database and retrieving the needed data.

Also to note at this point (and for the next while) the Windows RE Tools recovery drive is seen as a primary partition, doing this means that it can have a drive letter assigned to it and that drive letter will remain assigned after a reboot as the drive is treated as a normal primary partition.

After unlocking the drive and reassigning the drive letters, the boot wim is staged in our Windows RE Tools drive and now the computer reboots

Back into WinPE the computer continues the task sequence, at this point the OSDisk is now D: and the Windows RE Tools partition is C:

Next, the task sequence captures the data as it can now read from the unlocked drive

and then it installs the operating system (Windows 8.1 in this case)

After the operating system is installed, Windows Setup will begin detecting devices and doing it’s thing…

and after some time, Setup Windows and ConfigMgr

before it runs our PowerShell script..the purpose of the PowerShell script is to change the Windows RE Tools disc back to it’s correct type (Recovery) and to remove any unwanted temporary OSD files on it and finally to remove the Drive letter assigned to it

before running the step the partition layout looks like so..