Ereignisse auf allen Systemen fest im Griff
31. Januar 2012
Es gehört ohne Zweifel zu den Standardaufgaben der Administratoren, die Events auf den verschiedenen Server- und Client-Systemen regelmäßig zu überwachen – eine Aufgabe, die durch die Menge der Ereignisse nicht gerade erleichtert wird. Mit Hilfe des Features Event Forwarding and Collection können Systemverwalter diese Aufgabe leichter bewältigen. Jan de Clercq gibt Tipps zum Testen und hilft, wenn es um die Fehlerbereinigung dieser wichtigen Einrichtung geht.
Es ist nicht immer leicht für die Administratoren, die Ereignisse auf den vielen Systemen im eigenen Netzwerk unter Kontrolle zu bekommen. Natürlich muss ein Systembetreuer nicht jedes Event, das auf einem seiner Systeme auftaucht, einzeln untersuchen – aber der Überblick ist wichtig. Mit den aktuellen Windows-Systemen ab Windows Vista können die Systemverantwortlichen sogenannte Event Subcriptions (Ereignisabonnements) einsetzen.
Dabei werden Kopien der Ereignisse von anderen Remote-Systemen gesammelt und lokal abgespeichert. Mit dem Ereignisabonnement legt ein Systemadministrator dabei fest, welche Ereignisse gesammelt und in welchem Protokoll sie dann lokal gespeichert werden. Der Vorteil dieser Vorgehensweise: Sobald ein solches Abonnement aktiv ist und die Ereignisse gesammelt werden, können er diese weitergeleiteten Ereignisse wie lokal gespeicherte Ereignisse betrachten und auch bearbeiten.
Das Einrichten von Computern zum Weiterleiten und Sammeln von Ereignissen wird in einem Artikel auf dem TechNet von Microsoft gut beschrieben und erläutert.
Soweit die Theorie und soweit auch der normale Ablauf, wie ihn Microsoft beschreibt und vorgibt. Doch was sollen Systemprofis tun, wenn Fehler beim Event Forwarding auftauchen – oder wie stellt ein Systemverwalter überhaupt fest, ob dieses Feature seinen Wünschen und Vorstellungen entsprechend arbeitet? Zu diesem Zweck steht ein Kommandozeilen-Tool mit der Bezeichnung eventcreate.exe zur Verfügung. Dieses Werkzeug erlaubt es Administratoren ein selbsterstelltes Ereignis in einem bestimmten Ereignisprotokoll anzulegen. Das folgende Beispiel zeigt, wie ein Event mit der ID 100 im Anwendungsprotokoll (application log) auf einem Windows-System angelegt wird:
eventcreate /t error /id 100 /l application /d „Eigenes Event im Anwendungsprotokoll“
Wenn danach alle Komponenten für das Weiterleiten und Sammeln von Ereignissen richtig funktionieren und die Latenz-Zeiten des Netzwerks sich in einem normalen Maß befinden, sollte dieses Ereignis – das auf einem Remote-Computer erstellt wurde – innerhalb einer Zeitspanne von circa einer Minute beim Event Collector in den weitergeleitenden Ereignissen auftauchen.
Verschiedene Programme helfen bei der Fehlersuche
Was soll der Administrator tun, wenn dieses Ereignis dort aber wider Erwarten nicht auftaucht? In diesen Fällen empfehlen wir die Durchführung der folgenden einfachen Schritte zur Eingrenzung der Fehlerursache:
Der Administrator sollte sicherstellen, dass der Quell-Computer, auf dem dieses Ereignis erstellt wurde, auch mit den aktuellsten Einstellungen für die Gruppenrichtlinien-Objekte (GPO – Group Policy Objects) versorgt wurde.
Die Einstellung für die Weiterleitung der Ereignisse kann auf dem Quell-System so eingestellt werden, dass sie die GPO-Einstellung verwendet. Um sicherzustellen, dass die aktuellsten GPO-Einstellungen verwendet werden, kann das Ausbringen der GPO auf dem Quell-Computer durch den folgenden Befehl an der Kommandozeile sofort und direkt ausgelöst werden:
gpudate /force
In einem nächsten Schritt sollten Systemverwalter bei dieser Art der Fehlersuche überprüfen, ob der für die Weiterleitung notwendige Windows-Dienst auf dem Quell-System aktiv ist. Es handelt sich dabei um den Dienst mit der Bezeichnung Windows Remote Management (WinRM). Die Systembetreuer sollten sicherstellen, dass dieser Dienst auf den entsprechenden Systemen aktiv und standardmäßig konfiguriert ist. Dies kann aber ebenfalls sehr einfach direkt von der Kommandozeile aus passieren, wozu der folgende Befehl zum Einsatz kommen muss:
winrm quickconfig
Durch Aufruf dieses Kommandos wird der WinRM-Dienst so eingerichtet, dass er automatisch startet, ein WinRM-Listener wird ebenfalls eingerichtet und die entsprechende Ausnahme wird in der Windows-Firewall eingetragen. Danach sollten die Systemverantwortlich ebenfalls sicherstellen, dass der Event-Collector die verschiedenen Source-Systeme unter Einsatz von WinRM erreichen kann. Um dieser Bedingung zu genügen, kann auf dem sammelnden System den folgenden Aufruf zum Einsatz kommen:
winrm id -remote: <Name_Source_Computer> -auth: none
Wer Ereignis-Abonnements verwendet, die mittels eines Collectors ausgelöst werden (collector-initiated) sollte sich davon überzeugen, dass der Anwendername, der bei der Verbindung zum Source-System zum Einsatz kommt, auf diesem System auch Mitglied der Gruppe Ereignisprotokollleser (Event Log Readers) ist. Dabei handelt es sich um eine vordefinierte Gruppe auf den Windows-Systemen, deren Mitglieder die Ereignisprotokolle des lokalen Systems lesen dürfen.
Eine weitere Überprüfung gilt der Registrierung des Source-Systems beim sammelnden System: Ein Systemverwalter kann sich alle bei dem System zu diesem Zweck registrierten Computer mit dem folgenden Befehl schnell und einfach auflisten lassen:
wecutil gr <Name_des_Abonnements>
Schließlich sollten die Systemverwalter überprüfen, dass die Weiterleitung der Ereignisse nicht durch eine fehlerhafte Konfiguration der Windows-Firewall behindert werden kann. Sie sollten zu diesem Zweck nachschauen, ob die Windows Firewall so konfiguriert wurde, dass die Regeln für eingehenden Netzwerkverkehr die hereinkommen WinRM-Verbindungen „Windows Remote Management (HTTP-In)“ und „Windows Remote Management (HTTP-In)-Compatibility Mode“ auch wirklich die Firewall passieren dürfen.
Wer zudem ein Abonnement so konfiguriert hat, dass es das HTTPS-Protokoll verwendet, muss weiterhin darauf achten, dass er eine Firewall-Ausnahme-Regel für HTTPS auf dem Port 443 konfiguriert.
