The goal of this article is to provide context for understanding Apple's remote MDM and DDM Software Update workflows, executed from Jamf Pro using Managed Software Updates. Please see the OS Updates Rubric attached to this article for more information regarding install action commands, OS compatibility, MDM update keys, and expected behavior.

The remote MDM command options we can utilize in Jamf Pro's Managed Software Updates (and Jamf Pro Mass Action OS Updates) are limited to the ScheduleOSUpdate command keys created and maintained by Apple for the different install and deferral actions for macOS.

Each install related action for the ScheduleOSUpdate command has different compatibility in regards to minor updates and major OS upgrades. For example, the keys InstallForceRestart and MaxUserDeferrals are only compatible for minor updates (macOS 14.x to 14.y), whereas the key InstallASAP is compatible with major upgrades (macOS 13 to macOS 14).

This is stated for the MaxUserDeferrals key in Apple's MDM Dev Guide but not for the InstallForceRestart key or the InstallASAP key. We were able to determine and confirm expected behavior for the InstallForceRestart and InstallASAP keys through testing and finding additional mentions of the expected behavior outside of Apple's MDM Dev Guide.

For example, in the “Deploying macOS Monterey” video from Apple, it is stated that the InstallASAP key is the install action that should be used for major macOS upgrades via MDM. In turn, this means that the InstallForceRestart key can not be used for major OS upgrades, which we have confirmed through testing the key with minor OS updates and major OS upgrades. All MDM & DDM keys and their Managed Software Updates commands are outlined below, for clarity.

Since MaxUserDeferrals, InstallLater, and InstallForceRestart are macOS only, this means iOS and iPad OS cannot use the Jamf Pro install actions "Download, install, and allow deferral" or "Download, install, and restart". Additionally, when using "Download Only" with iOS/iPadOS, trying to use the sub-option "Notify Only" will fail too, since that is also macOS only.

However, because iOS/iPadOS is compatible with Apple's new DDM keys, they can use the Jamf Pro install action "Download and Schedule to Install" — this would be the recommended alternative for iOS for the "Download, install, and allow deferral" and "Download, install, and restart" install actions.

As noted previously, which version/latest update options work with each install action type depends on the context and the starting OS, so there isn't a hard rule to fall back to for some of the install action and target version combinations. If the latest OS version available for the given device is a major upgrade, like macOS 13 to macOS 14, then the upgrade will be using a full macOS installer which utilizes the local InstallAssistant application on macOS. InstallAssistant apps can only be installed by MDM when the InstallASAP key is used by the Install Action, as noted in the Apple video about Monterey, so that is how InstallASAP and InstallForceRestart differ.

For both the "Latest Version Available" and "Latest Major Version" options in Jamf Pro, the computer will ping Apple servers to see what OS updates are available for it and then choose the highest possible version it is compatible with as the option to download, even if it is a major OS jump (such as macOS 13 to macOS 14).

If the highest compatible version is a jump to the next major OS, then the Jamf Pro install action "Download, Install, and Restart" will fail when combined with these target version options because of the InstallForceRestart key. So if we know a computer or computer group is eligible for a major OS upgrade, then we need to use the Jamf Pro install actions "Download Only" or "Download and Install" which contain the InstallASAP key.

The server asks the device for available updates and the device sends back a response list of what it has available. Then that list is compared to the currently installed/known version of OS on the device to decide if it should update or not. For example, if a computer is running macOS 13.x, it will only report back available updates in the 13.x series as being eligible to install.

The server looks to Apple’s gdmf.apple.com/v2/pmv feed of available software updates and offers a dropdown menu based on those results to choose from. After the command is sent, the device is asked to present its own available updates. If the device sees the version selected in Jamf Pro when sending the update command as available, the computer selects that update to move forward. If that version is not available, then the computer will not proceed further.

With this context in mind, this means that the Jamf Pro install action "Download, Install, and Restart" can only be used with the target version options "Latest minor version" and "Specific version", the latter option being dependent on the specified version being within the same major macOS version that the computer is already running.

For example, if the install action selected for a computer on Ventura is "Download, Install, and Restart" and the target version option selected is "Latest version based on device availability", "Latest major version", or "Specific Version > 14.x.x", we would expect the computer to reject the command or fail to kick off the update process due to the InstallForceRestart key not being viable for major OS upgrades.

For any computers on Ventura, the compatible install action would instead be "Download and Install" combined with target version options "Specific Version > 14.x.x", "Latest major version", or "Latest version based on device eligibility".

If an incompatible install action command for the given target macOS version is sent to a computer, the computer should respond to the server with an error along the lines of "Unsupported InstallAction for this ProductKey". However, there are instances of computers accepting the command but still not proceeding further locally. In these instances, live local console logs are needed from the affected computer to see what is happening at the computer level after the computer has accepted the MDM command.

An additional point of context to keep in mind is that the InstallASAP, InstallLater, and InstallForceRestart MDM keys have no resiliency which limits the progress information we receive back from the devices on the MDM side. Meaning, when a computer accepts an update command that contains any of those keys and sends an Acknowledgement response back to the server, it will not send a follow up update to the server later on if the update is interrupted or fails due to an issue like low battery or network/power interruption. This results in the update process failing locally, but because the MDM server isn't informed (as there’s no native mechanism designed by Apple for this yet), the server will not automatically send automated retries to the device in question.

Generally speaking, there is not really a single guaranteed upgrade method across Intel and Silicon devices due to the differences in hardware and how they interact with update/upgrade installers and their end users. For example, Intel computers rarely require any user interaction for an update or upgrade to take place, but Silicon computers do require forms of user interaction because the local user(s) must be a volume owner to perform software updates and upgrades. So if a normal update or upgrade via System Settings is initiated on a Silicone computer, there will be a popup requesting the local user password before the computer will proceed with the update or upgrade.

From the MDM side, this means Apple Silicon computers must have a Bootstrap Token escrowed to Jamf Pro in order to update automatically without user interaction. Because of these differences, environments with mixed Intel and Silicon computers may need to have two separate workflows for managing software updates, depending on the needs of the environment.

That said, Apple's remote MDM commands are designed for both Intel and Silicon computers, so as long as the Silicon Macs have escrowed a Bootstrap Token to the server, they should be able to process the commands without issue.