In this blog post, I will go through the most common issues and questions you can encounter when deploying BitLocker Management in MEMCM.
Bitlocker protection is most likely the easiest way to protect the data you have on your device.
It is easy to set up, quick to get started, and together with the Configuration Manager integration, you have a centralized process of taking care of the data.
The most common scenario when you use Bitlocker protection is to secure the operating system drive. However, you can protect the other drives as well if you want to.
Challenges that you can encounter
You can encounter loads of different issues, and I can’t list them all here, but these are the most common.
- Force encryption without user interaction
- Checking the database for recovery keys
- Import recovery keys from already encrypted devices
- The client is unable to send recovery information
- Create a missing system partition
- Check Bitlocker compliance status
How do I overcome these challenges?
Force encryption without user interaction
Bitlocker Management (Previously MBAM) requires physical user interaction to start encrypting the drive.
That usually means that users postpone the encryption or don’t start it at all.
With some registry keys, you can force the encryption to start when the user signs in.
There are two keys that you want to add. One specifies that it should automatically encrypt the drive and the other that it should do so immediately.
Create these Registry Keys on your clients, and encryption will start by itself the next time users sign in.
Checking the database for recovery keys
You can manually check if BitLocker Management has encrypted and escrowed any keys using the MEMCM database.
With tools like SQL Server Management Studio, you can view the table containing the keys (they are encrypted if you follow the recommendations).
Connect to your database using SSMS and open the Tables folder.
You are looking for a table called dbo.RecoveryAndHardwareCore_Keys
Right-click it and then Select Top 1000 Rows.
The output will show you all of the recovery keys currently in the database, which means that you will see the keys here if everything is correctly configured.
Import recovery keys from already encrypted devices
You already have devices with Bitlocker enabled, and you wish to migrate the recovery data from Active Directory.
A great thing about this solution is that the MBAM client, installed when you deploy the policy, will automatically escrow the existing recovery keys to the MEMCM database.
The client is unable to send recovery information
After I configured the Bitlocker Management, one issue that I encountered was that the recovery keys weren’t escrowed to the database.
I checked the database using SQL Server Management Studio to verify that everything was working as expected.
Unfortunately, there were no keys in the database. I know for a fact that the drive is encrypted, which means that there should be a key.
While doing some digging in the client logs, I found that the client had trouble talking to the MBAM Core web service. The log is called BitlockerManagementHandler.log.
I found that the IIS had some trouble binding the new websites, which means that the MBAM services can’t start properly.
This problem can be solved by adding the following code to the web.config for the webpages.
<system.serviceModel> <serviceHostingEnvironment multipleSiteBindingsEnabled="true"> </serviceHostingEnvironment> </system.serviceModel>
The file itself is located in the SMS_CCM folder, depending on where you have MEMCM installed. <InstallDir>\Program Files\SMS_CCM\Microsoft BitLocker Management Solution\Recovery And Hardware Service.
I added the code at the bottom of the <system.servicemodel> section and restarted the servers. After this, the service started, and my clients began sending their keys.
Create a missing system partition
BitLocker requires a System partition to encrypt the drives. This partition must fulfill the following prerequisites.
- It must be configured as the active partition.
- It must not be encrypted or used to store user files.
- Must have at least 100 megabytes (MB) of space.
- Must have at least 50 MB of free space.
- May be shared with a recovery partition.
So what happens if you don’t have this partition when you enable BitLocker? The simple answer; Nothing.
Fortunately for us, it can be created on a running Operation System using the following command.
Execute it using an administrative command prompt.
%windir%\system32\bdeHdCfg.exe -target default -size 300 –quiet
Check BitLocker compliance status
During the testing process, you might want to check the status of MBAM on your client. For example, if you expect the drive to encrypt, but it doesn’t, the next step is to check the compliance status and compare it to the documented compliance codes.
This procedure will give you a good idea of where to look if you need to tweak or troubleshoot some settings.
Run this command in an administrative PowerShell window to get the information you want.
Get-WmiObject -Class mbam_Volume -Namespace root\microsoft\mbam
If you look closely at the image, you can see that ReasonsForNoncompliance contains four numbers, 1, 16, 12, 7.
These indicate an issue or status that you can translate using the table in the link below.
BitLocker is a great tool to use to quickly and easily encrypt your drives.
The addition of the MBAM functionality inside MEMCM makes it even easier to use, and you should take a look at it if you value your data.
If you like this post and want to find more interesting articles, check out the author’s blog!