@kacey3 Is this an M-series Mac? And was it enrolled with Jamf Pro via Automated Device Enrollment?

Yes and yes.

And yes, it is bootstrapped.

<quizzical look> Odd </quizzical look>

Tell me about it! I'm at my wits' end on this!

Just for grins, if you try issuing the "Download and install the update, and restart computers after installation" remote command by doing a search for that Mac and using the Action button on the results page does that work without a prompt?

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

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

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.

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

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

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.

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

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!

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.

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

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!

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.

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?

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

Mar 23 14:32:13 CVADMDL142334 com.apple.xpc.launchdh1] (com.apple.preferences.softwareupdate.remoteservicec2585]): Service exited due to SIGKILL | sent by com.apple.preferences.softwareupu2585]

The second possible culprit I see is this:

Mar 23 14:00:27 CVADMDL142334 com.apple.MobileSoftwareUpdate.UpdateBrainServicec674]: objcj674]: 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.

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.

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!

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!

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.

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!