Can upgrade MacOS through policy with login trigger, but not recurring check-in

[joshuam]

Hello everyone,

We are trying to use the following process to upgrade user machines from Catalina to either Big Sur or Monterey (depending on hardware support):

1. Use a policy to cache an install of MacOS, targeted by static group
2. Once the cached install has completed successfully, add the computer to a second group to manually extract and install the cached installer using a script.  The script uses jamfHelper to allow users to delay the upgrade, etc., and ultimately culminates in the following command:

   /Applications/Install\ macOS\ Big\ Sur.app/Contents/Resources/startosinstall --agreetolicense --nointeraction --forcequitapps --pidtosignal $jamfHelperPID >> /var/log/startosinstall.log 2>&1 &

We've verified that the script works when run directly, as well as when run by a policy that is triggered by login.  However, if we set the policy to run on recurring check-in, we see miscellaneous oddities including Jamf Helper launching in full screen and then immediately exiting, or launching in full screen but the upgrade never being executed.

Is this something anyone has run into?  I'd be content to just let the upgrade occur on login, but we have several users who don't log off despite the requests and we're a bit weary of potentially causing data loss from unsaved work, etc.

Thanks in advance!

[Tribruin]

Not sure what might be running different between the login trigger and the reoccurring trigger. But, I would suggest looking at this utility instead:

grahampugh/erase-install: A script that automates downloading macOS installers, and optionally erasi...

(Don't be frightened by the title, it can do in-place upgrades as well.) 

We used it to upgade about 600 computers from Catalina & Big Sur to Monterey and worked like a charm. Saved us a lot of work. You can even incorporate your current process of caching the installer before you run the upgrade. 

[joshuam]

Thanks for the resource; I will give it a try and see if it makes any difference on ability to upgrade on check-in (versus just on login) and let you know what I find.

[binjali]

I also want to do this for my fleet. How did you get this to work? I added the package to jamf, and pushed it out to my test computers by policy but how to I get the various switches into the install?  I thought i could make separate polices that included scripts that talk to the intalled package.  Is this the correct usage?

[joshuam]

Hi Tribruin,

Sorry for taking so long to get back to you.  I tested out the erase-install script, and while the appearance is much nicer than the Jamf Helper method I'd been using, I still ran into issues with the script running consistently on check-in.  I wonder if performing the upgrade on check-in is just a non-starter, as even on their Wiki they state:

Please note that when using this script in a Jamf policy with the --erase or --reinstall options, the policy will not be logged as completed, because the computer restarts before the script can complete. Therefore, it is important that you do not have this policy set to run automatically on a "Once Per Computer" basis.

I'll keep trying, other options, though, as I'd like to have everyone up to at least Big Sur by the time Ventura rolls around.

[Tribruin]

I wouldn't use reoccurring on this type of policy. I would set either once per computer or at least once per day. If you do set to once per day/week, make sure you scoping is set to exclude any computers already upgraded. 

[joshuam]

Sorry for the late reply, but I think I finally have a working script.  The approach I ended up taking is writing a script  which (at a high level) does the following:

• Checks for existence of a created temporary file (see the next bullet item), and if it exists deletes the file and exits with 0
• If the temporary file does not exist, create the file and then perform the upgrade

This script is then distributed as a PKG and executed through Files and Processes rather than distributed as a script within the Jamf policy (which was introducing problems of its own).  This approach solves all the problems I was running into:

• The upgrade constantly re-running because results were never uploaded to Jamf.
• Running the script through the policy itself resulting in the upgrade terminating before completing.
• Allows me to automate using smart groups in Jamf.

It's also worth mentioning that version 27.0 of erase-install is in pre-release, and appears to address most of the issues I was running into:

• Allows for logs to be reported back to Jamf Pro by changing the method startosinstall is launched. This requires rebootdelay to be set, which allows uploading the script result to Jamf Pro before startosinstall force-quits our script and reboots the machine (thanks to @cvgs).
• Adds launcher script erase-install-launcher.sh which can be used to start the pkg-delivered version of erase-install from the Scripts section of Jamf Pro (it also supports more than 8 arguments for erase-install because you can add multiple arguments in one Jamf Parameter field) (thanks to @cvgs).

Once it is a final release, I may give it another try to see if I can un-complicate my workflow some.  Thanks @Tribruin for the initial pointer to erase-install.