Self Service policy for Apple Software Updates

cwaldrip
Valued Contributor

In the olden days (Catalina and prior) we used the Software Update option to let users install any Apple software updates available (this doesn't include upgrades like 10.15 to 11.x, but just 10.15.x to 10.15.x+). But obviously this doesn't work now with Monterey (apparently).

I'm aware of configuration policies to force updates down onto machines, but we can't do that. We're a 24/7 organization with users in every time zone, and many do not have Silicon Valley quality internet (literally leasing lines from sheep herders in some countries or using mobile satellite terminals with bandwidth measure in KB not MB or GB). So we've trained the users to run the update regularly from our self service portal.

I've tried using the Files and Processes with... 

softwareupdate -iaR

...but that doesn't even seem to work for Monterey.

Any suggestions? Can't use a caching server, as sometimes these are the only users of ours in a location. Maybe a policy to cache the update and then install but they still need to be the ones to initiate it (when they have good/fast/reliable internet). 

1 ACCEPTED SOLUTION

dennisnardi
Contributor

That specific softwareupdate command doesn't work the same with ARM based Mac computers (or apparently Monterey, I guess, I'm not 100% sure on that). Apple depreciated the -iar part of the softwareupdate binary. As a result Jamf policies running that command no longer work, nor do policies with the software update payload either. Apple recommends using MDM commands. However that is extremely flaky, and you lack a real good way to schedule or notify users. It seems like something that in a few years might be good, but it's just not good or reliable currently. 

 

You really have 2 options. Option 1 is to use a 3rd party tool to help gain compliance. Nudge works great, is widely used, and is extremely well documented. Another option is utilizing SUPER which is also pretty well documented. Both essentially bug users to install updates themselves. Home users are the demographic Apple has primarily developed their product for, while the enterprise Mac environments are a languishing thought in the back of their heads often times. Thus modern versions of macOS/Mac hardware essentially require user interaction to complete, until MDM commands improve/are fixed. 

 

Option 2 is to download the full macOS Monterey 12.5.1 installer (which you can do with the link here), and then make a policy that just installs that over top of the OS. This is non-destructive, it will just take longer. There are multiple methods for that. I believe these two are the most popular ways to do so: 1 2. This generally also require some level of user interaction on modern macOS's/Mac hardware. If you can script an known user password on the machine you can fully automate it though. 

 

On top of all of that, in general there's been issues on Big Sur & Monterey with timely fetching software updates, even with the "keep my mac up to date" button checked. It's an issue with the softwareupdate binary again. Many people haven't seen the 12.5 or 12.5.1 updates available to them yet because of this. The general fix is to manually check for updates a few times, reboot, or run the "sudo launchctl kickstart -k system/com.apple.softwareupdated" command and then check for updates again.

View solution in original post

16 REPLIES 16

dennisnardi
Contributor

That specific softwareupdate command doesn't work the same with ARM based Mac computers (or apparently Monterey, I guess, I'm not 100% sure on that). Apple depreciated the -iar part of the softwareupdate binary. As a result Jamf policies running that command no longer work, nor do policies with the software update payload either. Apple recommends using MDM commands. However that is extremely flaky, and you lack a real good way to schedule or notify users. It seems like something that in a few years might be good, but it's just not good or reliable currently. 

 

You really have 2 options. Option 1 is to use a 3rd party tool to help gain compliance. Nudge works great, is widely used, and is extremely well documented. Another option is utilizing SUPER which is also pretty well documented. Both essentially bug users to install updates themselves. Home users are the demographic Apple has primarily developed their product for, while the enterprise Mac environments are a languishing thought in the back of their heads often times. Thus modern versions of macOS/Mac hardware essentially require user interaction to complete, until MDM commands improve/are fixed. 

 

Option 2 is to download the full macOS Monterey 12.5.1 installer (which you can do with the link here), and then make a policy that just installs that over top of the OS. This is non-destructive, it will just take longer. There are multiple methods for that. I believe these two are the most popular ways to do so: 1 2. This generally also require some level of user interaction on modern macOS's/Mac hardware. If you can script an known user password on the machine you can fully automate it though. 

 

On top of all of that, in general there's been issues on Big Sur & Monterey with timely fetching software updates, even with the "keep my mac up to date" button checked. It's an issue with the softwareupdate binary again. Many people haven't seen the 12.5 or 12.5.1 updates available to them yet because of this. The general fix is to manually check for updates a few times, reboot, or run the "sudo launchctl kickstart -k system/com.apple.softwareupdated" command and then check for updates again.

Thanks. What if the current user doesn’t have admin access though? Nudge and super (I’d heard of the first, but not the second) just prompt users - they’d still need admin rights I guess?

this is going to be a major pain point, I can feel it. It’s fine if users are admins and in a nice office with fast internet. But I’ve a lot of users who are none of those things. :-(

Admin isn't needed for software update, just being a volume owner. So they will be prompted for a password, but their will allow the process to continue. If you filevault and the user is enabled for filevault, then they should be an owner. Almost all users should be a volume owner. I would suggest giving those a try. 

This is not always true. Some updates require both filevault and an admin logged in.

Hi Dennis

Thanks for this answer. Although disappointing you've saved me a few more countless hours trying to figure out why things weren't working in Jamf and MacOS

Can I ask a follow up question on Nudge? Can it be configured to effectively force updates on? So perhaps given the users 3 deferrals (or whatever) but then categorically force them on? More importantly - does the feature actually work, because I'm sure there are comparable features in Jamf, but they just don't seem to work - hence my Nudge exists I guess

Thanks again

The only way to force updates are: if the machine is an Intel one using the softwareupdate -iaR command, using the same command but coding in a known username/password for ARM Macs, or by using MDM commands. However, MDM commands for updates are super flaky across the board, and are lacking in a lot of features currently, when they work, imo. So essentially the only way to automate updates on modern hardware is being able to input a known username/password (where the user is a volume owner) into a script to run the softwareupdate command. HOWEVER, and it's a big but, if you are experiencing the fairly common softwareupdate bug, where no updates are found or presented in sys prefs, this gets you nowhere. That is why, at least currently, I prefer Nudge. I get tickets in from a fair number of people saying "Nudge is telling me to update, but I don't have an update in my system preferences".

With Nudge, you can set a deadline and customize the behavior of the application after you hit the deadline (this is called going into "aggressive mode" with Nudge). In this aggressive mode, you can set Nudge to steal focus as much as you want, I've heard some places are doing as often as 30 seconds. This means Nudge is front and center every 30 seconds (or whatever you want) until the update is installed. So you can incredibly annoy end users until they cooperate. 

Thats helpful thanks

I'm trying to figure out what is going on in Apple's head with this stuff. It feels like I'm missing some clever element of their design philosophy but I keep coming back to this scenario:

A critical CVE gets discovered in the wild that is being actively exploited.

Apple releases a patch for the problem and creates signatures to detect exploitation in XProtect (or some other bit of built in security apparatus). Now, why would I want to ask permission from Betty in Accounts, Dave in marketing and so on and so on, for permission to protect the business from a critical risk....

I can't tell if its bad design, bad implementation or I'm just missing something

Thanks again for the quick reply

Jason33
Contributor III

I've just been using the Jamf Helper to bother users to update, and have been having success with that.  If they choose to update right then, one button opens System Preferences/Software Update.  If they choose to do so later, they can close the Helper window and will get notified the next day.  Its a good way to notify a user that their system needs an update and if they are unable to do so at the time of notification, typically they have been updating after hours or when time permits.

auser
New Contributor III

Can you advise what your using or how your are setting up Jamf helper? 

cwaldrip
Valued Contributor

Not needing to be admin does help at least. I’ll have to look into how to move forward but it’s promising at least. 

sh856531
New Contributor II

It is literally unfathomable to me that this is the way that critical security updates are managed in Mac land or that Apple attempts to sell itself as being suitable for enterprise environments.

I've been responsible for managing around 80 Mac devices for around 3 months and have been trying to figure out how on earth businesses running Mac comply with basic security standards such as ensuring critical updates are installed quickly or at least within 14 - 28 days. In our environment we have many devices that simply don't take updates despite Configuration Policies in Jamf saying that all updates must be applied

I'm really grateful to Dennis for such a comprehensive answer but am genuinely shocked that people can suggest MacOS as being a secure enterprise operating system given that you need the end users permission to keep your own devices safe.  

MCfreiz
New Contributor III

i just inherited a jamf pro server and about 100 macs. i cant beleive how updates are handled either. my secuirty team informed me about Monterey 12.5.1 and im still trying to figure out the best way to get it out to my clients. 

sh856531
New Contributor II

I'm expecting a similar level of absurdity trying to get the 20 - 30 or so business applications we use updated on a consistent and timely basis. If Apple genuinely doesn't care about providing a consistent way to get critical security updates to the OS, I'm expecting an even worse story for end user applications. The thing that really boggles my mind is that those OS updates are also the bits that exclude anti-malware signatures and so on in XProtect - meaning not only does Apple not care all that much about updating their OS - I also can't prove to an auditor that we would be running the latest AV signatures at all times.

It does make me wonder:
a. What the point of Jamf is if after spending $10sK on MDM we still can't update an OS
b. Whether Apple is deliberately trying to hobble MDM players for some reason


MCfreiz
New Contributor III

rcole
Contributor II

Thanks, for that share. Any luck? How are you doing updates now for Monterey/Silicon workstations?

MCfreiz
New Contributor III

i started using nudge with mostly the default settings and its been working out pretty well. since you need to modify a configuration profile to specify the minimum OS requirements, it also tells you which machines are not behaving properly even though they are checking in and running policies (the only fix for that has been to remove the jamf framework and reenroll but that's another topic).