Java problems - installing packages occasionally leaves clients with a non-working Java
I am seeing come cases where a javaupdate (u60) leaves certain clients with a non-working java. Even though the PDQ-deploy tells me that everything with fine. Any idea why?
Regards, Lars.
0
Comments
It could be that previous updates from Java we not successfully removed during the installation. In the package library there is a JAVA ALTERNATE package for update 60. That forces removal of any older updates. Please try that package on some of your non-functioning Java machines and see if that fixes the issue. Please let us know what you find.
I just ran alternative updates 60 for 32 and 64 bit version of java and I have a bunch of pc's with corrup java installs now. I ran 32 bit first and then 64.
Seems that alternative version is not removing the older java installs and that corrupts the install. So far the only fix I found is to manually uninstall all java, restart the machine and then install the updates again. Any advice on how to force the removal of older versions to work properly?
The alternate package only uninstalls previous updates of the same version. So pushing out the alternate for Java 7 update 60 will only remove earlier Java 7 updates. After doing the package you may need to reboot your systems. The alternate package actually removes the registry entries and deletes the associated directories.
If you are trying to remove earlier Java versions (Java 6, for example) that would need to be done in a separate package.
That is the problem. I'm seeing Java 45, 51 and 55 still there, after running the alternative version, which is supposed to remove all previous versions of java 7. I think the script is corrupt but I deleted all older packages from our library last week and we only have Pro subscription, which does not allow to re-download older packages, so I cannot compare the scripts.
Hi,
Which version of windows is experiencing these problems? Are you using static Java installations on your workstations that are having issues? Normal Java installations use the Patch-in-Place method of installation.
Here's a link referencing those - http://docs.oracle.com/javase/7/docs/webnotes/install/windows/patch-in-place-and-static-jre-installation.html
Also, when you say you're seeing Java 45, 51, and 55 still there, are you referring to seeing them in the Programs and Features uninstall window?
Thanks,
We have Win 7x64 pc's. And yes, seeing those java installations in Program and Features. Been using the alternative java deployment package with PDQ Deploy for a while now. Last 2 deployments, 55 and 60, are giving me issues. I did not alter the package, just download from repository and run.
Thanks,
Have you attempted to manually uninstall those older versions from the Program and Features window? Does it give any errors?
I would try uninstalling all versions of Java from one of your machines as a test. Then, remove all traces of Java from the registry and then try installing Java 7u60 once more. Normally, the ALTERNATE Java install package takes care of that, but it may be running into an error that's not being properly shown, so I think going step by step manually should hopefully give us some better details about what is going on.
Thanks,
Manually removing all software is the only thing that works. Also when manually trying to reinstall, we get RunDLL error: "There was a problem starting C:\Program Files(x86)\Java\jre7\bin\\installer.dll The specified module could not be found" Searching this error messages returns a lot of hits of corrupted/crashed uninstall.
Make that when manually trying to repair/re-install.
That error shouldn't happen if all traces of Java have been removed before installing again. After manually uninstalling all versions of Java, did you remove all traces of Java from the registry? Specifically, there are some entries in the registry that will need to manually remove before any reinstallation will work.
The Java GUID will correspond to a specific version of Java that's installed.
HKLM\SOFTWARE\Classes\Installer\Products\<Java GUID>
HKLM\SOFTWARE\Classes\Installer\Features\<Java GUID>
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<Java GUID>
HKLM\SOFTWARE\JavaSoft\Java Runtime Environment\
Additionally, you can manually delete the "Java\jre7" folder in your Program Files folders.
The error appears if we try to reinstall java without removing older versions. Manually removing older versions is only thing that works. The Alternate version of Java 7 update 60 does not remove any of the older versions of java 7 from the machine. I just ran a test on a good machine, installed update 45, 51 and 55 in addition to 60 and then ran the altarnate update package of java 60 with install portion removed. None of the java installations were removed. You guys need to fix that package and re-issue it. The current one is defective.
If you're installing multiple versions successfully (and it's showing all of them in the uninstall screen), then they are being installed as Static (see link) which our Alternate package does not attempt to remove. Our package only addresses the Patch-in-Place (PiP) installation of Java.
We recommend you use the normal Java 7 package and only use the Alternate version if the normal one fails installation for some reason. When a Java installation fails, it can leave many traces of the failed installation in the registry which can prevent further re-installations. That is why we provide the Alternate version for those edge cases when the original installation fails.
If you try to manually install an older version of Java while already having a newer version installed, all older versions will be installed as Static by default, which our Alternate installer does not attempt to remove. The Alternate package attempts to clear out the Java PiP version before re-installation. The reason we do not attempt to uninstall Static installs is because there are many companies who have software that rely on very specific versions of Java. By not attempting to uninstall Static versions, these companies can maintain their Static installs while keeping their PiP installs up-to-date.
We will definitely take a look at our package and see if there's anything else we can do to improve it based on our conversation.
Thank you,
Thank you.