Resolving Simatic NET OPC DA Server RPC Connection Failure

Problem Overview

When a custom OPC DA client application attempts to connect to a remote SIMATIC NET OPC server using the Automation Interface (the SiemensOPCDAAutomation 2.0 wrapper that exposes the OPCServer, OPCGroup, and OPCItems classes), the MyOPCServer.Connect(ServerName) call in the VB.NET application fails with the message:

The RPC server is unavailable (Exception from HRESULT: 0x800706BA)

Supporting telemetry captured in the application, the COM trace file, and the Windows event log pinpoints the failure to the COM activation layer rather than the network or RPC endpoint mapper:

• Visual Basic Err.Number = 462 with Source = Interop.OPCSiemensDAAutomation
• SOPCDAAUTO_ERR line: ERR 'CoCreateInstance' OPCAutoServer::Connect, [hr=0x800706BA] ProgID: 'OPC.SimaticNET'
• SOPCDAAUTO_ERR line: ERR 'gpOPC->GetClassDetails' OPCAutoServer::GetOPCServers, [hr2=0x80040154]
• Windows Event Viewer (System log): DCOM was unable to communicate with the computer "NAME" using any of the configured protocols — event ID 10010

Diagnostic context: the same client can call GetOPCServers(RemoteMachineName) without error, and the Siemens-supplied OPC Scout test tool can read/write tags from the same remote machine, which proves the RPC plumbing (port 135 + dynamic ports) and the server-side DCOM permissions are correct. The asymmetry between the working reference client and the failing custom client is the diagnostic fingerprint of a missing COM class registration on the client, not a network, firewall, or DCOM authentication failure.

Environment & Affected Components

The configuration is functional at the GetOPCServers call, which uses IOPCServerList::EnumClassesOfCategories to perform a CLSID enumeration over the local registry and the remote opcenum service. The failure point is the subsequent CoCreateInstance(CLSID_OPCServer, ..., ProgID="OPC.SimaticNET", ...), which is a remote COM activation that depends on both the local COM proxy/stub registration and the remote server's AppID launch permissions.

The same failure pattern applies to all SIMATIC NET versions from V6.x through V8.1 that ship the COM-based OPC DA server. The Automation wrapper (opcdaauto.dll) has been part of the SIMATIC NET PC software since the earliest releases and is identical across versions; only the underlying SIMATIC NET OPC DA server CLSID changes between major versions.

Decoding the Error

HRESULT Map

The first SOPCDAAUTO_ERR line is the critical clue: 0x80040154 is raised before the RPC call, while enumerating the class object. It indicates the Automation wrapper DLL is present but not properly registered. The subsequent 0x800706BA is the secondary failure when the wrapper tries to launch the COM server on the remote host.

Other HRESULTs You Will See in This Failure Mode

Anatomy of the SOPCDAAUTO_ERR File

The trace file is written by the SIMATIC NET OPC Automation wrapper to %TEMP%\SOPCDAAUTO_ERR.log and %TEMP%\SOPCDAAUTO_TRACE.log. Each line is structured as:

00000001 18:33:18,6020 D60 ***TRACEEVENT IS CREATED
00000002 18:33:18,6020 D60 ***TRACE IS INITIALIZED
00000003 18:33:18,6020 D60 -> DLL_PROCESS_ATTACH
00000004 18:33:18,6020 D60 <- DLL_PROCESS_ATTACH
00000005 18:33:26,7530 D60 ERR 'gpOPC->GetClassDetails' OPCAutoServer::GetOPCServers, [hr2=0x80040154]
00000006 18:33:31,7600 D60 ERR 'CoCreateInstance' OPCAutoServer::Connect, [hr=0x800706BA] ProgID: 'OPC.SimaticNET'
00000007 18:56:14,2100 D60 -> DLL_PROCESS_DETACH

The fields are: line number, HH:MM:SS,mmm timestamp, thread ID, severity (ERR or TRC), and the COM call site. The D60 suffix on the thread ID is a decimal-pid reference used by the trace writer. The hr and hr2 are the COM HRESULT and a secondary HRESULT for nested failures. In a healthy trace, the CoCreateInstance call is followed by a QueryInterface for IOPCServer and a successful AddRef; in the failure case, no such lines appear because the activation is rejected at the COM runtime.

Root Cause Analysis

The root cause is a missing COM proxy/stub registration and/or missing OPC Automation wrapper DLL on the client machine. Specifically:

1. GetOPCServers succeeds because OPC Scout (installed together with SIMATIC NET) calls IOPCServerList against the local registry. The remote machine's CLSIDs are returned over the OPCEnum custom interface (TCP port 135 plus the OPCEnum endpoint) — no COM launch permission is required for enumeration.
2. Connect fails because the client must now perform a remote COM activation. Windows uses the registered AppID for OPC.SimaticNET to look up the launch permissions, identity, and security blanket. On the client, two things are required:
   • The proxy/stub DLL for the IOPCServer interface family (opcproxy.dll) must be registered so the marshaled interface can be reconstructed locally.
   • The OPC Automation wrapper (OPCDAAuto.dll, the COM in-proc server that implements the friendly Automation classes such as OPCServer, OPCGroup, OPCItems) must be registered on the client.
3. In the failing case, neither was present: the client had only the .NET Interop assembly built against the type library, not the actual COM server. The Visual Studio project included Interop.OPCSiemensDAAutomation.dll (the .NET RCW), but OPCDAAuto.dll itself — the COM DLL the RCW activates — was never registered on the client.
4. The DCOMCNFG Default Protocols matched on both machines because both default to Connection-oriented TCP/IP. The mismatch is not in protocols but in the COM class registration.

Activation Flow Diagram

Resolution: Step-by-Step

Step 1: Install SIMATIC NET PC Software on the Client

The cleanest fix is to install the SIMATIC NET PC software on the OPC client machine using the same version (or a higher compatible version) as the server. This registers:

• opcdaauto.dll — OPC DA Automation 2.0 wrapper, the COM in-proc server behind the .NET RCW
• opccomn_ps.dll, opcproxy.dll — OPC DA proxy/stub DLLs
• opcenum.exe — the OPCEnum service
• The OPC.SimaticNET ProgID and its AppID ACLs
• The SIMATIC NET DCOM configuration entries under HKCR\AppID\

Procedure:

1. Insert the SIMATIC NET DVD or mount the ISO. Launch Setup.exe.
2. Choose Custom Installation and select at minimum:
   • SIMATIC NET PC Software
   • OPC Server (DA)
   • OPC Scout (for verification)
3. On the User Settings step, configure the same Workgroup or domain account that the server uses for the SIMATIC NET service. Both machines must recognize the same user.
4. Complete the installation and reboot.

If the client is on a different domain or a Workgroup with no trust, install the same SIMATIC NET build version that the server uses, but run it as a standalone Workgroup client — the SIMATIC NET setup supports both modes. The supported build matrix is documented in the SIMATIC NET release notes; the typical rule is that the client can be a higher minor version than the server but not a lower minor version (e.g., V14 client to V13 server is supported; V12 client to V14 server is not).

Step 2: Re-register the Automation DLL (Manual Recovery)

If a full SIMATIC NET install is not feasible, the minimum set of registrations on the client is:

regsvr32 opcdaauto.dll
regsvr32 opccomn_ps.dll
regsvr32 opcproxy.dll
opcenum.exe /regserver

These must be run from an elevated command prompt (Run as administrator) on Vista and later, or from an account with administrator privileges on Windows XP. Verify with:

reg query "HKCR\OPC.SimaticNET" /s
reg query "HKCR\AppID\{AppID_OPC.SimaticNET}" /s

If the ProgID is missing entirely, the SIMATIC NET install package is the supported route — the wrapper DLLs are not redistributable in isolation per the OPC Foundation redistribution policy referenced in the SIMATIC NET PC software release notes.

Step 3: Verify DCOM Configuration

Open dcomcnfg on both machines and apply the OPC Foundation DCOM settings:

Then drill into Component Services → Computers → My Computer → DCOM Config, locate the OPC.SimaticNET server, and on the Security tab:

• Launch and Activation Permissions → add the user that runs the VB client, grant Local Launch, Remote Launch, Local Activation, Remote Activation.
• Access Permissions → add the same user, grant Local Access, Remote Access.
• Configuration Permissions → leave at default unless the user needs to change settings.

On the Identity tab, select The interactive user if the VB application runs interactively, or This user with a domain/Workgroup service account that has access to the PLC network. For unattended services running under LocalSystem, choose This user with a named account — LocalSystem cannot authenticate to a remote machine across a Workgroup boundary.

On the Endpoints tab, ensure the DCOM protocol list includes Connection-oriented TCP/IP with the appropriate port range. The default is to use a dynamic range; if you need to lock down the firewall (recommended), restrict it as described in Step 5.

Step 4: Configure the Windows Firewall

DCOM uses dynamic TCP ports in addition to port 135 (RPC Endpoint Mapper). For Windows XP, the firewall is Windows Firewall; for later versions, use the advanced firewall (wf.msc).

Open the following inbound rules on both machines:

To restrict the DCOM port range on Windows XP and Server 2003, set the registry key:

HKLM\SOFTWARE\Microsoft\Rpc\Internet
  Ports = REG_MULTI_SZ "5000-5100"
  PortsInternetAvailable = REG_SZ "Y"
  UseInternetPorts = REG_SZ "Y"

…and add an exception for 5000-5100 TCP in the firewall. On Windows Vista and later, the equivalent is netsh advfirewall and the COM/DCOM predefined rule group. Reference: Microsoft DCOM technical reference.

Step 5: Verify with OPC Scout

Run OPC Scout on the client and connect to the remote OPC.SimaticNET server, then add a test item (e.g., S7:[S7 connection_1]DB1,INT0). If OPC Scout now also fails, the DCOM configuration is still wrong. If it succeeds (as in the source case), the fix is the missing local registration only.

Step 6: Validate the VB Application

Add diagnostic capture to the application so future failures are easier to triage:

Private Sub Button_Connect_Click(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) Handles Button_Connect.Click
    On Error GoTo ErrorHandler
    ServerName = ComboBox1_ServerList.Text
    Call MyOPCServer.Connect(ServerName)
    Button_AddGroup.Enabled = True
    Button_Disconnect.Enabled = True
    Exit Sub
ErrorHandler:
    MsgBox("Error! " & Err.Description & vbCrLf & _
           "Source: " & Err.Source & vbCrLf & _
           "ErrNr: " & Err.Number & vbCrLf & _
           "ErrHelpFile: " & Err.HelpFile & vbCrLf & _
           "ErrHelpContext: " & Err.HelpContext)
End Sub

And log the exact ProgID being passed to Connect — a misspelled or case-mismatched ProgID will produce a different HRESULT (0x800401F3 for CO_E_CLASSSTRING) that is easy to confuse with 0x800706BA.

DCOM Configuration Reference

Registry Keys Created by SIMATIC NET Install

To audit the current state, run on the client after install:

reg query "HKCR\OPC.SimaticNET" /s
reg query "HKCR\CLSID" /f "SimaticNET" /s
reg query "HKLM\SOFTWARE\Siemens\AUTSW" /s

The HKLM\SOFTWARE\Siemens\AUTSW key is the SIMATIC NET installation registry, which records the installed PC software version, the S7DOS configuration, and the S7 connection names exported by Station Configuration Editor.

Default Authentication and Impersonation Levels Explained

The SIMATIC NET OPC DA reference client and most third-party OPC clients use Connect (2) for Authentication and Identify (2) for Impersonation. The Microsoft COM error code reference documents the full set of authentication constants.

Verification Matrix

Why OPC Scout Worked Without the Fix

OPC Scout is a SIMATIC NET component installed on the same image as the OPC server. It uses the same wrapper DLLs that the failing VB application needs but that the client lacked. The VB application did not actually need OPC Scout to be installed on the client — it only needs the OPC Automation wrapper registered. OPC Scout's success on the client was incidental, not a requirement.

This is a common pattern in OPC troubleshooting: the reference client (Scout, Matrikon, Kepware Quick Client) succeeds, but the production client fails, because the reference client is installed in a way that registers more COM components than the production client ships with. Engineers familiar with the works on the reference client symptom often conclude that the network and DCOM are correct, which is true, and then overlook the COM class registration layer.

Migrating to OPC UA

The entire class of DCOM-related failures described here — 0x800706BA, 0x80040154, event 10010, firewall port gymnastics, identity mismatch — disappears when the application is migrated to OPC UA. The SIMATIC NET OPC UA server (component of SIMATIC NET V8.1 and later) speaks the binary OPC UA protocol over TCP port 4840, optionally with certificate-based authentication and AES-256/SHA-256 encryption.

To migrate the VB.NET application:

1. Add the OPC Foundation .NET Standard stack (Opc.Ua.Client) via NuGet, or the legacy OPC Foundation .NET API for .NET Framework targets.
2. Discover the endpoint:

   var discovery = new DiscoveryClient(new Uri("opc.tcp://server:4840"));
   var endpoints = discovery.GetEndpoints(null);
   

3. Create a session using the Certificate and UserIdentity configured in SIMATIC NET.
4. Translate the legacy ItemID (e.g., S7:[S7_1]DB1,INT0) to the corresponding NodeId (e.g., ns=3;s="DB1"."INT0").

The OPC UA route also lifts the platform constraint to any modern Windows, Linux, or container that supports .NET Standard 2.0 or higher — useful when the legacy Windows XP Embedded server is finally retired. The OPC Classic specifications and the OPC UA specification at the OPC Foundation describe the address space mapping.

Common Pitfalls & Edge Cases

Diagnostic Tools

Reference: Siemens Industry Online Support hosts the SIMATIC NET manuals, release notes, and the S7DOS configuration guide. Search for "SIMATIC NET OPC DCOM configuration" for the canonical DCOM setup procedure.

Security & Identity Considerations

Across a Workgroup, DCOM uses the local SAM account database on each machine; there is no Kerberos. The practical implications:

• The account that runs the VB client must exist on the server with the same username and password, or the DCOM activation will fail at the security blanket stage with 0x80070005 rather than the 0x800706BA seen in the unregistered scenario.
• Local Administrators group membership on the server is sufficient for DCOM launch and activation; OPC read/write authorization is separate and enforced by the SIMATIC NET OPC server based on the SIMATIC NET user rights configured in Station Configuration Editor.
• For a domain-joined environment, the domain controller is contacted for SIDs; the same user is resolved transparently on both machines. The error pattern in this article is typical of the Workgroup case, not the domain case.
• If the VB application is later moved to run as a Windows service, the service account must have the SeLogonRight (Allow log on locally) and SeNetworkLogonRight (Access this computer from the network) privileges, and must be granted DCOM launch/activation on the server's OPC.SimaticNET AppID.

Frequently Asked Questions