WIX/MSI CopyFile doesn't work when running through SSH

Question

I have built a simple MSI file with WixTool 3.10.
One of the feature is to copy a file which already exists on host.
Everything is working fine when I install this msi through Remote Desktop.
However if I login through SSH and run this MSI, the file doesn't get copied.
Here's a simplified version of my wxs file:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="my product" Language="1033" Version="1.0" Manufacturer="Allen" 
           UpgradeCode="PUT-GUID-HERE">
    <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
    <MediaTemplate EmbedCab="yes" />

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLFOLDER" Name="My Folder">
        </Directory>
      </Directory>
    </Directory>

    <Property Id="FILEA">
      <DirectorySearch Id="SearchSourceDir" Path="[SOURCEDIR]">
          <FileSearch Name="fileA.txt" />
      </DirectorySearch>
    </Property>

    <Component Id="cmpCopyFile" Guid="*" Directory="INSTALLFOLDER">
      <CopyFile Id="CopyFileA" SourceProperty="FILEA" DestinationProperty="INSTALLFOLDER"/>
    </Component>

    <Feature Id="FeatureCopyFile" Title="Copy file" Level="1">
      <ComponentRef Id="cmpCopyFile" />
    </Feature>
  </Product>
</Wix>

And here's the command I used for install:

msiexec /i test.msi /l*v install.log

Inside the log I can see the feature and component gets installed, however the file didn't get copy.
Is this the expected behavior? Any help or advice is appreciated.

Update: Here are the logs for local install and remote install install_local.log install_remote.log

Answer 1

It might make a difference if you use the correct name for the case-sensitive source property, which is SourceDir

https://msdn.microsoft.com/en-us/library/windows/desktop/aa371857(v=vs.85).aspx

Answer 2

SecureCustomProperties: The remote install is silent and the client one is interactive? This could affect the availability of the APPSEARCH property in deferred / silent mode.

You need to mark properties secured in order to have them pass from client- (GUI) to server process (Install). Could you please try to change this in your WiX source and recompile:

Current:

<Property Id="FILEA">

Updated:

<Property Id="FILEA" Secure="yes">

Then recompile and test install.

---

Alternatively you can modify or "hotfix" the SecureCustomProperties property in your current MSI file to include FILEA. That involves prefixing the current value for SecureCustomProperties with FILEA along these lines:

FILEA;NETFRAMEWORK20;WIX_DOWNGRADE_DETECTED;WIX_UPGRADE_DETECTED

If you recompile the MSI from the WiX source this will be done for you - obviously. Adding this in case the source won't compile with the Secured attribute specified.

---

Apart from that, this looks odd from the local log file:

PROPERTY CHANGE: Adding FILEA property. Its value is 'C:\Users\tetter\fileA.txt\'.

But let us see if the above solves the problem.

---

Avoid File Copy?: What SSH client? Never tried to deploy MSI via SSH. Not 100% match, but maybe read my answer on the issue of config files and settings management. It would very likely be more reliable to install the file by more robust means - as you can clearly see from the current problems. For example by using the IniFile table or to use WiX's XML writing capabilities.

Application Download: To be honest, why not download these settings from a database or from a UNC path directly from your application? Should save you any deployment issues, and you have better debugging abilities (debugging in real-time on test computers, no "one-shot" deployment problems to have limited debugging ability to investigate), and you can ensure that all clients have the latest settings provided they can access the UNC path? Just an idea.

Cause: If I was to theorize on the cause, I would say your MSI runs in your admin context via Remote Desktop with access to your login context and access token and hence have rights on the share. When you kick off the MSI from SSH it might run in system context, with no network access at all - or very limited. Just a guess.