Java is like a toddler. When ignored, it demands attention. We all know that it is going to act out somehow. And it probably pooped itself – I’m not checking though. For us administrators, it becomes more difficult to deploy with each version. So far, this theory has held true throughout the Java 8 release cycles. Whether you are just a release behind or very much out of date, you can use this guide to deploy the latest version of Java 8.

 

Getting Java 8 Ready for Deployment

Unlike some previous versions, Java 8 can be easily (and successfully) deployed with just the executable. It can also be deployed by extracting the MSI (as seen in previous Java guides). Personally, I have had better success with the executable in this release.  If your deployment method relies on Group Policy, you can’t deploy the executable with Group Policy Software Installation. You will have to do one of the following instead:

• deploy the executable with a run once startup script 
• deploy the executable with a run once Group Policy Preferences scheduled task
• extract, edit, and deploy the MSI

If you are using SCCM or another deployment suite, I would start with an EXE based deployment. If you see a higher failure rate, swap to the MSI. Download the offline installer from here: http://java.com/en/download/manual.jsp. The version that you deploy depends on the browser architecture version that you use. In most cases, the x86 version will suffice.

Copy the EXE to a network share where computers have read/execute. If you are deploying the MSI, launch the EXE manually now. Once the first splash screen appears, navigate to C:\Users\%USERNAME%\AppData\LocalLow\Oracle\Java\. You should see a sub folder with this JRE version and an MSI inside of that folder. Copy that MSI to your network location (you can keep both the MSI and EXE in case you swap deployments later). If you are unable to find the MSI, use What’s Changed to see where the executable is writing the MSI at.

 

Customizing the Java 8 EXE and MSI Installation Parameters

On a network share, create a new file named java.settings.cfg . We will eventually copy this file down to our clients. Open this file in Notepad and paste in the following:

AUTO_UPDATE=0
EULA=0
INSTALL_SILENT=1
NOSTARTMENU=1
SPONSORS=0
WEB_ANALYTICS=0
WEB_JAVA=1 
WEB_JAVA_SECURITY_LEVEL=H
REMOVEOUTOFDATEJRES=1

You can add additional parameters to this configuration file if needed. For example, you may wish to add REBOOT=0 (though Java almost never requires a reboot). The parameter descriptions and available options are listed on Oracle’s Java Documentation page. Copy this configuration file to each client that will receive this Java update. The file will need to be on the client before installing this version of Java. If it isn’t, you will see this installation error: Unable to install Java. Unable to open file

There are a few ways to get this file onto your clients:

• If you are using Group Policy scripts/scheduled task, you can add a copy command to the beginning of your installation script.
• If you are using Group Policy Software Installation, you can use Group Policy File Preferences
• If you are using SCCM/other deployment suite, you can use the second method above or create a required application that installs before the main java install.

For those of you deploying the executable, wait for us at the next section as the MSI deployers have a bit more work to do.

Now that we have all of the heathen EXE deployers gone, we can talk about really cool things without them …. things like ORCA! As you contain your excitement, right click on the MSI and select Edit with Orca. If you don’t have Orca, you can download from the tools page.

Make the following changes listed below to your MSI. You can either generate a transform file (MST) or make the changes directly to the MSI. A MST is the recommended method though.

• CustomAction\installexe – change type to 3090 (this prevents the dreaded Java MSI Error 1722 from occurring)
• InstallExecuteSequence\SetSilentInstall – change condition to UILevel<=3
• The remaining settings take place under the Properties table
  • Auto_Update: 0
  • AutoupdateCheck: 0
  • JaveUpdate: 0
  • EULA: 0
  • Sponsors: 0
  • Web_Java_Security_Level: H (as of Java 8, H is the lowest security level available)
  • WEB_ANALYTICS: 0

Deploying Java 8 with SCCM or Group Policy

Good to see you again my executable deploying friends. We will start with you all first and wrap up this article with notes for MSI deployment. When deploying the executable, I still keep all the parameters in my command line.

jre-8u101-windows-i586.exe INSTALL_SILENT=1 REMOVEOUTOFDATEJRES=1 AUTO_UPDATE=0 EULA=0 NOSTARTMENU=1 SPONSORS=0 WEB_ANALYTICS=0 WEB_JAVA=1 WEB_JAVA_SECURITY_LEVEL=H

You will also notice a few new parameters: INSTALL_SILENT and REMOVEOUTOFDATEJRES. The REMOVEOUTOFDATEJRES should get rid of any previous versions of JRE. If your software inventory still shows older versions of JRE hanging around, you can use an uninstall script like this one.

If you are deploying Java with SCCM, you can use a few different detection methods:

• You could look for the jre1.8.0_101 folder in Program Files.
• You could look for the MSI Product Code (I prefer to start my application wizard by using the MSI and then changing the installation command to whatever is needed).
• A custom script to detect the Java version (ex: you could query the version with java -version and grab that returned value).

If you are deploying the MSI, you can also use the parameters listed above. The SetSilentInstall MSI change that you made above allows the MSI to be called with the /qn switch. Your command line (if you are using a script), would look something like:

msiexec /i jre1.8.0_101.msi /qn PARAMETERS

This provides a completely silent installation. With all of that work, you can now successfully deploy the latest Java update. If you have any additional suggestions or tips, let me know in the comments below!