Software Patching - What's the future?

@danshaw I'm in the same boat, my script obtained through Jamf Nation failed to work on deploying 10.14.2, the script claimed it was installed so called my reboot prompt policy and rebooted. Nothing came up and I was taken straight back to the login screen

We use manage engine along side JAMF, it manages all the updates for us

Munki is part of AirWatch now, and as such, has given them an advantage over Jamf Pro.
Another area where we are going to get questioned on when the price of Jamf Pro is much more than AirWatch.
I'm buckling in for 2019. I fear I have some splaining to do or new skills to learn...

@scottb Yep, while one could technically ding VMware for grafting another product onto theirs, it's hard to truly fault them for this if the end result is a good patching experience, and I think almost anyone would agree that Munki provides a good patching and software update experience.
Back when I was forced to look at AW, lack of any patching and poor package pushing processes were big flaws that put them behind Jamf a substantial amount. With Munki now part of their product, Jamf needs to watch out, and up their game in this area. The AW folks have long been gunning for Jamf's marketshare, and they're serious in this regard. I hope Jamf is paying attention.

Count me in as another longtime and loyal Jamf customer that's disappointed in the anemic patch management offered within the Jamf Pro product. It was ballyhooed quite a bit (and clamored for) with Jamf 10 and I think you'd be hard pressed to find anyone that thinks it's a well-engineered component of Jamf Pro. One small example: even with their built-in and supported patch definitions, I'm seeing long out-of-date definitions (Sophos) and crazy numbering logic (Office). This makes using patch management built into Jamf rather useless.

I haven't heard much about Jamf Pro 11. Maybe Jamf's engineers are working on a patch management solution that's at least the equivalent of Munki. One can hope.

@mm2270 - again, spot-on. VMWare (AW) are going for the juggler. I have even been reaching out to Jamf for the last year letting them know this stuff. Calls, emails, etc. I sense that we are going to see a change in '19. I'm sad as the community Jamf has is second to none - AW will never have this as far as I'm concerned, but companies don't care about that like "we" do.

@damienbarrett - right there with you too. I'm crossing fingers that Jamf are reading and acting. I am hoping, but losing hope.

I'm in a similar situation with patching as the OP. I have yet to find a great workflow for our users that lets them choose a good time to install the updates and reboot but also lets me have the control over versions I need for our InfoSec folks. I really need Jamf to radically improve their game here to help justify the annual Jamf Pro licensing cost.

Patch management or lack of, is a sad state right now with Jamf. You can get a machine ready, deploy it and give it software but good luck keeping that software updated after deployment! I don't consider scripting, Munki or other alternatives a "solution" so to speak. I am glad they exist but the whole reasoning for choosing Jamf is the all in one "Gold Standard" for managing Apple devices from start to finish. Keeping me and my time free to do other things. Now, I spend a great deal of time trying to figure out way to make patching work, notifications work so users see it and respond. Stuff that should already be IN JAMF! It's a crap shoot.

I can't believe I am saying this but Jamf is replacing Ivanti for us but after using Jamf, Ivanti is much better in regards to patch management than Jamf currently is or at this point will ever be. Now if I could combine their patch management with Jamf ease of reporting and deployment, I would be golden.

The other thing that bothers me is with Ivanti, all patch packages are provided. I don't need to make them or go hunting for them. Jamf, I have to hunt them down, make them, upload them, package them, blah blah blah. It's tedious.

Please, PLEASE fix this or stop calling it patch management because it's not.

Yup! That we still have effectively NO built-in method to keep macOS up-to-date with notifications and deferrals etc. is simply mind boggling at this point. Especially with the price bump coming next year.

This is the only REAL area in Jamf that restricts me from doing things how I want. Sure, there's room for improvement in other areas, but man, patching just seems like a base feature at this point for products like this!

Another missing piece (IMO) is the ability to run scripts after a package is run. IE: installing helper applications, etc via scripts would be great to have.

Maybe it is not me understanding the issue, but why not enable Software update policy in a policy with deferrel and necessary information to the user when updates are there ? and here I talk in regards to OS updates of course that some of you mentioned

@Captainamerica

why not enable Software update policy in a policy with deferrel and necessary information to the user when updates are there ?

Because then you run into the issues with the 'deferral' aspect. As much as the complaint here is about not having a robust patch management framework, it is also about the UX the end users experience when trying to patch. The current offering suffers from the problem outlined in this FR. Namely that the deferrals only work on a future 'enforcement date' and not on the 'number of times' the user has seen the "update" message and allowed to defer. I can't speak for you, but this just doesn't work for me, and based on the popularity of that FR, I'm not alone there.
While I understand that in some circumstances one may need to enforce a patch by a certain date come hell or high water, more often than not, it's about getting end users to comply with the updates but also giving them some flexibility on when to apply it. Current policy and patch deferrals just don't allow for this. What ends up happening is Jamf admins end up pushing out the enforcement date again and again, until it gets to a point where you may as well not even bother.

@danshaw Adding JamJar, which uses Munki for patching, to our Jamf Pro workflow has greatly simplified our patching process. I re-used our existing distribution points, so it required no extra infrastructure. Check it out at - https://github.com/dataJAR/jamJAR/wiki.

For Apple and App Store software, we automate this using the built-in functionality in macOS. For updates that require a restart, we use a reminder process similar to what Pixar described at JNUC 2018 <pertinent comments begin around 22:00>

For trusted 3rd parties with CDN package distribution or built-in auto-update mechanisms, we use those.

For those oddball packages that can’t be automated any other way, a patch server/service is needed. Jamf’s patch function is usable and Munki is a mature solution with a clever community behind it.

What I would love to see from Jamf is to roll the full patch functionality into Jamf Pro, rather than requiring an external patch server. Patching & updating software is a core function of client management. I wish it were a core function of Jamf Pro.

I am quite new to Jamf and not working much with deferrels, but i May not work as i Think

So if a policy has 4 days deferrel, so user Can postpone it. What happens then when he Reach Day 5. Will it not prompt again that policy now HAS to run or nothing is happening ?

Patch didn't really live up to expectation.

Really deserves a good solid revisit.

Will JSS 10 finally bring us easy patch management?

@mrowell So now not only is Jamf (the "gold standard" for apple deployment) not doing patching, you're advising to use Munki and JamJar as well? Talk about a mess. Who has time to sit around and set all that up??? Who wants to? Now you have to worry about if something breaks, where is it breaking? What system is broken? Yeah, no. That's not a solution, that's a mess. If it works for you, that's great.

The sad part about all this, is that large corporation such as Disney - HAVE to go to such extremes for patch management even though they use Jamf. The fact they have to do that and it's NOT BUILT IN, is the problem here. Period, the end.

You can mention and offer third parties until the cows come home but that doesn't take the spotlight off the fact that Jamf isn't a complete product at all. At least not the one that was sold to our institution as such. I won't say we were lied to but we weren't told the entire truth/fact of the matter.

We went with Jamf because it was spoken so highly of for what it does. We specifically asked about patch management, setting schedules, delaying, etc and were told YUP, it can do that!

Nope, it can't.

@Captainamerica That's the problem, there are NO deferrals in patch policies. None. It's all or nothing. The user does not get to defer a patch. Once it's pushed out, it installs once it hits and the device checks in. You can't schedule it, you can't defer it, nothing. If the user is not paying attention to their computer, they will also miss the 3 second "notification" that pops up and never shows again for the duration. That same notification that tell them they have 15 minutes before the patch is applied. It's a bad system.

@Kristopher As the author of jamJAR, I can advise that:
1. jamJAR was written in response to Patch & the way we saw that working for an MSP.
2. We host & manage 100+ Jamf instances, with jamJAR looking after 200+ titles & a large number of the rest being deployed under VPP.. we're saving 100's of hours not having to manually patch stuff. We hardly manually re-pkg too.

jamJAR is Jamf saying to Munki "Update Flash', for example.

The actual project sets out to not mess with Jamf or Munki much.. so Jamf hands off the process to Munki.. so this becomes Munki's issue to deliver & as such it's Munki you'd then troubleshoot.

Lastly:

The sad part about all this, is that large corporation such as Disney - HAVE to go to such extremes for patch management even though they use Jamf. The fact they have to do that and it's NOT BUILT IN, is the problem here. Period, the end.

As per many large organisations, Disney is made up of many parts.

Where Munki is used by Walt Disney Animation Studios, it's not the whole organisation.

Other parts are using Jamf, but Walt Disney Animation Studios is not.

Anyways, sorry to be off topic.. Just wanted to clarify some things.

@bentoms Thanks for the clarification. My point being, you still need two other systems. For someone who just started with Jamf (myself, not going to act like I know everything), adding on another system.. Munki and then jamJAR .. is a bit overwhelming. There's a lot to learn and understand. Some of us haven't done a lot of scripting, if any. It's not an ideal situation. I don't mind putting in some work but the support for these systems isn't there, other than some reading or possibly some online help, if that.

Would love someone to walk me through it, video tutorial or something other than just read this. I've spent countless hours trying to get something going because all I had was text to read and it wasn't clear to me. Could be clear to someone that knew what they were doing?? I don't know. I don't have that time. I just don't.

@Kristopher

My point being, you still need two other systems.

That is what "Jamf And..." is about tbh

When I Jumpstart, I tell folks something like "Jamf is not a self driving car.. It's a car with automatic gearbox, sat-nav, parking assist.. etc.. you still need to know how to drive, the journey etc..."

So adding/extending Jamf is par for the course..

NOW, if we're looking a head further.. but every vendor to get their stuff on the App Store & use VPP.. job done.

What I would love to see from Jamf is to roll the full patch functionality into Jamf Pro, rather than requiring an external patch server. Patching & updating software is a core function of client management. I wish it were a core function of Jamf Pro.

@milesleacy that is indeed what I wish for and what another company has already done. This is why Jamf need to look at the future today. the premier Apple MDM is falling behind...