[wix-users] Running BA elevated

[Hoover, Jacob]

BA's don't modify machine state, installers and in controlled conditions the engine does (for ARP, autorun, etc).

Normal flow, you have a complete plan in place with rollback plans for the bundle before elevating. For some situations, you may have found some fringe cases where you might need elevation prior to this, but the proper answer is probably going to be to submit a WIP to teach the engine the ability to elevate early when this info is requested.  It is a hack to just say, give my UI Admin because it's hard to make the engine request the information for me.

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Vanniekerk, Tyrel (GE Healthcare) via wix-users
Sent: Monday, October 28, 2019 8:53 AM
To: wix-users at lists.wixtoolset.org
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>
Subject: [wix-users] Running BA elevated

Hi,

I have seen many many many posts and articles where people try to run the Bootstrapper part of their installer in elevated mode.  The purists will all chime in that it's not supported, should never be done etc., but I have had several cases where our installers (bootstrapper part) need elevated permissions because of silly Windows restrictions.  We 'solved' it, and I say solved, but it's not a real solution in my mind, by having a C# launcher application that has it's manifest set to launces elevated and that has buttons to run the various installers, which are then also running elevated, so no problems.  The installers themselves will give and error if the process is not running elevated, requiring the user to click "Run as Administrator'.  All fine and well, but there has to be a better solution this this, or as I have seen suggested, modifying the WiX Toolset source code to update the manifest files.

Now before you get angry and try to explain why this should never be needed, let me explain.  An option in the bootstrapper XML to enable elevated would be nice, then it's up to the user to decide if they want to do that.

I have two situations I can think of at the moment that I have not been able to get around yet.

  1.  One of our installers allowed the user to enter an username/password that the elevated MSI installer would use to create a local user for batch processing.  Problem is, Windows requires an elevated process to check the username and password policies.  So the installer was not changing anything, but it could not ensure the username and password were valid for Windows, so the MSI portion could fail.  Not acceptable.
  2.  I have not found a way yet (other than forcing our internal MSI to run in repair mode during a change, not desirable) to get the MSI installer to update our registry settings during modify mode.  The component is already installed and I don't see a way to get it to update.  So I a left to either create a custom action to update the registries manually, having to duplicate the code that was in the registry component, or I have the bootstrapper update the registry at the start or end of the install, which requires elevated permissions.
  3.  I think there was another case where I needed to check if all the required IIS components were installed that also required an elevated process.

So, other than possibly religious reasons, why is the option to run BA elevated so strongly blocked?

Thanks,
Tyrel

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.