Multiple Versions of JRE

(imported topic written by SystemAdmin)

Our environment currently requires that some users have multiple versions of the Java Runtime Environment. (We’re not happy about it, but it is what it is.) In deploying fixlets to update the JRE, we found that many of the 1.5 instances were not updated.

Looking at the fixlet, one of the relevances includes…

AND not exists value “DisplayVersion” whose (it as string as version >= “1.6.0.0”

So, our workstations with JRE 1.5 installed, that also have JRE 1.6, are not updated.

We’re thinking of building a “modified” version of the fixlet that does not exclude computers with 1.6 installed. Is there a specific reason why the fixlet was authored this way, or was the general thinking, “Why would you need to update 1.5 if 1.6 is present?”

Thanks in advance.

  • Mike

(imported comment written by Sam_Lam91)

Hi Mike!

Your assessment is correct. Our general approach has been that if a user has both JRE 5 and 6 installed, s/he would only be concerned about updating the latest version (JRE 6) and not the older version (JRE 5). In fact, our “Multiple JRE Versions Installed” Fixlet (id: 7052001) reflects this; its description recommends “keeping only the latest version of JRE to properly guard against known security vulnerabilities.”

Your concern has led us to begin re-evaluating our current approach. We may provide additional or revised content that’ll help users who, like you, may want to update older versions of JRE on a machine with multiple JRE versions installed.

In the interim, your building a modified Fixlet will serve your purposes just fine. In particular, all you need to do is to take the JRE 5 fixlet (id: 7051002) and change the first relevance statement to the following by removing the second clause, which excludes computers with JRE 6:

Revised Relevance:

NOT exists value 
"DisplayVersion" whose ((

if (it as string = 
"1.5.0") then (it as string & 
".000") 

else (it as string)) as version >= 
"1.5.0.160") of keys whose (value 
"DisplayName" of it as string as lowercase contains 
"j2se runtime environment") of key 
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" of registry

And that should do it! I just tested the Fixlet’s action on a test machine with a situation similar to yours, and as far as I can tell it works. Hope that helps, and thanks for bringing this to our attention!

Sam

(imported comment written by SystemAdmin)

Thank you.

From our side, we’re also working to get everyone on a single version.

We’ve found that using the “Multiple JRE Versions Installed” fixlet is very helpful.

However, it appears to leave 1.3.x versions installed.

(imported comment written by rwest23)

Hi Mike,

In order to address this issue we’ve recently released some new content. Our assessment was that administrators should be able not only to update their mixed installation machines, but also to distinguish the configurations of the machines that they are updating. As such, we’ve created/modified the following fixlets:

Java Runtime Environment 6 Update 7 Available (JRE 6 Installed): id 7051001

Upgrade to latest version of JRE 6 on computers with exclusively JRE 6 installed.

Java Runtime Environment 6 Update 7 Available (JRE < 6 Installed): id 7051005

Upgrade to latest version of JRE 6 on computers with exclusively JRE 5 or earlier installed.

Java Runtime Environment 6 Update 7 Available (JRE 5 & 6 Installed): id 7051006

Upgrade to latest version of JRE 6 on computers with JRE 5 & 6 installed.

Java Runtime Environment 5.0 Update 16 Available: id 7051002

Upgrade to the latest version of JRE 5 on computers with JRE 5 and possibly other versions installed.

There are likewise equivalent fixlets for 64-bit systems as well as French systems. Note that the actions for the first three fixlets listed above are identical.

It is our hope that this clears up any confusion on exactly which systems our fixlets apply to and allows you to more easily administer your environment, but please let us know if you see any more room for improvement. Thanks!

  • Randy