OPC DCOM errors on new Windows — step-by-step configuration

OPC Classic (OPC DA/HDA/A&E) runs on Windows COM/DCOM. After a Windows upgrade, a new PC, or a security patch, the OPC client often throws permission errors like 0x80070005 (Access Denied) or 0x800706BA (RPC server unavailable). This is almost always a DCOM + account + firewall issue, not a PLC fault.

Common causes

1. Account mismatch — client and server run under different user/password, or different domain/workgroup.
2. DCOM permissions — Launch/Activation and Access permission not granted to the user (or to ANONYMOUS LOGON when needed).
3. Authentication level — the DCOM hardening patch forces “Packet Integrity”; older servers can't meet it.
4. Firewall — blocks DCOM (port 135 + dynamic port range) between the two machines.
5. Hostname / DNS — client points to the server by a name that can't be resolved.

Step-by-step fix

1. Sync accounts Create the same user + password on both machines (or use a shared domain account). Run the OPC service under that account.
2. Configure DCOM for the app Open dcomcnfg → Component Services → select the OPC server → Properties → grant Launch/Activation & Access permission to the user.
3. Match the authentication level In the Security/General tab, set an appropriate level; account for the DCOM hardening patch — adjust on both ends.
4. Open the firewall Allow port 135 (RPC) + the DCOM dynamic port range, or restrict the DCOM port range then open exactly that range.
5. OPCEnum Make sure the OPCEnum service runs on both machines (allows browsing servers over the network).
6. Consider a tunnel/UA Long term: use an OPC tunneller or move to OPC UA to escape DCOM entirely.

When to call an expert

DCOM is a time-sink: one wrong permission blocks everything. If you keep adjusting without success, or don't want to dig into the Windows security of a running system, DeepDebug can handle it remotely — and advise a path off DCOM (tunnel or OPC UA) so it doesn't recur.