Do DCOM Settings Need to Be Configured on Both OPC Machines?

Do DCOM settings need to be configured on both the OPC client machine and the OPC server machine, and what are the key settings required on each side?

Yes, DCOM settings need to be reviewed and configured on both the OPC client machine and the OPC server machine. The server side requires correct application-level permissions including launch, activation, and access rights. The client side requires that the DCOM infrastructure can present valid credentials that the server machine will accept. A gap on either side is enough to prevent a stable connection.

Why Both Sides Are Involved

DCOM is a distributed communication framework, meaning it operates across a network and both endpoints participate in authentication and authorization. When an OPC client on one machine attempts to connect to an OPC server on another, DCOM on the server side must verify that the connecting identity has permission to launch the server process, activate the COM object, and access the data. DCOM on the client side must be configured to present credentials that the server can validate. If either side has incorrect or incomplete settings, the connection fails or behaves unpredictably.

Key Settings on the OPC Server Machine

On the machine hosting the OPC server, the primary settings are managed through the Component Services administrative tool under DCOM configuration for the specific OPC server application. The settings to verify are launch and activation permissions, which control who can start the server process and instantiate its COM objects, and access permissions, which control who can call into the running server. The machine-wide default DCOM settings also apply and must not conflict with the application-level settings. Authentication level and impersonation level settings on the server side affect how credentials are evaluated during communication.

Key Settings on the OPC Client Machine

On the client machine, the most important consideration is that the user account running the OPC client application must have credentials that the server machine can authenticate. In workgroup environments where there is no shared domain authentication, this means creating matching local user accounts with matching passwords on both machines. In domain environments, domain accounts that have been granted the necessary permissions on the server side are used. The client machine must also not have DCOM restricted in a way that prevents outbound COM calls to remote machines.

Common Mistakes and Where to Start

The most frequent mistake is configuring the server side correctly while overlooking the client side, or assuming that because the OPC client application is running under an administrator account, DCOM permissions are automatically satisfied. Administrator rights on the local machine do not automatically translate into permissions on the remote machine. Starting with a diagnostic tool that describes what is failing and why, rather than trying settings at random, significantly shortens the troubleshooting process.

Relevant Tools

The Troubleshooting OPC and DCOM tool from OPC Expert provides step-by-step guidance for diagnosing and correcting DCOM configuration problems on both machines. It identifies the specific setting that is causing a failure and explains what needs to change, making it practical for engineers who do not configure DCOM regularly. OPC Tunneler, also part of OPC Expert, is an alternative for situations where configuring DCOM across network boundaries is not feasible, bypassing the DCOM requirement entirely for the cross-network leg of the connection.

Correct DCOM configuration requires attention to both the client and server machines. Understanding what each side contributes to the authentication and authorization process, and verifying those settings systematically, is the most reliable path to a stable OPC Classic connection.