Resolving WinCC OPC Server Aspen CIM-IO Service Login Failure

The WinCC OPC Server (SOPCSRVRWinCC.exe) silently refuses incoming connections from the AspenTech CIM-IO for OPC client (asyncDlgp.exe) whenever CIM-IO is launched as a Windows service, even though the same executable connects and reads tags successfully when started from an interactive command prompt. The failure is not a DCOM corruption, a firewall problem, or a WinCC project fault — it is a service identity mismatch between the AspenTech service, the WinCC runtime, and the COM activation path that SOPCSRVRWinCC.exe uses to validate incoming OPC clients.

This reference documents the precise configuration that makes WinCC 6.2 SP and AspenTech CIM-IO for OPC v9.x coexist on the same workstation when the AspenTech side is operated as a service, exactly as required for an Aspen InfoPlus.21 historian data path. The guidance is derived from the SIMATIC WinCC OPC commissioning documentation, the AspenTech knowledge base on service account alignment, and field-validated WinCC 6.0 / 6.2 SP deployments.

1. Problem Summary

Symptom matrix observed in production and engineering stations:

Diagnostic fingerprints confirmed on affected stations:

• Task Manager shows WinCC.OPC executable running, WinCC runtime project active.
• AspenTech CIM-IO for OPC launches and reads tags when started from a manual cmd.exe with the operator's domain account.
• The same asyncDlgp.exe binary, when started by the Aspen CIM-IO Manager service, cannot bind to WinCC.OPC.
• OPC Scout V10 fails against WinCC.OPC whenever the OPC Scout log-on account differs from the WinCC runtime log-on account, even when both accounts are administrators on the box.

The diagnostic that always isolates the issue: the WinCC runtime user, the CIM-IO service log-on account, and the DCOM launch / activation identities must resolve to the same Windows principal.

2. Affected Software and Components

Reference material that governs the fix:

• AspenTech knowledge base article KB 000096650 — Error OPC.Ua.DiscoveryServer does not have a trusted list defined, which formally states: "First make sure the services Aspen CIM-IO Manager and OPC UA Discovery Server are running on the same administrator accounts." The same identity-alignment principle applies to the OPC DA path used by WinCC.OPC.
• Aspen InfoPlus.21 Product Family Installation Guide V12, available through AspenTech eSupport 000097634.
• AspenTech CIM-IO documentation portal at explore.aspentech.com CIM-IO.
• Matrikon OPC Server for AspenTech InfoPlus.21 — vendor page at matrikonopc.com OPC IP21 — useful as a fallback DA bridge when CIM-IO cannot be hardened to match WinCC identity.

3. Root Cause: Identity, Not DCOM

The most common red herring in this scenario is DCOM configuration. After the WinCC Connectivity Pack is installed, the SIMATIC Security Control tool writes a defined set of DCOM, COM, and Windows security descriptors that SOPCSRVRWinCC.exe relies on. Manually editing these descriptors, while well-intentioned, almost always shifts the trust path that WinCC requires. Field experience shows that once a WinCC client has been re-imaged because of DCOM tampering, the safest baseline is to leave DCOM untouched and instead fix the service identity.

The actual cause is COM activation identity. When asyncDlgp.exe runs as a Windows service, the COM layer authenticates the caller using the service's log-on account, not the operator account that opened the command prompt. The WinCC runtime, in turn, will only accept OPC DA calls from a principal that matches the account that started SOPCSRVRWinCC.exe. The result is silent rejection at the COM CoCreateInstance / IOPCServer::GetStatus boundary, even though no error is written to the WinCC diagnostic log by default.

The three identities that must coincide are:

1. The Windows account used to start the WinCC runtime (and therefore SOPCSRVRWinCC.exe).
2. The Windows account configured as the Log On identity of the Aspen CIM-IO Manager service and of the supervised asyncDlgp.exe child process.
3. The Windows account that is granted DCOM Remote Access, Launch, and Activation permissions on the WinCC OPC server — this is the account SIMATIC Security Control typically locks down to the WinCC operator group.

4. Step-by-Step Resolution

4.1 Prerequisites

• Local administrator rights on the WinCC station.
• WinCC 6.2 SP installed with the Connectivity Pack and a running WinCC project.
• AspenTech CIM-IO for OPC v9.x installed; both Aspen CIM-IO Manager and the CIM-IO for OPC service visible in services.msc.
• Snapshot of the current service accounts via sc qc "Aspen CIM-IO Manager" and sc qc "Aspen CIM-IO for OPC" for rollback documentation.
• A dedicated domain service account (recommended) or, at minimum, a local account that will own all three identities.

4.2 Identify the WinCC runtime account

1. Open the WinCC project in WinCC Explorer on the runtime node.
2. Confirm which Windows user started the WinCC runtime by inspecting the WinCC service account or by running tasklist /v /fi "imagename eq SOPCSRVRWinCC.exe" from an elevated command prompt — the User Name column is the runtime principal.
3. Record the value, for example DOMAIN\svc_wincc_opc. This is the only account that will be permitted to read tags from WinCC.OPC.

4.3 Realign the AspenTech service identities

1. Stop both Aspen CIM-IO Manager and Aspen CIM-IO for OPC services.
2. Open services.msc, right-click Aspen CIM-IO Manager, choose Properties → Log On.
3. Select This account, enter the WinCC runtime account from step 4.2, and supply the password twice. Apply.
4. Repeat for Aspen CIM-IO for OPC. The two services must use the same Windows principal; this matches the alignment AspenTech KB 000096650 requires between Aspen CIM-IO Manager and the OPC UA Discovery Server.
5. Set the startup type of Aspen CIM-IO for OPC to Manual if the Manager service is expected to supervise it, or to Automatic with the same log-on account if it must start independently.
6. Close services.msc and refresh the service account cache by running gpupdate /force on a domain-joined box, or by rebooting if local credentials are used.

4.4 Grant the account the rights WinCC requires

Even when the service identity is correct, the account must additionally hold the rights SIMATIC Security Control configures. Verify the following memberships and rights for the account from 4.2:

• Member of the local SIMATIC HMI / SIMATIC WinCC OPC group (group name varies by WinCC version; inspect with lusrmgr.msc).
• Member of local Distributed COM Users and, where applicable, Performance Log Users.
• Granted the Log on as a service right via

  secpol.msc → Local Policies → User Rights Assignment.

• Held DCOM Remote Access, Launch, and Activation on the WinCC.OPC DCOM application node. Do not grant these by hand across the entire DCOM tree — restrict to the WinCC.OPC application object via dcomcnfg.

4.5 Confirm asyncDlgp.exe is supervised by the Manager

The AspenTech Manager service is responsible for spawning and supervising asyncDlgp.exe. If the executable is launched by any other means — a scheduled task, a startup script, a third-party supervisor — the process identity will not match the service account, and the connection will fail in exactly the same way as a command-window launch from the wrong user. Validate this by stopping the Manager service and confirming that asyncDlgp.exe exits within the configured supervision interval.

5. DCOM & COM Hardening — What to Leave Alone

The SIMATIC documentation makes a specific, deliberate choice about default DCOM permissions, and violating those choices is the fastest way to break the runtime. Treat DCOM as a read-only artifact on a healthy WinCC station.

6. Verification Procedure

Run the following checks in order. Each one should pass before moving to the next; any failure indicates a remaining identity mismatch.

1. Service identity alignment. From an elevated prompt: sc qc "Aspen CIM-IO Manager" | findstr SERVICE_START_NAME and sc qc "Aspen CIM-IO for OPC" | findstr SERVICE_START_NAME. Both lines must show the same principal as the WinCC runtime account from step 4.2.
2. Process identity alignment. Start the AspenTech services, then run wmic process where "name='asyncDlgp.exe'" get name,ProcessId,ExecutablePath /format:list and cross-check the owning user via Sysinternals Process Explorer or wmic process where "name='asyncDlgp.exe'" call getowner. The returned domain\user must match the WinCC runtime account.
3. OPC Scout probe against WinCC.OPC. Launch OPC Scout V10 while logged in as the WinCC runtime account. Connect to OPCServer.WinCC. Add a tag, confirm value update. If OPC Scout succeeds with this account and fails with any other account, identity alignment is confirmed.
4. CIM-IO service test. Restart the AspenTech services and watch the CIM-IO log directory (default %ProgramFiles%\AspenTech\CIMIO\log or the path configured in the CIM-IO Manager). Look for lines such as Connected to OPCServer.WinCC and Item scan complete. A persistent CoCreateInstance or 0x80070005 entry indicates the service is still running as the wrong account.
5. End-to-end historian confirmation. With CIM-IO connected to WinCC.OPC, verify the bridged value lands in Aspen InfoPlus.21 by inspecting the IP21 tag via dm ip21_tag_list or Aspen Process Explorer. This is the production-grade test and the only one that proves the full path is healthy.

7. Alternative & Fallback Configurations

8. Operating Considerations

• Single-account discipline. A WinCC runtime is single-tenant by identity. Do not attempt to mix operators, engineers, and AspenTech services on different accounts — OPC will pick exactly one principal per station and reject every other caller, regardless of local group membership.
• Service start order. Start WinCC Runtime (or the WinCC service hosting SOPCSRVRWinCC.exe) before the AspenTech services. If CIM-IO starts first, it caches a CoCreateInstance failure that is only cleared by a service restart, not by a tag rescan.
• Password rotation. Rotating the password of the shared service account must be done in lockstep on the WinCC service configuration, the Aspen CIM-IO Manager log-on, and the Aspen CIM-IO for OPC log-on. A single missed update re-creates the original fault with no clear error in the WinCC log.
• High-availability / redundant stations. Each redundant WinCC station must have its own aligned AspenTech service account pair. Do not share service principals across nodes; DCOM authentication is host-scoped.
• Hardening post-fix. After the fix is verified, run SIMATIC Security Control once more so that any drift introduced by manual DCOM checks is replaced with the documented baseline.

9. Frequently Asked Questions