I implemented an installer for our product. Installer needs administrator privileges, so I used setup bootstrapper with a manifest file (as recommended here) to get these privileges on a Windows machines with UAC enabled. Installation and uninstall goes fine - the user is asked for permission and the installer does what it needs to do.
But if you run Control panel → Programs and Features and select "Change"* for installed program, an error occurs (custom, from installer LaunchConditions), telling that the installer needs administrative privileges. And I can't find any way to ask for permission in a such case - Windows simply runs the MSI file and doesn't know anything about required permissions.
Even more strange is the repair functionality - it asks for permission, but then fails to do some actions that were allowed during installation, using SetupBootstrapper.
I found a similar problem here:
But the proposed solutions are unacceptable in our case.
The only workaround for the change functionality now is to always use SetupBootstrapper and do not use the Programs and Features menu, but that is not very user-friendly and forces the user to keep the installer on his/her hard drive.
Has anybody better advise?
PS: I use WiX for creating the installer, so it would be great to hear about WiX solutions, but I'm pretty sure that it doesn't depend on the installer creation language, but only on MSI specifics.
What actions are failing? If they are actions that you added to the installation, make sure that such actions are defined with Impersonate="no" and Execute="deferred" (or "commit" or "rollback") and that they are sequenced somewhere between InstallInitialize and InstallFinalize.
Related
I know that this is a topic that has been discussed many times and people always claim: Wix bootstrappers should not require to be run elevated. Let me explain our requirement and hopefully anybody can suggest a solution that will work on all systems.
Our installed software is a Windows Service which runs elevated. The service has various settings which are stored in a database that can only be accessed by administrators. The installer also allows the configuration of those settings which is done as part of the elevated phase of the installer. And here is the problem: We cannot load the current settings from the database within the unelevated phase of the bootstrapper.
The easiest solution would be to run the whole boostrapper elevated but it seems that Wix intensively tries to prevent elevated bootstrappers by design. All discussions in this area result in wierd solutions where external tools are used afterwards to embed an application manifest after the Wix compilation.
Yes in theory we could rework the whole database credentials in order to allow the installer read access but I would like to prevent this due to security reasons. We could also keep a copy of the settings for the installer on a readable location (e.g. registry) but this is also not nice to maintain.
Is there some clean Wix-built-in mechanism to load those settings or elevate the bootstrapper from the beginning using an application manifest? We are aware that elevated bootstrappers are "not nice" to the user but our software addresses service operators that anyhow must have administrator privileges in order to operate our software.
Update #1: We already have a custom WPF-GUI as bootstrapper application utilizing the Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApplication class provided by Wix.
If it's not necessary for the UI itself to be elevated you can force the install engine to elevate so all the bootstrapper packages will be installed\executed in an elevated mode.
To elevate the engine use the Elevate method of the Engine (the Elevate gets a 'IntPtr hwndParent' parameter - I've used the IntPtr of the window and it worked great).
(Calling the Elevate method will show\pop the UAC elevation screen)
Just keep in mind that the Elevate method is not a blocking operation and from I remember it always returns true. The only way (that I've found) to determine if the elevation actually succeeded is to register to the bootstrapper's Error event and check if the error type is ErrorType.Elevate.
Keep in mind that in this solution the UI itself will remain un-elevated.
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.
I am working on a project that has been using 2 VD projects to distribute admin and user versions of installations, and now I need to switch to WiX. It was a bit painful experience with lack of documentation and all, but I managed to make something of it.
However, there is still one problem: I want to make only one .msi which will allow user to choose whether he wants to install as admin or as user. If he chose user, I don't want to ask him for elevation (as he doesn't need it), also if he chose admin, I don't want the installation to crash but to ask for privileges.
My current solution crashes in admin mode if I set InstallPrivileges to limited because the user doesn't have the permission to install, and it prompts for elevation in user mode if I set it to elevated.
My opinion is that there is no way to fix this because of compatibility with MSI, but perhaps there is some way to change privileges from elevated to limited in install time that I'm missing.
In conclusion, I want to know these things:
Is it possible to change privileges at install time
If there is no way to do so, what is the best workaround for this problem (exporting 2 .msi files or something)
One solution is to build two separate installers and then launch them via a custom WiX bootstrapper (aka Burn). The bootstrapper would be in charge of displaying the UI and launching the appropriate .msi.
Or you could separate the "admin" features into a separate .msi and then use a custom bootstrapper to install both .msis if the user selects an admin install.
Has anyone been able to get Windows Installer to use the InstallUISequence table during removal?
I started with an MSI file produced by the Visual Studio msi builder, decompiled it into WiX source code and handcrafted it, but I cannot get the installer to use my UI during removal. It insists on using a default UI provided by Windows Installer.
I have also analyzed several MSI files, and I have been unable to find one where Windows Installer will use the provided UI during removal.
I captured the msiexec logs during removal, and sure enough, Windows Installer appears to be ignoring the InstallUISequence table.
It seems that msiexec runs with minimal UI during removal. If I specify the /qf switch (use full UI) during removal, then Windows Installer does take the UI from the .msi file. However, this doesn't help the regular user, because she won't do the removal from msiexec.
Does anyone know of a way to convince Windows Installer to use the UI in the MSI file by default?
When removing an application from Add/Remove Programs, this will always run with "basic" UI.
You can't make uninstall run with full UI, the best you can do is prevent removal and force people to 'modify' (which does run with UI) and remove from there.
Whatever you do, there's still no way to prevent someone right clicking on the original MSI and selecting 'Remove', this will always run with basic UI.
The "Why" is basically because Microsoft says so. :-) Can't say I disagree as I get annoyed when ISV's get all cute when I'm just trying to remove a program.