How does your organization handle patch "early adopter" groups?

New Contributor II

We have been looking for a straightforward way to achieve a solution to the following:

  • Patch "Early release": Day 0-1 of patch
  • Patch "Test group": Day 3-5 of patch
  • Patch "Wide release": Day 7 of patch

The idea is that you would have a controlled population to test patches against instead of pushing a bad patch to everyone at once. In Patch Policies, it appears it would have to be a matter of manually going in and editing the scope on those three targets. Once to include the first group, second to add the second group, and final edit to make availability all systems.

Otherwise, the way we see this could be done is by creating multiple policies outside of Patch Policy to handle this, by defining multiple "Activation dates" for the policies. This would lead to a massive expansion of our policies list and would lead to extra work for the content creator in addition to losing out on functionality found in the Patch Policy module.

So, question: How does your team most effectively manage these patches? Do you use Jamf and one of the identified solutions listed above, or do something different? Or, do you use an outside tool (a la BigFix) to handle 3rd-party patches?

Any help would be greatly appreciated!


Valued Contributor

You are definitely on the right track:

We are a Private School and follow this schedule

We Use a Rolling CAB , with the option for an eCAB for anything that requires a restart/reboot ( Mostly OS Security Updates and "Point" releases). eCABS get a site wide notification regarding the required reboot/restart

Patch "Canaries": Day 0-1 of patch - 6 Users
Patch "Testers": Day 7 of patch - 30 Users
Patch "Production": Day 15 of patch - 400 Users

"Canaries" are the Immediate IT Staff

"Testers" is a volunteer group, however they sign an agreement with the understanding that they will test and report any issues. No response is understood to mean there are no issues.

We currently use a combination of Autopkg w/Jenkins, Reposado and Munki w/Git for patching

IT has worked well and we are currently prepping for a Mojave rollout


Valued Contributor II

@sjmosher We're using a combination of AutoPkgr and Jamf Pro for our patching.

My favorite feature of Patch Management Software Titles is that a single title (i.e., Enterprise Connection) can have multiple Patch Policies (i.e., we distribute to "Beta Testers" via Self Service and "Automatically" to everyone else once the new version is approved; see attached.)

Also, the following may prove helpful:
Your Internal Beta Test Program: Opt-in / Opt-out via Self Service