Cool Solutions

Clean up those old java versions



By:

June 13, 2008 5:58 pm

Reads:15,427

Comments:3

Score:4

Java runtimes are full versions to themselves. While it may say Java runtime 6 update 6, it’s not a patch. It’s a full release. Unless you have a program specifically tied to an update level such as 1.4.2.12 (I haven’t seen one yet), or one tied to a Java platform version, (1.4.0_xx, 1.4.1_xx) (This I have seen), you can safely toss all of those old versions. We have a vendor application tied to the 1.4.2 platform and in that case I leave only the latest version (1.4.2_16 at the time of this article) of that release. Since there are occasionally security holes patched in updated Java releases, it’s worth staying on top of these and only keeping the latest version installed.

For the majority of users, they only need the most current version, which is 1.6.0 update 6 as of this writing. When you make your ZENworks app to distribute 1.6.0_06, clear out the old versions in the run after distribution script. While this is a huge list of commands, it’s only going to pause when it hits a version you have installed. You may wish to e-mail your users ahead of time and let them know this could take a while if you have a lot of versions.

A good way to check how many versions you have out there is to use ZENworks Inventory and run a report. Select the Software Inventory/Add-Remove Programs by Application. Click More filters and set the name to “java*” (No quotes) You will also need to run it again for “j2se*” (No quotes) because Sun changed the string to J2SE when they hit Java 5 and changed it back again for version 6.

After you deploy the current version, wait for your machines to be updated in their inventory scans and run it again. You should only see the current version next time you run the report.

Now for the uninstall scripts. Everything for 1.4.2_xx to the current release uses a standard MSI installation and can easily be removed silently. 1.4.1_xx and below used InstallShield and thus will be harder to remove, and not covered here.

The following covers 1.4.2 initial release up to 1.4.2_16, 1.5.0 initial release – 1.5.0_14 and 1.6.0 initial release up to 1.6.0_05. Please note the last 6 digits at the end of the string as that’s what changes between subversions. As new versions are released, you can simply add on to this. I would advise adding this script to future java deployments if you have system images with old versions in the image. This way you will be sure to clean them out any time a system is re-imaged and the current Java runtime is deployed. If you wish to keep a particular version, say 1.4.2_16, you would simply delete the corresponding line below. In this case it’s the line ending in “00B0D0142160″.

msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142000}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142010}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142020}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142030}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142040}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142050}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142060}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142070}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142080}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142090}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142100}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142110}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142120}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142130}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142140}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142150}
msiexec.exe /qn /x {7148F0A8-6813-11D6-A77B-00B0D0142160}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150000}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150010}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150020}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150030}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150040}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150050}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150060}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150070}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150080}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150090}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150100}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150110}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150120}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150130}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150140}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160000}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160010}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160020}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160030}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160040}
msiexec.exe /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160050}

I did a test run on this by installing all of those versions into a single virtual machine. I then processed my update and checked afterwards to make sure everything was cleaned up. Success. It did take several minutes however to uninstall that many versions.

1 vote, average: 4.00 out of 51 vote, average: 4.00 out of 51 vote, average: 4.00 out of 51 vote, average: 4.00 out of 51 vote, average: 4.00 out of 5 (1 votes, average: 4.00 out of 5)
You need to be a registered member to rate this post.
Loading ... Loading ...

Tags:
Categories: Uncategorized

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

3 Comments

  1. By:ecyoung

    If anyone has a similar solution for java 1.4.1_xx or older, please post here. We have know about this ‘msiexec’ solution for newer java’s for a while, but the older java’s are still causing a lot of problems for us.

  2. By:WalterH

    Hi,
    I knew 2 programs that are “tied” to a Java version.

    1. SEP Sesam Windows client stores the JRE path in the start script and in a shortcut.

    2. CA ITM R8.1 Admin Console stores the JRE Path in the registry: [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\ApacheTomcatApplicationServer\Parameters\Java] Key: JVM and Classpath.

    For both programs: while installing the store the current JRE path, editing the path allows both programs to work with a newer JRE, tested up to 1.6.0_06.

    Walter

  3. By:grimlock

    We had issues with the Canon utilities to manage the rips on a CLC4000 and CLC5000 requiring Java 1.4.1 I believe.. So far that’s the only thing I’ve run in to.

Comment

RSS