Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

How is everyone addressing the forced Java dialog "Java Update Needed - Your Java Version is insecure"

Created: 22 May 2013 | 73 comments
greg_zielinski's picture

I'm in investigating how to deal with this issue in our environment.  It’s preventing me from further rolling out Java to version 17.  Our apps aren’t certified for version 21 yet (nor do we want to be on the hook on updating Java within a month of each release)

Starting with Java 7 update 17, The Java runtime introduced a feature to consider itself old and out of date as of 05/16/2013. It is essentially a built in expiration.  So that means our users on version 17 have started to receive this prompt.  A prompt that doesn’t seem to have an easy or reliable way to suppress.

java update dialog.png

The minor problem, I’d simply like to suppress this dialog from ever being seen by the user.  So far this does not look possible without some trickery. The major problem is, if you select “Update” and don’t actually perform the update (you changed your mind or tried but lack of admin access prevented you from updating), then you get stuck in a loop.  What happens is each launch of a product that needs Java will launch you straight into the Oracle website for Java 7 update 21.  To the user, it appears as if Java is no longer installed. The Java app doesn’t run.  It just keeps popping up this Oracle update 21 website.

Luckily you can delete the following registry key (gives you a chance to re-answer the dialog) HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties\deployment.expiration.decision.10.17.2

Or take the value of that key and change it from “update” to “later”

There is a very good discussion going on in the comments of this blog post that I’ve been following. http://www.labareweb.com/java-1-7-auto-update-deployment-with-sccmmdt/

Reading threw the comments, my plan of attack will likely be as follows (if we elect to proceed with rolling out update 17 to everyone)

  • Delete entire registry key
    • HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties
  • Delete the file
    • %localappdata%Low\Sun\Java\Deployment\deployment.properties
  • Copy a new deployment.properties file containing these 3 lines
    • deployment.expiration.decision.timestamp.10.17.2=5/21/2013 14\:2\:51
    • deployment.expiration.decision.10.17.2=later
    • deployment.expiration.decision.suppression.10.17.2=true
  • Launch %programfiles(x86)\java\jre7\bin\ javacpl.exe (this populates the rest of the deployment.properties file
  • Kill Javacpl process
  • Finished

At this point, if you launch a Java app, the dialog will have already been suppressed and the option to ignore until the next update will be selected.  This will get me past ONE release of Java.  The problem is, as soon as the new baseline is set at the URL configured at

 deployment.baseline.url = https://javadl-esd-secure.oracle.com/update/baseline.version

we enter back into this scenario of the user being prompted (the supersession is no longer valid as a new update has been made available).  So I almost need to preempt this but knowing what the next set of registry values are going to be.  https://javadl-esd-secure.oracle.com/update/baseline.version is updated now to “1.7.0_21”.  Suppressing with the bulleted steps and values above works for now.  But when https://javadl-esd-secure.oracle.com/update/baseline.version goes up to 1.7.0_##, what values might I need to consider my expiration decision on version 17 to “stick”?

I wanted to discuss the dialog here to see if anyone is seeing this issue, or a warning to those moving into Java 7 update 17 or 21.  The trick listed above is just ugly to me.  Creating software delivery policies that perform these actions per user (our machines are shared).  Curious if I’m missing something easier or more reliable.  I’m also considering the AutoIT task mentioned in the blog I referenced that will essentially answer the dialog on behalf of the user.

Operating Systems:

Comments 73 CommentsJump to latest comment

HighTower's picture

Have you configured your package to never check for updates?  It seems like it's only getting the information that it's out of date when it checks in...

greg_zielinski's picture

Yes we have. This is independent of the java update process/program.  That is disabled on our machines and isn't the process that is invoking this dialog.  Via process explorer and process monitor, it's javaws.exe and javaw.exe that are checking for these values.  This is a built in update check for version 7 update 17 that "hard expires" on 5/16/2013.

You can actually see the date inside the deploy.jar in the builtinproperties.class file.

And the securitybaseline.class has the calls to check the oracle website and also the calls regarding this hardcoded expiration date inside builtinproperties.class

I'm pretty positive this is all generated by javaws.exe and java.exe initializing the Java Run Time environment.

TJan's picture

uncheck - enable next generation Java Plugin located in the Java Console under Advance.

java.JPG
greg_zielinski's picture

Didn't work. Tested as follows.

Found that the checkbox in your previous post was checked.  Unchecked it and closed all browsers.

·         Set system clock to May 15, 2013.

·         Visit http://javatester.org/version.html

·         Allow Java application to run

·         Java version test runs and confirms result “Java Version 1.7.0_17 from Oracle Corporation”

·         close browser

·         Advance system clock to May 16, 2013

·         visit http://javatester.org/version.html

·         Allow Java application to run

·         Receive annoying “your java version is insecure” dialog

andykn101's picture

What if your proxy or hosts file blackholes javadl-esd-secure.oracle.com?

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

greg_zielinski's picture

We are thinking about that but from what I'm reading, that will only help with the portion of the prompt "Do not ask again until the next update is available.".  So if we block the ability to check, Java will never know a newer version is available via the URL.  It will still however pormpt after the hard coded 5/16/2013 date. (And since we are deploying after 5/16/13, I need to populate the "later" and "never check" setings)

If blackholing the Oracle site works, I still have to do the listed steps to supress the prompt that is triggered by the 5/16 date.  I just know (or would hope) that Java not knowing a never version is available, it'll respect the checkbox "Do not ask again until the next update is available." indefinantly.

Or, at least until it is reset to 7/18/13 for Update 21 -http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html "The expiration date for JRE 7u21 is 07/18/2013."

TJan's picture

interesting...works on my test vm.  I can go to multiple java sites and not get the message.  When I turn it back on, I instantly get the message.  I'm doing it on a svs java 1.7u17 that I just made.

greg_zielinski's picture

Thank you for the follow-up.  Unfortunantly that won't be an option for us.

jasonfo's picture

Unfortunately I'm finding nothing but disappointment with Oracles way of thinking. For someone who releases a new version about every couple of weeks they never think about the corporate world.  In the corporate world we have more sophisticated equipment to deal with vulnerabilities and users who generally don't have administrative access to install updates. 

I found this site (below) that had some great work done to get around the Java Insecurity expiration date but it appears to be broken again. If i'm reading right (day 2 of reading sites about why Java stinks) 1.6 update 45 or maybe Java 7 update 11 are the latest (don't take my word for it) that do not use this insecurity issue.

Also I've not found a way to suppress the prompt asking the user if they want to run the java applet. I've found that I can suppress the new addons prompt for IE but not this.

So for now I'm sticking with Java 1.6 update 31 which I know in working. It may not be as secure as Java 7 update 21 but hey, is that one really secure anyways?

Interesting read....

http://www.labareweb.com/java-1-7-auto-update-deployment-with-sccmmdt/

Donald Smith - Oracle's picture

Hi, I'm in the Java SE PM team and just wanted to follow up to this thread.

As recently noted here:

https://blogs.oracle.com/security/entry/maintaining_the_security_worthiness_of

we do intent to provide features and flexility as has been noted in some of the comments.  Do note that some of the security measures we've recently implemented were interim measures until we were able to deliver the additional configuration tools and options needed.  Note the section on "Local Security Policy" in the above link.  These features will be available over the next couple updates.  I won't be able to answer specific follow up questions here, but feel free to ping me on twitter @donaldojdk and I'll do the best I can.

 - Don

Sally5432's picture

Java management through policy, am I dreaming?  Thanks for posting.  Hope it comes true.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

greg_zielinski's picture

Thank you.  I see you signed up for Connect just to make this post and wanted to let you know it is very much appreciated.

superfuzz's picture

Hi Greg,

Just wondering if you found a solution to this?  We updated to 7.21 recently and have just hit the expiry date so are suddenly getting this prompt.  Our users are understandably wary of unfamiliar dialog boxes, so it's generating a lot of helpdesk incidents.  From reading this post and its replies, I'm planning to try forcing out a modified deployment.properties file with a group policy preference, then blacklisting https://javadl-esd-secure.oracle.com/update/baseline.version in our corporate firewall.  Do you think this would result in the desired behaviour (ie no prompts)?  

Thanks,

Rob

greg_zielinski's picture

I haven't been able to test it but we've had success in "prepopulating" the environment so the answer "later" and the checkbox for "do not ask again until the next update is available" is already done.  That way they don't get the prompt.  The specific part that alarms us from putting it into production is not knowing the exact behavior of "do not ask again until the next update is available".  I would think blacklisting the link you list above would be all that is needed.  Unfortunantly, we need to make abosultly sure that blacklisting the site would effectively cause the scenario "next update is available" to never occur.

burndtjammer's picture

How exactly did you do this?

Im thinking a bat script to reg add the key in to the registry for HKCU.

I would then create a policy in Software Management to run the script.  It would run as the currently logged on user and and the schedule would be when a user logs on. 

What was your method?  This seems like it may be the only way to stop oracle from eating up so much of our time.

Sally5432's picture

Donald,

Any hope of seeing security policy/enterprise mgmt of java anytime soon?

Thanks!

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

kharmon@cocc.edu's picture

Here is how we handle Java - We eliminate the autoupdate sub system. Even if it launches an update it won't do it.

To install Java without the updater, download the offline installer, execute the .exe and cancel the install. You can then find the extracted files in %APPDATA%\admin-user-used-to-install\LocalLow\Sun\Java\ and copy them to your network location or local drive. Finally run the installer with the following switches:

msiexec /i “\\server-name\share-name\JRE_FILENAME” 

The autodownload option will be on, but it won't matter because the subsystem that does the download and updates Java won't have been installed.

Other registry keys that can be included if the updater needs to be installed:

Modify the registry key [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy]

"EnableAutoUpdateCheck"=dword:00000000

"EnableJavaUpdate"=dword:00000000

Example:

 \\Sharename\Products\Current\Java\jre7u21 Win32 NoUpdates

Inst_JRE7u21.cmd

msiexec.exe /i "\\sharename\Products\Current\Java\jre7u21 Win32 NoUpdates\jre1.7.0_21.msi"

greg_zielinski's picture

Thank you Kharmon.  That is a tip worth sharing but I do also want folks to be aware that the internal expiration is a function within the Java Run Time environment.  If you exctract the .jar file you can actually see it in the code to check for this hardcoded expiration date.  Disabling the automatic update engine won't prevent this particular problem.

burndtjammer's picture

Previously, I would deploy the executable as part of a bat script and in that same script I would modify the registry to turn off the autoupdate features.

With Java 7u25 I am deploying as an MSI with an MST.  In orca I modified the Property Table as follows

ARPURLUPDATEINFO:  url for internal Altiris Software Portal

AUTOUPDATECHECK 0

IEXPLORER 1

JAVAUPDATE 0

JU 0

MOZILLA 1

REBOOTYESNO NO

As you mention, its not these keys that effect the update nagger we are all experiencing.  I am hoping by changing the update info url it will atleast keep the update button from sending users to java.com.

Honestly, I think the only way of truly stopping this, as you said, is to deploy a modified deployment.properties file along with the install which just creates more work for administrators. 

Until oracle gives us some real control over java, I think we are stuck with this ticking time bomb.  Also, if there were a way to stop the plugin from checking if theres a newer version of Java available everytime it loads, java 7 would load a hell of a lot faster.  

mdent's picture

We have just run into this very issue in one of our labs and it has been a pain. First of all, let me say that I do not know much about java, other than it's a pain in the nether regions. So reading this and other discussions has meant a rather steep learning curve for me. I've been doing some serious head scratching.

This is our environment:

Windows 7 64 image, running java 1.7.0_15 and runtime 1.5.0_06. I have downgraded from java 7 upd 21 and I am still getting the error! The program(s) triggering this mess are ESL type programs (Longman English Interactive 1 thru 4, etc).

I thought that 1.7 upd 15 was not supposed to have that issue. Is it caused by the runtime?

What's made it really tough as well is that if during testing the error comes up, if I either close the program from task manager or by closing the window (using the "x" and not picking any of the options), it will not come back next time I start the program, even though the error is still there.

Anyways, this is happening in a 50 pc lab. The lab is frozen (Deepfreeze), so thawing it and either doing the update or "ignoring" till next update is really not an option. We'd just have to do it again at next update interval.

Can anyone help?

resendesw's picture

mdent-

We had in issue with the Longman English Interactive as well.  We had to go into the Java Control Panel-> Advance and make a change.  If memory serves it had to do with the Mixed code option. But I will try to confirm with one of our lab techs.  If that doesnt work look thru those options.

Hope this helps

mdent's picture

I have changed that setting already to "Enable - hide warning and run with protections" Or should I totally disable verification?

mdent's picture

I have read that Oracle has a patch for this. It's patch # 16758419. Problem is, you have to have paid support to get it. Which doesn't make sense as it is a patch for a free product! Huh? Does anyone know how to get it?

greg_zielinski's picture

I'm not aware of any other way.  I can say we are in the process of signing up for this paid support and hope to have our hands on the fix soon.

No other workaround that we can count on has been found. Everything else relates to registry edits that include timestamps and is just too high risk for our environment.

mdent's picture

Sorry, more info. Just found something out. On one of our other images we have java 7 upd 17 and the Java SE Dev. kit 7 upd 17. By all accounts these should cause a problem but they don't seem to.

On the problem image I downgraded to Java 7 upd 15 and Jave SE Dev kit 7 upd 15 but the error still appears. The difference is, on this image I also have the J2SE Runtime Environment 5.0 update 6 so, it seems to be the runtime env. that is causing this.

Any thoughts?

Sally5432's picture

FYI here's some details on the enterprise mgmt tools going to be available with Java 7 Update 40.

Deployment rule set (white list known good java apps) and ability to disable JRE out of date warning are coming

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

It looks like this release is scheduled for mid Sept.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Sally5432's picture

Java 7u40 released
http://www.java.com/en/download/manual.jsp

example ruleset here:
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+orana+(OraNA)

Post here by tecrumors a little bit down the page seems helpful for packaging Java for those who need help -http://www.itninja.com/software/oracle/java-2/7-552

His post is for a prior version, but this version I think would be similar except add a line to deployment properties file: deployment.expiration.check.enabled=false & add a rulset xml file if you want to.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Shasha2013's picture

Hi , Does anyone know if the patch refer by mdent's comment (on Aug 01) exists? "It's patch # 16758419"

I have been looking for a link or just information from Oracle, so I can go to management an explain the case for getting paid support.

Thank you

Donald Smith - Oracle's picture

Hi, I'm in the Java SE PM team, and I replied earlier on this thread about the Deployment Ruleset feature helping here.  That may have been a bit of a red herring, see the section "Option to disable the "JRE out of date" warning" here -- http://www.oracle.com/technetwork/java/javase/7u40...

I believe between DRS and this configuration, IT teams should be able to configure most scenarios.

 - Don

burndtjammer's picture

Don,

 Your URL leads to an error page 404.  Do you have an updated path or did it get pulled all together?

andykn101's picture

Works for me in the UK.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Sally5432's picture

Not working for me either, US

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

andykn101's picture

For those of you who can't see it, the bit we're interested in is:

"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  

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Nicolas Horchower's picture

Hello,

We've runned this script in an Altiris Task and it looks to overcome the issue + the today obsolete 7 u40:

@echo off

rem We first check if a deployment.properties has been setup
set dplProp="%windir%\Sun\Java\Deployment\deployment.properties"
find "deployment.expiration.check.enabled" %dplProp%
if %ERRORLEVEL% == 0 goto :end

rem Then we check if deployment.config has already been setup
set dplConfig="%windir%\Sun\Java\Deployment\deployment.config"
find "deployment.system.config" %dplConfig%
if %ERRORLEVEL% == 0 goto :end

rem We create the folders
if not exist %windir%\Sun\*.* md "%windir%\Sun"
if not exist %windir%\Sun\Java\*.* md "%windir%\Sun\Java"
if not exist %windir%\Sun\Java\Deployment\*.* md "%windir%\Sun\Java\Deployment"

rem we add the settings
echo deployment.javaws.autodownload=NEVER >>%dplProp%
echo deployment.javaws.autodownload.locked >>%dplProp%
echo deployment.expiration.check.enabled=FALSE >>%dplProp%

echo deployment.system.config = file:\\%windir%\\Sun\\Java\\Deployment\\deployment.properties >>%dplConfig%
echo deployment.system.config.mandatory = true >>%dplConfig%

:end

--
NH

allenflame's picture

I still get the "Application Blocked by Security Settings" after running this.

Nicolas Horchower's picture

can you pm me a screen shot ?

have you restart your PC before doing the test ?

On my side, I've made the test with this URL :
http://www.java.com/verify/

without, you've got the pop-up with the 3 options, with it, you've got nothing (the applet is runned).

--
NH

zeiskind's picture

Can anyone help a non-tech end-user stop popups asking if Oracle can install java update on my computer.

Something simple please.

Thank you,

burndtjammer's picture

Do you have administrative rights to your system or part of an organization that wisely limits a users abilities? Users break things...

If you're just an individual, whats keeping you from upgrading?

Also, if it were simple this thread wouldnt be 40+ replies long. 

zeiskind's picture

No organization involved.

I am a loan user on home computer. Every day, I get a request to update Java-sent by Oracle. Every day, I let Oracle do its thing on my computer but next day, same message pops up.

I am not getting any more complicated messages about security or change in Java version. Should take a few sentences to tell me how to block Java updates. I get the registry part but don't know what file is aluded to in

"

  • Delete the file
    • %localappdata%Low\Sun\Java\Deployment\deployment.properties
  • Copy a new deployment.properties file containing these 3 lines
    • deployment.expiration.decision.timestamp.10.17.2=5/21/2013 14\:2\:51etc"

Do not even know which of my applications uses Java or Oracle -probably web browser.

And yes, I have admin privileges.

Thank you for your rapd reply.

burndtjammer's picture

Here's the deal, we know how to fix it after it starts, although that may be manual or done by enumerating user profiles and editing files in the user registry or appdata.

Here's what can be done to head this off with your next admin install.

1- Decide if you will be loading as an MSI or as an EXE.  Follow Oracles documentation for extracting the MSI.  I prefer the MSI and creating a custom transform using orca and applying the following settings.

how to extract the msi http://www.java.com/en/download/help/msi_install.xml

Orca KB http://support.microsoft.com/kb/255905

  If you go with the exe you will have to include reg hacks in your install script.

settings for transform at minimum:

AUTOUPDATECHECK 0

IEXPLORER 1

JAVAUPDATE 0

JU 0

MOZILLA 1

REBOOTYESNO NO

2- Place your install files in to an empty folder  (msi + cab for msi install, exe for exe install)

3-Create the following files in that folder:  deployment.config & deployment.properties  These files can be edited in your text editor of choice.

deployment.config should contain at the very least:

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

deployment.properties should contain at the very least:

deployment.expiration.check.enabled = false
deployment.expiration.decision.suppression = TRUE
deployment.javaws.autodownload = NEVER
deployment.javaws.autodownload.locked

Follow http://docs.oracle.com/javase/7/docs/technotes/gui... if you want to add anything else.

4-Create your install script (bat, vbs, etc..) It should do the following:

   - kill your java process, internet explorer, firefox, chrome, safari, etc...

   - Install java with proper commands and arguments.

    -copy / xcopy the two deployment files to c:\windows\sun\java\deployment with proper arguments.

Test your install.  Ensure it installs java and users can still access the applications they need to access.

Create or edit a software resource in your software catalog. http://www.symantec.com/business/support/index?pag...

See section II.  you want to upload the contents of your java install folder as the package and set the install script as your installation file.  it should display in bold.  Let SMF generate command line for you.  This is also a good time to create your inventory rules for detection and apllicability (you need these for a managed software delivery, custom inventory policys and installed software filters)

Create a software delivery task and test delivering of the package. 

Once you have completed testing you can create your software inventory policy, software filter & use them when creating a Managed Software Delivery Policy. Roll out as necessary.

Key note: If your users do things you dont like, you may not want to put this in the software portal for anyone to download without approval. The software portal requests do not apply detection rules when running.  If java is installed and you go to install it again, i've noticed java stops working and you have to uninstall, reboot & reinstall.

Sally5432's picture

I created an article walking through step by step how to create a customized Java package.  I'm not sure Step 8 is necessary... but hope it helps someone else new to customizing msi's.  Any pros here that see something obvious I did wrong, let me know & I can update the article.

https://www-secure.symantec.com/connect/articles/updating-java-through-managed-software-delivery-policy

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

JJV's picture

Some great info, but Im not able to get this to work...So I have a few questions.

If Java is already installed, will placing the config and property files work, or do they need to be laid down during installation.

Syntax...

Oracle says to use this to point to the cofig file  file:///C:/Windows/Sun/Java/Deployment/deployment.properties.

I see people here using 

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

WHen setting the variables, what is the spacing around the = sign

example

deployment.expiration.check.enabled=false

or

deployment.expiration.check.enabled = false

Sally5432's picture

@JJV - check my article here... it has the exact formatting that works for us.  I had issues using the format Oracle says too - go figure.

https://www-secure.symantec.com/connect/articles/u...

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Inconspicuous's picture

JJV: What version are you having trouble with? deployment.expiration.check.enabled worked correctly for us with Update 40 when U45 was released, but now that Update 51 is out we are finding that Update 45 apparently does not respect the setting.

I have verified with Process Monitor that the properties file is being read and that Java is seeing the deployment.expiration.check.enabled=false settings (it even copies it to the registry and explicitly reads that value again later), but users are still getting prompted to upgrade.

Again, the exact same setup worked with Update 40 but as far as I can tell is being completely ignored by Update 45. We have a long-running sev 1 ticket open with Oracle support about all the Java issues affecting our EBS environment; I'm reporting the issue there and we'll see if they have anything to say about it.

mike_plichta's picture

We are finally happy with 7u51 after buying a code signing certificate. We are no longer plagued by pop-ups, version checks, or slow load times. This is not a free solution as I was unable to figure out how to do this with self-signed certificates as opposed to a purchased one.

1. Make a Deployment.properties files

#Set security level to it's minimum "MEDIUM" to allow for apps to run on outdated java versions
deployment.security.level=MEDIUM

#disables certificate checking so that java apps load much faster.  Java still checks the certificate
#blacklist though which we feel is good enough.  This certificate check happens every page load.
deployment.security.validation.ocsp=false

#disables the pop up when Java becomes more than two versions out of date
deployment.expiration.check.enabled=false

#disables the auto updater
deployment.javaws.autodownload=NEVER

2. Buy a code signing certificate from digicert who has excellent documentation and is one of the less expensive resellers.

3. Make a ruleset.xml and put it in DeploymentRuleSet.jar (instructions at digicert). This will allow you to white list sites.

4. Sign the jar file

5. Follow Sally's Guide for deployment to disable updates and deploy the two files. Both of them go in c:\windows\sun\java\deployment.

Sally's deployment guide https://www-secure.symantec.com/connect/articles/updating-java-through-managed-software-delivery-policy-updated-article

Ruleset creation guide https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets

Code Signing Request tool from Digicert (put in your domain name in the common name and it will fill in the rest as well as generate the command line code you need for the java keytool https://www.digicert.com/easy-csr/keytool.htm

Code Siging Guide from Digicert https://www.digicert.com/code-signing/java-code-signing-guide.htm

D-M's picture

Hi

Just been testing this on version 7 update 51.

Have seen numerous posts about applying the supression to:

- Appdata

- Registry

- C:\Windows\Sun\Java\Deployment

Some articles suggest you do the lot, but i have found that doing just one works.

For example, if you put Deployment.properties into C:\Windows\Sun\Java\Deployment along with Deployment.config, and have the config file point to this properties file, seems to work ok. Of course you need to have the suppression setting in the properties file.

When Java is next started, it updates the registry keys anyway with the supression setting.

Just wondering if others with version 7 update 51 have tried this method successfully?

Thanks, DM.

Nicolas Horchower's picture

Hello D-M,

We've deployed the little script that I've posted a few weeks ago.

It creates the files, and push the settings.

Works perfectly, no more pop-up

Regards,

--
NH

Sally5432's picture

This is what we do

https://www-secure.symantec.com/connect/articles/u...

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

cnx_steve's picture

We have found creating and deploying the two deployment.* files is all that is needed on all of our systems (>10,000).

Sally5432's picture

FYI java release 1.7u55 is out

http://www.oracle.com/technetwork/java/javase/7u55...

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

romr's picture

Deployed JRE 1.7 Update 17

I got rid of the first Prompt via Current User Reg:

[HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties]
"deployment.expiration.decision.10.45.2"="later"
"deployment.expiration.decision.suppression.10.45.2"="true"

and also using amending deployment file:

C:\Windows\Sun\Java\Deployment\deployment.properties

deployment.javaws.autodownload=NEVER
deployment.javaws.autodownload.locked
deployment.security.locked
deployment.expiration.check.enabled=false
deployment.expiration.decision.suppression=TRUE
deployment.expiration.decision.10.17.2=later
deployment.expiration.decision=NEVER
deployment.insecure.jres=ALWAYS
deployment.expiration.decision.timestamp.10.17.2=4/24/2014 10:58:17
deployment.version=7.0
deployment.modified.timestamp=1398336515166
deployment.expired.version=10.17.2
deployment.expiration.decision.suppression.10.17.2=true
deployment.expiration.check.enabled=false

The second prompt that was very fiddly eventually found a file which was being created in location below and deployed this to user via MSI activesetup.

C:\Users\%Username%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\29\598ac1dd-6.0.lap

What a disarray!!!!

D-M's picture

I think i have sorted out the expired version issue.

My next issue is the Security Warning pop up that happens with "Do you want to run this application?", when you get to a Java enabled website.

Is there any way to supress this pop up?

Thanks, DM.

burndtjammer's picture

Yes, lowering the security level lower "works" but it is less than ideal and can open you up to a wider range of vulnerabilities.
 

D-M's picture

Hi

Any other way apart from setting the security to medium?

I have looked at various deployment.properties settings, but cant seem to find one that works with HIGH security settings.

DM.

Sally5432's picture

FYI latest java set to expire today but no word yet on new version, coming soon I guess

https://www.java.com/en/download/faq/release_chang...

"The expiration date for 7u60 is July 15, 2014. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 7u60) on August 15, 2014. After either condition is met (new release becoming available or expiration date reached), Java will provide additional warnings and reminders to users to update to the newer version."

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Scott W. Allen's picture

This Critical Patch Update Pre-Release Announcement provides advance information about the Oracle Critical Patch Update for July 2014, which will be released on Tuesday, July 15, 2014.  http://www.oracle.com/technetwork/topics/security/...

D-M's picture

Wonder when version 8 is going to be released.

Im having an issue with version 7, where it causes adhoc delays in loading the Java applets. Sometimes it can take minutes to load a simple java applet. Looking at debug, it is trying to talk to the Domain Controller for some reason. I have trialled the dev version 8, and this doesn't have the slow load issue.

DM

burndtjammer's picture

I was having issues on my workstations loading the java applets built in to altiris until i upgraded to 7u65 and added my NS to our custom excepted sites list.  You may need to look at configuring your excepted sites.

Sally5432's picture

Here's some release notes

https://www.java.com/en/download/faq/release_chang...

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Sally5432's picture

Java 7 update 67 expires today.  I don't see a new Java 7 version available yet, but probably will be posted by tomorrow.

Has anyone played with the Java 8 "Advanced Management Console" ?  Looks a little complicated, but does add some management/security options.

http://www.oracle.com/technetwork/java/javaseprodu...

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Sally5432's picture

kind of? Java 7 is supported until April 2015 http://java.com/en/download/manual_java7.jsp

Here's the download for 7u71  http://java.com/en/download/manual_java7.jsp

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

burndtjammer's picture

Agreed, that was a bit exaggerated.  Just remember, if you/we haven't being paying attention (and I know you have based on your posts) over the last 12 months and dont stay on top of future changes Oracle makes to Java your systems may upgrade to Java 8 before you are ready.  Also, keep in mind that once public support ends I would be wise to assume that Symantec will stop importing it through Patch Management.

Packager's picture

All,

I'd raised a support ticket with Oracle, and after much kicking of them they provided a link to a known issue on their support database (with a working solution - happy days!):

Applies to:

Java SE JDK and JRE - Version 7 and later
Generic Windows
Affects Java 1.7.0_40 (where this feature was introduced) or newer.
 

Symptoms

Even with the deployment.expiration.check.enabled=false property set in the system level deployment properties file, an end user still might see a pop-up declaring "Your Java version is insecure"

Cause

This happens because Java checks if the Java Runtime Environment is below security baseline before synchronizing the contents of the deployment.properties file with the corresponding Windows registry keys.  The second time the check is performed, the registry keys match the file and then it works.

Solution

Java engineering is working to correct this issue. Until a fix is available, the work around is to both add the appropriate properties to the system level deployment properties file and to set the corresponding values in the Windows registry.  There are three ways you can do this.  First, ensure that your deployment properties file includes the following properties:

deployment.expiration.check.enabled=false
deployment.expiration.check.enabled.locked
 
To set the corresponding Windows registry entries, please perform one of the following actions.  All of the actions listed are done at a command prompt.
 

     (1)  Add a system level environment variable [Recommended]

           on Windows 7:

               setx deployment.expiration.check.enabled false /m

           on Windows XP:

               Start the System control Panel, select the "Advanced" tab, then click on the "Environment Variables" button.
               The "Environment Variables" window will open.  Click on the "New" button, below the "System variables" pane.
               The "New System Variable" window will open.
               In the "Variable name:" field, enter  deployment.expiration.check.enabled
               In the "Variable value:" enter false
               Click "Ok" on the "New System Variable" to close it.
               Click "Ok" on the "Environment Variables" to close it
               Click "Ok" on the System control panel to close it.

     (2)  Use the Java WebStart command line utility to set the property.

               javaws -userConfig deployment.expiration.check.enabled false

     (3)  Edit the Windows registry directly.

               reg add HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties /v deployment.expiration.check.enabled /t REG_SZ /d "false"
Please note that Oracle does not recommend directly editing the Windows registry.  Oracle is not liable for any damage done should you choose to take this course of action.  If you decide on this course of action, please ensure that you back your registry up before editing it.

The first of the above actions is the one recommended by Oracle Support.  The other two options, while viable, have the disadvantage of only setting the property for the user who issues the command and not for the entire system.

mdent's picture

I have tried the above solution (adding the two lines to the deployment.properties file and setting the environment variable with the setx command from #1 above. It does seem to get rid of the "you need to update" nag, but I still get the securiy warning "Do you want to run this appliation?" Is there any way to get rid of that?

Packager's picture

Mdent,

You could try adding the site into the trusted sites.

Or potentially modify the deployment.properties to have these

# Mixed code (sandbox vs. trusted) security verification
deployment.security.mixcode=disable

deployment.security.mixcode.locked
 

The above level can be checked via the control panel, Advanced, Security, MixedCode if you want slightly tighter control.

A good website/file with descriptions of lots of settings can be found here

https://gist.github.com/MyITGuy/9628895

Matt