Apple's Software Update server (Policy) for Big Sur Security Updates

[jschank]

Anyone having issues attempting to update Big Sur devices via Policy and using Apple's Software Update server? The policy is not working for Big Sur including intel machines. Attempting to get the latest update (20D74).

With the terminal open, it states it downloads. It shows as completed in Jamf within the policy. Also within client history. Yet reboot does not install the update.

Mojave and Catalina devices update fine.

[kacey3]

I'll identify a test system and try this out.

[kacey3]

I got the exact same prompt using the MDM command from within the Jamf console.

[kacey3]

I got the same exact prompt using the MDM command from withing the Jamf console.

At least I know my script "works," since it gives me the same result.

[sdagley]

@kacey3 That _should_ work with no prompting. I've been able to use it to take a Mac on Big Sur to 12.2.1 with no user prompting. Are you seeing any other issues with MDM commands on that Mac? And can you nuke & re-pave it to the existing OS then re-enroll and see if the problem goes away?

[kacey3]

Nothing else stands out... and the ol' Nuke'n'Pave isn't an option since this is on all of my M1 Macs.

[sdagley]

So _every_ Mac you've tested this on does the same thing? I'll have to recycle my "Odd" comment as it might be less annoying that Work For Me™

[ianatkinson]

I'm trying to switch over our staff updates from softwareupdate to MDM based and have just hit this same error message. This is on an Intel Mac so nothing to do with M1 I don't think.

Peering through the install.log I have noticed this line:

2022-03-23 11:20:58+00 BW-BAGRAPH-08 SoftwareUpdateNotificationManager[59071]: SUOSUAuthorizationController: Requiring admin authorization prompt for standard user because restrict-store-require-admin-to-install is set

This seems to be a config profile I have set whereby staff can't just install random app store apps (which I don't want them doing) but that seems to be breaking the MDM. I'm not sure why it would since it's essentially JAMF installing the updates with root access but MacOS seems weird these days about the logged in user getting some say in this stuff.

That key is marked as deprecated though and there's a newer one so whether this will work OK if I swap to the newer key I don't know, I'll give it a go.

[kacey3]

Turns out that I needed to add a PPPC to grant SoftwareUpdateNotificationManger administrative rights. nAt this point, I'm not sure if I need both of the permissions I granted, but I picked the two most likely candidates for my first test. I suspect I only need PostEvents, but I will test that further.

 

[kacey3]

So... this worked on one test... but not on further tests. Will have to investigate deeper.

In fact every attempt to replicate my success has resulted in failure. This admin prompt is just driving me nuts!

[ianatkinson]

I'm getting this on an Intel machine and can see this in the install.log

2022-03-23 11:20:58+00 BW-BAGRAPH-08 SoftwareUpdateNotificationManager[59071]: SUOSUAuthorizationController: Requiring admin authorization prompt for standard user because restrict-store-require-admin-to-install is set

I have that set to stop users installing random app store apps by themselves but it seems to be conflicting with the MDM update command

[ianatkinson]

I tried updating to the more modern key and got the same error message so I think this is fundamentally broken if you restrict app store in that way. Instead I've set the key restrict-store-softwareupdate-only which basically disables app store and achieves the same thing and the MDM updates now work. I did wonder about using software resrictions in JAMF to give me more control but I'm thinking that might break some stuff underneath if JAMF is essentially killing the app store process if it sees it.

In the logs with this working this line gets logged instead:

2022-03-23 14:02:32+00 BW-ILLUSTRA-46 SoftwareUpdateNotificationManager[9150]: SUOSUAuthorizationController: Non-interactive authorization succeeded for non-admin user

Hopefully that might help someone out if they're seeing this!

[kacey3]

I came to that conclusion yesterday with Jamf Support, but was still testing to confirm success.

But yes, it is apparently an issue that if you have that restriction enabled, it will, in fact, trigger an authentication box and thus fail to update.

[AlanSmith]

Just wanting to add a "we're also having this issue" note to this as we have just moved from Catalina to Big Sur this year. 

Would love to see some JAMF input into this! 

I have created a 'feature request' to fix this. Feel free to give it a vote: https://ideas.jamf.com/ideas/JN-I-25777

[dmichels]

Apple Security Updates Big Sur 11.6.3 and 11.6.4 are not downloading and the Scripts and Policies & Procedures & Mass Action are not working well for me since Jamf Pro Cloud 10.35 updated.

• Files and processes: softwareupdate -iaR --force (the Policy is just hanging not even working
• Scripts essentially running this command: /usr/sbin/softwareupdate --install --all --include-config-data --restart --force (the Policy is just hanging not even working)

In the past these scripts worked and downloaded which I ran overnight. Then when I came in I had to log int Start the Update but the long tedius part downloading was completed. Now the System Preferences just hang. I have to go to Terminal and run: sudo /bin/launchctl kickstart -k system/com.apple.softwareupdated and then go back into System Preferences and run manually sometimes the updates are there and most times not.

[kacey3]

So, I've gotten past the admin authentication prompt, but now I'm seeing a new issue. The prompt was generated as a result of having "Require admin password to install or update apps" enabled under the user restrictions. While this shouldn't override an MDM command, it was confirmed by Jamf Support that it does, at least under Big Sur.

My new issue is that whenever I send the MDM update command, whether via the Jamf Console or an API script, the computer receives the command, but ultimately does nothing. The Software Update control panel confirms that there are still updates pending (as does the OS version), but no matter how I send the MDM command, it never actually updates. The management history shows the command running, but there's still no actual update to the target system.

Thoughts on where to look next?

 

[kacey3]

Looking at the logs, this is the most suspect line:

Mar 23 14:32:13 CVADMDL142334 com.apple.xpc.launchd[1] (com.apple.preferences.softwareupdate.remoteservice[2585]): Service exited due to SIGKILL | sent by com.apple.preferences.softwareup[2585]

The second possible culprit I see is this:

Mar 23 14:00:27 CVADMDL142334 com.apple.MobileSoftwareUpdate.UpdateBrainService[674]: objc[674]: Class LPPartitionMedia is implemented in both /System/Library/PrivateFrameworks/MSUDataAccessor.framework/Versions/A/MSUDataAccessor (0x1ff99cb98) and /private/var/db/com.apple.xpc.roleaccountd.staging/com.apple.MobileSoftwareUpdate.UpdateBrainService.16777230.6479675.xpc/Contents/MacOS/UpdateBrainLibrary.dylib (0x100bc18f0). One of the two will be used. Which one is undefined.

I'm not really familiar with either of these errors, but both seem suspect and both relate directly to SoftwareUpdate.

[kacey3]

What has really been plaguing me is the inconsistency of success and/or failure. I can try all day to get 10 computers to update, either via the Jamf Console or the API Command, and fail every time. Then all of a sudden it will work on all 10 computers without me really doing anything different. I just want a consistent and reliable method to update my remote computers.

[AlanSmith]

Ok, resurrecting this topic as with the latest security patches, our security team is putting the pressure on to apply them.

My experience to date, using Jamf Policy, configuring the Software Update to run via Apple's Software Update Servers, the updates download, but then do not apply as it states a restart is not required.
However if I log into a machine that has had the policy run and successfully downloaded the update,  and then select 'Restart...' from the Apple menu, the update starts installing and will run and reboot once finished!

[dmichels]

Interesting. I have not use SUS in awhile. Do you know if this downloads
for macOS Monterey as well?

--
Debbie Michels
Apple Specialist
ITS Information Technology Services
Bergen Community College
Pitkin Building - Room A236
400 Paramus Road, Paramus NJ 07652

dmichels@bergen.edu
(O) 201-879-1694

[AlanSmith]

Hi Debbie

I believe this issue applies to Monterey as well, yes. 
Just to re-iterate, the update will download, but will not install automatically, no matter what setting you have!
The only way to 'install' the update is to log in to the machine and select 'Restart...' from the Apple menu, and I am discovering, even then it doesn't always work.
However if I run 'sudo software update -i -a -R' from the command line in Terminal, then select 'Restart...' from the Apple menu it will finally run the updater!

Hope this makes sense!

[pueo]

I gave up on using the Software Update command via Jamf and any policies. I implemented Nudge.  It works, it bugs people and the success rate is very high. 
Anyway, we will stick with Nudge for awhile and see how it goes.

From 230 devices we have 7 people who have not updated as their machines have not been online for a few weeks and one person who just has not updated. There is a ticket for this user for Site Support to reach out to user.

[AlanSmith]

Unfortunately I work in a tertiary education environment that has a number of student labs and no users have admin rights.
We need to be able to update the machines all at pretty much the same time (say over a 12 hour period) so that they are all on the same macOS version.
Do something like Nudge wouldn't really work for us!

[pueo]

I undertand.

Can you push out a Jamf Helper command to automatically reboot the Mac?  We used Jamf Helper to alert users there were updates and they would install and then then require a reboot.  

You could also cache a copy of Monterey on each machine, then run a jamf policy to install Monterey. It will work and is pretty straight forward.  If you have 12hrs, you have plenty of time to reinstall the OS. It does not wipe anything and will fix any other small issues the machine has.
 You can set up a caching server so you are not downloading Monterey XX number of times.

 I used to work in a secondary school prior to my corporate job.  

At the school I would not update any labs until a break. It was then easier to just rebuild the labs anyway. We had Art, Media, Music labs etc.  Non of which needed the latest and greatest macOS to run the Apps.

All student machines were Standard users.
Staff machines were blocked for 90 days then they could upgrade them selves or let us do it. Staff were Admins.

Again, all scenarios are different and you have to work with in Policies.

I also worked at a private tertiary environment where we had 8 week terms.  Every 8 weeks we would wipe the machines and rebuild them.  Casper/Ghost worked great for PCs and the old Carbon Copy Cloner worked for Macs.  This was way back in 2002-2004