Sun sure can waste huge amounts of my time because they couldn't bother documenting an MST install for their newfangled JRE installer.

Having been soundly defeated in this thread, GPO install of JRE with "STATIC" option, I'm moving on to deploying by Startup Script. I wrote a couple batch files that will install the various JRE's I want, which currently include:

1.6u11 (to x86 and x64 clients)
1.6u12x86 (to x86 and x64 clients)
1.6u12x64 (to x64 clients only)

Nothing happens if they are already installed; the script just exits.

The scripts work PERFECTLY from the command line and as Startup Scripts on WS2003 x32 boxes. All relevant JREs get installed in Static mode.

On WS2008 x64 boxes, it works PERFECTLY on the command line, but as a Startup Script, installs only the x64 JRE. Here's what's weird...

I set up logging in my batch file and SOMETHING is happening for a couple minutes for 1.6u11, and a couple more for 1.6u12x86. Approximately long enough to install the two JREs. But nothing actually gets installed, and there are NO events from MSIEXEC in the Application logs at all. Enabling verbose MSI logging produces this (same for u11 & u12):

MSI (s) (0C:7C) [17:54:11:488]: ******* RunEngine:
******* Product: C:\Windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_12\jre1.6.0_12.msi
******* Action:
******* CommandLine: **********
MSI (s) (0C:7C) [17:54:11:488]: Note: 1: 2203 2: C:\Windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_12\jre1.6.0_12.msi 3: -2147287037
MSI (s) (0C:7C) [17:54:11:488]: MainEngineThread is returning 3
MSI (c) (64:70) [17:54:11:488]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (64:70) [17:54:11:488]: MainEngineThread is returning 3
=== Verbose logging stopped: 3/25/2009 17:54:11 ===

This is just the relvant part, but the whole log isn't much longer.

-2147287037 means "path not found". After logging on, I can verify that the path exists out to "LocalLow", but nothing beyond. Whether because MSI cleaned up after itself or the path was never created in the first place I can't know.

Any ideas why the almighty SYSTEM account can't install the x86 versions but my lowly admin account can?

I'll be happy to post the scripts if someone wants to look them over, but since they only fail in this specific instance, it didn't seem relevant.

[Edit] Same behavior observed with JRE 1.6.0u13. I've filed a bug on don't think this is my problem or Microsoft's.
0 Comments   [ + ] Show Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.


32-bit install from Startup Script fails on 64-bit machines

I'm having the same problem trying to silent install 32bit JRE 6 Update 17 on Windows 7 x64
using the system account. No problem when running installation script with admin account.
Did someone find a solution for it?

Thanks in advance!
Answered 11/26/2009 by: rmoreas
Yellow Belt

Please log in to comment
Just a stab in the dark, I'm not that experienced with 64-bit systems..

Check if your files happen to be in c:\Documents and Settings\Default User\ instead of C:\Windows\system32\config\systemprofile\

If so it means a property in your MSI is being set wrong. Check the installer's Custom Actions to see if there's a distinction made betwwen x32 and x64 UserProfiles
Answered 11/26/2009 by: pjgeutjens
Red Belt

Please log in to comment
I never did solve it, but I only used the script when I didn't know how to make the Static install work with a GPO software install. As of yesterday, I do, so I won't be using the Startup Script any more. If that's what you'd prefer, too, click here for the solution:,-freeware-and-shareware-programs-to-cloning6123
Answered 11/26/2009 by: JRV
Senior Yellow Belt

Please log in to comment
Firstly, I am a new-bee to posting, so please forgive me if I've done anything wrong here (direction/advice is welcome).
I know it's been a long time since the last post but it seems that this issue is still around with the new version of JRE. I have used the batch file deployment method and employed a little registry alteration to get around the issue of the SYSTEM account's lack of cooperation installing the 32-bit JRE on a 64-bit client. I found a batch file which got me part of the way but here's the full version with the registry change that allows both 64-bit & 32-bit installation to work. I will also include the text file afterwards that's used for uninstalling older versions of the JRE (jre-uninstall-list.txt), please be aware that the GUID list may not be complete but remarks in the batch file point you to a way of collecting GUIDs for older versions.

filename: jre-install.cmd
@echo off
set newjava32=jre-6u27-windows-i586-s.exe
set newjava64=jre-6u27-windows-x64.exe
set javasoftwarepath=\\myserverordomain.local\Software Repository\Applications\Sun\Java
cd "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java"

echo Determine 32bit or 64bit OS installation
Set RegQry=HKLM\Hardware\Description\System\CentralProcessor\0
REG.exe Query %RegQry% > checkOS.txt
Find /i "x86" < CheckOS.txt > StringCheck.txt
If %ERRORLEVEL% == 0 (
set ostype=32
) ELSE (
set ostype=64

echo Creating local software repository folder
if not exist "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java" md "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java"

echo Removing previous JRE versions - the GUIDs for previous versions must be entered in the jre-uninstall-list.txt file
rem GUIDs can be found for the older versions by searching the registry on PCs the old version's installed on
rem search in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" for the word "java" the version and GUID info should be indicated
xcopy "%javasoftwarepath%\jre-uninstall-list.txt" "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java" /D /I /Y
for /f %%a in (jre-uninstall-list.txt) do MsiExec.exe /uninstall %%a /quiet

echo Installing current JRE version
if %ostype% == 32 goto 32bit

echo Prepare registry key value for a Sun installer glitch - we'll fix it at the end
reg export "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18" "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java\wowprofile.reg" /y
reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18" /V ProfileImagePath /T reg_expand_sz /d "%systemroot%\syswow64\config\systemprofile" /f

echo Populate the local installation package folder
if not exist "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java\%newjava64%" copy "%javasoftwarepath%\%newjava64%" "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java\%newjava64%"
"%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java\%newjava64%" /qn /s AgreeToLicense=YES REBOOT=ReallySuppress JAVAUPDATE=0 AUTOUPDATECHECK=0 JU=0
ping localhost -n 5 >nul

if not exist "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java\%newjava32%" copy "%javasoftwarepath%\%newjava32%" "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java\%newjava32%"
"%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java\%newjava32%" /qn /s AgreeToLicense=YES REBOOT=ReallySuppress JAVAUPDATE=0 AUTOUPDATECHECK=0 JU=0

echo Removing Java update scheduler
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v SunJavaUpdateSched /f

echo Stopping Java QuickStarter Service
net stop JavaQuickStarterService
ping localhost -n 10 >nul

echo Removing Java QuickStarter Service
sc delete JavaQuickStarterService

echo Put the registry change we made earlier back to what it was
if %ostype% == 64 regedit /s "%systemdrive%\LOCAL DATA\Software\Installs\Sun\Java\wowprofile.reg"


filename: jre-uninstall-list.txt
































I hope this helps someone out there.
Answered 09/21/2011 by: jibber76
Yellow Belt

Please log in to comment


  After a week I manage to find the resolution to this problem.
Instead of using .exe file use the MSI file and the following command:


 WSHShell.Run  "msiexec.exe /i "+Path32+" /quiet",0,true

Path32= the path to may MSI file.
It will work for sure.
I`ve test it.

Using this command I manage to create a start-up script that will look at my PC`s and if there is java 32 or 64 bits on the PC:
   Then:  it will check if is the latest version and install the latest version if necessary.
    Else: if no java do nothing.
Plus it generates a log file to give me some info about the old java version, before update.

I hope you will find useful this info.


Answered 04/25/2012 by: daniel.crisan
White Belt

Please log in to comment
Answer this question or Comment on this question for clarity