Java 1.7 Auto-Update Deployment with SCCM/MDT

10/18/2013 Update – From a comment below.  I haven’t tested this as I’ve given up on Java completely. 

I just wanted to leave a note with how i got this working (there was lots of info in this thread but it was hard to find a clear step by step with success).

– Run the Java exe on a test machine, digg out the MSI + files from the %userprofile%\Appdata\…. area
– Create an MST using ORCA, set the update settings to not update etc.
– Create a blank “deployment.properties” file and have the “deployment.expiration.check.enabled=false” inside it.
– Install the MSI + MST
– Copy the deployment.properties to C:\Windows\Sun\Java\deployment
– Launch IE, browse to http://javatester.org
– Test the version with the button on the site
– Accept the security prompt (in our org. we are leaving this security level HIGH)
– Wait for any pop-up about an out of date version?
– Open up REGEDIT
– Browse to HKCU\Software\AppDataLow\Software\JavaSoft\DeploymentProperties
– You should see “deployment.expiration.check.enabled” REG_SZ false
– Retest by re-loading the Javatester.org website
– Retest by closing / reopening browser and hitting Javatester.org again
– Log off and on as a new user, repeat test to make sure the HKCU is being populated under the new user.
– Package up
– Have a beer

 

**Update 7/25/2013**  Sorry all, haven’t been as active with this as I’d like.  Unfortuntely we had to bite the bullet and get everyone upgraded to the latest and greatest.  It does seem that Oracle FINALLY sees this is massive issue and has released some patched versions for this.  Check all of the comments for the download link.  I personally haven’t even looked at the patches yet, so use at your own risk.  Please also look thru all the comments.  There any many different ways to look at resolving this at least temporarily.

 **Update 6/19/2013**  JAVA 7 UPDATE 25 RELEASED.   It appears a path was released for update 21, nothing that I can see for 25 yet.  From the comments

**Update 5/16/2013 **** PLEASE read all comments before implementing this.  Java has yet again changed the game and made the expiration date unavoidable.  There’s a lot of good info for temporary workarounds in the comments.  Key word … TEMPORARY. 

 

Unfortunately, you need a login on My Oracle Support (MSO). As I don’t have a login I cannot provide you a deep link to this particular patch.

If you have a login, you can sign-in on http://support.oracle.com, click “Patches and Updates”, then search for patch ID 16758419.

BTW: I have applied this interim patch on my PC today and changed the system date to August 10 (which is beyond the expiration date for the official public JRE 1.7.0_21). The infamous update popup did not occur, so the patch seems to work.

Oracle released an interim patch, 16758419, for JRE and JDK 1.7.0_21 (32bit only) with Auto-update Off and Insecure Java Version Message suppressed:

README for 16758419

Patch Details

Bug Number: 16758419

Product Name: Oracle JDK and JRE 1.7.0_21-fcs-b14
with Auto-update Off and Insecure Java Version Message suppressed
– Interim Patch

Platform: Windows-i586

 

some notes from Joe in the comments …

Got some bad news. If you start messing with your system date and set it to 5/16/13, even if you use the suggestions here of baseline.versions folder instead of files, you’ll get prompted. This all appears to be due to the JRE_EXPIRATION_DATE value that is hard coded to that date in 7.17. I tested it with 7.21 which has the variable set to 7/18/13 and it starts prompting you on 7/18 as expected (I mispoke in my post above 7/18 is correct). So I don’t know of any way to beat this.

I’m using this to push anyone with a JRE related app to demand from the vendor to move away from it. What a joke. 3 billion devices and counting … we’ll see about that Oracle.

Java, I do not like you!

 

Well, I am sure almost everyone is aware of the (in)famous Java updating mechanism within Java 1.7. 

Here’s the scenario if you haven’t already witnessed the madness with Java 1.7.x.  At the time of this writing, Java 1.7 update 15 was the latest version.  We package it up just like any other version, disabling auto-updates, and everything looks fine.  Then, we fast forward a few months and update 17 comes out.  No big deal, right?  Our package was set to turn Java auto-update off.  I wish it were so.  Once a user hits a webpage that uses Java, they will most likely see the following prompt.  The scary part – you’d never even know this was a problem until it’s too late.  If you deployed the latest version you wouldn’t see any error messages at all.  It’s only when a new version of Java is released that the messages start arriving. 

Your Java version is insecure.  Click Update to install the recommended secure version.  Click Block to stop Java content in your browser or Later to continue and be reminded again later.

 

error1

 

Unreal.  So let’s go thru the options here. 

Update:  Since 90% of corporate users are not local admins – that won’t work.  Result:  Service Desk Call

Block:  Block the app from running?  That’s why they are at this webpage to start with.  Result:  Service Desk Call

Later:  Well, this one kind of works.  This will at least get rid of the warning but only bring you to another!  Result:  Service Desk Call

Let’s assume a user clicks “later”  They will then see this additional popup message.  

Do you want to run this application?  Your version of Java is insecure and an application from the location below is requesting permission to run. 

 This particular site is just a Java tester site

 

error2

 So here’s our new options.

Run:  This will actually run the Java app.  Result:  No Service Desk Call (hopefully)

Update:  Another attempt to update Java to the latest version (remember, Java auto-update is turned off, right??)  Again, no local admin on most corporate machines.  Result:  Service Desk Call

Cancel:  Stops the app from running.  Result:  Service Desk Call

 

As you can see, sending this to an enterprise-wide distribution is not an option.  This would generate enormous amounts of Service Desk calls and very unhappy users.  This completely blows my mind.  I thought Adobe Flash was bad but now Oracle has topped the list.  I could go on for hours on why Oracle should disable this “feature”.  Until they do, we need a workaround.  Here’s my solution.  Not perfect by any means.  It seems to get rid of *most* of the popups.

You may have to tweak some things depending on your corporate policy/application requirements/etc. 

Remove all older versions of Java (at least 1.7 versions).  My testing with 1.6.x version has been a little strange but I realize application requirement may prevent this from happening. 

  • Verify C:\WINDOWS\sun\java\deployment directory is empty.  If not, have your install script delete this full directory.
  • You need to now create 2 text files, deployment.config and deployment.properties.  These files basically replace the command line switches in the java install.  Here are the contents of deployment.config

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

The top line basically tells the system where your deployment.properties file is located.  For simplicity I just stuck it in the default location but could also reside on the network.  The second line tells the system if this is mandatory.  I don’t know much more about this setting.  Just set it to “true”.

Here are the contents to put into deployment.properties

deployment.expiration.decision=NEVER
deployment.expiration.decision.suppression=TRUE
deployment.version=7.0
deployment.security.level=MEDIUM
deployment.security.mixcode=DISABLE
deployment.insecure.jres=ALWAYS
deployment.javaws.autodownload=NEVER

The key settings above are: 

deployment.expiration.decision=NEVER 

deployment.expiration.decision.suppression=TRUE

These settings suppresses the “Later” button so you are never prompted. 

deployment.security.level=MEDIUM

This is a big one also.  Still not 100% on this one yet.  The default in the Java install is “HIGH” so I hate to set this lower.  The MEDIUM setting seems to get rid of most of the popups.  The only setting I could find that completely suppresses all warning popup is “LOW” but I can’t imagine security departments allowing this.  May as well stick with the older versions of Java.

deployment.insecure.jres=ALWAYS

This setting suppresses the second popup that warns about running the Java application.  Set to ALWAYS

These 2 files need to be copied to the C:\WINDOWS\sun\java\deployment directory.  Have your script create the directory after you delete it. 

Update 3/8/2013 – NEW STEP

  • Create the folder C:\Documents and Settings\User\Application Data\Sun\Java\Deployment\security before installing Java
  • Create 2 files – baseline.timestamp and baseline.versions

Contents of baseline.timestamp is just a period ( . )

Contents of baseline.versions shows up like this.  I believe this is telling Java what the current version is for each (1.8, 1.7, 1.6, etc).  I figured out that when you are prompted it creates this file and the registry shown below.  It defaults to 1.7.0_17.  I changed that setting to 1.7.0_13 to trick it into thinking its current.   Another option to get this file is to break it intentionally and go edit this file.  Crossing my fingers…. seems to work! 

baselline.versions

It also shows up in the registy like this.

registrychangesmall

 

To automate this, you’ll need to create a script to walk the directory tree and add this to each users profile.   You can also use group policy which may be a bit easier. 

 

**Make sure these 2 files are present before installing Java. **

  • Install Java 1.7 with only a /qb or /qn switch.  No need to add any other switches since your files are now in the correct place. 
  • TEST TEST TEST!  Again, this is a far from perfect solution and differences will apply between corporations.  I am not a Java expert by any means – so let’s discuss any other options or repercussions! 

Also, a tip on locking the Java settings after deployment from the comments of Rafal below

Just a comment about config and properties file
if you want to prevent users from changing Java control properties you will need to place .locked on property you are changing in the properties mark
therefore
deployment.security.level=MEDIUM
deployment.security.level.locked
will effectivelly lockout/greyout the setting for the user

Hope this helps!

 

**Update 4/24***

Well, I managed to blow up my environment when Update 21 was released.  My group policy workaround for the files was set to update, not replace.  So if the files were already there and Java overwrote them, group policy didn’t care and saw it as compliant.  TONS of calls.  Ugh Java.

Read thru all the comments below as there are some other ideas that may work.  I think I may have thrown the white flag up and may just do some extensive end user training.  Just don’t hit the “update” button!!!

This is obviously a HUGE issue.  The blog has seen 25K hits just on this page since written.  Hopefully we can still figure it out eventually

 

Possible workaround – from Morgan in comments.  Worth trying.  Update 5/17

I created the following until Oracle gets there act together. It’s an AutoIT script that looks for the update window and then selects the ideal combination for the user. You can deploy it in the startup folder for users and there is very little CPU impact. Feel free to use and modify as you like.

http://www.autoitscript.com/site/autoit/

 

CODE HERE—- javafix.txt

 

Share
This entry was posted in Application Packaging, MDT, Patch Management, SCCM 2007, SCCM 2012 and tagged , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback.

212 Comments

  1. neuvilleromain
    Posted March 5, 2013 at 11:45 am | Permalink

    Thanks a lot for this.
    Oracle doesnt realize how much his reputation suffer with this “problem”.
    Java sucks and i ll hope dev will stop working with this thing.
    We have a lot of TSE/Citrix servers and i m going to test deeply your solution but it seems to work.
    Thanks again and bye !

    • LaBareWeb
      Posted March 5, 2013 at 2:41 pm | Permalink

      Great to hear. Let me know how it goes with Citrix. That’s my next task also.

      • Brian K
        Posted July 18, 2013 at 2:31 pm | Permalink

        LaBareWeb,

        thanks for your postings. The patch you refer to 16758419, is that for the standard JRE 1.7.21 software or is it for Oracle Java SE advanced?
        Once you installed the patch you stated the popups were gone.

        • LaBareWeb
          Posted July 18, 2013 at 3:16 pm | Permalink

          I believe it was for the standard 1.7 Update 21. I didn’t persue it any further, we just upgraded again to 25. Any others actually install and use the patch 21??

          • fl0w3r
            Posted September 12, 2013 at 11:07 pm | Permalink

            Now with 7 update 40 out, have your users in java 7 update 25 have reported the “java insecure message”?

  2. Rob
    Posted March 5, 2013 at 6:35 pm | Permalink

    Works for a few websites, then Java whacks the settings in the user profile and registry and you start getting the upgrade prompts again!
    This is getting ridiculous!

    I’m trying to figure out where the java client is polling the baseline version from – if I can block that website…

    • LaBareWeb
      Posted March 5, 2013 at 7:45 pm | Permalink

      Haven’t seen that yet Rob. I’ve only deployed to about 50 machines however. I am seeing some strange behavior when multiple versions of Java loaded though.

    • Ryan
      Posted March 6, 2013 at 3:04 pm | Permalink

      Curious if you figured out what URL or IP to block at the firewall to prevent the JRE from “phoning home.” Please post if you did.

  3. LaBareWeb
    Posted March 6, 2013 at 3:58 pm | Permalink

    Well, now I am seeing the same issue where it works for about 3-4 websites, then decides to reset itself and prompt. You can see this happen by viewing the C:\Documents and Settings\user\Application Data\Sun\Java\Deployment -> deployment.properties. When it’s working correct it’s populated from the deployment.config file … when you open it you can see the settings.

    Then for whatever reason – It doesn’t see it anymore or its cached? It fails to work completely going forward. The only way I’ve found to make it work again is delete the whole Sun directory from C:\Documents and Settings\user\Application Data\ folder. Then it seems to regnerate the correct file. This is a strange one. I’ve updated the article above with this info.

  4. Dan
    Posted March 7, 2013 at 6:33 pm | Permalink

    From what I have seen deployment.expiration.decision=NEVER type edits in the properties file is only temporary and those can be over-written, usually when you open the java control panel applet or when you go to a Java site and it performed the baseline queries… It will overwrite the registry and then the properties file ignoring the admin template you setup.

    If I were to guess, it is because the admin file does not directly support those settings, it may propagate them but they will get over-written.

  5. Dan
    Posted March 7, 2013 at 7:24 pm | Permalink

    I retested and am correct… the deployment.expiration.decision=NEVER settings is just a placebo… While the admin deployment.properties file will propagate the setting, it does not support it completely…

    It doesn’t matter to the client, it will still check and create the custom regkey it needs aka deployment.expiration.decision.10.15.2 (for update 15). Opening the Java control panel applet will initiate this check immediately.

    You then check the users deployment.properties file and the new settings will appear.

    The only way I can see “hacking” it right now is to generate multiple reg entries covering multiple versions that will come out in the future aka

    deployment.expiration.decision.10.15.2=later
    deployment.expiration.suppression.10.15.2=true

    deployment.expiration.decision.10.16.2=later
    deployment.expiration.suppression.10.16.2=true

    deployment.expiration.decision.10.17.2=later
    deployment.expiration.suppression.10.17.2=true

    The other option is to create a GPO that you can quickly edit and push to minimize support calls and issues when a new version is released.

  6. LaBareWeb
    Posted March 7, 2013 at 7:27 pm | Permalink

    Dan, I’ve been going down that path also. Thanks sir – I will try this. Hopefully we can get this figured out once and for all!

    Appreciate it!

  7. Dan
    Posted March 7, 2013 at 9:48 pm | Permalink

    ok since there does seem to be this weird over-write everything when you run the Java applet, I can’t be sure… This seems to be working but the first time I tried these type of tests, I did get to a point where the control panel applet overwrote everything no matter what I did.

    1. Started with our base image which includes Java 7 update 11
    2. Manually installed Java update 13 (we are working on 17 but I wanted to be sure this would still work when upgrading again…
    3. Went to javatester.org/version.html to cause the dialog (sometimes I had to wait a bit, others just required launching and closing the control panel applet to kick it off).

    4. SAVED my VM… I want a known bad config:)

    5. Delete HKCU\Software\Javasoft\DeploymentProperties key (whole thing)
    6. Delete Deployment.properties file in the user profile

    7. Updated my admin deployment properties with the following:

    deployment.expiration.decision.10.13.2=later
    deployment.expiration.decision.suppression.10.13.2=true

    NOTE: the 10.13.2 number is specific to the version of java that is installed. If/when you upgrade this will be to be updated.

    8. Ran Java control panel (you will notice that the deploymentproperties reg key is back and populated with both the stuff in admin deployment.properties file and a few others). You also will notice that the users file has NOT been updated yet, but it was created.

    9. Ran the test site… no upgrade dialog… Surprising the reg entries were NOT added to the users deployment file.

    This seems to work but I have been fooled by this, as I said there was one test where I was doing a similar procedure and the control panel applet would overwrite both regkey and the users properties file.

    You mentioned this in your blog, but if the admin file is working properly you should NOT see the setting in the users properties file. I think where are getting into trouble because it IS getting updated there and sometimes with the wrong setting…

    I think this is how it is supposed to work

    admin file> user file> user registry I have seen setting propagate back and forth from the user file to the registry and vice versa. If the user file is different then the registry it will overwrite the registry. If the setting is missing from the file the registry version will write to the user file. Opening the control panel seems to open/edit both user reg and file.

  8. LaBareWeb
    Posted March 7, 2013 at 9:57 pm | Permalink

    I have another hack that seems very promising. I am going to let it cook overnight and post it tomorrow. So far I can’t break it. Over 100 java loads, reboots, open java console, etc. Of course, I’ve said that before :)

    • Dan
      Posted March 8, 2013 at 12:51 pm | Permalink

      Can’t wait to hear it…

      Will test mine some more… I think the trick is that the user file and registry have to both be empty/missing the entried before the admin properties file is applied.

      Seems once a setting is in either of those 2 places havok occurs.

      I think I will be working on that assumption and add an activesetup script to clean up those areas when pushing 17.

  9. Dan
    Posted March 8, 2013 at 2:09 pm | Permalink

    Well I have been seeing pretty consistent results…

    The settings below have consistantly not worked for me at all.
    deployment.expiration.decision=NEVER
    deployment.expiration.decision.suppression=TRUE

    These settings seem to work consistently for me:

    deployment.expiration.decision.10.13.2=later
    deployment.expiration.decision.suppression.10.13.2=true

    The above is for update 13, you will have to adjust for your version, if doing 17=10.17.2

    The catch I have been seeing is that if either of those settings already exist in either the HKCU or the users properties file, the admin file will be ignored. There is some other thing I am missing, but I do know that if those locations are removed, Java sets them properly the next use.

    Just a little observation:

    When you open the Java control panel applet, it puts the admin property file settings in the registry.

    When you actually run java content, those registry settings are then added to the users property file (if the EXACT settings is not already in the admin file).

    You know the admin file is working properly if the user properties file does NOT contain the same settings in the admin file.

  10. LaBareWeb
    Posted March 8, 2013 at 2:47 pm | Permalink

    Updated the post above. Give that a try and let me know. Cross your fingers!

    I thought I tried the method you have here and it broke for me. Will double check though

    • Dan
      Posted March 8, 2013 at 4:11 pm | Permalink

      Let me know what you are using to test. You mentioned that after 3-4 sites, things seem to reset. Is that still true?

      I know what you mean… I think I tried it sort of as well. I think the issue is 2 fold, one the decision. settings need to have the version. The settings that don’t have the version seem to get ignored, I don’t think they are supported. The second thing is preventing the settings to getting in the users properties file, once it is there the admin file is ignored and the user file overwrites any reg changes.

      I hope those file changes work but at some point I think the client calls home to update that data, otherwise how would those baselines get updated to tell the client there is a new version available???

      Also just fyi… Low security settings will remove the java based dialog/update prompts the second one you posted in blog.

      The first one is the dickens!

    • Nina Duke
      Posted October 2, 2013 at 3:59 am | Permalink

      Sorry, LaBare.. updated what post above where?
      (-_-)’ am I not spotting an obvious solution?

  11. LaBareWeb
    Posted March 8, 2013 at 4:16 pm | Permalink

    Sorry, ignore that 3-4 sites section – I just deleted that. That was old …

    I am also worried about the new verison phoning home. Really the only way I am testing this is using version 13. We’ll have no idea if this works with .17 until the next one comes out.

    What I may do is send this to a pilot group and wait until the next version comes out. See what happens then. So far so good with my hack though. Still can’t break !

  12. Dan
    Posted March 8, 2013 at 4:46 pm | Permalink

    You are I are doing the same thing, testing with 13… I haven’t seen too much difference in the mechanics though we are talking about Java/Oracle here!

    The tricky part is that there has to be some update/check timeframe… Maybe it only checks and updates every 24 hours?

    Well I created the following VBS to remove both the HKCU hive and the user deployment file. It’s a bit sloppy, but works… You have to run it for each user, I plan to use ActiveSetup for this…

    On Error Resume Next
    ‘Sets object shell/File for later use.
    Set objShell=CreateObject(“Wscript.Shell”)
    Set objFile = CreateObject(“Scripting.FileSystemObject”)

    ‘Sets Current User profile path
    strUserProfile=objShell.ExpandEnvironmentStrings(“%USERPROFILE%”)

    ‘Sets up for HKCU registry edits
    const HKEY_CURRENT_USER = &H80000001
    strComputer = “.”
    Set oReg=GetObject(“winmgmts:{impersonationLevel=impersonate}!\\” &_
    strComputer & “\root\default:StdRegProv”)

    ‘Queries WMI for OS caption (aka name)
    strComputer = “.”
    Set objWMIService = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\” & strComputer & “\root\cimv2″)
    Set oss = objWMIService.ExecQuery (“Select * from Win32_OperatingSystem”)

    ‘Checks WMI caption and puts into the StrOS string
    For Each os in oss
    StrOS=os.Caption
    Next

    ‘Checks if the StrOS string contains “XP”, to determine if XP or not. Then sets file and reg paths to Java files/settings based on OS.
    If InStr(StrOS, “XP”) Then
    StrJavaRegKeyPath=”Software\JavaSoft\DeploymentProperties”
    StrJavaDeploymentPropertiesPath= strUserProfile & “\Application Data\Sun\Java\Deployment\deployment.properties”
    Else
    StrJavaRegKeyPath=”Software\AppDataLow\Software\JavaSoft\DeploymentProperties”
    StrJavaDeploymentPropertiesPath= strUserProfile & “\AppData\LocalLow\Sun\Java\Deployment\deployment.properties”
    End If

    ‘These lines actually remove the registry key and file.
    objFile.DeleteFile(StrJavaDeploymentPropertiesPath)
    oReg.DeleteKey HKEY_CURRENT_USER, StrJavaRegKeyPath

  13. Dan
    Posted March 8, 2013 at 5:07 pm | Permalink

    Here is my activesetup reg info..

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\HC_Java_Reset]
    “Version”=”1,0″
    “StubPath”=”\”c:\\Windows\\Sun\\Java\\Deployment\\Java_DeleteUserSettings.vbs\””
    @=”Java”

    Obviously it assumes the above script is installed with java @ c:\\Windows\\Sun\\Java\\Deployment\\, the same place as my admin properties files, path works for XP and Win7.

  14. Dan
    Posted March 8, 2013 at 8:25 pm | Permalink

    I will try and post back… The config I have been working on is going to lab next week, then 2 pilot groups 1 a week. Afterwhich it will go to everyone else.

  15. LaBareWeb
    Posted March 8, 2013 at 8:36 pm | Permalink

    Same here. I am packaging in Wise today and will try this Monday or Tuesday. Thanks for the insight sir!

  16. LaBareWeb
    Posted March 11, 2013 at 1:32 pm | Permalink

    Well, this fix still works after letting it sit over the weekend. Messy – but seems to do the trick

  17. Larry BK
    Posted March 12, 2013 at 11:28 am | Permalink

    Hi guys, Many thanks for providing a solution. I am working with Java 7 update 13, which has bene signed off my my pilot group, but I will not role out to all 1000+ corporate users in my company due to this “Java Insecure” prompt

    I have followed your instructions above, and deleted the deployment propertries reg folder and user profile file. It seems accessing the website for the first time once all settings are in place the site opens fine with no prompts.

    On accessingt the site the second time, the prompts return

    After checking the user reg keys at hkcu\software\appdatalow\software\javasoft\deploymentproperties, all of the suppression settings are reversed to the old settings, and the deployment file has returned to the user profile location, in turn this completely ignores the deployment file at C:\Windows\Sun\Java\Deployment

    I have noticed the 1.7.0 security baseline regkey is set to 1.7.0_131.6.0_41

    Setting this to just 1.7.0_13 does not help.

    I have followed the insructions twice and I don’t believe I have missed anything?

    Can you think of anything I can check?

    Many thnaks

    Larry BK

  18. KnifMelti
    Posted March 12, 2013 at 11:50 am | Permalink

    Thank you all for all the hard work!
    Took your tip/advice an implemented it in our school network today:

    Via Group Policy Preferences/User (every log in):

    * Delete HKCU\Software\JavaSoft\Java Runtime Environment\Security Baseline
    * Copy modified files
    XP:
    %AppDataDir%\Sun\Java\Deployment\deployment.properties
    %AppDataDir%\Sun\Java\Deployment\security\baseline.timestamp
    %AppDataDir%\Sun\Java\Deployment\security\baseline.versions (ver. 1.7.0_15)
    Win7: %SystemDrive%\Users\%LogonUser%\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
    %SystemDrive%\Users\%LogonUser%\AppData\LocalLow\Sun\Java\Deployment\security\baseline.timestamp
    %SystemDrive%\Users\%LogonUser%\AppData\LocalLow\Sun\Java\Deployment\security\baseline.versions (ver. 1.7.0_15)

    Now it’s just a matter of not updating to 1.7.0_17 or higher (if Oracle changes something)!

    Once again; thank you!!!

  19. LaBareWeb
    Posted March 12, 2013 at 1:39 pm | Permalink

    Larry, is the baseline.versions file incorrect? That’s what I am seeing when the deployment.properties file gets re-created in the user profile. There are those weird characters in between the versions (maybe carriage returns) that need to be there. The easiest way I found to get this file is install it on a test box normally and wait for the security prompts to show up. Then if you open that file in notepad you can change the 1.7 version from 17 to 15 or 13.

    It doesn’t matter what’s in the registry – it seems to pull that setting in the file and overwrite it.

    KnifMelti – Great to hear!

  20. Larry BK
    Posted March 12, 2013 at 3:27 pm | Permalink

    Thanks lad! This looks good and I’ll leave the fix in place over the next few days on my PC, continually test it before repackaging and deployment to my pilot group.

    With regards to the baseline.versions file, after completey removing Java from the PC, associated files and reg keys, Java reinstalled, I accessed the site in question and I got my prompts.

    After checking the baselines file again, all of the versions showed up on a single line, as shown in your screen shot above, but it did not have the carriage return or symbol between each version

    To get around this I moved the cursor to end of each version, pressed ctrl-return, and resaved the file. Each version is number is on its own line and I changed the Java 7 version to 13

    Cheers!

  21. KnifMelti
    Posted March 12, 2013 at 6:59 pm | Permalink

    Those symbols/weird characters are Line Feeds (HEX 0A, DEC 10) and is standard *nix way of breaking a line (DOS=CR+LF, MAC=CR).
    I don’t think it’s a good idea to introduce the DOS way of breaking lines in this file given it’s read by the JRE engine.

    I don’t bother with the mandatory “C:\WINDOWS\sun\java\deployment\deployment.config/deployment.properties”.

    Instead I just delete the registry key “HKCU\Software\JavaSoft\Java Runtime Environment\Security Baseline” and copy the modified “baseline.versions” (in my case with version change to 1.7.0_15 because that’s the version I’ve deployed), the proposed “deployment.properties” and the “baseline.timestamp” to every users environment every time they log on via Group Policy Preferences.

    And it’s working out of the box.
    Again, thanks; it’s been a pain.. ..and a lot of Help desk calls from our users on 3000 machines before this :-)

  22. LaBareWeb
    Posted March 12, 2013 at 7:34 pm | Permalink

    Awesome. I am hoping we finally have this figured out?!? :)

  23. KnifMelti
    Posted March 12, 2013 at 7:38 pm | Permalink

    Hopefully, until Oracle changes the system.
    It’s a way for them to say – Hey, you as a user made all the decisions; it’s not our fault if you were attacked!

    I’m not updating anymore for a looong time ;-)

  24. happyphunn
    Posted March 13, 2013 at 4:05 am | Permalink

    I set up everything according to what is outlined here and still have a question that doesn’t see to specifically be addressed. I have a website that requests to use 6.31. If I have a machine with only 6.31 or higher, the website works. If I install, for this example I am working with 7.15 as well as 6.31 everything still works but as soon as I put a higher version then 6.31, in this case 6.41 I now get a prompt stating: “This application would like to use an old version of Java (1.6.0_31) that is not installed on your system. We recommend running the application with the latest version of Java on your computer.” The only options are “Run with the latest version” (which will fail since the app needs 6.31 or higher of version 6 but not version 7) and “Cancel” which of course doesn’t actually run the app. If I have the combination of 6.31 and 7.15 installed then the app works. Then if I upgrade 6.31 to 6.41 the app WILL work as long as you don’t clear the cache (..\Deployment\cache). Once you do that the prompt will come up. This is not what I expect to happen. I would expect the same thing to occur as what happens when there is no version of 7 installed but 6.41 is installed where even though the site is looking for 6.31 it will go ahead and launch using 6.41. Any way around this?

  25. rakim0815
    Posted March 13, 2013 at 9:13 am | Permalink

    I’d like to thank you all, you saved me a lot of time and research.

    Any experience with Update 17 yet? Did they fix this weird update behavior?

    • LaBareWeb
      Posted March 13, 2013 at 1:52 pm | Permalink

      rakim0815 – That’s the biggest problem for me. I’ve done all my testing on Update 13 (to get the error popups) but am deploying Update 17 with the same methodology hoping nothing has changed. My plan is to send to a pilot and wait for the next release to come out. Then if everything still works deploy to everyone.

      We willl see.

  26. LaBareWeb
    Posted March 13, 2013 at 1:44 pm | Permalink

    Yeah happyphunn – I am having some big time issues trying to work around multiple versions of Java also. Still working those details out but I am ready to give up since it’s not an application requirement.

    If I come across anything for that I’ll update the post. Gotta love Java :(

  27. Waylon
    Posted March 13, 2013 at 4:58 pm | Permalink

    If this helps anyone, I am running multiple versions of Java 7 so I just put version 13 in the baseline.versions file and it really doesn’t seem to care that it is an earlier version. All my popups are gone for now. I’m still testing however but so far what KnifMelti posted along with LaBareWeb’s files work for me. Hopefully I can push this out next week.

  28. itguy
    Posted March 13, 2013 at 8:26 pm | Permalink

    A milion thank yous to all that have dontributed above!!

    In my case, we have already rolled out 7u13 to almost 6000 systems. So I am looking for a ‘post install’ solution.
    I have packaged all of the above actions (overwriting files where necessary) with two additions:
    I import the reg key found at HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties. When importing, I am setting the deployment.expired.version=10.18.2 hoping that Java won’t change the current logic for at least one more update.
    I am also importing HKEY_CURRENT_USER\Software\JavaSoft\Java Runtime Environment\Security Baseline and setting the 1.7.0 key to 1.7.0_13 which is the version we rolled out.

    Do you think this approach is feasible?

    Also, what if the above is applied, but the user has already updated to 7u15 or 7u17? Based on what you have seen in your testing, would you expect any additional problems?

    • LaBareWeb
      Posted March 13, 2013 at 8:37 pm | Permalink

      I haven’t had much luck changing the registry itself on the baseline – I’ve had much better results with the files themselves. The registry seems to pull the baseline from those files. When I tried editing the entries in the registry it would revert back to 17.

      I have a few users on 13, a few versions on 15, and a few on 17. So far so good with the same files. *knock on wood….

  29. Ian
    Posted March 14, 2013 at 9:05 am | Permalink

    Thanks for the comments!
    In my virtual environment (Citrix XenDesktop) I didn’t want edit my vDisk just for the Fu#@!&&@?!!!!§! java… ;) so I used the Citrix SSO to check the box and clic later automatically, the popup is seen quickly but no action is required by the users…
    It’s a tips not a solution! Luckily java is dying

  30. Jane Frasier
    Posted March 15, 2013 at 6:22 pm | Permalink

    This is great BUT I can’t get the deployment.config to use a deployment.properties file on a network server. It worked with Java 1 update 6xx. I am using this URL (file://///server/softwareinstalljf/java/deployment.properties) and if I put that in IE the contents of the properties file are displayed so I know that this computer can connect to the network share. If I open the Java control panel it insists on putting a new properties file in the users profile

    Any ideas?

    • LaBareWeb
      Posted March 15, 2013 at 6:31 pm | Permalink

      I haven’t had much luck with a network file – switched gears and used group policy.

      I’ll see if I can re-create your issue.

  31. Jerre
    Posted March 18, 2013 at 12:36 pm | Permalink

    Ok, lots off good info here! Great, thank you!

    I have made a VBScript implementing the fixes mentioned in the blogpost and Dan’s comments(hope he doesen’t mind). The VBscript is intended to be run as a MSI(MST) custom action together with suns Java .msiinstaller.

    I have created the MSTfile and shared it on my skydrive so you don’t have to create it, if you like to do it yourself or improve on the .vbsscript you can find that to in the link.

    http://sdrv.ms/119b7K3

    The .MSTfile should be portable, you don’t have to edit it to use it on new Java msi installers(until Sun changes something ofcours).

    The vbsscript is included in the mstfiles Binary table, you just need the mstfile, vbsfile attached just for reference.

    Command line like for example: msiexec /i jre1.7.0_13.msi TRANSFORMS=PublicJava7Config.mst /qn REBOOT=ReallySuppress

    Now, lets hope these fixes proves to be working in the long run, so far it seems to work.

    Info how to create a MSTfile with VBScript custom action:

    http://sourceforge.net/apps/mediawiki/localupdatepubl/index.php?title=Creating_Configuration_files_during_installation.

    Hope someone finds this useful.

  32. HoobaNYC
    Posted March 18, 2013 at 4:41 pm | Permalink

    Hi guys,

    Just wanted to thank you all for your efforts and posts. Lot’s of good information. Special thanks to Jarre for making a very clean MST with a binary VBS attached to it that does all the work. Thank you thank you!
    I just modified your MST to include additional PUBLIC property called REBOOT=R (which is the same as ReallySuppress by the way :)).
    Also 3 other properties I usually change JU, JAVAUPDATE and AUTOUPDATECHECK to all be = 0, I did that as well but I’m not sure it’s needed anymore after what your script does, but I left it in anyway.

    I started testing this solution and so far so good.

    Thanks again guys and hopefully this Java garbage will either go away soon or Oracle is going to hire some competent devs that know what they are doing, and solve this once and for all.

  33. Posted March 19, 2013 at 1:45 pm | Permalink

    Just a comment about config and properties file
    if you want to prevent users from changing Java control properties you will need to place .locked on property you are changing in the properties mark
    therefore
    deployment.security.level=MEDIUM
    deployment.security.level.locked
    will effectivelly lockout/greyout the setting for the user

    • LaBareWeb
      Posted March 19, 2013 at 1:52 pm | Permalink

      Thank you, I forgot about that! Adding this to the main post.

  34. TimJ
    Posted March 20, 2013 at 2:57 pm | Permalink

    Tried installing with the config files, the users that logs on however still have Auto Update enabled.

    • LaBareWeb
      Posted March 20, 2013 at 3:16 pm | Permalink

      The auto update in the Java control panel or the “your version of Java is insecure” message?

      • TimJ
        Posted March 20, 2013 at 7:31 pm | Permalink

        The Setting in the Java Control panel under the user account is checked and greyed out.

        Is there a way for me to send you a picture?

        • LaBareWeb
          Posted March 21, 2013 at 4:21 pm | Permalink

          Sure – send me a note at bretthexum at yahoo dot com

  35. Guillaume
    Posted March 20, 2013 at 3:27 pm | Permalink

    An easy trick that worked for me on different machines : just removed the following registry key (Windows 7)

    HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties\deployment.expired.version

    Guillaume

    • LaBareWeb
      Posted March 20, 2013 at 3:47 pm | Permalink

      Did you get it to stick? I tried that but after a few minutes/sometimes hours it came back.

      • Guillaume
        Posted March 20, 2013 at 4:23 pm | Permalink

        Then try putting the value to deployment.expired.version=99.99.99

        • SurfnTurf
          Posted March 26, 2013 at 3:17 pm | Permalink

          Guillaume,

          I’ve done the same and it looks to be sticking right now. Unfortunately, you cannot place that property (deployment.expired.version) into Java until the user runs the Java applet for the first time. Otherwise the values get deleted and placed with Java’s own properties.

          I did not test to see if, once the property is in place (deployment.expired.version = 999, or whatever you get to work, this did) it would stick after Java is updated again. If it does stick at least the users would only see it one time and not each time you update Java and it becomes outdated again.

  36. TimJ
    Posted March 20, 2013 at 4:37 pm | Permalink

    Also is there a way to suppress Updates through the HKCU registry?

  37. Walkabout Tigger
    Posted April 2, 2013 at 7:11 pm | Permalink

    It looks like this fix may temporarily work for Windows XP.
    I am trying to get Java to install silently, never prompt the user for updates and just work.
    So I added the following 3 lines to my installation script
    reg.exe add “HKLM\SOFTWARE\JavaSoft\Java Update\Policy”
    reg.exe add “HKLM\Software\Javasoft\Java Update\Policy” /v EnableAutoUpdateCheck /t REG_DWORD /d 00000000
    reg.exe add “HKLM\Software\Javasoft\Java Update\Policy” /v EnableJavaUpdate /t REG_DWORD /d 00000000
    But ti sounds as if this may not be sufficient, based on the notes above.

    • LaBareWeb
      Posted April 2, 2013 at 7:14 pm | Permalink

      I’ve never gotten that method to work myself. Sounds like others have.

      I’ve always had to use the 2 baseline text files in all users app data folder – so far its been good for me here.

  38. Oh-Lee
    Posted April 5, 2013 at 11:53 am | Permalink

    Create baseline.timestamp and baseline.versions as a folder in “%Userprofile%\AppData\LocalLow\Sun\Java\Deployment\security” and you get rid of this call home popup

    • Dan
      Posted April 5, 2013 at 7:22 pm | Permalink

      Interesting solution.. Oh-Lee.

      I assume the premise is that if the folder with the same name exists, the files aren’t created and thus ignored?

      • Oh-Lee
        Posted April 12, 2013 at 6:55 am | Permalink

        yes, because of a file system limitation it is not possible to have a folder and a file with the same name.

  39. Dan
    Posted April 5, 2013 at 7:23 pm | Permalink

    Our Pilot has gone well with my deployment.properties file/clean user profile solution. Though the real test is when an update comes out…

    Good to know there are a few solutions out there.

    We are pushing this to 8k early next week…

  40. LaBareWeb
    Posted April 16, 2013 at 4:21 pm | Permalink

    New release of Java on the way. We’ll see how this fix works…. Java 7 Update 21

    http://www.oracle.com/technetwork/topics/security/javacpuapr2013-1928497.html

  41. TimJ
    Posted April 17, 2013 at 2:48 pm | Permalink

    It still prompts me for the update when someone opens a IE browser to a site using java applets.

  42. miggitz
    Posted April 18, 2013 at 2:46 pm | Permalink

    Applied the suggested configuration to 30+ users using GPO last week referencing the 7_13 version that we are running … and as of JAVA 7_21 release this week, none of those users are being prompted with insecure version message or any requests to update. Thank you to all who tested, tested and re-tested … and then shared this resolution!!!

    • LaBareWeb
      Posted April 18, 2013 at 5:06 pm | Permalink

      You’ve had beeter luck than I… I got bombarded with message. Don’t think my GPO was setup correctly though. Was set to update instead of replace.

  43. Bryan
    Posted April 18, 2013 at 8:19 pm | Permalink

    Thanks for all the info! I’m still in test mode (since we’re really behind on our Java versions) but I’m using ActiveSetup to delete the user’s deployment.properties, baseline.versions, baseline.timestamp, then make a folder called baseline.versions, baseline.timestamp (thanks Oh-Lee), and lastly delete DeploymentProperties from the registry. This seems to work fine so far. I’m testing 7u17 and I haven’t got any warnings about updating to 7u21 yet.

    The only problem I have at this point is I don’t want to be warned about running unsigned applications. The only thing that’s worked so far is in the system deployment.properties file using the line: deployment.security.level=LOW
    I don’t like this solution though because if affects some of the behind-the-scenes function (such as how applet resources are handled). Also, 7u21 doesn’t allow you to set the security level to low. So does anyone have any other recommendations on how to disable the security warning of unsigned applications?

  44. Rob
    Posted April 19, 2013 at 12:21 am | Permalink

    ACK! Bombarded with calls today!
    Found out that if the user clicks Update, then any future java applet launches will automatically take them to the Java update site without prompting! Yikes!
    Delete user-side registry key: hkcu\Software\JavaSoft\DeploymentProperties\deployement.expiration.decision.version to get out of the loop.

    I’m implementing Oh-Lee’s solution – looking for and deleting those files and creating folders!
    Seems to be working a champ with updates 13-21

  45. miggitz
    Posted April 19, 2013 at 2:25 pm | Permalink

    LaBareWeb ~ verified that my GPO action was set to “replace”. Our test group has not had any interruptions with JAVA “insecure version” messages … which we did prior to the deployment of the suggested GPO.

  46. Dan
    Posted April 19, 2013 at 3:07 pm | Permalink

    just confirming, suggestion is to delete the baseline.timestamp and baseline.versions files and then create two empty files named baseline.timestamp and baseline.versions ?

    • LaBareWeb
      Posted April 19, 2013 at 8:05 pm | Permalink

      The baseline.timestamp has just a period . in it

      The baseline.versions has the different versions of Java with the special character in between. The easiest way to create that is to do a new install and let Java create it itself after using Java for a few loads. Then just take that file and edit it – change the _21 to a 13, or 17, whatever you deploy.

  47. Bryan
    Posted April 19, 2013 at 8:47 pm | Permalink

    I found this very useful. Go into the Java control panel (just run javacpl.cpl), go to the Advanced tab, Java Console, and choose “Show Console”, then Apply and OK. Next go to http://www.javatester.org/version.html and run the applet. The Java console will open. Click anywhere on the console and press [S] to “dump system and deployment properties”. This will fill the console up with properties and their values. One of them I just found is:
    deployment.baseline.url = https://javadl-esd-secure.oracle.com/update/baseline.version
    This is the actual URL Java calls out to get the the baseline file. I’m going to look at this output some more but we could trying putting in the system-level deployment.properties file:
    deployment.baseline.url=http://fakeurl.org
    This could cause Java to use an invalid URL and therefore prevent it from being able to pull the baseline data in the first place. I’ll give you guys an update after I can work though some of this data.

    • LaBareWeb
      Posted April 19, 2013 at 8:54 pm | Permalink

      Very interesting! I used Wireshark to find the same URL also. I am just worried about the following comment I saw on an Oracle forum.

      Don’t rely on blocking the update server(s) to prevent the pop-up from eventually showing. I’ve been told that the JRE has an embedded expiration date that it uses if it never is able to contact the update servers. Once that date passes, it may trigger the pop-up to be displayed. So, you may think you have successfully blocked it during testing and after deploying for a few weeks have all your users suddenly get the pop-up. Not good. Again, we need Oracle to either provide a supported workaround or include a configuration option in a future release that will prevent this from being displayed for their enterprise customers. For now, I’d be happy with just hearing from them that they recognize this is a major issue for enteprises and that they are going to provide a fix.

      • Bryan
        Posted April 19, 2013 at 10:01 pm | Permalink

        That’s good to know. At this point the best solution seems to be Oh-Lee’s solution. Although it sounds like even this solution won’t help once java hits the hard-coded date.

        FYI, you can modify any properties (such as deployment.baseline.url) by adding it to the deployment.properties file. You can also make up properties such as deployment.security.fakeproperty123=true and place it in the d.p file and it will show up in the console. This is good to know because if you place a retired property from an earlier version of java (such as deployment.java.update.check from 7u9) it will show up in the console. This could cause you to think that Java is actively using the property when in reality it’s ignoring it.

        Btw, has anybody figured out how to disable the security warnings for unsigned applications in 7u21? I need to turn this off before I can’t push the update to our enterprise until I can turn off the warning.

        • André
          Posted April 24, 2013 at 9:04 am | Permalink

          I also would like to know how to disable the security warnings for unsigned application in 7u21.

          What I found out is that you can ignore all registry settings, because they do not have really a function. It is more for “information”. All settings are integrated in the client e.g. deployment.properties. It will write it to registry, but will always be overwrited from the file(s)

    • André
      Posted April 25, 2013 at 7:34 am | Permalink

      What is with this: you redirect the update link to an intern address where the file baseline.version will never be updated. So you can e.g. install Java 7 Update 21 and the baseline.version says “1.7.0_21″. So Java gets always the current version 7u21 and will never update and expire?

    • Jay
      Posted April 26, 2013 at 3:22 pm | Permalink

      Whenever I have issues like that and the manufacturer is not willing to help, I resort to some reverse engineering :)

      Deep within DEPLOY.JAR, we find BuiltInProperties.class which apparently contains the following expiration date for Java 17 Update 17: 05/16/2013. So what LaBareWeb states appears to be true. I see no way of disabling that built-in expiration date.

      The bit about redirecting deployment.baseline.url should function, based on the source code.

      • LaBareWeb
        Posted April 26, 2013 at 3:25 pm | Permalink

        I’ve wondered about digging into that but don’t have the skillset. Good work!

  48. Peter
    Posted April 19, 2013 at 8:55 pm | Permalink

    Why not creating folders named “baseline.versions” and “baseline.timestamp”? This should suppress the recreation of the files.

    • TimJ
      Posted April 23, 2013 at 4:04 pm | Permalink

      Creating folders for those 2 files in a GPO does not work for all users.

      • Peter
        Posted April 24, 2013 at 9:06 am | Permalink

        Does it fail, if those files already exist? Folder creation will fail, if the files are still there.

  49. Georgy
    Posted April 22, 2013 at 9:01 pm | Permalink

    We were able to get rid of this “insecure” warning popup by un-checking “Enable Next generation plug-in” checkbox in Advanced tab of Java Control Panel.
    Anyone knows how this could be related ?
    What “Enable next generation plug-in” actually means ?

    Thanks in advance

    • Peter
      Posted April 24, 2013 at 9:44 am | Permalink

      Disabling the NG plugin shows either no popup :-) nor the java applet in the internet explorer :-( (checked on java.com)

  50. André
    Posted April 24, 2013 at 10:14 am | Permalink

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Plug-in\10.21.2]
    “UseNewJavaPlugin”=dword:00000000

  51. Jools
    Posted April 24, 2013 at 3:31 pm | Permalink

    Hey guys,

    Just to let you know I share your pain.

    If a user accidentlly clicks on “UPDATE”, we are then using the manual fix of setting “Do Not Prompt” under a CUSTOM Security Level – which then seems to let them access the page.

    The one thing with diagnosing this issue is it seems to be inconsistent to replicate the “UPDATE / BLOCK / RUN” prompt. Does anyone know how to get this prompt back up.

    If I reset all IE settings and delete temp java files, then I get the standard “UN / Update / Cancel prompt”which is not too annoying and doesnt get you in the UPDATE bug (even if u click update).

    • Bryan
      Posted April 25, 2013 at 1:38 pm | Permalink

      When a user clicks on one of the pop-ups, the data is saved in one of two places. Most of the time it’s:
      (XP) C:\Documents and Settings\JohnDoe\Local Settings\Application Data\Sun\Java\Deployment\cache\*

      The subfolders are for remembering site-specific information. If that doesn’t do it then go to:
      (XP) C:\Documents and Settings\JohnDoe\Application Data\Sun\Java\Deployment\
      and delete (or edit using notepad) a file called “deployment.properties”. This file has a lot of user-specific settings.

  52. Jools
    Posted April 24, 2013 at 3:34 pm | Permalink

    I am also a bit annoyed that Oracle are LOCKING any threads which are getting created on their FORUMS regarding this issue.

    • Bryan
      Posted April 24, 2013 at 4:24 pm | Permalink

      I’ve experienced the same thing. I’ve created a handful of threads. The next day I’ll go check on them and the thread won’t exist anymore. Craziest thing ever.

      • LaBareWeb
        Posted April 24, 2013 at 7:48 pm | Permalink

        Same thing happened to me! That’s why I gave up with Oracle and tried to figure it out on my own.

  53. Jools
    Posted April 26, 2013 at 9:26 am | Permalink

    So, I had a CUSTOM Security level which PROMPTED for untrusted and local, but “run without prompt (not recommended) set” for expired or insecure.

    I then browsed to Javatester.org, got the Java Updated needed -> UPDATE ¦ BLOCK ¦ LATER message

    SNAPSHOT machine – then click on LATER and selected the DO NOT ASK AGAIN checkbox.

    These are the bits it added to my APPDATA Deployment.Properties file:

    deployment.expiration.decision.10.17.2=later
    deployment.expiration.decision=LATER
    deployment.security.run.expired=ALWAYS
    deployment.expiration.decision.timestamp.10.17.2=4/25/2013 15\:40\:7
    deployment.security.mixcode=DISABLE
    deployment.expiration.decision.suppression.10.17.2=true

    It created an encrypted thing in cache also.

  54. Dmitry
    Posted April 26, 2013 at 1:08 pm | Permalink

    seems java process checks for updated version and inturn updates file baseline.versions. what if i was to remove ACL rights (leave maybe just local admin there). Java process should fail to update the file, but the function that checks if communication with java update server was a success should return retun true. This process may not call the logic that calls for update pop-up.msg

    I also found that 2nd prompt where you have option to suppress further msgs to RUN app, creates a file in the cache folder structure. File has extension LAP. File for a specific JAVA code always creates same LAP file name and is always places in same numbered subfolder. If you copy that LAP to another user’s cache folder\subfolder#, user will not get that prompt.

    Any thoughts?

  55. linuxbox
    Posted April 26, 2013 at 3:01 pm | Permalink

    Any workaround for firefox. I used the “UseNewJavaPlugin” hack there and it fixes the issue with IE but Firefox still prompts me.

    • LaBareWeb
      Posted April 26, 2013 at 3:16 pm | Permalink

      Have not tried with Firefox at all myself.

  56. Joe
    Posted May 2, 2013 at 9:01 pm | Permalink

    So I wonder if all of these great suggestions will be for nothing on 5/16/13 as suggested. Found this post referencing the variable where this is set: http://stackoverflow.com/questions/16067829/jre-expiration-date

    My guess is 5/17 we all take calls again. Great news, 7.21 has 7/26/13 hardcoded as the expire date as well.

    I think if you have a site that doesn’t need the NewJavaPlugin to function that is still the best option to get past this issue. Running this as an elevated user appears to work: ssvagent.exe -high -jpisetup -old

    Change it to -new to turn it back on.

    • LaBareWeb
      Posted May 2, 2013 at 9:16 pm | Permalink

      Does the ssvagent.exe -high -jpisetup -old command seem to disable the “do you want to run this application” message? If so, doesn’t seem to be working for me. Of course my test box is so dirty who know’s what’s going on :)

      • Joe
        Posted May 3, 2013 at 3:31 pm | Permalink

        Yes when I run that and it unchecks the NewJavaPlugin I can go to javatester.org and don’t get prompted at all. That’s with security set to high. The downside is java.com no longer works, looking at the console, “javadetection.class not found” is the error. However, if your app doesn’t need it this might be an easy fix for someone.

        Thanks again for this blog, without it we’d all be clueless and frustrated, now we’re informed and frustrated.

        • LaBareWeb
          Posted May 3, 2013 at 3:51 pm | Permalink

          You’re right. That worked for me. The page I am testing with is an internal page with bad code (no cert) so I am getting the insecure app message. Not the same message.

          clueless and frustrated, now we’re informed and frustrated.

          Love it! Now if we can just get Oracle to stop closing/deleting our threads on their forums….

    • Posted May 16, 2013 at 4:15 pm | Permalink

      Like you said… it happened…. taking thousands of calls……no way to suppress the stupid thing…. cant change next gen plugin setting, because that breaks certain java apps.

      anything find a neat way?

  57. TimJ
    Posted May 6, 2013 at 12:57 pm | Permalink

    A few users called this am about getting the Your version of Java is insecure. This is frustrating for sure!

  58. Joe
    Posted May 7, 2013 at 3:52 pm | Permalink

    Got some bad news. If you start messing with your system date and set it to 5/16/13, even if you use the suggestions here of baseline.versions folder instead of files, you’ll get prompted. This all appears to be due to the JRE_EXPIRATION_DATE value that is hard coded to that date in 7.17. I tested it with 7.21 which has the variable set to 7/18/13 and it starts prompting you on 7/18 as expected (I mispoke in my post above 7/18 is correct). So I don’t know of any way to beat this.

    I’m using this to push anyone with a JRE related app to demand from the vendor to move away from it. What a joke. 3 billion devices and counting … we’ll see about that Oracle.

  59. Jay
    Posted May 7, 2013 at 5:33 pm | Permalink

    Worst case, we could decompile BuiltInProperties.class, edit out all the non-enterprise friendly code, then re-compile and package back into deploy.jar. I don’t see a digital signature anywhere, but this type of “process” is probably considered illegal reverse-engineering.

    But the only way to fix a hard-coded anything is to decompile, edit out, recompile, especially if the manufacturer chooses not to provide a variable that can be flipped :(

    Our company had to revert back to Java 6 Update 45 for now…

  60. Joe
    Posted May 7, 2013 at 6:54 pm | Permalink

    Jay that’s a great idea going back to 6.45. What are we 2 extra JRE 6 updates past what Oracle said was EOL for 6? Who wants to bet a 6.47 and 6.49 will come out as well this summer.

  61. Cody
    Posted May 9, 2013 at 7:37 pm | Permalink

    Has anyone considered moving to the Windows IBM 1.7 JRE? The Nags are not an issue

    • LaBareWeb
      Posted May 9, 2013 at 7:43 pm | Permalink

      Never even knew there was such a thing….

      • Jools
        Posted May 13, 2013 at 8:45 am | Permalink

        Yeah I checked it out, a direct download of he IBM JRE is not available due to licensing issues yada yada.

  62. Posted May 16, 2013 at 5:28 pm | Permalink

    Looks like this hit us today! We block all internet access except for business related sites, so Java hasn’t been able to phone home until now.

    Can anyone confirm if this work around also stops the expiration date, or are we forced into testing/releasing Java updates monthly like we do Windows Updates.

  63. LaBareWeb
    Posted May 16, 2013 at 5:42 pm | Permalink

    Blew us up too. The workarounds work somewhat… but still its a bandaid. They’ve definitely changed something since going from 13 to 17. F*k’n Oracle…. seriously.

    We’ve bit the bullet and will accelerate the update to 21. Unreal. It’s going to turn into MS patches for us too… need a full time position for this.

  64. Joe
    Posted May 16, 2013 at 7:38 pm | Permalink

    Today was the lucky day for the new Expiration Date 5/16/13 that is hard coded into 7.17. You can update to 7.21 but you will get the same prompts on 7/18/13. That said with the tighter security in 7.21 I’d advise anyone looking at that route to set your date past 7/18 and then try your sites that need Java and see if they work. I’ve found you need to lower your security to Medium for most sites to work.

    If anyone found an easy way to do this on 7.21 please post. I found the system wide deployment.properties does not work, and the installer command line for Medium does not work as well. The only way I can do it somewhat reliably is to remove the user deployment.properties for the user and then copy down a new one with this set.

    LaBareWeb – again thanks for the site, but do you think you can put a note at the top saying, there really is no good work around now with the Expiration Date? That would save a lot of people time reading through all the posts.

    • LaBareWeb
      Posted May 16, 2013 at 8:02 pm | Permalink

      done. was in the process of doing that right as you reminded me

  65. Morgan Bunce
    Posted May 17, 2013 at 9:15 pm | Permalink

    I created the following until Oracle gets there act together. It’s an AutoIT script that looks for the update window and then selects the ideal combination for the user. You can deploy it in the startup folder for users and there is very little CPU impact. Feel free to use and modify as you like.

    http://www.autoit.com

    opt(“TrayIconHide”,1)

    Global $Title =”Java Update Needed”

    ;loop forever
    while 1=1
    ;Has the update window popped up? Yes?
    if WinExists ($Title, “”) Then
    ;Take action
    CheckBox()
    EndIf
    ;Give the CPU a small break =)
    Sleep (200)
    WEnd

    Func CheckBox()
    ;Activate update window
    WinActivate ($Title)

    ;Is the do not prompt me checkbox selected? No?
    if ControlCommand ($Title,””,10001, “IsChecked”) = 0 Then
    ;Select checkbox
    ControlClick ($Title,””,10001,”left”)
    ;Click on later
    ControlClick (“Java Update Needed”,””,2,”left”)
    EndIf
    EndFunc

    • LaBareWeb
      Posted May 17, 2013 at 9:21 pm | Permalink

      Very nice. THANK YOU! Adding to main article

    • KnifMelti
      Posted May 19, 2013 at 6:11 pm | Permalink

      And, if a user already is in the update loop (http://www.autohotkey.com/) an .ahk script:

      RegDelete, HKCU, Software\AppDataLow\Software\JavaSoft\DeploymentProperties
      EnvGet, LocalAppData, LocalAppData
      FileDelete, %LocalAppData%Low\Sun\Java\Deployment\deployment.properties
      MsgBox, 64,Reset Java Settings, Oracle JRE settings are now reset., 4

      • KnifMelti
        Posted May 19, 2013 at 6:28 pm | Permalink

        Combined with Morgan workaround (deploy it in the startup folder) as .ahk (http://www.autohotkey.com):

        #NoTrayIcon

        RegDelete, HKCU, Software\AppDataLow\Software\JavaSoft\DeploymentProperties
        EnvGet, LocalAppData, LocalAppData
        FileDelete, %LocalAppData%Low\Sun\Java\Deployment\deployment.properties

        while 1=1
        {
        IfWinExist, Java Update Needed
        DelayJava()
        Sleep, 200
        }

        DelayJava()
        {
        IfWinNotActive, Java Update Needed, , WinActivate, Java Update Needed,
        WinWaitActive, Java Update Needed,
        Sleep, 100
        Send, {DOWN}{DOWN}{DOWN}{SPACE}{UP}{ENTER}
        return
        }

    • Will
      Posted May 20, 2013 at 10:45 am | Permalink

      I pasted your autoit script code into Autoit. But I seem to get this error

      Line 21 (File “c:\Users\wreid\Desktop\Disable Java Update request.au3″):
      if ControlCommand ($Title,””,10001, “IsChecked”) = 0 then

      Error: Unterterminated string.

      I only pasted this so nothing was changed from what you put on here

      • LaBareWeb
        Posted May 20, 2013 at 1:32 pm | Permalink

        I see something got messed up with a copy/paste. The quotes are messed up. I’ll upload a txt file

  66. Posted May 21, 2013 at 7:20 am | Permalink

    Over here we have used the following solution:
    – Created a custom copy of the deployment.properties file that also contains the lines:
    — “deployment.expiration.decision.10.17.2=later”
    — “deployment.expiration.decision.timestamp.10.17.2=5/17/2013 8\:53\:3″
    — “deployment.expiration.decision.suppression.10.17.2=true”
    – Created a vbscript that copies the deployment.properties file to the LocalLow profile.
    – Let the vbscript start “Java\jre7\bin\javacpl.exe”
    – Let the vbscript kill “javaw.exe” once the Control Panel Applet started

    Deployed this solution using Active Setup

  67. Mark
    Posted May 21, 2013 at 1:47 pm | Permalink

    Guys – the only issue im having is with the security level :/ i have a GPO doing a replacement on the deployment.properties file and all other settings are fine but the

    deployment.security.level=MEDIUM

    is in the file but as soon as the end user goes to the java control panel to confirm it has gone to medium it changing this to HIGH – anything im missing here?

  68. Joe
    Posted May 21, 2013 at 2:34 pm | Permalink

    @Mark, which file are you replacing Mark, is is the one in Windows or the User Profile version of that file? I found the same thing that it seems like Oracle used some trickery to force a High setting and all Medium setting are ignored if you try to do it programatically.

    If you experiment it seems like if you set security to High that it leaves that property set in the file. Yet if you set it manually to Medium it removes that entry from the DP file and leaves that setting blank. I don’t get it at all. Maybe we need a nice AutoIT script to set the security to Medium after installing 7.21.

  69. Posted May 22, 2013 at 2:46 pm | Permalink

    http://www.syswow64.co.uk/2013/05/java-7-update-21-1721-enterprise.html

    This Link details the process to set security to medium.

    • Joe
      Posted May 22, 2013 at 6:46 pm | Permalink

      That seems to do the trick Syswow64 thanks for posting! Time to vbscript that up and start testing. I think we’ve decided to wait until mid June since logic would assume that’s when 7.23 or whatever version will get released and it’d be nice to see if Oracle is making any changes yet again.

  70. tretex
    Posted May 29, 2013 at 7:36 am | Permalink

    No news?

    • Bryan
      Posted May 31, 2013 at 1:43 pm | Permalink

      This is worth reading: https://blogs.oracle.com/security/entry/maintaining_the_security_worthiness_of

      It’s by Nandini Ramani, who leads the software development team for building Java. The second to last paragraph specifically talks about supporting enterprise policies in a future release. I hope the do it in the next release.

      “In addition, Oracle wants to improve the manageability of Java in enterprise deployments. Local Security Policy features will soon be added to Java and system administrators will gain additional control over security policy settings during Java installation and deployment of Java in their organization. The policy feature will, for example, allow system administrators to restrict execution of Java applets to those found on specific hosts (e.g., corporate server assets, partners, etc) and thus reduce the risk of malware infection resulting from desktops accessing unauthorized and malicious hosts.”

      It doesn’t fix their broken software today, but it does give me hope that they see our needs and will (hopefully) give us working tools so that we can get back to work.

      • Jay
        Posted May 31, 2013 at 4:56 pm | Permalink

        Glad to hear they are doing something to make Java more manageable in the enterprise.

  71. Greg Zielinski
    Posted June 3, 2013 at 4:08 pm | Permalink

    Just curious on anyone’s findings regarding the URL check at https://javadl-esd-secure.oracle.com/update/baseline.version.

    For those that have tried blocking it by changing the deployment.baseline.url with the deployment.properties file. Has this worked and more importantly, has the setting remained or have you seen cases of it being overwritten.

    I understand that there is a built in expiration. As it stands we plan on running a script to populate the necessary areas to “pre-answer” the popup. What has me concerned is the checkbox “do not show until next update”. I’m hoping if we dead end the deployment.baseline.url, then answering the prompt generated by the internal 5/16/2013 expiration of Update 17 will be all we need.

    What we don’t want is to have the Oracle baseline URL get checked and trigger the prompt as essentially, a “new” update is found.

    I’d feel even better if I could emulate their baseline website and confirm this works by mimicking a new baseline url of say, 7_23.

  72. Posted June 5, 2013 at 7:59 am | Permalink

    Kinda amazed that their still isn’t a clear fix for this issue,
    I’m trying to fix this issue in a Citrix environment with Xenapp 6, i’ve tried alot of different solutions.

    my GPO deletes the local deployment.properties and creates the windows\sun\java\deployment folder.
    then copies my own deployment.properties and .config over there.
    It also deletes the baseline.version and .time and creates them as a folder instead, but it doesn’t seem to work.

    deployment.properties
    “deployment.security.level=MEDIUM
    deployment.browser.path=C:\Program Files\Internet Explorer\IEXPLORE.EXE
    deployment.version=7.15
    deployment.security.level.locked
    deployment.insecure.jres=ALWAYS
    deployment.javaws.autodownload=NEVER
    deployment.security.run.expired=ALWAYS”

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

    This Reg key made the message not show, but only on first attempt, second time i open the page, the Java is insecure shows again…
    [HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties]
    “deployment.security.level”=”MEDIUM”
    “deployment.insecure.jres”=”ALWAYS”
    “deployment.security.run.expired”=”ALWAYS”
    “deployment.javaws.autodownload”=”NEVER”
    “deployment.expiration.decision.suppression.10.15.2″=”true”
    “deployment.version”=”7.0″
    “deployment.expiration.decision.10.15.2″=”later”
    “deployment.browser.path”=”C:Program FilesInternet ExplorerIEXPLORE.EXE”
    “deployment.modified.timestamp”=”1370413489624″
    “deployment.expired.version”=”10.15.2″
    “deployment.expiration.decision.timestamp.10.15.2″=”6/5/2013 8:24:46″

    Anyone got any ideas?

  73. Posted June 10, 2013 at 9:32 am | Permalink

    Seems i found the answer after i got a contact with an oracle employee that works with this stuff.

    since you need MOS access (My Oracle Support) i just post out everything here:

    Handling the New JRE Security Dialogs [ID 1553875.1]

    In this Document
    Purpose
    Scope
    Details
    Messages for running sandbox applications
    Message to prevent launching a JRE that has fallen below the security baseline

    Applies to:
    Java SE JDK and JRE – Version 7 to 7 [Release 7]
    Information in this document applies to any platform.

    Purpose

    Starting with the release of Java SE 7 update 10, Oracle added new security dialogs to the Java Runtime Environment (JRE). These new dialogs are displayed only when accessing the JRE through a web browser; either as Java applets or as Java Web Start applications launched through the browser. They are not shown when launching applications through the command line, for applications that embed the JRE, or when launching Java Web Start applications that the user has cached in their system.

    If a user has only JRE versions below 7 update 10 these warnings will not be shown.

    The new dialogs can be grouped into two categories:

    Messages for running sandbox applications

    Message to prevent launching a JRE that has fallen below the security baseline

    Scope

    Java developers and Java users of Java applets and Java Web Start applications.
    Details
    Messages for running sandbox applications

    Previously, sandbox applications, applications which do not request elevated permission, launched without user confirmation. Users now have to authorize running any application, even sandbox ones.

    Oracle used to recommend not signing sandbox applications. The new recommendation is to sign all applications with a valid code-signing certificate.

    To minimize the impact of these new dialogs for running sandbox applications, enterprises should sign all existing sandbox applications and when running them for the first time check the option in the new dialogs that says “Do not show this again for apps from the publisher and location above”.

    Message to prevent launching a JRE that has fallen below the security baseline

    Before running any content through web browsers, the system now checks if the JRE is below the security baseline or if the JRE has passed its expiration date.

    If either condition is true, a message prompts the user to update Java. The end user has the choice to update Java, block the content from running in the browser, or continue launching the application with the current version of the JRE (not recommended). Additional warnings may be suppressed until a new release of the Java is available by selecting the “Do not ask again until the next update is available” check box and selecting “Later”.

    An interim patch for the JRE, built on 7 update 21 with auto-update off, which doesn’t have the “insecure JRE” warnings is available. See Patch 16758419. It is recommended that only enterprises with other mechanisms for keeping the JRE up-to-date use this build.

  74. Posted June 10, 2013 at 10:41 am | Permalink

    Oracle released an interim patch, 16758419, for JRE and JDK 1.7.0_21 (32bit only) with Auto-update Off and Insecure Java Version Message suppressed:

    README for 16758419

    Patch Details

    Bug Number: 16758419

    Product Name: Oracle JDK and JRE 1.7.0_21-fcs-b14
    with Auto-update Off and Insecure Java Version Message suppressed
    – Interim Patch

    Platform: Windows-i586
    […]

    • LaBareWeb
      Posted June 10, 2013 at 2:59 pm | Permalink

      Do you have a link? I am on remote on an iPhone and can’t seem to find it anywhere

      • Christian
        Posted June 10, 2013 at 3:58 pm | Permalink

        Unfortunately, you need a login on My Oracle Support (MSO). As I don’t have a login I cannot provide you a deep link to this particular patch.

        If you have a login, you can sign-in on http://support.oracle.com, click “Patches and Updates”, then search for patch ID 16758419.

        BTW: I have applied this interim patch on my PC today and changed the system date to August 10 (which is beyond the expiration date for the official public JRE 1.7.0_21). The infamous update popup did not occur, so the patch seems to work.

        • DG
          Posted June 10, 2013 at 8:22 pm | Permalink

          I suggest that you may want read the fine print on this, my interpretation, in order to take advantage, you need to have a JAVA support agreement with Oracle, or you can only use for EBUS applications. It may have been me, but I also found the performance to have slowed with the patch, leading me to hold out for a later release.

          • Christian
            Posted June 11, 2013 at 8:06 am | Permalink

            Thanks for putting the focus on potential performance degration! I will keep an eye on this. However, Oracle support refered me to this interim patch when we escalated our many problems with clients running Oracle JRE 1.7.0_11 or later having difficulties to access Oracle EBS/Peoplesoft and such.

        • Robert
          Posted June 19, 2013 at 8:21 pm | Permalink

          So I signed up for a My Oracle Support ID today, but it gets me nowhere. Who do I contact or what do I have to pay to get access to this patch? The web page is useless.

          • LaBareWeb
            Posted June 19, 2013 at 8:59 pm | Permalink

            Same here. Unreal! Waiting to hear from our Oracle licensing person. I need a customer ID to continue. &*(&$*&*#@

  75. André
    Posted June 12, 2013 at 12:56 pm | Permalink

    Is there no way to get this patch without registration???

  76. Dennis Lundberg
    Posted June 19, 2013 at 12:24 pm | Permalink

    Java 7 Update 25 is out now. Does anyone know if it includes the fix in the interim patch? I can’t seem to find anything about it in the release notes:
    http://www.oracle.com/technetwork/java/javase/7u25-relnotes-1955741.html

    • Bryan
      Posted June 19, 2013 at 1:35 pm | Permalink

      I’m not sure yet. I just saw the update so I’m downloading it and testing will begin shortly. I’ll post my findings as soon as the results are in.

    • LaBareWeb
      Posted June 19, 2013 at 4:23 pm | Permalink

      Would be nice to see if there was a patch available with Update 25. No sense for us to apply patch when update 25 will need to be pushed eventually also….

  77. Bryan
    Posted June 19, 2013 at 2:24 pm | Permalink

    FYI, here’s the list of default deployment properties for Java 7 update 25. You “should” be able to add any of these properties into the d.p file. I got this info by going to Java in the console panel and choosing “show console”. Then run a java applet and when the console opens, press [s].

    —————————————————-
    Dump deployment properties …
    —————————————————-
    active.deployment.proxy.bypass.local = false
    active.deployment.proxy.same = false
    active.deployment.proxy.type = 3
    deployment.baseline.url = https://javadl-esd-secure.oracle.com/update/baseline.version
    deployment.blacklist.url = https://javadl-esd-secure.oracle.com/update/blacklist
    deployment.blacklisted.certs.url = https://javadl-esd-secure.oracle.com/update/blacklisted.certs
    deployment.browser.path = C:\Program Files\Internet Explorer\IEXPLORE.EXE
    deployment.browser.vm.iexplorer = true
    deployment.browser.vm.mozilla = true
    deployment.cache.enabled = true
    deployment.cache.jarcompression = 0
    deployment.cache.max.size = -1
    deployment.capture.mime.types = false
    deployment.console.startup.mode = SHOW
    deployment.control.panel.log = false
    deployment.insecure.jres = PROMPT
    deployment.javafx.mode.enabled = true
    deployment.javapi.cache.update = false
    deployment.javapi.lifecycle.exception = false
    deployment.javapi.log.filename =
    deployment.javapi.runtime.type = 0
    deployment.javapi.stop.timeout = 200
    deployment.javapi.trace.filename =
    deployment.javaws.associations = ASK_USER
    deployment.javaws.cache.update = false
    deployment.javaws.concurrentDownloads = 4
    deployment.javaws.install = IF_HINT
    deployment.javaws.installURL = http://java.sun.com/products/autodl/j2se
    deployment.javaws.logFileName =
    deployment.javaws.muffin.max = 256
    deployment.javaws.shortcut = ASK_IF_HINTED
    deployment.javaws.traceFileName =
    deployment.javaws.uninstall.shortcut = false
    deployment.javaws.update.timeout = 1500
    deployment.jpi.mode.new = true
    deployment.log = false
    deployment.macosx.check.update = true
    deployment.max.output.file.size = 10
    deployment.max.output.files = 5
    deployment.mime.types.use.default = true
    deployment.modified.timestamp = 1371651601957
    deployment.proxy.bypass.local = false
    deployment.proxy.override.hosts =
    deployment.proxy.same = false
    deployment.proxy.type = 3
    deployment.security.SSLv2Hello = false
    deployment.security.SSLv3 = true
    deployment.security.TLSv1 = true
    deployment.security.TLSv1.1 = false
    deployment.security.TLSv1.2 = false
    deployment.security.askgrantdialog.notinca = true
    deployment.security.askgrantdialog.show = true
    deployment.security.authenticator = true
    deployment.security.blacklist.check = true
    deployment.security.browser.keystore.use = true
    deployment.security.clientauth.keystore.auto = true
    deployment.security.disable = false
    deployment.security.https.warning.show = false
    deployment.security.jsse.hostmismatch.warning = true
    deployment.security.level = HIGH
    deployment.security.local.applets = PROMPT
    deployment.security.mixcode = ENABLE
    deployment.security.notinca.warning = true
    deployment.security.password.cache = true
    deployment.security.revocation.check = ALL_CERTIFICATES
    deployment.security.run.untrusted = PROMPT
    deployment.security.sandbox.awtwarningwindow = true
    deployment.security.sandbox.casigned = PROMPT
    deployment.security.sandbox.jnlp.enhanced = true
    deployment.security.sandbox.selfsigned = PROMPT
    deployment.security.trusted.policy =
    deployment.security.validation.crl = true
    deployment.security.validation.ocsp = true
    deployment.security.validation.ocsp.publisher = false
    deployment.system.cachedir = C:\Documents and Settings\admin\Local Settings\Application Data\Sun\Java\Deployment\SystemCache
    deployment.system.security.blacklist = C:\Program Files\Java\jre7\lib\security\blacklist
    deployment.system.security.cacerts = C:\Program Files\Java\jre7\lib\security\cacerts
    deployment.system.security.jssecacerts = C:\Program Files\Java\jre7\lib\security\jssecacerts
    deployment.system.security.oldcacerts = C:\Program Files\Java\jre7\lib\security\cacerts
    deployment.system.security.oldjssecacerts = C:\Program Files\Java\jre7\lib\security\jssecacerts
    deployment.system.security.trusted.certs = C:\Program Files\Java\jre7\lib\security\trusted.certs
    deployment.system.security.trusted.clientauthcerts = C:\Program Files\Java\jre7\lib\security\trusted.clientcerts
    deployment.system.security.trusted.jssecerts = C:\Program Files\Java\jre7\lib\security\trusted.jssecerts
    deployment.system.security.trusted.libraries = C:\Program Files\Java\jre7\lib\security\trusted.libraries
    deployment.system.tray.icon = false
    deployment.trace = false
    deployment.update.mime.types = true
    deployment.user.cachedir = C:\Documents and Settings\admin\Local Settings\Application Data\Sun\Java\Deployment\cache
    deployment.user.extdir = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\ext
    deployment.user.logdir = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\log
    deployment.user.security.blacklist = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\blacklist
    deployment.user.security.blacklist.dynamic = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\blacklist.dynamic
    deployment.user.security.blacklisted.certs = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\blacklisted.certs
    deployment.user.security.policy = file:/C:/Documents%20and%20Settings/admin/Application%20Data/Sun/Java/Deployment/security/java.policy
    deployment.user.security.sandbox.certs = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\sandbox.certs
    deployment.user.security.saved.credentials = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\auth.dat
    deployment.user.security.trusted.cacerts = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\trusted.cacerts
    deployment.user.security.trusted.certs = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\trusted.certs
    deployment.user.security.trusted.clientauthcerts = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\trusted.clientcerts
    deployment.user.security.trusted.jssecacerts = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\trusted.jssecacerts
    deployment.user.security.trusted.jssecerts = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\trusted.jssecerts
    deployment.user.security.trusted.libraries = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\security\trusted.libraries
    deployment.user.tmp = C:\Documents and Settings\admin\Application Data\Sun\Java\Deployment\tmp
    deployment.version = 7.21
    deployment.webjava.enabled = true
    java.quick.starter = true
    —————————————————-

  78. LaBareWeb
    Posted June 19, 2013 at 9:55 pm | Permalink

    Recvd this from a support ticket we created. No patch for 25.

    I am the Java engineer working on your issue. You asked about another interim patch to suppress the “Insecure Java Version” message for Java 7 Update 25?

    There was an interim patch for Java 7 Update 21 that suppressed the Insecure Java Version Message. Oracle provided this Interim Patch of 7u21 with the Insecure Java Version message disabled for customers to evaluate. Java 7 update 25 does not suppress the message. Please see the MOS Doc, Handling the New JRE Security Dialogs [ID 1553875.1].

    Your choices are to continue to use the previous patch or wait for the Java update, expected later this year that suppresses the message.

    • Bryan
      Posted June 20, 2013 at 12:53 pm | Permalink

      Thank you for the info! I won’t burn a lot of time trying to find a built-in workaround then. On 7u25 release notes (http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html) The gave the following info:

      “The next scheduled dates for Oracle Java SE Critical Patch Updates are: 15 October 2013, 14 January 2014, 15 April 2014, 15 July 2014.”

      So the patch to suppress this warning won’t be out until 10/15/2013. I’ve considered rolling back to v6 but since this is a retired product there’s no equivalent patch for 7u25. Hopefully the new patch in Oct. allows you to whitelist websites so that you don’t even have to lower the security settings for all sites. It’s just disappointing (all though not surprising) that Oracle has let us down again.

      So what work-arounds is everyone using now days? Any new ideas?

    • Bryan
      Posted June 20, 2013 at 12:56 pm | Permalink

      Forgot to ask but LaBareWeb, how did you go about creating a support ticket? I’d like to create one to see if I can get more documentation on the d.p security properties. For example you can go to http://docs.oracle.com/javase/6/docs/technotes/guides/deployment/deployment-guide/properties.html and http://download.java.net/jdk8/docs/technotes/guides/deployment/deployment-guide/properties.html to read about “deployment.insecure.jres” but other properties such as “deployment.security.disable” has no documentation on it.

      • LaBareWeb
        Posted June 21, 2013 at 2:31 pm | Permalink

        I didn’t do it specifically since I don’t have a business account. One of our licensing guys did it for me.

  79. AAnomoly
    Posted June 20, 2013 at 3:46 am | Permalink

    Does anybody know how to launch Javacpl.exe silently? I can’t seem to find any switches to facilitate this.

  80. Posted June 21, 2013 at 10:59 am | Permalink

    Will someone be able to supply Patch 16758419? Oracle is very unhelpful unless we buy a service contract with them and we have no intention of doing so just for this patch.

    Help would be much appreciated!

    • LaBareWeb
      Posted June 21, 2013 at 2:33 pm | Permalink

      I thought about posting it here, but they warned me not to re-distribute since its a interim patch not meant for production. We decided against deploying the patch anyway and just fast tracked the Update 25 out to everyone last night. At least this shows Oracle is FINALLY seeing how big of an issue this is, and hopefully have something out before the end of the year in production. Anyone else need a beer after this week??? ;)

  81. Matthew
    Posted June 21, 2013 at 2:55 pm | Permalink

    For JRE 7 update 25, you need an active Oracle support agreement. As of update 25, this patch is available for both x86 and x64 with patch numbers 16631990 (x86) and 16964517 (x64). Even if you have a support agreement, you will need to open a case to get the password to download patch 16964517.

    • Bryan
      Posted June 24, 2013 at 1:07 pm | Permalink

      So 16631990 and 16964517 is the v7u25 equivalent of 16758419, which suppresses the warning dialog boxes? If so, would you be willing to post a link to the files?

  82. NoOne
    Posted June 22, 2013 at 8:53 pm | Permalink

    You can download the patched version for u21 here:
    http://www.fileswap.com/dl/L9tKiPScUg/

    Thank you Oracle for making me work on a Saturday night installing your buggy and hopeless software.

    • Bryan
      Posted June 24, 2013 at 1:07 pm | Permalink

      Thanks, NoOne!

  83. Joe
    Posted June 26, 2013 at 3:35 pm | Permalink

    Anyone else notice that the deployment.version is equal to 7.21 in the DP file after upgradeing to 7.25? I noticed this in both the Public and “patched” version. Reason I bring it up is, my line in the DP file for deployment.security.mixcode=DISABLE no longer appears to get set correctly and I also can’t fake out the deployment.baseline.url path to an internal server like I could with 7.17 and 7.21.

    Wonder if Oracle secretly made some changes again?

    • Bryan
      Posted June 26, 2013 at 6:27 pm | Permalink

      Yeah, I noticed that too. At first I thought it was an old d.p file so I went through and deleted all of them but the new file said the same thing. It really bothers me how much Oracle changes/brakes the properties in the d.p file. But what gets me the most is they don’t document most of the properties.

      • Joe
        Posted June 27, 2013 at 10:01 pm | Permalink

        Thanks for confiming Bryan. I’ll bet I spent a 1/2 day trying to figure that out and the fact that the mixcode=disable can no longer be set via the d.p. file. Not fun explaining to a manager that “I don’t know why that no longer works”.

  84. Todd
    Posted July 1, 2013 at 11:32 am | Permalink

    Thanks for this page guys. Our company too has fallen victim to this issue and we are now having meetings with IT managers to brainstorm to come up with ideas on how to fix this. From my perspective, we have to control what the users see and what they click on, Oracle has made this near impossible.

    We have been offered by Oracle’s sales department a version that does not “auto update” for 30k. We are considering spending the money, however I still get nervous because it seems this issue it not an “auto update” issue but rather a “insecure Java version dialog box” issue.

    We have alot of older legacy applications using java in our environment and we have sent numerous communications company wide (3000 – 5000 people) and they do not read and keep clicking the wrong things, which is resulting in insane hold times on the helpdesk and just pure chaos on java update days.

    We need to do something and we need to do it quick. The issue also becomes our IT Security department, they will not accept any outdated versions of Java.

    Any additional suggestions would be greatly appreciated :)

  85. TimJ
    Posted July 1, 2013 at 2:13 pm | Permalink

    Anyone know if the patch will work on U11? We are locked in to 7u11 due to some internal software.

  86. Todd
    Posted July 1, 2013 at 3:18 pm | Permalink

    Pretty sure this “patch” is just a version of 7v21 that has the code modified to supress auto update and the “insecure version” message. I just logged into Oracle support and got this version, the issue with the version is that our IT-sec team will not allow anything but the latest and greatest. We have had to hack the crap out of Java (short of the internal code) just to get our software to work. We have software that will only run on Version 6 so we need to trick it into believing that 7v? is version 6… headache!

  87. Joe
    Posted July 1, 2013 at 8:20 pm | Permalink

    Todd,

    Here is my .02, and best of luck to you by the way. I tested the 2 versions of 7.21. One version was Auto Updates off and suppress the extra warning messages (Oracle support has said they won’t do this for 7.25). The other was just AU off and if you set your date our 6 months it simply never expired. That is exactly how the “special” 7.25 version offered from Oracle support behaves. I deployed this to production and it’s been working fine so far. The only prompts your users should see is what started with 7.17 with the “extra warning” messages. If a user clicks no, the app does not work. Launch it again and you’re fine. In my opinion the upgrade popup is much worse. Click on Block and it’s a HD call.

    I’d tell your managers that the risk should be small with the “special” 7.25″ with upgrade off. Assuming you have an Oracle support contract to download this. The special version shows up like this: 1.7.0_25-b32.

    The holy grain MIGHT be in October if they finally get the local policy (let’s hope it’s GPO instead) to whitelist apps so the annoying “Do you want to run this” can be suppressed. Until then, let’s hope there are no 0-day threats that require another release. Even if they do, with the AU off version you should be fine. Oh, and you may want to think about setting your security to Medium as well. Read through the whole comments section for reasons, especially if you have older apps.

    • Matt
      Posted July 2, 2013 at 2:57 pm | Permalink

      Joe – thanks for providing that info to the group. I am confused about the relationship between “Auto Updates” and the “Your version of Java is insecure” messages. Isn’t Auto Updates essentially referring to the “Updates” tab in the Java Control Panel? We already have this tab hidden and the underlying update process suppressed.

      We desperately want the “Your version of Java is insecure” message to not pop up in our enterprise. Tons of users click Upgrade and screw up our enterprise Java install, or click Block and disable Java in their browser. All generating a flood of Help Desk calls.

      Patch 16758419 for update 21 specifically says “with Auto-update Off and Insecure Java Version Message suppressed”. Sounds great, if not late since we have already rushed out 25.
      Patch 16631990 for update 25 only says “with Auto update off” – when the next security update comes out and they mark update 25 as secure – is the Insecure Java Version message going to come up even with this patch enabled? I set the system date a year into the future with this patch and I get the similar “out of date” dialog – so it seems the version still expires even with this update 25 patch.

      Thanks,
      Matt

      • Reza
        Posted July 9, 2013 at 2:27 pm | Permalink

        Hi
        thanks alot for your tips which saved us.
        I have other issue with Java deployment and that would be great if somebody help me out on this: when i deploy java to my test machines when I login as a normal user and open IE it asks for suername/password which it is looking for admin user. apparently it wants to enable java add-ons for IE and it looks for Admin account. what should i do in my deployment script so it happens during the installationand it doesnt ask user anything.

        Thanks
        Reza

        • Reza
          Posted July 10, 2013 at 1:58 pm | Permalink

          Hi Guys,
          I am still looking for a solution for this. i figured this is because of 2 SSV helper Plugins. how can I keep them enabled without login sccreen pop up on win7 users. apparently winXP is fine.

          any hint about this would be great.
          Reza

      • Joe
        Posted July 9, 2013 at 5:49 pm | Permalink

        Matt,

        Just to recap, any 7.25 version right now will turn off the “your version of Java is insecure” message. If you turned off the AutoUpdates tab (which I hope everyone does) that’s great as it will stop the balloon popup in the systray, but it Does Not stop the new updating mechanism that Oracle put in place with 7.17 and above.

        When 7.21 came out and corporations are like, WTH Oracle, they quickly created the 7.21 With Auto-Update off. (This has nothing to do with the Updates tab, but the new Auto Update mechanism.) I’m sure most of us also heard from end users what is this security popup that now comes up. That was the 2nd patch Oracle made for 7.21 with AU off and insecure suppressed.

        7.25 now comes out and thankfully Oracle was quick to create a 7.25 with AU off. That again is only the new update mechanism that throws the Upgrade, Block, or Later message. This is the version that I’ve tested that if you set your date our past the expiration any date in Dec 2013 you do NOT get the prompts. If you have the stock 7.25 and set your date to Dec 2013 you will reach the hard coded EOL and get the warning prompts. At least that is what happened with my testing . . . I could be wrong.

        So if you can get the 7.25 with AU off it is essentially insurance that you don’t get these prompts again until you are ready to push out the next version. Personally, I’d try hard to get this because if Oracle really adds all these new features to 7.2X who know how many issues we’ll have.

  88. Frank Bazan
    Posted July 10, 2013 at 4:06 pm | Permalink

    I seriously cannot find that patch.
    I really need to deploy 7.21, .25 is not yet approved by our security division

  89. goppi
    Posted July 10, 2013 at 9:07 pm | Permalink

    Hi guys,

    thank’s for this valuable website.

    Anyone able to provide a link to the “7.25 with AU off” version as we do not have a Oracle support contract?

    THX

    • Eric
      Posted July 18, 2013 at 1:50 am | Permalink

      Hi, Did you get a copy of 1.7u25 with AU off that you can share?

      • goppi
        Posted July 18, 2013 at 3:56 pm | Permalink

        No.

        Seems that nobody is willing to share it.

        • LaBareWeb
          Posted July 18, 2013 at 5:21 pm | Permalink

          If I worked for the company that had the extended $$ Oracle support I would, however I’m consulting so I am not able to share.

  90. Exigo
    Posted July 11, 2013 at 3:22 pm | Permalink

    Hi,

    Anyone could be so kind to provide me the “7.21 with AU off”?, I am not able to download it from the Oracle support website.

    Thanks in advance.

  91. Pisboi
    Posted July 12, 2013 at 12:33 pm | Permalink

    Those of you who have virtualization products available (Microsoft App-V, VMWare ThinApp, Symantec something..) should consider running your Java apps with a virtualized versjon of Java.

    You can then start the app with the Java version you want – and still have the latest and greatest version of Java installed locally on the client. Or better – you don’t need to have Java installed at all.

    Not a solution for everyone, though.

  92. TimJ
    Posted July 15, 2013 at 12:07 pm | Permalink

    7.21 major blowing up issue this am. Alot of users being redirected to the java site on apps requiring it. What a nightmare!

  93. TimJ
    Posted July 15, 2013 at 12:16 pm | Permalink

    Meant 7.11.

  94. Tarik Sarisen
    Posted July 18, 2013 at 2:35 pm | Permalink

    Hi all,

    how are your experiences about Java 7 Update 17. I am here in a 64-bit W7 environment using both Java 64 and 32 and have to package Java for both type of systems. As far as i can see on your posts every new version of Java could bring the above solution to breakdown.

    Can you please advice the best and proper solutions for 7update17, would work out myself, but need a little help on the start.

    Thanks

  95. Posted July 25, 2013 at 1:36 pm | Permalink

    Have you tried this ?

    https://www.java.com/en/download/faq/expire_date.xml#redirect

    simply delete the deployment.expiration.decision registry entry.

  96. Posted July 26, 2013 at 7:00 am | Permalink

    Fyi.

    HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties

    deployment.expiration.decision.suppression.10.21.2 REG_SZ “True”
    suppress the popup by us.

    the bad thing is that the name changes at next update to:
    deployment.expiration.decision.suppression.10.25.2 REG_SZ “True”

    Removing the deployment.expiration.decision from the Qracle Knowloadge base does not Fix the issue.

  97. TimJ
    Posted July 29, 2013 at 7:57 pm | Permalink

    No help for you on 7.17, but 7.21 has an issue where the java icon does not always show up in the control panel.

  98. James Medley
    Posted July 31, 2013 at 1:03 am | Permalink

    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.

    • Maseol
      Posted August 16, 2013 at 8:26 am | Permalink

      So what you all are saying is:
      Oracle has released a JRE 7.25 version without the “Your Java version is insecure” popup, but you’ll have to pay up for it, buying support from Oracle?

  99. g4m3c4ck
    Posted August 9, 2013 at 5:15 pm | Permalink

    We do the following in order to keep Java from updating after a Java deployment.

    We have a script that enumerates “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\”
    For the Displayname “Java Auto Updater”, Publisher “Sun Microsystems, Inc.” and then we execute the Uninstall String in the registry Silently.

    Also we enforce these registry keys:

    “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\EnableJavaUpdate”, 0
    “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\EnableAutoUpdateCheck”, 0
    “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\NotifyDownload”, 0
    “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\NotifyInstall”, 0
    “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\10.25.2\HideSystemTrayIcon”, 1

    We have never experienced any notifications of running outdated Java.

    On the deployment.config side of things. I have learned that user settings in %userprofile%\AppData\LocalLow\Sun\Java\Deployment\deployment.properties will override the configuration that deployment.config points to unless .locked is used on the setting.

    Example:
    deployment.security.mixcode.locked
    deployment.security.mixcode=HIDE_RUN

    If .locked is not used %userprofile%\AppData\LocalLow\Sun\Java\Deployment\deployment.properties has to be removed for deployment.config settings to take effect.

    I have been try to find a way to get Java to treat the settings in deployment.config as a preference instead of locking it.

    Possibly script running a config with locked settings first, running a dummy process of Java to enforce them and then putting a config in place with the settings not locked? Not really a possibility I really want to explorer if I don’t have to.

    If the settings where deployment.config points to were treated as a preference then a lot of deployment headache would be cured.

  100. kEmOsAbE
    Posted August 13, 2013 at 3:58 pm | Permalink

    Just want to share my findings… i downloaded the hotfix for java 1.7_21.. it is a exe file. I extracted all the folder and files from the exe file. I just ran the jre msi file without running the au msi file. It seems to work.. (I’m still doing more testing..) so far, it ran on our apps that reguires java without a hitch.. no messages either.. went to java games site just to see if it works.. and it works as well.. only caveat that I see so far is if you go to Oracle java site, it will tell you that you’re java is not installed..

    hope this helps…

  101. kEmOsAbE
    Posted August 14, 2013 at 1:04 pm | Permalink

    Just as an update…

    I did further testing.. It does work! I’ve even went to the Sun Java website, let the site detect it.. and it does detect it.. So far, no notifications, no messages!

    • John
      Posted August 22, 2013 at 1:37 pm | Permalink

      What hotfix did you download ?

  102. Emil
    Posted September 2, 2013 at 3:17 pm | Permalink

    Hi
    Has anyone seen if Oracle has published non-auto updating version also for 1.7.25 or is it still only available for 1.7.21?

  103. Bert&Ernie
    Posted September 3, 2013 at 3:16 pm | Permalink

    Hi Guys,

    Hope this helps…….

    It would appear that Java 7 Update 25 does apear to contain an AU “Patch”

    I am not sure if this is anything to do with what is being documented above but if you install the native 32-Bit installer onto a test machine and then once you have completely installed it you can navigate to %AppData%\LocalLow\Sun\Java\AU and you will find an AU.msi and AU.cab file in there.

    After inspecting this with Installshield it would appear there are JAUcheck.exe, JAUreg.exe, JUcheck.exe & JUsched.exe files. There are also a couple of XML files withih the installer and also a setrunkey with a condition of OEMUPDATE=0 and DISABLE=0 setting. The files get stored in the C:\Program Files (x86)\Common Files\Java\Java Update area when the MSI is run. The setrunkey appears to place a Reg Key in the HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Run location that references the JUsched.exe file

    I am currently in the process of messing around with this but I also need to deploy Update25 to our company in the next couple of weeks so am keen to avoid the “An unsigned application from the location below is requesting permission to run” prompt!! But this may initially help with the “Your Java version is insecure” Prompt.

  104. Matt
    Posted September 6, 2013 at 4:03 pm | Permalink

    When I originally found this post we were mostly on Java 6 on Windows XP. We have been migrating people to Java 7, and now have over 4500 PCs running Java 7 Update 25. About 95% of those 4500 PCs are still XP. Will this be a problem when the next update comes out? Does this only happen on Windows 7 with Java 7, or does it happen on Windows XP with Java 7, or Java 6…? According to the last patch, the next update is scheduled for October 15th. With my company’s security requirements, I’m supposed to apply security patches within 7 days of release. This leaves next to no time for testing. I may just have to schedule vacation for a week :-)

    http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html

    Separately, I’m now required to apply DISA STIG settings for Java. So I’m not sure if these settings will conflict.
    http://iase.disa.mil/stigs/a-z.html#J

    I’m not really expecting an answer here, just wanted to vent about Java for a bit.

  105. Greg Zielinski
    Posted September 9, 2013 at 6:08 pm | Permalink

    https://jdk7.java.net/EA_features_changes.html

    Option to disable the “JRE out of date” warning:
    When the installed JRE, 7u10 or later, falls below the security baseline OR passes it’s built-in expiration date an additional warning is show to users to prompt them to update their installed JRE to the latest version. For businesses that manage the update process this may cause problems when users attempt to update their JRE themselves.

    To suppress this one specific warning message add the following in the deployment properties file: deployment.expiration.check.enabled=false
    For the location of the file see: http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html
    The OS X deployment property file is located: ~/Library/Application\ Support/Oracle/Java/Deployment/deployment.properties

  106. fl0w3r
    Posted September 10, 2013 at 9:23 pm | Permalink

    Java 7 update 40 was released today
    http://www.oracle.com/technetwork/java/javase/downloads/index.html

    Check the new features and changes:
    Option to disable the “JRE out of date” warning
    Starting from 7u40, a new deployment property deployment.expiration.check.enabled is available. This property can be used to disable the “JRE out of date” warning.

    When the installed JRE (7u10 or later), falls below the security baseline or passes it’s built-in expiration date, an additional warning is shown to users to update their installed JRE to the latest version. For businesses that manage the update process centrally, users attempting to update their JRE individually, may cause problems.

    To suppress this specific warning message, add the following entry in the deployment properties file:

    deployment.expiration.check.enabled=false

    For more information, see Deployment Configuration File and Properties.

    look at the update to this faq today: http://www.java.com/en/download/faq/expire_date.xml

    • Bryan
      Posted September 13, 2013 at 5:37 pm | Permalink

      There’s also a new feature called “Deployment Rule Set”:
      http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html

      This allows you to have full control; the way Java should have been built a long time ago. I’m busy on another project right now so I haven’t tried this out yet. It looks like the very thing all of us have been waiting for though. I’ll give you guys an update once I try it.

    • Posted September 13, 2013 at 11:10 pm | Permalink

      Today i tried the new setting “deployment.expiration.check.enabled=false” with Java7u40 on W7x64.

      I already had a working deployment.properties file (double checked this by changing some settings in the properties) and added this setting.
      I saw that the setting is read from the deployment.properties file and the HKCU-registry key in (HKCU\Software\AppDataLow\Software\JavaSoft\DeploymentProperties) is updated with this setting.
      But when changing the systemdate after the built-in expirationdate of 10-dec-2013 Java7 is still giving me the “Java out of date” warning.
      See sreenshot http://i.imgur.com/Hi8KBKE.png
      Can somebody confirm this?

      Did also some tests with the Deployment Rule Set, and it looks like this is working. I can’t test 100% because i need een CA-signed JAR. So i can test that when having a “C:\Windows\Sun\Java\Deployment\DeploymentRuleSet.jar” which i had self-signed all Java applications are BLOCKED! This is as designed.
      See screenshot http://imgur.com/rw5AKB1

      • KnifMelti
        Posted September 17, 2013 at 10:45 am | Permalink

        I can confirm.
        But, i’t’s no longer red dialogs that eventually forces the users into a loop!
        The users just have to check/select the bottom checkbox/entry once until the next update (I assume).

        Think I can live with this solution and repackage the JRE every 3 months, following Oracles pipe ;-)

  107. Shawn Umansky
    Posted September 12, 2013 at 8:03 pm | Permalink
    • Andre
      Posted September 17, 2013 at 7:25 am | Permalink

      Thanks!!!

  108. dandirk
    Posted September 21, 2013 at 4:24 pm | Permalink

    The new expiration.check.enabled setting works but with some conditions… there are always conditions with JAVA :(

    I found if the deployment.expiration.check.enabled=false is in HKCU entry before running any java content it works as expected. It will NOT work if java content is run before your system deployment.properties file is replicated (new users basically).

    Test Baseline
    1. Win7 company image without java installed (I always do this first before testing upgrades).
    2. No %windir%\sun\java\deployment folders/files (these are installed by my java msi), will refer to this as “windir”
    3. No %userprofile%\apdata\locallow\sun\java\deployment folder, will refer to this as “userprofile”
    4. No reg data in HKCU\software\AppDataLow\Software\JavaSoft\Deploy… (actually keys don’t exist), will refer to this as “HKCU”
    5. no Java content run at all
    6. Java 7.0.40 x86 installed, tested using 32bit IE 8.
    7. System date set to x/x/2015

    My testing procedure, so you can mimic… hurah for the scientific method:)

    TEST #1 (fresh install as system account, straight to java content, did not run Java control panel applet)

    1. Install Java 7.0.40 (I used extracted msi) with custom deployment.properties and deployment.config files in Windir location.
    2. Check HKCU still empty (as expected installed as system acct)
    3. Check windir files are there with proper settings etc as expected.
    4. Check userprofile, still empty/does not exist.
    5. Go to: http://javatester.org/version.html

    RESULT: Receive upgrade, block, later prompt. Checked the HKCU location and it still is not populated with any settings when dialog is showing no selection made. checked userprofile location, it also is still empty.

    COMMENT TEST #1: Looks like properties.deployment file is useless at this point, at least in regards to the update prompt since its settings are not replicated to HKCU or userprofile when a java applet is started in this test scenario. IF you click Upgrade, and close the browser. Check HKCU location, the windir settings do get replicated but AFTER the upgrade/block/later dialog presents and is clicked through. While you will have the entries related to the upgrade dialog like deployment.expiration.decision.10.40.2 etc they seemly will be ignored NEXT time you run a java app because the expiration.check.enable setting is now populated and effective.

    TEST #2 (fresh install as system account, launch Java control panel, THEN access java content)

    1. Install Java 7.0.40 (I used extracted msi) with custom deployment.properties and deployment.config files in Windir location.
    2. Check HKCU still empty (as expected installed as system acct)
    3. Check windir files are there with proper settings etc as expected.
    4. Check userprofile, still empty/does not exist.
    5. Launch Java 32bit control panel applet, close by clicking OK
    6. Check HKCU, all custom settings from windir deployment.properties file is populated.
    7. Check userprofile, user deployment.properties file is created, but custom settings from windir file are not. I believe this is expected incase you allow user to override by not locking the setting in windir file.
    8. Go to: http://javatester.org/version.html

    RESULT: Receive Do you want to run this application prompt. This is expected, this version (40) doesn’t allow you to bypass unsigned java apps, which this test site seems to have. NO Update, block, later prompt though.

    COMMENT TEST #2: Looks like properties.deployment file replicates its settings only once the java control panel applet is run. At which point the setting seems to work in my test scenarios… But the deployment.expiration.check.enabled=false settings has to be in HKCU BEFORE you run any java content.

    OVER ALL COMMENTS: Still an issue with replication of the deployment.properties file, those settings seem to be replicated AFTER the update dialog/check is performed. While this will not be an issue for current users, because most should be running java content, replicating the settings before expiration… it will still present once AFTER the expiration date for NEW users/comptuers. Now my results could be off because I use the msi rather then the exe which also includes the updater app (if you use msi you don’t have to disable updates because the updater is a seperate msi installed by the exe.). It could be possible that the exe installer updates the deployment.properties file somehow replicating the settings before the user runs java content.

    • tLambda
      Posted September 23, 2013 at 2:02 am | Permalink

      Thanks for this.

      I double checked your testing, and confirmed that you indeed need to have HKCU:\Software\AppDataLow\Software\JavaSoft\DeploymentProperties\deployment.expiration.check.enabled=false set before java is launched for the first time to avoid any errors.

      If I don’t set this, I see a ‘Your Version of Java is Insecure’ prompt the first time I run an applet.

      I don’t see the error when I run applets any subsequent times as it looks like the configuration from C:\Windows\Sun\Java\Deployement\deployment.properties is put into the registry on that first run.

      I’m going to push that registry key via group policy to avoid any issues.

    • Posted September 23, 2013 at 7:44 pm | Permalink

      credits for dandirk and thumbsup for tLambda
      I didn’t had the time to troubleshoot this issue myself. Tomorrow and i will check if i recieve the same results so i can make another :-( custom Java-deployment setting in my SCCM-deployment.

      I must also to put some time in investigating to sign the DeploymentRuleSet.jar with a CA-cert and test with the Deployment Rule Set.

  109. fl0w3r
    Posted October 9, 2013 at 4:25 pm | Permalink

    Thank you for sharing your findings.

    I have been testing adding a the line “deployment.expiration.check.enabled=false” in the following path:
    c:\users\\AppData\LocalLow\Sun\Java\Deployment folder.

    I moved the system clock to 12/15/2013, and I get rid of the “out of date” message. So I think the job is done with adding that line in each profile.

    Now, what is the purpose of adding the line in the registry, it is really needed????? —>>>>
    HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties
    Create a new dword called deployment.expiration.check.enabled and set the value to false.

    to add the line “deployment.expiration.check.enabled=false” to each profile, what guys do you use: a group policy or a script along the script to deploy Java 7 update 40?

    • dandirk
      Posted October 15, 2013 at 12:58 pm | Permalink

      The only reason to put the reg edit in HKCU for all users is if you don’t EVER want to show the Upgrade, Block, later expiration check dialog.

      If you don’t put that reg there, the deployment.properties file entry (with same setting) will automatically write the HKCU entry for you, but ONLY AFTER java content is run and the expiration check/dialog is done.

      So all current computers/users that run java content BEFORE the expiration date will not see the dialog/prompt because java isn’t expired and the deployment.properties file setting will propagate to HKCU.

      BUT new computer/users AFTER expiration WILL see the prompt ONCE since the deployment.properties file settings are written to HKCU AFTER java content is run and the expiration is checked. The 2nd time they will NOT see the dialog because the setting will be in HKCU after the first run.

    • dandirk
      Posted October 15, 2013 at 1:01 pm | Permalink

      Also you don’t really want to edit the deployment.properties file in the users profile… it is best practice to use the system version of the same file so ALL users are automatically using the same settings…

      http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/properties.html

      I use the default location of c:\windows\sun\java\deployment.

      As for how to deploy the HKCU reg entry if you wish… GPO, activesetup, login script… many ways.

  110. Andreas Gräf
    Posted October 11, 2013 at 2:40 pm | Permalink

    After several tries here: Remember to put in:
    deployment.expiration.check.enabled=false
    (lower case). A “FALSE” will not work!
    Saves a lot headache!

  111. Posted October 16, 2013 at 9:44 pm | Permalink

    Like dandirk and tLambda (thumbs up) told:
    HKCU:\Software\AppDataLow\Software\JavaSoft\DeploymentProperties\deployment.expiration.check.enabled=false

    works and i will put this in our deployment for the current logged on users when SCCM is deploying Java7u40. We use WinBatch for custom deployments and i now add this HKCU-setting after the MSI install of Java. And for users who log on afterwards we allready use the Microsoft Activesetup technique and we add this HKCU.

    In my previous post i did promise to test with the DeploymentRuleSet.jar (DRS) JAR’d from a ruleset.xml. My Company bought a EV code signing certificate ($900/3y). And i finally managed to use a working DeploymentRuleSet.jar. I had some trouble to create a valid ruleset.xml because i used copy/paste some examples from the Oracle-site and this results in errors when the DRS was parsed on my test-client.
    The error was “exception parsing deployment rule set” and all Java applets were blocked “as designed” when the DRS has an error. Retype some parts from scratch of the examples solved this problem.
    Finally now we can use DRS to prevent the unwanted warning when users starts Oracle EBS11.

    Now i must test Java7u45 if it needs still all the custom pre- and post-deploymentsettings. And also test if unsigned or self-signed applets can run.

    On request i can post some additional info about the whole process of creating the DeploymentRuleSet.jar

    • Per
      Posted October 18, 2013 at 8:39 am | Permalink

      Yes ericvv, please post an example of a ruleset.xml that works for you.

  112. Geniee
    Posted October 18, 2013 at 4:58 am | Permalink

    I just wanted to leave a note with how i got this working (there was lots of info in this thread but it was hard to find a clear step by step with success).

    – Run the Java exe on a test machine, digg out the MSI + files from the %userprofile%\Appdata\…. area
    – Create an MST using ORCA, set the update settings to not update etc.
    – Create a blank “deployment.properties” file and have the “deployment.expiration.check.enabled=false” inside it.
    – Install the MSI + MST
    – Copy the deployment.properties to C:\Windows\Sun\Java\deployment
    – Launch IE, browse to http://javatester.org
    – Test the version with the button on the site
    – Accept the security prompt (in our org. we are leaving this security level HIGH)
    – Wait for any pop-up about an out of date version?
    – Open up REGEDIT
    – Browse to HKCU\Software\AppDataLow\Software\JavaSoft\DeploymentProperties
    – You should see “deployment.expiration.check.enabled” REG_SZ false
    – Retest by re-loading the Javatester.org website
    – Retest by closing / reopening browser and hitting Javatester.org again
    – Log off and on as a new user, repeat test to make sure the HKCU is being populated under the new user.
    – Package up
    – Have a beer

    • LaBareWeb
      Posted October 18, 2013 at 2:46 pm | Permalink

      Thanks, I added this to the top of the main article since its so hard to weed thru 100+ comments. I’ve completely given up on Java 7 and backtracked to 6. Just didn’t have the time for it anymore and the popups were pissing everyone off.

  113. Posted October 28, 2013 at 3:36 am | Permalink

    After two days research, we have a way to fix this issue.
    As this is a high priority issue, so we sent our ideas to you:

    1. In this folder there is a file named baseline.versions file. We can open this file with Notepad. This file was located in the current user folder.

    2. We need to copy “1.8.0_001.7.0_251.6.0_651.5.0_551.4.2_43” into this file.

    3. Save this file.
    If we finished these steps. We can make sure that JAVA would not pop-up “out of date” until 15 Nov 2013.
    After 15 Nov 2013
    We still have a way to suppress the “out of data” pop-up.

    Steps: 1. Open the folder under current user\AppData\LocalLow\Sun\Java\Deploymen

    2.We need to edit or replace the “deployment.properties” file. We need to add some parameters. We can provide a test versions of properties file for your test.
    copy these into the “deployment.properties”

    #deployment.properties
    #Mon Nov 18 13:44:56 CST 2013
    deployment.modified.timestamp=1384753496250
    deployment.expiration.decision.10.25.2=later
    deployment.expiration.decision.suppression.10.25.2=true
    deployment.capture.mime.types=true
    deployment.expiration.decision.timestamp.10.25.2=10/25/2013 9\:6\:25
    deployment.security.level=MEDIUM
    deployment.browser.path=C\:\\Program Files (x86)\\Internet Explorer\\iexplore.exe

    3. We need to change Java Security level as medium. And this setting can be done in the “deployment.properties” file.

    If we finished all of these steps, we can to suppress the “out of data” pop-up after 15 Nov 2013. But we need to write a VBS or a Bat file to make it done.
    Please help to confirm if this is a possible way to resolve this issue.

    I did some test… If this can help. Please let me know.
    My E-mail address:love4everjtx@126.com
    Thanks all.

  114. Posted October 28, 2013 at 4:21 am | Permalink

    This e-mail was I sent my leader… there is some screen short I cannot copy to here…
    I would like to say some background…
    We are useing JAVA 25 (32bit) now, and it’s pop up out of date after 15/10/2013. As JAVA 25’s exprie data is 15/Nov/2013. So we need to fix it.

    1.C:\Users\luomak\AppData\LocalLow\Sun\Java\Deployment\security\baseline.versions
    The baseline.versions file recorded the last versions information.
    1.8.0_00
    1.7.0_45
    1.6.0_65
    1.5.0_55
    1.4.2_43
    We need to change the 1.7.0_45 as 1.7.0_25
    1.8.0_00
    1.7.0_25
    1.6.0_65
    1.5.0_55
    1.4.2_43
    Save it.
    After this step, Java will not pop-up out of data unitl 11/Nov/2013.

    If use java25 and we wanted to suppress the out of date pop up after 11/Nov/2013.
    We must set up the JAVA security Level as Medium… If you cannot accept this option as Medium…Then ignore the bellow setps…

    Under C:\Users\luomak\AppData\LocalLow\Sun\Java\Deployment.
    There is a very important file. deployment.properties.
    replace all of the settings, use bellow setting.
    #deployment.properties
    #Mon Oct 28 11:57:19 CST 2013
    deployment.security.level=MEDIUM
    deployment.expiration.decision.suppression.10.25.2=true
    deployment.trace=true
    deployment.expiration.decision.10.25.2=later
    deployment.javaws.viewer.bounds=600,261,720,360
    deployment.browser.path=C\:\\Program Files (x86)\\Internet Explorer\\iexplore.exe
    deployment.expiration.decision.timestamp.10.25.2=10/25/2013 9\:6\:25
    deployment.modified.timestamp=1382932639988
    deployment.console.startup.mode=SHOW
    deployment.capture.mime.types=true

    Let me do some explain…
    to set up the security level as medium.
    deployment.security.level=MEDIUM
    ‘This option must be setup as later…
    deployment.expiration.decision.10.25.2=later
    And this must be true.
    deployment.expiration.decision.suppression.10.25.2=true

    Run Javatester.org websit. If you still get out of date pop up. then push F5 to reflash the websit.
    update some information…
    deployment.expiration.decision.10.25.2=later
    deployment.expiration.decision.suppression.10.25.2=true
    The first time we run javatester.org websit. JAVA’ll check some register underHKEY_USERS\SID\Software\AppDataLow\Software\JavaSoft\DeploymentProperties.
    If the reg_key value exist. and it’s different as our deployment.properties file.
    first time JAVA will use the register settings to run JAVA.
    But the register key value will not sync deployment.properties.
    The second time we run JAVA software. the deployment.properties file’ll sync the REG files…
    So we will not get the out of date pop-up.
    I have did some test. and it’s OK all of pc passed the test.
    Holp this can help some one. haha
    OK. If any problme. Please leave message.
    Thanks.

    • fl0w3r
      Posted October 28, 2013 at 3:50 pm | Permalink

      dandirk, geniee,

      thanks a lot for taking the time in posting your comments :)
      I was testing and I found something that it is really really weird. Trying to figure out what causes this:

      what happen: I replaced (using a script) the deployment.properties file with a file that has 3 lines:
      deployment.javaws.autodownload=NEVER
      deployment.javaws.autodownload.locked=
      deployment.expiration.check.enabled=false

      Success! I see the new file in C:\Windows\Sun\Java\Deployment with the 3 lines, after 2 or 3 minutes without doing anything else from my side it changed back! to only have 2 lines:

      deployment.javaws.autodownload=NEVER
      deployment.javaws.autodownload.locked=

      I thought I was going crazy. but I tested this in several machines and the same behavior ocurred.
      Does anyone of you have encountered this?

      I wonder now if that step is really necessary, if not I might need to apply another solution and just add the entry in HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties
      “deployment.expiration.check.enabled”=”false”
      for each user.

  115. Posted November 7, 2013 at 2:51 am | Permalink

    Hi All,

    Have you seen the new “Deployment Rule Sets” feature which was introduced on the 20th of August? It apparently work with JRE 1.7 u40 and byond. This is the first I’ve seen/heard of it and it looks like a f*cking mess!

    Why can’t Oracle store their settings in the windows registry like they’re supposed to and then they could create a Group Policy ADMX files. This would be sooooooo much easier!

    This is rediculous, I hope companies start looking for an alternaitve to Java!

  116. Geniee
    Posted November 8, 2013 at 12:38 am | Permalink

    I was finding before i realised that you need the deployment.properties file in the C:\Windows\Sun\… dir. If you manually created the reg entry to stop the out of date check, via the entry

    HKCU\Software\AppDataLow\Software\JavaSoft\DeploymentProperties\“deployment.expiration.check.enabled” REG_SZ false

    As soon as you loaded up Java it would kill it off.
    So i see the “deployment.properties” file like the windows “Default User” profile creater template of old WinXP days.
    Whatever is in that file, will be added to the HKCU.

  117. Geniee
    Posted November 11, 2013 at 12:16 am | Permalink

    FYI folks, we have figured out how to “WHITELIST” web sites from seeing the “Are you sure you want to run Java on this page”
    This was very important for our ORG as we have several internal sites that are used that require Java.
    We were also seeing a bad dialog box that would seem to crash Java, and you couldnt actually accept the dialog box, it was just not clicking.
    Before going any furthur. Here are some references that i used.
    https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1072
    https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets
    http://docs.oracle.com/javase/tutorial/deployment/jar/index.html
    http://docs.oracle.com/javase/tutorial/deployment/jar/signing.html

    Basically, you need to follow these steps.
    – Download the latest JDK and install to default locations.
    – Open notepad and create an XML file named ruleset.xml
    – Use the following format.

    See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html#examples for additional examples.

    Make sure the ruleset.xml is in the same location as the JAR.exe command you will need to run C:\Program Files (x86)\Java\jdk1.7.0_45\bin

    In a CMD prompt run the following, change to C:\Program Files (x86)\Java\jdk1.7.0_45\bin
    type the following

    jar -cvf DeploymentRuleSet.jar ruleset.xml

    This will create a file named DeploymentRuleSet.jar
    This file now needs to be signed using a cert.

    Depending on your Org, you may have a cert store, or it may be inside your browser that you can export as a PFX file (note you will need to know the password)
    (http://www.pentaware.com/pw/how_to_export_a_pfx_file_from_your_browser.htm)

    Check to see if the JDK Keytool can read the PFX(.p12) file by running the following in the CMD prompt.
    It will also list an Alias which will be a long bunch of letters and numbers (needed below)

    keytool -list -v -storetype pkcs12 -keystore “name_of_exported_cert.pfx”

    There will be a huge output, but up top you will see an Alias.
    Take note of the Alias (copy to notepad or somthing)
    Next, you will need to paste the file names of the PFX file and the Alias from the previous command.

    jarsigner -storetype pkcs12 -keystore “name_of_exported_cert.pfx” DeploymentRuleSet.jar “paste_the_alias_from_previous_step”

    Verify the signature of the file.
    jarsigner -verify DeploymentRuleSet.jar

    The file is now signed and can be placed on the workstations C:\Windows\Sun\Java\deployment directory.
    The URL’s listed in the initial RuleSet.xml will now be able to use Java without any prompts.

    To confirm the machines are now using this new DeploymentRuleSet.jar for the whitelist,
    open the Java console from ControlPanel,
    Click the Security tab
    You should see in the lower section “View the active Deployment Rule Set”
    Click this link
    You will now see what you entered in the RuleSet.xml file (your whitelisted URLS)

    Try visiting one of those URL’s and it should now just automatically start working without requiring any Java acceptance.

    Hopefully this will help some people, i know how frustrating Java can be and thought i would be able to help out.

    • Geniee
      Posted November 11, 2013 at 12:18 am | Permalink

      I forgot to paste an example of a RuleSet.xml

      —-

    • Posted November 21, 2013 at 9:49 pm | Permalink

      Geniee, thanks for sharing! Worked fine here.
      I do not want just to thank you – I want to complement your answer too. Just want to say sorry for my bad English, I’m Brazilian.
      Most enterprises – accounting, mainly – have a certification. At least on Brazil. If you do not have a certification, you do not need to pay Verisign to have one: do one yourself.
      First, install GetGnuWin32. It have a lot of useful Linux tools – one in special: openssl, that allow us to have a certification. You can download it here: http://sourceforge.net/projects/getgnuwin32/
      Open the downloaded executable. It will extract the contents of the file in the same folder you run it, creating a folder called “GetGnuWin32″.
      My recommendation is moving it to “C:\Program Files (x86)\GetGnuWin32″.
      Run, inside the folder, the “download.bat” and after the “install.bat” file. It can take some time, it is a little big.
      After the install, open cmd as administrator and run the command:

      #cd /d “C:\Program Files (x86)\GetGnuWin32\gnuwin32\bin”

      With this command, cmd will change the actual directory. If it didn’t, do it yourself.

      Now, run the following commands:
      openssl genrsa -des3 -out server.key 1024
      openssl req -new -key server.key -out server.csr -config “C:\Program Files (x86)\GetGnuWin32\gnuwin32\share\openssl.cnf”
      openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
      openssl pkcs12 -export -in server.crt -inkey server.key -out server.pfx

      It will ask you a password for the cert. I have used 1234.

      Inside “C:\Program Files (x86)\GetGnuWin32\gnuwin32\bin”, you will have 4 files: one is server.crt (deploy to the clients) and one is server.pfx (used to sign the DeploymentRuleSet.jar).

      Give right click on “server.crt” and select “Install certificate”.
      Follow the on-screen instructions.
      When the wizard ask you where you want to put it, select “put all certificates in the following repository” and select “Trusted authorities”.

      You now can keep reading the comment that Gennie commented. Use the certificate server.pfx.

      I want to make available, with who need it, the script (VBScript), certificate, my ruleset.xml, etc. that I have used in MDT 2010 to deploy Java in my corporation.
      It:
      * Checks if Java 7 Update 45 (both 86 and 64. 64 only if Windows is 64-bit) is installed before install. If installed, do not install. Just configure it.
      * Install Java unanttend, show only progress bar. If you want to hide it, use “/qn” instead of “/qb”
      * Deploy a custom deployment.properties and registry settings: Set Java Security level to Medium, do not warn about mixed code, do not check for Java Updates (remove SunJavaUpdateSched from the start, set autodownload to false, enablejavaupdate to 0, etc). In teory, it does not expires too, but I did not have tested. Only follow the recommendation of the people in comments (It replaces the files baseline.versions and update.timestamp with folders and use some settings in registry). Not sure if it works really, only in Feb ’14 I will know it.
      * After finished building DeploymentRuleSet.jar, I have copied the file to C:\Windows\Sun\Java\Deployment.
      * Installed the certified unantted.

      You can obtain the msi files referenced in the script at C:\Users\Administrator\AppData\LocalLow\Sun\Java. Note that this folder is only created AFTER you install Java on your machine.
      You need to use Orca (http://www.technipages.com/download-orca-msi-editor.html) to edit the MSI files. After install Orca, give right click in jdk1.7.0_45\jdk1.7.0_45.msi and select “Edit with Orca”.
      In the left bar, select “Property”. Now, in the right bar, you need to set AUTOUPDATECHECK, JAVAUPDATE and JU with the value 0.
      Click on the floppy in the top of the program to save the modified MSI file.
      Do the same process at jdk1.7.0_45_x64\jdk1.7.0_45.msi.

      It is based on the comments that I have read on this page and comments on it, and some other researchs I have done. I’d lost a day on it.

      https://anonfiles.com/file/68755b697c68869a081de8be76631104

      PLEASE NOTE: IT IS A VBSCRIPT. BUT IS FOR USE WITH MDT (TESTED ON 2010). YOU NEED TO EDIT IT TO MAKE IT USABLE IN OTHER SCENARIO.
      If you want to run it outside MDT, I recommend you download Elevate (http://jpassing.com/2007/12/08/launch-elevated-processes-from-the-command-line) and run in cmd (Run as Administrator!): cscript “Install-Java.wsf”
      You need to remove the ZTIUtility.vbs in the top of the script, replace oUtility.RunWithHeartbeat with oShell.Run “command”,0,True (remove iRetVal in front, and anything that have iRetVal at the code, including the “If (iRetVal = 0) or (iRetVal = 3010) […] LogTypeInfo End If”. May need some other adaptations but you can do it. VBScript is not so hard at all. Did not tested if it works outside MDT: It is just a suggestion from where you can start.

      Any suggestion to the script are welcome.

      Long life to IT Administrators!

      References:
      http://www.akadia.com/services/ssh_test_certificate.html
      https://langui.sh/2009/01/24/generating-a-pkcs12-pfx-via-openssl/

      • Posted November 21, 2013 at 9:53 pm | Permalink

        Forgot to comment: You can use the pfx file instead of crt file if your company already have pfx file installed. I’m not sure if you can install pfx unantted because you need to inform the password to import it.
        My DeploymentRuleSet allow javatester.org run without showing any warning. Worked here. REMEMBER TO IMPORT THE CERT BEFORE TRYING.
        I am using Java 7u45.
        Thanks.

  118. Geniee
    Posted November 24, 2013 at 11:31 pm | Permalink

    FYI, had another drama with IE10 and Java not loading correctly in the “Internet Zone”
    It would simply fail to launch the Java verifier. (javatester.org / java.com etc.)
    After lots of searching on the net, it turns out there is a GPO that you can turn on to “re-enforce” the default Java security of “High Safety”

    Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page \ Internet Zone \ Java permissions = High Safety

    According to the description, High Safety is the default if the GPO is set to “Not Configured” but in our case, it was not working untill we re-enforced this setting.

    Perhaps its a bug between IE10 and Java 7u40 that we are using.
    We did not have this issue with our Intranet or Trusted sites URL’s (perhaps they are allowing lower Java permissions by default?)

    Thanks for all the thanks guys, its important we all help each other out with documentation and knowledge.

  119. REBL
    Posted December 3, 2013 at 3:08 pm | Permalink

    What do you mean about the new Java Information? How will you manage this?

    New security requirements for RIAs in 7u51 (January 2014)
    By costlow on Sep 09, 2013
    Java 7 update 51 (January, 2014) intends to include two security changes designed to enhance authentication and authorization for Rich Internet Applications (Applets and Web Start). The default security slider is being updated in a way that will block RIAs that do not adhere to these requirements. Note: this only applies to RIAs, and not to Java on server or desktop applications run outside of a browser.
    Summary:
    • You are required to sign all RIAs (Applets and Web Start applications).
    • You are required to set the “Permissions” attribute within the Manifest.
    • Your application will be affected if it uses Java started through a web browser. Your application will not be affected if it runs anywhere outside of a web browser.

    Pasted from

  120. Tall_Paul
    Posted December 12, 2013 at 11:32 am | Permalink

    We’ve just started rolling out Java 7 update 45. Fortunately I’ve only put it on a few machines so far.

    What on earth are Oracle playing at? This is TERRIBLE software.

    I simply do not have the time, and neither do my team, to investigate and implement some of the fixes mentioned above and neither should we have to. Whoever at Oracle thought this was an improvement to version 6 needs firing.

4 Trackbacks

  1. By Sequencing Java - The Definitive Guide - Part 1 on February 27, 2014 at 9:37 am

    […] another Java update has been released. I have seen posts describing ways to suppress this (such as this one) but I did not have any luck with any of them – the only method that worked for me was to set […]

  2. […] Java 1.7 Auto- Update Deployment with SCCM/MDT – … – Create the folder C:Documents and SettingsUserApplication DataSunJavaDeploymentsecurity before installing Java… […]

  3. By Fix Drs.jar Errors - Windows XP, Vista, 7 & 8 on October 27, 2014 at 9:02 pm

    […] Java 1.7 Deployment with SCCM/MDT | LaBareWeb System … – From what I have seen deployment.expiration.decision=NEVER type edits in the properties file is only temporary and those can be over-written, usually when you …… […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Your email address will never be published.