macOS 11.3 update via policy: reboot not required?

mschroder
Valued Contributor

Hi,

I am trying to do minor software updates via a policy, and I have a strange result on macOS 11. The targeted devices (running 11.2.3) download the 11.3 installer, and then the log claims "reboot not required" - so the update does not get installed.

Any idea what is wrong there?

17 REPLIES 17

DS6220
New Contributor

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.

DS6220
New Contributor

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

bassic
New Contributor III

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

tcandela
Valued Contributor

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

1e8f9a98fb8e4844b2d9b500aa1f135c

1858e0e96ca049ad8a2178a3b972d355

tcandela
Valued Contributor

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.

39b9504e977a4b609a1ae1c6472ccbd0

tcandela
Valued Contributor

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.

Not applicable

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.

nelsoni
Contributor II

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

mschroder
Valued Contributor

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.

nelsoni
Contributor II

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

mschroder
Valued Contributor

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

JustDeWon
Contributor III

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

mschroder
Valued Contributor

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

fredrik_virding
Contributor

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?

tcandela
Valued Contributor

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

Not applicable

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

fredrik_virding
Contributor

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