How can we utilize the Bitlocker Management feature during OSD with Endpoint Manager

[anyweb]

Introduction

Update: March 2022. This is now resolved natively in ConfigMgr 2203 or later, please review this post for more info.

NOTE: If you are using ConfigMgr 2103 or later do NOT use the Invoke-MbamClientDeployment.ps1  Powershell script as it will cause serious problems with your site. Read the following and scroll down for more info.

see https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/mbam-v25/how-to-enable-bitlocker-by-using-mbam-as-part-of-a-windows-deploymentmbam-25).

Quote

These instructions do not pertain to Configuration Manager BitLocker Management. The Invoke-MbamClientDeployment.ps1 PowerShell script is not supported for use with BitLocker Management in Configuration Manager. This includes escrowing of BitLocker recovery keys during a Configuration Manager task sequence. Furthermore, starting with Configuration Manager Current Branch 2103, Configuration Manager BitLocker Management no longer uses the MBAM key recovery services site to escrow keys. Attempting to use the Invoke-MbamClientDeployment.ps1 PowerShell script with Configuration Manager Current Branch 2103 or newer can result in serious problems with the Configuration Manager site. Known problems include creation of a large amount of policy targeted to all devices which can cause policy storms. This will lead to severe degradation of performance in Configuration Manager primarily in SQL and with Management Points.

I've had a lot of questions recently about people wanting to use the new BitLocker Management capabilities in Configuration Manager, and to make use of those abilities during OSD (Operating System Deployment). First things we need to keep in mind is that the BitLocker Management capabilities change quite a bit depending on the version of ConfigMgr you are using, the newer version it is, the more feature rich.

With ConfigMgr 1910, the abilities are minimal and therefore you'll have to have manual steps to make up for it in the task sequence. A lot has changed since the early release of Bitlocker Management so in this blog post I will assume you are using either CM1910, CM2002 or CM2006.

So what is our overall goal here?

It's to better understand what the different versions of Configuration Manager (with BitLocker Management enabled and configured as per my previous guides) and to be able deploy an operating system (Windows 10 version 1909 or later) to a computer and have it secured from the outset with BitLocker, and to have BitLocker configured with the same encryption algorithm we defined in our BitLocker Management policy and for the recovery key information to be stored in ConfigMgr's database.

Note: As the ConfigMgr agent is in provisioning mode during Operating System Deployment (OSD), it cannot process policy, therefore even if you add the computer to a collection targeted with BitLocker Management policy during OSD, it will not apply that policy until after the task sequence has successfully completed operations.

Deploying a computer with default BitLocker steps using CM1910 or CM2002

In ConfigMgr if you create a standard Install operating system task sequence with BitLocker included, even with BitLocker Management enabled, it will add a few BitLocker Specific steps namely

• Disable BitLocker (Capture USMT state phase)
• PreProvision BitLocker
• Enable BitLocker

These steps alone can enable a default configuration of Bitlocker but it may not be what you want, for example, the encryption algorithm will most likely not match your policy setting and will instead use the default value of XTS-AES 128 shown below.

 

In addition, the conversion listed above is Used Space Only Encrypted, you can change that to Full Disk Encryption if that's what you prefer

For more info on using the FDE options in the steps see the following blog post. https://www.niallbrady.com/2020/02/25/full-disk-encryption-a-closer-look-on-real-hardware/

If you leave everything in the default task sequence as default the end result will be a Bitlocker encrypted OS volume with XTS-AES128 using Used Space Only as shown here.

 

The computer will not have any MDOP agent installed (unless you target it somehow) and will not have any BitLocker Management policy deployed (unless again, you somehow target it with that policy.

 

Changing the default Encryption Algorithm

To change the encryption algorithm in an OSD task sequence in Configuration Manager 1910 or 2002 you'll need to add steps (before the Pre Provision BitLocker step) to the task sequence to force that encryption algorithm. The possible settings are listed below as registry keys, the REG_DWORD value 7 below will force it to use XTS-256 AES which is recommended.

cmd /c reg.exe add HKLM\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethod /t REG_DWORD /d 7 /f

as shown here.

 

The values you can use are listed below:

Value 3, AES_128: The volume has been fully or partially encrypted with the Advanced Encryption Standard (AES) algorithm, using an AES key size of 128 bits.

Value 4, AES_256: The volume has been fully or partially encrypted with the Advanced Encryption Standard (AES) algorithm, using an AES key size of 256 bits.

Value 6, XTS_AES128: The volume has been fully or partially encrypted with the Advanced Encryption Standard (AES) algorithm, using an XTS-AES key size of 128 bits. – This is the default of Windows PE 10.0.586.0 (1511 Release)

Value 7, XTS_AES256: The volume has been fully or partially encrypted with the Advanced Encryption Standard (AES) algorithm, using an XTS-AES key size of 256 bits.

 

Setting these registry keys is not necessary in ConfigMgr version 2006 or later as you can explicitly set the encryption method in the Pre-provision BitLocker step as shown here.

Ok now that we know how to force the algorithm, let's redeploy the computer to see the result.

 

So that was successful, but still there is no MDOP client agent and no BitLocker Management policy.

Adding the MDOP agent

To add the MDOP agent is simple enough as the MSI file we need is included with the files installed when you install the Configuration Manager client agent, and located in C:\Windows\CCM.

To install it during a task sequence, simply create a Run Command Line step after the Setup Windows and ConfigMgr step but before the Enable BitLocker step as shown below.

 

So, now that we've configured the Encryption Algorithm and have added the MDOP Agent, let's redeploy our computer to see what happens.

The end result, we have the right encryption algorithm settings, and the MDOP agent is installed, but there is still no BitLocker Management policy applied.

 

Meaning that the MDOP agent won't know what to do with itself and therefore no new keys will be stored in ConfigMgr's database from this computer (until it get's BitLocker Management policy) as you can see below, note today is 2020/8/14 and the last key added in this lab was a month ago exactly.

 

So what is our next option ?

Manually forcing the BitLocker Management policy

To 'tell' the MDOP agent where to send it's gathered data (keys, compliance and more), you can download some scripts from this link.

You will use those files to create a package within ConfigMgr, and later add the package as another step in the task sequence. This can manually force the MDOP agent into reporting the data to your respective recovery service.

 

Once done, distribute the package and add a new Run PowerShell Script step to the task sequence. Fill in the following details

Package: MDOP Scripts

Script name:

"Invoke-MBamClientDeployment.ps1"

Parameters:

-RecoveryServiceEndpoint "https://<RECOVERYSERVICE>/SMS_MP_MBAM/CoreService.svc" -EncryptionMethod "XTSAES256" -EncryptAndEscrowDataVolume -IgnoreEscrowOwnerAuthFailure -IgnoreReportStatusFailure -WaitForEncryptionToComplete

Replace <RECOVERYSERVICE> with the site hosting your configured BitLocker Management recovery service eg: https://CM01.windowsnoob.lab.local

Note: This step requires the MDOP agent is installed, so make sure you added it in the previous step.

Note: Once done, disable the built in Enable BitLocker step, however, keep in mind that doing so will stop the BitLocker recovery data from being stored in Active Directory. If you want the recovery data in AD, then don't disable this step.

Ok, now that that's done, let's redeploy our computer again to see what happens. This time, in addition to our Encryption Algorithm being set, the recovery key is stored in ConfigMgr's database.

So now the recovery information is stored in the database but still the configmgr client agent doesn't have any policy applied (unless you add that computer to a collection with the policy deployed to it).

Summary

To summarize, you've created manual steps in the task sequence to set the desired encryption algorithm settings, you've created a package and installed the MDOP agent and used a PowerShell script to store the recovery key information in ConfigMgr's database.

You would however still need to add the deployed computer to a collection where BitLocker Management policy is deployed if you want to report on the compliance of your deployed computers. In other words, there is no real native support for BitLocker Management configured policy within an OSD task sequence currently, instead, you must manually specify those configured settings within your task sequence if you want your devices encrypted with the same settings as your configured policy.

Lastly, if you are using CM2006 or later, things are a little bit easier and you no longer have to manually set the registry keys for encryption algorithim, instead in both the PreProvision BitLocker step and Enable BitLocker step you have a new drop down which you can use to set those values.

[syparon]

Great article ! Is it possible to have the recovery key escrowed in CM database and AD ?

[anyweb]

33 minutes ago, syparon said:

Great article ! Is it possible to have the recovery key escrowed in CM database and AD ?

yes

see

 

[kramer314]

FYI ... Don't use Invoke-MBAM (or the underlying MBAM agent WMI methods) to escrow directly to the recovery service anymore. It actively causes significant client policy issues starting with MECM 2103. At least a few enterprise customers are currently working through support cases with MS related to this.

If you *have* been using Invoke-MBAM on MECM 2103 for key escrow you may want to check both your client policy agent logs and the ResPolicyMap/PolicyAssignment DB tables for large numbers of extraneous BitLocker policies named TPM* being silently deployed to all clients (even those outside of collections with targeted BitLocker management policies) ... and if you are affected get in a support case with MS about how to fix it.

There's some additional context from an MS engineer just posted at https://www.reddit.com/r/SCCM/comments/o5v7tn/invokembam_configmgr_2103_bad/h31gvgi?utm_source=share&utm_medium=web2x&context=3

[anyweb]

good info, thanks for sharing, i'll ask Microsoft for comment

[kramer314]

Line from MS is that Invoke-MBAM was never supported for use with any release of ConfigMgr-native BitLocker management and that there is no supported ConfigMgr mechanism for on-demand recovery key escrow (during OSD or other scenarios) outside of normal policy / CI evaluation cycles.

This is also starting to be posted on some of their recent QA forum posts that were previously incorrectly answered by MS support employees - for example, https://docs.microsoft.com/answers/answers/452642/view.html ; Support's telling us they're working on additional doc updates to that effect as well.

Even though pre-MECM 2103 ConfigMgr's BitLocker management was (and mostly still is) MBAM under the hood and with MECM 2103 the MBAM recovery service is still present ... don't try and reverse engineer it anymore. You're going to end up shooting yourself in the foot. We were lucky to catch this in our environment quickly but are still waiting on MS to see if they can figure out how to correctly clean up database / client WMI policies that were silently created as a result of using Invoke-MBAM with MECM 2103. Every OSD cycle you run with Invoke-MBAM on MECM 2103 is currently likely to make the issue worse.

Just use the normal Enable BitLocker TS step during OSD and then let the client filter into a collection that receives BitLocker management policy to escrow recovery information. Escrow to AD if you need immediate / on-demand key escrow and can't wait for escrow based on policy / CI evaluation cycles. I wish the Enable BitLocker TS step had a supported option to escrow to MECM but it doesn't.

Edited June 26, 2021 by kramer314

[kramer314]

There's an official MS doc update on this now at https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/mbam-v25/how-to-enable-bitlocker-by-using-mbam-as-part-of-a-windows-deploymentmbam-25).

Quote

These instructions do not pertain to Configuration Manager BitLocker Management. The Invoke-MbamClientDeployment.ps1 PowerShell script is not supported for use with BitLocker Management in Configuration Manager. This includes escrowing of BitLocker recovery keys during a Configuration Manager task sequence. Furthermore, starting with Configuration Manager Current Branch 2103, Configuration Manager BitLocker Management no longer uses the MBAM key recovery services site to escrow keys. Attempting to use the Invoke-MbamClientDeployment.ps1 PowerShell script with Configuration Manager Current Branch 2103 or newer can result in serious problems with the Configuration Manager site. Known problems include creation of a large amount of policy targeted to all devices which can cause policy storms. This will lead to severe degradation of performance in Configuration Manager primarily in SQL and with Management Points.

No clue how many companies are potentially affected by this ... but seriously, for anybody reading this post ... if you're currently using Invoke-MBAM with ConfigMgr's native BitLocker Management, just get it completely out of your task sequences now. Even if you're not on 2103 yet ... get it out so you don't get hit by this if / when you do upgrade to 2103. It's frustrating there's no supported way to escrow recovery info during OSD but trust me, you do not want to have a large environment get hit by this issue.

If you are on 2103+ and have used Invoke-MBAM in task sequence scenarios since upgrading to 2103 ... I'd recommend you get in a support case with MS ASAP and then you too can join in the fun of waiting to see if and how your database / server WMI / client WMI can be salvaged.

[anyweb]

thanks a bunch for the info, i'll include a note linking to this at the top of the blog post ! I've also tweeted the info and posted it on my linked-in page

 

[anyweb]

update: there's a hotfix released and i've blogged about how you can verify if you have the issue and explained what the hotfix does...

https://www.niallbrady.com/2021/07/28/hotfix-available-for-2103-bitlocker-policy-storm/

[anyweb]

update: this is now resolved natively without the need for a Powershell script in ConfigrMgr 2203, read more here > https://www.niallbrady.com/2022/03/06/new-video-escrow-bitlocker-recovery-password-to-the-site-during-a-task-sequence-in-configuration-manager-2203/