Skip to main content
Solved

Custom trigger policies, a way to have it wait?

  • October 7, 2021
  • 7 replies
  • 35 views
A
Forum|alt.badge.img+8

Hello,

I have a script being run as a policy that uses the sudo jamf policy -event eventtrigger format multiple times to run multiple policies that install applications. Is there a way to have it wait for the previous process to finish installing before kicking off the next install, it seems that none of the apps are installing correctly even though it returns with a succesful in JAMF.

 

Example of code:

 

# Installs app1
/usr/local/jamf/bin/jamf policy -event app1

# Installs app2
/usr/local/jamf/bin/jamf policy -event app2

# Installs app3
/usr/local/jamf/bin/jamf policy -event app3
 
echo " All done with installs"
 
Thanks for any help in advance!!

Best answer by Tangentism

If you need to create a cascade with dependency on the previous app installed, there are several ways to do this:

 

Extension Attribute reads if app installed -> Smart group scopes to machines with app installed.

I have McAfee set up like this on my current project so that each module installs only when the previous one is present.

Or have the code to read if the app is installed and create an if...then loop within your main scrip that only progresses if the app is installed.

Obviously there's several ways to skin the cat with this but a bland example would be:

 

# Installs app1 /usr/local/jamf/bin/jamf policy -event app1 # checks for app1 if [[ -e /path/to/app1 ]]; then # Installs app2 /usr/local/jamf/bin/jamf policy -event app2 fi

 

 

    7 replies

    Tangentism
    Forum|alt.badge.img+10
    • Tangentism
    • Honored Contributor
    • 147 replies
    • Answer
    • October 7, 2021

    If you need to create a cascade with dependency on the previous app installed, there are several ways to do this:

     

    Extension Attribute reads if app installed -> Smart group scopes to machines with app installed.

    I have McAfee set up like this on my current project so that each module installs only when the previous one is present.

    Or have the code to read if the app is installed and create an if...then loop within your main scrip that only progresses if the app is installed.

    Obviously there's several ways to skin the cat with this but a bland example would be:

     

    # Installs app1 /usr/local/jamf/bin/jamf policy -event app1 # checks for app1 if [[ -e /path/to/app1 ]]; then # Installs app2 /usr/local/jamf/bin/jamf policy -event app2 fi

     

     

    A
    Forum|alt.badge.img+8
    • ajamfadmin1810
    • Author
    • Contributor
    • 40 replies
    • October 7, 2021

    If you need to create a cascade with dependency on the previous app installed, there are several ways to do this:

     

    Extension Attribute reads if app installed -> Smart group scopes to machines with app installed.

    I have McAfee set up like this on my current project so that each module installs only when the previous one is present.

    Or have the code to read if the app is installed and create an if...then loop within your main scrip that only progresses if the app is installed.

    Obviously there's several ways to skin the cat with this but a bland example would be:

     

    # Installs app1 /usr/local/jamf/bin/jamf policy -event app1 # checks for app1 if [[ -e /path/to/app1 ]]; then # Installs app2 /usr/local/jamf/bin/jamf policy -event app2 fi

     

     


    I tried adding this for each app but for some reason it still didnt install as expected. Each app installs just fine when run as self service or manual trigger but I cant get them to install one after another. Facing this same issue with apps set to install at enrollment, seems like only one or two install. What method are you using for low/no touch deployment?

    T
    Forum|alt.badge.img+19
    • Tribruin
    • Honored Contributor
    • 582 replies
    • October 7, 2021

    Do any of the policies have a scope that depends on the previous policy completing successfully?

    The policies should run sequentially one after another. They should not run in parallel. Can you see anything in /var/log/jamf.log that indicates if the policy is running successfully or not?

    If you can, I use this code snippet at the beginning of my scripts to get details on what the script is doing. 

    # Redirect STDOUT to file exec 1> /var/log/file.log # Redirect STDERR to STDOUT exec 2>&1 # Debugging is turned on (show results of each command) set -x

     

    A
    Forum|alt.badge.img+8
    • ajamfadmin1810
    • Author
    • Contributor
    • 40 replies
    • October 7, 2021

    Do any of the policies have a scope that depends on the previous policy completing successfully?

    The policies should run sequentially one after another. They should not run in parallel. Can you see anything in /var/log/jamf.log that indicates if the policy is running successfully or not?

    If you can, I use this code snippet at the beginning of my scripts to get details on what the script is doing. 

    # Redirect STDOUT to file exec 1> /var/log/file.log # Redirect STDERR to STDOUT exec 2>&1 # Debugging is turned on (show results of each command) set -x

     


    Hello

     

    None of the policies are scoped to depend on a previous policy completing successfully currently. Im building out the JAMF environment, i can create smart groups for that i suppose.

     

    Looking at the /var/log it shows as the installs that do get pulled in as succesful.

     

    A
    Forum|alt.badge.img+8
    • ajamfadmin1810
    • Author
    • Contributor
    • 40 replies
    • October 27, 2021

    If you need to create a cascade with dependency on the previous app installed, there are several ways to do this:

     

    Extension Attribute reads if app installed -> Smart group scopes to machines with app installed.

    I have McAfee set up like this on my current project so that each module installs only when the previous one is present.

    Or have the code to read if the app is installed and create an if...then loop within your main scrip that only progresses if the app is installed.

    Obviously there's several ways to skin the cat with this but a bland example would be:

     

    # Installs app1 /usr/local/jamf/bin/jamf policy -event app1 # checks for app1 if [[ -e /path/to/app1 ]]; then # Installs app2 /usr/local/jamf/bin/jamf policy -event app2 fi

     

     


    This is basically what i did but I did the built in "files and process" to call the next event starting with app1,app2 so on just like the commands you posted. Thanks for your help

    piotrr
    Forum|alt.badge.img+8
    • piotrr
    • Contributor
    • 132 replies
    • September 21, 2022

    Policies run in sequence, never in parallell. This could change at some point I guess, but for now, they will run in ASCII order based on name, one after the other. This has worse implications as you will realize when you think about it, but it CAN be used to create a sequence. 

    Tangentism's first solution is robust and accurate and good, the only drawback is that it requires an inventory update between policies running, to scope the next policy, which means it may take several 15-minute intervals (check-ins) to fully run all the required policies. 

    I recently realized I could launch configurations and package installations directly from PreStage Enrollments. You could put the first installer in there, to make sure it installs before you start the policies. 

    A
    Forum|alt.badge.img+8
    • ajamfadmin1810
    • Author
    • Contributor
    • 40 replies
    • September 26, 2022

    Policies run in sequence, never in parallell. This could change at some point I guess, but for now, they will run in ASCII order based on name, one after the other. This has worse implications as you will realize when you think about it, but it CAN be used to create a sequence. 

    Tangentism's first solution is robust and accurate and good, the only drawback is that it requires an inventory update between policies running, to scope the next policy, which means it may take several 15-minute intervals (check-ins) to fully run all the required policies. 

    I recently realized I could launch configurations and package installations directly from PreStage Enrollments. You could put the first installer in there, to make sure it installs before you start the policies. 


    Correct. DEPnotify simplifies all this and makes it easy thats what we are currently using for zero touch deployment to users


    Terms & ConditionsCookie settingsAccessibility statement