Uninstallation Paradox
We have been having some trouble with a couple applications we are deploying over SMS which replace very old and dated WINSTALL applications (the point here is they are not MSIs). I cannot imagine no one has run into this before, and from my research and much to my surprise there is no documentation on how to handle this at all. I'd like to get the community's input on the best practices to handle this. The problem is as follows:
(Software X 1.0) was deployed as an exe, and therefore has no product code listed, so when trying to deploy (Software X 5.0) as an MSI, it simply installs over it, overwriting anything with the same name, and leaving all others intact. Sometimes the uninstaller has a silent option, which can be called using the WSH Run method in VBScript, but others do not work so well.
Another, more difficult scenario we have run into: (Software Y 1.0) was captured using IS Repackager, and some protected system files were left in the MSI, and it was deployed. We noticed this when we tested an upgrade to (Software Y 2.0) and it could not uninstall because it tried to remove the protected system files. An MST was created to remove this from the package, but simply putting that into a custom action wasn't possible because it had to encounter the InstallFiles standard action to copy the corrected MST in order to remove the existing product. However, it's silly to remove existing products after installing because it will remove all files and keys with the same path. As you can see this presents a paradox where we are stuck with the old package.
All inputs and suggestions would be appreciated, and I think it will benefit the community to have some documentation on this.
(Software X 1.0) was deployed as an exe, and therefore has no product code listed, so when trying to deploy (Software X 5.0) as an MSI, it simply installs over it, overwriting anything with the same name, and leaving all others intact. Sometimes the uninstaller has a silent option, which can be called using the WSH Run method in VBScript, but others do not work so well.
Another, more difficult scenario we have run into: (Software Y 1.0) was captured using IS Repackager, and some protected system files were left in the MSI, and it was deployed. We noticed this when we tested an upgrade to (Software Y 2.0) and it could not uninstall because it tried to remove the protected system files. An MST was created to remove this from the package, but simply putting that into a custom action wasn't possible because it had to encounter the InstallFiles standard action to copy the corrected MST in order to remove the existing product. However, it's silly to remove existing products after installing because it will remove all files and keys with the same path. As you can see this presents a paradox where we are stuck with the old package.
All inputs and suggestions would be appreciated, and I think it will benefit the community to have some documentation on this.
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
ghosh.kunal
14 years ago
Regarding your first scenario where 1.0 was deployed as an EXE, what was the uninstall mechanism for 1.0? Whatever you install, MSI or EXE it has got to have some entry for an Uninstall string in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. You can try getting the uninstall string from there and include some logic in your MSI, that if it detects 1.0 is installed, execute the uninstall string. Since you said 1.0 is not an MSI, it should not be a problem.
Posted by:
anonymous_9363
14 years ago
Whatever you install, MSI or EXE it has got to have some entry for an Uninstall string in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\UninstallUtter tosh, I'm afraid. There will be an entry there IF the vendor wrote his installer to do so. If it's not a newer InstallShield-driven installer, or an MSI, there's no guarantee that there'll be such an entry. Remember, the OP said this was a legacy app so it might pre-date even Windows 9x which introduced the Add/Remove Programs applet in Control Panel.
Posted by:
smooochy
14 years ago
Thanks for replies. For that first scenario I'm trying to run a custom action that will run the respective uninstaller for each application (the one already included on the destination node). I tried doing it in VBScript but I couldn't think of any way of doing it without using any WScript methods. I even had a neat little (like 5 line) script like this:
And for the longest time I could not figure out why it did not work. Most of the applications are not THAT old, especially not pre-Windows 9x (to my knowledge). I'll post back here when I have some sort of breakthrough.
'Create object for checking for Subversion 1.0
Set WshShell = WScript.CreateObject("WScript.Shell")
err = 0
'Look for Subversion 1.0
On Error Resume Next
UninstallStr = WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Subversion_is1\UninstallString")
'If exists then uninstall
If er = 0 then WshShell.Run (UninstallStr & " /silent")
And for the longest time I could not figure out why it did not work. Most of the applications are not THAT old, especially not pre-Windows 9x (to my knowledge). I'll post back here when I have some sort of breakthrough.
Posted by:
anonymous_9363
14 years ago
There's little point in trying to execute a command using a string that may not be present. Does the registry in fact have an entry for the 'UninstallString' value?
Posted by:
pjgeutjens
14 years ago
(Software Y 1.0) was captured using IS Repackager, and some protected system files were left in the MSI, and it was deployed. We noticed this when we tested an upgrade to (Software Y 2.0) and it could not uninstall because it tried to remove the protected system files.
We've run into this problem a few times as well. Our solution was to replace the cached MSI for the affected product in <WinDir>\Installer.
To identify the msi you need to go look in the registry at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products ( if the product was installed with NT/SYSTEM credentials) and find the correct subkey for your product. Under the InstallProperties key you'll find a LocalPackage value identifying the name of the cached MSI.
So basically you take your faulty MSI and modify it to remove the references to the systemfiles. Then you either overwrite the correct cached MSI, or simply copy it to the Installer folder and change the LocalPackage value. An uninstall will then use your "new" MSI.
I have to say even though this works, I always get a bad taste in my mouth when talking about it, cause it's quite a dirty solution...
Hope it helps
PJ
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.