"Mac Apps" workflow recommendations?

[erichughes]

We are wanting to move to using the "Mac App" and the Jamf App catalog to manage several apps. Since it only support Smart Groups, simply assigning it to "All Managed Clients" or similar seems a bit lazy to me. What kind of workflows are you using? Generally we use a Policy that installs the app the first time to a static group that needs the application, not everyone gets Sketch for example. Then we use Patch Management for updates. We do have company wide applications such as Zoom that All Managed works for. Just interested in how others have gotten around the single Smart Group limitation of Mac Apps.

[sdagley]

@erichughes For each app in the Mac App catalog I want to be installed on user request I have a policy that will create a hidden file on the Mac specific to that app, an EA for each app that looks for the presence of that file, a Smart Group for each app that contains Macs where the app specific hidden file is found, and finally the app specific Smart Group is used to scope the app in the Jamf App catalog.

If I wanted to force install I can just run  policy to create the app specific hidden file.

[jamf-42]

I'd suggest, if not too late to create a new smart group.. 'foobar_Baseline' and use that rather than 'All Managed Clients' this gives you a level 'up'  where you can add / remove.. 

With Jamf Mac Apps, you can use a smart group, scoped to the App name, when installed App falls into that group it will become 'managed'.. take care with the config profiles this installs for notifications. Test test test. 

To install. you can make other smart groups bases on a certain criteria.. and you can nest smart groups.

I never use static groups for less than a few pilot users.

[mm2270]

It might be a bit of overhead, but you can just create very basic Smart Groups to target devices that have the specific app in question installed on it, using the "Application Title | has" criteria, and put in the application name. There shouldn't be a need to worry about the version installed. I haven't played with it a lot just yet, but I believe the Jamf App Catalog workflow will figure out if an update is needed or not on it's own, so there's no requirement to track the version, just whether the app is installed.

Make such Smart Computer Groups for each application you'd like to use the Jamf App workflow with, and then use that group as the scope for each title. That way Jamf App Catalog won't inadvertently push out an app to all your Macs that don't really need said application.

The above is just my "off the napkin" thinking out loud. There may be a more efficient way to do it that I'm not thinking of.

[sdagley]

My concern on using the Jamf Mac App catalog to "adopt" an existing app install is that the Jamf app catalog installers have been modified to not include any automatic update configurations. If you've installed an app which set up an automatic update component and you then install a Jamf app catalog version over it there may be a conflict. 

[mm2270]

That is a good point. I have noted that in nearly all cases, the app installers Jamf builds do not include the vendor auto update mechanisms, or explicitly disables them in any case. That could create some issues, but I guess it really depends on how you want your apps to be updated on the endpoints. In the past, I would have said, when possible, use an apps built in auto updating mechanism. I mean, why not, if your org allows that sort of thing. But with the introduction of Jamf App Catalog, for my purposes, I may be ok with just allowing Jamf App Installers to take over the updating of those apps. In the end, the apps will get updated, just using a different Jamf controlled process over the vendor one.

That said, I'm certain there are some edge cases where the vendor provided update mechanism may be needed or desired over the Jamf one. I can't think of any right now, but that doesn't mean there aren't any.

If you know of some examples where it could create a problem or conflict, I'd love to hear about it. I'm not using Jamf App Catalog just yet, because we're still in the process of migrating from on-prem to cloud, but we plan on using it full on once our transition has happened. In my limited playing around with Jamf App Catalog, the updates they provide have always worked and have never borked a program. Not saying it can't happen, but so far it seems like Jamf has built a very solid updater tool.

[sdagley]

Microsoft's deferred update channels when using Microsoft AutoUpdate for Office app updates (for details see https://www.kevinmcox.com/2021/10/microsoft-now-provides-curated-deferral-channels-for-autoupdate/) provide much more flexibility in scheduling updates than updating via the Jamf. I don't see adding that level of granularity to Jamf's Mac App Catalog update mechanism as being worth the effort or the added complexity it would introduce.

I don't have an example of where installing a Jamf App Catalog package over an existing app install done via the publisher's installer causes a problem, but I tend to believe in O'Toole's Corollary to Murphy's Law - "Murphy was an optimist." I'm glad to hear you haven't run into any problems yet, and I plan to do some testing (looking at you Adobe Acrobat apps) now that I've had our production JSS updated to 10.45.

[JustinC]

@sdagley  in most cases we are not blocking the apps built in auto update mechanism with App Installers. We were only doing it with software titles where we are getting conflicts between the built in auto-update mechanism and App Installers which was resulting in corrupted apps on the end user Macs. We are about to roll out a change to the Adobe titles in App Installers to allow them to auto update again which should only leave (I believe) 3 titles left in App Installers where the auto update mechanism is blocked. Those titles being Chrome, Slack and Zoom.

[sdagley]

@JustinC Thanks you very much for that information, it is very useful.

[JustinC]

@erichughes one workaround that has been pointed out to me is that you can create Smart Groups that use a Static Group as its criteria. I know that this is 'clunky' as you would have to create a new Smart Group for each Static Group that you want to use in App Installers however it will work. In the attached screenshots you can see where we have used a Static Group called 'KTW" as the criteria for a new Smart Group called 'KTW (inc. Static Group)'. This Smart group is then available to select in my App Installers scope.

 

 

[MPHEGGELO]

The limitation to assigning to a singular Smart Group is ridiculous. IMHO

[jamiesmithJAX]

An exclusion groups option would be nice as well.  Currently piloting this with a bunch of apps and what I had to do was make a static group to add the actual machines into, and then a smart group that shows all members of the group that currently have the application I am trying to update installed.  If I don't do that it the application is going to install as soon as I add it to the static group, even if the machine doesn't already have it.

It's an awesome feature in JAMF Pro so I am not complaining a few small updates could go a long way in making this great.