Recent Blog Posts View All
Fixing memory leaks is easier than you think Tuesday April 5, 2022 by mvolo Memory leaks can be causing poor website performance, and blowing out your cloud hosting costs.You can now easily reduce memory usage and fix memory leaks, check out our Diagnose memory us...
Fixing memory leaks is easier than you think Tuesday April 5, 2022 by mvolo Memory leaks can be causing poor website performance, and blowing out your cloud hosting costs.You can now easily reduce memory usage and fix memory leaks, check out our Diagnose memory us...
Async await hangs in ASP.NET Core, MVC and WebAPI Tuesday March 8, 2022 by mvolo Debugging async hangs in ASP.NET core, MVC and WebAPI apps can be extra hard!To help, we added async task support to LeanSentry hang diagnostics. Check out the Diagnose async hangs in ASP.NET Core,...
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.
"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.
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.
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.
Troubleshoot IIS7 errors like a pro
Where did my IIS7 server go? Troubleshooting "service unavailable" errors
Troubleshooting Failed Requests using Tracing in IIS 7
Making Failed Request Tracing More Approachable
Troubleshooting Failed Requests using Tracing in IIS 7
Troubleshooting HTTP 500.19 Errors in IIS 7
Troubleshooting a simple error message using FREB
FREB Viewer
Recovering FREB.XSL after deleting it
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.
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.
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.
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
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
Kerberos für MOSS
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.)
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.
Plesk für Windows nutzt für das Hosting und Verwalten von Websites den IIS-HTTP-Server
Die Standardkonfiguration für Webserver
Die IIS-Standardkonfiguration wird über IIS-Tools (z.B. den IIS-Manager) vom Hosting-Provider definiert. Die Standardkonfiguration wird auf alle Websites auf dem Server angewendet. Dennoch können einige Konfigurationsparameter für einzelne Websites direkt in der Plesk Benutzeroberfläche geändert werden.
Benutzerdefinierte Konfiguration für Webserver
Website-Betreiber benötigen unter Umständen benutzerdefinierte Webserver-Funktionalitäten, die mit der Standardkonfiguration nicht gegeben sind. Dies können zum Beispiel sonst nicht übliche Arten von Indexdateien oder die Einschränkung des Zugriffs auf die Website anhand der IP-Adresse sein.
Sie und Ihre Website-Betreiber können Webserver-Einstellungen für eine Website konfigurieren, indem Sie die IIS-Einstellungen im Kunden-Panel angeben. Die benutzerdefinierte Website-Konfiguration überschreibt die Standardkonfiguration. Einzelheiten zur benutzerdefinierten IIS-Konfiguration finden Sie im Abschnitt Anpassen der IIS-Einstellungen für Websites.
Anpassen der IIS-Einstellungen für Websites
Sie oder Ihre Website-Betreiber können die IIS-Konfiguration für eine bestimmte Website im Kunden-Panel anpassen. Dazu gehen Sie zu Websites & Domains >
Leave a Comment