|
Stan S
Posts: 184
Joined: 2007-09-04
|
Hi,
I compiled brand-new setup package with WIX (previously I used to stick to Visual Studio setups which are no longer available in VS2012). One things I spotted that the WIX setup package generates custom actions with impersonate=yes
Problem is, resulting file does not run correctly; in a few scenarios, including shell-execute from windows, whenever elevation is involved, setup does not get administrative permissions; and it looks like the reason is that impersonate=yes means for WIX that LocalSystem must impersonate user who's currently logged in (e.g., before elevation had occured)
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. Quoting from http://wixtoolset.org/documentation/manual/v3/xsd/wix/customaction.html
Typically the value should be 'yes', except when the custom action needs elevated privileges to apply changes to the machine.
Which is exactly the case for per-machine setup packages.
I do have a client in Europe who has probems with these setups, and I am unfortunately in very inconvenient time zone to work with him directly. He sent over the logs and the problem was, adxregistrator did not get admin permissions. I am going to send him variant of setup with impersonate=no to try.
But I would like to ask you guys, was there a specific reason to do impersonate=yes in WIX per-machine setup? I am not a specialist in WIX at all; I am not sure if there's going to be a known side effect of using adxregistrator with impersonate=no. I can also send you wix setup of my product & give email of my client in Europe if you would like to investigate deeper. |
|
|
Stan S
Posts: 184
Joined: 2007-09-04
|
|
Andrei, this is about the same add-in as from my previous post; I am preparing full source code for you & sending it anyway, will provide more details on email. |
|
|
Stan S
Posts: 184
Joined: 2007-09-04
|
I got confirmation from that guy in Europe that impersonate=no worked for him when he installed from command line,
but when deploying with SCCM, no difference - both approaches work (as administrative permissions are required).
So the question stands; as far as I can see, impersonate=no works in at least one more additional scenario; may I have missed anything? |
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hello Stan,
I would advise you to follow the recommendations given in the Add-in Express manual ;)
Everything depends on the actual scenario, not just on the value of the Impersonate attribute.
You can start the installer in two ways: elevated (1) or not (2). If the installer is not elevated right at startup, you can elevate it a bit later e.g. by specifying Program Files as the target directory (3) or you may leave it non-elevated (4). Finally, a custom action may have impersonate=true (5) or impersonate=false (6).
Now, consider scenarios 2-3-5 and 2-3-6, i.e. let an administrator start a per-machine add-in installer non-elevated (2) and then choose to install the add-in to Program Files (3). If you have impersonate=true (5) on the custom action, this will result in the custom action getting the permissions of the administrator user at startup; in this case the custom action will be run non-elevated and the installer will fail because you cannot write to HKLM non-elevated. If you have impersonate=false (6), the custom action will be run with the permissions elevated as a result of installing to Program Files; these permissions are valid for installing a per-machine add-in.
The total number of scenarios is not that large but sitting at the support desk I know that it is really difficult to find out all nuances of how a given installer (custom action) was run. The possibility for a developer to choose between impersonate=true or false makes the installation more troublesome. The possibility for a developer to choose different values of the impersonate attribute on different custom actions multiplies the variants. This results in a mess that will make a non-prepared developer to ask us: hey guys, why is it that difficult to install my add-in?
The Add-in Express manual suggests using one of just two variants described in section "Registration-time Privileges" in the manual. Adhering to these recommendations and having impersonate=true which is default in Add-in Express minimizes the number of possible problems. You install a per-machine add-in is this way: you get the UAC prompt right after you start setup.exe, an adxregistrator.exe having impersonate=true uses these permissions to write to HKLM.
Hope this helps.
Andrei Smolin
Add-in Express Team Leader |
|
|
Stan S
Posts: 184
Joined: 2007-09-04
|
Yep I see, thank you for the explanation. I have never had problem with setup.exe; the problems are only with MSI
I do understand your logic behind choosing default impersonation behavior.
For my specific case, I have been advising that MSI is created for GPO-based distributions, and having said that, I think impersonation=no is the best case for me in this case but not for any other developer and not for any other plugin.
This answers my question, and thank you very much for tutoring me with WIX, too. Perhaps this thread could be very useful to someone else facing the same problem. Thank you very much and have a great vacation!
Stan |
|
Forums
Topics
Search
Help
Login
Register