Death, taxes, and a new Java update…all inevitable. The worst of it is silently installing Java doesn’t always go smoothly. Let’s go over some of the most frequently seen Java errors and how you can get them resolved and on to the rest of your day.
Most Common Java Errors
The Java 1603 error is a common error, mostly because the error code encompasses so many possibilities. Basically, a 1603 error just tells you “Whoops! That didn’t work.” Not very helpful, is it? Possible issues range from a previous Java installation still running to issues with installation file itself. Troubleshooting this error can seem impossible.
- Deploy the Java 8 Package If you tried doing a silent install of Java without success, try out the Package Library. The Java 8 package is ready-to-deploy and has been deployed successfully by thousands of sys admins.
- Try the Java 8 – ALTERNATE Package If the first package didn’t work, you may have some prior Java installation remnants impeding your install. The Java 8 – ALTERNATE package is a heavy-hitting deployment. Only deploy this to computers that the first deployment failed on. This package deletes keys found in the registry, and as always, if you can avoid touching the registry, do. That said, this deployment is very effective when you do encounter errors with a typical Java deployment.
If you’re using Symantec End Point Protection in your environment, you might get a 1603 error if you run as the deploy user account. Change your deployments to run as the local system and your install should be successful. You can change the run as setting under the options tab for any step in your deployment.
1618 is another relatively common error code, but is not unique unique to Java deployments. The 1618 error code occurs with MSI installation files. The Microsoft Installer can only process one installation at a time, and if you’re seeing a 1618 error this means that another MSI file was being installed when you attempted to deploy your Java MSI file.
This error is pretty easy to solve…just wait. Let the installation in progress finish up. If you want to make sure all the installation processes are finished before attempting another deployment, you could reboot that computer.
You could also go in and stop the installation, just be aware that killing an in progress installation could leave you with a corrupted installation. With that in mind, use the following command to terminate the msiexec.exe.
taskkill.exe /f/im msiexec.exe
This is included in a command step in the Java ALTERNATE package
I Just Checked My Browser…it Doesn’t Have My New Java Installation!
You’ve just deployed the latest Java, the installation went smoothly. How exciting! But wait…you remote in to one of the computers you deployed to and checked if this new Java was being used and it still shows an old version of Java! What’s up with that?!
Likely, the deployed the wrong Java for that browser has been deployed. Most browsers are 32-bit, so you would want to deploy a 32-bit Java. Deploy 64-bit Java and your 32-bit browser won’t use it. Easy fix, just deploy the appropriate version of Java for your browsers and you’ll be good to go.
Modifying Your Java Installation
I want to configure the Java control panel and/or modify the exception site list
Awesome. Check out a full blog post on how to do that here.
I’d like to use a previous version of Java
If you have an Enterprise license of PDQ Deploy, you can access most past versions of any package. Select a package and you’ll notice in the right corner a list of past version of Java ready to be imported for you to deploy. If you don’t have an Enterprise level license, you can still create your own package by first, getting your install file from Oracle. You can then build your own deployment package in your free download of PDQ Deploy. (See step-by-step how to build your own deployment package here.)