I'm tired trying to figure out how to run Mac OS Updates myself. Nothing works. What have you tried, so I can test it out myself?
I'm tired trying to figure out how to run Mac OS Updates myself. Nothing works. What have you tried, so I can test it out myself?
The most simple command to install all updates and force restart is:
sudo softwareupdate -i -a -R
You add it to scripts and just setup with a policy. Though this won't give a warning to users and just start the restart once it's done.
Mass Action:
https://docs.jamf.com/best-practice-workflows/jamf-pro/managing-macos-updates/Updating_macOS_Using_a_Mass_Action.html
Using Policy (Never really works):
https://docs.jamf.com/best-practice-workflows/jamf-pro/managing-macos-updates/Running_Software_Update_Using_a_Policy.html
Install or Defer (works fairly decent and has some extra options):
https://github.com/mpanighetti/install-or-defer
For upgrades (worked for a majority of people from Big Sur to Monterey):
https://github.com/kc9wwh/macOSUpgrade
Best is to cache the macOS pkg and then run this.
Have you tried erase-install.sh?
https://github.com/grahampugh/erase-install
I will give this a shot.
Thanks
@fimi I have not used it in Production, but in testing the MDM update command using the "Update OS version and built-in apps (macOS 10.11 or later, Supervised or enrolled via a PreStage enrollment)" selection with the "Specific version: 12.2" and "Download and install the update, and restart computers after installation" options was reliable for upgrading Big Sur machines to Monterey 12.2. Using the "Download and allow macOS to install later" option for that did NOT work.
On your M1 devices this have been working for Us on the Monterey Builds
/usr/sbin/softwareupdate -aiR --user $SecureTokenUser --stdinpass "$SecureTokenUserPassword "
Using this script has allowed a majority of my end-users to manually authorize the update from self-service. Works for both M1 and Intel based Macs.
Note: A Monterey installer is required on each machine prior to running this.
@fimi
I created this workflow, it works flawlessly everytime. Takes into account Intel/M1, standard users & allows you to pass administrator credentials via jamf parameters for standard accounts. In your case with standard users, do not use scripts ending in #2 & #3, you just need to use ending scripts #1 & #4. If you have a mixed environment, just include all of the scripts, even if they're standard it will fail & fallback to using the final script to run the install command as admin.
https://github.com/Rocketman-Tech/Upgrade-to-macOS-Monterey
I think some people in this thread are a little confused. What the OP is referring to is SEQUENTIAL OS updates, eg 12.2 to 12.2.1 NOT OS upgrades e.g. Big Sur to Monterey. Our org also uses install or defer and yes it is completely broken right now in Monterey for Intel machines (m1 still appears to be working) We have no new solution for updates are are extremely frustrated as well.
@PEBKAC If the machine/account has a securetoken & bootstrap token escrowed, the mdm deferral command via jamf allows incremental updates for macOS 12.0.1 & Up.
I think some people in this thread are a little confused. What the OP is referring to is SEQUENTIAL OS updates, eg 12.2 to 12.2.1 NOT OS upgrades e.g. Big Sur to Monterey. Our org also uses install or defer and yes it is completely broken right now in Monterey for Intel machines (m1 still appears to be working) We have no new solution for updates are are extremely frustrated as well.
@PEBKAC To be honest it's kind of both.
So far https://github.com/grahampugh/erase-install is working. For example to get 12.2.1 the command would be in the policy:
/Library/Management/erase-install/erase-install.sh --build=21D62 --update --reinstall --confirm --depnotify
Pros:
So far it's worked on every machine.
Ideal for Self Service for Standard users.
The only cons I find:
-It download the whole package (takes long). Though you can probably cache the download before hand.
-Users can still exit the update before it actually starts. A prompt is shown
-Really only ideal from Self Service. Meaning no check in policies. Otherwise after a reboot even with a recon policy on startup it may not work and still report an old OS version and try to run again. So those people that never update are still hard to do. Even if you force it on them they can technically cancel unless you remove it from the script. Then if you remove it from the script you might have a very upset employee where their computer rebooted mid meeting.