Troubleshooting BitLocker from the Microsoft Endpoint Manager admin center
Published Feb 26 2021 01:42 PM 27.2K Views

By Luke Ramsdale – Service Engineer | Microsoft Endpoint Manager – Intune

 

This is the second in our five-part series about deploying BitLocker with Microsoft Endpoint Manager - Microsoft Intune. Catch up by reading the first post in this series: Enabling BitLocker with Microsoft Endpoint Manager - Microsoft Intune - Microsoft Tech Community. In this post, we’ll look at troubleshooting encryption settings for BitLocker using the Microsoft Intune Encryption report.

 

BitLocker encryption methods

By default, the BitLocker setup wizard prompts users to enable encryption. You can also configure a BitLocker policy that silently enables BitLocker on a device.

 

Note
Automatic encryption is not the same thing as silent encryption. Automatic encryption is performed during Out-Of-Box Experience (OOBE) mode on modern standby or on Hardware Security Test Interface (HSTI)-compliant devices. In silent encryption, Intune suppresses the user interaction through BitLocker configuration service provider (CSP) settings. Each method has different prerequisites.

 

Prerequisites for BitLocker silent encryption

  • A Trusted Platform Module (TPM) chip (version 1.2 or 2.0) that must be unlocked.
  • Windows Recovery Environment (WinRE) must be enabled.
  • The hard disk must be partitioned into an operating system drive formatted with NTFS and a system drive of at least 350 MB must be formatted as FAT32 for Unified Extensible Firmware Interface (UEFI) and NTFS for BIOS.
  • UEFI BIOS is required for TPM version 2.0 devices. (Secure boot is not required but will provide more security.)
  • The Intune enrolled device is connected to Microsoft Azure hybrid services or Azure Active Directory (Azure AD).

 

Prerequisites for user-enabled encryption

  • The hard disk must be partitioned into an operating system drive formatted with NTFS and a system drive of at least 350 MB formatted as FAT32 for UEFI and NTFS for BIOS.
  • Intune enrolled device through hybrid Azure AD join, Azure AD registration, or Azure AD join.

 

Note
A TPM chip is not required but is highly recommended for increased security.

 

Identifying device status

Intune provides a built-in encryption report that presents details about the encryption status of devices across all managed devices. It is a very useful tool that provides an overview of the encryption status. You can use the report to identify and isolate BitLocker encryption failures, the TPM status, and encryption status of Windows devices.

 

Troubleshooting encryption failures

BitLocker encryption failures on Intune enrolled Windows 10 devices can fall into one of the following categories:

  • The device hardware or software does not meet the prerequisites for enabling BitLocker.
  • The Intune BitLocker policy is misconfigured, causing Group Policy Object (GPO) conflicts.
  • The device is already encrypted, and the encryption method doesn’t match policy settings.

 

To identify the category a failed device encryption falls into, navigate to the Microsoft Endpoint Manager admin center and select Devices > Monitor > Encryption report.

 

The report will show a list of enrolled devices. You will be able to answer questions about their encryption status such as:

  1. Is the device encrypted?
  2. Does it have a TPM chip?
  3. Is the device ready for encryption?

    Encryption report exampleEncryption report example

 

Note
If a Windows 10 device displays a Not ready status, it might still support encryption. For a Ready status, the Windows 10 device must have TPM activated. TPM devices aren't required to support encryption but are highly recommended for increased security.

 

The above example shows that a device with TPM version 1.2 has been successfully encrypted. Additionally, you can see two devices not ready for encryption and will not be able to be encrypted silently and that one TPM 2.0 device is ready for encryption but not encrypted.

 

Common failure scenarios

Next, let’s look at a few common failure scenarios. Each scenario details the encryption report status.

 

Scenario 1 – Device is not ready for encryption and not encrypted

When you click on a device that is not encrypted, Intune displays a summary of its status. In the example below, there are multiple profiles targeting the device: an endpoint protection policy, a Mac operating system policy (which is not applicable to this device), and a Microsoft Defender Advanced Threat Protection (ATP) baseline.

 

Scenario 1 - Device is not ready for encryption and not encryptedScenario 1 - Device is not ready for encryption and not encrypted

 

Encryption status explained:

The messages under Status details are codes returned by the BitLocker CSP’s status node from the device. The encryption status is in an error state because the OS volume is not encrypted. Additionally, the BitLocker policy has requirements for a TPM that are not satisfied by the device.

 

The messages mean that the device is not encrypted because it doesn’t have a TPM present and the policy requires one.

 

Scenario 2 – Device is ready but not encrypted.

This example shows that the TPM 2.0 device is not encrypted.

 

Scenario 2 – Device is ready but not encrypted.Scenario 2 – Device is ready but not encrypted.

 

Encryption status explained:

This device has a BitLocker policy that is configured for user interaction rather than silent encryption. The user has not started or completed the encryption process (the user receives a notification message), so the drive remains unencrypted.

 

Scenario 3 – Device is not ready and will not encrypt silently. 

If an encryption policy is configured to suppress user interaction and encrypt silently and the encryption report Encryption readiness state is Not applicable or Not ready, it is likely the TPM is not ready for BitLocker.

 

Scenario 3 – Device is not ready and will not encrypt silently.Scenario 3 – Device is not ready and will not encrypt silently.

 

Clicking on the device reveals the following reason:

 

Scenario 3 - Device encryption statusScenario 3 - Device encryption status

 

Encryption status explained: 

If the TPM is not ready on the device, it could be because it is disabled in the firmware or needs to be cleared or reset. Running the TPM management console (TPM.msc) from the command line on the affected device will help you understand and resolve the TPM state.

 

Scenario 4 – The device is ready but not encrypted. 

There are several reasons that a device targeted with silent encryption is ready and not encrypted.

 

Scenario 4 – The device is ready but not encrypted.Scenario 4 – The device is ready but not encrypted.

 

Encryption status explained: 

One explanation is that WinRE is not enabled on the device, which is a prerequisite. You can validate the status of WinRE on the device using the reagentc.exe/info command as an administrator: 

 

Command Prompt output of reagentc.exe/infoCommand Prompt output of reagentc.exe/info

 

If WinRE is disabled, run the reagentc.exe/info command as administrator.

 

Enabling WinRE in Command PromptEnabling WinRE in Command Prompt

 

The Status details page will display the following information if WinRE is not configured correctly: 

The user logged into the device does not have admin rights.

 

Another reason could be administrative rights. If your BitLocker policy is targeting a user who does not have administrative rights and Allow standard users to enable encryption during Autopilot is set to not configured, you will see the following in the encryption status:

 

Device encryption status - User that does not have admin rights.Device encryption status - User that does not have admin rights.

 

Encryption status explained: 

Switching Allow standard users to enable encryption during Autopilot to Yes will resolve this issue for Azure AD joined devices.

 

Scenario 4 – The device is in an error state but encrypted. 

In this common scenario, if the Intune policy is configured for XTS-AES 128-bit encryption and the device it is targeting is encrypted is using XTS-AES 256-bit encryption (or the reverse), you will receive the error shown below.

 

Scenario 4 – The device is in an error state but encrypted.Scenario 4 – The device is in an error state but encrypted.

 

Encryption status explained: 

This happens when a device that has already been encrypted using another method—either manually by the user, with Microsoft BitLocker Administration and Monitoring (MBAM), or by the Microsoft Endpoint Configuration Manager before enrollment.

 

To rectify this, decrypt the device manually or by using Windows PowerShell. Then let the Intune BitLocker encrypt the device again the next time the policy reaches it.

 

Scenario 5 – The device is encrypted but the profile state is in error. 

Occasionally a device appears encrypted but has an error state in the summary.

 

Scenario 5 – The device is encrypted but the profile state is in error.Scenario 5 – The device is encrypted but the profile state is in error.

 

Encryption status explained: 

This usually occurs when the device has been encrypted by another means (possibly manually). The settings match the current policy, but Intune has not initiated the encryption.

 

Conclusion 

The encryption report is a useful starting point for troubleshooting encryption failures.  In some cases, you will need to investigate the device further to understand the reasons for failure.

 

To take full advantage of this troubleshooting method and the error details available in the encryption report, you will need to configure a BitLocker policy. If you are currently using a device configuration policy, consider migrating the policy. To perform either task, navigate to the Microsoft Endpoint Manager admin center and select Endpoint security > Disk encryption.

 

More info and feedback

For further resources on this subject, please see the links below.

Encrypt Windows 10 devices with BitLocker in Intune

Intune endpoint security disk encryption policy settings

Microsoft Defender for Endpoint

BitLocker cannot encrypt a drive known TPM issues

Troubleshooting tips for BitLocker policies in Microsoft Intune

 

The next post will cover troubleshooting from the client side. Stay tuned! Here’s the series:

 

Let us know if you have any additional questions by replying to this post or reaching out to @IntuneSuppTeam on Twitter.

17 Comments
Iron Contributor

Good info.

Silver Contributor

Thank you for sharing.

The primary design and data are easy to use and read.

It would be nice to have some sort of Power BI integration or some diagrams to show overall status of devices and show with icons like readiness errors and so on.

Microsoft

Excellent information for TS and know the status of bitlocker on each device.

Copper Contributor

Excellent ! The third part is not available yet ?

Copper Contributor

Hi,

What does it mean when the device is Ready, the Policy state is succeeded but the OS volume is still unprotected and there are no other messages?

 

Thanks

Dave

 

 

 

Microsoft

@David Beck Usually this means the user has not initiated the encryption using the notification provided if the policy is configured for user interaction. It worth checking they have admin rights on the device too, it could be that they can't launch the BitLocker wizard because of this. Check out the third blog in the series for client side troubleshooting and what logs are useful to check what is happening on the device.

Copper Contributor

Thanks Luker1, I had initially tried the silent method but then switched to the interactive method which as you say kept failing, when I reviewed the event logs for Bit Locker there were numerous errors in there regarding conflicting group policies, no matter what changes I made I could not get these to go away. 
In the end I removed the policy completely (This had been created in the Endpoint Security..Disk encryption area) and created a new policy in the more traditional way in the Devices..Configuration profiles area, as soon as I did this the policy was applied successfully and silently although it can take a while to mark compliant as I assume it takes its time over encrypting the drive.

Thanks David

 

 

Microsoft

@David Beck The group policy conflicts are almost certainly caused by conflicting settings in the startup authentication settings, either set these all to allow or set the compatible TPM startup to required and the rest to block (more about this in an upcoming blog).

 

I would strongly recommend using the endpoint protection rather than device config because all the new features will be added here and not device config. 

 

Also make sure you dont have conflicting policies deployed which may cause confusion about what settings are being applied.

Copper Contributor

@Luker1 Thanks I will look out for the new blog.

 

As I did not change anything else other than remove and re-create a policy it is difficult to see how one of the settings or another policy conflict could come into play, of course I may have configured the new policy slightly differently from the off but I believe it was the same.

I now have 50 laptops going live on Friday so don't really want to change anything now, I will set up a test area and try the policy in the Endpoint area again, this is what I wanted to do as it does appear to be the correct place to create it.

Thanks for your input. David

Hi @Olivia_Friedmann and @David Beck, thanks for the feedback! Part 3 has been posted here: Troubleshooting BitLocker policies from the client side. Let us know if you have any additional questions or feedback by replying to that post!

Copper Contributor

Hello,

What do these two scenario mean:

 

Scenario 1:
Encryption Readiness: Ready
Encryption Status: Encrypted
Policy state: Pending
Bitlocker state: The encryption method of the OS volume doesn't match the BitLocker policy

 

Scenario 2:
Encryption Readiness: Ready
Encryption Status: Encrypted
Policy state: Succeeded
Bitlocker state: The encryption method of the OS volume doesn't match the BitLocker policy

 

2 scenarios only differs in Policy state. All the rest are the same.


Thanks.

Mark

Microsoft

@mamark If you have made a change to the policy and the device has not yet checked in since the change was made then the policy will switch to pending until the device syncs again.

Copper Contributor

@Luker1 Thanks. Will take note of that.

 

Does this mean that regardless of its policy state, if the Bitlocker state says "The encryption method of the OS volume doesn't match the BitLocker policy", there is a mismatch on the encryption method that was configured in the policy and on the target device?

Microsoft

@mamark Correct, if the policy is configured for 256 and the device encrypted with 128, via some other method other than the policy, (or vice versa) then you will see this message. You can decrypt the device and then sync it to allow the policy to configure it to get around this.

Copper Contributor

Thanks a lot @Luker1 . Big help!

Copper Contributor

Hi,

What does it mean when the device is Ready, the Policy state is succeeded but the OS volume is still unprotected and there are no other messages?

Still have the same issue.

812: 

BitLocker cannot use Secure Boot for integrity because the UEFI variable 'SecureBoot' could not be read.

 

851: 

Failed to enable Silent Encryption.

Error: Group policy prevents you from backing up your recovery password to Active Directory for this drive type. For more info, contact your system administrator..

 

Vérification:

- winre: OK

-tpm version: 2.0

- rule assigned: Ok

- bios type: uefi

Copper Contributor

@Ngoug88 

812: 

BitLocker cannot use Secure Boot for integrity because the UEFI variable 'SecureBoot' could not be read.

This is ok. SecureBoot is no required.

 

851: 

Failed to enable Silent Encryption.

Error: Group policy prevents you from backing up your recovery password to Active Directory for this drive type. For more info, contact your system administrator.

This error is occurs because required settings cannot be configured in Endpoint security | Disk encryption for hybrid joined devices. You need to go to Devices | Configuration profiles, create a new policy from templates.

 

namikou1610_0-1705061969425.png

This will save the recovery key to Azure AD

 

Version history
Last update:
‎Dec 19 2023 01:29 PM
Updated by: