IIS und Web-Workloads

Fast jedes IIS-Missverständnis geht auf eine Verwechslung von Website, Anwendung und Anwendungspool zurück — Bindungen und Zertifikate hängen an der einen Ebene, Identität und Rechte an einer anderen. Dieses Modul sortiert das und behandelt die Voreinstellungen, die als Anwendungsfehler gemeldet werden: ein Recycling alle 29 Stunden, das im Wochenverlauf durch die Geschäftszeit wandert, ein Leerlauf nach zwanzig Minuten, der die erste Anfrage am Morgen zäh macht, und eine Poolidentität, die es in der Benutzerverwaltung nicht gibt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Drei Begriffe, die ständig verwechselt werden

Fast jedes IIS-Missverständnis lässt sich auf eine Verwechslung dieser drei Begriffe zurückführen. Sie klingen ähnlich, gehören verschiedenen Ebenen an und werden getrennt konfiguriert.

Website: Der Eingang von außen. Sie trägt die Bindungen: IP-Adresse, Port, Hostname, Zertifikat.
Anwendung: Ein Pfad innerhalb der Website mit eigenem Inhalt und eigener web.config.
Anwendungspool: Der Prozess, in dem der Code läuft. Er trägt Identität, Recyclingregeln und Isolation.

Die wichtigste Folge daraus: Bindungen und Zertifikate hängen an der Website, Rechte und Identität am Anwendungspool. Wer ein Berechtigungsproblem an der Website sucht oder ein Zertifikatsproblem am Pool, sucht auf der falschen Ebene.

Der Anwendungspool ist die Isolationsgrenze

Zwei Anwendungen im selben Pool teilen sich einen Arbeitsprozess. Das bedeutet: dieselbe Identität, denselben Speicher, dasselbe Schicksal bei einem Absturz und dieselbe Unterbrechung bei jedem Recycling.

Was das im Betrieb kostetEin Speicherleck in einer Anwendung beendet den Prozess — und damit auch die andere. Eine Rechteerweiterung für Anwendung A gilt automatisch für Anwendung B, weil beide unter derselben Identität laufen. Und ein geplantes Recycling für ein Update an A unterbricht auch B. Ein eigener Pool je Anwendung kostet etwas Speicher und beseitigt alle drei Kopplungen — das ist meistens der bessere Tausch.

Umgekehrt gilt: Wer Anwendungen bündelt, sollte es begründen können. Zwanzig Anwendungen in zwanzig Pools brauchen mehr Arbeitsspeicher als zwanzig in einem — auf einem knapp bemessenen Server ist das ein echtes Argument, nur eben eines, das man kennen und benennen muss.

Zwei Anwendungen, ein Pool

Szenario

Auf einem Webserver laufen eine interne Auswertung und ein Bestellportal im selben Anwendungspool. Die Auswertung braucht Lesezugriff auf eine Dateifreigabe mit Personaldaten. Der Betreiber will dafür die Poolidentität berechtigen.

Anforderungen

Die Auswertung soll die Freigabe lesen können.
Das Bestellportal soll es nicht können.

Schritte

Feststellen, unter welcher Identität beide laufen — dieselbe, weil sie sich den Pool teilen.
Daraus folgt: Eine Berechtigung für die Auswertung gilt automatisch auch für das Bestellportal.
Einen zweiten Anwendungspool anlegen und die Auswertung dorthin verschieben.
Die Freigabe auf IIS AppPool\Auswertung berechtigen, nicht auf die gemeinsame Identität.
Prüfen, dass das Bestellportal die Freigabe weiterhin nicht erreicht — der negative Test.

Merksatz: Die Anforderung „A darf, B nicht“ ist mit einem gemeinsamen Pool nicht erfüllbar, egal wie sorgfältig die Rechte gesetzt werden. Die Isolationsgrenze ist der Pool; alles darin teilt sich eine Identität.

Die Identität eines Anwendungspools

Seit IIS 7.5 läuft ein neu angelegter Pool voreingestellt unter der Anwendungspoolidentität — einem virtuellen Konto, das den Namen des Pools trägt und beim Anlegen automatisch entsteht.

ApplicationPoolIdentity: Voreinstellung. Eigenes virtuelles Konto je Pool, niedrig privilegiert.
NetworkService: Zugriff auf Netzressourcen als Computerkonto. Mehr Rechte, geteilt mit anderen Diensten.
LocalService: Tritt im Netz anonym auf — für Netzzugriffe unbrauchbar.
LocalSystem: Weitreichende Rechte auf dem lokalen Rechner. Die Dokumentation nennt das ausdrücklich ein ernstes Sicherheitsrisiko.
SpecificUser: Ein eigenes Konto mit Benutzername und Kennwort.

Warum die Voreinstellung die richtige istVor der Anwendungspoolidentität liefen Arbeitsprozesse als NetworkService — dieselbe Identität wie viele Windows-Systemdienste. Da IIS voreingestellt fremden Code ausführt, konnten sich Dienste unter derselben Identität gegenseitig beeinflussen. Genau deshalb bekam jeder Pool ein eigenes virtuelles Konto. Wer die Identität ohne Grund auf eine der eingebauten zurückstellt, macht diese Trennung rückgängig.

Die beiden mittleren Zeilen der Tabelle erklären ein wiederkehrendes Fehlerbild. Soll ein Anwendungspool auf eine Netzwerkfreigabe zugreifen, scheitert er unter der Anwendungspoolidentität, weil dieses virtuelle Konto nur lokal existiert. Unter NetworkService tritt er als Computerkonto auf und lässt sich auf der Freigabe berechtigen; unter LocalService bleibt er anonym und ist im Netz überhaupt nicht adressierbar. Wer die Wahl trifft, ohne diesen Unterschied zu kennen, vergibt Rechte an eine Identität, die am Ziel gar nicht auftritt — genau der Fall aus dem Modul über Dienste und Aufgabenplanung.

Rechte für ein Konto, das nicht existiert

Die Anwendungspoolidentität hat eine Eigenschaft, die regelmäßig für Verwirrung sorgt: Es ist kein echtes Benutzerkonto. Es taucht in der Benutzerverwaltung nicht auf, und man kann es dort nicht suchen.

Berechtigen lässt es sich trotzdem — über den Namen IIS AppPool\<Poolname>. Beim Anlegen eines Pools erzeugt IIS eine Sicherheitskennung mit dem Namen des Pools; ab dann lassen sich Ressourcen darauf berechtigen.

In der Rechteoberfläche IIS AppPool\MeinPool eintippen — die Suche findet es nicht, die direkte Eingabe funktioniert.
icacls C:\Daten\App /grant "IIS AppPool\MeinPool:(OI)(CI)M" auf der Kommandozeile.
Der Name folgt dem Poolnamen: Wird der Pool umbenannt, zeigen die vergebenen Rechte ins Leere.

Der Fehler, der daraus entstehtWeil das Konto nicht auffindbar ist, greifen viele stattdessen zu IIS_IUSRS oder gleich zu Authentifizierten Benutzern — und geben damit allen Anwendungspools Zugriff statt einem. Die Isolation, für die es die virtuellen Konten gibt, ist damit wieder aufgehoben, und zwar an genau der Stelle, an der sie zählt: bei den Daten.

Recycling passiert nicht nachts

Ein Anwendungspool wird in regelmäßigen Abständen neu gestartet. Der Standardwert dafür ist der Wert, der die meisten Überraschungen erzeugt.

29 Stunden, nicht 24Die Voreinstellung für das zeitgesteuerte Recycling ist 29:00:00 — 29 Stunden, nicht ein Tag. Das ist Absicht: Ein fester Tageswert würde auf allen Servern zur selben Zeit auslösen. Die Folge ist, dass das Recycling jeden Tag fünf Stunden später stattfindet und im Lauf einer Woche einmal durch die Hauptgeschäftszeit wandert. Wer eine kurze Unterbrechung zur immer gleichen Nachtzeit will, muss das ausdrücklich als festen Zeitpunkt konfigurieren und den Intervallwert abschalten.

time: Zeitgesteuertes Recycling. Voreinstellung 29 Stunden.
schedule: Feste Uhrzeiten. Der Weg für ein planbares Fenster.
requests: Nach einer Zahl von Anfragen. Voreinstellung 0, also abgeschaltet.
memory / privateMemory: Nach Speicherverbrauch. Voreinstellung 0, also abgeschaltet.

Die beiden letzten Zeilen sind der eigentliche Hebel bei einer Anwendung mit Speicherleck: Ein Recycling bei überschrittenem privatem Speicher fängt den Ausfall ab, statt ihn abzuwarten. Es behebt das Leck nicht — und wer es einrichtet, sollte den Grund dokumentieren, sonst gilt das Symptom irgendwann als gelöst.

Zu bedenken ist außerdem, was ein Recycling für laufende Anfragen bedeutet. IIS startet dabei einen neuen Arbeitsprozess und lässt den alten seine offenen Anfragen zu Ende bearbeiten — ein überlappender Wechsel, der für kurze Anfragen unbemerkt bleibt. Für eine Anwendung mit langlaufenden Vorgängen oder mit Zustand im Prozessspeicher ist er es nicht: Sitzungen, die im Arbeitsspeicher gehalten werden, sind nach dem Wechsel weg. Wer Sitzungszustand außerhalb des Prozesses ablegt, macht Recycling unsichtbar; wer es nicht tut, muss den Zeitpunkt planen.

Die erste Anfrage nach zwanzig Minuten

Ein Arbeitsprozess, der nichts zu tun hat, wird beendet. Der Standardwert für diesen Leerlauf ist 00:20:00 — zwanzig Minuten. Danach startet die nächste Anfrage den Prozess neu, und der Anwender wartet.

Warum das als Anwendungsfehler gemeldet wird„Morgens ist es immer langsam, danach geht es“ ist die klassische Beschreibung dieses Verhaltens — und sie klingt nach einem Problem der Anwendung. Tatsächlich ist es eine Konfigurationsvoreinstellung, die auf einem Server mit wenigen Zugriffen genau das bewirkt, wofür sie gebaut wurde: Speicher freigeben. Für eine intern genutzte Anwendung mit Nutzung ab acht Uhr ist der Wert oft falsch gewählt, nicht die Anwendung langsam.

Abschalten lässt sich der Leerlauf mit dem Wert 00:00:00. Neuer ist die Möglichkeit, den Prozess statt zu beenden nur auszusetzen — der Speicher wird dann freigegeben, der Neustart entfällt. Beides ist ein Tausch zwischen Speicherverbrauch und Antwortzeit der ersten Anfrage, und die richtige Wahl hängt davon ab, wie viele Anwendungen sich diesen Server teilen.

Eine IP, ein Port, viele Namen

Eine Bindung besteht aus IP-Adresse, Port und optional einem Hostnamen. Der Hostname ist der Teil, der mehrere Websites auf demselben Port unterscheidbar macht — er wird aus der Anfrage gelesen, nicht aus der Verbindung.

Ein Listener, mehrere Namen. Ohne passende Bindung landet eine Anfrage bei der falschen Site oder nirgends.

Bei HTTPS wird es interessanterBei verschlüsselten Verbindungen muss der Server das Zertifikat auswählen, bevor er die Anfrage lesen kann — der Hostname steht ja darin. Die Servernamensanzeige löst das, indem der Client den gewünschten Namen bereits im Aufbau der verschlüsselten Verbindung mitschickt. Ohne sie gilt je IP und Port genau ein Zertifikat. Das ist der Grund, warum eine zweite Website auf derselben Adresse plötzlich das Zertifikat der ersten präsentiert: Die Bindung wurde ohne Namensanzeige angelegt.

Für die Fehlersuche ist eine Eigenschaft wichtig: Trifft eine Anfrage keinen passenden Hostnamen, landet sie bei der Website, deren Bindung am wenigsten spezifisch ist — typischerweise der Standardwebsite. Das erzeugt das Fehlerbild „ich bekomme die falsche Anwendung“, und es ist keine Fehlfunktion, sondern eine fehlende Bindung. Get-IISSite oder appcmd list sites beantworten die Frage in einer Zeile: Welche Bindungen gibt es, und ist der gewünschte Name darunter?

Wo die Konfiguration wirklich steht

IIS führt seine Konfiguration nicht in der Registry, sondern in Textdateien — und in mehreren, die einander ergänzen und überschreiben.

%SystemRoot%\System32\inetsrv\config\applicationHost.config: Die Serverebene: Anwendungspools, Websites, Bindungen, globale Module.
web.config im Anwendungsverzeichnis: Die Anwendungsebene. Wird mit dem Inhalt ausgeliefert und vererbt sich in Unterverzeichnisse.
%SystemRoot%\System32\inetsrv\appcmd.exe: Das Kommandozeilenwerkzeug — auf Server Core der Hauptweg.
Get-IISSite, Get-IISAppPool: Die PowerShell-Sicht, seit dem IISAdministration-Modul.

Vererbung schneidet in beide RichtungenEine web.config in einem Unterverzeichnis kann Einstellungen des übergeordneten Verzeichnisses überschreiben — deshalb liegt eine Datei mit einer Fehlkonfiguration manchmal drei Ebenen tiefer als vermutet. Umgekehrt lassen sich Abschnitte auf Serverebene sperren, sodass eine web.config sie nicht überschreiben darf. Ein Anwendungsteam, dessen Einstellung wirkungslos bleibt, hat oft genau diesen Fall — und die Fehlermeldung nennt ihn nicht deutlich.

Ein praktischer Hinweis für Änderungen: Weil die Konfiguration in Dateien liegt, ist ihre Sicherung eine Dateikopie. appcmd add backup <Name> erzeugt eine Momentaufnahme der Serverkonfiguration, appcmd restore backup <Name> holt sie zurück. Das ist der Rückweg vor einer größeren Änderung an applicationHost.config — und er kostet einen Befehl. Eine Änderung an dieser Datei ohne vorherige Sicherung ist derselbe Fehler wie eine Registry-Änderung ohne reg export.

Kennwörter in Konfigurationsdateien

Läuft ein Pool unter einem eigenen Konto, muss dessen Kennwort irgendwo stehen — und die Konfiguration ist eine Textdatei. Die Dokumentation gibt dafür eine klare Anweisung.

Wörtlich dokumentiertUm unverschlüsselte Kennwörter in Konfigurationsdateien zu vermeiden, sollen Kennwörter immer über AppCmd.exe oder den IIS-Manager eingegeben werden. Diese Werkzeuge verschlüsseln die Zeichenkette automatisch, bevor sie in die XML-Datei geschrieben wird. Wer die Datei direkt bearbeitet, umgeht diesen Schritt — und hinterlässt ein Kennwort im Klartext in einer Datei, die in Sicherungen, Abbildern und Konfigurationsvergleichen mitläuft.

Die Dokumentation nennt an derselben Stelle die bessere Alternative: verwaltete Dienstkonten, bei denen das Verzeichnis das Kennwort selbst dreht und es gar keine Zeichenkette zu schützen gibt. Für einen Pool, der auf eine Netzressource zugreifen muss, ist das der tragfähige Weg — die Anwendungspoolidentität kann das nämlich nicht, sie ist lokal.

Abnahme über die reale Transaktion

Ein IIS-Server bietet viele Signale, die grün sein können, während der Dienst nicht funktioniert: Der Anwendungspool läuft, die Website ist gestartet, ein Aufruf von localhost antwortet.

Kurzcheck

Nach einem Update meldet das Team: Anwendungspool läuft, Website gestartet, http://localhost liefert die Startseite. Reicht das als Abnahme?

Nein — geprüft ist damit weder die Bindung noch das Zertifikat noch die Berechtigung
Ja — wenn die Startseite kommt, funktioniert die Anwendung
Nein — es fehlt die Prüfung des Ereignisprotokolls auf Fehler nach dem Update

Treffer. Richtig. Ein Aufruf über localhost umgeht Namensauflösung, Hostnamen-Bindung, Zertifikat und oft auch die Authentifizierung. Er beweist, dass ein Prozess antwortet.

Die belastbare Abnahme läuft über den Weg, den ein Nutzer nimmt: der echte Hostname, von einem echten Clientnetz aus, mit einem echten Konto, und eine Aktion, die die Anwendung tatsächlich tut — Anmelden, einen Datensatz lesen, etwas speichern. Alles davor prüft nur die eigene Schicht.

Der negative Test gehört ausdrücklich dazu und wird fast immer vergessen. Wenn eine Anwendung nur für eine bestimmte Gruppe gedacht ist, muss ein Konto außerhalb dieser Gruppe auch tatsächlich abgewiesen werden — und zwar über denselben Weg, den ein echter Nutzer nimmt. Eine Abnahme, die nur prüft, dass Berechtigte hereinkommen, hat die Hälfte der Anforderung ungeprüft gelassen. Diese Hälfte fällt erst auf, wenn jemand sie ausnutzt.

Was die Protokolle sagen

IIS schreibt für jede Anfrage eine Zeile. Diese Protokolle sind die erste Quelle bei jeder Beschwerde und werden erstaunlich selten gelesen.

Sie liegen voreingestellt unter %SystemDrive%\inetpub\logs\LogFiles, getrennt nach Website.
Statuscode, Unterstatus und Win32-Statuscode zusammen sagen mehr als der Statuscode allein.
Die Zeit-genommen-Spalte trennt eine langsame Anwendung von einer langsamen Verbindung.
Ein Fehler, der im IIS-Protokoll gar nicht auftaucht, hat den Server nie erreicht — dann liegt es an Namensauflösung, Netz oder Bindung.

Der letzte Punkt ist der wertvollsteDie Frage „steht die Anfrage überhaupt im Protokoll“ trennt zwei völlig verschiedene Fehlerklassen in einem Schritt. Ist sie da, liegt es am Server oder an der Anwendung; ist sie nicht da, liegt es davor. Das ist dieselbe Logik wie die Schichtung im Modul über Netzwerk und Remoteverwaltung, nur mit einer Quelle, die man ohnehin hat.

Für tiefere Fälle gibt es die Ablaufverfolgung fehlgeschlagener Anfragen. Sie schreibt für Anfragen, die eine gesetzte Bedingung erfüllen — etwa einen bestimmten Statuscode oder eine Mindestdauer —, eine detaillierte Datei mit jedem durchlaufenen Modul. Das ist die Quelle, mit der sich beantworten lässt, an welcher Stelle der Verarbeitungskette eine Anfrage stehen bleibt. Sie ist standardmäßig nicht aktiv und erzeugt im Betrieb Datenmenge: Sie gehört gezielt eingeschaltet, mit enger Bedingung, und nach der Untersuchung wieder aus.

Was in die Übergabe gehört

Eigener Anwendungspool je Anwendung — oder eine begründete Ausnahme.→Identität festgelegt: Anwendungspoolidentität, wenn kein Netzzugriff nötig ist; sonst ein verwaltetes Dienstkonto.→Rechte auf IIS AppPool\<Pool> vergeben, nicht auf IIS_IUSRS oder weiter.→Recycling bewusst konfiguriert — fester Zeitpunkt statt 29-Stunden-Intervall, Speicherschwelle nur mit dokumentiertem Grund.→Bindung mit Hostname und, bei mehreren Zertifikaten auf einer Adresse, mit Servernamensanzeige.→Abnahme über den realen Clientweg, positiv und negativ.

Der negative Test fehlt fast immer: Ein Konto ohne Berechtigung muss auch tatsächlich abgewiesen werden.

Und ein Hinweis für Server CoreDie IIS-Verwaltungskonsole braucht mmc.exe und ist auf Server Core erst nach dem App Compatibility Feature on Demand verfügbar. Wer IIS auf Core betreibt, arbeitet mit appcmd und PowerShell — und sollte das vor der ersten Übergabe geübt haben, nicht im Störungsfall. Der Zusammenhang steht im ersten Modul dieses Tracks.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität10 Primärquellen · zuletzt geprüft: 2026-09-04