Windows Update ETLs manuell dekodieren

08 März 2018 AustrianBossfan it

Seit Windows 10 werden die Logfiles vom Windows Update Service nicht mehr in einfach lesbare Log-Dateien sondern in sogenannte Event Trace Logfiles (ETL) geschrieben. Wieder einmal eine ganz tolle Idee von Microsoft, die besonders dann hilfreich ist wenn es ans Troubleshooten von Windows Update Problemen geht (die soll es ja angeblich hin und wieder geben).

Die ETL Files haben 2 eklatante Nachteile:

  • man kann nicht mehr live (mittels tail oder anderen Tools) mitlesen
  • lokal gibt es das Powershell Cmdlet "Get-WindowsUpdateLog", welches die ETLs in ein lesbares Log dekodieren und auf den Desktop legen. Leider ist man nicht immer lokal unterwegs, schon gar nicht wenn man im Enterprise Umfeld tätig ist.

Manuelles dekodieren ist möglich, aber natürlich nicht so einfach wie man es gerne hätte. Dazu muss man wie folgt vorgehen:

Die Windows Update ETL Files befinden sich auf C:\Windows\logs\WindowsUpdate:

Mittels tracefmt.exe können diese ETLs nun in eine lesbares Logfile dekodiert werden:

tracefmt.exe -o windowsupate.log WindowsUpdate.20180308.103756.226.8.etl -r c:\Symbols

Möchte man mehrere ETLs auf einmal dekodieren, einfach durch Leerzeichen getrennt die entsprechenden Dateinamen angeben.

Das Ergebnis ist ein (halbwegs vernünftig) lesbares Logfile, wie man es von früheren Windows Versionen gewöhnt ist:

[0]0DA8.25DC::03/07/2018-14:37:26.883 [WUTraceLogging]{"name":"Misc","Info":"Got WSUS Client/Server URL: \"http://wsus.meine.firma.at/ClientWebService/client.asmx\""}
[0]0DA8.25DC::03/07/2018-14:37:26.900 [WUTraceLogging]{"name":"ProtocolTalker","Info":"OK to reuse existing configuration"}
[0]0DA8.25DC::03/07/2018-14:37:26.900 [WUTraceLogging]{"name":"ProtocolTalker","Info":"Existing cookie is valid, just use it"}
[0]0DA8.25DC::03/07/2018-14:37:26.900 [WUTraceLogging]{"name":"ProtocolTalker","Info":"PTInfo: Server requested registration"}
[0]0DA8.25DC::03/07/2018-14:37:26.916 [WUTraceLogging]{"name":"Misc","Info":"Got WSUS Reporting URL: \"http://wsus.meine.firma.at/ReportingWebService/ReportingWebService.asmx\""}
[0]0DA8.25DC::03/07/2018-14:37:26.916 [WUTraceLogging]{"name":"IdleTimer","Info":"WU operation (CLegacyEventUploader::HandleEvents) started; operation # 102; does use network; is at background priority"}
[0]0DA8.25DC::03/07/2018-14:37:26.916 [WUTraceLogging]{"name":"WebServices","Info":"Auto proxy settings for this web service call."}
[0]0DA8.25DC::03/07/2018-14:37:27.241 [WUTraceLogging]{"name":"IdleTimer","Info":"WU operation (CLegacyEventUploader::HandleEvents, operation # 102) stopped; does use network; is at background priority"}
[0]0DA8.246C::03/07/2018-14:47:27.250 [WUTraceLogging]{"name":"Agent","Info":"Earliest future timer found: "}
[0]0DA8.246C::03/07/2018-14:47:27.250 [WUTraceLogging]{"name":"Agent","Info":"    Timer: 29A863E7-8609-4D1E-B7CD-5668F857F1DB, Expires 2018-03-08 09:14:12, not idle-only, not network-only"}
[0]0DA8.13E0::03/07/2018-14:47:28.253 [WUTraceLogging]{"name":"Misc","Info":"CSusClientGlobal::DoServicePreShutdown"}
[0]0DA8.13E0::03/07/2018-14:47:28.253 [WUTraceLogging]{"name":"IdleTimer","Info":"Idle timer disabled in preparation for service shutdown"}
[0]0DA8.13E0::03/07/2018-14:47:28.253 [WUTraceLogging]{"name":"Misc","Info":"WUTaskManager uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.253 [WUTraceLogging]{"name":"Agent","Info":"Earliest future timer found: "}
[0]0DA8.13E0::03/07/2018-14:47:28.253 [WUTraceLogging]{"name":"Agent","Info":"    Timer: 29A863E7-8609-4D1E-B7CD-5668F857F1DB, Expires 2018-03-08 09:14:12, not idle-only, not network-only"}
[0]0DA8.13E0::03/07/2018-14:47:28.259 [WUTraceLogging]{"name":"Misc","Info":"CreateSessionStateChangeTrigger, TYPE:2, Enable:No"}
[0]0DA8.13E0::03/07/2018-14:47:28.259 [WUTraceLogging]{"name":"Misc","Info":"CreateSessionStateChangeTrigger, TYPE:4, Enable:No"}
[0]0DA8.13E0::03/07/2018-14:47:28.266 [WUTraceLogging]{"name":"Misc","Info":"Agent uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.269 [WUTraceLogging]{"name":"Misc","Info":"Reporter uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.269 [WUTraceLogging]{"name":"Misc","Info":"network cost manager uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.269 [WUTraceLogging]{"name":"Misc","Info":"Eventer uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.269 [WUTraceLogging]{"name":"Misc","Info":"ServiceManager uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.270 [WUTraceLogging]{"name":"Misc","Info":"PersistentTimeoutScheduler uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.270 [WUTraceLogging]{"name":"Misc","Info":"datastore uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.297 [WUTraceLogging]{"name":"Misc","Info":"setting cache uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.297 [WUTraceLogging]{"name":"Misc","Info":"security checker uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.297 [WUTraceLogging]{"name":"Misc","Info":"Test Hook uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.297 [WUTraceLogging]{"name":"Misc","Info":"IdleTimer uninit"}
[0]0DA8.13E0::03/07/2018-14:47:28.299 [WUTraceLogging]{"name":"Shared","Info":"* END * Service exit Exit code = 0x240001"}

 

 

Active Directory und Legacy Logon Scripts

11 März 2016 AustrianBossfan it

Ich hatte das Problem, dass in einer unserer Active Directory Domains bei der Anmeldung eines Users keine Logon Scripts mehr ausgeführt wurden. Da über diese jedoch Netzlaufwerke verbunden und diverse andere Einstellungen vorgenommen werden, ist das relativ unangenehm.

Es gab keine Hinweise im Eventlog am Client, auch keine Hinweise im Eventlog am Domain Controller. Mittels Procmon und Boot Logging (da wird das Logon auch mitgeloggt) konnte ich auch nicht wirklich etwas finden, außer dem seltsamen Versuch, das Logon Script am Client auf "C:\Windows\system32\repl\import\scripts" zu finden. Ich fühlte mich in NT4 Zeiten zurück versetzt.

Microsoft selbst ist ja kein Freund von Legacy Logon Scripts, wenn man mit Google umgehen kann, findet man recht schnell heraus, dass man statt dessen Group Policy Scripts verwenden soll. Somit war es relativ schwierig hier etwas hilfreiches via Suchmaschine zu finden. Nach langem Suchen stellte sich heraus dass das Problem aufgrund einer ganz speziellen Konfiguration auftritt.

Hat man mehrere Active Directory Domains, wie z.B. x.mydomain.at und y.mydomain.at, dann hat man für diese auch ein DNS zu betreiben. Wenn jedoch am Client in der DNS-Suchreihenfolge nur die Domain x.mydomain.at eingetragen ist, wird ein Versuche einen Computer in der Domain y.mydomain.at aufzulösen scheitern (außer der Computer hat auch in der DNS-Zone x.mydomain.at ein A-Rechord oder einen CNAME). Und genau das war das Problem. Legacy Logon Scripts werden aus historischen Gründen anscheinend via \\Servername\NETLOGON\... oder \\%LOGONSERVER%\NETLOGON\... aufgerufen. Hallo NT4 ;-)

Meldet sich ein User aus der Domain y.mydomain.at auf einem Rechner an, der in der DNS-Suchreihenfolge die DNS-Zone y.mydomain.at nicht eingetragen hat, dann kann der Pfad zum Logon Script nicht aufgelöst werden (das erklärt dann auch den seltsam erscheinenden Versuch das Logonscript lokal zu finden) und somit wird es nicht ausgeführt.

Also schnell CNAMEs für die Domain Controller der Domain y.mydomain.at in der DNS-Zone x.mydomain.at angelegt und alles war gut :-)

(RaiZl)

Windows Firewall Regeln

29 November 2015 AustrianBossfan it

Wer komplexe Firewall-Regeln mit vielen IP Adressen oder ähnlichem erstellen muss, wird mit dem GUI schnell narrisch. Daher habe ich mich auf die Suche gemacht und festgestellt, dass die Firewall-Regeln in der Registry gespeichert werden und sich dort ausgezeichnet manipulieren lassen.

Die Regeln finden sich hier:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

Die Regel für den Internet Information Server (IIS) auf Port 80 sieht z.B. so aus:

v2.22|Action=Allow|Active=TRUE|Dir=In|Protocol=6|LPort=80|App=System|Name=@%windir%\system32\inetsrv\iisres.dll,-30500|
Desc=@%windir%\system32\inetsrv\iisres.dll,-30510|EmbedCtxt=@%windir%\system32\inetsrv\iisres.dll,-30501|

Eine Regel zum Blocken bestimmter IP Adressen und ganzer Subnetze sieht z.B. so aus:

v2.20|Action=Block|Active=TRUE|Dir=In|RA4=192.168.125.0/255.255.255.0|RA4=192.168.124.34|RA4=192.168.126.223|Name=Block stupid people|

Es empfiehlt sich, die Regel via GUI anzulegen, und dann zusätzliche Adressen in der Registry hinzuzufügen.

(RaiZl)