I have customers ask me sometimes how application supersedence works and one of the more common questions that I get around supersedence is customers who want to move up to a new major version of Java runtime environment.
A major version upgrade of Java runtime environment will not remove an older major versions that’s installed. Example: you want to upgrade Java 6 Update X to Java 7 Update X. Some early versions of Java 6 won’t be uninstalled when a newer version gets installed as well. All versions of Java 5 will require a manual uninstall when installing a newer version of Java. This is a scenario where application supersedence can help us out.
Update: Noticing a lot of comments of people saying use the WMIC method: wmic product where “X" call uninstall /nointeractive method within WMI. I don’t recommend this because when using this method it will reconfigure every product and can cause issues you can see this in the application event log.
How this can be accomplished:
There are a few things that will need to be configured for this to work. We will need an application and deployment type for Java 7 Runtime (Update 55 during this post) and an application and deployment type for Java 5/6 (All Versions) for uninstallation purpose only. All versions means we will need to create a detection method in our deployment type that will check out for any version of Java runtime 6 and 5 (You could easily check for older versions as well).
Here is my application for Java 7 Runtime is called “Java 7 Update 55”. I have one deployment type named “Java 7 Update 55”.
Here is my application “All Java 6/5 Runtimes (Detection / Uninstall Only)” and my deployment type “All Java 5/6 Runtimes Uninstall Only”
The deployment type “All Java 5/6 Runtimes Uninstall Only” the source location for a script I created. Notice: the install program is bogus since this deployment type is not ever going to be used to install Java runtime. The uninstall program is referencing the VBScript.
This script will loop though the uninstall hive (x86 and x64) of the registry looking for the displayname value’s. If the displayname contains any values you enter in the AppsToUninstall.txt file the script will search for the UninstallString value. If the uninstall value contains MSIEXEC (Windows Installer based installations only), it will parse the value to get the product code. The script will then call “msiexec /X%ProductCode% /qn REBOOT=REALLYSUPPRESS” to perform the uninstall.
Here’s what I am using for Java 5/6 detection and uninstall:
The deployment type “All Java 5/6 Runtimes Uninstall Only” detection method is using the following:
- HKLM – SOFTWARE\JavaSoft\Java Runtime Environment\1.6 (or)
- HKLM – SOFTWARE\JavaSoft\Java Runtime Environment\1.6 (With this registry key is associated with a 32-bit application on 64-bit systems).
- HKLM – SOFTWARE\JavaSoft\Java Runtime Environment\1.5 (or)
- HKLM – SOFTWARE\JavaSoft\Java Runtime Environment\1.5 (With this registry key is associated with a 32-bit application on 64-bit systems).
This detection methods will allow us to detect either x86 or x64 based installs of Java runtime 6 or 5.
In the properties of the Java 7 Update 55 application, I specified a Supersedence relationship to the Java 5/6 application and used the uninstall option. When Java 7 Update 55 is being installed from ConfigMgr, it will check the detection method for the Java 5/6 deployment type and if it's detection will use the uninstall script before installing the latest Java version.
To test this out, I have a Windows 7 x64 machine that has the following installed:
- Java Runtime Environment 5 Update 13 x64
- Java Runtime Environment 5 Update 16 x64
- Java Runtime Environment 5 Update 15 x86
- Java Runtime Environment 6 Update 41 x86
- Java Runtime Environment 6 Update 45 x64
I went ahead and requested the Java 7 Update 55 from the application catalog. I a made an available deployment to a user collection for this test scenario.
We can see in AppEnforce.log that the Java 5/6 deployment type was found. We will then call the uninstall command from the deployment type for Java 5/6 (The Uninstall VBScript).
The Uninstall.vbs script will also log everything it does to %temp%\UninstallScript.log. In my case, this will be %Windir%\Temp\UninstallScript.log since the script is executed in SYSTEM context from ConfigMgr.
If all goes well with the uninstall of Java 5/6 (or whatever you enter in the text file), you should have the latest version of Java 7 Update 55 in add and remove programs!
In this post, we went over the process of superseding all versions a Java 6/5 runtime with Java 7 Update 55. The script is available Here to Download (Use at your own risk). It’s especially important to be careful with the AppsToUninstall.txt. This does a contains search. For example, if you add just Java to the text file the script would uninstall any application that was installed by windows installer where the display name *contains* Java in it. The script should be able to work to uninstall other applications as long as they were installed by windows installer (MSI).
Version 1.1 (2.11.15) – The script will now close if the AppsToUnisntall.txt is not in the same directory
Version 1.2 (5.27.15) – The script will ignore empty lines in the AppsToUnisntall.txt