United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7014194 32-bit JRE silent install fails on WINDOWS 2008 SERVER 64-bit under System account
JDK-7014194 : 32-bit JRE silent install fails on WINDOWS 2008 SERVER 64-bit under System account

Details
Type:
Bug
Submit Date:
2011-01-24
Status:
Closed
Updated Date:
2013-06-26
Project Name:
JDK
Resolved Date:
2011-12-21
Component:
install
OS:
windows_vista,windows_2008,windows_7
Sub-Component:
install
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u22,6u23,7
Fixed Versions:
6u30-rev (b22)

Related Reports
Backport:
Backport:
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

Description
JRE 1.6.0_22 silent install is failing on WINDOW SERVER 2008 when
done in system context (whatever that means)
Works on all other platforms of Windows the customer has tested on.

Here is what they are doing to repro this issue.
***
The local installation of JRE on Windows 2008 using system context does NOT work.  Here is how we test it:

1)      Use ???psexec.exe ???s cmd.exe??? ??? This opens command prompt under system context
2)      Type everything within quotes but not the quotes itself "jre-6u22-windows-i586.exe /s IEXPLORER=1 MOZILLA=1 ADDLOCAL=ALL REBOOT=Suppress JAVAUPDATE=0 JU=0 AUTOUPDATECHECK=0 STATIC=1 /L %TEMP%\in16022.log"
3)      Task Manager shows exe running for 2-3 hours
4)      Nothing happens afterwards ??? no files are installed, no registry entry - Nothing
***

They confirm that the system context has ADMIN rights.

They see no failures. There is no log file generated, although as you can see
they are specifying one. There is not much to go on here.
The install hangs for hours

I had them do the following
From the ADMIN account
open a dos window
execute the above silent install command

This worked, which leads me to believe this is not a JRE issue.
I am not clear on what doing this from System context changes or
if this is supported and should work in the first place.

I can see from the  JRE install doc, WINDOWS 2008 SERVER is a support4ed
platform.

                                    

Comments
WORK AROUND

.
                                     
2011-03-08
WORK AROUND

There is an interaction between Java installer launched from cmd.exe (windows console) running under "System" account and cmd.exe itself.
Installer performs a blocking operation which waits for response from console or just console signals to installer to wait until
a certin condition is fulfilled. 
I need to investigate more the details of this interaction to provide a final solution for this CR.

cmd.exe and Java installer are two separate windows processes
and Java installer doesn't need cmd.exe to continue with installation so
the simple workaround is just to stop cmd.exe process
after it lunches jre installer as a "system" process.

Jre installer will not need cmd.exe anymore 
and will continue as a "System" process with jre installation .

So the workaround will be:

1)      Use ???psexec.exe ???s cmd.exe??? ??? This opens command prompt under system context
2)      Type everything within quotes but not the quotes itself "jre-6u22-windows-i586.exe /s IEXPLORER=1 MOZILLA=1 ADDLOCAL=ALL REBOOT=Suppress JAVAUPDATE=0 JU=0 AUTOUPDATECHECK=0 STATIC=1 /L %TEMP%\in16022.log"
3)      type "exit". It will stop cmd.exe process but will not stop jre-6u22-windows-i586.exe
        which will continue under system account.

or just:

1)
Create a file "Jre_system_install.cmd".
This file has to contain two lines:
jre-6u22-windows-i586.exe /s IEXPLORER=1 MOZILLA=1 ADDLOCAL=ALL REBOOT=Suppress JAVAUPDATE=0 JU=0 AUTOUPDATECHECK=0 STATIC=1 /L %TEMP%\in16022.log
exit

2)      Use ???psexec.exe ???s cmd.exe??? ??? This opens command prompt under system context
3)      cd to a directory containing Jre_system_install.cmd
4)      type "Jre_system_install.cmd" - it will launch java installer under SYSTEM account

UPDATE:
Above workaround didn't work for customer see "Comments" section for details.
                                     
2011-02-22
WORK AROUND

Running 64bit installer (jre*-x64.exe) solves the problem for now and could be considered as a temporary workaround.

Fiducia IT workaround by usinr Windows registry modification doesn't work for me.
On systems I tested these registry entries didn't even exist.
                                     
2011-03-10
WORK AROUND

Looks like Windows problem with accessing
C:\Windows\System32\config or C:\Windows\syswow64\config

Java installer wrapper jre*.exe at the beginning creates *.msi package and then installs that package using msiexec.exe.

If 32 bit or 64 bit jre*.exe is launched under admin account it creates *.msi package in
C:\Users\Administrator\AppData

If 64bit jre*.exe is launched under system account it creates *.msi package in
C:\Windows\System32\config

If 32bit jre*.exe is launched under system account it hangs before it creates *.msi package.


Workaround procedure (to force 64 bit Windows to install 32bit JRE under system account):
---------------------------------------------------------------------------------------------

create *.msi package by running on any machine (for example for jre6u23):
jre-6u23-windows-i586.exe

When it opens "Java Setup - welcome" window just press Cancel button

Goto
C:\Users\<user_name>\AppData\LocalLow\Sun\Java\jre1.6.0_23    (on Server 2008)
or goto
C:\Documents and Settings\<user_name>\Application Data\Sun\Java\jre1.6.0_23 (on Windows XP)
and get
jre1.6.0_23.msi and Data1.cab

Copy these files to a temporary directory on a machine on which you want to install JRE (for example C:\aaa).
Let's assume  PsExec is in C:\PsTools.

Run installation like below:

C:\PsTools>PsExec.exe -s msiexec.exe /i c:\aaa\jre1.6.0_23.msi  /qn  INSTALLDIR=c:\java.dir  /L c:\java.log

It should create a following output:
-------------------------------------------
PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com


msiexec.exe exited with error code 0.
--------------------------------------------

Important:
/qn is a last parameter for msiexec.exe.
All subsequent parameters are for Java installer.
Do not specify /s parameter for jre installer when /qn parameter is specified for msiexec.exe.
/qn and /s  mean the same (installation without User Interface) and can't be specified together.
                                     
2011-03-15
EVALUATION

msi package doesn't get created by 32bit JRE installer wrapper (jre*.exe)
running under system account on 64bit Windows Server 2008.
Further investigation in progress.
                                     
2011-03-15
EVALUATION

On 64 bit operating Windows system (including Windows Server 2008) 
JRE installer wrapper 
install\make\installer\bundles\windows\ishield\wrapper\wrapper.jre\wrapper.cpp
which is a 32 bit application running under system account
attempts to create *.msi and *.cab files in 
C:\Windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_25\
which is being mapped by WOW64 (emulation of Windows32 On Windows64) to
C:\Windows\syswow64\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_25\

AS a next step the wrapper calls:
"C:\Windows\SysWOW64\\msiexec.exe" /i "C:\Windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_25\jre1.6.0_25.msi" 

Looks like msiexec.exe runs as a64 bit application so it doesn't translate
C:\Windows\system32 into C:\Windows\syswow64 and as a result looks for *.msi file in 
in a wrong location.

A Path to msi files is generated by wrapper with 
void GetSingleMSIFileNames(LPTSTR lpszLocalFileName, BOOL b64bit) function located in
install\make\installer\bundles\windows\ishield\wrapper\common\WrapperOffline.cpp

Moreover on a fresh installation of Windows Server 2008 
LocalLow directory doesn't exist in
C:\Windows\syswow64\config\systemprofile\AppData\
which is causing 
BOOL ExtractFileFromResource(HINSTANCE hInst, LPCTSTR lpName, LPCTSTR lpType, LPCTSTR lpszFile) 
located in 
install\make\installer\bundles\windows\ishield\wrapper\common\WrapperUtils.cpp
hang.
                                     
2011-07-28
SUGGESTED FIX

Problem 1:
LocalAppDataLow does not exist on a fresh installation of Windows Server 2008.
        
Fix:
Try to get LocalAppData location instead and then create LocalAppDataLow
in the same location.
                
Problem 2:
Windows doesn't map System32->Syswow64 for location of *.msi files being passed to
msiexec.exe.
For 32bit applications running under 64 bit Windows all attempts to access System32 directory
should be mapped by WOW64 (Windows 32 On Windows 64) emulator to Syswow64 directory.
For some reason System32->Syswow64 conversion/mapping doesn't take place for msiexec.exe
(neither for 32bit version Syswow64/msiexec.exe nor for 64 bit version System32/msiexec.exe).
        
Fix:
Detect location of msiexec.exe by checking following registry:
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Installer\\InstallerLocation"
If the location contains "Syswow64" then it means that
Java installer wrapper is a 32 bit application running under 64 bit Windows 
so replace "System32" string with "Syswow64" string in a path to *.msi files
being passed to msiexec.exe

FVB is available here:
----------------------
/net/nightsvr/export5/users/miroslaw/share/FVB/7014194

Above directory contains jre-6u25*.exe installer bundle:
jre-6u25-nb-bin-b99-windows-i586-17_aug_2011.exe
and the same bundle wrapped with IDR package:
IDRJDK-7014194-541135956.zip

Note: 
There are still two issues to be solved: 
- OpenOffice.jpg banner error message appearing during installation under system account 
- No Java Update Tab in Java Control Panel if installation done under system account
                                     
2011-08-18
SUGGESTED FIX

webrev:
http://jpsesvr.us.oracle.com:8080/ctetools/html/ViewDetail.jsp?index=4230
http://jpsesvr.us.oracle.com:8080/ctetools/html/ViewDetail.jsp?index=4231
                                     
2011-08-30
SUGGESTED FIX

Integration request:
https://jetsvr.sfbay.sun.com:8443/BugApproval/ViewDetail.jsp?index=10933&mode=view
                                     
2011-11-15



Hardware and Software, Engineered to Work Together