IIS Failed Request Tracing

Auf der Seite IIS - Webserver Troubleshooting habe ich einige Möglichkeiten zur Analyse von IIS-Problemen beschrieben. Für das aus meiner Sicht sehr leistungsfähige Feature "IIS Failed Request Tracing" habe ich aber eine eigene Seite spendiert.

Einsatz

Oftmals sehen Sie im IISLog zwar die Zugriffe mit der URL und die Fehlercodes aber keine Details. Wenn Sie z.B. viele 401-Fehler sehen, dann können Sie im Windows Security Eventlog vielleicht ermitteln, welche NTLM-Anmeldungen fehlgeschlagen sind, aber der 401-Fehler an sich kann auch andere fehlerhafte Anmeldungen berichten. Hier wäre es dann hilfreich, wenn wir als Administrator z.B. den Request des Clients im Klartext, die Verarbeitung durch den IIS und die Rückantwort an den Client analysieren könnten.

Bei unterschlüsselten Verbindungen können Sie auch per WireShark die TCP-Connection mitschneiden aber da heute alles per HTTPS/TLS verschlüsselt ist, fällt diese Möglichkeit immer häufiger aus. Hier komme dann das "IIS Failed Request Tracing" zum Einsatz.

Installation

Voraussetzung ist, dass Sie das Feature "Tracing" installiert haben

Aktivierung pro Webseite

Im zweiten Schritt muss das Features auf der jeweiligen Webseite noch aktiviert werden.

Aktivierung pro Verzeichnis

Und dann müssen Sie auf dem jeweiligen virtuellen Verzeichnis ebenfalls noch genauer hinterlegen, welche Fehler sie denn protokollieren lassen wollen.

Auswerten

Das Ergebnis sind dann für jeden Request, auf den die Bedingungen zutreffen, entsprechende XML-Dateien in dem anfangs angegebenen Pfad.

Probieren Sie es einfach mal aus. Es ist schon erstaunlich wie detailliert diese XML-Dateien in einem Internet Explorer den Ablauf der Anforderung ausgeben. Fast immer finden Sie heraus, warum und wo der Fehler aufgetreten ist. Sehr oft kann man sogar erkennen, an welcher Stelle eine Anfrage getrödelt hat. Also auch für Performanceprobleme kann dies ein erster Ansatz sein. Richten Sie bitte diese Funktion aber nicht für "jeden" Request ein und vergessen Sie nicht die Funktion nach ein paar Ausgaben wieder abzuschalten. Diese zusätzliche Arbeit belastet den Server durchaus.

Zudem kann es ziemlich mühsam sein, die "richtigen" Dateien ausfindig zu machen. Daher habe ich mir ein kleines Skript welches zu jeder Datei die URLs etc. ausgibt:

param (
   $path = "C:\inetpub\logs\FailedReqLogFiles\W3SVC1"
)

Write-Verbose "Gettings Files from $($path)"
foreach ($file in (get-childitem "$($path)/*.xml")){
   Write-Verbose "Processing $($file.name)"
   $content = [xml](get-content $file)
   $content.failedRequest | select @{name="Filename"; expr={$file.name}},verb,statuscode,url,authenticationtype,username
}

So kann ich dann zumindest anhand der URLs etc. schnell weiter filtern und die nicht erforderlichen Dateien gleich wieder löschen, z.B. mit

.\parse-freblogs.ps1 `
| where {$_.url -eq "https://localhost:443/ews/"} `
| Foreach {Remove-Item 
"C:\inetpub\logs\FailedReqLogFiles\W3SVC1\$($_.filename)"}

.\parse-freblogs.ps1 `
| where {$_.url -like "*healthcheck.htm"} `
| Foreach {Remove-Item "C:\inetpub\logs\FailedReqLogFiles\W3SVC1\$($_.filename)"}

Gerade auf einem Exchange Server gibt es doch relativ viel Grundrauschen durch die Selbstüberwachung (Exchange 2013 Managed Availability) auf healtcheck.htm.

FEB.XML in Edge anzeigen

Früher konnten Sie die XML-Dateien per Doppelklick im Internet Explorer anzeigen lassen.

Allerdings ist der IE mittlerweile natürlich veraltet. Der neue Edge-Browser zeigt aber nur hier nur eine leere Seite, weil er aus Sicherheitsgründen keine "file://-Urls" mehr mit öffnet. Und genau das ist der Verweis auf die XSLT-Datei. Starten Sie daher den Edge mit folgendem Parameter:

start msedge.exe --allow-file-access-from-files

Dazu müssen vorher aber alle Edge-Instanzen geschlossen sein.

Weitere Links