Until recently I had been quiet happy strolling along with the built in triggers – login, startup, logout etc.. I was using these in combination with smart groups for package deployment or determining which computers needed to run a script. I would create a smart group for lets say all the computers that didn’t have a version of clickview installed, then set to install at startup.
I was asked recently about what I was doing with custom triggers.. the answer I wasn’t – I was quite happy with the builtin triggers.. then a few days another person asked me the same question.. OK it’s time to see what all the fuss is about. Let’s just say I implemented them pretty quickly.
I’ve created a custom trigger for a re-imaged computer. There are some applications that don’t package well – for example ones that generate files containing a unique identifier for the computer based on the MAC address. I was previously deploying these with smart groups for the computers that were missing the application.
Now I needed to do 2 things to have the application deployed on first boot:
- Create a script that calls my custom trigger (setting the script to run “At Reboot” in Casper Admin) and assign to the configuration in Capser Admin
- Using the web interface of my JSS create policies that are triggered by my custom trigger name
So part one is simple you need a script that is pretty much one line:
#!/bin/sh
jamf policy -trigger reimaged
A couple of points here, the jamf command with policy option needs to run as root, because we are running this as a first boot script it automatically runs as the root user. If say you were running the jamf policy command manually you should put sudo in front. It is also good practice to put the full path of the jamf command which I have left out of the example above.
The word reimaged is the name of our custom trigger, you can call this anything you like. You can also create as many custom triggers as you like.
Now that the freshly imaged computer is going to check in with the JSS to see what policies have the trigger reimaged, we just need to set reimaged as a trigger. This is really easy – When creating the policy in the general tab of your JSS Select Other for the “Triggered By” option, then when the text box opens up type the same trigger name as in your script in this example “reimaged”. For execution I select ongoing as we never know how often a computer will need to be reimaged.
Please share your custom trigger usage, I’d like to see what others are using them for.