Flushing Policies...

Hmm. I was under the impression Casper Imaging did the flush policies automatically, no? Are you using something other than Casper Imaging? If it isn't doing it, the command you need to run on the Mac at imaging time is

jamf flushPolicyHistory

This tells the JSS that all policies that previously ran on the Mac in question the script is running on need to be flushed so they can run again.
I would check in with your TAM if you're using Casper Imaging for your re-imaging and its not flushing the policies. I did think it did this on its own with no need to place it into a postrun script, but I may be wrong.

The answer @mm2270 gave is the most likely solution, but I have seen issues in the past with imaging computers that were already in the JSS. These issues ranged from policy logs not flushing to the reimaged computers not re-enrolling properly. At the time we had to delete the computer record from the JSS prior to imaging (I had a script to do this in my imaging config), and that resolved all of the issues. This was several JSS versions back, however, and I haven't seen these issues on more recent versions.

If you're not using Casper Imaging, check the QuickAdd package. Try creating a fresh one from the lastest Recon version you have.

None of my policies automatically flushed when I reimaged last using Casper 9.82 and I was advised a JAMF trainer that it isn't automatic. I would test using the flush policy command as a policy to run after enrolment.

Thanks all,

We are using Casper imaging along with NetBoot. We can image without any issues so that part is working.

What seems to be happening is, when the computer is re-enrolled into the JSS, it appears the run once policies aren't being flushed and the JSS retains the record as already being run, so it doesn't run again.

If I remove the computer from the JSS, it works every time.

I will check with JAMF Support and ask them what might be happening. In my testing, I have to flush all in order for the computer to pick up the policy and run them again. What is even more curious, if I don't remove the test system from the JSS and I image it, the computer is re-enrolling but it is not checking in again. Strange to be sure.

Removing from the JSS prior to imaging is working every time.

Mick

Just in case you don't already have this, here's the script I used to delete computer records when imaging.

#!/bin/sh
SERIAL=$(system_profiler SPHardwareDataType | grep 'Serial Number (system)' | awk '{print $NF}')
curl -ksu user:pass "https://jss.url:8443/JSSResource/computers/serialnumber/$SERIAL" -X DELETE

Thank you @bburdeaux I will look at this soon. I am hopeful this will be the magic bullet to get this working!!

Be advised that jamf flushPolicyHistory flushes VNC logs too - if you want those to stay in place, but you want to flush policy logs, add a quickadd package to your image workflow. Make the quickadd install on boot device with priority 1.

As @mm2270 suggested, we have been using the same method for a while now.
I just added that command as a script in the JSS and attach it to all my configurations that need it. That way, they (the configs that need it) always start fresh.

Additionally, I have seen and heard from TAMs that Casper Imaging does not re-enroll a computer all the time. I don't have parameters for this, such as if it was enrolled in the past x days, etc. I don't have any evidence like that.

But what I do know, is I was testing the 9.97.1488392992 hotfix and we were having script issues during imaging. With the TAMs direction, took those scrips out of the config and put them as "On-Enrollment" policies. Worked great the first time but not for subsequent re-imaging. TAM stating Casper Imaging was "re-managing" those computers but not "re-enrolling".

At that point, we punted back to 9.97.1482356336 and have held there for now.

Thank you Everyone for you thoughts and responses here.

I think for ease of use and training, we are going to remove the computers from the JSS and AD before imaging. I am currently working on a process to run a policy via self service that will remove the computer from AD, remove the firmware password and remove the computer from the JSS.

Then when imaging, we are going to have smart groups set up to automatically deploy the correct packages to the computers based on the computer name. In testing, this should work well. Once the computer shows up in the JSS with the correct name, the computer will get all of the applications, printers and so forth.

Thanks again!!

@mconners Just one more thing before heading down that route, you will lose any purchase/warranty information if you have that in your jss.
Might not be a big deal if you don't, but did want to make you aware of that.
Of course, if you have GSX setup, that won't matter either as it should pull it all back in.

Thank you @jrippy for this. Curiously, we do have GSX setup, however, the connection is failing to work with Apple. Our GSX portal is working directly with Apple, but the connection from the JSS to GSX stopped working. I have been trying to work with Apple and JAMF support, but it is failing to work no matter what we do.

Interestingly, the "test" function is working via the JSS. When we attempt to pull in records, we get a message saying no serial numbers found. JAMF is stumped and so is Apple's GSX support person. I am hopeful this will be resolved before summer when we start our imaging process.

@mconners I was about to say something similar to @jrippy Personally I would not delete Macs from my JSS unless they were truly decommissioned and were never going to be used again. If they are active systems, my preference would be to simply flush the policy logs and leave the Mac history and other data intact in my JSS. It's entirely up to you of course, but you should be aware you may lose some data about those Macs that you might look for later and it won't be there if you delete and re-enroll them as new systems.

One last thing. Macs in Static Groups remain in Static Groups when they are re-imaged and the record kept in the JSS, because the JSS sees them as the same Mac (based on hardware UUID) So they get placed back in the same Static Groups. Deleting them removes them from those groups. Just something to keep in mind. It could be either desirable to have them drop from those groups, or not.

Thanks @mm2270 this is a very good point. The only reason I even considered the removal of the computer was because the policies weren't re-running as expected. I am trying to find a tried and true record that would work every time.

I am going to work more on the "flushing of policies" piece before I end up down the removal path. As has been pointed out, losing the computer record could have more drawbacks that I haven't considered. If I can get the policies to work, then I might be okay. Thanks again!!

Just checking back in @mm2270. After some brief testing, I have created a new quick add package added to the casper image sequence to install at reboot time and added the flush policy log to run AFTER installing the OS and at reboot, two different trials. Either way, the policies are not being flushed.

I have asked JAMF Support to weigh in on this one. Over the past couple of years, this has been my experience too. The policy logs will not flush and thus, a re-imaged Mac will not reinstall the policies. I have to manually flush the logs via the JSS as the command apparently does nothing, at least in the context I am using.

Am I missing something? I would really like to keep the computer records as you have pointed out. But if I cannot flush the policies easily, then I have to do something different.

@CasperSally Forgive me for missing the leap in logic... but i don't see how a quick add package helps in this situation? I checked and there is no setting in Recon QuickAdd for flushing policies. What am i missing?

I am not sure either @Kyuubi but I did add the quick add package to our imaging process and added the flush policy script as well. I have both of them set to run at reboot. These two things together did result in a successful flush of the policies, not sure how, but it did work. More testing will be done to ensure it is consistent.

At this point, all we have in our image is the OS, two local accounts created by CreateUserPkg and at reboot, we have the quick add package and the script to flush the policies. These things together resulted in a new OS being installed with local accounts and a flushing of the policies. This allowed the existing policies to this system to be re-run after imaging. Precisely what I am looking for.

I am optimistic this will all work now.

@mconners Are you sure the jamf flushPolicyHistory command is being run after the QuickAdd package gets installed and the Mac successfully enrolled?

If you're sure it's running after being enrolled and it's not working, I guess you'll need to see what Jamf Support says on it. It should work. I can't say I've run that command anytime recently on a Mac though, so I don't know if it's broken or not.

@mconners Are you on 9.97.1488392992? If so, scripts during imaging are broken. That's why I had to go back to the previous hotfix.
Jamf, or at least the support person I talked to, is aware of this. He thinks it is probably related to the specific issue they were trying to fix.
Their workaround was to try to do the script in a policy on "Enrollment Complete".
Then I had issues with that, but as you are doing, adding in a Quick-Add pkg should take care of that.

We are on 9.97.1488392992 @jrippy. I have the quick add package and flush policy script set to run at reboot. Checking the log file, I am not seeing evidence the flush policy piece is running. More testing is needed for sure.

I really wish this just worked when imaging a system. I am not seeing evidence this is the case without a little prodding.

So.... this is a defect in the 9.97.1488392992 release then it sounds like? Where scripts in CI configs are not being run?

To be honest @mm2270 I am not sure about the defect state though. I am can tell you if I don't have the flush policy script in Casper Imaging and set to run at reboot, the policies are not being flushed. I tried with only the quick add set to install at reboot and this didn't flush the policies. Having set the flush policy script to run at reboot and having it part of CI, it ran and the policies flushed as expected.

Whether or not there is a defect at play here, I cannot tell. I am not attempting to run at imaging time, only at reboot and it is working.

While I don't have the PI number, @mconners @mm2270 I can confirm there is a defect with all scripts when used with Casper Imaging regardless of when the scripts actually run (imaging time vs reboot).
@mconners Your option would probably be to do what they told me, have the flush policy script run on enrollment complete as a policy. That should run immediately after the Quick-Add runs assuming it actually enrolls properly.

That will also immediately reset the flush policies policy but as the trigger is enrollment complete, that shouldn't create an unwanted loop. It should be ready the next time you re-image.

You are correct @jrippy. In emailing support, I was informed of the following, Casper Imaging Unable to Download Scripts via Automatic PreStage Imaging. This is noted as PI-003666. They suggested I do what you suggested, set to run the policy at enrollment. However, in my testing, if I have the flush policy script set to run at reboot it is working.

So now, I am a little confused.

Could there be a difference between Prestage Imaging versus Casper Imaging via netboot?

All I am doing is running Casper Imaging via netboot. If I throw in the script during imaging and set to run at reboot, it works. If I remove it, the policies don't flush.

@Kyuubi - I needed a solution to flush policy logs without touching VNC logs, and quickadd is what jamf told me to do. It also solved some issues we had with computers with saved autorun data.