On my Windows 8.1 laptop with a small SSD (100GB), disk space was running out. When I checked disk usage by folder using TreeSize, I found that C:\Windows\Installer was taking up over 22GB! A quick online research revealed that I couldn’t delete files from this folder safely. However, I also learned that it could be holding files that were no longer in use or needed.
On further search, I found this neat little utility called Patch Cleaner, which looks for such unused files and gives you the option to delete them or back them up to another location. When I ran it, I found that about 15GB out of those 22 were being hogged by the files that were no longer needed! All of these 400+ unused files are MSP files. I have moved these files to an external hard disk just in case there is an issue later. Restoring the files is as easy as copying them back to the installer folder.
Thank you Patch Cleaner for freeing up over 15% of my disk space!
If you see this error, it has to do with the installer configuration. More likely, you may find this with an uninstaller, particularly when the installed product versions have been mixed up. For example, uninstalling Documentum Web Publisher server files, more likely with the older versions. I say that because there are several EMC support notes about this so we may hope that the newer versions have addressed this issue.
We encountered this with an uninstaller which claimed to be version 5.2.2. The uninstaller just balked with a message, “
A suitable JVM could not be found. Please run installer again using the option -is:javahome <JAVA HOME DIR>“. That sounded really helpful, so we tried pointing to 9 JRE’s (one by one, among many more present) embedded at various paths within Documentum products. Nothing worked and we continued to get the same error.
Then we found a support note on the InstallShield support site about this message. Even though it helped us understand the potential cause, it didn’t help fix it.
Research on Powerlink brought forth similar information. The key to making progress was the discovery of the option
-is:log. This option enabled us to capture logs of the uninstaller activity.
The first thing we discovered was that the uninstaller was looking for IBM JVM 1.3.1 (yes, that old!) for the specific OS and was unable to locate it.
So we passed the path using
-is:javahome and captured the log again. Now we realized that it was appending
jre to the path and was unable to locate it. So we massaged the path to match what the uninstaller was expecting and that did it!
Finally, the command looked like the following
./uninstaller.bin -is:log log.txt -is:javahome path_to_parent_of_jre_folder