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.