The CM Update KB10372804 and later versions of MEMCM contains a fix to make sure that these policies are not created. In one of my lab environments I have one entry as shown in the sample output below: If you have used the script or MBAM GPO pointing the MBAM client to MEMCM I would run the script in the KB article above to check if you are impacted, if so you need to create a support ticket to get help to fix it. This leads to severe degradation of performance in Configuration Manager, primarily with SQL and Management Points.” “Using the Invoke-MbamClientDeployment.ps1 PowerShell script or alternative methods that utilize the MBAM Agent API to escrow recovery keys to a Management Point in Configuration Manager current branch, version 2103 generates a large amount of policy targeted to all devices which can cause policy storms. However in MEMCM 2103 this all changed after supportcase it turned out that using the script (and I would assume GPO) creates extra policies and drastically impact performance. When MBAM was integrated into MEMCM many of us still used the same script / solution to enable BitLocker during OS deployment as the WebService/DB tables used by MBAM was basically just added to Configuration Manager.
The script then escrowed the recovery key and if present the TPM Password Hash to the MBAM Webservice and all was well. To enable BitLocker during OSD when using MBAM Standalone we used the script “Invoke-MbamClientDeployment.ps1” after first installing the MBAM client during OSD. Where the latest addition is support for Enhanced HTTP and CMG to escrow the recovery key which is awesome! MBAM was integrated in Configuration Manager and first released in 1910 and has been improved in every release after that. – Protection against accidental deletion of AD computer object (Separate DB) I have always liked Microsoft BitLocker Administration and Monitoring(MABM) as it provides us with additional functionality compared to saving the BitLocker recovery key in Active Directory.
0 kommentar(er)
