Fleet version:
Fleet 4.46.2
Go go1.21.7
osquery 5.11.0
orbit 1.22.0
Web browser and operating system:
macOS 14.3.1
Google Chrome Version 122.0.6261.112
Parallels Desktop Version 19.2.1 (54832)
VM:
Windows 11 Pro 23H2 10.0.2262
💥 Actual behavior
- Enrolled a Windows VM in Fleet
- Immediately after enrollment began a notification popped up that said Bitlocker was enabled.
- The computer name was changed several times via script, queries were run against it, & it was eventually deleted from Fleet.
- After deletion, I ran the same .msi package on the Windows VM I used to originally enroll it. The file size is too big to attach. I can provide it if needed.
- After "re-enrollment" the Bitlocker status in Fleet shows as "Off" but the Windows VM GUI settings show the computer as encrypted. None of the Bitlocker settings on the computer were touched or changed.
🧑💻 Steps to reproduce
- Enroll a Windows computer in Fleet.
- Ensure that Bitlocker has been enabled via MDM.
- Ensure the Windows GUI settings show Bitlocker is enabled.
- Delete the computer from Fleet.
- Re-enroll the computer into Fleet ideally using the same .msi package as before.
- Verify the Disk Encryption status in Fleet says "Off".
🕯️ More info (optional)
Disk Encryption status will likely eventually update after some delay. Regardless, the bug being reported is that the Disk Encryption status immediately after re-enrollment should actually match the state of the device.
If Fleet can't know the state at that point it should say "--" or "null" or whatever in the field. It seems like what may be happening is the Disk Encryption attribute defaults to "Off" if there was a previous record for the same device.
Fleet version:
Fleet 4.46.2
Go go1.21.7
osquery 5.11.0
orbit 1.22.0
Web browser and operating system:
macOS 14.3.1
Google Chrome Version 122.0.6261.112
Parallels Desktop Version 19.2.1 (54832)
VM:
Windows 11 Pro 23H2 10.0.2262
💥 Actual behavior
🧑💻 Steps to reproduce
🕯️ More info (optional)
Disk Encryption status will likely eventually update after some delay. Regardless, the bug being reported is that the Disk Encryption status immediately after re-enrollment should actually match the state of the device.
If Fleet can't know the state at that point it should say "--" or "null" or whatever in the field. It seems like what may be happening is the Disk Encryption attribute defaults to "Off" if there was a previous record for the same device.