OPC DA

OPC DA (Data Access) is the most widely used component of the OPC Classic standards. It is built on Windows COM/DCOM technology and provides real-time data access. It was used as the de facto standard in industrial automation before OPC UA.

inSCADA supports the OPC DA protocol in Client role only.

Note

OPC DA is built on Windows COM/DCOM, and inSCADA’s OPC DA client uses a native Windows library. inSCADA itself therefore has to run on Windows — the OPC server may be on another machine, but an inSCADA running on Linux cannot open an OPC DA connection. Starting one gives:

OPC DA needs inSCADA to run on Windows (COM/DCOM); this server runs on Linux.

For a platform-independent solution, prefer OPC UA.

OPC DA vs OPC UA

Feature	OPC DA	OPC UA
Platform	Windows only	Platform independent
Technology	COM/DCOM	TCP/IP, HTTP, WebSocket
Security	DCOM security	TLS, certificates, user auth
Discovery	Via DCOM	Browse + Discovery
Status	Legacy	Active development

Data Model

Configuration

Connection

Parameter	Example	Description
Protocol	OPC DA	Protocol selection
IP Address	192.168.1.100	OPC DA server IP address
Port	135	DCOM port (default: 135)
COM ProgID	Matrikon.OPC.Simulation	OPC server COM programmatic identifier
Separator	.	Tag path separator character (default: dot)
Max Depth	12	Tag tree browse depth
Server Status Check Time	30000 ms	Server status check period
Username	SERVER\\opcuser	The connection’s Windows account — see the Windows account for a remote server
Password	••••	That account’s password

Tip

COM ProgID is the OPC server’s programmatic name in the Windows Registry. Examples: Matrikon.OPC.Simulation, KEPServerEX.V6, RSLinx OPC Server. It can be found from the OPC server documentation or OPC browser tools.

Device

Parameter	Example	Description
Scan Time	1000 ms	Scan period
Scan Type	PERIODIC	PERIODIC or FIXED_DELAY

Frame

Parameter	Example	Description
Use Subscription Mode	true	Subscription-based data retrieval (notification on change)
Percent Deadband	0.5	Analog value change threshold (%)

Subscription Mode: When true, the OPC server sends notifications only when values change — reducing network traffic and CPU load. When false, periodic polling is performed.

Variable

Parameter	Example	Description
Name	Temperature	Variable name (also used as OPC Item ID)
Type	VT_R4	OPC DA data type
Array Index	0	The element index on an array-valued item (0 – 65535)

Supported Data Types (VARIANT Types)

Data Type	Description
VT_BOOL	Boolean
VT_I1	Signed 8-bit integer
VT_UI1	Unsigned 8-bit integer
VT_I2	Signed 16-bit integer
VT_UI2	Unsigned 16-bit integer
VT_INT	Signed 32-bit integer
VT_UINT	Unsigned 32-bit integer
VT_I8	Signed 64-bit integer
VT_R4	32-bit floating point (float)
VT_R8	64-bit floating point (double)
VT_BSTR	Character string

Browse (Discovery)

inSCADA can discover available items by browsing the OPC DA server’s tag tree. This feature makes it easier to find the correct Item ID information when defining variables.

A remote server: what to do on both machines

This section covers the case where the OPC server sits on another Windows machine. With the server on the same machine as inSCADA, none of it is needed — DCOM never comes into play.

Three network steps

A DCOM connection goes through three separate steps, each with requirements of its own. The quickest way to understand why an installation is not working is to find which step it fails at.

Step	Direction	What happens	What it needs
1. Activation	inSCADA → server machine, TCP 135	The server machine starts the OPC server; COM ProgID is resolved there	An account with DCOM permission, 135 open
2. Calls	inSCADA → the OPC server process, dynamic port	Reads, writes, browse	Inbound permission for the OPC server’s program on the server machine
3. Callback	server → inSCADA, dynamic port	Subscription values	Inbound permission for Java on the inSCADA machine, and a matching DCOM permission

Most guides skip the third step

With subscriptions on (the default) the OPC server sends the values itself. The connection is made in the opposite direction, and the inSCADA machine has to accept an incoming DCOM call. “I can read but subscription values never arrive” is almost always this step.

1. The Windows account: who inSCADA connects as

There are two ways.

a) An account on the connection — recommended. Fill in Username and Password on the connection form; the user name is SERVER\user (workgroup) or DOMAIN\user. inSCADA then makes all of that connection’s outgoing calls as that account: activation, reads, writes, browse and the server list. It is the same thing Windows does with runas /netonly — the inSCADA service keeps running under its own account and only goes out to the network as this one.

What that buys you: the inSCADA service account does not need a mirror on the server machine, and different servers can be reached with different accounts.

b) The service account. With the user name left empty, calls go out under the account the inSCADA service runs as. In a workgroup that means creating a local account on the server machine with the same name and the same password. If the service runs as LocalSystem, a remote server in a workgroup cannot be reached this way; use (a).

Either way: group membership on the server machine

The account given must exist on the OPC server machine and belong to two groups:

Add-LocalGroupMember -SID S-1-5-32-562 -Member <account>   # Distributed COM Users
Add-LocalGroupMember -Group Users       -Member <account>

Distributed COM Users grants remote activation and access. Users is needed as well because some OPC servers open their own DCOM access list only to Users and SYSTEM — and an account created with New-LocalUser does not join Users by itself.

Those two memberships are enough: the machine-wide limits under dcomcnfg, and the per-application launch and access settings, do not have to be touched.

A local administrator account is not enough

In a workgroup, Windows downgrades the token of a local administrator arriving over the network (the UAC remote restriction). An account in the server’s Administrators group still gets 0x80070005 E_ACCESSDENIED for DCOM. Making it an administrator does not help; Distributed COM Users membership is what does.

A Windows Hello PIN is not a network password

Network authentication uses the account’s real password. And the password is not checked as you type it into the connection form — a wrong one only surfaces as 0x80070005 at connect time. Event 4625 (substatus 0xC000006A) in the server machine’s Security log confirms it.

2. Firewall: the OPC server machine

TCP 135 is for activation only. Once started, the OPC server opens a dynamic port in its own process, and reads, writes and browse go there. What needs an inbound allow on the server machine:

• TCP 135
• The OPC server’s executable
• OpcEnum.exe — where COM ProgID is resolved, and where the server list comes from

New-NetFirewallRule -DisplayName "OPC DA: server runtime" -Direction Inbound -Action Allow -Profile Any `
  -Program "C:\Program Files (x86)\<vendor>\<server>.exe" -RemoteAddress <inSCADA IP>

A general “TCP 135” rule is not enough — the commonest mistake

Write the rule for the program, not the port. The server’s dynamic port can change on every start.

The symptom: the connection is made, the server starts, and then it waits about 40 seconds and drops with:

The server started but did not give IOPCServer (HRESULT 0x800706BA RPC_S_SERVER_UNAVAILABLE)

Activation over 135 succeeded, but the server process’s own port could not be reached. With a program rule in place, the same servers connect within seconds.

If OpcEnum cannot be reached: a CLSID instead of a ProgID

In the COM ProgID field you can write the server’s CLSID without braces instead of its ProgID — for example F8582CF2-88FB-11D0-B850-00C0F0104305. inSCADA then starts that class directly, without asking OpcEnum at all. The CLSID is shown beside each server in the server list.

If the network team would rather open a single port range, Windows’ dynamic RPC range can be narrowed on the server machine under HKLM\SOFTWARE\Microsoft\Rpc\Internet. That is a machine-wide setting affecting every DCOM server on it; a per-program rule is narrower and more predictable.

3. Subscriptions: the server’s callback to inSCADA

On frames with Use Subscription Mode on (the default), the OPC server sends values to inSCADA itself.

The inSCADA machine’s firewall must allow inbound connections to the java.exe running inSCADA.

Which DCOM permission is needed depends on the account the OPC server runs as:

The account the OPC server runs as	The callback’s identity	Needed on the inSCADA machine
A named account that also exists on the inSCADA machine with the same name and password	That account, NTLMv2	Nothing extra — recommended
LocalSystem, workgroup	ANONYMOUS LOGON, NTLMv1	Remote DCOM access for ANONYMOUS LOGON

The arrangement to aim for

Run the OPC server as a service under a named account that also exists on the inSCADA machine: on the server machine, services.msc → the service → Log On → This account. Windows grants the “log on as a service” right as you do it.

The callback then arrives identified, and you never have to open anonymous access on the inSCADA machine.

The connection’s account does not change the callback

The Username/Password from step 1 are used only on calls going out of inSCADA. The callback’s identity is always the account the OPC server runs as. Giving the connection an account therefore does not remove the third step’s requirement.

Where the server runs as LocalSystem in a workgroup, the anonymous permission is granted on the inSCADA machine through dcomcnfg → My Computer → Properties → COM Security → Access Permissions → Edit Limits → ANONYMOUS LOGON → Remote Access: Allow.

That path is fragile

An anonymous callback from a LocalSystem server uses NTLMv1, and NTLMv1 is being withdrawn from Windows. Such an installation may stop working later — running the server under a named account is both safer today and more durable tomorrow.

No data is lost if a subscription cannot be set up

inSCADA falls back to polling the frame at the device’s scan time, and warns once:

Subscription could not be set up for frame <frame>; it is polled instead. Cause: ...

Values still arrive — periodically rather than on change. That can be the reason a screen shows “the data is there but it is late”.

Error codes

HRESULT	Meaning	Where to look
0x80070005 E_ACCESSDENIED	The account has no DCOM permission	Step 1 — group membership, password
0x800401F3	COM ProgID is not registered	The ProgID’s spelling; is the server actually installed
0x800706BA RPC_S_SERVER_UNAVAILABLE	The server, or the server process’s port, cannot be reached	Step 2 — the per-program firewall rule
0xC0040007 / 0xC0040008	The variable’s name does not exist on the server	The variable’s Name
0x80040202	The subscription callback could not be set up	Step 3
0xC0040004 OPC_E_BADTYPE	The server could not convert the written value to the item’s type	The variable’s Type

An unknown variable does not drop the connection

If a variable’s name does not exist on the server, inSCADA leaves that variable out of the connection, marks its value as no communication and logs The OPC DA server does not know <n> item(s). The rest of the connection keeps working.

Checklist

The OPC server machine

• The account given on the connection exists here, in Distributed COM Users and Users
• Firewall: inbound allow for TCP 135, the OPC server’s program, and OpcEnum.exe
• The OPC server runs under a named account where possible

The inSCADA machine

• inSCADA is running on Windows
• Firewall: inbound allow for java.exe
• If the OPC server runs as LocalSystem in a workgroup: remote DCOM access for ANONYMOUS LOGON

What this section was measured on

Every requirement here was found by testing it in a lab rather than inferred: both machines Windows 11 Pro, build 26200, on the same network and in a workgroup. The OPC servers used were Matrikon.OPC.Simulation, KEPServerEX V4 and V6, and TMW.

This is not a support matrix — it does not mean other Windows versions will not work. It says where the steps above come from.

A domain installation was not tested in that lab. Giving the user name as DOMAIN\user is supported by the product, but the behaviour in a domain was not measured; on a domain-joined installation, verify the steps above as you go.

Windows and DCOM: how much life is left

There is no decision that makes OPC DA unusable after a particular Windows version. Microsoft has not removed DCOM from any Windows release and has not announced that it will. But three developments narrow OPC DA’s practical life, and they belong in any plan for a new installation.

The DCOM hardening became permanent (14 March 2023). Microsoft shipped the hardening for CVE-2021-26414 in three phases: off in June 2021, on but disableable in June 2022, and on with no way to disable it from March 2023. Activation now requires at least RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, and the RequireIntegrityActivationAuthenticationLevel registry value that used to switch it off no longer does anything. Only cross-machine OPC DA is affected — a client and server on one machine never use DCOM.

The Windows versions underneath are going out of support. Most OPC DA installations sit on older Windows. Support for Windows 10 ended on 14 October 2025; for Windows 10 Enterprise LTSC 2021 the date is 12 January 2027. That is not an OPC DA limit, but it governs the machines OPC DA lives on.

NTLMv1 is being withdrawn. The anonymous callback from a server running as LocalSystem uses NTLMv1, and that authentication method is being removed from Windows. The recommended arrangement above (a named account, NTLMv2) does not carry that risk.

What this means in practice

If you are building an OPC DA installation today, the order of preference is:

1. Use OPC UA where you can. None of DCOM’s problems apply, and it is platform-independent.
2. Put the OPC server on the same machine as inSCADA. DCOM drops out and nothing in this section is needed.
3. Where neither is possible, follow this section with a named account and avoid the path that depends on NTLMv1.