10

I have built a Windows Installer package using WiX 3.6 that embeds a custom managed (C#) action.

At this stage, the installation requires that

  1. The installer be run using a specific local administrator account (in this case, the SharePoint installer account, which is a local administrator)
  2. User Account Control be disabled

There really isn't a way I can bypass requirement #1, because the managed action can only perform certain steps if it runs in the context of the SharePoint installer account.

I would like to remove requirement #2 and let the installer properly run even if UAC is enabled.

I've researched the issue quite extensively but still can't get it to work. I have set InstallScope="perMachine" in my package, which seems to properly prompt for UAC elevation, but the installer still fails with the infamous 2869 error.

The main problem is that my custom action is configured with Impersonate="yes" because it has to run in the context of the current user, not the local administrator account. When I search online, almost all "fixes" point to Impersonate="no" in the custom action, but that's not an option for me.

My question therefore is: is there a way to run a custom managed action with the identity of the current user without requiring UAC to be completely disabled?

Raphael Londner
  • 201
  • 1
  • 2
  • 3
  • Love an answer to this as well. – Rick Glos Jan 02 '13 at 17:33
  • I am trying to do this same thing. The way I'm trying to get around it is creating an EXE that has admin privileges required in the app.manifest (http://stackoverflow.com/questions/3915370/impersonating-in-net-using-process-start-and-uac/3915492#3915492). I then call that EXE as a type 2 deferred custom action that impersonates the user (http://stackoverflow.com/a/8828776/1203288). However, this works on my machine, but I'm having trouble on other machines: it's not even running on other machines as long as the require admin is in the app.manifest. Hope this gives you a good start. – bsara Jan 17 '13 at 16:55

2 Answers2

7

When you use Impersonate="yes" your Custom action runs without administrative privileges with the credentials of the currently logged user.

When Impersonate="no" your Custom action is run in System context. When running in system context, the custom action has full access to the system.

From WiX CustomAction element documentation, Impersonate attribute:

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.

Alexey Ivanov
  • 11,541
  • 4
  • 39
  • 68
  • 1
    I did this, but my application throws a System.UnauthorizedAccess exception. How that could happend, when I have system rights? – Patrick Jan 08 '14 at 11:56
  • 2
    @AstralisSomnium Try to make sure your custom action is really run with full access. `Impersonate="yes"` is valid for _deferred_ actions only. In their turn, deferred actions do not have full access to installation properties, you can use only `CustomActionData`. – Alexey Ivanov Jan 08 '14 at 15:29
  • 6
    I think it's actually the reverse. According to WIX documentation: "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.' So Impersonate="no" means your action runs as LocalSystem, which has full access to the machine, and Impersonate="yes" means your custom action runs with the privileges of the installing user. – Mr. Bungle Jan 13 '14 at 03:19
  • @Mr.Bungle You're right! I must have confused it with `NoImpersonate` bit in the MSI tables. Yet [this article](http://blogs.technet.com/b/alexshev/archive/2008/02/21/from-msi-to-wix-part-5-custom-actions.aspx) says the same as I did: `Impersonate="yes"` runs in system context. Perhaps something has changed… – Alexey Ivanov Jan 13 '14 at 06:43
  • 2
    As per the other comment, You have this the wrong way around. `Impersonate="no" ` will run as the system user (`NT AUTHORITY\SYSTEM`). Please amend or delete your answer – wal Feb 18 '15 at 23:49
  • 1
    @wal Thanks! I've edited the answer and also added a quotation from WiX documentation. – Alexey Ivanov Feb 19 '15 at 11:54
2

Where are you referencing the custom action?

Having the .msi running with elevated privileges might not be enough. To be sure that your custom action works with elevated privileges you also have to use a deferred custom action and reference it in the InstallExecuteSequence. This might not solve your problems, but the articles linked at the bottom goes in detail in explaining the UAC logics during an msi installation.

Basically, not everything the installer does carries the privileges with it, an you have to be sure to run the custom action when the installer is using the elevated privileges.

Source: http://blogs.msdn.com/b/rflaming/archive/2006/09/30/uac-in-msi-notes-when-general-custom-action-mitigation-fails.aspx

I hope you find this information useful, I might be of more assistance if you share your custom action code.

blalasaadri
  • 5,990
  • 5
  • 38
  • 58
Epiderma
  • 31
  • 2
  • 1
    While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – Mathias Müller Aug 13 '14 at 09:04
  • 2
    You're right sorry, edited it with a better answer. I'm new and still learning how to use stackoverflow. Thank you. – Epiderma Aug 13 '14 at 09:16