Here at Rocketman we've migrated from using installation scripts and AutPkgr to utilizing Jamf’s built in App Installers to deploy software patches for thousands of Macs. This migration has taught me a lot about the process and the benefits of utilizing App Installers.
Jamf App Catalog
So what is the Jamf App Catalog? Well it's just that, it's a catalog of applications that Jamf packages and deploys on our behalf, taking the heavy lifting off of our shoulders as Mac admins and adding it as a readily available resource within the Jamf pro dashboard.
The Jamf App Catalog launched one year ago this month, in March 2022, as a technical preview in Jamf pro version 10.37. At the time of this post we are now running Jamf Pro 10.44.1.
App Installer Configuration Profiles
If you're new to utilizing Jamf's App Installers, here's a quick guide to a basic app installer configuration. It is refreshingly simple.
In Jamf Pro, click Computers at the top of the sidebar.
Click Mac Apps.
Click New.
Select Jamf App Catalog.
Click Next.
Click Add for the app you want to distribute.
Read and acknowledge the Terms and Conditions.
Edit the display name for the app.
Choose a category from the Category pop-up menu.
Choose a target group from the Target Group pop-up menu.
It's important to note that the target group must be a smart computer group.
Click View App Installer Info to view additional information about the selected app installer. The following information is displayed:
Application Name
Publisher
Latest Version
Package Size
Click Save .
Use the Deploy switch to enable deployment of the app.
End-User Experience
In this example we are updating Zoom. Once deployed it is queued up in the background, waiting for the application to close. In the video above, Zoom is at version 5.12.9 at the start. We close the application and once opened up again, Zoom has updated to version 5.13.7. It's that easy, it's that fast, it's that efficient.
And it's become more robust in the year since Jamf launched App Installers.
Behind the Scenes
What exactly is happening behind the scenes?
There are four major requirements to successfully use Jamf App Installers
Could Services Connection established
Mac OS only
For Jamf App Installers, everything is deployed through an MDM command. Jamf will deploy a temporary launch daemon, waiting for the application to close before installing, if necessary. This daemon is located locally on the machine in the /Library/LaunchDaemon directory and it is only a temporary daemon. Once the installation process has commenced and completed, Jamf removes the daemon from that directory. Packages are sent via the install enterprise application MDM command and these packages are temporarily located on the machine in the /Library/Application support/Jamfappinstallers directory. Again, this is temporary, once the installation has commenced and completed, Jamf removes it from that directory.
User Notification Setup
Notification settings are also sent through an MDM command, through a configuration profile with the notification payload configured. In the short clip above we walk through the steps of adding notification settings to the Zoom client.
In Jamf Pro, click Computers at the top of the sidebar.
Click Mac Apps in the sidebar.
Select the App you would like to setup notifications for.
Select the checkbox for Install supporting configuration profiles
Please note the message below the selection:
"Jamf Pro will automatically install configuration profiles with all required settings to successfully deploy this App Installer. These profiles cannot be previewed or removed."
Select User Notifications
Within this page you can modify the following:
Custom notification frequency
Custom notification message
Enable user deferral limits
Custom force quit message
We recommend giving an appropriate amount of time for both the notification frequency and the deferral limits. As well as enough description in the notification message for the end user to feel confident in the actions being taken. In this example, we are adding notifications for the Zoom client update. Given that Zoom meetings may take more than an hour, it may be advantageous to the end-user to set these limits at 2 hours or greater.
App Installer Logs and Configuration Profiles
Let's take a look at the logs and configuration profiles. First we're going to start with the app installer metadata.
App Installer Metadata
In Jamf Pro, click Computers at the top of the sidebar.
Click Mac Apps in the sidebar.
Select the App to see the App Installer Metadata
Scroll down to the App Installer Metadata section at the bottom of the page.
The following information is available at this point:
Application Name
Publisher
Bundle ID
Version
Package Publish Date
Architecture
Minimum OS
Media Source URL
Original Media Hash
Original Media Has Type
Package Size
Package Signing Identity
Installer Package Hash
Installer Package Hash Type
LaunchDaemon Included
Custom Notification Available
Built-in Auto-Updates disabled
A few notes on the information provided for the Zoom update that we've been following throughout the blog. From the information Jamf provides we know the package published date, when Jamf added this Zoom package to App Installers. We know that the architecture for Zoom is universal, which is very important, and we know the minimum OS is 10.10. In the center column we have the media Source URL, this is the URL that Jamf originally procured the package from. They include the developers media hash for the packaging hash type, they include their package size and they confirm that Jamf is the signing identity for this package since Jamf repackaged it. In the right column Jamf provides their hash, their hash type for security. You get the launch daemon, you can get your custom notification, and you get your built-in auto updates disabled. Auto-updates is important to note, the metadata is informing us that built-in auto updates is disabled. This is disabling the application's native auto update feature, allowing the Jamf app catalog and the app installer service to completely control the update workflow for said application.
Deployment Status
In Jamf Pro, click Computers at the top of the sidebar.
Click Mac Apps in the sidebar.
Select the App to see the Deployment Status
Select Deployment Status from the top of the page.
Looking at the Deployment Status is very straightforward. From the Deployment Status tab we can see installed in progress, failed, and unqualified. Unqualified is important to note, for Zoom, if a user happens to be running Mavericks or 10.9 you're out of luck, you can't get the latest version of Zoom. Another important thing to note is the logs for app installers, where are these?
Management Commands
Jamf made it very efficient in providing the information you're looking for when you want to look at computers deployment status and look at the logs. They take you directly to the management tab of their computer inventory record.
In Jamf Pro, click Computers at the top of the sidebar.
Click Mac Apps in the sidebar.
Select the App to see the Deployment Status
Select Deployment Status from the top of the page.
Select the computer from the list on the right.
This brings you to the Management tab of their computer inventory record.
This isn't necessarily where we want to look for all the logs but this will show you what's pending and failed. We want to look at the history tab and the management history to go over all the the logs that the App Installers actually pushed. In here you'll see a bunch of install configuration profiles, remove configuration profiles, you'll get the installed application list. These are all MDM commands that the app installer service is pushing. This is where you're going to want to look if something isn't installing or something's hung up or the application didn't update in the time frame you expected. Another important command to note is the actual installEnterpriseapplication command; here you see the zoom client for meeting version 5.13.10 is on the screen. If you've configured a computer to receive this and you're not seeing this install Enterprise application command for said application, this is where you're going to realize it that's a problem. "Okay, why isn't this sending?" Then you can rebuild the application app catalog and deploy again hopefully, figure it out.
Other Considerations
Some other considerations, regarding the Jamf app catalog, is the limitations. For example, if a computer is removed from the scope of an application payload you configured within the Jamf app catalog, it does not delete the app locally on the machine.
But, if the computer remains in scope of the application payload configured within the Jamf app catalog but the app is removed it doesn't automatically reinstall it. However, the next time the application is updated by Jamf, within the Jamf app catalog, it will deploy the app back to the machine and reinstall it. Currently there's no support for self-service and we also can't control when the deployment happens, so there's no custom trigger within the application payload like there is, for example, with a policy. Because this is an MDM command we can't use the Jamf binary to install everything.
This available on Jamf's website, in their Learning Hub. The list is consistently being updated.
Some notable applications that aren't available:
VPN Applications
Cisco AnyConnect
GlobalProtect
EndPoint Protection Applications
Crowdstrike
Sophos
McAfee
Other Applications
Druva
Q&A with Justin Clark | Director, Product Strategy - Jamf
"How do you ensure that the place you're pulling the package from is secure?"
Justin Clark: To give a bit of background to to what's happening, we actually have a bunch of automation that is running multiple times an hour that is hitting the vendors websites and checking to see if new versions exist. We then, first of all, pull that new media down through a security tool and then that gets checked for malware other exploits before it even hits our test environment. Once it hits our test environment the team pull that apart, create a new patch definition, and then publish that to our test instances. The media then gets converted into app installer media. We do an install and check that the patch definition picks up the new version. We then publish that version to patch, so you should actually see new versions appear in patch before you'll see them appear in app installers because of this extra testing that we have to do. Then the team do a couple of deployments with that app installer deployment, our test gear has security tools like Jamf Protect running on it so we can actually check that the live code is secure not just "let's see if there's any malware in it," and it's only after the app installer behaves as expected and that it's passed all the security checks that we will then publish it to app installers. So, generally the app installer deployment normally happens within a couple of hours of a patch definition being published, there's a lot of manual QA that happens.
"Will we be able to control when the application gets initially installed?"
Justin Clark: As you explained earlier in the presentation, because we're not using the Jamf management framework to trigger the installs, we're using MDM. We have to work around all of the constraints that MDM provides and one of which is we never know when the command is going to get issued to the machine, so we don't have the fine grain control over the installation experience that we do if we're using the Jamf management framework. Having said that, I've spoken to lots of customers and this is very common feedback that we we get, it is in our roadmap on how we could address this. I can't say today how we will or when we will but we are always looking at ways that we can provide more controls to the installation behavior while still working within the constraints that MDM gives us. So, not today.
"Will we be able to use this with self-service at some point?"
Justin Clark: Yes, I've already seen this pop up number of times in the chat. At JNUC last year during the keynote, we mentioned that self-service support would be coming to app installers by the middle of this year. We're on track, like everything with software development until that actually is shipping out the door, it doesn't exist. But, now that the end user notification UI is shipped it's pretty much what the team is working on, so. it will be the the next feature that comes with app installers is the ability to push an app installer deployment to self-service. The one thing that I will explain now is to help set the expectations around it, it's the behavior of the initial install. So you'll either be able to push an app out as you currently do via the smart group scoping or you will be able to publish it to self service for the opt-in install. From that point on, the rest of the workflow will stay the same. As in, once it's on the user's machine, app installers will keep it updated using the end user notification settings that you've published and that sort of stuff. It's that first step on how it gets to the user's machine. But it is coming, it will be here by media.
"What's the timeline for adding all 800 software titles?"
Justin Clark: The Jamf app catalog, to just add a little bit of extra context to a statement you made earlier in the presentation, the app catalog is our catalog of data about third-party software titles and their versioning. That feeds multiple workflows, so we've got the over 800 live titles in-app catalog that we use in our patch management feature area and then there's a subset of those which we use in app installers.
There are titles that we may not be able to add as as app installers, that we can add as patch management titles. There's a number of of different reasons for that; some of which are technical, some of which are not technical which I won't go into too much. But, we are continually adding new titles to that page that you linked to earlier which, not only does it have the complete list but we have a release history, so you can see what titles we add and when. We are focused on growing as many titles to be available in app installers as possible but we may not ever be able to have every title that we have available for patch management available as an app installer, unfortunately.
How do Apps (like zoom) deployed from Jamf App Catalog work if you have Zoom already deployed? Should you remove the configuration profiles deployed for the app before you deploy the Jamf app and it's configuration profile?
Should you remove / uninstall the existing app before you deploy the Jamf app and it's configuration profile?