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.

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?

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.

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.

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.

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.

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

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?

for those following this thread: read this blog post for the sorry state of managing softwareupdates in 2021...:-(
https://travellingtechguy.blog/demystifying-macos-big-sur-updates-and-jamf-pro-10-29/

@KSibley See here

Some of my frustrations with Software Update deferments:

-Deferments are located in the Restrictions profile - not in the Software Update profile.

-You can only have 1 Restrictions profile per device, so it's easy to get into messy situations with multiple instances of the profile scoped to multiple groups of Macs.

-Deferment options are limited to 1, 7, 30, 45, 60, and 90 days. The 'sweet spot' for me is 14 days - which isn't possible.

@dstranathan

Check out this JNUC 2019 video by Matthew Mitchell about editing Configuration Profiles to not only apply only those settings you want to apply (and not every other option available on that part of the interface) but also to set specific values that might not otherwise be available in the interface. We've used this method to set deferrals of three or ten days. We also configured a screen lock to a custom value of 15 mins when the interface would otherwise only permit 10 or 20 minute intervals.

https://www.youtube.com/watch?v=tqF4ls823ig

Does anyone just force the updates to download and install with enabling everything in a config?

How would you address this with the end-user? They reboot and unexpectedly have to wait 20 minutes..

It's a heavy-handed approach although management is pushing for us to do it that way.

We're not doing it that way. I currently use a heavily modified version of the defer or install that allows the user to postpone during the workday

So I finally got a solution working which is running well and giving us good results with patching, which is bringing us inline with our windows estate.

I set up the following:

• Config profile to stop auto updates and stop users running updates.


• An Extension attribute pulls in the software updates to the Operating system inventory (I made this as there is no default way to get updates into a smart group)


• Smart group then looks at this and if it sees anything like "macOS" or "Security" then it falls into an OS updates policy



• The Policy runs weekly and runs a script which does the following:
  Notifies the user via jamfhelper that updates are available
  lets the user postpone or continue (if postponed a date stamp is added to the mac and used to force the update after 5 days)
  if the user continues then the script will run softwareupdate -i -r -R (which runs recommended updates)
  The user gets another jamfhelper popup to tell them whats happening and then the computer reboots if needed




• The postponed macs fall into another policy which runs daily and runs the same mac updates script as above but with some added logic to check the date stamp on the mac and force it after 5 days.

We also roll this out in patching waves which again is another piece of scripting which is applied when we provision our macs. They basically get assigned to one of 3 static groups (patching waves) and then updates are rolled out to different waves to avoid potentially bricking all systems if there is a bad update.
we have:
Admin macs
Pilot users
Wave 1
Wave 2
Wave 3

These are all in the exclusion scope of the update policy and removed weekly each month to run through each wave until the whole estate is patched.

Bit long winded but its working really well so far and our estate is in a much healthier place.

@tzeilstra I attended Matthew Mitchell's session I think. It was pretty handy, and I have a few custom profiles that leverage what he demonstrated.

Correct me if I am wrong, but I don't I can break out the software update deferral times (forceDelayedSoftwareUpdates) into a custom MDM profile because the preference domain for the forceDelayedSoftwareUpdates key/value pair is com.apple.applicationaccess - which is used by a ton of other restrictions that I also need to be managed. You can't have multiple profiles managing the same preference domain, can you? I know the most restrictive setting (usually) takes priority when conflicts occur, but this would be rather messy to manage.

Here is a listing of most of the key/value pairs in the com.apple.applicationaccess preference domain:

allowCloudDocumentSync
llowCloudDesktopAndDocuments
allowSpotlightInternetResults
allowMusicService
allowCloudKeychainSync
allowCloudBTMM
allowCloudFMM
allowCloudBookmarks
allowCloudMail
allowCloudCalendar
allowCloudReminders
allowCloudAddressBook
allowCloudNotes
allowFingerprintForUnlock
allowPasswordSharing
allowPasswordAutoFill
allowPasswordProximityRequests
allowCamera
allowContentCaching
forceDelayedSoftwareUpdates
forceDelayedAppSoftwareUpdates
enforcedSoftwareUpdateDelay
allowAirPrint
forceAirPrintTrustedTLSRequirement
allowAirPrintiBeaconDiscovery
allowScreenShot
allowRemoteScreenObservation
forceClassroomUnpromptedScreenObservation
forceUnpromptedManagedClassroomScreenObservation
forceClassroomUnpromptedAppAndDeviceLock
forceClassroomAutomaticallyJoinClasses
forceClassroomRequestPermissionToLeaveClasses
allowActivityContinuation
allowDeprecatedWebKitTLS

In my environment, I need (3) scopes for Software Update deferrals

0 days = Me & fellow Mac admin's Macs
7 days = IT Macs
30 days = Production Macs

Also, If I'm not mistaken, I can't set the value of enforcedSoftwareUpdateDelay to 14. I think it MUST be 1, 7, 30, 45, 60 or 90, otherwise, macOS will not honor the key/value pair, correct?

@dstranathan I'm pretty sure you can have multiple Profiles addressing the same Preference Domain as long as they're not both trying to set the same key/value pair. I know we certainly use several different profiles for several different PPPC and Notification payloads. I can also confirm that you don't need to stick to the values specified in the GUI for the delays. One thing you do need to confirm is that the profile is signed BEFORE you upload it back to Jamf. if you don't sign it first, Jamf will attempt to "correct" it and exactly what happens next is anyone's guess.

Thanks, @tzeilstra - Ill play with it and see what I can come up with.

@dstranathan Was Matthew's session something that was public - or was this a training class you were in? I'm intrigued.

Is there a way to block Big Sur from checking for updates and users seeing that updates are available? I know that's not the ideal solution but working in a 6-12 school making sure students, especially the younger ones, keep their macs updated and not update it during the school day stresses me out.

@k3vmo This was a JNUC session in Minneapolis a couple years ago. It’s still available on YouTube.

Are MDM update commands in Big Sur unreliable?

I tried sending an MDM command to an 11.4 Big Sur Mac to download update, install and restart but while it seemed to download from the management history, and it even rebooted, nothing occurred (still at 11.4 instead fo 11.5). Nobody was logged into this machine. 

Any suggestions?

They still aren't working well for me; getting very frustrating as I approach the school year and am on the brink of upgrading my Fac/Staff stations.

And then you see stuff like this in /var/log/install.log and you just die a little: 2021-07-22 15:55:52-05 CAC301-MD-TS softwareupdated[368]: SoftwareUpdate: request for status for unknown product MSU_UPDATE_20G71_patch_11.5

Jamf Pro recommend using Mass Action Feature which can NOT be scheduled and KILL the network. I tried this on just 25 iMacs and my network was completed flooded and this was at night. It also worked on some and did not work on others. Very inconsistent.

the Policy running softwareupdates -i -a -R says is works in the logs but nothing happens as well. I can't believe the answer is to turn on Apple Automatic Updates or run manually. 

1. • Log in to Jamf Pro.
     

   • Click Computers at the top of the page.
     

   • Click Smart Computer Groups.
     

   • Select the name of the smart computer group you created.
     

   • Click View at the bottom of the pane.
     

   • Click Action at the bottom of the pane.
     

   • Select Send Remote Commands.
     

   • Click Next.
     

   • Under Remote Commands, select Update OS version and built-in apps (v10.11 or later computers enrolled with DEP only).
     

   • At the bottom of the pane, select one of the following for Update Action:
     

     • To download the update on computers for users to install themselves, select Download the update for users to install.
       

     • To download and install the update on computers automatically, select Download and install the update, and restart computers after installation.

Yes, I concur with you MDM commands are unreliable with Big Sur and even worse all the logs say everything is working.