Introduction

App Auto-Patch combines local application discovery, an Installomator integration, and user-friendly swiftDialog prompts to automate application patch management across Mac computers.

What’s Changed in App Auto-Patch (2.0.0)

For an up-to-date view of what’s changed, feel free to check out the change log at: App Auto-Patch Changelog

🚨 Breaking Changes for users of App Auto-Patch before 2.0.0 🚨

• The unattendExit variable has been moved outside of the Jamf Pro Script parameters. If you desire to change the default setting for this variable, you can find it under the ### Unattended Exit Options ### heading in the script.
• The outdatedOSAction variable has been moved within the Jamf Pro Script parameters from Parameter 9 to Parameter 10, make sure to update your Jamf Pro policies accordingly.

Added deferral options

Huge thanks to @TechTrekkie for adding this workflow to App Auto-Patch!

There is a new heading in the App Auto-Patch script labeled ### Deferral Options ###.

• maxDeferrals – This variable by default is set to Disabled. If you would like to enable deferrals for end users then this will need to be changed to the maximum number of deferrals you would like to offer. Once the maximum number of deferrals has been reached, App Auto-Patch will continue to its updating dialog. To use this option, you will need to have interactiveMode set to either 1 or 2.
• deferralTimer – This is the number of seconds given to the end user to respond to the deferral prompt before the deferralTimerAction is triggered.
• deferralTimerAction – This is the action that takes place once the timer has expired, either Defer or Continue. Defer is currently set as default.
• AAPActivatorFlag – If you are utilizing the new AAP-Activator script workflow within your Jamf Pro setup, this variable should be set to true. More on AAP-Activator below.
• aapAutoPatchDeferralFile – This is the location of the App Auto-Patch Deferrals plist.

AAP-Activator

https://github.com/robjschroeder/App-Auto-Patch/tree/main/AAP-Activator

If you are using deferrals with your App Auto-Patch setup, the policy within Jamf Pro will need to be run again to prompt the user for their updates and give them to option to defer once again or continue. This can be achieved by setting your policy to run weekly at recurring check-in. Another option, however, is to use the AAP-Activator script. This script works in tandem with App Auto-Patch and is meant to trigger AAP under the right conditions.

*Note* AAP-Activator requires App Auto-Patch version 2.0.0 or later.

Configuration Variables

This script writes two variables to a configuration file:

• AAPWeeklyPatching (True | False) – Used to determine if the patching process has been completed for the week. A value of False means the Activator will trigger AAP to run, and a value of True means it will be skipped
• AAPWeeklyPatchingStatusDate (datetime) – This gets populated with the date/time the Activator script first executes and is used to calculate how many days have passed since that weekly patching period started. Once 7 days have passed, the AAPWeeklyPatching status is reset back to False to restart the weekly patching cadence

Configuration

The APP-Activator utilizes the existing AppAutoPatchDeferrals.plist configuration file created in the App-Auto-Patch script and works regardless if the deferral workflow is being utilized or not

Two values are set in the config file:

AAPWeeklyPatching (True | False) – This is set to False by default which signals AAP-Activator to trigger the App-Auto-Patch script AAPWeeklyPatchingStatusDate (datetime) – This gets set with the date/time that AAP-Activator first runs and is used to calculate how many days have passed for a weekly patching cadence

Setup

1. Set your App Auto-Patch Jamf Policy to a frequency of “ongoing” and set a custom trigger (ex: AppAutoPatch)
2. Import the AAP-Activator Script to your Jamf Pro instance and set the Jamf Pro Script parameter names to match Parameter #4 and #5 from the script (#4: Log Location, #5 AAP Jamf Policy Trigger)
3. Create a Jamf Pro policy that uses the AAP-Activator Script
   • Set the Trigger to Recurring Check-In
   • Set the execution frequency to Once Every Day
   • Populate Parameter #4 with your log location
   • Populate Parameter #5 with the App Auto-Patch policy trigger from step #1
   • Populate Parameter #6 with The number of days until the activator resets the patching status to False (for a weekly reset, set to 7)

New Deferrals Remaining extension attribute

There is now a new extension attribute available to display how many deferrals an individual has left before App Auto-Patch will automatically continue. Thanks @andrewbarnett for this EA!

Script Cleanup and Organization

Version 2.0.0 has been re-organized and cleaned up. This should provide a much easier experience for MacAdmins to parse through and make customization that fit their organizational needs.

swiftDialog install now dependent on interactiveMode setting

If App Auto-Patch interactiveMode is set to 0, the Pre-Flight portion of the script will skip the function that checks and installs swiftDialog. If interactiveMode is set to 1 or 2 the function for swiftDialog check and install will continue as normal.

Added optionalLables parameter

The parameter has moved into Parameter 9 under the Jamf Pro Script parameters. This option will give MacAdmins the ability to define Installomator app labels that may not be required to be installed by the organization, but if it is installed, go ahead and update it. For example, an organization may not require GitHub Desktop installed on all their computers, but if it is installed, they would like it to be up-to-date. Adding the label githubdesktop to this new parameter will check to see if the application is installed and if so, add it to the list of apps to update.

Getting Started

1. Download the latest App-Auto-Patch-via-Dialog.zsh script to your computer. The latest version can be found here: https://github.com/robjschroeder/App-Auto-Patch/blob/main/App-Auto-Patch-via-Dialog.zsh
   • If you’d like to use Terminal to download a copy and save it to your Downloads, open Terminal, and paste in the following command:

curl -o ~/Downloads/App-Auto-Patch-via-Dialog.zsh https://raw.githubusercontent.com/robjschroeder/App-Auto-Patch/main/App-Auto-Patch-via-Dialog.zsh

2. Feel free to make any modifications to this script to fit your organizational needs.
3. Upload the script to Jamf Pro (or your current MDM, but we’ll be talking about Jamf Pro here as that is what I use). The current parameter labels are as follows:
   • Parameter 4: Script Log Location [ /var/log/com.company.log ] (i.e., Your organization’s default location for client-side logs)
   • Parameter 5: Toggles swiftDialog to use an overlay icon [ true (default) | false ]
   • Parameter 6: Interactive Mode [ 0 (Completely Silent) | 1 (Silent Discovery, Interactive Patching) | 2 (Full Interactive) ]
   • Parameter 7: A space-separated list of Installomator labels to ignore (i.e., “firefox* zoomgov googlechromeenterprise nudge microsoft*”)
   • Parameter 8: A space-separated list of required Installomator labels (i.e., “githubdesktop”)
   • Parameter 9: A space-separated list of optional Installomator labels to update if installed on the computer.
   • Parameter 10: Outdated OS Action [ /System/Library/CoreServices/Software Update.app (default) | jamfselfservice://content?entity=policy&id=117&action=view ] (i.e., Jamf Pro Self Service policy ID for operating system upgrades)
4. Once your script is uploaded to Jamf Pro, the next step is to create a policy.
5. In your policy, add the script payload and select the App-Auto-Patch script that was uploaded to Jamf Pro. You should be able to fill out your parameter labels to make sure you get the desired result of the script.
6. Optionally, you can make the policy available in Self Service for end-users to run on their own time.
7. After you have the policy set up as you’d like, feel free to test it out.

Silent Scans

App Auto-Patch has the ability to silently scan the computer for applications and their updates. To perform a silent scan, use the Interactive Mode option set to 1. This will set the script to run a silent discovery and will still show a dialog to the end-user, notifying them of the update statuses.

Extension Attributes

Version 2.0.0 offers some Extension Attributes that can be used to gather some more information on App Auto-Patch. Currently, there are three EAs available:

1. AAP-LastDiscovery
   • This will return a date and time that the last discovery was run using App Auto-Patch. There is an option in the script to use the runDiscovery variable to skip the discovery process. This EA will help you to make sure your data isn’t outdated.
2. AAP-LastRun
   • This will return the date and time of the last run of App Auto-Patch.
3. AAP-Verison
   • This will return the version of App Auto-Patch that was last used.
4. AAP-DeferralsRemaining
   • This will return the number of deferrals remaining for the user.

Extension Attributes are powerful and can expand upon the workflows that a tool can utilize. I will look to expand these in the future and if you have any recommendations, feel free to reach out.

Updates

Interactive

During the update process, a dialog window can be presented to the end-user letting them know the status of each application. By default, we show this to the end user. Once all updates have been processed, the “Done” button is made available to exit out of the dialog.

There are additional options in the script that can be modified to control Installomator’s install options. (i.e., BLOCKING_PROCESS_ACTION, NOTIFY, and LOGO).

Silent

App Auto-Patch can also be run completely silently in the background if that’s what you would like to do. Again, this is achieved by changing the default behavior of interactiveMode. When this variable is set to 0, App Auto-Patch will run silently. This may be helpful for administrators who want to make sure apps are patched but don’t need to send the updates to the end users.

*Depending on your Installomator options, users may still see prompts to close the apps that need updates, if they have them open. If you don’t want any notifications at all, change out the BLOCKING_PROCESS_ACTION variable.

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 Barnett (@andrewmbarnett)
• Trevor Sysock (@bigmacadmin)
• Charles Mangin (@option8)

Support, Feature Requests, & Issue Reports

Support

The #app-auto-patch channel on MacAdmins Slack is a great resource to use when getting started.

Feature Requests

Feature requests are welcome and can be submitted on Github

Issue Reports

If you find something not working quite right, you can reach out on the MacAdmins Slack channel for App Auto-Patch. Additionally, issues can be submitted on Github