Service Logon

There are 3 scenarios that would require setting the service LogOn to one of the OAS Services running on Windows.  The following information is not applicable for Linux.

Connecting to classic DCOM OPC Servers that run under the desktop account
The OPC Client connection to third party OPC Servers runs in a Windows Service called OAS OPC (previously called OPC Systems Data). By default this Windows Service runs under the System account.

If you are receiving bad data quality from a classic OPC Server it is most likely due to a security logon restriction in the operating system. Some OPC Servers cannot run as a Windows Service, so you may need to either use the OPC Data Fix or set the OAS OPC Service to run under the desktop user account with the service LogOn so that the operating system DCOM security allows the connection. Using the OPC Data Fix is preferred in case the user account login is changed in the domain for the server.

If the OPC Server is running as a Service you can often leave the Service Log On to the Local System account, but check the box for “allow service to interact with desktop” if DCOM security is restricting the connection.

Refer to the Troubleshoot OPC Communications section in this Knowledge Base to resolve all OPC connection issues.

Data Logging or Recipe access to MS Access on a remote network drive
If you cannot assign the SYSTEM account to have access to the remote drive set the OAS Reports service LogOn (previously called OPC Systems Database).

Data Logging to CSV or SQLite file on a remote network drive
If you cannot assign the SYSTEM account to have access to the remote drive set the OAS Engine service LogOn (previously called OPC Systems).

Network Path – Best Resolution
Another common solution is to use the full network path instead of a mapped drive.  Mapped drives are usually defined to a user while a network drive starting with \\ will work without a user depending on the domain and security.