5 Replies Latest reply: Feb 3, 2010 3:21 PM by 843804 RSS

    JRE 1.6 u17 deployment fails

    843804
      I have created an MST to go with the 1.6 u17 MSI. Using this combination from the command line (e.g. msiexec -i zzz.msi transforms=yyy.mst -qn) will successfully perform a silent install which does work as expected.
      However, using the same MSI+MST combo via a group policy has the odd behavior of appearing to install correctly - but two files are missing at the end of the installation:
      C:\Program Files\Java\jre6\lib\charsets.jar
      C:\Program Files\Java\jre6\lib\rt.jar
      Other than this all registry keys and files are in place, and according to the event viewer the installation was a success.

      If I manually copy these two missing files into place JRE works as expected, otherwise Java applications do not run - they crash and burn. Even the Java applet in the control panel fails to open without these files.


      Both the manual command line and GPO deployments were performed on the same machine over the existing JRE 1.6 u16 - so the starting conditions are identical.
      This has been a persistent and reproducible phenomenon which has so far prevented me from deploying JRE 1.6 u17 to the workstations, it is not limited to one particular PC.



      The MST performs the following:

      Dialog table -> LicenseAgreement
      set Control_First and Control_Default to LicenseAgree

      Property table
      AUTOUPDATECHECK = 0
      IEXPLORER = 1
      MOZILLA = 1
      EULA_JAVAFX_ACCEPT = yes



      I did notice that when applying from GPO the computer reboots at the end of the installation which doesn't happen when installing from the command line - which seems odd.
        • 1. Re: JRE 1.6 u17 deployment fails
          843804
          [REBOOT=Suppress|http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/silent.html#running]?
          • 2. Re: JRE 1.6 u17 deployment fails
            843804
            The rebooting was just a side note, the real problem is the two missing files.
            Just for the heck of it I modified the transform to set Reboot = suppress and for good measure also RebootYesNo = no

            Not only does this not resolve the issue of the two missing files, the system still reboots after installing from an AD deployment!


            I've noticed that some machines I test this on will have the charsets.jar but are still missing rt.jar
            This leads me to believe that the machine simply reboots too quickly not allowing the unzipcore custom action to complete leaving one or both of the largest files unextracted.
            Interestingly, core.zip is deleted prior to rebooting.


            Which brings up two good questions:
            Why doesn't unzipcore complete? It's set to execute synchronously in the install sequence!
            Why does the system still reboot at all?


            I have a feeling that if I introduce a custom action after unzipcore that simply pauses for 10 seconds everything will work out, but this seems like an unnecessary hack.
            • 3. Re: JRE 1.6 u17 deployment fails
              843804
              Well, that didn't help :(
              • 4. Re: JRE 1.6 u17 deployment fails
                843804
                Having the same issue now with U18, rt.jar is missing after the GPO deployment is done.
                This is really becoming a pain!
                • 5. Re: JRE 1.6 u17 deployment fails
                  843804
                  Turns out this is a similar situation to what I was encountering with JRE 6 u12 in this post
                  here

                  Unlike that time, no pop-up windpw was being generated in the unattended installation, but the installation was still stalling due to iGateway.exe.
                  GREAT JOB SUN - you "fixed" the pop bug up by simply aborting the install, fantastic! [sarcasm]

                  I created a new transform which stops and starts iGateway as per the previous case and this resolved the installation, now JRE 6 u18 installs successfully with ALL the files needed.

                  How you brought back a bug that was fixed four releases ago I have no idea.