B for Bitlocker

B for Bitlocker

This blog will be about the Bitlocker recovery key and how to make sure it will be escrowed to Azure. I will show you what options you have to make sure your recovery keys are safe.

Bitlocker is one of the many security measures you will need to implement to make sure the data is safe when the device gets stolen. Bitlocker encrypts the data on the device so it can’t be read without authenticated decrypting using a recovery key.

One of the downsides is the support tickets that could be created when a user simply does not remember their password anymore and tried it too many times.

Luckily in a normal situation, you have made sure there is a backup of the recovery key in Azure. An admin could query the device to get the recovery key.

Or the end-user itself could log in to my account from any device to retrieve the recovery key

My Account (microsoft.com)

But wait, what if there is no backup in Azure Ad? How are you going to monitor this or make sure there is always a recovery key present.

This week we had a customer who entered the wrong password too many times. The device ended up booting into the Bitlocker screen. So as the good admin’s we are, we opened the azure active directory to look up the recovery key but no single recovery key was available!!!

At that point, I was very glad we are also using Solarwinds to monitor the devices. One of the scripts we made sure was implemented, was to show the recovery key in Solarwinds. The end-user was very grateful to get the recovery key so he could get back to work. The problem is solved you might think but I was very curious why there wasn’t a backup recovery key available.

We started searching and the first place to look would be the Bitlocker event log. It showed us the event 846 with a nice error: Unknown HResult error code: 0x801c0450

As shown above, this is definitely the problem. Googling the error did not result in any useful hits.

You can also use PowerShell to query the event log:

Let’s try to reproduce the error and try to back up/escrow the recovery key again. We opened a PowerShell session and launched this script.

$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

And the backup of the recovery key was done?

That’s odd because when the device was enrolled the same script did not do its job.  To be sure, we checked all the other devices in the company but all the devices had their recovery key uploaded.

As stated before, for now, we are using Solarwinds. But what if you don’t have Solarwinds monitoring configured?

I am going to show multiple options on how you can make sure the recovery key is safe.

  1. Powershell / Win32 Bitlocker Script
  2. Intune Device Configuration
  3. Proactive Remediation

1.Powershell Script

You can make sure Bitlocker is enabled and configured on the device with the use of PowerShell. There are some benefits when you add a task schedule to the Powershell script and deploy it.

Normally when the BitLocker fails to back up the key to Azure, it will not try again and you end up with a device with no Bitlocker. But with this Win32app/Powershell script, you can be pretty sure it will try to encrypt the device and it will backup the key to azure each time you log in. Even when you forgot to unplug the installation media, this is no problem at all.

if($BLinfo.EncryptionPercentage -eq '100'){
$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

Download Link: (Powershell script and the PowerShell Script converted to a Win32 App)


The script also contains some policies to make sure the backup is required before encryption. One of the policies is also necessary when you want to manually perform a key rotation


I prefer using Intune as much as possible to deploy settings. It’s a lot easier when every setting or configuration which is configured on the device is visible in one place.

Making a change to your configuration is a lot easier within the Intune portal than using Powershell script to deploy settings. When you are using PowerShell scripts you will need to get back your scripts first before you add some changes to them.

You can deploy Bitlocker in Intune by creating a new device configuration profile or an Endpoint security Profile.

When you want to make sure the recovery keys are uploaded, please configure these settings.

3. Proactive Remediation

You could also create a proactive remediation script and schedule it to run each hour. It will try to find the event 846 which I showed you earlier and when it’s found it will try to back up the key.

Detection script:

Try {
$Result = get-winevent -FilterHashTable @{LogName="Microsoft-Windows-BitLocker/BitLocker Management";StartTime=(get-date).Addseconds(-86400)}|Where-Object{($_.id -eq 846)} | ft message
$ID = $Result | measure-Object
If ($ID.Count -lt 5)
    Write-Output "Bitlocker backup to azure add succeeded"
    Exit 0
    Write-Output $result
   Exit 1


Write-Warning "Value Missing"
Exit 1

When looking at the detection script, you will notice the 86400 seconds.  When a device is enrolled and this error would occur, endpoint analytics will make sure it will try to resolve it.

Remediation script (very small)

$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

Let’s check if it’s working. Open pro active remediations and select all at the detection and remediation status to get a better overview and some more information when your remediations are failing.

As shown above, everything is fine and luckily the specific event log is not detected within the last 24 hours. With this remediation, you can be a little bit more sure the recovery key is uploaded.

This blog is not really about how Proactive remediations are launched, but why not?

When you have configured proactive remediations, the Powershell scripts are stored on the device itself.

They are handled by the Intune Management Extension (Sidecar agent) who invokes the Agent executor to trigger the execution of the PowerShell scripts. Let’s open the agentexecutor.log first to determine where the Powershell scripts are stored.  

It’s nice to see where the PowerShell scripts are stored (You will need admin rights to access this folder)


Not monitoring your devices and just trusting everything would just work, is not that smart.

You need to make sure the BitLocker keys are safe or make sure the recovery key is uploaded before encryption! This is the way.

Mandalorian Leadership: This Is The Way – Neil Gupta, Ed.D.

Leave a Reply

Your email address will not be published. Required fields are marked *

23  +    =  28