Custom triggers and chaining them together

[seanjsgallagher]

I am looking to see if anyone has had experience like I am having using custom triggers and chaining policies together? When we enroll a machine the first policy is set for "At Enrollment" to start it. In the "Files and Processes" section of the policy we put "jamf policy -trigger policy2" in the "execute command" section to trigger the second policy. The second policy is set to custom trigger with the "policy2" and then in the In the "Files and Processes" section of this policy we put "jamf policy -trigger policy3" in the "execute command" section to trigger the third policy and then repeat it for all the policies we have.

This has worked well and typically takes 25 minutes to complete. Before this we would have those same policies all set to "recurring checking" and it would take about an hour so the time is a big improvement.

The only issue we see it that when the policies are chained together that way the "Submit log to the JSS" that runs after each policy does not execute until after all the policies have completed. This causes every log for each of the policies to have all of the log entries for each policy bundled together. It my testing if one policy fails it reports all the ponies chined with it as failed as well even if they succeeded.

Has anyone seen this or found away to make the policies submit their logs as they complete even if they are chained with custom triggers?

I have tried substituting the "jamf policy -trigger ..." in the execute command section with a script that runs after, and even put a sleep 60s in it but that did not work.

If anyone has any suggestions I would appreciate it.

Sean

[donmontalvo]

We usually use a single trigger and number the policy names. This way they run in order and each policiy submits it’s log upon completion.

[koalatee]

I would run a script that has all the triggers. Easier to substitute and make changes.

#!/bin/bash

jamf policy -event $trigger1
jamf policy -event $trigger2
etc...

You should also move to jamf policy -event $trigger rather than jamf policy -trigger $trigger (or so I've been told).

[easyedc]

@koalatee I've always done it the way the OP has, but I see the advantage of being able to edit/change easier with one policy kicked off by a script. Out of curiosity, can you expand on what you've been told about -event/-trigger?

[seanjsgallagher]

@donmontalvo Can you give me more information on how you are doing that? Also are the logs being submitted for each completed policy before the next one in the chain runs?

[mm2270]

Might be easier to have all your policy triggers in one parameter (assuming they don't exceed the total character limit) separated by a single space. Policy triggers themselves always need to be single words or strings, so they don't contain spaces. Then have the script loop over them.

#!/bin/bash

triggers=($4)

while read ID; do
    /usr/local/bin/jamf policy -event "$ID"
done < <(printf '%s
' "${triggers[@]}")

The only issue with the above, which could be worked around, is that they all need to be policy triggers. If you mix in policy IDs with triggers, you'll get some problems. That could be fixed though.

[koalatee]

@easyedc I don't think I've personally ever heard from jamf, but enough chatter here and there from others who have heard from jamf... Sorry I don't have more info.

I don't think there's any current issue stopping -trigger... but I think -event is (eventually) what everything should be moved to.

[Jlindop]

Check Update inventory under maintenance for each policy. It slows things down abit but singles out the policy logs