JNUC (for those that may not know) is the Jamf Nation User Conference. It is Jamf’s annual event to showcase what is new for Apple MDM management and for other Jamf administrators to show how they are using Jamf in their unique environments. 

The Jamf Nation User Conference is not a sales expo or a tradeshow. Instead, it’s a welcoming, three-day rally of community and Jamf-led presentations, deep-dive education sessions, and expert product insights to discover new and better ways to manage Apple devices with the purpose of empowering people, transforming business processes and making IT life easier.

I was allowed to present at this year’s JNUC in Nashville. This was the second time I’ve presented at JNUC and it was just as exciting this time as it was in San Diego in 2022. It was a great opportunity to see some old friends and meet some new ones. Thanks to everyone at JNUC that I was able to meet and speak with during the conference, and to all those that attended the App Auto-Patch presentation.

As mentioned above, the presentation that I was able to give was on the subject of App Auto-Patch: Hands-Off Application Updates. For this session, I was able to invite another App Auto-Patch admin to co-present, so special thanks to Andrew Spokes for helping out with the session. Next, we will dive into the content of that presentation.

Video

Overview

This project began with a challenge: managing and patching an environment with over 2,500 application titles, many of which were either unknown or difficult to track. 

App Auto-Patch is designed to simplify and automate the entire app patching process for Mac Admins. It streamlines what can often be a time-consuming and manual task, turning it into something that is both efficient and scalable. 

This tool integrates seamlessly with Jamf, leveraging tools like swiftDialog for user interaction and Installomator for application discovery and patching. 

App Auto-Patch was heavily inspired by Patchomator, and at its core, it uses Installomator to access a large repository of applications. With App Auto-Patch admins can easily customize patching requirements based on the specific needs of their environment. 

Ultimately, the goal is to provide a solution that not only addresses the complexity of patching large environments but also gives Mac Admins a more automated and reliable way to maintain security and compliance. 

App Auto-Patch has three main phases to function:

First is the Discovery Phase: The script checks installed applications against installomator labels, comparing versions to determine if updates are needed. Applications with newer versions available are queued for updates. This phase also compares the list of queued apps against app label variables to add/remove labels as needed.

The Second Phase is the Deferral Check: The script checks if deferrals are enabled. If so, prompts are displayed using SwiftDialog to display the list of apps that need to be patched and the number of deferrals remaining. 

This function also checks for any display assertions such as screen sharing, and can automatically defer if needed.

Finally, the Installation phase is executed. Any applications that are queued will download and install updates.

App Auto-Patch Workflow: Detailed diagram of the steps that the script follows.

Variables and Configuration

End-User Experience

Now, let’s dive into the End-user experience with App Auto-Patch. We’ve designed it to be flexible, offering three different behavior modes to suit various environments and user preferences. 

The first option is the `completely silent` mode. In this setting, the script quietly runs in the background, discovering and patching applications without any user interaction. This is ideal for scenarios where minimizing disruption is key. 

The second option takes a hybrid approach. App discovery happens silently in the background, but if an update is required, users are notified with the option to defer the installation. This mode strikes a balance between keeping users informed and giving them some control over when updates are applied. 

Finally, we have a Fully Interactive mode. Here, users see everything — app discovery, deferral options, and the patching process. This mode is perfect for environments where transparency and user awareness are priorities. 

Each mode is designed to provide the right level of interaction depending on the organization’s needs, ensuring that patches are applied efficiently without unnecessary interruptions. 

Let’s take a look at what the end-user experience looks like during the app discovery phase. 

In this demo, we’re showing Fully Interactive Mode in action. As you can see, the dialog displays each application that’s being discovered and analyzed in real time. This gives users full visibility into the process, ensuring they’re aware of what’s happening on their machine.

One nice feature of this mode is that users have the option to minimize the dialog if they prefer not to monitor the process. This way, it stays out of their way while the discovery continues working in the background.

Now, let’s move on to the deferral prompt. If deferrals are enabled and App Auto-Patch detects applications that require updates, users will see this prompt.

The dialog lists all the applications that need updates, allowing users to save their work before proceeding with the installation. This ensures users can prepare for any potential disruptions.

It also shows the number of deferrals remaining and includes a countdown, letting users know how much time they have to make a decision.

By default, if the user doesn’t choose before the timer expires, the system will automatically defer the update—if deferrals are available. Otherwise, it will move directly into the installation phase.

Lastly, let’s talk about the installation phase. In this phase, users are shown a dialog that displays the list of applications being patched, along with real-time updates on the download and installation status for each app.

If any of the updates fail, the dialog will display the failure status next to the affected application, so users and admins are aware of any issues that might need attention.

This phase provides transparency, keeping users informed as their apps are updated, and ensuring they know what’s happening throughout the entire process.

App Auto-Patch Configuration

Installomator App Label Categories

As mentioned before, App Auto-Patch scans for apps matching all possible labels but allows for a tailored approach using the Ignored, Required and Optional label categories. 

For ignored labels, any matches in this list will be ignored. This category accepts wildcards. For example, you can include the word Microsoft with an asterisk afterwards which would ignore all labels that begin with Microsoft. Additionally, you can add a single wildcard to this category to ignore all apps, letting you pick and choose using the Required and Optional category. 

For Required labels, any labels added to this list will be force installed or updated, regardless if the app is installed or not. This can be beneficial for required business apps that need to be installed, even if a user were to remove it, intentionally or not. 

Optional labels will Install or Update applications only if the app is installed. This category comes in handy for the scenario of ignoring all applications, and patching only a set list of applications only if they exist on the device. 

Jamf Pro Parameter Variables

When adding the script to Jamf, there are a set of variables that use Jamf Parameters to more easily customize patching scenarios. 

Parameter 4 sets the interactive mode: 0 for silent, 1 for Silent Discovery and interactive patching, 2 for completely interactive

Parameters 5, 6 and 7 are for the three Installomator Label categories: ignore, required and optional

Parameter 8 allows for a space-separates list of options to override the default Installomator options such as the blocking process action and installomator notifications

Parameter 9 is for setting the deferral mode. The default is disabled, but setting to an integer will enable the deferral mode and set the maximum number of deferrals.

Feature Variables

Within the script contains several feature variables that can be hard coded, the majority of which are deferral options. 

Deferral Timer: This sets the amount of time in seconds given to the user to respond to the deferral prompt

Deferral Timer Action: This determines what happens at the end of the deferral timer, if there are deferrals remaining. You can either set it to auto-defer, or to continue on to the installation phase

The next two variables are based on two calculated values: Patch Status and Patch Start Date, which are useful for a patching cadence. 

For example, lets say you want to run everything based on a weekly patching cadence, meaning users need to successfully patch apps at least once every week.

Patch Status: The Patch Status is a true/false flag indicating if patching has been completed or not for the patching cadence. 

Patch Start Date: The Patch Start Date is the date the patching cadence begins, which is set the first time the script runs

Going back to the variables, The first is the Days Until Reset: This indicates the number of days after the Patch Start Date to reset the Patch Status to False

Patch Week Start Day: This allows to you set the Patch Start Date to a specific day of the week, allowing you to keep everyone on the same patching cadence. For example, If you had this set to 3, the patch start date would be set to the most recent prior Wednesdays date, so if a Mac is offline for a few days and the script runs for the first time on a Friday, the start date would still have that prior Wednesdays date. 

Next up is the Max Display Assertion Count which sets the number of times deferrals are allowed for Display Assertions such as screen sharing.

Webhooks

We’ve included feature variables that allow you to add a webhook URL for services like Slack or Microsoft Teams. This enables real-time notifications, so every time App Auto-Patch completes a cycle—or if any failures are detected—your team will be immediately informed.

These notifications are a great way to stay on top of patching activities and quickly address any issues without needing to manually monitor the process.

Here is an example of what a Slack Webhook notification looks like for a successful run. This shows the computer info and the applications that were updated. Clicking the button will open the computers inventory record in Jamf. 

Additional Variables

App Auto-Patch also offers a range of additional variables and customizable configurations to give admins more control over how it operates.

For example, one option allows you to automatically pull the latest version of the Installomator script based on the version date. This ensures you’re always using the most up-to-date app label logic without manual intervention.

There are also options for handling apps located in a user’s home folder. You can either choose to ignore these apps entirely or convert them to their default path for easier management.

All of these configuration options are fully outlined in the Wiki on our GitHub repository, so you can customize App Auto-Patch to fit your organization’s specific needs.

Getting Started with Jamf Pro – Policy Configuration

To get started with setting up App Auto-Patch, You’ll upload the script and set the parameter labels. 

Next you’ll create a new policy and configure your general payload options: Display Name, trigger, execution frequency. I usually set mine to a recurring check-in for once a day. 

After that you’ll configure the script payload to use the App Auto-Patch script you uploaded, and then set the parameters for the script for how you want it to function. 

Finally you’ll set your scope and test. Now if you’re using deferrals and testing, when you complete patching it’s going to set that patch completion status to true, so what you can do is either set the value in the PLIST to False, or just delete the status PLIST altogether and let the script re-create it next time it runs

Example Jamf Policy with script parameters configured for Silent discovery/Interactive Patching, a list of app labels to ignore, some standard Installomator Options and Deferrals set to 2.

Future Development

As we continue improving App Auto-Patch, our focus is now shifting toward the next major version.

We’re looking to introduce even more features that enhance automation, expand app compatibility, and provide deeper integration with other tools. We’re also gathering feedback from users and contributors to help shape the direction of future releases.

Our goal is to keep refining the patching process, making it more efficient and customizable for Mac Admins, while continuing to provide a seamless and secure experience for end-users.

The next Major version will be Version 3.0 which will include several enhancements for both the end-user and Mac Admin:

3.0 can be managed using a Configuration Profile, either deployed via MDM or locally. You will also be able to configure settings using command line triggers.

3.0 is MDM Agnostic, allowing you to deploy it to devices and have it run independently. A LaunchDaemon will be used to for all automation and scheduling. There will still be the option to trigger it via Jamf Policy like 2.x if needed, but the LaunchDaemon will take over so the Jamf Binary isn’t tied up running the process. 

3.0 has enhanced deferral options, allowing you to defer by count or days and customize deferral and dialog timeouts.

Thank you! I hope you found this session on App Auto-Patch informative and valuable. Feel free to reach out with any questions, and don’t hesitate to explore the resources we’ve shared. 

Thank you to everyone who has helped contribute to App Auto-Patch, including but not limited to:

Dan Snelson (@dan-snelson)
Andrew Spokes (@TechTrekkie)
Andrew Clark (@drtaru)
Andrew Barnett (@andrewmbarnett)
Trevor Sysock (@bigmacadmin)
Bart Reardon (@bartreardon)
Charles Mangin (@option8)

And special thanks to the Installomator Team
Armin Briegel (@scriptingosx)
Isaac Ordonez (@issacatmann)
Søren Theilgaard (@Theile)
Adam Codega (@acodega)