25.01.2008 | Autor / Redakteur: Markus Widl / Andreas Donner
Um Problemen frühzeitig auf die Spur zu kommen, hilft oft ein Blick in die Windows-Ereignisprotokolle. Noch schneller ginge es, wenn dieser Blick automatisch und auch auf anderen Computern im Netzwerk machbar wäre. SearchNetworking zeigt eine Lösung mit der PowerShell von Microsoft.
Zur Abfrage der Ereignisprotokolle liefert die PowerShell das Cmdlet get-eventlog mit. Dieser Befehl erfordert über den Pflicht-Parameter -logname die Angabe des gewünschten Protokolls und liefert je ein Objekt vom Typ System.Diagnostics.EventLogEntry für die Einträge. Hier ein Beispiel zum Auslesen des System-Logs:
get-eventlog -logname system
Die hier meist umfangreich zurückgegebenen Informationen lassen sich auch filtern, etwa über den Parameter -newest. Das folgende Beispiel liefert nur die neuesten fünf Einträge, unabhängig vom Typ (Warning, Information, Error):
get-eventlog -logname system -newest 5
Die Filterung nach dem Typ des Eintrags ließe sich mit Hilfe des Cmdlets where-object und der Eigenschaft EntryType realisieren. Beispielsweise sollen im folgenden Beispiel nur Fehlermeldungen ausgegeben werden:
get-eventlog -logname system | where-object { $_.EntryType -eq „Error“ }
Das Cmdlet get-eventlog ist einfach einzusetzen und erledigt seinen Dienst, jedoch hat es einen erheblichen Nachteil: es arbeitet ausschließlich auf der lokalen Maschine.
In einem solchen Fall wird gerne auf WMI (Windows Management Instrumentation) ausgewichen, da mit dem Cmdlet get-wmiobject auch auf andere Computer im Netzwerk zugegriffen werden kann. Gegen Ende des Artikels wird dieses Verfahren auch gezeigt, zuerst soll jedoch noch eine andere Möglichkeit besprochen werden, die bei der Problemstellung eleganter und stärker PowerShell-typisch arbeitet: Es wird die Klasse System.Diagnostics.Eventlog des .NET-Frameworks eingesetzt.
Zunächst einmal wird ein Objekt vom Typ System.Diagnostics.Eventlog erstellt, was mit dem Cmdlet new-object erledigt wird. Dabei wird der Klassenkonstruktor mit zwei Parametern aufgerufen. Im ersten wird der Name des auszulesenden Ereignisprotokolls angegeben und im zweiten der Computername. Im folgenden Beispiel wird auf das System-Protokoll des Rechners London zugegriffen und das erzeugte Objekt zur weiteren Verwendung in einer Variablen gespeichert:
$log = new-object System.Diagnostics.EventLog(„System“, „London“)
Der Zugriff auf die Protokoll-Einträge erfolgt nun über die Eigenschaft Entries:
$log.Entries
An dieser Stelle werden, wie schon beim Cmdlet get-eventlog, Objekte vom Typ System.Diagnostics.EventLogEntry geliefert. Die Weiterbearbeitung erfolgt also analog. Nur der Parameter -newest kann hier nicht zum Einsatz kommen, aber mit dem Cmdlet select-object kann dasselbe Ergebnis leicht erreicht werden. Auch in diesem Beispiel werden die fünf neuesten Einträge ausgegeben, allerdings in umgekehrter Reihenfolge:
$log.Entries | select-object -last 5
Zum Schluss folgt noch die oben bereits angesprochene Variante über WMI, das Ereignisprotokoll von Remote-Maschinen abzufragen. Über WMI können Objekte der Klasse Win32_NTLogEvent sowohl lokal als auch remote ausgelesen werden, in denen die gesuchten Informationen aus den Ereignisprotokollen stehen. Mit dem Cmdlet get-wmiobject werden diese Objekte abgefragt:
get-wmiobject -class Win32_NTLogEvent
Damit diese Abfrage auf einem anderen Computer ausgeführt wird, ist die zusätzliche Angabe des Rechnernamens über den Parameter -computername nötig.
get-wmiobject -class Win32_NTLogEvent -computername London
In den bisherigen WMI-Beispielen wird keine Unterscheidung zwischen den verschiedenen Ereignisprotokollen vorgenommen. Über eine Filterung kann eine Beschränkung auf ein bestimmtes Protokoll erreicht werden, wie hier auf das System-Log:
get-wmiobject -class Win32_NTLogEvent -filter „LogName=‘System‘“
Die Klasse Win32_NTLogEvent unterscheidet sich etwas von der oben zum Tragen gekommenen Klasse System.Diagnostics.EventLogEntry. Die unten angegebenen Links führen zur vollständigen Dokumentation aller besprochenen Klassen.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2010291)
