Tipp: PowerShell-Workarounds für Juni-Bug der Windows-Ereignisanzeige im Detail

[English]Ich habe mich mal intensiver mit dem Bug in der Windows-Ereignisanzeige, der durch die Juni 2019-Patches verursacht wird, befasst. Speziell interessierte mich das von Microsoft ins Internet gekippte Power-Shell-Fragment. Der Beitrag ist ein Hands-on, der zeigt, wie man mit dem Workaround umgehen kann und bringt einen modifizierten Ansatz, um sowohl die Ereignisanzeige als auch 'Benutzerdefinierte Ansichten' auf einer Maschine nutzen zu können.

Rückblick: Darum geht es

Die Sicherheitsupdates für Windows zum Juni 2019 sollen ja zahlreiche Schwachstellen schließen, haben aber für Administratoren einen ziemlichen Pferdefuß im Gepäck. Sobald die Updates installiert wurden, klemmt die Ereignisanzeige. Sind dort unter 'Benutzerdefinierte Ansichten' eigene Einträge definiert, stürzt die Ereignisanzeige bei deren Anwahl ab.

(Zum Vergrößern klicken)

Sobald der Fehler einmalig aufgetreten ist, lässt sich die Ereignisanzeige grundsätzlich nicht mehr verwenden. Hintergrund ist, dass das betreffende Snap-In beim nächsten Start automatisch die letzte benutzerdefinierte Ansicht laden möchte.

Ich hatte mich mit dem Thema ausführlich im Blog-Beitrag Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.) auseinander gesetzt. Im Artikel wird erläutert, welche Windows-Versionen und Updates betroffen sind (faktisch alle). Und ich hatte einen Workaround skizziert, wie man zumindest den Absturz der Ereignisanzeige flicken kann.

Warum das Thema nochmals aufgreifen?

Problem bei meiner in obigem Artikel skizzierten Lösung war dabei: Mit dem Workaround kann man zwar die Ereignisanzeige wieder aufrufen und in den Ereignissen navigieren und auch suchen. Aber eigene Einträge im Zweig 'Benutzerdefinierte Ansichten' lassen sich nicht mehr definieren – dann kommt es sofort wieder zu einem Absturz. Das war von Nutzern in obigem Artikel auch in Kommentaren angemerkt worden.

Von Microsoft wurde ein Workaround veröffentlicht, mit dem sich benutzerdefinierte Ansichten per PowerShell auslesen lassen sollen. Problem bei diesem Ansatz: Der Support-Beitrag KB4508640 ist arg knapp. Die Jungs und Mädels aus Redmond haben nur das folgende Script-Fragment ins Internet gekippt:

function get-EventViewer {
                Write-Output "List of custom views on the machine"
                Write-Output ""
                Get-ChildItem "C:\ProgramData\Microsoft\Event Viewer\Views" -Filter *.xml | % { select-xml -Path $_.FullName -xpath "//Name" } | Select-Object -ExpandProperty Node | Select-Object -ExpandProperty InnerXml
 
                Write-Output ""
                $view_name = Read-Host "Enter the name of custom view to execute"
 
 
                # Get the file name of the view
                $ViewFile = Get-ChildItem "C:\ProgramData\Microsoft\Event Viewer\Views" -Filter *.xml | where-object { (Select-Xml -Path $_.FullName -xpath "//Name").Node.InnerXml -eq $view_name }
 
                Get-WinEvent -FilterXml ([xml]((Select-Xml -Path $ViewFile.FullName -XPath "//QueryList").node.OuterXml))
}

Dazu gab es dann noch die Kurzanleitung, wie man zu verfahren habe – für erfahrene Administratoren ein Kinderspiel:

To work around this issue, copy and paste the following function into a PowerShell window and run it.  You can now use the command get-EventViewer at the PowerShell prompt to view your Custom Views. You will need to re-enter the function each time you open a new PowerShell window. Note The get-EventViewer function will only allow you to view previously defined Custom Views.  To create new Custom Views, see Creating Get-WinEvent queries with FilterHashtable.

Nun gut, ich bin jetzt kein erfahrener Administrator, sondern habe mich vor 6 oder 7 Jahren zuletzt mit der PowerShell auseinander gesetzt. Und die Kollegen von der Schreibenden Zunft sind da offenbar auch nicht besser aufgestellt. Ich habe mal schnell geschaut – standardmäßig findest Du den Satz: 'Ach ja, es gibt von Microsoft einen Workaround für die PowerShell – das war es.

Das müsste doch klappen …

Als ich gestern abend einen Artikel für heise zum Bug verfasst habe, zuckte der Gedanke 'schau doch mal, wie der Workaround funktioniert' durch den Hinterkopf. Gesagt, getan, auf einer Windows 10-Maschine den Browser und die PowerShell-Konsole geöffnet, das obige Code-Fragment aus dem Browser per Copy&Paste in das Konsolenfenster kopiert und die Eingabetaste gedrückt. Dann sah ich nur noch rot – nix mit einer Fool-Proof-Lösung. Hatte schon diesen Teil meines Artikeltexts gelöscht, der sich mit einigen Ideen befasste, als mich der Ehrgeiz gepackt hat. Das muss Du doch zum Laufen kriegen!

Und wäre es nicht cool, wenn beides ginge: Benutzerdefinierte Ansichten abrufen, aber gleichzeitig mit der Ereignisanzeige arbeiten und dort in deren restlichen Zweigen nach Ereignissen schauen oder filtern können? Ach ja, cool wäre es, wenn das Ganze noch als anklickbare PowerShell-Module in Form von .ps1-Dateien vorliegt – und ein paar Erläuterungen für Dummies wären auch nicht schlecht.

Eine halbe Stunde später stand meine Lösung – und weil ich nicht an drei Stellen flicken möchte, habe ich das Prinzip der Single Source realisiert. Das Know-How, die PowerShell-Scripte und die Beschreibungen finden sich in diesem Blog-Beitrag (da kann ich ggf. ändern und ergänzen) – aus meinem obigen Beitrag und dem heise-Artikel wird hierhin verlinkt. Und ich kann eine zip-Datei mit einer readme.txt sowie zwei fertigen PowerShell-Lösungen zum Download bereitstellen. Das Ganze soll die Zeit, bis ein Bug-Fix von Microsoft (avisiert für Ende Juni 2019) zur Verfügung steht, überbrücken. Quasi die Hilfskrücke für genervte Administratoren und Unternehmensumgebungen. Keine Ahnung, ob das jemand braucht.

Was der Microsoft-Workaround leistet

Zuerst einige Worte zum Microsoft-Workaround – ist erfahrenen Administratoren wohl intuitiv klar – aber ich musste erst einmal den Script-Code anschauen und etwas sortieren. Das Script kann man um den Funktionsaufruf erweitern und in eine .ps1-Dateien speichern. Das Ganze sieht so aus:

function get-EventViewer { Write-Output "List of custom views on the machine" Write-Output "" Get-ChildItem "C:\ProgramData\Microsoft\Event Viewer\Views" -Filter *.xml | % { select-xml -Path $_.FullName -xpath "//Name" } | Select-Object -ExpandProperty Node | Select-Object -ExpandProperty InnerXml Write-Output "" $view_name = Read-Host "Enter the name of custom view to execute" # Get the file name of the view $ViewFile = Get-ChildItem "C:\ProgramData\Microsoft\Event Viewer\Views" -Filter *.xml | where-object { (Select-Xml -Path $_.FullName -xpath "//Name").Node.InnerXml -eq $view_name } Get-WinEvent -FilterXml ([xml]((Select-Xml -Path $ViewFile.FullName -XPath "//QueryList").node.OuterXml)) }

get-EventViewer

Erst mit der letzten Anweisung wird das Code-Fragment mit der PowerShell-Funktion get-EventViewer bei der Script-Ausführung auch aufgerufen.

Das setzt das PowerShell-Script voraus

Dieses PowerShell-Script setzt voraus, dass global für alle Benutzerkonten der Maschine 'Benutzerdefinierte Ansichten' definiert sind (die sind dann in ProgramData gespeichert).

Diese Bedingung war bei meiner Testmaschine mit Windows 10 nicht gegeben, so dass das PowerShell-Script wenig genutzt hätte. Definiert man aber benutzerdefinierte Ansichten global, lässt sich die Ereignisanzeige wegen des Bugs nicht mehr aufrufen. Man muss also komplett mittels der PowerShell arbeiten.

So wird das Script eingesetzt

Das PowerShell-Script muss mit administrativen Rechten (Als Administrator ausführen) in der PowerShell-Konsole oder in der PowerShell ISE ausgeführt werden. Dann sollte es auch keine Fehlermeldungen geben.

(Zum Vergrößern klicken)

Das Script listet die gefundenen globalen benutzerdefinierte Ansichten auf und fragt dann nach dem Namen der Ansicht, die anzuzeigen ist. Tippt man den Namen ein, werden die Ergebnisse aufgelistet. Obiges Bild zeigt den Ansatz in der PowerShell ISE – wobei ich dort bereits das modifizierte Script aus dem nachfolgenden Ansatz verwendet habe.

Nutze Event-Viewer und 'Benutzerdefinierte Ansichten'

An dieser Stelle entstand bei mir die Idee, ob es nicht die Möglichkeit gibt, beides, die Ereignisanzeige zu verwenden und trotzdem auch Ereignisse über benutzerdefinierte Ansichten auszulesen. Die grobe Idee war:

• Man flickt die Ereignisanzeige mit dem im Blog-Beitrag Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.) beschriebenen Workaround (entfernen der Views-XML-Dateien) für globale benutzerdefinierte Ansichten.
• Dann legt man lokale benutzerdefinierte Ansichten unter einem Standard-Benutzerkonto an (ggf. die Views-XML-Dateien entsprechend kopieren) – oder man verwendet die im Microsoft-Artikel Creating Get-WinEvent queries with FilterHashtable beschriebenen Ansätze (habe ich nicht versucht).

Dabei liegt folgende Idee zugrunde: Rufe ich unter dem Standard-Benutzerkonto die Ereignisanzeige über Als Administrator ausführen auf, läuft das Snap-In im Kontext des Administratorkontos. Sind dort keine globalen oder lokalen Einträge in 'Benutzerdefinierte Ansichten' abgelegt, funktioniert das Snap-in der Ereignisanzeige. Ich kann also in Ereignissen suchen, darf nur keine benutzerdefinierten Ereignisse anlegen.

Und zur Anzeige lokaler benutzerdefinierter Ereignisse verwendet man unter dem Standard-Benutzerkonto das PowerShell-Script. Sollte ein halbwegs komfortables Arbeiten ermöglichen – ich habe es hier kurz getestet, das funktionierte, soweit ich gesehen habe.

Lokale benutzerdefinierte Ansichten erstellen und verwenden

Um neue Einträge unter 'Benutzerdefinierte Ansichten' in der Ereignisanzeige zu verwenden, muss diese mit Standard-Benutzerrechten aufgerufen werden. Oder bei Ausführung über Als Administrator ausführen muss beim Speichern die Markierung des Kontrollkästchens Alle Benutzer im Dialogfeld Filter in benutzerdefinierte Ansicht speichern unten rechts gelöscht werden.

Ich hatte das im Blog-Beitrag Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.) bereits erläutert. Die Microsoft Management Console MMC.exe speichert dann die Daten des Ereignisanzeigen-Snap-Ins in AppData des lokalen Profilordners. Damit haben die benutzerdefinierten Ansichten nur Einfluss auf das lokale Konto (und führen auch nur dort zum Absturz des Event Viewers).

Tipp: Man könnte auch die globalen XML-Dateien wie Views_0.xml etc. in den lokalen Profilordner kopieren. Dann hat man sofort die alten Definitionen – und in der Ereignisanzeige lässt sich ja maximal ein benutzerdefinierter Eintrag anlegen, da es sofort danach zum Absturz kommt. Die Pfade der Ordner habe ich ja im oben verlinkten Blog-Beitrag beschrieben.

Modifiziertes PowserShell-Script für lokale benutzerdefinierte Ansichten

Um unter diesem Benutzerkonto auf (die lokal gespeicherten) benutzerdefinierten Ansichten zuzugreifen, verwendet man ein PowerShell-Modul. Leider klappt das mit dem obigen Microsoft PowerShell-Fragment nicht. Aber das ist kein Problem, man braucht nur die Pfade zu den Views-XML-Dateien entsprechend anzupassen.

function get-EventViewer {   $account = "MSKonto"
                Write-Output "List of custom views on the machine for: $account"
                Write-Output ""
                Get-ChildItem "C:\Users\$account\appdata\local\Microsoft\Event Viewer\Views" -Filter *.xml | % { select-xml -Path $_.FullName -xpath "//Name" } | Select-Object -ExpandProperty Node | Select-Object -ExpandProperty InnerXml
 
                Write-Output ""
                $view_name = Read-Host "Enter the name of custom view to execute"
 
 
                # Get the file name of the view
                $ViewFile = Get-ChildItem "C:\Users\$account\appdata\local\Microsoft\Event Viewer\Views" -Filter *.xml | where-object { (Select-Xml -Path $_.FullName -xpath "//Name").Node.InnerXml -eq $view_name }
 
                Get-WinEvent -FilterXml ([xml]((Select-Xml -Path $ViewFile.FullName -XPath "//QueryList").node.OuterXml))
}
 get-EventViewer

In obiger Box ist der modifizierte PowerShell-Script-Code, um Views des lokalen Benutzerkontos auszulesen, zu finden. Ich habe eine Variable $account definiert, der ich den Namen des Benutzerprofils auf meiner Testmaschine (hier MSKonto) zugewiesen habe. Die Idee dahinter: So kann ich ein festes Konto angeben, welches die Custom Views der Ereignisanzeige enthält, d.h. das PowerShell-Script funktioniert von diversen Benutzerkonten.

Wichtig: Der Wert der Variablen (der Teil in " ") muss an den Profilnamen des eigenen Rechners, unter dem die benutzerdefinierten Ansichten angelegt wurden, angepasst werden, damit das Script funktioniert. Es handelt sich um die Datei LocalEventView.ps1.

Bei der Ausführung der Funktion greift diese dann auf AppData im Benutzerprofil zu und liest die lokal definierten 'Custom Views'. Diese werden aufgelistet und der Benutzer kann dann einen View-Namen eintippen, um die benutzerdefinierte Ansicht abzurufen (siehe nachfolgendes Bild).

(Zum Vergrößern klicken)

Ich habe dort die PowerShell ISE über Als Administrator ausführen gestartet (mit Standardrechten kommt es zu Fehlern) und dann das .ps1-Script geladen. Dann reicht es, auf die Script ausführen-Schaltfläche der Symbolleiste zu klicken oder die Funktionstaste F5 zu drücken. Die Ein-/Ausgaben werden im unteren Konsolenfenster angezeigt. Durch die absoluten Pfadangaben im Script funktioniert dieses auch, wenn es mit administrativen Rechten läuft – es wird der richtige Profilordner gefunden.

Die beiden PowerShell-Varianten samt einer kleinen Readme.txt findet ihr als PowerShell-EventViewer.zip zum Download (ich habe das Zeugs für einen heise-Artikel erstellt).

Vielleicht hilft es dem einen oder anderen Administrator weiter. Falls was übersehen wurde, könnt ihr ja Kommentare hinterlassen oder Ergänzungen vornehmen.

PS: Der Artikel Juni-Sicherheitsupdates sabotieren Ereignisanzeige in allen Windows-Versionen ist jetzt bei heise im Newsticker erschienen. Gab dort diesen Kommentar, bei dem ich mir die Frage stelle, ob das so bei den Admins gehandhabt wird?

Ähnliche Artikel:
Windows 7-10: Ereignisanzeige hängt nach Juni 2019-Update (KB4503293/KB4503327 etc.)