Bitlocker Recovery with PXE

Copper Contributor

I discovered an issue with Bitlocker and PXE. I use ConfigMgr required deployments to start ZeroTouch OSD. To allow zero touch here we configured PXE to be the first in the boot order. So adding a computer to the OSD collection (or reverting the PXE boot flag) will start the deployment. During the deployment Windows Setup puts Windows Boot Manager as first UEFI boot device, and the TS enabled Bitlocker with TPM protection. At the end of the TS we configure PXE to be the first boot device again. Now comes the issue… as soon Bitlocker tries to unlock then it runs into recovery. I figured out, that this only happens, if a required deployment did already run and now the PXE flag prevents it from PXE booting (PXEAbort). So in SMSPXE.log we can see it send abortpxe.com to the client. If I assign a second, available deployment, PXE waits for "ENTER" to boot. If I do not press ENTER it just boots up fine without Bitlocker Recovery. If I remove the deployment from the client it also boots fine.

So I suppose, that abortpxe.com is somehow "untrusted" by the Bitlocker boot process.

The workaround to have an optional deployment in parallel is good, as long nobody presses ENTER, because if this was done it will boot into WinPE and run the other mandatory deployment then (and delete the client accidently).

4 Replies
I believe the issue is that you may be enabling BitLocker then changing the boot order. You can either change the boot order before starting BitLocker in the TS or configure BitLocker, then disable protectors, change boot order, reboot, re-enable protectors.

If you make any changes to boot order while BitLocker is protecting the drive, you will get prompted for recovery unless you disable protectors first.

Does not like this is the cause. Changing the activation as described, did not change the behavior. In fact, to me it seems, that as soon abortpxe.com is loaded the trust to TPM somehow is broken. If PXE responds, but does not provide a bootimage (if client is unknown) this does not happen. So if we could tweak SCCM to not send abortpxe.com when a system is known, but does not need to boot PXE that will likely solve the issue (just let it time-out).

@Tobias Abele 

We have encountered the same issue in our environment. It is clearly the pxeabort signal that triggers bitlocker recovery. If I boot with no ethernet cable, Bitlocker recovery does not trigger at all. I've added my support to the UserVoice suggestion that was probably created by you. https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/38526007-fix-bitlocker-re...

@Tobias Abele can you please provide the BitLocker Configuration you use? I know, it might not seem like it, but it is important that the configuration is correct even in that phase of the boot process.

 

Regards

Martin