Patch Management - still showing Office at 15.24, when 15.25 came out yesterday

@jlbrown Good question. Let me explain a little bit about how the process works. JAMF has a team of patch curators that create and maintain the definition files that drive this whole process. They update these files as new patches are released by software vendors. For the most part, we are using a script to monitor for updates. Right now it runs automatically every two hours. We are then doing some basic testing on each patch before making them available. This includes things like installing it on all the minimum required OSs, and making sure the versions are reported correctly in the JSS once installed. Our definition files are stored in the cloud, and your JSS monitors them for changes every 5 minutes. The “Latest version” of a title gets updated when the JSS detects a new version in the definition file for the title. All of this typically happens within 48 hours, often quicker. We are actively working on continuing to automate and improve this process.

@erin.miska ... just wanted to (again) say thank you.

While I like KNOWING that an update is out there, I appreciate the vetting you guys are doing even more. In essence, you're allowing me to skip any internal "alpha" testing of updates, once I know it has been tested by you guys I'm fairly comfortable releasing to my test group and scheduling our production release.

@erin.miska Should I submit a feature request for what I'm about to ask?

While JAMF may want to vet new software, that should not prevent the Casper from notifying an admin that a new update is available. As an example, AutoPKGr will allow email notifications on new downloads. However just because it downloads does not mean that the download was processed and added to a software deployment solution (in this case Casper) for deployment.

48 hrs may work for some people, but in some organizations that would not be acceptable. That is, finding out 48 hrs AFTER the fact that an update was released and then having to vet the software yourself (it's not a JAMF thing, but I wouldn't trust someone else to do the vetting for me; at least with autopkg there's some transparency as to what's going on, but even then I'd still prefer to make sure the app functions as intended). It would be great regardless of the situation to be notified that an update is available immediately to allow the admin to start testing and researching as needed without necessarily forcing an update to be pushed out to end users.

@erin.miska Hi Erin - The community expects to see the JSS updated when a patch is released by the vendor, demonstrated by OP. Especially a risky vulnerability such as Flash or Java. If you are testing, and planning distribution of that patch, that's all great and I understand there may be a delay before it's available. However people expect the version number in the JSS to increment pretty quickly after it's released, showing you realize it's there. I hope you'll consider that in your process workflow.

I think a simple solution would be for JAMF to have two channels of Patch Reporting (and soon management).

One for the Cutting Edge, and another for Tested Releases. Allow the JSS Admin to select which channel their JSS subscribes to.

Cutting Edge would list the update immediately after JAMF's automation finds it (~2 hours). Tested Releases would list the update after the existing process takes place (within 48 hours).

Everyone wins?

There's no need to create channels for this. The request is simple enough, allow admins to be notified immediately when an update is available from a vendor. Why would JAMF need to be verify anything when it comes to sending out a notification to an admin "Office 2016 15.25 has been released today"?

@erin.miska Please add this info to the 9.93 Admin documentation.

Thanks for the feedback, everyone.

We're liking the idea of immediately notifying you when a vendor releases, even if the patch is still being tested and verified. Not sure exactly how we'd make that happen within the current framework we've set up for this release process, but we can certainly look into it. Just to clarify, you'd be happy with an immediate notification even if we'd be unable to help you do anything about it for 24-48 hours (e.g. patch reporting would not include the latest version until it's gone through the release process I described above)?

@jyergatian To your point about having multiple channels or tracks, we are already considering this idea for future releases, and I think it will come into play more when we've opened this up to the community to write their own definitions. For example, we could have JAMF-approved definitions that are a little slower but "safer", and community-sourced definitions that are faster but not as well vetted. There's lots we can do around that idea.

@dstranathan The Casper Suite admin guide doesn't typically explain behind-the-scenes stuff like this about the inner workings of the software and is more of a "how-to" guide, but I do think that would be good information for a Knowledge Base article. And we could look in to cross referencing it in the admin guide. Would that be helpful?

Thank you @erin.miska ! Nice to know you're listening. And yes, I think you understand the ask here. We expect immediate notification of updates. And I assume you're planning a button 'import patch into my JSS'; or perhaps that'll be automatic. I'm ok if that is grayed out temporarily during your testing, although 12-24 hours feels like a limit. I, like most people here, will be doing our own testing before deploying to our environment. So superficial and 'out the door as quickly as possible' is all we ask. Autopkg functionality and speed - with just a hint of testing.

I'd be happy with immediate notification that an update exists, even if JAMF is still testing the update itself. That way, if my shop needs to move faster with updates than JAMF's planned 48 hour turnaround, we have that option.

This is why we can't have nice things : ) : )

C

PS I am teasing ......

Hi folks!

Thought I'd add a little as to why Jamf wasn't quite up-to-date. Microsoft throttled the 15.25 release intentionally.

Last Monday's release was the first official 64-bit release of Office for Mac. While Microsoft didn't expect major issues, they were being cautious with the speed of the release.

Version 15.25 was available on Monday for only a short while and then Microsoft reverted availability to 15.24 to give them time to review metrics from those who quickly received the update. Again, they weren't expecting issues, but they wanted some data from customers before going widespread.

When Jamf picked up on the release, the currently available version from Microsoft AutoUpdate was 15.24. This was a one-time throttle and probably won't happen again. I don't think Microsoft lifted the throttle until Wednesday or Thursday (Aug. 24 or 25).

Only folks participating in the #microsoft-office channel in the MacAdmins team on Slack were provided this information in advance.

@erin.miska is that 48 regular hours or 48 business hours? I'm curious because Firefox 48.0.2 was release last Wednesday but the latest version is still reporting 48.0.1 in JSS 9.93. Thanks for clarifying!

@mpermann morning, this Firefox release was an unusual one. They released it partially. If you get a fresh download of the software it comes through as 48.0.2, but when you tried to update an existing copy it stated 48.0.1 was the latest release, (my test machine is still showing that today.) If you look at the release notes https://www.mozilla.org/en-US/firefox/48.0.2/releasenotes/ it states this release fixes Windows crashes so I am not sure if this was meant for Mac at all. That combined with the fact that their source version control site, still states 48.0.1 as the latest version I did not feel comfortable updating it in the JSS until we were we certain of what their plan is. I hope this helps explain the process a little more.

I received a Firefox 48.0.2 for Mac installer via AutoPkg and was able to confirm that it was actually Firefox 48.0.2.

@shawn.eberle thanks for the details. I will admit I didn't read the release notes, I just know that my AutoPkgr notified me of the newer version on Wednesday. Forgetting the oddities of the Firefox 48.0.2 release for a minute, in general, is the policy 48 regular hours or 48 business hours that we can expect to see an update?

Weird...I never updated my installation of Firefox on my desktop until I read the responses this morning and got this...

No prompt for updating at all and still at 48.0.

I did receive via autopkg though a 48.0.2 but have yet to verify it is what it says it is.

@mpermann No problem I did not see it at first either until I started seeing oddities in the release. The 48 hours is a general timeline in which we are shooting for in other words "48 hours real time." Some of the release in the last few weeks we have been able to drop on the same day.

Based on all of the great questions asked in this thread, we've updated the Software Definition Files in the JSS KB. Thanks for the feedback!

I like both the vetting being done by JAMF as well as knowing it's available ASAP.

Maybe simply indicate it's available, and indicate if its been verified (add a fancy checkmark next to the name).

If we decide to go with it when it's available, but not yet verified - the onus is on us.

He's a good question - Oracle recently released JRE 8 update 102, but that then disappeared and only 101 has been available since. What happens with the JSS and Patch Management in these cases? Does the 102 update get changed back to 101? Will clients that updated to 102 show up in the list of machines with Java 8? What about with actual patches - will the 101 replace the 102? Hmm. I wish I was going to JNUC this year. :-)

When "On Latest Version" and "On Other Version" are both zero, could you change % on Latest Version to list as either blank or 100%?

Seems strange and a bit misleading to have 0% as I feel that I need to then go fix something!

There's also an issue with us patching faster than you update your patch definitions... these appear to be showing as "unknown"... If you've done a good job vetting all of the possible patches for an application, these can ONLY represent patches newer than your current "latest".

So why would you then include them within "On Other Version" which drops down the compliance percentage? Or perhaps "On Other Version" could be "On Older Version" instead and then include "unknown" with the "On Latest" calculations.

"unknown" is a cop-out, IMHO. Certainly the same mechanisms (/usr/bin/defaults read) will report the newer version number/string, JAMF just chose not to display the version when it's reported to be newer-than-current. What problem does that behavior solve? If you can read the version, report the version.