Run .msi with highest available privileges on Vista

[mdavies]

The configuration:
Required Execution Level: Highest Available
Require Administrative Privileges: No
Must install for both users in the Users and Administrators groups.

What works:
Installing from the setup.exe works great and the user is granted the highest available rights. This means that users in the Users group run WITHOUT administrative rights and users in the Administrators group run WITH administrative rights. Basically, users in the Users group can't install to Program Files and users in the Administrators group can. Fine.

What breaks:
When a user in the Administrators group tries to uninstall or modify the program from Vista's Programs and Features the .msi file does not run with the highest available privileges (administrative). This means that the user can't access the locations they accessed on install during uninstall or modify.

What I tried:
I tried pointing the uninstall values in the registry to my setup.exe but Programs and Features insisted on calling a .msi. Should this work? I also tried changing all of the manifest files in the IS2008 folder to be "highestAvailable" but apparently none of those get embedded in the .msi.

Conclusion:
How do I get the .msi file to run with the highest available privileges? I can't require administrative rights since non-administrators must be able to install and uninstall as well. Is there a setting somewhere in either InstallShield or on the target machine where I can set this? Is there a resource that I can edit to set this?

Why do they make it so hard on us?

[MichaelU]

This scenario is not really supported, and thus not suggested. Microsoft seems to suggest making a package target just one of per-user and per-machine install styles; your description is that of a package which targets both. The central problem is that the Require Administrative Privileges must be set in order for MSI to elevate at the execute sequence. Your manifested setup.exe overrides this at install time, but MSI has no corresponding setting.

So the general suggestion to handle this is to create two packages, one for the per-user non-administrative case (require administrative privileges = no), and one for the administrative per-machine case (require administrative privileges = yes). Whether you write a bootstrap or cd-browser which can select the correct one, or whether you require the user to choose it, this can get the results you want.

One optional solution, though not suggested, would be to create an alternate launcher for uninstallation, register the MSI uninstall key as a System Component (ARPSYSTEMCOMPONENT) and create your own uninstall keys which reference the appropriately manifested launcher. If you want to go this route, please research all the corner cases which Heath Stewart describes on his blog before committing to it.

[mdavies]

Thanks for the insightful response.

It is unfortunate that they leave that one puzzle piece missing. It would be great if each release had a "MSI Required Execution Level" that I could set to "Highest Available". (This is a feature request if you are listening Macrovision).

I got really crazy and started editing the .msi files on the target machine with notepad and changing all "asInvoker" to "highestAvailable". I thought I was onto something when the shield showed up on the Uninstall button in Programs and Features but when I tried to uninstall it said something about not being a valid installer. Was I actually onto something or does editing those files break some checksum or signature? I still feel like there could be some InstallShield program file that could be edited to get the correct manifest in the .msi file (read: hack).

Anyway, time to send the bad news upstairs. I am sure I will be back.

[MichaelU]

You're welcome. Just so you know, such a feature would be predicated on Microsoft introducing the capability to specify such in MSI, something which I haven't seen any indication they would be likely to do.

I'm not sure exactly what your edits will have done to the MSI; MSI files do not have manifests in the way that exe and dll files do, and the corresponding exe (msiexec.exe) is a system file which you cannot change. It's possible, at least in a compressed build, that you were editing the bytes that corresponded to the manifest of some exe file contained in the MSI. If so, that would likely have invalidated the archive records of where the files began and ended.

[mdavies]

Here is the workaround.

Used ARPSYSTEMCOMPONENT to hide the default ARP entry. Copied setup.exe to a cache directory. Created my own ARP keys for the local machine and current user and pointed those UninstallString keys to the cached setup.exe. That way when the user tries to uninstall from ARP they are actually calling the setup.exe and it runs with the correct privileges.