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:
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:
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
Hey Justin. Very good write up here! I do have a question. I extracted your zipped file that has the VBS script along with the text files. As of now the latest version of Java is 7 Update 60. If I wanted to uninstall all previous version (Java 7 Update
55 and below) would I have to modify your "AppsToUninstall.txt" file to look like this...
Java 7 Update 55
Java 7 Update 51
Java 7 Update 45
Java 7 Update 40
Java 7 Update 25
... and keep going until the oldest version I want to uninstall?
Also if I just left your two lines that say...
Java 6 Update
Java(TM) 6 Update
Would those two lines uninstall all Java 6 update versions completely? Thanks for your help. I'm trying to clean up my environment and delete old versions of Java that are still installed on PC's.
This script is a great concept but the fact that it will uninstall anything that contains *name of app* causes the script to be inconsistent. You should change it from "contains" to "equals" atleast. It's more work on the back end gathering the exact names
but the outcome is much more consistent.
@ Jayzus, It should be easy to make a few edits to do an exact match.
@ Pgrantland, It is a contains search. So if you leave Java 6 Update and Java(TM) 6 Update it will remove them all.
Good blog, this is a nice way to remove old Java, but unless I am missing something you are not actually using application supersedence as per the supersedence tab found in the properties of the application? Maybe you are just missing a screenshot.
Nice. A good way to get rid of all old Java versions.
u can use this to :
wmic product where "name like 'Java(TM) 6%%'" call uninstall
wmic product where "name like 'Java 7%%'" call uninstall
and for really old devices :
wmic product where "name like 'Java 7%%'" call uninstall /nointeractive
wmic product where "name like 'JavaFX%%'" call uninstall /nointeractive
wmic product where "name like 'Java(TM) 7%%'" call uninstall /nointeractive
wmic product where "name like 'Java(tm) 6%%'" call uninstall /nointeractive
wmic product where "name like 'J2SE Runtime Environment%%'" call uninstall /nointeractive
It's not recommend to use the uninstall method from WMI. If you look at the event logs you will see every application is reconfigured when you use this method.
Thank you for this write up! I feel like I too, along with John, missed the application supersedence portion of this. Could you elaborate on that a little more possibly?
@ Jordan, Should be good now. I'm not sure what happened with the Supersedence section. I made a few edits so I may have deleted it on accident.
What type of Deployment Types you choose? Script Installer or MSi? Second, what if I want to deploy as required application?
@THyfere You can choose either for the uninstall I choose a script installer and for the new Java installer I believe I used MSI deployment type. and you can deploy it as required just fine.
It ran well except it didn't install the Old updates of Java 7. How can I do this?
@Thefere what version of Java are you installing? If it's Java 7 Update XX it should receive previous versions.