Re-imaged computers don't re-run Patch Policies

Hey Jason
In the settings, under Global Management -> Re-enrollment, is Clear policy logs on computers enabled?

Short term you can go to those computers, >history>Policy logs and flush all logs. Long term you would want to move away from using "Once Per Computer" Policies for standard softwares. https://www.jamf.com/resources/videos/moving-beyond-once-per-computer-workflows/

I am not personally a fan of having clear policy logs enabled on the re-enrollment level, because it can cause unwanted behavior should you ever have to re-enroll a machine that is currently in use.

What I have done is added the command

/usr/local/jamf/bin.jamf flushPolicyHistory

to my Erase macOS and re-install macOS scripts that I have. I also include API calls to make sure the computer is unmanaged in the JSS/JPS so that I am not paying for licenses on machines that are blank.

In the settings, under Global Management -> Re-enrollment, is Clear policy logs on computers enabled?

Yes it is. I assumed this is only for normal Policies, and not Patch Policies, since the latter can't be cleared in the console.

Short term you can go to those computers, >history>Policy logs and flush all logs. Long term you would want to move away from using "Once Per Computer" Policies for standard softwares.

I think you're talking about normal Policies, not Patch Policies. There's no flush logs or trigger for Patch Policies.

What I have done is added the command /usr/local/jamf/bin.jamf flushPolicyHistory

@sdamiano Thanks. Can you confirm that this flushes Patch Policies even though there's no "flush" in the console for them?

If the machines are being wiped and re-deployed, why not just delete them from Jamf and let them re-enroll with a completely fresh history?

@echave If your using DEP, then technically a user could concievably internet restore and automatically re-enroll themselves (in fact this might even be the preferred method in the case of total OS failure offsite). I doubt there is a way to include a delete prior to removal in this scenario so you have to account for re-imaged machines coming back into the system somehow.
We used a scripted solution as per @sdamiano for ours, you generally going to have some kind of first run happening so it's pretty easy to drop in there. It is worth noting if you have a large database or a device with a large amount of logging it can take sometime so it needs to be followed by a short delay before attempting to check for any further policies.