I am trying to connect to a local OPC server. It is one of 7 OPC servers on the computer. I can connect to all the other servers except for this one.
As far as I can tell I have the server-specific DCOM settings wide open. Is there anything I could be overlooking as to why I cannot connect to this server?
Again this is a local server, not a remote computer.
By can't connect I mean I can see the OPC server in an OPC client, so opcenum is working - but I get a "OPCServer.WinCC. CoCreateInstanceEx: : 80070005 (Access Denied)" error.
I have a similar problem with Unitronic OPC Server on Windows 10. The OPC client is SCADA Reliance 4. The OPC Server runs as local on the same PC as Reliance. The problem is that the user requires to run Reliance with OPC server with limited privileges. Unitronic OPC server runs only with increased privileges because it is unable to operate with lower privileges. If an OPC client runs with a lower privilege than an OPC server, it is unable to establish a connection because of the restrictions. For these reasons, user must run the OPC client using the "Run As Administrator" option and the connection is successfully established in this case.
Related
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.
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
I am trying to connect an OPC-UA server with an OPC-UA client. I am using a remote desktop connection. Is it the reason that I am not getting any server discovered by Matlab OPC UA or Aspen CIMIO even though they are running?
"Discovered" or just "connected"? Connecting to the remote OPC UA server is normal process so if you cannot connect I would check if there is connection can be made in the first place (firewall) and if certificate is used and what is policy.
Can you put the server on your local computer and check the connection then?
I am using OPC Foundation's OpcNetApi.dll to communicate with an OPC DA server.
I am curious if there is a programatic way to kill specific connections which are currently active on the server using this library or a similar library.
I'm not positive, but I don't think what you are asking for is always possible (without a debugger). OPC is based on Microsoft COM. There are two ways that COM can be implemented:in-proc and out-of-proc. The choice depends on the OPC server vendor.
With an in-proc implementation, if you are running the OPC client on the same machine as the OPC server then the OPC server is just a dll that is loaded directly into the memory space of the OPC client. This dll exposes the OPC interfaces like CreateGroup, ReadAllItems, etc. Now it is probably getting the actual data through some other mechanism (named pipe, TCP/IP, etc) but this depends again on the OPC server implementation. The only way to really force stop this OPC server is to end the OPC client or get the OPC client program. Of course the OPC client or OPC server may already have implemented a mechanism to end, but there is not guarantee.
If it is an out-of-proc OPC implementation then the OPC server will run in a separate executable so you can find the name of that executable and terminate it. (You can search in regedit for the name of the OPC server to find the corresponding executable name). If I remember correctly, the OPC server can be designed so all clients share one executable or each OPC client gets their own instance of the executable.
If you are running the OPC server remotely then it is probably going to be loaded inside of a stub program if its an in-proc implementation and then tied to RPC. If you block the ports that RPC communicates over I think most clients would decide to disconnect after a while, although there is no guarentee they won't try to reconnect later.
Here's some more information:
https://www.opcsupport.com/link/portal/4164/4590/Article/711/May-I-get-a-In-Proc-and-Out-Of-Proc-explanation
Given these 2 installations:
A machine with 3 OPC UA servers.
A machine with 3 OPC UA servers and a LDS.
What is the difference in functionality? In particular, I would like to know:
Is the installation of a LDS mandatory?
What is the practical difference between discovering a server, then connecting to it, and directly connecting to the endpoint of the server without discovery?
What does installing an LDS enable to do?
(All this, with proper OPC UA specification references where applicable, please)
Is the installation of a LDS mandatory?
No, the installation of an LDS is purely optional. Especially on small / embedded devices you might not even be able to install anything else than the OPC UA server.
What is the practical difference between discovering a server, then connecting to it, and directly connecting to the endpoint of the server without discovery?
With the LDS running on a standarized port (4840) it is possible to discover all servers on the computer without knowing their endpoint URLs. Without an
LDS there is no way to connect to a server without knowing the URL.
As already commented, having the LDS makes discovery (very) slightly slower, as a connection to both LDS and server has to be established.
If only one server is running on the computer one might want to set the port of this server to 4840, so clients discovering on the computer find the server without needing to know a custom port.
What does installing an LDS enable to do?
It simply allows to discover all servers running on the computer without knowing all their different endpoint URLs.
Future versions will contain enhancements, broadcasting this information via Zeroconf, so every LDS would have the list of all OPC UA servers on the local network.
I have installed a SQL Express 2008 Server on my Desktop for some local work. This has mixed authentication. I have enabled TCP/IP connection so that one colleague can connect to this server. However, this exposes the server to everyone in the network. How do i keep track of which PC in the network connected to this server and when ? This would just help me audit the usage of the server.
Well you can get information about current users, sessions, and processes in an instance by using
sp_who;
MSDN Documentation