/build/static/layout/Breadcrumb_cap_w.png

Java Runtime Environment Version 7.0 Update 40

Oracle has released "Java Platform, Standard Edition 7 Update 40" also know as 'Java Runtime Environment Version 7.0 Update 40'.

This update release contains several enhancements and changes including the following:

Oracle added a Deployment Rule Set to JRE to enable an enterprise to establish a whitelist of known applications.

The rule set is an XML file that must be named ruleset.xml. Use any text editor to create this file. The rule set defined in the ruleset.xml file must be packaged in a signed JAR file named DeploymentRuleSet.jar. The JAR file must be signed with a valid certificate from a trusted certificate authority. For information about creating and signing a JAR file, see the lesson Packaging Programs in JAR Files in the Java Tutorials.

Install the DeploymentRuleSet.jar file on your users' systems in the following directories:

    On Windows platforms, install the file in the <Windows-directory>\Sun\Java\Deployment directory, for example, c:\Windows\Sun\Java\Deployment.
    On Mac OS X and UNIX platforms, install the file in the /etc/.java/deployment directory.

To view the active rule set, see the Security section of Java Control Panel.

For more information, see Setting the Level of Security for the Java Client and Java Control Panel.

First of all download and run either jre-7u40-windows-i586.exe for Windows 7 / XP 32-bit or jre-7u40-windows-x64.exe for Windows 7 / XP 64-bit. If you use 32-bit and 64-bit browsers interchangeably, you will need to install both 32-bit and 64-bit Java in order to have the Java plug-in for both browsers. These offline installers are available in the Java SE Runtime Environment 7 Downloads section of Oracle's Java website.

When the License Agreement screen pops up, look in the "c:\Documents and Settings\<username>\Local Settings\Application Data\Sun\Java\jre1.7.0_40 directory" when you're using Windows XP or "C:\Users\<username>\AppData\LocalLow\Sun\Java\jre1.7.0_40\" when your're using Windows 7.

For the x64 version look in the "C:\Users\<username>\AppData\LocalLow\Sun\Java\jre1.7.0_40_x64\" directory. In that directory you will find the 'jre1.7.0_40.msi' and a Data1.cab file. The jre1.7.0_40 msi file is the one we can use to deploy "Java Runtime Environment Version 7.0 Update 40" by using MSI technology.

Don't forget Data1.cab because this is an uncompressed msi:



Start up the AdminStudio Tuner and create a response transform file. It's as simple as that if you want to do a default deployment. For an advanced deployment you can further tweak you J2RE configuration two ways:

  • by changing the 'Setup Properties'
  • by changing registry settings

The result is the same. You can change some basic 'Setup Properties' in the Tuner:

  • AUTOUPDATECHECK - Java Update mechanism - on {1} or off {0}
  • EULA - popup the EULA when you first start a Java applet - on {1} or off {0}
  • IEXPLORER - indicates that the Plug-in should be registered with the Internet Explorer browser - on {1} or off {0}
  • JAVAUPDATE - indicates that the Java Update feature should be disabled (the Update tab in the Java Plug-in Control Panel will not appear) - on {1} or off {0}

    However, it seems that using the property doesn't work anymore and that you have to set this registry key additionally:

    [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy]
    "EnableAutoUpdateCheck"=dword:00000000

  • MOZILLA - indicates that the Plug-in should be registered with Mozilla 1.1 and later browsers - on {1} or off {0}
  • WEB_JAVA - if used, disables any Java application from running in the browser. WEB_JAVA=1, the default, enables Java applications in the browser. This field is available as of the 7u10 release. For more information, see Setting the Security Level of the Java Client.
  • WEB_JAVA_SECURITY_LEVEL, if used, sets the security level of unsigned Java apps running in a browser. The possible values for this field are V (very high), H (high), M (medium, the default) or L (low). This field is available as of the 7u10 release. For more information, see Setting the Security Level of the Java Client.

... but you can also collect the JRE's registry settings to tweak the JRE a little more.

Launch the "Java Control Panel" (available in c:\Program Files\Java\jre7\bin\javacpl.exe). Most settings you will change by using this utility will then be stored in the registry in [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft]. Some examples:

  • Click on the "Update" tab. If you uncheck the "Check for Update Automatically" you will shutdown the Java Update mechanism. This may be wise, because we want to deploy newer versions by using ZENworks and not automatically by using the Java Update mechanism.

  • If you want to disable the 'Update' tab, then use this registry setting to enable (00000001) or disable it (00000000):

    [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy]
    "EnableJavaUpdate"=dword:00000000

  • Click on the "Advanced" tab. If you open up the "Miscellaneous" node by clicking on the + sign, you can uncheck "Place Java icon in system tray". Which just does what is says. Now it has become more difficult for users to fiddle around with the J2RE configuration. If you change this setting, this registry setting is changed:

    [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.7.0_40
    "HideSystemTrayIcon"=dword:00000001

 

Some settings however are stored somewhere else. Some examples:

  • Click on the "General" tab. Click on 'Network Settings'. The settings you configure here are stored in:

    C:\Documents and Settings\%USERNAME%\Application Data\Sun\Java\Deployment\deployment.properties.

    This 'deployment.properties' file is used for storing and retrieving deployment configuration properties in the Java Control Panel. They are also used for customizing runtime behavior for both Java Plug-in and Java Web Start. There is always a User-Level deployment.properties file. Its location, which is non-configurable, is described here. There may also be an (optional) System-Level deployment.properties file. If it exists, its location is determined by a System Administrator through the deployment.config file as described here.

Comments

  • Wow, I wonder if Oracle could have found a way to make this a little more hard to use? - bkelly 11 years ago
    • Amazing indeed ... - rovabu 11 years ago
      • I found their development methodology. http://dilbert.com/strips/comic/1996-02-23/ - Ben M 11 years ago
  • Does the MSI have a property I can edit to remove the start menu junk ? I'm using Orca and cant spot anything - accesser 11 years ago
  • Hello, not it has not. But you can add a Custom Action (1122) to your Transform file, where you run this command:

    cmd.exe /C rmdir "%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Java" /S

    ... and where in the InstallUIExecuteSequence table you set the Sequence ID of this Custom Action to '3183'. Which is between the InstallJava custom action (3181) which apparently create these shortcuts and InstallFinalize (3185).

    (Thanks to jaybee96 helping me out on this one) - rovabu 11 years ago
    • Learn something new everyday thanks - accesser 11 years ago
    • I can't seem to get this to work properly for the 64 bit version. Works great for x32. x64 keeps spitting out an internal error 2762.. But the custom action does work. weird.

      The CA is in Execute Immediate. I've tried with TYPE 98 and as you've suggested, 1122.

      InstallExecuteSequence is 3183, right between InstallJava (3181) and InstallFinalize (3185).

      Can anyone offer some advice? - Secondlaw 10 years ago
      • In Setup Commander's Java Runtime Configuration Wizard we use '1122' for the custom action which runs:

        cmd.exe /C rmdir "%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Java\" /S /Q

        The /Q switch was missing in the example above btw ... - rovabu 10 years ago
  • you're welcome ;-) - jaybee96 11 years ago
  • Thank you @rovabu. The command line was prompting a yes/no response. Adding /Q removes this and runs the command. - ComputerBlu3 11 years ago
  • This is nuts. So there is not a ton of information out there for those of us required to use smart cards. First, I got a token with a code signing certificate, but it only has that. I am able to sign the JAR, but when I test websites with the deploymentruleset.jar, I get "This application will be blocked in a future Java security update because the JAR file manifest does not contain the Permissions attribute. Please contact the Publisher for more information. " I then had to research how to update a manifest file from inside the jar, which still had no effect after then signing it again (after re-creating the jar from scratch). I am suspecting this has to do with how I'm signing the jar file. When I sign with the code-signing certificate on a smart card, I get "This jar contains entries whose certificate chain is not validated." How on God's earth are those of us with token-based code signing certificates supposed to sign it? I've been at this now for a few weeks off and on and this has been one of the most nightmarish scenarios I've ever encountered. When I go to sign it, I use "jarsigner -keystore NONE -storetype PKCS11 -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar alias" where alias here is the alias provided on my smart card. I was able to get the alias by using "keytool -keystore NONE -storetype PKCS11 -list -v". This only worked after I had to look all over the internet with how to read the smart card. Turns out, you need to update the java.security file, then create a cfg file somewhere that points to a dll. Then, that wasn't good enough because I have multiple smart card readers, and if I take out my personal smart card to put in a code signing certificate, bad things happen. So I needed to have a second card reader on my machine. So, I then had to add a line to the cfg file with "slot=1" so it would read the other card reader. I'm at my wits end. I'm able to digitally sign a jar file with a code signing certificate, but it seems like that's not good enough. I have a hardware token with the code signing certificate, so it's not like I can just add things to it. Does anyone have any tips to sign the jar file with a token-based code signing certificate to NOT get those errors? I'm assuming those errors are what are ultimately affecting my "whitelisting" function not to work properly. - NateFishPA 11 years ago
  • Thanks for the Tip...

    @rovabu and @jaybee96 - ekgcorp 5 years ago
This post is locked

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ