Troubleshooting WinCC 7.4 to KEPServerEX OPC A&E Communication

Problem Overview

When integrating Siemens WinCC 7.4 with KEPServerEX (PTC Kepware) as an OPC A&E (Alarms and Events) client, a recurring failure pattern is observed: the OPC DA (Data Access) channel functions correctly in the KEPServerEX client and tags are browsable and read/write, but the OPC A&E channel returns no alarms, no subscription, and no events. The same asymmetry is frequently encountered after migrating Siemens PCS 7 from V8.0 to V9.0/V9.1 where the project was previously running with a working A&E bridge.

This document captures the full resolution path used in production PCS 7 migrations and standalone WinCC 7.4 stations. The two independent causes that have to be ruled out (or confirmed) are:

1. DCOM security configuration on the WinCC station and on the KEPServerEX station — this is the most common root cause and is fully documented in the Siemens support entry Siemens Support Entry 109768431 — DCOM configuration for OPC.
2. WinCC option licensing — the OPC XML DA, OPC HDA, OPC A&E and OPC UA servers in WinCC 7.4 only start if a valid license for the WinCC Connectivity Pack is installed alongside the WinCC RT license, as described in Siemens Support Entry 109483815 — OPC server license requirements.

If OPC DA shows a green check in tag management and values can be read through OPC Scout but the runtime or a remote client cannot subscribe to A&E notifications, the DCOM/launch permissions side of the problem is almost always involved.

Symptoms and Diagnostic Indicators

Use the following matrix to triage the symptom set you observe in the field. The four indicators that almost always appear together point to the same root-cause cluster.

Indicator	Observed Behavior	Indicates
OPC DA tag channel	Green check in KEPServerEX, tags browseable, values updating	Network + base DCOM working
OPC A&E channel	Server listed in KEPServerEX browser but no alarm area/subscription is created, alarm count = 0	A&E-specific DCOM or license issue
WinCC OPC Scout (V10 / V20)	Both DA server and A&E server appear, A&E shows active alarms and acknowledgements	WinCC internal A&E server is functional
External OPC A&E client (e.g. KEPServerEX, third-party HMI)	Cannot enumerate areas/sources, "Access Denied" or silent no-data	DCOM launch / access permission is missing for the client user or anonymous logon
Event Viewer (Application log)	DCOM error 10016 — "The application-specific permission settings do not grant Local Activation permission for the COM Server application"	Explicit DCOM ACL on the WinCC OPC A&E server CLSID is missing the client identity

The Event Viewer 10016 DistributedCOM error is the single most diagnostic entry. The CLSID reported in the event maps to either the WinCC OPC DA server or the WinCC OPC A&E server executable. If only the A&E channel is broken, the CLSID will belong to OpcAeSrv.exe of WinCC.

Root Cause Analysis

OPC Classic (DA, HDA, A&E) is a DCOM-based distributed component technology. Two independent layers must both be valid:

1. DCOM transport / security layer — governs whether the client process may instantiate, call, and subscribe to the server object on a remote machine. This is configured per-machine in dcomcnfg.exe and per-application in the AppID/CLSID ACL editor.
2. Application / option layer — governs whether the WinCC OPC server processes are loaded at all, and which protocol families they expose. This is configured via the WinCC project and via licenses in the Automation License Manager.

If the OPC DA path works (i.e. the client can instantiate OPCDA.Server.WinCC.1) and the OPC A&E path fails (the client cannot instantiate OPCAlarmsAndEvents.WinCC.1), the DCOM launch permissions for the A&E server executable — or the WinCC Connectivity Pack license — are the only places to look. DA and A&E use different server executables and different CLSIDs in WinCC, so it is technically possible for one to be reachable and the other to be locked down.

Why a successful OPC Scout test is misleading

OPC Scout runs in-process on the WinCC station as the same interactive user that started WinCC Runtime. It uses the local DCOM endpoint and the local user's token, which is already granted every default DCOM permission. As soon as a remote client (KEPServerEX) connects from a different machine or a different service account, the DCOM ACLs are enforced and the call is rejected if the remote identity is not present. This is the reason a working Scout test does not prove end-to-end A&E delivery.

DCOM Configuration Procedure (Authoritative Path)

The Siemens entry 109768431 is the canonical DCOM configuration reference for WinCC / PCS 7 OPC communication. The procedure below condenses the steps that are actually required to make the OPC A&E server reachable by a remote KEPServerEX client.

Prerequisites

• Local administrator on both the WinCC station and the KEPServerEX station.
• A dedicated Windows user account that runs the KEPServerEX service (default: Local System; recommended: a domain user with consistent password).
• Consistent local policy on both machines: Network access: Let Everyone permissions apply to anonymous users must be set if the OPC client connects anonymously.
• Windows Firewall rules that permit DCOM (TCP 135) and the dynamic RPC port range used by the OPC server. Easiest path: add the WinCC OPC servers (OpcAeSrv.exe, OPCDA_ServerWinCC.exe, OPCEnum.exe) to the firewall exception list.

Step 1 — Configure Default DCOM Properties

Run dcomcnfg.exe on the WinCC station. In Component Services → Computers → My Computer → right-click → Properties set the four default tabs as follows:

Tab	Setting	Value
Default Properties	Enable Distributed COM on this computer	Checked
Default Properties	Default Authentication Level	Connect (or Default for legacy clients)
Default Properties	Default Impersonation Level	Identify (for WinCC OPC servers, "Identify" is required — "Anonymous" will break A&E subscription)
Default Protocols	Connection-oriented TCP/IP	First in list, set as default
COM Security → Access Permissions	Edit Limits…	Add ANONYMOUS LOGON, Everyone, the KEPServerEX service user, and the WinCC runtime user — Allow for Local + Remote
COM Security → Access Permissions	Edit Default…	Same list as above
COM Security → Launch and Activation Permissions	Edit Limits…	Add the same identities — Allow Local Launch, Remote Launch, Local Activation, Remote Activation
COM Security → Launch and Activation Permissions	Edit Default…	Same list

Critical: The four ACLs (Edit Limits and Edit Default, for both Access and Launch/Activation) must be edited independently — modifying one does not affect the others. KEPServerEX using the default LocalSystem service identity needs SELF, SYSTEM and Interactive present in the Launch/Activation Default ACL or the COM activation will fail silently with 0x80070005 E_ACCESSDENIED.

Step 2 — Configure the WinCC OPC A&E Server Application

Expand Component Services → Computers → My Computer → DCOM Config. Locate the application whose Application Name matches the WinCC OPC A&E server. The CLSID is stable across WinCC 7.4 SPx installations:

Role	ProgID	CLSID
WinCC OPC DA Server	OPCDA.Server.WinCC.1	{9D44C22E-5FCB-11D2-A4F7-00C04F79D7B0}
WinCC OPC A&E Server	OPCAlarmsAndEvents.WinCC.1	{9D44C22F-5FCB-11D2-A4F7-00C04F79D7B0}
WinCC OPC HDA Server	OPCHDA.Server.WinCC.1	{9D44C230-5FCB-11D2-A4F7-00C04F79D7B0}
WinCC OPC XML DA Server	OPC.XMLDA.1	{1A3F8E78-5FCB-11D2-A4F7-00C04F79D7B0}

Right-click the A&E entry → Properties:

• General tab — Authentication Level: Default (recommended) or Connect; do not select None, which breaks the A&E subscription callback.
• Location tab — Tick Run application on the following computer, enter the WinCC station name. If WinCC and KEPServerEX are on the same host, tick Run application on this computer only.
• Security tab — Customise Launch & Activation Permissions and Access Permissions and explicitly add the KEPServerEX service user and the Anonymous Logon identity with Allow rights. Inheritance from the system defaults is normally insufficient when the OPC client runs as a non-interactive service account.
• Identity tab — For cross-machine A&E, set This user and supply a dedicated service user that exists on both stations with the same password. Launching User is acceptable for same-machine but is the most common cause of inter-station A&E failure.
• Endpoints tab — Ensure at least one connection-oriented TCP/IP endpoint is enabled. NewDCOM endpoints with static port assignment are recommended for firewall-friendly deployments.

Step 3 — Configure the OPCEnum Service

OPCEnum.exe is the COM-Catalog enumerator used by every OPC Classic client. If its DCOM ACL is wrong, clients will not even discover the WinCC servers. Apply the same Launch/Activation/Access ACLs to the OPCEnum DCOM application on the WinCC station, and confirm the service is started:

sc query OpcEnum
# Expected: STATE = 4 RUNNING

Step 4 — Firewall and Port Rules

Open TCP 135 (DCOM/RPC endpoint mapper) and the dynamic RPC range, or — preferred — restrict to the OPC server executables:

netsh advfirewall firewall add rule name="WinCC OPC DA Server" 
  dir=in action=allow program="C:\Program Files (x86)\Siemens\Automation\WinCC\OPC\OPCDA_ServerWinCC.exe" enable=yes
netsh advfirewall firewall add rule name="WinCC OPC A&E Server" 
  dir=in action=allow program="C:\Program Files (x86)\Siemens\Automation\WinCC\OPC\OpcAeSrv.exe" enable=yes
netsh advfirewall firewall add rule name="OPCEnum" 
  dir=in action=allow program="C:\Windows\SysWOW64\OPCEnum.exe" enable=yes

WinCC Connectivity Pack Licensing

Beyond DCOM, the WinCC option licensing layer must be intact. Open SIMATIC Automation License Manager on the WinCC station and confirm both of the following are present, valid, and not in a grace period:

License Slot	Required For	Symptom if Missing
WinCC RT (Runtime)	WinCC Runtime + WinCC OPC DA server	WinCC Runtime does not start
WinCC Connectivity Pack	OPC XML DA, OPC HDA, OPC A&E, OPC UA	OPC servers other than DA do not start; clients see them in OPCEnum but CoCreateInstance returns E_FAIL

If only the DA channel works, this is the most likely cause: the Connectivity Pack license is missing or has been moved to a different station (this happens routinely during PCS 7 OS server migrations). Reinstall the license, restart the WinCC Runtime, and re-test A&E from KEPServerEX.

You can confirm whether the A&E server is even loaded using the WinCC internal service control:

# In WinCC Explorer: Tools → WinCC Explorer → right-click the project → Properties → Runtime
# Verify the option "OPC A&E Server" is enabled and active.
# If the option is grayed out, the Connectivity Pack license is the cause.

KEPServerEX Client Configuration

On the KEPServerEX side, the OPC A&E client driver must be configured to point at the WinCC station's A&E server, not the DA server. The channel and device setup is as follows:

1. In the KEPServerEX configuration, add a new channel of type OPC A&E Client (note: A&E, not DA). Setting the wrong driver type here is a common cause of silent failure.
2. Enter the WinCC station as the server host. KEPServerEX will call OPCEnum on the WinCC station and list OPCAlarmsAndEvents.WinCC.1. Select it explicitly.
3. Configure the KEPServerEX service to run as the dedicated service user that has been granted DCOM access on the WinCC station, or as LocalSystem if the WinCC station's Launch and Activation → Edit Limits ACL includes SYSTEM and SELF with Remote Activation allowed.
4. Under Advanced, set the Keep-Alive interval to 30 s and the Subscription Deadband to 0 — the WinCC A&E server does not honour per-event deadbands and a high deadband can mask state-change events.
5. Add a device and select the WinCC alarm classes (e.g. AlarmHigh, Warning, Fault, System) that should be forwarded. WinCC 7.4 maps these from the project's Alarm Logging configuration.

After saving, click Quick Client in the KEPServerEX configuration. The A&E browser will enumerate the WinCC areas. If the browser shows the areas but no events arrive, the issue is on the WinCC side (event subscription) or in DCOM callback permissions. If the browser shows no areas, the issue is in DCOM initial activation.

PCS 7 8.0 → 9.0/9.1 Migration Notes

The same fault pattern is common after a PCS 7 OS server migration. The DCOM defaults are sometimes reset to Windows defaults by the installation media, and the new WinCC 7.4 SPx OPC server executables are signed with different binary paths. Confirm the following post-migration:

• Re-apply the DCOM ACLs from 109768431 — do not assume the migration carried them across.
• Re-apply the same ACLs on every OS server, not just the master. A&E clients often connect to the standby or a redundant server during failover.
• Re-license the Connectivity Pack on each OS server.
• Verify the OS service account is the same as before the migration.
• If WinCC single-user / multi-user project rights changed, re-validate the Operator Authorization mapping in the alarm logging export — wrong authorization levels cause A&E to be filtered at the source.

Verification and Commissioning

Run the following checks in order; each is a gate to the next.

1. Local A&E test (WinCC station) — Open OPC Scout V10, add the WinCC A&E server, browse areas, subscribe to @System. Active alarms must appear within 2 s. This proves the WinCC A&E server is up and licensed.
2. Remote DCOM test (KEPServerEX station) — Use the KEPServerEX OPC A&E Client channel as a probe. If activation fails, capture the exact HRESULT and cross-reference with the Event Viewer 10016 source CLSID.
3. End-to-end test — Trigger a controlled WinCC alarm (force an unacknowledged alarm in Alarm Logging) and confirm the event arrives in KEPServerEX within the keep-alive interval. Confirm the priority, area, source, and message fields are populated — partial population indicates a misformatted subscription filter.
4. Acknowledgement round-trip — Acknowledge the alarm in KEPServerEX and confirm the acknowledgement is reflected back in WinCC Alarm Logging. If the acknowledgement is one-directional, the impersonation level in the A&E server's Security tab is the cause.
5. Stress / failover test — Run the test on a redundant OS pair and trigger a master→standby failover. The KEPServerEX client should reconnect automatically. A reconnect timeout longer than the client's keep-alive means the OPC A&E server's EndPoints tab is not advertising the standby.

Common Pitfalls and Field Notes

Pitfall	Symptom	Fix
Impersonation Level set to "Anonymous" in Default Properties	DA works, A&E silently returns no events	Set to Identify
KEPServerEX running as LocalSystem, WinCC ACL has only Interactive	0x80070005 on activation	Add SYSTEM and SELF to Launch/Activation ACL
Connectivity Pack license installed on wrong station	OPCEnum lists A&E server but CoCreateInstance fails	Reinstall license on the WinCC runtime station
Windows Firewall enabled after WinCC installation	DA works locally, A&E fails remotely	Add firewall rules for OpcAeSrv.exe and OPCEnum.exe
Different service accounts on OS server and KEPServerEX station	Intermittent subscription drops	Use a dedicated domain service account with identical credentials on both sides
DCOM Machine Access / Machine Launch Limits removed during a security hardening pass	All OPC clients broken, not only A&E	Restore the four default ACLs to include ANONYMOUS LOGON, Everyone, SYSTEM, Interactive
Time skew > 5 minutes between WinCC and KEPServerEX	Kerberos authentication fails; NTLM fallback is used and may be denied	Synchronize time to a common NTP source
Antivirus / EDR blocking OpcAeSrv.exe child processes	Activation succeeds, callback fails	Add WinCC OPC executables to the AV exclusion list
Routing/ARP between stations in different VLANs blocks UDP 135	OPCEnum timeout, no servers listed	Use a static DCOM endpoint range and open TCP only

Quick Diagnostic Flowchart

1. Does OPC DA work from KEPServerEX? → If no, fix the base DCOM layer first (Machine Access / Machine Launch Limits, firewall, OPCEnum). If yes, continue.
2. Does OPC A&E work from OPC Scout on the WinCC station? → If no, the WinCC A&E server is not started; check the Connectivity Pack license and the WinCC project's Runtime → OPC A&E option. If yes, continue.
3. Does OPC A&E work from KEPServerEX? → If no, capture the HRESULT and the Event Viewer 10016 CLSID. The CLSID will tell you whether the A&E server is registered (good) or whether the issue is in client-side activation (recheck the application-level ACLs).
4. Are events received but empty? → The subscription is connected but the filter or impersonation is wrong. Lower the impersonation level and disable the filter.
5. Are events received and acknowledged in one direction only? → Fix the Impersonation Level in the A&E server's Security tab.

Reference Parameters

Parameter	Recommended Value	Notes
Default Authentication Level	Connect (default)	Raising to Packet Integrity / Packet Privacy can break legacy clients
Default Impersonation Level	Identify	WinCC OPC A&E requires Identify; Anonymous returns no events
OPC A&E Specification	1.10 (WinCC 7.4 supports 1.10 and 2.0 for DA, 1.10 for A&E)	KEPServerEX A&E client driver supports up to 1.10
Default Protocol	Connection-oriented TCP/IP	UDP is deprecated and unreliable across subnets
KEPServerEX service identity	Domain service user, identical password on both stations	Avoids NTLM pass-through issues
Keep-alive interval (KEPServerEX)	30 s	Shorter than the OS server's OPC timeout
Subscription deadband	0	WinCC A&E ignores per-event deadbands

FAQ