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

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.

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.

Any update? You have the logs.

>>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?

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.

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

Then check AD and you will probablly find the computer still exists in which you need to delete the object.

Seeing the same issue, and neither AD nor DNS has any trace of the system referenced in the error. Any thoughts on that?

same, system is gone, and not in AD/DNS, where else could a reference exist?

I also get the same error. I've looked exhaustively through AD and DNS, and have removed all references to the dead server. In my case, I've traced the DCOM requests to the Certificate Services Client scheduled task "SystemTask", which executes every 8 hours. It looks like everyone here is in essentially the same situation: a server died and a service on another server on the network is trying to contact it via DCOM. Somehow, the name of the dead server is hardcoded into the offending service. It'd be nice if someone from Microsoft could suggest a general way to remove the dead server name from such services. ~~Eugene

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

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

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.

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?

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

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.

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?

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.

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

Can someone please "unmark as answer" Mr. Zhang's above post? It clearly is not an answer/resolution/explanation!

I am receiving this error not even from a windows box but from a 3com switch. WTF Microsoft. Could someone post a fix pls.

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

Same here... My DNS servers are generating these events every often when trying to access external DNS forwardersMate

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

I don't think it's a config problem...unless three dozen Microsoft articles are also wrong.

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?

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

Hi Greg, Interesting - we also use Labtech - I'll send a ticket in... Edmund

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

This is in no way "answered" unless i Missed something.CPC Computers

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

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.

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??

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.

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

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

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!)

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?

Was wondering if there was any progress on this issue?

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

Yip. Same here.

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.

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.

Thanks BocalT helped me solve my Domain problems.

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