How to access/What is the the WiX CommonAppDataFol

Question

I have a Windows Service which needs to run under the SYSTEM account. I am using the CommonAppDataFolder as the destination for application specific configuration content and source material such as log files, Excel template files etc... The Service installs correctly and runs, however when it attempts to load the Excel template file it encounters a problem, the following content shows that the service is able to access and write to the log file. The application is using NLog as the Logging Framework:

Application Name: AppName File Version: 5.2.0.0 Released: User: NT AUTHORITY\SYSTEM |12:24:59|NT AUTHORITY\SYSTEM|Info|AppName - Started AppName Service 2|12:24:59|NT AUTHORITY\SYSTEM|Trace|AppName - Fetching RTU alarm names from configuration file 3|12:24:59|NT AUTHORITY\SYSTEM|Trace|AppName - Fetching conditonal alarm names from configuration file 4|12:25:23|NT AUTHORITY\SYSTEM|Debug|AppName - Fetched scheduled queries

The log file is located at:

D:\programdata\Companyname\AppName\Logs

However when the service attempts to access the Excel template file it generates:

System.Runtime.InteropServices.COMException (0x800A03EC): Microsoft Excel cannot access the file 'd:\programdata\CompanyName\AppName\Templates\PsaDefault.xltm'. There are several possible reasons:

• The file name or path does not exist.

• The file is being used by another program.

• The workbook you are trying to save has the same name as a currently open workbook.

None of these is the cause. My immediate thought thereafter was, Ok... commonappdata for SYSTEM account is in a different location, and this was bourne out with a quick google on the subject. However if this is the case how is the service able to write to and access the log file, which is under exactly the same folder structure?

Is there a way that I can amend my WiX project to either provide the necessary instructions to override possible 'Logged in User'/SYSTEM account conflicts, or alternatively change the folder structure to a location where the SYSTEM account does not encounter this issue. Is there an equivalent WiX parameter for the SYSTEM account? Or am I completely wrong in my assumptions with respect to this problem?

The following is an excerpt from my product.wxs file (GUIDs, Company and Application specific info overwritten with placeholders):

  <!-- The following section deals with the deployment of the application data files including logs, templates and userguide elements-->
  <Directory Id="TARGETDIR" Name="SourceDir">
    <Directory Id="CommonAppDataFolder" Name="CommonAppData" >
      <Directory Id="dirCompanyAppData" Name="CompanyName">
        <Directory Id="dirAppNameAppData" Name="AppName">
          <Component Id="cmpDirAppNameAppData" Guid="{###}" KeyPath="yes">
            <CreateFolder Directory="dirAppNameAppData" />
            <RemoveFile Id="PurgeAppnameAppData" Name="*.*" On="uninstall" />
            <RemoveFolder Id="idDirAppNameAppData" On="uninstall" Directory="dirAppNameAppData" />
          </Component>
          <Directory Id="dirAppNameAppDataOutput" Name="Output">
            <Component Id="cmpDirAppNameAppDataOutput" Guid="{###}">
              <CreateFolder Directory="dirAppNameAppDataOutput" />
              <RemoveFile Id="PurgeAppNameAppDataOutput" Name="*.*" On="uninstall" />
              <RemoveFolder Id="idDirAppNameAppDataOutputRemove" On="uninstall" Directory="dirAppNameAppDataOutput" />
            </Component>
          </Directory>

Answer 1

Suggestion: In short, move template to somewhere under: %ALLUSERSPROFILE%.

---

File / Folder ACL: The actual ACL settings on the user profile folder itself could be the cause. Could you try to run from somewhere under %ALLUSERSPROFILE%? Should be writable by default?

On modern Windows systems that usually maps to: C:\ProgramData (on older systems somewhere else). I think the SYSTEM account should have full access here? Give it a go?

---

Test Path: To test that path: Windows Key + Tap R. Paste %ALLUSERSPROFILE% and press OK.

Also: Open a cmd.exe and go "set" (without the quotes) to see environment variables and their values. Can be helpful. Just adding for convenience (it is well-known).

---

DCOM Permissions: COM servers have associated permissions for launching. Some tools and comments to help you debug:

• Default: There are some default DCOM permissions set in: comexp.msc.

  • Launch: Windows Key + Tap R. Paste comexp.msc and press OK.
  • Right click My Computer => Properties => COM-Security.
  • I haven't looked much at these settings. A lot of flexibilty, few things that make sense?

• Specific: There can also be specific permissions set in the registry for each COM class. Maybe check using oleview.exe (or directly using regedit.exe)?

  • Find oleview.exe in Windows SDK folders. Search disk under: %ProgramFiles(X86)%\Windows Kits\[SDK-VERSION-NUMBER-HERE]\bin.
  • Locate your class (sample below: Scripting.Dictionary). See the "Launch Permissions" and "Access Permissions" tabs.

  

I can't recall having seen many custom settings here for Office apps, I could be wrong. I don't have Office to test with at the moment.