Skip to main content

Support needed for easy java runtime roll-outs

17 replies [Last post]
osbald
Offline
Joined: 2003-06-13
Points: 0

On the cusp of Sun's newfound enthusiasm for Java everywhere I felt I had to post a few questions on the state of the runtime installers. We've been having awful problems getting the runtime installed on clients; Windows XP boxes are a particular problem as users have a very restricted set of privileges and write access - meaning that the runtime installation has to be run by someone with Administrator rights. This just isn't practical when we're trying to roll out a Java Web Start solution enterprise-wide.

In an ideal world I suppose the runtime would be delivered pre-installed and big pat on back for getting Dell & HP to agree to this; but even with their support they'res still going to be a lot of Java unfriendly PC's out there.. Anybody got any clever ideas on routes around these problems.. I've tried to document some of our frustrations in the first part of this document http://lopica.sourceforge.net/services/ . During the process of writing the same I stumbled across Microsoft's Windows Installer Service WhitePaper which states:


Operation in Lockdown Environments

To decrease support costs, many organizations have locked down their desktops by controlling people's ability to write to the file system and registry. While this prevents a person from accidentally or intentionally modifying their configuration, it also requires administrator intervention whenever a new application needs to be installed. Since the Windows Installer operates as a system service on Windows NT 4.0 and Windows 2000, it has the ability to run in one of two contexts:

- As the Local System account, which has greater privileges than the user
- As the user, which is the default behavior

In a Windows 2000 environment, using the Group Policy-based Change and Configuration Management, the administrator can approve certain applications, specifying that all configuration operations on those applications (installation, uninstall, and repair) run as the Local System account. In this manner, administrators can lock down the file system and registry as described above, and the Windows Installer service can still perform installations on the person's behalf. Only those applications approved by the administrator run with elevated privileges.

I've also run across "Provide .MSI file for Java, to deploy Java using active directory" http://developer.java.sun.com/developer/bugParade/bugs/4854974.html . It appears Microsoft Installer might be the answer to both enterprise installation and the admin rights installation bugbear which really prevents us from offering users an easy install path. Comments? Anyone?

..Also (can't resist a winge here) I find Sun's renewed interest in Java on the Desktop all very laudable; but the runtime support for Java Web Start and the Window ActiveX AutoDownloader is becoming a joke. Web Start users still can't access 1.4.1_01, 1.4.1_02 or 1.4.1_03 runtimes (http://developer.java.sun.com/developer/bugParade/bugs/4827788.html) and support for other versions is very limited and slow coming online (http://developer.java.sun.com/developer/bugParade/bugs/4836169.html) . I understand these are special installers and require development alongside the better known .exe versions (which have they're own chequered history with XP & InstallShield issues) . But come-on Sun, a little more forethought and support - please..

- Richard

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
osbald
Offline
Joined: 2003-06-13
Points: 0

Yeah 1.4 will need registry access, or at least Java Web Start (included in 1.4) will; as it makes registry changes to insert the jnlp mime types.

Infact most Windows XP users will also need administrator rights, as by default they won't be able to write any files to the program files directory nor make changes to various sensitive parts of the registry.. It's Windows XP that really knocks us for a loop, even if you do have a system admin willing to run around installing the runtime after hours it still messes up as the jre directorys get owner:rewd and public:re ..this makes Java Web Start fail
when it cant modify it's own configuartion files - and when I'm facing a possible rollout to 160,000 users thats a lot of running around the mr sys admin has to do..

- Richard

zander
Offline
Joined: 2003-06-13
Points: 0

> .this makes Java Web Start
> fail when it cant modify it's own configuartion files

Are you saying that java webstart needs to write a config file outside the users 'home' dir?
I suggest posting/voting for a bug on the JDC, as this is a very stupid bug, and funny that linux does not have this problem.
Maybe its fixed in 1.4.2 ?

osbald
Offline
Joined: 2003-06-13
Points: 0

Yes dont freak - it is fixed in 1.4.2, all of the important config files and caches are moved under the userprofile.. Sun are on the ball here.

It still exists as a problem when you try to install a 1.3 or 1.4 jre under Windows XP at least until 1.4.2 - but not everybody lives in an enviroment where thy're free to upgrade on a whim.. I know teams in MTV who are still stuck supporting/developing under jre 1.2 (shudders).

- Anyone got ideas on getting over the priveldge roadblocks Windows XP throws in our path?

- Richard

osbald
Offline
Joined: 2003-06-13
Points: 0

Actually I can update this slightly by explaining the limits of my own sucesses with this approach (hopefully Sun won't mind me sharing this too much). I can tell you how to get hold of an .msi package for the 1.4.2 beta java runtime for somebody to test these ideas out with. The process itself is pretty easy, just download the full offline version of the 1.4.2 jre and start the install process. When you reach the prompt about install to directories etc.. stop, go to explorer and hunt through the temp files the installer created.. you'll find "Java 2 Runtime Environment, SE v1.4.2.msi" hidden inside.

This could be used to achieve the enterprise deployment which should clear our first hurdle; however each user still would need to have administrator privs to install the thing - so I'm still stumped.

Like most Java developers the idea of working with msi packages is just completely alien to me; what I think we really need is help from a friendly MS certified sys admin who can take the ball from here and run with it. I think the installer itself has been told to check for admin rights and stop when they're not present - rather than attempting to allow for elevated privileges, and the msi package itself seems to be an unintentional side-effect of using the latest InstallShield software (I'd be more than happy to be told I'm wrong here). My own tiny company just doesn't have the time or resources to commit to finding the solution. Infact I've been told to rewrite our jfc/swing web start app into a html web app precisely because we've lost customers who haven't been able to achieve a comfortable java rollout..

- Richard

osbald
Offline
Joined: 2003-06-13
Points: 0

Right then, I'll continue talking to myself here (first sign of madness - don't ya know). Found a couple of interesting bug reports I'd originally missed because their both closed - fixed (can you guess where I'm going with this).

Bug ID 4657166 RFE Elevated privilege support in jinstall for NT4-2000-XP: http://developer.java.sun.com/developer/bugParade/bugs/4657166.html

Bug ID 4431060 Installer quits when run as restricted user in windows 2000: http://developer.java.sun.com/developer/bugParade/bugs/4431060.html

Both sound pretty great, but I've spent the morning on our WinXP pro box trying variations of all installers (1.4.2beta - .exe & .msi) and the new v5.5.5 update trial and the above bugs just don't work, not when I'm logged in as a normal domain user nor when I give myself power user privs. Only developers and sys admins give themselves administrator access in the majority of co-operate networks everybody (normal users) are effectively working as restricted user (windows xp default). The installer and update teams really need to address this issue if they expect Java to seriously penetrate the desktop, beyond the developer and the hobbyist home-user which is whom the installation and java web start defaults (http://lopica.sourceforge.net/services/) seem to be targeting.

Every time I try to install the runtime I'm faced with the same old 'This account does not have sufficient privileges to install Java VM.'. Bug#4657166 claims it will prompt for an admin password at this point - doesn't happen. Bug#4431060 claims by modifying the registry keys

HKEY_LOCAL_MACHINE/Software/Policies/Microsoft/Windows/Installer/AlwaysInstallElevated = 1

HKEY_CURRENT_USER/Software/Policies/Microsoft/Windows/Installer/AlwaysInstallElevated = 1

We can achive the elevated installs; sorry but either your notes are wrong (well the bit about anyone being able to modify HKEY_CURRENT_USER/../AlwaysInstallElevated is - it's a protected system key) , or the installers disallow because their hardcoded to look for admin rights.
I assume they' res a more acceptable route for domain admins to configure these options for all users/groups under the domain..? (help please) hacking registry keys (protected registry keys) is no better than needing to be local administrator to install (or update) the runtime.

Gah!

- Richard

Message was edited by: osbald

Message was edited by: osbald

zander
Offline
Joined: 2003-06-13
Points: 0

You probably don't want to hear this; but I've been playing with the though of using knoppix to do what you need.
Basically I provide a CD based on the Knoppix CD (a bootable CD that does all hardware detection and after a minute shows you a full-blown desktop) and add the JRE to that.
Using webstart allows me to not have to press new CDs every other day.

http://www.knoppix.net/

ps. it seems that the real problem is XP, while I am certainly not saying you should not support XP, I think its wise to at least tell all your business contacts that XP is not benefitting them, and that they should stay with 2000 or even 98.

osbald
Offline
Joined: 2003-06-13
Points: 0

Well it's not an XP problem per se: more a Java playing second fiddle to the security polices in use, big companies will have an enforced windows security policy in force for NT, 2000 and XP. It seems Java just hasn't squared up to the realities of working in these locked down environs. Windows XP exasperates the problems by defaulting to restricted mode for either a new user or more critically whenever a general domain user logs into a generic XP box.. no rights = no install (and no java update either).

..as a developer I can't really dictate to the like of DaimlerChrysler,
HILT or SchlumbergerSema what OS they should be using to be able to use Web Start. What happens is they say Java's obviously rubbish - no-thanks goodbye!. The whole point of Java being on the Desktop was that it really shouldn't matter what desktop that is.. I've been trying to point out it really does matter when it's practically impossible to get java runtimes installed or accepted because of these basic issues. Hence the neverending court case with Microsoft about getting them to pre-install the runtime - mind you it wouldn't stop there, because typically users still won't be able to update (no privs). So we're back to a situation of a particular runtime version set in stone (1.1.5).

Sure you get a sense of my frustration,

- Richard

zander
Offline
Joined: 2003-06-13
Points: 0

> Sure you get a sense of my frustration

No doubt atbout that; but I am wondering if it is any different from having needing a flash plugin for your project. (those updates have been coming at steady interval).

In other words; why can't you require java to be installed? If another company were creating this application, and they choose to write a COM app, they would need to install something as well; why is that different?

I do understand that the upcoming JRE 1.4.2 has webstart fixed so everything is always in your homedir. I guess that means no angry popups anymore :)

osbald
Offline
Joined: 2003-06-13
Points: 0

Because installing 1.4.2 (unlike Flash) requires an administrator login to install it. This isnt too bad for three or four installs, but we get asked for 160,000 clients; administrator is going to be pretty busy that day - lets be frank it's currently inpratical to attempt a roll-out on this kind of scale.

1.4.2 fixes some problems with web start, but it only works once you've installed the runtime ..back to square one.

- Richard

osbald
Offline
Joined: 2003-06-13
Points: 0

Thinking on a tangent here (or rather why didn?t I think of this before) what is it about the runtime install that needs admin rights? Aside from the XP access rights to the program files directories - the major culprit is my beloved web start, which needs to make registry entries to associate the jnlp mime types with javaws (oh and the plugin integration with ie - thats got to be more grubby registry hacks).

So in essenance if we were wrap the runtime files into a zip and ship it with our application, we wouldn't have quite so many problems.. (if we assume users have at least power-user privs). Flys in the face of all the modern wonders of java web start, java update and java plugins, but for just getting just our java application running -- its a worthwhile avenue.

- Richard

osbald
Offline
Joined: 2003-06-13
Points: 0

Yes - yes I do feel suitably humbled that all the while I've been banging on about msi installation Sun have been busy migrating the 1.4.2 installers to Microsoft Installer 2.0 (ref http://java.sun.com/j2se/1.4.2/jre/install-windows.html). ;-) Someone could have said something..

Mind you, still dosn't help us with access rights issues, the installation notes (above) still read:

[i]You must have administrative permissions in order to install the Java 2 Runtime Environment on Microsoft Windows 2000 and XP.[/i]

Feel like I've thrown every trick in the bag at v5.5.5 and 1.4.2beta installers; all to no avail (ref: http://www.javadesktop.org/forums/thread.jspa?threadID=184&tstart=0).

- Richard

billy
Offline
Joined: 2003-06-30
Points: 0

Can someone from Sun comment on the Java runtime saga?

jschulenburg
Offline
Joined: 2006-02-17
Points: 0

Is there already a solution to this problem? I tried to alter the msi delivered by Sun, nu success yet (it failes at unpacking rt.jar under system context). I have to install this package 1.4.2_05 on more than 2000 locked down WS's (2000 & XP) an i would like to do this as a normal user!

evickroy
Offline
Joined: 2004-07-23
Points: 0

As stated, most big companies will be more locked. Also, most big companies having Windows desktops will most likely be using MS Active Direcoty for mangaing security on the desktops. If that is true, the installation should be done two ways. 1) The image used to setup all new desktops should be updated to include the JRE. That way any new PCs that come in will already have it. 2) The admins can setup Active Directory to auto-push software down to the PC depending on the user. The instructions for this are stated here: http://java.sun.com/j2se/1.4.2/docs/guide/deployment/installation/window...

Of course, you can always have a Terminal Server that all clients run your application on. Then you only need to install the JRE once on that server. Using this method, you can also install certain jar files as "System" libraries into the cache so that they can be shared accross multiple users.

Hope this helps.
Erik

nik0
Offline
Joined: 2006-06-13
Points: 0

I am currently testing the roll out process via Active Directory (no problem with the rollout !). After a reboot : my computer is not able to use the JVM, nevertheless :
_There is one entry in my Tools menu (Java Console)
_One entry in the Advanced settings (JRE is enabled)

but no java applet is loaded when i try to test my installation

Anonymous

> On the cusp of Sun's newfound enthusiasm for Java
> everywhere I felt I had to post a few questions on
> the state of the runtime installers. We've been
> having awful problems getting the runtime installed
> on clients; Windows XP boxes are a particular problem
> as users have a very restricted set of privileges and
> write access - meaning that the runtime installation
> has to be run by someone with Administrator rights.

Maybe this is not exactly what you are looking for, but I can tell you what I have done with my recent project:

I was looking for an easy way of installation and I couldn't use WebStart, because some machines were not connected to the network. I took the JRE directory from an installed JDK and wrote a small Windows C application that simply ready a config file where a JAR file is defined and calls java.exe. Put all components in a .ZIP file and distribute it, done. No registry, nothing.

One thing I must admit is tha I was using JDK 1.3.1, don't know if 1.4 needs registry access.

zander
Offline
Joined: 2003-06-13
Points: 0

> One thing I must admit is tha I was using JDK 1.3.1,
> don't know if 1.4 needs registry access.

At least the java preferences package does. Notice that this means that the programmer explicitly uses this, and has nothing to do with normal user preferences!