Uninstalling all previous versions of Java runtime environment using application supersedence in Configuration Manager


Scenario:

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”.

image

Here is my application “All Java 6/5 Runtimes (Detection / Uninstall Only)” and my deployment type “All Java 5/6 Runtimes Uninstall Only”

image

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.

image

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:

image

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.

image

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

image

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).

image

image

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.

image

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!

image

Wrapping Up:

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).

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Updates:

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

Comments (74)

  1. Anonymous says:

    Nice. A good way to get rid of all old Java versions.

  2. Anonymous says:

    @AJ, i’m not sure what’s going on. Can you email me the output of the log when manually run vs with sccm? use the contact request here and I will reply so you have my email.

  3. Anonymous says:

    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.

  4. Anonymous says:

    @BPersaud This is likely do to Java being corrupted at some point. It may have been trying to update while running if it didn’t uninstall completely and left information in the registry.

  5. Anonymous says:

    @ Pgrantland, It is a contains search. So if you leave Java 6 Update and Java(TM) 6 Update it will remove them all.

  6. Anonymous says:

    @Thefere what version of Java are you installing? If it’s Java 7 Update XX it should receive previous versions.

  7. Anonymous says:

    thanks

  8. Anonymous says:

    @ Larry, Can you email me the log file. Frist . Last name @Microsoft.com

  9. Anonymous says:

    @ 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.

  10. Anonymous says:

    @ Jayzus, It should be easy to make a few edits to do an exact match.

  11. Anonymous says:

    @ jhensley, 1603 is generic. You would need to enable /l for a log. It very well could be the older version of Java is running and/or corrupted.

  12. Anonymous says:

    @Andy, No not currently, I may create another version where it has to match the display name rather that a contains check if I get much feedback about that being helpful on this thread.

  13. Anonymous says:

    @ Hugh, Definitely a good idea. It’s something that would be outside scope for adding that to the script in this blog, but you can feel free to modify the script locally.

  14. Anonymous says:

    @discontinuity, No when choosing this is 32-bit app on x64 OS it will auto check in the SysWow.

  15. Anonymous says:

    @ AJ, are you deploying the script using a deployment type or package?

  16. Anonymous says:

    @ckuever do you have the script in the same directory as the application source? that error = Unable to detect post-uninstall.

  17. Anonymous says:

    @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.

  18. Anonymous says:

    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

  19. Anonymous says:

    Having a bit of an issue even when just running the script manually. It does find and attempt to remove old Java but then encounters an Error 1603 which according to the interwebs is a very common problem with Java. Any suggestions on where to go from
    here?

  20. Anonymous says:

    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.

    Pat

  21. Anonymous says:

    @ ckuever, I’m not to sure what’s going on there. I haven’t seen this before.

  22. Anonymous says:

    @ Doesn’t work, I would need more info on what exactly isn’t working? Logs etc would be needed.

  23. Anonymous says:

    @ JW, review my comment of the first comments page you should not use the WMIC method because it will reconfigure every installed MSI application.

  24. Anonymous says:

    It tells you in the post

  25. Anonymous says:

    @Nick, this is the way Java’s installer works now. They don’t remove previous version. They give consumers a uninstall tool during a non-silent install, but that’s pretty much useless when trying to silently deploy it.

  26. Anonymous says:

    @Mike this = Unable to detect post-uninstall.

  27. Anonymous says:

    Nice blog my friend. It’s a really good way to get rid of all old Java versions.

  28. Anonymous says:

    @Nozuka and Matt Skalecki, I released v 1.1 of this script that will now exit the script if the apps to uninstall.txt isn’t in the same directory. If you following the directions, this would not occur though.

  29. Anonymous says:

    @ Rajneesh, you the email form and I will see what I can do.

  30. Anonymous says:

    @Greg thanks for pointing this out will work to get an update to the script to make it skip empty lines

  31. Anonymous says:

    @ Tom I just released version 1.2 that will skip empty lines.

  32. Jayzus says:

    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.

  33. John says:

    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.

  34. Tabouli says:

    u can use this to :
    wmic product where "name like ‘Java(TM) 6%%’" call uninstall
    wmic product where "name like ‘Java 7%%’" call uninstall

  35. Jordan says:

    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?

  36. THyfere says:

    What type of Deployment Types you choose? Script Installer or MSi? Second, what if I want to deploy as required application?

  37. ThyFere says:

    Thanks Justin.

    It ran well except it didn’t install the Old updates of Java 7. How can I do this?

  38. Mark says:

    Great work, thank you.

  39. Hugh says:

    While this is an excellent script, I have found that recent malware and Trojans infiltrate java cache 6.0 which is left over from java 6. The Java website when checking for it to uninstall old versions does not recognize this folder either (users\AppDataLocalLowSunJavaDeploymentcache6.0
    – Win7).

    The script will look for old versions of java, but will not look for the java cache.
    The script can be adapted to look in that file path though.

  40. tom says:

    Hi, i am a beginner in SCCM and cannot make it running. I wonder if uninstall.vbs, which is defined on programs tab of All JAVA 5/6 Uninstall should be in the same folder as msi for a new java 7, and should i enter the proper path in "Uninstall start in"
    cell for this vbs script ?. On detection method tab, whether there should be this uninstall script.vbs used or i have to configure all the detection rules?
    Thanks for help.

  41. Larry Shewell-Woodbury says:

    This script looks like it will do what I need, to perform a universal uninstall, of previous versions of Java (before I install the latest version). When I run the script, it seems to hang, I look at the uninstall.log file, it seems to have gone thru the
    hive, and then has a bunch of repeating lines, "Checking for in the uninstall hive" & "Checking for in the Wow6432Node uninstall hive". It seems to not be reading from the appstouninstall.txt file.

  42. Larry Shewell_Woodbury says:

    Ok, figured out what was going on (used wscript.echo to tell me what the name of the uninstall.txt file was). The objFSO.GetAbsolutePathName(…) was returning the path of cscript, not of the *.txt file. I rem’d out that line, replacing it with the following
    4 lines:

    strPath = Wscript.ScriptFullName
    Set objFile = objFSO.GetFile(strPath)
    strFolder = objFSO.GetParentFolderName(objFile)
    strUninstallFileFullPath = strFolder & "" & strUninstallFile

    Now the *.log files shows the apps that are listed in the *.txt file.

  43. Larry S-W says:

    @Justin & That fixed what I had…:) It works like a charm!! Thank you Justin!!

  44. Andy says:

    Great write up. It works perfectly. Is there a way to just add exceptions for uninstall?? For example, how can I exclude Java 7 Update 51 – 64 bit from uninstalling,

  45. ckuever says:

    I always get error 0x87D00325 with SCCM 2012 R2

    explained here:
    https://social.technet.microsoft.com/Forums/en-US/a8a85481-9ffc-424c-ac03-1691280c3fe7/application-removal-successful-but-fails-according-to-software-center?forum=configmanagerapps

    but a simple wscript.sleep didn’t fix the Problem

    Anyone else the same Problem or a Suggestion?

    Thanks.

  46. ckuever says:

    @Justin Chalfant: yes i have

    both applications use the same source path

    thanks,

    ckuever

  47. BPersaud says:

    1st, thank you for the script. 2nd apologies for any ignorance you may encounter. I seem to be having a problem. I’m trying to deploy the script on it own as the latest Java has already been pushed. When ran manually as local admin on the same machine
    I have no issues, when deployed with SCCM the log returns the following (seems to point to a permissions issue but the sccm account is a domain admin.)

    Checking for Java 7 in the uninstall hive
    Java 7 Update 67 (64-bit) Found
    HKLMSOFTWAREMicrosoftWindowsCurrentVersionUninstall{26A24AE4-039D-4CA4-87B4-2F06417067FF}
    Java 7 Update 67 (64-bit) Uninstall String Parsed To = /X{26A24AE4-039D-4CA4-87B4-2F06417067FF}
    Uninstall Command Is: C:Windowssystem32msiexec.exe /X{26A24AE4-039D-4CA4-87B4-2F06417067FF} /qn REBOOT=REALLYSUPPRESS
    Uninstall Finished With Exit Code 1605

    Checking for Java 7 in the Wow6432Node uninstall hive
    Java 7 Update 67 Found
    HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionUninstall{26A24AE4-039D-4CA4-87B4-2F03217067FF}
    Java 7 Update 67 Uninstall String Parsed To = /X{26A24AE4-039D-4CA4-87B4-2F03217067FF}
    Uninstall Command Is: C:Windowssystem32msiexec.exe /X{26A24AE4-039D-4CA4-87B4-2F03217067FF} /qn REBOOT=REALLYSUPPRESS
    Uninstall Finished With Exit Code 1605
    Script complete

    SCCM
    Error Code: "0x645 (1605)"
    Error Description: "This action is only valid for products that are currently installed."
    Description: "Action failed"

  48. ckuever says:

    regardless what i configure, always 0x87D00325

    SCCM 2012 R2 CU3

    old Java Versions were successfully uninstalled via the vbs script, then 0x87D00325:

    Unable to detect post-uninstall.

    do we Need some sleep commands somewhere?

    Thanks,

    ckuever

  49. discontinuity says:

    Really nice script. Thank you very much. It works most of the time. But app detection for the uninstall script seems to be a bit wrong.
    The deployment type “All Java 5/6 Runtimes Uninstall Only” detection method is using the following:

    " HKLM – SOFTWAREJavaSoftJava Runtime Environment1.6 (or)
    HKLM – SOFTWAREJavaSoftJava Runtime Environment1.6 (With this registry key is associated with a 32-bit application on 64-bit systems). "

    Shouldn’t the second key be "HKLM – SOFTWAREWow3264NodeJavaSoftJava Runtime Environment1.6" ?

    By the way, should we add the "HKLM – SOFTWAREJavaSoftJava Runtime Environment1.7" key to app detection clause if we are to uninstall also Java 7 updates?

  50. discontinuity says:

    Oh! My bad! Thank you 🙂 What about uninstalling the Java 7 detection? Should we add "HKLM – SOFTWAREJavaSoftJava Runtime Environment1.7" keys to detection rules?

  51. Vlad says:

    Thanks a lot for the script! Worked for me!

  52. Aj Jain says:

    Justin, I am having a strange issue running this script via SCCM 2012 sp1.
    When I deploy the package, the script always searches the WOW6432 registry key.
    I written some error checking which indicates it should be looking at the 64-bit key but it still pulling uninstall strings from 32bit.

    If I run the script manually from the machine, the script works flawlessly. Is there any settings I need to change in SCCM to make this run properly?

    Thanks,
    AJ

  53. Aj Jain says:

    I was attempting to deploy it as a package.

  54. Aj Jain says:

    Justin, I also tried to deploy the vbs as an application and got the same results.

  55. Aj Jain says:

    Justin,

    I have figured out the issue. When I created the application, I entered "Uninstall.vbs" under Installation program. I tried with wscript.exe "Uninstall.vbs" and had same results. I later noticed the 32 bit version of wscript.exe was executing on the machine.

    Finally, I tried %windir%system32wscript.exe "Uninstall.vbs" and it was executed with the 64bit version of wscript.exe. After completion I verified everything worked as expected.

  56. mike says:

    Little question, if there are no previous versions of Java on the computer. The deployment works or not ?

    Because, I have a case with this error : 0x87D00325(-2016410843). And, on this computer, there are no previous version of Java.

  57. Arnaud says:

    Hello guys,

    I have launch a deploy for Java 8u25 and results are good.
    Just a question, on some computer we have problem to execute deploy.

    You can take a look here :
    http://upload.tech2tech.fr/images/2015/01/22/2015-01-22_12-20-39.png
    50 computers have Java 8u25 deployed with success (and old java uninstall)
    5 computers have this error code : 0x87D01106 – Failes to verify the executable file is valid or to construct the associated command line.

    Do you have ideas about this error code ?

  58. Doesn't work says:

    This use to work and now it doesn’t with Java 8. A fix would be great….

  59. Doesn't work but might work? says:

    @Justin Chalfant. How can I get some logs? I would love to use this. At first it wouldn’t uninstall version 8 at all. Now for some reason it is working on the local computer but when I try to do it from SCCM it just says failed to update. …

  60. Nozuka says:

    Nice Script, but there is a dangerous flaw that should be fixed!
    If it can’t find the "AppstoUninstall.txt" File it will uninstall ALL programs!

  61. Matt Skalecki says:

    This script is EXTREMELY DANGEROUS. As Nozuka says, running this script without the AppstoUninstall.txt file attempts to uninstall every program on the computer.

  62. rajneesh1 says:

    Hi Justin thanks for really nice script but i have one more script for same purpose but it won’t work via SCCM and it works when i run this locally. not sure what wrong i am doing can u please help me in that script how to deploy that script via SCCM.

  63. Nick Arnold says:

    This worked great for me. Unrelated to the script – I created a new application (java 8u40) and deployed to a test machine with u25.. Did not upgrade/replace – both are installed. Anyone else run into this?

  64. Nick Arnold says:

    Justin> I figured that’s what was going on.. I guess your script will work as an uninstaller going forward.

  65. JM says:

    wmic product where "name like ‘%%Java %%’ and not name like ‘%%Java 8 Update 40%%’" call uninstall /nointeractive

  66. PPK says:

    Hi Justin, The script doesn’t seem to uninstall all the versions when installed with SCCM. If anybody is using the SCCM 2007 which is a 32 bit client, will check for the entries only under "HKEY_LOCAL_MACHINESOFTWAREWow6432Node" registry hive and will
    uninstall only 32 bit Java.
    The reason for this is, whenever packages are installed with SCCM-2007, the cmd which is executed is 32 bit and hence it will uninstall only the 32 bit packages from Wow6432Node.

    NO doubt the script is as expected, the workaround for this is to execute the below command in SCCM which will check for both the registry hives and uninstall any 32 bit and 64 bit java pacakges from the system.
    %windir%Sysnativewscript.exe "Uninstall.vbs"

    where Sysnative is a virtual folder, a special alias, that can be used to access the 64-bit System32 folder from a 32-bit application or script.

  67. Chris Cabral says:

    Hi Justin. I am trying to follow this guide but am getting lost all over the place as I am quite new to SCCM 2012. Do you by any chance have a more in depth step by step on how you set this all up?

    Thanks,

    Chris

  68. Greg T says:

    Nice Script Justin. I just wanted to point out that you need to be very careful that you save the AppsToUninstall.txt files with no extra lines. I executed the script on a batch of computers and it uninstalled all of the Java versions that I had specified
    in the first few lines but then continued to uninstall every other program on the PC. This is because it interpreted the last blank line as meaning that it should include any program names comntaining spaces. This is most of them! I had to do a CTRL + END
    to ensure that my cursor was sitting after the last character on the last line and then re-save it. The script then executed safely uninstalling only my specified programs! Just a bit of a trap for the unwary 🙂

  69. Tom L says:

    Justin, were you able to find the time to update the script to skip empty lines?

    Thanks,

    Tom

  70. palonso says:

    I am unable to download the scrip, I get a 404 error – File or directory not found. Can you provide me with a link? thx

  71. palonso says:

    nm, I was finally able to download it. Thank you

  72. Martin says:

    Hi, can you please add feature to also kill running processes. The script fails if java or internet explorer is running.

  73. Steffen says:

    Thanks a lot for this great script. Works perfectly and save me a lot of time