Windows 7 - How to get elevated privileges from a MSI?

Asked By Emmanuel Stapf [ES] on 18-Jul-08 08:50 PM
On Vista, my MSI does not install properly because I'm not able to run
it as administrator when you double click on it. Is there a property to
set so that Vista automatically ask the user to run the MSI with
elevated privileges?


Rob Hamflett replied on 21-Jul-08 04:11 AM
If you set Package@InstallPrivileges="elevated", you should get the elevation prompt when Windows
Installer switches to the server side of things to do the real work.

Rob Hamflett replied on 21-Jul-08 04:18 AM
Ooops.  Have just realised I've mixed up my newsgroups.  That suggestion is how to do it in WiX.
I'm not sure how you do it for other editors, or through direct MSI manipulation.

Emmanuel Stapf [ES] replied on 21-Jul-08 01:28 PM
Actually I have been using WiX to generate this package so it is of direct
interest to me. I will try that.

Tony replied on 23-Jul-08 04:56 AM
On Jul 18, 8:50=A0pm, "Emmanuel Stapf [ES]" <ma...@newsgroups.nospam>

InstallPrivileges=3Delevated is the default value, so something else may
be your problem.
Group policy editor shows in Administrative Templates\Windows
Components\Windows Installer an entry called "Always install with
elevated privileges"

I've set it to Enabled so that installer can change Program Files
folder even when I am not running as an administrator.
Tony replied on 23-Jul-08 04:56 AM
On Jul 18, 8:50=A0pm, "Emmanuel Stapf [ES]" <ma...@newsgroups.nospam>

In any case, even if you do not want to allow always elevated
privileges to installer, I would check Windows Installer group policy
entries (with gpedit.msc) to see if there is something there that is
preventing you to run.
Phil Wilson replied on 23-Jul-08 04:51 PM
If the issue is a custom action that needs elevation you may need to change
the type to "not impersonate".

Phil Wilson
Definitive Guide to Windows Installer
Emmanuel Stapf [ES] replied on 24-Jul-08 03:02 PM
It was indeed a custom action but this custom action was executed during
the UI phase and that's why it was failing. We found a workaround by
have 2 custom actions, one during the UI that does the checking but
actually does not require elevated privileges and a second one that use
the data produced by the first one to perform actions requiring elevated
privileges. Complicated but it seems to work.

qwert replied on 24-Jul-08 05:44 PM

Your solution actually sounds more like a 'best practices' solution of
Winodws Installer.  Any system-modifying custom actions should be
deferred-type custom actions, sequenced in the InstallExecuteSequence table.
Data gathering should be done prior to the deferred phase, either earlier in
the InstallExecuteSequence sequence and/or in the InstallUISequence sequence.
Emmanuel Stapf [ES] replied on 25-Jul-08 02:30 PM
That's right. The part that was failing was the checking of a
registration key as we were storing immediately the result in HKLM
during the UI sequence but on Vista it would simply fail. It makes
things more complicated to do 2 things at once but once you know about
it, it is not a problem anymore.