Enrolling with newly imaged machine if the machine is already in Casper

Are all of the same policies running in both scenarios? I am wondering if a "Run Once" policy will re-run when the system is re-enrolled if it has run in the past.

how are you imaging the machine? are you using Casper imaging? what version of Casper are you on? I believe in the latest version it does this for you but, in most of the older versions you need to run
jamf flushPolicyHistory
if the machine is already in the JSS

There are about 10 or 15 policies and they are all set to "Run Once". When I enroll the machine the second time, yes, it appears to run all of them again. Maybe it shouldn't? But as far as the JSS knows, those policies have already happened. Or do those logs get flushed when you re-enroll?

@nessts:

We are not using Casper Imaging. We use deploy studio with a quick add package.

Our infrastructure is similar, but we use a standalone JSS for imaging that is separate from our management JSS so it's essentially the same setup (we install the Quickadd package post-imaging). I haven't noticed any issues with policies after re-enrolling a system.

So you are only seeing issues with one application, if I am reading this correctly? And there is a policy that is related to that application?

So far the issue is only with one application. This application is Houdini by SideFX. When I enroll a new machine into Casper and then add it to a group that inherits many policies, then those policies run fine and the program opens as expected.

Then if I reimage that machine (via deploy studio), but leave the record in Casper, then I have issues. If I take that newly imaged machine and re-enroll. Casper takes the machine and starts running the policies again (not sure if this is expected behavior, but I don't mind it). However this time the Houdini program does not open as expected. Icons inside the program are missing and an error message comes up.

Seems like it would be installing everything the same way, right? So I don't understand the discrepancy in results.

You may be having an issue with timing. It sounds like you just need to troubleshoot that one policy and app, and maybe compare the jamf.log files to see the order in which the policies are being executed.

If you have two policies for that application (like an installation policy and a configuration policy) then the order is probably important.

I'll watch the logs more closely and see if I can find an issue. This specific application does not have a configuration policy in our JSS. It is just the application.

I had this same issue. Run this MySQL command from the MySQL command prompt..or use a GUI like Navicat.

update mac_os_x_enrollment set flush_management_history_on_remanage=0

this will tell the JSS to not flush the management history when a Mac re-enrolls

Adam-

Thanks for the advice. I probably wasn't very clear in my initial post. We don't mind that all policies run again on a re-enroll. In fact, in lots of cases this is desirable. Either way, we are okay with this functionality. The issue is that when we re-enroll a machine that was "wiped clean" and the policies run again, at least one of the applications installed the second time behaves unexpectedly. I have no idea why. Doesn't seem like Casper would run a policy differently on a re-enroll but perhaps it does?

Alex- I watched the order of the policies carefully and they run in the exact same order as the original enroll.

Thank you all for your help with this. I'll keep you posted if we find a solution. Something just came to my mind. Our JSS is currently 9.24, but I believe our quickadd package is still from 9.20. This doesn't seem to affect our original enroll, but perhaps it is affecting a re-enroll on a machine that the JSS knows to be 9.24?