Software Deployment

did you grab the accompanying files (like data1.cab) from the AppData folder? The MSI I found there runs just fine.

PJ

Are you sure you can't find the MSI file after you've started setup.exe....?

http://java.com/en/download/help/msi_install.xml

Regards,
Rob.

(This reply was written quickly and will be full of grammer mistakes. If anyone needs any clarification on anything please let me know.)

My Recommendation is to not use the msi by itself. The jre-6u22-windows-i586-s.exe has other processes it calls.

Test everything before you put in SCCM you can use psexec to bring up a cmd window:

psexec -d -i -s C:\windows\system32\cmd.exe
or psexec -d -i -s C:\windows\syswow64\cmd.exe on x64 machines.

When you do a manual install you will find it (on Vista or Windows 7) in the %localappdata%low\sun\java\

Here are some notes on this crazy installer:

Problem1: With SCCM the deployment runs from the SystemProfile. On x86 machines this is fine, however on x64 machines this software does not play nicely. The software extracts out to (non modified Windows Vista x64 or Windows 7 x64) C:\windows\syswow64\config\systemprofile\appdata\locallow\Sun, but the msi actually uses the %LOCALappdata% which always uses the C:\windows\system32\config\systemprofile\appdata\locallow\sun.

My Method for resolving this was to write a massive batch file that did a check for execution from the systemprofile and copy the files from SUN\*.* (This folder is precreated in my package. Such a pain but you do what you need.)
(Dont forget the systemprofile executes from 2 different locations as well as problems with cmd.exe*32 and cmd.exe*64. They will both provide back different variables to things...

Problem2: Java Auto Updater. This is the worst part of this install, the call being made to it actually installs not to the computer but the userprofile that installs it. You can uninstall it but it can be a pain when a user manually installs the entire product.

My Method for resolving this was detect the install path via the registry and use that path to uninstall, if I recieve a 1605 error, I reinstall it in the batch file, then turn around and uninstall it again doing a check for the error. On Windows 7 or Windows Vista it will always end with a 1603 which means successful i guess in Sun's eyes. ugh
I do a futher kill of it by looking for registry enteries that start the java auto update and kill them if they just so happen to exist.

Problem3: Next Generation Plugin. This does not work with half of the sites for my Enterprise, but with it off every site seems to work great.

My Method for resolving this was to run a command to disable the plugin. This is actually tricky because it runs under systemcontext it looks for all logged on users and makes the change to HKUSERs. This means for all the users not logged on the next generation plugin is still on even though the check box is off. In my batch file I write another file that the users can run with out any problem to turn it off or back on.

Problem4: This was by far the oddest error. If a user installs the exe version, but you auto depoy the msi over it, you will be left with a single file in the %PROGRAMFILES%\java\jre6\lib folder. Worst part is the msi says it installs perfectly fine.

My Method for fixing this is to never run in to this again. I do a wmi check and a registry check before my deployment so I make aboustely sure that the right version of java is not on the machine before I start the deployment. This saves me from actually fixing this issue.

(To fix this issue, you will have to repair the product via the msi after fixing any broken reg keys in the classes\installer and etc. After you reinstall, you uninstall then install the version again via the exe. Everything will be right again with the world)

Problem5: JQS. Enough said

My Method for resolving this is to detect and uninstall the service before and after the install.


In Conclusion, I hope Java eventually addresses these issues, so I can again deploy this package with just a small batch file.

If anyone needs my batch file please free to hit me up or if anyone at least willing to test or even help make it better, then I would be thankful. (It needs more testing)

Thanks,
Christopher Holmes

CA Consultant
Microsoft SCCM Engineer

It is there but SCCM doesnt see it as a valid msi. also I cannot run it with msiexec or just running it... any thoughts ?

thanks for suggestion on jqs. i use a similar technique to get rid of jusched.exe and jupdate.exe

Here is the method for detecting if JQS Service is installed.

(Set the logfile to whatever you like, I try to log on both CA DSM side as well as the client side. It makes life easier when finding abnormalities.)

If {%PROCESSOR_ARCHITECTURE%} EQU {x86} SET progloc=%programfiles%
If {%PROCESSOR_ARCHITECTURE%} NEQ {x86} SET progloc=%programfiles(x86)%
FOR /F "tokens=4 skip=1" %%A IN ('sc qdescription javaquickstarterservice') DO set errno=%%A
echo JQS service will be checked and uninstalled on XP machines >> %JAVALOGFILE%
IF NOT %ERRNO%==does "%progloc%\Java\jre6\bin\jqs.exe" -unregister >> %JAVALOGFILE%

**Complete the install of product then**

FOR /F "tokens=4 skip=1" %%A IN ('sc qdescription javaquickstarterservice') DO set errno=%%A
echo JQS service will be checked and uninstalled on XP machines. Last Check >> %JAVALOGFILE%
IF NOT %ERRNO%==does "%progloc%\Java\jre6\bin\jqs.exe" -unregister >>%JAVALOGFILE%

I just found a problem with Java 6 Update 22. They've modified the RemoveFile table in the .msi installer to remove files on both Install and Uninstall, see the InstallMode table. I checked in Java 6 Update 15 and here most entries were listed as '2' while in Update 22 they were set to '3'.

If you try to install Java 6 Update 22 with msiexec /i after already installing it you will fuck up the installation and you won't be able to remove the package again either (you'll have to msi zap).

To fix this change the InstallMode entires from 3 to 2 in the RemoveFile table with an .mst.

Great catch! Have you advised Oracle/Sun (and offered your services as a proper QA function)?

ORIGINAL: VBScab

Great catch! Have you advised Oracle/Sun (and offered your services as a proper QA function)?


Hmm no, should I? I figure they either don't care or that there's some vague reason they do it this way. Considering this .msi install really is a quasi-msi setup, it is plasuible they RemoveFiles on install because they don't have all the setup files in the .msi File Table.

Instead they seem to have a core.zip file, which is installed "by" the .msi File Table and then some custom action unpacks this on the client. Perhaps they use InstallMode 3 on the RemoveFile table to ensure upgrades work properly or something. Then again I don't know why that was not the case for Java 6 Update 15.

What I don't understand is why they can't just freaking stay true to the msi standard.

I also agree great catch.

I actually saw this change back in Java 6 Update 18. It was aboutsely nerve racking to fix. Basically to break, install the exe. Now deploy the msi version overtop of it. This will leave one file in the lib folder and a a successful msi log, but java will be very broken.... :(

To fix, reinstall the msi again from the same location, then turn around and do a remove.... Now reinstall via the exe. (if you are unable to reinstall from the same location due to a deployment type product then rewrite the classes/installer/product /source to point to a location where the files exist.)


As far as notifying Sun/Oracle. They seem like they are not listening. I have sent them email after email with this information and they send nothing in return. There is no longer a customer support number and they rarely open a bug report. I have learned more from these Boards and on my own than Java's support team will ever recongize.

It is a shame that we as Admins, packagers, Consultants, Help Desk and ServiceDeak personal have to figure out wierd ways around a piece of software that is on 100s of Million machines.

It would take them a few minutes longer when building to fix some of the problems I mentioned, and they really need to get back to the basics. They are working hard, but lately I am having trouble figuring out what that is they are working on.

I really wish they would have left jscript alone so I would not be going through this junk...

If they are going to make a big stink about something, then make a product that is not going to give Enterprises a big headache deploying. (We are some of the largest Oracle customers.) Due to where I work, I have deployed every version, from before java 6 update 15 through now java 6 update 22. (even 19 and 20) I think 19 was out for 3 weeks max? I am getting quite good at writing batch, vbs, and powershell scripts to make them work in Altris, SCCM, CA DSM, and CA ITCM to just deploy this junk software on XP, Vista and Windows 7. Both x86 and x64 on all platforms.

I have to say other developers and major product holders are going the same route. Quicktime does not play nicely from the command line either. At least Adobe plays decent, but requiring every update to be dependent on the previous is a pain. Citrix provided a decent batch file to deploy it, and the list goes on.

Well, as somebody reminded us all recently, if this cr@p was easy, we'd be out of a job.

Great posts guys. Do you know if this is an issue with update 21 as well? I am working on the deployment for both 64 and 32-bit with SCCM having strange problems with the EXE.

All, this was discussed in a previous thread I created a couple of months back regarding update 20.

http://itninja.com/question/java-6-installation-issues&mpage=1&key=

User Deranjer found and corrected the issue with a custom MST file. I've used it in my enterprise and works like a charm.

Java 6 Update 18-22 is affected by this issue.

I had a similar issue on an image with Java 6 update 18, I kept getting error return values of 3 in the log.

I had to use the MST with values changed to 2, as mentioned above, and then run "C:\Program Files\Java\jre6\bin\jqs.exe" -register before the msi install would install correctly.

"What I don't understand is why they can't just freaking stay true to the msi standard."

Silverlight, of all freaking products on the market, uses an EXE installer and doesn't support MSI deployment through Group Policy.

If Microsoft doesn't support MSI properly, who the heck else is supposed to? :{

I think you'll find that the EXE extracts and runs an MSI...

You can piece together an MSI yourself, however, the MSI can't be properly upgraded by future MSIs you piece together the same way. I don't think the current way of making your own MSI is supported by Microsoft, either. So if something goes wrong, they'll give you a nice SOL line.

Is anyone else amused by the non sequitor "Java" and "Quick Start"?