Recurring check-in with scope limitations

[lucjamf]

Hi everyone,

I tried searching but couldn't find really an answer. Hopefully I can explain my situation clearly with my limited knowledge in english language.

Is it possible to construct a policy to install software this way. I would like to have a policy that install specific software. Software is available to every computer so that our Administrators can log in to Self Service and start the install. For classrooms there would be a script for each room that would use the custom triggers to start install on recurring check-in if the software is missing.

My goal would be to get rid of some policies. Currently we have two policies for each software; one for Self Service installation and one for automatic installation for classrooms.

The problem I have is that on recurring check-in when the script runs, it checks for policies for custom trigger install_maya_2018 but cannot find any policies because it is limited to <LDAP_Administrator_Group>. I tested to also include root user as limitation but it doesn't seem to work.

Below is an example what I would like to accomplish.

The policy
Policy name: SOFTWARE Autodesk Maya 2018
Trigger: custom (install_maya_2018)
Frequency: Once per computer
Scope: All Computers, Limited to <LDAP_Administrator_Group>
Packages: Autodesk_Maya_2018.pkg
Self Service: Make the policy available in Self Service

[ChrisCox · Accepted solution]

I think you may have a bit of a design flaw from the ground up on this one. If you want the software automatically installed on all computers, you ought to just have the policy use the check-in trigger instead of custom or Self Service. If you want to be able to check for and install all automatic policies in scope you could setup a Self Service policy that just executes the jamf policy command. Typically, an automatic policy and Self Service policy will have options that are mutually exclusive from each other. For example, you will generally want a Self Service policy to have a frequency of ongoing and an automatic policy to have a frequency of once per computer. Also, the scoping issue you are running into will continue to be a problem. You cannot have a Self Service policy scope limited to a set of users if you wish that same policy to be able to run automatically regardless of user. If you feel you really need to have a Self Service policy for this software, best practice in my opinion is to just have a separate policy to use in that case.

[lucjamf]

Thank you for the reply Chris! As I feared, I have to keep on having two policies per software to accomplish my goals.

The only problem I really had was the scoping limitation to users, as my script that runs every check-in calls for the custom triggers and they work if the scopes are not limited. Atleast I can use my solution to the free software that doesn't require limiting the scope at all!

[marklamont]

If it were me I would have one install policy, with only a custom trigger and scoped to all devices and allowed to run continually.
Then create your two polices where the scoping is active. These can then be set to send the trigger that calls the install policy using a script like the one shown
I do all my deployments like this as it means there is only ever one policy to update when a package changes. if you say use install-xxx-live as the trigger you can easily create a test workflow by creating a set of cloned policies and changing the trigger to install-xxx-test

#!/bin/bash

################################################################################################
# script to take multiple inputs and use them to fire multiple jamf policy -event triggers.    #
# uses $4--11                                                                                  #
# script will exit out when it detects no more policies to try                                 # 
# Mark Lamont Mar 2019                                                                       #
################################################################################################

###########################################
# if 8 aren't enough what are you doing!? #
###########################################
policyTrigger1="${4}"
policyTrigger2="${5}"
policyTrigger3="${6}"
policyTrigger4="${7}"
policyTrigger5="${8}"
policyTrigger6="${9}"
policyTrigger7="${10}"
policyTrigger8="${11}"


################
# debug lines. #
################
#echo "$policyTrigger1"
#echo "$policyTrigger2"
#echo "$policyTrigger3"
#echo "$policyTrigger4"
#echo "$policyTrigger5"
#echo "$policyTrigger6"
#echo "$policyTrigger7"
#echo "$policyTrigger8"


############################
# run sequentially.        #
# when no input found exit #
############################
if [ "$policyTrigger1" != "" ]; then
    jamf policy -event $policyTrigger1
else
    echo "No work to do at all!"
    exit 0
fi

if [ "$policyTrigger2" != "" ]; then
    jamf policy -event $policyTrigger2
else
    echo "no more work to do"
    exit 0
fi

if [ "$policyTrigger3" != "" ]; then
    jamf policy -event $policyTrigger3
else
    echo "no more work to do"
    exit 0
fi

if [ "$policyTrigger4" != "" ]; then
    jamf policy -event $policyTrigger4
else
    echo "no more work to do"
    exit 0
fi

if [ "$policyTrigger5" != "" ]; then
    jamf policy -event $policyTrigger5
else
    echo "no more work to do"
    exit 0
fi

if [ "$policyTrigger6" != "" ]; then
    jamf policy -event $policyTrigger6
else
    echo "no more work to do"
    exit 0
fi

if [ "$policyTrigger7" != "" ]; then
    jamf policy -event $policyTrigger7
else
    echo "no more work to do"
    exit 0
fi

if [ "$policyTrigger8" != "" ]; then
    jamf policy -event $policyTrigger8
else
    echo "no more work to do"
    exit 0
fi

echo "all 8 policies triggered, good work everyone!"
exit 0