Event details
We have rolled out a script to set the Secure Boot registry value AvailableUpdates = 0x5944 and trigger the Secure Boot update scheduled task across ~10,000 devices with Secure Boot already enabled.
The script executes successfully; however, a subset of devices prompts users for the BitLocker recovery key after reboot.
We are trying to proactively prevent this scenario for end users.
We reviewed documentation referencing Secure Boot Event ID 1032 as an indicator of possible recovery prompts, but this event is not present on affected devices prior to reboot.
Our questions:
Is there a reliable way to proactively determine whether a device will request a BitLocker recovery key during the next reboot after applying Secure Boot DB updates?
Are there supported methods to detect potential Secure Boot / firmware trust-chain update failures before reboot so they can be remediated automatically?
There is a section about that in the Secure Boot Troubleshooting document:
https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d#ID0ELBP-button
For Scenario 1 (bug in firmware implementation), you cannot reliably detect it. If you have identified affected firmware vendors/versions, you can mitigate it by disabling or suspending Bitlocker before applying the Secure Boot updates, restart another time when they have been successfully applied, and re-enable Bitlocker. (Note that Microsoft does not endorse increasing your attack surface by disabling or suspending Bitlocker, you will have to do your own risk assessment on that).
For Scenario 2 (There is a PXE server early in the boot sequence which will most of the time do nothing more than trigger BOOTNEXT, and uses a bootloader signed by the 2011 certificates), you can mitigate it by moving Windows Boot Manager to spot 1 in your boot sequence or temporarily blacklist the MAC addresses of your devices from the PXE server's DHCP configuration so that PXE boot is not attempted or uses a bootloader signed by the 2023 certificate.
But in general, there is no reliable way to predict whether Measure Boot TPM resealing is working on your current firmware or not, otherwise Microsoft would probably add a safeguard lock for that :-)
We have also seen an uptick of Bitlocker recovery in our environment since performing the same steps. Can i expect that devices that have previously had Bitlocker recovery not be affected by whatever is going on with the April update?
Since they fixed a bug in that area, you can expect that at least some of those devices won't have issues any more. I guess nobody can predict whether that is more like 5% or like 100% of your devices.
