This content has been marked as final. Show 9 replies
Hello, we are experiencing the same problem here. I am trying to install the 32-bit version of java 6u31 (jre-6u31-windows-i586-s.exe) via an SCCM task sequence with the /s switch. This runs the installer as the SYSTEM account and whilst it seems to install the 64-bit version fine it fails to install the 32-bit version. I have gone so far as to follow this guide on launching a command prompt as SYSTEM
then launching the jre-6u31-windows-i586-s.exe without any switches. This allows me to see the installer within the SYSTEM shell and I can see the following error after clicking "Install" at the welcome to java screen.
*"The installation package could not be opened, verify that the package exists and you can access it or contact the application vendor to verify that it is a valid Windows Installer package"*
I can only suspect that the installer must extract the msi file to some arbitrary location that the SYSTEM account can't see. I have tried using Universal Extractor to get hold of an MSI file to install this version of java but this so far hasn't been successful.
If this isn't fixed soon I will be forced to try and use an older version of the JRE. Can anyone from oracle direct us to where we can get hold of an MSI file or how to work around this issue?_
PS - It appears to install without error when ran from an administrative user account. Obviously this is no good as we are deploying to 700+ machines and really need it to work from SCCM. I am going to try and use the runas command in windows to see if this will work but I am not holding my breath.
PPS - Runas is no good, as it requires password input and even then it doesn't seem to work very well from the SYSTEM conext.
Edited by: 921104 on 15-Mar-2012 05:14
Edited by: 921104 on 15-Mar-2012 05:16
Edited by: 921104 on 15-Mar-2012 05:19
Is the MSI not able to be extracted through this process?
1. Download and launch the Sun JRE Windows Offline Installion executable (.exe) file.
2. Retrieve the ".msi" file from the LocalAppData folder (the user's Application Data folder). The LocalAppData folder will differ for each Windows platform.
3. Inside this folder you will find a folder named:
The first 2 digits are "71" for version 1.4.2_xx, and "32" for 1.5.0_xx. The last 6 digits of this CLSID and the name of the .msi file correspond to the release number. A CLSID ending with "150000" means version 1.5.0_00, and "142010" means verision 1.4.2_01
Hi RogerL thanks for your tip. I found the java6u31 msi file located at:
This is a slightly different location to the one the guide RogerL suggested but he got me looking in the right area.
I have tested this interactively in the SYSTEM context and it works, I don't see why it shouldn't work with the /qn or /qb switches from SCCM in a task sequence or through software distribution.
I think is can be marked as SOLVED :)
Edited by: d4rkcell on 16-Mar-2012 02:04
happy to hear that you were able to get a hold of the MSI. The alternate location could be due to the OS. We have a second page, the should probably be consistent, that lists the location based on the OS. http://www.java.com/en/download/help/msi_install.xml
How could either of those pages be made easier to find? When you were looking for the MSI or how to obtain the MSI, what documents did you look at where you would have expected to find the instructions?
Has the /qn or /qb switches worked correctly in previous versions of the 6 JRE with SCCM? If so can you give a specific version and the full command string that you used?
OK, so what about that Data1.cab file in C:\Users\%username%\AppData\LocalLow\Sun\Java\jre1.6.0_31? Nobody has mentioned it in this thread. Wouldn't we need to copy the .cab file along with the .msi file? The .msi file is way too small (886 KB) to contain all of the JRE. Without the .cab file in the SCCM data source folder, what does the .msi do? Go out and download it for each SCCM client?
I've tested it on Win7 Pro x64 with SCCM 2007 and having both the .msi and .cab files in the data source directory. It fails every time.
Also, if using only the .msi file, does it download and install those stupid toolbars? We cannot have that in an enterprise environment.
Oracle's support (lack) is worse than Adobe so you just need to Google around.Java support has always been carried on the shoulders of the community really. For the gritty details I've always had to rely on information found in forums, articles and blogs (some more obscure than others) even in the times where Sun still owned the name. Sun did create nice usage documentation though. Things were no different when I was coding C/C++ on Windows systems; MSDN is great, until things start to break down. Then Google is great.
The good thing: the information actually is out there, you just have to make the effort to go and search for it. There is not a single thing I could not solve by asking Google a well-reasoned question AND thinking about it.
The bad thing: Alas, lots of people demand that people repeat that great effort again and again and again by demanding things are rehashed in the forums. Why? So they don't have to search...
But hey, there are good souls who take the time to answer a thread of a few months old and post the links that are helpful, just so that someone else does not have to make any effort. I thank you for your contribution.