24-04-2024, 17:10
Also, du steckst ein bisschen in der Klemme mit IIS, huh? Ich war schon öfter dort, als ich zählen kann, besonders wenn du mehrere Seiten auf demselben Server hostest. Es kann schnell chaotisch werden. Aber keine Sorge, ich habe einige Tipps und persönliche Erfahrungen, die dir helfen sollten, die Dinge in Ordnung zu bringen.
Zuerst ist das Erste, was ich mache, wenn ich mit Problemen auf einem IIS-Server konfrontiert werde, der mehrere Seiten hostet, die Protokolle zu überprüfen. Im Ernst, sie sind wie die Brotkrumen, die dich zur Lösung führen können. Die Protokolle findest du im Verzeichnis der IIS-Protokolldateien, normalerweise auf deinem C-Laufwerk im Ordner \inetpub logs\LogFiles. Jede Seite, die du konfiguriert hast, hat ihren eigenen Ordner, also musst du herausfinden, welche Seite Probleme hat.
Wenn ich an diesem Punkt der Fehlersuche bin, suche ich nach spezifischen HTTP-Statuscodes. Wenn du 404-Fehler siehst, ist es wahrscheinlich, dass die angeforderte Ressource nicht gefunden werden kann. Aber bleib nicht einfach dabei stehen; mach einen schnellen Check der Konfiguration deiner Seite, um sicherzustellen, dass die Pfade und Bindungen korrekt eingerichtet sind. Manchmal führt eine fehlende Datei zu diesen Fehlern, oder vielleicht hast du versehentlich eine Verzeichnisstruktur geändert und die Links nicht aktualisiert.
Als nächstes gibt es Bindungsprobleme. Das hat mich schon öfter erwischt, als ich zugeben möchte. Wenn du mehrere Seiten betreibst, musst du besonders auf die Bindungen achten, die du eingerichtet hast. Es ist leicht, zu übersehen, wie Seiten an spezifische Hostnamen und Ports gebunden sind. Du willst sicherstellen, dass nicht zwei Seiten versuchen, denselben Port mit demselben Hostnamen zu verwenden. Wenn du zwei Seiten mit dem Standardport 80 ohne einzigartige Host-Header eingerichtet hast, viel Glück beim Zugriff auf etwas anderes als die erste Seite, die du erstellt hast. Geh einfach in den IIS-Manager, finde die betreffende Seite und überprüfe die Bindungen.
Wenn eine Seite dir einen 403 Forbidden-Fehler zeigt, überprüfe die Berechtigungen. Ich erinnere mich, dass ich einmal eine Seite eingerichtet habe, bei der ich absolut überzeugt war, dass alles korrekt konfiguriert war, aber sie immer wieder diesen Fehler warf. Es stellte sich heraus, dass die IIS_IUSRS-Gruppe nicht die richtigen Berechtigungen für den Ordner, der die Site-Dateien enthielt, eingestellt hatte. Geh in den physischen Ordner der Seite, klicke mit der rechten Maustaste, gehe zu Eigenschaften und überprüfe die Registerkarte Sicherheit. Stelle sicher, dass deine Anwendungspool-Identität Lese- (und vielleicht Schreib-) Berechtigungen hat, insbesondere wenn deine Seite eine Art von Inhaltsverwaltung beinhaltet.
Lass uns einen Moment über Anwendungspools sprechen. Jede Seite in IIS läuft auf einem Anwendungspool, und es ist sehr häufig, dass Dinge schiefgehen, wenn diese Pools nicht richtig verwaltet werden. Wenn deine Seite dir einen 500 Internal Server Error zeigt, ist das ein Zeichen, dass der Anwendungspool der Schuldige sein könnte. Überprüfe zuerst, ob der Pool, der mit deiner Seite verbunden ist, gestartet ist. Glaub mir, ich hatte schon Morgende, an denen ich aufgetaucht bin und festgestellt habe, dass eine Seite down war, nur um zu realisieren, dass der Anwendungspool nach einem Serverneustart nicht gestartet war. Du kannst den Status direkt im IIS-Manager überprüfen; schau einfach unter Anwendungspools und sieh nach, ob der Status grün ist.
Wenn du alles überprüft hast und der Anwendungspool tatsächlich läuft, aber trotzdem Probleme hast, solltest du die Einstellungen des Anwendungspools überprüfen. In IIS gibt es verschiedene Konfigurationen, die du festlegen kannst, wie die .NET CLR-Version oder ob der Pool für 32-Bit-Anwendungen aktiviert ist. Ich hatte einmal einen Seitenabsturz, weil ich vergessen hatte, von einem 64-Bit-Pool auf einen 32-Bit-Pool zu wechseln, nachdem ich Code migriert hatte. Vergiss nicht zu überprüfen, ob der richtige Pipeline-Modus eingestellt ist - integriert oder klassisch -, denn das Verwechseln dieser kann wirklich stören, wie deine Anwendung läuft.
Vielleicht möchtest du auch einen Blick auf das Framework werfen, das deine Anwendung verwendet. Wenn du kürzlich deinen Server aktualisiert oder gepatcht hast, funktionieren manchmal bestehende Anwendungen nicht mehr richtig. Es gibt nichts Schlimmeres, als herauszufinden, dass eine Seite, die auf einer alten Version von .NET erstellt wurde, nicht funktioniert, weil dein Server auf eine neuere Version aktualisiert wurde, die inkompatibel ist. Wenn das passiert, gehe ich normalerweise zurück zum Anwendungscode oder zur Dokumentation, um zu sehen, was benötigt wird, und überprüfe, ob Konfigurationsdateien, wie web.config, Anpassungen benötigen.
Ein weiterer Trick, den ich gelernt habe, ist die Verwendung eines Tools wie Failed Request Tracing. Dieses Feature in IIS kann helfen, aufzuzeigen, was während der Anfragen schiefgeht. Es kann besonders nützlich sein, wenn die Standardprotokolle nicht genügend Klarheit bieten. Du kannst dies für bestimmte Seiten im IIS-Manager aktivieren und dann so einrichten, dass Fehler verfolgt werden, sodass du detaillierte Protokolle über jeden Schritt im Verarbeitungsprozess erhältst. Es ist wie ein Backstage-Pass, um die Show hinter den Kulissen zu sehen.
Manchmal könnte es sogar ein netzwerkbezogenes Problem sein. Du könntest so auf deine Servereinstellungen fokussiert sein, dass du lokale Konnektivitätsprobleme übersiehst. Wenn deine Seiten so konfiguriert sind, dass sie auf einer bestimmten IP-Adresse hören, stelle sicher, dass der Server diese IP richtig zugewiesen hat. Überprüfe außerdem Firewalls oder Routerkonfigurationen, die den Datenverkehr zu bestimmten Ports oder IPs blockieren könnten. Es ist überraschend, wie oft diese einfache Überprüfung alles klärt.
Betreibst du Antivirus- oder Drittanbieter-Sicherheitswerkzeuge auf deinem Server? Ich hatte einmal eine Situation, in der die Sicherheitssoftware Anfragen an eine meiner Seiten blockierte. Ich musste die Anwendungsdateien und die Ports, die IIS für HTTP-Verkehr verwendete, auf die Whitelist setzen. Diese Art der Fehlersuche dauert eine Minute, aber Mann, sie kann dir eine Menge Kopfschmerzen ersparen.
Und apropos Dienste: Wenn du benutzerdefinierte Module oder Handler konfiguriert hast, können diese manchmal Konflikte verursachen. Überprüfe noch einmal, ob deine Seite auf spezielle benutzerdefinierte HTTP-Module oder Handler angewiesen ist und ob diese über alle Instanzen hinweg korrekt eingerichtet sind. Ich hatte ein seltsames Problem mit einem Modul, das für die URL-Umleitung gedacht war und mit einem anderen Skript in Konflikt geriet. Nach einigem Ausprobieren, bei dem ich sichergestellt habe, dass nur eine Instanz aktiv war, wurde das Problem gelöst.
Zuletzt, unterschätze niemals den Wert eines guten Neustarts. Es klingt einfach, aber manchmal braucht der Server einfach einen kleinen Wachruf. Wenn du all diese Fehlersuche-Schritte durchgegangen bist und nichts scheint sich zu ändern, könnte ein Neustart des IIS-Dienstes (oder, wenn du mutig bist, des gesamten Servers) das Hickhack, das die Probleme verursacht, beheben. Lass nur vorher alle betroffenen Benutzer wissen, bevor du es tust!
Die Fehlersuche in IIS mit mehreren Seiten ist nicht immer unkompliziert. Es braucht ein bisschen Geduld und ein Auge fürs Detail, aber du wirst mit der Übung besser. Ich kann nicht versprechen, dass jedes Problem beim ersten Versuch gelöst wird, aber diese Techniken haben mich aus vielen kniffligen Situationen gerettet. Mach weiter, lerne aus jedem Problem, dem du begegnest, und du wirst bald ein echter IIS-Profi sein!
Ich hoffe, du fandest meinen Beitrag nützlich. Übrigens, hast du eine gute Backup-Lösung für Windows Server eingerichtet? In diesem Beitrag erkläre ich, wie man Windows Server richtig sichert.
Zuerst ist das Erste, was ich mache, wenn ich mit Problemen auf einem IIS-Server konfrontiert werde, der mehrere Seiten hostet, die Protokolle zu überprüfen. Im Ernst, sie sind wie die Brotkrumen, die dich zur Lösung führen können. Die Protokolle findest du im Verzeichnis der IIS-Protokolldateien, normalerweise auf deinem C-Laufwerk im Ordner \inetpub logs\LogFiles. Jede Seite, die du konfiguriert hast, hat ihren eigenen Ordner, also musst du herausfinden, welche Seite Probleme hat.
Wenn ich an diesem Punkt der Fehlersuche bin, suche ich nach spezifischen HTTP-Statuscodes. Wenn du 404-Fehler siehst, ist es wahrscheinlich, dass die angeforderte Ressource nicht gefunden werden kann. Aber bleib nicht einfach dabei stehen; mach einen schnellen Check der Konfiguration deiner Seite, um sicherzustellen, dass die Pfade und Bindungen korrekt eingerichtet sind. Manchmal führt eine fehlende Datei zu diesen Fehlern, oder vielleicht hast du versehentlich eine Verzeichnisstruktur geändert und die Links nicht aktualisiert.
Als nächstes gibt es Bindungsprobleme. Das hat mich schon öfter erwischt, als ich zugeben möchte. Wenn du mehrere Seiten betreibst, musst du besonders auf die Bindungen achten, die du eingerichtet hast. Es ist leicht, zu übersehen, wie Seiten an spezifische Hostnamen und Ports gebunden sind. Du willst sicherstellen, dass nicht zwei Seiten versuchen, denselben Port mit demselben Hostnamen zu verwenden. Wenn du zwei Seiten mit dem Standardport 80 ohne einzigartige Host-Header eingerichtet hast, viel Glück beim Zugriff auf etwas anderes als die erste Seite, die du erstellt hast. Geh einfach in den IIS-Manager, finde die betreffende Seite und überprüfe die Bindungen.
Wenn eine Seite dir einen 403 Forbidden-Fehler zeigt, überprüfe die Berechtigungen. Ich erinnere mich, dass ich einmal eine Seite eingerichtet habe, bei der ich absolut überzeugt war, dass alles korrekt konfiguriert war, aber sie immer wieder diesen Fehler warf. Es stellte sich heraus, dass die IIS_IUSRS-Gruppe nicht die richtigen Berechtigungen für den Ordner, der die Site-Dateien enthielt, eingestellt hatte. Geh in den physischen Ordner der Seite, klicke mit der rechten Maustaste, gehe zu Eigenschaften und überprüfe die Registerkarte Sicherheit. Stelle sicher, dass deine Anwendungspool-Identität Lese- (und vielleicht Schreib-) Berechtigungen hat, insbesondere wenn deine Seite eine Art von Inhaltsverwaltung beinhaltet.
Lass uns einen Moment über Anwendungspools sprechen. Jede Seite in IIS läuft auf einem Anwendungspool, und es ist sehr häufig, dass Dinge schiefgehen, wenn diese Pools nicht richtig verwaltet werden. Wenn deine Seite dir einen 500 Internal Server Error zeigt, ist das ein Zeichen, dass der Anwendungspool der Schuldige sein könnte. Überprüfe zuerst, ob der Pool, der mit deiner Seite verbunden ist, gestartet ist. Glaub mir, ich hatte schon Morgende, an denen ich aufgetaucht bin und festgestellt habe, dass eine Seite down war, nur um zu realisieren, dass der Anwendungspool nach einem Serverneustart nicht gestartet war. Du kannst den Status direkt im IIS-Manager überprüfen; schau einfach unter Anwendungspools und sieh nach, ob der Status grün ist.
Wenn du alles überprüft hast und der Anwendungspool tatsächlich läuft, aber trotzdem Probleme hast, solltest du die Einstellungen des Anwendungspools überprüfen. In IIS gibt es verschiedene Konfigurationen, die du festlegen kannst, wie die .NET CLR-Version oder ob der Pool für 32-Bit-Anwendungen aktiviert ist. Ich hatte einmal einen Seitenabsturz, weil ich vergessen hatte, von einem 64-Bit-Pool auf einen 32-Bit-Pool zu wechseln, nachdem ich Code migriert hatte. Vergiss nicht zu überprüfen, ob der richtige Pipeline-Modus eingestellt ist - integriert oder klassisch -, denn das Verwechseln dieser kann wirklich stören, wie deine Anwendung läuft.
Vielleicht möchtest du auch einen Blick auf das Framework werfen, das deine Anwendung verwendet. Wenn du kürzlich deinen Server aktualisiert oder gepatcht hast, funktionieren manchmal bestehende Anwendungen nicht mehr richtig. Es gibt nichts Schlimmeres, als herauszufinden, dass eine Seite, die auf einer alten Version von .NET erstellt wurde, nicht funktioniert, weil dein Server auf eine neuere Version aktualisiert wurde, die inkompatibel ist. Wenn das passiert, gehe ich normalerweise zurück zum Anwendungscode oder zur Dokumentation, um zu sehen, was benötigt wird, und überprüfe, ob Konfigurationsdateien, wie web.config, Anpassungen benötigen.
Ein weiterer Trick, den ich gelernt habe, ist die Verwendung eines Tools wie Failed Request Tracing. Dieses Feature in IIS kann helfen, aufzuzeigen, was während der Anfragen schiefgeht. Es kann besonders nützlich sein, wenn die Standardprotokolle nicht genügend Klarheit bieten. Du kannst dies für bestimmte Seiten im IIS-Manager aktivieren und dann so einrichten, dass Fehler verfolgt werden, sodass du detaillierte Protokolle über jeden Schritt im Verarbeitungsprozess erhältst. Es ist wie ein Backstage-Pass, um die Show hinter den Kulissen zu sehen.
Manchmal könnte es sogar ein netzwerkbezogenes Problem sein. Du könntest so auf deine Servereinstellungen fokussiert sein, dass du lokale Konnektivitätsprobleme übersiehst. Wenn deine Seiten so konfiguriert sind, dass sie auf einer bestimmten IP-Adresse hören, stelle sicher, dass der Server diese IP richtig zugewiesen hat. Überprüfe außerdem Firewalls oder Routerkonfigurationen, die den Datenverkehr zu bestimmten Ports oder IPs blockieren könnten. Es ist überraschend, wie oft diese einfache Überprüfung alles klärt.
Betreibst du Antivirus- oder Drittanbieter-Sicherheitswerkzeuge auf deinem Server? Ich hatte einmal eine Situation, in der die Sicherheitssoftware Anfragen an eine meiner Seiten blockierte. Ich musste die Anwendungsdateien und die Ports, die IIS für HTTP-Verkehr verwendete, auf die Whitelist setzen. Diese Art der Fehlersuche dauert eine Minute, aber Mann, sie kann dir eine Menge Kopfschmerzen ersparen.
Und apropos Dienste: Wenn du benutzerdefinierte Module oder Handler konfiguriert hast, können diese manchmal Konflikte verursachen. Überprüfe noch einmal, ob deine Seite auf spezielle benutzerdefinierte HTTP-Module oder Handler angewiesen ist und ob diese über alle Instanzen hinweg korrekt eingerichtet sind. Ich hatte ein seltsames Problem mit einem Modul, das für die URL-Umleitung gedacht war und mit einem anderen Skript in Konflikt geriet. Nach einigem Ausprobieren, bei dem ich sichergestellt habe, dass nur eine Instanz aktiv war, wurde das Problem gelöst.
Zuletzt, unterschätze niemals den Wert eines guten Neustarts. Es klingt einfach, aber manchmal braucht der Server einfach einen kleinen Wachruf. Wenn du all diese Fehlersuche-Schritte durchgegangen bist und nichts scheint sich zu ändern, könnte ein Neustart des IIS-Dienstes (oder, wenn du mutig bist, des gesamten Servers) das Hickhack, das die Probleme verursacht, beheben. Lass nur vorher alle betroffenen Benutzer wissen, bevor du es tust!
Die Fehlersuche in IIS mit mehreren Seiten ist nicht immer unkompliziert. Es braucht ein bisschen Geduld und ein Auge fürs Detail, aber du wirst mit der Übung besser. Ich kann nicht versprechen, dass jedes Problem beim ersten Versuch gelöst wird, aber diese Techniken haben mich aus vielen kniffligen Situationen gerettet. Mach weiter, lerne aus jedem Problem, dem du begegnest, und du wirst bald ein echter IIS-Profi sein!
Ich hoffe, du fandest meinen Beitrag nützlich. Übrigens, hast du eine gute Backup-Lösung für Windows Server eingerichtet? In diesem Beitrag erkläre ich, wie man Windows Server richtig sichert.
