Custom Trigger creation question

@tcandela I typically apply printer drivers for my Xerox printers to all machines during imaging, regardless of whether they are going to need it or not. In the grand scheme of things, you're only talking a few hundred MB of data on the machine, and does that really amount to much anyway?

As far as how you can trigger the driver to install during a policy, since you want the driver to install before the printer, you would be better off using a script. Although a simple script to call the policy would suffice, you could put a little logic into the script so that it doesn't attempt to load the driver at all.

If the driver policy is set to a frequency of "Once per computer", each subsequent run of the driver policy will amount to "No policy found" during the script run, thus meaning the script to install the driver will not run and will not re-install the driver. Instead the printer policy will continue on with installing the printer.

usher.br --- I'm assuming the script that will call the custom event trigger would be easy, I am not a scripting pro, would it be just this?

#!/bin/bash
jamf policy -event TESTXeroxDriverCustomTrigger

so when I add this script to the second policy that adds the printer, set the script to 'BEFORE' and it will do the custom event THEN comeback and install the printer?

stevewood -- valid points. I'm also looking to learn how to use/create custom triggers.

@tcandela Yes, that would be it.

awesome, going to test very soon, thanks
i
t automatically gets run as root ? no need for 'sudo'

Correct

The above suggestions will work and you could go either way (script vs execute command) really.

Another approach that you may find interesting is writing a dummy receipt upon successfully installing the printer (touch /Library/Application Support/JAMF/Receipts/ihavebeentouched.pkg). The advantage here is that this will create a readable value within the JSS that you can manipulate and place computers in smart groups or write extension attributes. This will give you management capabilities beyond only running policies.

There are numerous threads in JAMFNation where people discuss using dummy receipts and some people have done really clever stuff.

Hope this helps.

You also do not have to put a trigger name in the "custom" field of the policy. Policies can be executed in one of three ways:

1. By setting a trigger such as "Check In", "Enrollment", "Login", etc.

2. By setting a custom trigger after checking "Custom".

3. By using the policy ID found in the URL of the policy.

A script can have method 1 or method 2 selected, and still be triggered by its ID.

As @yan1212 mentioned, you can use a dummy receipt, or an Extension Attribute, to further scope your policies. In the case of a dummy receipt, touching a file in the JAMF receipts folder, as he mentioned, you can then use the "Packages Installed By Casper" criteria in a Smart Group search. If you use an Extension Attribute, you simply use the Extension Attribute name and value in the Smart Group search.

There are plenty of posts about both of those methods.

I forgot to mention the methods for calling the custom trigger and the policy id via a script, just in case you need it:

- to call a custom trigger: jamf policy -trigger <triggername>

- to call via the policy ID: jamf policy -id <id#>

good to know also: could go either way (script vs execute command) really.

While I recommend installing driver first then add printer, I've noticed that OS X doesn't care which order they happen in. So your initial idea of add printer then use Execute Command to start the policy to install the driver is perfectly fine, as the added printer will recognise the driver once available.

With the install policy being called from the add printer policy, Self Service will show the policy still executing until the drivers are installed (if needed).