adam argyle

At first glance, my script jamfEvent.sh may seem too simple. It just calls a Jamf policy by a custom trigger. But this can be very useful in a few workflows.

event=$4
if [[ -z $event ]]; then
	read -p "Jamf Custom Trigger:" event
fi

jamf policy -event $event

I use this script to create Self Service policies that are scoped specifically to the required OS or department. They refer back to a policy that actually installs the software that is only triggered by the custom event. I can also create another policy to automatically install on newly DEP enrolled machines during their provisioning workflow. I can have multiple policies that refer back to the primary one. This means I only need to edit one policy if something changes in the installer, package name, or choices XML modifications.

I also use this to kickstart our DEP Provisioning workflow in Self Service because the enrollmentComplete trigger from Jamf can be unreliable. If the network connection is interrupted during the enrollment, it may never see the trigger. So when setting up a machine, if I don’t see the notice that it’s starting the process I can click it from Self Service.

If Jamf changed the way to call a custom event it also would mean only changing the primary script which just makes things slightly easier, as opposed to using the “Execute Command” feature located under Files and Processes in a Jamf Policy.