Wix Installer Going to Wrong Path on Command Line with Admin Privilege - wix

Question

I built a simple installer in Wix which will place a couple of data files in a specific folder in a preexisting product installation so that the user doesn't need to know anything about the product's installation in order to update their data files. The product stores its installation path in an environment variable (ENVVAR) which I'm using here to calculate the path of its NewData subfolder.
When I double-click the .msi or run it from the command line (msiexec /i filename.msi) it works perfectly and the files show up in C:\ProductPath\NewData. However, if it's installed with elevated privileges (msiexec /a filename.msi) the files go to the root of D:\ (which isn't even the same drive the product is installed on.)
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension">
<?include InstallVariables.wxi ?>
<Product Id="*"
Name="Product Name"
Manufacturer="My Company"
Version="$(var.Version)"
UpgradeCode="guidgoeshere"
Language="1033">
<Package Description="Description $(var.Version)" Comments="Install package for my product."
InstallerVersion="300" Compressed="yes" InstallScope="perMachine"/>
<Media Id="1" Cabinet="Cabname.cab" EmbedCab="yes" CompressionLevel="high"/>
<SetDirectory Id="PATHMAP" Value="[%ENVVAR]\NewData" Sequence="first" />
<!-- Describe the folder layout here. -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="PATHMAP" FileSource="..\New Files">
<Component Id="File1" Guid="guidgoeshere">
<RemoveFile Id="Remove_File1File" Name="$(var.File1Pattern)" On="both" />
<File Id="File1File" Name="$(var.File1)" Vital="yes" KeyPath="yes" />
</Component>
<Component Id="File2" Guid="guidgoeshere">
<RemoveFile Id="Remove_File2File" Name="$(var.File2Pattern)" On="both" />
<File Id="File2File" Name="$(var.File2)" Vital="yes" KeyPath="yes" />
</Component>
</Directory>
</Directory>
<Feature Id="FeatureId" Title="New Files for a Feature" Level="1" >
<ComponentRef Id="File1"/>
<ComponentRef Id="File2"/>
</Feature>
</Product>
</Wix>
Note that the file removal in the components is intentional; if there is an existing version of either file (which may have a slightly different file name -- not my choice) I want to remove and replace it. The patterns used to do so are in the include file and are working properly.

Answer 1

The command line: msiexec.exe /a filename.msi will not trigger installation with elevated privileges, but rather an administrative installation. Follow the link for a description - it is important that you do for a complete description. Essentially an administrative installation is just an extraction of embedded files in the MSI to make a network installation image from where people can run a regular installation of the MSI (better explained in the linked answer above) - administrative installations don't install anything at all - it is a mere extraction.
You should be able to control the output directory of the administrative installation by providing a TARGETDIR like this: msiexec.exe /a filename.msi TARGETDIR=C:\MyOutputFolder\. Your MSI is probably lacking a basic GUI to show the administrative installation's dialog sequence - which makes the extraction happen without any parameters specified (hence you output to the largest drive on the box by default). You might want to consider linking a standard dialog set such as <UIRef Id="WixUI_Mondo" /> for your MSI. You can see a step-by-step description of how to do this here: WiX installer msi not installing the Winform app created with Visual Studio 2017. This will give your setup basic, standard GUI for both regular installation and administrative installation. Very useful I think - you should also set your own license agreement - I have updated the linked answer to include that.
I think this is the end of the answer for you. Installing with /a isn't installation with elevated rights - essentially - it is just an extraction of files. But do link in that default GUI to make your MSI more standard and better overall.
A couple of comments on the environment variable approach. I have never stored anything like that in environment variables. I usually just write to my own location in HKLM and read back from there either via a custom action or using MSI's built in search feature (preferably the latter - it is much better to rely on built-in MSI features. I am a little sloppy with read-only custom actions at times, but very much against read-write custom actions. You can see why here: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups? - a digression I guess). WiX can easily define these searches and set the search result to your property: Define Searches Using Variables.
Maybe a quick link to "The WiX toolset's "Remember Property" pattern" by Rob Mensching (WiX creator). This is quite old now, there may be a new, smarter way to do this that I am not aware of yet.
If I were you, I would rather download these updated files from the network rather than deploy them like this into a "data folder" using Windows Installer. Deployment of user data files has always been problematic with MSI with its complex file overwrite rules and "quirks". Though perhaps not entirely related to your use case, here is a description of other approaches you can use to deploy data files for your application - perhaps in a more reliable fashion: Create folder and file on Current user profile, from Admin Profile. Maybe have a quick skim at least.

Answer 2

There are two types of environment variables: user environment variables (set for each user) and system environment variables (set for everyone).
By default, a child process inherits the environment variables of its parent process. Programs started by the command processor inherit the command processor's environment variables.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx
Probably, you can check machine users and if product is installed for all users point to system environment variable in Local Machine.