1

We have an installer created with the WiX toolset that needs to run escalated to do a per-machine install, but also needs to drop some things (e.g., installer logs, license info) in the current user's folder, because the application needs to access them later when run non-escalated.

Put another way, we start several functions using rundll32 from within the installer, and when the installer is run by a non-privileged user who has entered the Admin's credentials into the UAC prompt, when our code asks the system for the local AppData folder path we get the path to the folder for the Admin, not the installing user.

I guess this makes some sense, since the program is being run in the privileged context of the Admin. But we really need the installing user's info. And no, we cannot make it a pure per-user installation.

Is there a way to determine, when an application is being installed by a non-privileged user who's provided the administrator's credentials for escalation, the folder areas that correspond to the original, non-privileged user.

Thanks.

NoelC
  • 1,407
  • 10
  • 16

2 Answers2

1

If you literally mean that there is code calling APIs to get the folders, then this is often an issue. For example impersonation won't load the user's profile (as an interactive logon would) so folder locations can be unexpected.

There are a few things you can try although I don't know if they will work:

  1. Pass the [AppDataFolder] property into your custom action and see if it's the one you want. I think these folder locations are resolved early in the install (before elevation) and so might be the current user's locations.

  2. The LogonUser and UserSid properties refer to the current interactive user. You might be able to get the path with variations of ImpersonateLogedOnUser, ShGetFolderPath, registry loading as described here:

How can I get the path of a Windows "special folder" for a specific user?

PhilDW
  • 20,260
  • 1
  • 18
  • 28
0

I think you are over complicating this with the API calls. Once installed an installer can be ran again without needing permissions. This can be triggered by using resiliency or it can be triggered with say an active setup key to force the repair. Once the installer runs again it can evaluate the current user and reinstall the per-user components.

That said this type of behavior is often misinterpreted as broken or annoying so another potential pattern is to install these files in a per-machine location and have your application copy them to the per-user locations when the application runs.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Thanks, but your suggestion is not a good match for our needs. The key issue is that the install is being performed by a particular user, but escalation to an admin privilege level is required for the install- yet the install logs need to be in the user's area so that if a bug is reported by a user running non-privileged, the data is available to the bug reporter subsystem, and thus sent in to us. I don't want to escalate the bug reporter. – NoelC Dec 19 '17 at 18:55