Hi,

Thanks for the additional input, that could be a helpful option.

The end result is still the same i.e. DCOM changes are required when using QuickOPC .Net, but other OPC Clients work without any DCOM changes.

Getting a service to work with QuickOPC is the final goal.

The original problem was connecting to the OPC Server on a remote machine from the XMLLogger sample, this scenario can be expanded to say that the remote OPC server is using a service login that is unknown to the host running the XMLLogger sample.

My testing so far has indicated that this is will never work with QuickOPC, although other clients (Matrikon, OPC Expert, and our native service) will work.

The only way the sample would work, is to ensure the login used by the remote OPC Server is also a local user in the Administrator group on the host system running XMLLogger. It was then possible to subscribe to data changes with default values for the QuickOPC security settings under SharedParameters.ClientParameters.

From what I have since read about CoInitializeSecurity and .NET, it appears to be impossible to control unless a "Native Shim" is used prior to loading a .NET Module. Would this be the approach we would need to take when writing a service with QuickOPC?

Stack Overflow

We want to capture a high volume of data changes from the OPC Server, so using asynchronous subscriptions has to be the way for this to work.

We were able to make this work by changing the OPC Server service to use a login that was also part of the local Admin group on the host system running the XMLLogger sample.

In our native application we initialise COM security as below. Our application can subscribe to OPC data changes without any requirement to change the OPC Server configuration. Is this something that can be replicated on the QuickOPC side?

CSecurityDescriptor sd;
sd.InitializeFromThreadToken();
hr = CoInitializeSecurity(sd, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_PKT, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL) ;

Thanks for your input with regard to the Identity setting. This is a "Workgroup" scenario, and the users have been synchronised between the machines, once the OPC Server is restarted we can re-test.

Irrespective of this Identity setting, there are 3 other OPC Clients that do work, is it possible to adjust Quick OPC settings to work in a similar way?

Thanks for the suggestion to use the GUID, but I'm getting the same results.

We have discovered that the remote OPC Server has DCOM "Identity" settings configured as "This User" and a specific user account, so it may be that this is the issue for Quick OPC. We will ask for this user to be added to the Client machine and re-test.

We still don't understand why all the other OPC Clients can subscribe to data changes with the current DCOM setup and the Quick OPC test application does not. What are the most "open" settings we can apply to the XMLLogger example?