Jump to content

Recommended Posts

Posted

Hi,

 

It appears there's a problem running Java applets when using a proxy server with AD Authentication. The upstream proxy appears to work fine so am looking to globally configure Java to use the upstream proxy to get around this issue however, a reg frag to populate the appropriate values doesn't change the radio button away from "Use browser settings" to "Use proxy server" within the Java Console and the same is the case for manually populating the "deployment.properties" file within the user profile. I then thought that this could be pre-populated within the msi but can't find this file within the data1.cab file and there doesn't appear to be any tables that contain the relevant data within the msi itself so really doesn't want me to set this by the looks of things!!

 

Any ideas how I can do this?

Posted

I use GPP to deploy the deployment.properties and deployment.config files into the relevent java directories on the workstations.

 

deployment.config is put in the (because we still use java6) Program Files\Java\jre6\lib folder and contains the following:

 

#Points to the Deployment.config file

deployment.system.config=file\:C\:\\Program files\\Java\\jre6\\lib\\deployment.properties

 

And then we put the deployment.properties into the smae folder which has the following:

 

#Java Deployment.Config for admin machines
#Routes all Java traffic straight out through to CLEO/Cumbriagfl proxy which removes kerberos issue
deployment.proxy.ftp.host=wwwcache.cleo.net.uk
deployment.proxy.https.port=8080
deployment.proxy.bypass.list=intranet;*.domain.local;
deployment.proxy.bypass.local=true
deployment.proxy.ftp.port=8080
deployment.proxy.http.host=wwwcache.cleo.net.uk
deployment.proxy.type=1
deployment.proxy.https.host=wwwcache.cleo.net.uk
deployment.proxy.same=true
deployment.proxy.http.port=8080

  • Thanks 1
Posted
I don't appear to have a deployment.config file present anywhere on the local drive so I'm assuming this file needs to be created manually? Is it a case that the install detects the deployment.config file automatically and this reads the deployment.properties file and configures this accordingly?
Posted
Currently the application data for Java is "C:\Users\username\AppData\LocalLow\Sun\Java\Deployment" which doesn't help with the deployment of these files and regardless of creating the deployment.config manually, Java still doesn't look to be using the upstream proxy!
Posted (edited)
I don't appear to have a deployment.config file present anywhere on the local drive so I'm assuming this file needs to be created manually? Is it a case that the install detects the deployment.config file automatically and this reads the deployment.properties file and configures this accordingly?

Yes to both questions. I normally put the two deployment files in '%SystemRoot%\Sun\Java\Deployment'.

 

http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html

Edited by Arthur
  • Thanks 1
Posted (edited)

Was just about to post back that I'd found the same documentation and seen the system level deployment section.

 

I've placed both files in this location with the deployment.config pointing to the deployment.properties files within '%SystemRoot%\Windows\Sun\Java\Deployment' yet still no luck. I can't help but think the existing deployment.properties file located in 'C:\Users\username\AppData\LocalLow\Sun\Java\Deployment' is overriding this maybe or do I need to trigger this change off with a reboot or something maybe!?

Edited by randle
Posted
Yes I thought of this but wanted to avoid anything that involved manual interaction but have just seen that I can delete files through GPP also so will test this out and see if it works. Beers all round if so ;)
Posted (edited)
yet still no luck.

There was a typo in the path I posted above (since I was typing the reply on my phone). I've edited my post now.

Edited by Arthur
Posted
Thanks for the update. I tried this and deleted the existing file but when running an applet in IE this file just gets re-created within 'C:\Users\username\AppData\LocalLow\Sun\Java\Deployment' so looks to be completely ignoring the manually created files!!
Posted

What does your deployment.config file look like? This is mine.

 

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

Posted
I thought the file is created but is ignored. You could add a exception to the proxy settings and see if the setting is carried to the user file.
Posted
I thought the file is created but is ignored.

Is it. The settings in the system-level configuration files will take precedence over the user-level settings.

Posted
What does your deployment.config file look like? This is mine.

 

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

 

Hmmm you have forward slashes in your path where I have only back slashes as per the example above. I'll change mine tomorrow, test and let you know. I'll also post my files so you can see the content.

Posted
Hmmm you have forward slashes in your path where I have only back slashes as per the example above.

That could be why it doesn't work then. :)

Posted
Grrr. Still no success. I have both files present in 'C:\Windows\Sun\Java\Deployment' with the exact same content as you've posted above Arthur. I've tried storing these files in the 'JavaInstall\lib' folder with amended path in the deployment.properties file also but again the same happens! I've noticed in the following article (The configuration file must contain proper keys and values to deploy settings correctly.) that backslashes are used and there isn't one after the word "file" in the "deployment.system.config" path which appears different to what you've been using however, yours is obviously working so who am I to argue!
Posted
I've had some luck copying over the modified file to the user level location so will look at deploying this out here instead but would have preferred this working from the system level file really.
Posted

I've been doing some further testing on the system level deployment and setting a purposely invalid path within the 'deployment.config' displays an error on the webpage that it's trying to locate the file so now know the config file is at least being used to find the location of the 'deployment.properties' however, when correcting the path and using the same 'deployment.properties' file that I know to work, the proxy settings are simply being ignored and I know it's definitely using this properties file now because renaming this file gives the same 'unable to locate' message when testing an applet.

 

I'm seeing other threads reporting on similar issues with Java ignoring proxy settings within the deployment.properties file so doesn't look to be a unique issue however, these are for earlier versions so would hope this fixed by now. Out of interest what version of Java are you using?

 

Just to confirm, regardless of using the system level method, a user level file is still created.

Posted

One step forward and five back....

 

I now can't deploy to the user level location due to the change RM makes to the %AppData% location. The article Java Group Policy Network Settings states that the %username% variable cannot be used within GPPs so need to use %AppDataDir% instead but this variable points to 'N:\My Settings\Application Data' rather than where the normal Application data directory is and where the configuration file needs to be (C:\Users\Username\AppData\LocalLow\Sun\Java\Deployment).

 

So now I have no choice but to use the system level file but currently this isn't working as explained above!! How frustrating...

Posted
I've noticed this problem for a long long time but has only become an issue now that ICT are using scriptlets in coursework modules.
Posted
Well there's a workaround to the redirection by using the %userprofile% variable so can now push this out through GPP however, am now getting an access denied message in the event log and can't see why as this is a problem seeing as the file is in a public, shared location.
Posted

Ignore me, I'm being a total tool. I'd missed off the filename from the end of the target path in the GPP 'file' section....:getmecoat:

 

Looks like this is working through GPP deployment so at least that's something. Annoying that it didn't want to play at the system level. Thanks for all your help anyway.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...