One action for turning off MDM, removing fleetd, and deleting a host in Fleet

[nonpunctual]

Scenario:

A previously enrolled device must be reissued to a new user or used for testing (i.e. repurposed)

• If scripts are used to remove the fleetd agent:
  • There’s no feedback from the scripts after the agent has been removed
  • Admins can’t be sure that a host enrolled previously in Fleet is a net new enrollment
• Host expiry is a workaround but not a permanent solution

Feature Parity:

macOS

• Unenrolling Macs works consistently & is straightforward
  • Disabling MDM causes Configuration Profiles to be removed
  • A command or script can be run to remove fleetd
  • A command or script can be run via the API to remove the Host record from the Fleet server

Windows

• Disabling MDM does not remove device profiles
  • It is understood that the behavior of Windows device profiles is not identical to Configuration Profiles in macOS
  • The equivalent behavior would be for settings enabled via MDM to be disabled
  • Depending on the Windows feature in some cases this may not be possible
• fleetd is not removed from a Windows computer if MDM is disabled
• Tracking of enrollment status is lost on the device once the MDM connection is broken

Problem

Customer-preston is concerned about:

• Device / employee offboarding
• Device repurposing
• Unenrolling Hosts at scale (e.g., if a customer-preston cancels a contract)

given that there is not as much control or predictability as they would like to have over unenrollment behavior & would like to have an easier-to-use, complete workflow to unenroll a device handled by Fleet automatically even though workflows for unenrollment that can be cobbled together with current features.

Potential solutions

1. Include a button in the Fleet UI & an API endpoint that 1) Completely uninstalls the fleetd agent client-side 2) completely removes the Host device record permanently server-side. This feature should be designed to work on 1 Host or on multiple Hosts simultaneously in a single action / call.

[noahtalerman]

A previously enrolled device must be reissued to a new user or used for testing (i.e. repurposed)

@nonpunctual the current best practice for repurposing a device is to wipe it via UI, API, or CLI.

Do you know why this doesn't work for the customer?

[nonpunctual]

1. @noahtalerman I beleve the ask here is clear & atomic:

• Include a button in the Fleet UI &
• an API endpoint that:
  • Completely uninstalls the fleetd agent client-side
  • Completely removes the Host device record permanently server-side.
• This feature should be designed to work on 1 Host or on multiple Hosts simultaneously in a single action / call.

2. Further context:

For an MSP (or often even for admins if they are managing remote workers) there is no hands-on device access & there is often little or no contact with an end user.

There are features of Fleet that attempt to make repurposing a device easy that are not clear or documented well &, in my opinion, don't follow the best practices an admin managing devices would expect.

If a device record is removed server-side, there should be no way for a device to be recognized as a device that was ever enrolled before. A new, unencumbered record should be associated with a net new device. In Fleet a new record for enrollment is created if a device is re-enrolled, but, for Windows (& in some cases even for Mac) the enrollment state can be ambiguous.

If the agent is removed server-side, there should be no way other than a net new enrollment that the device from which the agent was removed could be recognized as previously enrolled.

Features that recognize previous enrollments would be ok / nice-to-have if all cases & behaviors were documented. Some of the enrollment behavior in Fleet is unpredictable which is why there have been numerous FR & bug reports around it.

I will search & collect the FR & bugs related to enrollment in a comment in this issue for reference.

To guarantee that an unenrollment is successful customer-preston believes Fleet should handle all aspects of the unenrollment workflow, i.e.,

• delete the fleetd agent client-side
• give meaningful feedback / ack in the UI or in an http repsonse data that this was done correctly
• delete the Host record

What is not working for the customer is the current prescribed methods in practice. They would not be asking for a more reliable workflow if the current methods achieved their desired result.

[valentinpezon-primo]

Hi @noahtalerman @nonpunctual ,

Disenrolling a windows computer, in the case where you do not want to Wipe it, is a huge pain. Especially if you want to do this for a lot of devices.

To disenroll a Windows device for end users, at scale, using API only, we have to do 3 steps, in a synchronous manner :

1 - Run a script that turn off MDM on the host

• Wait that this script is actually properly executed and successfull

2 - Run a script that remove the fleetD agent

• Here, you never know if the script was successfull or stuck in the queue. Since the agent is removed, you have no feedback on the script

3 - Then you proceed to delete the host from Fleet, assuming the previous script went well (this is already very hard to implement programatically already)

Now, imagine a scenario where you do all of the above, programatically, for 2 separates hosts, and then this happens :

• For host A, every script and steps work, and the device is truely disenrolled (you are not able to know that programatically btw but lets assume it went well)
• For host B, the script that removed fleetD failed (but we still deleted the host from fleet)

Here we are stuck in a loop because, what if theses 2 devices comes back to fleet, how are you able to know if :

• This is a re-enrollment
• The disenrollemnt failed, and you need to run the disenrollment flow again ?

Imagine you have to do this for lets say 100 devices.. :(

[noahtalerman]

This one contributes to Jamf parity.

[nonpunctual]

@noahtalerman thanks for locating the dupe!

[nonpunctual]

The comments above are related to app installs but also to how Fleet handles un-enrollment. If devices were cleanly un-enrolled this type of record keeping would not conflict with actual device state.

[zayhanlon]

@ddribeiro @pintomi1989 i'm taking this off as we selected a few other key priority asks for this customer. please bring this back to the next prioritization call

[nonpunctual]

related: https://github.com/fleetdm/fleet/issues/22820