Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

CustomAction run as administrator

I have created a custom action:

<CustomAction Id='AddEventLog' BinaryKey='CustomActionEventLog.dll' DllEntry='AddEventLog' Return="check" Execute="immediate"/>

Install sequence

<Custom Action="AddEventLog" Before="InstallFinalize"  />

My installer does pop up and say that it needs admin rights to run. Which I grant it.

InstallPrivileges='elevated' InstallScope='perMachine' AdminImage='yes'

However when it runs the custom action it doesn't work because its not running as administrator.

I even tried adding the following to app.manifest on my custom action project dll. It didn't help.

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

I have scoured all the tutorials and forum posts I can find on this subject. Noting has worked yet.

If anyone has any better tags for this please feel free to add them I have been struggling with this all day.

Update for clarification:

While my customAction does work with EventLog I am not using http://schemas.microsoft.com/wix/UtilExtension Util:EventSource. It is a genral question can you even force a customAction to run as administrator?

like image 774
DaImTo Avatar asked May 23 '16 12:05

DaImTo


People also ask

What is a custom action?

What is a Custom Action? A package in MSI format uses the Windows Installer service provided by Microsoft to install and configure an application (a widely-known fact within professionals in the industry).

Can I use immediate custom action to change the system state?

According to Windows Documentation's best practices, "you should not attempt to use an Immediate custom action to change the system state, because every custom action that changes the state needs to have a corresponding rollback custom action to undo the system state change on an installation rollback."

Should the Windows Installer impersonate the installed user when executing custom actions?

This attribute specifies whether the Windows Installer, which executes as LocalSystem, should impersonate the user context of the installing user when executing this custom action. Typically the value should be 'yes', except when the custom action needs elevated privileges to apply changes to the machine.

What does the scheduling attribute of a custom action indicate?

This attribute indicates the scheduling of the custom action. This attribute's value must be one of the following: deferred Indicates that the custom action runs in-script (possibly with elevated privileges). immediate Indicates that the custom action will run during normal processing time with user privileges.


2 Answers

To run any custom action with administrator privileges you must run the custom action during the Server portion of the installation. ie: it must be a deferred custom action. Otherwise, I think you get a consent.exe message box asking for administrator privileges.

All msi installs work in two parts, Client and Server portions of the install. The Client portion is where you see the UI and set properties that may determine where things get installed and what gets installed (they must be marked Secure for the Server portion of the install to have access to them). The Server portion is what actually puts the files on your system. This always (??) requires administrator privileges because it can be writing stuff into Program Files and other protected file locations.

These custom actions must be marked "Execute='deferred'" and must also be scheduled between the InstallaInitialize and InstallFinalize.

Also to note, if you want to use values of any properties from your installation within the custom action you need to use a separate custom action which sets a specially named property with a special format. You then get the property values in your custom action querying the CustomActionData of the session object. There are lots of examples out there you can find.

like image 65
Brian Sutherland Avatar answered Sep 28 '22 10:09

Brian Sutherland


Disclaimer, I've not done this previously, and personally I'd take the other approach of using the wix extensions, but you should be able to give elevated permission to your custom actions by using deferred execution and not impersonating the current user. So in your case, Execute="immediate" is what's standing in your way.

<CustomAction Id="MyCustomAction" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="no"/>


<!-- -or- -->


<CustomAction Id="MyCustomAction" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="commit" Return="check" Impersonate="no"/>

Source

like image 44
Patrick Allwood Avatar answered Sep 28 '22 10:09

Patrick Allwood