Windows Server 2025 / IIS-Bindungen und Anwendungspools für zwei Websites einrichten

Eine IIS-Bindung wählt eine Website anhand von Protokoll, IP-Adresse, Port und Hostname aus. Der Anwendungspool organisiert Ausführung und Identität seiner Anwendungen; für die richtige Seite müssen DNS, Bindung, Inhaltsordner und Pool zusammenpassen.

Vier Konfigurationsebenen unterscheiden

Ein DNS-Eintrag löst einen Namen in eine Adresse auf, erstellt aber keine IIS-Bindung. Umgekehrt registriert eine Bindung keinen DNS-Namen. Die IIS-Bindungsreferenz erläutert Protokoll sowie IP-, Port- und Hostinformationen. Prüfen Sie vorhandene Kombinationen aller Sites auf dem Server vor dem Hinzufügen oder Ändern; verschiedene Anzeigenamen der Sites allein genügen nicht.

Beginnen Sie mit der funktionierenden LabSite auf WEB1 unter 172.24.50.30:8080, ihrem Ordner und LabSitePool. Nutzen Sie denselben erlaubten Client und die bereits auf TCP 8080 begrenzte Laborregel. Erfassen Sie auf WEB1 vor Änderungen vollständige Bindungen, Pfad, Pool und Zustand und arbeiten Sie als Administrator. Verwenden Sie auf DC1 die vorgesehenen DNS-Verwaltungsrechte. Hinzu kommen nur web.lab.example.test und status.lab.example.test im Labor, ohne öffentliches DNS oder eine produktive Website zu ändern. Sind StatusSite, ihr Ordner, Pool oder die Einträge bereits vorhanden, klären Sie den Zweck und stoppen Sie vor einer Ersetzung.

DNS-Namen hinzufügen und prüfen

1. Öffnen Sie auf DC1 DNS-Manager → Forward-Lookupzonen → lab.example.test. Bestätigen Sie die vorhandene Übungszone auf diesem Server, nicht ad.example.test.
2. Prüfen Sie, ob web bereits als A-Eintrag, Alias oder anderer Eintrag existiert. Nur bei freiem Namen erstellen Sie einen neuen Host (A) web mit 172.24.50.30. Überschreiben Sie keinen anderen Wert; ein PTR ist für diesen HTTP-Zugriff nicht erforderlich.
3. Prüfen und erstellen Sie status entsprechend mit derselben Adresse. Dokumentieren Sie beide Namen und Werte als eigene Testobjekte.
4. Bestätigen Sie, dass CLIENT1 DC1 unter 172.24.50.10 für internes DNS verwendet. Der ausdrücklich in PowerShell befragte DNS-Server muss nicht dem vom Browser verwendeten entsprechen.
5. Fragen Sie von CLIENT1 beide Namen ab und prüfen Sie die zurückgegebenen Adresseinträge. Beheben Sie Fehler oder abweichende Adressen zuerst in DNS, statt sie mit unpassenden Bindungsänderungen zu überdecken.

Resolve-DnsName web.lab.example.test -Server 172.24.50.10
Resolve-DnsName status.lab.example.test -Server 172.24.50.10

Der Parameter Server von Resolve-DnsName bestimmt den befragten DNS-Server. Für beide Namen wird eine A-Antwort 172.24.50.30 erwartet. Ohne Type fragen die Befehle standardmäßig A und AAAA ab; erfinden Sie deshalb keine IPv6-Antwort für ein reines IPv4-Labor. Die ausdrückliche Abfrage beweist nicht, dass der Browser DC1 nutzt. Prüfen Sie zusätzlich Clientkonfiguration und reguläre Namensauflösung vor dem HTTP-Test.

lab.example.test ist die DNS-Übungszone des Kurses, getrennt von der Active-Directory-Domäne ad.example.test. Eine dateibasierte Zone repliziert nicht automatisch nach DC2, nur weil der Server Domänencontroller ist. Fehlt die Zone, prüfen Sie DC1 und die vorgesehene Einrichtung. Legen Sie Einträge nicht wegen ähnlicher Namen in der AD-Zone an und ändern Sie nicht den Zonenspeichertyp, um weiterzukommen.

Hostnamenbindung für die erste Site konfigurieren

1. Wählen Sie im IIS-Manager → LabSite → Bindungen genau http / 172.24.50.30 / 8080 mit leerem Hostnamen. Dokumentieren Sie die Werte vor dem Bearbeiten.
2. Ändern Sie nur den Hostnamen auf web.lab.example.test und bestätigen Sie. Lassen Sie IP, Port, Typ, Pfad und Pool unverändert.
3. Prüfen Sie anschließend, dass keine zweite Bindung mit derselben vollständigen Kombination besteht. Fügen Sie nicht zusätzlich eine unnötige Kopie ohne Hostnamen hinzu.
4. Öffnen Sie auf CLIENT1 http://web.lab.example.test:8080/. Erwartet wird die LabSite-Seite der vorherigen Übung; prüfen Sie URL und Inhalt, nicht nur irgendeine Antwort.

Der HTTP-Host-Header bezeichnet den angeforderten Namen, authentifiziert aber keinen Benutzer. Die Kenntnis von web.lab.example.test belegt keine Identität und erteilt keine weiteren Rechte. Nach Ersetzen des leeren Hostnamens kann direkter IP-Zugriff LabSite nicht mehr auswählen oder wegen einer anderen passenden Bindung eine andere Antwort liefern. Prüfen Sie jede Site mit vorgesehenem Namen und Port.

Prüfen Sie bei Fehlern zuerst die Auflösung nach 172.24.50.30 und vergleichen Sie Protokoll, Port 8080 und angeforderten Namen mit der tatsächlichen Bindung. Bei einer falschen Seite kontrollieren Sie auch Bindungen ohne Hostnamen und den gewählten Inhaltsordner. Selbst mit korrektem DNS können Netzwerkweg, Firewall, Rechte, Authentifizierung oder Pool fehlerhaft sein. Ersetzen Sie internes DNS nicht durch öffentliches DNS und schalten Sie die Firewall nicht pauschal aus.

Zweite Site mit eigener Identität erstellen

1. Erstellen Sie C:\Sites\StatusSite nur, wenn der Ordner nicht existiert. Verwenden Sie eine eigene UTF-8-Datei index.html: Kopieren Sie dafür das vollständige LabSite-Dokument aus der vorherigen Übung und ändern Sie nur in dieser Kopie title und h1 auf StatusSite sowie den Absatz auf This page is served by StatusSite on WEB1. Behalten Sie die HTML-Struktur und verändern Sie LabSite nicht. Prüfen Sie die tatsächliche Erweiterung.
2. Erstellen Sie StatusSitePool nur bei freiem Namen, mit No Managed Code und ApplicationPoolIdentity. Verwenden Sie nicht aus Bequemlichkeit LabSitePool.
3. Öffnen Sie Eigenschaften → Sicherheit des neuen Ordners, wählen Sie WEB1 als Suchpfad und fügen Sie IIS AppPool\StatusSitePool hinzu. Gewähren Sie Lesen und Ausführen, Ordnerinhalt anzeigen und Lesen für Ordner und Datei, mit erhaltenen SYSTEM- und Administratorrechten. Gewähren Sie dem Webprozess weder Schreiben noch Vollzugriff.
4. Erstellen Sie unter Sites → Website hinzufügen StatusSite mit C:\Sites\StatusSite und StatusSitePool. Prüfen Sie alle drei Angaben.
5. Verwenden Sie http / 172.24.50.30 / 8080 / status.lab.example.test. Kopieren Sie nicht web.lab.example.test und ändern Sie den Port nicht so, dass der Vergleich verloren geht.
6. Aktivieren Sie für StatusSite Anonyme Authentifizierung und wählen Sie Anwendungspoolidentität. Prüfen Sie aktiviertes Standarddokument mit index.html sowie startfähigen Pool und Site.
7. Öffnen Sie auf CLIENT1 http://web.lab.example.test:8080/ und http://status.lab.example.test:8080/. Erwartet werden unterschiedliche Meldungen von LabSite und StatusSite. Bei gleichen Inhalten prüfen Sie Bindung, Pfad und Datei, bevor Sie einen Pool stoppen.

Die Sites teilen IP und Port, weil der Hostname ihre HTTP-Anfragen unterscheidet. Duplizieren Sie weder die vollständige Kombination noch versehentlich denselben Namen für beide Sites. Prüfen Sie, welche Anfragen eine verbleibende Bindung ohne Namen erhält; entfernen Sie fremde Bindungen nicht ohne Kenntnis ihrer Nutzung. Namensunterscheidung ersetzt weder Authentifizierung noch die gesonderte Einrichtung von HTTPS-Zertifikaten.

Getrennte Pools erleichtern getrennte Verwaltung von Identität, Stoppen und Wiederverwendung des Arbeitsprozesses. Sie teilen weiterhin Betriebssystem, Kernel, Speicher und Hostressourcen. Sie bieten deshalb nicht dieselbe Grenze wie getrennte VMs und garantieren keine Begrenzung einer Überlastung. Wenden Sie anhand der Anleitung zu Anwendungspoolidentitäten minimale Rechte je Identität an; StatusSitePool benötigt keinen unnötigen Zugriff auf die Dateien der anderen Site.

Stoppen und Wiederverwenden des Pools vergleichen

1. Dokumentieren Sie erfolgreiche Antworten beider Sites, URLs, Zeitpunkt, Poolzuordnungen und Zustände beider Pools. Ein bereits vorher bestehender Fehler beweist keine Auswirkung des Stoppens.
2. Wählen Sie im IIS-Manager → Anwendungspools ausschließlich StatusSitePool und Beenden. Prüfen Sie den Namen vor der Aktion; stoppen Sie weder LabSitePool noch IIS insgesamt.
3. Senden Sie von CLIENT1 neue Anfragen an beide Namen, damit eine zwischengespeicherte Browserseite nicht als neue Serverantwort erscheint. Prüfen Sie HTTP-Status im Netzwerkbereich und Protokolle und erfassen Sie beide Sites getrennt.
4. Wählen Sie StatusSitePool → Starten und bestätigen Sie die Wiederherstellung mit einer neuen Anfrage. Prüfen Sie ebenfalls LabSite, bevor Sie den Versuch beenden.

Bei gestopptem StatusSitePool kann dessen Site HTTP 503 liefern, während LabSite über den anderen Pool weiter korrekt antworten sollte. Prüfen Sie beide Antworten, statt einen beliebigen Fehler als ausreichenden Isolationsnachweis zu betrachten. Fallen beide aus, kontrollieren Sie Poolzuordnung, Sitezustand und gemeinsame Ressourcen. Unterscheiden Sie Stoppen einer Site von Stoppen eines Pools; verwenden Sie für diesen Vergleich weder iisreset noch einen Serverneustart.

Die Wiederverwendung eines Anwendungspools ersetzt seinen Arbeitsprozess und kann Sitzungen im Arbeitsspeicher oder laufende Aufgaben beeinflussen. IIS unterstützt Auslösebedingungen und Einstellungen für überlappende Prozesse; eine statische Seite beweist keine unterbrechungsfreie Anwendung. Vergleichen Sie die manuelle Aktion Wiederverwenden gegebenenfalls nur an StatusSitePool, nachdem beide Sites wieder funktionieren. Halten Sie Zustand und Anfragen vorher und nachher fest und prüfen Sie beide Seiten am Ende, ohne Grenzwerte oder Zeitpläne zur Fehlerprovokation zu ändern. Entfernen Sie zur Bereinigung nur StatusSite, nach Prüfung anderer Anwendungen StatusSitePool, eigene entbehrliche Dateien und den selbst angelegten status-Eintrag. Behalten Sie LabSite samt web-Bindung für die HTTPS-Übung, falls Sie fortfahren. Beenden Sie hier, stellen Sie die dokumentierte ursprüngliche Bindung wieder her und entfernen nach Abhängigkeitsprüfung nur eigene neue DNS-Einträge, nicht die Zone oder Domäneneinträge.