I heard this was shown at JNUC2014. +1 / #WANT

I'm definitely looking forward to this being added. I'm assuming it will be before Oct this year otherwise JAMF may get some criticism.

It doesn't look like an easy thing to add in, considering the number of possible variables with every update. Just hoping it will be smooth enough to use when it is released!

The only concern I have about what was shown is that it was mentioned JAMF would be using the Third Party Applications information from JAMFNation to determine versions and download locations. If that's the case, they will probably need to control that information. Right now, anyone can go in and edit the information in the 3rd party section for any product. Allowing anyone here to edit it could potentially mean breaking everyone's patch management solution. So JAMF will either need to have specific fields in each entry they lock down and have control over, or just not allow anyone to edit those entries anymore.
It will also mean its on JAMF to continuously stay on top of and keep those entries as accurate as possible. That's kind of a tall order unless they are working on some pretty advanced process to automate that.

All in all, I look forward to what they are putting together. Until then, we'll use our custom processes, since the current process of Smart Groups and manual packages is tedious. AutoPkg and AutoPkgr help alleviate this somewhat, but some organizations aren't inclined to plug in an external product for this and would rather use what's built in to the product they purchased. Even if its not perfect, my guess is JAMF's patch management solution will have a pretty good uptake by customers.

One of the other things that JAMF was very clear to point out was that they recognize the need to focus on quality control (for lack of a better term) as opposed to fast feature roll out. A lot of folks went through a lot of issues with the transition in early 9.x, myself included. Trust me, I want it. I want it bad. However, when I do get my hands on JAMFs version of patch management I want the darned thing to work or I don't want it at all!

I'm really happy that JAMF announced the fact that they are working on it. Personally, I'm not ready to move toward AutoPKGr even though I know it works. It's too much outlay and thumb holding for my organization (I'm Casper Admin + a million other things). Personally, I'm willing to hold off for as long as necessary to get something I can trust, that will also make my job easier.

I agree. I hope that it works and that implementation can be a little more straight forward. I have had all kinds of issues implementing things (early on) that I really wanted to use that would in theory increase our productivity. I am also excited about this new tool. Yes please more QA and testing before a quick software release. Chris_Hafner I get what your saying about work loads as I am in a similar situation. I am totally ok with working to implement something new that does not require more hand holding.

I agree with @Chris_Hafner, even though I created the original patch management feature request (https://jamfnation.jamfsoftware.com/featureRequest.html?id=662

Autopkg makes it so easy to get the latest files, it takes me ~10 minutes a month to update/stage policies without even trying to automate it with other tools that are out there. I'm fine with that at this point. Like Chris, I manage a million other things outside of Casper, and just want something that is quick and reliable.

I want patch management built in to the product, but I also don't want it at the expense of support being stretched too thin. Since moving over to config profiles and relying on cert based communication, something breaks with each upgrade for us that takes weeks+ to resolve. Apple's yearly upgrade cycle forces us to upgrade JSS 1-2x a year just to support the latest OS (and iOS).

The thought of JAMF taking on something else big and seemingly complicated scares me. Hopefully I'm underestimating the size and resources of the dev/support team.

I doubt (or hope) the patch management feature(s) won't rely on community manifests - we really need the ability to create/manage our own manifests internally (for risk mitigation, security, confidentiality, etc., reasons).

I'd love to see a followup communication from JAMF on where they are, what path they are heading down, even if is fuzzy/vague enough to protect themselves from being derailed (always a risk when too many conductors are trying to drive a train).

Planning my trip to JNUC2015... :)

Don

I'd rather have community sourced manifests than JAMF sourced ones to be honest. Just look at Licensed Software definitions and how fast those go out of date. AutoPkg is a perfect example of how effective and quick community-sourced "recipes" can be.

As for security, my only concern is that the source of the software is from the vendor and not a third-party, after that, it doesn't matter how I get it. If I have an application that I don't want to share my specific recipes for, no one is forcing me to do so.

@lashomb I think a good compromise would be to give us the option to choose. Create our own, or link to community provided manifests. Everyone would be happy. :)

@donmontalvo As long as it has something easy like autopkg repo-sync, which will pull down the latest recipes from your added repos from github. We don't need to go backwards now that the Mac Admin community has excellent tools like this available.

@lashomb yep, and that's why it is important to keep this thread alive. JAMF are monitoring this thread, the more feedback they get on how these methodologies can help make the lives of Mac admins better, the better. :)

Something I have noticed missing from this thread is built-in "blocking application" support for policies. Is seems a bit ridiculous to have to script this for each application deployment. I suggest the developers at JAMF review how Munki addresses this issue. Out of all the feature request, little things like this save huge amounts of time and will make the product more palatable to admins regardless of the level of skill.

The race is on! C'mon, JAMF, you can do it! :D

Let's hope!!

Do it!

If JSS 10 can allow import of profiles, for delivery as we deliver PKGs/DMGs that would be helpful for environments that have proxy servers.

As we approach JNUC2015, good to keep this thread fresh.

Interesting and sometimes funny responses to a Feature Request:

Smart computer group application version compare with greater than & less than

@CasperSally fingers crossed your Feature Request finally comes to fruition...

Patch Management Integration

The 2014 teaser is, well, a year + in the making. I'm desperately hoping something substantial is announced on this next week.

I'll be watching this thread with interest come next week. I do expect there to be an announcement around this, since it was shown off a bit last year. If its not announced that its release is imminent, well, there will be some 'splaining to do I reckon.

My guess would be that it'll get mentioned but not sure if it's anywhere near ready.

I've started using the autopkg / JSS importer method but would personally still like something more integrated from JAMF.

Saying it was "shown off a bit" is pretty generous; at the marketing event we didn't even get any screenshots, just general conversation about the effort to make it. I wouldn't be surprised if we maybe get some screenshots and general concept but not much more.

/me is setting low expectations to not be disappointed

@emilykausalik It sounds like you're referring to JAMF's Ice Out event, yes? If so, then yeah, there was not even a mention of the patch management solution from what I recall.
But I was referring to what was actually shown at JNUC 2014 during the first day keynote. It was more than just a mention or a bullet point. There was some type of demo of it in action. Now, granted, it probably was just a canned demo or concept recording or something, not sure, but still, it got some actual screen time.

This was about a year ago, and in those intervening months, we've heard nary a peep about this. That's a little concerning. I'm sure 10.11 may have derailed some of the development this year on it since JAMF needed to work to make their existing product compatible with it. Still, a year is a while, so I'm a bit surprised there's been no talk of it, no beta versions with early builds of it in place, etc. Its been very quiet.
I won't be there next week to see anything, but I'm hoping it gets brought up again at least. I don't think everyone that was there then, who will be there now, will just forget JAMF talked about it last year.

@mm2270 - The Ice Out Event - don't bring back the bad memories!

I'm sure they'll mention patch at JNUC, and I'll be following along the news for sure. I'm not expecting production release of patch soon, but probably some beta release in a month or so? Totally conjecture, but I know more support JAMFers were moved to the Patch team in recent weeks/months.

While I requested
3rd party patch management back in 2012 (!!!) I'm quite happy with our Autopkgr implementation. The only place my patching could be a smoother would be the promotion from test to production, but I haven't implemented the new launch daemon approach yet - awaiting to see what JAMF will announce this week.

Honestly, I am more worried about support getting stretched more thin at this point than I am at finally getting Patch now. I've had some lingering JSS issues I'd really like to see finally resolved.

"Quality first, Patch Management in the works but will be released when ready." - JAMF CEO

Music to my/our ears.

@donmontalvo And I have no problem with that. I'd rather have something be great and working day one instead of being rushed and broken. Also, Dean is a pretty cool CEO.