We are populating the IIS websites to a drop down list based on the instructions provided here: Bind IIS local websites in dropdown list of wix installation?
The custom action works when the msi is launched from admin command prompt, however there is a failure when the msi is launched with out admin rights. Having the Impersonate value to no in the CA does not elevate the custom action execution with administrator privileges.
Is there a way to launch the msi with administrator privileges? How to execute immediate custom action in UI sequence with elevated access rights?
Thanks.
It's unfortunate that the IIS API (ServerManager class in .NET) requires elevation. What I do in this situation is create a bootstrapper for the MSI and mark it to require elevation.
In order to resolve the issue of running the Immediate custom action with admin rights, we had to embed the msi into an exe and display the error message if exe is not run as administrator.
ChilKat Zip 2 Secure Exe creator software was used to create an exe. https://www.chilkatsoft.com/chilkatsfx.asp
Added the following snippet in wix project: <Condition Message="Launch installer with admin rights!">Privileged</Condition> in order to display error message if the it is run in non admin mode.
Related
I'm using Wix to create an installer to deploy a simple .NET 6 web API in IIS. When I launch the .msi it displays an error popup with the message "The [application] must be launched with administrative privileges." The only option is to click OK which advances the installer to the "Setup Wizard ended prematurely" page.
Since it's an .msi there's no Run as Administrator right-click menu option, though I can install my application from an Administrator command prompt. Is there a property I can set so that the installer either doesn't require administrator privileges or automatically executes with administrator privileges?
You can run it as administrator using comand prompt.
Or try this attributes for you package
<Package InstallPrivileges="elevated" InstallScope="perMachine">
I have programmed a Bootstrapper application with WiX 3.8, which installs IIS Express 8.0 and activates IIS-features.
But the feature-activation only works, when the user is a local administrator at least.
How can i check in a WiX-Bootstrapper, if the user has admin rights?
Thanks in advance!
See:
Burn Built-in Variables
•Privileged - non-zero if the process could run elevated (on Vista+)
or is running as an Administrator (on WinXP).
This is similar to the Windows Installer Privileged property.
Also check that you are using the PerMachine attribute on the ExePackage element if you are using it.
In my wix setup, I use InstallScope="perMachine". In the interactive setup, there is no problem and it installs my application perfectly. However, when I try to install it from command line using /qn, I get the following error.
MSI (s) (60:EC) [11:51:05:268]: Product: ClickShare Launcher -- Error 1925. You do not have sufficient privileges to complete this installation for all users of the machine. Log on as administrator and then retry this installation.
Could anyone tell me why it gives such problem only in silent installation? Does command line have different user privileges?
Can I somehow detect if the user has required privileges and install the application perUser instead of perMachine? Would this be a solution?
Thanks.
You can try to set the install per user / per machine code as a parameter
C:\Users\xxxxx\Desktop>msiexec /i "program.msi" MSIINSTALLPERUSER=1 ALLUSERS=2 /qn
this helped us on a application that did NOT require admin priviledge on interactive, but did require admin priviledge on silent mode....
maybe it helps some other users in the future... (from google searches)
Starting with Windows Vista, MSI installs running from a standard user process requiring elevation cannot do so when running silent. This is due to UAC. Elevate the process prior to invoking msiexec.
I'm making a installer, a strange issue was on my way.
I use a custom action to call the sc.exe to install my service, and the MSI is already built.
But If i click the installer to install, the installation failed, the log says that the sc.exe installation failed.
But the wired thing is that if I use a CMD in administrator privilege and use msiexec to run the installer, it'll succeed.
Why?
In question itself you have answered your question.
Windows vista onward by default runs most applications with least privilege access (non-admin) in an attempt to keep both malicious virus code and inexperienced end users from damaging the system.As your application is trying to modify the system, it needs to be elevated to Admin privilege in order to run successfully.
Go through Services permissions.
To run your custom action with elevated privileges set Impersonate as No and Execute in custom action as deferred.deferred Indicates that the custom action runs in-script (possibly with elevated privileges).refer this for more info.
Let Me know if it worked for you
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
The installer be run using a specific local administrator account (in this case, the SharePoint installer account, which is a local administrator)
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?
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.
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.