Requesting a Process for Apple Software Updates via Policy for Big Sur Security Updates

Not an easy one to do.

The software updates command wont work.

Had this through from a JAMF engineer...

"The important thing to understand here is that if you want to be able to send OS updates to macOS 11(Big Sur) machines without user-interaction the machine MUST be Supervised.

https://support.apple.com/en-gb/guide/deployment-reference-macos/ior7ba06c270/web

You also need to ensure you have escrowed a Bootstrap token from machines.

https://support.apple.com/en-gb/guide/deployment-reference-macos/apdff2cf769b/web

Once your devices are enabled for Supervision and a Bootstrap token escrowed, you will be able to deploy updates to the machine silently without user-interaction. Apple is moving away from scripting updates on users’ machines in favour of MDM-command-based upgrades."

However, so far in my testing, the timing of when the update gets installed is very hit and miss. I use the Mass action command to send a download and install updates to them. Be warned if you do this your network supervisor might just have a fit. I did it to 150 Macs, that needed the 11.5 update, it maxed out our link for several hours.

Martin here from Jamf Support, just following-up from our conversation earlier. I am going to test this recommendation from Jamf, however, you can't schedule it. It pushes the macOS out immediately or the next time the device checks in. 

To summarize our conversation, we are looking to update Macs to the latest Big Sur security update from Jamf Pro.

During our phone conversation, we determined that we can use the "Mass Action" feature in Jamf Pro to send a remote command to Macs to update to the latest version.

Here is our documentation on that process as well.

 > https://docs.jamf.com/best-practice-workflows/jamf-pro/managing-macos-updates/Introduction.html

Please let us know if any issues arise during that process so we can help troubleshoot them and find a solution.

For now, we will create a case and keep it open until we hear back from you. Please feel free to reply back to this email if we have any additional questions or issues along the way.

Thank you and hope you're having a great day!

Case Number: JAMF-3066146

Very Respectfully,

Martin C.

Updates is not a place Apple really has any significant interest in developing tools for unfortunately. Apple seems perfectly content telling people to let their users handle updates. This is an area of with massive opportunity for improvement for both Apple and JAMF. Apple does not really care, and JAMF has avoided building anything for macOS updates up to this point. Hopes are not high it will get better and it’s a pain for all of us :(. 

Honestly, I would suggest giving up on researching the softwareupdate command and look into software updates by Mobile Commands. Mobile Commands are the direction Apple is going with Software Updates for better or worse. The Mobile Command to run software updates is very barebones in Big Sur, most of the management options for this will be on Monterey. Apple Silicon and Big Sur is really SOL for any real enforceable options to make sure devices and users update aside of zero trust.

I currently use the softwareupdate -aiR command in a script that drops a log when ran since JAMF cannot report on the softwareupdate policy as it reboot the computer before the policy finishes so no logging. Over the next few weeks I am going to be researching moving things over to the software update mobile command, but it wont be fully fleshed out until Monterey.

softwareupdate -aiR on Apple Silicon requires user interaction, the only unattended way to run updates on Apple Silicon is via Mobile Command.

pain in the @rs3 for sure. here is the approach we've been trying, by no means is this a fool proof or sophisticate approach.

Option 1 – monthly patches, we run a MDM command on all Macs that do not have the latest version roughly once a month, this will (in a perfect Apple world) download and install the latest point updates and security updates and restart the device as needed. Sometimes the user sees a system prompt, but this is a mass action based off of a Smart Group and Advanced Search

Option 2 – this is mainly for devices that miss the patches or the updates don't for whatever reason get to them and its a bit of on longer process, you'll understand why..

basically, I use grahamrpugh's eraseinstall workflow to get the latest macOS Big Sur Installer, run an update (not erase!) on top of the existing OS and usually that does the trick for us. a bit radical because you are essentiallyin installing an entire operating system ontop of itself...but we haven't seen too many issues with the few devices that do fall into that scope. and whats nice is if you deploy DEPNotify it has a nicer user notification experience.

however for Apple silicon, a user prompt is required, but like others said MDM commands have been the way to go.

Could you please provide me what command are you using on option 1? Thanks

Thank you for replying to my issue and giving me information that really help with me coming up with this months work around for Jamf and Apple Security updates. Which every month Jamf comes up with a new one but never resolves the issue. My inventory is Intel based iMacs and they are acting like Apple Silicon M1 updates requiring a user to be logged on to Restart to install the update. 

This is my workaround for this month for Apple Security Updates: 

• Jamf Pro create a Policy with just this Payload:
  • Files and Processes
  • Execute Command
  • /usr/sbin/softwareupdate -i -a -R
  • I scope it to my iMacs a group at a time and then the next morning I log in with any users credentials and hit Restart. 

Again, ridiculous that I have such a manual process, but glad I have some kind of a process to install these Apple Security updates. 

Thank you for replying to my issue and giving me information that really help with me coming up with this months work around for Jamf and Apple Security updates. Which every month Jamf comes up with a new one but never resolves the issue. My inventory is Intel based iMacs and they are acting like Apple Silicon M1 updates requiring a user to be logged on to Restart to install the update. 

This is my workaround for this month for Apple Security Updates: 

• Jamf Pro create a Policy with just this Payload:
  • Files and Processes
  • Execute Command
  • /usr/sbin/softwareupdate -i -a -R
  • I scope it to my iMacs a group at a time and then the next morning I log in with any users credentials and hit Restart. 

Again, ridiculous that I have such a manual process, but glad I have some kind of a process to install these Apple Security updates. 

Unfortunately I cannot stress enough how poorly Apple has designed the software update function in macOS and how insistent JAMF is at avoiding doing anything with it.

Softwareupdate uses a Bootstrap Token to approve the updates to be installed and reboot the device (if you use -R and if needed). Starting with M1 (Apple Silicon) Apple no longer allows the use of a Bootstrap Token to install updates, Apple requires the use of a Secure Token. A Secure Token comes from a user, so if you run Softwareupdate -aiR on an Apple Silicon Mac the user will get a popup to enter credentials to provide that Secure Token to install updates. If they input bad credentials or cancel the box updates wont install. This is a departure from the behavior on Intel Macs where updates just install. 

Apple is Moving to Management Commands to hand software updates, this requires management/supervision and DEP if I am not mistaken of the device and you see the option within the management tab on the inventory record if the Mac has available updates. You can do mass updates off of computer groups and this works for Apple Silicon and Intel Macs.

Its not all rosy though. Apple has that management command barely fleshed out. Extremely limited user notification, no deferral (until Monterey), absolutely no reporting or logging in JAMF as its a management command. Basically you have no idea if the updates seceded or failed. When you tell them to run the Mac will run them when it gets the command and it reboots without warning the user when ready. If a Mac is turned of it will get the command when it comes online even if that is days later. Basically Apple killed a poorly designed but working method with Softwareupdate with an incomplete product that is the Management Command.

In sort look in to running software updates from the management command for minimal interaction, and do some research on managing that management command on Monterey. I would provide more information on this but I am still figuring the Monterey stuff out myself.

Where the softwareupdate management command is located in the inventory record.

Where the softwareupdate management command is located in a search or group action.

Thank you for this. I am having the same issue as the OP. I cannot dependably push out OS updates via mass action. It either results in seemingly doing nothing or, at some random time, perhaps days later, a user's machine will reboot and the update gets installed. There has to be a reliable and consistent way to update the OS, right?

I got it to work once on an Intel iMac using the following Jamf Pro Policy, which means it downloaded the Apple Software Security update and did a Reboot to install. Then I tried it on two other Intel machines and it just downloaded, still waiting on a user to sign in and hit Restart, which is unacceptable in an enterprise environment. 

Thanks. As a new Jamf user, I am constantly surprised about certain things. This is a remote management tool, correct? So why is it designed for users to interact in any way? Most enterprise environments cannot and should not entrust the updating and patching of their machines to the users. That is just crazy. I need a way to push the command and have it happen at that moment (eg after hours).

Apple just released another Apple Software Update 11.5.2 and I am still having the exact same results on Intel based computers. It will download, but will not Restart unless I log in as a user and hit restart:

what are your logs saying? Personally I prefer to run softwareupdate as a script, even using files and processes I would probably put sudo in there. 

Its not so much JAMFs fault as it is Apples. JAMF really needs to be much faster to adopt new macOS Management features (or heck adopt managing macOS updates period) but JAMF is not responsible for Apples poor engagement and documentation practices. In Apples core philosophy the user should be in control. Apple does not view the company that purchases the device as their customers, Apple views the users of the device as their customers. Most everything Apple does is to empower, inform, and give their customer control. Do I agree with this, no. However, once you understand this concept, a lot more of what Apple does makes sense.  

The unfortunate situation we are in right now with OS updates. Apple has intentionally broken the old workflow for software updates by requiring the softwareupdate command to need a secure token (user interaction). However, Apple did this before fully fleshing out the replacement ScheduleOSUpdateScan workflow which was introduced several years ago in 10.11 (not 11.0). The entire workflow of ScheduleOSUpdateScan lacks any ability to give any user notification, or deferral options (i.e. do you want to install updates tonight or differ until tomorrow, you can differ 3 more times). Not that the softwareupdate command could differ updates itself, but you could setup the script to do that with other functions. So, we are waiting on Apple to release MacOS Monterey to get our hands on the final changes to the InstallLater policy with the ScheduleOSUpdateScan workflow and with that the enforcement of the MacUserDiferrals. Lord only knows when JAMF will add support for any of this, but I am figuring mid 2022 if we are lucky.

Also, in typical apple fashion these new features to ScheduleOSUpdateScan will all only come to macOS Monterey, so Big Sur devices on Apple Silicon will always be a weak spot in OS Update management. Apple should have gotten the ScheduleOSUpdateScan finished long before breaking the softwareupdate command workflow, but welcome to Managing Apple Products I suppose. Don’t even get me started on logging for ScheduleOSUpdateScan or any management command action really.

This may be a good watch. It is from WWDC2021 and is basically the run-down of where apple is taking macOS in regard to managing OS updates. Personally, I recommend if you don’t have a good work flow for the softwareupdate command for your Intel Macs give up working on one and put your effort in to the schedule an OS management command (ScheduleOSUpdateScan workflow). The management command should work in one way or another on All macs running 10.11 or newer, where the softwareupdate command will not work on any Apple Silicon devices.

https://developer.apple.com/videos/play/wwdc2021/10129/

Please always test, but running this as a Script appears to be the answer for Intel Based Macs: 

/usr/sbin/softwareupdate --install --all --include-config-data --restart --force

Logs are saying it ran as normal. That's what is so frustrating. 

We're new to Jamf and Mac management, but why does the Jamf "Patch Management" not get brought up as an option in regards to doing the OS updates?  We've been using patch management for any software updates that we can and its been working, so today I found that they also have options for OS installs and updates, but no one seems to ever mention this when talking about this topic.  What am I missing?

“JAMF has directly avoided ever formally adding any support for managing macOS updates” I suppose is the best answer to your question. Its not what patch management was intended for. The macOS patch management items are really just for tracking and reporting from what I can tell

Apple no longer provides macOS deltas that you can download package for JAMF to deploy, this was stopped with Catalina. So, you cannot deploy macOS updates from JAMF with Big Sur and any new OS’s going forward with a package. JAMF Patch management also has very little in the way of deferral and notification options which most companies require.

Apple has moved to using management commands for OS updates. You must deploy updates with management commands either device by device or by using smart groups/inventory searches and mass actions which patch management cannot do.

Thanks @AJPinto for this explanation.  It's a shame because I've found the patch management to be very useful in managing all the individual app updates.  We have set the configuration profile settings for the software updates, but have found it to be very unreliable as it feels as if the user still has to make the decision to install the update.

I'm going to look more into the update management commands.

Ya, most everything right now with software updates is unreliable. MacOS has never been particularly reliable to patch, but with scripting you could make something work. Now that it is all moving to management commands that takes a lot of control out of the engineers hands. 

How it should work. The MDM server regular tells the mac to scan for updates and report findings. When the engineer is ready the engineer tells the mac to update with a schedule OS updates management command. JAMF with 10.29 adopted the InstallASAP key to that install updates, but not the force key. So if anything prevents the mac from rebooting like an active terminal window, poof updates do nothing. Where apple is no saint here, most of my current problems are with how JAMF is handling the management commands. Apple has the keys to make it work, JAMF is just not using them. JAMF also really needs to build a payload for Management Commands in to Policies, so we can force this stuff.

I am really looking forward Jamf supporting the MDM command InstallLater to enforce macOS Updates, this is a very important MDM command for Jamf Admins, I think.

I totally agree, however JAMF has taken way to long to do anything involving these OS update MDM commands so my hopes are not high we will see this anytime soon.

Granted many of the new OS management options come with Monterey, but JAMF still does not support most of the Big Sur MDM commands for OS updates. I do place a lot of blame on Apple here, they should have never retired softwareupdate without making sure the MDM commands had all the functionality which they flat out do not. We have had to make due for a year while Apple figures out what they are doing, then the delay it takes JAMF to implement the new management. The same goes with EFI passwords, Apple removed them with Apple Silicon and did not put a way to restrict access to recovery until 11.5 and JAMF still does not support that. Apple Silicon has been an absolute mess of a deployment by apple, and a mess in adopting its management by JAMF. I suppose in short even at this point Apple Silicon is an incomplete product and we are paying apple to be their beta testers.

There is light at the end of the tunnel, I am just hoping its not a train (that is stopped on the tracks and never arrives).

https://community.jamf.com/t5/jamf-pro/managed-software-updates-using-deferrals-via-a-mass-action/td-p/249821?emcs_t=S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufEtWNzRHODdVOEZXWEdQfDI0OTgyN3xTVUJTQ1JJUFRJT05TfGhL

Thanks for the link, I posted a comment there.

If you don't want to prompt the user at all, you can make a bash or python script that runs the Download and Install Updates management command for you. Add the script to a user interaction policy  to give the user the option to defer the update. 

Regarding the script, will M1 users still have to type in their password to run the updates? I see in the script that after the 4th day, it says it'll download in 4hours. Is it possible to add a specific time, so the update will run at night?