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

    Question

  • I get this message on a domain controller that i just put into production, running windows server 2008 r2, AD 2003.  This gets generated almost everytime i reboot the server.  It occurs 4 times in succession relating once to each of our external dns forwarders.  I have checked that DCOM uses tcp/ip.  I do not believe this to be impacting us significantly however i do prefer to know what this means and how to prevent it.
    Thanks
    Tuesday, January 26, 2010 4:40 PM

Answers

  • Hi,

     

    Thanks for the post.

     

    From your description, I understand that the Event error 10009 stating “DCOM was unable to communicate with the computer %1 using any of the configured protocols” is received on the new DC.

     

    There is a problem accessing the COM Service on a remote computer. To resolve this problem:

    • 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.
    • Other reasons for the problem might be found in the Extended Remote Procedure Call (RPC) Error information that is available in Event Viewer.

     

    For detailed information about the above steps, please refer to the following article:

     

    Event ID 10009 — COM Remote Service Availability

    http://technet.microsoft.com/en-us/library/cc774368(WS.10).aspx

     

    Does it work?

     

    If the problem continues, please collect the MPSReport from Windows Server 2008 R2.

     

    1. Download proper MPS Report tool from the website below.

     

    Microsoft Product Support Reports

    http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en

     

    2. Double-click to run it, if requirement is not met, please follow the wizard to download and install them. After that, click Next, when the "Select the diagnostics you want to run" page appears, select "General", “Internet and Networking”,“Server Components”, click Next.

     

    3. After collecting all log files, choose "Save the results", choose a folder to save <Computername>MPSReports.cab file.

     

    For your convenience, I have created a workspace for you.  You can upload the information files to the following link.  (Please choose "Send Files to Microsoft")

     

    Workspace URL: (https://sftasia.one.microsoft.com/choosetransfer.aspx?key=a7031c4a-e8ca-48cd-bb5d-7727e2967780)

    Password: #PAxwF2A+1xvy[zj

     

    Note: Due to differences in text formatting with various email clients, the workspace link above may appear to be broken.  Please be sure to include all text between '(' and ')' when typing or copying the workspace link into your browser.


    Thanks,

    Miles

    Wednesday, January 27, 2010 9:42 AM
    Moderator

All replies

  • Hi,

     

    Thanks for the post.

     

    From your description, I understand that the Event error 10009 stating “DCOM was unable to communicate with the computer %1 using any of the configured protocols” is received on the new DC.

     

    There is a problem accessing the COM Service on a remote computer. To resolve this problem:

    • 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.
    • Other reasons for the problem might be found in the Extended Remote Procedure Call (RPC) Error information that is available in Event Viewer.

     

    For detailed information about the above steps, please refer to the following article:

     

    Event ID 10009 — COM Remote Service Availability

    http://technet.microsoft.com/en-us/library/cc774368(WS.10).aspx

     

    Does it work?

     

    If the problem continues, please collect the MPSReport from Windows Server 2008 R2.

     

    1. Download proper MPS Report tool from the website below.

     

    Microsoft Product Support Reports

    http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en

     

    2. Double-click to run it, if requirement is not met, please follow the wizard to download and install them. After that, click Next, when the "Select the diagnostics you want to run" page appears, select "General", “Internet and Networking”,“Server Components”, click Next.

     

    3. After collecting all log files, choose "Save the results", choose a folder to save <Computername>MPSReports.cab file.

     

    For your convenience, I have created a workspace for you.  You can upload the information files to the following link.  (Please choose "Send Files to Microsoft")

     

    Workspace URL: (https://sftasia.one.microsoft.com/choosetransfer.aspx?key=a7031c4a-e8ca-48cd-bb5d-7727e2967780)

    Password: #PAxwF2A+1xvy[zj

     

    Note: Due to differences in text formatting with various email clients, the workspace link above may appear to be broken.  Please be sure to include all text between '(' and ')' when typing or copying the workspace link into your browser.


    Thanks,

    Miles

    Wednesday, January 27, 2010 9:42 AM
    Moderator
  • Hi,

     

    I just want to check if the information provided was helpful. If there is any update on this issue, please feel free to let me know.

     

    We are looking forward to your reply.

    Friday, January 29, 2010 9:15 AM
    Moderator
  • Miles,
    Thanks for the response.  I never received an email notifying me of response, until the second post.
    I gathered the logs, and now have them uploaded.

    Friday, January 29, 2010 3:29 PM
  • Any update?  You have the logs.
    Wednesday, February 03, 2010 2:26 PM
  • >>Ensure that the remote computer is online.

     

    what do you do if the reason is that the computer is not online because the computer does not exist on the network any more.

    how do you stop COM from looking for it?

Saturday, September 17, 2011 5:58 AM
  • Hi There, I have a similar issue as above. Our Primary DPM server is throwing up an error "DCOM unable to communicate with the computer xxxxx using any of the configured protocols" But the computer in question no longer exists! how can we stop DCOM from reporting this. The computer is also showing up under available members when modifying a protection group - is there any way removing references to this computer manually form DPM. Any help appriciated.
    Tuesday, September 20, 2011 9:42 AM
  • Hi,

     

    Thanks for the post.

     

    From your description, I understand that the Event error 10009 stating “DCOM was unable to communicate with the computer %1 using any of the configured protocols” is received on the new DC.

     

    There is a problem accessing the COM Service on a remote computer. To resolve this problem:

    • 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.
    • Other reasons for the problem might be found in the Extended Remote Procedure Call (RPC) Error information that is available in Event Viewer.

     

    For detailed information about the above steps, please refer to the following article:

     

    Event ID 10009 — COM Remote Service Availability

    http://technet.microsoft.com/en-us/library/cc774368(WS.10).aspx

     

    Does it work?

     

    If the problem continues, please collect the MPSReport from Windows Server 2008 R2.

     

    1. Download proper MPS Report tool from the website below.

     

    Microsoft Product Support Reports

    http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en

     

    2. Double-click to run it, if requirement is not met, please follow the wizard to download and install them. After that, click Next, when the "Select the diagnostics you want to run" page appears, select "General", “Internet and Networking”,“Server Components”, click Next.

     

    3. After collecting all log files, choose "Save the results", choose a folder to save <Computername>MPSReports.cab file.

     

    For your convenience, I have created a workspace for you.  You can upload the information files to the following link.  (Please choose "Send Files to Microsoft")

     

    Workspace URL: (https://sftasia.one.microsoft.com/choosetransfer.aspx?key=a7031c4a-e8ca-48cd-bb5d-7727e2967780)

    Password: #PAxwF2A+1xvy[zj

     

    Note: Due to differences in text formatting with various email clients, the workspace link above may appear to be broken.  Please be sure to include all text between '(' and ')' when typing or copying the workspace link into your browser.


    Thanks,

    Miles


    hi

    what do you mean "ensure computer is online"?

    i have the same issue, but again it is trying to dcom to external DNS servers (the DNS servers we have as forwarders in DNS where only dns queries are done).

    could you pls clarify why this access would be required?

    brgds

    Angelos

    Wednesday, September 28, 2011 2:01 PM
  • Then check AD and you will probablly find the computer still exists in which you need to delete the object.
    Thursday, October 20, 2011 1:00 PM
  • Seeing the same issue, and neither AD nor DNS has any trace of the system referenced in the error. Any thoughts on that?
    Saturday, October 29, 2011 6:42 AM
  • same, system is gone, and not in AD/DNS, where else could a reference exist?
    Wednesday, November 23, 2011 12:51 PM
  • I'm getting a whole bunch of these filling up my event log, historically we have had scavenging turned off (for some unknown reason). Have just turned this on; will keep all updated to see if these errors stop.

     

    JR

     

    Wednesday, December 07, 2011 3:04 PM
  • I'm on SBS 2011 that was migrated from SBS 2008. Old server gone (removed) and I'm getting DCOM errors in Event Log. Same boat as you guys, nothing in AD and DNS.
    I went to "Active Directory Administrative Center" and searched for offending server (changed scope to Global Catalog Search). Got two results. ADSI Edit and delete them.

    Now, wait and see.

     

    Dave

    Thursday, January 19, 2012 8:05 PM
  • I'm also having this issue, however it's for our ISP's DNS servers. They are both online and responding, but I'm not sure why DCOM would be attempting to contact external DNS servers.
    Thursday, February 09, 2012 1:42 AM
  • Holy Hannah! I'm not alone - ANYone find a way to stop my bleepin' SBS 2011 server from attempting DCOM connections to nonexistent (or, Linux) boxes?
    Monday, February 20, 2012 9:18 PM
  • I have the same problem here in our university environment.  The error logs are filling up on a number of computers.  One thing these all have in common is that they were ghostcast.  The DCOM error references the original name of the computer I gathered from.

    Windows XP SP3 boxes.  Anyone have any luck fixing this?

    Brad

    Wednesday, February 22, 2012 7:05 PM
  • That regedit proposed above really didn't do much, and perhaps made my situation worse, because now I have no idea which computers we're getting the DCOM errors:

    Description:

    The description for Event ID 10009 from source DCOM cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

    Wednesday, February 22, 2012 7:18 PM
  • I'm also having this issue, however it's for our ISP's DNS servers. They are both online and responding, but I'm not sure why DCOM would be attempting to contact external DNS servers.

    You are not alone.  I have at least one client server that is receiving DCOM 10009 errors, and the IP addresses are of the server's external DNS forwarders.  The server's DNS settings are fine, as are those of its NIC.

    Every search I've done points me to opening firewall settings for COM+ --the problem isn't the firewall settings (which I don't want to change), the problem is I don't want the DCOM behavior to be occurring in the first place.


    Everyone gets everything he wants. Me, I wanted to be a sysadmin. And for my sins --they made me one.


    • Edited by LoneWolf15 Thursday, February 23, 2012 4:01 PM
    Thursday, February 23, 2012 3:59 PM
  • I'm getting this problem on a MS SQL Server. I think it's trying to contact an old web server which has since been decommissioned and no longer exists. Did anyone find a solution to this problem?
    Tuesday, March 06, 2012 5:13 PM
  • I have the same problem here in our university environment.  The error logs are filling up on a number of computers.  One thing these all have in common is that they were ghostcast.  The DCOM error references the original name of the computer I gathered from.

    Windows XP SP3 boxes.  Anyone have any luck fixing this?

    Brad


    Exact same issue here!!   And I am unable to find an answer.    Anyone at MS able to help?   I have delted every printer, deleted every file/regkey etc that might possibly containg the orginal host name.   I have ran ghostwalker, NewSid,  etc.    Nothing has worked.
    Thursday, March 15, 2012 3:25 PM
  • I'm also having this issue, however it's for our ISP's DNS servers. They are both online and responding, but I'm not sure why DCOM would be attempting to contact external DNS servers.

    You are not alone.  I have at least one client server that is receiving DCOM 10009 errors, and the IP addresses are of the server's external DNS forwarders.  The server's DNS settings are fine, as are those of its NIC.

    Every search I've done points me to opening firewall settings for COM+ --the problem isn't the firewall settings (which I don't want to change), the problem is I don't want the DCOM behavior to be occurring in the first place.


    Everyone gets everything he wants. Me, I wanted to be a sysadmin. And for my sins --they made me one.



    I have the same issue...SBS2011 Essentials logging DCOM errors for all DNS forwarders
    Thursday, March 15, 2012 3:45 PM
  • Can someone please "unmark as answer" Mr. Zhang's above post? It clearly is not an answer/resolution/explanation!
    Thursday, March 15, 2012 4:46 PM
  • Hi, Miles--

    Not sure if you are still around at Microsoft, but there are major unanswered questions on this post.

    Why does DCOM continue to look for non-existent computers?  In our case, the computers are on foreign domains to which we connected briefly through their VPN.  Others question how to turn this off for particular nodes since those nodes are deleted from the Domain.

    If you could respond to these, we would be most grateful.

    Sincerely,

    Graeme


    • Edited by The Oracle Friday, April 27, 2012 10:15 AM
    Friday, April 27, 2012 10:12 AM
  • I replied to Mr. Zhang on our behalf.  If everyone votes the reply as Helpful, maybe we can get Mr. Zhang (or someone at Microsoft) to take notice.

    Graeme

    • Edited by The Oracle Friday, April 27, 2012 10:14 AM
    Friday, April 27, 2012 10:13 AM
  • I am receiving this error not even from a windows box but from a 3com switch.  WTF Microsoft.  Could someone post a fix pls.

    Thursday, May 03, 2012 1:35 PM
  • Similir issue here, the error is pointing to my linksys router (home lab) and Google DNS server 8.8.8.8. These errors are not allowing me to setup my Exchange lab.  arrrrgggghh.


    Ncruz1980

    Friday, May 04, 2012 7:19 PM
  • Same here... My DNS servers are generating these events every often when trying to access external DNS forwarders

    Mate

    Friday, May 04, 2012 7:42 PM
  • Is this one of those issues with no fix?

    There has to be a way to find where the dcom service lists the computers it tries to communicate with.


    CPC Computers

    • Proposed as answer by OTL-UPT Wednesday, May 23, 2012 1:06 AM
    • Unproposed as answer by OTL-UPT Wednesday, May 23, 2012 1:06 AM
    Saturday, May 12, 2012 1:23 PM
  • Same here.
    Server 2008 R2 DC. DCOM errors (Event ID 1009) because it can't create an RPC connection to my DNS forwarder (OpenDNS)!?!

    WTH is it trying to do that?!?


    • Edited by Alceryes Sunday, June 03, 2012 1:17 AM
    Sunday, June 03, 2012 1:12 AM
  • Just wanted to add that we're also seeing this at multiple clients. I've posted the below in the MS Partner Forums but was met with a complete lack of interest in the issue or any information that was of use:

    Problem: Multiple servers are throwing DCOM 10009 errors in the System Log stating that "DCOM was unable to communicate with the computer <EXTERNAL DNS FORWARDER> using any of the configured protocols."

    Notes:

    • The issue started occuring after May 13th 2012 when we patched our clients boxes.
    • One common factor appears to be that KB2676562 was installed to all the servers at this point. (EDIT: having seen that people were experiencing this prior to this patch update I now suspect that this is irrelevant)
    • The issue is affecting mulitple servers covering 2003, SBS2003, 2008 R2/SBS2011, all DC's, secondary DNS servers that are not DC's are not exhibiting the problem.
    • There is an entry per DNS Forwarder in the System logs, these DNS Forwarders vary per client but generally include Google (8.8.8.8, 8.8.4.4), OpenDNS (208.67.222.222, 208.67.220.220) and two from each clients ISP which vary.
    • It appears to be happening daily at approx 1490 minute (24hrs 50mins) intervals but one server is producing the errors far more frequently, every hour in two sets 10 minutes apart, this is a 2008 R2 box.
    • No other DNS errors or issues are encountered in the logs or on the networks.
    • Various people have also comment at the bottom of this thread. They appear to be experiencing the same issue.
      MS Article Link : http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/353d381d-0911-41c3-98fb-2475b65c32f6

    Any assistance appreciated in resolving.

    Additional: Extended info dump from one of the events on a SBS2011 server

    <Record#1: Computer=(null);Pid=144;6/5/2012 19:30:33:820;Status=1722;Gencomp=2;Detloc=1710;Flags=0;Params=1;{Param#0:0}>
    <Record#2: Computer=(null);Pid=144;6/5/2012 19:30:33:820;Status=1722;Gencomp=18;Detloc=1442;Flags=0;Params=1;{Param#0:8.8.8.8}>
    <Record#3: Computer=(null);Pid=144;6/5/2012 19:30:33:820;Status=1722;Gencomp=18;Detloc=323;Flags=0;Params=0;>
    <Record#4: Computer=(null);Pid=144;6/5/2012 19:30:33:820;Status=1237;Gencomp=18;Detloc=313;Flags=0;Params=0;>
    <Record#5: Computer=(null);Pid=144;6/5/2012 19:30:33:820;Status=10060;Gencomp=18;Detloc=311;Flags=0;Params=3;{Param#0:135}{Param#1:0}{Param#2:0x808080800000000}>
    <Record#6: Computer=(null);Pid=144;6/5/2012 19:30:33:820;Status=10060;Gencomp=18;Detloc=318;Flags=0;Params=0;>


    • Edited by Greg Steer Monday, June 11, 2012 5:17 PM
    Monday, June 11, 2012 5:07 PM
  • We're seeing the same error as Greg.  Servers on multiple customer sites are connecting via port 135 to the Google DNS servers (configures as our forwarders) - would be great to get this nailed?  Is it a configuration problem or a bug do you think?

    Edmund

    Thursday, June 21, 2012 11:53 AM
  • I don't think it's a config problem...unless three dozen Microsoft articles are also wrong.
    Thursday, June 21, 2012 8:52 PM
  • Because this thread has been marked as "answered", I feel we should start a new one (with obvious links to this one).

    Anyone else agree?

    Friday, June 22, 2012 2:15 PM
  • As an update to my post we've now tracked down the source of our issue.

    The offending article is our managed services software Labtech. It appears that the latest update must have introduced a monitor or script that is running on a regular basis that is causing these requests to happen at our clients sites, disabling it at one client last night knocked out the production of the errors.

    I'm following up with them to establish exactly which script/monitor is causing it and will report back, at least to let people know what mechanism is triggering it, in case there is something similar being run on your systems.

    Cheers

    Greg

    Friday, June 22, 2012 5:54 PM
  • Hi Greg,

    Interesting - we also use Labtech - I'll send a ticket in...

    Edmund

    Friday, June 22, 2012 6:14 PM
  • Nice find, Greg. We use LabTech too. I found this MS article(http://support.microsoft.com/kb/957713), but I am curious if you heard anything back from LT. Thanks for your persistence.

    -brad

    Solve IT

    Lakewood, CO

    Tuesday, June 26, 2012 4:28 PM
  • This is in no way "answered" unless i Missed something.

    CPC Computers

    Saturday, July 14, 2012 1:23 PM
  • I agree that this is not answered.  We also use LabTech like the last couple of people have mentioned.  We are getting the same error with DCOM trying to communicate with the external dns servers.  

    For us, it is only occurring on: 

    2008 R2 Enterprise x64
    2008 R2 Foundation x64
    2008 R2 Standard x64
    2011 SBS Standard x64

    but is not occurring on:

    2008 Standard Federation Edition
    2008 Standard (32 bit)
    Any 2003 server

    Monday, July 16, 2012 3:06 PM
  • Same "DCOM trying to communicate with ISP DNS / DNS Forwarders" here and running Labtech. LabTech mentioned this is not caused by their product and must be DNS related on our side.



    Tuesday, July 17, 2012 3:55 AM
  • We also have the same problem with the DCOM error message on our DNS and the IP referenced is the external DNS.  We are also a LabTech user.  If enough of us complain, maybe they will acknowledge this.

    Is anyone getting this exact symptom with external DNS IP on an internal DNS machine that is NOT on LabTech??

    Wednesday, July 18, 2012 1:03 PM
  • This is NOT a LabTech specific problem.
    I've got a Server 2008 R2 lab at home (domain controller, exchange, web, dev, etc...) and I do not use LabTech.

    Wednesday, July 18, 2012 4:20 PM
  • After digging in, I learned that LabTech is just running a DCDIAG script which triggers the event in the log.  It isn't the root cause of the issue, only the timing

    The specific command to reproduce is DCDIAG /TEST:DNS /DNSforwarders

    Wednesday, July 18, 2012 6:46 PM
  • This is the resolution provided by labtech

    I am including a resolution that I found on Microsoft's Support Page. This is actually a Microsoft Issue, but here is their resolution. 

    http://support.microsoft.com/kb/957713 
    2.1DCOM Event ID 10009: 
    Problem: The DCOM event ID 10009 will occur when a client workstation has a misconfigured firewall or other issues affecting its network communications within the domain. For example, if the workstation is not managed by an SBS GPO. In this scenario, the DCOM event ID 10009 will happen repeatedly, potentially hundreds per day. 

    Resolution: To attempt to resolve configuration issues with the firewall try the following: 
    * Make sure to allow remote management exception. Depending on your firewall solution this might be implemented or might require opening several ports. Unfortunately, this means opening common ports like TCP/135, TCP/139 but also a range of dynamic ports that cannot easily be defined and start at 1025. Check with your firewall manufacturer for the proper ways of allowing dynamic RPC traffic. 
    * If the workstation is on a different subnet than the SBS server and it is running Windows XP SP2 or higher, the firewall exceptions provided by the SBS group policies will not properly allow the required connectivity. You should edit the Client XP GPO and change the scope of the rules to allow subnet + the internal IP of the server. Follow the extra steps below to properly monitor XP SP2 (or higher) machines running in the SBS domain on different subnets than the SBS server, and prevent the DCOM event ID 10009 errors if that is the case. 

    1. Click Start, click Run, type GPMC.MSC, and click OK. 
    2. Click Continue on the UAC prompt. 
    3. Expand Forest: Domain.local, Domains, Domain.local and select Group Policy Objects. (Replace Domain.local with your domain) 
    4. Right-click the Windows SBS Client - Windows XP Policy and click Edit. 
    5. Expand Computer Configuration, Policies, Administrative Templates, Network, Network Connections, Windows Firewall, Domain Profile. 
    6. Find the IP Address of the server: Open a command prompt window (cmd.exe) from the Start menu. In the command prompt window type IPConfig and press return. Make note of the IPv4 address listed. 
    7. In the Group Policy Management Editor, double click Windows Firewall: Allow inbound file and printer sharing exception 
    a. In the text box labeled Allow unsolicited incoming messages from these IP addresses, add the IP (IPv4) of the server. For example, if the IP of the server is 192.168.1.2, the text box should read: localsubnet,192.168.1.2. 
    b. Click OK. 
    8. Repeat Steps 7.a and 7.b for the following rules: 
    Windows Firewall: Allow inbound remote administration exception 
    Windows Firewall: Allow inbound remote desktop exceptions 

    • Proposed as answer by alexpking Wednesday, July 18, 2012 9:13 PM
    Wednesday, July 18, 2012 9:12 PM
  • Not a solution, so please PLEASE don't close this thread.

    I realize this thread is lengthy, but the common complaints are:  attempted DCOM communications to either 1) servers that do not exist, or 2) servers with which we should NOT be having DCOM comms with (e.g. ISP DNS servers!)



    • Edited by BB8771 Wednesday, July 18, 2012 10:21 PM
    Wednesday, July 18, 2012 10:20 PM
  • Also having this problem, except with two Win 7 workstations that are active. We do not use LabTech, however, we do use Kaseya. Oddly enough, the two workstations in question are two where the Kaseya agent is not installed (it seems to have some problem installing).

    Why can't we simply get a solution that involves telling DCOM to ignore these machines?

    Thursday, July 19, 2012 3:35 PM
  • I'm also seeing the same dcom errors when N-Able is trying to connect to machines that are no longer on the network. I've removed them but will have to see if the 10009 errors clear up.

    I also ran the "dcdiag /test:dns /dnsforwarders" command at a couple clients. Both claim every test passed. One finished quickly and didn't log any errors, the other took 2-3 mins and logged 3 errors... 8.8.8.8 being one of them. The only difference between the 2 configurations that I see is that one has the 3 static DNS forwarders configured and the other is using just the Root Hints.

    Removing the forwarders from DNS seems to have cleared the errors when running the command from above, and the test runs much faster. Which makes sense because according to a couple Technet articles the forwarders actually have to time out before the root hints kick in, and if there's no forwarders configured then the /test:dns /dnsforwarders skips them. This article has some good info about Root hints and forwarders, http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/16c8211b-eaea-4c78-beea-435686056ff3/ and http://technet.microsoft.com/en-us/library/ff807391%28v=ws.10%29.aspx

    It looks like the issue is with what the actual "dcdiag /test:dns /dnsforwarders" command is designed to test and how it goes about it (http://technet.microsoft.com/en-us/library/cc776854%28v=ws.10%29.aspx). Your servers just don't have access to your ISP's or Google's DNS server through the DCOM protocols (probably due to the firewall restrictions mentioned earlier in this thread), where as if you run that command on a dns server forwarding to an internal DNS server that is then relaying all dns out through root hints or another forwarder you wont get any errors.

    In which case the Labtech script attempting to monitor the dns forwarders is whats actually at fault becuase its not using the dcdiag command as intended.

    I hope this helps everyone.

    -J


    • Proposed as answer by Jay Forster Tuesday, July 31, 2012 9:05 PM
    • Edited by Jay Forster Tuesday, July 31, 2012 9:09 PM added labtech comment
    Tuesday, July 31, 2012 9:05 PM
  • Yip.  Same here. 
    Tuesday, July 31, 2012 9:33 PM
  • I'm also seeing the same dcom errors when N-Able is trying to connect to machines that are no longer on the network. I've removed them but will have to see if the 10009 errors clear up.

    I also ran the "dcdiag /test:dns /dnsforwarders" command at a couple clients. Both claim every test passed. One finished quickly and didn't log any errors, the other took 2-3 mins and logged 3 errors... 8.8.8.8 being one of them. The only difference between the 2 configurations that I see is that one has the 3 static DNS forwarders configured and the other is using just the Root Hints.

    Removing the forwarders from DNS seems to have cleared the errors when running the command from above, and the test runs much faster. Which makes sense because according to a couple Technet articles the forwarders actually have to time out before the root hints kick in, and if there's no forwarders configured then the /test:dns /dnsforwarders skips them. This article has some good info about Root hints and forwarders, http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/16c8211b-eaea-4c78-beea-435686056ff3/ and http://technet.microsoft.com/en-us/library/ff807391%28v=ws.10%29.aspx

    It looks like the issue is with what the actual "dcdiag /test:dns /dnsforwarders" command is designed to test and how it goes about it (http://technet.microsoft.com/en-us/library/cc776854%28v=ws.10%29.aspx). Your servers just don't have access to your ISP's or Google's DNS server through the DCOM protocols (probably due to the firewall restrictions mentioned earlier in this thread), where as if you run that command on a dns server forwarding to an internal DNS server that is then relaying all dns out through root hints or another forwarder you wont get any errors.

    In which case the Labtech script attempting to monitor the dns forwarders is whats actually at fault becuase its not using the dcdiag command as intended.

    I hope this helps everyone.

    -J


    Tested this on one of the DNS servers and seems to have solved the issue. But we will not implement this solution, rather keep the DNS forwarders and just ignore these error messages in the eventlog. 
    Monday, August 06, 2012 1:58 AM
  • I have had a problem similar to this that had been driving me crazy for a long time; I eventually solved this by solving another error that I was also experiencing for the same non-existent server

    Event ID 13

    Certificate enrollment for Local system failed to enroll for a DomainController certificate with request ID N/A from servername.domain.com\abc CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722)).

    Event ID 10009

    DCOM was unable to communicate with the computer servername.domain.com using any of the configured protocols.

    By following Step 6: Remove CA objects from Active Directory in this article http://support.microsoft.com/kb/889250/en-us

    This solved my problem as I found the unknown server listed here, this might help someone.

    • Proposed as answer by Trade of Jacks Friday, February 08, 2013 4:41 PM
    Friday, August 10, 2012 11:03 AM
  • Thanks BocalT helped me solve my Domain problems.

    Wednesday, August 22, 2012 7:59 PM
  • All LabTech users try this:

    Find the dctest.bat file in the \windows\ltsvc folder on the server and edit it so that it only does the basic DNS tests and all others full tests:

    dcdiag.exe /c /test:DNS /DNSBasic

    e.g.

    @echo off
    if exist %windir%\system32\dcdiag.exe %windir%\system32\dcdiag.exe /c /test:DNS /DnsBasic | findstr /I /C:"failed test" | findstr /I /V /C:"systemlog"
    if exist %windir%\system32\dcdiag.exe goto :end
    if exist %windir%\ltsvc\dcdiag.exe %windir%\ltsvc\dcdiag.exe  /c /test:DNS /DnsBasic | findstr /I /C:"failed test" | findstr /I /V /C:"systemlog"
    if exist %windir%\ltsvc\dcdiag.exe goto :end
    echo failed test Unable to find dcdiag.exe
    :end

    Also - edit the dctest.bat in LTShare\Transfer\Monitors on the LabTech server for all future Agents to use

    This does not run all the full DNS tests, but should be fine - see http://technet.microsoft.com/en-us/library/cc731968(v=ws.10).aspx for more info

    • Proposed as answer by Broxigar1983 Tuesday, October 09, 2012 5:37 AM
    Tuesday, August 28, 2012 9:52 PM
  • All LabTech users try this:

    Find the dctest.bat file in the \windows\ltsvc folder on the server and edit it so that it only does the basic DNS tests and all others full tests:

    dcdiag.exe /c /test:DNS /DNSBasic

    e.g.

    @echo off
    if exist %windir%\system32\dcdiag.exe %windir%\system32\dcdiag.exe /c /test:DNS /DnsBasic | findstr /I /C:"failed test" | findstr /I /V /C:"systemlog"
    if exist %windir%\system32\dcdiag.exe goto :end
    if exist %windir%\ltsvc\dcdiag.exe %windir%\ltsvc\dcdiag.exe  /c /test:DNS /DnsBasic | findstr /I /C:"failed test" | findstr /I /V /C:"systemlog"
    if exist %windir%\ltsvc\dcdiag.exe goto :end
    echo failed test Unable to find dcdiag.exe
    :end

    Also - edit the dctest.bat in LTShare\Transfer\Monitors on the LabTech server for all future Agents to use

    This does not run all the full DNS tests, but should be fine - see http://technet.microsoft.com/en-us/library/cc731968(v=ws.10).aspx for more info

    Thanks Jez Nolan!!

    I have tested this on both of our DNS servers and all DCOM 10009 errors disappeared.


    Tuesday, October 09, 2012 5:39 AM
  • Hey All,

    I can verify that this fixes the issue with Labtech.  I found it only today after our LT backend server was crashing.  Well, this was due to an overwhelmingly high number of Event Logs being generated from Domain Controllers in our environment and for our clients.  Why were these logs being generated?  Because of Labtech running the DCDIAG tests and associated "fix" script pretty much continuously.  So, a Microsoft bug is found by Labtech, only to have Labtech recursively spread the bug to the point it crashes itself...awesome.  Anyway, the fix above works, whether  you're a Labtech customer or not.

    Tuesday, December 11, 2012 10:40 PM
  • Long time and no response from me I know as I originally posted it being related to LabTech.

    The fix from Jez above was also the one we ended up using.

    The reason it happens is that the full DNS Diagnostics are running queries that are specific to MS AD DNS servers, if these are run against a non-MS DNS server then no response is received and these errors are thrown.

    Quoting a LabTech Tech's response:

    "Greg, This issue is due to the labtech service running a DC Diag to ensure your AD environment is healthy and following MSFT's best practices. The DC DIAG tool will write the DCOM errors to the event log. The reason that these are valid is that the systems should only contain AD DNS servers per MSFT best practices. LabTech follows these best practices and will alert you when you are not following them. At this time, there are two options. Disable the Master Script Run 2008 R2 Best Practice Report from the group: Service Plans. Windows Servers.Server Roles.Windows Servers Core Services.Domain Controllers or remove the DNS entries of non-AD DNS servers. Kevin"

    Wednesday, January 02, 2013 10:57 PM
  • Is there a way to modify this batch file so it is pushed out to the DCs again from LabTech?  Or do we need to modify this batch file manually on all DCs (ugh)...
    Friday, January 04, 2013 6:27 AM
  • IIRC Labtech's answer was "no it won't be pushed".

    But you could knock up a script in LT to do the file copy and run it against the Service Plans -> Windows Servers -> Server Roles -> Windows Servers Core Services -> Domain Controllers group.

    Wednesday, January 16, 2013 7:34 PM
  • This link helped me.  I was getting the DCOM 10009 error for a SBS 2003 server I had removed from the domain during a migration to SBS 2011.  The SBS2003 server was configured as a Certification Authority, and as a result there will still left over entries in AD for the server.  This link helped me find and delete them.
    Friday, February 08, 2013 4:46 PM
  • Hi there. I've seen this issue on mainly our SBS 2008 / 2012 installations

    Beleive it or not it is by design, as for whatever reason Microsoft decided that using root hints instead of forwarders for SBS server was a good idea

    Its a relatively simply fix, remove all of your DNS forwarder addresses from the DNS server - then add the FQDN and the IP address of your forwarders to the root hint list

    Friday, February 15, 2013 3:55 AM
  • TechieBuff,

    Can you clarify something for me? We use OpenDNS servers as forwarders on all of our servers and have for sometime. If we remove them from the DNS forwarders and add them to the root hint list, do we need to remove all of the other root hint addresses in order to be certain that our external traffic is only going to those DNS servers? Will we run into any other issues by removing the other root hint servers?

    Thanks.


    Michael Kanet ITernal Networks

    Friday, March 15, 2013 12:56 AM
  • This is not limited to SBS. I am running server 2008 R2.
    • Proposed as answer by Skip47025B Wednesday, March 20, 2013 4:32 PM
    • Unproposed as answer by Skip47025B Wednesday, March 20, 2013 4:32 PM
    Friday, March 15, 2013 7:05 PM
  • I am also having this problem. I have searched and searched and cannot find the answer.

    The server DCOM is trying to communicate with is dead and gone. It is no longer in AD or DNS or DHCP records. I cannot find a thing on the server that should make it want to communicate with this dead and gone server.

    I am running windows Server 2008 R2 and have never used LabTech.

    Please help.

    Thanks,


    • Edited by Skip47025B Wednesday, March 20, 2013 4:36 PM
    Wednesday, March 20, 2013 4:35 PM
  • Anyone figure this out yet?

    Having the same problem here, The server that DCOM is trying to communicate with has been removed from the domain and pulled out of the rack. We are getting this error every 10 minutes. I also have never used LabTech.

    Thanks,

    Thursday, March 28, 2013 4:37 PM
  • Hi,

     

    Thanks for the post.

     

    From your description, I understand that the Event error 10009 stating “DCOM was unable to communicate with the computer %1 using any of the configured protocols” is received on the new DC.

     

    There is a problem accessing the COM Service on a remote computer. To resolve this problem:

    • Ensure that the remote computer is online.
    • (remainder left out)

    From my side I can add that the same error is also occurring in mass on our SCCM 2007 server.
    I see not only machines that are no longer existing, but most often : machines that were not available/online at the point in time the job was running !!
    The (portable) machine may have just been switched off, or the owner may be on the road at the given moment. Or not connected through VPN onto the local network.

    Nevertheless, the eventlog is flooded with this type of messages. And because of those, our monitoring system is indicating full red alerts for a reason of no relevance !  We really would like to find a way to disable the generating of these messages !

    Wednesday, April 03, 2013 11:31 AM
  • Here is one solution that worked for me

    http://community.spiceworks.com/topic/288546-dcom-was-unable-to-communicate-with-the-computer-64-99-64-32

    For reference in case link breaks.

    We see this sometimes if your DNS server isn't resolving your domain right -- sometimes it's because you have a .com as part of your local domain. For example, Spiceworks will try to query localhost, but your DNS server returns the results for localhost.com.

    Go to the hosts file on the Spiceworks server and uncomment the IPV4 localhost entry, but leaving the IPV6 entry commented out. You'll need to restart your computer after you save the changes, but it should be good to go afterwards!

    Thursday, May 16, 2013 9:55 AM