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.

Wenn Sie ein Tracing auf dem Client nutzen können, dann sollten Sie sich Fiddler oder die Debuggertools der Browser anschauen
https://docs.microsoft.com/en-us/azure/azure-portal/capture-browser-trace

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)

Siehe dazu die eigene Seite IIS - Webserver Troubleshooting

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:

  • Kommt die Anfrage überhaupt an
    Es ist gar nicht mal selten, dass Sie in ihrem Browser eine Adresse eingeben und gar nicht dort landen. Falsche Namensauflösung, Proxyserver, Firewalls machen oft einen Strich durch die Rechnung. Ein Netmon auf dem Client, dem Server oder "unterwegs" kann bei der Suche nach der TCP-Verbindung sehr hilfreich sein.
  • Größe
    Dann ist interessant, wie groß z.B. die Anfrage ist. Gerade "übergroße" Pakete können von Webserver, Proxyserver oder Firewalls als "Buffer Overflow"-Angriff gewertet und verändert werden.
  • Inhalt
    Leider geben weder Internet Explorer noch Webserver in den Logs Auskunft darüber, welche Anmeldedaten verwendet werden. Die Anmeldung ist entweder erfolgreich oder fehlerhaft. Erst ein Blick in die HTTP-Daten erlaubt Rückschlüsse auf die vom Webserver angebotenen und vom Client verwendeten Anmeldeverfahren. Auch wenn Sie die NTLM-Hashwerte nicht verstehen müssen, so sehen Sie oftmals genug Informationen zur Fehlersuche.

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 

  • 896861 You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version

Und dazu passen noch einige andere Artikel

  • 957097  MS08-068: Vulnerability in SMB could allow remote code execution
  • 926642 Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path"
  • 917664  Error message when you try to install Microsoft Operations Manager 2005 Reporting: "Error code: -2147467259 (Unspecified error)"
  • 281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
  • 911149 Error message in Internet Explorer when you try to access a Web site that requires Kerberos authentication on a Windows XP-based computer: "HTTP Error 401 - unauthorized: Access is denied due to invalid credentials"
    Windows XP SP2 hat einen Bug, der in SP1 nicht da war und SP3 gefixt wurde: IE nutzt dann den Hostnamen anstelle des CNAME
  • Kerberos fails when using CNAME records
    http://www.marcvalk.net/2009/06/kerberos-fails-when-using-cname-records/
  • Kerberos für MOSS
    http://jakeswebpad.blogspot.com/2007/09/kerberos-for-moss.html
  • 870911 How to consolidate print servers by using DNS alias (CNAME) records in Windows Server 2003 and in Windows 2000 Server
  • Fix: Access CNAME based URL from same server (SharePoint, CRM etc.)
    http://techontip.wordpress.com/2011/03/22/fix-access-cname-based-URL-from-same-server-sharepoint-crm-etc/

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