Windows 10 Failed to enable Silent Encryption

One of my latest blog posts I wrote about Modern desktop deployment. One of the paragraphs was about security and the ability to fully automate disk encryption on Azure AD joined, Intune managed devices.
At one of our customers we are implementing Intune to manage the laptops and run into a problem with this silent encryption process. I`d like to share my findings in this blog post and what setting resolved our issue.

Failed to enable silent encryption

In this environment we are testing modern desktop deployment using Windows AutoPilot. So the user authenticates to Azure AD, the device is joined to the Azure AD and automatically enrolled in Intune.
We created an Endpoint Protection policy with some Windows encryption settings. One of the encryption settings we set is Encrypt devices (to Require), which equals to the Bitlocker CSP setting RequireDeviceEncryption set to value 1.
We also set Warning for other Disk encryption to Block, this equals BitLocker CSP AllowWarningForOtherDiskEncryption set to 0.
As stated on Microsoft docs here, on Windows 10 1803 and newer devices Windows will attempt to silent enable BitLocker with those settings.

Because we don`t have devices with InstanGo or HSTI hardware, but we are piloting Windows 10 1809 devices, we also set AllowStandardUserEncryption with a value of 1.

The Intune policies are successfully applied and the first pilot devices were indeed successful encrypted without any user action. But when we tested some more devices with the same settings (and same hardware), BitLocker wasn`t enabled by default.
In the BitLocker-API event log on these devices, we saw several errors and warnings.
On of the errors we saw repeatedly was event 846:
Failed to backup BitLocker Drive Encryption recovery information for volume C: to your Azure AD.

The error was followed by a warning, event 778:
The BitLocker volume C: was reverted to an unprotected state.

Strange enough we looked up the device under the user his account in Azure AD and it showed us the BitLocker recovery key. And a recovery key wasn`t available once, but several times!
Event 845 confirmed the recovery information was indeed uploaded to Azure AD, unlike event 846 told us:
BitLocker Drive Encryption recovery information for volume C: was backed up successfully to your Azure AD.

Because these events are completely the opposite of each other and the recovery information was written to Azure AD, we didn`t immediately had an idea where to begin with our troubleshooting. We searched on the internet for those events. We also checked online documentation if we missed a requirement to silent enable encryption. It couldn`t be a hardware requirment, the hardware is all equal and still on some hardware it worked as expected and some did not. We compared the TPM versions on several devices and noticed we have TPM 1.2 and 2.0. So we run a TPM update on some of our test devices, without luck. We went through the BIOS (which is UEFI) searching for differences. After a while we noticed Secure Boot was disabled on some devices. With that in mind I took one of the machines and opened the BitLocker API log again. I remembered I had seen an information event about BitLocker that it wasn`t able to use Secure Boot.
BitLocker cannot use Secure Boot for integrity because the reguired UEFI variable ‘PK’ is not present.

Because it was an Information event and not an error or warning, we didn`t paid much attention to it, but we decided to turn on Secure Boot on a few devices. And yes now the machines were able to silent start encryption without any user interaction!

On a few devices which still didn`t work as expected, we noticed an older BIOS version. After upgrading the BIOS of those devices to the latest version, all our devices are starting silent encryption.
Conclusion for us:
Turn on Secure Boot and update your BIOS!
And if you are upgrading your BIOS, update your TPM to 2.0 😉

NB: I recommend testing silent encryption on physical hardware and NOT on a Virtual Machine. I have tested silent encryption on several VM`s and this was very unstable!