Java Runtime Environment 7 Update 40 released. Update warning can now be disabled!

[Arthur]

Click here for details or see the quoted text below.

 

Java SE 7 Update 40 (expires 10th December 2013)

Download (Windows: 32-bit, 64-bit / OS X: 64-bit) / Release Notes

 

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

 

http://i.imgur.com/ed63Nxc.jpg

Edited September 10, 2013 by Arthur

[AngryTechnician]

It seems that the newest irritation for Java is that as of update 40 it dumps a load of shortcuts on the Start Menu:

 

 

Because the .msi is a wrapper and not a true .msi, there's no Shortcuts table to remove lines from. I also can't see anything in the Property table to set that might suppress them. Does anyone know a way to install 7u40 without these or do I have to resort to deleting them using GPP after the install?

[gerardsweeney]

A complete and utter fudge might be to do it the way I do our software deploys - have a compiled AU3 script run the MSI/whatever, and then do tidying up of shortcuts.

Yep, it's a pockle, but if it works...

[Arthur]

Because the .msi is a wrapper and not a true .msi, there's no Shortcuts table to remove lines from.

This is one of the most infuriating things about the installer. I am almost tempted to create my own MSI.

 

Does anyone know a way to install 7u40 without these

I have created a .vbs custom action to delete the shortcut folder during installation. MST attached. You can use this in combination with your existing transform file if you want, since it only contains the bits required to delete the folder. e.g.

 

msiexec /i jre1.7.0_40.msi TRANSFORMS="jre1.7.0_40.mst;[color="#FF0000"]DeleteStartMenuFolder.mst[/color]" /qb!

DeleteStartMenuFolder.mst

[martinkasabov]

Hi there!

Where is that "deployment properties" file?

I have looked all inside the cab file that is extracted along with the MSI when the offline EXE installer is run...

I could not find the file name mentioned in your posting.

[martinkasabov]

Hi there!

Here is what I have done and it works like a charm:

 

You first need to create a vbscript file with the following content:

-------------------------------------------------------------------

dim strProgramData, strJavaPath

 

 

set wshShell = CreateObject("WScript.shell")

set scrFilesystem = CreateObject("Scripting.FileSystemObject")

 

 

strProgramData = wshShell.ExpandEnvironmentStrings("%ProgramData%")

strJavaPath = strProgramData & "\Microsoft\Windows\Start Menu\Programs\Java"

 

 

if scrFileSystem.FolderExists(strJavaPath) then

scrFileSystem.DeleteFolder(strJavaPath)

end if

---------------------------------------------------

I have named it "DelStartMenuDir.vbs" - ir can be any name, just need to know it and its location.

 

[Edit the MSI w/ InstEd It! or Orca:]

 

 

1. Go to "Binary" table, add row: give and for Data [binary Data]:

... Browse to the "DelStartMenuDir.vbs" File > OK

(The script will now be embedded into the MSI)

(No need to provide it w/ the installer when deployed)

 

 

2. Go to "CustomAction" Table > Add a row:

- Action > Give it a

[AngryTechnician]

The similar solutions from @Arthur and @martinkasabov are both very interesting. I've never dabbled in creating my own custom actions before and wasn't aware they could be as simple as calling a VBS. Will definitely think about using that trick again in future. Edited October 4, 2013 by AngryTechnician

[Arthur]

Save your MSI and run it. No need to provide .MST

It's probably worth mentioning that modifying a vendor supplied MSI directly (without creating a transform) is considered bad practice and should only be done as a last resort.

[martinkasabov]

Good and valid point, Arthur.

Then I believe your approach would be best fit regarding best practices.

I am not trying to steal ideas or any of that. I realize your solution (using MST and custom action with vbscript) is basically what I did apply in my case, and it was thanks to your posting. In my posting I just wanted to share the detailed steps to take to make this happened.

 

So at the end - to correct the process I described, instead of saving these changes directly to the MSI:

 

[Edit the MSI w/ InstEd It! or Orca:]

 

*Create New Transform

(From the Menu > This will create an MST File - provide name and THE location where the original MSI is)

 

*Start making the changes listed as before;

 

-----------------------------

 

*At the end save THIS file (mst) and exit.

 

Then when deploying just add the TRANSFORMS="" at the command options for msiexec...

 

 

Arthur, thank you for pointing that out!

[Arthur]

In my posting I just wanted to share the detailed steps to take to make this happened.

No worries. It's good to have the steps documented - thanks for posting them. I even learnt something new too (the bit about using -1).

[martinkasabov]

Yes, that was challenge indeed. I tried several different values (as recommended straight from Microsoft, regarding InstallExecuteSequence Table in MSI Files)

Suggested InstallExecuteSequence (Windows)

... but this specific JAVA Installer did not like any of them.

 

So at the end I used another reference that explains pretty good the usage of negative values:

InstallExecuteSequence Table (Windows)

 

On another note - I did ask you about the:

 

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

 

 

from your original posting here...

Where exactly is this file where we can add this property?

[Gatt]

Update 40! Bleedin heck!

What happened to 26 thru 39?!

[Arthur]

Where exactly is this file where we can add this property?

The deployment.properties file needs to be placed in the folder listed below along with another file named deployment.config. I have attached a copy of the files I use so you can see what they should contain. Feel free to customize the 'deployment.properties' file to suit your environment though.

 

%SystemRoot%\Sun\Java\Deployment

jre1.7.0_40_deployment_files.zip

[Arthur]

What happened to 26 thru 39?!

Oracle have switched to a new naming convention.

 

• Limited Update releases will be numbered in multiples of 20.
  
• We intend for Critical Patch Updates to continue to use odd numbers. The numbers will be calculated by adding multiples of five to the prior Limited Update and when needed adding one to keep the resulting number odd.
  

This is best illustrated with an example:

 

The next Limited Update for JDK 7 will be numbered 7u40, and the next 3 CPUs after that will be numbered 7u45, 7u51, and 7u55. The next release will be a Limited Update 7u60, followed by CPUs 7u65, 7u71, and 7u75.

 

This numbering scheme will leave several numbers between releases which will allow us to insert releases – for example security alerts or support releases, should that become necessary - without having to renumber later releases.

[martinkasabov]

Thank you, Arthur!

I was able to successfully deploy these files and everything works great. I utilized most of the settings you have in the properties file provided.

The only confusing thing was the "deployment.properties" generated in the user profile when java installation is verified (via web browser, visiting java.com), or when java.cpl is opened. That file contains different config that the one in %SystemRoot%\Sun\Java\Deployment, which I am not sure why and what affect it has. But I confirmed that the system-wide settings deployed take over and enforce that configuration. All good.

[Edu-IT]

So are you using an MSI to push those two files out too?

[martinkasabov]

No, I actually use the same vbscript that I embed in the MST - along with its main purpose to remove the JAVA start menu folder, I did add few lines that call a batch file from a network share (on our deployment server), using the xcopy command to dump the whole Directory Sun (with subdirs Java, Deployment, and the files there) in Windows Folder. The batch file has a IF statement, so if the Sun directory already exists, it will just exit without any actions; otherwise it will deliver that content.

 

I figured the MST can be handy for pushing future JAVA updates, as BOTH actions in the embedded vbscript (Remove Start Menu Dir and Deploy system-wide config) are conditional, and if there is no need to apply them, they will be skipped...

[Gongalong]

Anyone having any luck with 7u45? I've accessed the MSI using the instructions in Ivan's blog, but neither Orca or InstEd will seem to open it (aside from whether to use a transform or edit directly). The MSI seems much larger than previous versions, unless I've cocked something up How to package and deploy Java JRE 1.6.0_26 via Group Policy | ivan's blog

[Gatt]

Oh for crying out loud! Only just got 7u40 deployed!!!

 

*mutter mutter grumble grumble*

[Gongalong]

I haven't got around to an update since 7u25. Mind you that was probably only a couple of weeks ago (or June, possibly).

[JHLEHS]

syswow64 blog: Java 7 update 45 Enterprise deployment

 

This is a very useful read if you want to turn off updates and do a whole lot more.

[goran13]

This script does not work properly on Windows XP. Here is alternative:

 

dim strJavaPath

 

set wshShell = CreateObject("WScript.shell")

set scrFilesystem = CreateObject("Scripting.FileSystemObject")

 

strJavaPath = wshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs") & "\Java"

 

if scrFileSystem.FolderExists(strJavaPath) then

scrFileSystem.DeleteFolder(strJavaPath)

end if

 

This script works both on Windows XP and Windows 7 (maybe other versions too).

[martinkasabov]

Thanks for the input, goran13!

That is true (would not work for WinXP), as the variable %PROGRAMDATA% in XP points to "C:\Documents and Settings\All Users\Application Data", where there is indeed a "Microsoft" Folder, but there is no "Windows" folder where normally the Start Menu > Programs > Java will be placed.

Instead, a "%ALLUSERSPROFILE%\Start Menu\Programs\Java" can be used for XP.

However, your alternative is better, as it is applicable for both OS, which is pretty cool.

[2097]

there does seem to be missing a few bits here

 

Heres what i have done for the latest update !

 

create two files Deployment.config and deployment.properties

 

copy the original settings from your user profile deployment.properties into the new deployment.properties

 

and add the following

 

deployment.security.mixcode=HIDE_RUN

deployment.security.level=MEDIUM

deployment.javaws.autodownload=NEVER

 

inside the deployment.config put the following

 

deployment.system.config.mandatory=true

 

copy these to a network share . Now in the previous page there was the method on using a VBS to remove the startmenu folder . I have added the following to it to keep it nice and simple !

 

'Option Explicit

'On Error Resume Next

dim strJavaPath

set wshShell = CreateObject("WScript.shell")

set scrFilesystem = CreateObject("Scripting.FileSystemObject")

Set objFSO = CreateObject("Scripting.FileSystemObject")

strJavaPath = wshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs") & "\Java"

if scrFileSystem.FolderExists(strJavaPath) then

scrFileSystem.DeleteFolder(strJavaPath)

end if

strSource = "\\servername\packages\Java Runtime Environment\JRE 7.0 u51\"

strDest = "C:\WINDOWS\Sun\Java\Deployment\"

For Each strFileName In Array("Deployment.config","Deployment.properties")

objFSO.CopyFile strSource & strFileName, strDest,True

Next

 

You can find more stuff like this on LukeTaylor.org.. Memoirs of an IT Technician

Edited April 3, 2014 by 2097

[Zyxn]

Starting with Java Update 40, Oracle allows you to disable the pop-up box that prompts users in-browser that their Java is out of date.

Java

"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: Code: deployment.expiration.check.enabled=false"

I use ORCA to create a .mst file to deploy with the .MSI file via Group policy

I change the following properties:

 

• Autoupdatecheck = 0
  
• IEXPLORER = 1
  
• JAVAUPDATE = 0
  
• JU = 0
  
• MOZILLA = 1
  
• WEB_JAVA_SECURITY_LEVEL = M (add a new property & Value)
  

Should I add another property called "Deployment_Expiration_check_enabled" = False ? I'd rather not have to create another group policy to change the registry key of "deployment.expiration.check.enabled=false"

What is the best practice?

*none of our clients have SCCM