I'm in investigating how to deal with this issue in our environment. It’s preventing me from further rolling out Java to version 17. Our apps aren’t certified for version 21 yet (nor do we want to be on the hook on updating Java within a month of each release)
Starting with Java 7 update 17, The Java runtime introduced a feature to consider itself old and out of date as of 05/16/2013. It is essentially a built in expiration. So that means our users on version 17 have started to receive this prompt. A prompt that doesn’t seem to have an easy or reliable way to suppress.
Image may be NSFW.
Clik here to view.
The minor problem, I’d simply like to suppress this dialog from ever being seen by the user. So far this does not look possible without some trickery. The major problem is, if you select “Update” and don’t actually perform the update (you changed your mind or tried but lack of admin access prevented you from updating), then you get stuck in a loop. What happens is each launch of a product that needs Java will launch you straight into the Oracle website for Java 7 update 21. To the user, it appears as if Java is no longer installed. The Java app doesn’t run. It just keeps popping up this Oracle update 21 website.
Luckily you can delete the following registry key (gives you a chance to re-answer the dialog) HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties\deployment.expiration.decision.10.17.2
Or take the value of that key and change it from “update” to “later”
There is a very good discussion going on in the comments of this blog post that I’ve been following. http://www.labareweb.com/java-1-7-auto-update-deployment-with-sccmmdt/
Reading threw the comments, my plan of attack will likely be as follows (if we elect to proceed with rolling out update 17 to everyone)
- Delete entire registry key
- HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties
- Delete the file
- %localappdata%Low\Sun\Java\Deployment\deployment.properties
- Copy a new deployment.properties file containing these 3 lines
- deployment.expiration.decision.timestamp.10.17.2=5/21/2013 14\:2\:51
- deployment.expiration.decision.10.17.2=later
- deployment.expiration.decision.suppression.10.17.2=true
- Launch %programfiles(x86)\java\jre7\bin\ javacpl.exe (this populates the rest of the deployment.properties file
- Kill Javacpl process
- Finished
At this point, if you launch a Java app, the dialog will have already been suppressed and the option to ignore until the next update will be selected. This will get me past ONE release of Java. The problem is, as soon as the new baseline is set at the URL configured at
deployment.baseline.url = https://javadl-esd-secure.oracle.com/update/baseline.version
we enter back into this scenario of the user being prompted (the supersession is no longer valid as a new update has been made available). So I almost need to preempt this but knowing what the next set of registry values are going to be. https://javadl-esd-secure.oracle.com/update/baseline.version is updated now to “1.7.0_21”. Suppressing with the bulleted steps and values above works for now. But when https://javadl-esd-secure.oracle.com/update/baseline.version goes up to 1.7.0_##, what values might I need to consider my expiration decision on version 17 to “stick”?
I wanted to discuss the dialog here to see if anyone is seeing this issue, or a warning to those moving into Java 7 update 17 or 21. The trick listed above is just ugly to me. Creating software delivery policies that perform these actions per user (our machines are shared). Curious if I’m missing something easier or more reliable. I’m also considering the AutoIT task mentioned in the blog I referenced that will essentially answer the dialog on behalf of the user.