Bitlocker issue with MECM

Question

Hello forum,

We recently setup a test Bitlocker policy in Microsoft Endpoint Configuration Manager and added one Windows 10 1909 laptop (Dell Latitude 3380) to it. It successfully encrypted the drive. I then used Powershell to initiate a test recovery on the device. The laptop booted to the recovery screen and I used the recovery ID to get the recovery key from the MECM Helpdesk portal hosted on our Configuration Manager site system. That all worked as expected and the laptop booted to the OS. Afterwards, I may have put it to sleep after using it. Side note: after encryption, this laptop was placed in a collection that had the Windows 10 Cumulative Update from January deployed to it, so it's likely that some system files got changed over the weekend.

Fast forward to today, I went to boot the laptop and it booted to the Bitlocker recovery screen again, however, this time it had a different recovery key ID on it. I entered the displayed recovery key ID into the Helpdesk portal and was met with a "Recovery key not found" message. Online research found that when keys are disclosed via the MECM Helpdesk portal - "once the Recovery Key is given to the user via the Help Desk, it is then rotated on the Client and the new Recovery Key and Recovery Key ID are transferred to the Server, and therefore the old Recovery key becomes useless." So apparently my initial recovery last week did cause the device to generate a new key.

I queried the RecoveryandHardware tables in the Configuration Manager database and there was only one entry for the laptop and its last update time was from when I initially added this device to the Bitlocker Policy. So it appears for whatever reason the MBAM client on the laptop did not update the Configuration Manager database with its latest key.

This device was just a test laptop, so I re-imaged it and got it back to a useable state, but does the community have any recommendations that could keep this scenario (devices not updating their recovery key in the Configuration Manager database) from happening again? I would hate to roll this out on a large scale and be met with a bunch of unrecoverable keys and upset users.

Thanks for any input.

Answer 1

Honestly, without deeper details -- which I know you don't really have -- there's not much that can be said except this is not expected and something possibly failed. I suggest opening a support case to help dig into this so that we can investigate whether or not a product defect is responsible and needs to be corrected. I don't truly know how successful an investigation would be here though since the volume is currently locked and most (if not all) necessary evidence for an investigation is also locked on that volume.