Behind the Curtain: Managing Software Updates with MDM

Over the past several years, Apple has made a number of deep platform changes to both macOS and Mac hardware that have resulted in enormous shifts in how Mac computers are deployed and managed. 

Among the most important:

• The introduction of APFS as the default filesystem for Mac computers brought an end to monolithic system imaging.
• The advent of the Apple T2 security chip and later Apple silicon provided increased protections to startup security and the integrity of low-level firmware. 
• The Signed System Volume (SSV) in macOS Big Sur put an end to the combo updater packages that had acted as universally compatible installers that worked across hardware models.
• A new user authentication requirement for the ubiquitous softwareupdate CLI tool on Apple silicon made it more difficult to use that tool securely in an automated fashion.

Given these and other changes, what was Apple’s recommended replacement for organizations that wanted to keep Mac computers up to date? The answer was—and will continue to be—mobile device management. As a familiar voice told Mac admins in the spring of 2021: “You should use MDM and the ScheduleOSUpdate command to deploy software updates to managed Mac computers going forward in an organization.” 

It can’t get much clearer than that! But what exactly does that mean? And what’s involved for MDM? Let’s take a look behind the curtain.

Commands and Queries

Since the introduction of macOS 10.11, Apple has offered the ability for an MDM solution to issue the ScheduleOSUpdate command to Mac computers to install software updates. 

However, many organizations and solutions (Kandji included) continued to use the softwareupdate CLI tool, because it offered more flexibility and could be more tightly integrated into customized on-device tools like the Kandji Agent. 

Using the CLI tool also avoided the back and forth round-trips between Mac computers and the device management solution, thus removing an additional dependency on the Apple Push Notification Service (APNs). But given that APNs is required for MDM in general, and because some modern Apple device management features aren’t possible without MDM, ultimately the dependency on APNs for update management is just an implementation detail; it shouldn’t require any extra work. 

ScheduleOSUpdate was originally supported on macOS after being added to the MDM protocol for use with iOS—after all, there are no agent tools available on iOS—but it remained mostly unused until last year. It’s now an important component of any comprehensive Apple device management solution. 

The flow to install a software update on a Mac computer via MDM prior to macOS Monterey was:

1. The MDM solution told the Mac to check for available updates, by sending the ScheduleOSUpdateScan command.
2. After waiting an arbitrary amount of time, the device management solution would then query the device for the full—and sometimes very long—list of updates using the AvailableOSUpdates query.
3. MDM would then send another command, ScheduleOSUpdate, instructing the Mac to install an update specified using a product key from the list of available updates.
4. To monitor the progress of the installation, the device management tool would then query the device for the status of the update using the OSUpdateStatus query, as often as it deemed necessary.

Visually, it looked like this, with the entire process having to be repeated for each step (swapping out the appropriate command or query in the blue rectangle): 

Repeating these steps over and over again for each device in a large fleet quickly became redundant. For example, if your entire fleet consists of just a few different Mac computer models, why should it be necessary to query every single device for the same list of available updates? Surely there would be some common updates in that list?

Several years ago, to solve the redundancy problem for iOS devices, Apple introduced the Apple software update lookup service, also known as GDMF (due to its hostname). GDMF serves up a JSON listing of supported device models and available OS versions. For example, it can tell an MDM solution that all iPhone 13 Pro devices support iOS 15.5, 15.4, and so on. 

As of macOS Monterey, Apple enabled that same sort of mapping for Mac computers. That means that a device management solution can periodically poll Apple for the mapping of compatible models to OS versions. And that means that steps 1 and 2  above can be completely eliminated for macOS updates, reducing overhead by at least 50 percent. 

When MDM instructs the device to install an update in this more optimized flow, it uses the version of the update, such as 12.4 or 15.5, instead of a product key obtained from a device itself through the AvailableOSUpdates query. 

Install Actions

Regardless of which flow is used, when the MDM solution sends the ScheduleOSUpdate command in step 3, it also specifies an install action. The install action defines what happens on the device. Supported actions for Mac computers include:

In macOS Monterey, Apple added an additional option to be used with InstallLater: MaxUserDeferrals, which is meant to be a built-in enforcement mechanism for OS updates initiated by MDM. MaxUserDeferrals specifies a maximum number of times a user can defer an update before it is installed automatically by macOS. 

Unfortunately, at the time of this writing, that option requires the user to explicitly act on the notification for a deferral to be used; it doesn’t automatically decrement deferrals each night. Thus, in practice it is not very useful for update enforcement; it won’t, for example, let the admin define that an update is installed by a specific date and/or time.

(If you use Kandji, take note: Kandji utilizes MDM commands to install OS updates on both Apple silicon and Intel-based Mac computers for macOS Big Sur and later, and supports date and time enforcement using a combination of the above install actions combined with intelligent logic and notifications delivered by the Kandji agent. For more information, see the Kandji Managed OS support article.)

Hopes for the Future

At WWDC 2022, Apple announced that the next generation of MDM, called declarative device management (DDM) will expand to all device and enrollment types in the fall 2022 OS releases, including macOS Ventura. We’re hopeful that this will bring additional capabilities to OS update management via MDM on macOS, including the ability to tell a Mac ahead of time that a specific update should be installed by a specific date and time. 

By using DDM, much of the back-and-forth communication of the existing processes could be even further reduced by moving the enforcement logic to the Mac itself, and perhaps by also offering the ability for MDM to subscribe to status reports on OS updates, instead of needing to continuously poll for it. The MaxUserDeferrals feature announced last year was a great step in the right direction. With just a few additional improvements combined with the ones that are inherent to DDM, the future could be incredibly bright. 

Editor’s note: To encourage these efforts, Kandji has filed the following feedback IDs (among others) with Apple. (ER stands for “enhancement request.”)

• FB10400912 – ER: MaxUserDeferrals shouldn't require user interaction to decrement the deferral counter overnight
• FB10400927 – ER: MaxUserDeferrals should bypass do not disturb as the update enforcement window approaches
• FB10400960 – ER: DDM policies for update enforcement, including date/time activation
• FB10400995 – ER: DDM status subscription for OS update status
• FB10401152 – ER: DownloadOnly for major macOS upgrades