Demo
Log In
Support

Catalog Release History

We help you save time, money and improve your IT security

Setup Documentation
Release Notes

Java Wrapper Script Version 6.1

UPDATE: Due to Java Runtime licensing changes in Java 8 Update 211 and beyond,  the Java wrapper information below is no longer supported.

Please see our updated guide here for how to automatically remove previous Java runtime installations during the latest update: https://patchmypc.com/remove-previous-versions-of-java-8-runtime-during-upgrade 

We have received feedback related to only allowing the upgrade of Java runtime environment when Internet Explorer, Chrome, Opera, and Firefox are not open. If browsers are open during a Java update, it can cause issues during a Java update in some scenarios.

In order to work workaround to this problem, we created a self-extracting .EXE installer (SFX installer) that will use a wrapper script (VBScript) that can optionally perform various checks prior to calling the Java EXE installer.

Starting with updates Java 8 Update 152 and any future releases, we will be using version 6.1 of the Java wrapper script.

Java Wrapper Script Version 6.1 Change Log:

  • Minor improvements

Command Line Argument Supported In Version 6.1:

  • /checkforconflicts – this command line argument will tell the wrapper script to check if (Internet Explorer, Firefox, Chrome, Opera, or Java processes) are running. The script will recheck every minute for up to the max runtime you specify or until conflicting processes are closed. You need to specify the max runtime in minutes by adding an integer number in the command line argument after the /checkforconflicts. In order for the process check to work, both the /checkforconflicts and an integer number must be defined in the command line argument. For example, you could use /checkforconflicts 120 to specify a conflicting process check for up to 120 minutes. If the time limit is reached and browsers aren’t closed, the script will exit with exit code 1618 / 0x87D00664 (Updates handler job was canceled) in Configuration Manager and the Java update will not be installed. The update installation should retry based on the “Software Update deployment re-evaluation” schedule.
  • /kill – this command line argument will kill any conflicting processes (Internet Explorer, Firefox, Chrome, Opera, and Java processes) prior to installing Java. This should only be used when proper communication has been sent to end users. This could cause loss of data if users are actively working with any of these processes. When using this command line argument, there is no need to use the /checkforconflicts command line argument.
  • /skipuninstall – starting with Java 8 Update 20 and newer, Java 8 will no longer remove previous Java 8 unless they are older than the security baseline. This wrapper script will automatically detect and uninstall any previous versions of Java 8 based on known product codes. This argument can be used to skip the uninstall feature and leave previous Java 8 versions installed.
  • /dontdisableupdates – this can be used to disable our default feature that disables the automatic update check within Java.

How To Use The Java Wrapper Script:

We do not publish our catalog to use any of the command line arguments offered in our Java wrapper script. This means the script will simply call the Java installer regardless of whether conflicting processes are running that could cause Java install issues.

If you would like to use any of these options, you will need to edit the command line in the SCUP 2011 console prior to publishing the update to WSUS.

Here is a sample screenshot to show how you could enable the conflicting process check for up to 120 minutes.

CommandLineSCUP

When using the /checkforconflicts command line argument, you should increase the maximum run time for the update in Configuration Manager. By default, the maximum runtime will be set to 5 or 10 minutes in Configuration Manager.

You can increase the maximum update runtime in the Configuration Manager console in the properties of the update as shown below:

Runtime

Note: The maximum runtime in Configuration Manager should always be at least 5 minutes longer than the value you specify in the command line argument.

If the maximum runtime in Configuration Manager is shorter than the value you specify in the command line argument, the Configuration Manager client stops monitoring the update install. The Configuration Manager client will not close the wrapper script when the maximum runtime is complete.

The script will still be running and will be monitored by the Windows update agent. This will cause any updates after the Java update to fail until script exits and the Windows update agent is free to perform another installation. This is why it is important to ensure the maximum runtime in Configuration Manager is longer than the value you specify in the command line argument.

If you notice Java updates are failing with code 0x87D00664, it means the maximum time was reached.

Error

If there are other updates that try to install after Java reached the maximum runtime, you will likely see error 0x87D00705 (Pause state required).

If the update fails with error code 0x87D00668 (Software update still detected as actionable after apply), it’s likely due to the script reaching the max minutes you defied and exiting before the Java installer was called.

Failed

Logging:

The script will create a log here: C:\Windows\temp\PatchMyPC_jreversion.msi_Install.log. This log will be in a format used by CMTrace.exe, and the log will contain the logging for the wrapper script. Below is a sample of the log:

Test

We use the following configuration are used during the Java install:

/s
/L %temp%\jre-8u152-windows-x64.exe.log (Version number changes between releases)
INSTALL_SILENT=Enable
STATIC=0
AUTO_UPDATE=0 or 1
EULA=Disable
REBOOT=Disable
NOSTARTMENU=1
SPONSORS=0