The current java 32 bit update provided by BigFix has some relevance in it to determine if a workstation is 64 bit. If a workstation is 64 bit will will return false for the applicability of the Fixlet.
Is is possible to have Java 32 bit installed on a 64 Bit OS such as Windows 7 64 bit.
Has anyone out there have experienece updating java 32 bit to the latest version using BigFix? I created a custom copy of the fixlet provided by BigFix and removed relevance clause #4 which is looks at a key in the registry to determine if the OS is 64bit. The custom fixlet is now relevant on a Windows 7 64 bit with Java 32 bit installed but the update fails. It appears like there is a problem extracting the installer.
we’ve done quite a bit of research on this, and it looks like there is a bug in the Sun/Oracle packaging routine that prevents your approach from working reliably. While 32 bit Java works fine on 64 bit OS, the upgrade/patch/installation routines often look in the wrong places. We’re currently investigating providing detection only fixlets for this situation and would welcome any feedback on this approach. In the meantime, my recommendation is to ensure that 32 bit Java is not used on 64 bit OSes, if that situation is possible to avoid in your environment. I believe this will show instances of 32 bit Java installed on 64 bit Windows OSes:
q: (x64 of operating system) and ((it > 0) of number of keys whose (((it contains "java" OR it contains "j2se") AND (it contains "runtime environment" OR it contains "update") and (not (it contains "development kit" or it contains "auto updater"))) of (value "DisplayName" of it as string as lowercase)) of key "HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall" of x32 registry)
Has anyone contacted Sun about this bug that prevents the upgrade routines from working reliably? From what I’ve bene able to figure out it looks like the installer has trouble extracting the setup files “Error 25099. Unzipping core files failed.
This forum post makes mention of two folder paths that may need to be cleared out in order for the setup files to get extracted sucessfully. If we do this procedure manually it seems to allow upgrading java to the latest version. We haven’t been sucessful in translating this into an action script. Perhaps the %appdata% is the issue since this resides in the users profile. I’m not sure where these setup files would be extracted if run under a system account which is what the BigFix client would use to install software.
To run things as a user instead of local system, you should create a batch file and use runascurrentuser.exe (http://support.bigfix.com/cgi-bin/kbdirect.pl?id=392) to start it. The batch file trick can be picked up by looking at examples, such as “Task: Enable BigFix Client Interacting with Desktop”.
Caution is advised though; not only do you need to deal with different versions and multiple versions of Java, but %programfiles% will send you to the wrong place on a 64-bit OS.
Not securely, there isn’t. You’d have to pass the credentials to psexec or runas. I’ve seen customers write little wrappers in scripting languages and compile them to obfuscate the credentials, but that seems like a lot of work to solve a problem in the wrong way… if that admin wins the lottery and disappears, it’s hard for someone else to figure out what’s being done.
Are these single user computers? If you know the user’s login name (say through the Primary User analysis here: http://forum.bigfix.com/viewtopic.php?pid=5466), then you can just use that to construct the right path to application data. That still doesn’t solve your program files redirection or the JRE packaging problem with incorrect temporary extraction locations. Do the end users need to have 32 bit JRE on 64 bit OSes?
Not securely, there isn’t. You’d have to pass the credentials to psexec or runas. I’ve seen customers write little wrappers in scripting languages and compile them to obfuscate the credentials, but that seems like a lot of work to solve a problem in the wrong way… if that admin wins the lottery and disappears, it’s hard for someone else to figure out what’s being done.
Are these single user computers? If you know the user’s login name (say through the Primary User analysis here: http://forum.bigfix.com/viewtopic.php?pid=5466), then you can just use that to construct the right path to application data. That still doesn’t solve your program files redirection or the JRE packaging problem with incorrect temporary extraction locations. Do the end users need to have 32 bit JRE on 64 bit OSes?
I’ve been working with the OP on this issue. End users use 32-bit JRE on 64-bit Windows 7 because the 64-bit IE doesn’t support many plugins (like Flash, primarily). As a result, most of the workstations are configured with only 32-bit JRE installed. The users also all run as user, and do not have admin credentials to the machines, which seems to be the biggest hurdle.
If I login as an admin, I can download and install 32-bit JRE updates with no problem. What doesn’t work is being logged in as a User, downloading JRE update, being prompted for Admin credentials, and supplying valid Admin credentials. Trying to update that way fails every time. I would assume this is also why the BigFix 32-bit fixlet doesn’t work on the 64-bit OS.
That makes sense, thanks. We’ve put some effort into making the upgrades work properly, but it appears to be unreliable without making modifications to the vendor-supplied package. Since we don’t feel like that’s the right approach, we’ve created an audit fixlet to reveal the situation, called “Java Runtime Environment - Outdated JRE 32-bit Version detected in x64 Operating System (x64)”. This will notify you that there is a 32 bit version which is not up to date on a 64 bit OS so that you can evaluate the best solution for your organization.
I manually installed it on one machine and copied the the folder %userprofile%\AppData\LocalLow\Sun\Java\jre1.6.0_22. I’m installing the msi with the transform and a few switches. Modified the relevance so it no longer checks for a 64 bit system. Seems to work so far, haven’t run into any issues yet.
Thank you for your reply. In our case, deployment via BigFix to XP machines works fine; deployment to x64 Win7 fails. The issue appears to be not with the package itself (though I could be wrong), but the hashing-packing-extracting routine: if I pre-cache the file on BF relay and deploy a fixlet, every step of the action completes successfully, yet overall status is Failed and Java is never installed on the target machine. If I execute the very same exe I previously downloaded from Java and pre-cached on BF relays, with the very same command-line parameters locally, it succeeds without any problems. It looks like when the file is delivered via BF fixlet and extracted/executed, something happens and installation is terminated.
I wanted to ask if you or anyone else knows what the packaging mechanism is used when file is compressed in a TMP and later extracted via “extract j6u23_x86exe.tmp” command. Is it possible to download the TMP file and extract its content manually and see if running that by hand via command line work? I tried Win/7-zip but neither one recognized the downloaded TMP file as valid archive.
Thanks,
Dimitri
P.S. FWIW, we are also using SMS/SCCM to deploy Java, and it has none of the issues delivering/installing native Java packaged EXE.
that sounds like the situation described in posts 2 through 6 of this thread. The issue is related to who the installer runs as. Is there something I’m missing?
OK, I think I know what the problem is. The issue is, I suspect, with the way BigFix process passes identity when running installation of Java: even if you select the option “Run when at least one of the selected users is logged on, and only display the user interface to those users” on the Users tab in the Take Action dialog box when deploying the action, the only way to really install Java on Win7 is via “RunAsCurrentUser.exe” utility, similar to the syntax below:
Only then the fixlet will succeed and even then, RunAsCurrentUser.exe will trigger a UAC prompt despite user being an admin and UAC being at its lowest setting. Overall, it’s doable but very clumsy way of installing a patch. I’m not sure this is strictly a Java issue; more like BigFix deploying this version of Java – like I said, SMS and SCCM are both deploying the very same j6u23_x86.exe without any fuss.
I have a ticket opened, I will update this thread once anything comes out of it.
Thanks to Jack Coates for his help, if anyone has any other ideas, please do share them.
I have been working on this issue for a while, and your investigation does reflect some of my findings. It does have something to do with how BigFix is deploying Java 32-bit on 64-bit OS. At the same time, it can be how Java packages their updates, as explained in
, under the section titled “Install JRE with msi without removing old version in a mixed 32-bit/64-bit environment”. RunAsCurrentUser.exe does seem like the only way to get it to work on a Win7 machine due to how BigFix is interacting with Windows and how Java is being packaged, but with UAC issue like you saw, we can’t provide a proper fix yet.
We’ve updated the Fixlet to now perform the actual installation of 32-bit Java on 64-bit OS. There is a warning in the Fixlet description about potential failed installations with UAC. Additionally, there is another action available for all Java installation Fixlets that will kill any running instances IE, Firefox, and Java. Hopefully, this will help alleviate some issues.
I have a fixlet working to update 32bit java on 64bit windows 7. It uses a combination of hacks to work, so use at your own risk, but for us we simply have to get this to work, so here it is for those interested (attached)
Basically it creates (or clears and recreates to be sure its correct) an NTFS directory junction between the pseudo system32 directory 32bit apps see, and the real one, for the system profile app data related to java. In addition I find I have to specifically run the java installer from a 32bit cmd.exe. Action sequence looks like this:
prefetch jre-6u27-windows-i586.exe sha1:3133735f705f1af47d0807585b7c5739df7fbd33 size:16897824 http:
//download.oracle.com/otn-pub/java/jdk/6u27-b07/jre-6u27-windows-i586.exe
// Note: update .exe will restart service automatically
if
{exists running service
"JavaQuickStarterService"
} delete __appendfile delete stop_javaquickstarter.bat appendfile net stop JavaQuickStarterService move __appendfile stop_javaquickstarter.bat waithidden stop_javaquickstarter.bat endif waithidden taskkill /F /IM java.exe waithidden taskkill /F /IM javaw.exe waithidden taskkill /F /IM javaws.exe waithidden taskkill /F /IM iexplore.exe waithidden taskkill /F /IM firefox.exe regset
"[HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation]"
"InstallingJava32"=dword:00000001 action uses wow64 redirection
false
// Remove any existing directory junction point dos C:\windows\sysnative\cmd.exe /C fsutil reparsepoint delete
"C:\WINDOWS\syswow64\config\systemprofile\appdata\locallow\sun\java"
// delete java directory in 32bit version of system32, if any dos rmdir /q /s
"C:\WINDOWS\syswow64\config\systemprofile\appdata\locallow\sun\java"
// 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) dos mklink /J
"C:\WINDOWS\syswow64\config\systemprofile\appdata\locallow\sun\java"
"%windir%\system32\config\systemprofile\appdata\locallow\sun\java"
// Finally, try to install java... action uses wow64 redirection
false dos C:\windows\syswow64\cmd.exe /C __Download\jre-6u27-windows-i586.exe /norestart /s action may require restart
"3133735f705f1af47d0807585b7c5739df7fbd33"
continue
if
{((exists value
"DisplayVersion" whose ((it >=
"6.0.270") of ((
if (it as string =
"1.5.0") then (it as string &
".00")
else (it as string)) as version)) of keys whose (value
"DisplayName" of it as string as lowercase contains
"j2se runtime environment" OR value
"DisplayName" of it as string as lowercase starts with
"java(tm)") of it) AND (exists key whose (((it contains
"java" OR it contains
"j2se") AND (it contains
"runtime environment" OR it contains
"update")) of (value
"DisplayName" of it as string as lowercase)) of it)) of key
"HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall" of x32 registry
} regdelete
"[HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation]"
"InstallingJava32"
