Tags: Remote-Verwaltung, Log-Management
Aktiviert man beispielsweise das Auditing für Active Directory oder NTFS, dann möchte man kritische Ereignisse nicht in der Ereignisanzeige eines jeden einzelnen Servers suchen. Vielmehr kann man die Logs mehrerer Rechner auf einer Maschine zusammenfü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 sammlungsinitiiertes Weiterleiten von Log-Einträgen.
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.
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.
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 Kommandozeilenprogramm 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.
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.
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 Ereignisprotokollleser 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.
Nach dem Speichern des Abonnements kann man aus seinem Kontextmenü den Befehl Wiederholen ausführen, um eventuell auftretende Probleme zu erkennen.
Ihre detaillierte Beschreibung findet sich dann unter Laufzeitstatus. Dort stehen typischerweise Meldungen zu WinRM-Verbindungsfehlern oder fehlenden Rechten des verwendeten Kontos (Code 0x5).
Täglich Know-how für IT-Pros mit unserem Newsletter
Ähnliche Beiträge
- Ereignisanzeige von Remote-Windows-PCs überwachen
- Sysinternal-Updates: PsExec 2.40, ProcMon 3.90, SigCheck 2.90, BgInfo 4.30
- PowerShell 7.3: JEA über SSH, Cmdlet für Setup, erweiterte ARM-Unterstützung
- Warnungen aus mehreren vCenter mit dem kostenlosen vSphere Alert Center zusammenführen
- Storage-Kapazität bei VMware vRealize Log Insight erhöhen
2 Kommentare
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.
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!