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

1. 装完 WinCC 就连不上：OPC 服务器配置到底卡在哪

WinCC 装完，画面能跑，变量能归档，结果一接第三方 OPC 客户机就哑火——这是工控现场最典型的“装完不等于跑通”。问题多半不在 WinCC 本身，而在 DCOM 这一层：WinCC OPC 服务器和客户机之间的数据交换全靠 DCOM 承载，安装程序给的默认权限只够本机管理员自己用。一旦客户机换了账号、登录用户不是管理员，或者服务器和客户机不在同一台机器上，默认配置立刻翻车。这份《WinCC-OPC服务器配置详细方法》文档讲的就是这件事：什么情况下必须改 DCOM、在 Windows 2000/XP 上怎么一步步改、每个权限项该放谁进去。适合刚接手 WinCC 项目、被 OPC 连接折腾过的自动化工程师，也适合需要把老系统迁移到新机器时重新配一遍环境的运维。

2. 装前把环境列清：WinCC 版本、系统与账号三件事

2.1 先确认 WinCC 与操作系统的对应关系

这份文档的原始场景是 Windows 2000 和 Windows XP 时代的 WinCC，DCOM 配置界面和权限项名称都按那个年代的“分布式 COM 配置属性”对话框来写。放到今天的环境里，第一步不是急着敲dcomcnfg.exe，而是先确认三件事对得上：WinCC 版本、操作系统位数、以及 OPC 服务器组件是否随 WinCC 一起装全。

WinCC 的 OPC 服务器不是一个独立安装包，它随 WinCC 安装时注册进系统，注册名分三种：基础数据访问是OPCServer.WinCC，历史数据访问是OPCHDAServers.WinCC，报警与事件是OPCServerAE.WinCC。文档里明确写了这三个条目名，配置时选错条目是最常见的低级错误——客户机要读实时变量，你却在 A&E 条目上改权限，改完照样连不上。

我一般会先让现场确认 WinCC 的完整安装路径和版本号，再看系统里是否已经注册了对应的 OPC 服务器。注册信息可以在注册表里核对，路径是HKEY_CLASSES_ROOT下找OPCServer.WinCC这个 ProgID。如果这里根本没有条目，说明 WinCC 的 OPC 组件没装或注册失败，后面所有 DCOM 配置都是白做。

提示：文档针对的是 Windows 2000/XP 的 DCOM 配置界面。在较新的 Windows 系统上，dcomcnfg.exe打开的是“组件服务”管理单元，界面层级不同，但“应用程序 → 属性 → 安全”这条路径的逻辑是一致的，权限项名称也基本沿用。

2.2 账号规划：客户机和服务器要互相认得对方

文档在“先决条件”里写得很直白：在 OPC 客户机计算机的用户管理器中，创建 WinCC OPC 服务器用于运行的用户账号；反过来，在 OPC 服务器计算机上建立客户机的用户账号。这句话翻译成现场操作就是——两台机器上的本地账号要能对得上，或者干脆用同一套域账号。

为什么必须这样？DCOM 在建立连接时会做身份验证，客户机进程以某个账号身份发起调用，服务器端要能识别这个身份并映射到本地的一个账号上。如果服务器上根本没有这个账号，验证直接失败，表现就是客户机报“拒绝访问”或“服务器没有注册”。文档里提到的两种必须改设置的情况——登录用户没有管理员权限、服务器和客户机用不同账号登录——本质上都是账号映射没打通。

常见做法是：如果现场有域环境，客户机和服务器都加入域，用同一个域账号跑 OPC 客户端和 WinCC 服务；如果没有域，就在两台机器上各建一个用户名和密码完全相同的本地账号，并且都设成管理员组。密码必须一致，这一点文档没展开，但实际配置里密码不一致导致的失败比权限项漏配还多。

2.3 网络与防火墙的前置检查

DCOM 不是单端口通信，它先通过 135 端口找服务，再动态协商一个高位端口传数据。Windows XP 自带的防火墙默认会拦这些动态端口，Windows 2000 时代防火墙问题少一些，但现场如果装了第三方安全软件，一样会拦。

配置前我一般会先做两件事：一是确认两台机器能互相 ping 通、能访问对方的共享目录，证明基础网络和账号验证没问题；二是临时关掉防火墙做一次连通性测试，确认 OPC 能通之后再按需放行端口。文档没有涉及防火墙内容，但这是现代环境里绕不开的一步，尤其是把老 WinCC 系统迁到新机器上时，防火墙策略往往比 DCOM 权限更先卡住人。

3. 改 DCOM 权限：从 dcomcnfg 到五个权限项逐个落地

3.1 打开 DCOM 配置工具并定位正确的 OPC 服务器条目

文档给出的第一步是：从开始菜单选“运行”，输入dcomcnfg.exe，打开“分布式 COM 配置属性”对话框。这个命令在 Windows 2000/XP 上直接可用，不需要额外安装。打开后切到“应用程序”选项卡，在列表里找OPCServer.WinCC。

这里有个容易忽略的细节：列表里可能同时存在多个 WinCC 相关条目，除了OPCServer.WinCC，还有OPCHDAServers.WinCC和OPCServerAE.WinCC。文档明确要求按实际使用的服务选对应条目——只做实时数据交换就选第一个，要用历史数据就选 HDA 那个，要订阅报警事件就选 A&E 那个。选错条目的后果是权限改在了不相关的组件上，客户机连的还是原来那个没权限的服务器。

选中条目后点“属性”，弹出的是该 OPC 服务器的属性对话框。接下来的所有权限设置都在这个对话框的“安全”选项卡里完成。我习惯在这一步先把属性对话框截图存档，后面排查时能对照确认到底改没改、改的是哪个条目。

3.2 访问权限：把五个身份放进去

文档第 3 步到第 4 步讲的是访问权限。在“安全”选项卡下选“使用自定义访问权限”，点“编辑”，弹出“注册表数值权限”对话框，然后通过“允许访问”添加五个用户：管理员、交互式、所有人、网络、系统。

这五个身份各自管什么，文档没细说，但配置时心里要有数：

“网络”这一项是关键，客户机从另一台机器连过来，走的就是网络身份。漏掉它，本机测试一切正常，一跨机器就报拒绝访问。“所有人”则是文档所说的“没有考虑安全性需求”的完整授权做法，它把权限放到了最宽，适合内网隔离环境下的调试和上线初期。如果现场有安全审计要求，就不能照搬“所有人”，而要精确到具体账号，这一点文档自己也提醒了：这些设置允许通过 OPC 进行连接，但没有考虑安全性需求，建议由网络管理员完成。

3.3 启动权限：只放“所有人”和“网络”

文档第 5 步到第 6 步是启动权限：在“安全性”选项卡下选“使用自定义启动权限”，点“编辑”，在“注册表数值权限”对话框里通过“允许启动”添加“所有人”和“网络”。

启动权限和访问权限是两回事。访问权限管的是“连上来之后能不能读写”，启动权限管的是“能不能把 OPC 服务器进程拉起来”。客户机第一次连接时，如果服务器进程还没运行，DCOM 会尝试以客户机身份启动它，这时候启动权限不够，报的错通常是“服务器没有注册”或“RPC 服务器不可用”，很容易被误判成网络问题。

注意这里只加了“所有人”和“网络”，没有加“系统”和“交互式”。文档的写法是有意为之：启动动作只需要覆盖远程和本地普通用户，系统进程本身不需要额外授权。照抄的时候不要自作主张把五个身份全加到启动权限里，权限放得越宽，后面出问题越难定位。

3.4 身份与常规设置：确认“交互式用户”还是“指定用户”

文档在权限步骤之后以“单击确定关闭所有打开的对话框”收尾，没有展开“标识”选项卡。但实际配置里，这个选项卡经常是最后一根稻草。OPC 服务器属性对话框里有一个“标识”页，决定这个 DCOM 应用以什么身份运行，常见选项是“交互式用户”和“下列用户”。

如果 WinCC 是以某个固定账号登录运行的，这里选“交互式用户”意味着 DCOM 启动的服务器进程跟随当前登录会话；如果服务器是无人值守运行，通常要选“下列用户”并填入专门的服务账号。文档的权限配置默认了“交互式”这个身份在访问权限列表里，说明它的场景是有人登录的工控机。现场如果是开机自动运行、没人登录的状态，就要把“标识”改成指定用户，并确保这个用户在访问和启动权限里都有。

改完所有对话框后逐层点“确定”关闭。文档最后一句是“OPC 服务器设置完毕”，但真正的验证在下一章——配置完不验证，等于没配。

4. 避坑与排查：五条现场翻车记录

4.1 本机通、跨机器不通

现象：在 WinCC 服务器本机用 OPC 客户端测试，变量读写正常；换到另一台客户机，连接直接失败，报“拒绝访问”或“0x80070005”。

原因：访问权限里漏了“网络”身份，或者客户机登录账号在服务器上没有对应账号。本机测试走的是本地会话，不经过网络身份验证，所以看不出问题。

解决：回到dcomcnfg.exe，确认OPCServer.WinCC的访问权限里“网络”在列；同时在服务器上补建客户机使用的账号，密码保持一致。两步都做完再测。

4.2 改了权限但重启后失效

现象：配置完当场能连，机器重启或 WinCC 重启后，客户机又连不上了。

原因：DCOM 权限改的是注册表里的组件配置，正常情况下重启不会丢。真正丢的是“标识”设置和账号状态——如果服务器用的是“下列用户”指定账号，而这个账号密码过期或被改过，DCOM 启动就会失败。另一种情况是改权限时没点到最后一级“确定”，中间某层对话框被取消，配置没落盘。

解决：改完权限后重新打开属性对话框逐项核对，确认“使用自定义访问权限”和“使用自定义启动权限”两个单选都处于选中状态；指定账号的场景下检查账号密码有效期。

4.3 选错 OPC 服务器条目

现象：客户机要读实时变量，连OPCServer.WinCC失败，但换成 HDA 条目又能连上，或者反过来。

原因：配置时在“应用程序”列表里选错了条目，权限改在了OPCHDAServers.WinCC或OPCServerAE.WinCC上，客户机实际访问的那个条目还是默认权限。

解决：先确认客户机用的 ProgID 是哪一个，再回到列表里对号入座。三个条目要分别配，不能只配一个就以为全覆盖。

4.4 防火墙拦掉动态端口

现象：ping 得通、共享能访问，OPC 连接就是超时，抓包看到 135 端口有响应，后续数据端口没动静。

原因：DCOM 协商出的动态端口被防火墙拦截。Windows XP 自带防火墙和第三方安全软件都会这么干。

解决：临时关闭防火墙验证，确认是端口问题后，按 DCOM 的端口范围放行，或者把 OPC 服务器和客户机放在同一安全区域。文档年代没有这个问题，现代环境必须补上这一步。

4.5 权限放太宽导致审计不过

现象：按文档把“所有人”加进访问和启动权限，功能是通了，但安全审计要求逐账号授权，配置被退回。

原因：文档明确说了这套设置“没有考虑安全性需求”，它是连通性优先的完整授权版本。

解决：在连通性验证通过后，把“所有人”替换成具体的客户机账号和服务器运行账号，逐个测试。先通再收，比一上来就精确授权更容易定位问题。

5. 装完怎么验证：三步确认 OPC 真的跑通了

配置改完，别急着交付。我习惯按三步走一遍，每一步都能独立证明一层是通的。

第一步，服务器本机自测。在 WinCC 服务器上打开一个 OPC 客户端工具，连OPCServer.WinCC，浏览变量树，读一个实时变量。这一步验证的是 OPC 服务器本身注册正常、WinCC 变量能对外暴露。如果这一步就失败，问题在 WinCC 侧，不用去查 DCOM。

第二步，跨机器连接测试。在客户机上用同一个客户端工具连服务器，重点看两件事：能不能枚举出服务器列表，能不能读到变量值。枚举失败通常是 DCOM 启动权限或网络发现问题；能枚举但读值失败，多半是访问权限或账号映射问题。这一步是文档配置的核心验证点，也是“本机通、跨机不通”这类坑的照妖镜。

第三步，换账号复测。用客户机上实际运行 OPC 客户端的那个账号登录，再连一次。很多现场是用管理员账号配的、用普通账号跑的，配置时一切正常，上线后换账号就翻车。这一步能提前把账号映射问题暴露出来。

三步都过，再回头把临时放开的防火墙和“所有人”权限收一收，按现场安全要求做精确授权，收完再快速复测一次连接。这套流程走下来，DCOM 配置才算真正落地。

从那以后我每次配 WinCC OPC，不管文档写得多清楚，都强制按“本机自测 → 跨机测试 → 换账号复测”走一遍，宁可多花二十分钟，也不在交付后被一个“连不上”的电话叫回现场。希望帮到你。

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