**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.
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.
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
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!
It also shows up in the registy like this.
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/
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
108 Comments
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 !
Great to hear. Let me know how it goes with Citrix. That’s my next task also.
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…
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.
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.
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.
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.
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.
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!
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.
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
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.
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.
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
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!
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 !
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
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.
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.
Same here. I am packaging in Wise today and will try this Monday or Tuesday. Thanks for the insight sir!
Well, this fix still works after letting it sit over the weekend. Messy – but seems to do the trick
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
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!!!
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!
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!
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
Awesome. I am hoping we finally have this figured out?!?
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
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?
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?
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.
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
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.
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?
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….
Thanks for the comments!
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…
In my virtual environment (Citrix XenDesktop) I didn’t want edit my vDisk just for the Fu#@!&&@?!!!!§! java…
It’s a tips not a solution! Luckily java is dying
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?
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.
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.
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.
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
Thank you, I forgot about that! Adding this to the main post.
Tried installing with the config files, the users that logs on however still have Auto Update enabled.
The auto update in the Java control panel or the “your version of Java is insecure” message?
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?
Sure – send me a note at bretthexum at yahoo dot com
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
Did you get it to stick? I tried that but after a few minutes/sometimes hours it came back.
Then try putting the value to deployment.expired.version=99.99.99
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.
Also is there a way to suppress Updates through the HKCU registry?
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.
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.
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
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?
yes, because of a file system limitation it is not possible to have a folder and a file with the same name.
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…
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
It still prompts me for the update when someone opens a IE browser to a site using java applets.
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!!!
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.
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?
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
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.
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 ?
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.
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.
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.
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.
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)
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?
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.
I’ve wondered about digging into that but don’t have the skillset. Good work!
Why not creating folders named “baseline.versions” and “baseline.timestamp”? This should suppress the recreation of the files.
Creating folders for those 2 files in a GPO does not work for all users.
Does it fail, if those files already exist? Folder creation will fail, if the files are still there.
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
Disabling the NG plugin shows either no popup
nor the java applet in the internet explorer 
(checked on java.com)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Plug-in\10.21.2]
“UseNewJavaPlugin”=dword:00000000
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).
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.
I am also a bit annoyed that Oracle are LOCKING any threads which are getting created on their FORUMS regarding this issue.
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.
Same thing happened to me! That’s why I gave up with Oracle and tried to figure it out on my own.
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.
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?
Any workaround for firefox. I used the “UseNewJavaPlugin” hack there and it fixes the issue with IE but Firefox still prompts me.
Have not tried with Firefox at all myself.
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.
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
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.
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.
Love it! Now if we can just get Oracle to stop closing/deleting our threads on their forums….
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?
A few users called this am about getting the Your version of Java is insecure. This is frustrating for sure!
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.
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…
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.
Has anyone considered moving to the Windows IBM 1.7 JRE? The Nags are not an issue
Never even knew there was such a thing….
Yeah I checked it out, a direct download of he IBM JRE is not available due to licensing issues yada yada.
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.
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.
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.
done. was in the process of doing that right as you reminded me
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
Very nice. THANK YOU! Adding to main article
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
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
}