Java 8 u60 32bit on 64 but windows Fixlet problems

Seeing “failed” or Not relevant with the fixlets that install 32 bit java on a 64 bit windows 8.1 box…

64 bit on 64 bit seems to be working… The failed section is the very last paprgraph

Is this from the IBM patching site?

Can you provide the actionscript?

Is there an exit code?

Can you provide client logs? ( Redact the root / relay info / similar )

Even with successful status “Fixed” Java version 8 update 51 is still the only version visible in the installed software list.
None of the successful “installed” PC shows up under the “Java Runtime Environment - Multiple JRE Versions Installed - J2SE 1.4.2 and Up” fixlet.

Java Runtime Environment 8 update 60 (32-bit) Available (x64) - CORRUPT PATCH helps nothing, always fail.

I’m a bit confused by what you are saying, what is wrong, and what you are expecting.

When you install a new version of JAVA 8, it uninstall the previous version, then installs the new version. You don’t get multiple copies of JAVA installed.

JAVA has changed the way they handle installing multiple versions many times, it is kind of annoying.

We ran into this problem as well. For software offers, we just use the action script provided by IBM to upgrade Java and then modify the relevance of that task to look for no java installed instead. Easy peasy usually but with the latest 32-Bit Installer for Java 8.60 and testing on 64-bit Windows, it did not work. The action would say the installer ‘Completed’ but then it would fail when during the ‘continue if’ check to see if the latest version of Java is in the registry. Verified that Java was not installed in the Program Files folder.

Ended up testing the install manually by:
1 - downloading the installer from Oracle’s site and running it to which it installed correctly
2 - using the downloaded installer that we uploaded to the BigFix server’s cache and then executing it manually in the __Download folder and clicking through the screens - this installed correctly
3 - using the downloaded installer in the __Download folder, running a command prompt as admin and then executing the installer with same silent install command used in the action script - this installed correctly

My guess is that Oracle changed the installer’s behavior which is leading to this problem.

To reiterate, I only tested for 32-Bit Java on a 64-bit OS.

1 Like

Can anyone help to provide some screenshots showing what’s going wrong?

I couldn’t reproduce the issue in my lab Win8.1 x64 machine with JRE 8u51 32-bit instaled.

I copied the fixlet and changed the install to include a log
waithidden __Download\jre-8u60-windows-i586.exe /s /L c:\temp\jre8u60x32.log

The failure has only been when Bigfix tries to run the install as system

jre8u60x32.log - I didn’t include what was matching when I ran the install as me.
MSI (s) (B8:44) [11:10:09:299]: ******* RunEngine:
******* Product: C:\Windows\system32\config\systemprofile\AppData\LocalLow\Oracle\Java\jre1.8.0_60\jre1.8.0_60.msi
******* Action:
******* CommandLine: **********
MSI (s) (B8:44) [11:10:09:299]: Note: 1: 2203 2: C:\Windows\system32\config\systemprofile\AppData\LocalLow\Oracle\Java\jre1.8.0_60\jre1.8.0_60.msi 3: -2147287037
MSI (s) (B8:44) [11:10:09:299]: MainEngineThread is returning 3
MSI (s) (B8:94) [11:10:09:299]: User policy value ‘DisableRollback’ is 0
MSI (s) (B8:94) [11:10:09:299]: Machine policy value ‘DisableRollback’ is 0
MSI (s) (B8:94) [11:10:09:299]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (B8:94) [11:10:09:299]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (B8:94) [11:10:09:299]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (B8:94) [11:10:09:299]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (B8:94) [11:10:09:299]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (B8:94) [11:10:09:299]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (B8:94) [11:10:09:299]: Restoring environment variables
MSI © (24:4C) [11:10:09:299]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI © (24:4C) [11:10:09:299]: MainEngineThread is returning 3
=== Verbose logging stopped: 8/24/2015 11:10:09 ===

Oracle has changed the path in 8U60 to
LocalLow\Oracle\Java\ rather than LocalLow\Sun\Java\

2 Likes

That is so nice of them to do that in a random update instead of waiting until the next major version with some sort of announcement.

I’m constantly surprised at how bad vendors are at being enterprise friendly.

Hello Rezma,
This shouldn’t make a difference for the actual install right? That’s the location for user configuration files and cache. I think something has definitely changed with the installer. I’m getting the same results as above with a failed install on a 64-bit machine installing 32-bit Java. Mine has also been failing on the Continue If statement checking for Java 8 Update 60 in the registry.

1 Like

The details of what can be done before there is a release of a new fixlet.

Make a copy of the current
Java Runtime Environment 8 update 60 (32-bit) Available (JRE 8 32-bit version Installed) (x64) and rename to something like
Java Runtime Environment 8 update 60 (32-bit) Available (JRE 8 32-bit version Installed) (x64) - Oracle path
that way you still have the original.

Edit the action to change the sun to oracle

else
// Remove any existing directory junction point
dos %windir%\syswow64\cmd.exe /C fsutil reparsepoint delete “%windir%\syswow64\config\systemprofile\appdata\locallow\oracle\java”
// delete java directory in 32bit version of system32, if any
dos rmdir /q /s “%windir%\syswow64\config\systemprofile\appdata\locallow\oracle\java”
//create a java folder under system32 folder if not exists
if {not exist folder (system folder as string &"\config\systemprofile\appdata\locallow\oracle\java")}
action uses wow64 redirection false
dos mkdir "%windir%\system32\config\systemprofile\appdata\locallow\oracle\java"
endif
// create ntfs junction point from 32bit version of system32 java files to sysnative version
// (NOTE: mklink argument seems to be in native path perspective, so system32 is correct here, not sysnative)
action uses wow64 redirection false
dos mklink /J “%windir%\syswow64\config\systemprofile\appdata\locallow\oracle\java” “%windir%\system32\config\systemprofile\appdata\locallow\oracle\java”

2 Likes

Rezma -

That fixed it - I modified the action script from having “sun” in the folder paths to “oracle” and the installs have been successful so far.

Thanks!

1 Like

What rezma mentioned above worked for me also. In the action script for 64-bit machines replace “sun” with “oracle”.

1 Like

That path change worked for me too… I also had to edit the CORRUP PATCH fixlet too…
It does trigger the “Multiple versions of Java installed” fixlet to become relevant too…

Thanks all…

Do we have anyone from IBM looking at this, or do we need to get someone to PMR it?

1 Like

It does seem like a PMR is in order.

The change has been published to Updates for Windows Applications site.
Kindly gather the latest version.

1 Like

I am looking for a way to get all PC having not installed u60.
I now that I have a few PC still on u51 but they are not showing up at any u60 fixlet. e.g. TEM thinks they are on u60

It could be that they have both installed, or it could be some other issue. You would need to do some specific relevance evaluation in pieces to really figure out where the issue is.