Separate scoping of Trigger vs Self Service

user-mBVrFoEtXa
New Contributor

I have a policy to install a package, which I want to make available to all computers via Self Service, but I only want it to automatically install (e.g. via enrollment trigger) for some computers only.

Can this be done somehow, without having 2 different policies? (e.g. 1 policy for Self Service, another policy for enrollment trigger)

 

I presume, when configuring the scope of a policy, it applies to both 'trigger' and 'Self Service' scenarios.

1 ACCEPTED SOLUTION

sdagley
Esteemed Contributor II

@user-mBVrFoEtXa Yes, the Scope settings for a policy apply to both the 'trigger' and 'Self Service' scenarios. A common approach for what you're trying to do is actually have 3 policies - one that will install the package triggered only by a custom event (e.g. InstallRandomApp) and scoped to all computers, one triggered by enrollment with a Files and Processes payload with "/usr/local/bin/jamf policy -event InstallRandomApp" as the command to execute scoped as you want, and finally a policy only triggered via Self Service scoped to all computers with the same Files and Processes payload with "/usr/local/bin/jamf policy -event InstallRandomApp" as the command to execute. This way when you need to update the package being installed there's only one policy you'll need to change the package in.

View solution in original post

9 REPLIES 9

bmack99
Contributor III

I've only been able to accomplish this via 2 separate policies. I just tag a _SS onto the end of the Self Service Policy name to distinguish.

sdagley
Esteemed Contributor II

@user-mBVrFoEtXa Yes, the Scope settings for a policy apply to both the 'trigger' and 'Self Service' scenarios. A common approach for what you're trying to do is actually have 3 policies - one that will install the package triggered only by a custom event (e.g. InstallRandomApp) and scoped to all computers, one triggered by enrollment with a Files and Processes payload with "/usr/local/bin/jamf policy -event InstallRandomApp" as the command to execute scoped as you want, and finally a policy only triggered via Self Service scoped to all computers with the same Files and Processes payload with "/usr/local/bin/jamf policy -event InstallRandomApp" as the command to execute. This way when you need to update the package being installed there's only one policy you'll need to change the package in.

jcarr
Release Candidate Programs Tester

This approach works, but may be unnecessarily cumbersome.  If, when updating a package, you upload the new package as a separate item rather than simply updating the existing item, then you do need to update each policy that references that package in order to point at the new package.  If however, when a package update is available, you simply update the existing item, policies do not need to be updated since the ID of the package referenced by the policy has not changed.

sdagley
Esteemed Contributor II

I said it was a common approach, I didn't say it was necessarily the best. Personally I prefer the clarity of seeing a package name that indicates exactly what version is packaged (e.g. GoogleChrome-107.0.5304.110.pkg instead of simply GoogleChrome.pkg) so I always create a new package when uploading a new version.

jcarr
Release Candidate Programs Tester

Agreed.  I wanted to make sure to point out al alternate method.

 

FWIW, I like to have the version available as well.  I leave the .pkg named as is when downloaded from the vendor, and simply change the item display name to identify the version:

Screenshot 2022-11-16 at 12.01.18 PM.png

sdagley
Esteemed Contributor II

It sounds like you might want to take a look AutoPkg/AutoPkgr to monitor for vendor updates (putting the version number into the .pkg name is SOP for autopkg). I can't use the Jamf Pro integration for automatically adding new .pkgs to Jamf Pro at my org, but having it pull new releases automatically for evaluation is extremely handy.

jcarr
Release Candidate Programs Tester

Good tip.  Although I've actually migrated the few that I had to use Jamf App Catalog.

sdagley
Esteemed Contributor II

The Jamf App Catalog is on my list of things to evaluate in 2023, and it looks like Jamf has addressed the majority of the initial problems as of JSS 10.42, but unless I'm missing something you're limited to the apps that Jamf makes available in the catalog. That is a small subset of the apps available via already published autopkg recipes, and you can always create your own recipe if one doesn't already exist. That said, I definitely see the appeal of moving to the Jamf App Catalog for apps it does offer, and expect that's where I'll end up.

user-mBVrFoEtXa
New Contributor

thank you to all for your suggestions.

I eventually went with something similar to what sdagley had suggested -

I created 1 policy with only 1 (custom) trigger="ABC" and Self Service enabled and deployed it to all computers.

This makes the policy available to all computers via Self Service.

Then, I created a 2nd policy that has 'enrollment' trigger (not available in Self Service) and deployed it to a subgroup of computers.

This 2nd policy will automatically execute for this subgroup, and will basically run "/usr/local/bin/jamf policy -event ABC", thus executing the 1st policy above.

 

With this, the 1st policy is made available to all computers via Self Service, while it will also automatically install for a subgroup of computers.