For years I had been updating my campus computer lab Macs with either a script or Apple Remote Desktop and the command "softwareupdate --install --all --restart --force". Now it seems like this command doesn't work in Big Sur without someone logged into the machine. I don't want/can't trust my users to have to click on anything to make the update happen, I would just like to apply Apple updates to the machines when they aren't being used. (And with 500+ machines it's not practical for me to login to each to update.) I would also prefer something where I can choose when the updates are applied, so they don't randomly apply just as a class is starting or when a big project is due. Does anybody have a workflow to make this happen?
I use this script https://github.com/mpanighetti/install-or-defer
It gives the user flexibility to defer install by 72 hours before it forces the install and restart beyond the users ability to block.
It users a launchdaemon to ensure it runs at boot so even if a user reboot their device to avoid the update it’ll still happen
Thanks @mbracco , like donmontalvo I'm glad Apple is at least aware of this. Please post here if you find out it's fixed.
And thanks again @Cayde-6 , but I need something that doesn't rely on users. Since this for student computer labs the students don't have the flexibility to wait for an update to happen as their class is starting. But your suggestion on another ticket about doing a startosinstall with the Big Sur installer is something I will explore while we wait for Apple to fix this.
@donmontalvo We are at 10.27.0, but only because we have JAMF Cloud and they always keep us on the latest update.
I still don't think that gets around the problem of having to have a user logged in to the Mac for Big Sur updates to run @Cayde-6 . I don't want our students to login to a lab machine and have it instantly start updating. And I don't want to have to login to 500+ machines individually to allow them to run updates. But maybe I'm missing something.
@mikeo Had you made any progress with this? I'm kind of in the same boat, retooling the way we deploy updates. I am going to try creating a new smart group of two machines that are on Big Sur and enrolled via ADM, and use a mass action to download and install the update and restart computers after the update. On one machine I'll have an account logged in, the other wont be. The Jamf admin guide says on M1 devices a user may be prompted to authenticate before an update can be installed. This definitely should be fixed by either Jamf/Apple for devices that are MDM enrolled.
I haven't made much progress @Jason33 . I had read somewhere that you can do a startosintall with the machine not logged in as long as you have the full Big Sur installer. I was able to use softwareupdate --fetch-full-installer to get the full Big Sur installer on a machine. But I haven't been able to get /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall to work correctly, because it seems to want to work interactively. I could write a script, but from what I can tell that script will have to contain the username and password for an admin on the machine. Using a script through JAMF is going to be my next test, then at least the script will only be on the JSS and not the individual machines.
That's great news @mbracco . I haven't had the time to mess around with the betas, but I'm REALLY hoping they roll the fix into 11.3 when it comes out.
We did the long way also, downloading the InstallAssistant 11.x pkg from apple. Then firing a script after install to launch startosinstall with '/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --nointeraction --forcequitapps'.
After installing the pkg it takes about 20 minutes to prepare the update. So A good way is to push the pkg let it install and create a smartgroup with preinstalled big sur. Then next day or (later) launch a second policy scoped to the new smartgroup.