Goal of the script

Current patch management solutions, unfortunately, do not offer a unified approach where both scripts and packages can be used interchangeably.

• With JAMF Pro's own Patch Management, only packages can be utilized.
• When using Jamf App Catalog, the user receives individual prompts for each application to update them.
• Distributing updates through a policy results in the user either receiving separate notifications for each application or having the update distributed in the background. However, the problem here is that the user lacks information about what is happening, and if the application is closed, it is not apparent to the user whether it was closed due to the update or if it crashed.
• Distributing InHouse applications is usually not possible via either a script or Jamf App Catalog. In such cases, resorting to Jamf Pro Patch Management becomes necessary. Unfortunately, all these options do not offer a consistent approach when patching an application.

The script "Patch Helper" is designed to inform the user about available updates for the device by displaying a message that lists the applications to be updated.

Function of the script

As soon as the script starts, it will first check, using the API user, which policies are available for the device. Please check what permission the API user needs. Api User and privilege set

After the script has pulled the list of which policies are available for the device, it separates the policies that are available with the custom trigger patch_app_updates and writes the ID'S of each policy into an array.

In addition, the number of times patch_app_updates occurs is also counted. If no policies with the trigger patch_app_updates occur, the script is terminated and the user does not notice anything.

Based on the Bundle ID defined in the configuration profile icon_service.json, the system checks whether the application is currently running.

• If the application is not running, the policy is executed silently in the background, and the user is not notified.

• If the application is running, or the Bundle ID is set to "None", the application is added to the JSON file for processing steps.
  In this case, the user will be guided through the update process via SwiftDialog.

This procedure is applied to each detected application individually.
If all policies are executed in the background (i.e., no user interaction is required), an inventory update is performed at the end without user notification, and the SwiftDialog window is not shown.

Once the script starts, the script waits for the user's action whether to install it now or postpone the update. The script waits for a time defined by the administrator.

For information about the available variables, please see here MDM: JAMPF PRO.

If no action is taken by the user within this time, the script is automatically postponed. If the script is postponed, a LaunchDaemon will be created that will restart the script at the interval specified by the system administrator until the user has installed the updates or the count has reached "0".

When the LaunchDaemon is started, it executes the command /usr/local/jamf/bin/jamf policy -event update. This executes the policy that is only started by the LaunchDaemon.

Once the user has installed the updates, the LaunchDaemon is terminated and deleted from the client. The user will be informed about the pending updates again when the Policy Patch Helper is started.

No matter how many policies are executed, the inventory is always transmitted to Jamf at the end, so that the correct version of the application is displayed in Jamf and so that each policy does not transmit the inventory individually. If not every policy sends the inventory, the policies will be executed faster.

Creating the "Patch Helper" Policies

In my case, I created two policies with the same script:

• 1 . The first one, which is started regularly at the interval defined by the administrator.
• 2 . The second, is started by the LaunchDaemon when the user has moved.

The first policy is created so that it is

• executed at the Recurring Check-in
• and as Execution Frequency Once every day

So that the user is not notified daily that there is only one update, I have set the "Client-Side Limitation" so that the policy starts only on certain days and only during working hours.

The second policy is configured as follows:

• It is triggered using the Custom trigger update.
  The trigger name can also be set via the profile and configured using the DaemonEventTrigger key.

• The Execution Frequency is set to Ongoing.