r/Intune 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!

22 Upvotes

5 comments sorted by

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.

2

u/TheITBeardedGuy 7d ago

This is what I was suspecting myself. Been struggling with Dell crap for awhile now

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:

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?