Does anyone know of an easy way of uninstalling the InstallShield engine from a PC? Our network has multiple versions of ISSCript installed (10, 11, 11.5) and now we need to uninstall them. But the ISScript MSI doesn't allow removal, even using MSIEXEC /x {product_code}, it just reports that the product isn't installed.

Any ideas on removing the InstallShield engine would be gratefully received.

Nick
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I seem to recall that IS removes the registry information which WI uses to determine installed state, e.g.

HKCU\Software\Microsoft\Installer\Products\[CompressedProductCode]
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Managed\[UserSID]\Installer\Products\[CompressedProductCode]

so you may be able to recreate the entries first, using the relevant ProductCodes in compressed form, then attempting the uninstall. I have some VBS code for managing the ProductCode<==>CompressedProductCode nonsense, if you need it.

Failing that, your only option is a a scripted uninstall. Luckily, the CLSIDs are documented (here on AppDeploy, IIRC) so it should be relatively straightforward.
Answered 07/01/2008 by: VBScab
Red Belt

Please log in to comment
0
Just curious really, but why do you need to remove the InstallShield engines ?

Multiple versions of the engine can coexist on the same system quite satisfactorily in my experience - in fact, I've seen several organisations choose to incorporate them into their core build to simplify deployment of InstallScript MSI's at any future stage.

Regards

Spartacus
Answered 07/01/2008 by: spartacus
Black Belt

Please log in to comment
0
We also have multiple versions of the InstallShield engine incorporated into our core build. Unfortunately we've now encountered the known problem with InstallShield whereby its DCOM server is set to run as an interactive user, not a launching user. This means InstallShield-based MSIs could fail to install when a non-admin user tries to run them.

The only way of correcting this when the InstallShield engine has already been rolled out to many workstations is to do an automated uninstall, then re-install with the DCOM changes.

VBScab - Thanks for your reply, I'll have a look at your solution, though as InstallShield have made the uninstall so messy we may end up manually changing the DCOM settings using dcomcnfg.
Answered 07/02/2008 by: nburgess
Senior Yellow Belt

Please log in to comment
0
Hi Nick,

Have a look at the vbscript at http://www.appdeploy.com/messageboards/fb.asp?m=19850 under the "Summary of InstallShield InstallDriver DCOM Identity problem" section to set back the identity.
Answered 07/02/2008 by: AngelD
Red Belt

Please log in to comment
0
Ah ha! Well, go with Kim's suggestion and use that script. It'll be a hell of a lot simpler than thrashing about with the WI registry stuff! :) IIRC, you'll need to add some GUIDs to the list in that script to cater for versions not listed therein but you'll have those details already.
Answered 07/02/2008 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab
you'll need to add some GUIDs to the list in that script to cater for versions not listed therein but you'll have those details already.

If you were referring to the script I provided then there is no need to update it as it will "reset" all installed versions.
Answered 07/02/2008 by: AngelD
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity