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>

WPKG
http://wpkg.org
"W-package" (GUI and Command line) is an automated software deployment, upgrade and removal tool for Windows.

• WPKG is open source software.
• It can be used to push/pull software packages, such as Service Packs, hotfixes, or program installations from a central server to a number of workstations.
• It can run as a service to install software in the background (silent install), without user interaction.
• It can install MSI, InstallShield, PackagefortheWeb, Inno Setup, Nullsoft, other software installers or .exe packages, .bat and .cmd scripts and similar: no more repackaging to perform software installation.

Here's a list of software that have already available silent installs, upgrades, and uninstalls configurations (yes, Adobe flash/reader, Java, Firefox, Quicktime are included here). You can write your own too, and contribute to the community.

It doesn't include a full "software-push" feature, but we solved this by using psexec to run it on all our client/hosts, from a remote computer.

You can use the wpkgCreateReport tool to generate a report showing which packages are installed on which computers.

check out the other user contributed software/tools, might come in useful

LUP

http://localupdatepubl.sourceforge.net

Another solution could be using software called Local Update Publisher. It allows you to publish 3rd party software updates through your WSUS server. It seems to use WSUS API feature called "Local Publishing". I haven't used it though, here's what claims to do:

• Publish applications to a domain or workgroup.
• Create rules to define install behavior.
• Monitor progress of installations.
• Use WSUS groups for approvals.
• Utilize existing WSUS architecture. Support multiple parent and child servers.
• Import and export standard update catalogs.