Resolving WinCC 6.0 OPC Server Discovery Failures Over DCOM

Problem Description

When two Windows PCs are configured with WinCC V6.0 (or WinCC V6.0 SP3) and SIMATIC NET PC software, a common commissioning failure is the inability of an OPC client on PC2 to enumerate or browse the OPCServer.WinCC instance exposed by PC1. The OPC server does not appear in the client-side "Add OPC Server" dialog of the SIMATIC NET configuration tool, the WinCC Explorer, or any external OPC client such as OPC Scout, even though both stations are reachable on the network and the WinCC runtime is running locally on PC1.

The failure mode is consistent: the DCOM server enumeration handshake never completes, the OPCEnum service returns no remote servers, and the user is unable to add PC1's WinCC runtime as a remote OPC DA source in PC2's WinCC project. Because classic OPC DA depends entirely on COM/DCOM for both enumeration and runtime data transfer, the root cause is almost always in the COM security layer, the SIMATIC NET OPC security add-on, or the Windows firewall state of the involved stations.

Architecture and Protocol Stack

WinCC V6.0 implements the OPC Data Access 1.0/2.0/3.0 specification using COM (Component Object Model) and DCOM (Distributed Component Object Model) as the transport. Unlike OPC UA, which is message-oriented over TCP and HTTP, OPC DA relies on:

• OPCEnum (service name OPCEnum, display name "OPC Server Enumerator") for server discovery via IRemoteServer over DCOM.
• DCOM activation and call-back for both the initial IOPCServerList::EnumClassesOfCategories call and the subsequent IUnknown marshaling into the client process.
• Windows RPC (port 135 + dynamic ephemeral range) as the underlying transport. The RPCSS service must be running on both stations.

For each WinCC project running on PC1, the WinCC runtime registers an OPC DA 3.0 server under the ProgID OPCServer.WinCC. Because these are COM in-process servers hosted by CCOPCSvr.exe, every client connection results in a DCOM activation of that executable inside the security context of the configured launch user.

Reference: WinCC V6.0 Communication Manual, section "Configuring WinCC Stations for OPC" (Siemens entry ID 21320307).

Prerequisites

Before changing any DCOM configuration, verify the following baseline. Missing prerequisites are responsible for the majority of "OPC server not found" failures reported in the field.

Root Cause Analysis

Five distinct failure paths account for nearly every reported "I cannot find OPCServer.WinCC in the network" scenario. They must be ruled out in order because each subsequent layer assumes the previous is healthy.

1. OPCEnum not running or unreachable. The client first queries \\<PC1>\Root\CIMV2 via WMI / DCOM to ask OPCEnum for the list of registered OPC DA servers. If the OPCEnum service is stopped or blocked by the firewall, the enumeration returns an empty list — even though OPCServer.WinCC is correctly registered on PC1.
2. DCOM access permissions on PC1 deny anonymous / interactive launch. By default, Windows restricts DCOM activation to the launching user. If the WinCC OPC server application is configured to "run as the launching user" or "interactive user" without the appropriate access/launch permissions for the remote user account, IRRPCE returns E_ACCESSDENIED (HRESULT 0x80070005).
3. SIMATIC NET OPC security not configured. SIMATIC NET installs an additional access-control layer in the registry path HKLM\SOFTWARE\SIEMENS\SIMATIC NET\OPCS\Security that gates the COM activation separately from the DCOMCNFG settings. Without this, even a correctly configured DCOMCNFG can still refuse the OPC connection.
4. User context mismatch. DCOM uses NTLM / Kerberos to pass the calling security context to the remote server. If the client user is a local account on PC2 but a domain account is required on PC1, the activation fails with CO_E_FAILEDTOAUTHENTICATE (HRESULT 0x8000401A).
5. Windows firewall or anti-virus product blocking RPC dynamic ports. Even with the DCOMCNFG firewall exception for "COM/DCOM", third-party endpoint protection products frequently re-block the ephemeral range 49152–65535 (or 1024–5000 on XP/2003), preventing the marshaled interface transfer.

Solution — Server-Side DCOM Configuration (PC1)

Perform the following steps on the PC hosting the WinCC runtime (PC1, the OPC server). After each step, restart the WinCC runtime so it re-registers its COM objects.

1. Open Component Services: Start → Run → dcomcnfg (or via Control Panel → Administrative Tools → Component Services).
2. Expand Console Root → Component Services → Computers → My Computer.
3. Right-click My Computer → Properties and confirm the COM Security tab is visible (it requires Windows XP SP2 or later). Configure the four machine-wide defaults:
   • Access Permissions → Edit Limits: allow ANONYMOUS LOGON, Everyone, and the specific domain / local user that PC2 uses.
   • Launch and Activation Permissions → Edit Limits: same accounts, full allow.
   • Access Permissions → Edit Default: same accounts.
   • Launch and Activation Permissions → Edit Default: same accounts.
4. Navigate to DCOM Config. Locate the entry whose Application ID matches the WinCC OPC server (ProgID OPCServer.WinCC). Right-click → Properties:
   • General tab: Authentication Level = None for testing; revert to Connect once verified.
   • Location tab: enable "Run application on the following computer"; confirm "Run application on this computer" remains checked.
   • Security tab: customize all three sections (Launch & Activation, Access, Configuration) and grant full control to Everyone for first-pass testing. Lock down later.
   • Identity tab: select The interactive user for the typical scenario, or This user with a dedicated service account if the client runs headlessly.
   • Endpoints tab: select "Use any available" or "TCP/IP". Static endpoint configuration is recommended for firewall traversal — e.g., port 5000 with protocol ncacn_ip_tcp.
5. Repeat for the OPCEnum COM application (CLSID {13486D51-4821-11D2-A494-3CB306C10000}) — it must allow remote activation or remote enumeration will silently fail.
6. Restart the OPCEnum service and the WinCC Runtime service on PC1.

Solution — Client-Side DCOM Configuration (PC2)

1. Open dcomcnfg on PC2.
2. On My Computer → Properties → COM Security tab, under Default Security → Edit Default, ensure the same user accounts from the server side have Launch and Activation rights on the client as well. Some installations require both directions to be granted.
3. On My Computer → Properties → Default Protocols, confirm "Connection-oriented TCP/IP" has been moved to the top of the property order list.
4. Add a static endpoint for OPCEnum on PC2 so that the firewall rule for inbound 135 plus the chosen static port is sufficient.

Solution — SIMATIC NET OPC Security Configuration

The SIMATIC NET OPC add-on enforces an additional access-control list stored in the registry. Without populating it, even a perfectly configured DCOM layer will refuse the activation. Configure on PC1:

1. Open SIMATIC NET Configuration Console (Start → Programs → SIMATIC NET → Configuration Console).
2. Navigate to PC Station → Applications → OPC.
3. Right-click the OPC entry → Properties → Security (on older localizations the menu reads "OPC Settings" or "OPC Properties"; on older builds the Security tab is not present at all — in that case the SIMATIC NET hotfix must be applied).
4. Click Add and enter ANONYMOUS LOGON (German: ANONYME ANMELDUNG). Grant Read, Write, and Execute.
5. Repeat for the domain / local account used on PC2. Click Apply.
6. Restart the SIMATIC NET OPC service (S7OPCSX or OPC.SimaticNET, depending on SIMATIC NET version).

Verification with OPC Scout

OPC Scout is shipped with SIMATIC NET and is the canonical loopback / cross-machine validation tool. Always validate the configuration in this order before re-opening the WinCC Explorer:

1. On PC1, start OPC Scout (Start → Programs → SIMATIC NET → OPC Scout). Confirm OPC.SimaticNET appears in the local server list and reads a known WinCC tag. This proves the server side is healthy.
2. On PC2, start OPC Scout. In the OPC Scout dialog, click ... next to "OPC Server" and choose Network. The list must show the WinCC runtime on PC1 with ProgID OPCServer.WinCC.
3. Double-click the remote server entry; add a tag, click Read. A numeric / boolean value matching the runtime confirms end-to-end OPC DA functionality.
4. If PC2 cannot see PC1, fall back to Direct Connection: enter the ProgID and the hostname as \\PC1\OPCServer.WinCC. If this works but network enumeration does not, the failure is in OPCEnum, not in DCOM authentication.
5. Repeat with both stations restarted and logged in with the same domain user.

Troubleshooting Matrix

Modernization Path — OPC UA over WinCC 7.x / TIA Portal WinCC

The configuration footprint described above exists because WinCC V6.0 relies exclusively on COM/DCOM. From WinCC V7.0 onward and across the TIA Portal WinCC Professional / Comfort / RT families, OPC UA is available as a first-class server with built-in certificate-based security, binary TCP transport on port 4840, and discovery URLs of the form opc.tcp://<host>:4840. Migrating to OPC UA eliminates every DCOM configuration step and the firewall complexity.

Known caveats observed on WinCC Professional / Panel RT OPC UA servers:

• The discovery URL opc.tcp://<hostname>:4840 must resolve to a routable IPv4 address. Hostname-based discovery requires a working DNS or hosts entry on the client; otherwise the client falls back to LastKnownValue with quality Uncertain and reduced operation count.
• The server enforces a maximum items-per-subscription. Older Panel RT firmware rejects requests larger than 64 items per CreateSubscription. If the client batches 300 items, the server silently reduces the operation count. Adjust the subscription size on the OPC UA client side (UA Expert, Kepware, or SIMATIC NET OPC UA client).
• Certificate trust must be established on first connect: copy the WinCC OPC UA server certificate into the client's trusted-certificate store under %ProgramData%\OPC Foundation\CertificateStores\UA Applications\certs (or the SIMATIC NET equivalent). Without this, every call returns BadCertificateUntrusted (HRESULT 0x801A0000 in the UA mapping).

References: Siemens Industry Online Support; OPC Foundation — What is OPC?

Firewall and Port Reference

Safety and Operational Notes

FAQ