Big Sur to Monterey Upgrade

[MPL]

So our organization is looking to have all users upgraded from Big Sur to Monterey. All machines in our organization are standard users, NOT administrators (minus IT of course). 

I've been trying out different methods and landed upon the erase-install by grahampugh.

While this is *almost* perfect for the upgrade, the policy in JAMF never completes and always stays in "Pending".

- The issue with staying in Pending is, while testing, the machines upgraded to Monterey successfully, but then the update runs AGAIN.

We want to first have users manually install it via a policy in Self Service and then force push it to machines after xx amount of time (say a week after avail in Self Service). 

Is there any possible way to get the erase-install policy to show as completed in JAMF OR is there another way to get machines upgraded to Monterey seamlessly? 

[awoodbury]

I scoped the Monterey upgrade Self Service Policy to a Smart Group that captures all Big Sir computers and added an Exception to the Scope of that Policy that captures Monterey computers after they have been upgraded so that they are then Excluded from the Policy.

[MPL]

Yeah that's something that's already been done on my end but when pushed via check-in, the installers runs, installs Monterey, then once the machine is finished upgrading, since the status is still "Pending" in JAMF, it will run again despite just being upgraded to Monterey.

[sdagley · Accepted solution]

@MPL Create a policy triggered on login that will do a recon so that the newly install OS is recognized.

As an alternative if you don't necessarily want your Macs reporting inventory on every login you could deploy a LaunchDaemon that runs a script on every startup to check if the current build version of macOS matches what was running the last time the Mac started up, and if it is not trigger a jamf recon (and save the new build version). This is the approach I take, and it ensures that both intermediate macOS updates as well as full version upgrades are logged ASAP.

[jcarr]

If the erase-install process IS working as expected, one option might be to install a package that lays down a launchd to update inventory after the system reboots.

You'll need a script...

#!/bin/sh

#	Wait for active connection to Jamf Pro and then update inventory.

while [[ -z  $(/usr/local/bin/jamf checkJSSConnection | grep "Jamf Pro is available") ]]; do
	sleep 5
done

/usr/local/bin/jamf recon

rm /Library/LaunchDaemons/org.myschool.updateInventory.plist
rm $0

exit 0

and the launchd to run it after reboot...

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	<dict>
		<key>Label</key>
		<string>org.myschool.updateInventory</string>
		<key>Program</key>
		<string>/usr/local/bin/updateInventory.sh</string>
		<key>RunAtLoad</key>
		<true/>
	</dict>
</plist>

Once inventory updates, your devices should fall out of scope for the Monterey upgrade (presuming you're excluding devices already on Monterey from the policy).  This doesn't fix the issue of the policy not showing as completed, but perhaps that has something do do with how you are triggering it?

The way I've done it is a single policy that installs the "erase-install-depnotify-26.0.pkg" and my "ReconAfterBoot.pkg" and then uses the Files and Processes payload to run the following command:

/Library/Management/erase-install/erase-install.sh --reinstall --os=12 --update --min-drive-space=35 --current-user --check-power --no-fs --depnotify --cleanup-after-use

[mm2270]

This is the process I created for addressing this issue:

https://github.com/mm2270/JamfProScripts/blob/master/post_restart_recon_control.sh

[jcarr]

Perfect. Looks like that script does essentially the same thing. Glad you have a solution.