Babble 11 Geschrieben 13. Mai 2013 Melden Teilen Geschrieben 13. Mai 2013 Hallo zusammen, auf unseren beiden physikalischen DCs (Server 2008R2, SP1, alle Updates) wird das Systemprotokoll im Sekundentakt mit Fehlern geflutet. Quelle: DistributedCOM, Event-ID 10009. Die Fehlermeldung lautet: DCOM konnte mit dem Computer "a.b.c.d" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen. Die IP-Adressen sind sowohl interne als auch externe IP-Adressen aus dem Internet. Der Fehler tritt schon seit mehreren Monaten auf, diverse Tipps von Google sind schon testet worden. Meistens geht es dabei um SBS 2008 oder um falsch konfigurierte DCOM-Komponenten, was in meinem Fall nicht wirklich zu passen scheint. In der letzten Woche habe ich einen der beiden DCs neu installieren müssen, der Fehler trat nach kurzer Zeit wieder auf. Es existieren noch vier weitere DCs, davon zwei mit Server 2008R2 SP1 als virtuelle Maschinen und zwei als Physik mit 2003 R2, die diese Fehler nicht protokollieren. Auf den betroffenen Systemen ist außer DNS, DHCP nur noch der Palo Alto Agent installiert, eine Deinstallation brachte auch keine Besserung, insbesondere da dieser Dienst auf den nicht betroffenen System auch installiert ist. Hat jemand 'ne Idee? LG, Babble. Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 13. Mai 2013 Melden Teilen Geschrieben 13. Mai 2013 Wieso und welche Verbindungen sind aus dem Internet möglich ? Ein DC sollte aus dem Internet überhaupt nicht erreichbar sein. Welches DCOM-Objekt (Object-ID9 kann nicht aktiviert werden ? Beschreiber Deine Systemumgebung näher. Was mach der DC sonst noch. Zitieren Link zu diesem Kommentar
Babble 11 Geschrieben 13. Mai 2013 Autor Melden Teilen Geschrieben 13. Mai 2013 Hallo Zahni, der DC initiiert die Anfragen, Die Anfragen kommen vom DC und laufen anscheinend gegen alle IP-Adressen, die er so kennt. Und da er auch DNS-Server ist, kennt er ziemliche viele IP-Adressen :). Der DC ist DNS-Server, DHCP-Server und natürlich DC. Sonst nix. LG, Babble. Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 13. Mai 2013 Melden Teilen Geschrieben 13. Mai 2013 Wenn der DCOM mit einer "externen" IP-Adresse keine Daten austauschen konnte, hat das eher nichts mit DNS zu tun. Nochmals die Frage welche DCOM-Komponente nicht mag (sollte im Eventlog stehen). Welche Adressen aus dem Internet sind denn betroffen ? Zitieren Link zu diesem Kommentar
Babble 11 Geschrieben 13. Mai 2013 Autor Melden Teilen Geschrieben 13. Mai 2013 Wenn der DCOM mit einer "externen" IP-Adresse keine Daten austauschen konnte, hat das eher nichts mit DNS zu tun. Das sehe ich auch so. Die Frage ist, warum er überhaupt mit allen ihm bekannten System irgendwelche Daten austauschen möchte. Nochmals die Frage welche DCOM-Komponente nicht mag (sollte im Eventlog stehen). Ich bin morgen wieder vor Ort und suche mal ob ich einen Hinweis auf eine Komponente finde, bisher war meine Suche erfolglos. Welche Adressen aus dem Internet sind denn betroffen ? Die Adressen sind unterschiedlich. Wie gesagt, er möchte mit internen und externen Adressen kommunizieren, alles was er so kennt. Ein zweiter DC produziert diesen Fehler ebenfalls, die restlichen DCs nicht. Ich tippte auf einen Treiber o.ä. und habe auch deshalb einen der betroffenen DCs schon neu installiert - allerdings nur mit der minimalsten Treiberausstattung, die möglich war. Trotzdem kam nach der Neuinstallation diese Fehlermeldung wieder... LG, Babble. Zitieren Link zu diesem Kommentar
Babble 11 Geschrieben 14. Mai 2013 Autor Melden Teilen Geschrieben 14. Mai 2013 Im Eventlog taucht nur der Fehler DistributedCOM, Ereignis-ID 10009 auf: DCOM konnte mit dem Computer "193.46.63.181" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen. Leider kein Hinweis auf eine bestimmte Komponente. Zitieren Link zu diesem Kommentar
Sunny61 772 Geschrieben 14. Mai 2013 Melden Teilen Geschrieben 14. Mai 2013 Im Eventlog taucht nur der Fehler DistributedCOM, Ereignis-ID 10009 auf: DCOM konnte mit dem Computer "193.46.63.181" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen. Ist der Computer "193.46.63.181" in dem Netz oder hat er etwas damit zu tun? Möglicherweise ist der DC nicht mehr in deiner Hand. Mit einer Rescue CD Offline scannen. Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 14. Mai 2013 Melden Teilen Geschrieben 14. Mai 2013 Die IP-Adresse gehört der Infoline Gmbh (ivwbox.de). Bekannt für Werbung/Tracking. Die Frage ist, was will DCOM von der Adresse. PS: Im Eventlog in der "Angezeigte Ansicht" findet man binäre Daten. Dort lässt sich eventuell die "zuständige" PID ablesen. Zitieren Link zu diesem Kommentar
Babble 11 Geschrieben 14. Mai 2013 Autor Melden Teilen Geschrieben 14. Mai 2013 Der DC ist sauber. Das Problem ist auch nur auf den beiden physikalischen 2008R2-DCs. Die virtuellen und die 2003R2-DCs haben das Problem nicht. Wenn man mit Procmon das ganze verfolgt, so kommt man zu svchost als verantwortlichem Prozess ( :() und dort zu OLE, welche den Key HKLM\SOFTWARE\Microsoft\OLE\ActivationFailureLoggingLevel abfragt. Diesen Schlüssel auf 2 (dword) schaltet das Logging für DCOM aus, so das das Systemprotokoll wieder lesbar wird. Ist zwar keine Lösung, aber immerhin ein Workaround... @Zahni: Die IP-Adresse war Zufall, ich habe einfach nur eine Zeile aus dem Systemprotokoll kopiert... Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 14. Mai 2013 Melden Teilen Geschrieben 14. Mai 2013 Du solltest Dich mit dem Problem aber beschäftigen und nicht ignorieren. Wir haben Dir doch nun div. Hinweise gegeben. Ein DC greift normalerweise nicht auf Server zu, die zum Tracken beim Surfen genutzt werden. Zitieren Link zu diesem Kommentar
Sunny61 772 Geschrieben 14. Mai 2013 Melden Teilen Geschrieben 14. Mai 2013 Der DC ist sauber. Das Problem ist auch nur auf den beiden physikalischen 2008R2-DCs. Die virtuellen und die 2003R2-DCs haben das Problem nicht. Wie hast Du festgestellt dass der DC sauber ist? Zitieren Link zu diesem Kommentar
Babble 11 Geschrieben 14. Mai 2013 Autor Melden Teilen Geschrieben 14. Mai 2013 Wie hast Du festgestellt dass der DC sauber ist? Nicht Der DC, sonder die DCs. Einer der beiden ist gerade frisch installiert. Beide Systeme protokolieren diesen Fehler seit Monaten. Er ist eigentlich nur nervig, da das Ereignisprotokoll zugemüllt wird. Ich habe derzeit keinen direkten Zugang zu den Servern, diese stehen im gesicherten RZ in abgeschlossenen Schränken. Um sicher zu gehen werde ich kurzfristig beide betroffenen Systeme mit einer entsprechenden CD prüfen. Ein DC greift normalerweise nicht auf Server zu, die zum Tracken beim Surfen genutzt werden. Bitte nicht an der IP festmachen! Diese war nur zufällig drin. Insgesamt sieht das so aus: Fehler 14.05.2013 11:11:10 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:07 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:06 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:06 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:06 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:05 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:04 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:04 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:03 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:03 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:02 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:02 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:01 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:01 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:00 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:00 DistributedCOM 10009 Keine Fehler 14.05.2013 11:11:00 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:58 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:57 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:57 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:54 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:54 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:52 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:52 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:51 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:51 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:50 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:49 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:49 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:48 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:48 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:48 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:46 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:44 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:43 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:39 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:39 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:39 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:37 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:37 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:36 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:35 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:35 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:34 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:33 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:31 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:30 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:28 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:28 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:27 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:27 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:26 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:25 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:25 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:23 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:23 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:22 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:22 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:22 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:21 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:20 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:20 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:20 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:19 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:18 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:17 DistributedCOM 10009 Keine Fehler 14.05.2013 11:10:17 DistributedCOM 10009 Keine wobei jede Zeile eine andere IP als Ziel hat, sowohl intern als auch externe Adressen. Ziele sind ThinClients, Drucker, Notebooks, PC etc. Das deaktivieren des Logging ist ein Workaround, damit die Chance besteht, wichtige Einträge zu lesen. Der Fehler ist damit nicht behoben. Und nein, der DC ist aus dem Internet nicht erreichbar. LG, Babble. Zitieren Link zu diesem Kommentar
jiri01 0 Geschrieben 29. Oktober 2014 Melden Teilen Geschrieben 29. Oktober 2014 Hi, sorry wenn ich die "Leiche" hier ausgrabe... ;)Hast Du das Problem fixen können? Ich habe genau das Selbe Problem auf 2 virtualisierten 2008er DCs. Bei uns werden allerdings nur interne IPs angesprochen...Server, Clients, Drucker und auch Smartphones. VGJiri01 Zitieren Link zu diesem Kommentar
jiri01 0 Geschrieben 7. Juli 2016 Melden Teilen Geschrieben 7. Juli 2016 Ich gebe mal ein Update...habe den Fehler lange ignoriert bzw. keine Zeit gehabt, mich darum zu kümmen. Jetzt bin ich es mal wieder angegangen und habe per procmon festgestellt, das es der User-ID Agent der Palo Alto Firewall ist. Sobald ich den ausschalte, hört die Spamerei im Systemlog sofort auf. Mal sehen, wie wir nun weiter vorgehen, immerhin ist der Übeltäter bei uns schon mal entlarvt. Zitieren Link zu diesem Kommentar
Babble 11 Geschrieben 8. Juli 2016 Autor Melden Teilen Geschrieben 8. Juli 2016 Hallo Jiri, Bingo. Der User-ID-Agent läuft bei uns auch. Welche Version hast Du installiert? Bei uns läuft noch die Version 4.1.5. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.