Re-imaged MacBook do not receive Enrollment Policies

I've also encountered this issue every time I image a machine that's already been enrolled. I'm not entirely sure what causes this, but you can rectify it without having to delete the machine's inventory record. Instead, open a terminal and do:

sudo jamf enroll -prompt

This will ask you for your JSS credentials, and credentials for the local management account. It will refresh the machine's certificate with the JSS and re-enroll, then check for policies triggered by enrollment.

What execution frequency are the policies set on? If they are set on "Once per machine", casper will only run it once per machine. You'll have to flush that machine from the log before re-enrolling it.

Been seeing this as well....looks like the enrollment script is corrupted and never gets created properly. Not sure why though. What versions are everybody using?
Im on 9.73 of Casper Imaging and running a 10.10.5 netboot image.

Gabe Shackney
Princeton Public Schools

The default behavior for the JSS is to retain the policy history on re-enrollment, thus causing any "Once Per Computer" policies to not run, as the JSS has a log of them running once already.

The easiest way to change this to get the behavior that you want is to work an at reboot script into your imaging workflow that runs

jamf flushPolicyHistory
jamf policy -event -enrollmentComplete

This will remove the existing policy logs, then call anything set to be triggered by Enrollment Complete.

Hope that helps!

On reimage, our policies are flushed automatically (we don't use enrollment trigger), probably because we have to run a quickadd package for our imaging to work properly.

You might want to try adding that into your imaging workflow (set it to run on boot drive in casper admin). I suspect it would then run your enrollment trigger policies as well.

As @kitzy mentioned, we used to use a reboot script in our imaging configuration with the flushPolicyHistory command, but that hasn't worked for us for several versions (9.72 currently).

If re-imaging an existing computer that does NOT use autorun data:
The computer will re-enroll and run a policy with the "flushPolicyHistory" command set to "enrollment complete".

If re-imaging an existing computer that DOES use autorun data:
The computer does not re-enroll and enrollment triggers do not fire. As @CasperSally mentioned, using a quickadd package in your configuration with "install on boot drive after imaging" selected will re-enroll the device and enrollment triggers will fire. Of course this means you'll also boot to the temporary adobe account and the JAMF lock screen...I haven't tried this in awhile, but when we were on 9.3x it would sit logged into the temporary Adobe account for hours which was just not acceptable. Maybe this works better now?

I'm still not sure why imaging a computer that has autorun data means that a device won't re-enroll. I've been told by JAMF that this is by design, but if I'm re-imaging a computer, especially with autorun data, why wouldn't I want it to re-run all of my once per computer policies?

@rdwhitt yea hours isn't right. I've had to do this for a year or 2 now. If I didn't have other software running it would only be a few minutes.

I have a post image script that runs first and enables ethernet adapter, then another script that waits for enrollment to complete before allowing my other post image scripts to run (including installing a bunch of software) and it's in the temp account max 10 minutes.

You should work with JAMF to do some logging of what's taking hours.

JAMF promises my days of having to run a quickadd for enrollment to work properly with autorun data are numbered, but we'll see.

flushing the policy logs doesn't make a difference unfortunately. This results in the same behavior: Machine gets imaged, shows up, pending policies. Dead silence....

Checked the logfiles, nothing. :(

@rschenk Do you have autorun data set for this machine in Casper?

@rschenk Can you elaborate on that, or provide a screenshot of your working policies for Enrollment Complete trigger? We're hitting the same issue.

I have mine set to trigger on enrollment complete, frequency ongoing, and also allow the user to trigger via Self Services since they are failing.

Here is an example of our Printer policy that runs after enrollment. I've set the reboot option @ No User Logged In Action to Restart immediately. This is the same for my other Enrollment Policies and it works for me.