Sometimes macOS configuration profiles aren't removed

[noahtalerman]

Fleet version: Observed in Fleet's dogfood environment (commit 66b992e)

---

💥  Actual behavior

On 2024-02-14, @rfairburn and I ran the sudo profiles renew -type enrollment command on his macOS host to renew the SCEP client certificate. The SCEP client certificate had expired (more context here).

After waiting several minutes, all the expected profiles (Workstations team) were installed on Robert's macOS host.

However, there was one macOS profiles that wasn't removed: "Ad tracking"

Here's the full list of profiles:

🧑‍💻  Steps to reproduce

1. Add a macOS host to Fleet
2. Add some profiles
3. Renew the host's SCEP cert
4. Transfer the host to a different team and transfer it back to redeliver profiles

🕯️ More info (optional)

The current hypothesis is that we added the "Add tracking" profile (the ones that weren't removed) before we built features in Fleet to keep track of the expected profiles.

Thus, Fleet doesn't know that Robert's macOS host has some extra profiles that need to be removed.

🛠️ To fix

• UI change: Figma link

[roperzh]

@noahtalerman we did some digging into dogfood's db with @gillespi314 , and we found that this rogue profile has been lingering there for a while. Back in November we sent a RemoveProfile command for this profile, but we've got an error response and we never tried again.

With some of the improvements we did (better timestamps for the nano tables to respect command order + being smarter for "edited" profiles) I think this specific scenario won't happen again.

---

Having that said, there's a lingering question: what happens if for any other unforeseen reason we fail to remove a profile?

Right now we don't have a good answer to this. Looking at the code two things might happen depending on the error code:

• We ignore the failure and never try again (this is what happened to Robert's computer)
• We mark the profile as "failed"

Do you have any thoughts about this? we could do a variety of things: eg:

1. add removal retries
2. enhance the double checkmark logic to handle this case
3. always show the profile as failed (but needs copy updates to say "failed to remove")
4. etc

Tempted to make this a story so we can be prioritized vs other stuff we need to do and also you can build a holistic product solution.

[roperzh]

@georgekarrv I added the :product label and removed :release because this looks like it's going to take some product design, and not a bug per-se.

cc: @noahtalerman please feel free to relabel if I messed up

[noahtalerman]

Hey @marko-lisica your proposed UI changes LGTM 👍

[noahtalerman]

We ignore the failure and never try again (this is what happened to Robert's computer)

Thanks for the summary @roperzh! If I'm understanding correctly, in some cases we don't surface an error to the IT admin.

Do you know if we got an error back from the MDM protocol in Robert's case?

In this pass, we want to make a small improvement. If we fail to remove a profile, for all cases, surface the MDM protocol error to the user (similar to # 3 in your comment here)

See the expected UI in the Figma [here](Figma link).

Is this a smaller change? Will this change make it more difficult to enhance double checkmark and add retries later?

[roperzh]

@noahtalerman

Do you know if we got an error back from the MDM protocol in Robert's case?

yes! we got an error

In this pass, we want to make a small improvement. If we fail to remove a profile, for all cases, surface the MDM protocol error to the user (similar to # 3 in your comment here)

See the expected UI in the Figma [here](Figma link).

Is this a smaller change? Will this change make it more difficult to enhance double checkmark and add retries later?

yes, I think it won't make it more difficult later, and I like your proposed solution!