Microsoft blogged about Bitlocker Management capabilities back in May, 2019. They detailed how that would impact and evolve on the following three platforms.
Cloud-based BitLocker management using Microsoft Intune
On-premises BitLocker management using System Center Configuration Manager
Microsoft BitLocker Administration and Monitoring (MBAM)
And recently they've posted an updated blog post here where they go into detail about how BitLocker Management in Microsoft Endpoint Manager has evolved (both in Intune and ConfigMgr). This purpose of this mini series is to help you troubleshoot problems related to the installation, configuration and usage of the new BitLocker Management capabilities in ConfigMgr and will be broken down into the following 3 parts.
Troubleshooting BitLocker Management in ConfigMgr - Part 2. Client side(this part)
Troubleshooting BitLocker Management in ConfigMgr - Part 3. Common issues
In the previous part we created a BitLocker Management policy, but we did not deploy it. This was enough to start the flow of how things work on the server side. But let's focus on the client side for now and in this blog post we will look at a Windows 10 20H2 client. As Windows 10 20H2 is a newly released operating system, we need to use ConfigMgr 2006 to remain supported. Let's take a look at some client computers both before and after they receive BitLocker Management policy from ConfigMgr.
Before BitLocker Management policy
Before a client receives BitLocker Management policy, it can be in one of 2 states with regards to encryption, namely fully encrypted or fully decrypted. If the computer has not been targeted with BitLocker policy and is for whatever reason decrypted, then the hard disc drives data will be readable at rest (not protected). I've prepared 2 virtual machines running Windows 10 20H2 and neither virtual machine has received our previously configured BitLocker Management policy yet, however one vm is encrypted using a different encryption algorithm than the one we created in the previous blog post, this is so that we can see what occurs when it receives that policy.
Both are running Windows 10 version 20H2 with the ConfigMgr client agent version 5.00.9012.1020.
Note: I manually encrypted one of the two virtual machines with XTS-AES 128 using the following:
Opening Windows File Explorer on both vm's show's that clearly the vm on the right is encrypted, while the vm on the left is not.
Using manage-bde -status reveals details about the encryption (or decryption) on both vm's.
Neither VM contains BitLocker Management policy based logs in C:\Windows\CCM\Logs
and we can see that there is no BitLocker Management related policy shown in the ConfigMgr client agent on either of the two virtual machines
A quick check of programs installed, reveals that the MDOP MBAM client Agent is not installed on either Virtual Machine. This agent is responsible for interpreting the BitLocker Mangement policy settings and acting accordingly.
This MDOP MBAM client agent installation file (MSI) is present in the ConfigMgr client agent files path (C:\Windows\CCM\MBAMCLIENT.MSI) even when the no BitLocker Management policy is deployed to the client.
There will be no MBAM related events (or folders) in the Event Viewer at the following path Applications and services logs\Microsoft\Windows\
And there will be no FVE\MDOPBitLockerManagement registry entries in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft
After BitLocker Management policy
So now that we've seen what client computers look like when not targeted with BitLocker Management policy, let's go ahead and deploy policy the previously created policy to them.
And once done, we can see things happening on the two clients.
The first indication that there's a change comes from the PolicyAgentProvider.log on the client, where it see's the new policy and refers to it via it's ScopeID.
You can confirm that this is indeed the policy by enabling the CI_Unique_ID column in the Configuration Manager console for your respective BitLocker Management policy.
very shortly after the client receives and interprets the policy, the following two logs are created on the client in the following order.
BitlockerManagementHandler.log
BitlockerManagement_GroupPolicyHandler.log
The BitlockerManagementHandler.log records details about BitLocker management policies, the installation of the MBAMClient.msi (MDOP MBAM client agent) and whether the configured policy is compliant or not.
Below you can see the BitlockerManagementHandler.log showing the installation of the MBAMClient.msi.
Below you can see the BitlockerManagementHandler.log showing that it's checking for compliance
and after the MDOP MBAM agent is done enforcing policy the computer will be marked Compliant or Non-Compliant. On this vm everything was compliant so the configuration baseline was marked as compliant.
If you remember in the start of this blog post we had two virtual machines, one had no encryption configured (vm1) while the second had XTS-AES 128 configured, and that does NOT match our BitLocker Management policy of XTS-AES 256 therefore it is marked as non compliant even though it is encrypted.
You can also look at the built in report for the Configuration Baseline by clicking on View report to see why it's not compliant, it's not that clear but if you see at the bottom of this report it's referring to the BMSOSDEncryptionPolicy and that's because the algorithm is different to the policy.
After checking for compliance the log reports on whether or not it can reach the BitLocker Management recovery service. Below you can see a successful connection to the recovery service.
The BitlockerManagement_GroupPolicyHandler.log records information about the presence of Local Group Policy settings which are written to the registry and if appropriate, enforces them.
Below you can see the registry settings are now populated.
if it looks like there are several registry keys missing (such as in the example below)
then double-check that you've configured and enabled the BitLocker Management Settings in the Client Management setting of the configured BitLocker Management policy
Once the registry keys are populated correctly, they'll be reflected in Local Group Policy settings on the clients.
Lastly, the MDOP MBAM agent logs the success or failure of it's actions to the event viewer and includes information about whether or not it can reach the Recovery Service as you can see in the example below:
and it will also log the escrowing of recovery keys.
Reviewing Policy using WMI Explorer
You can also use WMI Explorer 2.0 to take a closer look at policy on the client computers, browse to ROOT\Microsoft\MBAM as shown here (ran as Local Administrator).
and below you can see the two virtual machines side by side showing compliant versus non-compliant in WMI Explorer
Using PowerShell to determine non-compliance
You can use Powershell to determine non compliance, for example:
Introduction
Microsoft blogged about Bitlocker Management capabilities back in May, 2019. They detailed how that would impact and evolve on the following three platforms.
And recently they've posted an updated blog post here where they go into detail about how BitLocker Management in Microsoft Endpoint Manager has evolved (both in Intune and ConfigMgr). This purpose of this mini series is to help you troubleshoot problems related to the installation, configuration and usage of the new BitLocker Management capabilities in ConfigMgr and will be broken down into the following 3 parts.
In the previous part we created a BitLocker Management policy, but we did not deploy it. This was enough to start the flow of how things work on the server side. But let's focus on the client side for now and in this blog post we will look at a Windows 10 20H2 client. As Windows 10 20H2 is a newly released operating system, we need to use ConfigMgr 2006 to remain supported. Let's take a look at some client computers both before and after they receive BitLocker Management policy from ConfigMgr.
Before BitLocker Management policy
Before a client receives BitLocker Management policy, it can be in one of 2 states with regards to encryption, namely fully encrypted or fully decrypted. If the computer has not been targeted with BitLocker policy and is for whatever reason decrypted, then the hard disc drives data will be readable at rest (not protected). I've prepared 2 virtual machines running Windows 10 20H2 and neither virtual machine has received our previously configured BitLocker Management policy yet, however one vm is encrypted using a different encryption algorithm than the one we created in the previous blog post, this is so that we can see what occurs when it receives that policy.
Both are running Windows 10 version 20H2 with the ConfigMgr client agent version 5.00.9012.1020.
Note: I manually encrypted one of the two virtual machines with XTS-AES 128 using the following:
Opening Windows File Explorer on both vm's show's that clearly the vm on the right is encrypted, while the vm on the left is not.
Using manage-bde -status reveals details about the encryption (or decryption) on both vm's.
Neither VM contains BitLocker Management policy based logs in C:\Windows\CCM\Logs
and we can see that there is no BitLocker Management related policy shown in the ConfigMgr client agent on either of the two virtual machines
A quick check of programs installed, reveals that the MDOP MBAM client Agent is not installed on either Virtual Machine. This agent is responsible for interpreting the BitLocker Mangement policy settings and acting accordingly.
This MDOP MBAM client agent installation file (MSI) is present in the ConfigMgr client agent files path (C:\Windows\CCM\MBAMCLIENT.MSI) even when the no BitLocker Management policy is deployed to the client.
There will be no MBAM related events (or folders) in the Event Viewer at the following path Applications and services logs\Microsoft\Windows\
And there will be no FVE\MDOPBitLockerManagement registry entries in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft
After BitLocker Management policy
So now that we've seen what client computers look like when not targeted with BitLocker Management policy, let's go ahead and deploy policy the previously created policy to them.
And once done, we can see things happening on the two clients.
The first indication that there's a change comes from the PolicyAgentProvider.log on the client, where it see's the new policy and refers to it via it's ScopeID.
You can confirm that this is indeed the policy by enabling the CI_Unique_ID column in the Configuration Manager console for your respective BitLocker Management policy.
very shortly after the client receives and interprets the policy, the following two logs are created on the client in the following order.
The BitlockerManagementHandler.log records details about BitLocker management policies, the installation of the MBAMClient.msi (MDOP MBAM client agent) and whether the configured policy is compliant or not.
Below you can see the BitlockerManagementHandler.log showing the installation of the MBAMClient.msi.
Below you can see the BitlockerManagementHandler.log showing that it's checking for compliance
and after the MDOP MBAM agent is done enforcing policy the computer will be marked Compliant or Non-Compliant. On this vm everything was compliant so the configuration baseline was marked as compliant.
If you remember in the start of this blog post we had two virtual machines, one had no encryption configured (vm1) while the second had XTS-AES 128 configured, and that does NOT match our BitLocker Management policy of XTS-AES 256 therefore it is marked as non compliant even though it is encrypted.
You can also look at the built in report for the Configuration Baseline by clicking on View report to see why it's not compliant, it's not that clear but if you see at the bottom of this report it's referring to the BMSOSDEncryptionPolicy and that's because the algorithm is different to the policy.
After checking for compliance the log reports on whether or not it can reach the BitLocker Management recovery service. Below you can see a successful connection to the recovery service.
The BitlockerManagement_GroupPolicyHandler.log records information about the presence of Local Group Policy settings which are written to the registry and if appropriate, enforces them.
Below you can see the registry settings are now populated.
if it looks like there are several registry keys missing (such as in the example below)
then double-check that you've configured and enabled the BitLocker Management Settings in the Client Management setting of the configured BitLocker Management policy
Once the registry keys are populated correctly, they'll be reflected in Local Group Policy settings on the clients.
Lastly, the MDOP MBAM agent logs the success or failure of it's actions to the event viewer and includes information about whether or not it can reach the Recovery Service as you can see in the example below:
and it will also log the escrowing of recovery keys.
Reviewing Policy using WMI Explorer
You can also use WMI Explorer 2.0 to take a closer look at policy on the client computers, browse to ROOT\Microsoft\MBAM as shown here (ran as Local Administrator).
and below you can see the two virtual machines side by side showing compliant versus non-compliant in WMI Explorer
Using PowerShell to determine non-compliance
You can use Powershell to determine non compliance, for example:
and the results returned (16) match what was seen in WMI Explorer on the already encrypted client.
To get a list of these Reasons For Non Compliance see here https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/mbam-v25/determining-why-a-device-receives-a-noncompliance-message
or simply click on the Properties tab in WMI Explorer, and look what it reveals for that Property.
Recommended reading
Well that's it for this part, join me in the next part where we'll look at some common problems seen in BitLocker Management and how to resolve them.
cheers
niall.
Share this post
Link to post
Share on other sites