Force msi to run elevated
-
in Vista, an .msi starts out non-elevated for the user interface portion of the install and later at some stage, the service elevates the .msi to run "privileged". Without getting into specifics, I have a need to start the .msi "elevated" or "privileged" from the start and for the duration of the process. I can do this by spawning the .msi from an .exe that has a manifest with a security section embedded in it. I understand some of the "proper" ways to adapt to this "elevation" occuring late but I'm finding that there are many "custom" actions in legacy installs that just don't fit into this mold without a crowbar. So my question is, does anybody know how to force the .msi to run "elevated" without using a bootstrapper to spawn the .exe so the uninstall will work "elevated" as well? Kinda like the effect of having the ability to embed a manifest with a security section in the .msi if that were even possible.
-
in Vista, an .msi starts out non-elevated for the user interface portion of the install and later at some stage, the service elevates the .msi to run "privileged". Without getting into specifics, I have a need to start the .msi "elevated" or "privileged" from the start and for the duration of the process. I can do this by spawning the .msi from an .exe that has a manifest with a security section embedded in it. I understand some of the "proper" ways to adapt to this "elevation" occuring late but I'm finding that there are many "custom" actions in legacy installs that just don't fit into this mold without a crowbar. So my question is, does anybody know how to force the .msi to run "elevated" without using a bootstrapper to spawn the .exe so the uninstall will work "elevated" as well? Kinda like the effect of having the ability to embed a manifest with a security section in the .msi if that were even possible.
-
You can create cmd or batch script with the following command: "msiexec /i [MyMSIPackage].msi" Then, you can use "run as administrator" command on your script. Hope it'll help.
unfortunately, that still leaves the uninstall to be invoked from Add/Remove programs as standard user. I don't think the system uses the uninstallstring in the registry when it also contains keys declaring it as a windows installer package. InstallShield packages don't have the windows installer related keys so I think they use the uninstallstring they way I would like to. I have modified the unintallstring and it still runs the uninstall by running the msi directly without regards to the string I provide. I also aim to prevent the .msi from being doubled clicked on directly when using a second entity to elevate it from the start. If I provide an install CD for the product, I would need to prevent the .msi from being run directly to prevent installation mishaps. This led me to search for a way to spawn the .msi elevated hopefully without that second entity so I could prevent the problems that surround such an approach. Regardless, thanks for the help and idea.