Automating patch management with PatchBot and Jamf Pro

Jamf’s customers love to leverage automation in all forms to reduce clicks, manual steps and processes. Tony Williams is a Jamf administrator who creates tools leveraging Jamf frameworks and makes them available for the community to download. Read more about his path to a patch workflow.

The package lifecycle

Once you install an application across your fleet, the work has only just begun. You now have to keep that application up to date, which in turn requires discovering, building and deploying application packages for each new version and deprecating the old ones. I call this collection of activities the package lifecycle.

Monitoring that lifecycle and managing application packages was my close study for several months while I built some software tools to make managing it easier. My tools leverage Jamf Pro Patch Management, the Jamf Pro API and AutoPkg:

• Patch management: a feature of Jamf Pro that ties a package to an application version and makes it available in Self Service on any Mac that is running an earlier version of the application. Patch management also includes some useful version tracking across the fleet.
• Jamf Pro API: allows me to write Python scripts to perform any number of tasks rather than doing them manually.
• AutoPkg: an “open source automation framework for macOS software packaging and distribution, oriented towards the tasks one would normally perform manually to prepare third-party software for mass deployment to managed clients,” to quote its website. At its core it is used to build the packages, but people have also written add-ons to perform other tasks.

The existing add-on (or processor, in AutoPkg parlance) for integrating AutoPkg with a Jamf distribution point is jss-importer. I’ve written a replacement for two reasons. The first is that when I set out to build my first management system, jss-importer could not upload to a cloud repository. The second is that jss-importer was designed and built around a system of using policies and smart groups to deliver patches to the users, and now Jamf has patch management softwareto perform that work more easily.

How does it all work?

PatchBot starts by building the packages and uploads them to Jamf Pro. At the same time it saves the package details in a policy called TEST-<title> (where <title> is the name of the application).

Once packages are uploaded, it’s time to start patch management:

Step 1: Find the version definition for the new package and get it pointed to the package, then update a patch policy Test <title>. This patch policy is scoped to a single group regardless of the application; I call mine Package Testers.

Step 2: Move a package from test into production. This is done seven days after it is moved into test using a production patch policy scoped to all computers and a self-service deadline of seven days. Both the delay before moving patches into production and the self-service deadlines are easily changed on a per application basis. At this point PatchBot updates the install policy for the application so it uses the new version. This automatically deprecates the old package.

Step 3: There is no step 3.

We now have a patch package in production and an updated install policy. At no stage have we had to do a thing. The only human intervention we might need is halting the shift from test to production if our testers discover a broken package. That requires editing a single patch policy.