Results here of testing the remote OPC server using QuicOPC v5.63.183.1. As before, we adjusted our INI file with the same permutations of configuration changes. Instead of getting "No method available to convert ProgID to CLSID" consistently, we are now getting "The RPC server is unavailable." This occurs when we use the ProgID only or included both the ProgID and CLSID in the server descriptor. If we include only the CLSID in the server descriptor then again we revert back to getting the "No method available to convert ProgID to CLSID" error. We also noted seeing the following, as we also did with the old QuickOPC version, the following in the Windows System event logs:

We also performed an additional test. Since the OPC Expert client is able to connect to this remote OPC server, and OPC Expert has a "mimic" mode in which it connects to remote servers and re-exposes them as a local DA server, we configured OPC Expert as such and it runs as a local DA server on the same machine as our application using QuickOPC. Before testing this setup with our QuickOPC based client, we first confirmed that the other OPC client from Integration Objects was working. The Integration Objects OPC client was able to connect to the local OPC Expert DA server and create a group with one item ID successfully. So from this standpoint, the local OPC Expert DA server is working as a proxy to the real remote ArchestrA DA server. We then attempted to point our QuickOPC based service to this now local DA server. No luck. In this setup, QuickOPC reports the new error "Class not registered (0x80040154)".

For sure, trying to provide as much detail as I can since we all know OPC classic stuff can get spicy with all the unique environments encountered. You all truly do provide excellent support, one of the main reasons we went with QuickOPC.

Yes, I am using nuget to reference all the QuickOPC assemblies.

Have you tried running your Windows service (temporarily) under some regular user account (such as your own), or running the browsing code from "normal" app (not a Windows service|)?

We have attempted running our Windows service under the same user account used to remote into the system. This account did work with the OPC clients however not when used by the service. We did not test with this account though to the extent shown in my first post in the thread.

It can still be DCOM configuration/permissions issue if your Windows service was running under account different from what the other, working OPC clients are using.

We ran the two OPC clients using the same account as setup in the service. These two OPC clients were able to browse and subscribe to items successfully whereas the service was not able to do so with the same account.

A potential important detail I left out. The machine on which our service (and the two working OPC clients) resides also has a web proxy configured for all outbound http/s traffic leaving the local network. Is there any chance that QuickOPC would pick up and use a machine wide web proxy setting?

We have a Windows service application using QuickOPC v5.63.162 and are trying to connect to a remote OPC DA server which is the ArchestrA FSGateway product with its ProgID=ArchestrA.FSGateway.2 and CLSID={19d98a61-b3ca-4143-0088-35464d714ea0}. Our app supports the Intrinsic Component config within QuickOpc so below is our INI file showing the permutations of configuration changes attempted:


Along with manipulating the settings above, we have also tried giving QuickOpc the server descriptor which includes the ProgID only, CLSID only, and both the ProgID and CLSID of the OPC server. All of these attempts have resulted in us seeing the error "No method available to convert ProgID to CLSID (E_FAIL.0xC0049039)" in the data change event handler following the initial subscription attempt. When we set BrowseViaCategories=false and used the CLSID only I would have expected a different error since OPCEnum should not be used in this scenario; instead forcing a registry search for the CLSID we provided. This was not the case, and we received the same error in the subject of this post. Another interesting thing about the host machine our application lives on, is that the OPCEnum Windows service is in Manual mode but not running. Since we are connecting to a remote OPC server here, should we care at all about the state of the OPCEnum Windows service on the local machine?

Weirdly enough, there are two OPC clients (OPC Expert and the other from Integration Objects) on the same machine as our application, both "run as" the same account as our Windows service application which are able to connect and subscribe to items on the remote OPC DA server. Not sure where to go next since two unrelated OPC clients are working leading me to believe firewall, DCOM, and associated permissions are all correct.