Is flushPolicyHistory part of Casper imaging now?

We actually had the FlushPolicyHistory.sh from the old Resource Kit in our workflow. From this conversation I am assuming it's no longer needed with the later releases of the JSS software?

Thanks Drew for the official answer.

This for policy flushing at machine re-imaging and we really like it.
I was using "jamf flushPolicyHistory" command in our PostImage script to manually flush the policies and I can remove that line now with confidence.

Thanks

@drew - as of what version?

I believe I tested and as of 8.64 it didn't flush without the jamf flushPolicyHistory command.

I have scoped 4 policies to recurring checkin using casper 9.24 and have run "sudo jamf policy" to watch them complete.

If I reboot the machine and reimage it again using casper imaging then log in and run the command again, it says "No policies found for the recurring checkin trigger". The policy logs on the JSS shows the policies I ran manually prior to imaging but no policies since imaging. If I flush the logs using the JSS and run "sudo jamf policy" again then it reruns the policies on the machine.

Based on that, for me at least, it isn't automatically flushing logs when reimaging. Is there something else I have to do or should I just shrug and put the "jamf flushpolicyhistory" command in a script for first run?

Hey nigelg,

After hearing about a few cases like this, and running into one or two of my own this afternoon, I tested it out in my own test environment and was able to reproduce the same behavior that you were seeing.

I have gone ahead and opened up a defect for the issue ( D-006509 ) as this is something that is supposed to happen automatically in 9.x.

As a workaround, we can set up a policy to run a jamf flushpolicyhistory after enrollment and that should do the trick.

I should note that, for certain policy triggers (startup, login, logout) I did need to restart, log out, or log out/login on my test machine to get the policies on those triggers to kick off after the policy that ran jamf flushpolicyhistory had finished.

Thanks!

Amanda Wulff
JAMF Software Support

@amanda.wulff as additional issue associated with this is the appearance of ghost machines with the same name getting added to the JSS when the machine is re-imaged.

Hi @jhbush1973 ,

As much as I dislike having to say the word 'defect', that's likely what we're hitting there as well.

We've got a couple of defects that were recently re-opened that could cause 'ghost' machines or duplicate skeleton records in the JSS.

D-004995 is currently listed as a status of Fixed: Planned for Release, so we should hopefully see that soon!

The behavior for that defect manifests as a reimaged computer having its full record and one skeleton/empty record left behind.

There is also D-005079, which is still open, but that one is specific to imaging with removable ethernet dongles.
In that one, we see the following behavior:
Two inventory records are created: 1) A shell inventory record that includes the computer name and both the removable MAC address and AirPort MAC address. 2) A full inventory record after enrollment that only includes the AirPort MAC address, as expected.

Workarounds for both are to delete the shell/skeleton records.
Using TMI for MacBook Airs instead of the ethernet dongles can also help avoid it.

The issue happens most frequently on 9.23 and 9.24.

Do either of these sound like what you’re seeing?

Either way, it may be a good idea to reach out to your Account Manager so we can get your issue documented and taken care of.

Thanks!

Amanda Wulff
JAMF Software Support

@amanda.wulff Hi Amanda, its been a while but do you know if either of these defects were resolved?

Hi @nigelg ,

When defects are resolved, they're always noted in the release notes for the version in which they've been resolved. The best way to find out if a defect has been resolved or not is to get into the habit of checking the release notes with every release; in addition to defects fixed, the release notes also make note of new features added, and make note of major known issues.

If you don't see it listed in the most recent release notes, it likely means that it's either still open or was fixed in a previous release (and is noted in that release's release notes). If you have further questions about a specific issue, please contact your TAM.

It is worth noting, however, that your TAM will not be able to provide information on specific timelines as to when an open defect will be fixed; they will simply be able to tell you if a particular issue is still open or if it's been closed.

Thanks!
Amanda

We are still seeing this in 9.82

When we re image a machine the old policies are not flushed.

There's a db setting that controls if policies are flushed or not. Your TAM should be able to help you adjust.

Also, I am pretty certain if you have the db set to flushpolicyhistory on reimage - your VNC logs (and maybe some other logs) go poof as well. For us, that's a deal breaker for using the flushpolicyhistory flag.

Luckily, a workaround for us is running quickadd at reimage which flushes policy history without touching VNC logs. I wish JAMF would separate out the VNC/policy logs like it was prior to 9.x.

Seeing this issue as well. On v9.82.

Good to know I have to adjust a setting in the db to force policy history flushing at imaging. But I wanted something more easily accessible.

A script that runs jamf flushpolicyhistory At Reboot doesn't work for some reason. It used to for a little while.
QuickAdd.pkg has never flushed for us.

Might try a Policy that runs jamf flushpolicyhistory at Enrollment since I don't do anything else at Enrollment.

This was our cure - ensure flush_management_history_on_remanage setting is at 1 on the enrollment_settings and client_check_in tables:

UPDATE enrollment_settings 
SET flush_management_history_on_remanage=1

UPDATE client_check_in 
SET flush_management_history_on_remanage=1

I was working with JAMF support this past week with the same issue, I referenced this post and they mentioned that they do not recommend changing the database settings like the post above.

I tried a policy that ran jamfflushpolicy history at enrollment and found the other enrollment packages did not run until a different trigger called them.

What I ended up getting to work was setting up a payload free package to run the script as part of imaging. This ended up triggering before the policy on_enrollment trigger was called so all policies started to come down as expected after the imaging reboot. I used [ www.modtitan.com/2016/06/getting-casper-imaging-splash-screen.html]( www.modtitan.com/2016/06/getting-casper-imaging-splash-screen.html) as a reference on how to setup the script/package, substituting the jamfhelper command with the jamf flushpolicyhistory