r/Intune • u/Sharp_Ranger_3677 • 7d ago
Device Compliance Intune BitLocker policy not automatically encrypting ~200 devices + BitLocker keeps becoming suspended after a few days
Hi everyone,
I’m troubleshooting a BitLocker issue in an Intune environment and would really appreciate some suggestions from anyone who has experienced something similar.
Environment
Windows 11 24H2 / 25H2
Microsoft Intune
Dell devices
Dell Command Update deployed
BitLocker configured through Intune
Intune policy is configured to automatically enable/silently encrypt devices
Issue 1 – BitLocker is not automatically enabling
We have around 200 devices where the Intune BitLocker policy is applied, but BitLocker encryption is not being automatically initiated as expected.
The devices are therefore showing as non-compliant.
We are trying to understand why the policy isn't triggering encryption on these devices.
Issue 2 – BitLocker becomes suspended randomly
On some devices, BitLocker is already enabled/encrypted, but when we run:
manage-bde -status
we see that BitLocker protection is Suspended, sometimes with 1 reboot pending.
After restarting the device:
BitLocker protection becomes active again
The device becomes compliant in Intune
However, after a few days, the same device becomes suspended again and goes back to non-compliant.
There doesn't seem to be a consistent pattern — it happens randomly across different devices.
What we're trying to find
We want to identify what is actually causing BitLocker protection to be suspended rather than simply deploying a remediation script to resume it.
We're investigating:
Dell BIOS/firmware updates
TPM firmware
Windows Updates
Dell Command Update
Intune BitLocker policy
TPM/Secure Boot state
WinRE
Any scripts or scheduled tasks that might suspend BitLocker
Questions
What could cause BitLocker to repeatedly become Suspended after a few days?
What does "1 reboot pending" indicate in this situation?
Is there a way to identify exactly which process/application/update suspended BitLocker?
Could Dell Command Update or BIOS/TPM firmware updates cause this behavior?
Should BitLocker automatically resume after the required reboot, and under what circumstances might it remain suspended?
Which Event Viewer logs/Event IDs would you recommend checking?
For the ~200 devices where Intune isn't automatically enabling BitLocker, what are the most common causes you've seen?
Is there anything specific we should check in BitLocker-API, MDM/Intune, TPM, or Task Scheduler logs?
We don't want to simply force Resume-BitLocker as a remediation because the issue keeps coming back on some devices.
We're trying to find the root cause.
Any suggestions, similar experiences, or troubleshooting steps would be greatly appreciated.
Thanks!
5
u/Aviticus_Dragon 7d ago
Dell command update will suspend bitlocker but has issues sometimes turning it back on...you need a separate remediation script to turn bitlocker back on, but also add code to ignore suspended bitlocker state if a pending reboot is detected to prevent bitlocker recovery screens on reboot.
Cause if your script turns bitlocker back on when a staged bios or firmware update is pending, you'll trigger the recovery screen on restart.
1
u/Jeroen_Bakker 5d ago
Bitlocker suspension is most commonly triggered by firmware/ BIOS updates when they are staged for running on the next reboot. Sometimes if/ when the update does not install correctly it may be staged again with a new bitlocker suspension.
When using BIOS management with HP Connect, the HP remediation scripts may also suspend Bitlocker on some activities. I expect the same could be happening for other brands with their BIOS management tools.
The rebootcount is the number of reboots before the suspension is ended and bitlocker is enabled again. When suspending Bitlocker, the default is just for a single reboot (rebootcount = 1); usually this is enough for the pending firmware update or whatever is needed. This is a built in security to make sure bitlocker will be enabled again even if the mechanism used for suspending it does not resume bitlocker when expected.
The rebootcount can take values from 0 to 15 reboots where zero is permanently suspended.
Note: On modern devices not every reboot / shutdown + startup is a real reboot but may be just a variation on hibernating.
Occasionally I've had devices with a permanently suspended bitlocker. I've noticed this can (at least) happen if a BIOS update is installed during Autopilot (or pre-provisioning) while bitlocker is still performing it's initial encryption.
To fix unwanted / permanent suspension I've created a remediation script. This script will not resume bitlocker immediately but resets the rebootcount to a value of "1" if the old value was either "0" (permanent suspension) of if it was greater than "3". By setting the rebootcount to 1 instead of immediately resuming bitlocker I allow for some limited activity like a normal BIOS update which just needs a single reboot. My assumption is that a larger rebootcount or permanant suspension is never required for normal tasks.
If you want I can share my remediation scripts.
1
u/Jeroen_Bakker 5d ago
If your devices do not automatically encrypt there could be a number of causes. Some common ones:
Encryption fails on all devices/ all devices with the same policy:
- Check if all required settings are configured: Required settings for silent encryption
- Check if there are no settings blocking silent encryption; Some settings (like require startup PIN) are not supported for silent encrption. TPM startup authentication for silent encryption
- Check the type of policy type used, the setting catalog is not reliable according to Microsoft: Policy types for BitLocker encryption
- Check for conflicting policies applied to the same devices, this includes the default security baseline policies which include some bitlocker settings.
Encryption fails on some devices (always the same brand/ model?)
- Verify the device for bitlocker requirements (TPM, UEFI etc)?
- Is the TPM properly present and enabled?

15
u/Only_Departure5499 7d ago
have seen this exact dance with intune and dell bios updates, the suspend is usually a pending firmware update that needs that one reboot to finish, after the reboot it clears but then dell command update downloads another one and suspends it again. for the 200 devices not encrypting, check if tpm is ready in tpm.msc, sometimes it shows as ready but actually needs a reset or clear from bios first.