Automating patch management policies with Auto-Update for Jamf

Introduction

If you are starting out with the open source jamJAR Jamf/Munki project, or are creating your first Auto-Update for Jamf policies but are not sure how best to structure your them, read on. In this post we will discuss some recommended workflows for three core scenarios and how we would handle them. 

What is jamJAR and Auto-Update for Jamf?

jamJAR is an open source solution to combine both Jamf policies and the installation skills and logic of Munki to provide a single offering to deploy software and updates to your devices. In true open source fashion, it provides the framework for you to build into, relying on some experience with Jamf Pro and Munki, as well as packaging applications (either manually or via AutoPKG).

Auto-Update for Jamf (AUfJ) is our paid offering where we take care of  the back-end configuration, application packaging and file hosting for 600+ common titles, allowing a Jamf Pro administrator more time for the other items on their to-do list.

General recommendations

Before we get stuck into the three scenarios, here are some general tips and recommendations:

Use a single policy per application title

We recommend using a different policy for each application title. This will result in an increase in the number of policies in your Jamf Pro instance, however it will also give you much greater control over which devices in your fleet can get specific applications. Additionally, it allows you to rush a rollout of a certain application or update for one title rather than all in a collective policy (more on that below).

Set these policies to a once every week frequency

We suggest any AUfJ policies are configured to run once every week via the ‘Recurring check-in’ trigger. This strikes a balance between deploying updates that are needed, while not pestering users too much. As devices are deployed and powered on at different times, each once-a-week policy will naturally stagger across different days of the week for each device, providing a natural sharding of new updates to give you time to stop the deployment should you find an internal incompatibility with the newest version.

On the flip side, if there is an update that must go out now (for example, we have loaded a new version of Google Chrome that patches some active exploits), you can flush the policy log for one or all devices, forcing them to cache and install the update next time they reach out to your Jamf Pro instance.

Make use of categories and policy names

Large numbers of policies in Jamf Pro can often become messy and lead to confusion, especially if you have multiple Jamf Pro administrators at the wheel. For this reason we strongly recommend using the Jamf Pro categories feature, as well as deciding (and sticking to) a naming convention for your policies. 

This is true of all Jamf Pro policies but, specifically for AUfJ policies, we suggest something like:

• Auto-Update Ongoing category
  • To store any policies that are set to run automatically and related to AUfJ. 
• Auto-Update Self Service category
  • To store any policies that are set to run via Self Service only and related to AUfJ.
• Auto-Update – [title name] for policy names
  • Using the above (or similar) naming convention for your AUfJ policies, to make it obvious what each policy does just from the title.

Workflows and recommendations

With the general recommendations provided, let us dig into the three scenarios you are likely to have with AUfJ.

Scenario 1: automatically deploy and patch a title for a group or list of devices

Imagine you have a specific title, for example Google Chrome, that you wish to be installed automatically on a group of devices and kept up to date. 

For this, we suggest using a single policy, scoped to the group (or list) of devices you wish to apply things to. We recommend a frequency of Once every week, and a trigger of Recurring check-in as per the above general recommendations.

Scenario 2: you wish to make a title available via Self Service, but also ensure it is patched

You have a specific title, for example Mozilla’s Firefox, that you wish to provide via Self Service to your users – but once installed you need it kept up to date.

For this, we suggest using two policies and a smart group:

• The smart group should pick up the devices that have Firefox installed. 
• The Self Service policy should be configured to target the group (or list) of devices you wish to offer the title to via Self Service, and be configured without a trigger (other then Self Service). We suggest a frequency of Ongoing.
• The last policy will be what is used to patch the installation; we suggest using the same policy as outlined in scenario one above but, instead of targeting devices, you would target the smart group created above.

Tip: if you want a software title to be in Self Service for some devices, and automatically installed for others, you can combine the patching policy for the Self Service devices and the policy from scenario one to cover both areas.

Scenario 3: you wish to only patch the title if found, not to offer it in Self Service or automatic installation

This one is a little unusual but might be something you see. If you do not wish to offer a title via Self Service, nor do you wish for it to be installed automatically – but a user has it installed, then you need to patch it.

For this one, we recommend a smart group and a patching policy as per scenario two:

• The smart group should pick up the devices that have Firefox installed. 
• The last policy will target the smart group created above.

Summary

We have covered some general recommendations, as well as three specific scenarios and the workflows we would suggest to achieve them. These workflows will work with AUfJ and should work for your own jamJAR solution (depending on how you have it configured). 

However you go about it, please keep your devices patched and protected.