Dcom ошибка 10009

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’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 forwarders

Mate

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

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

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?

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. 

Thanks BocalT helped me solve my Domain problems.

All LabTech users try this:

Find the dctest.bat file in the windowsltsvc 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%system32dcdiag.exe %windir%system32dcdiag.exe /c /test:DNS /DnsBasic | findstr /I /C:»failed test» | findstr /I /V /C:»systemlog»
if exist %windir%system32dcdiag.exe goto :end
if exist %windir%ltsvcdcdiag.exe %windir%ltsvcdcdiag.exe  /c /test:DNS /DnsBasic | findstr /I /C:»failed test» | findstr /I /V /C:»systemlog»
if exist %windir%ltsvcdcdiag.exe goto :end
echo failed test Unable to find dcdiag.exe
:end

Also — edit the dctest.bat in LTShareTransferMonitors 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.

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.

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»

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

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.

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.

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

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

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,

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
!

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!