Well, I am glad I wasn't seeing things. I am seeing the same thing, but I see it on multiple versions (like 11.1.0 and 11.2.1, etc..). I am going to try running the policy again against the remaining machines but force the reboot regardless and see if that helps.

Just a quick update, I did change the policy to force a reboot regardless of the package information and it still isn't working on some of these machines. What I do notice is that the log files make it look like the installer does not actually fully download. It is a large update, but the log files seem to indicate it is not actually getting what it needs. There is no error, but it looks different than when a machine does fully download the file (there is usually a progress recorded). So this all may be Apple servers choking or it could be the machines need to be looked at (like PRAM or whatever reset, etc..)

I'm seeing this with the 11.3.1 update, no solution yet...

I'm seeing this also with the 11.3.1 update.

I restarted the laptop and nothing installed.

I ran 'recon' and the software update was saying it's still available so i logged back out again and the policy quickly ran without a reboot and the log for the second time around said no updates available. Here are 2 images of each 'details' from the policy.

but recon still shows the 11.3.1 update is available for the computer.

probably going to have to run the update manually and inform Big Sur users to do the same

something strange going on with this 11.3.1 update being run through policy. Now the 3rd and 4th time through im seeing this (see image), but laptop still says its running 11.3.0 and software updates says 0. When i run recon it then again shows 11.3.1 update available.

Gonna exclude Big Sur computers from my software update policy and have users run it manually.

Yep, had to run the 11.3.1 update manually and afterwards did a recon and laptop now says it's running 11.3.1 and 0 software updates available.

I think simply using the 'Software Update' option in a macOS policy in jamfPro probably is trying to leverage the softwareupdate binary on the Mac to run updates. I believe Apple is moving towards leveraging the MDM commands to run updates instead. JamfPro has the MDM buttons of either 'Download Updates' or 'Download and Install Updates'.

Like iOS, these are now available for macOS Big Sur. I know there was talk of using a script that sends those MDM commands to a Big Sur Mac via the API but I don't recall if anyone had success with that or not. Here is an Apple Support article talking about the MDM commands for software updates: https://support.apple.com/en-us/HT211951 The article mentions if you choose to 'Download and Install' MDM command it could result in data loss if the user is in the middle of working.

I'm not saying you couldn't get the softwareupdate command to work like with previous version of macOS, I'm just suggesting this might be a reason why it's not working.

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

Yes, the MDM command works more reliable than the policy option, but how can I trigger that command from the Self-Service or the command line? Putting the api user password in a script is not an option for me.

You could set parameters 4 and 5 as the username and password and have the policy be executed in self service that way.

Sure, but I don't like the idea to expose the username and password by putting them as parameters in a script.

@mschroder , you would encrypt the password.. Use this as a guidance

@JustDeWon Thanks for the pointer. As all our users are admins of their devices they all can read the script if they want, so they can get the credentials :( That's the disadvantage of BYOD...

Anyone seen this error?

Script result: mismatched tag at line 10, column 2, byte 404:
<p>You can get technical details <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2">here</a>.<br> Please continue your visit at our <a href="/">home page</a>.
</p>
=^
</body>
</html> at /System/Library/Perl/Extras/5.30/darwin-thread-multi-2level/XML/Parser.pm line 187.

<html>
<head> <title>Status page</title>
</head>
<body style="font-family: sans-serif;">
<p style="font-size: 1.2em;font-weight: bold;margin: 1em 0px;">Unauthorized</p>
<p>The request requires user authentication</p>
<p>You can get technical details <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2">here</a>.<br> Please continue your visit at our <a href="/">home page</a>.
</p>
</body>
</html>

Any clues?

Just have the users run the stupid update manually, what's the big deal See if the issue is resolved when the next update comes out

@fredrik.virding My guess is your API account in jamfPro doesn't right the proper permissions

@_ssrussell I managed to fix that, but the User still gets a prompt to install a Helper.

Anyone who tested around with the jamf binary command runSoftwareUpdate -fromApple?

We run a script with our update policy that process after the download phase. Ours stopped working but with JAMF Support help they suggested using "softwareupdate -i -a -R"

Which fixed it for us.

@chriso16 chriso16   I do the same thing in my policy. In the processes payload i put softwareupdate -aiR  but it doesnt restart the computers.  Maybe i'll spread it out softwareupate -i -a -R

are your M1 computers restarting? or sitting there waiting for admin account?

M1 computers were already 11.6.4 when they gave me the suggestion I'll update once next update comes out.