While this is, arguably, a feature that Jamf should be able to handle at its core, what is the best method in 2021, across the gamut of supported OS's and architectures, to enforce Apple software updates?
I understand that theres resistance to using any terminal commands for software updates. As stated in the Nudge channel, Since 2018 this has been a problem since Apple doesn't test softwareupdate commands that are triggered by a script. In addition to that, this requires a password if the computer is Apple Silicon.
I recently rolled out the UEX-Tool-For-Jamf, and two of the components in it are no longer developed and throw gatekeeper issues in Big Sur.
I would like to use Nudge, but, my confidence in my users is low enough to not expect Nudge to work fine on its own. Nudge cannot force the update to happen.
What is the best way to handle software updates? Is there MDM magic I am missing? What is the downside to having the checkbox "keep my mac up to date" checked via a config profile?
I'm definitely following this thread with interest. The biggest downside to just checking "Keep my Mac up to date" are things like last year's updates that started bricking systems and then were pulled and re-released by Apple. Their Quality Control has fallen to a level that I cannot trust automatic updates.
Getting popcorn and note pad ready.....
@tomt question - what happens if you keep that checkbox but also have the deferral set by the MDM?
@sdamiano Not entirely sure. I know what is SUPPOSED to happen (machine ignores updates for x number of days), but couldn't say with any certainty how it works in the real world.
It's really not ideal but I'm using a combination of an MDM deferral period and a daily prompt for Macs with the criteria "Number of available updates is not 0". We scan for updates weekly so the deferral period begins at that point (e.g. the client knows the update exists and will install it on the next scheduled scan, once the deferral period expires).
The prompt, once acknowledged, directs users to Software Update.app so they can install from there. It's pretty effective and future proofs us for Big Sur when user authentication is required to install updates and a background scan/install is no longer effective.
Our reason for deferring updates across the board was the Mojave patch last year that took down ~150 Mojave Macs.
Jamf's suggestion for a "more modern approach" was to install updates via an MDM command but this is not workable as it can't be done using a policy. What a mess!
@jtrant Are your users admins or do you make allowances for non-admins to use Software Update?
Pulling up a chair for this one and grabbing some of that popcorn...
We've got the Config Profile in place that postpones updates x number of days just to give us a little breathing room in case Apple does release a problematic update. After that though, all the "Automatically apply updates" boxes are checked but it's still pretty much up to the user to respond to the update prompts. If a user doesn't want to take the time to update their system, our options seem to be pretty limited. One option is the nagging route of popups via policy until they apply the updates. Another option is to use the MDM command to force the update (similar to pushing those updates on iOS devices) immediately with no warning to the user. Doesn't seem ideal to say the least. I'm not really considering scripting options since it sounds like that won't work in an Apple Silicon world.
I'd love to see any other suggestions that balance keeping the user informed of what's happening (and perhaps even giving them deferral options) while at the same time providing a near iron-clad assurance to us that machines WILL get updated.
It seems far too many eggs are being put in the Conditional Access Basket by Apple and Jamf. Making it rely heavily on the user to ensure compliance is... not an easily palatable method for many organizations. I get that Apple prefers the "have the user do it" method of doing things, however, users are going to user, and granting users admin rights so that they can manually accomplish that which we as engineers were previously able to automate is simply not going to fly.
Totally agree, and the "update them via MDM commands" line doesn't work if you can't craft a policy around it.
Just curious - what are people's thoughts on applying updates automatically, but delaying the reboot on the user? We're working through a small POC for this due to all other options being hit or miss. Thinking basically just do the equivalent of "softwareupdate -ia" in the background, then once completed, use JamfHelper to pop up a window (which cannot be closed by the user) with something like a 48-72 hour countdown timer. Users can reboot on their own up until the timer expires, at which point the policy will reboot them. Thoughts?
This is what we do @tarmstrong but you'll need to use the "Software Update" policy payload as the 'softwareupdate' binary cannot install updates in the background on Big Sur.
Our policy:
Scans and installs updates
If their available SWU count is > 0 they get a jamfHelper notification
Once they click 'OK' we direct them to Self Service to install
Pretty effective, although far from ideal.
Thanks for that, @jtrant .
We currently have a practice that "works" but is overly complicated and I'm trying to simplify.
Right now we use a two-pronged approach:
1) If available SWU count is > 0 they get a jamfHelper notification stating that they have a week to apply the update. JamfHelper gives a cancel button, or a button that takes them to Sys. Prefs to apply the update. This also has a payload for #3, below.
2) They also get a daily reminder/nag notification that there are updates available.
3) After 6 days, they get a JamfHelper notification, which they cannot close that has a 24 hour countdown timer. Only button is "apply and restart". They can press it, or it will happen automatically at the end of the countdown.
We're adopting a standard approach for any other items that need reboots (firmware pw. changes, anything else that comes up) and wondering about just using the same notification for "hey, you have updates that need a reboot". Simpler, and more consistent with our other practices, but...
I'm looking to simplify my process. The way my org wants updates deployed, I have set up 3 different config profiles with different deferment dates (o days, 7 days, 30 days) and 3 policies to apply updates. I have each policy set to notify the user the the policy is going to run and install any updates, and they can defer for up to 3 days. I'm not sure if that is the "best" approach, but its what I came up with given the requirements.
@Jason33 Once they hit the 3 day limit and are forced to install, how do you do that? I'm assuming something with the softwareupdate script command which doesn't seem like it will be an option going forward with M1s because of the requirement for the user to authenticate. Overall though, totally agree--that structure seems like the best path given the available options/requirements!
@tzeilstra At the end of the deferral period the policy runs. We're not yet deploying Big Sur or M1's, so I will tackle that obstacle when we get there.
If they get to the point in the future where someone has to authenticate to do updates how is anyone supposed to update hundreds or thousands of student computers? That needs to be a fully automated process we can't possibly go round them individually.
Apple should allowed us to set an interval on which updates are forced installed, like it does now with delaying updates.
For now a schedule which sends the command would really be helpful and solved this issue. Like it it currently done with Wallpapers on iOS. This would really help us.
I know Nudge was mentioned, but here's the link for those curious what it does: https://github.com/macadmins/nudge
A granular MDM workflow to replace the softwareupdate binary going bye bye is much needed.
.....Watching also.
Does anyone know why the "Defer Updates..." MDM settings are located in a "Restriction" payload and not in the "Software Update" payload? Took me 30 minutes to find the setting - Grrr...
man.. I wish JAMF can figure this out.. We can't seem to update our Big Sur machines... via jamf policy/scripts....
@aaelic24 My understanding is that this is more of an Apple issue than Jamf.
https://babodee.wordpress.com/2021/03/30/handling-major-upgrades-and-minor-updates-for-macos-with-jamf/
This is absolutely worth a careful read.
Much like @T.Armstrong and @tzeilstra We have a deferral option available for up to 3 days.
After the 30 day delay we enforce via config - the policy sees that updates are available and runs the script referenced below.
It allows the user to do it at their convenience during the day.
Trust me, the last thing you want is to interrupt a Doctor in the middle of a presentation because of a software update
Note - not tested - not expected to work on Big Sur. My fleet is Catalina for now.
I use a variation of install or defer
The end-user can defer updates up to 3 days before it's forced through the command line. The policy runs once a day on systems
