Mystery Solved: Bitlocker is enabled, but Intune shows the computer as non-compliant for Require Bitlocker
For some time, I have struggled to understand why Intune reports some computers as non-compliant with the "Require Bitlocker" setting, even though Bitlocker is enabled and working on the computer. In my searches for an explanation, I found the same question asked by many others, but never an answer. Until today.
I accidentally stumbled across this article from Microsoft's Rob Lane, which explains how the Require Bitlocker setting is evaluated and why it might seem to incorrectly report a non-compliant state. I encourage you to check out that article for full details. I'll just summarize here the part that suddenly made this bitlocker compliance issue make sense to me.
This means that if Bitlocker protection is suspended when a computer restarts, even if protection is automatically resumed after the restart, Intune will report the computer as not compliant with the Require Bitlocker setting until the next time the computer is restarted.
Here's why this could be a very common situation in environments managed by SCCM. As we all know, Windows Updates often require restarting the computer to complete installation. If Bitlocker is enabled & has an active PIN protector, the computer will prompt for the Bitlocker PIN as part of the restart. Until a user sees the prompt & enters the PIN, the computer can't boot back up, much less finish applying updates.
To get around this issue, when an update requires a restart SCCM will suspend bitlocker protection on the drive before restarting the computer. This allows the computer to restart, finish applying updates, and return to the Windows login screen automatically, with no user intervention required. Once the updates are applied and Windows fully loaded, SCCM automatically resumes bitlocker protection.
During that restart, the DHA service will check whether the drive is being protected by bitlocker. Since protection is suspended, it records the drive as not protected. Protection is resumed once Windows boots, but the DHA service doesn't know that. It will report the computer as non-compliant until it checks again when the computer next restarts.
Putting it all together, this means that after Windows Updates are deployed using SCCM, it is to be expected that computers appear in intune as non-compliant with the Require Bitlocker setting. Updating that compliance status will require restarting the computer again, without suspending bitlocker. This could be done by the users or automatically from remote. Just be aware that if you restart the computers remotely, they won't boot back up until a user is present at the keyboard and enters the Bitlocker PIN to grant access to the drive.
I accidentally stumbled across this article from Microsoft's Rob Lane, which explains how the Require Bitlocker setting is evaluated and why it might seem to incorrectly report a non-compliant state. I encourage you to check out that article for full details. I'll just summarize here the part that suddenly made this bitlocker compliance issue make sense to me.
- The "Require Bitlocker" setting in Intune relies on the Device Health Attestation (DHA) service in Windows 10 to report the state of Bitlocker encryption on the computer.
- If Bitlocker protection is disabled or suspended, DHA will report that the computer is non-compliant with this setting.
- The DHA service only checks the Bitlocker state at boot time. This means that if the state changes after the computer boots, DHA will continue to report the old state until the next time the computer restarts.
This means that if Bitlocker protection is suspended when a computer restarts, even if protection is automatically resumed after the restart, Intune will report the computer as not compliant with the Require Bitlocker setting until the next time the computer is restarted.
Here's why this could be a very common situation in environments managed by SCCM. As we all know, Windows Updates often require restarting the computer to complete installation. If Bitlocker is enabled & has an active PIN protector, the computer will prompt for the Bitlocker PIN as part of the restart. Until a user sees the prompt & enters the PIN, the computer can't boot back up, much less finish applying updates.
To get around this issue, when an update requires a restart SCCM will suspend bitlocker protection on the drive before restarting the computer. This allows the computer to restart, finish applying updates, and return to the Windows login screen automatically, with no user intervention required. Once the updates are applied and Windows fully loaded, SCCM automatically resumes bitlocker protection.
During that restart, the DHA service will check whether the drive is being protected by bitlocker. Since protection is suspended, it records the drive as not protected. Protection is resumed once Windows boots, but the DHA service doesn't know that. It will report the computer as non-compliant until it checks again when the computer next restarts.
Putting it all together, this means that after Windows Updates are deployed using SCCM, it is to be expected that computers appear in intune as non-compliant with the Require Bitlocker setting. Updating that compliance status will require restarting the computer again, without suspending bitlocker. This could be done by the users or automatically from remote. Just be aware that if you restart the computers remotely, they won't boot back up until a user is present at the keyboard and enters the Bitlocker PIN to grant access to the drive.
Comments
Post a Comment