Concerning App Updates and Patch Management

[fdeltesta]

Hello,

So we are having a bit of a struggle here, since the begining I've never wanted to use the Patch Management feature because there was only a defined set of apps usable, and thus you had to have apps in here, and the unsuported ones in the policy section. I didn't like that so I went for a full policy updating workflow.

It actually works pretty well, I even created some scripts so you can easy add any type of pckage you want and you just have to tweak thhe paramters to control the installation process, very handy.

But the problem we have is that it seems impossible to filter computers in smart group by "less than" for a software version. It's a nightmare, so we've been updating as soon as possible the precise version in these groups and update de package as sson as possible. But if for some reason an update gets released and we don't react fast enough some computers might auto update some stuff, and then jamf would then downgrade the app, cause it doesnt match our policy.....

And this is precisely why patch management should be used you might say, and yeah you're right, they're made for that reason. But something is still triggering me about that feature: you can't use a script. if you want any kind of custom interaction with the end user, you can't. I wish they could defer the update process, and then it tries later. Here you can only warn the user with only a notification, not even a pop up window (so for our idiots in here, this will be litteraly unnoticable). And at the end of the timer the update triggers. Theres no choice for the user.

And i really don't want to script the installation process and dialog with the user in a pre install script that we would have to compose each and everytime we have to push a package.

Is this really that stupid, or am I missing something ?

[raymondap]

As far as I can tell it's that stupid. My biggest about Jamf/Apple device management is the complete lack of anything like maintenance windows, and my biggest complaint about Patch management is the poor end user experience.

You might want to check out AutoPkgr if you haven't already. We found it helpful when we were using policy based patching. https://marketplace.jamf.com/details/autopkgr/

[PhillyPhoto]

I ran in to the same issues, and ended up completely scripting our patches. So take Chrome for example, the first thing it checks for is the OS build version for software that has minimum/maximum requirements. Then it checks the application version (I can specify a direct path if it's not in /Applications). If it meets the OS requirements and is less than the version number passed to the script, it will then prompt the user to run or defer the install policy. 

For normal products like Chrome, they can defer 30 minutes at a time for up to 3 hours. For OS updates, they can defer 8 hours. It will also kill the process to upgrade it. 

One annoyance of patch management in Jamf is there's no way to say what your "current" version is. Say you're rolling out SEP 14.3 RU1 do to certain internal limitations. The patch policy tracks the progress only of the latest version, so you won't see your devices as 100%.

It's not an issue anymore, but when Apple was supplying standalone and combo updates, there wasn't a way to upload each under macOS updates.

[mm2270]

Everything you outlined above falls into the same reasons why I chose to roll my own patch solution instead of using the Jamf built in one. Patch Management in Jamf Pro just feels... incomplete. It was a great first start, but Jamf seems to have forgotten they added to their product, as the core functionality hasn't been updated in years now. Adding in new software titles to track isn't enough. It's just missing too many important features that probably should have been included in it from the start.

One thing I do use of theirs is patch reporting titles. I know they don't include every available software title one might need to track, but for the ones they do (which is a lot!), I add those Patch titles that I need to track and can then build out my Smart Computer Groups for my patch policies using the Patch Reporting Title criteria and it's built in version logic, instead of having to use some wacky regex pattern or use an EA/script to determine if an installed application is out of date.

It's just the Patch policies that I tend not to use due to their limitations.

[kacey3]

We were able to create a maintenance window for our patch management policies using some creative scripting and static groups. It's a bit of a workaround, but it gives us much more control over our application updates while still leveraging the built in patch management system.

You can see how we made this work here: https://community.jamf.com/t5/jamf-pro/creating-a-patch-policy-maintenance-window/m-p/301107#M264970