Jump to content


anyweb

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

Recommended Posts

Introduction

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.

pre provision bitlocker.png

 

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

pre provision bitlocker step and FDE setting.png

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.

default encryption with no changes.png

 

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.

no policy and no MDOP agent.png

 

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.

force xts-aes 256.png

 

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.

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

deployed with xts-aes 256.png

 

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.

adding the mdop agent.png

 

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.

enc algo and mdop agent but no configuration.png

 

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.

no keys in db.png

 

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.

mdop scripts.png

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.

MDOP scripts package.png

 

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.

configure bitlocker management policy.png

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.

disable enable bitlocker step.png

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.

recovery key in database.png

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).

no configuration items.png

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.

disk encryption mode.png

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by kramer314

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...