This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Run .msi with highest available privileges on Vista
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 02, 2007
12:13 PM
Run .msi with highest available privileges on Vista
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?
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?
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 03, 2007
10:36 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 03, 2007
11:01 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 03, 2007
11:15 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 05, 2007
07:27 PM
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.
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.