Updating to macOS 11.6 with Jamf Pro 10.32.x and MDM commands

[mark_buffington]

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!

[ubcoit]

Thanks, worked for me on a M1 MBP. Ran /usr/libexec/mdmclient AvailableOSUpdates manually in terminal then sent Download and Install Updates. Watched data received go from 2.5GB to 6GB and awhile later I was asked to terminate terminal, no other prompts or warnings. Not a great user experience to just push this out. I assume if it existed you would have posted it but I'll ask. Is there a way to simulate the Download and Install Updates client side, /usr/libexec/mdmclient Engage?

Do you know if macOS 11.6 was considered a minor or major macOS release?

I see new options for delaying updates now vis configuration profiles in 10.32.1 but it's not clear what a minor/major software update is. I believe it was clear before Big Sur but no so much now!

Thanks!

[mark_buffington]

Per the Apple documentation page linked above, macOS should present a notification.

After the update has been downloaded and prepared, a 60 second countdown begins.

I haven't seen that in my experience, which is why I mentioned testing on your own first. 😀

Regarding Major vs. Minor versioning and different deferral keys for different types, a Major update would be like any macOS 11.x version going to macOS 12. When a macOS 11.x device reports its available updates to an MDM server, it has a key of `IsMajor` with a "true" or "false" value.

Jamf Pro uses that data to allow administrators running macOS updates by MDM to choose when to opt-in to a Major update if only a patch or minor update like 11.6 is available.

[hb3b]

Thanks for sharing this, Mark. We're actually seeing an odd behavior with the built-in Software Update Policy payload where 11.x clients will download the 11.6 installer but not install it. It appears that calling softwareupdate with the -iar arguments does trigger a shutdown/reboot. Are there issues with how the policy's logic parses the output of softwareupdate -l for the 11.6 update?

Also, can you please confirm if a one-shot script like this is sufficient to cover all the edge cases you're aware of. Any issues with doing both MDM and "softwareupdate" and seeing which one arrives first?

#!/bin/bash

/usr/libexec/mdmclient AvailableOSUpdates

jss="https://jamf/JSSResource"
username=''
password=''
system_udid=$(system_profiler SPHardwareDataType | awk '/Hardware UUID/ { print $3 }')
system_id=$(curl --silent -u "$username:$password" "$jss/computers/udid/$system_udid" | awk -F "id>" '{print $2;exit;}' | tr -d '</' )
curl -X POST -u "$username:$password" "$jss/computercommands/command/ScheduleOSUpdate/action/install/id/$system_id"

softwareupdate -iaR

 Thanks!

[fredrik_virding]

Hi!

Have you tried if the script above works?

[hb3b]

Yes, it’s working very well for us.

[fredrik_virding]

Am i to understand the JSS is the url for our jamf cloud, and the user is an API user?

[hb3b]

Yes, an API user with the following permissions:

• Jamf Pro Server Objects: Computer [Create, Read]
• Jamf Pro Server Actions: Send Computer Remote Command to Download and Install macOS Update

[fredrik_virding]

Hi again,

I did see this on occasion in some testing, any clues?

Password: Software Update Tool Finding available software Downloading macOS Big Sur 11.6 Downloaded: macOS Big Sur 11.6 Failed to authenticate

[hb3b]

If this is a M1 machine, it would be indicate that "softwareupdate -iaR" or the like was run on it but the user "X"'d out of the password prompt. We had that happen here (as we rolled out a form of that script above to everyone - M1 and Intel on all recent OSes). The strange part is that even after they failed to authenticate, this one machine that showed that message couldn't be updated via MDM and we're not exactly sure why at this time.

[fredrik_virding]

Ah! I see! That does seem like one of those lovely M1 things.

As for the "install" MDM command, have you tried with installASAP?

[taugust_ric]

@mark_buffington thank you for this post, it was very informative.

What is the recommended procedure for software updates in macOS Big Sur for shared systems (computer labs, classrooms, clusters, etc), where updates are scheduled to be installed during maintenance windows "after hours" when systems are not in use.

It seems that in Big Sur, even on the Intel Macs, the softwareupdate -iar command no longer works as it did previously in macOS Catalina and earlier versions of the operating system.  Similar to what @hb3b states, if computers are not logged in, the softwareupdate command does not allow a restart to occur to complete the install of the updates.  I've attempted to work-around this by setting up policies that automatically login with an administrator account and then run the software updates while that account is logged in, but it's very un-reliable, and we have had instances where we have had "reboot loops" occur due to the restart flag (com.jamfsoftware.tasks.restart.plist) not being cleared at the end of the software update policy.

We really need a reliable method for installing updates on these types of systems in educational environments.  They make up about 1/3 of the systems managed by our Jamf Pro environment.  Any details or recommendations on how to get this working as it previously did would be greatly appreciated!

[hb3b]

One thing to note for folks using "softwareupdate" is that changing the "delay updates for X days" setting in a profile won't take effect on endpoints until they are restarted or this is run:

launchctl kickstart -k system/com.apple.softwareupdated

It's not required if you're deploying updates via MDM but it will definitely impact users who elect to update on their own.

[user-lOCkETbIwx]

New to JAMF and mac management. My main focus has been SCCM and Intune. How would I user the script above to patch our systems? Can I patch systems without any of this advanced functionality and just use our JAMF cloud instance? No disrespect to anyone, but so far, patching PCs with Intune is a lot more intuitive.

[AJPinto]

I think you could fix your statement. Patching PC's is a lot more intuitive, Intune really has nothing to do with it. Patching on macOS has always been garbage compared to what you can do with Windows. You also jumped in at a time when Apple is doing out with the old and in with the new where it concerns OS patching. 

My advice, give up on scripting this. Its not how Apple wants it done, and even if it works now it will not work for long. Apple has been very clear they want to you to use Management Commands from your MDM for patching. JAMF is really dragging their feet at supporting the new (not new but 9 year old) software update management commands. May want to get with your JAMF CA and raise hell about OS patch management, as it is horrible right now and really has always been horrible.

[user-lOCkETbIwx]

Like I said, no disrespect. I was just merely highlighting the fact that patching PCs right now with Intune is more intuitive than with JAMF and that was not what I was expecting.  

[AJPinto]

None taken. You have a point, and I welcome you to the root tops with us to yell it until some billionaire listens. We need more people submitting feedback to both Apple and JAMF that this is unacceptable and there is no excuse for being this backwards and behind in 2021. Microsoft figured this out 20 years ago. Yes Intune and SCCM are 1st party for Microsoft, but JAMF says they are the leading MDM offering for macOS and its time they stop saying it and act like it. JAMF does many things great, OS updates is not one of them.

[bbarciz]

I'm in a similar situation as you.  I'm primarily a windows management guy, SCCM mostly, and their windows patching is super great.  I feel like doing the same thing in Jamf is much more difficult.  Care to share what you are doing currently on the Macs for OS patching?

[jpeters21]

ok so mass action and the individual download updates  are the M1 supported methods (anyone who thinks that a good solution does not know what enterprise management means) ..How can you manage updates with out being able to schedule them?  I have reached out to jamf and there always seem to be a reason or excuse (last one was 11.6 was a hot mess), but I have not once successfully forced an update from the console.  that is via Mass Command Policy, or other. I am assuming this is why some people are using a software update command. This problem exists on intel based macs for me as I have only started purchasing apple silicone based devices. 

[user-lOCkETbIwx]

I really don't know why this is such a huge problem. Why is this so hard? What is everyone else doing?

[jpeters21]

my assumption is letting their Mac environment be the wild west, or a whole lot of manual interaction. Manual interaction and ARD commands was our solution until I talked my organization into jamf, but this right here is a big part of what I sold the organization on, and its not working properly.

[tjosey]

After 10.15 Catalina we patched via policy which was great but now with Big sur its **bleep** near impossible to push updates and needs user intervention. Jamf keeps referring me to mass action updates but coming from an end user perspective it would be a horrible experience since we can't even set a schedule for mass action updates to take place and there is no reporting on it either. Jamf Please assist as you guys are suppose to be the leaders on this an offer same day support

[fredrik_virding]

@mark_buffington 

This has been a great thing for us so far! Have you had any experience using this to install the Monterey upgrade?

[mark_buffington]

@fredrik_virding - Using the MDM commands for the "Download & Update" workflow uses an `InstallASAP` action, and can work fine. If a standard user account is logged in, it's best to be on macOS 11.5 or greater though (or log them out first,) as there were update issues resolved in that release for full macOS installers.

It's not the best end user experience though, as the installer will download, notify the user that an update has been requested, then start preparing in the background for about 30 minutes. Once finished, the computer will go down for a restart and install, but thankfully that part only takes 4 minutes before being back at the login screen.

[fredrik_virding]

Hi @mark_buffington 

Thats pretty much what i tried above. And it doesnt really move the Mac from 11.6.1 to Monterey. Now with the Jamf update to select a specific version, it maybe can work via Mass Action?

[szultzie]

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.

[jpeters21]

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

[clarkep]

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....? 

[jpeters21]

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". 

[AJPinto]

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"

[bbarciz]

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.

[AJPinto]

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.

[clarkep]

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. 

[clarkep]

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. 

[kavila]

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-macbo...

[tdenton]

@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.

[ckruter]

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.