Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DCOM Error 10016

22 views
Skip to first unread message

kewlhand

unread,
Aug 10, 2007, 9:59:16 AM8/10/07
to
So, Yeah I've been all over the web trying to figure this out. I'm
hoping someone from this group can shead some light. I have a com+
application that runs just fine on Windows 2000 Server. I'm in the
process of upgrading hardware and eventually the code base for the
application, but in the mean time I'm looking to get it up and runnin
gon Server 2k3 R2 SP2. I install it as I normally would, registering
all of my dlls and when I attempt to browse to the website I receive
an HTTP 500 error and the following is logged in the event log.

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10016
Date: 8/10/2007
Time: 9:35:26 AM
User: ServerName\IUSR_ServerName
Computer: HRVRPT
Description:
The application-specific permission settings do not grant Local
Activation permission for the COM Server application with CLSID
{AD7C30FB-2739-4912-86C6-2518D2AF62FB}
to the user ServerName\IUSR_ServerName SID (Sid ID...). 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.

I've seen plenty of resources that suggest finding the freindly name
and changing the launch and activation permissions for that
application via the DCOM Config. I'd love to do that, but my
application is not listed as one in the DCom Config. I've already
added the Network Service, and the IUSR account to the Default Launch
and Activation Permissions for Com Security (and checked all of the
options), with no change. I'm somewhat at my wits end here. If
anyone has any other ideas that I could try please respond back. I'd
greatly appreciate it.

Thanks in advance
-L.

Brian Muth

unread,
Aug 10, 2007, 11:58:33 AM8/10/07
to
Scan the registry for {AD7C30FB-2739-4912-86C6-2518D2AF62FB}. In particular,
you should find the COM object under

HKCR\CLSID\{AD7C30FB-2739-4912-86C6-2518D2AF62FB}

That should give you the ProgID and InprocServer32 information you need to
find out which COM object is giving you trouble.

HTH

Brian

kewlhand

unread,
Aug 15, 2007, 9:10:49 AM8/15/07
to
Like I'd said, I've already gotten the freindly name of the component
that's giving me issues, but the fixes I've seen all say once you have
that go to DCOM config and change the permissions there, however that
particular component isn't listed in the DCOM config section either by
freindly name or by GUID.

So that I can get my application to run in the mean time I've uncheck
the Enfore access checks for this application checkbox from com+
applications/app name/properties/security tab, but that's not the way
I'd like to run this app in production.

Any other info you could share would be greatly appreciated.

Thanks.
-Luke

On Aug 10, 11:58 am, Brian Muth <BrianM...@discussions.microsoft.com>
wrote:

Brian Muth

unread,
Aug 15, 2007, 1:34:03 PM8/15/07
to

"kewlhand" wrote:

> Like I'd said, I've already gotten the freindly name of the component
> that's giving me issues, but the fixes I've seen all say once you have
> that go to DCOM config and change the permissions there, however that
> particular component isn't listed in the DCOM config section either by
> freindly name or by GUID.
>

For COM+ applications, you don't use DCOMCnfg. Instead you use Component
Services. Typically this would involve creating a role for the COM+
application of interest and adding ServerName\IUSR_ServerName (in your case).

If you have enabled component level access checks, you will need to click on
the Properties of the specific COM+ object that is giving trouble, then click
on the "Security" tab and enable the checkbox that lists the role you just
created.

HTH

Brian


Adrian Herscu

unread,
Sep 5, 2007, 3:43:35 PM9/5/07
to
Brian hi,

I have a similar problem -- trying to activate two COM Servers the
following errors are thrown:

The application-specific permission settings do not grant Local
Activation permission for the COM Server application with CLSID

{0C0A3666-30C9-11D0-8F20-00805F2CD064}
to the user MANAGER\pm SID
(S-1-5-21-1351778941-242146922-296224648-1005). 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 machine-default permission settings do not grant Local Activation

permission for the COM Server application with CLSID

{9BA05972-F6A8-11CF-A442-00A0C90A8F39}
to the user MANAGER\pm SID
(S-1-5-21-1351778941-242146922-296224648-1005). 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.

One of those components is MDM and the other is ShellWindows. I am
trying to activate them from a user account. Activation through SYSTEM
or one of the Administrators' accounts succeeds.

Please explain where do I need to create that "role" since those
components do not show under any of the COM+ Applications hives. (They
appear under the DCOM Config category)

TIA,
Adrian.

Brian Muth

unread,
Sep 5, 2007, 4:52:46 PM9/5/07
to
You didn't mention what operating system you are working on, but I'll guess it is WinXP SP2 or Win2003 SP2. This introduced a
machine-wide AccessCheck call that must succeed in addition to other specific access checks.

You can modify the settings of this machine-wide AccessCheck by using Component Services. Right-click on "My Computer", and click on
the COM Security tab.

Also, have a look at the document http://technet.microsoft.com/en-us/library/bb457156.aspx in the section marked "DCOM Security
Enhancements". This may be helpful to you.

Good luck!

Brian

Adrian Herscu

unread,
Sep 6, 2007, 4:03:02 AM9/6/07
to
Brian, thanks for your fast reply.

I am using WinXP SP2.
According to the document you pointed:
>>>
By default, the Everyone group is granted local launch, local
activation, and local call permissions. This should enable all local
scenarios to work without modification to the software or the operating
system.

By default, the Everyone group is granted remote call permissions. This
enables most COM client scenarios, including the common case where a COM
client passes a local reference to a remote server, in effect turning
the client into a server. This might disable scenarios that require
unauthenticated remote calls.
>>>
I added my developer account to have full access to the involved
components and that solved the problem.
Thanks,
Adrian.

0 new messages