This documents the access needed if one chooses to not use the local system user and decides to configure Centro services with a custom user. The table below summarizes the changes followed by details for each of the permissions needed.
R (Centro 7.10)
TempFolderLocation (if configured)
Folder access required by the three Centro services
To ensure Centro and its components operates correctly, one should verify/set folder permissions in three areas as described below.
All three services (Webapp, PipelineHost, PipelineManager) require R/W access to C:\ProgramData\Actify\Centro7 for some internal storage (e.g. ShapeSearch index, pipeline databases etc).
The Webapp also requires access to the CatalogStorageLocation*. This is residing inside to the Webapp installation folder by default, so it's granted automatically, but if it's manually changed and/or if the ApplicationPool user is changed, it may need to be adjusted as well.
Implicitly, each service requires access to their own install location. This is granted automatically on install time but if the user that the service runs under is changed, care needs to be taken to grant access for that user to the respective install locations:
Access to C:\Program Files\Actify\SpinFire may also be required by the PipelineHost service to read the SpinFire Ultimate license file. This is again granted automatically but may need to be re-adjusted in case of a user change.
For ease of configuration it might be simpler to assign access to C:\Program Files\Actify instead.
Additionally, the services may require access to the folder specified by the TempFolderLocation, if this is overridden in each of the services' centroSettings.config. The value of this is C:\ProgramData\Actify\Centro7\temp by default, so it's implicitly true thanks to the first requirement.
The easiest option by far is to have all three services run under the same service account user, and grant folder access of C:\ProgramData\Actify\Centro7 to that user. There is of course a complication in that the Webapp is ran by an ApplicationPool. The application pool can be however configured so that it also impersonates the same service account user as the other two services: