Uninstall issue (secure uninstall) with Basic MSI project

[KingWulfgar]

We are migrating our old InstallScript project to a Basic MSI. Our product is a parental controls suite and as such, we have a fairly secure uninstall procedure. The user must provide their account credentials (username and admin password) before removal is allowed. This way, not just anyone who uses the computer can remove our product.

The problem we are coming across is that the Uninstall/Remove button in the Control Panel circumvents all our custom dialogs and actions that are supposed to validate their admin credentials. It just goes all out on a full removal and skips over all our custom actions/dialogs. (So does just msiexec with the /x option.) There was a "Not PRESELECTED" condition on one of them (which I would have thought meant a preselected "remove"), but taking that out didn't seem to have any effect at all.

Using the ARPNOREMOVE option is not a good solution because any kid with Google and 5 minutes can figure out how to hack our Uninstaller registry entry and add back the "no remove" option.

Is there a way to make the Add/Remove Control Panel Uninstall button ALWAYS force a maintenance run (i.e. - you always get the Modify/Repair/Remove screen)? Or, is there a way to make it at least drop through our custom actions in the sequence so we can catch the uninstall and make them provide their account credentials?

There should be no way (short of hacking our files/registry keys out manually) of removing our product without going through the proper administrator verification process (for our own user accounts).

[#2]

If the users are running non-administrator accounts then they cannot remove your installation if you set the ALLUSERS property to 1 during the initial install. In this case, it would require an Administrator to remove the product from the machine (Non-administrators can modify the product).

What you would be doing here is a per-machine installation:
http://msdn.microsoft.com/en-us/library/aa370810(VS.85).aspx

[KingWulfgar]

Thanks for the reply, but I'm still stumped.

Our software (because of what it does) requires you install it as an Administrator already. However, that is not enough to guarantee security (inability to uninstall the product). In many many cases, our users are the Administrator of their Windows machines, yet they are not administrators of our software (their wife or parent or accountability partner is). Those people should not be allowed to remove our software (unless they can provide the proper credentials for their customer account).

We are already effecting a per-machine install (ALLUSERS = 1) and the software is put in the Run key to always run no matter the user logging in.

The thing that gets me is that this worked in our old InstallScript install. Suddenly, MSI lets you completely shortcut any conditions you have on any actions and immediately removes the product (which is not good in our case).

[KingWulfgar]

After some further investigation into it, it seems like the Add/Remove Control Panel (Programs and Features on Vista) ALWAYS executes a remove with no UI. Is there any way to get the UI version of the uninstall (maintenance mode) to fire from ARP?

Is this a limitation of MSI or just something subtle we're missing within the InstallShield IDE?

[#5]

The "Remove" button runs msiexec /x {ProductCode} in essence, so there's no way to integrate a UI or anything like that.

Windows Installer doesn't understand the concept of a "Software Administrator" or any specific rights to apply to a certain Administrator account. MSI is designed around user groups, so any Administrator should be equal.

If your software uses domain specific concepts for deployment then perhaps you might be better served staying in the controlled environment provided by InstallScript. Windows Installer is explicitly designed to provide a common installation point for system administrators so that they can perform maintenance and customization in a consistent manner. Requiring a specific Administrator to alter the system state would be at odds with this design.

Essentially, I wouldn't describe it a limitation so much as intentional functionality.

[DLee65]

I am not sure if this would work, but what if you insert a custom action 19 (error) if a certain private property is not set. The private property can only be set using the full UI.

I would set a condition on this custom action also to always run if the UILEVEL is not equal to 5 and if REMOVEALL property is set. I think this might prevent the uninstall using ARP, unfortunately it does not give you a clear path for legitimately uninstalling the application.

I do not believe that it is possible to override the UILEVEL for uninstalls executed from Add/Remove Programs.

[KingWulfgar]

DLee65 wrote:
I am not sure if this would work, but what if you insert a custom action 19 (error) if a certain private property is not set. The private property can only be set using the full UI.

I would set a condition on this custom action also to always run if the UILEVEL is not equal to 5 and if REMOVEALL property is set. I think this might prevent the uninstall using ARP, unfortunately it does not give you a clear path for legitimately uninstalling the application.

I do not believe that it is possible to override the UILEVEL for uninstalls executed from Add/Remove Programs.

Thanks, DLee. That is exactly what I tried and it worked, but because it makes it really really ugly to legitimately uninstall the app, we decided we didn't like that solution. Basically, the only way to uninstall at that point is to launch the Setup.exe that installed it. Plus, it wasn't always 100% successful. Sometimes, it randomly decided to just do a complete UI-free reinstall when I launched Setup.exe (expecting the Maintenance dialog).

At this point, we've don't have a huge impetus to go to MSI and with the drawbacks we've found of the architecture, I think we're going to just be straight-upgrading our oldschool InstallScript project. We toyed with doing an InstallScriptMSI, but even that seems to require you to script the whole UI sequence and recreate our dialogs that we already recreated once. What a pain. Plus, we couldn't even be guaranteed (without doing a lot of work to test it) if we'd get the Full UI Remove we desired.

If anyone has any further input, I'd love to hear it, but at this point, it seems like both Basic MSI and InstallScript MSI aren't really going to buy us anything and just gives us a world of trouble to try and workaround to keep our product secure (i.e. - cannot be uninstalled by even the Administrator of Windows without administrator credentials for our software).

[KingWulfgar]

DLee65 wrote:
I am not sure if this would work, but what if you insert a custom action 19 (error) if a certain private property is not set. The private property can only be set using the full UI.

I would set a condition on this custom action also to always run if the UILEVEL is not equal to 5 and if REMOVEALL property is set. I think this might prevent the uninstall using ARP, unfortunately it does not give you a clear path for legitimately uninstalling the application.

I do not believe that it is possible to override the UILEVEL for uninstalls executed from Add/Remove Programs.

Well, I had typed up a whole big response, but apparently the forum here decided to toss it!

Thanks for the response DLee. I was able to get that to work, but with it being so hacky, we just couldn't justify using that. It makes removal VERY difficult (essentially you have to have Setup.exe laying around and even that didn't work 100% of the time).

At this point, MSI doesn't really give us any advantages and has a whole lot of disadvantages (for our software), so we're planning on sticking with the old-school InstallScript we have already. I had high hopes for rewriting our installer as a true MSI, but unless there's a way to legitimately prevent a silent remove (and I don't think there is), we can't use it. We even looked into making it an InstallScriptMSI, but even that you have to script the whole UI (which our old InstallScript already does and it works already) and recreate all the custom dialogs again. It doesn't really seem to give us any advantages either.

If anyone has anything further to add on the subject, I'm all ears. I just think the way MSI was designed precludes us from using it.