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.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Access Denied on DASSIDirect
Access Denied on DASSIDirect
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
Isn't the reason why you needed to put that use into Administrator group because on the client computer, DCOM is configured to allow Administrator to access applications.
If you start DCOMCNFG on the client computer, navigate Console Root -> Component Services -> Computers -> My Comuter, right-click on My Computer, select Properties, switch to the COM Security tab and then in the Access Permissions group, make sure that the OPC server user is under "Edit Limits" and "Edit Default", does that help?
Regards
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
Among many problems with DCOM, there is one with DCOM initalization: Whoever makes the call to CoInitializeSecurity first in the process, wins. Further calls cannot change it.
In hosted environments, it happens that the host calls CoInitializeSecurity before QuickOPC gets the chance. It then really does not matter what QuickOPC does - it is all ignored. This can very well be the case here.
Regards
Please Log in or Create an account to join the conversation.
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) ;
Please Log in or Create an account to join the conversation.
Can you please try whether ReadItem/ReadItemValue methods work OK - and if not, whether they work OK when you set
client.InstanceParameters.Mode.AllowAsynchronousMethod = false;
Thank you
Please Log in or Create an account to join the conversation.
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?
Please Log in or Create an account to join the conversation.
If the two (client vs. server) machines are not in the same Windows domain (specifically, if they are in Windows workgroup), then - unless security is left totally open, without any authentication - the user account used needs to be duplicated on both machines, meaning identical username and identical password.
Regards
Please Log in or Create an account to join the conversation.
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?
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Access Denied on DASSIDirect