Posted on 02-03-2021 12:29 AM
Before the M1 Mac's we used the softwareupdate command line tool to download and install updates - and force a restart after a 48 hour deadline has passed.
On M1 Mac's with Big Sur this fails because softwareupdate now needs a user password in the middle of the upgrade. No amount of sudoing will help.
Then we have the "Download and install software updates" management command, which:
- Cannot be issued as a policy
- Cannot be deferred
- Cannot be scheduled
and worst:
- Still needs the user to enter the password! Simply clicking cancel fails the updates :(
What are we supposed to do now? Our security team is not happy that our brand new mac's are potentially running insecure versions of macOS indefinitely - especially after we just taught everyone that security updates will be automatically installed within 48 hours.
01-25-2022 07:56 AM - edited 01-25-2022 07:57 AM
I hear you, but if the MDM provider isn't giving me any solutions, I have to bend it to my will. That's the benefit of the API...just encrypt those passwords. Looking forward to Jamf providing a solution for this.
Posted on 01-25-2022 01:54 PM
To add a #3 to @AJPinto 's list - if you ever decide to restrict the IP addresses allowed to access your JSS console then you will find the API doesn't work except from those IP addresses. That kind of precludes using the API from arbitrary endpoints.
Posted on 01-26-2022 06:57 AM
We have an always on VPN (Palo Alto Global Protect) , so that's not much of a problem for me.
Posted on 03-31-2022 04:45 PM
To bypass the concerns about username/password info via clear text.. Could we create a service account that's only permissions is to "Send Computer Remote Command to Download and Install macOS Update."
Posted on 01-25-2022 11:52 AM
I use the "install" action btw.
Posted on 01-25-2022 02:03 PM
Ah! I see!
So that will simulate "InstallForceRestart" i assume?
01-26-2022 07:03 AM - edited 01-26-2022 07:05 AM
@fredrik_virding, from testing it seems to have that behavior, but I do see people using "installForceRestart" directly in their API commands though. Doing more testing on this...
With the "install" action it takes anywhere from 20 minutes to an hour to reboot the machine. I'm trying to lower that interval, so that the user won't be confused.
Posted on 01-27-2022 06:59 AM
@bwoods
Tried running the InstallLater, and it did download, and install, but no notification about a restart pending.
However, manually going into Jamf and running a remote command, and there selecting InstallLater, triggered that notification about a "manage updated".
Curious behavior, but close to working.
Posted on 03-09-2022 07:45 AM
Sadly, even when I use this method, my target computers still prompt for admin credentials and I can't for the life of me, figure out why. They were deployed via MDM to begin with, they are communicating with the server as expected, and their Bootstrap Tokens are escrowed with our Jamf server, and yet I get this pop-up every time I use the actual MDM command in the Jamf Console or use the above script.
I can't for the life of me figure it out!
Posted on 01-28-2022 09:36 AM
@fredrik_virding, not sure if that action is fully supported. You can use user interaction or jamf helper to inform the user of a pending update though.
Posted on 03-24-2022 12:53 PM
I finally resolved the admin authentication, but now I'm dealing with a fully inconsistent response to my attempts to initiate the update.
I can use either the Jamf Console or an API Command embedded in a policy to trigger the update. The results in the computer management logs are the same either way:
ScheduleOSUpdate
AvailableOSUpdates
ScheduleOSUpdateScan
The problem is, sometimes it works, and other times it doesn't. I haven't figured out, yet, what I can do to consistently make the update command stick and proceed.
At first, I thought it was the update manager getting stuck, and I came across this command that, once issued and the computer rebooted, seemed to allow the update to go through:
sudo rm -rf "/macOS Install Data"
But that only worked for a couple of my test cases. I then found an alternate solution that involved sending this command in advance:
sudo launchctl kickstart -k system/com.apple.softwareupdated
Which, again, worked for several computers. This one did not required a reboot, so I added it to my API command script to hopefully fix the problem before it became a problem.
Unfortunately, after having updated 20 computers through a variety of the above fixes, I now have 10 more computers that seem resistant to update at all, and thus I'm back looking for another solution, because apparently nothing that I've done previously was actually a solution. They were likely all placebos, and I am thinking I was just lucky with the first 20.
If they would at least all succeed or all fail, that would be something, but this roller coaster of success and failure is just maddening.
Posted on 05-16-2022 01:12 PM
Posted on 05-17-2022 02:54 PM