J
Jay Scovill
Guest
I'm having a problem with Windows 2003 SP2 Terminal Services and COM Plus.
We have an application that launches a COM Plus component when it is run.
The application is the client portion of a client/server product. Both the
client and the server are running on the Terminal Server. So all
interaction between the two should be local with no involvement of the
network.
When a non-administrative user logged on though a regular RDP session and
tries to launch the application it fails and the following error is logged
in the event viewer:
Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10016
Date: 10/15/2007
Time: 3:59:45 PM
User: DOMAIN/user
Computer: COMPUTER
Description:
The application-specific permission settings do not grant Local Activation
permission for the COM Server application with CLSID
{1DC47A80-C950-43D0-865C-2B8DC2A2EEA9}
to the user DOMAIN\user SID (S-1-5-21-5706737-1535929353-1477605468-1256).
This security permission can be modified using the Component Services
administrative tool.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
The CLSID in the log matches that of the COM Plus component in question.
However, if I place that user (or any user) into the local admin group and
log them onto the console connection through RDP as well as giving them the
CreateOwner role on that COM Plus component they are able to launch the
component succesfully. The two key factors here are that the user is
connected to the Console RDP session and they are given the CreateOwner
Role. Simply giving them local admin rights doesn't work and if I change
either of the other two factors the problem exhibits itself.
This all happens when the component is registered as a Server application
(this is required to get around some memory corruption problems with .NET
if it's registered as a Library application).
I have not been able to manipulate any permissions to allow this to run
when the user is not logged onto the Console connection.
Any ideas out there as to what is so special about the Console connection
that allows this component to run but not when there is a regular RDP
session? Any permissions that I can change to fix this?
We have an application that launches a COM Plus component when it is run.
The application is the client portion of a client/server product. Both the
client and the server are running on the Terminal Server. So all
interaction between the two should be local with no involvement of the
network.
When a non-administrative user logged on though a regular RDP session and
tries to launch the application it fails and the following error is logged
in the event viewer:
Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10016
Date: 10/15/2007
Time: 3:59:45 PM
User: DOMAIN/user
Computer: COMPUTER
Description:
The application-specific permission settings do not grant Local Activation
permission for the COM Server application with CLSID
{1DC47A80-C950-43D0-865C-2B8DC2A2EEA9}
to the user DOMAIN\user SID (S-1-5-21-5706737-1535929353-1477605468-1256).
This security permission can be modified using the Component Services
administrative tool.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
The CLSID in the log matches that of the COM Plus component in question.
However, if I place that user (or any user) into the local admin group and
log them onto the console connection through RDP as well as giving them the
CreateOwner role on that COM Plus component they are able to launch the
component succesfully. The two key factors here are that the user is
connected to the Console RDP session and they are given the CreateOwner
Role. Simply giving them local admin rights doesn't work and if I change
either of the other two factors the problem exhibits itself.
This all happens when the component is registered as a Server application
(this is required to get around some memory corruption problems with .NET
if it's registered as a Library application).
I have not been able to manipulate any permissions to allow this to run
when the user is not logged onto the Console connection.
Any ideas out there as to what is so special about the Console connection
that allows this component to run but not when there is a regular RDP
session? Any permissions that I can change to fix this?