{"id":219245,"date":"2019-06-14T13:50:00","date_gmt":"2019-06-14T11:50:00","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=219245"},"modified":"2019-06-16T00:04:20","modified_gmt":"2019-06-15T22:04:20","slug":"tipp-powershell-workarounds-fr-juni-bug-der-windows-ereignisanzeige-im-detail","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2019\/06\/14\/tipp-powershell-workarounds-fr-juni-bug-der-windows-ereignisanzeige-im-detail\/","title":{"rendered":"Tipp: PowerShell-Workarounds für Juni-Bug der Windows-Ereignisanzeige im Detail"},"content":{"rendered":"

[English<\/a>]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\u00f6nnen.<\/p>\n

<\/p>\n

R\u00fcckblick: Darum geht es<\/h2>\n

\"\"Die Sicherheitsupdates f\u00fcr Windows zum Juni 2019 sollen ja zahlreiche Schwachstellen schlie\u00dfen, haben aber f\u00fcr Administratoren einen ziemlichen Pferdefu\u00df im Gep\u00e4ck. Sobald die Updates installiert wurden, klemmt die Ereignisanzeige. Sind dort unter 'Benutzerdefinierte Ansichten' eigene Eintr\u00e4ge definiert, st\u00fcrzt die Ereignisanzeige bei deren Anwahl ab.<\/p>\n

\"Ereignisanzeige<\/a>
\n(Zum Vergr\u00f6\u00dfern klicken<\/a>)<\/p>\n

Sobald der Fehler einmalig aufgetreten ist, l\u00e4sst sich die Ereignisanzeige grunds\u00e4tzlich nicht mehr verwenden. Hintergrund ist, dass das betreffende Snap-In beim n\u00e4chsten Start automatisch die letzte benutzerdefinierte Ansicht laden m\u00f6chte.<\/p>\n

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

Warum das Thema nochmals aufgreifen?<\/h3>\n

Problem bei meiner in obigem Artikel skizzierten L\u00f6sung war dabei: Mit dem Workaround kann man zwar die Ereignisanzeige wieder aufrufen und in den Ereignissen navigieren und auch suchen. Aber eigene Eintr\u00e4ge im Zweig 'Benutzerdefinierte Ansichten' lassen sich nicht mehr definieren \u2013 dann kommt es sofort wieder zu einem Absturz. Das war von Nutzern in obigem Artikel auch in Kommentaren angemerkt worden.<\/p>\n

Von Microsoft wurde ein Workaround<\/a> ver\u00f6ffentlicht, mit dem sich benutzerdefinierte Ansichten per PowerShell auslesen lassen sollen. Problem bei diesem Ansatz: Der Support-Beitrag KB4508640<\/a> ist arg knapp. Die Jungs und M\u00e4dels aus Redmond haben nur das folgende Script-Fragment ins Internet gekippt:<\/p>\n

function get-EventViewer {\r\n                Write-Output \"List of custom views on the machine\"\r\n                Write-Output \"\"\r\n                Get-ChildItem \"C:\\ProgramData\\Microsoft\\Event Viewer\\Views\" -Filter *.xml | % { select-xml -Path $_.FullName -xpath \"\/\/Name\" } | Select-Object -ExpandProperty Node | Select-Object -ExpandProperty InnerXml\r\n \r\n                Write-Output \"\"\r\n                $view_name = Read-Host \"Enter the name of custom view to execute\"\r\n \r\n \r\n                # Get the file name of the view\r\n                $ViewFile = Get-ChildItem \"C:\\ProgramData\\Microsoft\\Event Viewer\\Views\" -Filter *.xml | where-object { (Select-Xml -Path $_.FullName -xpath \"\/\/Name\").Node.InnerXml -eq $view_name }\r\n \r\n                Get-WinEvent -FilterXml ([xml]((Select-Xml -Path $ViewFile.FullName -XPath \"\/\/QueryList\").node.OuterXml))\r\n}<\/pre>\n
Dazu gab es dann noch die Kurzanleitung, wie man zu verfahren habe \u2013 f\u00fcr erfahrene Administratoren ein Kinderspiel:<\/p>\n
To work around this issue, copy and paste the following function into a PowerShell window and run it.\u00a0 You can now use the command get-EventViewer<\/strong> at the PowerShell prompt to view your Custom Views<\/strong>. You will need to re-enter the function each time you open a new PowerShell window. Note<\/strong> The get-EventViewer <\/strong>function will only allow you to view previously defined Custom Views<\/strong>.\u00a0 To create new Custom Views<\/strong>, see Creating Get-WinEvent queries with FilterHashtable<\/a>.<\/p><\/blockquote>\n
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 \u2013 standardm\u00e4\u00dfig findest Du den Satz: 'Ach ja, es gibt von Microsoft einen Workaround<\/a> f\u00fcr die PowerShell \u2013 das war es.<\/p>\n
Das m\u00fcsste doch klappen \u2026<\/h3>\n
Als ich gestern abend einen Artikel f\u00fcr 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\u00f6ffnet, das obige Code-Fragment aus dem Browser per Copy&Paste in das Konsolenfenster kopiert und die Eingabetaste gedr\u00fcckt. Dann sah ich nur noch rot \u2013 nix mit einer Fool-Proof-L\u00f6sung. Hatte schon diesen Teil meines Artikeltexts gel\u00f6scht, der sich mit einigen Ideen befasste, als mich der Ehrgeiz gepackt hat. Das muss Du doch zum Laufen kriegen!<\/p>\n
Und w\u00e4re 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\u00f6nnen? Ach ja, cool w\u00e4re es, wenn das Ganze noch als anklickbare PowerShell-Module in Form von .ps1-Dateien vorliegt \u2013 und ein paar Erl\u00e4uterungen f\u00fcr Dummies w\u00e4ren auch nicht schlecht.<\/p>\n
Eine halbe Stunde sp\u00e4ter stand meine L\u00f6sung \u2013 und weil ich nicht an drei Stellen flicken m\u00f6chte, 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. \u00e4ndern und erg\u00e4nzen) \u2013 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\u00f6sungen zum Download bereitstellen. Das Ganze soll die Zeit, bis ein Bug-Fix von Microsoft (avisiert f\u00fcr Ende Juni 2019) zur Verf\u00fcgung steht, \u00fcberbr\u00fccken. Quasi die Hilfskr\u00fccke f\u00fcr genervte Administratoren und Unternehmensumgebungen. Keine Ahnung, ob das jemand braucht.<\/p>\n
Was der Microsoft-Workaround leistet<\/h2>\n
Zuerst einige Worte zum Microsoft-Workaround \u2013 ist erfahrenen Administratoren wohl intuitiv klar \u2013 aber ich musste erst einmal den Script-Code anschauen und etwas sortieren. Das Script kann man um den Funktionsaufruf erweitern und in eine .ps1<\/em>-Dateien speichern. Das Ganze sieht so aus:<\/p>\n
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)) }<\/p>\n
get-EventViewer<\/p>\n
<\/pre>\n
Erst mit der letzten Anweisung wird das Code-Fragment mit der PowerShell-Funktion get-EventViewer<\/em> bei der Script-Ausf\u00fchrung auch aufgerufen.<\/p>\n
Das setzt das PowerShell-Script voraus<\/h3>\n
Dieses PowerShell-Script setzt voraus, dass global f\u00fcr alle Benutzerkonten der Maschine 'Benutzerdefinierte Ansichten' definiert sind (die sind dann in ProgramData<\/em> gespeichert).<\/p>\n
Diese Bedingung war bei meiner Testmaschine mit Windows 10 nicht gegeben, so dass das PowerShell-Script wenig genutzt h\u00e4tte. Definiert man aber benutzerdefinierte Ansichten global, l\u00e4sst sich die Ereignisanzeige wegen des Bugs nicht mehr aufrufen. Man muss also komplett mittels der PowerShell arbeiten.<\/p>\n
So wird das Script eingesetzt<\/h3>\n
Das PowerShell-Script muss mit administrativen Rechten (Als Administrator ausf\u00fchren<\/em>) in der PowerShell-Konsole oder in der PowerShell ISE ausgef\u00fchrt werden. Dann sollte es auch keine Fehlermeldungen geben.<\/p>\n
\"PowerShell-Script<\/a>
\n(Zum Vergr\u00f6\u00dfern klicken<\/a>)<\/p>\n
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 \u2013 wobei ich dort bereits das modifizierte Script aus dem nachfolgenden Ansatz verwendet habe.<\/p>\n
Nutze Event-Viewer und 'Benutzerdefinierte Ansichten'<\/h2>\n
An dieser Stelle entstand bei mir die Idee, ob es nicht die M\u00f6glichkeit gibt, beides, die Ereignisanzeige zu verwenden und trotzdem auch Ereignisse \u00fcber benutzerdefinierte Ansichten auszulesen. Die grobe Idee war:<\/p>\n