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.
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
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. **
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.
