Some weeks ago a Jamf Patch Uploader user contacted Graham and me about a patching workflow, which he wasn’t able to deploy with the current processor design. AutoPkg is all about flexibility and not much was needed to make this workflow possible, so I am glad to present you a new feature in the Jamf Patch Uploader!

If you never used the Jamf Patch Uploader, read my other post first. I explained the usage and idea behind it in detail -> JamfPatchUplaoder: Automate Jamf’s Patch Management with AutoPkg

More control over Jamf’s patch deployment⌗

So far the uploader did two main steps:

  1. Link a previously uploaded package to the corresponding version - the so called ‘patch definition’.
  2. Create a patch policy to deploy the just defined version.

It’s now possible to simply skip the second part!

But what’s the use of this?⌗

Every admin (and his company) have different kind of needs in term of Patch Management. App Lifecycle Management is overall a rather complex topic - and a bit out of scope of this post - but it can be broken down to two main use cases:

  1. Deploy new software versions as fast as possible with as little work as possible.
  2. Deploy specific software versions after a specific date/time and have full control over this deployed version.

The second approach is mostly needed when you have some kind of testing procedure e.g. every new software versions needs to be tested by a specific group of people before you are allowed to mass deploy it. With the new update this approach is a bit easier to archive.

How to use the new feature⌗

First you need to update Graham’s repo including his Jamf Processors so you can use the new feature:


autopkg repo-update grahampugh-recipes

Beware that you also need to update your trust infos! Otherwise AutoPkg may refuse to run the new code (depending on your AutoPkg settings). Graham has an excellent article how to easily manage trust info: AutoPkg - verify and update trust information on all recipes in a recipe-list

The update doesn’t break any existing workflows. Also it doesn’t add any new parameters. To stop creating the Patch Policy, simply don’t define a patch_template in your recipe e.g.:

  - Processor: com.github.grahampugh.jamf-upload.processors/JamfPatchUploader
    Arguments:
      patch_softwaretitle: "%PATCH_SOFTWARETITLE_NAME%"
      replace_patch: False

This would result into the following:

Jamf Pro Patch Softwaretitle Firefox

Also the processor reports that no Patch Policy was created in AutoPkg’s summary:

The following patch policies were created or updated in Jamf Pro:
    Patch Id  Patch Policy Name               Patch Softwaretitle  Patch Version
    --------  -----------------               -------------------  -------------
    0         Not created - missing template  Mozilla Firefox      108.0.1

The idea behind this behaviour is, that you manage your Patch Policies completely by hand. Probably you have only one Policy which get’s deployed to all clients (excluding your testing group!) and defines the productive software version. If you want to change that version, simply edit the Policy and select the new version. Since the Processor links the Patch Definitions, all versions should be available right away. At least when you regularly run AutoPkg ;)

Why not deploy disabled Patch Policies⌗

Maybe you already used a similar workflow, but with the old version of the Processor. For example simply by creating disabled Patch Policies and only enabling them if needed. When you also set replace_patch: False in your recipe, AutoPkg would also not alter your edited policy.

The result would be nearly the same, but you would end up with many Patch Policies, since AutoPkg would create one for each version. With the new workflow you could keep your Patch Policies cleaner and your Jamf Pro instance probably a bit happier :)

If you have further questions just let me know and contact me on Slack!