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 installer.

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

Please review Version 1, Version 2 or Version 3 release notes if needed.

Java Wrapper Script Version 4 Change Log:

• The wrapper script will now check for the following additional processes when using the /checkforconflicts option.
  • java.exe
  • javaw.exe
  • javaws.exe
  • javacpl.exe
  • jp2launcher.exe
• The wrapper script will now kill the following processes when using the /kill option.
  • java.exe
  • javaw.exe
  • javaws.exe
  • javacpl.exe
  • jp2launcher.exe

Command Line Argument Supported In Version 4:

• /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 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 cancelled) 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. Starting with version 3 of the Java Wrapper Script, the script will automatically detect and uninstall any previous versions of Java 8. 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 screen shot to show how you could enable the conflicting process check for up to 120 minutes.

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:

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.

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.

Logging:

The script will create a log here: %WinDir%\Temp\WindowsPatchMyPC_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:

The script will also create a verbose log for the actual Java MSI installer file here: %WinDir%\Temp\PatchMyPC_jreversion_x86.msi_Verbose.log

We use the following command line arguments for the Java MSI installer:

/L*v %temp%PatchMyPC_jreversion.msi_Verbose.log /qn AUTOUPDATECHECK=0 JAVAUPDATE=0 IEXPLORER=1 NOSTARTMENU=1 REBOOT=ReallySuppress