Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Java Headaches After Update Release

Posted by William Diaz on October 17, 2013


So Java just released JRE 7 Update 45. This is apparent when someone goes to run a Java applet and encounters the following prompt:”Your Java version is out of date…”

image

For the average home user, this is not a big deal. But in a corporate environment headaches ensue. Why? Because some users will blindly click on the Update button and be redirected to the Java download page for the latest release. The first problem is that our users are not going to have the administrative privileges to update their Java client. But the real problem is that once a user has done this, they will be redirected to the Java download page each and every time they need to run a Java applet. So the question was, how do we get the prompt back so the user can select the appropriate Later option and Do not ask again until the next update is available?

For starters, the property that controls this setting is located in a file called deployment.properties in %userprofile\AppData\LocalLow\Sun\Java\Deployment named deployment.expiration.decision.10.25.2=update:

 

image

To restore the message prompt you need to delete the file and then clear the Java Cache (Java CPL > General > Settings > Delete Files). This will restore the deployment.properties values to the default and force the Java update prompt to re-appear.

Now, for the major problem. As of the latest Java release update, several common websites our users frequent that host Java applets stopped working. These are workstations that did not update to the latest JRE release so this left me scratching my head. As time went buy, the list of problem websites grew so I started to visit some of the sites, enabled Java logging and saw a common theme. For example, a Browse button was no longer working on a site that uses Java to browse a file on the user’s workstation:

image

I ran a search for LiveConnect (JavaScript) blocked due to security security settings and found the culprit in the release notes for the JRE version we are currently using (Java 7 Update 25):

LiveConnect Blocked under Some Conditions

LiveConnect calls from JavaScript to Java API are blocked when the Java Control Panel security slider is set to Very High level, or when the slider is at the default High level and the JRE has either expired or is below the security baseline.

So, in short, with the latest release, our Java 7 Update 25 has expired and thus this security setting is being enforced, which is forcing us to move to medium security for Java applets (Java CPL > Security > Medium).


Update

Since the Java expiration is hard-coded into the JRE, you cannot stop it from knowing when it is expired. However create the following registry strings in HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties:

  • deployment.expiration.decision.10.25.2 with a value of later
  • deployment.expiration.decision.suppression.10.25.2 with a value of true

See Deployment Configuration File and Properties for details on system-wide configuration settings to apply to everyone.

Further, for reasons I don’t yet understand (there no suppression properties are not documented as system-wide), you also need to set these in the deployment.properties file. To do this:

  • Create a file named deployment.config in C:\Windows\Sun\Java\Deployment. This tells Java where to look for a system-wide config file. Apply this line:
    • deployment.system.config = file\:\\C\:\\WINDOWS\\Sun\\Java\\Deployment\\deployment.properties
  • Create a file named deployment.properties in the same location. Apply these lines along with whatever other properties you want to be applied for everyone:
    • deployment.expiration.decision.10.25.2=later
    • deployment.expiration.decision.suppression.10.25.2=true

Leave a comment