Context

People who administer Mac deployments at a large-ish scale (hundreds to tens of thousands—i.e., large enough that you have to automate things and can’t physically touch every machine to change settings or install updates) generally want to be able to patch software and macOS while giving a decent user experience.

I think you’ll find the vast majority of Mac admins (at least the ones on the MacAdmins Slack) don’t use MDM commands to install Apple software updates.

What we used to be able to do was use the softwareupdate binary to script installs of software updates, but Apple’s made it so that binary is unreliable for installing updates.

You can patch Macs with the full macOS installer, but there are downsides to that, too. (More details in Using a full macOS installer with Munki to patch macOS.)

So a lot of Mac admins are relying on the “bother users until users install updates” approach, leveraging open source tools like Munki, Nudge, or Deprecation Notifier.

Example from Munki

Testing the MDM command to install macOS updates

Well, why not use your MDM to send a command to install an update? That’s what Apple wants you to do.

Well—apart from the fact that Apple will allow you (via configuration profile) to delay updates for only up to 90 days—the user experience is terrible.

I’d tried it before and found it lacking, but I tried it again recently, and I’d recommend avoiding it at all costs. This is what my testing experience was like…

For a VM Mac on an older build of Catalina, I sent a command from the MDM to install OS updates (no ability from Jamf, it seems—someone correct me if I’m wrong—to specify which update).

After about a minute, a notification appeared on the Mac in the top-right corner of the screen saying that an OS update is available, with the options to try again in an hour, try again later tonight, or remind tomorrow. I didn’t select any option. I just left it there.

Then, I got another notification about the update being available (that appeared on top of the first notification) with the option to click for details. I clicked on the details, and it opened in System Preferences > Software Update with a note about the update being scheduled to install later tonight (no specified time).

Since this was a VM, I suspended it (I don’t believe this is the same as putting a real Mac to sleep), because I wanted to see if the update would install the next morning.

The next morning, the update was still pending. So I left the VM up all night with some unsaved changes in a Numbers spreadsheet as well as Chrome open with a bunch of tabs.

Came to find out the update installed by itself (no user interaction or approval) at 5:30pm (at “night”) and the OS, rather than updating to the latest Catalina build, upgraded to Big Sur. Oddly enough, it wasn’t to the latest available Big Sur release (11.2.3, at the time of the test) but to a slightly older Big Sur release (11.2.1).

More importantly, even though Chrome prompted to restore the tabs from the interrupted session, all my unsaved changes in Numbers were lost (they weren’t important to me, because this was just a test, but this is indicative of what real users might encounter if you just send an MDM command to install pending OS updates).

So, yeah, if you’re wondering why Mac admins just bother users (or coerce users via lost SSO access) to install macOS updates rather than using an MDM to send a command to install OS updates, this is why.

Problems in Summary

• Apart from using a profile to delay updates for up to only 90 days, there doesn’t seem to be a way (at least with Jamf—maybe other MDMs can?) to specify what update to install, which could likely result in older macOS versions upgrading rather than updating.
• The OS update/upgrade will just install at the (mysteriously unspecified) “scheduled” time without any user interaction or approval.
• Because there is no user interaction, unsaved changes to files are left solely up to the programs themselves to recover what you lost. Of course users should save files often, but they shouldn’t lose all their work because you decided to randomly reboot their machine.
• The upgrade itself may not even upgrade you to the absolute latest build available, which means the user may have to update again to get to the latest build.

I have very little faith that Apple will ever implement an automated macOS update command via MDM that will be a good user experience or ensure that users will never lose unsaved changes because of an unexpected reboot, but I’d love to be wrong about this.