Upgrade macOS Policy Keeps Repeating

[AHSitguy]

Hi,
I have a policy that deploys the macOS Catalina installer to /private/var and that uses the Files and Processes module to run startosinstall. I have the policy scoped to one computer right now and set to run once per computer. The mac will download and run the macOS upgrade, but the policy never says completed in Jamf. As a result, the policy keeps repeating itself on the already upgraded mac. The mac will get to the login screen, but then it will reinstall macOS Catalina once I log into the mac.

[Devyn_Lowry]

We are also having this problem, did you find a solution to this?

[john_sherrod]

@lowryd What's the trigger on your policy?

[Devyn_Lowry]

@john.sherrod recurring check in, we used the same method of Mojave last year however didn't encounter this problem.

[larry_barrett]

Change your Scope.

You want two groups:
Catalina
Mojave

You scope it to Mojave group, Exclude it from Catalina group.

Obviously this is over simplified and just one example of how you can handle it. Recurring doesn't really make sense, I'd go once per computer per day and make it available in Self Service

[Devyn_Lowry]

@larry_barrett Oh no no Im saying the policy we're using for Catalina is based off the one we used last year for Mojave, the Catalina policy is currently only scoped to one test machine

[john_sherrod]

@lowryd Interesting. We're doing our Catalina upgrades via Self Service. Would that be an option for your environment?

[Devyn_Lowry]

@john.sherrod Sadly its not as we need to upgrade multiple labs across multiple campuses across the state during non-business hours.

[bramstedtb]

@lowryd This has happened to me when the Jamf logs weren't able to upload before the computer rebooted. The two things I've done in the past are adding an "&" at the end of the startosinstall command. This has the upgrade start in the background and will make sure the policy completes before the computer reboots. I've also had a policy that runs at startup to update inventory. That policy should force the computer to upload the log file to Jamf.

What I do now is that I have my actual upgrade policy triggered to a custom trigger, and then my recurring check-in policy updates inventory, and then runs the custom trigger. Both are scoped to exclude Macs running Catalina. Once the inventory update happens, the Mac falls out of scope of the upgrade policy, and the trigger exits without running the policy.

[alexjdale]

Yeah, this is what happens when a policy can't upload its results to the JSS when it completes (or it never technically completes because of a restart or similar action).

For these situations, a control script would be my preferred solution, to run pre-flight checks before executing the upgrade. In this case, it would simply detect that the system had been upgraded already and exit out. This would close the policy loop and flag it as completed so it wouldn't run again.

[talkingmoose]

In addition to an upgrade policy where the macOS version may change, clone your existing Update Inventory policy to make a new one and set it to Ongoing using the Startup trigger. This will take inventory every time your computer restarts (including restarts made by upgrades).

[AHSitguy · Accepted solution]

I finally got the upgrade to work by using two policies. One policy copies the Catalina installer to the computers and the policy is scoped to a smart group of all computers < 10.15. Then I have a second policy that triggers the startosinstall --agreetolicense command and the policy is scoped to a smart group of all computers that has the Catalina installer cached.

[FleetBeat_AMART]

@bramstedtb tell me more about the '&' call after the --startosinstall. Maybe I can set a Trigger for Update inventory at Login?

[bramstedtb]

@WooSheeAllyn Adding the '&' at the end of a command has that command run in the background. From the policies point of view, it runs the command, and then finishes before the command has actually finished running. This lets the Mac submit the policy log to Jamf before rebooting.

Like I said in my previous post, this is how I used to do upgrade policies. Now I actually use two policies. Policy 1 is the upgrade policy, it's scoped to the computers that need the upgrade with a custom trigger of say 'runUpgrade', and is set to ongoing. Policy 2 is scoped to the same group, uses recurring check-in (Or whatever trigger you want to update with), and is set to ongoing as well. All this policy has is the following command in the execute command payload: 'jamf recon; sleep 5; jamf policy -event runUpgrade'. This will require an inventory update before attempting to run the OS upgrade. If the OS has been updated, then the computer will fall out of scope of the upgrade policy before it is triggered.