How many policies for each Application?

[G_M__webkfoe_]

Hello everyone,
I have a doubt about policies specific for Applications (packages, not talking about App Atore apps) installation and I'd like to collect some ideas from you all, just to understand if I can do better.

I'd like to understand how do you handle Applications in your Jamf platform.

For example, in our case, we would have 3 different policies for each applications:

1) the first one is dedicated for the enrollment trigger, as we want the device to be born with the right Apps already in place (if that device is in scope of that Application), as we use the "Enrollment Complete" trigger during our first device installation

2) the 2nd one is dedicated to self service, so that the user can always deploy his scoped Applications whenever he wants, if needed for any reason

3) the 3rd one is dedicated to automatic silent installation, as we have accustomed our users to get instant deploy of Applications when they get allowed by marketing dept. to use those application

Note that in our specific business case, at the moment we do not give "optional" applications, like "if you want you have this, this and this in the self service.."
We just give what it's needed to work and we want them to use it.

Another thing on which I'd like to put some highlight and collect some use case from the community it's about Categories (still specific to Application packages).

In our case, we have one "Applications" category in which we drop all 3 kind of the above mentioned "Applications" policies.

But I am thinking of splitting them in 3 different categories...

what about yours??

Thanks to everyone who will partecipate!

[bentoms]

Well.. it depends.

@grahamrpugh has documented workflows with 7 policies per title.

Whereas I would have 3 max via jamJAR

1. self service
2. Install automatically or update it installed
3. Uninstall

4. two

5. two

[grahamrpugh]

I've got more now:

1. Untested version (Self Service)
2. Install prod version via trigger
3. Self Service install prod version
4. Self Service update to prod version
5. Auto-install prod version
6. Auto-update to prod version
7. Uninstall by trigger
8. Self Service uninstall

[mschroder]

Our main installation method is via the Self-Service. For simple cases I have two policies: "install" and "remove". Some apps and configs get installed when a device joins a static group. In that case we add a custom trigger to the same policy as used for the Self-Service.

Then there are the products that require whitelisting kernel extensions, these need a few more policies:
- install on macOS < 10.13.4 (Self-Service, now obsolete)
- request the install (Self-Service, for macOS >= 10.13.4) - whitelist kext (when MDM sees flag that user requested install, but kext is not yet whitelisted)
- install product (when MDM sees that kext is whitelisted)
- remove (Self-Service)

What are you doing different in (un)install by trigger and (un)install by Self-Service that you need extra policies for them?

[john_sherrod]

Just came across this thread and wanted to add my method. I figure the more people share their processes, the more we can all learn from each other! I currently employ six policies:

1. Main - contains the package and the policy trigger
2. Automatic Install - for apps that we deploy automatically
3. Self Service - even if we deploy an app automatically, I like for the user to be able to re-install from Self Service
4. Update - A Self Service policy the lets the user take ownership for updating their apps
5. Patch - Installs the latest version of the app at login so that it gets it when they reboot
6. Remove - just what it says on the tin

[mm2270]

Similar to what @mschroder mentioned, I would remove the Enrollment Complete trigger and instead use a Custom Event trigger setting and simply call that trigger in a script during enrollment. Meaning, have a single policy that gets called at Enrollment Complete that has a script which runs all the other policies by their custom event triggers.
That way the policy would only get called during enrollment when that trigger is specifically called. This eliminates at least one of those separated out policies, since the same policy can double for Self Service, as long as you make sure the scope is set correctly. Both Self Service and Custom Event can be considered as "user initiated" if you think about it, just that one is called from an app and the other called from a script or Terminal.

Unfortunately you will still end up having several other policies for that same application if you want to have things like uninstalls, silent installs that get triggered based on Smart Group membership, etc. Can't help much there. Given how Jamf Pro is designed it's inevitable that you will end up with a number of different policies all installing (or uninstalling) the same product but under different circumstances.

It would be nice actually if Jamf figured out some easy to use way to make installs & uninstalls into one policy, as in, if the app is installed, automatically (or via a checkbox option in the policy under the Self Service tab) show an "uninstall" version of that policy in Self Service. This would be a nice feature as it would eliminate a common reason why we need more than one policy per application title. I actually think there's a rather old Feature Request floating around here that asks for that in fact.

[jhuls]

I think the thing to remind yourself is what is expected from your organization in terms of deployment for testing and production. Some organizations put their trust in IT allowing for them to cater the flow to what's easiest to put together. Others, like my own, we're required to email people IT Alerts that includes scheduled times for specific computers at certain times. Due to this I have a few more policies per application than some others might as the "auto" policies are split up for different areas that get deployed on different days.

While it creates a number of policies and groups, the only thing you really have to touch once it's done is the version number in the smart group to deal with updates.

At the risk of going off topic I would be curious how people using this method are deploying something like Creative Cloud. Are you splitting them into individual applications with a few policies for each one or do you deploy as one or a couple large packages? Do you update using this policy system or something like RUM?