Jamf App Catalog vs Packages and Policies

KeithStrand
New Contributor III

Our current Jamf Pro instance is a mess with unpatched apps missing packages and policies no one has tended to in years. 

I recently learned about Jamf App catalog and have 8 "Jamf App catalog" apps deploying on my dev server. Besides the known limitations of Jamf App catalog (less control over versions, lack of verbose install feedback, etc) are there any other downsides to using Jamf App Catalog for basic apps like Chrome 1Password etc? Will I regret not doing it the old way?

Jamf App catalog seems much easier to maintain. Am I missing an obvious downside to Jamf App catalog?  Would love to hear about others views on this.  

5 REPLIES 5

sdagley
Esteemed Contributor II

@KeithStrand I think it all depends on how much control you need on when updates to an app get deployed. For the Jamf App Catalog there's no option to defer the installation of any update to the application. That might be an issue for some apps (e.g. my org defers Office app updates for 21 days), but if it's not a problem my opinion is make use of the feature. 

mm2270
Legendary Contributor III

We've begun using Jamf App catalog titles, but only for some programs. We're slow rolling it out. It would be nice to have some more control over versions, but I understand the premise of the feature is to "set it and forget it", and it just keeps that application up to date without any additional intervention needed. But maybe that's something they'll add at some time. I'd like to at least be able to push an N-1 version instead of "current" only.

I do hope Jamf continues to keep the focus on this new functionality and improve on it, like what they recently did by making them available in Self Service. We had similar hopes of continued improvement with Patch Management, but development on that hasn't progressed very far from its original implementation.

sharriston
Contributor III

The only downside we have experienced is that it's not as instant as I would like (like calling it via Self Service or a check in trigger) but otherwise it's pretty smooth. The one behavior that is strange is it's not super dynamic. If the app catalog installs an app and the user deletes it, Jamf won't reinstall the app until a new version comes out. The device will sit there as "Successful Deployment".

Have you looked at Installomator as well?  It lets you install the latest version of an app from the developer, has logic to not run if the current version is installed, and uses gatekeeper and app notarization to make sure the correct version is being installed. It also runs as script so you can use it with a policy/during enrollment. 

easyedc
Valued Contributor II

Our organization has taken an approach of "be on latest" for security purposes.  Before the App Catalog was an option, I began writing scripts to look for and download latest version of certain apps.  Those scripts are both how I patch as well as perform new installs (just 2 different policies with different execution frequencies - new=once, patching=monthly). If I have any zero-days to patch, I just flush the log history of the patching policy.

 

#!/bin/sh

#  Google Chrome - Download and Install Latest.sh
#
#  Last updated by Ed C on 4/20/23.
#
[ -f /tmp/debug ] && set -x
# This script downloads the latest Google Chrome
InstalledVersion=$(/usr/bin/defaults read /Applications/Google\ Chrome.app/Contents/Info CFBundleShortVersionString 2>/dev/null)
CurrentVersion=$( curl -s https://omahaproxy.appspot.com/history | /usr/bin/awk -F',' '/mac,stable/{print $3; exit}' )
/bin/echo "Found version $InstalledVersion installed..."
/bin/echo "The current version is $CurrentVersion..."
if [[ "$InstalledVersion" = "$CurrentVersion" ]]; then
    echo "Google Chrome is current. Exiting"
    exit 0
fi
URL='https://dl.google.com/dl/chrome/mac/universal/stable/gcem/GoogleChrome.pkg'

/bin/echo "Downloading Chrome"
/usr/bin/curl https://dl.google.com/dl/chrome/mac/universal/stable/gcem/GoogleChrome.pkg -o /tmp/GoogleChrome_$CurrentVersion.pkg

if [ $? = 0 ]; then   # if mount is successful
    /bin/echo "Kill Google Chrome..."
    /usr/bin/pkill Chrome
    /bin/echo "Removing old copy..."
    /bin/rm -rf "/Applications/Google Chrome.app"
    /bin/echo "Installing..."
    /usr/sbin/installer -pkg /private/tmp/GoogleChrome_$CurrentVersion.pkg -target / -verbose
fi
    /bin/sleep 5
# Clean-up
/bin/echo "Cleaning Up..."
/bin/rm -rf /private/tmp/GoogleChrome_$CurrentVersion.pkg
/bin/echo "Successfully installed Google Chrome $CurrentVersion"
exit 0

 

This takes care of my needs, but your needs may vary. Or to quote @mm2270 YMMV

DG_Edwards
New Contributor II

I would like to throw one thing out there regarding the Jamf managed apps.  My company has been a big fan of making things available through self service vs the forced deployment method.  I did not immediately realize that in creating the deployments for self service, while the verison being installed would always be up to date at the time of install there is no patching policy created along with that.  Only force deployed "managed" apps will stay up to date on your endpoints.  What I needed to do was create a secondary set of smart groups that inventory each of the individual apps and then targeted a separate forced deployment of each of the apps to those smart groups to keep the app up to date after the self service deployment was done.