简介：这份文档面向使用西门子 SIMATIC WinCC 的工控工程师与自动化技术人员，聚焦 WinCC OPC 服务器与 OPC 客户机之间基于 DCOM 的数据交换配置问题，尤其针对登录用户无管理员权限、服务器与客户机使用不同账号登录等需要手动调整 DCOM 的场景。资源包共 1 个 doc 文件，约 29KB，篇幅精简，属于可直接查阅的操作型技术文档。内容围绕 OPC 操作基础与 DCOM 设置修改展开，涵盖用户账号的双向创建、dcomcnfg.exe 的调用、OPCServer.WinCC 及 HDA、A&E 服务器条目的选择，以及自定义访问权限与启动权限的逐项添加，并附有安全性与网络技术基础的注意事项。已有 2620 人学习，适合需要快速排查 OPC 连接失败、理清权限配置思路的读者对照参考。

1. 一份 2007 年的 WinCC OPC 配置文档，为什么今天还有人翻出来用

产线上跑着 WinCC 的老项目，上位机要跟第三方组态软件、MES 采集端或者一台自研的 OPC 客户端对接，结果客户端一连接就报0x80070005拒绝访问——这种场景在工控现场一点都不新鲜。翻遍论坛，最后指向的往往就是一份流传了十几年的老文档：WinCC OPC 服务器配置详细方法。它讲的核心不是 WinCC 组态本身，而是 OPC 通信底层依赖的 DCOM 配置，尤其是当客户端和服务器不在同一台机器、或者两边登录账号不一致时，怎么把 DCOM 的访问权限和启动权限放开。这份资料适合两类人：一是手上维护着 WinCC 老版本、需要打通 OPC DA 通道的现场工程师；二是刚开始接触工控通信、被 DCOM 权限绕晕的新手。它不厚，但把最容易翻车的那几个配置项说清楚了，照着做能少走不少弯路。

2. DCOM 权限模型：OPC 连不上，八成卡在这三层

2.1 OPC DA 为什么绕不开 DCOM

OPC DA（Data Access）规范诞生在 COM/DCOM 时代，它的进程间通信完全建立在微软的组件对象模型之上。WinCC 作为 OPC 服务器时，会向系统注册一个名为OPCServer.WinCC的 COM 组件，客户端通过 DCOM 远程激活这个组件、拿到接口指针，然后才能读写标签。这意味着通信能不能建立，不取决于 WinCC 项目配得对不对，而取决于 Windows 的 DCOM 安全机制放不放行。

DCOM 的权限校验分三层，任何一层没过都会导致连接失败。第一层是访问权限，决定谁可以调用这个组件的方法；第二层是启动权限，决定谁可以把这个组件进程拉起来；第三层是身份标识，决定组件以哪个账号的身份运行。老文档里反复强调的“添加管理员、交互式、所有人、网络、系统”，就是在配第一层和第二层。很多人只改了访问权限忘了启动权限，结果客户端能枚举到服务器但一连接就超时，这就是典型的只过了第一层没过第二层。

还有一个容易被忽略的点：DCOM 的配置是分机器、分组件、分账号的。服务器端要放行客户端的账号，客户端也要放行服务器的账号，双向都要配。老文档里那句“在 OPC 客户机计算机的用户管理器中创建服务器运行账号，反过来在服务器上建立客户机账号”，说的就是这个双向信任关系。只配一边，通信照样不通。

2.2 三种 OPC 服务器条目别选错

WinCC 安装后会注册多个 OPC 相关组件，不同组件对应不同的数据访问规范，选错了条目配了也白配。老文档里明确列了三个：

现场对接九成以上用的是 DA，所以重点配OPCServer.WinCC。但如果你接的是历史数据查询或者报警采集，就得去配对应的条目，配错了现象是客户端能连上但读不到数据，比连不上还难排查。我一般会先在客户端用 OPC 客户端工具枚举一下服务器列表，确认目标条目确实出现在列表里，再去动 DCOM 配置，避免对着一个根本没注册的组件瞎调。

2.3 用 dcomcnfg 逐项配访问与启动权限

老文档给的是 Windows 2000/XP 的操作路径，界面叫“分布式 COM 配置属性”。在 Windows 7 及以上系统里，这个工具还在，但入口变成了组件服务（comexp.msc），底层配置项是一致的。下面按现代系统的路径把关键步骤走一遍，逻辑和老文档完全对应。

先确认组件已注册。在服务器上打开注册表，定位到HKEY_CLASSES_ROOT\OPCServer.WinCC，能看到 CLSID 子键就说明组件在。然后打开组件服务：

# 方式一：直接运行 dcomcnfg，老系统和新系统都能拉起组件服务 dcomcnfg.exe # 方式二：运行 mmc 加载组件服务管理单元 comexp.msc -32

这里有个坑：WinCC 的 OPC 组件多数是 32 位的，在 64 位系统上必须用comexp.msc -32打开 32 位组件服务，否则在“DCOM 配置”节点下根本看不到OPCServer.WinCC。我第一次在 64 位系统上配的时候就是这个问题，翻了半天以为组件没注册，其实是看错了节点。

打开后依次展开“组件服务 → 计算机 → 我的电脑 → DCOM 配置”，在列表里找到OPCServer.WinCC，右键属性。在“安全”选项卡里，把“启动和激活权限”和“访问权限”都选为“自定义”，然后点编辑。启动权限里添加Everyone和NETWORK，给“本地启动”和“远程启动”允许；访问权限里添加ANONYMOUS LOGON、Everyone、NETWORK、SYSTEM，给“本地访问”和“远程访问”允许。老文档里写的“所有人”“网络”“系统”就是这几个内置组，只是中文系统翻译不同。

配完安全选项卡，还要去“标识”选项卡确认运行身份。默认是“启动用户”，如果服务器和客户端账号不一致，建议改成“此用户”并指定一个两边都存在的本地账号，密码保持一致。这一步是很多“配了权限还是连不上”的根因——组件以启动者身份运行，而启动者账号在客户端那台机器上不存在，DCOM 校验直接失败。

最后在“常规”选项卡确认身份验证级别为“无”或“连接时”，默认的“数据包完整性”在某些老客户端上会协商失败。改完这些，重启一次服务器上的 WinCC 运行系统和 DCOM 服务（net stop DcomLaunch && net start DcomLaunch，或者直接重启机器更稳妥），让配置生效。

3. 跨机器对接：账号、防火墙与本地安全策略的联动

3.1 双向账号必须同名同密

DCOM 的远程激活依赖 Windows 的账号认证，服务器和客户端之间不存在“匿名信任”这回事。老文档开篇就点明两种必须改配置的情况：客户端或服务器登录用户没有管理员权限，以及两边用不同账号登录。实操中最稳的做法是在两台机器上各建一个同名同密的本地账号，比如都叫opcuser，密码完全一致，然后把这个账号同时加入两边的“管理员”组和“分布式 COM 用户”组。

为什么强调同名同密？因为 DCOM 在远程激活时，服务器会用客户端提供的凭据去本地 SAM 里比对，账号名或密码任何一边对不上，激活就返回拒绝访问。有人图省事在客户端用当前登录账号、服务器用另一个账号，然后在 DCOM 标识里指定“交互式用户”，这种配法在单机测试能通，一到跨机器就翻车，血泪经验就是别在这种地方省步骤。

账号建好后，还要确认两边的本地安全策略没有把网络访问卡死。运行secpol.msc，在“本地策略 → 用户权利分配”里检查“从网络访问此计算机”是否包含Everyone和NETWORK，以及“拒绝从网络访问这台计算机”里有没有误加账号。有些加固过的系统默认把Guest和匿名访问全禁了，DCOM 的某些协商阶段会用到匿名令牌，禁得太死会导致枚举得到、连接不上。

3.2 防火墙放行 DCOM 的端口范围

DCOM 不像 HTTP 走固定端口，它先用 135 端口做 RPC 端点映射，然后动态协商一个高位端口做实际通信。只放行 135 是不够的，实际数据通道会被防火墙拦掉。现场常见的做法有两种：一是把 DCOM 的动态端口范围限制在一个固定区间，然后在防火墙上放行这个区间；二是直接在工控内网里对受信任子网放行。

限制端口范围需要改注册表。在服务器上新建一个.reg文件导入：

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet] "Ports"=hex(7):31,00,30,00,32,00,34,00,2d,00,31,00,30,00,32,00,34,00,00,00,00,00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet] "PortsInternetAvailable"="Y" "UseInternetPorts"="Y"

这段注册表把 RPC 动态端口限制在 1024 到 1024 这个单端口上（十六进制值对应字符串1024-1024），实际部署时建议改成一段区间比如5000-5100，给并发连接留余量。改完重启 RPC 服务，然后在防火墙入站规则里放行 TCP 135 和这段区间。注意这个注册表项在 64 位系统上要写到Wow6432Node下对应的路径，否则 32 位 OPC 组件读不到。

防火墙配完，用telnet 服务器IP 135从客户端测一下连通性，通了再往下走。这一步看着简单，但现场很多“DCOM 配了没用”的案例，最后查出来是防火墙把动态端口挡了，客户端在 RPC 端点映射阶段就超时，报错信息还特别含糊。

3.3 用 OPC 客户端做最小化连通验证

配置改完别急着上正式系统，先用一个轻量 OPC 客户端验证。常见的做法是用 Matrikon OPC Explorer 或者免费的 OPC Quick Client，在客户端机器上枚举远程服务器。枚举能看到OPCServer.WinCC说明 RPC 端点映射和组件注册没问题；能连上并浏览到标签树，说明访问权限和启动权限都过了；能读到实时值，才算整条链路打通。

验证时按这个顺序排查，能快速定位卡在哪一层：

1. 枚举不到服务器 -> 查 135 端口、RPC 服务、组件是否注册 2. 枚举到但连接超时 -> 查启动权限、DCOM 标识、防火墙动态端口 3. 连上但读标签报错 -> 查访问权限、WinCC 运行系统是否启动、标签名是否正确 4. 读得到但值不刷新 -> 查 WinCC 变量归档周期、OPC 服务器的更新速率设置

我一般会在服务器本地先用客户端连一次localhost，本地能通再测远程。本地都不通，说明 DCOM 配置本身有问题，跟网络无关，这时候去查防火墙就是浪费时间。本地通了远程不通，才把排查重心放到账号、防火墙和网络策略上。

4. 避坑排查：五条现场踩出来的记录

4.1 现象：客户端报 0x80070005 拒绝访问

原因：这是 DCOM 权限不足最典型的报错，多数情况是只配了访问权限没配启动权限，或者组件标识指定的账号在客户端不存在。也有一种情况是服务器上的“分布式 COM 用户”组没有包含客户端账号，导致远程激活被拒。

解决：回到组件服务，把OPCServer.WinCC的启动和激活权限、访问权限都改成自定义并显式添加Everyone、NETWORK、ANONYMOUS LOGON；标识选项卡改成“此用户”并指定两边同名的账号；确认该账号在“分布式 COM 用户”组里。改完重启 DCOM 服务再测。

4.2 现象：64 位系统上 DCOM 配置列表里找不到 OPCServer.WinCC

原因：WinCC 的 OPC 组件是 32 位的，在 64 位系统上默认打开的组件服务管理单元是 64 位视图，看不到 32 位组件的注册信息。

解决：用comexp.msc -32打开 32 位组件服务，或者在运行对话框里执行mmc comexp.msc /32。确认能看到组件后，后续所有 DCOM 配置都在这个 32 位视图里做，别在两个视图之间来回切，容易配串。

4.3 现象：本地能连，远程枚举得到但一连接就超时

原因：RPC 端点映射（135 端口）通了，但 DCOM 协商的动态高位端口被防火墙拦截，实际数据通道建立不起来。这种情况报错往往不是拒绝访问，而是超时或“服务器不可用”。

解决：按 3.2 节的方法限制 RPC 动态端口范围并在防火墙放行，或者临时关闭防火墙做对照测试确认是端口问题。确认后把端口区间固化到部署文档里，别每次上线都重新猜。

4.4 现象：连接成功但读不到任何标签，浏览树是空的

原因：DCOM 层已经通了，问题出在 WinCC 侧。常见的是 WinCC 运行系统没启动、OPC 服务器组件没随项目激活，或者客户端连的是 HDA/A&E 条目却按 DA 的方式读数据。

解决：先在服务器上确认 WinCC 运行系统处于激活状态，变量管理里能看到实时刷新的值；再确认客户端连接的 ProgID 是OPCServer.WinCC而不是 HDA 或 A&E 条目；最后检查 WinCC 用户管理里给 OPC 访问分配的权限是否包含该账号。

4.5 现象：跑一段时间后突然断连，重启客户端又恢复

原因：DCOM 的连接有超时和回收机制，长时间空闲或网络抖动后连接被回收；也可能是服务器上账号密码策略变更导致凭据失效。老系统上还常见于 RPC 动态端口被其他服务占用后重新分配，客户端缓存的端点信息过期。

解决：在客户端侧加心跳读取，定期读一个固定标签保持连接活跃；检查服务器账号密码是否设置了过期策略，工控账号一般设为密码永不过期；如果频繁断连，考虑把 DCOM 端口范围固定下来减少端口漂移。这类问题没有一劳永逸的配置，只能靠监控和心跳兜底。

5. 把配置固化成可复现的检查清单

老文档只有三页，讲的是 Windows 2000/XP 时代的操作路径，但 DCOM 的权限模型十几年没变过，今天在 Windows 7、Windows 10 甚至部分 Server 版本上照样适用，变的只是入口界面和 32/64 位视图的区分。真正让这份资料有价值的，不是它列了多少步骤，而是它点明了“什么时候必须改 DCOM 设置”这个判断条件——账号不一致、权限不足，这两个触发条件至今仍是 OPC 连不上的主因。

我在多个现场落地后，习惯把配置过程整理成一张检查表，每次新环境部署照着过一遍，比凭记忆点鼠标靠谱得多：

这张表里最容易被跳过的是“本地先连 localhost”这一步。很多人一上来就从客户端远程测，失败了分不清是 DCOM 问题还是网络问题，来回折腾。先把本地回路打通，等于把变量隔离掉一半，剩下的问题范围就小多了。

还有一个习惯值得养成：每次改完 DCOM 配置，导出一次组件服务的配置备份，或者至少把改动的注册表项和权限项记到部署文档里。工控现场的系统往往一跑好几年，中间换人维护是常态，没有配置记录，下次出问题又得从头摸一遍。从那以后我每次配完 OPC 通道，都会把账号、端口区间、DCOM 权限项和验证结果写进一页纸的交接说明里，强制走一遍本地到远程的验证流程，再交给现场。希望帮到你。

本文还有配套的精品资源，点击获取