Now that i have that out of the way.

I have googled, and searched too.

Has anyone how come across an issue where you install java with a MSI and MST (my MST turns off java update, reallysuppress, no systray via properies. made with Orca so its very clean), and it managles the instalations on the second install? My understanding is that if it detects that Java is already installed with the same ProductCode, it will just run a repair?

This is what happens below on a single target machine, run with in cmd with admin rights.
1) install java with transform.
2) test java, all working ok, all happy.
3) install java again, same command as in step 1.

- at this point the install will managle itself, the java dir is semi cleaned out in a way and you are left if 1/2 install with the contents of "core.zip, patchjre.exe, zipper.exe, dir: bin, dir: lib" with not many files in the dirs.

It looks like it just unpacks the core.zip etc and dosent unpack it to finish.

Anyway had an experiance like that?

0 Comments   [ + ] Show Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.


Riley, keep in mind that this is not a true windows installer/MSI installation. All of the files are installed with the vendor custom actions. Therefore, the repair doesn't do any good. I have seen when a repair or re-install totally craps the product. It's not anything that you are doing wrong.

You may want to disable repair by setting the ARPNOMODIFY property to 1.
Answered 01/30/2012 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
What Owen said. Had the same thing happen to me that you described, Riley, but on an older version we had deployed, so I dealt with it by setting ARPNOMODIFY like Owen described.
Answered 01/30/2012 by: RonW
Third Degree Blue Belt

Please log in to comment
Hey all,

Sorry fot the slow response, been busy at work with deployments (boo). Thanks for the tip above, wish i'd asked that a month ago! Guess i know that for the next release.

If you have had the problem and would like to know to remove a "broken" java install, you can throw a repair switch at it which will fix it to a state where the MSI can uninstall it properly (:

Answered 02/01/2012 by: rileyz
Red Belt

Please log in to comment
Hey all,

Repair and rerun of Java is a BAD practice, due to the custom actions which install Java.

The product codes of Java seem the same, but they differ in the last numbers. The x64 version has another product code.
Java 1.6u30 x64: {26A24AE4-039D-4CA4-87B4-2F86416030FF}
Java 1.6u30 x86: {26A24AE4-039D-4CA4-87B4-2F83216030FF}
Java 1.6u31 x86: {26A24AE4-039D-4CA4-87B4-2F83216031FF}

Answered 02/29/2012 by: maasvdhaar
Senior Yellow Belt

Please log in to comment
Thanks for the info Mass.

I will put a link in the Java u30 package notes, will help some other folks in future.

Note for all:
my reference to the repair is to fix a broken java install after the fact it has been broken (before you found out about the above :). Example, we broke our java on our estate by installing java, then installing it again (as it should repair, but didnt). This broke the install, see "at this point the install will managle itself" above. At this point you cant uninstall with the MSI cos some files are missin and its moanig about it.
To get the java install to a working state where you can fix/clean up the mess i used this cmd "msiexec /famv jre1.6.0_26.msi /qb /l*vx c:\windows\logs\JREu26_Repair.log", then i installed java as above.

Hope that makes sense.
Answered 02/29/2012 by: rileyz
Red Belt

Please log in to comment
Hi all,

Here is my changed content:

Preventing Java managles itself on a repair action or the second install action works as follows:
a) change the condition on the 'unzipcore' action, so it runs also on a repair and a rerun during a repair and not during Remove.
b) a repair or a second install will fail (error 1723, msiexec 1603) and the repair / second install will be rolled back if you didn't configure the DisableRollback policy. Hence it will return Java in it's original working state.

This will result in error: "Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action unzipcore, entry: MSIunzipcore, library: C:\Program Files\Java\jre6\bin\regutils.dll." when a second install or a repair is triggered.
MsiExec exits with error 1603, when a repair or a rerun (msiexec /i product.msi is runned more than once) is triggered.
If your 'DisableRollback' policy is not enabled (as default M$) you will keep a working version of Java, unless you tried to repair Java.

Here is howto create:
1) Create with Orca a new transform
2) Open the InstallExecuteSequence table (for silent install)
3) paste Condition "(MODE<>"U" And NOT Installed) OR Installed And NOT REMOVE" for the unzipcore action.
4) repeat step 3) for the InstallUISequence table (for manual install)

This works fine for Java16u30 upgrading to Java16u31 on Windows 7x32 and Windows XP SP3.

It is not possible to uninstall normally a corrupted version of Java due to missing files. You should first repair it with caching the transform.
1) make the transform as described above
2) run msiexec /fav jre1.6.0_30.msi TRANSFORMS=jre1.6.0_30.mst
3) run msiexec /x jre1.6.0_30.msi /q
4) run msiexec /i jre1.6.0_31.msi TRANSFORMS=jre1.6.0_31.msi /q

I'm not 101% sure if it is a good idea to hack the vendors msi (by .mst) by setting conditions on vendors custom actions. It should be better if Oracle / Sun delivers a normal msi with no vendor custom actions. [;)]

Kind regards,

Answered 02/29/2012 by: maasvdhaar
Senior Yellow Belt

  • Maas, quick question.
    In step 4 I cant seem to find the "unzipcore" action in the InstallUISequence table.
Please log in to comment
Answer this question or Comment on this question for clarity