I
recently ran into an issue updating the Sun Java runtime (JRE) on our x64
machines where 32 version of JRE is installed. We have lot of systems
with JRE 32bit version installed on Windows 7 and XP 64-bit systems. When I
advertised the JRE 32-bit executable on those systems the installation failed on
the systems with 1619 exit code.
1619
exit code translates to “This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows
Installer package.”
Well,
In Windows 7, processes that run as local system have a special profile found
in c:\windows\system32\config\systemprofile.
Unfortunately, on 64-bit systems, there are two system32 folders; one for
64-bit processes, and another (whose name is syswow64) for 32-bit
processes. As a result, there are two separate system profiles; one for
32-bit, one for 64-bit.
The
Sun Java installer unpacks into a subfolder of the LocalLow application data
directory. In this case, the folder in question is C:\windows\system32\config\systemprofile\LocalLow\Sun\Java\jre1.7.0_11\.
Because this is a 32-bit process, though, it is really writing to syswow64
instead of system32.
The Windows Installer, however, is a
64-bit process. So when it is asked to open the MSI file, it’s looking in
the wrong place; hence error code 1619. The file can’t be opened because
it can’t be found.
As
a workaround you could targeted the 64-bit systems that needs 32-bit JRE by
configuring the program to run under the user context. Well, your end users on
the systems must have admin rights to install when the advert executes on their
system.
You
can also directly pick the extracted JRE MSI content from C:\windows\system32\config\systemprofile\LocalLow\Sun\Java\jre1.7.0_11\
from any system and use this content to create the package and deploy it.
5 comments:
Great tip there.
But I found my MSI under C:\Users\\Appdata\LocalLow\Sun\Java\
as per doco found at; http://www.java.com/en/download/help/msi_install.xml
Hadi: you found it there because you ran it under the user context (and i assume there was a username folder after the "User" folder in your above example where you have the double \), if you run it under the SYSTEM context (as SCCM will do), then it'll be in the folders explained in the article.
Hello, i think that i saw you visited my web site
so i came to “return the favor”.I'm trying to find
things to enhance my site!I suppose its ok to use a few of your ideas!!
Here is my page ... information resource
This is bordering on ridiculous, but you can temporarily change System's profile like this. I've also noticed the installer doesn't even clean up older versions anymore.
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18" /f /v ProfileImagePath /d c:\windows\temp
start /wait jre-8u66-windows-i586.exe /s
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18" /f /v %%systemroot%%\system32\config\systemprofile
I used this technique with update 71 32-bit when installing on Win 7 64-bit. It worked perfectly. Thanks!
Post a Comment