It sounds like you need an immediate inventory collection to happen post reboot. I can't be sure, but it seems maybe the problem is after the upgrade the machine still shows as running the previous OS build (in Jamf Pro, not locally) and therefore doesn't drop out of whatever Smart Group you have built to capture machines that should get the pop-up/upgrade process. I'm guessing this because you stated you have policies to "install the 10.15.7 upgrade on systems that are on <10.15", which sounds like that would be a Smart Group.

Stop me here if that doesn't sound like what's happening though. I don't have a super clear idea of your setup, including Smart Groups and scope, etc.

But if this does sound like part of the problem, then you might want to consider an approach I put together that uses a pre-installed LaunchDaemon and a command run at the end of your policy that will cause the machine to collect inventory right after a restart. This should in theory prevent your policy from kicking in again after the machine reboots, since if the scope of the policy is to only run on devices in your Smart Group and it's no longer in the Smart Group, then it doesn't run.

You can find the process I put together here:
https://github.com/mm2270/JamfProScripts#post_restart_recon_controlsh
or
https://github.com/mm2270/JamfProScripts/blob/master/post_restart_recon_control.sh
for a direct link to the script itself.

Take a look and see if you think it might help. And to be fair, there are other approaches to take here, such as ensuring that the policy itself completes and uploads a log to Jamf Pro before it reboots the Mac. So what I've outlined is only one option.

@mm2270 I will give that a shot. However, the policy is set to run on systems with the Mac OS installer cached. After the initial install, I have checking in /Library/Application Support/Jamf/Waiting Room and the .pkg is no longer cached, so the devices should fall out of scope. I guess if inventory is not updating, then the policy still thinks they are in scope. The strange thing is, one of the computers, installed the update, policy log marked as complete, and it removed from the group. Yet the update continues to loop.

I will give it a shot with the inventory update. Thank you for the info.

@mm2270 I'm looking to attempt the script you created. Could you provide me a little more info on deploying the script? I see it stating not to change anything in the script, however do I need to adjust the y0urOrg parameter? also, just to clarify, this script should be run as it's own policy, and then the execute command run during the OS install policy?

Thank you for all the help, I appreciate it

Hi @ryan.adams_Sema4 So yeah, basically the script I pointed you to creates all the necessary pieces for the process to work, meaning it ends up making the LaunchDaemon and the script the Daemon is pointed to. The only items you generally would want to change in that main script is that yourOrg parameter, which you would set to a short name of some kind for your organization, and the maxAttempts, which should be an integer. The maxAttempts determines how many times the script called by the LaunchDaemon will try to connect to your Jamf Pro server after reboot before giving up if it can't make a successful connection. This is done because the network stack isn't available as soon as other processes, especially if your Macs connect to a Wi-Fi connection that is only available to logged in users, and not at the login window. So it tries up to a certain amount of times to connect to Jamf Pro, and if successful, then performs the inventory collection. If it can't make a successful connection after the maximum tries, it exits. This is so it doesn't get caught in an endless loop of trying to reach the server.

So once you've added that script into a policy, run it using whatever trigger you may want, such as recurring check-in, the one I recommend. It should only run once, since this is just laying the pieces down. On the next reboot after the policy has run on it, the Mac will collect inventory automatically since the plist file that determines if the recon should happen or not isn't present on the system yet. If it doesn't find it, it will run a recon by default and then flip the setting in the newly created plist to false On any subsequent reboots inventory won't be collected.
To activate the inventory collection post reboot you would want to add something to your policy in the Execute Command field that reboots the Macs, such as upgrading the OS or installing reboot required updates. See the script for an example of what to add there to flip the setting back to true in the plist. The LaunchDaemon will run the script which will see that the setting is now at true and do what it needs to do to collect inventory again. It then repeats the process of flipping the setting back to false so it won't run again until called upon.

Hopefully that all makes sense. Let me know if you need any other help with it. If it works for you, let me know.

@mm2270 Thank you so much for the detailed explanation. I've setup as you described, although I added the first script to the policy caching the OS installer .pkg so that it is already on the computer before the install policy begins. I hope that won't mess with anything, but if it does I can have it run as a stand alone policy. I have the Execute command field set to
/Applications/InstallCatalina.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps && /usr/bin/defaults write /Library/Preferences/com.sema4.postrestart.reconcontrol.plist PerformRecon -bool TRUE
since I need to run the startosinstall command. I will see how this works, or if you see anything that I've done incorrectly.

Again, thanks so much for the help!

@mm2270 This did it, thank you!!

Great! Glad to hear that helped. Just out of curiosity though, is the policy still showing as "pending" even though it completed on the machine?

@mm2270 No the policy shows as complete in JSS, so all is looking good. Thanks again