How are we supposed to manage Big Sur updates on the M1 Macs now?

New Contributor III

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.


Valued Contributor

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.

Honored Contributor III

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.

Valued Contributor

We have an always on VPN (Palo Alto Global Protect) , so that's not much of a problem for me.

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


I use the "install" action btw.

Ah! I see!

So that will simulate "InstallForceRestart" i assume?

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

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. 

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.

Screenshot 2022-03-09 09.42.41.png

I can't for the life of me figure it out!

Valued Contributor

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



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:


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/

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.