Skip to main content

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.

We're seeing the same issue, have you been able to find a solution?


Same issue here. Would love to know when you have been able to find a solution.


I ran an update via policy yesterday, and it downloaded and prompted me to reboot. After entering my non-admin user account password, machine rebooted and installed 11.2.2.


I ran an update via policy today. The download was bit to fast. After download the terminal says "no reboot required". But this is wrong.
AUtomaticly no reboot will be forced on our side and forcing it manually nothing happens.
So on our side this not work like expected.
Mac which I test is on 11.1 and should be updated to 11.2.2(20D80)


As a workaround we are just executing this command to update "/usr/sbin/softwareupdate --install --all --restart"


I have seen install issues on Catalina and Big Sur for months now. Some updates work on some machines, others downloaded and install, but when the OS comes back up the install didn't take. No idea what the hell is going on. Only thing I can find is a bad BridgeOS update.


Same issue doesn’t to Restart after Apple Security Update is downloaded but JAMF Pro gives a false Completed.


Same here. I also created a test policy with "Restart Options" set to "Restart Immediately" and while it rebooted the update was still not installed.


Same issue, Apple updates through Jamf show "No Reboot Required".



I have been working with Jamf support on this issue and we have created a policy to execute a command "softwareupdate -i -a -R". This does work and installs updates, however, we don't like to reboot user machines with out warning. We tried to modify the command a little bit and do "softwareupdate -i -a; shutdown -r +30" which does schedule a reboot in 30 minutes and warn the user but in initial testing it downloads all updates, reboots in 30 minutes, but OS versions still shows updates pending in sys pref. It seems either the OS or Jamf takes the scheduled shutdown as a separate command and does not install updates when powering back up.



I am still testing with but if anyone have any ideas on how to force install updates and schedule a reboot in 30 minutes while prompting the user or if I am just doing something wrong, let me know.


It's a bit annoying that we moved away from patching using a Files & Processes payload for Big Sur, only to find that what we were told to move to (Software Update payload) is completely broken. In my case all of the Big Sur clients I need to patch in an automated fashion are headless, so I can reboot them without warning. I'll give the old method a try and report back.


Just reporting back on this. The "Files & Processes" payload method is working for me, the downside being that they restart even if there are no updates pending. This is a good stopgap method until, presumably, Jamf update the "Software Update" payload to support whatever changed in Big Sur.


@jtrant Can you elaborate on the "Files & Process" payload method?


@jtrant - Please let us know in detail what is the exact command which goes in "Files & Processes" payload. Additionally have anyone noticed the password authorisation while installing macOS Big Sur security updates.


Sorry for the delay. My Files & Processes payload is simply:



softwareupdate -i -a -R


However, it doesn't seem to work after 11.2.3 (attempting to install 11.3) so I'm back to square one.


for me it works with softwareupdate -i -a -R +"Time you want give until restart" and the policy shows the restart in through user interaction. The restart is configured as well in the restart payload.
So when I am giving 60 Minutes to restart in the processes payload, I add the restart payload with 60 minutes to the same policy


@user-faWBxyKMJD How are you getting that to work in Files and Processes within a Policy? When it runs on a client device it hangs. Like it is waiting for authentication.



Security Updates for Big Sur through Jamf seems impossible


So the fix is to add a Policy using Payload Files and Processes - Execute Command softwareupdate -i -a -R and now that does not work in Big Sur? So what can we do it install an update considering how important it is right now with real security vulnerabilities being reported for Apple products not running 11.3.1?


@dmichels after further testing it does seem to work on intel devices with Big Sur but it takes a very long time to download then about 40 minutes to install.



I cannot get it to work on M1 devices. I would think that is due to the new authentication.



Still not the best process for managed devices


'softwareupdate -i -a; shutdown -r' and 'softwareupdate -i -a; shutdown -r +30' on Big Sur Intel Macs seem to work, but only if they are run by the user. A Jamf Files & Processes payload in a policy seems to download and reboot, but not actually install the update.


I couldn't get it to work via JAMF policy so I had it manually install via terminal - sudo softwareupdate -aiR



this is regarding the 11.3.1. update


I have been beating on an M1 MacBook Air in an attempt to issue an unattended macOS software update from 11.3 to 11.3.1 and I believe I have it working.



I crafted a very rough API script that issues the ScheduleOSupdate command and once I ran it on the M1, it showed in Jamf that the MDM command was in fact pending and eventually reported successful, but I saw no indication on the Mac itself that anything occurred or that the update was even downloading. I left it alone for toughly 7 minutes when all of the sudden it just restarted and did perform the update. I was never prompted to enter a password, it simply restarted and forced closed all apps open.



The only issue is that I was logged in at the time so I cannot confirm if this will work at the login screen. I have pasted the script I ran in here so if someone else wants to give it a try please do. Maybe it was a fluke.



#!/bin/sh

#API login info
temp_nu="Temp Username"
apiuser=$(echo $temp_nu | openssl base64 -d)
temp_np="Temp Password"
apipass=$(echo $temp_np | openssl base64 -d)
jamfProURL="https://ORG.jamfcloud.com"

#Grab serial number and OS Version of computer
SerialNumber=$(system_profiler SPHardwareDataType | grep 'Serial Number (system)' | awk '{print $NF}')
macOSVersion=$(sw_vers -productVersion)

#Check macOS Major
CheckIt=$(echo $macOSVersion | cut -d . -f 1)

#Set xpath option based on macOS major version
if [[ "$CheckIt" == "11" ]]
then
xpath="xpath -e"
else
xpath="xpath"
fi


jamfProCompID=$( /usr/bin/curl -s -u ${apiuser}:${apipass} ${jamfProURL}/JSSResource/computers/serialnumber/${SerialNumber}/subset/general | $xpath "/computer/general/id/text()" )
echo $jamfProCompID
#/usr/bin/curl -s -X POST -H "Content-Type: text/xml" -u ${apiuser}:${apipass} ${jamfProURL}/JSSResource/computercommands/command/ScheduleOSUpdate/action/InstallForceRestart/id/${jamfProCompID}

#/usr/bin/curl -s -X POST -H "Content-Type: text/xml" -u ${apiuser}:${apipass} ${jamfProURL}/JSSResource/computercommands/command/ScheduleOSUpdate/action/Default/id/${jamfProCompID}

/usr/bin/curl -s -X POST -H "Content-Type: text/xml" -u ${apiuser}:${apipass} ${jamfProURL}/JSSResource/computercommands/command/ScheduleOSUpdate/action/install/id/${jamfProCompID}


exit 0

I have 100+ headless Intel Mac minis to update from 11.23/11.3 to 11.3.... Running 'softwareupdate -iaR' via ARD command or Jamf policy isn't working so well. Logs show the update downloads and says restarting but nothing happens.


I'm trying to update via mass action to a Smart Group, and getting this error:
Unsupported InstallAction for this ProductKey



Anyone else have similar? Both machines running 11.2.3, one M1, the other Intel chip


jason33, I was getting the same error when I would run an API script using the flag "InstallForceRestart". Once I changed it to just "install" it would work without issue.


@nelsoni I'm not even forcing an install or reboot - I chose just to download the update for user to install.


Reply