Resolving ProTool OPC.SimaticHMI.PTPro RPC Server Unavailable Errors

This troubleshooting guide addresses the classic RPC server is unavailable (HRESULT 0x800706BA) failure when a ProTool/Pro RT or WinCC flexible RT client attempts to browse or read tags from the OPC.SimaticHMI.PTPro in-process OPC DA 2.0 server running on a remote engineering or runtime station. The same root cause produces the NO OPCPROXY.dll is registered message and the No OPC servers are installed on this machine: \\<HOST> error reported by Matrikon OPC Explorer and Siemens OPC Scout.

1. Problem Description

A ProTool/Pro Runtime OPC client on computer A is configured to use the OPC.SimaticHMI.PTPro OPC DA server running on computer B (MB in the original report). One or more of the following symptoms appear:

The same engineering station, when used as both client and server (ProTool/Pro RT hosting OPC.SimaticHMI.PTPro plus a co-located WinCC flexible RT acting as client), operates correctly. The failure is direction-dependent: in the original case, host A → host B succeeds (WinCC flexible server), but host B → host A fails (ProTool server). This asymmetry is a fingerprint of DCOM launch and access permissions, not of the OPC application itself.

2. Root Cause Analysis

The OPC.SimaticHMI.PTPro server is a Windows in-process (in-proc) COM server implemented as a DLL hosted by dllhost.exe via the COM surrogate. Three independent layers must succeed for a remote browse or read to work:

1. Network reachability (TCP/IP, name resolution, ping) between client and server.
2. RPC endpoint mapper reachability on TCP port 135, and dynamic high port allocation for dllhost.exe between 1024-65535.
3. DCOM launch and access permissions for the OPC.SimaticHMI.PTPro AppID on the server, and matching default protocol / authentication on both sides.

The error string "RPC server is unavailable" is returned when the client cannot reach the RPC endpoint mapper, or when the server refuses the DCOM activation request because the caller identity is not in the launch or access ACL. It is not, by itself, an OPC fault: the OPC stack never initialises because COM never returns a pointer to the in-proc server.

3. Preconditions and Inventory

Before changing configuration, capture a snapshot so each layer can be verified independently.

The ProgID OPC.SimaticHMI.PTPro maps to a CLSID installed by ProTool/Pro RT; the CLSID value should be recorded from HKCR\OPC.SimaticHMI.PTPro\CLSID. This CLSID is required for step 4.3.

4. Layer-by-Layer Solution

4.1 Network and Name Resolution (Layer 1)

Open an elevated command prompt on the client and run:

ping -4 <server-hostname>
ping -4 <server-ip>
nslookup <server-hostname>
net view \\<server-hostname>

All three must succeed. If ping hostname fails but ping ip succeeds, name resolution is broken (DNS suffix, WINS, or LMHOSTS lookup). If both fail, there is a routing, subnet, or local-link issue. If net view fails with "Access is denied" (0x00000005) or "The network path was not found" (0x00000034), the SMB / CIFS stack is misconfigured; DCOM cannot be fixed until that succeeds because the OPC DA browser falls back to SMB for some operations.

4.2 RPC Endpoint Mapper and Dynamic Ports (Layer 2)

On the server, verify the RPC service is running and that port 135 is reachable:

sc query RpcSs
netstat -ano -p tcp | findstr :135
telnet <client-ip> 135

If sc query RpcSs reports STOPPED, start it with net start RpcSs and set the start type to Automatic. The RPCSS service hosts the endpoint mapper and is required for every DCOM activation; without it, every remote OPC client receives 0x800706BA.

On Windows XP SP2 and later, restrict the dynamic port range used by dllhost.exe to a predictable interval so the firewall can be configured deterministically:

netsh int ipv4 set dynamicportrange protocol=tcp start=5000 num=2000
netsh int ipv4 show dynamicportrange protocol=tcp

Open TCP 135 plus the range above, inbound, on the server. UDP 135, 137, 138, and TCP 139, 445 must also be permitted if SMB browse is used. Reference: Microsoft KB 154596 - How to configure RPC dynamic port allocation to work with firewalls.

4.3 DCOM Configuration (Layer 3)

Launch dcomcnfg.exe on the server. The configuration is in two parts: the machine-wide Default Properties and Default Security that act as a baseline, and the per-application OPC.SimaticHMI.PTPro AppID overrides.

4.3.1 Default Properties (server)

Console Root → Component Services → Computers → My Computer, right-click → Properties:

• Default Authentication Level: Connect (RPC_C_AUTHN_LEVEL_CONNECT, value 2). Selecting None silently breaks the OPC DA 3.0 secure channels even when DA 2.0 still works, which is a common source of intermittent failures.
• Default Impersonation Level: Identify (RPC_C_IMP_LEVEL_IDENTIFY, value 1). The OPC DA specification requires Identify or Impersonate so the server can apply its launch ACL. Do not select Anonymous.
• Check Enable Distributed COM on this computer.

4.3.2 Default Security (server)

On the Default Security tab, edit both the Access and Launch sections. For each, in Edit Limits and Edit Default, grant Everyone Allow on every line. This is the lab-grade configuration that Siemens documents in Siemens Support entry 15248719 - Construction of an OPC.SimaticHMI.PTPro OPC-Server and a ProTool/Pro Runtime as OPC-Client and in the NCM PC - Configuring PCs and Networks manual, chapter 18, DCOM Settings with the dcomcnfg System Program. Once the connection works, tighten to the principle of least privilege by replacing Everyone with the specific user or group that runs the client runtime.

4.3.3 Per-Application AppID Overrides (server)

Console Root → Component Services → Computers → My Computer → DCOM Config. Locate OPC.SimaticHMI.PTPro (if the ProgID is missing, the in-proc server DLL is not registered: re-run regsvr32 "C:\Program Files\Siemens\ProTool\ProRT\OPC\OpcSrv.dll" or reinstall the ProTool/Pro RT runtime). Right-click → Properties:

The Identity tab is the most common cause of direction-dependent failures: when the server runs as Interactive User and the user has no interactive session (e.g. session 0 in a service-only environment, or a user who logged out), activations from a different machine still work as long as DCOM can launch a new instance under that identity. Setting it to This User with a dedicated service account is the robust option for 24/7 operation.

4.4 Client-Side Matching Configuration

On the client, repeat Default Properties from 4.3.1 with the same Authentication and Impersonation levels. Mismatched levels silently break the call: the client opens the connection at None while the server requires Connect, producing the same 0x800706BA symptom with no additional diagnostic detail.

On the client, also confirm that the OPC Proxy 2.0 stub DLL is registered:

regsvr32 "%SystemRoot%\System32\opcproxy.dll"
regsvr32 "%SystemRoot%\System32\opccomn_ps.dll"
regsvr32 "%SystemRoot%\System32\opcdaauto.dll"

These three DLLs implement IOPCServerList, IOPCCommon, and the DA 2.0 / 3.0 automation wrappers. If opcproxy.dll is unregistered, the client raises "NO OPCPROXY.dll is registered" immediately on startup of the OPC channel, before any network call. On 64-bit hosts running a 32-bit ProTool/Pro RT, use the 32-bit regsvr32 from %SystemRoot%\SysWOW64\.

4.5 Windows Firewall on Windows XP SP2+

The XP SP2 firewall blocks unsolicited inbound traffic by default. Add the following exceptions on the server:

1. Open Windows Firewall from Control Panel → Security Center.
2. On the Exceptions tab, add Program: dllhost.exe with scope = Any computer (or the specific client subnet).
3. Add Port: TCP 135 for the RPC endpoint mapper.
4. Add Port: TCP 5000-7000 (match the dynamic range configured in 4.2).
5. Add File and Printer Sharing as a pre-defined exception so net view works.

If a third-party firewall (Symantec, McAfee, Kaspersky, GFI, etc.) is installed, either disable it for the test or add equivalent rules. XP SP2's built-in firewall can be disabled with netsh firewall set opmode mode=disable profile=ALL for a baseline test, then re-enabled and locked down once DCOM works.

5. Verification Procedure

Each verification step must pass before moving to the next. A failure at step N is the actual cause; steps N+1 must not be attempted.

5.1 Network Verification

ping <server>
net view \\<server>
net use \\<server>\IPC$ /user:<domain\user> <password>

The net use line tests the null session and authenticated session that DCOM relies on. A System error 5 (Access is denied) on the authenticated line indicates a credential mismatch; a System error 1326 (Logon failure) indicates a name or password mismatch; a System error 53 (Network path not found) indicates routing or DNS.

5.2 OPC Scout Local and Remote

OPC Scout is bundled with Simatic Net 6.x and lives at C:\Program Files\Siemens\SimaticNet\opc2\bin\s7otbldx.exe or in the OPC Core Components folder. On the server, run OPC Scout, expand Local, double-click OPC.SimaticHMI.PTPro. If the local browse works, the in-proc server is registered and functional. If it fails locally, the problem is in the ProTool/Pro RT installation, not in DCOM.

On the client, run OPC Scout, expand Remote Computers, enter the server's hostname or IP, and double-click OPC.SimaticHMI.PTPro. A successful remote browse with the same credentials confirms the DCOM configuration.

5.3 Matrikon OPC Explorer

Matrikon OPC Explorer (free download from matrikonopc.com) is the third-party reference client. Connect to \\<server>\OPC.SimaticHMI.PTPro. If it returns No OPC servers are installed on this machine, DCOM activation is failing. Run dcomperm -ml from the Windows Resource Kit to dump the machine-default DCOM ACL and compare with the working configuration in the original setup.

5.4 Simatic Net Component Configurator

If OPC Scout on the local machine shows component configurator errors or catastrophic errors, open the Simatic Net Configuration Console (version 6.1 or later) and re-run the component configurator. The configuration console has a per-OPC-server Security tab; set it to Allow and confirm. This is a separate layer that sits on top of the Windows DCOM ACL for the Simatic Net OPC servers (OPC.SimaticNET, OPC.SimaticHMI.PTPro in some builds).

5.5 End-to-End Read Test

In the ProTool/Pro RT client, open Controllers → PLC → Parameters → OPC Connection and enter the server hostname. The OPC browser should populate with the tag list from the HMI variable pool. Drag a tag to a configured I/O field. The field should update within the configured polling interval (default 1 s).

6. Tightening the Configuration

Once the connection works with Everyone allowed, restrict the ACL to the minimum necessary. The recommended production configuration is:

After each tightening step, reboot the server (dcomcnfg changes do not take effect on existing dllhost.exe instances). Re-verify with OPC Scout and Matrikon Explorer after each step.

7. Known Issues and Edge Cases

8. Cross-Platform Notes

On Windows 7 and later, the same DCOM configuration moves from Component Services → Computers → My Computer → DCOM Config to dcomcnfg.exe with the same node tree, but the dialog gains UAC prompts. Always start dcomcnfg.exe elevated (Run as administrator). The Windows Firewall with Advanced Security adds inbound rules with a default action of Block; create explicit Allow rules for dllhost.exe, TCP 135, and the configured dynamic range. Service Hardening on Windows Server 2008 and later rejects DCOM activations from the network service and local service accounts unless an inbound firewall rule exists.

When the OPC client is a third-party product (Ignition by Inductive Automation, Kepware, PI Interface for OPC DA, WinCC OA OPC DA client, etc.), the same DCOM rules apply. For Ignition specifically, the OPC COM client driver is hosted in a 32-bit JVM or 64-bit JVM depending on the Ignition version; the opcproxy.dll, opccomn_ps.dll, and opcdaauto.dll must be registered for the matching bitness. Reference: Ignition OPC UA Driver documentation and the corresponding OPC COM driver notes.

9. Diagnostic Quick Reference

10. Summary

The RPC server is unavailable error when browsing OPC.SimaticHMI.PTPro is always a layer 1-3 problem: network, RPC endpoint, or DCOM ACL. The OPC application and the ProTool/Pro RT configuration are not the cause and should not be modified. The fastest path to a working baseline is:

1. Confirm network and SMB reachability.
2. Confirm RpcSs running and TCP 135 reachable.
3. Apply the lab-grade DCOM defaults (Everyone Allow) on both machines, matching authentication and impersonation levels.
4. Register the OPC Proxy 2.0 DLLs on the client.
5. Add firewall exceptions for dllhost.exe and the RPC ports.
6. Verify with OPC Scout locally and remotely, then with Matrikon Explorer.
7. Restore production-grade ACLs and re-verify.