Patch Management Group

I'm looking for recommendations for how you all are keeping up with keeping Java current.  This week was the first time where Java update was released (8u51) and our working Java installs (8u45) in IE stopped working the same or next day of the new release.  In the past, we seemed to be able to keep going for at least a week while the new one got pushed out (see my earlier article on how I push out Java).

I reread Java's config file documentation, and the "deployment.expiration.check.enabled" seems to just suppress the notification to the user of expiration, whereas I may have read that earlier that it wasn't doing the check for expiration at all.

Maybe I should be looking again at using the Patch Management to push java.  Does anyone have experience with how well that works when IE is left opened (or Chrome, I realize Chrome blocks java but I don't know if Chrome interferes with the installer).  I used to care about using the config files so the user wouldn't see prompts, but we have business critical apps that depend on working Java in the browser, so now I just need to know the best way to support Java 8 updates with CMS 7.5.

I also need to make sure the old versions are removed from the PCs.

It seems like with the blocking of old versions - it would make more sense to push Java once to the users that need it & let Java update itself if it can do it well & remove the old version(s).  I don't really trust their mechanisms much though.

I created a job that uninstalls all previous versions of java, then i install the last version of java

basically i run a batch file then i run another task that installs the latest version of java. 

its not pretty, but it does work...below is just an excerpt of the batch file contents..the trick is finding the uninstall key in the registry for the old java versions

MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83217055FF} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83217076FF} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83217079FF} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F03217080F0} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83218011F0} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83218020F0} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83218025F0} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83218031F0} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83218040F0} /passive /norestart /qn
MsiExec.exe /uninstall {26A24AE4-039D-4CA4-87B4-2F83218045F0} /passive /norestart /qn

then i as you mentioned your article above, i have task to install the lastest version of java, either i will use the MSI or run the exe with an /s switch

You could use this script I found awhile back:

wmic product where "name like 'Java%% %%'" call uninstall /nointeractive

It will remove all versions of Java. Only tested on Windows 7 at this time.

You could use this script I found awhile back on Spiceworks:

wmic product where "name like 'Java%% %%'" call uninstall /nointeractive

It will remove all versions of Java. Only tested on Windows 7 at this time.

ok, i will have to try the command from spiceworks also....

Sally5432, you may also want to add a task that will kill IE before you start the uninstall of java

i would recommend creating a job as follows:

1. Kill IE (command script - TASKKILL /F /IM iexplore.exe)

2. Uninstall java (batch file) or Spiceworks comment above

3. Install new version of Java

If using Software Management Solution, you would need to upload and create software releases of all updates, and then configure Update Association within the software resource between each one of them.

That would resolve the uninstall first, install later, issue.

I don't know if that can be achieved with Patch Management.

Regards.

Yea our process works well enough, but I'm more wondering how everyone handles the timing of it.

This was the first time our users experienced Java being blocked in the browsers within 48 hours of the new java coming out.  Are you all just keeping up with it that fast?  I do wonder about what will happen the next time Java is released and I'm on vacation.  I wish there was an more automated way to set up someone else to take care of it.

Java is tricky and oh-so-vulnerable all the time, it seems. This topic seems to come up every several months.

In our environment we have a few poor legacy applications that are hard-coded to a specific version of Java...something like Java 7 U25 or some such. Luckily on a very small subset of machines. We've experimented just a little with Java updates in Patch, but never got to production with it. I'm the sole Altiris engineer here (5,000 endpoints along with CEM clients) so not much time to run trials.

We don't have Java install as a post-image task. We only roll it out on an as-needed basis so that keeps our Java population somewhat manageable. For everyone that does have it (except for the legacy app users above) we rip out Java via the script I posted and roll the new version. It hasn't broken anything yet (but now it will since I am talking about it!)  ;)

And that's how we do it here.

You can configure deployment.expiration.check.enabled = false in deployment.properties or install java with  -userConfig deployment.expiration.check.enabled false.

So Java is not blocked in browser and you can update when you want to update.

https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/jcp/properties.html

We have always set deployment.expiration.check.enabled to false & never had issues until this last release.  If you reread the documentation it says that flag "Must be "true" to prompt users to update the JRE when an out-of-date JRE is found on their system. Set to "false" to suppress the prompt. "

It sure reads like all it does is suppress the prompt, not enable Java to run out of expiration, which is what seemingly happened to us on this last release.  Users got no prompt, but Java didn't work either.

We also added the following settings and got no issues with the last release.

deployment.security.expired.warning=false
deployment.security.expired.warning.locked
deployment.expiration.decision=never
deployment.expiration.decision.suppression=true

I don't see those keys anywhere in their documentation... where'd you get them from?

Sally,

Do you know the automated workflow you can configure to achieve automation?

Take a look: https://www-secure.symantec.com/connect/videos/workflow-template-zero-day-patch

Regards.

Have you explored using the Workspace Virtualization component (included with CMS 7.x) to virtualize your legacy app and legacy Java, isolating them from the rest of the OS so that you can run that specific version of java when the app launches, running the latest versions for everything else?

https://www-secure.symantec.com/connect/articles/virtualizing-java-symantec-workspace-virtualization 

http://www.symantec.com/docs/HOWTO75050 

Also, on the subject of Java versions, Oracle now has built in expiration that triggers security settings:

https://www.java.com/en/download/faq/release_changes.xml 

Java Expiration Date

The expiration date for 8u51 is October 20, 2015. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u51) on November 20, 2015. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version.

For more info on Java security you can read this page: https://www.java.com/en/security/developer-info.jsp as well as: https://www.java.com/en/download/help/java_blocked.xml 

The workflow automation is interesting, but it doesn't really help me since Java needs to be managed outside of patch management.  

Typical Symantec though, the automated workflow stuff looks about 100x more complicated than it should be on the customer facing end of things.

For comparison, the developers should take a look at the open source Autopkgr on Mac (integrates nicely with Mac management tools like munki or Casper).  GUI based & easy to set up.  I select Mac apps I want to keep updated (such as Flash, Java, Chrome) and 2x a day it checks for new versions of those apps and if found, emails me and imports them into our mac management tool and scopes them to our test group of laptops & has logic to install when apps are closed if you want.  Once tested, I can promote same patches to production.

Seems similar to what this workflow is trying to do, but so much more nicely presented and packaged.  It took maybe 2 hours to get set up and working for thousands of Macs.