We have received feedback related to giving an option to only allow the upgrade of Java runtime environment when Internet Explorer, Chrome, and Firefox are not open. If browsers are open, it can cause issues during a Java runtime environment upgrade in some cases when the website is running a Java applet.

Starting with Java 7 Update 60, we are adding the option for you to use a custom switch for the install to check for open browsers before the upgrade is started. The switch /checkforconflicts will tell the script wrapper that calls the Java installer to check to verify these browsers (Internet Explorer, Chrome, and Firefox) aren’t open before calling the installer.

By default, we will not publish the updates in our catalog with this switch. You will need to change this manually prior to publishing the update as shown below:

You may want to consider increasing the maximum run time for each Java update that you enable with this switch. By default, the maximum runtime will be set to 10 minutes for security updates. This means if the user has a browsers open the Configuration Manager client will stop monitoring the update installation after ten minutes and move to the next update.

When the Configuration Manager client stops monitoring the install, this will not close the wrapper script that’s being monitored from the Windows update agent. This will cause any updates after the Java update to fail until browsers are closed and the script is no longer being monitored by the Windows update agent.

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

If you notice the Java update failing with code 0x87D00664, that means the maximum time was reached and it’s no longer being monitored by the Configuration Manager client.

If there are other updates that try to install after Java reached the maximum runtime, you will probably see error 0x87D00705. This means the Windows update agent is busy running another update (Java Wrapper Script), and it won’t be able to install any other updates until that update completes.

The script wrapper will create a log in the %temp% directory. Since the script is running in SYSTEM context the log will be located in %WinDir%\temp\PMPC_JavaXUpdateXX64/x86_Install.log. Here is a sample output from the log with the /checkforconflicts switch enabled.

We are looking into adding another switch to allow you to specify a timeout for the script. If the timeout is lower than the maximum runtime for the update, only the Java install will fail and not updates that run after the Java install.