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
28 Dec 2020 06:57 #9320
by support
Replied by support on topic Access Denied on DASSIDirect
Thank you for the additional information. I think you are asking too much from us. DCOM behavior, in all possible combinations and environments, would be nearly impossible to explain even for Microsoft.
My understanding is that you have found combination(s) that so work - is that right?
Best regards
My understanding is that you have found combination(s) that so work - is that right?
Best regards
Please Log in or Create an account to join the conversation.
23 Dec 2020 21:35 #9317
by tblong
Replied by tblong on topic Access Denied on DASSIDirect
An additional behavior uncovered in my test environment. I created a local admin account called "dcomuser" and assigned this user as the Log On account for my Windows service instead of the default local SYSTEM account. For COM security, the local SYSTEM account was removed from the Limits access permissions and the "dcomuser" account was give full local and remote in Defaults and Limits under both Access and Launch permissions. I got the following stack trace:
I then added back the local SYSTEM account to the Limits for access permissions with my service still logging on as the "dcomuser" and the subscription to items became successful again. This was quite unexpected to be successful. What might be going on here?
OpcLabs.EasyOpc.Engine.NetApiException: An exception with error ID 'HResult=0x80040202' occurred during processing in a NET API OPC Data Access client. The inner exception contains details about the problem.
+ The client method called was 'ItemChanged'. ---> System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80040202
+ This error might be related to DCOM configuration (even locally). Run DCOMCNFG, and in COM Security on My Computer, add Everyone, Interactive, Network and System to the Defaults and Limits for Access Permissions, and Launch and Activation Permissions, allowing Local or Remote permission as needed in your application.
at OpcRcw.Comn.IConnectionPoint.Advise(Object pUnkSink, Int32& pdwCookie)
at OpcCom.ConnectionPoint.Advise(Object callback)
at OpcCom.Da.Subscription.Advise()
at OpcCom.Da.Subscription.add_DataChanged(DataChangedEventHandler value)
at Opc.Da.Subscription.add_DataChanged(DataChangedEventHandler value)
at OpcLabs.EasyOpc.Implementation.NetApi.DataAccess.NetApiOpcDaServer.CreateSubscription(SubscriptionState state, DataChangedEventHandler dataChangedEventHandler, SubscriptionState& newState, Exception& exception)
--- End of inner exception stack trace ---I then added back the local SYSTEM account to the Limits for access permissions with my service still logging on as the "dcomuser" and the subscription to items became successful again. This was quite unexpected to be successful. What might be going on here?
Please Log in or Create an account to join the conversation.
23 Dec 2020 16:41 #9316
by tblong
Replied by tblong on topic Access Denied on DASSIDirect
I disabled the native client (InstanceParameters.EnableNativeClient = false) using the latest released nuget package v5.59.492. While the stack trace is a bit different now, the resulting error is the same with "access denied" when the local SYSTEM account is not in the Limits access permission. Adding the local SYSTEM account back to Limits performs the same as when the native client was enabled with respect to the "access denied" error. Stack trace below showing the native client being disabled and local SYSTEM not in Limits:
OpcLabs.EasyOpc.Engine.NetApiException: An exception with error ID 'ErrorCode=0x80004005' occurred during processing in a NET API OPC Data Access client. The inner exception contains details about the problem. ---> System.Runtime.InteropServices.ExternalException: CoCreateInstanceEx: Access is denied.
at Opc.Server.Connect(URL url, ConnectData connectData)
at Opc.Da.Server.Connect(URL url, ConnectData connectData)
at Opc.Server.Connect(ConnectData connectData)
at OpcLabs.EasyOpc.Implementation.NetApi.DataAccess.NetApiOpcDaServer.ServerConnect(Server server, ConnectData connectData, Exception& exception)
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.Implementation.NetApi.DataAccess.NetApiOpcDaServer.ConnectToServer(WebProxy proxy, Server server, NetworkCredential credentials, String connectionGroupName, EasyDAAdaptableParameters adaptableParameters)
at OpcLabs.EasyOpc.Implementation.NetApi.DataAccess.NetApiOpcDaServer.Connect(Boolean doOnlyIfGoodStatus, Boolean callGetStatus, Exception& exception)
--- End of inner exception stack trace ---I was following this "At that moment, however, I will kindly ask you to try out the new 2020.3 version (even if it's just pre-release at that moment), because due to the changes in the implementation, it would make no sense to try to resolved issues in the implementation that we are just discarding." on this thread here . I imagine your intent here was to suggest that I should not have used this beyond my own test environment, on that point I agree and got a bit ahead of myself.BTW, please do not use pre-release versions unless instructed to
Yes our service is targeting .NET Framework v4.7.2.This hint assumes that you are running under .NET Framework. If you were running under .NET Core, the setting would already be effectively in use.
Please Log in or Create an account to join the conversation.
17 Dec 2020 12:46 #9293
by support
Replied by support on topic Access Denied on DASSIDirect
Hello.
The reason why QuickOPC behaves differently is because the low-level OPC DA/A&E code is written in C++, and the COM security calls there compete with settings that the .NET host (CLR) does.
I suggest that you try the following: Switch to the latest released version. In your code, wherever you instantiate the EasyDAClient object, immediately set its InstanceParameters.EnableNativeClient property to false (before doing any OPC operation). Rebuild and retest. (BTW, please do not use pre-release versions unless instructed to).
What this does is that it switches to fully .NET implementation of OPC DA low level code. We are slowly migrating to make this the default behavior, but we are not there yet. The expectation is that the DCOM security will work more in line with other implementations.
This hint assumes that you are running under .NET Framework. If you were running under .NET Core, the setting would already be effectively in use.
Best regards
The reason why QuickOPC behaves differently is because the low-level OPC DA/A&E code is written in C++, and the COM security calls there compete with settings that the .NET host (CLR) does.
I suggest that you try the following: Switch to the latest released version. In your code, wherever you instantiate the EasyDAClient object, immediately set its InstanceParameters.EnableNativeClient property to false (before doing any OPC operation). Rebuild and retest. (BTW, please do not use pre-release versions unless instructed to).
What this does is that it switches to fully .NET implementation of OPC DA low level code. We are slowly migrating to make this the default behavior, but we are not there yet. The expectation is that the DCOM security will work more in line with other implementations.
This hint assumes that you are running under .NET Framework. If you were running under .NET Core, the setting would already be effectively in use.
Best regards
Please Log in or Create an account to join the conversation.
17 Dec 2020 11:41 #9292
by tblong
Replied by tblong on topic Access Denied on DASSIDirect
This is with the prerelease nuget v5.59.0-rev23. Just noticed also that the official release of this version is now available.
Please Log in or Create an account to join the conversation.
17 Dec 2020 10:14 #9291
by support
Replied by support on topic Access Denied on DASSIDirect
I cannot tell what precisely is the reason, the DCOM setting you described is just one among many.
Before we go to further tweaking of the settings, please tell me which QuickOPC version you are using.
Best regards
Before we go to further tweaking of the settings, please tell me which QuickOPC version you are using.
Best regards
Please Log in or Create an account to join the conversation.
16 Dec 2020 22:08 #9290
by tblong
Replied by tblong on topic Access Denied on DASSIDirect
@support, Our service only performs subscriptions and is seeing the "access denied" error from the item changed event. Our service is not programmed to perform any browse or read operations.
In our test environment, not the client's system, I was able to reproduce the "access denied" issue by making sure that the local SYSTEM account shown in the attached screenshot was NOT in the Limits setting and ONLY in the Defaults. Once I added local SYSTEM back to the Limits setting for Local access then I was able to subscribe to items successfully.
The second attachment shows my test kepserver setup to use Default access permissions. Why did adding SYSTEM to Limits have a positive effect? Does this one change help identify why using QuickOPC requires different COM settings?
In our test environment, not the client's system, I was able to reproduce the "access denied" issue by making sure that the local SYSTEM account shown in the attached screenshot was NOT in the Limits setting and ONLY in the Defaults. Once I added local SYSTEM back to the Limits setting for Local access then I was able to subscribe to items successfully.
The second attachment shows my test kepserver setup to use Default access permissions. Why did adding SYSTEM to Limits have a positive effect? Does this one change help identify why using QuickOPC requires different COM settings?
Please Log in or Create an account to join the conversation.
16 Dec 2020 16:32 #9289
by csm
Replied by csm on topic Access Denied on DASSIDirect
@tblong It was never resolved. I never got an explanation as to why other OPC Clients work and this one does not.
There was no solution offered other than configuring DCOM which is a pain. The SDK works really well apart from this.
There was no solution offered other than configuring DCOM which is a pain. The SDK works really well apart from this.
The following user(s) said Thank You: tblong
Please Log in or Create an account to join the conversation.
16 Dec 2020 16:11 #9288
by support
Replied by support on topic Access Denied on DASSIDirect
Hello,
how is it with other OPC operations (not subscriptions?) Are you getting "Access denied" only in subscription notifications, or also when you try to Browse, Read, etc.?
Thank you
how is it with other OPC operations (not subscriptions?) Are you getting "Access denied" only in subscription notifications, or also when you try to Browse, Read, etc.?
Thank you
Please Log in or Create an account to join the conversation.
15 Dec 2020 23:19 #9284
by tblong
Replied by tblong on topic Access Denied on DASSIDirect
@csm Were you able to get this resolved?
@support I may need some help here myself.
We are also using QuickOPC .Net with our own Windows service and seeing the same access denied issue on subscription. Our Windows service is on the same machine as the OPC DA server (PI OPC DA server). Using our old OPC library works but when subscribing to the same items we get the access denied issue.
Our service runs under the typical local SYSTEM account which works with our old OPC library and we are able to subscribe to items. See screenshot attached. The SYSTEM account on the machine is checked only for Local and the Remote box is unchecked in the Defaults within the COM Security tab under here "Component Services -> Computers -> My Comuter, right-click on My Computer". Is checking Remote for the SYSTEM account one of the changes in DCOM settings I may need to perform QuickOPC .Net?
@support I may need some help here myself.
We are also using QuickOPC .Net with our own Windows service and seeing the same access denied issue on subscription. Our Windows service is on the same machine as the OPC DA server (PI OPC DA server). Using our old OPC library works but when subscribing to the same items we get the access denied issue.
Our service runs under the typical local SYSTEM account which works with our old OPC library and we are able to subscribe to items. See screenshot attached. The SYSTEM account on the machine is checked only for Local and the Remote box is unchecked in the Defaults within the COM Security tab under here "Component Services -> Computers -> My Comuter, right-click on My Computer". Is checking Remote for the SYSTEM account one of the changes in DCOM settings I may need to perform QuickOPC .Net?
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Access Denied on DASSIDirect
Time to create page: 0.110 seconds