Jump to content


kramer314

New Members
  • Posts

    3
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by kramer314

  1. 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). 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.
  2. 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.
  3. 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
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.