I know there's quite a few different ways people have tackled macOS Updates. In the past I've general leaned into the "encourage" users camp vs trying to brute force them. I've done a number of methods all to varying degrees. This week our CSOC identified CVE's that needed patching by getting everyone to macOS 11.6.3 or 12.2. Instead of guiding users to update, I'm actively trying to force them at certain actions (login/logout is my goal). That being said, I checked with Jamf about best practices and was pointed to this article -> https://docs.jamf.com/technical-papers/jamf-pro/deploying-macos-upgrades/9.96/Running_Software_Updat... (we don't have any M1's so the article applies). I built my policy, applied it to some test boxes and, well, hit or miss. Specifically I'm running into this running software update locally:
Last login: Thu Feb 3 11:22:11 on console Ed@TestBox ~ % softwareupdate -la Software Update Tool Finding available software Software Update found the following new or updated software: * Label: macOS Big Sur 11.6.3-20G415 Title: macOS Big Sur 11.6.3, Version: 11.6.3, Size: 2552748K, Recommended: YES, Action: restart, Ed@TestBox ~ %
Which most definitely indicates that it requires a reboot to complete the install. However the Jamf policy doesn't see it that way (note the last 2 lines):
Executing Policy Software Update - Install All Available - Test Setting Software Update preferences to apple.com for all accounts... Installing all available Software Updates... Result of Software Update: Software Update Tool Finding available software Downloading macOS Big Sur 11.6.3 Downloaded: macOS Big Sur 11.6.3 Software update finished. Reboot is not required. Software update will not require a shutdown.
and as a result, the macOS update doesn't ever happen. I have a case open with Jamf Support, but wanted to reach out to the community to see if anyone else has encountered this and what your fix was.
So interestingly, that also seems to not be working for me either. When I run that as a logout policy, nothing seems to happen. When I use Jamf's workflow, at least some updates apply.
I do find myself having to run the
sudo launchctl kickstart -k system/com.apple.softwareupdated
command fairly frequently lately to get Software Updates to even show.
We too are trying to patch the same CVE and have had varied results with this policy. Some devices will recognise that 11.6.4 is available, only install the device support update and Safari update and then fail to install 11.6.4 until we flush the policy and they try again but for some still it never installs unless the user manually runs it from Software Update. We are looking at Nudge right now to try and force users there.
Also having even less success with the Mass Action option.
Executing Policy macOS Software Update Setting Software Update preferences to apple.com for all accounts... Installing all available Software Updates... Result of Software Update: Password: Software Update Tool Finding available software Downloading macOS Big Sur 11.6.4 Downloaded: macOS Big Sur 11.6.4 Software update finished. Reboot is not required. Software update will not require a shutdown.
Yep, I'm experiencing the exact same issue - have been for a while now. Ever since we upgraded to Big Sur the issue seems to have started.
I think I have tried just about every suggestion on these forums and the end result is all the same, - the updates download, but then the:
Software update finished. Reboot is not required. Software update will not require a shutdown.
message in the logs.
The absolute only way I have found to make the updates happen short of running it from the System Preferences pane, is to log on to the machine after your update policy has run and select 'Restart...' from the apple menu. It should be noted simply clicking the restart button on the login screen does not work. There may well be other settings that are required to be in place, but so far that long arduous, manual process is the only way to make them happen.
Seems a bit pointless having an MDM in that case!
Yep running into the same issue, i always assumed mu softwareupdate -i -a would do what it is documented as doing.
So in doing some testing, i noticed if a user is logged in the updates take, testing with the 12.5.1 (from 12.5 on Intel machines) updated today.
But same exact build (lab of 17) logs says it found the 12.5.1 but no reboot ever happens, and a simple restart at the log in screen does nothing like someone pointed out above)
Loggin in and doing a restart does not work for me but going into Software Updates in preference panes works, but then what is the point of having a MDM/macOS cream of the crop management suite? I mean Jamf is not cheap and if i have to do it with ARD... :/
I understand for a 1 to 1 setup w can give direction with Self Service, but for the 350 or so lab machines we need a real management suite not this hockey pockey expensive solution that we end up writing our own scripts 95% of the time cause nothing built in ever works.
2023. Still experiencing this.
|Setting Software Update preferences to apple.com for all accounts...|
|Installing all available Software Updates...|
|Result of Software Update: 2023-01-08 23:59:24.056 softwareupdate[80155:862615] XType: Using static font registry.|
Software Update Tool Finding available software Downloading macOS Ventura 13.1 Downloaded: macOS Ventura 13.1
|Software update finished. Reboot is not required.|
|Software update will not require a shutdown.|
We're having the same issue trying to force install the latest Ventura zero day patch 13.2.1. Even when adding a Restart Options payload with User Logged In Action set to "Restart if a package or update requires it", but the end result is still the same:
|Software update finished. Reboot is not required.|
|Software update will not require a shutdown.|
The policy completes but the Mac is still on 13.2.0
This is using the Software Updates payload to install software updates from "Apple's Software Update server."
We've also tried a different type of policy, using a Files & Processes payload with command sudo softwareupdate -ia. This also has the same result where a reboot is not forced. If the user shuts down or reboots on their own, it doesn't initiate the staged upgrade either.
I find it alarming that this has been a known issue for over a year and there is still no fix from Jamf for this? Sure we could email our Mac users and ask them to self install the update, but we won't have optimal compliance with that approach.
Have you tried forcing an MDM command to cause the update? After a conversation with Apple I started using the MDM command for all our workstations running Monterey and higher. It's been mostly successful. The only time it seems to not always work is when the workstation has not rebooted for a few weeks. Given the output of this will be uncontrolled reboots to apply the patch, I definitely go through our change approval process to get proper approval to force reboot mid-day. I've had more mixed results doing the first 2 options (download for the user to install/download and prompt to install after X deferrals).
Sure the MDM commands work, but there is no control over them. I need ot run this in the middle of the night when nobody is using the Lab/Classroom machines.
Wish Jamf/Apple gave us a way to schedule this. Maybe a maintenance window? Is that really that much of an ask?
The best luck we've had is erase-install from Graham https://github.com/grahampugh/erase-install. Though again we're mostly stuck with people not wanting to update. The script is not so great when pushed out because of the check-in that doesn't happen that the new version was installed. In the end we just force people even if they are mid meeting. They get enough warning to do it.
For our Windows users with Intune it's just set and forget with the update rings. Maybe the only thing I like from Intune.
It's always been a nightmare with Apple from an admin point of view.
So i have some nice "Nudge" style policy i created using Jamf Helper, its not as fancy as nudge but gets the job done fore end users when they are logged in. We pop it up give them an option to defer or do it right then and there. Had best luck with that.
We dont want to do an erase install just in place upgrades. And its different when a user is logged in vs a lab machine with no user.
The issue im having with both Jamf and Apple is the inconsistency in commands and answers i get depends on the tech im talking with. Apple is horribly my engineer gives me different answer a few weeks apart when the first answer didnt line up with what i found.
I have been using this command
sudo softwareupdate -iaR
to keep the OS up to date. I asked Appel and Jamf will this command upgrade a 12.6.2 or 12.6.3 machine to Ventura, at first both said no. I have a set of like 32 machines at 12.6.2 and 12.6.3 that are slowly upgrading to 13.2 or 13.2.1 i run that command every friday night, and over the past 3 weeks i have seen 26 out of 32 machines upgrade themselves, but i pushed this command out to about 300 and the rest are staying put.
Running the command manually in terminal is also hit or miss ive seen it upgrade and other times not upgrade.
Look at the screenshot do you see anything wrong with it? At first both apple and Jamf said that the command will not upgrade to Ventura. But as you can see it is. And the OS is 12.6.3 so either the bug is still not fixed or Apple has no clue what its commands do. But also i ran that same command on an identical machine, same hardware and OS (lab machines built identically) and the command doesn't upgrade to Ventura.
We also opened a Jamf support case to get some guidance on this topic & here's the suggestions that we'll be looking into:
The first is the use of Mass Actions to upgrade: https://docs.jamf.com/technical-papers/jamf-pro/deploying-macos-upgrades/10.34.0/macOS_Updates_and_U...
This method is recommended for computers with Apple silicon to install macOS updates without the need for a user with volume ownership privileges to authorize the updates using their password.
The second is the kickstart command. This is helpful when Mass Actions are stuck or taking their time. We are at the mercy of bandwidth and other Network considerations. In my own testing, a macOS upgrade can take some time to process and complete (in some cases overnight). This can be sent in a policy in the files and processes payload. The command is: launchctl kickstart -k system/com.apple.softwareupdated. As an example, Jamf internally added a button to our Self Service for any computer that was in need of a software update and didn’t see it as available or hadn't completed.
Thirdly, if you are looking to simply “just allow” users to download and install Ventura on their own, they could just run a Files & Processes command of:
softwareupdate --fetch-full-installer --full-installer-version 13.2.1 in a Policy.
Lastly, we recommend admins consider Nudge for managing the macOS upgrades: https://marketplace.jamf.com/details/nudge
As all those options are viable, they dont solve my issue of doing Labs/Classrooms. I cant do them in the middle of the day. Sure i can send it out at midnight, but no guarantees it will finish by morning.
But thats not my biggest issue here. It's how do i keep the macs up to date with other stuff that goes through software updates pane? if i cant use the sudo softwareupdate -iaR command becasue it upgrades me to Ventura.
That is what i am trying to solve.
In the same position with 3 labs of computers to try to wrangle. My best results - and most reliable outcomes - atm is S.U.P.E.R.M.A.N or
Pretty much tried everything else including Nudge approach and SUPER is the closest script 'solution'. It's a swiss army knife AND wack-a-mole approach to try to try and get Apple macOS updates to work. Astonishing and impressive amount of work by Kevin M. White.
It appears the current macOS updates are in a world of collective poo atm. Lets hope something positive comes out of all this update pain...
Kevin did my first Jamf kickstart LLLLOOOOONNNNGGG ago. He's very good at what he does. I'd come across the SUPERMAN stuff and was thinking it could solve my issues. I still keep thinking Apple will resolve their OS update mechanisms with every patch that comes out. But alas, here were are still with random update issues.
Not sure where folks are on this but I thought I'd share one thing that's helped my environment. Usually when CVEs are identified and a specific patch requires deployment, I've gotten a lot of traction from my user base just by educating them with a Jamf helper pop-up.
#!/bin/bash # Update Notification.sh # # # Created by Corfman, Ed on 11/22/22. # Edited to correct the date variable (line 11). # # Get Version of macOS date=$4 version=$(sw_vers -productVersion) getversion=$( if [[ $version == 13.* ]]; then echo "macOS Ventura" fi if [[ $version == 12.* ]]; then echo "macOS Monterey" fi if [[ $version == 11.* ]]; then echo "macOS Big Sur" fi if [[ $version == 10.* ]]; then echo "macOS Catalina" fi ) /Library/Application\ Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -lockHUD -title "Your Company Workstation Software Update Needed" -alignDescription justified -description "Your computer requires an update to the Operating System - $getversion. Please update your workstation at your earliest convenience to prevent an unplanned forced restart. Forced updates are scheduled to begin $4. Thank you for your prompt attention and cooperation in keeping Our Company workstations safe and functioning efficiently!" -icon "/Applications/Utilities/Path/To/icon.png" -button1 "I Understand" -timeout 900 -countdown exit 0
And I give the
as a specific date within my policy. After that they can expect to be rebooted whenever after that date.
Once that runs as a policy daily to any target not on latest macOS release they get a nice popup encouraging updates.