无法在 Windows Server 2019 上浏览网络以查找可用的 OPC DA 服务器，但如果手动指定则可以连接到 OPC DA 服务器
当所有其他 OPC 通信似乎正常运行并且文件共享浏览似乎也正常运行时，是否有人在 Windows Server 2019 上看到过任何内容会阻止在 Active Directory 域环境中浏览网络以查找远程主机上可用的 OPC 服务器？
我在这里缺少一些东西，但我找不到它。由于核心 OPC 功能正在运行，因此 OPC Expert 等工具不会显示任何错误，并且 OSIsoft、KEPware 和 OSI Institute 的 DCOM 设置指南均无效。 DCOM 设置似乎都没有解决 CLSID 网络浏览问题。如果客户端能够提供远程主机并查询该主机，那么 OPC 服务枚举就可以正常工作。问题是我们试图使用不具备任何功能的客户端来手动定义服务器并且仅依赖于网络浏览功能。
请告诉我其他人看到过这种行为。我怀疑这是 Windows Server 2019 的某些网络安全功能，但我找不到任何文档指出可能导致此功能失败的原因。更糟糕的是，该函数正常完成，但结果为零，所以我什至没有错误消息来跟踪问题。
Has anyone seen anything on Windows Server 2019 that would prevent browsing the network in a Active Directory domain environment to find available OPC servers on remote hosts when all other OPC communications seem to be functioning normally and file share browsing seems to also be functioning?
There is something I'm missing here, but I cannot find it. Since the core OPC functions are working, tools like OPC Expert are not showing any errors and guides for DCOM settings from OSIsoft, KEPware, and OSI Institute are all being used to no avail. None of the DCOM settings seem to be addressing the CLSID network browsing. If a client has the ability to supply a remote host and query that host, the OPC services enumeration works just fine. The problem is that we are attempting to use clients that do not have any features to manually define the servers and solely relies on the network browsing functions.
Please tell me someone else has seen this behavior. I suspect that it is some network security feature of Windows Server 2019, but I can't find any documentation that points to what might be causing this function to fail. Worse, the function is completing normally, but with zero results, so I don't even have error messages to track the issue down with.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这实际上取决于您使用的应用程序。 OPC 客户端可以通过多种方式查找远程 OPC 服务器。大多数客户端将使用以下各项的组合：
OPCEnum。特别是，繁重的工作是使用 EnumClassesOfCategories 完成的，它是组件类别管理器的一部分。不通过注册表进行爬网。
获取 OPCServers()。该方法可作为名为 IOPCAutoServer 的接口的一部分使用，该接口来自 OPC 基础本身（通过 OPCDAAuto.dll）
CLSIDFromProgID() 首先获取 CLSID，然后执行 CoCreateInstanceEx()。
当 CLSIDFromProgID() 失败时，它会在建立连接之前使用 OPCEnum 列出所有 OPC 服务器。
这意味着您首先需要找出您的客户端应用程序使用什么来列出 OPC 服务器。
然后，在 Windows 安全方面，根据两个节点的操作系统版本，您可能需要禁用简单文件共享模式（Windows XP 及更早版本的情况）
如果它使用 OPCEnum，您将需要配置 DCOM对于 OPCEnum 也是如此，这是列出远程 OPC 服务器的推荐方法。
如果应用程序仅支持远程注册表查找来查找 OPC 服务器，则您需要向从客户端连接到服务器的帐户授予访问权限
It really depends on the application you are using. There are many ways for an OPC Client to find the remote OPC Server. Most clients will use a combination of the folowing:
OPCEnum. In particular the heavy lifting is done using EnumClassesOfCategories which is part of Component categories Manager. Does not crawl through registry.
GetOPCServers(). This is a method is available as part of an interface called IOPCAutoServer which comes from the OPC foundation itself (via OPCDAAuto.dll)
CLSIDFromProgID() first to get the CLSID and then does the CoCreateInstanceEx().
When CLSIDFromProgID() fails, it falls back to using OPCEnum to list all OPC servers before making a connection.
That means that you would first need to find out what your client application is using to list the OPC Servers.
Then, on the Windows Security side of things, depending on the OS version of both nodes, you may need to disable Simple File Sharing mode (that is the case for Windows XP and older)
If it uses OPCEnum, you will need to configure DCOM for OPCEnum as well, which is the recommended method to list remote OPC Servers.
If the application only supports remote registry lookup to find the OPC Server, then you will need to grant access to the account connecting from the client to the Server