Skip to main content

Greetings Jamf Nation!

Many organizations are likely running software updates on their fleets this week, as well as with new Jamf Pro versions. As a Jamf who knows a few things about macOS software updates and their various nuances, I want to share a couple tips, as well as explain a bit of what goes on behind the scenes in the macOS update process, specifically by way MDM commands on macOS 11.2 or greater.

Some organizations deploy macOS updates leveraging a full installer and the startosinstall command, some will use tools to compel users to update on their own, and other will use Jamf policies or MDM commands to update.

As the macOS 11.6 release is not yet distributed in a full installer by Apple, there can be some downstream consequences to an organization's preferred software update workflow, including issues updating to that version via MDM commands due to PI-009722, explained later in this post with workarounds.

 

tl;dr – Summary is all at the bottom...

 

Why MDM-based updates?

  • In Jamf Pro, policies can be made for software updates for Intel Macs, whether it's a native Software Update payload, or a specific "Files and Processes" policy containing the `softwareupdate -iaR` command.
    • Note: use of command line or agent-based updates can't update something if it's deferred by a configuration profile restriction.
  • For computers with Apple silicon, updates require authorization with a volume owner user's password, or macOS can request and use a bootstrap token escrowed with Jamf Pro if an update was scheduled with an MDM command, avoiding the need for user interaction to authorize an update.
    • Note: software updates scheduled by MDM commands override any deferral settings from configuration profiles, as devices report ALL available updates (even deferred) when an MDM server queries which are available.
  • macOS updates via MDM commands are available to both types of computer processors, both Intel and Apple silicon, and further enhancements to end-user experience are coming to macOS 12 from Apple. 

Note: Not all organizations wish to automate software updates with commands, and would rather guide users to install it on their own time. For that, there's a great app called Nudge which can be deployed and configured to achieve user-led updates as well. (There's also a Jamf Pro Applications and Custom Settings schema for the app, so the settings can be configured in the Jamf Pro UI.) 

 

More info on managing software updates and the specific sets of commands used for it can be found in Apple's MDM Guide for IT, or added to this post later. (I'm already sensing I'm writing a bit much here.  😀)

 

Changes in macOS 11 to AvailableOSUpdate queries

Here are a number of things we've observed about software update queries in macOS Big Sur during its release availability:

  • Prior to macOS 11, computers would only respond with the latest point release of macOS as available, and therefore Jamf Pro would instruct computers to install all available updates that were reported as available.
  • In Big Sur, computers will report back to MDM -ALL- available versions of macOS it can find, often including the version that is currently installed on the computer. That means a computer with macOS 11.4 can report back to an MDM server that the following versions are available: 11.4, 11.5, 11.5.1, 11.5.2, and now macOS 11.6 as of this writing.
    • Note: Jamf Pro 10.32 has changes in logic for parsing out the latest, non-major macOS update, and only instructing computers to install that version. Major updates, (like from macOS 11.x to macOS 12, when available,) can be installed using MDM commands within Mass Actions.
  • Beyond just the numerical version of a macOS update, there are also two distinct types of updates and installers that can be reported back within an MDM query: Full "InstallAssistant" macOS installers, and "MSU Update" or "patch" style updates, (which are what users would receive when clicking in System Preferences to update.)
    • Both types of updates can leverage a Bootstrap Token with Apple silicon
    • Both types of updates are handled differently on macOS, with certain versions of macOS 11 having issues with full installers, or full installers installs when a user with Standard privileges is logged in.
    • Ideally, the "patch" style of update is preferred, as it uses less bandwidth, and is similar to normal user-driven updates.
  • The first MDM AvailableOSUpdates query will only list full macOS installers, and not the available "patch" update versions.
    • This is captured in PI-009722, "(Third-Party Issue) When the Download Only or Download and Install Updates commands are executed on supervised computers with macOS 11.2 or later the AvailableOSUpdates query responds with product keys for full macOS installers instead of macOS patch versions. This causes inconsistent results on target computers."
    • Combined with the lack of a full macOS 11.6 installer, this means that the first AvailableOSUpdates query ran on a computer will not report this version as available to Jamf Pro. The second time the command is run, the computer will inform Jamf Pro of the appropriate available updates will be reported within the query response.
    • An upcoming release of Jamf Pro has additional logic built in to work around the issue in PI-009722 without needing the workaround below.

 

Summary of successful macOS update workflow using MDM commands, and workaround for PI-009722: (at the time this writing)

  • Start on Jamf Pro 10.32.x version, so only the latest macOS version is instructed to be installed
  • Run a synthetic MDM query of AvailableOSUpdates command in a Jamf Policy
    • "Files and Processes" payload, "Execute Command" and enter:
      /usr/libexec/mdmclient AvailableOSUpdates
  • After the command runs, send the Download and Install Updates command or Mass Action to target computers

 

If you're curious to see the user experience and try any of these updates yourself, it's advised to first test on individual machines before sending Mass Action MDM commands.

 

I hope this is helpful to anyone who reads it!

My Jamf rep just said the solution was in this post...but I am not seeing any solution to upgrading a mac to Monterey yet. Has anyone gotten a good workflow to have a standard user (like a student) be able to launch the update from Self Service? The Mass Action stuff is absolutely useless. In what world can someone just send a mass action command to update and then have end user laptops suddenly blast into an update in the middle of a class or worse, a community wide zoom session that we are broadcasting etc....? 

My Jamf rep just said the solution was in this post...but I am not seeing any solution to upgrading a mac to Monterey yet. Has anyone gotten a good workflow to have a standard user (like a student) be able to launch the update from Self Service? The Mass Action stuff is absolutely useless. In what world can someone just send a mass action command to update and then have end user laptops suddenly blast into an update in the middle of a class or worse, a community wide zoom session that we are broadcasting etc....? 


I am guessing that how it does work is described many times over in this post is what they are referring to as a solution.. Mass Action is the only way that did not require the local user to be an admin, and now on M1 devices that still requires local admin. That said Mass Action is not for major OS releases (at least my understanding) . Policy seems to work (just kind of inconsistent on its messaging) but again requires a local admin account. I find Jamf support to be pretty good on somethings, but on OS updates specifically the message just seems to be  "it is, what it is". 

Ive been trying to do the Mass Action for years, every-time i call support on it they say to use a policy, which works sometimes, but still needs to be initiated while a user is logged in (or i missed a step), so not a great solution for a Lab.


funny part (or not)  is when I called about policy they sent me a link on mass action

My Jamf rep just said the solution was in this post...but I am not seeing any solution to upgrading a mac to Monterey yet. Has anyone gotten a good workflow to have a standard user (like a student) be able to launch the update from Self Service? The Mass Action stuff is absolutely useless. In what world can someone just send a mass action command to update and then have end user laptops suddenly blast into an update in the middle of a class or worse, a community wide zoom session that we are broadcasting etc....? 


Ha, there is no solution in this post. I think you got a runaround. This thread really has nothing to do with OS upgrades. Its all about JAMFs miserable support of OS updates.

 

Once you get the install macOS monterey.app on to a Mac kicking off the upgrade is a simple matter of running a policy. With a policy you can set all kinds of limitations.

 

The nuts and bolts of the upgrade script would just be

"/Applications/Install macOS {version here}/Contents/Resources/startosinstall" --agreetolicense --nointeraction --forcequitapps

 

Getting the install macOS {version} to the Mac is another story. You can use VPP and tell the appstore app to force install, or you can use a terminal command which should fetch the most recent version of macOS.

softwareupdate --fetch-full-installer

 

Or do what I do since I am a control freak. download Monterey, package it with composer as a .dmg. Deploy it as a policy (caching the dmg) and run a script like this to move it to applications. I took out all the Parameter and Variables so its easier to follow along. I run this in the background weeks before actually upgrading devices. If the installer is in place 1st upgrading is literally just a matter of running a script from a policy.

#!/usr/bin/env bash

## Mount DMG file with no browse to hide the desktop icon
echo "...Mounting /Volumes/Install_macOS_Monterey_12.1"
sudo hdiutil attach "/Library/Application Support/JAMF/Waiting Room/Install_macOS_Monterey_12.1.dmg" -nobrowse

## Install PKG
echo "Copying MacOS Installer to /Applications"
sudo cp -R "/Volumes/Install_macOS_Monterey_12.1/Applications/Install macOS Monterey.app" "/Applications/Install macOS Monterey.app"

## Wait 20 seconds to allow for package to transfer
sleep 20

## Unmount DMG
echo "Unmounting /Volumes/Install_macOS_Monterey_12.1"
sudo hdiutil unmount "/Volumes/Install_macOS_Monterey_12.1"

## Wait 20 sec to make sure DMG unmounts
sleep 20

## Delete DMG
sudo rm -rfv "/Volumes/Install_macOS_Monterey_12.1"

 

 

 

Ha, there is no solution in this post. I think you got a runaround. This thread really has nothing to do with OS upgrades. Its all about JAMFs miserable support of OS updates.

 

Once you get the install macOS monterey.app on to a Mac kicking off the upgrade is a simple matter of running a policy. With a policy you can set all kinds of limitations.

 

The nuts and bolts of the upgrade script would just be

"/Applications/Install macOS {version here}/Contents/Resources/startosinstall" --agreetolicense --nointeraction --forcequitapps

 

Getting the install macOS {version} to the Mac is another story. You can use VPP and tell the appstore app to force install, or you can use a terminal command which should fetch the most recent version of macOS.

softwareupdate --fetch-full-installer

 

Or do what I do since I am a control freak. download Monterey, package it with composer as a .dmg. Deploy it as a policy (caching the dmg) and run a script like this to move it to applications. I took out all the Parameter and Variables so its easier to follow along. I run this in the background weeks before actually upgrading devices. If the installer is in place 1st upgrading is literally just a matter of running a script from a policy.

#!/usr/bin/env bash

## Mount DMG file with no browse to hide the desktop icon
echo "...Mounting /Volumes/Install_macOS_Monterey_12.1"
sudo hdiutil attach "/Library/Application Support/JAMF/Waiting Room/Install_macOS_Monterey_12.1.dmg" -nobrowse

## Install PKG
echo "Copying MacOS Installer to /Applications"
sudo cp -R "/Volumes/Install_macOS_Monterey_12.1/Applications/Install macOS Monterey.app" "/Applications/Install macOS Monterey.app"

## Wait 20 seconds to allow for package to transfer
sleep 20

## Unmount DMG
echo "Unmounting /Volumes/Install_macOS_Monterey_12.1"
sudo hdiutil unmount "/Volumes/Install_macOS_Monterey_12.1"

## Wait 20 sec to make sure DMG unmounts
sleep 20

## Delete DMG
sudo rm -rfv "/Volumes/Install_macOS_Monterey_12.1"

 

 

 


I think the problem here is that the upgrade policy method does not work on Apple Silicon machines.  Mass action or individual computer MDM commands are the only option that seem to work from my experience and research.

I think the problem here is that the upgrade policy method does not work on Apple Silicon machines.  Mass action or individual computer MDM commands are the only option that seem to work from my experience and research.


I have not tried this on AppleSilicon yet, I was thinking about that just a moment ago. I think MDM command is the only way to do it and JAMF has absolutely horrible support for MDM commands involving software updates.

Ha, there is no solution in this post. I think you got a runaround. This thread really has nothing to do with OS upgrades. Its all about JAMFs miserable support of OS updates.

 

Once you get the install macOS monterey.app on to a Mac kicking off the upgrade is a simple matter of running a policy. With a policy you can set all kinds of limitations.

 

The nuts and bolts of the upgrade script would just be

"/Applications/Install macOS {version here}/Contents/Resources/startosinstall" --agreetolicense --nointeraction --forcequitapps

 

Getting the install macOS {version} to the Mac is another story. You can use VPP and tell the appstore app to force install, or you can use a terminal command which should fetch the most recent version of macOS.

softwareupdate --fetch-full-installer

 

Or do what I do since I am a control freak. download Monterey, package it with composer as a .dmg. Deploy it as a policy (caching the dmg) and run a script like this to move it to applications. I took out all the Parameter and Variables so its easier to follow along. I run this in the background weeks before actually upgrading devices. If the installer is in place 1st upgrading is literally just a matter of running a script from a policy.

#!/usr/bin/env bash

## Mount DMG file with no browse to hide the desktop icon
echo "...Mounting /Volumes/Install_macOS_Monterey_12.1"
sudo hdiutil attach "/Library/Application Support/JAMF/Waiting Room/Install_macOS_Monterey_12.1.dmg" -nobrowse

## Install PKG
echo "Copying MacOS Installer to /Applications"
sudo cp -R "/Volumes/Install_macOS_Monterey_12.1/Applications/Install macOS Monterey.app" "/Applications/Install macOS Monterey.app"

## Wait 20 seconds to allow for package to transfer
sleep 20

## Unmount DMG
echo "Unmounting /Volumes/Install_macOS_Monterey_12.1"
sudo hdiutil unmount "/Volumes/Install_macOS_Monterey_12.1"

## Wait 20 sec to make sure DMG unmounts
sleep 20

## Delete DMG
sudo rm -rfv "/Volumes/Install_macOS_Monterey_12.1"

 

 

 


That's an interesting way to get the installer. I managed to package it up and deploy it directly into /Applications. Is there a reason you don't do it that way? The part I am hung up on is creating a policy that will actually kick off the installer for the standard user. If I log into an admin account with secure token enabled and supply the password, it works, but that isn't something I can do on student laptops. This is the most frustrating experience yet in all of my jamf/apple time. 

I have not tried this on AppleSilicon yet, I was thinking about that just a moment ago. I think MDM command is the only way to do it and JAMF has absolutely horrible support for MDM commands involving software updates.


I haven't attempted this on Intel yet. The M1s in my deployment are the smallest number and right now I've got almost every other device on some level of Catalina right now--that was a big win for us. So My first concern was now getting M1s up to Monterey while thinking that once I crack that code, the Intels will be easier. And Mass Action is just out the window. I can't send an action and have computers randomly starting to update in the middle of class or an exam or get interrupted because they woke up and packed their laptop up to get to school. 

 

 

That's an interesting way to get the installer. I managed to package it up and deploy it directly into /Applications. Is there a reason you don't do it that way? The part I am hung up on is creating a policy that will actually kick off the installer for the standard user. If I log into an admin account with secure token enabled and supply the password, it works, but that isn't something I can do on student laptops. This is the most frustrating experience yet in all of my jamf/apple time. 


Not sure if you're still having issues with this but here's an incredibly valuable thread with ongoing chatter. 

https://community.jamf.com/t5/jamf-pro/macos-installer-script-not-working-for-apple-silicon-m1-macbook/m-p/251358/page/2

@clarkep 

We had some great success with the below. Currently using it do a site wide Monterey upgrade in our Labs. With a mix of M1 & Intel Mac's.

https://github.com/grahampugh/erase-install.

Works a treat on Intel devices.

M1 devices require user password and need to be a volume owner. There is'nt away around this to my knowledge due to increase in security on M1 devices.

@clarkep 

We had some great success with the below. Currently using it do a site wide Monterey upgrade in our Labs. With a mix of M1 & Intel Mac's.

https://github.com/grahampugh/erase-install.

Works a treat on Intel devices.

M1 devices require user password and need to be a volume owner. There is'nt away around this to my knowledge due to increase in security on M1 devices.


I will second this method. I am. also combing it with Nudge-Swift so Nudge will alert users to upgrade their machines and then when they click the install button it opens the erase install policy from Self Service. Since quite a few of my users are standard users we'll probably make it just a standard policy to do the full install as an "update" with Nudge and erase install. 

Reply


Terms & ConditionsCookie settings