Has anyone reviewed the relevance clause in this fixlet for success? Relevance clause 9 sets the relevance for success. This fixlet should not report “Fixed” until the system has been rebooted. Our testing indicates that it reports as fixed prior to rebooting which gives the false impression that the affected system is patched. To be clear this is the patch for Java 7 32 bit running on a 64 bit system. Below is the relevance
if (exists key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation” of registry) then (not exists value “InstallingJava7_32” whose (it = 1) of key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation” of registry) else true
Success Criteria
This action will be considered successful when the applicability relevance evaluates to false
Thanks for reporting this. We are currently investigating on it.
In your case, I believe you will find the “Corrupted Patch” fixlet shows Relevant to indicate that the update is actually unsuccessful. But we will investigate and see if we can improve the original fixlet to make it more straightforward.
The JRE installers are complicated. They may fail at any point of time without rolling-back. It usually uninstalls the old JRE and insalls the new one. Therefore, the JRE fixlets have been designed in such a way that their is one normal installation fixlet and one corresponding corrupt fixlet. So for your case, I believe the corrupted patch fixlet shows as relevant after the normal one applied.
I agree that the action status shows as “Fixed” is misleading. While in TEM terminology, if a fixlet shows “Failed” it would mean that it is still relevant and we should be able to install it again. This will only happen if we do not have corrupt patch fixlets (Which we cannot do away with from past experiences).
Showing “Fixed” is not the ideal solution but a viable work around in this case because of installation issues surrounding JRE’s.
We’ve found the java fixlets failing over 70% of the time on Windows 7 64 bit. If we install manually they work. Seems to be an issue with installing under the BES service context rather than under the user context. Can’t the fixlets be written in such a way as to install via the user context with elevated (admin) permissions?
We’ve incurred countless person hours fixing the failed fixlet upgrades.
We saw this same issue with the 32-bit Java update on 64-bit systems (which has been around for a while: http://forum.bigfix.com/viewtopic.php?id=5819) and ended up making a custom copy of the fixlet, extracting the msi and cab files contained in the exe, and updating the action to download both files and then call msiexec directly. We currently have a ~99% success rate using this method. We can’t run in the user context because we have users that are not administrators on their computers.
The short of the issue, at least from my observation, is that the 32-bit Java exe installer runs in the context of the invoker (SYSTEM account for BESClient), extracts the msi and cab files to what it thinks is the native system profile’s temp folder (by default: C:\Windows\System32\Config\SystemProfile\AppData\Temp), but ends up being caught by the file system redirector and put under the 32-bit temp folder (C:\Windows\SysWow64\Config\SystemProfile\AppData\Temp). When the exe installer calls msiexec (which is 64-bit native), the path to the msi does not get translated to the SysWow64 folder and msiexec ends up not finding the msi under the System32 folder.
Unfortunately, until Oracle figures out how to bypass file system redirection using any of the means Microsoft has documented, or avoid it all together, there will always be an issue with the Java exe installer when run from the SYSTEM account no matter what the deployment mechanism is…
Mayank did mention the MSI method to install JRE (3rd from the bottom). But deathbots’s post (2nd from the bottom) indicated that the msi installer misses some services and the java folder in common directory. I’ve tried this method and found that some registry values are missing as well.
So, etorres, may I know if there is real world problems with this “MSI-installer” method of updating JRE?
I just added one line to his code so that it would not fail when java folder is not exist under system32 folder. The solution works fine in my environment. We just need more extensive testing before we release this solution.
Anyone who is interested can have a try first and please let us know if there is any issue.
prefetch jre-7u11-windows-i586.exe sha1:682fb136563f08c20d37b25a28fce0883f893d8b size:31473568 http:
//download.oracle.com/MANUAL_BES_CACHING_REQUIRED/jre-7u11-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 regset
"[HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation]"
"InstallingJava7_32"=dword:00000001
//if it is win2k/2k3/xp system, just invoke the .exe installer
if
{(name of it contains
"Win2000" or name of it contains
"WinXP" or name of it contains
"Win2003") of operating system
} waithidden __Download\jre-7u11-windows-i586.exe /s /norestart
else
// Remove any existing directory junction point dos C:\windows\syswow64\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 a java folder under system32 folder if not exists
if
{not exist folder (system folder as string &
"\config\systemprofile\appdata\locallow\sun\java")
} dos mkdir
"%windir%\system32\config\systemprofile\appdata\locallow\sun\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
"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-7u11-windows-i586.exe /norestart /s endif action may require restart
"682fb136563f08c20d37b25a28fce0883f893d8b"
continue
if
{((exists value
"DisplayVersion" whose ((it >=
"7.0.110") of (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)" OR value
"DisplayName" of it as string as lowercase starts with
"java 7") 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]"
"InstallingJava7_32"