custom event trigger

[ateazzie]

Hi, am looking for a way to trigger a custom event.
once Outlook is installed, the netsus policy should kick in
how would that look like?

appreciate any help
btw running jamfpro 10.8

thnx

[Hugonaut]

This cat can be skinned a thousand ways +1

off the cuff, easy way to handle this is to create 3 policies. 1st Policy for Outlook & 2nd Policy for Netsus. Set these policies to trigger via a custom event. for this example custom event triggernames will be Outlook & Netsus.

image example for outlook...

For the 3rd policy, create a script similar to the following & add it to the policy.

#!/bin/bash

jamf policy -event outlook

jamf policy -event netsus

then scope the policy and set whatever trigger / execution frequency you need. Hope this helps, always love seeing other workflows.

[mm2270]

I'm not sure if for something like this it would be necessary to create 3 policies. That will work, but you can probably get there with just 2. The main policy which will install the program you want - in your case, Outlook, (or is it the full Office suite?), call it "Policy A", and then a second policy that gets called by the custom trigger, call it "Policy B", which does the NetSUS stuff.

In the main Policy A you have the option of doing one of two things.

1. Add a command in the Execute Command field under the Files and Processes payload, that just does something like /usr/local/bin/jamf policy -event <customtrigger> to run Policy B.

2. You can create and add a script that does basically the same thing as above, but add it to Policy A and set it to run "After", which means it will fire after everything else in Policy A is done.

The above method is sometimes referred to as "chaining policies", since you are calling a second policy within the first one. There are some things to keep in mind about this though.

1. The machine you want to run the custom trigger Policy B on must be properly in scope to run it. Just adding a custom trigger to it does not negate the need to make sure the system sees that the policy can run on it when called, or it will not run at all. I usually get around this by keeping the custom trigger as the only "trigger" and setting it to Ongoing for execution frequency, and scoped to all machines. That works in a case where you know the only time this policy will get called is by it's custom event trigger and never any other way. If that doesn't work, then make sure to create the proper Smart Groups to ensure the machines will fall into scope for it to run.

2. Although many people might say that adding the command to call Policy B to the Execute Command field in Policy A is the easiest way to do this (technically it is), one important thing to keep in mind is that the command will run to execute Policy B, even if Policy A fails. There is no logic detection in place to only run if Policy A was successful. This is ALSO true with scripts, but with a full script you have a bit more leeway in putting some logic and detection into it and only calling Policy B if you see Policy A ran to successful completion. In your case, that could be as simple as seeing if Microsoft Outlook was installed into /Applications/ or something to that effect.

Hopefully that all helps get you where you want to go with this.

[ateazzie]

thnx guys, i'll have a look