Skip to main content
Solved

Custom Trigger calling two different policies.

  • August 8, 2018
  • 6 replies
  • 57 views
J
Forum|alt.badge.img+6

Hi All,

Is it possible to give 2 policies the same custom trigger name ? that are scoped differently

I need to remove some software from our Macs. The script to do this is the same no matter what version of the OS it is running.
I then want to immediately install the new software. This is slightly different for OSX10.11 and lower machines than it is for OSX10.12 and up machines.
So I have a policy made for each of the installs. If I scope one with a smart group for "10.11 and down" machines and one to "10.12 and up" machines , if I give them the same custom trigger name, when the first policy finishes will it call both policies, but due to the scope will it only run the policy for that machine ?

Andrew

Best answer by mm2270

Well, you would still be using custom triggers, just slightly different ones depending on the OS version. Here's an example of what I mean.

#!/bin/bash

ElCapTrigger="InstallProduct_10.11"
SierraTrigger="InstallProduct_10.12"

OSVers=$(sw_vers -productVersion | cut -d. -f2)

if [ "$OSVers" -lt 12 ]; then
      TRIGGER="$ElCapTrigger"
else
      TRIGGER="$SierraTrigger"
fi

/usr/local/bin/jamf policy -event "$TRIGGER"

You would just need to put the proper custom trigger names in for those 2 items at the top, and make sure they match the correct policy triggers that should be called. The script would check if the OS is lower than "12", meaning under 10.12.x, and run the older version, or if not, run the newer one.

Make sense?

The only thing is, this is a standalone script. You would need to see how to integrate these items into your software removal script. Shouldn't be hard to add this in somewhere.

    6 replies

    C
    Forum|alt.badge.img+5
    • csanback
    • Contributor
    • August 8, 2018

    Check out Der Flounder's post on this.

    https://derflounder.wordpress.com/2017/04/08/running-multiple-jamf-pro-policies-via-custom-trigger/

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • August 8, 2018

    Wouldn't it be better to detect the OS the Mac is on in the main removal script and then call the appropriate policy by it's trigger. Meaning, name each policy with an appropriate different name, like "InstallThing_10.11" and "InstallThing_10.12" or whatever. Then in the script that does your removal, check to see if the OS is below or at 10.12 and higher and run the correct policy.

    J
    Forum|alt.badge.img+6
    • JustCallMeAJ
    • Author
    • Contributor
    • August 8, 2018

    Sounds like a good idea, I'm just not very good at scripts and custom triggers seemed an easier way. I'll look into it

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • Answer
    • August 8, 2018

    Well, you would still be using custom triggers, just slightly different ones depending on the OS version. Here's an example of what I mean.

    #!/bin/bash

ElCapTrigger="InstallProduct_10.11"
SierraTrigger="InstallProduct_10.12"

OSVers=$(sw_vers -productVersion | cut -d. -f2)

if [ "$OSVers" -lt 12 ]; then
      TRIGGER="$ElCapTrigger"
else
      TRIGGER="$SierraTrigger"
fi

/usr/local/bin/jamf policy -event "$TRIGGER"

    You would just need to put the proper custom trigger names in for those 2 items at the top, and make sure they match the correct policy triggers that should be called. The script would check if the OS is lower than "12", meaning under 10.12.x, and run the older version, or if not, run the newer one.

    Make sense?

    The only thing is, this is a standalone script. You would need to see how to integrate these items into your software removal script. Shouldn't be hard to add this in somewhere.

    J
    J
    Forum|alt.badge.img+6
    • JustCallMeAJ
    • Author
    • Contributor
    • August 8, 2018

    Thank you. I managed to find a few test machines and my way didn't work. The software got removed and the new software installed, but as there was a policy that was called but didn't run then jamf never reported back that the first one had work so everything just hung.

    G
    Forum|alt.badge.img+16
    • gachowski
    • Honored Contributor
    • August 8, 2018

    If you are scoping to different machines isn't just two independent work flows... and have two triggers too!!

    Create one for the .11 machines then clone everything and then set it up for the .12 machines

    yes it's more policies and scripts but it's easier...and much easier to troubleshoot

    C

    Terms & ConditionsCookie settingsAccessibility statement