0
votes

I am running the .exe file through a CustomAction in Wix. The executable is running but not with admin rights. Seems like i am doing everything correct but not sure what's going wrong. Here is the sample of my Custom Action

<CustomAction Id="RunExe" FileKey="Setup" ExeCommand="-switch" Execute="deferred" Return="check" Impersonate="no"/>

<InstallExecuteSequence>
<Custom Action="RunExe" Before="InstallFinalize">NOT Installed</Custom>  
</InstallExecuteSequence>

The actual problem is that this .exe that is executed through ExeCommand is not able to access a registry key(HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders).

Running the msi as administrator solve the problem but i need a solution in which WIX should itself able to run the command as admin or atleast give a prompt to user.

1
Whose HKCU would you expect an elevated exe would be able to access?Michael Urman
The HKCU is created each time user login into the system and is always meant for the user who is currently logged in and using the system.Harry
Yes, but a custom action with Execute="deferred" and Impersonate="no" may not be running as the logged-on user. It may be running as the SYSTEM account.Michael Urman
there is no other option to run exe inside msi besides using Execute="deferred" and Impersonate="no". Also running as s System account should have access to registry value of Current User? Moreover, i have solved the problem by not reading the registry value in Shell Folders instead calling the Shell Function of C++ to get the path to User's Font DirectoryHarry
If that were the only way, those attributes wouldn't be necessary; perhaps your EXE has an incorrect manifest on it. Anyway, while you've made a step in the right direction, it's still unclear what the custom action does, and I suspect it should be implemented using native Windows Installer functionality instead.Michael Urman

1 Answers

0
votes

A deferred custom action in a per machine install runs elevated with the system account. It's not clear what you mean by access to the HKCU key, but the HKCU key for an executable running with the system account is the system account's HKCU, not the installing user's HKCU. It would help if you said exactly what you are trying to achieve, because you might not need code at all. The install will update HKCU for the installing user if you use the registry features of WiX/MSI, so this may be a case of not really needing code at all.

It's also unclear why running the MSI as administrator solves the problem because that custom action will already be elevated in a per machine install with InstallPrivileges elevated. There is insufficient info in your post as tp your install context, but my guess is that you might be doing a per user install without InstallPrivileges elevated - that's one situation in which the MSI would run CAs under the installing user's account but they would not be elevated unless you elevate the entire install by doing as you said - runningthe MSI as administrator.