By Luke Ramsdale – Service Engineer | Microsoft Endpoint Manager – Intune
This is the third blog in our series on using BitLocker with Microsoft Endpoint Manager - Microsoft Intune. In the last post, we described how to effectively troubleshoot common scenarios using the Microsoft encryption report in the Microsoft Endpoint Manager admin center. Now we’ll look at common issues, the logs and data you need to collect, and the steps you can take to troubleshoot BitLocker encryption on the client side.
The following steps describe the flow of events that should result in a successful encryption of a Windows 10 device that has not been previously encrypted with BitLocker:
The encryption report identifies common troubleshooting scenarios that are documented in the BitLocker configuration service provider (CSP) status node. However, some status scenarios might not be reported and you will need access to the device to investigate further.
There is already extensive documentation available for troubleshooting BitLocker encryption policies. You can check out Intune troubleshooting tips or follow guidelines from a Windows perspective to help isolate issues when enabling BitLocker using Intune.
If you determine that there is no actionable information in the encryption report to understand why BitLocker was not enabled, the next step is to access an affected device and gather the required data to complete the investigation.
If a device is accessible, you can initiate a sync with the Intune service manually from your Windows device by selecting Settings > Accounts> Access work or school > Connect <tenant> Azure AD > Info before collecting the data.
Mobile device management (MDM) agent event log
The MDM event log is useful to determine if there’s been an issue processing the policy sent from Intune. The OMA DM agent will connect to the Intune service and attempt to process the policies targeted at the user or device. Success and failures processing Intune policies will be found in this log.
Once the sync is complete, collect or review the following information:
LOG > DeviceManagement-Enterprise-Diagnostics-Provider admin
To filter this log, right-click the event log and select Filter Current Log > Critical/Error/Warning. Then search through the filtered logs for BitLocker (press F3 and enter the text).
Errors in BitLocker settings will follow the format of the BitLocker CSP, so you will see entries like this:
./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption
or
./Vendor/MSFT/BitLocker/ConfigureRecoveryPasswordRotation
Note
You can also enable debug logging for this event log using the Event Viewer for troubleshooting.
BitLocker-API management event log
This is the main event log for BitLocker. If the policy has been processed by the MDM agent and there are no errors in the DeviceManagement-Enterprise-Diagnostics-Provider admin event log, this is the next log to investigate.
LOG > BitLocker-API management
Usually, errors are logged here if there are hardware or software prerequisites missing that the policy requires such as Trusted Platform Module (TPM) or Windows Recovery Environment (WinRE). As you can see in the following example, conflicting policy settings that cannot be implemented during silent encryption and manifest as group policy conflicts are also logged:
Failed to enable Silent Encryption.
Error: BitLocker Encryption cannot be applied to this drive because of conflicting Group Policy settings. When write access to drives not protected by BitLocker is denied, the use of a USB startup key cannot be required. Please have your system administrator resolve these policy conflicts before attempting to enable BitLocker.
Resolution: Configuring the compatible TPM startup PIN to Blocked will resolve conflicting Group Policy settings when using silent encryption.
Configuring the TPM startup PIN and startup key to Allowed and other startup key and PIN setting to Blocked for user interaction and will result in a conflicting Group Policy error in BitLocker-AP event log.
Also, if you configure TPM startup PIN or startup key to require user interaction, it will cause silent encryption to fail. You must set the PIN and TPM startup key to Blocked if silent encryption is required.
Configuring any of the compatible TPM settings to Required will cause silent encryption to fail.
TPM not available
Another common errorin the BitLocker-API log is that the TPM is not available. The following example shows that TPM is a requirement for silent encryption:
Failed to enable Silent Encryption. TPM is not available
Error: A compatible Trusted Platform Module (TPM) Security Device cannot be found on this computer.
Resolution: Ensure there is a TPM available on the device and if it is present check the status via TPM.msc or the PowerShell cmdlet get-tpm.
Un-Allowed DMA capable bus
If the BitLocker-API log displays the status: Un-Allowed DMA capable bus/device(s) detected, it means that Windows has detected an attached Direct memory access (DMA)-capable device that might expose a DMA threat.
Resolution: To remediate this issue, first verify that the device has no external DMA ports with the original equipment manufacturer (OEM). Then follow these steps to add the device to the allowed list. Note: Only add a DMA device to the allowed list if it is an internal DMA interface/bus.
System event log
If you’re having hardware-related issues—such as problems with the TPM—errors will appear in the system event log for TPM from the TPMProvisioningService or TPM-WMI source.
LOG > System event
Resolution: Filter on these event sources to help identify any hardware-related issues that the device may be experiencing with the TPM and check with the OEM manufacturer whether there are any firmware updates available.
Task scheduler operational event log
The task scheduler operational event log is useful for troubleshooting scenarios where the policy has been received from Intune, but BitLocker encryption has not successfully initiated. BitLocker MDM policy refresh is a scheduled task that should run successfully when the MDM agent syncs with the Intune service.
The log is worth investigating when:
The BitLocker policy appears in the DeviceManagement-Enterprise-Diagnostics-Provider admin event log, in MDM diagnostics, and the registry.
There are no errors (i.e., the policy has been picked up successfully from Intune).
Nothing is logged in the BitLocker-API event log to show that encryption was even attempted.
LOG > Task scheduler operational event
Important
You must manually enable this event log before logging anything because the log will identify any problems running the BitLocker MDM policy Refresh scheduled task.
When the run is complete, inspect the Last Run Result column for any error codes and examine the task schedule event log for errors.
In the example above, 0x0 has run successfully. The error 0x41303 this means the task has never previously run.
Note
Check out this article for more information about Task Scheduler error messages.
MDM Diagnostics Report
You can create a report of MDM logs to diagnose enrollment or device management issues in Windows 10 devices managed by Intune. The MDM Diagnostic Report contains useful information about an Intune enrolled device and the policies deployed to it.
File system location: C:\Users\Public\Documents\MDMDiagnostics
The operating system (OS) build and edition in encryption failures: It’s important to investigate the OS build and edition because some CSPs were introduced on specific versions of Windows and will only work on a certain edition. For example, the bulk of BitLocker CSP settings were introduced in Windows 10, version 1703 but these settings weren’t supported on Windows 10 Pro until Windows 10, version 1809.
Additionally, there are settings such as AllowStandardUserEncryption (added in version 1809), ConfigureRecoveryPasswordRotation (added in version 1909), RotateRecoveryPasswords (added in version 1909), and Status (added in version 1903).
Checking if your Windows version and edition supports the settings configured in your policy is the first step in understanding why they are not applying correctly.
Investigating with the EntDMID: This is a unique device ID for Intune enrollment. You can use the EntDMID to search through the All Devices view in the Microsoft Endpoint Manager admin center to identify a specific device. It is also a crucial piece of information for Microsoft support to enable further troubleshooting on the service side if a support case is required.
You can also use the MDM Diagnostic Report to identify whether a policy has been successfully sent to the device with the settings the administrator configured. By using the BitLocker CSP as a reference, you can decipher which settings have been picked up when syncing with the Intune service. This article discusses this topic in more detail. You can use the report to determine if the policy is targeting the device and identify what settings have been configured using the BitLocker CSP documentation.
MSINFO32
MSINFO32 is an information tool that contains device data you can use to determine if a device satisfies BitLocker prerequisites. The required prerequisites will depend on BitLocker policy settings and the required outcome. For example, silent encryption for TPM 2.0 requires a TPM and Unified Extensible Firmware Interface (UEFI).
However, if this item doesn’t meet the prerequisites, it doesn’t necessarily mean that you can’t encrypt the device using an Intune policy.
TPM.MSC file
TPM.msc is a Microsoft Management Console (MMC) Snap-in file. You can use TPM.msc to determine whether your device has a TPM, to identity the version, and whether it is ready for use.
As we discussed in previous blogs, having a TPM is not a prerequisite for BitLocker but is highly recommended due to the increased security it provides.
Having a TPM is required for silent and automatic encryption. If you’re trying to encrypt silently with Intune and there are TPM errors in the BitLocker-API and system event logs, TPM.msc will help you understand the problem.
The following example shows a healthy TPM 2.0 status. Note the specification version 2.0 in the bottom right and that the status is ready for use.
This example shows an unhealthy status when the TPM is disabled in the BIOS:
Configuring a policy to require a TPM and expecting BitLocker to encrypt when the TPM is missing or unhealthy is one of the most common issues.
Get-Tpm cmdlet
A cmdlet is a lightweight command in the Windows PowerShell environment. In addition to running TPM.msc, you can verify the TPM using the Get-Tpm cmdlet. You will need to run this cmdlet with administrator rights.
In the example above, you can see that the TPM is present and active in the PowerShell window. The values equal True. If the values were set to False, it would indicate a problem with the TPM. BitLocker will not be able to use the TPM until it is present, ready, enabled, activated, and owned.
Manage-bde command-line tool
Manage-bde is a BitLocker encryption command line tool included in Windows. It’s designed to help with administration after BitLocker is enabled.
You can use manage-bde to discover the following information about a device:
In the following example, the device is not encrypted:
This is the first place in the registry to look when you want to decipher the policy settings picked up by Intune.
The MDM agent registry key will help you identify the Globally Unique Identifier (GUID) in the PolicyManager that contains the actual BitLocker policy settings.
The GUID is highlighted in the above example. You can include the GUID (it will be different for each tenant) in the following registry subkey to troubleshoot BitLocker policy settings:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\<GUID>\default\Device\BitLocker
This report shows the BitLocker policy settings that have been picked up by the MDM agent (OMADM client). These are the same settings that you will see in the MDM Diagnostic report, so this is an alternative way of identifying settings that the client has picked up.
Example of EncryptionMethodByDriveType registry key:
<enabled/><data id="EncryptionMethodWithXtsOsDropDown_Name" value="6"/><data id="EncryptionMethodWithXtsFdvDropDown_Name" value="6"/><data id="EncryptionMethodWithXtsRdvDropDown_Name" value="3"/>
SystemDrivesRecoveryOptions:
<enabled/><data id="OSAllowDRA_Name" value="true"/><data id="OSRecoveryPasswordUsageDropDown_Name" value="2"/><data id="OSRecoveryKeyUsageDropDown_Name" value="2"/><data id="OSHideRecoveryPage_Name" value="false"/><data id="OSActiveDirectoryBackup_Name" value="true"/><data id="OSActiveDirectoryBackupDropDown_Name" value="1"/><data id="OSRequireActiveDirectoryBackup_Name" value="true"/>
BitLocker registry key
The settings in the policy provider registry key will be duplicated into the main BitLocker registry key. You can compare the settings to ensure they match what appears in the policy settings in the user interface (UI), MDM log, MDM diagnostics and the policy registry key.
This is an example of the FVE registry key:
Registry key location: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE
You can decode all of the setting names in the registry using the BitLocker CSP documentation.
REAgentC.exe command line tool
REAgentC.exe is a command line executable tool that you can use to configure the Windows Recovery Environment (Windows RE). WinRE is a prerequisite for enabling BitLocker in certain scenarios such as silent or automatic encryption.
Location: Right-click on Start > Run > enter cmd > right-click cmd and select Run as administrator > reagnetc /info.
File system location: C:\Windows\System32\ReAgentC.exe.
Tip
If you see error messages in the BitLocker-API about WinRe not being enabled, run the following command on the device to determine the WinRE status:
If the WinRE status is disabled, it is possible to enable it manually using the following command line as an administrator:
When BitLocker fails to enable on a Windows 10 device using an Intune policy, in most cases, the hardware or software prerequisites are not in place. Examining the BitLocker-API log will help you identify which prerequisite is not satisfied. The most common issues are:
Policy misconfiguration can also cause encryption failures. Not all Windows devices can encrypt silently so think about the users and devices that you’re targeting.
Configuring a startup key or PIN for a policy intended for silent encryption will not work because of the user interaction required when enabling BitLocker. Keep this in mind when configuring the BitLocker policy in Intune.
It is useful to be able to verify whether the policy settings have been picked up by the device to determine whether the targeting has been successful.
It is possible to identify the policy settings using MDM diagnostics, registry keys and the device management enterprise event log to verify if the settings have been successfully applied. The BitLocker CSP documentation can help you decipher these settings to understand whether they match what has been configured in the policy.
There are multiple places to configure BitLocker settings in the Microsoft Endpoint Manager admin center – Security baselines, Endpoint security, and Configuration profiles. It’s not a good idea to have conflicting policies. The preferred and recommended approach is to use Endpoint security > Disk encryption.
Here’s an overview of the logs, diagnostic checks, and command-line tools discussed in this post:
Logs
BitLocker settings checks
Command line/Powershell tools
More info and feedback
For further resources on this subject, please see the links below.
Enforcing BitLocker policies by using Intune known issues
Diagnose MDM failures in Windows 10 - Windows Client Management
BitLocker Management Recommendations for Enterprises (Windows 10)
Guidelines for troubleshooting BitLocker - Microsoft 365 Security
The next post will cover the BitLocker Recovery Key. Stay tuned! Catch up on other posts in the series:
Let us know if you have any additional questions by replying to this post or reaching out to @IntuneSuppTeam on Twitter.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.