Java Deployment Woes

With the recent back-to-back, off-hours, and off-schedule security updates from Oracle and Adobe, Systems Administrators have never before been more in a bind than they are today with needing centralized software management tools in their environment.

Us IT Administrators have significant challenges to address with the ever evolving Information Security landscape which will require a regular security maintenance plan. Some of these challenges are inherent to the operating systems, some are also inherent to the applications that are used day-to-day.

I have searched online for answers to my questions with regards to Java deployment and have usually turned up empty-handed. Java itself has the following challenges:

• It does not like being deployed in-use. The JRE Executable installer forces you to close all applications that have Java loaded before it will let you continue with the upgrade.
• Many different applications often come with their own versions of Java installers. For example, some applications include JRE 5.0, and now your systems may potentially be vulnerable to attack. (Eclipse IDE come to mind, and any web application built on Tomcat).
• Java Auto Updater can cause deployment challenges for centralized administration tools. For example, the Dell KACE management appliance uses "Assignments" for application installs. If you "Assign" Java 6u39 (Java 1.6.0.39), and someone updates to Java 6u41; Kace will attempt to reinstall the earlier version.
• We have political battles with users who will often ignore the Java Update utility and leave the icon sitting in their task tray. We have a class of users who protest up the management chain every time IT does a deployment of Java, swearing that their particular application cannot be upgraded.
• The Java Executable installer does not allow for ALL of the MSIEXEC properties to be specified on the command line.
• Leveraging MSI for Java is an 'afterthought' to Oracle, who provides specific instructions to dig within your Application Data folder after launching the EXE to find the extracted MSI and CAB files.

So how do we address these issues? There are a few different answers with different solutions.

• You can deploy at startup. The challenge here is that with the ever increasing "BYOD" style devices and ultra mobility, network connections are often not made until after the user has logged in to the machine. In this manner, application installs will not work from most centralized tools because they require this connectivity to download and execute their installers.
• Microsoft, as an OS vendor, should encourage and enforce developers to use all of the platform's tools. MSI installers should be the rule, not the exception, for all Windows applications.
• Changes should be made to the underlying OS to allow for upgrade-in-place of applications.
• Microsoft should encourage developers to use their "Update" process that exists in Windows (You know, the one that says PLEASE DO NOT SHUT OFF YOUR COMPUTER while it installs updates). Interfacing with this functionality should be encouraged at both an IT and Developer level.

In the mean time, one of the tricks I have used for deployment is the following:

• Download the Windows SDK to obtain a utility called Orca. Orca will allow you to modify the MSI file properties and save MST (Transform) files to use for installation.
• Within your MST, set JAVAUPDATE=0, AUTOUPDATE=0,MOZILLA=1,IEXPLORER=1.
• Deploy at bootup, login, or prompt users to close applications using the Java Runtime.
• msiexec.exe /qn /i "jre_installer.msi" TRANSFORMS="mytransform.mst"