New JRE7u55 (Upgrade) packages

This is a known condition when the JRE installer is obtained from an incorrect location.

The Package Download Assistant has a built-in link to obtain the installer from the Oracle Technology Network.

http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880261.html

and that's the binary that the package was tested with.

If you obtain the binary from JAVA.COM ... you'll get a binary with a different File Version number (and possibly also different functionality), and among other things, the Installed Rule will fail in the supplied packages because the build number is not correct.

There are, functionally, two ways to resolve this scenario:

1. You can uninstall the JRE7u55 package that used the wrong binary. Expire the package on the WSUS server. Run detections on all affected clients so they see the expiration, and then DELETE that package from the WSUS server. Download the correct binary from OTN and republish the JRE7u55 packages with the correct binary file.

2. Customize the existing JRE7u55 package (Do NOT create a duplicate package in this instance; a duplicate package will confuse it even further.) to test for the 7.0.550.13 build number in the JAVA.DLL and RE-publish that package as a revision. Force all clients to run detections, which will get them the updated metadata, and subsequently report that package as "Installed". However, note at this point you still have an incorrect JRE7u55 package deployed, which may or may not also have undesirable functionality. (The packages at JAVA.COM are designed for Single-User Consumer implementations.) Once clients have reported the package as "Installed", RE-publish the JRE7u55 packages with the correct binaries (the metadata will automatically correct at the next catalog sync event with SolarWinds). Approve the corrected JRE7u55 package and deploy the correct JRE7u55 binaries.

   Okay, my bad. Followed your Step 1 and got everything back to the way it should be. Tested both my VMs and everything works fine.

   Thanks Lawrence, have a great weekend!

Additional Information -- for those reading this after the fact.

Sometime yesterday (Mon Apr 21), Oracle 'updated' the contents of the binaries contained on the Oracle Technology Network JavaDownloads page... and didn't tell anybody. It's not the first time they've done this; it likely won't be the last.

As a result, several additional customers who correctly downloaded the binaries from the OTN then experienced this same behavior, because now they had the v7.0.550.13 JAVA.DLL.

The packages in the catalog have been updated as of 9:20am this morning. Please perform a manual synchronization to obtain the updated package, expire/delete the previously published packages, and republish the package with today's revision date, which will contain the correct metadata logic to test for the v7.0.550.13 JAVA.DLL file.

I followed your instructions, expired the original package , downloaded the new package, and published it. Java appears to install successfully, but the Windows Update continues to pop up and show that JRE7u55 still is needed.

Any suggestions?

I'm merely speculating at this point; authoritative answers would require inspecting the WindowsUpdate.log to determine exactly what happened.

A key point, though, is that the steps must be performed in exactly the right sequence, and allowing for completion of the previous step.

1. After expiring the original package, it is necessary that all clients execute a detection event to obtain information about the expiration of that package. Lacking knowledge of the expiration of the original package, it will continue to be evaluated and scheduled for installation by the WUAgent. Which JRE update package was actually installed by the WUA may be a critical issue here.

2. After all clients have detected and obtained the expiration of the original package, I recommend deleting the original package from the WSUS server.

3. Publish the revised JRE7u55 package(s). Be sure to obtain the updated binaries from the included download link. Approve the update and deploy. Note also, in consideration of the points made in #1 above, if *both* JRE packages are still believed to be valid by the WUA, it's also possible that the WUA will attempt to install them both, and the actual order of attempted installation is random.

I suggest inspecting the WindowsUpdate.log on the affected client(s) and confirm that [a] the original package is no longer being processed by the WUA, and [b] the revised package is the one actually installed by the WUA today. If you need assistance reviewing/interpreting the WindowsUpdate.log, I'm happy to help you with that.

Thanks for the response. These are the steps I have taken. I did expire the original package and forced the machine to report. I then checked for updates on that machine and there were none, so I deleted the original package.

I downloaded and published the new package, but with the same results. I really don’t know how to read the windowsupdate log. What is the best way for you to help me with that? Should I copy/paste it in an email or take a screen shot?

Thanks

I really don’t know how to read the windowsupdate log. What is the best way for you to help me with that?

Email it to me, please. You can get my email address from my Thwack Profile.

The original version of this message was technically inaccurate on so many levels... all I can say is that my brain wasn't properly in gear when I wrote the part I've now struckout that is below.

To be specific: The revision number of the update published IN WSUS has absolutely nothing at all to do with the revision number of the update package contained in the Patch Manager catalog.

So, let's try this again.

First, I believe there may also be a defect in my original remediation guidance. If a JRE7u55 update with the v7.0.550.13 JAVA.DLL was previously installed (from the old package), and not uninstalled as part of this remediation/clean-up, then the "(Upgrade)" package for JRE7u55 should be detected as Not Applicable, so that's my first item of concern. Second, if the JRE7u55 package failed to install completely, or was rolled back (such that JRE7u51 or earlier is still on the system), then the "(Upgrade)" package is applicable. If the JRE7 was completely uninstalled, then the "(Upgrade)" package should also be Not Applicable.

Setting aside the question of applicability for the moment, and assuming the behaviors are correct, we then turn to the WindowsUpdate.log:

At 12:52pm the WUA discovered the new JRE7u55 package and determined it was applicable.

It downloaded the update package, and at time the new JRE7u55 package is pending installation:

2014-04-22 12:52:26:605 1008 fc8 Report REPORT EVENT: {76FD9377-D3E4-42AE-8AE4-1F4F3FD8C536} 2014-04-22 12:52:22:595-0500 1 189 102 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Content Install Installation Ready: The following updates are downloaded and ready for installation. To install the updates, an administrator should log on to this computer and Windows will prompt with further instructions:  - Java Runtime Environment 7u55 (x64) (Upgrade)

And that update was installed immediately via the WUApp.

2014-04-22 12:52:55:114 1008 fc8 Report REPORT EVENT: {B2C48189-A52B-4D0C-90C0-7CF0B515C5A1} 2014-04-22 12:52:50:105-0500 1 183 101 {AB986344-33B8-4467-A5A4-22069E056198} 1 0 AutomaticUpdates Success Content Install Installation Successful: Windows successfully installed the following update: Java Runtime Environment 7u55 (x64) (Upgrade)

And immediately following that, the WUA did, in fact, detect that very same package as still installable.

At 1:36pm a revision to the package was obtained by the WUA. I'm curious about this revision, but it's merely a curiosity. It has nothing to do with the observed behaviors.

At this point, there are two questions to be answered:

1. Did the JRE7u55 x64 (Upgrade) package detect as installable when it never should have.

2. Even after being successfully installed, why is it still detecting as installable.

Most likely the same answer addresses both questions. I'm inquiring internally about this, but it would be helpful to know if anybody else is still experiencing this issue after obtaining the revised packages.

Looks to me like you were able to publish Revision =2= of that new package. The current revision is Revision =6= which was published at 9:12am this morning.

2014-04-22 13:42:08:344 1008 e4c Agent *   Title = Java Runtime Environment 7u55 (x64) (Upgrade)

2014-04-22 13:42:08:344 1008 e4c Agent *   UpdateId = {AB986344-33B8-4467-A5A4-22069E056198}.2

As far as I know, it is not possible to publish an older revision to WSUS, which suggests that Revision 2 was available in the LIVE catalog at the time your Patch Manager synchronized overnight.

If Revision 2 was published to the LIVE catalog, and your server synchronized the catalog between 5:30pm yesterday and 9:00am this morning, it's quite likely that the current revision was not on your server at the time of publication.

Luckily, the fix is simple. Verify that you have Revision 6 of this update in your Patch Manager catalog collection, and simply re-publish the update as a revision. Force the clients to detect to get the revision, and that should resolve the false positives still occurring in your environment.

I'm checking on this with the content team.

I wanted to let you know that I expired the Java update that I had, deleted it, downloaded and published it again and it’s working perfectly. Not sure what changed as I had already done this previously.

Thanks for your help.

Deb

Thank you for the update, Dev.

Glad to hear the package did work as expected the second time around.

At this point, we've not heard anybody else experience issues with the revised package, so I'm inclined to chalk this up to some transient/quirky issue with your specific publication of that package on Tuesday.