Windows boots into Automatic Repair after Intune enables BitLocker on a sysprep image

Symptom

A Windows 11 machine built from a sysprep image is enrolled in Intune. The BitLocker policy applies, the drive gets encrypted, and at the next reboot the machine lands in Automatic Repair. Restarting again brings it back to the same screen: the classic recovery loop.

In my case it was a Hyper-V VM built from a sysprep VHDX, but the same thing happens on physical machines deployed from a captured image. A machine installed from the plain Windows ISO with the same Intune policy encrypts and reboots normally.

Cause

The Boot Configuration Data of the image does not point at the right partition. After sysprep and deployment, osdevice and device in the {current} entry can reference the volume by a device path that no longer matches the disk layout of the target. Windows tolerates this as long as the system volume is readable. Once BitLocker encrypts the volume, the boot manager has to find and unlock the exact partition before Windows starts, and a BCD entry pointing elsewhere sends it to recovery.

This is why the problem only appears after encryption, and only on imaged machines.

Get the machine to boot again

From the Automatic Repair screen: Advanced options > Command Prompt.

Find the Windows volume and make sure it has a drive letter:

diskpart
list vol
select vol 0        (use the number of your Windows volume)
assign letter=G:
list vol
exit

Unlock it with the recovery password (from Intune: device > Recovery keys, or from the Entra device page), then decrypt:

manage-bde -unlock G: -RecoveryPassword "xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx"
manage-bde -off G:
manage-bde -status G:

Wait until the status shows the volume fully decrypted, then close the prompt and reboot. The machine starts normally.

Fix the BCD so encryption survives a reboot

Boot into the firmware once to confirm Secure Boot is enabled, then log on to Windows and open an elevated command prompt.

These commands assume a standard single-disk installation with Windows on C:. Check with bcdedit /enum before running them.

bcdedit /set {current} osdevice partition=C:
bcdedit /set {current} device partition=C:
bcdedit /set {memdiag} device partition=\Device\HarddiskVolume1

Reboot. Intune re-applies the BitLocker policy, the drive encrypts again, and the next reboot goes straight to the logon screen.

Fix the image, not every machine

Doing this by hand on each deployed machine is not a solution. Put the correction in the image, so that every machine deployed from it has a correct BCD before the encryption policy ever hits it.

In unattend.xml, add a RunSynchronousCommand in the specialize pass (or oobeSystem if your process runs later), one per command:

<settings pass="specialize">
  <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
    <RunSynchronous>
      <RunSynchronousCommand wcm:action="add">
        <Order>1</Order>
        <Path>cmd /c bcdedit /set {current} osdevice partition=C:</Path>
      </RunSynchronousCommand>
      <RunSynchronousCommand wcm:action="add">
        <Order>2</Order>
        <Path>cmd /c bcdedit /set {current} device partition=C:</Path>
      </RunSynchronousCommand>
    </RunSynchronous>
  </component>
</settings>

If your deployment tool runs a post-install script instead (MDT, FOG, a task sequence), the same two lines belong there.

Checklist before enabling BitLocker through Intune on imaged machines

• deploy one machine from the image and run bcdedit /enum {current}: device and osdevice must read partition=C:, not a \Device\HarddiskVolumeN path
• Secure Boot on, TPM 2.0 present and ready (Get-Tpm)
• the recovery key backup to Entra ID is enabled in the policy, otherwise the unlock step above is not possible

The original thread that put me on the right track: Computer going to automatic repair after enabling BitLocker on Microsoft Q&A.