Uninstall Java using Powershell and WMI either as a script or module with options to keep a specified version installed and optional list the versions installed.
UPDATE: 1.0 Released, see post here
Download from here if you don’t want to read on: https://poshuninstalljava.codeplex.com
I’ve had a couple of comments from my previous post on uninstalling Java with Powershell. They have been in regards to either enhancing the WMI query or leaving a particular Java version installed. That has spurred me on to rewrite the script in a more complete form and include some optional arguments.
The new script is written as a Powershell module (you’ll see the psm1 extension on the file) so the module will have to be loaded and then called just like a normal cmdlet. There’s lots of info on the web about how to use modules, so I won’t repeat that here, but to quickly load the module use “ipmo .\uninstall-java.psm1” from Powershell.
The cmdlet has two optional arguments:
-KeepVersion “Java version number” will uninstall all other versions of Java except the versions that match the string provided. Using “7.0.51” will retain Java version 7 Update 51, for example. Note that this switch does a match on the start of the version string, so passing “7” will keep all updates of the major version 7 whilst uninstalling versions 6 and 5.
-Whatif will flag the cmdlet to not uninstall any software but will output (as an object from WMI) all the software that matches the query that would be uninstalled if the switch was not used. This can also be used to get a list of all versions of Java that are installed as a series of objects that can be piped to other powershell commands or to a text file.
In either mode the cmdlet outputs the results as an array of WMI objects which can be piped into other commands.
I’ve included in the WMI query a set of additional product name matches supplied by a commenter “Carsten” which excludes a number of non Oracle software packages that otherwise would have been accidentally triggered by the cmdlet. There is a line early in the module which sets the base query string which reads something like:
$query=“select * from win32_Product where (Name like ‘Java %’ or Name like ‘Java(TM)%’ or Name like ‘J2SE%’) and (Name <> ‘Java Auto Updater’) and ((Vendor=’Sun Microsystems, Inc.’) or (Vendor=’Oracle’)) and (NOT Name like ‘%CompuGROUP%’) and (NOT Name like ‘%IBM%’) and (NOT Name like ‘%DB%’) and (NOT Name like ‘%Advanced Imaging%’) and (NOT Name like ‘%Media Framework%’) and (NOT Name like ‘%SDK%’) and (NOT Name like ‘%Development Kit%’)“
This is where you can add any other possible strings to exclude from the un-installation process.
A final word of warning. This module was written as a quick way of screening and removing Java from computers in an environment where there hasn’t been a lot of control in terms of software distribution. As you’ll see from the changes to the WMI query, there are a number of software packages that could have been accidentally removed because of the broad query used. I suggest you run the cmdlet with the -Whatif switch and capture the output for review before running properly.
UPDATE: The Win32_Product WMI class will cause the MSI Installer service to scan through all installed applications and generate a number of events (ID 1035) but otherwise does not seem to cause major issues. The Microsoft KB articel is here: http://support.microsoft.com/kb/974524/en-us. There is no way to avoid this and using the Win32_AddRemovePrograms class offers no uninstall() method. For the time being if you want to use this script then I would avoid using it as a login script or s start up script which may slow down login times..
You can download the file from the Codeplex project I’ve started : https://poshuninstalljava.codeplex.com
EDIT: There is now a ps1 version to provide the same functionality but as a script rather than a full module for those who may want to remotely launch or embed in something like SCCM or Group Policy.