Skip to main content

Hi All,



We have different software configurations that we apply depending on where the machine is going. I'll go ahead and mention that due to legal reasons well above my pay grade we can't use DEP. I'm trying to setup policies in self service that will install the software for a specific configuration by calling a custom trigger. So I can offer the applications through self service individually, or I can have a user select a configuration "bundle" and it will install all the applications tagged with that specific event trigger. The way I'm trying to go about this is by essentially stacking policies. For instance, I have a base policy that all it does is run the command 'jamf policy -event baseInstall' that installs basic software every machine should have (Chrome, Office, etc) Then I have another policy (let's say Workstation) that will execute a script that runs the command 'jamf policy -event workstationInstall' that installs workstation specific software and then runs the command 'jamf policy -event setupBase' which just calls the base policy and let's it do it's work to install the base packages. That way each configuration is self-contained and it's not necessary for the user to click on several different configurations.



I've actually gotten this to work quite nicely through several levels when scoped to All Computers. The problem I'm running into is restricting access to these policies in self-service. I only want our techs to be able to run these, at least until any kinks are worked out, so I scope all of them to the same static group that contains our techs. But after logging into self service, when I try to run any policy that calls another policy I get the error "This Item No Longer Exists" (except for the base policy which is only executing on items that are scoped to All Computers). I think what is happening is that the scope is not following the policy calls, so when policy B calls policy A it doesn't see policy A because it thinks it's outside of the scope. Is there any way to call a policy and include the jamf user calling it, or have the policies understand that when they being called by custom trigger the scope is ok or doesn't matter?



I hope I explained this well. Does anyone have any suggestions? I'm kind of stumped.

from what I understand you possibly need to scope all the polices to all computers but set custom triggers as the calling trigger, and not any other method at all.
then if the first policy is scoped, either by device or ldap login to self service, it will work.



I use a broadly similar process on our builds, we also have an extensible method by having one of the scripts read receipt files on the device which is used to fire off different events so multiple configs can be deployed from the same base.

If you put a user scope on a policy the policy will only be applied when called directly via Self Service or as a login policy.
Secondary policies called by trigger will not work with a user restriction applied.



You can do something like this though.



Policy A - Scoped by machine - Custom Trigger A.
Policy B - Scoped by machine & User - Self Service - Only Calls Customer Trigger A.



This will work the way you want as I understand it.
There is one caveat thoug, if a user has admin rights they can run "sudo jamf -event "Customer Trigger A" to deploy the policy, they would of course have to know they could do this and what the trigger was.



If your wanting to bundle up a bunch of custom triggers this might be useful.
You put it in the self service policy and it runs through arguments 4 thru 11 and calls them as custom triggers in that order.



#!/bin/bash

echo START

date

for Custom_Policy in $(seq 4 11); do

if [[ "${!Custom_Policy}" ]]; then

echo Running trigger ${!Custom_Policy}

jamf policy -event "${!Custom_Policy}"

fi

done

echo FINISH

date
There is one caveat though, if a user has admin rights they can run "sudo jamf -event "Customer Trigger A" to deploy the policy,


I'm not sure if you're saying calling the policy by trigger overrides scoping. The policy still has to be scoped to run even if called by the trigger.



we either scope to smart groups or all devices and use specific dynamic triggers.
Indeed some of our policies are in self service and have triggers so we can use them in self service or by calling from other policies.

Thanks for the responses you guys. I ended up creating policies that were triggered only by a custom event and scoped to all computers, and then individual self-service items to call those policies. I like that script @Look , that will come in handy for the future. @marklamont I'm also going to look into reading receipts from machines to automate some aspects. That's a great idea! Thanks again!

Terms & ConditionsCookie settings