Open marko-lisica opened 2 months ago
Hey @georgekarrv, this one is ready to be specified.
Hey @marko-lisica, @roperzh, and @georgekarrv, I added the decision we landed on ("local file solution" for handling hosts that disconnect from Wi-Fi) to the "fleetd changes" section in the issue description.
I included the rationale for going with this approach.
Please feel free to tweak it if I'm missing anything.
Also, George, heads up that it will be helpful for planning if we carve out a subtask for handling hosts that disconnect from Wi-Fi. This way, if it ends up being somewhat large (5-8), we can cut this.
Let me know how Marko or I can be helpful w/ spec'ing so we can get this one to tomorrow's estimation. Thanks!
@zayhanlon @dherder FYI this story is pushed to 4.56.0. We're confident it will ship in 4.56.0.
Note: we decided to remove the on-demand showing of the macOS Remote Management modal, because:
cc @noahtalerman
Pulled the below from MDM daily standup (internal):
MDM migration: we won’t be able to cover the case where a host is manually enrolled but added in ABM after all. This is due to a limitation of the profiles show command on macOS; it is client-side rate limited after 10 calls (it returns a locally cached response after the 10th call). This is possibly something we could figure out in a future iteration, but recommend that we just move forward with this limitation for now since there are other big stories we need to get done as well.
Hey @jahzielv just following up to make sure if I’m understanding correctly.
We will now run the sudo profiles --type show
command and show the Apple Remote Management screen (Figma here) if the host was manually enrolled.
But, if we hit the rate limit w/ the sudo profiles
command for some reason then we’ll show Fleet's My device page (Figma here) instead.
Sound right?
Hey @noahtalerman sorry, I think I might not have explained it well!
I was referring to the case where a host might be manually enrolled in a 3rd party MDM, but assigned to Fleet via ABM. We said that we'd want that host to go through the ADE migration flow. To detect this case, we were going to use profiles show -type enrollment
in Fleet Desktop. This command would tell us if the host was assigned to Fleet in ABM. There are 2 issues with this approach though:
profiles show -type enrollment
command. It can be called a max of 10 times per 23 hour period. After that, the command returns a locally cached response.sudo
, which is not possible in Fleet Desktop. We can't really make Orbit run it for Fleet Desktop due to a lack of inter-process communication. case where a host might be manually enrolled in a 3rd party MDM, but assigned to Fleet via ABM. We said that we'd want that host to go through the ADE migration flow.
@jahzielv that's right!
To detect this case, we were going to use
profiles show -type enrollment
in Fleet Desktop.
Why do we have to run the command? Don't we already know it's in ABM tho? Because we hit ABM API to get all hosts.
Unrelated to the above comment:
@marko-lisica, @PezHub, and @georgekarrv I was looking at the copy for macOS < 14 and I think we might be missing a step (I could be wrong).
I think the end user has to click on the macOS notification to get the profile to show up in System Settings. Is that right?
If Marko can't remember, George and Gabe can we please check this during QA?
Thanks!
@noahtalerman Thanks for catching this. I'm not sure if a user needs to click on the notification, so would be great to test that.
I was looking at the copy for macOS < 14 and I think we might be missing a step (I could be wrong).
@marko-lisica and I confirmed this earlier today on a call. He'll have a copy update for me to implement in the AM.
Why do we have to run the command? Don't we already know it's in ABM tho? Because we hit ABM API to get all hosts.
We need that command on the host to know which migration flow to send the user down. Fleet can only tell fleetd that some migration is needed, not which one specifically.
Fleet can only tell fleetd that some migration is needed, not which one specifically.
@jahzielv doesn't fleetd know whether it's in ABM or not? And if it is, go through the automatic enrollment migration (Remote Management screen)
@noahtalerman
doesn't fleetd know whether it's in ABM or not? And if it is, go through the automatic enrollment migration (Remote Management screen)
Fleet does know, but it only sends a single type of notification to fleetd to indicate whether a migration is needed, not which type. As currently implemented, the type is determined purely on fleetd. We'd need to change the notifications flow to make Fleet tell fleetd which type of migration to do in this case.
As currently implemented, I believe that the Remote Management
modal will be launched, but the swift dialog modal will have the images and copy for the manual case.
Perhaps this is a bug we could come back for in a quick improvement (only suggesting that because it's a very edge case)?
Thanks @jahzielv!
As currently implemented, I believe that the Remote Management modal will be launched, but the swift dialog modal will have the images and copy for the manual case.
Perhaps this is a bug we could come back for in a quick improvement (only suggesting that because it's a very edge case)?
Up to @marko-lisica.
Perhaps this is a bug we could come back for in a quick improvement (only suggesting that because it's a very edge case)
@jahzielv I agree, this is an edge case and I think we shouldn't change anything right now, in order to move quickly. We can always improve this later if we learn this is a real problem.
cc @noahtalerman
Goal
Context
macOS 14 (Sonoma) introduced a new experience for macOS hosts in Apple Business Manager. Instead of a notification that appears in notification center, new dialog pops up over whole screen. In "Forced" migration mode, Fleet shows a window every 15 minutes to end user, telling them to start migration process.This Fleet window conflicts with new macOS Sonoma experience.
Changes
Product
Engineering
QA
Risk assessment
Manual testing steps
Testing notes
Confirmation