windows Installer - uninstalling previous version

问题:

We have a visio plugin (say, version 1) which was installed by the User with Admin rights as per-user (‘Just me’ otpion) and the msi installer was created using setup and deployment of visual studio. Later because of organization policy in place to revoke admin privileges for all users were revoked. So the new version (version 2) needs to be installed by a IT admin as per-machine (everyone option) in order for the plugin to be available for all users on that machine and also to uninstall the old version (version 1) installed by the User whose permissions were revoked.

We are trying to automate the uninstallation to avoid manual intervention. The utility works by detecting all installed instances of the application by looking at registry keys on that machine and forcing uninstall with msiexec. But msiexec fails to uninstall the version that was installed by other user with exitcode as 1605 - This action is only valid for the products that are currently installed

If the User (who installed the version 1 plugin) is given admin rights to uninstall the application, he is able to manually uninstall it that proves that the application not tampered and is in a state that can be uninstalled without any issues.

Any pointers about how to programmatically uninstall application installed on a machine that has been installed by the other user with ‘Just me’ option would really help

回答1:

It's not just a Visual Studio problem. Windows Installer doesn't allow the installation context (user/machine) to change durin an upgrade. You have to perform logon as the user profile(s) that did the installation(s) and remove them before installing the new per-machine install.

回答2:

I found some further documentation:

The following approach can be used to eliminate existing per user installs and install the new package per machine if you are using Installshield. The same should be possible to do with your own replacement CA for "ISSetAllUsers" if you don't use Installshield. The following assumes a properly populated Upgrade table for a "major upgrade" - do a search for info on major upgrades:

1. Insert Installshield's ISSetAllUsers custom action before FindRelatedProducts. This action will read the value of ALLUSERS for the existing install, and enforce it for the new setup. See below for how to get this action added.
2. Move RemoveExistingProducts early in the sequence, before InstallInitialize.
3. Right after RemoveExistingProducts use a set property CA to set ALLUSERS back to 1.
4. It is very important that both the above operations are done before InstallInitialize. If the value of ALLUSERS changes after InstallInitialize all components will be in an unrecognized state after installation and a self-repair will generally occur.

In order to insert the ISSetAllUsers custom action you need to do as follows:

1. In Installshield select Tools -> Options -> General -> Enable "Automatically create ISSetAllUsers action". Click OK.
2. Go to the upgrades view and insert a dummy entry.
3. Go to direct editor, remove the dummy entry from the Upgrade table.
4. The ISSetAllUsers action should have been inserted. Go to the InstallExecuteSequence view and move the action before FindRelatedProducts.

Important: Please note that the ISSetAllUsers custom action should never be added to any project unless you need to perform a per-user to per-machine migration. The action will effectively ensure that the new setup is installed with the same value as the old setup unless a set property custom action is used to force a per machine install (as we do in the scenario described above).

回答3:

I created a package to do this years ago, but for my life I can't find it. As I recall it involved using a major upgrade and the Upgrade table to uninstall the per user installation in the context of the right user, and then using a set property custom action to change the value of ALLUSERS before the new install hits InstallInitialize and performs a new install per-machine. This means that you must move RemoveExistingProduct as early in the InstallExecuteSequence as possible, and then do the set property right after it.

Sounds crazy, but as far as I recall it worked after some serious testing and debugging. The critical part is to run the new installer as the user who originally installed the per user install. This is not always easy to do logistically since sccm might run the install in a different context. It also might be that you have to move the RemoveExistingProducts even earlier in the sequence, and move some standard actions behind it to make it work. I don't recall exactly - sorry. You could use ActiveSetup to schedule the install to run "once per user". You then might need to suppress the setup GUI to avoid bombing out with error messages to each and every user if the install isn't present.

Note that the above is difficult to do in Orca. Try in Wise for Windows Installer or Installshield. Note that Installshield packages also has their own way of reyanking the value of ALLUSERS, and you might need to disable their variant to make yours work. It isn't supposed to be easy :-).