Enforcing Apple software updates in the year 2021.

[sdamiano]

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?

[tomt]

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.

[bainter]

Getting popcorn and note pad ready.....

[sdamiano]

@tomt question - what happens if you keep that checkbox but also have the deferral set by the MDM?

[tomt]

@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.

[jtrant]

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!

[tomt]

@jtrant Are your users admins or do you make allowances for non-admins to use Software Update?

[tzeilstra]

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.

[dgreening]

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.

[jtrant]

Totally agree, and the "update them via MDM commands" line doesn't work if you can't craft a policy around it.

[T_Armstrong]

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?

[jtrant]

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.

[T_Armstrong]

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...

[harsha]

Hi T_Armstrong,

May I know how to alert users 2 or 3 times to install the new updates in jamf pro.

what are the settings to be done in jamf pro.

[Jason33]

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.

[harsha]

Hi Jason33,

Can I see the settings how to get notification for the updates in jamf pro?

[tzeilstra]

@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!

[Jason33]

@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.

[ianatkinson]

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.

[martin]

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.

[jphillips]

I know Nudge was mentioned, but here's the link for those curious what it does: https://github.com/macadmins/nudge

[isThisThing0n]

A granular MDM workflow to replace the softwareupdate binary going bye bye is much needed.

.....Watching also.

[dstranathan]

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...

[JamfMyMac]

man.. I wish JAMF can figure this out.. We can't seem to update our Big Sur machines... via jamf policy/scripts....

[jhuls]

@aaelic24 My understanding is that this is more of an Apple issue than Jamf.

[tzeilstra]

https://babodee.wordpress.com/2021/03/30/handling-major-upgrades-and-minor-updates-for-macos-with-jamf/

This is absolutely worth a careful read.

[k3vmo]

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

[bpavlov]

My contribution to handling software updates: https://babodee.wordpress.com/2021/03/30/handling-major-upgrades-and-minor-updates-for-macos-with-ja...

[bmack99]

This process has worked great for us for a few months now. We are utilizing it for minor macOS updates, in an environment with macOS 10.15, 11, and 12 devices(mix of intel and arm). Out of the blue with this latest macOS 12.3.1 update that addresses a couple of zero day vulnerabilities the script is exiting with an exit code of 0 showing no new updates available, even though system preferences > software update > shows the 12.3.1 update. :( Curious if anyone else utilizing this solution is seeing the same?

[Geissbuhler]

I am seeing the exact same behavior, and thought I was nuts because it was my first time trying this script.

My higher ups are having us switch to a different MDM specifically because this issue is so bad. We are Mostly M1 hardware at this point. We need an automated/scheduled way to do this. We had many eyes on the macOS M1 update test project and higher ups testing with me, so far it has not gone well. Super sporadic results. Sometimes commands showed on devices, sometimes not. This script looked nice, but so far not good results.

As much as I love Jamf, the tests for OS Version handling in the new MDM have been absolutely flawless for M1 and intel so far, so I really can't argue with their decision, (People from multiple teams were shocked saying, isn't this what Jamf does, isn't macOS Updates basically the core of what they do? I had no useful rebuttal.) Jamf has been an amazing company and I hope a "built-in option" for scheduling and macOS version control arrives quickly for all. I love this great community and sure I will still ref this often.

Feel free to DM if you have any questions

[ianatkinson]

We're at capital bid time at my University and since we didn't really buy anything last year due to COVID we need a fairly large pile of iMacs this year. I've suggested we get the new M1 ones because there doesn't seem any point getting hundreds of end of line Intel ones and I expect they'll be gone from the lineup soon anyway so it's only delaying the inevitable. This means we will have some Big Sur only machines.

If I get all the student computers updated to Big Sur to match across campus (which we generally do for consistency) that means I'm looking at having a mixed Intel/M1 Big Sur fleet next year to keep up to date so all these issues are going to come to the fore in quite a nasty way.

The way I see it at the moment:

• the JAMF software update payload doesn't work on Big Sur because it can't properly detect when reboots/shut downs are required by the softwareupdate binary (support have told me this is an Apple issue)

• sending an MDM command to do updates doesn't work reliably either at least in the limited testing I've done, again the reboot doesn't seem to be performed where required

• M1 macs apparently need a password when being updated? Since we don't own any yet I don't have experience with this. I read in the JAMF release notes that this can be bypassed if using the MDM command

• updating via MDM to me is pretty useless. Since we're closed on a Sunday I have all our student stuff updating throughout Sundays and this kind of scheduling isn't available via MDM. I'm not going to sit at home on a Sunday every week sending MDM commands to hundreds of computers and hoping they work. Staff updates are complex since they can't interrupt their work so they are done with various policies some of which they can defer, again that all relies on proper policies not pushed commands.

• configuration profiles which turn on the settings to keep the mac up to date automatically don't seem to work reliably at all, I had to abandon those

• you can't simply do background installs and then force a restart at certain times because touch bar macbooks sometimes need properly turning off not rebooting to avoid issues

If Apple are working towards a scenario where updates can only be handled individually by users that in no way fits with a large educational setting and I'm not seeing a sensible way around this at the moment. Neither our staff or students are admins on machines so this has to be centrally managed.

I also don't think everyone should need to cobble together their own scripts and hacky bits of code to make such a fundamental thing work either - the core payload in JAMF to do updates should be simple to implement and needs to work reliably such that it can either just be run at some appropriate time (e.g. students) or run with a deferral if it needs a reboot (for staff). Everyone is trying to achieve the same thing with updates really and it's very important so I don't know why it's gotten so difficult.

[tzeilstra]

Looks like Apple is adding to our fun...

The Apple Support tech I've talked to has confirmed that there does seem to be a bug in macOS Mojave and Catalina with regards to some software updates - most recently the Safari 14.1 and Safari 14.1.1 updates. These updates will show as available if you run the "softwareupdate -l" command from Terminal and in the Jamf Inventory record. As a result, these machines will also show up in any Smart Groups that look for machines with Available SWUs greater than 0. If there is a deferral policy in place though via a Configuration Profile, the user can't actually see or install these updates by going to System Preferences - Software Update. They're just told that there are no updates available. This means that if you use a Config Profile to postpone updates AND if you have a policy that's scoped to machines with available software updates, that policy will be run on machines where users can't actually install the updates via Sys Prefs meaning they're just stuck in that group until the deferral period in the Config Profile expires. For those of us that use a jamfHelper prompt asking users to install those pending Apple updates, users are being pestered to install updates they can't see.

Can anyone else confirm this?

[PaulHazelden]

As a college, none of the staff or students are admins on any of our systems. If I presented them with software updates, there will be one of several responses...
Ignored totally.
Updates applied.
Helpdesk ticket for the popups happening.
Updates applied as a means to avoid working.

As a norm up to now, I use a Saturday as the time to run all of my updates. Adobe, Microsoft and Mac OSX. Reboots can happen at this time as there are no classes. I used to run some of the updates early in the mornings, but slow connections can make the reboot delay until after classes start, which seriously impacts on teaching and learning time.

For me having the ability to install updates at a specified time would be the ideal, and having the server do this for me is the obvious choice. Why do something yourself when you can have a server do it for you.
If I cant schedule it, then how about having it as one of the Mass action options? At least then I can sign in to the server on a Saturday and then hit the button to download and install updates, for all of a given group of Macs.
M1 Macs are going to be whole new problem, as they have to have user approval to install updates I cant update them with no user logged in. So this year, it will be around 50 M1 macs for us, next year it will be an additional 200 going M1. Does this mean I will need to spend my weekends sitting in front of a computer, signing in to and updating Macs. That is if Apple will allow it to be done via a remote session??

So to JAMF I ask for the ability to apply updates to Macs that have no user logged in, at a time of my choosing. If the MDM command can do the updates, please put it in a place where I can actually use it. The simplest solution would be a Mass Action item, with a schedule, run now, run tomorrow, run on the weekend, run at nine o'clock.

[harsha]

Hi PaulHazelden,

may I know how to set the time(manually) for the users to update the software, if users not updated within the time how can we update automatically? Can you tell me the settings how to add in jamf pro?

[mschroder]

There seem to be plenty of issues around software update. I often have the situation that System Preferences / Software Update claims there are no updates available, but when I run "softwareupdate -l" it shows some updates - that soon after also appear in System Preferences / Software Update.

I also have seen several cases where a policy claimed that no updates were available, although I knew there were some outstanding on that Mac.

The state of macOS software updates is rather unsatisfactory.

[ianatkinson]

I tried updating this Big Sur test laptop I have at home again with MDM today, still doesn't work.

It's on 11.2.3, softwareupdate -l says this is available:

• Label: macOS Big Sur 11.4-20F71 Title: macOS Big Sur 11.4, Version: 11.4, Size: 5598182K, Recommended: YES, Action: restart,

Did a tail on /var/log/install.log then pressed the 'download and install updates' MDM action, it immediately sprang to life so it got the command. After some time it said

2021-05-25 11:46:39+01 LT-JAMFTEST-16 SoftwareUpdateNotificationManager[95485]: SUOSUShimController: Install finished with error: Error Domain=SUAppStoreUpdateErrorDomain Code=105 "No updates were selected." UserInfo={NSLocalizedDescription=No updates were selected.}

And ultimately nothing seems to have happened. So I don't entertain the idea of doing all updates with MDM, but even if I did it doesn't actually work.

[Jason33]

I've had to resort to just using the Jamf Helper to notify users that updates for Big Sur are available, and to manually install them. I've set up a smart group so that any Big Sur machines not on 11.4 will get the notification.

[harsha]

Hi Jason33,

May I know how the users get notification? can you tell me where can i apply those settings in jamf pro?

[jtrant]

@Jason33 I'm doing something similar, but for Macs with "Number of available software updates" != 0. This way you set it and forget it. The downside to this process is that a Big Sur Mac with an update pending could be an OS update or something as simple as Safari.

[KSibley]

Supposedly there is an ability in Big Sur for the MDM to defer Major OS Upgrades for up to 90 days. Does anyone know what that setting is located in Jamf?