Hi Jamf and everyone,
Long time jamf user here, looking to reduce the amount of manual labor for packaging and deployment of packages through jamf. Jamf, can do a lot of powerful things, it can execute code, deploy configuration profiles over MDM, plugin into IdP/LDAP and use that to calculate scope, etc. Packaging has always been a manual process on the jamf end, and patching and updating has always been a bit labor intensive. While, the policy model in jamf is pretty great at accomplishing tasks, and executing workflows, I think there could be a more efficient way to deploy and manage apps.
At the end of the day, what we are really trying to accomplish (in my opinion) is the state of each application on our client end points. We want to make sure that Application Foo, is installed and is version Bar. To do this now in jamf you have to probably create smart groups by application version, you have to maybe chain a few policies together, you have to maintain those policies and groups (tech debt) and it makes it more complex to automate through jamf's API. The more API end points you must control to build a workflow, the more complex automation becomes. This is definitely not to say it isn't possible to automate packaging and deployment of packages. I currently have a workflow at my current job doing this (AutoPKG virustotal + ongoing policies in jamf that patch the software). Now, this workflow works, and I have yet to even build a single package manually since I started this job (previous engineer did pretty much all the work, it existed before I started - cheers Nick!) However, I have always thought this for many years that is just not the best approach and we can do it better.
The idea behind this FR, is that jamf could actually stop using
policies for software deployment all together. Instead, of using policies, or patch policies, we could look at building an application catalog and using application state model as means of deploying, updating, patching, and even rolling back apps to our Mac fleets. The idea would be that each application is an object in the JPS. So,
Firefox would be an object. With in that object are all the deployment options, meta data, and packages with versions of what you want to deploy or maintain currently.
A horribly done diagram:
In the very poorly done, and probably confusing diagram above, I am trying to illustrate visually, what the Application object would look it. I believe Apple does this in the App Store by a
family_id where it maps versions of apps to a parent ID, making their app catalog. I could be wrong, did not get much google searching that specific data. So, instead of every touching a ton of policies and smart groups and so forth, you simply put all the data into an app catalog. This means all app deployment options are in a single end point in the JPS.
So, ideally, when automating this stuff in the JPS, you can hit a single end point in the API, like for example perhaps this:
Since you are posting that PKG into an existing App catalog, that new PKG would inherit all the already defined settings of that object in the database. Also, if this info were stored at the object level in the JPS, you might never actually ever have to change the Self Service description, because that meta data would be stored and Self Service could just
GET request it and populate the UI. Making automation easier, because you aren't injecting text, in every self service policy you have ever created for Firefox.app. Some of you may have
Uninstall policies that flip buttons and rely on smart group calcs and recons for the Self Service UX to work as you deem fit at your Org. That means you would have to touch all those policies in your automation workflow, making it more complex, and harder to sustain.
Some other benefits of moving to a state model could also mean, querying the local device versus keeping the JSP as the source of truth. Since how jamf is currently designed, it will only go off the inventory data server side, and we all know clients drift in application state. That is just a fact, and there is no denying it. At scale, you aren't going to run daily recons, it just is not possible because recon is just too expensive of a cost resource wise. So, you end up doing things like cascading recons, or recon on state change (like apps installed via Self Service) and just hope users do not install apps 10 times in a row across your entire fleet, thus generating 10 recons per a device at once. So, being able to query the local state of the device would greatly increase scale-ability, and reduce overhead on the JPS server infrastructure as well. Not to mention, all the data is already there, and so many users install their own apps.
So, lets toss some scenarios of workflows and better UX this could possibly gain.
user installs their own version of Firefox off the internet, and perhaps they somehow install either an older version that has known CVEs against it, or the newest version which has known bugs that breaks integration with web mail (look it's a stretch but hear me out lol). So, you simply set the application state of Firefox to the known good version, that also does not have those CVEs tied to it. It no longer matters where the end user got Firefox from. It could be the Internet, they could have got it from Self Service a year ago and never updated it, but with an application state model, the jamf binary can check and validate you are running an unwanted version of Firefox and automatically install the proper one. This is because you set the application state of Firefox to be the version you wanted to deploy. The rest is done by the agent and jamf's logic. No smart groups, not chaining policies, just the app catalog setting the version you want.
Automating this on the Engineering side. Classically, you must build your PKG in Composer (or desired pkg builder tool), upload the PKG to your Distribution Points (or use Capser Admin), then go in and manually click on the UI to create a bunch of policies. Imagine if that were just all one single object in the JPS? You create a Firefox, or Adobe Flash (Crom help you if you still deploy flash) objects, then you just upload the PKGs to that object, and all the scoping and rules and meta data are tied to that object and both jamf an Self Service can access that data. This means your workflow now goes to:
build PKG (with your preferred tools) + automation code to post PKG to API + there is no step 3
This is because you have already built all the logic, options and scope into the App object in your App Catalog, and your packages just inherit that. Think of it like software classes and inheritance
Uh oh, here is a bug! Somehow, you missed a bug and deployed a broken app to your fleet. With an application state model you just could select your previous version (the known good one) as the active app that should be deployed and jamf could magically take care of the rest. Right now you would have a few options, none of them great. Create a smart group for that bad version and then scope a policy against that smart group to blast back the working version of the app. Another way could be write a script and deploy to everyone, in the code logically check for app version, if bad version found, execute code to a manual trigger policy to put the proper version back. Also, at large scale you are not attaching a recon to that, you are going to push out your script and then wait for recon to run at a later time. Most security, compliance and auditors do not like this, haha, but you can do it that way. With an Application state model, you would just set the state back to what you wanted and let it be. No big red button, the sky is falling, omg we have to write scripts and create smart group moments.
From a UX standpoint, Self Service can just pull all that data in and automatically populate it. Things like, but not limited to:
If you are already populating that information in the Self Service
Description Box you are updating this manually every single time. All of this data literally lives in macOS in Spotlight. Just do
mdls /Applications/Firefox.app to see all the meta data that could be auto populated into Self Service. This makes a better UX for both the engineer doing the work and the customer who is using Self Service. This also allows you to have one parent description for the app object in your app catalog and reuse it for every version of the app you ever deploy, and it would hopefully auto update this meta data in self service.
So, in my humble opinion, this would be a great model to manage applications on macOS with jamf. It also opens up the doors for any Org that wants to use modern tool stacks and create CI/CD pipelines into their workflows. Simplifying the model to Application State with an Application Catalog, means it would be simpler to automate and control. It is less work for the engineers building these workflows both manually in the UI and through code, and it can reduce tech debt from too many manual processes.