windows Installer - uninstalling previous version when the versions differ in installation policy (per-user, per-machine)

Question

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 de

Answer 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.

Answer 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).

Answer 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 :-).