Configuration Manager (still SCCM or MECM to many admins) has BitLocker management built in. It enforces encryption, stores recovery keys in the site database and gives the helpdesk and users portals to get keys back, which is what stand-alone MBAM used to do. In this post I'll set it up from start to finish, cover the MBAM migration traps and show what a healthy client looks like.
How it works and what you need#
There are two parts. The Configuration Manager client switches on the BitLocker management agent when a BitLocker policy is deployed to the device. The recovery service on your management points receives recovery data. Since version 2103, clients escrow keys through the management point's message processing engine, over the secure client notification channel, so a site that uses enhanced HTTP works. Only clients on version 2010 or earlier need an HTTPS-enabled recovery service on the management point.
| Requirement | What to check |
|---|---|
| Feature | BitLocker management is an optional feature. Check Administration › Overview › Updates and Servicing › Features and turn it on if it's off. |
| Communication | Site and clients on version 2103 or later, with enhanced HTTP or HTTPS. |
| Devices | Windows clients joined to Active Directory. Microsoft recommends TPM 2.0. |
| Permissions | Full Administrator, which you need to create the policy. |
| Key protection | A BitLocker management encryption certificate in SQL Server (see Microsoft's "Encrypt recovery data" guidance). Without it, recovery information can only be stored in plain text. |
Step-by-step#
1. Clear out conflicting Group Policy#
Configuration Manager writes BitLocker settings as local policy, and domain Group Policy overrides it. If an old MBAM GPO still points key recovery at the MBAM server, keys never reach your management point. On a pilot device, run:
gpresult /scope computer /h %TEMP%\gp.htmlLook for settings under Windows Components › BitLocker Drive Encryption and Windows Components › MDOP MBAM (BitLocker Management), then unlink or filter those GPOs for the devices you're moving. Microsoft's advice is to configure BitLocker only through Configuration Manager policies.
2. Create the policy#
- Go to Assets and Compliance › Overview › Endpoint Protection › BitLocker Management and select Create BitLocker Management Control Policy.
- On General, name the policy and choose its components: Operating System Drive, Fixed Drive, Removable Drive and Client Management.
- On Setup, enable Drive encryption method and cipher strength (Windows 10 or later) and pick a method per drive type. A common choice is XTS-AES for internal drives and AES-CBC for removable drives that older Windows versions must read. Unconfigured, BitLocker uses AES 128-bit. Choose carefully: changing the method later doesn't re-encrypt drives.
- On Operating System Drive, enable Operating System Drive Encryption Settings and choose TPM only, or TPM and PIN (minimum PIN length defaults to 4).
- On Fixed Drive, enable Fixed data drive encryption with auto-unlock, which needs an encrypted OS drive. Configure Removable Drive only if you want to manage USB encryption.
- On Client Management, enable Configure BitLocker Management Services, store the recovery password and key package, and leave Allow recovery information to be stored in plain text off.
If several policies target a device, priority decides which settings win. To script this, use New-CMBlmSetting and New-CMSettingDeployment.
3. Deploy it to a pilot collection#
Select the policy, choose Deploy, pick a device collection and set a compliance schedule. Select Allow remediation outside the maintenance window if devices may encrypt or decrypt at any time.
Two things commonly hold encryption up. First, the agent won't start while a Remote Desktop connection is active or when the signed-in account is local rather than a domain account. Use mstsc.exe /admin /v:<device> to connect to the console session instead. Second, with TPM and PIN, encryption waits until the user sets a PIN.
4. Install the helpdesk and self-service portals#
Set up both portals with the MBAMWebSiteInstaller.ps1 script that comes with Configuration Manager. Install them on IIS servers that aren't stand-alone MBAM servers, because reusing those servers breaks stand-alone MBAM. After a key is retrieved through either portal, the client rotates it and escrows a new one, so a disclosed recovery password only works once.
5. Migrate from stand-alone MBAM#
- Check the encryption method your devices use (
manage-bde -statusshows it) and match the policy to it. Configuration Manager doesn't re-encrypt protected drives. With a mismatch, such as XTS-AES 128 on disk and XTS-AES 256 in the policy, the device reports non-compliant although it's encrypted. The only other fix is to decrypt it and let the new policy encrypt it again. - Remove the MBAM GPO for a pilot group, deploy the policy and check that the keys arrive.
- Expand in waves. A migrated device rotates its recovery password when the policy arrives and escrows the new one, so from then on its working key is in the site database, not MBAM.
- Keep MBAM until every device has escrowed to Configuration Manager, then decommission it.
Verify#
In the console, the BitLocker Management node shows compliance, failure and non-compliance counts for each policy, and View Status on a deployment opens per-device detail in Monitoring › Deployments. On the device:
manage-bde -status C:
manage-bde -protectors -get C:Good looks like Protection Status: Protection On, a conversion status of Fully Encrypted (or in progress), your policy's encryption method, and a TPM (or TPM and PIN) protector plus a numerical password. If something is missing, check these:
| Where | Log |
|---|---|
| Client | BitlockerManagementHandler.log and BitlockerManagement_GroupPolicyHandler.log in %WINDIR%\CCM\Logs, for policy processing |
| Client | Applications and Services Logs › Microsoft › Windows › MBAM, for agent events |
| Management point | Applications and Services Logs › Microsoft › Windows › MBAM-Web, for recovery service events |
| Management point | Recovery service trace files: <Default IIS Web Root>\Microsoft BitLocker Management Solution\Logs\Recovery And Hardware Service\trace*.etl |
For an end-to-end test, retrieve a pilot device's key in the helpdesk portal. Once the client has checked in again, run manage-bde -protectors -get C: again. A new ID on the numerical password proves that escrow and rotation both work.
Tips & gotchas#
- Co-management moves the authority. If you switch the Endpoint Protection workload to Intune, the client ignores its Configuration Manager BitLocker policy and uses Intune's encryption settings. If the encryption method changes too, plan for re-encryption. For the Intune side, see BitLocker silent encryption not starting and moving co-management workloads to Intune.
- "Non-compliant but encrypted" usually means an encryption method mismatch. Check that before you blame the agent.
- Internet-based clients can escrow through a cloud management gateway. From version 2103, that includes removable-drive recovery keys.
- Use one authority. Don't let GPOs, Intune and Configuration Manager all configure BitLocker on the same device.

