BitLocker activation blocked by “previous unsuccessful attempt” error after migrating from another MDM

[kitzy]

• customer-pingali: Slack thread.
• customer-preston: Slack thread.

💥 Actual behavior

When enabling BitLocker on a Windows device that was previously enrolled and encrypted with another MDM, encryption does not start. No user-facing prompt appears on the device. Orbit logs show:

ERR disk encryption failed due to previous unsuccessful attempt, user action required

manage-bde -status reports the OS volume as fully decrypted with protection off. Screenshots referenced in thread:

🛠️ To fix

TBD

Current workarounds:

1. Wipe out the registry key.
2. Manually deleting the protectors (even though it says there aren't any) can clear any stale reg keys.

🧑‍💻 Steps to reproduce

1. Enroll a Windows device in another MDM. Enforce encryption through that MDM.
   • In the customer's case, this was on a Microsoft Surface Laptop 4 running Windows 11 Enterprise 24H2 (10.0.26100.6584).
2. Unenroll the device from the other MDM and remove BitLocker encryption from the drive.
3. Enroll the device in Fleet and enable Windows disk encryption in the relevant team/policy.
4. Wait for Fleet to attempt enablement. Observe Orbit logs on the host.
5. Note there is no interactive Windows prompt. manage-bde -status shows: - Conversion status: Fully Decrypted
   • Protection status: Off
   • Key protectors: None found
6. Optional remediation attempts that do not resolve the issue:
   • Reboot the device.
   • Run manage-bde -off C: and wait for the next Fleet retry window.

🕯️ More info (optional)

• Hardware: Microsoft Surface Laptop 4.
• OS: Windows 11 Enterprise 24H2, build 10.0.26100.6584.
• TPM status (Get-Tpm): Present, Ready, Enabled, Activated, Owned; AutoProvisioning Enabled; ManagedAuthLevel Full; not locked out.
• Registry (osquery):
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\TPM\OSManagedAuthLevel = REG_DWORD 5
  • No FVE policy values returned under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\FVE\%.
• Orbit/osquery logs include many network errors earlier in the file; the first disk encryption related entry seen:

ERR disk encryption failed due to previous unsuccessful attempt, user action required

• manage-bde -status output (summary):
• Volume C: Local Disk [OS Volume]
• BitLocker Version: 2.0
• Conversion Status: Fully Decrypted
• Percentage Encrypted: 0.0%
• Encryption Method: XTS-AES 256
• Protection Status: Off
• Key Protectors: Numerical Password, TPM
• No visible alerts or popups on the Windows device when Fleet attempts encryption.
• Host may have been previously managed by AirWatch, where BitLocker was known to work. Device was reportedly removed from AirWatch prior to this test.
• Actions already tried: reboot, manage-bde -off C:, waiting for Fleet’s retry. Issue persists.

QA plan

Prerequisites

• A Windows 10/11 VM with a TPM (can be virtual)
• TPM must be initialized and owned — open PowerShell as admin and run Get-Tpm, confirm TpmOwned: True. If not, run Initialize-Tpm -AllowClear
• Fleet orbit installed and enrolled in a Fleet instance. The host's team should have disk encryption disabled initially (you'll enable it per-test)

How to reset between tests

Run these in an admin PowerShell on the VM:

# 1. Disable disk encryption in Fleet UI for the host's team

# 2. Stop orbit
Stop-Service "Fleet osquery" -Force
Stop-Process -Name orbit -Force -ErrorAction SilentlyContinue
Stop-Process -Name osqueryd -Force -ErrorAction SilentlyContinue

# 3. Decrypt volume (skip if already decrypted)
manage-bde -off C:
# Wait until manage-bde -status C: shows "Fully Decrypted"

# 4. Remove all protectors
manage-bde -protectors -delete C:

# 5. Clear orbit log
Remove-Item "C:\Windows\system32\config\systemprofile\AppData\Local\FleetDM\Orbit\Logs\orbit-osquery.log" -ErrorAction SilentlyContinue

---

Test 1: primary bug scenario — OSEncryptionType=1

This is the actual customer bug. A device migrated from another MDM has an orphaned registry key requiring full disk encryption.

Prerequisite

Orbit enrolled in Fleet, team has disk encryption disabled, volume fully decrypted, no protectors.

Steps

1. Set the orphaned registry key on the VM:

   New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Force | Out-Null
   Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Name "OSEncryptionType" -Value 1 -Type DWord

2. Enable disk encryption for the host's team in Fleet UI
3. Start the service:

   Start-Service "Fleet osquery"

4. Wait ~2 minutes for orbit to fetch config and attempt encryption

Expected results

• Orbit log (C:\Windows\system32\config\systemprofile\AppData\Local\FleetDM\Orbit\Logs\orbit-osquery.log) contains: OSEncryptionType registry policy requires full disk encryption, using full encryption mode
• Orbit log contains: deleted orphaned OSEncryptionType registry policy value
• manage-bde -status C: shows Encryption in Progress or Fully Encrypted, with Numerical Password and TPM protectors
• Registry key is gone: Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Name "OSEncryptionType" returns an error
• Fleet UI shows disk encryption status as "Enforcing" or "Verified" with recovery key available

Tested on Azure VM: Yes — confirmed working.

---

Test 2: default behavior (no registry key)

Verifies that the fix doesn't break the normal case where no other MDM was involved.

Prerequisite

Orbit enrolled in Fleet, team has disk encryption disabled, volume fully decrypted, no protectors. No HKLM:\SOFTWARE\Policies\Microsoft\FVE key.

Steps

1. Ensure no FVE registry key exists:

   Remove-Item "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Recurse -ErrorAction SilentlyContinue

2. Enable disk encryption for the host's team in Fleet UI
3. Start the service:

   Start-Service "Fleet osquery"

4. Wait ~2 minutes

Expected results

• Orbit log does NOT contain OSEncryptionType messages
• manage-bde -status C: shows encryption in progress or fully encrypted with Numerical Password and TPM protectors
• Fleet UI shows recovery key available

Tested on Azure VM: Yes — confirmed working. No OSEncryptionType log messages, encryption started with both protectors, recovery key escrowed.

---

Test 3: stale protectors from previous failed attempt

Verifies that leftover key protectors from a prior failed encryption are cleaned up.

Prerequisite

Orbit enrolled in Fleet, team has disk encryption disabled, volume fully decrypted.

Steps

1. Remove any FVE registry key:

   Remove-Item "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Recurse -ErrorAction SilentlyContinue

2. Manually add a stale protector to simulate a failed prior attempt:

   manage-bde -protectors -add C: -RecoveryPassword

3. Confirm protector exists: manage-bde -status C: shows Numerical Password but volume is Fully Decrypted
4. Enable disk encryption for the host's team in Fleet UI
5. Start the service and wait ~2 minutes

Expected results

• Encryption starts successfully (the stale protector was removed and fresh ones added)
• manage-bde -status C: shows Numerical Password and TPM protectors
• Fleet UI shows recovery key available

Tested on Azure VM: Yes — confirmed working. Stale protector {FAD043A0...} was replaced with new protector {B15B6E0D...} (different IDs/passwords confirm cleanup). Encryption started with both Numerical Password and TPM protectors, recovery key escrowed.

[kitzy]

Unthread ticket: https://fleetdm.unthread.io/dashboard/inbox/filter/bfa51a24-39f6-4ec8-915c-018f63263eb3/conversations/0df75d42-935c-4964-b0df-aef8b365edd1

Slack thread: https://fleetdm.slack.com/archives/C050XE4CQNA/p1758781403975369

[JordanMontgomery]

@kitzy does the customer have any entries in the registry in the locations mentioned here: https://github.com/fleetdm/fleet/blob/main/docs/Contributing/architecture/mdm/disk-encryption.md#troubleshooting-1

Also are there any unapplied Windows updates? We have seen similar behavior when driver updates had not been applied.

[kitzy]

@JordanMontgomery see this comment for your question on registry entries.

Customer believes that the device is up to date on all Windows updates.

[noahtalerman]

@PezHub when you get the chance, can you please help us repro this one? Chatting w/ pingali, who's going to share osquery results with us.

In the meantime, let's try to repro.

[AndreyKizimenko]

Currently waiting for a reply from the customer in the attached Slack thread

[AndreyKizimenko]

I haven't been able to reproduce this issue locally. The customer ended up wiping the device, and it doesn't sound like the issue has reoccurred for them. Closing this issue for now, but happy to look into it more if we see it again