Posted on
06-22-2018
07:35 AM
- last edited on
03-04-2025
06:56 AM
by
kh-richa_mig
Part of our imaging workflow has included running the jamfhelper on reboot so that the screen is locked as all of the applications are installed on the enrollment complete check-in. At the end of the policies running, the machine would reboot effectively closing the jamfhelper, so it would give the indication that the computer was finished. Nice and smooth.
Since we've upgraded to 10.4.1 we've noticed that policies are now running twice. Looks like the reoccurring check in policy is running in the middle of the enrollment complete, and any policy that hasn't finished is now running twice, causing some errors. These policies are all set to run on both reoccurring check on and enrollment complete.
Has anyone else seen similar?
Support suggested to modify the policies so they were reoccurring check in only and not both. If I could get the computer to not reboot after finishing enrollment complete, that would add a 15minute delay to the imaging, so not optimal.
I was thinking I could lengthen the check-in timeframe, but not sure if I would like that for long term.
My last thought was to modify most policies and then make the very last one trigger the reoccurring checkin. That might give the experience I'm looking for.
I'd gladly take any other suggestions for work around.
Posted on 06-22-2018 09:16 AM
I like custom triggers since that gives you control over when they run.
Posted on 06-25-2018 11:54 AM
This is what jamf recommend to me a few years back and we still use it today
Sudo launchctl unload /Library/LaunchDaemons/com.jamfsoftware.task.1.plist
Sudo launchctl load /Library/LaunchDaemons/com.jamfsoftware.task.1.plist
It's tricky depending on your process two scripts one runs before everything
script 1
Sudo launchctl unload /Library/LaunchDaemons/com.jamfsoftware.task.1.plist
and
Sudo launchctl load /Library/LaunchDaemons/com.jamfsoftware.task.1.plist
is the last line before your reboot....
Hope this helps
C