The Problem:
IBM’s java patches set a flag in the registry before installing the java update and delete it after. If something goes wrong then this flag is never deleted, and it will cause the machine to never become relevant for the update again.
The Fix:
This Fixlet will delete any “InstallingJava” flags set in the registry if they are older than 2 days. There may be multiple flags set on the same machine, in which case this fixlet should be deployed as a policy so that it can run multiple times and delete them all.
Just out of curiosity, may I know why do you prefer not to use the CORRUPT PATCH Fixlets provided side by side with the JRE patch Fixlets? Is there anything we can enhance?
To be honest, I really don’t understand what the “InstallingJava” flags are about, why they are used, or what the whole “Corrupt Patch” stuff means with the JAVA updates. It wasn’t until you said this that I took a closer look at the “Corrupt Patch” fixlets and noticed that they will run against machines with the “InstallingJava” flag set.
It would be helpful to have better comments within the actionscript for these fixlets, and better documentation on what these extra pieces are designed to fix / prevent, how and why. Some recommendations on how to patch java on systems would be good as well.
I added the check for these “InstallingJava” flags to the analysis to get a better understanding of what they were doing and see how many machines within my environment had that flag set, and how old they were. I found many machines with multiple of these set that were rather old and was concerned about what this meant for JAVA updates on these systems.
These days JAVA is a huge security concern and patching is very important, but JAVA is also one of the most difficult things to patch on a user’s system because it affects all JAVA apps and browsers. It would be helpful if BIgFix/IEM had a way to patch JAVA more easily without disrupting the end user.
The listed computers have faulty installations of the latest Java Runtime Environment.
BigFix recommends reinstalling this update to ensure the safety of affected computers. For
more information about corrupt patches, see BigFix KB #
166.
The above was taken from the description of one of the CORRUPT PATCH Fixlets. Is this the “better comments” you were looking for?
If there are machines on your environment that has this Flag set, it usually means JRE patching on these machines did not succeed, JRE was not patched. I would suggest to take every CORRUPT PATCH Fixlet, check machines that are relevant, and apply the action of the Fixlet to try patching JRE again on these machines.
As of your last point, we would be more than happy to see JAVA patched without disrupting the end user. However, this is greatly dependent on how Oracle designs their JRE patches. Do let us know if there is any improvement necessary for our Fixlets.
This KB article is not sufficient and not what I am referring to:
www-01.ibm. com/support/docview.wss?uid=swg21505985
I think the actionscript, not the description, should have more inline comments, in this case, the regset for the “InstallingJava” flags because I did not understand the function, but I believe I understand it a bit better now.
Consider this scenario:
the patch for Java 7 update 45 is attempted, but something is wrong with the installer and it never executes and the actionscript never completes. Now the “InstallingJava7_32” value is set in the registry. This will cause the Java 7 update 45 corrupt patch to become relevant, and cause the regular patch to no longer be relevant due to this reg value. Since many of our console operators do not know what the corrupt patch things are, they do not always deploy them.
Now the patch for Java 7 update 51 comes out. The regular version will NEVER be relevant on these machines even though this patch has never been attempted because of the “InstallingJava7_32” value. Only the Java 7 update 51 corrupt patch will be relevant, even though this patch has never been attempted and is not technically corrupted.
It is not completely clear to me what the function of the “InstallingJava7_32” value is. Is it to prevent multiple Java patches from being applied to the same machine before one has had a chance to reboot or something like that? is it to better detect corrupt patches? something else??? The KB article, the description in the fixlets are both insufficient to explain this.
Thank you so much for your feedback. We will definitely consider your point and see how we can improve the readability of our Fixlets, in both the description and the scripts.
Our design and intention was that, when a CORRUPT PATCH becomes relevant (triggered by the InstallingJava7 key), it serves as indicator that an installation is ‘corrupted’, and action is required. Taking into consideration that user might just ignore these CORRUPT PATCH, we will need to see what we can add to make this intention clearer.
After rereading this:
www-01.ibm .com/support/docview.wss?uid=swg21505985
And checking the JAVA corrupt patch fixlets, I see this in the KB “These Fixlet messages generally check the registry and every file that is installed by the patch.” as a description of what “Corrupt Patch” fixlets do. This is not the case with the JAVA ones, because they seem to be only concerned about the “InstallingJava” flags in the registry and are not concerned with the actual file versions on the system that the patch would install.
I do now better understand how this “InstallingJava” flag is meant to try to detect corrupt patches, but it does not do so in a way that lines up with the KB article, nor is it explained with inline comments in the actionscript or the description. It also falsely applies to machines that have the “InstallingJava” flag set from a previous patch attempt like the scenario I described above.
These “Corrupt Patch” java fixlets do not detect the case presented in the KB article in which a patch appears to apply successfully, but not all files are patched as they should be, or a file is changed back to an older version somehow. I realize this is a complicated case to write the relevance for, but this is the case that the KB article suggests but is not the reality.
Thanks for the reply. You are right that neither the Java Fixlet nor the CORRUPT PATCH Fixlet checks for file versions. They check the registry key under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall for the installed Java version instead.
The CORRUPT PATCH Fixlet does check the registry key for the version, other than checking the Installing_JAVA flag. It tries to detect the situation where a Java Fixlet was run but did not finish.
We are having some issues with corrupt java installs, more so recently.
It seems that the number of JAR files in a Java installation does not change frequently from version to version, and they are often missing from corrupt installations.
Also these issues were not detected by the “corrupt patch” fixlets because the “installing java” flag was not set because these installs happened outside of IBM patch fixlets, and even if the IBM provided fixlets were used, the Uninstall Regkeys for java were set, but not all the files were present.
We really appreciate the work and effort researching and composing the relevance to detect a corrupted JAVA installation. However I am sorry to say that we are still a little conservative in accepting this change at this stage, without extensive test (yet) and official (Oracle) documentation support. However we will definitely look into this and reference your work when we are making enhancements to our Java Fixlets.
When I am looking at your Fixlet http://bigfix.me/fixlet/details/3707
, Action 2, I notice that it checks for running status of JRE, Internet Explorer, and Firefox before continuing to apply the patch. I believe this makes perfect sense - if this Fixlet is going to fail, it’s better fail without applying the patch to the endpoint. After necessary measures we are likely to make this check into the default action.
Other than this, we are also planning some change to the Fixlet description. Hopefully it would make user more aware of the CORRUPT PATCH if they ever need to use them.
Once again we thank you for the work you put up for the community!
(note: your ‘newer reply’ was not overlooked - we just need more time to compose this reply )
, I was trying to find an easy way to detect a corrupt Java installations. One of our other BigFix admins realized that in the corrupt Java installs we were seeing, some of the .jar files were missing. He determined that “lib\alt-rt.jar” was one of the last files to be placed by the Java installer and if it was missing, then it was a good sign that the Java install was corrupted. I did think about trying to check for the presents of every single file and version of the file that is placed by the Java installer as a way to detect corrupt patches if they are missing, but this seemed like overkill and a waste of relevance evaluation. I then tried to see if there was a easier proxy for detecting a corrupt Java install.
It turned out the
of LibJarFiles
was a factor that was stable across many different Java versions. This tells me that if there are less than 12 Jar files present in a wide array of Java versions, then Java is corrupt, and this relevance will not need to be updated often. I am not saying that this will detect all instances of corruption, but it WILL detect with a high degree of certainty some types of corrupt Java installations in a more robust way than the “InstallingJava” registry flag, which is not a true measure of corruption, only an indicator that something went wrong with one of the IBM provided Java patches at some point, but not necessarily the most recent Java installation, which may have been performed by hand or through a BigFix action that does not set or delete this flag.
Java is by far one of the most annoying things to update. It would be nice if instead of just installing Java, there was an option to setup a Java update as a one time pre-login script along with an “action requires restart” so that Java could be installed at login in cases where machines typically have a user logged in all the time. This along side using the existing patches applied to machines with no user logged in would cover all the bases.
I will post an update here once the enhanced Java Fixlets (which use this relevance in the action script, and contains more information in the description) passes the tests and are published to live site.
Please gather the site version 650. The JRE Fixlets have their description and default action behavior updated. If you are still having problem finding the changes, kindly let me know which Fixlets are you looking at, and what changes are you expecting.
I think I agree. I think maybe part of the problem is that it takes people all of this effort to explain what a corrupt patch actually is instead of it being readily apparent. I think when I first learned about bigfix I just ignored all the corrupt patches too.
What if corrupt patches changed to something like: Warning: Problem detected in JRE 6u51… please look at these endpoints… instead? Hopefully operators stop ignoring these guys? Since systems in the corrupt state tend to be tricky to begin with, maybe they should be audit fixlets instead?
I’m not sure that audit only is the solution, I think I’d prefer something actionable if possible. My main issue is just not fully understanding what is going on in the actionscript / relevance and why, or what the “Corrupt Patch” fixlets were created to address.
I think it is a good idea to manually audit the endpoints that show up under corrupt patch to better understand what is happening and if there is a reason for it, especially if the corrupt patch fixlets don’t address the issue.
How interesting that you have this problem as well. I hard-coded this line into our Java patches as well.
if (exists key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation” of registry) then (if ((now - last write time of key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation” of registry) > 86400 * second) then true else not exists value “InstallingJava7_32” whose (it = 1) of key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation” of registry) else true
)