Trouble with using MDM updates in Monterey

[JSzinger]

I am having a lot of trouble having users kick off MacOS updates from the kiosk.

 I create the specific MDM updates in FileWave and add it to the the kiosk and try to kick them off.  The update says installed, sometimes it says 'downloading' for the fileset status in the Admin and it mostly does nothing.  Any advice?  

[Josh Levitsky]

I wonder if this is because when you pick to install an MDM update it really does the notification from FW to Apple to ask Apple to ask the device to update and then it would download to the device and run so perhaps that could take a variable amount of time. Aside from it saying Installed where maybe it's not really yet installed does it eventually appear to install some time after? If you look in FileWave Central (Admin) what does the FileSet status look like when you pick a device? Does it just say "Handled by MDM" like it is waiting to see how it goes? Maybe @Sean will have a thought on this but I'm thinking it's because MDM updates aren't directly pushed from FW -> device that introduces complexity to what is seen. That's not to say that it shouldn't be better, but I'm thinking that's the reason. 

[JSzinger]

I see different statuses.  Sometimes it days Downloading with a % and just sits there. I will run a few tests and see what feedback I can give you.  As far as the feedback from the kiosk, it just switches to 'Uninstall' after a brief time. I have had Macs sitting for up to an hour waiting for the update.
From what I hear from others on different MDMs is that this process can be hit and miss and Apple promises to fix it after each update.  

I guess I am looking for an idea to apply these updates reliably.  I have considered sending the full installer to these Macs and having FW trigger that but that is downloading 4x the data and it would have to come from us.

Maybe there is another way to trigger a specific install through the terminal, I know Apple is preventing us from using 'software update -iaR' in a script via FileWave.

[Larry Benshoof]

We also have had issues with the macOS MDM software updates. We send via SoftwareUpdate, not the Kiosk. We get about a 40% return of actual successful installs. The biggest issue for us has been that the update can kick off without any warning to user. Using the Rollout Plan on FileWave Anywhere seems to help at least keep the restart damage to off-hours but the behavior is wildly inconsistent. Some users get notifications and options to install/try later. Others get no notifications but the update is sitting ready in the Software Update preference pane, and the some just get restarted. Overall not a great experience for our department or the end users. We have been heavily communicating with users to install updates via the Software Update preference pane and once we got everyone to 12.6.2 that has been working well to get users up to Ventura via Software Update (as a standard user). We are testing Nudge to use going forward to give our users better notifications and timelines to install updates. A couple things that helped us get to 12.6.2 were: 1 - removing the software update plist from the Managed Users folder (/Library/Managed Preferences/com.apple.SoftwareUpdate.plist) there is also one of these files for each user in that folder. 2 - restart and immediately check for software updates and install right away (often used in conjunction with #1, but sometimes just a restart gets what you need).

[Josh Levitsky]

On 1/19/2023 at 1:27 PM, Larry Benshoof said:

We are testing Nudge to use going forward to give our users better notifications and timelines to install updates.

I've seen Nudge used by folks from all the main MDM solutions. It's not optimal because MDM pushing of updates should work, but I've seen that Apple's part of the MDM triangle frequently is a source of issue. Doing a bit of research I found this to be the case. Nudge does seem fairly easy to implement and does empower your users to install when they want to but to annoy them just enough to make sure the update is installed. The only real obstacle someone might have to implementing it would be to have an Apple Developer account which is easy to sign up for and is $99/year. If you do make apps for your org make sure you don't build them in your own personal account in case you leave the organization in the future. https://www.macadmins.org/ has a #nudge channel that is active. I added one to our Discord https://discord.gg/filewave as well but I don't know that there are experts there on this topic yet. 

We'll obviously always continue to develop the MDM push of OS updates and do everything we are able to in order to make them as reliable as possible. I think also consider if your organization needs an Apple Caching Server. One reason for updates not to reliably be distributed could be if you have a lot of devices all pulling from Apple at about the same time and perhaps they throttle the connection. A caching server is better for bandwidth and offers more reliability for devices that are inside your network. 

[Sean]

• We initially send a ScheduleOSUpdate as an MDM command to inform the device to talk to Apple to action the update.  It then commences the download.
• We periodically send OSUpdateStatus as MDM commands which will tell us how far it has got in downloading so far.  (Apple don't automatically send back how the update is doing, so we have to keep asking).  I think we send these every 5 minutes.
• Once reported back as download completed from the OSUpdateStatus command, we then send ScheduleOSUpdate MDM command again, but this time it should instal the now downloaded update

If the command is acknowledged, then everything is down to Apple thereafter, but that goes for each command sent, of course.

There have been multiple bugs with this whole process, e.g.

• Device does not report updates it requires
• Sometimes the device reports updates it requires
• Device will report an update as required, but then when the command is received to action that update, the device then fails to report it as required (it reconfirms in case the update has been actioned otherwise since) and the command is ignored.  Since the command needs to be sent twice, once to download and again to instal, the device might action the download, but then ignore the request to instal it!

Due to the silent ignoring of the request, we may not get any failure information back from the device, and as such the Fileset might appear as complete, even though it hasn't done the requested update.

Kiosk being involved is meaningless, as long as the command is acknowledged.

Commands can be viewed from the Command History tab of a Client's Info.

I've tested this whilst writing this on a single device with a Safari update.  First OSUpdateStatus command reported 30%, with the next reporting 97% download complete.  There have been two more OSUpdateStatus commands sent since and it still reports 97% complete.  So each 5 minutes we are going to keep sending this status report from the server and it looks at the moment like it is going to be stuck here forever.

Clearly we don't expect the situation that the download will never complete, so we don't expect to be constantly sending out OSUpdateStatus commands to devices, they should eventually and naturally disappear once download is finalised.  

Oh and the next one has just reported 97% complete still again.  I imagine that the download did complete, but the device doesn't think it needs the update anymore so isn't replying to the request for the download status and so we are stuck in limbo.

 

 

 

[mdspidle]

How do you send an MDM command "We periodically send OSUpdateStatus as MDM commands". Is this done somewhere in FileWave?

[Sean]

It is automatic.  It will occur at multiple points, e.g. Update Model, Inventory, Verify, etc. We then know what to push to the device based upon the latest manifest and the current device details.  A series of MDM commands are sent together, one of which is the OSUpdateStatus.  When we get the reply, we then know whether to send additional commands or not to devices.  E.g ProfileList command will be sent, the reply will be compared with the manifest and, if need be, commands to instal or remove Profiles will be sent to the device.

Manually the process can be triggered on a single device just by opening the Device Info and selecting the Command History view.  If there are not already queued entries, then a fresh set of commands should be triggered at this time.