Remove old Java version folders / files

Hello,

A couple of our customers have asked for a way to remove old Java version folders and/or files as they appear in vulnerability scans. I have the below bat file that works but is somewhat crude. I’m looking for a way to build on this and create a custom fixlet/task that will detect what folders need to be removed prior to the latest Java version and will work for 32 bit or 64 bit Java. Thanks in advance for any assistance given.

"cd “c:\Program Files\Java\jre1.8.0_25”

DEL /q /F /s .

cd “c:\Program Files\Java\jre1.8.0_60”

DEL /q /F /s .

rmdir “c:\Program Files\Java\jre1.8.0_25” /s /q

rmdir “c:\Program Files\Java\jre1.8.0_60” /s /q"

There is already a fixlet that removes old java versions installed on a system:

Java Runtime Environment - Multiple JRE Versions Installed - J2SE 1.4.2 and Up.

The listed computers have multiple versions of the Java Runtime Environment (JRE) installed. BigFix recommends keeping only the latest version of JRE to properly guard against known security vulnerabilities. Deploying the action below will keep the highest installed version, and will uninstall all lower JRE versions.

Note: Client machines may briefly display progress windows during installation of this update. 

Note: Affected computers may report back as 'Pending Restart' once the patch has run successfully, but will not report back their final status until the computer has been restarted. 

Note: Upgrading the Java Runtime Environment does not remove older versions of JRE. Please upgrade JRE to the latest version first using Fixlet message "Java Runtime Environment x.0 Update X Available" (ID 70510XX) to avoid running this action multiple times.

Important Note: Some applications and applets are written and tested against a specific version of JRE. Removing old versions 

If you want just to remove the folders, then you will have to extend your script and do the needed checks to ensure you are removing just old versions, but newest version.

1 Like

Yes we have a policy action that runs and removes the old Java versions when new ones are installed. So my question relates more to creating some sort of custom fixlet/task that would remove the folders for the old versions. Any assistance would be great as I am not that swift with the Bigfix relevance language :grin:

So you mean that the fixlet @fermt references does correctly uninstall the older Java versions, but leaves an empty folder or almost-empty folder behind that you want to remove?

I have a Task that performs a similar case that you might be able to modify. Take care to test it thoroughly though, removing whole directories can obviously be dangerous.

My use case is to delete the installer caches for Java versions that are no longer on the system. Java creates installer caches at \windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java, for every version of Java SE and Java JDK; when a machine frequently upgrades JRE (and especially JDK) versions, these installer caches can take up considerable space, and are not removed by the Java uninstallers.

Relevance 1:

windows of operating system

Relevance 2:
if exists property "in proxy agent context" then not in proxy agent context else true

Relevance 3:
exists folder "config\systemprofile\AppData\LocalLow\Sun\Java" of native system folder

Action Script:

action uses wow64 redirection false
delete __appendfile
appendfile SETLOCAL
appendfile SET FAILCOUNT=0
//Compare the names of the JRE/JDK installer caches with the names of JRE/JDK versions still referenced by the Registry; if the version of the installer cache folder is not referenced, remove the folder
    appendfile {concatenation "%0d%0a" of ("rd /s /q %22" & pathname of it & "%22 || @SET /A FAILCOUNT += 1") of folders whose ((name of it starts with "jdk" or name of it starts with "jre") AND name of it is not contained by set of (("jre" & name of it) of keys of key "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" of registry; ("jre" & name of it & "_x64") of keys of key "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" of native registry; ("jdk" & name of it) of keys of key "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit" of registry; ("jdk" & name of it & "_x64") of keys of key "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit" of native registry)) of folder "config\systemprofile\AppData\LocalLow\Sun\Java" of native system folder}
    appendfile @EXIT /B %FAILCOUNT%
    delete DeleteDirectories.cmd
    move __appendfile DeleteDirectories.cmd
    waithidden cmd /c DeleteDirectories.cmd

For something a little simpler but maybe more crude, you could check for the empty folders themselves. Here I have a “true” jre1.8.0_77 install in both Program Files and in Program Files (x86), and I’ve set up a dummy/empty “jre1.7.0.test” folder as well. I check for the subdirectories of Java that do not contain a java.exe or javaw.exe (presumably because that version has already been properly uninstalled by the fixlet above)

q: pathnames of folders whose (not exists files ("bin\java.exe";"bin\javaw.exe") of it)of folders "Java" of (program files x32 folders; program files x64 folders)
A: C:\Program Files\Java\jre1.7.0.test
T: 1.129 ms
I: plural string

A Delete command in ActionScript might be something like

action uses wow64 redirection false
delete __appendfile
appendfile {concatenation "%0d%0a" of ("del /q %22" & it & "%22") of pathnames of folders whose (not exists files ("bin\java.exe";"bin\javaw.exe") of it)of folders "Java" of (program files x32 folders; program files x64 folders)
delete ClearJavaFolders.cmd
move __appendfile ClearJavaFolders.cmd
waithidden cmd.exe /c ClearJavaFolders.cmd

Thanks very much for your replies.

I believe with what you have given me, I’m almost ready to piece together what I need. Below is the output from a sample machine. As you can see there are several folders that contain java.exe javaws.exe, etc. How can I delete these folders without deleting the current Java version folder (jre 1.8.0_92)? Or whatever the current version might be on a specified machine? Thanks again for your assistance.

`Q: pathnames of folders whose (not exists files (“bin\java.exe”;“bin\javaw.exe”)
of it)of folders “Java” of (program files x32 folders; program files x64 folder
s)
A: C:\Program Files (x86)\Java\jre1.8.0_65
A: C:\Program Files\Java\jre1.8.0_51
A: C:\Program Files\Java\jre1.8.0_65
A: C:\Program Files\Java\jre1.8.0_66
A: C:\Program Files\Java\jre1.8.0_77
T: 5886

Q: pathnames of folders whose (exists files (“bin\java.exe”;“bin\javaw.exe”) of
it)of folders “Java” of (program files x32 folders; program files x64 folders)
A: C:\Program Files (x86)\Java\jre1.8.0_73
A: C:\Program Files (x86)\Java\jre1.8.0_74
A: C:\Program Files (x86)\Java\jre1.8.0_91
A: C:\Program Files (x86)\Java\jre1.8.0_92
A: C:\Program Files\Java\jre1.8.0_73
A: C:\Program Files\Java\jre1.8.0_74
A: C:\Program Files\Java\jre1.8.0_91
A: C:\Program Files\Java\jre1.8.0_92
T: 11083`

I’d first run the three fixlets from the “Updates for Windows Applications” site that uninstall all but the most current JRE versions -
7057001 Java Runtime Environment - Multiple 64-bit JRE Versions Installed - J2SE 1.4.2 and up (x64)
7057003 Java Runtime Environment - Multiple 32-bit JRE Versions Installed - J2SE 1.4.2 and up (x64)
7052001 Java Runtime Environment - Multiple JRE Versions Installed - J2SE 1.4.2 and up

That should run the uninstallers and remove the binaries, leaving behind only customizations you made after the installation (like custom cacerts, deploymentrules, etc.).

I spot checked some machines today that had the fixlets above (which I knew about previously) run on them recently. The Java folders look pretty clean. It’s interesting, do you or anyone know if the old Java version folders being cleared out is a modification that was done recently for these fixlets? To my knowledge, weren’t they updated recently? The reason I ask is because we were running the uinstallations for old Java versions from Bigfix previously for another customer and the Java folders were not being cleared out (or so one of my engineers told me).

At any rate, thanks for the assistance.