Event-Weiterleitung: Logs von mehreren Rechnern auf einem PC sammeln

    Eventlogs weiterleiten: Sammlungsinitiiert oder quellcomputerinitiiertAktiviert man beispiels­weise das Auditing für Active Directory oder NTFS, dann möchte man kritische Ereig­nisse nicht in der Ereignis­anzeige eines jeden einzelnen Servers suchen. Vielmehr kann man die Logs mehrerer Rechner auf einer Maschine zusammen­führen und dort auswerten.

    Das Konsolidieren von Events in einer Datenbank gehört zu den Standard-Features von fortgeschrittenen Tools für die Logfile-Analyse. Seit Vista und Server 2008 ist Windows dazu selbst in der Lage, auch wenn sich dann die Auswertung in der Ereignisanzeige auf die vorgegebene Ansichten und benutzerdefinierte Filter beschränkt.

    Vorbereitungen

    Bevor man die Events mehrerer Rechner an einen Computer weiterleitet, sollte man ungefähr einschätzen können, welches Datenvolumen man dadurch ungefähr bewegen wird. Dabei spielen die verfügbaren Bandbreiten des Netzwerks eine wesentliche Rolle. Daher ist es sinnvoll, auf einem Rechner die Logs solcher Geräte einzusammeln, die über eine leistungsfähige Verbindung miteinander kommunizieren.

    Außerdem ist darauf zu achten, dass der Zielrechner ein ausreichend dimensioniertes Logfile verwendet. Das für diesen Zweck vorgegebene Protokoll Weitergeleitete Ereignisse ist von Haus aus mit den üblichen 20 MB knapp bemessen. Diesen Wert kann man entweder über Gruppenrichtlinien ändern oder interaktiv in der Ereignisanzeige anpassen.

    Sammlungsinitiiert versus quellcomputerinitiiert

    Windows kennt zwei Formen der Event-Weiterleitung:

    • Der Collector (also der Zielrechner für die Ereignisse) ruft die Einträge von den Quellsystemen ab ("Sammlungsinitiiert"). Diese Variante eignet sich eher für eine kleinere Zahl an Rechnern und lässt sich vollständig in der Ereignisanzeige konfigurieren.
    • Die Source-Rechner übertragen ihre Events an den Collector ("Quellcomputerinitiiert"). In diesem Fall legt man per Gruppenrichtlinie fest, welche Computer ihre Ereignisse über ein bestehendes Abonnement auf einem Collector übertragen.

    Die folgende Anleitung beschreibt das Vorgehen für ein sammlungs­initiiertes Weiterleiten von Log-Einträgen.

    Vor dem Einrichten des ersten Abonnements muss der Sammeldienst für Events konfiguriert werden.

    Neues Abonnement erstellen

    Wenn man in der linken Navigationsleiste der Ereignisanzeige zum ersten Mal auf Abonnement klickt, dann bietet das Tool an, den Sammeldienst für Events zu starten und künftig auch nach einem Reboot auszuführen. Anschließend kann man daran gehen, über das Menü Aktion ein neues Abo einzurichten.

    Der Befehl zum Anlegen einer neuen Weiterleitung findet sich unter Aktion oder im Kontextmenü von Abonnements.

    Nach der Eingabe von Name und Beschreibung wählt man das Zielprotokoll aus, voreingestellt ist Weitergeleitete Ereignisse. Nun entscheidet man sich für die Option Sammlungsinitiiert und klickt auf die Schaltfläche Computer auswählen.

    WinRM testen und bei Bedarf aktivieren

    Im folgenden Dialog trägt man nicht nur die Rechner ein, von denen Events weitergeleitet werden sollen. Zusätzlich kann man hier gleich über den entsprechenden Button testen, ob WinRM eine Verbindung zu den Quellrechnern aufbauen kann.

    Nach der Auswahl der Quellsysteme kann man gleich testen, ob sich eine Verbindung über WinRM aufbauen lässt.

    Tritt dabei ein Fehler auf, dann muss man WinRM auf den betreffenden Computern konfigurieren. Bei nur wenigen Maschinen lässt sich das manuell über das Kommando­zeilen­programm winrm.exe erledigen, alternativ stehen dafür auch Gruppenrichtlinien zur Verfügung (siehe dazu: WinRM über GPOs konfigurieren und Firewall-Ausnahmen einrichten).

    Events filtern

    In den allermeisten Fällen wird man nicht sämtliche Events der Quellrechner auf dem Collector sammeln, sondern nur ausgewählte Ereignisse aus einzelnen Protokollen übernehmen. Daher öffnet man über den Button Ereignisse auswählen einen Dialog, mit dessen Hilfe man die Events filtern kann. Er ist identisch mit jenem, den man für das Erstellen benutzerdefinierter Ansichten verwendet.

    Die Filter für Abonnements entsprechen jenen in den benutzerdefinierten Ansichten.

    Zum Abschluss konfiguriert man noch die Einstellungen unter Erweitert. Sie bieten die Möglichkeit, anstelle des Computerkontos einen anderen Benutzer für den Abruf der Events festzulegen. Das ist normalerweise nicht nötig.

    In den erweiterten Abonnementeinstellungen kann man ein alternatives Konto und die Verbindung über HTTPS konfigurieren.

    Rechte für Collector auf Quell-PCs einräumen

    Belässt man es aber beim Computerkonto, dann muss man den Zielrechner auf allen Quellsystemen in die lokale Gruppe Ereignis­protokoll­leser aufnehmen. Verwendet man dafür die Computerverwaltung, dann aktiviert man im Dialog zum Hinzufügen von Objeten erst Computer als zusätzlichen Objekttyp, andernfalls schlägt die Suche fehl.

    Wenn sich der Collector über das Computerkonto verbindet, dann muss es auf den Quell-PCs in die Gruppe Ereignis­protokoll­leser.

    Nach dem Speichern des Abonnements kann man aus seinem Kontextmenü den Befehl Wiederholen ausführen, um eventuell auftretende Probleme zu erkennen.

    Unter Laufzeitstatus finden sich Hinweise auf eventuell auftretende Fehler.

    Ihre detaillierte Beschreibung findet sich dann unter Laufzeitstatus. Dort stehen typischerweise Meldungen zu WinRM-Verbindungsfehlern oder fehlenden Rechten des verwendeten Kontos (Code 0x5).

    2 Kommentare

    Bild von Christian
    Christian sagt:
    29. Juli 2015 - 13:21

    Hatte ich mir auch mal angesehen, war aber mit dem Ergebnis nicht so richtig zufrieden, weshalb ich mir jetzt mal "graylog" ansehe. Das ist ein Open-Source Serversystem auf Linux-Basis, welches man nutzen kann, um die unterschiedlichsten Logdateien oder Windows Eventlogs "einzusammeln". Es gibt zum ersten Anschauen auch eine virtuelle Appliance, die man auf graylog.org kostenlos laden kann ...
    Im Moment schiebe ich mittels "nxlog" alle wichtigen Events meiner Windows Server zu graylog, wo man dann z.B. definieren kann, dass bei Event xy eine Mail verschickt wird.
    Es gibt darüberhinaus noch etliche "Konnektoren", so dass man eine Vielzahl von Systemen damit überwachen kann -und das alles kostenlos und sehr flexibel verwaltbar.

    Bild von Wolfgang Sommergut
    29. Juli 2015 - 14:03

    Ich stimme zu, die Bordmittel von Windows für das Log-Management sind eher simpel gestrickt und stoßen schnell an ihre Grenzen. Daran ändert auch PowerShell nicht viel. Trotzdem wollte ich das eingebaute Event-Forwarding einfach mal beschreiben, für manche Ansprüche reichen sie ja wahrscheinlich. Und danke für den Hinweis auf Greylog!