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

[anyweb]

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.1x64 in UEFI mode with Secure Boot enabled refreshed to Windows 8.1x64. If you want to refresh Windows 7x64 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

 

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

 

The CM12 UEFI BitLocker FrontEnd HTA.zip

 

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

 

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..

 

 

and after the PowerShell script has done its' magic, the changes are in place

 

 

next the User's data is restored using Loadstate

 

 

and the reinstallation is complete !

 

 

allowing us to Login and review things

 

 

job done !

 

Summary

 

Refreshing UEFI based computers encrypted with BitLocker is a challenge, but with some clever thinking and a few scripts it's possible.

 

Related reading

• Secure Boot Overview - http://technet.microsoft.com/en-us/library/hh824987.aspx
• Protecting the pre-OS environment with UEFI - http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx
• PARTITION_INFORMATION_GPT structure - http://msdn.microsoft.com/en-us/library/windows/desktop/aa365449%28v=vs.85%29.aspx
• CM12 in a Lab - The CM12 BitLocker FrontEnd HTA - video
• CM12 in a Lab - The CM12 BitLocker FrontEnd HTA
• CM12 in a Lab - How can I deploy Windows 8 in UEFI mode using Configuration Manager 2012 ?

 

Downloads

 

You can download a Microsoft Word copy of this guide here.

 

How can I reinstall BitLockered UEFI Computers iva PXE boot using System Center 2012 R2 Configuration Manager.zip

[Rstilekar]

Did your steps for my Task Sequence for Win10. Gives issues when trying to reimage Bitlockered machines. We have different boot images in our envionment and the Windows 10 needs to copy the new Boot image after loading into PXE from default boot image and when it is on step Copying to PXE envionrment it fails with error 0x80070490. Below is the smsts.log from failed machine - 

Volume '\\?\Volume{b0d228cc-fffa-4a17-b45e-bf62f26a357d}\' not found    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
Mounting \Device\HarddiskVolume2 at Z:    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
Unmounting volume Z:\    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
Searching for a volume to stage the boot image    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
    Volume C:\ is not NTFS    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
    Volume X:\ is not on a fixed disk    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
BootImage::FindBootableVolume( NULL, sPath), HRESULT=80070490 (..\bootimage.cpp,1135)    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
Unable to find a volume that is suitable for staging the boot image. 
Element not found. (Error: 80070490; Source: Windows)    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
BootImage::PrepareForStaging(sLocalDataPath), HRESULT=80070490 (..\bootimage.cpp,783)    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
Failed to validate for boot image staging    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
StageBootImage() failed. 0x80070490.    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
TS::Boot::BootImage::StageBootImage( pAssociatedWinPE->GetPackageID(), TsBootProgress, pv, hCancelEvent), HRESULT=80070490 (tsmediawizardcontrol.cpp,2252)    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
Failed to stage WinPE. Code(0x80070490)    TSPxe    1/22/2019 9:51:21 AM    1736 (0x06C8)
 

I added the steps that you had but it still fails with same issues. Please suggest.smsts.log