Let’s say you want to enable BitLocker during a Windows Autopilot user-driven deployment, and you want “maximum security” by changing the default BitLocker encryption settings to instead use XTS-AES 256-bit encryption (instead of the default 128-bit). You would end up creating a device configuration profile in Intune that looks something like this:
Notice the note that is displayed in the Intune portal when you choose an encryption method that is different from the default:
Note: devices enabled with automatic encryption will require decryption before changing encryption method.
Well, if this is a new device being deployed via Windows Autopilot, that’s exactly what you don’t want to do.
It’s worth explaining what it means for a device to be “enabled with automatic encryption.” As mentioned in the BitLocker docs, devices that meet these requirements will automatically begin encrypting:
- The device contains a TPM (Trusted Platform Module), either TPM 1.2 or TPM 2.0.
- UEFI Secure Boot is enabled. See Secure Boot for more information.
- Platform Secure Boot is enabled
- Direct memory access (DMA) protection is enabled
The rest of that doc page explains in even more detail what’s required, but there is one more key item: The device needs to support modern standby or HSTI. Practically, this includes all Surface devices, and some OEM devices (especially tablets).
OK, but why does that all matter? Imagine you aren’t using the Enrollment Status Page (or, horror of horrors, you aren’t using Windows Autopilot at all). As soon as the device boots up, if it sees the device meets the automatic encryption requirements it will start encrypting. And that give you no time to get a new set of BitLocker settings to the device first, so it starts encrypting with the default XTS-AES 128-bit settings. Too late to make changes, hence the note in the portal about having to decrypt to make the change.
Alright, now back to making it actually work. We made some changes in Windows 10 1809 and above to fix this problem when you are using BitLocker with Windows Autopilot and the Enrollment Status Page. With these changes, BitLocker will wait to begin encrypting until the end of OOBE, after the ESP device configuration phase has completed. That gives Intune sufficient time to get the BitLocker policies applied to the device first, so when BitLocker starts encrypting, it does it using the XTS-AES 256-bit settings you configured.
Of course all of this is documented in the Windows Autopilot documentation. I’m sure you’ve read all of that, right?
There’s one other gotcha though: Windows 10 1903 broke this process (causing BitLocker to start encrypting prematurely) requiring some additional changes that were included in the June 27th cumulative update (KB4501375) and all later updates. (There are a variety of other Windows Autopilot fixes in the July 26th cumulative update, so it would be even better to use at least that one.) For new devices, make sure your OEM is shipping a properly-patched version of Windows 10 1903 to get those fixes.
Categories: Windows Autopilot