OPC DA and DCOM errors after Windows updates: KB5004442, what to check and the path to OPC UA

When OPC DA works on one computer but fails between two, or stopped working after Windows updates, the cause is usually DCOM authentication. Since Microsoft's update of 14 March 2023, Windows enforces DCOM hardening permanently: activation across machines must use at least the Packet Integrity authentication level, and OPC software that asks for less is refused. The short-term fix is current software and proper accounts at both ends; the lasting fix is to stop sending DCOM over the plant network.

Why OPC Classic depends on DCOM

The OPC Foundation groups OPC Data Access (DA), Alarms & Events (A&E) and Historical Data Access (HDA) under the name OPC Classic, built on Microsoft COM. A client and server on the same computer talk through local COM. On different computers the same calls travel as DCOM, which Microsoft describes as a protocol that exposes application objects through remote procedure calls (RPC).

• Windows only. Inductive Automation notes that its OPC COM connection exists only on Windows gateways; other operating systems must use OPC UA.
• Traffic in both directions. The same page explains that the OPC server calls back to the client with data. A client can connect and still show bad quality if the callback is blocked.
• RPC ports. RPC clients ask the endpoint mapper on TCP 135 which dynamic port a service was given. Microsoft lists 49152–65535 as the default dynamic range from Windows Vista and Server 2008 onward, and gives DCOM as a random port in that range.

One of the reasons the OPC Foundation gives for creating OPC UA is that Microsoft has de-emphasised COM and DCOM in favour of cross-platform service-oriented architecture. It also describes OPC UA as firewall-friendly.

What Microsoft changed: KB5004442

Microsoft's support article KB5004442 describes DCOM hardening made for the vulnerability CVE-2021-26414. With it enabled, a DCOM server requires activation requests at authentication level RPC_C_AUTHN_LEVEL_PKT_INTEGRITY (level 5, Packet Integrity in configuration tools) or higher. It came in three phases:

The registry value is RequireIntegrityActivationAuthenticationLevel under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat. Microsoft describes it for the phases in which the hardening could be switched; Phase 3 removes the ability to disable it. Old advice to switch the hardening off through this value no longer works on a computer with current updates.

The same page adds two points:

• Client auto-elevation. Updates from November 2022 to January 2023 raise non-anonymous activation requests from Windows DCOM clients to Packet Integrity automatically, so most Windows clients work unchanged once both ends have the January 2023 cumulative updates.
• Anonymous activation is outside the hardening. A DCOM server that allows anonymous activation still allows it. This is not a fix: on the OPC Foundation forum, the administrator warns that a DA server running without security is exposed to attackers on the network.

The code side is explained in that forum post and in Matrikon's 2022 white paper. An OPC client that calls CoInitializeSecurity, or sets the level explicitly when it creates the server object, must request Packet Integrity itself, because its own setting overrides the Windows default. If it does not, only a new version from its vendor helps; Matrikon says Windows settings alone cannot work around it. Both documents date from 2022, before the auto-elevation updates. If event 10037 or 10038 still names the application on a fully updated client, Microsoft's event text also sends you to the application vendor.

Symptoms and what they point to

Microsoft added DCOM error events to the System log to find incompatible applications. They exist only on the Windows versions and updates listed in KB5004442, for example from the August 2021 update for Windows Server 2019 and the October 2021 update for Windows Server 2012 R2.

Both codes come from Microsoft's tables: 0x80070005 is E_ACCESSDENIED in the COM error list, and HRESULT_FROM_WIN32 places a Windows error in the 0x8007xxxx range, so error 1722 (hex 6BA) becomes 0x800706BA.

What to check, in order

1. Confirm that DCOM is involved. Matrikon and Softing both state that OPC Classic communication on one computer is not affected. A local link that fails has a cause other than the hardening.
2. Bring both PCs to current updates. Microsoft recommends the latest security updates. Rockwell's help warns that patched and unpatched computers cannot communicate reliably, because both ends need the same authentication level.
3. Read the System log on both ends. Event 10036 on the server gives user and client IP; 10037 or 10038 on the client names the application.
4. Check that the OPC software supports Packet Integrity. Rockwell's help says the minimum DCOM authentication level used by its products was raised to Packet Integrity, and points to notice PN1581 for the affected products. Softing's February 2023 notice lists products for which it strongly recommends a tunnel instead of DCOM, among them dataFEED OPC Suite 5.19 or older, and says it does not support problems with remote OPC Classic connections. Siemens' Desigo CC help states that every OPC component in the path must support the hardening. Ask each vendor which version you need.
5. Check where the level is set. Matrikon's test procedure sets the default level, and the level of each OPC server in DCOM Config, to Packet Integrity; Softing names Packet Integrity or Packet Privacy. FactoryTalk software and RSLinx Classic instead keep their own DCOMAuthLevel (5 after upgrading the Rockwell software) and ignore the Component Services setting. Rockwell's help also lists backward-compatibility options for mixed systems, which remove the Microsoft update or lower the level, and states that levels below 5 are not supported once the Microsoft update is installed. Updating both ends is the route that keeps the protection.
6. Check the accounts. Rockwell's help says that in a workgroup each user must exist on every computer in the connection with the same name and password, and blank passwords generally fail; in a domain, domain accounts are used. Give DCOM launch, activation and access rights to the accounts that run the OPC client and server, and to nobody else.
7. Check OPC Core Components. Inductive Automation requires them on both machines for a remote connection, each in the 32-bit or 64-bit package that suits that machine.
8. Check the firewall both ways. TCP 135 and the dynamic range must be open between the two hosts, including callbacks to the client, and only between them. The firewall article explains why the dynamic range should not be narrowed too far.

Some older vendor guides suggest granting Everyone and ANONYMOUS full rights or setting the default authentication level to None. That removes authentication: the hardening does not cover anonymous activation, so the server is open to anyone who can reach it. Grant DCOM rights only to the accounts that need them. If an old client cannot reach Packet Integrity, plan one of the routes below.

Long-term routes: take DCOM off the network

One PC. If the OPC DA server can run on the SCADA or historian computer, the DCOM link disappears; that PC then needs its own route to the controllers.

Tunnel or wrapper. The OPC Foundation forum post suggests a proxy or wrapper using COM locally and OPC UA on the network. Matrikon's UA Tunneller connects locally to OPC Classic clients and servers and uses TCP/IP between its components, without changes to existing applications. Softing recommends its dataFEED OPC Tunnel instead of DCOM for remote links. Ignition's OPC COM Tunneller exposes local COM connections through Ignition's OPC UA server. PTC's Kepware tutorial shows a similar pattern: an OPC UA Client driver on one computer reads a Kepware server on another, and an OPC DA client reads the local instance.

Native OPC UA. OPC UA was released in 2008. It runs on Windows, Linux and other systems, from PCs and cloud servers to PLCs and microcontrollers, and its security includes X.509 application certificates, message signing, encryption, user authentication and auditing. OPC UA Part 6 gives opc.tcp port 4840 as the well-known address of the Local Discovery Server; each server's endpoint port is set in the product. PTC's tutorial says to note that port for the firewall exception and that the default endpoint accepts only signed and encrypted connections. Keep it that way: with the policy None, the tutorial notes, certificates are not validated.

How OPC UA fits into zones and conduits is covered in the IEC 62443 article, and the layers it connects in What is SCADA.

Applying it on a project

• List every OPC Classic link: client PC, server PC, both software versions, DA, A&E or HDA, and whether it crosses machines. Historians can read through an OPC DA interface, as the historian article describes.
• Ask vendors for the Packet Integrity version of each client and server, and test on patched machines before the plant applies updates.
• Prefer OPC UA for new links and replace cross-machine DCOM links during upgrades.
• Do not weaken security to make a link work: no broad accounts, no anonymous access, no authentication level of None, and firewall rules limited to the hosts involved.

TDL's page on connecting existing equipment to SCADA describes bringing BACnet/IP equipment into SCADA through gateways and KEPServerEX, and the SCADA and historian page describes historian data from PLCs and third-party systems over OPC UA, Kepware and Modbus. If a FactoryTalk View SE client is what fails, see FactoryTalk View SE client cannot connect.