While I won’t discuss here the sub-optimal way those changes were introduced, you can have a look at the link below to get more information. Most of the content in this post comes from this discussion, but since this is the only available resource so far for the problem, I choose to post information here as well.

http://www.labareweb.com/java-1-7-auto-update-deployment-with-sccmmdt/

Java Version Insecure

As things have changed a lot between JRE 1.7U11 and JRE 1.7 U21, I will just talk about the workarounds that you can use for version JRE 1.7U25 which is more current and that I successfully deployed.

What you need to know:

1. The Security prompts are linked to a fixed date and this date can’t be changed

When you install JRE 1.7U25 today, you will NOT notice this “Your Java version is insecure” popup, because it won’t appear… until November 15th, 2013.

2. Another change in version 25 is the check for Certificate revocation.

If the computer you are deploying the JRE to does not have internet connectivity you will need to change the “Perform certification revocation checks” and set it to Do not check.

This check is done at every launch of the JRE, and prevents the user to bypass the error message.

jrecp

3. If you happen to have Oracle support, then all problems have easy workarounds, otherwise, it gets a little more complex.

4. Only 32 bits versions of the software are “impacted” by the security prompts.

5. This has nothing to do with Java Updates as you know them and for which other settings/workaround do exist.

Effective Workarounds

 

In order to avoid the “Your Java version is insecure” message, you have two potential choices:

A. You download the special version of 1.7u25 that does not check the updated version (you need a support contract from Oracle in order to do so !). The version is named 7U25AUOff (I know the title is misleading, but at least it works). This version will NOT prompt after the expiry date is passed (November 15th in this case)

B. If you don’t have a support contract with Oracle, you will need to deploy files and registry entries to the User Profile (this can’t be done per machine)

The registry keys:

Path: HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties *

“deployment.expiration.decision.10.25.2″=”later”

“deployment.expiration.decision.suppression.10.25.2″=”true”

Both are strings /Reg_SZ

* [on a 32bits OS the path would be HKEY_CURRENT_USER\Software\JavaSoft\DeploymentProperties]

File to deploy

Name : Deployment.Properties

Contents:

deployment.expiration.decision.10.25.2=later

deployment.expiration.decision.suppression.10.25.2=true

Path:

Local Profile path:\ [SamAccountName]\AppData\LocalLow\Sun\Java\Deployment*

*[on a 32 bits OS the path would be Local Profile Path:\Documents and Settings\Application Data\Sun\Java\Deployment.

This workaround has been tested and works.

Note that for version 1.7U17 you just need to replace 25 by 17 in the entries to get the same result.

In order to avoid the Certificate prompts if your machine is not connected to internet

The best way to deal with this is with the standard Java provided:

Just deploy two files to c:\windows\sun\java\deployment

deployment.config

with this content

deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=false

deployment.properties

with this content

deployment.security.revocation.check=NO_CHECK
deployment.security.revocation.check.locked

If you need to set the security level to Medium, add the following lines

deployment.security.level=MEDIUM
deployment.security.level.locked

Note that the *.locked lines make the changes visible when you open the Java console (on 64bits systems, open the 32 bits console, not the one in Control Panel which defaults to 64bits !) and also prevent the user from making changes.

 

Advertisements