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.
We initially created an optional switch with Java 7 Update 60 that could check whether a browser is open and keep checking till it’s closed. Version 1 of the script can be seen here.
Starting with Java 7 Update 65 and Java 8 Update 11. We are adding an additional command like parameter to specify a max runtime of the script.
The /checkforconflicts will tell the script wrapper that calls the Java installer to check to verify these browsers aren’t open before calling the installer (Note: Use all lowercase). The second parameter is the number of minutes before the script will timeout and cause the update to exit.
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:
The command: /checkforconflicts 120 will tell the script to wait until browsers are closed before installing Java for up to two hours.
When using this command line, you should increase the maximum run time for each Java update the command is used on in Configuration Manager. By default, the maximum runtime will be set to 5 or 10 minutes. This means if the user has a browsers open the Configuration Manager client will stop monitoring the update install after 5 or 10 minutes and move to the next update. When the Configuration Manager client stops monitoring the install, this will not actually 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. (Note: The max runtime within Configuration Manager should be a higher number of minutes specified in the max runtime parameter for the update)
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 Installer), and it won’t be able to install any other updates until that update completes.
If the update fails with, The software change returned error code 0x87D00668(-2016410008) it’s most likely due to the script reaching the max minutes you defied and exiting before the Java installer was called. You can see the script log to get more information as shown below.
The script wrapper will log out to the %temp% directory. Since the script is running in SYSTEM context the log will be located in %WinDir%\temp\PMPC_jre1.X.X_XX.msi_Install.log. Here is a sample output from the log with the /checkforconflicts 1 defined.
