Resolving OPC-DA Write Access Denied in WinCC RT Advanced V16

Problem Overview

An HMI project built with TIA Portal V16 and deployed on Siemens WinCC Runtime Advanced 16 exposes its internal tag database over the OPC Data Access (OPC-DA) server shipped with the runtime. When a third-party OPC-DA client — Integration Objects OPC Explorer, MatrikonOPC Explorer, Kepware Quick Client, OPC DA Spy — connects to the runtime, tag enumeration and synchronous/asynchronous read operations succeed, but every write call is rejected with the standard OPC error string OPC_E_BADRIGHTS (HRESULT 0x80070005, "Access is denied") or with the higher-level diagnostic E_ACCESSDENIED. The diagnostic rendered to the operator typically reads "The Item Access rights do not allow the operation" or "The item is write protected", even though the tag is explicitly configured for read/write access in the HMI configuration editor.

The behavior is independent of the host operating system — Windows 7 SP1 (where supported by TIA V16) and Windows 10 1809 through 21H2 exhibit the same fault — and independent of the network topology, because the failure also reproduces when the OPC client is installed on the same workstation as the WinCC Runtime. Swapping the test client, disabling the Windows Firewall, or modifying DCOM security descriptors does not resolve the fault. The defect is not present in TIA Portal V15.1, and the standard escalation path through regional Siemens support has confirmed the issue as a software defect in TIA V16 forwarded to factory engineering for formal resolution. The fingerprint of the failure (OPC-DA reads OK, OPC-DA writes rejected, OPC-UA writes succeed) is unique and points directly at a V16-specific OPC server side effect.

OPC Data Access Architecture and Write Authorization Model

OPC Data Access is the original real-time data transfer specification from the OPC Foundation, ratified in three versions: 1.0 (1996, simple synchronous read/write), 2.0 (1999, added asynchronous subscription and dead-band), and 3.0 (2003, added complex data, time-stamped writes, and keep-alive). The specification defines the contract between an OPC server and one or more OPC clients over Microsoft COM/DCOM. Three access rights are exposed on every server-managed item:

The WinCC RT Advanced OPC-DA server advertises the access rights for each tag through the IOPCItemProperties interface, property ID 4 (ItemAccessRights) and property ID 5 (ItemDeadband). When the client issues WriteVQT, Write, or WriteMultiple, the server performs two checks before applying the new value to the runtime tag database:

1. Tag-level access-right check. The ItemAccessRights property of the tag must contain OPC_WRITEABLE. This is the value configured in the HMI tag editor under Properties → Access Protection. When writes are rejected as "write protected" this check is the one failing — even though the configuration is correct, the OPC server returns the wrong access mask.
2. COM security check. The Windows DCOM layer must permit the client's launch, activation, and access against the OPC server's AppID security descriptor. The OPC Enum service (OpcEnum), the OPC server executable, and the helper DLLs run under a COM identity that is evaluated against the client's COM security descriptor.

Failure of the first check yields an OPC_E_BADRIGHTS return code with the COM E_ACCESSDENIED HRESULT. Failure of the second check yields the same HRESULT but is logged in the Windows COM+ Event log with a different event source (DCOM, Event ID 10016). The V16 defect being addressed here corrupts the first check inside the server's tag-rights enumeration helper, sopcdacmnsrv.dll, so the server reports every tag as read-only even when the HMI database says otherwise.

OPC DA COM Interfaces Used for Write Operations

To triage the failure precisely, identify which OPC Foundation COM interface is returning the rejection. The OPC-DA specification defines three write paths:

Regardless of which write path the client uses, the rejection originates from the server's access-right decision before the value is committed. The OPC client's display message ("Item is write protected", "Item Access rights do not allow the operation") is a localization of the OPC_E_BADRIGHTS HRESULT and does not by itself distinguish the V16 defect from a user-rights or DCOM misconfiguration. The diagnostic that distinguishes them is the reported access right in the browse result: with the V16 defect, every tag reports 0x01 regardless of the HMI configuration; with a real DCOM problem, the access right is 0x03 but the write still fails with a different HRESULT (0x80010108, RPC_E_DISCONNECTED, or 0x800706BA, RPC_E_SERVER_UNAVAILABLE).

Affected Versions and Symptom Matrix

Affected operating systems include Windows 10 (1809 through 22H2), Windows Server 2016, and Windows Server 2019 when used as a WinCC RT Advanced host. Windows 7 SP1 exhibits the same fault because the failure is in the OPC server helper DLL, not in the OS layer. Windows 11 21H2 and 22H2 deployments of TIA V16 are not officially supported by Siemens, but the same sopcdacmnsrv.dll binary is loaded when V16 is force-installed, so the same failure is reproduced.

Root Cause: Defective sopcdacmnsrv.dll in TIA Portal V16

The WinCC OPC-DA server is implemented as an in-process COM server that loads sopcdacmnsrv.dll from %CommonProgramFiles(x86)%\Siemens\OPC\sopcdacmnsrv.dll. This module translates the WinCC tag database into the OPC Foundation item tree, including the per-item ItemAccessRights property. In TIA Portal V16 the initial build of this DLL returns a static OPC_READABLE value for every enumerated item, regardless of the tag's configured access mode. The OPC-DA client therefore sees each tag as read-only and refuses every write with OPC_E_BADRIGHTS.

The defect can be confirmed before applying the fix with a four-step diagnostic:

1. Open the OPC client and connect to the WinCC OPC-DA server using its ProgID. For WinCC RT Advanced V16 the ProgID is registered under HKEY_CLASSES_ROOT\<project-specific ProgID>; confirm by inspecting the registry tree on the runtime PC.
2. Browse or enumerate the tag tree.
3. Inspect the ItemAccessRights property for a known writable tag. The reported rights will be 0x01 (read-only) even though the HMI configuration shows Access: read/write.
4. Attempt a write operation. The client receives 0x80070005 with the message "Access is denied" or "Item is write protected".
5. Switch the client to OPC-UA using the WinCC RT Advanced UA endpoint (default URL opc.tcp://<host>:4870) and repeat the write. The write succeeds.

The differential diagnosis — OPC-DA write fails, OPC-UA write succeeds, on the same HMI tags — is the unique fingerprint of the sopcdacmnsrv.dll defect. When the same fingerprint is observed in the field, skip generic DCOM, firewall, and user-rights troubleshooting and go straight to the DLL replacement.

Prerequisites for OPC-DA Write Access in WinCC RT Advanced

Before applying the V16-specific fix, confirm that the base installation satisfies the prerequisites for any WinCC RT Advanced OPC-DA deployment:

• WinCC Runtime Advanced installation complete. Install from the WinCC RT Advanced DVD/ISO using Setup.exe /Install or via the TIA Portal Add-In. Some OPC components are only installed when the OPC feature is selected in the custom setup dialog.
• OPC XML Gateway installed. Even if the project uses OPC-DA and never calls OPC-XML, install the OPC XML Gateway component. Without it, some tag enumeration paths return incomplete access-right metadata that compounds the V16 defect by hiding additional failed tags.
• Windows user account with administrator privilege on the HMI runtime PC.
• Runtime project started with the Run as service option disabled for diagnosis; running as a foreground application surfaces log messages in %ProgramData%\Siemens\Automation\Logfiles.
• DCOM access permissions configured for the OPC user. The default "Everyone" for access and launch is acceptable for a single-machine integration but must be tightened for any production network per the security hardening section below.
• File-hash capture tool available (PowerShell Get-FileHash or Sysinternals sigcheck) to record before/after file integrity for change-management compliance.

Step-by-Step Resolution Procedure

Step 1 — Confirm Complete Runtime Installation

Re-run the WinCC Runtime Advanced installer from the matching DVD/ISO. From the WinCC RT Advanced V16 DVD entry point documented at Siemens Support Entry ID 109062698, perform a custom install and verify the following components are selected:

• WinCC Runtime Advanced
• OPC Server (DA)
• OPC XML Gateway
• WinCC Runtime Advanced — Communication modules for the project's target PLC network (PROFINET, PROFIBUS, or MPI as applicable)

If any component is missing, the OPC-DA server may still register but will fail internal calls with COM exceptions that the V16 defect will mask.

Step 2 — Configure DCOM Launch and Access Permissions

Even though the V16 defect is in the application layer, misconfigured DCOM permissions will re-create the failure after the DLL replacement. Configure DCOM globally and per-application using the Microsoft COM technical overview as the reference for the security model:

1. Open dcomcnfg.exe from an elevated command prompt.
2. Navigate to Component Services → Computers → My Computer → DCOM Config.
3. Right-click My Computer, choose Properties, open the Default Properties tab:
   • Enable Enable Distributed COM on this computer.
   • Default Authentication Level: Connect.
   • Default Impersonation Level: Identify.
4. Open the COM Security tab:
   • Access Permissions → Edit Limits: add ANONYMOUS LOGON, Everyone, and the OPC client user with Allow for Local Access and Remote Access.
   • Launch and Activation Permissions → Edit Limits: add ANONYMOUS LOGON, Everyone, and the OPC client user with Allow for all four operations (Local Launch, Remote Launch, Local Activation, Remote Activation).
5. Locate the OPC-DA server application in DCOM Config. For WinCC RT Advanced this appears as the ProgID listed in HKEY_CLASSES_ROOT\AppID. Right-click → Properties → Security tab:
   • Use the same customized launch and access permissions; do not inherit from the default if those are locked down.
   • On the Identity tab, choose This user and provide a service account that has write access to the WinCC runtime tag database file (default location: %ProgramData%\Siemens\Automation\HmiRTm\Tags.db).

Step 3 — Configure Windows Firewall Rules

The OPC-DA server uses dynamic TCP ports (TCP/135 plus RPC-allocated ephemeral ports in the 49152-65535 range by default). Open inbound rules for:

• %SystemRoot%\SysWOW64\dllhost.exe — TCP, all ports, profile "Domain, Private". The 32-bit dllhost is required because the WinCC OPC-DA server is a 32-bit in-process COM server even on 64-bit Windows.
• The WinCC Runtime Advanced executable (default C:\Program Files\Siemens\Automation\HmiRTm\HmiRTm.exe or the project-specific deployment path).

For initial diagnosis, the quickest path is to disable the firewall entirely on the workstation, confirm writes succeed after the DLL replacement, then re-enable the firewall and add the targeted inbound rules. A misconfigured firewall will produce RPC connection errors, not "Item is write protected" errors, so the firewall is a secondary defense rather than the primary fix.

Step 4 — Install OPC XML Gateway (Even When Not Used)

Reinstall the runtime with the OPC XML Gateway feature checked. This installs the SOAP tunneler and a set of helper services that participate in tag enumeration. Some configurations report incomplete access-right metadata when the OPC XML Gateway is absent, which can compound the V16 defect by hiding additional failed tags and producing misleading diagnostic output. The component does not consume significant resources and can safely remain installed.

Step 5 — Replace sopcdacmnsrv.dll with the V15.1 Build

The field-proven workaround is to replace the V16 build of sopcdacmnsrv.dll with the V15.1 build, then re-register the COM server:

1. Stop the WinCC Runtime Advanced instance.
2. Stop the OPC Enum service: sc stop OpcEnum.
3. Open an elevated cmd.exe and navigate to the OPC install directory:

   cd "%CommonProgramFiles(x86)%\Siemens\OPC"

4. Take ownership and record the file hash:

   takeown /f sopcdacmnsrv.dll
   icacls sopcdacmnsrv.dll /grant Administrators:F
   Get-FileHash sopcdacmnsrv.dll -Algorithm SHA256 | Tee-Object -FilePath sopcdacmnsrv_V16.sha256

5. Rename the V16 file as a backup:

   ren sopcdacmnsrv.dll sopcdacmnsrv.dll.V16.bak

6. Copy the V15.1 file into the directory from a verified source:

   copy /Y "\\fileserver\Siemens\OPC_V15.1\sopcdacmnsrv.dll" "%CommonProgramFiles(x86)%\Siemens\OPC\"

7. Unregister the backup and register the replacement:

   regsvr32 /u sopcdacmnsrv.dll.V16.bak
   regsvr32 /i sopcdacmnsrv.dll

8. Restart the OPC Enum service and the WinCC Runtime:

   sc start OpcEnum
   net start "Siemens HMI Runtime Advanced"

Verification Procedure

After applying the fix, verify both functional and diagnostic layers.

Functional Verification (OPC-DA Client)

1. Launch the OPC-DA client (Integration Objects OPC Explorer, MatrikonOPC Explorer, Kepware Quick Client, or any OPC Foundation-compliant client).
2. Connect to the WinCC RT Advanced OPC-DA server using its ProgID and host name (or localhost).
3. Enumerate the tag tree and inspect the ItemAccessRights property for a previously writable tag. The reported rights must now be 0x03 (read/write).
4. Write a test value (for example 42.0 to a floating-point tag) using Write or WriteVQT. The client must return S_OK (hex 0x00000000).
5. Read the same tag back to confirm the new value is in the HMI runtime.
6. Cross-check by triggering an HMI screen that displays the tag and verifying the value updates visually.
7. Repeat with a string tag, a boolean tag, and a tag with configured engineering-range bounds to confirm the server applies type validation and range checks in addition to the access-right check.

Diagnostic Verification (COM and Event Log)

• Open Event Viewer → Windows Logs → System. Confirm no DCOM errors with Event ID 10016 are logged against the OPC server AppID during the write.
• Open Event Viewer → Applications and Services Logs → Siemens Automation → HMI Runtime. Confirm OPC server start events with no follow-up fault entries.
• Run the OPC server under Sysinternals Process Monitor and filter on sopcdacmnsrv.dll to confirm the DLL is loaded from the replacement path and that write operations produce expected registry reads of the access-right property without returning the V16 hard-coded read-only value.
• Capture a network trace with Wireshark filtered on the DCOM endpoint (port 135 plus the ephemeral port allocated to OpcEnum) to confirm the IOPCItemProperties::GetItemProperties response carries the 0x03 access mask.

OPC-DA vs OPC-UA Trade-Offs in WinCC RT Advanced

For new deployments on platforms where OPC-UA is available, evaluate whether OPC-DA is required at all:

If the downstream system already exposes only OPC-DA, the DLL replacement is the correct fix. If both endpoints support OPC-UA, migrating the link to OPC-UA eliminates the V16-specific defect as a failure mode entirely and removes the DCOM configuration burden, including the requirement for the OPC XML Gateway component and the dynamic RPC port range.

Long-Term Resolution Path

The DLL replacement is a workaround, not a permanent fix. The proper resolution path is one of:

1. Apply TIA Update that includes the corrected sopcdacmnsrv.dll. After every TIA Update installation, repeat the verification procedure. If the file reverts to the V16 baseline behavior, repeat the DLL replacement and reopen the change record.
2. Upgrade to TIA V17 or later. The defect is no longer present in current WinCC RT Advanced versions. Plan a project migration that includes retesting all OPC-DA paths because the COM ProgIDs, tag-database schema, and runtime logging locations can change between major versions.
3. Migrate the integration to OPC-UA. For sites already running WinCC RT Advanced V17 or later, OPC-UA provides a non-DCOM path with a single firewall rule and no exposure to sopcdacmnsrv.dll. Migrate the downstream SCADA client to OPC-UA in a staged rollout with parallel OPC-DA validation before decommissioning the legacy path.

Security Hardening Notes

The "Everyone" and "ANONYMOUS LOGON" DCOM grants listed in Step 2 are appropriate for single-machine integration but must be tightened for production networks. Apply the following hardening in addition to the OPC-DA fix:

• Replace the "Everyone" grant with the specific COM security principals used by the OPC client. For domain-joined systems, use the client service account's NTLM\<account> identifier. For workgroup systems, use the local account with a matching SID on both ends.
• Replace "ANONYMOUS LOGON" with the local SYSTEM identity for the OPC server's launch account and remove the anonymous grant entirely from access permissions.
• Constrain the firewall rules in Step 3 to the source IP address or subnet of the OPC client. The dynamic RPC port range can be narrowed with netsh int ipv4 set dynamicport tcp start=49152 num=16384 to reduce the open-port surface.
• On the runtime PC, set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction and MachineLaunchRestriction to a security descriptor that lists only the required COM identities. This restricts who can launch any DCOM server, not just the OPC server.

FAQ