DCOM was unable to communicate with the computer using any of the configured protocols

We get the following in our Exchange 2010 SP3 Rollup 1 event log:
Log Name:      System
Source:        Microsoft-Windows-DistributedCOM
Date:          19.07.2013 10:07:49
Event ID:      10028
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      cashub01.domain.com
DCOM was unable to communicate with the computer cashub02.domain.com using any of the configured protocols; requested by PID      604 (c:\windows\system32\inetsrv\w3wp.exe).
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
    <EventID Qualifiers="0">10028</EventID>
    <TimeCreated SystemTime="2013-07-19T08:07:49.405004600Z" />
    <Correlation />
    <Execution ProcessID="648" ThreadID="15880" />
    <Security UserID="S-1-5-18" />
    <Data Name="param1">cashub02.domain.com</Data>
    <Data Name="param2">     604</Data>
    <Data Name="param3">c:\windows\system32\inetsrv\w3wp.exe</Data>

This is the same issue, but it does not provide a solution; Only a workaround to hide the error.

I can povoke the error when running
Get-OWAVirtualDirectory -Server cashub02

Open in new window

from cashub01. Same thing the other way.

Setup of Exchange 2010 environment:
* cashub01
* cashub02
* mailbox01 (in DAG with 02)
* mailbox02 (in DAG with 01)

All servers are Microsoft Windows Server 2012 Datacenter running on VMware ESXi 5.1.1.
Everything else is working. This is the only error on our cashubs.
Firewall is configured to allow traffic in and out between the IPs of the four Exchange servers.

Note!: The Exchange 2010 environment is currently coexisting with Exchange 2007 witch currently is our production Exchange environment.

Hope some of you guys can help us out.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Shreedhar EtteCommented:
What does domain security group CERTSVC_DCOM_ACCESS contains? Please post the details.
Sushil SonawaneCommented:
Make sure port 135 open in your server and client side firewall. If still issue persist then off the client side firewall and then check.
nifdriftAuthor Commented:
shreedhar: We do not have such a group in our domain

Marshalhubs: I do not wish to show this information to everyone. Do you have an e-mail so I can mail you the link for the cab?

sushil84: There is no firewall between any of the Exchange servers, only between Exchange and mail clients.
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

Simon Butler (Sembee)ConsultantCommented:
Unfortuantely the post by marshalhubs is a straight copy and paste from a Microsoft Technet forum post where someone from Microsoft asks for the content.


Therefore the post is completely useless to you.

You have mentioned a firewall. Are you talking about the Windows firewall or something else? Microsoft do not support any kind of firewall traffic blocking between Exchange servers, so if you are trying to restrict the traffic you will need to remove that restriction.

nifdriftAuthor Commented:
I tried turning off the firewall on both cashubs, but i still get the following error in the event log
DCOM was unable to communicate with the computer cashub02.domain.com using any of the configured protocols; requested by PID      604 (c:\windows\system32\inetsrv\w3wp.exe).

Open in new window

Simon Butler (Sembee)ConsultantCommented:
"Firewall is configured to allow traffic in and out between the IPs of the four Exchange servers."

What EXACTLY do you mean by that.

Are you referring to the WINDOWS firewall or something else? Disabling the WIndows firewall is not recommended.

nifdriftAuthor Commented:
"Firewall is configured to allow traffic in and out between the IPs of the four Exchange servers."
This is the Windows firewall. I have re-enabled it.
Simon Butler (Sembee)ConsultantCommented:
What did you change in the Windows firewall configuration? You shouldn't need to change anything.

Are the two servers on the same subnet?

nifdriftAuthor Commented:
All the Exchange servers are on the same subnet.
I am receiving the same error for my two Exchange 2013 STd - CU2 servers. Nothing is prevented from happening, but an extreme delay occurs before I get the information/configuration back from the other server.
nifdriftAuthor Commented:
I'm going to inquire Microsoft about this issue. Will come back with more information.
•Ensure that the remote computer is online.
•This problem may be the result of a firewall blocking the connection. For security, COM+ network access is not enabled by default.
•Check the system to determine whether the firewall is blocking the remote connection.

1. Disable Offload/SNP features from registry
Please backup system state before making any registry changes.
a. Disable RSS in the Registry by adding a DWORD registry key value for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableRSS and setting it to 0.
b. DisableTaskOffload in the Registry by adding a DWORD value for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableTaskOffload and set it to 1.

c. Disable TCPChimney in the Registry by adding a DWORD value for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPChimney and set it to 0.

d. Disable EnableTCPA in the Registry by adding a DWORD value for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA and set it to 0.

e. Configure HKLM\Software\Policies\Microsoft\Windows NT\Rpc\IgnoreDelegationFailure =1

2. Make the following changes on your physical NIC
Go to the NIC properties, click on advanced button, disable features that has the "Offload" or "RSS" wording in feature name.
For examples, below is some of the features commonly seen in NIC's advanced properties:
- IPv4 Checksum Offload

- IPv6 Checksum Offload

- IPv4 Large Send Offload

- IPv6 Large Send Offload

- Receive Side Scaling
Set registry key on both the servers and then reboot. if you experience the issue that trust relation between the domain is broken, then rejoin the server to the domian controller.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
nifdriftAuthor Commented:
We did everything except diabling Receive Side Scaling/RSS and now we dont get errors in the event log regarding DCOM.
Yep...this fixed my issues on my Exchange 2013 servers.
The big question I have, now that this issue is resolved for me, what did this error do or prevent from doing other than giving me a big red error in my event viewer? I still got the details I was requesting when communicating from one server to the other, but I don't know if something else was happening in the background that was creating true problems.
Correct me if I'm wrong but the solution really only masks the problem by disabling reporting of DCOM errors. I'm still looking for a way to "solve" the issue!
I had the same issue with a client's 2011 SBS, the System log showed Event 1009 every 30 minutes for two computers in the domain. It did not seem to affect anything but the log was full of these errors. While dealing with some other issues I found the solution, which was pretty simple. No reg hacks, no port changes.

The two computers showing in the logs had recently been upgraded to Windows 7. They were both wiped clean and then had Win 7 pro reinstalled from scratch, and then rejoined to the domain with new computer names. However, both still showed in AD under the old names as well as the new ones. My guess is they were not dis-joined from the domain before the upgrade. The new computer names showed in AD under SBS Computers, but the old names were still showing under the Computers OU.

In my case the answer was as simple as deleting the old computer names out of AD. The new names stayed put and the errors which were filling up the logs every half hour stopped completely.

Hope this helps someone...
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.