Skip to main content
Solved

advice: Package Install

  • July 3, 2019
  • 6 replies
  • 57 views
D
Forum|alt.badge.img+3

Hi,

Jamf user of 2 days, sorry if this is a simple one. Looking for advice on the best way to deploy a package.

We have a policy to install a package to a smart group scope filtered on department. I'de also like to offer this to all computers in self service would i:

Create 2 policies one to install to computers in the smart group and one to offer in self service

OR

Is there something clever that i can do in the one policy where it install to the smart group but only offers in self service to other computers?

Thanks

Best answer by mickgrant

ok so here is what i do. you will have 3 policies for each package.
MAIN - this will have the actual installer or script for your policy. and you set the trigger to custom and name the custom trigger 

main_*PolicyName*

This policy is our Master policy for all the later policies. scope it to every machine and every user.

DEPLOY - this will be for all the computers you need to push the application too. you will not include any packages or scripts here instad you will reference your main policy. To make it work you go to the Files and Processes tab and then Execute Command. the command you want to enter here is .

jamf policy -trigger main_*PolicyName*

This tells this policy to refer back to the MAIN policy we created first and to run the main_PolicyName package/script
scope this policy to all the computers you want the policy to run on automatically, and set the install triggers to whatever you want

SELFSERVICE - do the same as you did for the DEPLOY policy, but this time you can add it to the category you want it to appear in in self service, and then scope it to whoever you want

I know this seems a little complicated at first, but it really pays dividends for you down the track when you need to update an application installer or script because when you have to change it, you only have to do it in one place in the MAIN policy, because all the others are just links back to it.

It also pays back in organisation, because after creating categories for MAIN and DEPLOY they are all grouped together, and everything else in there is organised as they will appear to your users in self service

6 replies

mickgrant
Forum|alt.badge.img+12
  • mickgrant
  • Contributor
  • Answer
  • July 4, 2019

ok so here is what i do. you will have 3 policies for each package.
MAIN - this will have the actual installer or script for your policy. and you set the trigger to custom and name the custom trigger 

main_*PolicyName*

This policy is our Master policy for all the later policies. scope it to every machine and every user.

DEPLOY - this will be for all the computers you need to push the application too. you will not include any packages or scripts here instad you will reference your main policy. To make it work you go to the Files and Processes tab and then Execute Command. the command you want to enter here is .

jamf policy -trigger main_*PolicyName*

This tells this policy to refer back to the MAIN policy we created first and to run the main_PolicyName package/script
scope this policy to all the computers you want the policy to run on automatically, and set the install triggers to whatever you want

SELFSERVICE - do the same as you did for the DEPLOY policy, but this time you can add it to the category you want it to appear in in self service, and then scope it to whoever you want

I know this seems a little complicated at first, but it really pays dividends for you down the track when you need to update an application installer or script because when you have to change it, you only have to do it in one place in the MAIN policy, because all the others are just links back to it.

It also pays back in organisation, because after creating categories for MAIN and DEPLOY they are all grouped together, and everything else in there is organised as they will appear to your users in self service

    Brad_G
    Forum|alt.badge.img+16
    • Brad_G
    • Valued Contributor
    • July 4, 2019

    @DanielDarnbrough , I second what @mickgrant is saying above. It seems like a lot of work (and it is slightly) at first but it will pay dividends down the road. Only having to have one policy to update when a new release of software comes out helps keep everything in sync.

    Plus once you have your deploy and self service policies in place you can easily change scope on who gets it which way.

      M
      Forum|alt.badge.img+12
      • marklamont
      • Contributor
      • July 5, 2019

      and I third it, if that's a thing.
      I use the trigger style

      install-<package>-live

      as my main install policy trigger. this allows easy creation of test or UAT workflows by policy duplication then modify the trigger,

      install-<package>-test

      and the packages and scripts in the policy.

      I use this script as my method of calling the install scripts. allows up to 8 to be deployed in one chain and uses the jamf variables as inputs

      #!/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

      Set the variable labels in the script like so;


      then in the policies used to install the package set it like so;

      The really important thing to remember is do the actual scoping on the deployment policies and NOT the install policy. The installer, th eone with the trigger of install-<package>-live must be scoped to all computers and set to ongoing. Any conditional scoping needs to be on the policies that show in self service or automatically run. This means the installer will always run no matter which method is used to run it.

      D
      Forum|alt.badge.img+3

      Perfect. Thank you so much for a detailed description.

      Works a treat and i learnt something too :)

      T
      Forum|alt.badge.img+8
      • tomhastings
      • Valued Contributor
      • July 8, 2019

      Marklamont, I like the script and will be testing it this week in my environment.
      Just wondering, what was the reason for developing the script since Jamf lets you stack packages within a policy?

      P
      Forum|alt.badge.img+2
      • pvcit
      • New Contributor
      • July 8, 2019

      Sad part is if JAMF just had separate scope for self service tab you would not 3 policies but just one.

      Terms & ConditionsCookie settingsAccessibility statement