Video Screencast Help

DCOM errors on newly installed Exchange 2010

Created: 19 Sep 2011 | 7 comments
Tobbe.S's picture

Hi. I´m getting ALOT of event 10016 in the system log on a newly installed Exchange 2010 server. The 10016 Event states the following: The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {0E312BE4-7FFF-4C2F-A0E9-6AE80CABDB8F} and APPID {9050D46B-FBDB-4D32-8A98-EA601E03FBAE}to the user DOMAIN\Serviceaccount SID (S-XXX-XXX....) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool. I´ve failed to find an official answer to what is causing this...Has anyone else experienced this and also solved it? The SMSMSE version is 6.5.5.255

Discussion Filed Under:

Comments 7 CommentsJump to latest comment

Tobbe.S's picture

Hi Benjamin, and thanks for your reply.

I´ve got to admit that the error message is spot on, however the DCOM permissions where already correct for both SMSMSE admins and viewers.
Also, all administration is done locally on the Exchange server, and I have not experienced any issues during the setup or afterwards. The only evidence that I can find of an issue is in fact the errormessages in the systemlog.

Mick2009's picture

Hi Tobbe,

Is that server set with a default of "impersonate" or "identify"?

See the following article:

Error: "You have insufficient rights to access this application." when trying to open the console
Article: TECH86549   |  Created: 2007-01-13   |  Updated: 2011-07-25   | 
Article URL http://www.symantec.com/docs/TECH86549

Change DCOM permissions on Windows 2003 or Windows 2008

NOTE: Any changes made to DCOM permissions will require a reboot of the server to take effect.

On the Windows taskbar, click Start > Run.
In the Open box, type the following text: dcomcnfg
Press Enter.
In the left pane, expand Component Services > Computers.
Right-click My Computer > Properties.
Click Default Properties.
For Default Impersonation Level, click Identify.

Please keep this thread up-to-date with your progress! 

With thanks and best regards,

Mick

Tobbe.S's picture

Hi Mick.

The default DCOM settings are in fact set to impersonate, however we are not having any issues with launching the application which the tech note is meant to address? I´m familiar with the DCOM functionality in general so I tried to understand what the difference would be between Impersonate and Identify mode, and this is from the local help:

"Default Impersonation Level: Select the system-wide default level of authority that a COM client on this computer can grant to a server application to perform processing tasks on its behalf. Levels are listed in order of increasing authority."

Since Impersonate comes after Identify in the list, to me that sounds as if changing the level to Identify is in fact lowering the powers of the client?

Regardless of which, I´m willing to give this a go anyway, but I need to find a suitable window for a Exchange reboot.

If you have more suggestions or explanations I´d appreciate it of course.

Thanks so far and I´ll return with the results of the changed DCOM settings once I can execute it.

Tobbe.S's picture

Hi again.

I changed the settings to Identify, but the problem did not disappear. In fact, the DCOM error message was one of the first to appear after the reboot...how encuraging...

I then decided to revert the change so the default setting is once again back to Impersonate, and the server has been rebooted after that change as well, so I´m back to the original settings again.

benjamin_lurie's picture

Since it is not a problem with the SMSMSE administration console it is likely a different SMSMSE component using the DCOM component. 

In your original error message:

 

DOMAIN\Serviceaccount SID (S-XXX-XXX....)

 

Which account is it?  Is it the service account that the SMSMSE services are running as or a different one? Maybe that account does not have the correct DCOM permissions?

It might be helpful to run Microsoft procmon to see in more detail which component causing that.  Though I have to admin analyzing the procmon file is not a trivial task and you may want to actually open a Symantec Technical Support case for that.

Is there any pattern to the timing and frequency of the messages?  That could provide a clue.  But without looking a the Windows Application Event log I really don't have much to go on there.

Ben

Tobbe.S's picture

Hi again.

The referenced account is the service account used by SMSMSE and running the SAVFMSESrv.exe service, but I´m not sure how I would go about to verify that it has all the correct DCOM permissions...?

I´ve tried to find a red thread through the error messages but I´ve failed. They can occur at almost any hour of the day, but they definitely tend to be more frequent at daytime. In fact, over the few days that the system has been up and running there seems to be "radio silence" between approx midnight to five AM.

There can be anywhere between one to four log entries at the same second and then it can be any type of gap between them from seconds to minutes to even several hours.

I remember running procmon from sysinternals many, many years ago, but I would definitely need some assistance with that if that is the path to go from here, and I hear what you say about registering a support case.