DCOM errors

[PoorAdmin]

Going through my event logs and noticed the following event. I tracked this down to the StorageManagement service under Component Services. Since this is requesting permissions for the anonymous login I'd like to be sure that this needed. Any thoughts? 

Log Name:      System
Source:        Microsoft-Windows-DistributedCOM
Date:          10/6/2014 7:17:45 AM
Event ID:      10016
Task Category: None
Level:         Error
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:     
Description:
The application-specific permission settings do not grant Remote Activation permission for the COM Server application with CLSID
{912A9DC6-D9F7-11D1-ADF2-0000F87A3C74}
 and APPID
{29A9E25B-D9FE-11D1-ADF2-0000F87A3C74}
 to the user NT AUTHORITY\ANONYMOUS LOGON SID (S-1-5-7) from address 10.10.10.62 running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

[AndrewB · Accepted solution]

i found a couple technotes which correlate to the same error. you can see if one of them applies to your situation.

http://www.symantec.com/business/support/index?page=content&pmv=print&impressions=&viewlocale=en_US&id=TECH204473

http://www.symantec.com/business/support/index?page=content&id=TECH204450

[dallandra]

Hi Andrew,

i just wanted to thank you for these suggestions...particularly the 2nd one .  we've been having DCOM errors relating to access to the ev components ever since we migrated hardware eg

The application-specific permission settings do not grant Remote Activation permission for the COM Server application with CLSID
{3A92686F-E5E8-4505-ABB5-49E5F725617A}
and APPID
{9FB267AD-C6CE-4084-A18F-5100B54964B3}
to the user NT AUTHORITY\ANONYMOUS LOGON SID (S-1-5-7) from address 10.61.1.14 running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

issuing the command from that technote "setspn /L oldevserver hostname" it was found that our old ev server still existed in AD (even though it was physically decomissioned long ago).  deleting this server in AD instantly solved out problems.

no need to manually add DCOM permissions through dcomcnfg.exe (even though they reset when the server was reset or ev admin service was restarted)... a manual process we had been living with for a year!  and which continued even after migrating again to a new EV server, new EV version (from EV10 to EV11) and an upgrade O/S (server 2012)

thanks again!