Hi,
I recently ran into an issue updating the Sun Java runtime on our x64 machines. We don’t have the budget for fancy deployment solutions, so we just use a startup script (actually an executable, but that’s just fine-tuning) that checks the version number and runs the installer(s) as necessary.
Installing the 32-bit JRE results in error code 1619, which NET HELPMSG translates as “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.” Running the installer in interactive mode produces the same message. The installer works normally when run from the context of a logged-in user.
Several hours of troubleshooting later, I identified the source of the problem. Startup scripts run as local system. 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 real name is syswow64) for 32-bit processes. As a result, there are two separate system profiles; one for 32-bit, one for 64-bit.
So what? Well, 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\AppData\LocalLow\Sun\Java\jre1.6.0_24. 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.
The same underlying problem (duplication of the system profile) seems to be the cause of this problem with Known Folders warning 1002 appearing repeatedly in the event log. Some 32-bit system process is registering folder paths inside the (32-bit) system profile and of course these folders can’t be found by 64-bit processes.
For the problem with installing 32-bit software, there are a number of possible workarounds. You could manually extract the installer files, copy them to a suitable path on the local system, and run them directly. Most installers won’t mind this, although some will balk or fail to function properly. Alternatively (and this is the solution I chose) you could create the necessary directory ahead of time and add a junction point (mklink /J) from the 64-bit profile to the 32-bit profile (note that this command line assumes you are in a 32-bit context, and has been split for readability):
mklink /J c:\windows\sysnative\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24 c:\windows\syswow64\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24
This is the equivalent command if you are in a 64-bit context:
mklink /J c:\windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24 c:\windows\syswow64\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24
Another possible approach would be to merge the two system profiles together and create a junction point from one to the other. That would solve this issue for all installers, as well as the Known Folders issue and any other variants. However, I can’t recommend doing this; it’s too broad a change, and there’s no way to predict what it might break. If you’re very brave, go ahead, but test thoroughly – and don’t blame me!
Hope this helps.
Harry.
