Professional OPC
Development Tools


Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

OPC DA client and server running on differente machines with different accounts

17 May 2016 14:55 #4043 by support
With regard to the security settings, there is absolutely no difference between ReadItem vs. ReadMultipleItems,

ReadItem simply constructs a call with a single item to ReadMultipleItems, and then "unpacks" the single result it receives.

Note that ReadMultipleItems does never throw (given that it is passed valid arguments); if there is an error, it is returned for each item separately, in the .Exception property of the DAVtqResult.

BTW, if you are doing things such as reading 700 items, you should definitely use ReadMultipleItems - the performance difference will be enormous.

The following user(s) said Thank You: frighini

Please Log in or Create an account to join the conversation.

17 May 2016 14:01 #4042 by frighini
And what about ReadMultipleItems? (not yet tested but i think not working with our current configuration)
From remarks in the doc, it seeems to me that reading is done in parallel:

//The function performs all individual
//operations in parallel, but only returns after all individual operations
//are completed (or their timeouts elapse).

Thank you again!

Please Log in or Create an account to join the conversation.

17 May 2016 12:52 #4041 by support
For OPC & DCOM configuration, it is very important to know whether both computers are in the workgroup, or one in the domain and one in the workgroup. The security consequences and settings are completely different in the two settings. And, the configuration when one is in the workgroup and the other in the domain should be avoided at all costs. In my opinion, in general case, it cannot be set up to work with OPC, without compromising the security of the domain.

To the exception: You need to look into the InnerException and give us the details of it.

It is a common DCOM configuration problem to have such settings in which the OPC client can access the OPC server, but the OPC server cannot access the client. For full OPC communication, *both* directions must be correctly configured. You might be in this situations, based on the symptoms you have described.

We have made special provisions to allow QuickOPC work, with a degraded functionality, under such circumstances as well. Parts that will *not* work without the reverse-direction channel are asynchronous operations, and subscriptions (and a server shutdown request, which is not that important). Everything else should work. This may explain why with AllowAsychronousMethod = false, the ReadItem works. I do not see it as a problem per se that sync reads is used, because if you are using one thread and waiting for the results in a loop anyway, async reads only add complexity but no benefit. What may be worse is that you should not ideally used repeated reads at all, if you are reading still the same thing - for that, we have subscriptions (but I understand that they may not work for you - but that again usually boils down to the proper DCOM settings).


Please Log in or Create an account to join the conversation.

17 May 2016 11:28 #4040 by frighini
Thank you for your answer: as you may have guessed i'm not familiar with DCOM (and unfortunately no time to became)!

Some more info: OPC client computer is in a workgroup.
OPC server i'm not sure but i think it is in a workgroup too.

I would like to ask you another question. When setting the same account on client and server:
1) EasyDAClient.GetPropertyValue works
2) EasyDAClient.ReadItem fails with this exception

Exception while disposing EasyDAClient : An OPC operation failure with error code -1073430509 (0xC004C013) occurred, originating from 'OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient'. The inner exception contains details about the problem.

3) EasyDAClient.ReadItem is ok if we set to false all these properties:
AllowAsynchronousMethod , UseCustomSecurity, TurnOffActivationSecurity, TurnOffCallSecurity

Do you think it could be related to any missing configuration in DCOM?
What i'm interest in is particularly AllowAsynchronousMethod=true because we should read many items (about 700 every second)

Thank you.

Please Log in or Create an account to join the conversation.

17 May 2016 08:33 #4039 by support
This has to do with very complicated area of COM/DCOM security, and any answer I give here cannot be complete. Instead, I'll just point out some things:

1) You do not say whether the two computers are in the same domain, or different domains, or one of them is in a domain and other in a workgroup, or whether the two computers are in a workgroup. Many other answers and facts rely on this.

2) The LocalSystem account has, by default, very limited privileges on the network (and it is highly recommended to keep it configured as such). It is therefore not suitable for remote COM/DCOM.

3) It is certainly possible to run OPC client and OPC server on different machines and with different accounts. It is, in fact, precisely how it is generally used in many industrial installations. This is not to say it is easy to configure, though. I do not know where you have taken the information about it being not possible. In addition, "same account" is not the same as "having same username/password", at least not in the domain environment (where "same" means "the same account in the domain" - two local accounts with the same username and password are still different one from the other and from the domain account with the same username and password). You might have confused it with the fact that in a workgroup environment, if one wants to refer to a user account and does not have it locally, then first a corresponding local account with the same username/password needs to be created - but even then, the client and server should be able to use different accounts.

4) Impersonation on the client side is not supported by QuickOPC (and I have never seen it being used by any OPC client). AFAIK, proper security settings is always done by running the client process under a specific account. The UserName and Password in the ServerDescriptor are ignored for COM/DCOM servers: They only have to do with OPC-XML.

In order to try to put it at least in a bit simplified way: The common approach that works is to use a domain, and run the client and the server under specifically created accounts (not LocalSystem); if needed, they can be different on both sides.

Best regards

Please Log in or Create an account to join the conversation.

17 May 2016 06:53 #4038 by frighini

here is our problem:
- our OPC DA client is a service running under System account (we would prefer not change this).
- the OPC DA server is on another machine and was configured with "OPCConnect" user.

In this situation reading item fails. If temporarly we change client account setting "OPCConnect" it works.
Searching online i've found that OPC DA client and server on different machines must run under the same account (username/password).

Is there a method to connect to the server using different account?
Perhaps using thread impersonation on the client?

We have tried also with ServerDescriptor.UserName and ServerDescriptor.Password but no success.


Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.061 seconds