IIS - Webserver Troubleshooting

Viele Funktionen von Exchange, z.B. Outlook Webzugriff, ActiveSync, aber seit Exchange 2007 auch die Webservices (EWS), nutzen den IIS. Mit Exchange 2010 RBAC nutzt nun auch die Verwaltung per Powershell die WinRM-Schnittstellen und damit den IIS. Sie sehen also, dass Sie auch als Exchange Administrator ein paar Kenntnisse zum IIS benötigen. Diese Seite soll die verschiedenen Debugging-Optionen zusammenfassen.

Fehler auf dem Client

"Leider" werden Programme immer freundlicher und möchten die numerischen Fehlermeldungen gerne "lokalisiert" anzeigen. Dazu gehört auch der Internet Explorer, welche anhand der Fehlernummer des Webserver seine "lokalisierte freundliche Fehlermeldung" liefert. Dies kann und sollte man bei der Fehlersuche natürlich abschalten.

 Eine sehr gute Hilfe sind Programme wie Fiddler, die einen tieferen Einblick in die übertragenen Daten zulassen. Aber auch der IIS kann aktiv mithelfen.

Fehlermeldungen auf dem Server einschalten.

Auch auf dem Webserver gibt es eine Einstellung, die das Format der an den Client gesendete Fehlermeldungen beeinflusst. Wenn der Client diese denn anzeigt, dann sehen Sie eventuell schon mehr Details. Die Einstellung ist pro virtuellen Verzeichnis einstellbar.

In den meisten Fällen kommen Sie damit schon sehr weit.

Debugging mit IIS 7 und Error 500 und Failed Request Tracing (FREB)

Etwas kniffliger sind aber die "generellen 500er Fehler", die früher fast gar nicht zu analysieren waren. Mit dem IIS7 geht aber auch das. Der IIS 7.5 kann nämlich sehr gut für eine Fehlersuche aktiviert werden. Gerade den Fehler "500", der einem nicht viel mehr sagt, als dass der Server ein "Problem" hatte, kann damit in vielen Fällen eingekreist werden. Voraussetzung ist, dass Sie das Feature "Tracing" installiert haben

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

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

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.

Netzwerktrace

Es immer noch gutes Werkzeug ist der Microsoft Netzwerk Monitor. Wenn die Daten unverschlüsselt sind, dann können Sie die Anfragen und Antworten einfach betrachten. Selbst wenn die Daten verschlüsselt sind, müssen Sie nur den privaten Schlüssel des Webservers extrahieren und einbinden. Dann können Sie auch diese Pakete inspizieren. Interessant sind dabei Fragen wie:

Das sollen nur drei Dinge sein, die mit Netmon auf dem Netzwerk die Fehlersuche ergänzen können.

IIS, Integrierte Authentifizierung und MS08-068 mit "loopback check security feature"

Eine Falle bei der Fehlersuche ist aber gar nicht im IIS zu suchen sondern in den Anmeldediensten. Seit Windows 2003 SP1 bzw. mit dem Security Update MS08-068 wird Windows "sicherer", indem die Anmeldedienste einen "Loopback-Check" machen. Das wirkt sich z.B. immer dann aus, wenn Sie z. B. mit dem Internet Explorer auf den lokalen Server zugreifen und eine "integrierte" Anmeldung per NTLM erforderlich ist.

Beschrieben ist es in den KB-Artikel 

Und dazu passen noch einige andere Artikel

Bislang habe ich diese Effekte z. B. auf einem Windows 2003 Server zur Verwaltung von Frontpage Extensions gehabt. Auch ein Testzugriff über "Localhost" auf die Webseiten eines Lync-Servers hat das Problem aufgezeigt. Wenn Sie also mal „komische Effekte“ habt, wenn man auf einem Server einen IIS auf sich selbst ansprechen will, dann versucht es mal von einem anderen System oder lockert hier die Sperre.

Weitere Links

Tags:IIS DEBUG 500 Fehler FREB