Silent Java Install Failures

Every now and then you will run into a situation where Java (JRE) won’t successfully deploy to a computer. This generally will happen when you attempt to apply a Java update. There can be several reasons for Java failing to install. 

When you go to the Package Library in PDQ Deploy you may notice that we have an extra Java package available. A recent addition is the ALTERNATE package. 

Java 7 Alternate Package

We prefer that you deploy the regular (non-alternate) Java package. However if you experience problems (such as the ol’ 1603 error) when you update targets then you may need to grab the Alternate. What is the difference? 

By default Java will, during an installation, attempt to uninstall previous Java versions of the same family. (i.e. Java 7 Update 17 will attempt to uninstall Java 7 Update 15 but it won’t touch Java 6 since versions 6 and 7 are in different families). If Java is unable to fully uninstall a previous update then the installation will either hang or it will fail with a 1603 error.

In these cases the most common culprit is that the uninstall is not complete and there are a few remnants of the previous update that are preventing any new installations of Java.

This is where the Alternate package comes in. Deploying this package will attempt remove these remnants (registry keys) which are preventing the upgrade. After these keys are deleted the upgrade is attempted again.

The reason we recommend using the Alternate package only when it is needed is because the additonal steps we take will remove only the registry keys which are preventing the upgrade. Other items from the previous install (files and other registry components) may still exist on the target. It’s just kind of a housekeeping thing. We really want Java to perform the uninstall / upgrade because we trust that it is cleaning up after itself.