Re-imaged MacBook do not receive Enrollment Policies

[skeb1ns]

Hi all,

I have a strange issue regarding reimaging of an existing Mac that is present in the Casper database. What I normally do is that I delete the machine from the database so that Casper doesn't know it already exists and then image it so that the enrollment policies run after the initial Imaging process is complete (my triggers are based on a Smart Group that checks the date that the machine is imaged on).

However since a week or so when I image an existing Mac (my last attempt was last week when a failed Yosemite upgrade needed a fresh install) the enrollment policies are never triggered. The machine gets Imaged, reboots, shows up in Casper, gets his Configuration Profiles and I see a pending entry in all the enrollment policies that should be executed next but this never happens. (I do have a working network connection.)

Manually triggering the policies in terminal with the jamf -policy -event -enrollmentComplete command results in "no policies where found for the enrollmentComplete trigger". The funny thing is, when I install the QuickAdd package on this machine, the policies are getting executed fine and all my applications and other settings are installed.

What could be the issue? I'm thinking it's a database thing since this behaviour does not occur on MacBooks that are Imaged fresh out of the box.

I'm running Casper 9.65 btw, should an upgrade to a higher version (perhaps 9.8 for that matter) fix this?

Thanks in advance!

Regards,

Rob

[mhrono]

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.

[McAwesome]

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.

[GabeShack]

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

[kitzy]

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!

[CasperSally]

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.

[rdwhitt]

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?

[CasperSally]

@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.

[skeb1ns]

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. :(

[rdwhitt]

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

[skeb1ns · Accepted solution]

Fixed!, turned out that not all of the policies had the restart option @ no user logged in action set to restart immediately.

[pmcgurn]

@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.

[skeb1ns]

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.