Custom Event triggers?

[AVmcclint]

Can someone explain how to create and define a custom event trigger? I've looked through the admin guide and searched the jamfnation and I can't seem to find anything at all explaining how this works - other than the mention of iBeacons.

[cmarker]

So lets say you define a policy with the custom event called "bindtoAD" as the trigger.

On a client machine that is within the scope for that policy, you can then run:
sudo jamf policy -trigger bindtoAD

And the client will only execute that policy, instead of a regular policy check.

This becomes useful in custom scripts or if you want one policy to call another using the Execute Command field under "Files and Processes"

I'm sure there are all sorts of custom uses out there that are more creative, but that is the gist of them.

[davidacland]

Hi,

You can use them in scripts with sudo jamf policy -event customtriggername

So you put a word in for your custom trigger (whatever you want it to be) and then run the policy by that name in your scripts.

[nessts]

here is how I got it working, we had an application that people used for IP phone, it is free for non corporate users, and the company did not want to pay for a license for it, so the users that have it get it removed, as well as it being on the restricted software list I go out and delete it if it exists. So I have two policies one that checks for the existence of the app and one that removes it. The check for policy runs once a day and if it finds the app it calls the remove policy, I do this via the Execute command on the Files and Processes section with this command:

if [ -d /Applications/X-Lite.app ]; then jamf policy -event rmXlite; fi

Then the remove policy is defined on the General page as ongonig and Custom is checked and it has

rmXlite

in that box. Of course this could have been done hundreds of ways, but it was mainly an exercise on how to call a custom event for me. It is the only custom event I have ever created in 5 years, but I have ideas for others now and time permitting I may add some.

[davidacland]

We use them quite often in first boot scripts to get things setup. Saves a load of code!

[Josh_Smith]

To add to the responses above, here is where you define your custom trigger in a policy:

To run that policy you would run:

sudo jam policy -event installChrome

(not case sensitive in my experience)

With Custom Triggers you can run a policy as part of another policy or as part of your imaging process. I use Payload Free packages to trigger policies when I need something to run in a particular order or check for prerequisites in my imaging configurations and patching policies.

Please note that Scope and Frequency still apply to policies when using custom triggers....you are just telling it when to start, not overriding who or how often.

[AVmcclint]

So they aren't really "events" in the same respect as Login, Logout, Enrollment, etc. It's more of a tag that lets you specify that one policy out of the multitude of other policies you may have setup. I don't really see any advantage to calling it a custom event. Why not just enable jamf policy to run a specified policy by name instead of this "tag"? Seems superfluous to me. When I see the name "Custom Event" it makes me think of "run this policy on Tuesday mornings after the logged in user launches xx.app" or "run this policy every 4th reboot" or "run this policy after Firefox autoupdates". THOSE are events.

[Look]

@AVmcclint You can have multiple jobs with the same trigger and call them all simultaneously.
These can then be scoped based on other factors such as OS or Hardware so exact makeup of policies can vary from machine to machine.
Far more flexible than having to work out which policies you want and call them individually by name or number.
Also if you completely replace one policy with another you just use the same trigger you referrenced ealier without having to change whatever calls the policy.

[Josh_Smith]

@AVmcclint - I see what you are saying, but try looking at it from the JSS's point of view. The communication is all initiated by the client to tell the JSS what is going on. The built-in event triggers have corresponding mechanisms (LaunchDaemons) on the client that tell the JSS "Hey this Mac logged in/out/booted/etc, do you have any policies for me to run because of that event?"

With custom triggers you have that same capability, but you have to create a mechanism so the Mac can tell the JSS what is going on. You would need to write a launchdaemon/script that runs on the Mac to tell it to monitor itself for the 4th reboot or a Firefox AutoUpdate, and when that event occurs your script would send your custom trigger to the JSS to see if there are any policies it needs to run for that event (trigger) at this time (frequency) for this machine (scope).

[AVmcclint]

OK. I think I understand it now. I've done a few tests and I see how that function can be useful. But calling them "custom events" is still a bit misleading.

[msample]

In the case where you want a policy to kickoff much faster so that you can see the results immediately following a user who has logged in, is there a special command that can help?

[davidacland]

@msample if you want a policy to run when a user logs in you're best bet would be to use a login trigger (unless I mis-understood the question :)