In this blog, we’ll look at the Autopilot BitLocker 256-bit issue, a problem where devices start encrypting with 128-bit encryption during Autopilot Device Preparation, even when 256-bit encryption is required. It’s been a real challenge for environments that enforce stronger policies through Intune. A new Windows feature in the latest Insider build seemed to finally solve the issue, but it came with its own problems.
The Autopilot Device Preparation 256-bit BitLocker Issue
One of the outstanding issues in Autopilot Device Preparation (AP-DP) is that BitLocker encryption activates before the Intune policy has a chance to enforce stronger encryption settings. Even Microsoft documents this behavior under known issues:
“BitLocker encryption defaults to 128-bit when 256-bit encryption is configured.”
By default, Windows automatically starts encrypting the disk with XTS-AES 128-bit encryption during OOBE, which occurs immediately after the user logs in and just before the Intune policy sync is completed.
Which corresponds with Microsoft’s official documentation, as shown below.
But… If you configured a BitLocker policy requiring XTS AES 256-bit BitLocker Encryption, you’re already noncompliant.. and pretty much screwed! (if using AP-DP or the regular OOBE experience)
The only option we had when using AP-DP in combination with a 256-bit encryption requirement was to run a PowerShell script after/during enrollment to decrypt and re-encrypt the device. But that’s just a workaround for something that Windows should have handled from the start.
In a recent Windows Insider build, we found signs that Microsoft is finally addressing this. A new feature attempts to defer BitLocker until policy sync has finished, but enabling it came with a side effect: the “Next” button stopped working during enrollment.
A New Feature Appears: Autopilot BitLocker Deferral
While working on something else using the IDA tool, we spotted a new feature ID in the system: 29240126. It was labeled ‘Autopilot BitLocker Oobe Deferral’.
If you want to know more how we figured out this Feature in the BitLocker code, you may want to watch this episode of Patch N Rant
Patch N Rant Episode 3
The BitlockerOobeDeferral name was promising and appeared to address the AP-DP 256 bit BitLocker issue (not the escrow issue we discussed here). So, we decided to take a closer look. What we found was a change in the encryption logic inside fveapi.dll. (Full Volume Encryption.) which is responsible for BitLocker encryption.
This Autopilot BitLocker Oobe Deferral feature adds logic to delay BitLocker automatic encryption until the MDM policy sync has completed. It does so without relying on the Enrollment Status Page to hold back encryption (because AP-DP is a bit different from Autopilot). Let’s do a deep dive into the code..
How the Autopilot Bitlocker Deferral Feature Works Internally
When Windows starts the BitLocker encryption, it calls:
CFveApi::InitializeDeviceEncryption()
This function checks whether it’s safe to start encryption by calling:
FveIsOOBECompleted()
Under normal conditions, that check returns true if the system sees that OOBE is complete. It does that by checking the WNF state WNF_SHEL_OOBE_USER_LOGON_COMPLETE or registry values like SetupDisplayedEula.
With Feature 29240126 enabled, it performs an extra check. Inside FveIsOOBECompleted(), it now calls:
FveShouldDeferForMdmPolicySync()
That function looks for two conditions:
- Is the device in an Autopilot provisioning scenario
- Has MDM policy sync completed, indicated by the WNF flag:
WNF_PROV_AUTOPILOT_PROVISIONING_BITLOCKER_DEFERRAL_COMPLETE
Only when both checks pass does BitLocker start. If either fails, encryption is deferred. This allows the system to receive and apply the 256-bit encryption policy from Intune before writing any data to disk.
Testing the Behavior with ViVeTool
We enabled the feature manually using ViVeTool and then enrolled the device with an Intune BitLocker policy configured to enforce XTS AES 256-bit encryption.
In a typical scenario, without the BitLocker OOBE Deferral fix, Windows would begin encrypting automatically during OOBE using the default 128-bit method.
By the time the Intune policy arrives, it’s already too late, the drive is partially encrypted, compliance fails, and the only solution is to decrypt and re-encrypt.
With Feature 29240126 enabled, that behavior changed. BitLocker did not start during OOBE or Autopilot Device Preparation. The device waited until the Intune MDM policy was received and processed successfully. As shown below, BitLocker encryption was indeed deferred entirely the moment the user logged in for the first time.
From there on, after the Autopilot Device Preparation enrollment was completed successfully, the BitLocker encryption should now kick in with the 256-bit BitLocker policy in place.
At least, that’s what we were hoping for. However, we never got that far because the enrollment couldn’t even be completed. The “Next” button on the Device Preparation Page was visible, but clicking it did absolutely nothing.
What happened? Let’s examine the Shell Core Log first to gain a better understanding of it.
What the Shell-Core Event Log told us
After clicking the “Next” button, we checked the Shell-Core event logs (They hold Information about what happens with the CloudExperienceHost OOBE). The logs confirmed the click event was registered, but the page failed during its exit sequence. Here’s what was captured:
1. Next Button ClickedDevicePrepPage_NextButtonClicked_Started
Confirms that the click handler was triggered correctly.
2. Reboot Resumption UnsetDevicePrepPage_RebootResumption_UnsetAutopilot_DevicePreparationPage_unsetResumeToCurrentPageAsyncSucceeded
The system clears the resume-to-this-page-on-reboot flag, as expected.
3. ExitPageAsync StartsDevicePrepPage_ExitPageAsync
Logs a call to setPageStatusAsync With value 3.
4. Instance Null on GetDevicePrepPage_autopilotDevicePreparationUtilitiesInstance_getOrCreateWinRtInstanceHelperAsync_instanceNull
The JS logic fails to get a valid instance of autopilotDevicePreparationUtilitiesInstance.
5. WinRT Instance Creation AttemptDevicePrepPage_autopilotDevicePreparationUtilitiesInstance_createWinRtInstanceHelperAsync_Started
The system attempts to create the required WinRT instance.
6. Instance Creation FailsDevicePrepPage_autopilotDevicePreparationUtilitiesInstance_createWinRtInstanceHelper_Failed
Error code: -2130464756 (0x80D07014 / MDM_E_DEVICE_PREPARATION_UTILITIES_FAILED)
The WinRT instance creation fails completely, preventing the page from progressing.
This log sequence aligned exactly with the behavior we observed: the UI became unresponsive at the “Next” step, and the only way forward was to resolve the underlying issue… but how? I decided to find out if the BitLocker Deferral feature was the one causing the issue.
Verifying the Root Cause
To confirm that Feature 29240126 was the cause of the issue, we first enabled it to ensure the device would not automatically start encrypting during Out-of-Box Experience (OOBE). That part worked exactly as expected. BitLocker waited/deferred.
But since the “Next” button in the Device Preparation Page refused to respond, we needed a way to isolate the cause. So, we created a PowerShell script that disables the BitLocker deferral feature using ViVeTool.
We uploaded this script to Intune and added it to the list of required scripts that must run during Autopilot Device Preparation.
Once the device progressed through the initial phases and the Intune Management Extension (IME) was installed, the script was executed as part of the provisioning flow.
After the script completed and the feature was disabled, we clicked “Next”, and the page finally responded. From there on, we finally could find out if the AES256 Bitlocker policy was going to kick in.
Once we logged in, we opened PowerShell and executed the get-bitlockervolume | FL command. As shown below, the Autopilot Device Preparation Device was now automatically being encrypted with 256-bit AES encryption.
Besides checking the device, we also checked Intune. As shown below, no errors! No conflicts! Just a working 256-bit BitLocker policy.
Disabling the Autopilot Bitlocker OOBE Deferral feature just before the Required Setup is complete page appeared, confirmed that the BitLocker deferral feature was directly responsible for breaking the navigation logic in the Device Preparation Page.
With this information, I moved over to look at the Autopilot Device Preparation Javascript code, which was responsible for the flow.
The UI Is Just Code
Before diving into the exact cause, it’s important to understand what we’re dealing with. The Device Preparation Page in Autopilot isn’t a native compiled binary or some deeply integrated part of Windows. It’s just HTML and JavaScript, specifically the file autopilotDevicePreparation-page.vm.js, running inside a WebView App during OOBE.
That JS file controls exactly what happens when buttons like “Next” are clicked. It handles telemetry, WinRT calls, and transition logic. And if one of those calls fails without proper error handling, the entire flow breaks.
The Root Cause: Missing Error Handling
Inside the file autopilotDevicePreparation-page.vm.js, we found the cause. When the BitLocker deferral feature is enabled, the page calls:
signalBitlockerProvisioningComplete(3)
This function is used to notify the system that BitLocker provisioning has completed or was skipped. But it was called without any try-catch block, it seems. If the call failed, the page never transitioned to the success state.
The Fix: Patch the JavaScript Before Enrollment
Before triggering the Autopilot Device Preparation enrollment again, we manually edited the file autopilotDevicePreparation-page. vm.js on the system. This required taking ownership of the file and assigning write permissions to it. After changing the permissions, we modified the code to wrap the BitLocker signal call with a try-catch block:
With this in place, even if the BitLocker signal failed, the page continued to transitionToSuccessPageAsync().
We kicked off the enrollment again, and the result was clear: the “Next” button was functional and working again. The Device Preparation Page exited cleanly. BitLocker still waited for the policy, and no manual re-encryption was needed. Feel free to watch the full video
Upon reviewing the Shell-Core event log again, it confirmed that the fix had been applied: DevicePrepPage_ExitPageAsync “DevicePrepPage: Calling setPageStatusAsync with 3”, “errorCode”: 0
Will We Get Control Over This?
Right now, there’s no real control over how this BitLocker deferral feature works. No CSP. No toggle in the Autopilot profile. Just a hidden feature ID you have to enable with ViVeTool.
Ideally, we’d get a setting inside the Autopilot Device Preparation (AP-DP) profile to turn this on or off, just like you’d expect with any platform-level change.
However, even if Microsoft adds that setting, there is still a problem, the BitLocker decision happens before the device is fully enrolled. So, unless the OS knows up front that the feature should be active, it’s already too late. Automatic encryption is activated as soon as the user logs in to the desktop.
That means either:
- Microsoft makes this the new default behavior for AP-DP
- Or they need a way to apply this logic before MDM takes over (Device Linking?)
Until we know how they’ll handle that, this feature sits in a grey area: promising, but not yet manageable.
Autopilot Bitlocker Final Thoughts
Autopilot Device Preparation (AP-DP) didn’t previously support BitLocker deferral the way classic Autopilot (v1) did. That’s now changing. Feature 29240126 introduces logic to delay BitLocker encryption until after Intune MDM policy sync, using a WNF signal as the trigger.
The backend logic worked, but the frontend did not? It appears that a try-catch block was missing in the Device Preparation Page JavaScript, which caused the “Next” button to malfunction. Once we patched the JS file ourselves, the next button started working, and BitLocker waited until the user signed in before starting encryption, this time with the correct 256-bit encryption method applied
The feature isn’t exposed through Intune or CSP yet, and there’s no reliable way to control it during early provisioning. BitLocker deferral is finally making its way into AP DP, and it’s getting close to working as expected.