We recently deployed Java 7 update 11, now that 13 was released we have been getting tons of calls on the below dialog (dialog pops when going to a java page):

 

This seems like a new dialog/update path that we do not want.  We manage java, the users should not install it.

I know this is tied to the security changes in Java, that is another issue we know about and know how to manage but the above prompt does not seem disable-able at least not globally.

I have found that this dialog adds some registry values:

HKCU\Software\JavaSoft\DeploymentProperties... 

deployment.expiration.decision.10.11.2=later ("never" seems to work as long as you put it in the deployment.properties file and delete the registry key so it reloads when java control panel is launched)

deployment.expiration.decision.suppression.10.11.2=fale (true will remove prompt but again tricky since the java control panel will over-write on some occations...).


What really worries me is that these settings are tied to a specific version of java (10.11.2=7 update 11).  I worry that the next release will change the entries (say to 10.13.2=7 update 13) and any disabling will be for naught.

I I I cannot find any official documentation on those regkeys or the dialog.  Anyone run into this?

 

I have found only one other referrence to this on the web, it is on Oracles own site... no solutions there but more info:

 

https://forums.oracle.com/forums/thread.jspa?threadID=2488735&tstart=0

 

 

 

1 Comment   [ + ] Show Comment

Comments

  • I'm up against the same wall. My company has many applications that have Java dependencies and each needs to be tested prior to deploying a new Java version/update. Oracle forcing a new update on us is generating a lot of complaints from users.
Please log in to comment

Answers

1
Answered 02/11/2013 by: jagadeish
Red Belt

  • Thanks for the link, though there are settings to manage other dialogs none effect the dialog and upgrade prompt above. While we can force the "deployment.expiration.decision.10.11.2" settings with deployment.properties file, the settings both in registry and in the users file are over-written when the java control panel is opened/used. I suspect the settings propagate from deployment.properties file to registry just as a generic action but the settings themselves are not fully supported like others (other documented settings in deployment.properties file will over-write registry, the settings noted above do not, there seems to be a default automatically applied both to users file and registry. Not only that but the 10.11.2 referenced in the setting is version specific, the setting will change as soon as another security related update comes out.
Please log in to comment
1

Right, wrong, or indifferent - here's my "fix".  Seems fairly stable and gets rid of most of the popups.  For now at least.  http://www.labareweb.com/java-1-7-auto-update-deployment-with-sccmmdt/

Answered 03/05/2013 by: bretthexum
Yellow Belt

  • I commented on your blog... It is nice but even you own tests suggest it isn't rock solid. From what I have seen those settings will get overwritten on the next scheduled baseline check OR when you open the Java Control Panel applet which seems to immediately perform the baseline check.
  • Yep, agree. This is one I am ready to give up on and take my chances with 1.6. I am interested in what changes if you check the box "dont notify me until the next version is available" and "dont ask me again" on the application permission popup. I've run registry tracers, and can't find anything related. I even tried your comment on deployment.expiration.decision.10.15.2=later and deployment.expiration.suppression.10.15.2=true and it eventually failed again. Unreal isn't it? Something within Java itself must be sending out the commands for this.
    • Yeah totally... I think I am seeing exactly what you are with some success and odd failures... At one point I added the full reg keys deployment.xxxx.10.13.2=later and the other one true. The moment I run the control panel applet it would get overwritten. Tried direct reg edits and deployment.properties file. What I was seeing is that if you put the setting in deployment.properties file, it will propagate to the user reg hive location but won't appear in the users deployment properties file... This I sort of expected since other supported settings don't ever appear in the users file (like security level). The moment you run the java control panel it overwrites the reg AND the users deployment file. Then I expanded to include the couple of date entries, pretty much added all user reg keys (after checking box and hitting later) to the admin deployment file... This worked, and I just started to remove entry after entry until it didn't... didn't happen. The only regkeys I saw edited when clicking on those boxes were in the same deployment.properties key we have already been looking into. Maybe a file/ini is edited somewhere that tells java not to overwrite???? oh I was on crack about the multiple regkeys versions... Thankfully those unique version numbers in the regkeys are related to the version installed and NOT the newest version. That would mean if we every figure it out, that one setting should be good until you package release a new version updating those keys to the new version #.
  • I've updated my post with the messy fix. We're actually looking at group policy to push out the files in the security folder to all users (existing profiles + new profiles) rather than try to script something and modify the default user. It may not work, but worth a test.
  • Using GP to push to user profiles do not work.
    • Group Policy preferences, sorry
      • Did that work for you? we have a small testing group and the users still get the Java is Insecure prompt at random when accessing sites requiring Java.
  • It did for the most part... until the next version of Java came out and overwrote the files. It's not pretty. With group policy preferences the files only come down at login - so if a user sits for 3 days and then Java releases an update - the files will get overwritten. Then, at next login, back to normal (sometimes). I am so sick of Java.... this is beyond ridiculous.
  • Oracle have released a build of Java that does not, by default, display the message that the JRE is below the security baseline. It needs to be downloaded from the Oracle support site not the public release download page. From what I understand, the special build contains binaries that have the baseline check code omitted: Handling the New JRE Security Dialogs (Doc ID 1553875.1) Starting with 7u25, the version of the JRE with auto-update off (see support note 1470691.1) does not, by default, display the message that the JRE is below the security baseline. Users who need to suppress this warning should use that version of the JRE. It is recommended that only enterprises with other mechanisms for keeping the JRE up-to-date use this build. Support Note: Java Auto-Update (AU) Policy Change (Doc ID 1470691.1) JRE builds with auto-update turned off, previously available only to customers of Java SE Advanced and Java SE Suite, can now be downloaded for free from the Java SE Downloads page. (I found the hard way that the public download page version still has the expiration date feature, If it changed system clock to April 25, 2059 the insecure message still showed, but I downloaded from the support site link and it supressed the expiration date with the same test.) Link: https://support.oracle.com/epmos/faces/PatchResultsNDetails?_afrLoop=247344574904963&patchId=16631990&_afrWindowMode=0&_adf.ctrl-state=h4jacbsbd_157 Please read the following before using the JRE build with auto-update turned off: •The JRE build with auto-update turned off is available only for the Windows 32-bit platform, because the auto-update feature is not available on any of the other supported Java platforms. •It is critical that desktops are always kept up to date with the latest security releases. The easiest way to handle this is to use the standard Oracle binaries and let the default auto-update mechanism handle this for users. If you have a desktop management solution in place and prefer to have more control over when and how updates are pushed out, you can use the auto-update-disabled binaries and provision updates through that system instead.
    • How does one go about gaining access to that link. I created an account but it says I do not have access to downloads. If I attempt to gain access, it tells me to contant my Customer User Administrator.
Please log in to comment
Answer this question or Comment on this question for clarity