fleetdm
Error resending Disk Encryption profile for Windows host
Fleet version: 4.55
💥 Actual behavior
A Fleet customer is getting an error message when trying to resend the built-in Disk Encryption profile on a Windows machine after the initial delivery failed. The initial delivery failed because bootable media (CD or DVD) was detected in the computer.
After clicking the resend button, Fleet displays an error message: Couldn't resend. Please try again. at the top of the page.
Using the browser's web inspector, when the resend button is clicked, Fleet is attempting to make an API call to /api/latest/fleet/hosts/:id/configuration_profiles/resend/0 and failing with reason: "Invalid profile UUID prefix."
🧑💻 Steps to reproduce
- Enroll a Windows host into Fleet with Windows MDM enabled.
- With bootable media in the disk drive, assign the host to a team with disk encryption enabled. This should cause the delivery of the Disk Encryption profile to fail.
- Upon failure of the profile delivery, click the resend button in the Fleet UI to observe the error message.
🕯️ More info (optional)
After spinning my wheels on this bug for a bit, the penny finally dropped: the command UUID is 0 because we do not use MDM commands at all for bitlocker! it's implemented in Orbit; if Fleet determines that the disk needs to be encrypted, then it sends a notification to Orbit to do the encryption.
Seems to me like a fix will require product input. One fix could be:
- Remove the ability to "resend" a failed disk encryption attempt
- Add a retry mechanism that will continue to send the notification to Orbit if there is an error on the previous encryption attempt. There are several errors that can be encountered while encrypting the disk. Should we retry regardless of error, or just for certain ones? The one in the ticket (bootable media present) I think should be retried, since the end user can address that pretty easily by ejecting the bootable media.
Once we pick a path forward, part of the PR for this fix should include updating this test.
cc @georgekarrv @noahtalerman
I would say not changing the behavior on retries today but just allowing the re-send for that to trigger the orbit notification again should be enough.
@georgekarrv from taking a deeper look at the code, seems like we're already retrying if there is an error, in the sense that the orbit notification for enforcing bitlocker is sent even if there was an error in a previous attempt.
I would advocate for removing the "resend" affordance in this case, since it is confusing (because bitlocker enforcement is implemented as an orbit notification, you can't properly "resend" since the notifications are polled from the orbit side).
We could also just have the "resend" button be a no-op when it's for bitlocker.
Happy to go either way, or come up with a 3rd option if needed!
This was discussed at standup today, passing back to Marko for design review 🫡
Hey @jahzielv, I'm moving this bug back to the release board. The fix is specified in Figma attached to the issue description.
FYI @rachaelshaw @mostlikelee this bug made me realize that I think we want to hide the "Resend" button for Linux hosts as part of #22074
IIRC there's no MDM command or script that Fleet is sending to enforce disk encryption on Linux.
we want to hide the "Resend" button for Linux hosts
@noahtalerman thanks for flagging, @mostlikelee thanks for forwarding – already handled this 👍
@jahzielv heads up this will (also) address the "hide send" button part of this issue, in case that merge conflict comes up
QA Notes:
Was able to reproduce the error using a Proxmox VM with a mounted windows ISO file (Virtual CD Drive). I can confirm the Resend button is gone and the copy has been updated. However we have a small typo = missing a period before Fleet will retry automatically.
Additionally I was able to confirm via the Orbit logs that Fleet resends the encryption profile after failure (as indicated in the hover hint)
Error fixed, peace resumes, Fleet's light through Windows now streams. Secure data blooms.
