Like I suppose a lot of people, we have a Windows/Active Directory environment and a lot of internal line of business apps that require Java. Our experience is that Java does not play nice in such a corporate network environment. Initial installation is fine (at least there's an MSI these days), but keeping things ticking over can be quite a challenge.

Specific issues we encounter include:

  • Java has it's own updater, and so it does not tie into our internal patch management systems.
  • The lack of any tools for management of Java settings via GPOs.
  • The requirement for users to manually configure certain settings.
  • Multiple Java runtimes on each machine (Oracle Jinitiator is a particular culprit here).
  • Critical settings files stored under the Program Files folder.

with us it's mostly a batch of logon scripts and hacky workarounds, but I'm interested in hearing how other people handle these items, and if there are any other things one needs to watch out for here.

3 Answers 3


To speak to each of your concerns:

I've been deploying Java runtime environment releases for a few years now as software installation assignments from Group Policy. I disable updater functionality as a transform to the MSI and deploy updates, as necessary, through mandatory upgrades. If machines need to keep an older JRE (because some application requires it), I use security groups to keep machines from receiving newer upgrades. (Fortunately, I have not had to do this frequently.)

I build transforms to Sun's MSI using Microsoft's Orca tool. It might be nice to have a tool like Adobe's "Customization Wizard", but I can do everything I need with Orca.

I haven't had occasion for users to "manually configure certain settings", but I'd handle it one of two ways. If it's a matter of some users needing some settings that are different that the "norm", I'd either deploy a Group Policy "preference" to set that setting (assuming it's in the user portion of the registry), or an Administrative Template to change the setting (assuming it's in the computer portion of the registry). If it's required that hte user be allowed to change the setting on-demand, I'd grudgingly alter the permissions on the registry to allow the user (really, a security group containing the user) to do so. Grudgingly.

If an app requires its own JRE I'd be apt to tie the installation of that JRE in with the script / GPO that deploys the application and treat the two as a unit. That's the simplest way I can think of to deal with it.

I'm having a hard time recalling what settings live under "Program Files", but I'd grudgingly grant permission to a security group containing user accounts that need to modify these settings, if that was required. I'd probably also hold my head in my hands and curse Sun.

Until Sun gets their act together re: enterprise deployment and management of the JRE, I think it's likely that all of us are going to have hacky workarounds to deal with it. It's frustrating, but sadly typical. It seems like the vast majority developers have no concept of what it's like to do sysadmin work. <sigh>

  • Would you describe how to turn off automatic updating? I'm familiar with Orca and the idea of Windows Installer transforms. Where are the specific settings that need to be changed in the transform file? Jun 9, 2009 at 13:26
  • 2
    To stop the automated update functionality, transform the MSI to set the "JU" and "JAVAUPDATE" entries in the "Property" table to 0. That stops jusched.exe from running on logon and prevents the user from configuring automated updates. Jun 9, 2009 at 14:06

We've actually had to deal with a lot of third party applications (java included) and their updaters as well.

We decided as an organization to integrate Ninite as our solution. Visiting the site and running the free version works great for a one-time setup on any PC, but, When you go Pro on ninite you also get Ninite One as part of your subscription. Ninite one is something you can run from the command line, silently, to deploy a good number of applications.

I'll gladly disclose that we're all PCs, but, as a whole we're really happy with the solution.

Ninite One has command line switches to disable things like automatic updates and creating desktop shortcuts on updates. That's what we've done and it works pretty well. It doesn't, however, allow for multiple versions of Java if that is a requirement I don't believe (but I could be wrong, I just haven't tested that out)


I have a solution for you, although it is a commercially related solution, but you can use PolicyPak to create a GPO that will manage nearly every setting within Java. They have a trial mode and community mode editions to either try it out or use in a limited capacity for free. PolicyPak integrates with Windows Group Policy and allows you to manage and lockdown application configuration settings for third party applications like Java even more effectively than Standard Group Policy locks down the various aspects of Windows. The link to its Java Pak is here http://www.policypak.com/products/manage-java-jre-with-group-policy.html and the link to the free editions is here http://www.policypak.com/support-sharing/policypak-trial-community-edition-fully-licensed-modes.html.

Brad (employee of PolicyPak)

  • Though this is basically an advertisement it's OK, I guess, since it kind of answers the question. It would be better if you showed how using your product.
    – slm
    Aug 4, 2013 at 21:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.