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 erasing or upgrading macOS in a single process. (github.com)

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

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.

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?

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.

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. 

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.