When a new version of an application is available a package is built and a patch is sent to a test group, after a set delay the package is moved into production where everyone with the app installed gets a patch to update and our application install policy is updated. This excerpt from Tony‘s blog describes the essential process: It leverages the Jamf Patch Management system, which was not available when JSSImporter was developed. Unlike JSSImporter, which deliberately relies on Self Service, the goal of PatchBot is to apply patches to managed systems with no intervention by the user or admin. Tony Williams added a new entrant to the party earlier this year: PatchBot. It won’t be for everyone, but it does have a community built up around it for help.
There is a lot of depth in what has been provided by this tool, but it too requires a fair bit of initial setup and general understanding of both how Jamf Pro works and how JSSImporter works with Jamf Pro. To accomplish all this, it leverages the same API that the Jamf Admin app uses to interact with the Jamf Pro Server.
Additionally, the user has to install the software using Self Service, which is meant as a safeguard. Įssentially, this was intended to add some Munki-like functionality to Jamf Pro using Jamf Pro’s native tools (e.g., policies, smart groups, Self Service). The JSSImporter processor adds the ability for AutoPkg to upload packages to a Jamf Pro distribution point, and create scripts, extension attributes, computer groups and policies in a Jamf Pro server (the server formerly known as "JSS"), allowing you to fully-automate your software testing workflow. Because of that and some other dependencies, it requires an installer. It’s not a traditional shared processor it needs to be located in autopkglib, the same place all the core processors are located. JSSImporterĪnother option is using the JSSImporter processor with AutoPkg.
It is arguably the most powerful option available - commercial or not - and could be migrated should you choose to change to a different MDM platform. The human resources needed for Munki implementation and integration are the biggest hurdle - this was the path we were pursuing at my institution until some recent staff cuts made it too difficult to proceed.
The UK company dataJAR has distinguished their MSP by building their deployment business around this with some added integrations ( "Auto-Update for Jamf", “jamJAR”). Once choice is to deploy Munki and let it do the work, thus working around some of Jamf Pro’s weaknesses in this regard.
If we want to get the full benefit of AutoPkg with Jamf Pro, what choices do we have to integrate the two? I’m going to briefly discuss the four (great) Open Source options you currently have, and do a bit of a case study on the newest entrant, the JamfUploader series of shared processors. We are currently only taking advantage of those first two AutoPkg benefits: automating downloads and packaging. At my place of work, we adopted Jamf Pro as our management system. Some of you may even recall that I built a set of recipes for copying installer packages to the DeployStudio Packages repo, since that was my deployment system at the time. While AutoPkg was built for Munki, it was designed so that it could be extended to other management systems. Finally, you can get the full value of AutoPkg by having it upload those packages to your management system and automatically trigger their deployment using the methods required by that system. pkg format for deployment with that management system, so automating pkg creation is a time saver. Some also leverage its ability to post-process those downloaded items to make them more ready for deployment - Jamf Pro admins will be aware that everything needs to be in a. Some admins only leverage its ability to download the latest versions of the software you deploy in an automated, reliable fashion - that’s still a great value proposition.
AutoPkg is a tremendous tool for Mac Admins.