Our organisation needs to deploy JRE7U25 to over 4000 workstations. Our desktops are running the following Windows and IE combinations:
WinXP 32 Bit/IE7
WinXP 32 Bit/IE8
Win7 32 Bit/IE8
Win7 32 Bit/IE9
Win7 64 Bit/IE8
Win7 64 Bit/IE8
We use the 32bit JRE installer across all environments and all IE browsers use 32Bit IE. On all of our environments the Deployment.properties and config files no longer work due to what appears to be a bug in the JRE7U25 installer. Our deployment files are as follows:
Both files are being copied to the following location:
After the installer runs and deployment files are copied to the workstation the deployment.properties and config files look like this:
#System Deployment Properties
#Mon Jul 01 12:29:20 CAT 2013
I have tried changing the deployment.config file as follows in an attempt to fix this to no avail:
None of the above mentioned works. So all our required settings in the deployment.properties file are being overwritten when opening the Java console? Our other major problem is that Changing the registry key to 0 in order to disable the next generation plugin does not disable the next generation plugin in Jre at the usual location as it worked for us machine wide (across multiple profiles for JRE6U29):
^^I have observed on a fresh install of JRE7U25 that the above mentioned registry key no longer exists in this version so a computer wide disablement of this option is no longer possible via the registry.
On our 32Bit and 64bit machines running the 32 bit JRE 7U25 client when we disable the next generation plugin it keeps enabling itself again. Even when we run the javacpl.exe to run as administrator by changing the compatibility settings and disabling the next generation plugin it enables itself again. This is a huge problem for us because our company Oracle web based applications need this plugin to be disabled in order to run the apps properly.
These are major obstacles for our deployment as we desperately require assistance or any advice in addressing these issues as there appear to be numerous bugs with the JRE7U25 release. Thank you in advance.
Update 7 July 2013:
I have observed that if you have the following options in your Deployment.config file it doesn't allow our java webstart apps which use jnlp extensions to run.
The jnlp file association is also broken on Windows XP workstations with JRE7U25. We are having to manually associate the .jnlp file extension with javaws.exe on workstation for Web start apps or else users cannot lauch JRE whn clicking on .jnlp links.
The only Deployment.config syntax which allows our Webstart applications to run is as follows:
What a mess!
I don't have an answer to the problem, but I am having problems with the system level deployment.properties file and IE9 on Windows 7 32/64bit.
Starting with version 13, the IE plugin seems to igonore the system level deployment.properties file in favor of the user level deployment.properties file. When I open the Java Control Panel, the settings are correct per the system deployment.properties file. Currently to get the Java Plugin to work reliably in IE9 I have to set the following:
_JAVA_OPTIONS = -Djava.net.preferIPv4Stack=true
Set the proxy to Direct Connection.
If I set the _JAVA_OPTIONS as an environment variable and the other two in the system deployment.properties file, Firefox works fine, but IE wont load either of the Java tests. If I removed the system deployment.properties files and configure the user deployment.properties file, both IE and Firefox work fine.
I find it interesting that if I set the configuration through the control panel, then apply the system deployment.propteries file, the user deployment.properties file reverts to defaults when the system file is removed.
Disabling the Next-Generation Plug-in
I executed the following commandline post Java deployment: "C:\Program Files\Java\jre7\bin\ssvagent.exe" -high -jpisetup -old
This was from the following post on java.net: https://www.java.net//node/703528
This worked consistently for us but was not as nice as using deployment.properties as we have for the remainder of our configuration:
Why don't you simply provide URL to the config file?
It works much better, especially in large organizations. You will be able to change any setting within seconds, globally. And you deploy only one file (
deployment.config), only once. Ever.
I would advise you though to use a CNAME which you could easily redirect to another server in case of failure (like
javaconfig.mydomain.com, whatever suits you).