KomuraSoft LLC
Kontakt
Menü

Ereignisprotokolle mit Get-WinEvent praxisnah untersuchen — Die Geschwindigkeit der Filterung entscheidet über die Dauer der Untersuchung

· · PowerShell, Windows, Ereignisprotokoll, Fehleruntersuchung, Betriebsoptimierung, IT-Systeme, Auditierung, Troubleshooting

„Es sieht so aus, als hätte sich der Server am späten Freitagabend von selbst neu gestartet.“ „Die Fachanwendung stürzt ein paar Mal im Monat ab, aber nur auf einem bestimmten Rechner.“ — Untersuchungen wie diese beginnen fast immer beim Windows-Ereignisprotokoll. Scrollen Sie sich jedoch in der grafischen Oberfläche der Ereignisanzeige durch mehrere Hunderttausend Einträge, ist der ganze Vormittag dahin.

Mit PowerShells Get-WinEvent dauert dieselbe Arbeit Sekunden bis wenige zehn Sekunden. Es gibt allerdings eine Bedingung: Sie müssen an der richtigen Stelle filtern. Schreiben Sie Get-WinEvent | Where-Object { ... }, laden Sie zunächst jedes Ereignis, um es anschließend zu verwerfen — das kann sogar langsamer sein als die grafische Oberfläche.

Dieser Artikel behandelt die korrekte Verwendung der Filterung von Get-WinEvent, Rezepte für die in der Praxis am häufigsten anfallenden Untersuchungen (unerwartete Neustarts, Anmeldungen, Anwendungsabstürze, Dienstunterbrechungen) sowie das Sammeln von mehreren Rechnern.

1. Das Wichtigste zuerst

  • Verwenden Sie Get-WinEvent, nicht Get-EventLog. Letzteres steht nur unter Windows PowerShell zur Verfügung und kann nur klassische Protokolle verarbeiten; in PowerShell 7 ist es nicht verfügbar.1
  • Filtern Sie mit -FilterHashtable. Da die Filterung auf Seiten des Ereignisprotokolls erfolgt, ist dies um Größenordnungen schneller als eine nachträgliche Eingrenzung mit Where-Object.2
  • Die Schlüssel für -FilterHashtable sind fest vorgegeben. Dazu zählen LogName, ProviderName, ID, Level, StartTime, EndTime, Keywords, Path, UserID und weitere.2
  • Für komplexe Bedingungen oder die Filterung nach Ereignisdaten verwenden Sie XPath (-FilterXPath). Sie können den XPath-Ausdruck aus einer benutzerdefinierten Ansicht in der Ereignisanzeige kopieren.1
  • Level ist ein numerischer Wert. 1 = Kritisch, 2 = Fehler, 3 = Warnung, 4 = Information, 5 = Ausführlich.3
  • Das Lesen des Security-Protokolls erfordert besondere Berechtigungen. Die Ausführung als Administrator ist der schnelle Weg; untersuchenden Personen lesenden Zugriff über die Gruppe Event Log Readers oder eine Kanal-ACL zu gewähren, entspricht eher dem Prinzip der geringsten Rechte.14
  • Betrachten Sie die Ereignisdaten, nicht die Meldungszeichenkette. Das Abrufen der strukturierten Daten mit ToXml() liefert ein Skript, das nicht von den Spracheinstellungen des Betriebssystems abhängt.1
  • Sie können auch .evtx-Dateien analysieren. Geben Sie -Path an, um vor Ort erfasste Protokolle von Ihrem eigenen Rechner aus zu untersuchen.1
  • Für eine dauerhafte Zusammenführung verwenden Sie Windows Event Forwarding (WEF). Für eine einmalige Untersuchung genügt die parallele Ausführung über Invoke-Command.5

2. Zwei Arten von Protokollen und die Wahl des Cmdlets

Windows-Ereignisprotokolle lassen sich grob in zwei Familien einteilen.

Art Beispiele Cmdlets, die sie lesen können
Klassische Protokolle System / Application / Security Get-EventLog (nur 5.1) und Get-WinEvent
Anwendungs- und Dienstprotokolle Microsoft-Windows-TaskScheduler/Operational und weitere nur Get-WinEvent

Gerade Letztere enthalten die für Untersuchungen nützlichen Informationen. Der Ausführungsverlauf der Aufgabenplanung, das Script Block Logging von PowerShell, der Installationsverlauf von Windows Update — die meisten der für eine Untersuchung entscheidenden Protokolle liegen hier. Deshalb ist es richtig, sich bei ab jetzt geschriebenen Skripten auf Get-WinEvent festzulegen.1

Prüfen Sie zunächst, welche Protokolle vorhanden sind.

# Protokolle auflisten (die mit den meisten Einträgen zuerst). Ein Protokoll mit RecordCount 0 zeichnet nicht auf
Get-WinEvent -ListLog * -ErrorAction SilentlyContinue |
    Where-Object RecordCount -gt 0 |
    Sort-Object RecordCount -Descending |
    Select-Object LogName, RecordCount, MaximumSizeInBytes, IsEnabled -First 20

# Protokolle für ein bestimmtes Produkt finden
Get-WinEvent -ListLog *TaskScheduler* | Format-Table LogName, IsEnabled, RecordCount
Get-WinEvent -ListProvider *PowerShell* | Select-Object Name

3. Bei der Filterung entscheidet „Wo“

Vergleichen Sie drei Wege, um dasselbe Ergebnis zu erhalten.

# [Am schlechtesten] Alles lesen, dann auf der PowerShell-Seite verwerfen
Get-WinEvent -LogName System | Where-Object { $_.Id -eq 41 }

# [Empfohlen] Auf Seiten des Ereignisprotokolls filtern (FilterHashtable)
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ID = 41 }

# [Komplexe Bedingungen] Mit XPath filtern
Get-WinEvent -LogName System -FilterXPath "*[System[EventID=41]]"

Bei der ersten Variante werden alle mehreren Hunderttausend Ereignisse zunächst in Objekte umgewandelt, um sie anschließend zu verwerfen — der größte Teil der Wartezeit ist damit verschwendet. Die zweite und dritte Variante filtern auf Seiten der Ereignisprotokoll-API, sodass nur das Benötigte zurückkommt.2

Die mit -FilterHashtable verwendbaren Schlüssel sind fest vorgegeben.2

Schlüssel Was er angibt Beispiel
LogName Der Protokollname 'System', 'Microsoft-Windows-TaskScheduler/Operational'
ProviderName Die Quelle des Ereignisses 'Application Error', 'Service Control Manager'
ID Die Ereignis-ID (Arrays erlaubt) 41, @(1000, 1001)
Level Schweregrad (numerisch) 2 (Fehler), @(1,2)
StartTime / EndTime Der Zeitraum (Get-Date).AddDays(-7)
Keywords Schlüsselwörter (Audit-Erfolg/-Fehlschlag und Ähnliches) 9007199254740992 (Audit-Erfolg)
Path Eine .evtx-Datei 'D:\collect\srv01_System.evtx'
UserID Eine Benutzer-SID 'S-1-5-21-...'

Die numerischen Werte für Level sind wie folgt.3

Wert Bedeutung
1 Kritisch
2 Fehler
3 Warnung
4 Information
5 Ausführlich

In praktischer Form sieht das so aus.

# Fehler- und kritische Ereignisse der letzten 7 Tage nach Quelle zusammenfassen (der erste Schritt zur Einordnung einer Situation)
$filter = @{
    LogName   = 'System', 'Application'
    Level     = 1, 2
    StartTime = (Get-Date).AddDays(-7)
}
try {
    Get-WinEvent -FilterHashtable $filter -ErrorAction Stop |
        Group-Object ProviderName, Id |
        Sort-Object Count -Descending |
        Select-Object Count, Name -First 15
}
catch {
    # Nur "keine passenden Ereignisse" stillschweigend abfangen. Dies ist unabhängig
    # von der Spracheinstellung, weil wir FullyQualifiedErrorId prüfen (die
    # Meldungszeichenkette würde in einer deutschsprachigen Umgebung nicht passen)
    if ($_.FullyQualifiedErrorId -notlike 'NoMatchingEventsFound*') { throw }
}

Gibt es überhaupt keine passenden Ereignisse, löst Get-WinEvent einen Fehler aus. Hängen Sie hier nicht unbedacht -ErrorAction SilentlyContinue an. „Keine Treffer“, „Sie haben keine Berechtigung, dieses Protokoll zu lesen“ und „das Ziel ist nicht erreichbar“ fallen sonst alle zu demselben leeren Ergebnis zusammen. Während einer Untersuchung ist das die problematischste Art zu scheitern.

Die richtige Lösung besteht darin, den Fehler wie oben mit -ErrorAction Stop abzufangen und ihn nur dann zu verschlucken, wenn FullyQualifiedErrorId gleich NoMatchingEventsFound ist. Eine Prüfung auf die Meldungszeichenkette funktioniert nicht, da sie in einer deutschsprachigen Umgebung nicht passt (zu den Überlegungen hinter der Fehlerbehandlung siehe „PowerShell-Fehlerbehandlung und Retry-Design“).

4. Untersuchungsrezepte, die Sie ständig brauchen werden

(1) Unerwartete Neustarts und Herunterfahrvorgänge

# 41:   Neustart ohne sauberes Herunterfahren (Kernel-Power)
# 6008: unerwartetes Herunterfahren (EventLog)
# 1074: Herunterfahren durch einen Prozess/Benutzer angefordert (wer oder was es ausgelöst hat)
# 6005/6006: Ereignisprotokolldienst gestartet/gestoppt (= Marker für Start/Herunterfahren)
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    ID        = 41, 1074, 6005, 6006, 6008
    StartTime = (Get-Date).AddDays(-30)
} | Select-Object TimeCreated, Id, ProviderName,
      @{ n = 'Message'; e = { ($_.Message -split "`r?`n")[0] } } |
    Sort-Object TimeCreated -Descending | Format-Table -AutoSize

1074 ist das entscheidende Ereignis, weil es angibt, wer den Neustart angefordert hat. Taucht dort WindowsUpdate oder ein bestimmter Prozessname auf, ist die Ursache so gut wie geklärt. Sehen Sie dagegen nur 41 und 6008 aufeinanderfolgen, ohne dass 1074 dazwischen auftaucht, liegt der Verdacht auf einem anormalen Abbruch durch Stromausfall oder ein Hängenbleiben nahe.

(2) Anmeldungen und Abmeldungen nachverfolgen (Security-Protokoll)

# 4624: Anmeldung erfolgreich / 4625: Anmeldung fehlgeschlagen / 4634: Abmeldung
# Erfordert Berechtigung zum Lesen des Security-Protokolls (als Administrator ausführen
# oder das ausführende Konto vorab zur Gruppe Event Log Readers hinzufügen)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    ID        = 4624, 4625, 4634
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $d   = @{}
    foreach ($n in $xml.Event.EventData.Data) { $d[$n.Name] = $n.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Kind      = switch ($_.Id) { 4624 { 'Anmeldung erfolgreich' } 4625 { 'Anmeldung fehlgeschlagen' } 4634 { 'Abmeldung' } }
        User      = $d['TargetUserName']
        LogonKind = $d['LogonType']    # 2=interaktiv 3=Netzwerk 10=RDP
        Source    = $d['IpAddress']
    }
} | Where-Object User -notlike '*$' | Format-Table -AutoSize

Das ist der Musterfall für die Verwendung von Ereignisdaten. Die Message-Eigenschaft mit einem regulären Ausdruck zu zerlegen hängt von den Spracheinstellungen des Betriebssystems ab, während sich die EventData aus ToXml() namentlich referenzieren lässt — dasselbe Skript läuft also gleichermaßen in einer deutschsprachigen wie in einer englischsprachigen Umgebung.6

Bedenken Sie außerdem: Ist die Überwachung nicht aktiviert, wird gar kein Ereignis aufgezeichnet. „Es taucht nichts auf“ kann bedeuten, dass „nichts aufgezeichnet wurde“, statt dass „nichts passiert ist“.

(3) Anwendungsabstürze

# 1000: Application Error (ein Anwendungsabsturz)
# 1026: .NET Runtime (Beendigung durch eine verwaltete Ausnahme)
# 1001: Windows Error Reporting (Fault-Bucket-Informationen)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    ID        = 1000, 1001, 1026
    StartTime = (Get-Date).AddDays(-14)
} | Select-Object TimeCreated, Id, ProviderName, Message |
    Sort-Object TimeCreated -Descending | Format-List

1000 liefert den Namen des fehlerhaften Moduls und den Offset, 1026 den .NET-Ausnahme-Stack. Sich hier zu orientieren, bevor Sie zur Dump-Analyse übergehen, ist der effiziente Weg (siehe „Eine Einführung in das Sammeln von Windows-Absturz-Dumps“ und „Absturz-Dumps mit WinDbg + SOS lesen“).

(4) Dienste, die stoppen und neu starten

# 7034: ein Dienst wurde unerwartet beendet / 7031: Wiederherstellungsaktion nach Beendigung / 7045: ein neuer Dienst wurde installiert
Get-WinEvent -FilterHashtable @{
    LogName     = 'System'
    ProviderName = 'Service Control Manager'
    ID          = 7031, 7034, 7045
    StartTime   = (Get-Date).AddDays(-30)
} | Select-Object TimeCreated, Id, Message | Format-List

7045 (ein neuer Dienst wurde installiert) ist auch nützlich, um die Installation nicht beabsichtigter Software zu erkennen. Zum betrieblichen Design von Windows-Diensten siehe „Windows-Dienste erstellen und betreiben“.

(5) Ausführungsverlauf der Aufgabenplanung

# [Schlecht] Alles abrufen und dann nach der Anzeigemeldung filtern (sprachabhängig)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-TaskScheduler/Operational'
    StartTime = (Get-Date).AddDays(-3)
} -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -like '*NightlyAggregation*' }

# [Gut] Serverseitig nach dem Aufgabennamen (Ereignisdaten) filtern. Schnell und sprachunabhängig
$xpath = @"
*[System[TimeCreated[timediff(@SystemTime) <= 259200000]]]
and
*[EventData[Data[@Name='TaskName']='\NightlyAggregation']]
"@
Get-WinEvent -LogName 'Microsoft-Windows-TaskScheduler/Operational' `
             -FilterXPath $xpath -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

timediff ist eine XPath-Funktion, die „verstrichene Zeit seit jetzt“ in Millisekunden angibt, und 259200000 entspricht drei Tagen. Geben Sie den Aufgabennamen als den vollständigen Pfad an, unter dem er registriert wurde (\TaskName, wenn er direkt unter der Wurzel liegt). Die auf die Anzeige ausgerichtete Message hängt von den Spracheinstellungen ab, und die Filterung darauf erfolgt clientseitig — filtern Sie deshalb, wie in diesem Artikel empfohlen, nach den Ereignisdaten.

Dieses Protokoll ist in manchen Fällen standardmäßig deaktiviert. Wie Sie es aktivieren und wie Sie die Ursache eingrenzen, wenn eine Aufgabe nicht läuft, behandelt „Wenn Aufgaben der Aufgabenplanung nicht laufen oder mit 0x1 enden“.

5. Protokolle auf mehreren oder anderen Rechnern untersuchen

Ansatz 1: direkt remote lesen

Get-WinEvent -ComputerName 'srv01' -FilterHashtable @{ LogName='System'; ID=41 } -MaxEvents 10

Ansatz 2: parallel mit Invoke-Command abfragen (bei vielen Rechnern verwenden)

$servers = 'srv01', 'srv02', 'srv03'
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-WinEvent -FilterHashtable @{
        LogName = 'System'; Level = 1, 2; StartTime = (Get-Date).AddDays(-1)
    } -ErrorAction SilentlyContinue |
        Select-Object TimeCreated, Id, ProviderName, LevelDisplayName
} | Sort-Object PSComputerName, TimeCreated

Invoke-Command läuft parallel gegen mehrere Rechner (siehe „Eine Einführung in PowerShell Remoting (WinRM)“ und „Parallele Verarbeitung in PowerShell“).

Ansatz 3: .evtx-Dateien sammeln und lokal analysieren

Eine vor Ort exportierte Datei können Sie direkt einlesen. Das ist schneller als wiederholte Abfragen über das Netzwerk und bleibt zudem als Nachweis erhalten.

# Vor Ort: wevtutil epl System D:\collect\srv01_System.evtx
Get-WinEvent -Path 'D:\collect\srv01_System.evtx' -FilterXPath "*[System[(Level=1 or Level=2)]]" |
    Select-Object TimeCreated, Id, ProviderName, Message

Ansatz 4: Windows Event Forwarding (WEF) — das ist die Lösung für eine dauerhafte Zusammenführung. Es handelt sich um eine Standardfunktion, die Ereignisse von jedem Rechner an einen Sammelserver weiterleitet, ohne dass ein zusätzlicher Agent installiert werden muss.5

6. Protokollgröße und Aufbewahrung

„Ich wollte den Zeitraum untersuchen, aber das Protokoll dafür war schon überschrieben“ ist ein sehr häufiger Fehlschlag. Die standardmäßige Maximalgröße ist eher klein bemessen, und in stark ausgelasteten Umgebungen läuft sie innerhalb weniger Tage über.

# Aktuelle Größeneinstellungen und Aufbewahrungsstatus prüfen
Get-WinEvent -ListLog 'System', 'Application', 'Security' |
    Select-Object LogName, IsEnabled, LogMode,
        @{ n='MaxMB'; e={ [math]::Round($_.MaximumSizeInBytes / 1MB, 1) } },
        RecordCount, OldestRecordNumber

# Maximalgröße ändern (erfordert Administratorrechte. Beispiel: System-Protokoll auf 256 MB)
wevtutil sl System /ms:268435456

Auf Servern, bei denen mit einer Untersuchung zu rechnen ist, und auf Rechnern, die gerade von Störungen betroffen sind, ist es die Standardvorgehensweise, zunächst die Protokollgröße zu erhöhen und dann auf eine Reproduktion zu warten. Zur Generationenverwaltung und automatischen Archivierung von Protokollen siehe auch „PowerShell-Skripte in der Praxis — Protokolluntersuchung, Archivierung und Reporting“.

7. Praktische Faustregeln (Entscheidungstabelle)

Situation Wahl Anmerkungen
Ab jetzt geschriebene Skripte Get-WinEvent Get-EventLog gilt nur für 5.1 und nur klassische Protokolle1
Filterung nach Protokollname, ID und Zeitraum -FilterHashtable Am schnellsten und am besten lesbar2
Filterung nach dem Inhalt der Ereignisdaten -FilterXPath / -FilterXml Lässt sich aus einer benutzerdefinierten Ansicht in der Ereignisanzeige kopieren1
Zu viele Einträge, dauert zu lange Zeitraum einschränken, -MaxEvents verwenden Filterung nicht auf der PowerShell-Seite vornehmen
Wert aus einer Meldung extrahieren EventData aus ToXml() Liefert ein von den Spracheinstellungen unabhängiges Skript1
Einmalige Untersuchung über mehrere Rechner Invoke-Command Läuft parallel5
Dauerhafte Zusammenführung Windows Event Forwarding (WEF) Standardfunktion ohne zusätzlichen Agent5
Ältere Protokolle sind nicht mehr vorhanden Protokollgröße erhöhen Dies vor dem Warten auf eine Reproduktion erledigen

8. Zusammenfassung

  • Legen Sie sich auf Get-WinEvent fest. Get-EventLog ist in PowerShell 7 nicht verfügbar, und die von ihm handhabbaren Protokolle sind begrenzt.
  • Filtern Sie mit -FilterHashtable oder -FilterXPath. Eine nachträgliche Eingrenzung mit Where-Object verschlechtert die Untersuchungszeit um eine Größenordnung.
  • Betrachten Sie bei Neustart-Untersuchungen neben 41 und 6008 auch 1074 (wer es angefordert hat). Bei Anwendungsabstürzen sind 1000, 1026 und 1001 die Ausgangspunkte.
  • Die Verwendung der Ereignisdaten aus ToXml() statt der Meldungszeichenkette liefert ein Skript, das nicht von den Spracheinstellungen abhängt.
  • Für einmalige Untersuchungen über mehrere Rechner verwenden Sie Invoke-Command, für eine dauerhafte Zusammenführung Windows Event Forwarding, und wenn Sie Nachweise benötigen, erfassen Sie .evtx-Dateien und analysieren sie lokal.
  • Existiert das Protokoll für den gewünschten Zeitraum nicht mehr, lässt sich nichts mehr tun. Die Überprüfung der Protokollgrößen hat als Vorbereitung auf die Störungsbehandlung höchste Priorität.

Beispielcode herunterladen

Der in diesem Artikel behandelte Code wird als direkt lauffähiges Paket bereitgestellt. Es enthält den Neustartverlauf, den Anmeldeverlauf, fehlgeschlagene Aufgaben und das Sammeln von mehreren Rechnern.

Beispielcode herunterladen (zip)

Da die Beispiele zu diesem Artikel von Windows und einem Mandanten abhängen, wurden sie nicht durch Ausführung verifiziert. Die Syntaxanalyse und die statische Analyse mit PSScriptAnalyzer wurden für jede Datei durchgeführt, prüfen Sie das Verhalten aber unbedingt auf Ihrem eigenen Testrechner.

# Syntaxanalyse + statische Analyse (läuft auch auf Nicht-Windows-Plattformen)
./Invoke-SampleTests.ps1

Die Konfigurationswerte (Pfade, Servernamen, Mandanten-IDs und Ähnliches) sind Beispiele. Führen Sie sie nicht unverändert gegen die Produktivumgebung aus — passen Sie sie an Ihre eigene Umgebung an.

Verwandte Artikel

Verwandte Beratungsleistungen

KomuraSoft LLC übernimmt die Störungsuntersuchung in Windows-Umgebungen, die Ursachenanalyse bei sporadischen Neustarts und Anwendungsabstürzen sowie den Aufbau von Protokollerfassung und Überwachung.

  1. Microsoft Learn, Get-WinEvent. Dazu, dass sowohl klassische Protokolle als auch die seit Windows Vista eingeführten Ereignisprotokolle abgerufen werden können; zur Auflistung mit -ListLog / -ListProvider; zur Filterung mit -FilterHashtable / -FilterXPath / -FilterXml; zum Lesen archivierter Protokolle (.evtx) mit -Path; zum Remote-Abruf mit -ComputerName; zur Begrenzung der Anzahl der Einträge mit -MaxEvents; dazu, dass zum Lesen des Security-Protokolls Administratorrechte erforderlich sind; sowie dazu, dass sich die XML-Darstellung jedes Ereignisses über dessen Methode ToXml() abrufen lässt. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  2. Microsoft Learn, Erstellen von Get-WinEvent-Abfragen mit FilterHashtable. Zu den mit -FilterHashtable angebbaren Schlüsseln (LogName, ProviderName, Path, Keywords, ID, Level, StartTime, EndTime, UserID, Data und weitere); dazu, dass dies effizienter ist als die Filterung mit Where-Object, weil die Filterung serverseitig erfolgt; sowie zur Angabe von Keyword- und Schweregrad-Werten. ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, Ereignisebenen. Zu den Standardwerten für Schweregrade von Ereignissen (1 = Kritisch, 2 = Fehler, 3 = Warnung, 4 = Information, 5 = Ausführlich). ↩ ↩2

  4. Microsoft Learn, Active Directory-Sicherheitsgruppen — Event Log Readers. Dazu, dass Mitglieder der integrierten Gruppe Event Log Readers die Ereignisprotokolle des lokalen Computers lesen können (ohne dass ihnen Administratorrechte gewährt werden müssen). Zum Ändern der Zugriffsberechtigungen eines einzelnen Kanals siehe auch wevtutil und dessen Option sl /ca (Channel Access). ↩

  5. Microsoft Learn, Windows Event Forwarding. Dazu, dass Ereignisse von mehreren Windows-Rechnern ohne Installation eines zusätzlichen Agents an einen Sammelserver weitergeleitet werden können, und zur Angabe der zu sammelnden Inhalte über Abonnements. Siehe auch Invoke-Command zur parallelen Ausführung gegen mehrere Computer. ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, 4624(S): Ein Konto wurde erfolgreich angemeldet. Zu den in den Ereignisdaten eines erfolgreichen Anmeldeereignisses enthaltenen Elementen (TargetUserName, LogonType, IpAddress und weitere) und der Bedeutung der Anmeldetypwerte sowie dazu, ob Datensätze abhängig von der Konfiguration der Überwachungsrichtlinie erzeugt werden. ↩

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Sollte ich Get-EventLog oder Get-WinEvent verwenden?
Get-WinEvent. Get-EventLog steht nur unter Windows PowerShell 5.1 zur Verfügung und kann ausschließlich die klassischen Protokolle wie System, Application und Security verarbeiten. Die seit Windows Vista unter „Anwendungs- und Dienstprotokolle“ hinzugekommenen Protokolle — detaillierte Protokolle wie Microsoft-Windows-TaskScheduler/Operational — lassen sich nur mit Get-WinEvent auslesen. Da Get-EventLog in PowerShell 7 überhaupt nicht mehr verfügbar ist, sollten Sie sich bei jedem neuen Skript auf Get-WinEvent festlegen.
Get-WinEvent ist so langsam, dass ich keine Untersuchung mehr durchführen kann.
Sehr wahrscheinlich filtern Sie weiter unten in der Pipeline mit Where-Object. Bei dieser Schreibweise wird zunächst jedes Ereignis im Protokoll in ein Objekt umgewandelt und in PowerShell eingelesen, und erst danach werden die unerwünschten verworfen. Bei einem Protokoll mit mehreren Hunderttausend Einträgen ist das nicht praktikabel. Verwenden Sie -FilterHashtable oder -FilterXPath, erfolgt die Filterung auf Seiten des Ereignisprotokolls, und es kommen nur die benötigten Ereignisse zurück — das ist um Größenordnungen schneller. Gewöhnen Sie sich an, Protokollname, Zeitraum und Ereignis-ID zuerst in einer FilterHashtable anzugeben.
Ich erhalte eine Zugriffsverweigerung, wenn ich versuche, das Security-Protokoll zu lesen.
Das Lesen des Security-Protokolls erfordert standardmäßig besondere Berechtigungen. Prüfen Sie nur den eigenen Rechner, genügt es, PowerShell als Administrator auszuführen. Möchten Sie der untersuchenden Person aber keine Administratorrechte einräumen, können Sie sie stattdessen zur integrierten Gruppe Event Log Readers hinzufügen oder ihr über die Zugriffsberechtigungen (ACL) des Kanals nur lesenden Zugriff gewähren. Aus Sicht des Prinzips der geringsten Rechte empfehlen wir Letzteres. Beachten Sie außerdem, dass die Audit-Datensätze möglicherweise schlicht nicht existieren. Die Anmeldeüberwachung und Ähnliches hängen von der Konfiguration der Überwachungsrichtlinie ab. Finden Sie überhaupt keine Ereignisse, prüfen Sie also, ob die Richtlinie selbst aktiviert ist.
Ich möchte einen bestimmten Wert (einen Benutzernamen oder einen Prozessnamen) aus einer Ereignismeldung extrahieren.
Die Verwendung von Properties beziehungsweise der Ereignisdaten ist zuverlässiger, als die Message-Eigenschaft mit einem regulären Ausdruck zu zerlegen. Jedes Ereignis stellt eine Methode ToXml() bereit, die seine XML-Darstellung zurückgibt; diese enthält benannte Elemente unter EventData. Die angezeigte Meldungszeichenkette ändert sich mit den Spracheinstellungen des Betriebssystems, die Struktur der Ereignisdaten dagegen nicht. So können Sie ein Skript schreiben, das sowohl in einer deutschsprachigen als auch in einer englischsprachigen Umgebung funktioniert.
Ich möchte die Ereignisprotokolle mehrerer Server gemeinsam untersuchen.
Bei nur wenigen Rechnern genügen der Parameter -ComputerName von Get-WinEvent oder eine Remote-Ausführung über Invoke-Command. Invoke-Command läuft parallel gegen die angegebenen Rechner und ist bis zu einigen Dutzend praktikabel. Möchten Sie eine dauerhafte Zusammenführung, ziehen Sie Windows Event Forwarding (WEF) in Betracht, um Ereignisse auf einem Sammelserver zu bündeln. Für eine einmalige Untersuchung ist es ebenfalls wirksam, evtx-Dateien auf jedem Server zu exportieren und sie lokal mit Get-WinEvent -Path zu analysieren.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.

Kontakt
Zurück zum Blog