More Java update pain

(imported topic written by rmnetops91)

So this is back to the issue of Java updates causing some machines to get Java un-installed (instead of upgraded like it should), when IE is running.

Based on the latest Java fixlets, we see two options: Install the Java update using the default action, and risk having a handful of machines with inoperable Java, or 2: Use the option to install the fixlet regardless if IE or Firefox is running, which appears to forcefully shut down IE on the user, interupting their work.

Couldn’t BigFix create a third option as follows: Only become relevant on the fixlet if IE or Firefox processes are not running on the machine? That way the fixlet will only become relevant if their web browsers are not running. They may not be updated immediately, but at some point when the users close their web browser, it would. I could create custom installers for Java to do this, but doing that every time Oracle releases a new Java update would be a lot of overhead.


(imported comment written by SystemAdmin)

You make a valid point, and this issue has been brought up before. But there are reasons for not implementing your suggestion.

A while back, we had this discussion as well, but the main reason we don’t do this, if i recall correctly, is that the uninstallation of Java isn’t always due to IE/Firefox is running at the same time. Our internal testing has ran into this issue even when IE/Firefox isn’t running. To add this extra check for IE/Firefox may solve some issues, but it is not the root solution. Another reason for not including this check is that there really isn’t any way to do it nicely. A lot of people like to leave IE/Firefox running all day. If we put the check for “no running IE/Firefox” in the relevance, the Fixlet will never become relevant. If we put the check in the action as a 3rd action (in addition to the two we currently have), then the Fixlet will always fail, which will bring us back to the original issue you have.

Our current solution is that the installation Fixlet should catch the cases when an uninstall has occurred rather than an upgrade, and when this happens, a “corrupt patch” Fixlet should become relevant, which should allow you to try to re-install the Java update. Check to see if you can see the corrupt patch Fixlet become relevant. If you’re not familiar with corrupt patch Fixlets, here’s a KB article -

Believe me, we are tired of these Java issues as well. But until Oracle releases updates that don’t do that, we’re stuck with what we have.

(imported comment written by rmnetops91)

We did use the corrupt patch to fix the majority of the issues. We had a handful of users that never showed relevant on it though, where we needed to fix their Java manually. Not sure why and didn’t have time to check the relevance to see why it didn’t match.

Thanks for the additional info. What I think we will do is add the running process relevence I mentioned to our Java baseline instead, that way it won’t matter what Java update version we add, it will only be relevant if the web browser process are not running in our environment.

(imported comment written by KimberlyNNH91)

I have a few users whose Java always uninstalls the old version but doesn’t install the new version. Basically I just have to make a mental note to check their machines. Not too hard in a small environment but not very efficient. I’m curious if others have found the same thing?