Bitlocker Is Not Resuming After Reboot Count Has Been Reached

Hi,

I'm Helmut Wagensonner, a Cloud Solution Architect Engineer at Microsoft. Recently, I ran into an unexpected Bitlocker behavior at a customer. It turned out that this behavior is on purpose so I thought I let you know about it, even if you may never run into it.

BitLocker is a feature in Windows 10/11 that encrypts your device’s hard drive to protect your data from unauthorized access. However, there are some scenarios where you may need to suspend BitLocker temporarily, such as when you update your BIOS or firmware using a vendor’s update utility. When you suspend BitLocker, you can specify how many times your device can restart before BitLocker resumes encryption. This is called the reboot count parameter. You can set this parameter using the PowerShell cmdlet Suspend-BitLocker (https://learn.microsoft.com/en-us/powershell/module/bitlocker/suspend-bitlocker?view=windowsserver2022-ps). Following example would suspend Bitlocker until the client has been rebooted 3 times:

Suspend-Bitlocker -MountPoint "C:" -RebootCount 3

However, there is a known issue with BitLocker that you may encounter: BitLocker does not resume automatically after suspending when OOBE (Out of box experience) is not complete. OOBE is the process of setting up your device for the first time after installing Windows 10. This means that your device will remain unprotected until you manually resume BitLocker. To do this, you have the option to use the manage-bde command line tool from an elevated command prompt.

manage-bde -resume C:

Or use the Powershell command Resume-Bitlocker (https://learn.microsoft.com/en-us/powershell/module/bitlocker/resume-bitlocker?view=windowsserver2022-ps)

Resume-BitLocker -MountPoint "C:"

To check how many reboots are left before BitLocker resumes encryption, you can use the GetSuspendCount method of the Win32_EncryptableVolume WMI class (https://learn.microsoft.com/en-us/windows/win32/secprov/getsuspendcount-win32-encryptablevolume). For example, this PowerShell command will show you the number of reboots left for drive C:

Get-CimInstance -Namespace "ROOT/CIMV2/Security/MicrosoftVolumeEncryption" -Class Win32_EncryptableVolume -Filter "DriveLetter='C:'" | Invoke-CimMethod -MethodName "GetSuspendCount"

As mentioned at the beginning of this blog, you may never run into this issue because there are very few situations where you need to manually suspend Bitlocker when OOBE has not completed. One situation is, for example:

• You deploy a Windows 10/11 PC (fresh installation) via Config Manager Task Sequence. You activate Bitlocker during the task sequence.
• At the end of the installation you need to install device drivers not available on Windows Update. Or you want to update the BIOS with the vendor's update tool.
• You suspend Bitlocker with the "-rebootcount 1" parameter before you trigger the driver/BIOS installation.
• You do a manual reboot at the end of the installation.

The expected behavior would be, that Bitlocker is active after the reboot (because of the -rebootcount 1 option). However, this may not be the case as no user has logged on to the client before and user OOBE has not completed. Bitlocker remains in suspended mode until manually resumed (i.e. using Powershell’s resume-bitlocker command).

Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.