Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Manage the Appliation State of Devices

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 JSS Importer 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:

.../JSSResource/appcatalog/firefox(or id)/packages/the_new_pkg

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 Install, Reinstall, and 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.

Scenario 1:

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.

Scenario 2:

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

Scenario 3:

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:

  • App Name
  • App Version
  • Size on disk
  • Developer

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.

Comment
Order by:

Posted: by mscottblake

I wish I could give this more than one vote. Very well thought out and described, @tlarkin.

Like

Posted: by grahamrpugh

TL;DR be like Munki for package management.

Like

Posted: by tlarkin

@mscottblake thanks! Been thinking about this for years now haha

@grahamrpugh Yes, but also have server side APIs and integration into jamf's framework. There is a lot you can do here that is not even mentioned, because it would be an even longer wall of text.

For example, your Application State could just set a minimum version and basically state that version 1.2 or higher is required for this app. Jamf has a binary and an agent and can already do all of this stuff, they just need to build it. :-)

Like

Posted: by tlarkin

Also, can someone please fix my typo in the title, and actually spell Application properly for me?

Thanks!

Like

Posted: by RobertHammen

For the love of God, please do this, Jamf!

The patch stuff in the JSS is... to be kind, not great. And there's been no noticeable improvement since release.

I think more and more organizations are wanting to take this approach. Not wanting to have to create more policies and more smart groups, work to integrate an optional third-party patch server, etc.

Like

Posted: by milesleacy

As long as “latest” is one of the state/version options, where Jamf (accurately and in a timely fashion [day 0]) maintain the definition of “latest” and automatically ingests the source package (where source is publicly available), this is all great and should be done immediately.

I’ve called this out in other FRs: I don’t want to build my own update mechanism. Where possible, I’ll use App Store and /or the manufacturer’s built-in auto update mechanisms. Where it isn’t possible, I want a solution that is as turnkey as possible.

The Patch features in Jamf Pro provide the loosest of frameworks. To make use of them I need to stand up a supplemental service and build arcane workflows.

Like

Posted: by CasperSally

Sounds great. I'll fall over if it happens :)

Like

Posted: by tlarkin

@milesleacy I think there should be options for both. Let me give you a real story that happened this week at my Org. I was engaging with my team when my AutoPKG server sent a slack bot message to inform us it had built and uploaded a new package for Zoom. With in 5 minutes of that happening, my boss got a pop up on his Mac kindly asking him to quit zoom so it can be patched. Once the patch completed another dialog box notified him that it was done.

Do you know how much time it took me to accomplish this (omitting the time it took to build it)? The answer is zero minutes, zero seconds. It was fully automated end to end. Package creation, package validation, upload to jamf, static policies + python code kicked in.

My approach is more in-depth than just this specific case with the prompt, but the fact that it ran 100% on its own with out me having to log into a UI, is what I want to achieve. Right now this is possible AutoPKG JSS Importer static policies + handler scripts. What I would like to see is some of this removed, and mainly around the specific patching from jamf, in the manner I outlined above.

Jamf took 2-3 days to release the 10.14.5 Patch Definition to their own product, and it patched a very critical CPU CVE and no other patch has any other mitigations. The only way you can control Jamf Patch is if you use Bryson's server, which I have personally used at previous gigs. By doing this you are accepting the tech debt of owning it, and there are still manual processes to do. Manual processes mean options for human mistakes.

Automation is more about the repeated end result, and humans often make mistakes and manual processes add lots of opportunity for mistakes. Patch just is missing those API end points and an easy way to understand and manage your application catalog. Which is why when I swapped jobs I went a different route. I currently have end to end full automation of patching apps with jamf using the methods I outlined above. It does work, but it can be so much better.

Also, I want to move away from the one to one or one to many model of jamf policies for installing software. It just creates too much tech debt. I am already writing enough code to work around these shortcomings. It isn't that jamf can't do this either, they just haven't yet. I personally feel that having jamf do everything for you will put jamf in a position where they design something that cannot please everyone. This is bad for jamf and this is bad for the customers. Jamf should work on building APIs and frameworks that allow all customers to build their own and manage their own app catalog how they see fit.

Your Org hired you to be the expert, and you, as the expert, will do what is best for your Org. This is most likely unique to your Org and doesn't transfer to any other Org. Just like everything I do at my Org, is not cookie cutter for other Orgs. For jamf to build this in, with out having APIs and orchestration puts them in a bad situation where they have to make a hard choice and hope it pleases most of their customers. Where as if they build an application catalog model and allowed tagging or meta data of rules and jamf just did whatever based off that, it would allow all of us to do what is best for your Org.

At my Org, I can 100% silent patch, push apps, and if you are out of compliance I am allowed to force reboot your computer. We do this as a common practice. Obviously, this is probably not universally allowed at other Orgs. It works for us and is our culture, so let me design how I want to manage my app catalog how I want and don't make decisions for my Org.

Just my humble opinion of course.

Like

Posted: by tlarkin

Another #humblebrag story I can share is that there have been other CVEs for web browsers, and when my security engineering team asked about these zero day exploits, on the day that the CVE has been published, the majority of my fleet had already auto patched. I think we had under 20 devices that had not patched yet.

This is what I want, this is the level of automation I want with the proper process that does some basic validation of a package.

Like

Posted: by mhrono

Yes please and thank you! This would be a huge improvement to the app management experience.

Like

Posted: by milesleacy

@tlarkin My final sentence is really my core point:

To make use of them [Jamf patch features] I need to stand up a supplemental service and build arcane workflows.

Your process is great, tuned to your needs, and probably reusable with few changes for many orgs.

The problem, as I see it, is that you had to build a ton of logic, custom notifications, an AutoPKG server, presumably a Patch Server for Jamf Pro, etc.

I want all of this functionality in the product. I don't want to stand up supplemental servers, services, data stores, etc. I want to be able to delegate the work to junior admins, who will use Apple-like GUIs that "just work", when a new title comes along that needs some non-App Store deployment and updating.

I think we're on the same page, more or less. :)

Like

Posted: by tlarkin

@milesleacy yup I think we are agreeing minus a few minor points. To reiterate I completely agree with you that jamf should do it all for us. I think my model, while not perfect, outlined in this FR, could accomplish that for you. I play around with Spotlight a lot (because it is freaking amazing!) and going off the local state of an application the jamf binary could do a lot of this and should do a lot of what you are stating. I did not go into every minor detail of my pipe dream here (because lets face it, I am already writing novels here) but to sort of expanding on my ideas, the jamf agent can do a GET request from the JSS (I know JPS, but c'mon JSS 4 LYFE!) to grab the app catalog of apps and versions and just compare the local state instantly with out having to rely on a recon. A local agent can leverage the same APIs I am right now to get meta data on Applications locally, and Spotlight is super fast

mdfind -onlyin /Applications "kMDItemKind == Application"

That gives you every app installed via Spotlight meta data. Apple has literally given us an amazing tool to easily do this. Then it is super easy to get the version of any app from that return:

mdls -name kMDItemVersion /Applications/Firefox.app/
kMDItemVersion = "66.0.5"

Now if the jamf agent can easily do that with Spotlight and it knows that I have Firefox 66.1.23 in my App catalog it knows it can update. I totally agree with you 100% it should do it for us.

Where I differ in opinion is, that I want the option, to integrate my already working and robust tooling. If I can plug AutoPKG into this, then amazing, great. If I have to migrate all of my workflows it has to be equal or better to what i have and it has to reduce my tech debt. Otherwise, there is just very little incentive for me to swap.

I think (my opinion) when you focus too much on making that turn key solution for the masses, you end up not doing it flexible or in a right away that can please everyone. To quote Bruce Lee, "Be like water." I feel jamf should "be like water," and not only offer a better solution, but a flexible one that can embrace the open source community and does allow us to build tools, share them, collaborate and so forth.

I totally get the point of delegating work to junior admins, but some Orgs may not buy into that paradigm either. In a DevOps, Cloud First, automation, code as infra, CI/CD world, some Orgs may want engineers that take care of it. Different strokes for different folks. I feel that if jamf makes patching and application state flexible enough, they can probably meet both my wants and your wants, and probably many other Org's wants as well.

Just my opinion is all, take it with a grain of salt.

Like

Posted: by tlarkin

Oh and one more thing to pile on here, what if the user goes and grabs a newer version? Since Smart Groups can only use Strict versioning this cause a lot of false positives and manual labor. However, with a local state model you could do something like this

>>> 
>>> 
>>> from distutils.version import LooseVersion
>>> a = '10.2.33'
>>> b = '10.10.44'
>>> LooseVersion(a) > LooseVersion(b)
False
>>> LooseVersion(b) > LooseVersion(a)
True

as you can see, using a LooseVersion string comparison module I am easily able to test if a newer version is present. If a user decides to self update or get the new version before you update your tools, do you want them to get the old version plowed to their system? Right now, jamf will 100% do this. This is where jamf could take care of all the local logic for you and all you need to do as an admin is simply define your app catalog and then use whatever tools you want to pump your packages into jamf.

Thanks for coming to my Ted Talk,

Love y'all

-Tom

Like

Posted: by lisacherie

Reading the post and the comments, I have some thoughts that should be considered.

  • Over automation. The workflow described is excellent in that the time to deploy is extremely efficient, however it also introduces risks.

  • validating the package does not introduce a problem to the environment be it security or functionality

  • detail is not provided about the use case handling of an application in use, there is little more annoying than being interrupted whilst presenting for an update

  • virus total is an excellent screen, however does not catch everything. There is a risk with crowd sourced recipes and an automated deployment such as has been seen in the past with npm

  • a gap where there would be value is a subscriber based package management at a fee to be confident packages have been tested and are free from malware, and obtained from a trusted source. Such a model would be similar to red hat subscription manager. Even with a model like this functional testing is still prudent. The App Store does fill part of the gap with vpp, yet most of the apps I have to patch are not there.

  • Taking patching inputs from vulnerability scanners should be considered an input too. A good scanner will find more to address than what can be determined by installed software inventory

  • the performance concerns are valid

Like

Posted: by tlarkin

@lisacherie Hi! All of your points are great and certainly valid. There is an entire stack of QA automation you could toss into this as well. That is where my concept of Bruce Lee's "Be like water," comes from. Jamf just needs to provide the framework and the underlying technology. How we decide as organizations to test apps and build out or process is probably dynamic across the board. You should be able to pipe this through any QA process you see fit, with probably some exceptions, since nothing 100% works in every scenario under the sun

I look at it this way. Using things like VCS you could have a test branch and a master branch. All of your automation could go to your test branch, allowing either a human, or other automation/tools to do some sort of validation testing. You could payload a pkg somewhere and have tools scan it before you swap to the master branch. Really, all of this is completely up to you and your Org as you all see fit to meet your needs.

AutoPKG by default does not auto trust any recipe changes and you must trust all code changes, also you are allowed to create your own repos and just control the code end to end. If you are worried about malicious code you can host your own repo anywhere you like. The new features of the 1.x series of AutoPKG shows you all the code change or you to test and validate before you commit to it. However, you don't have to use AutoPKG, you can use any tool stack you want to build packages, and then delivering it to jamf should have API endpoints to allow you to automate this. You shouldn't have to create so many server side objects to do this, as I agree with @milesleacy that jamf should do this for us.

I know the things I have built may not work for some Orgs, or they aren't willing to assess those risks. I am not really here though to push my workflow on everyone, but rather take this opportunity to open up a discussion on how we can make managing apps better with jamf. There are a lot of caveats with a server based inventory/scoping system where the local client can easily drift.

I am not really looking at the QA process as I have a lot of opinions and experiences with that as well, but so many other people and organizations have their views. The idea is, I don't want to log into a UI and I want code to automate it. Jamf cannot please everyone, nor can jamf define everyone's process (that is just impossible) but jamf can build a framework and some APIs to allow people to plug in their process and workflows into it.

Thanks
Tom

Like