Introduction

Microsoft are continuously responding to feedback from UserVoice and one such new implementation in Technical Preview 2010.2 is the ability to manage BitLocker policies and escrow recovery keys over a cloud management gateway (CMG).

For more details see here and here.

So let’s read about the new ability.

Improvements to BitLocker management

Based on your UserVoice feedback, you can now manage BitLocker policies and escrow recovery keys over a cloud management gateway (CMG). This change also provides support for BitLocker management via internet-based client management (IBCM) and when you configure the site for enhanced HTTP. There’s no change to the setup process for BitLocker management. For more information, see Deploy BitLocker management.

If you have either the Helpdesk or Self-Service portals set up, use these portals to validate that clients escrow their keys directly to a management point. For more information, see Set up BitLocker portals. Continue to use BitLockerManagementHandler.log to help troubleshoot client communication.

Known issue with BitLocker management

When the client can’t communicate with an on-premises management point, there’s an issue with the client’s BitLocker configuration for key recovery. As a temporary work around for this preview release:

1. Set the following registry key on the client: HKLM\SOFTWARE\Microsoft\CCM\BLM, "UseKeyRecoveryService"=dword:00000001
2. Restart the SMS Agent Host (ccmexec) service.

This value resets each time the client evaluates the BitLocker management policy, which is seven days by default.

Using boundaries with CMG

CMG’s (Cloud Management Gateways) are internet based virtual machines running in Azure comprising the functionality of a ConfigMgr management point and cloud distribution point. Boundaries within ConfigMgr help you to define where content can be located based on many factors for client computers so that they pull that content from the nearest possible location to avoid going across the WAN to remote sites.

Normally internet based clients will have an IP address that you cannot define, cannot control or even be aware of in advance. Therefore in those scenarios it would be impossible to create a boundary for computers with an internet provided IP address. In that scenario, defining a CMG boundary would be pointless and therefore you would not create a CMG based boundary, and just leave the ‘magic’ up to ConfigMgr.

The connection between the Configuration Manager client and the CMG isn’t region-aware. Client communication is largely unaffected by latency and geographic separation. It’s not necessary to deploy multiple CMG for the purposes of geo-proximity. Deploy the CMG at the top-level site in your hierarchy. To increase scale, add VM instances.

The ConfigMgr client agent will know if it’s on the Intranet or Internet.  You can force it to use Always Internet via  a registry key for testing purposes. To verify what the connection type is currently set to look at the General tab of the ConfigMgr client agent specifically the Connection Type. In an Internet based scenario it will know that it should use the CMG for policy and content.

You can verify the CMG settings in the Network tab of the ConfigMgr client agent.

There are scenarios however where creating a CMG boundary would make sense, for example if you have a remote site that needs content, apps or policy but has a weak WAN (Wide Area Network) link back to the head office. In that scenario you could define an IP range for your remote site to define the boundary of that CMG. And that is the scenario we will test here. I’ve created a boundaries for both the on premises computers and CMG based as shown here.

The client computer we will verify with is MININT-DRQDRS6,  as you can see above, it falls within the CMG boundary group.

Testing the new functionality

To test this I deployed some virtual machines running both Windows 10 2004 and Windows 10 20H2 without BitLocker (not encrypted), and then verified connection to the CMG by deploying an application (Mozilla Firefox) before deploying new policy to enable BitLocker.

Via the logs, you can verify that the application has come from the CMG via the DataTransferService.log. So now we know that our client computer is getting policy and applications via the CMG.

Next, I created a BitLocker Management policy and deployed it to a collection

Next, I added some computers to the collection with BitLocker Management policy deployed to it. Then as per the documentation I added the registry key specified in the docs.

Finally, I restarted the SMS Agent Host service

After doing this I updated machine policy and verified my client had the BitLocker Management policy. Once I could see it had the policy I clicked on Evaluate.

and when all the requirements match up…

And after another evaluation of the BitLocker Management policy, I can see it’s reporting as Compliant !

For proof, a quick check of the key protectors on the client computer…

double checking that against the ConfigMgr database…reveals the RecoveryKeyId is escrowed.

Job done !

Troubleshooting

Note: This is for Technical Preview 2010.2 only, your mileage may vary, these are my notes based on the testing I’ve done.

If the computer doesn’t encrypt after getting policy and instead this error is repeated over and over, verify that the client computer can process Group Policy from the Domain controller.

You may or may not see the MBAM Client Agent informing you about encryption, which is probably why it says ‘Attempting to launch MBAM UI’. If you test this by manually decrypting a drive and then refreshing policy, the agent might not popup to the end user but that’s ok, the encryption will take place.

You do not need co-management to get this to work, I tested with a client that was co-managed and with a client that was not co-managed, both worked the same way. If you are using co-management then the Endpoint Protection slider must point to Configmgr.