WinCC OPC服务器DCOM配置详解：从权限模型到避坑排查

简介：这份文档面向使用西门子 SIMATIC WinCC 的工控工程师与自动化技术人员，聚焦 WinCC OPC 服务器与 OPC 客户机之间基于 DCOM 的数据交换配置问题，尤其针对登录用户无管理员权限、服务器与客户机使用不同账号登录等需要手动调整 DCOM 设置的场景。资源包共 1 个 doc 文件，约 29KB，内容围绕 OPC 操作基础与 DCOM 设置修改展开，涵盖 Windows 2000 环境下创建对应用户账号、运行 dcomcnfg.exe、定位 OPCServer.WinCC 及 HDA、A&E 服务器条目、设置自定义访问与启动权限等完整流程，并附有安全性说明与参考文档提示。已有 2620 人学习，适合需要排查 OPC 连接失败、理清 DCOM 权限配置思路的读者对照查阅，可作为现场调试与权限配置的参考手册。

1. 一份 2007 年的 DCOM 配置笔记，为什么今天还有人翻出来用

产线上跑着 WinCC 的机器，突然要接一台第三方上位机或者数据采集网关，对方一句“你那边 OPC 服务器开一下”，很多人第一反应是去翻 WinCC 的通讯手册，结果翻半天发现卡住的根本不是 WinCC，而是 Windows 的 DCOM。这份《WinCC-OPC 服务器配置详细方法》就是干这个的：它不讲 OPC 协议原理，也不讲变量怎么建，只把dcomcnfg.exe里那几个安全选项卡该点哪里、加哪几个账户、勾“允许访问”还是“允许启动”写成了可照抄的步骤。适合谁？适合手上有一台装着 WinCC 的工控机、需要让另一台机器上的 OPC 客户端连上来、但连接一直报“拒绝访问”或“服务器没有注册”的现场工程师。它老，老到原文还在讲 Windows 2000 和 XP，但 DCOM 这套权限模型在后续的 Windows 版本里骨架没变，所以这份文档的价值不在版本号，而在它把“账户—权限—启动”这条链路拆得足够细。

2. 先把 DCOM 权限模型吃透：为什么装完 WinCC 能连、换个账户就连不上

2.1 OPC 走的是 DCOM，不是 TCP 直连

WinCC OPC 服务器对外暴露的接口，客户端不是直接拿 IP 加端口去连的，而是通过 DCOM 的组件激活机制找到服务器进程。这意味着连接能不能建立，取决于三件事同时成立：客户端账户在服务器机器上有对应的登录身份、这个身份对OPCServer.WinCC这个组件有“访问”权限、并且有“启动”权限。原文里那句“安装 WinCC 后 DCOM 设置正确”，前提是客户端和服务器用同一个管理员账户登录，或者都在同一个域里且账户能互相识别。一旦现场是两台独立的工作组机器、各自用本地账户登录，这套默认设置立刻失效，因为服务器机器根本不认识客户端那个账户是谁。

我一般会把这条链路理解成三道门：第一道是账户映射，客户端拿什么身份来；第二道是访问权限，这个身份能不能读组件；第三道是启动权限，这个身份能不能把服务器进程拉起来。原文的步骤顺序其实暗合这个逻辑——先建账户，再配访问，最后配启动。很多人翻车是因为只配了访问没配启动，现象是客户端能看到 OPC 服务器列表、能浏览变量，但一读数据就超时，因为进程压根没被拉起来。

2.2 原文那套“加所有人”的做法，边界在哪

原文在访问权限里让加“管理员、交互式、所有人、网络、系统”，启动权限里加“所有人、网络”。这是典型的“先连通再收紧”思路，原文自己也写了“没有考虑安全性需求”。放在隔离的生产网段里，这套配置能最快让连接通起来，适合调试阶段。但如果这台 WinCC 机器同时连着办公网，把“所有人”和“网络”都放进来，等于把 OPC 接口对整张网敞开，任何能解析到这台机器的客户端都能尝试激活组件。我的做法是调试期照原文配通，通了之后立刻把“所有人”删掉，只保留具体的客户端账户和NETWORK SERVICE（如果本机有服务需要访问），然后重新用客户端验证一遍。这一步不做，后面做等保或者网络扫描的时候，DCOM 端口和组件权限就是现成的扣分项。

2.3 账户怎么建才不白建

原文说“在 OPC 客户机计算机的用户管理器中，创建 WinCC OPC 服务器用于运行的用户账号。反过来，在 OPC 服务器计算机上建立客户机的用户账号”。这句话容易被读成“两边各建一个”，实际要的是两边账户名和密码完全一致。工作组环境下没有域控帮你做身份映射，DCOM 只能靠“同名同密码”来认人。所以正确做法是：在服务器和客户端上各建一个同名账户，比如都叫opcuser，密码设成一样，然后把客户端那边的 OPC 客户端程序改成用这个账户启动，服务器这边的 DCOM 权限里也把这个账户加进去。密码不一致是最隐蔽的坑，因为 DCOM 报错往往只给一个笼统的“拒绝访问”，不会告诉你“密码对不上”。

# 在服务器和客户端分别执行，确认账户存在且名称一致 net user opcuser # 输出里重点看“用户名”和“帐户启用”两行，两边必须完全对应

这段命令不是配置，是排查用的。现场接手一台别人配过的机器，先跑一遍确认账户名有没有拼写差异，比如一边是opcuser、一边是opc_user，肉眼扫过去差不多，DCOM 认起来就是两个人。参数上没什么可调的，net user后面跟账户名即可，不带参数会列出本机所有账户，适合快速比对。

3. 照着 dcomcnfg 走一遍：从组件定位到权限落盘

3.1 组件名别选错：OPCServer、OPCHDAServers、OPCServerAE 是三套

原文特意提醒，普通 OPC 数据访问服务器对应OPCServer.WinCC，历史数据访问对应OPCHDAServers.WinCC，报警和事件对应OPCServerAE.WinCC。这个提醒很关键，因为dcomcnfg的应用程序列表里这几个条目长得像，选错了配半天，客户端连的还是没配的那个组件。现场判断方法很简单：客户端要读实时变量就配第一个，要读历史趋势才配第二个，要订阅报警才配第三个。多数数据采集场景只涉及第一个，但有些 MES 对接会同时要实时值和历史值，那就得两个都配，权限设置重复一遍。

操作路径（以常见 Windows 版本为例，原文为 2000/XP，后续版本入口名称略有差异）： 开始菜单 → 运行 → 输入 dcomcnfg.exe → 回车 组件服务窗口 → 计算机 → 我的电脑 → DCOM 配置 在列表中找到 OPCServer.WinCC → 右键 → 属性

这里用文本块而不是代码块，因为它是界面操作路径，不是可执行脚本。dcomcnfg.exe这个命令本身在后续 Windows 里仍然可用，只是弹出的窗口从“分布式 COM 配置属性”变成了“组件服务”管理单元，原文描述的选项卡名称基本能对上，个别按钮文字有出入，按语义找即可。

3.2 访问权限和启动权限要分开配，别一把梭

原文第 3 步到第 6 步是核心：安全选项卡里先勾“使用自定义访问权限”，编辑里加账户并勾“允许访问”；再勾“使用自定义启动权限”，编辑里加账户并勾“允许启动”。这两组权限在界面上挨着，但作用完全不同。访问权限管的是“能不能跟这个组件对话”，启动权限管的是“能不能把这个组件的进程拉起来”。只配访问不配启动，客户端能枚举服务器但读不到数据；只配启动不配访问，客户端连枚举都过不去。我见过有人图省事只在启动权限里加了账户，然后抱怨“OPC 客户端能看到服务器名字但连不上”，就是漏了访问那一组。

访问权限添加项（调试期，按原文）： 管理员、交互式、所有人、网络、系统 → 均勾选“允许访问” 启动权限添加项（调试期，按原文）： 所有人、网络 → 均勾选“允许启动” 收紧后建议保留： 访问权限：具体客户端账户、SYSTEM、NETWORK SERVICE 启动权限：具体客户端账户、SYSTEM

表格里“收紧后建议保留”这一列是我自己补的，原文没有，因为原文明确说不考虑安全性。SYSTEM和NETWORK SERVICE保留是因为 WinCC 自身有些服务以这两个身份运行，全删了可能导致本机组件激活也出问题。具体客户端账户就是 2.3 里建的那个同名账户。

3.3 配完必须重启相关服务，别指望立即生效

DCOM 权限改完，很多人直接拿客户端去连，连不上就以为配错了。实际上权限变更对已经缓存的组件激活不一定立即生效，稳妥做法是重启一下 WinCC 相关的服务，或者干脆重启机器。现场不方便重启整机的话，至少把 WinCC 的 OPC 服务停掉再起。

# 查看与 WinCC OPC 相关的服务，服务名因版本而异，按显示名称过滤 sc query state= all | findstr /i "wincc opc" # 找到后重启，例如服务名为 WinCCOPCService 时： net stop WinCCOPCService && net start WinCCOPCService

sc query state= all会列出所有服务，findstr做名称过滤，这样不用去服务管理器里一个个翻。net stop和net start用&&串起来，停成功才起，避免停一半失败还硬起。服务名一定要以本机实际显示为准，不同 WinCC 版本命名不一样，别照抄我示例里的名字。

4. 避坑与排查：连接报错时先看这五处

4.1 现象：客户端报“拒绝访问”，服务器事件日志无记录

原因通常是账户映射没对上，客户端用来启动 OPC 客户端的账户在服务器上不存在，或者存在但密码不同。DCOM 在身份验证阶段就失败了，根本没走到组件激活，所以服务器端日志干净得很。解决：两边net user比对账户名，用runas以目标账户启动客户端程序验证。

4.2 现象：能枚举服务器、能浏览变量，读数据超时

这是典型的只配了访问权限、没配启动权限。客户端能跟组件对话拿到变量列表，但真正读值时需要服务器进程处于运行状态，启动权限不够就拉不起来。解决：回到dcomcnfg的启动权限里补上客户端账户，勾“允许启动”，重启服务再试。

4.3 现象：本机客户端能连，另一台机器连不上

先确认两台机器能不能互相解析主机名，DCOM 对名称解析的依赖比想象中强。工作组环境下建议在hosts文件里把对方的主机名和 IP 写死，避免 NetBIOS 解析时好时坏。解决：两边hosts各加一行对方记录，再用ping 主机名确认解析到的是预期 IP。

4.4 现象：配完当时能用，过几天又连不上

多半是账户密码过期或者被改了策略。工作组环境下同名账户的密码一旦不同步，DCOM 立刻失效。解决：把opcuser这类服务账户的密码设成“永不过期”，并在变更密码时两边同步改。这个坑很阴，因为改密码的人往往不知道还有另一台机器依赖这个账户。

4.5 现象：防火墙开着就全断，关了就好

DCOM 不是单一端口，动态端口范围让防火墙规则很难写死。原文年代防火墙压力小，现在不行。解决：不要图省事关防火墙，而是在服务器上为 DCOM 配置固定的端口范围（通过组件服务的计算机属性里设置“在此计算机上限制 TCP/IP 端口范围”），然后只放行这个范围和 135 端口。这一步原文没写，但今天做现场实施绕不开。

5. 把这份老文档用出新价值：权限收紧与连通性验证的固定套路

原文给的是“配通”路径，实际交付要的是“配通且可复现”。我现在的习惯是：照原文配通之后，立刻做一轮收紧，然后写一个最小验证脚本，把“账户对不对、权限够不够、端口通不通”三件事一次性验完，避免下次换人接手又从头猜。

收紧的顺序是反着来的：先把访问和启动权限里的“所有人”“网络”删掉，只留具体账户和系统账户；再用客户端连一次，连不上就说明某个具体账户漏了，补上；连上了再把防火墙动态端口关掉、改固定范围，再连一次。每改一步验一次，出问题能立刻定位到是哪一步引入的。

验证脚本我一般用 PowerShell 写，不依赖 WinCC 自带工具，换台机器也能跑：

# 验证目标机器 135 端口和 DCOM 动态端口范围是否可达 $target = "OPC-SERVER" # 替换为服务器主机名或 IP Test-NetConnection -ComputerName $target -Port 135 # 若已配置固定端口范围，例如 5000-5020，逐个抽验 5000..5020 | ForEach-Object { $r = Test-NetConnection -ComputerName $target -Port $_ -WarningAction SilentlyContinue if ($r.TcpTestSucceeded) { "端口 $_ 可达" } }

Test-NetConnection的-Port参数指定探测端口，-WarningAction SilentlyContinue只是压掉中间过程的告警输出，不影响结果判断。135 是 DCOM 的端点映射端口，这个不通后面全免谈；固定端口范围抽验是为了确认防火墙规则真的生效，而不是只配了没应用。这套脚本跑完，再拿 OPC 客户端做一次实际读写，两层验证都过，才算交付完成。

从那以后我每次碰 DCOM 配置，都强制先跑一遍账户比对和端口探测，再动dcomcnfg，因为血泪经验告诉我，八成“OPC 连不上”根本不是 OPC 的问题，是账户和端口这两件小事没对齐。希望帮到你。

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