How to access/What is the the WiX CommonAppDataFolder Parameter for a Windows Service under SYSTEM Account

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:

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>

Looks like a failed COM-call. I suppose the SYSTEM account might not be able to invoke Excel as a COM-object? What are you doing with this template? Perhaps there is an alternative? A little odd to use an Excel template in a service? — Stein Åsmul, May 16 '19 at 16:06
At first I would try to save the .xls file into temp directory to rule out if this simply is a permission problem (Excel COM server running under different account than SYSTEM won't be able to write to "ProgramData"). These links may also help: [Considerations for server-side Automation of Office](https://support.microsoft.com/en-us/help/257757/considerations-for-server-side-automation-of-office) | [Excel COM automation stops working when user logs off](https://stackoverflow.com/q/4234615/7571258). — zett42, May 16 '19 at 16:43
Excel is used as mechanism for generating reports in combination with an smtp client for scheduled distribution to users. It is a legacy piece of software which has stood the test of time. Recent changes to the corporate security model however, mean that config and log changes cannot be written to the C: drive. The logical alternative was the app data folder. — Paul Johnson, May 17 '19 at 10:39
Thinking about things, it wouldn't be difficult to hold the template in an an appropriate alternative folder. — Paul Johnson, May 17 '19 at 10:40
COM access itself has not historically been an issue with the software when running under the SYSTEM account. This only became an issue when the template folder was changed to the app data folder. — Paul Johnson, May 17 '19 at 10:42
Then that must be the issue. Move template to somewhere under: `%ALLUSERSPROFILE%`? Might not help, give it a go? Let me add as an answer for better formatting. — Stein Åsmul, May 17 '19 at 17:30
Regular users don't have write access to the common app data folder. Excel COM server may run as regular user, so it doesn't have write access to this folder. Possible alternative is common documents folder. — zett42, May 17 '19 at 22:21

Stein Åsmul · Answer 1 · 2019-05-20T17:33:32.540

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.

OK had a play with the above apps, though in all honesty I'm loath to make any changes as this is a customer corporate machine :-) I did check the environment variables though and %ALLUSERSPROFILE% is set to the 'commonappdatafolder' destination utilised in the WiX product.wxs file. Also confirmed that current production software which runs on a different machine currently works, however when I install this flavour of the software onto my development machine it responds with the same COM error as the new software release. — Paul Johnson, May 22 '19 at 11:04
So looks like something in the config between the two machines is different. Will chase up with desktop support. — Paul Johnson, May 22 '19 at 11:05

How to access/What is the the WiX CommonAppDataFolder Parameter for a Windows Service under SYSTEM Account

1 Answers1

Linked