Disclaimer: I am not a Jamf Cloud customer, so I am not touching on whether or not App Installers is better, worse, or even comparable.
Until Jamf allows on-premise customers to use all aspects of Jamf Pro I can’t give any consideration to App Installers.

Overview of Jamf Patch Management

Jamf’s Patch Management is, on paper, a dream for an admin. Curated definitions of all versions for a given software. The ability to have one or more patch policies to distribute a given version to a given group. The ability to pop up a notification, then close the app and update it. When it’s described to you, it comes across as the perfect solution to keeping all of the apps in your fleet up to date.

And it can be, but out of the box here is the typical workflow.

  • Download an app or installer in .dmg or .pkg format
    • If a .dmg, use Composer or your favorite packaging tool to create a .pkg installer
  • Upload the installer package to your Jamf distribution point
  • Go to Patch Management and select the patch title
  • Go to the Definition tab, edit, and manually select the package that coincides with each or any version(s)
  • Save the Patch title, go to the Patch Policies tab and create or select the Patch Policy
  • Enter a patch policy name, select the version to deploy, decide if you want to prompt users to manually install the patch, add machines on the Scope tab, and customize the user interaction to suit your tastes
  • Move on to the next app on your list

That doesn’t sound too bad, if patching is your only job. But for the rest of us, you could be looking at 10-15 minutes of manual work per app. And it will need to be done for. every. version.
picture alt

Automating Patch

The key to improving Patch is automating everything we can. Package creation? Automate with Autopkg. There a ton of people who use and describe how to use autopkg, so I’m not going to get too far into the weeds on that. There are still more ways to automatically run autopkg from a script or from a repository. And if you use some obscure piece of software that isn’t Jamf’s patch catalog or you want to maintain your own definitions, well, there’s an autopkg processor for that too.

And that gets us to an advanced, autopatching workflow. Using autopkg, Graham Pugh’s JamfUploader processors to extend autopkg by uploading built packages automatically and updating patch policies, we can set ourselves up to automate the whole process.

Here is what those steps will look like:

  • Use autopkg search to find recipes
    • Write any recipes needed (i.e. .jamf recipes)
  • autopkg make-override for each .recipe
  • Modify the overrides with the variables we need for our own setup
  • Create templates for any policies/patch policies, and harvest any needed icon files
  • Run autopkg and watch your workload drop

Yes it takes time to set this all up, but the important part is this: Only the final step needs to be done repeatedly, freeing up your time for other tasks because you never have to touch Jamf Patch Management again only have to touch Patch in specific circumstances.

This is where PI111395 (updating the patch policies via the API has a different timing for when the patch policies recalculate their scope to then deploy) rears it’s head. So how is the timing changed?

Currently it can vary depending on various factors like the number of scoped devices or other patch policies running as well but in general, we’ve seen that the Patch Policies recalculate their scope the Macs update inventory AND THEN check-in. We could maybe speed that up by running 2 sudo jamf recon commands on the Macs.”1

So when do we need to manually touch patch policies? Well, for most patches, a slight delay in deployment isn’t the end of the world. For patches with CVEs or where there is a business need for the latest and greatest, there is a workaround: manually edit and save those patch policies in the gui.

TL;DR

Autopkg and the referenced processors can make your automated Patch workflow as simple as:

For multiple recipes, create a recipe list file with one per line and your automation can be as simple as a LaunchAgent running autopkg run -l recipeList.txt on a schedule. That’s it - autopatching with autopkg and Jamf’s Patch Management. I’m cheesy, so I call it autopatchg.

And here’s how it looks when complete:

% autopkg run Edge.jamf Sleep Edge.patch 

The following packages were copied:
    Pkg Path                                                                                      
    --------                                                                                      
    /Users/autopkg/autopkg/cache/local.jamf.edge/Microsoft_Edge_116.1938.23090676.pkg  

The following packages were uploaded to or updated in Jamf Pro:
    Pkg Path                                                                           Pkg Name                              Version    
    --------                                                                           --------                              -------    
    /Users/autopkg/autopkg/cache/local.jamf.edge/Microsoft_Edge_116.1938.23090676.pkg  Microsoft_Edge_116.1938.23090676.pkg  116.1938.23090676            

The following policies were created or updated in Jamf Pro:
    Policy                  Template                                                                   Icon      
    ------                  --------                                                                   ----      
    Install Microsoft Edge  /Users/autopkg/Library/AutoPkg/RecipeRepos/recipes/JamfPolicyTemplate.xml  edge.png  

The following patch policies were created or updated in Jamf Pro:
    Patch Id  Patch Policy Name  Patch Softwaretitle  Patch Version      
    --------  -----------------  -------------------  -------------      
    189       Edge ASAP          Edge                 116.1938.23090676

  1. This is literally all the guidance I got from Jamf to my support request asking about what I was seeing. If this affects you, please reach out to support and reference this PI. ↩