microsoft internetinformationsdienste (iis) 7.0 – die technische...

Mike Volodarsky

Bernard Cheah

Olga LonderBrett Hill

Steve SchofieldCarlos Aguilar MaresKurt MeyerMicrosoft IIS Team

Microsoft

Internetinformations-dienste (IIS) 7.0 – Die technische Referenz

http://www.microsoft-press.de/product.asp?cnt=productopt&id=ms-5924

Dieses Buch ist die deutsche Übersetzung von: Internet Information Services 7.0 Resource KitMicrosoft Press, Redmond, Washington 98052-6399Copyright 2009 Microsoft Corporation

Das in diesem Buch enthaltene Programmmaterial ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autor, Übersetzer und der Verlag übernehmen folglich keine Verantwortung und werden keine daraus folgende oder sons-tige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programmmaterials oder Teilen davon ent-steht.

Das Werk einschließlich aller Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfäl-tigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Die in den Beispielen verwendeten Namen von Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereig-nissen sowie E-Mail-Adressen und Logos sind frei erfunden, soweit nichts anderes angegeben ist. Jede Ähnlichkeit mit tatsächlichen Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereignissen, E-Mail-Adressen und Logos ist rein zufällig.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 110 09 08

ISBN 978-3-86645-5-924-3, auch Teilband von Microsoft Windows Server 2008 – Die technische Referenz (ISBN 978-3-86645-919-9)

© Microsoft Press Deutschland(ein Unternehmensbereich der Microsoft Deutschland GmbH)Konrad-Zuse-Str. 1, D-85716 UnterschleißheimAlle Rechte vorbehalten

Übertragung ins Deutsche: Detlef Johannis, Uwe ThiemannKorrektorat: Karin Baeyens, Dorothee Klein, SiegenSatz: Cordula Winkler, mediaService, Siegen (www.media-service.tv)Umschlaggestaltung: Hommer Design GmbH, Haar (www.HommerDesign.com)Herstellung, Druck und Bindung: Kösel, Krugzell (www.KoeselBuch.de)


Inhaltsverzeichnis III

Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV

Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIIWelche Neuerungen bietet IIS 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIIÜbersicht über das Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIXBesondere Kennzeichnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX

Lesehilfen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIXEinschübe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXBefehlszeilenbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XX

Inhalt der Begleit-CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXWeitere Inhalte online finden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI

Supportrichtlinie für die technische Referenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI

Teil I Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Kapitel 1 Einführung in IIS 7.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Übersicht über IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Welche Neuerungen bietet IIS 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Der Webserverkern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Verwaltungstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Diagnose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Windows-Prozessaktivierungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Anwendungskompatibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Grundlegende Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Websites erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Anwendungen erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Virtuelle Verzeichnisse erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Anwendungspools erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Einem Anwendungspool eine Anwendung zuweisen . . . . . . . . . . . . . . . . . . . . . . . . . . 21

IIS 7.0 Features unter Windows Server 2008 und Windows Vista . . . . . . . . . . . . . . . . . . . . 22Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Kapitel 2 Grundlagen der IIS 7.0-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Übersicht über die IIS 7.0-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30IIS 7.0-Kernkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

HTTP.sys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33WWW-Publishingdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Windows-Prozessaktivierungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


IV Inhaltsverzeichnis

Konfigurationsspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Arbeitsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Anforderungsverarbeitung im Anwendungspool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Klassischer Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Der integrierte .NET-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Gültigkeitsbereiche von Modulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Modulreihenfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Verarbeitung von Nicht-HTTP-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Kapitel 3 Verstehen der modularen Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Die Ideen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Modultypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Module und Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Hauptvorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Integrierte Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Kapitel 4 Verstehen des Konfigurationssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Übersicht über das Konfigurationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Konfigurationsdateihierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Konfigurationsdateisyntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Das IIS 7.0-Konfigurationssystem und die IIS 6.0-Metabasis . . . . . . . . . . . . . . . . . . . . 80IIS 7.0 und die .NET-Konfigurationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Konfigurationsbearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Auswahl des Konfigurationsorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Konfigurationen festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Konfigurationsfehler verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Konfigurationsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Sichern der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Arbeiten mit dem Konfigurationsverlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Exportieren und Importieren von Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Konfigurationsdelegierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Eine Konfiguration für mehrere Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112


Inhaltsverzeichnis V

Teil II Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Kapitel 5 Installieren von IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Planen der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Installationsszenarien für IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Möglichkeiten der Installation von IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Mit dem Server-Manager arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Den Paketmanager verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130ServerManagerCMD verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Antwortdateien für unbeaufsichtigte Installationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Sysprep/Neues Setupsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Automatische Installationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Windows Server 2008-Setup für optionale Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Nach der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Ordner und Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Überprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Behandlung von Installationsproblemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Ereignisprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140IIS 7.0-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Andere Protokollierungsoptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

IIS 7.0 entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Die Benutzeroberfläche unter Windows Server 2008 und Windows Vista . . . . . . . . . . 142Die Befehlszeilenmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144


Teil III Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Kapitel 6 Verwenden von IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Übersicht über den IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Den IIS-Manager starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Die Benutzeroberfläche des IIS-Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Navigationsleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Der Bereich Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Arbeitsbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Der Bereich Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Features verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Die Zuordnung von Features zu Modulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Speicherort der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Gültigkeitsbereich der Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Anpassung und Erweiterbarkeit des IIS 7.0-Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Remoteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182


VI Inhaltsverzeichnis

Kapitel 7 Verwenden von Befehlszeilentools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Befehlszeilentools für die Verwaltung benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Appcmd.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Erste Schritte mit Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Die Syntax von Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Unterstützte Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Die Hilfe nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Die Ausgabe von Appcmd verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Allgemeine Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Bereichsoperatoren verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Häufige Fehler bei der Arbeit mit Appcmd vermeiden . . . . . . . . . . . . . . . . . . . . . . . . . 196

Die Grundverben verwenden: List, Add, Set und Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Objekte mit dem List-Befehl auflisten und auffinden . . . . . . . . . . . . . . . . . . . . . . . . . . 196Objekte mit dem Add-Verb erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Bereits vorhandene Objekte mit dem Set-Verb ändern . . . . . . . . . . . . . . . . . . . . . . . . . 198Objekte mit dem Delete-Verb entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Arbeiten mit der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Konfigurationen mit dem Befehl List Config betrachten . . . . . . . . . . . . . . . . . . . . . . . . 201Konfigurationen mit dem Befehl Set Config festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . 202Die Konfigurationsdelegierung verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Konfigurationssicherungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Mit Anwendungen, virtuellen Verzeichnissen und Anwendungspools arbeiten . . . . . . . . . . 207Mit Webservermodulen arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Ausgeführte Arbeitsprozesse und Anforderungen untersuchen . . . . . . . . . . . . . . . . . . . . . . . 208

Ausgeführte IIS-Arbeitsprozesse auflisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Gegenwärtig ausgeführte Anforderungen auflisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Mit der Ablaufverfolgung für Anforderungsfehler arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 210Die Ablaufverfolgung für Anforderungsfehler aktivieren . . . . . . . . . . . . . . . . . . . . . . . 210Ablaufverfolgungsregeln für Anforderungsfehler aufstellen . . . . . . . . . . . . . . . . . . . . . 211Ablaufverfolgungsprotokolle für Anforderungsfehler durchsuchen . . . . . . . . . . . . . . . 213

Microsoft.Web.Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Sites mit MWA erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Anwendungspools mit MWA erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Die Konfiguration festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Windows PowerShell und IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218WMI-Anbieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219COM-Objekte für die IIS 7.0-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Kapitel 8 Remoteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Der IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Webverwaltungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223WMSvc-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224


Inhaltsverzeichnis VII

Die Remoteverwaltung verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Mit der Remoteverwaltung arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Problembehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245


Kapitel 9 Verwalten von Websites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools . . . . . . . . . . . . . . 249

Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Virtuelle Verzeichnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Anwendungspools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Eine neue Website hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Die Bindungen einer Website konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Die Websiteverwendung einschränken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Die Websiteprotokollierung und Ablaufverfolgung für Anforderungs- fehler konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Websites starten und beenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Virtuelle Verzeichnisse verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Ein neues virtuelles Verzeichnis hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Virtuelle Verzeichnisse konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Nach virtuellen Verzeichnissen suchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Remoteinhalte verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Anwendungen für die Arbeit mit Remoteinhalten konfigurieren . . . . . . . . . . . . . . . . . . 273Das Sicherheitsmodell für den Zugriff auf Remoteinhalte auswählen . . . . . . . . . . . . . . 274Feste Anmeldeinformationen für den Zugriff auf Remoteinhalte konfigurieren . . . . . . 276Den Zugriff auf Remoteinhalte gewähren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276


Kapitel 10 Verwalten von Anwendungen und Anwendungspools. . . . . . . . . . . . . . . . . . . . 279Webanwendungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Webanwendungen erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Webanwendungen auflisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Anwendungspools verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Überlegungen zu Anwendungspools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Einen neuen Anwendungspool hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290Anwendungspoolidentitäten verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Erweiterte Anwendungspoolkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Arbeitsprozesse und Anforderungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Arbeitsprozesse und Anforderungen überwachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302



VIII Inhaltsverzeichnis

Kapitel 11 Hosting von Anwendungsentwicklungsframeworks . . . . . . . . . . . . . . . . . . . . . 309IIS als Anwendungsentwicklungsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Anwendungsframeworks unterstützen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310Unterstützte Anwendungsframeworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

ASP.NET-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Den integrierten und den klassischen ASP.NET-Modus verstehen . . . . . . . . . . . . . . . . 314Mehrere ASP.NET-Versionen gleichzeitig ausführen . . . . . . . . . . . . . . . . . . . . . . . . . . 316ASP.NET installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318ASP.NET-Anwendungen bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Zusätzliche Überlegungen zur Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

ASP-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327ASP installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327ASP-Anwendungen bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328Zusätzliche Überlegungen zur Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

PHP-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330PHP-Anwendungen bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331Zusätzliche Überlegungen zur Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Anwendungsframeworks ermöglichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337Die Verarbeitung von neuen statischen Dateien konfigurieren . . . . . . . . . . . . . . . . . . . 338Frameworks basierend auf systemeigenen IIS 7.0-Modulen bereitstellen . . . . . . . . . . . 340Frameworks basierend auf ASP.NET-Handlern bereitstellen . . . . . . . . . . . . . . . . . . . . 341Frameworks basierend auf ISAPI-Erweiterungen bereitstellen . . . . . . . . . . . . . . . . . . . 342Mit FastCGI arbeitende Frameworks bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342Mit CGI arbeitende Frameworks bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346


Kapitel 12 Verwalten von Webservermodulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349IIS 7.0-Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

Die IIS 7.0-Erweiterbarkeitsarchitektur auf einen Blick . . . . . . . . . . . . . . . . . . . . . . . . 350Die Erweiterbarkeit verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

Webservererweiterbarkeit zur Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Was ist ein Modul? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Module installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359Allgemeine Modulverwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Verwaltete Module mit dem IIS-Manager installieren und verwalten . . . . . . . . . . . . . . 377Handlerzuordnungen mit dem IIS-Manager erstellen und verwalten . . . . . . . . . . . . . . 380Verwaltete Module mit Appcmd installieren und verwalten . . . . . . . . . . . . . . . . . . . . . 384Handlerzuordnungen erstellen und verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388Webservermodule sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390



Inhaltsverzeichnis IX

Kapitel 13 Konfigurations- und Benutzeroberflächenerweiterungen verwalten . . . . . . . . 401Übersicht über den Verwaltungsstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401Konfigurationserweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

Konfigurationsabschnittsschemata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405Konfigurationsabschnitte deklarieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Neue Konfigurationsabschnitte installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410Konfigurationsabschnitte sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Verwaltungserweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415Wie Verwaltungserweiterungen funktionieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417Verwaltungserweiterungen installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418Verwaltungserweiterungen sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

IIS-Manager-Erweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419Die Funktionsweise von IIS-Manager-Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . 420IIS-Manager-Erweiterungen installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422IIS-Manager-Erweiterungen sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422


Kapitel 14 Implementieren von Sicherheitsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427Sicherheitsänderungen unter IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Verkleinern der Angriffsfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430Die Angriffsfläche der Anwendung verkleinern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

Anwendungen für die Nutzung von geringstmöglichen Berechtigungen konfigurieren . . . . 445Eine über wenige Berechtigungen verfügende Anwendungspoolidentität verwenden . . . 446NTFS-Berechtigungen für den Mindestzugriff gewähren . . . . . . . . . . . . . . . . . . . . . . . 448Einschränken der Vertrauenswürdigkeit von ASP.NET-Anwendungen . . . . . . . . . . . . 450Anwendungen isolieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

Die Zugriffssteuerung implementieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453IP- und Domäneneinschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455Anforderungsfilterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461Auf NTFS-ACLs basierende Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462URL-Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468Anonyme Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470Standardauthentifzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472Digestauthentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474Windows-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Authentifizierung über Clientzertifikatzuordnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 479Authentifizierung über IIS-Clientzertifikatzuordnungen . . . . . . . . . . . . . . . . . . . . . . . . 481UNC-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485Die Authentifizierungsdelegierung verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

Sichern der Kommunikation mit SSL (Secure Sockets Layer) . . . . . . . . . . . . . . . . . . . . . . . 488SSL konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489SSL voraussetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490Clientzertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492


X Inhaltsverzeichnis

Sichern der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493Einschränken des Zugriffs auf die Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494Sensible Konfigurationen sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498Kontrollieren der Konfigurationsdelegierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503Die zu delegierende Konfiguration festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503


Teil IV Problembehandlung und Leistungsoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

Kapitel 15 Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511Was ist neu? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

Der Internetinformationsdienste-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512Das XML-Konfigurationsschema für die Protokollierung . . . . . . . . . . . . . . . . . . . . . . . 513Konfigurationsoptionen für zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . 514Standardkonfiguration für neue Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514Konfigurationsoptionen zum Deaktivieren der HTTP-Protokollierung . . . . . . . . . . . . . 515Standardspeicherort der Protokolldateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515UTF-8-Kodierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515Neue Statuscodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516Verwaltungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

Protokolldateiformate, die sich nicht verändert haben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516Zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

W3C-Format für die zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517Binärformat für die zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Remoteprotokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517Einrichten der Remoteprotokollierung mit dem Internetinformationsdienste-Manager . . . 518Einrichten der Remoteprotokollierung mit Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520Remoteprotokollierung mit dem FTP-7.0-Publishingdienst . . . . . . . . . . . . . . . . . . . . . 520Benutzerdefinierte Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Konfigurieren der IIS-Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523Internetinformationsdienste-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526Erweiterte Appcmd-Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528Windows PowerShell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

Http.sys-Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532Anwendungsprotokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

Protokollierung der Prozesswiederverwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533IIS-Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

Ordnerkomprimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534Protokollanalyse mit Log Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536


Inhaltsverzeichnis XI

Kapitel 16 Ablaufverfolgung und Problembehandlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537Problembehandlung mithilfe von Ablaufverfolgung und Diagnose . . . . . . . . . . . . . . . . . . . . 538

Installieren des FRT-Moduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538Aktivieren und Konfigurieren der FRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539Lesen der FRT-Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545Integrieren von Ablaufverfolgung und ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550Leistungsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

Problembehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552Anwenden eines Verfahrens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552Arbeiten mit Tools und Dienstprogrammen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554Problembehandlung für HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

Beseitigen häufig auftauchender Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574IIS 6.0-Verwaltungsprogramme sind nicht installiert . . . . . . . . . . . . . . . . . . . . . . . . . . 574SSl ist nicht aktiviert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574Unerwartete Wiederverwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574Abstürze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575Website nicht erreichbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575Authentifizierungsfehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575Langsame Reaktion oder hängender Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575


Kapitel 17 Optimieren der Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577Einen Kompromiss zwischen Sicherheit und Leistung finden . . . . . . . . . . . . . . . . . . . . . . . . 577

Messen der Belastung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583Prozessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584Arbeitsspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588Festplatten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593Leistungsindikatoren für die Anwendungsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

64-Bit-Modus und 32-Bit-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600Optimieren der Konfiguration unter Leistungsaspekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601

Serverebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603Optimieren der Konfiguration für den Belastungstyp . . . . . . . . . . . . . . . . . . . . . . . . . . 603Serverseitige Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

Systemüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615WCAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615Zuverlässigkeits- und Leistungsüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615FRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616Ereignisanzeige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616System Center Operations Manager 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616


XII Inhaltsverzeichnis

Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617Entwurfsphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617Mehr Computer oder leistungsfähigere Computer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617


Teil V Anhänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623

Anhang A HTTP-Fehlercodes in IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

Anhang B IIS 7.0-Fehlermeldungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631HTTP-Fehler in IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632Konfigurieren von <httpErrors> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634

Unterstatuscodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634Beispiel für einen Unterstatuscode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635

Benutzerdefinierte Fehler in unterschiedlichen Sprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . 635Optionen für benutzerdefinierte Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636

Ausführen einer URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636Umleiten der Anforderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637

Anhang C Liste der IIS 7.0-Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639Native Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639Verwaltete Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

Anhang D Reihenfolge der Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

Anhang E IIS 7.0-Standardeinstellungen und Zeitlimits/Schwellenwerte . . . . . . . . . . . . . . 655ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680Standardeinstellungen für Anwendungspools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682

Anhang F IIS 7.0 und 64-Bit-Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685Windows Server 2008 x64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

Konfigurieren einer 32-Bit-Anwendung unter einer 64-Bit-Version von Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686

Anhang G Zuordnung von Internetinformationsdienste-Manager-Features und Konfigurationsabschnitten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689

ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

Anhang H Zuordnung zwischen IIS 6.0-Metabasis und IIS 7.0-Konfiguration . . . . . . . . . . 693


Inhaltsverzeichnis XIII

Anhang I Shared Hosting mit IIS 7.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707Implementieren von Process Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707

Arbeiten mit der Befehlszeile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708Konfigurationsänderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709

Aktivieren des Schwellenwerts für das dynamische Leerlaufzeitlimit . . . . . . . . . . . . . . . . . . 709Arbeiten mit der Befehlszeile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711Konfigurationsänderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712

Anhang J Durchführen von Administrationsaufgaben im Internetinformationsdienste-Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713

Die Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719

Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721

Systemvoraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735


XV

Danksagung

Das Buch, das Sie gerade in den Händen halten, ist das Ergebnis einer kollektiven Anstrengung vieler Menschen.

Wir möchten damit beginnen, Bill Staples, Mai-Lan Tomsen Bukovec und dem gesamten IIS-Produkt-team für die Unterstützung zu danken. Einige von uns arbeiten für das IIS-Produktteam. Deshalb wissen wir aus erster Hand, dass wir ohne die unschätzbare Hilfe des Teams einfach nicht dazu in der Lage gewesen wären, an diesem Buch zu arbeiten.

Wir sind außerdem Martin DelRe von Microsoft Press sehr dankbar, und zwar für seine Vision, für seine harte Arbeit, um dieses Projekt zu realisieren und für dessen erfolgreichen Abschluss zu sorgen, sowie für seine nie endende Unterstützung und die vielen Ermutigungen.

Es braucht viele Personen und viel Arbeit, um ein Buch wie dieses ins Leben zu rufen. Es gibt einige Menschen, denen wir speziell danken möchten. Ohne sie gäbe es dieses Buch nicht. Brett Hill initiierte dieses Projekt und war bis zu dessen Abschluss dabei. Ein besonderer Dank geht an Mike Volodarsky, dem Qualität und Vollständigkeit sehr wichtig sind, was dazu geführt hat, dass er zum Hauptautor wurde. Kurt Meyer war als Projektmanager eine große Hilfe. Er koordinierte die Arbeit der Autoren und sorgte dafür, dass die jeweiligen Projektetappen fast immer innerhalb des vorgegebenen Zeitrahmens erreicht wurden.

Viele unserer Kollegen im IIS-Produktteam lieferten wichtige Informationen, die in das Buch eingingen. Jedes Kapitel wurde sogar von mindestens einem Mitglied des Produktteams überprüft. Andere Team-mitglieder schrieben die »Direkt von der Quelle«-Einschübe, die im gesamten Buch verteilt sind und Ihnen einen einmaligen Einblick in das Design und die Entwicklung von IIS 7.0 bieten. Unser aufrichtiger Dank gilt auch den folgenden Mitgliedern des IIS-Produktteams, die mit uns an diesem Buch gearbeitet haben. Sie sind, sortiert nach dem Vornamen, in alphabetischer Reihenfolge aufgeführt: Anil Ruia, Bill Staples, Edmund Chou, Eric Deily, Fabio Yeon, Jaroslav Dunajsky, Kanwaljeet Singla, Nazim Lala, Michael Brown, Thomas Marquardt, Tobin Titus, Ulad Malashanka und Wade Hilmo.

Wir möchten außerdem Tito Leverette für seinen Rat und Beitrag zum siebzehnten Kapitel, »Optimieren der Leistung«, danken.

Viele andere Microsoft-Teams erklärten sich ebenfalls dazu bereit, eine fachliche Überprüfung durch-zuführen und ihre Erfahrungen und Einblicke mit uns zu teilen. Wir danken besonders Tom Hawthorn vom Windows Performance-Team und George Holman sowie dem gesamten Microsoft.com-Opera-tions-Team. Nick McCollum von Quixtar Inc. half ebenfalls mit einem Fachlektorat und Vorschlägen bezüglich der Kapitel 5, 15 und 17 aus.

Als Nächstes möchten wir dem hervorragenden Bearbeiter- und Redaktionsteam danken. Unser besonderer Dank gilt den Projektbearbeitern Karen Szall und Victoria Thulman von Microsoft Press für ihren Profes-sionalismus, ihre Betreuungstätigkeit, ihre außerordentliche redaktionelle Arbeit und vor allem für ihre Geduld. Bob Hogan und Bob Dean waren für das Fachlektorat dieses Buches verantwortlich. Sie sorgten für einen einheitlichen Schreibstil und für ein leichtes Verständnis der Texte. Jean Findley von Custom Editorial Productions, Inc., leistete hervorragende Arbeit bei der Organisation der Buchproduktion, für die ein enger Zeitrahmen gesetzt war.


XVI Danksagung

Wir danken außerdem Susan Chory und Isaac Roybal, die uns halfen, dieses Projekt auf die Beine zu stellen. Ein weiterer Dank geht an Simon Brown und Arvindra Sehmi, die den nötigen Ansporn für diese Arbeit lieferten.

Wir danken Euch allen!

Hochachtungsvoll,

Das Autorenteam: Mike, Olga, Brett, Bernard, Steve, Carlos und Kurt


XVII

Einführung

Inhalt dieses Kapitels:� Welche Neuerungen bietet IIS 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

� Übersicht über das Buch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX

� Besondere Kennzeichnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX

� Inhalt der Begleit-CD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XX

� Weitere Inhalte online finden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI

Willkommen zu IIS (Internetinformationsdienste) 7.0 – Die technische Referenz! Dieses Buch ist eine fachliche Informationsquelle für die Einsatzplanung, Bereitstellung und den Betrieb von IIS 7.0 (Internet-informationsdienste), Microsofts nächster Generation von Webserverplattformen. Obwohl sich diese technische Referenz vorwiegend an IT-Experten richtet, die bereits Erfahrungen mit früheren Versionen von IIS gesammelt haben, wird das Buch auch für diejenigen sehr hilfreich sein, die lernen möchten, wie IIS 7.0 bereitgestellt und betrieben wird.

In dieser technischen Referenz finden Sie detaillierte Informationen über die Verbesserungen, die an IIS 7.0 vorgenommen wurden, sowie die zugrunde liegenden Architekturkonzepte, mit deren Hilfe Sie das Prinzip der Bereitstellung und Verwaltung von IIS 7.0-Webservern besser verstehen werden. Darüber hinaus werden Sie Techniken untersuchen, die es Ihnen ermöglichen, die neuen IIS 7.0-Features und -Fähigkeiten zu nutzen. Weiterhin erhalten Sie ausführliche Informationen und aufgabenbasierte Anleitungen zu allen anderen Aspekten der IIS 7.0-Verwaltung, einschließlich der Bereitstellung modularer Webserver, der Konfiguration von Websites und Webanwendungen und der Verbesserung der Webserversicherheit, -zuverlässigkeit und -leistung. Sie werden außerdem von den Mitgliedern des IIS-Produktteams unzählige Randbemerkungen finden, die einen tiefen Einblick in die Arbeitsweise von IIS 7.0 gewähren und die empfohlene Vorgehensweisen für die Verwaltung der Webserverplattform sowie unschätzbare Tipps zur Problembehebung vorstellen. Die Begleitmedien zu diesem Buch ent-halten schließlich zusätzliche Tools und Dokumentationen, die Sie nutzen können, um IIS 7.0-Web-server zu verwalten und Probleme zu lösen.

Welche Neuerungen bietet IIS 7.0?IIS 7.0 wurde von Grund auf neu errichtet, um eine modulare und erweiterbare Webserverplattform zur Verfügung stellen zu können. Diese Plattform bildet die Grundlage für schlanke, leichte Webserver, die auf verschiedene Auslastungen und unterschiedliche Webanwendungen abgestimmt werden können. Die neue erweiterbare Architektur ermöglicht es Ihnen, einen maßgeschneiderten Webserver zu konfi-gurieren. Sie können die benötigten IIS-Features auswählen und sie mit neuen Webserverfeatures, wel-che die neuen funktionsreichen Erweiterbarkeits-APIs (Application Programming Interface) nutzen, ergänzen oder durch diese ersetzen. Der Webserver bietet außerdem ein neues verteiltes Konfigura-tionssystem und Verwaltungstools an, die seine Bereitstellung und Verwaltung erleichtern. Die Kern-features von IIS 7.0 nutzen die auf Zuverlässigkeit und Sicherheit ausgerichtete Architektur, die bereits vom Vorgänger, IIS 6.0, eingeführt wurde, und sie fügen zusätzliche Verbesserungen hinzu, um diese


XVIII Einführung

Zuverlässigkeit und Sicherheit der Webserverplattform zu erweitern. IIS 7.0 enthält außerdem eine erweiterte Unterstützung von Anwendungsframeworks, die z.B. mit FastCGI kompatibel sind und eine engere Verflechtung mit ASP.NET bieten.

Zusätzlich zu den vielen Verbesserungen bietet IIS 7.0 die folgenden Besonderheiten:

� Modulare Webserverachitektur Im Gegensatz zu seinen monolithischen Vorgängern ist IIS 7.0 ein vollständig modularer Webserver, der aus mehr als vierzig Komponenten besteht. Der Administ-rator kann diese Komponenten einzeln installieren, um leichte Webserver mit einer auf das Wesent-liche beschränkten Benutzeroberfläche zu generieren, die innerhalb der Anwendungstopologie die ihnen zugedachten Rollen spielen. Darüber hinaus ist es dank der neuen Erweiterbarkeitsarchitektur möglich, jedes der integrierten modularen Features durch maßgeschneiderte Implementierungen zu ersetzen, die von Microsoft oder Drittanbietern zur Verfügung gestellt werden.

� .NET-Erweiterbarkeit über ASP.NET-Integration Die neue ASP.NET-Integration ermöglicht es Ihnen, IIS 7.0-Features unter Verwendung von ASP.NET und dem .NET Framework zu entwickeln, wodurch die Entwicklungs- und Wartungskosten für benutzerdefinierte Webserverlösungen verringert werden. Sie können in diesem Fall bereits vorhandene ASP.NET-Dienste verwenden, um Anwen-dungstechnologien zu erweitern. Dies gilt auch für solche Technologien, die nicht im Hinblick auf ASP.NET entwickelt wurden. Mit Hilfe dieser Möglichkeiten können IIS 7.0-Webanwendungen den Webserver an die eigenen Bedürfnisse anpassen, ohne höhere Entwicklungskosten zu verursachen, was sich bei der bisher verwendeten ISAPI-Lösung (Internet Server Application Programming Inter-face) nicht vermeiden ließ.

� Erweiterte Unterstützung von Anwendungsframeworks Zusätzlich zur Erweiterung des Web-servers durch eine verbesserte ASP.NET-Integration bietet IIS 7.0 weitere Optionen zur Unterstüt-zung anderer Anwendungsframeworks. Dazu zählt auch das FastCGI-Protokoll, das von vielen Open-Source-Anwendungsframeworks wie z.B. PHP (PHP Hypertext Preprocessor) eingesetzt wird. Solche Frameworks werden nun aufgrund der Tatsache, dass IIS 7.0 mit FastCGI arbeiten kann, in einer Windows-Umgebung problemlos unterstützt.

� Verteiltes Konfigurationssystem mit der Möglichkeit zur Delegierung IIS 7.0 ersetzt den zentralisierten Metabasis-Konfigurationsspeicher durch ein neues Konfigurationssystem, das auf einer aus verteilten XML-Dateien bestehenden Hierarchie basiert. Dies ermöglicht es den Anwen-dungen, eigene Konfigurationen festzulegen. Mit dem neuen Konfigurationssystem ist eine ver-einfachte Anwendungsentwicklung ohne administrative Einbindung möglich. Es bildet außerdem die Grundlage für eine flexiblere Verwaltung der Webserverkonfiguration.

� Verbesserte Verwaltungstools IIS 7.0 bietet eine Vielzahl verschiedener Verwaltungstools an, die das neue Konfigurationssystem nutzen, um die Verwaltung der Webserverkonfiguration flexib-ler und einfacher zu gestalten. Dazu zählen ein brandneuer aufgabenbasierter IIS-Manager, der eine delegierte Remoteverwaltung ermöglicht, ein neues Tool für die Verwaltung über die Befehlszeile (Appcmd) und mehrere APIs zur Verwaltung der Webserverkonfiguration mit Hilfe von Skripts, WMI (Windows Management Instrumentation) und .NET Framework-Programmen.

� Erweiterte Diagnose und Problembehandlung IIS 7.0 stellt Diagnosefeatures zur Verfügung, die Sie dabei unterstützen, Webserverfehler zu untersuchen und mit Hilfe einer Infrastruktur zur Ablauf-verfolgung fehlgeschlagener Anforderungen Probleme zu lösen, deren Ursachen schwer nachvollzieh-bar sind. Die Ablaufverfolgungsfeatures sind in ASP.NET-Anwendungen integriert, damit eine voll-ständige Webanwendungsdiagnose von Endpunkt zu Endpunkt durchgeführt werden kann.


Einführung XIX

Übersicht über das BuchDie vier Teile dieses Buches behandeln die folgenden Themen:

� Teil 1: Grundlagen Bietet eine Übersicht über die IIS 7.0-Features, beschreibt die mit IIS 7.0 eingeführten Verbesserungen und stellt die Kernarchitektur eines Webservers vor.

� Teil 2: Bereitstellung Erklärt die für die Bereitstellung von IIS 7.0 wichtige modulare Installa-tions-Architektur und hält Anleitungen zur Installation von IIS 7.0 für verschiedene übliche Web-serverauslastungsszenarien bereit.

� Teil 3: Verwaltung Erläutert die Schlüsselkonzepte der IIS 7.0-Verwaltung und beschreibt, wie bestimmte Verwaltungsaufgaben mit Hilfe der von IIS 7.0 bereitgestellten Verwaltungstools gelöst werden.

� Teil 4: Problembehandlung und Leistung Erklärt, wie die Protokollierungs- und Ablaufverfol-gungs-Infrastruktur verwendet wird, um für einen reibungslosen Betrieb des Webservers zu sorgen, wie Fehlerursachen behandelt werden und wie die Leistung des Webservers überwacht und ver-bessert wird.

Das Buch enthält außerdem mehrere Anhänge zu verschiedenen Themen sowie ein Glossar zum Nachschlagen.

Besondere KennzeichnungenIn diesem Buch werden die folgenden Kennzeichnungen verwendet, um bestimmte Besonderheiten hervorzuheben.

LesehilfenDie folgenden Lesehilfen werden im gesamten Buch eingesetzt, um auf nützliche Informationen hinzuweisen.

Lesehilfe Bedeutung

Hinweis Unterstreicht die Wichtigkeit eines bestimmten Konzepts oder hebt einen bestimmten Fall hervor, der nicht alltäglich ist

Wichtig Lenkt die Aufmerksamkeit auf wichtige Informationen, die nicht ignoriert werden sollten

Vorsicht Warnt Sie davor, dass eine Missachtung des beschriebenen Sachverhalts zu ernsthaften Problemen für die Benutzer, das System, die Funktionsfähigkeit usw. führen kann

Auf CD Lenkt die Aufmerksamkeit auf ein Skript, ein Tool, eine Vorlage oder eine Arbeitshilfe auf der beiliegenden CD-ROM, das bzw. die Ihnen hilft, eine im Text beschriebene Aufgabe zu lösen


XX Einführung

EinschübeIm gesamten Buch werden die folgenden Einschübe verwendet, um zusätzliche Einblicke zu gewähren und Tipps und Ratschläge zu geben, die sich auf die verschiedenen IIS 7.0-Features beziehen.

BefehlszeilenbeispieleIn diesem Buch werden die folgenden Gestaltungsmerkmale für die Darstellung von Befehlszeilen-beispielen verwendet.

Inhalt der Begleit-CDDie Begleit-CD ist eine nützliche Ergänzung zu diesem Buch und weist den folgenden Inhalt (in eng-lischer Sprache) auf:

� Elektronisches Buch Der gesamte Text des gedruckten Buches in einem durchsuchbaren PDF-eBook

� Skripts Skripts, die Ihnen helfen, IIS-Aufgaben zu automatisieren

� Tools Links zu Tools für IIS, Windows PowerShell usw., die Sie direkt verwenden können

� Produktinformationen Links zu Informationen über die Features und Möglichkeiten von IIA NS Windows Server 2008 und anderen Produkten, die Ihnen helfen, Windows Server 2008 in Ihrem Unternehmen zu optimieren

� Ressourcen Links zu Anleitungen, technischen Ressourcen, Webcasts, Foren usw., die Ihnen zei-gen, wie die Features von IIS, Windows Server 2008 und anderen Produkten richtig eingesetzt und Probleme behoben werden

Einschub Bedeutung

Direkt von der Quelle Beiträge von Microsoft-Experten, also direkt von der Quelle, die Einblicke in die Arbeitsweise von IIS 7.0 bieten, empfohlene Vorgehensweisen zur IIS 7.0-Verwaltung erläutern sowie Tipps zur Problem-behandlung geben

So funktioniert es Vermittelt einen Eindruck von den IIS 7.0-Features und deren Arbeitsweise

Stil Bedeutung

Fettschrift Kennzeichnet Benutzereingaben (Zeichenfolgen, die Sie genauso eingeben, wie sie im Text abgedruckt sind)

Kursivschrift Kennzeichnet Variablen, denen konkrete Werte zugewiesen werden müssen (name_datei steht zum Beispiel für jeden gültigen Dateinamen)

Nichtproportionale Schrift Kennzeichnet Codebeispiele und Befehlszeilenausgaben

%SystemRoot% Schreibweise von Umgebungsvariablen


Einführung XXI

Weitere Inhalte online findenWenn neues oder aktualisiertes Material verfügbar ist, das eines Ihrer Bücher ergänzt, wird es auf den Server- und Clientwebsites von Microsoft Press Online veröffentlicht. Bezogen auf die finale Version von Windows Server 2008 kann es sich bei diesem Material um Buchaktualisierungen, Artikel, Links zu zugehörigen Inhalten, Korrekturen, Beispielkapiteln usw. handeln. Diese Website ist unter der folgenden Adresse verfügbar und wird regelmäßig aktualisiert: http://www.microsoft.com/learning/books/online/serverclient. Beachten Sie bitte, dass die dort veröffentlichten Informationen in englischer Sprache vorliegen.

Supportrichtlinie für die technische ReferenzEs wurde jede Anstrengung unternommen, um die Richtigkeit dieses Buches und der beiliegenden Medien zu gewährleisten. Microsoft Press hält unter der folgenden Webadresse mögliche Korrekturen zu seinen Büchern bereit: http://www.microsoft-press.de/support.asp.

Wenn Sie Kommentare, Fragen oder Ideen zu diesem Buch oder dem zugehörigen Inhalt haben oder Ihre Fragen nach einem Besuch der zuvor aufgeführten Sites nicht beantwortet werden konnten, senden Sie sie bitte an Microsoft Press.

Per E-Mail:

[email protected] (bitte verfassen Sie Ihr Schreiben in englischer Sprache)

Postalische Adresse:

Microsoft Press Betrifft: IIS 7.0 – Die technische Referenz Konrad-Zuse-Straße 1 85716 Unterschleißheim

Bitte beachten Sie, dass über diese Adressen kein Support für Microsoft-Produkte angeboten wird. Um Supportinformationen zum Produkt zu erhalten, besuchen Sie bitte die Produktsupport-Website von Microsoft unter der folgenden Adresse: http://support.microsoft.com.


1

T E I L I

Grundlagen

In diesem Teil:Einführung in IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Grundlagen der IIS 7.0-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Verstehen der modularen Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Verstehen des Konfigurationssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


3

K A P I T E L 1

Einführung in IIS 7.0

Inhalt dieses Kapitels:� Übersicht über IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

� Welche Neuerungen bietet IIS 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

� Grundlegende Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

� IIS 7.0 Features unter Windows Server 2008 und Windows Vista . . . . . . . . . . . . . . . . . . . . . . . . . . 22

� Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

� Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Microsoft IIS 7.0 (Internet Information Services) in Verbindung mit Windows Server 2008 ist ein Webserver, der eine sichere und einfach zu verwaltende Plattform für die Entwicklung und das Hosten von Webanwendungen und Diensten zur Verfügung stellt. IIS 7.0 wurde vollständig überarbeitet und weist gegenüber seinen Vorgängern wichtige Vorteile auf. Mit seiner neuen modularen und erweiter-baren Architektur sorgt IIS 7.0 dafür, dass die Entwicklung, Bereitstellung, Konfiguration und Ver-waltung von Webanwendungen und der Webinfrastruktur einfacher und effizienter als jemals zuvor ist.

Kurz gesagt ist IIS 7.0 die bisher leistungsfähigste Microsoft-Webserverplattform. Es verfügt über neue Fähigkeiten, die die Art und Weise, in der Webanwendungen und Dienste entwickelt, bereitgestellt und verwaltet werden, vereinfachen. Aufgrund des modularen Designs von IIS 7.0 haben die Administ-ratoren die volle Kontrolle über die Funktionalität ihrer Webserver. Dieses Design umfasst eine erweiterbare Architektur, die es Administratoren und Entwicklern ermöglicht, angepasste und spezia-lisierte Webserver einzurichten. Die neuen Verwaltungsmöglichkeiten und das verteilte, auf XML basierende Konfigurationssystem sorgen dafür, dass die Bereitstellung und Verwaltung von Webanwen-dungen mit IIS 7.0 einfacher und effizienter als bei jedem anderen Webserver sind. Darüber hinaus können Administratoren und Entwickler mit Hilfe der neuen Funktionen für die Problemdiagnose und -behebung die Systemausfallzeiten verringern.

Dieses Kapitel konzentriert sich auf die wichtigsten neuen Features und die neue Funktionalität von IIS 7.0 und beschreibt deren Vorteile gegenüber den vorherigen Versionen. Wir werfen außerdem einen Blick auf die grundlegenden Verwaltungsaufgaben und erörtern die Unterschiede hinsichtlich der Verfügbarkeit von IIS 7.0-Features unter Windows Server 2008 und Windows Vista.

Übersicht über IIS 7.0Mit den Features und Funktionen von IIS 7.0 können Administratoren die Webinfrastruktur zuverlässig und effektiv verwalten, Entwickler können Webanwendungen und -dienste schnell entwickeln und Webhosting-Anbieter können einer größeren Zielgruppe ein kostengünstiges, skalierbares und ver-lässliches Webhosting anbieten.


4 Kapitel 1: Einführung in IIS 7.0

Für Administratoren hält IIS 7.0 eine sichere, zuverlässige und einfach zu verwaltende Webserverplattform bereit. Die anpassbare Installation von IIS 7.0 gewährleistet, dass sie für ihre Webinfrastruktur die Größe der Angriffsfläche, die Notwendigkeit zur Fehlerbehebung und den benötigten Speicher minimieren können. Das IIS 7.0-Prozessmodell macht Websites und -anwendungen sicherer, indem es diese auto-matisch isoliert. Möglich wird dies durch eine abgeschirmte Konfiguration und eindeutige Prozess-kennungen.

IIS 7.0 verringert die Verwaltungskomplexität, indem es eine Gruppe von Tools zur Verfügung stellt, die die Verwaltung der Webinfrastruktur effizienter gestaltet. Der IIS-Manager besitzt eine neue aufgabenorientierte, featurebezogene Verwaltungskonsole, die mit einer intuitiven Benutzeroberfläche für administrative Tätigkeiten arbeitet. Zusätzlich zum IIS-Manager gibt es ein neues Befehlszeilen-hilfsmittel für die Verwaltung, einen WMI-Anbieter (Windows Management Instrumentation) und eine .NET-API (Application Programming Interface).

IIS 7.0 unterstützt die vereinfachte Verwaltung von Webfarmen, wobei die Webserverkonfiguration zusammen mit dem Webanwendungscode und den Inhalten auf einem zentralisierten Dateiserver gespeichert und von den Front-End-Webservern einer Farm gemeinsam genutzt werden kann.

IIS 7.0 ermöglicht es den Administratoren, die Kontrolle über die Site- und Anwendungsverwaltung sicher an solche Entwickler und Besitzer von Inhalten zu delegieren, die auf dem Server über keine administra-tiven Rechte verfügen. Auf diese Weise werden die Verwaltungslast und die Betriebskosten verringert. Wird der IIS-Manager unter Windows Vista, Windows XP, Windows Server 2003 oder Windows Server 2008 verwendet, können die Entwickler und Inhaltsbesitzer ihre Sites und Anwendungen von jedem beliebigen Ort aus remote verwalten, sofern sie über HTTPS mit dem Server verbunden sind.

Weiterhin können Administratoren mit Hilfe der neuen IIS 7.0-Möglichkeiten zur Problemdiagnose und -behandlung die Ausfallzeiten eines Webserver verringern.

Für Entwickler bietet IIS 7.0 eine flexible, erweiterbare Webserverplattform zur Entwicklung und Bereitstellung von Webanwendungen unter Windows Server 2008 und Windows Vista an. In Verbindung mit IIS 7.0 können Entwickler Anwendungen unter Verwendung eines Webframeworks ihrer Wahl erstellen, z.B. mit ASP.NET, klassischem ASP, PHP, PERL, ColdFusion, Ruby und vielen anderen.

IIS 7.0 bietet eine noch nie da gewesene Erweiterbarkeit. Es verfügt über eine aus Komponenten zusammengesetzte Architektur mit mehr als vierzig plugfähigen Modulen, die auf öffentlichen Erweiter-barkeits-APIs aufgebaut ist. Entwickler können neue Module oder Ersatzmodule in systemeigenem oder verwaltetem Code schreiben, die IIS-Konfiguration erweitern und IIS-Manager-Erweiterungen erstellen, die sich nahtlos in die Verwaltungskonsole integrieren lassen.

IIS 7.0 besitzt ein verteiltes, dateibasiertes Konfigurationssystem, mit dem es möglich ist, IIS-Ein-stellungen zusammen mit ASP.NET-Einstellungen in web.config-Dateien zu speichern. Dieses verein-heitlichte Konfigurationssystem vereinfacht die Entwicklung und ermöglicht auf IIS 7.0-Servern die Bereitstellung von vorkonfigurierten Anwendungen per xcopy.

Darüber hinaus helfen neue Diagnosemöglichkeiten, wie z.B. der Zugriff auf Laufzeitinformationen und die automatische Nachverfolgung fehlgeschlagener Anforderungen, den Entwicklern dabei, die Problembehandlung schneller durchzuführen und die Ausfallzeiten von Websites zu verringern.

Webhostern bietet IIS 7.0 eine kostengünstige, skalierbare Webserverplattform, mit der es möglich ist, eine größere Zielgruppe mit einem zuverlässigen Webhosting zu versorgen. IIS 7.0 senkt Kosten, indem es eine neue, skalierbare und gemeinsam nutzbare Hostingarchitektur zur Verfügung stellt, die tausende von Websites auf einem einzelnen IIS 7.0-Server hosten kann, ohne die Prozessisolation oder Betriebs-sicherheit opfern zu müssen.


Welche Neuerungen bietet IIS 7.0? 5

IIS 7.0 ermöglicht es den Webhostern, mehr Kunden zu erreichen. Der Grund hierfür ist ein neues FastCGI-Modul, das ein schnelles und zuverlässiges Hosting für PHP- und andere Webframeworks bietet.

Darüber hinaus stellt IIS 7.0 einen FTP-Server (File Transfer Protocol) zur Verfügung, so dass Webhoster ihren Kunden eine vollständig integrierte Web-/FTP-Plattform mit modernen Publishing-möglichkeiten, z.B. FTP über SSL (Secure Sockets Layer), und einer mitgliederbasierten Authentifi-zierung anbieten können.

Welche Neuerungen bietet IIS 7.0?IIS 7.0 wurde von Grund auf neu gestaltet und aufgebaut. Die neuen Features und Funktionen bieten Administratoren und Entwicklern viele neue Möglichkeiten:

� Die genaue Kontrolle über die Installationsgröße des Webservers trägt dazu bei, dass weniger Patches installiert werden müssen und das Sicherheitsrisiko sinkt.

� Es ist möglich, neue Weblösungen mit Hilfe des Erweiterbarkeitsframeworks schnell zu implementieren.

� Durch die vereinfachte Bereitstellung und Anwendungskonfiguration kann eine schnellere Veröffentlichung erzielt werden.

� Die Administrationskosten werden dadurch verringert, dass Webinfrastrukturen nun effizienter verwaltet werden können.

� Die Ausfallzeiten von Websites können verringert werden, da es möglich ist, Anwendungsfehler schneller zu beheben.

Diese Verbesserungen wurden durch wichtige Neuerungen in IIS 7.0 möglich, die nachfolgend aufgeführt sind:

� Ein modularer, erweiterbarer Webserverkern

� Ein vereinheitlichtes, verteiltes und dateibasiertes Konfigurationssystem

� Integrierte Systemzustandsüberwachung und Diagnose

� Eine Gruppe neuer Verwaltungstools mit der Möglichkeit zur Delegierung

Darüber hinaus bietet IIS 7.0 einen neuen Dienst namens WAS (Windows Process Activation Service) an, der das IIS 7.0-Prozessmodell für gewöhnliche und auf HTTP basierende Anwendungen und Dienste offenlegt.

Lassen Sie uns einen genaueren Blick auf diese Neuerungen und deren Vorteile gegenüber den vor-herigen IIS-Versionen werfen.

Der WebserverkernDer IIS 7.0-Webserverkern wurde vollständig überarbeitet und weist, verglichen mit IIS 6.0, große Unterschiede auf. Eine neue, komplett aus einzelnen Komponenten zusammengesetzte Architektur hält zwei wichtige Erweiterungen bereit, die die Basis für viele Verbesserungen in den Bereichen Sicherheit, Leistung, Skalierbarkeit, Verwaltbarkeit und Flexibilität bilden. Diese beiden fundamentalen Erweite-rungen sind Modularität und Erweiterbarkeit.



ModularitätBei den vorherigen IIS-Versionen war die gesamte Funktionalität standardmäßig in einem monolithischen Server integriert. Es gab keine einfache Möglichkeit, um diese Funktionalität zu erweitern oder zu ersetzen. Der Webserverkern von IIS 7.0 weist eine vollständig modulare Architektur auf. Alle Webserver-features werden nun als eigenständige Komponenten verwaltet. Der IIS 7.0-Webkern ist in mehr als vierzig separate Komponenten unterteilt, die jeweils ein bestimmtes Feature oder eine bestimmte Funktionalität implementieren. Diese Komponenten werden als Module bezeichnet. Sie können diese Module abhängig von Ihren Anforderungen hinzufügen, entfernen und ersetzen.

IIS 7.0 integriert die ASP.NET-Laufzeit in den Webserverkern, wodurch eine vereinheitlichte Anforde-rungsverarbeitungspipeline entsteht. Sowohl systemeigener als auch verwalteter Code werden über diese einzelne Anforderungspipeline verarbeitet. Alle Benachrichtigungsereignisse in der Anforde-rungspipeline werden sowohl für die systemeigenen als auch die verwalteten Module offen gelegt. Diese Verflechtung führt dazu, dass bereits vorhandene ASP.NET-Features – z.B. die formularbasierte Authentifizierung, die Mitgliedschaft, der Sitzungszustand usw. – für alle Inhaltstypen verwendet werden können, so dass die gesamte Webanwendung ein einheitliches Arbeitsumfeld bietet.

Abbildung 1.1 zeigt verschiedene Phasen vom Beginn bis zum Ende der vereinheitlichten Anforde-rungsverarbeitungspipeline. In der Anforderungsauthentifizierungsphase zeigt Abbildung 1.1 Authentifizierungsmodule, die für alle Anforderungen zur Verfügung stehen. Die Standardauthentifi-zierung, Windows-Authentifizierung und anonyme Authentifizierung sind systemeigene Module. Die Formularauthentifizierung ist ein verwaltetes Modul. Sowohl systemeigene als auch verwaltete Authentifizierungsmodule bieten Dienste für alle Inhaltstypen an, z.B. für verwalteten Code, systemeigenen Code und statische Dateien.

Abbildung 1.1 Die integrierte Anforderungsverarbeitung von IIS 7.0



Hinweis Weitere Informationen zur Anforderungsverarbeitung finden Sie im zweiten Kapitel, »Grundlagen der IIS 7.0-Architektur«.

Durch die IIS 7.0-Modularität ergeben sich die folgenden Möglichkeiten:

� Sichern des Servers durch Verkleinern der Angriffsfläche Das Verkleinern der Angriffsfläche ist einer der wichtigsten Schritte auf dem Weg zu einem sicheren System. Bei IIS 7.0 können nicht benötigte Webserverfeatures ohne Auswirkung auf die Anwendungsfunktionalität sicher entfernt werden, wodurch die Angriffsfläche verkleinert wird.

� Verbessern der Leistung und Verringern des benötigten Arbeitsspeichers Wenn Sie nicht benötigte Webserverfeatures entfernen, wird die Größe des vom Server beanspruchten Arbeits-speichers verringert. Darüber hinaus wird die Menge des Codes, der für jede Anforderung ausge-führt werden muss, verringert, was zu einer verbesserten Leistung führt.

� Erstellen von angepassten und spezialisierten Servern Wenn Sie einen bestimmten Satz Serverfeatures auswählen und die nicht benötigten Features entfernen, können Sie angepasste Server erstellen, die für bestimmte Funktionen, wie z.B. das Edge-Caching oder den Lasten-ausgleich, optimiert sind.

Hinweis Weitere Informationen zur Modularität des Servers finden Sie im dritten Kapitel, »Verstehen der modu-laren Basis«.

ErweiterbarkeitDie modulare Architektur von IIS 7.0 ermöglicht es Ihnen, Serverkomponenten zu erstellen, die eine bereits vorhandene Funktionalität erweitern oder ersetzen und die für die von IIS gehosteten Web-anwendungen einen zusätzlichen Nutzen darstellen.

Der Webserverkern enthält eine neue Win32-API zur Erstellung von Serverkernmodulen. Sie können benutzerdefinierte Features hinzufügen, um die bereits vorhandenen Webserverfeatures zu erweitern oder zu ersetzen. Dies ist mit eigenem Code und Webserverkern-Erweiterungen von Drittanbietern möglich. Sowohl der eigene Code als auch die Erweiterungen müssen dabei unter Verwendung dieser neuen Erweiterbarkeits-API erstellt worden sein.

Die Webserverkernmodule stellen einen neuen und leistungsfähigeren Ersatz für ISAPI-Filter und -Erweiterungen (Internet Server Application Programming Interface) dar, obwohl diese Filter und Erweiterungen auch weiterhin von IIS 7.0 unterstützt werden. Das neue C++-Erweiterbarkeitsmodell von IIS 7.0 verwendet eine vereinfachte objektorientierte API, mit der es möglich ist, stabilen Server-code zu schreiben, so dass weniger Probleme als bei der bisherigen ISAPI-Entwicklung auftreten.

IIS 7.0 unterstützt außerdem die Entwicklung von Webserverkern-Erweiterungen mit Hilfe des .NET Frameworks. In IIS 7.0 ist die IHttpModule-API für ASP.NET integriert, weshalb Module, die aus benut-zerdefiniertem verwalteten Code bestehen, auf alle Ereignis in der Anforderungspipeline zugreifen können, und zwar für alle Anforderungen.

Die ASP.NET-Integration in IIS 7.0 erlaubt die schnelle Entwicklung von Servermodulen mit Hilfe der Möglichkeiten, die ASP.NET und das .NET Framework bieten. Der Einsatz der maschinennahen C++-IIS-API ist somit nicht mehr notwendig. Verwaltete ASP.NET-Module können den Server uneinge-schränkt erweitern und Anforderungen bedienen, die sich auf alle möglichen Inhaltstypen beziehen, z.B. ASP, CGI (Common Gateway Interface) und statische Dateien.



Wenn Entwickler ASP.NET oder die native C++-Erweiterbarkeit nutzen, können sie Lösungen erstellen, die von allen Anwendungskomponenten, z.B. benutzerdefinierte Authentifizierungsschemata, Überwachung und Protokollierung, Sicherheitsfilterung, Lastenausgleich, Inhaltsumleitung und Zustandsverwaltung, genutzt werden können.

Hinweis Um weitere Informationen zur Erweiterbarkeit des Webserverkerns zu erhalten, lesen Sie bitte das zwölfte Kapitel, »Verwalten von Webservermodulen«.

KonfigurationDie frühen IIS-Versionen verfügten über nur wenige Konfigurationseinstellungen, die in der Windows-Registrierung gespeichert wurden. IIS 5.0 führte einen binären Speicher zur Verwaltung der URL-basierten Konfiguration ein, der als Metabasis bezeichnet wurde. Bei IIS 6.0 wurde die binäre Meta-basis durch eine auf XML basierende Metabasis ersetzt, um Konfigurationsdaten zu speichern. IIS 7.0 führt ein verteiltes, dateibasiertes XML-Konfigurationssystem ein, mit dem die Administratoren Einstellungen für IIS und seine Features in XML-Klartextdateien vornehmen können, die zusammen mit dem Code und den Inhalten gespeichert werden. Die XML-Dateien nehmen die Konfigurations-einstellungen für die gesamte Webserverplattform auf. Dazu zählen auch IIS, ASP.NET und andere Komponenten. Die Dateien speichern Einstellungen der Server-, Site- und Anwendungsebene, und sie können optional auf der Inhaltsverzeichnisebene gesetzt werden, wo sich auch die Webinhalte befinden, so dass eine delegierte Verwaltung möglich wird.

Da Website- und Anwendungseinstellungen nicht länger an einen zentralisierten Konfigurations-speicher auf dem lokalen Computer gebunden sind – wie dies bei älteren Versionen von IIS der Fall war –, vereinfacht das verteilte dateibasierte Konfigurationssystem die Anwendungsentwicklung in hohem Maße, indem es eine xcopy-Bereitstellung der Konfiguration in Verbindung mit dem Anwendungscode und den Inhalten bietet. Darüber hinaus ermöglicht dieses Konfigurationssystem die gemeinsame Nutzung einer Site- oder Anwendungskonfiguration innerhalb einer Webfarm.

Die IIS 7.0-Konfiguration basiert auf dem .NET Framework-Konfigurationsspeicher. Dieses gebräuch-liche Format trägt dazu bei, dass IIS-Konfigurationseinstellungen zusammen mit der ASP.NET-Konfiguration in einer aus web.config-Dateien bestehenden Hierarchie gespeichert werden können, wodurch ein Konfigurationsspeicher für alle Webplattform-Konfigurationseinstellungen entsteht, auf die über eine bestimmte Gruppe von APIs zugegriffen werden kann und die in einem einheitlichen Format gespeichert werden.

Die verteilte Konfigurationshierarchie enthält die globalen, computerweit gültigen .NET Framework-Konfigurationsdateien, machine.config und die web.config-Stammdatei, die globale IIS-Konfigura-tionsdatei applicationHost.config und die verteilten web.config-Konfigurationsdateien, die sich wie in Abbildung 1.2 dargestellt in den Websites, Anwendungen und Verzeichnissen befinden.

Die globalen .NET Framework-Einstellungen für einen Servercomputer sind in der machine.config-Datei gespeichert, die sich im Ordner %SystemRoot%\Microsoft .NET\Framework \<version>\config befindet. Globale ASP.NET-Einstellungen für einen Webserver sind in der web.config-Stammdatei gespeichert, die im selben Ordner des Servercomputers enthalten ist.

IIS 7.0 speichert die globale Konfiguration in der applicationHost.config-Datei, die sich im Ordner %SystemRoot%\System32\Inetsrv\Config befindet. ApplicationHost.config besitzt zwei wichtige Konfigurationsabschnitte: <system.applicationHost> und <system.webServer>.



Abbildung 1.2 Dateibasierter verteilter Konfigurationsspeicher

Der Abschnitt <system.applicationHost> enthält Einstellungen für Sites, Anwendungen, virtuelle Verzeich-nisse und Anwendungspools. Der Abschnitt <system.webServer> enthält die Konfiguration aller anderen Einstellungen, einschließlich der globalen Webstandards.

Die URL-spezifische Konfiguration wird mit Hilfe von <location>-Tags in applicationHost.config gespeichert. Um die URL-spezifische Konfiguration für einzelne Sites, Anwendungen und Inhalts-verzeichnisse des Servers zu lesen und zu schreiben, verwendet IIS 7.0 die web.config-Dateihierarchie. Dort befindet sich auch die ASP.NET-Konfiguration.

Abbildung 1.3 zeigt die Struktur der web.config-Datei einer Site. Sie sehen dort außerdem, wie diese Datei von den globalen Konfigurationsdateien erbt.

Abbildung 1.3 Die web.config-Datei einer Site



Der Serveradministrator kann verschiedene Ebenen der Konfigurationshierarchie an andere Benutzer delegieren, z.B. an den Siteadministrator oder an die Anwendungsentwickler. Das Setzen von Konfi-gurationseinstellungen ist standardmäßig ausschließlich auf den Serveradministrator beschränkt. Der Serveradministrator kann die Verwaltung bestimmter Konfigurationseinstellungen an Benutzer dele-gieren, die über keine administrativen Rechte für den Servercomputer verfügen.

Die dateibasierte Konfiguration für eine bestimmte Site oder Anwendung kann von einem Computer auf einen anderen kopiert werden. Dies ist beispielsweise dann möglich, wenn die Anwendung von der Entwicklungsphase in die Testphase übergeht und schließlich veröffentlicht wird. Aufgrund der gemeinsamen Bereitstellung von Konfiguration, Code und Inhalten mit Hilfe von xcopy ist es sehr einfach, Anwendungen in IIS 7.0-Systemen bereitzustellen.

Das verteilte Konfigurationssystem trägt außerdem dazu bei, dass innerhalb einer Webserverfarm die Konfiguration einer Site oder Anwendung gemeinsam genutzt werden kann, so dass alle Server die Konfigurationseinstellungen von einem einzelnen Server abrufen. Nachdem eine Website in Betrieb genommen wurde, können die Administratoren die Konfigurationsinformationen über mehrere Front-End-Webserver hinweg gemeinsam nutzen, wodurch kostenintensive und fehleranfällige Replikationen und Probleme mit der manuellen Synchronisierung vermieden werden.

Dass IIS 7.0-Konfigurationssystem ist uneingeschränkt erweiterbar und ermöglicht es Ihnen, den Konfigurationsspeicher dahingehend zu erweitern, dass er benutzerdefinierte Konfigurationen auf-nimmt. Auf der API-Ebene ist das System mit älteren Versionen von IIS abwärtskompatibel. Gleiches gilt für ältere Versionen des .NET Frameworks und die XML-Ebene.

Hinweis Um weitere Informationen zum verteilten IIS 7.0-Konfigurationssystem zu erhalten, lesen Sie bitte das vierte Kapitel, »Verstehen des Konfigurationssystems«.

VerwaltungstoolsDie IIS 7.0-Verwaltungstools wurden vollständig neu entwickelt. Sie bieten unterschiedliche Schnitt-stellen an, um aus der aus Konfigurationsdateien bestehenden Hierarchie des Servers zu lesen und darin zu schreiben. Zu diesen Dateien zählen beispielsweise applicationHost.config, die web.config-Stamm-datei des .NET Frameworks und die web.config-Dateien für einzelne Sites, Anwendungen und Verzeichnisse. Sie stellen aber auch Schnittstellen für die Arbeit mit Laufzeitinformationen und verschiedenen Anbietern zur Verfügung.

IIS 7.0 hält die folgenden Verwaltungstools bereit:

� Der IIS-Manager ist eine neue Verwaltungskonsole, die mit einer intuitiven, feature- und aufgabenorientierten grafischen Benutzeroberfläche zur Verwaltung von IIS 7.0 und ASP.NET arbeitet. Bei IIS 7.0 wird der IIS-Manager als Windows Forms-Anwendung implementiert, die das MMC-Snap-In älterer IIS-Versionen ersetzt.

� Das Befehlszeilentool Appcmd.exe ersetzt die Befehlszeilenskripts von IIS 6.0. Es erlaubt den Zugriff auf die Konfigurationsdateienhierarchie und andere Servereinstellungen über die Befehlszeile.



� Die Schnittstelle Microsoft.Web.Administration stellt eine streng typisierte verwaltete API zur Verfügung, mit der verwalteter Code auf die Konfiguration und andere Servereinstellungen zugreifen kann.

� Ein neuer WMI-Anbieter ermöglicht den Skriptzugriff auf alle IIS- und ASP.NET-Konfigurationen. Der alte WMI-Anbieter von IIS 6.0 ist auch weiterhin verfügbar, um die Abwärtskompatibilität mit bereits vorhandenen Skripts zu gewährleisten.

Sie können ebenfalls Windows PowerShell für einen leistungsfähigen Skriptzugriff auf die verteilte Konfigurationshierarchie benutzen.

Hinweis Um weitere Informationen zum Einsatz von PowerShell für die IIS 7.0-Verwaltung zu erhalten, lesen Sie bitte das siebte Kapitel, »Verwenden von Befehlszeilentools«.

Windows Server 2008 stellt außerdem das IIS 6.0-MMC-Snap-In zur Verfügung, um die Remote-verwaltung sowie die Verwaltung von FTP-Sites zu ermöglichen.

Alle neuen Verwaltungstools unterstützen uneingeschränkt die neue verteilte IIS 7.0-Konfiguration, und jedes dieser Tools ermöglicht das Delegieren des Zugriffs auf die Konfiguration einzelner Sites und Anwendungen. Dieser Zugriff kann an Benutzer delegiert werden, die für den Servercomputer über keine administrativen Rechte verfügen.

Hinweis Sie können die Verwaltungstools und die Webserverkomponenten unabhängig voneinander installieren.

Abbildung 1.4 zeigt die Benutzeroberfläche des neuen IIS-Managers, die der eines Browsers gleicht und die wie der Windows-Explorer über eine Adressleiste verfügt. Der Hauptteil des IIS-Manager-Fensters ist in drei Bereiche gegliedert:

� Der Verbindungsbereich auf der linken Seite des IIS-Manager-Fensters ermöglicht es Ihnen, Verbindungen zu Servern, Sites und Anwendungen herzustellen. Die Verbindungen werden in einer hierarchischen Struktur dargestellt.

� Ein zentraler Bereich, der als Arbeitsbereich bezeichnet wird, befindet sich in der Mitte des IIS-Manager-Fensters. Der Arbeitsbereich besteht aus zwei Ansichten: Features und Inhalt.

� In der Ansicht Features können Sie die Features des gegenwärtig ausgewählten Konfigurations-pfades betrachten und konfigurieren. Jedes IIS-Manager-Feature ist in der Regel einem Konfi-gurationsabschnitt zugeordnet, der das entsprechende Webserverfeature kontrolliert.

� Die Ansicht Inhalt stellt die Inhalte, die sich auf den gegenwärtig ausgewählten Konfigurations-pfad beziehen, schreibgeschützt dar. Wenn Sie die Ansicht Inhalt aktiviert haben und in der hierarchischen Struktur des Verbindungsbereichs einen Knoten auswählen, wird dessen Inhalt im Arbeitsbereich aufgelistet.

� Rechts im IIS-Manager-Fenster befindet sich der Bereich Aktionen. Die Einträge im Bereich Aktionen beziehen sich auf bestimmte Aufgaben und sind vom jeweiligen Kontext abhängig.



Abbildung 1.4 Die grafische Benutzeroberfläche des IIS-Managers

Die Delegierung der Verwaltung ist wie bei den anderen Verwaltungstools eine der wichtigsten Fähig-keiten des IIS-Managers. Mit dieser Funktionalität können die Benutzer von gehosteten Diensten den IIS-Manager auf dem eigenen Desktop ausführen und eine Remoteverbindung herstellen, um ihre Sites und Anwendungen auf dem hostenden Server zu verwalten, ohne für diesen Servercomputer über administrative Rechte zu verfügen. Zur Identifizierung von Benutzern kann der IIS-Manager Windows-Anmeldeinformationen, aber auch andere Anmeldeinformationsspeicher verwenden. IIS-Manager-Anmeldeinformationen sind besonders dann nützlich, wenn Sie nicht für alle Remotebenutzer Windows-Konten erstellen möchten oder wenn die Anmeldeinformationen bereits in einem nicht von Windows genutzten Authentifizierungssystem gespeichert sind und Sie nur diesen einen Speicher verwenden möchten.

Der IIS-Manager unterstützt die Remoteverwaltung über HTTPS-Verbindungen, die von einer Firewall nicht behindert werden. Dadurch wird eine lokale Verwaltung bzw. eine Remoteverwaltung möglich, die nicht auf DCOM (Distributed Component Object Model) und auch nicht darauf angewiesen ist, dass andere administrative Ports der Firewall geöffnet werden. Bei IIS 6.0 geschah der Remotezugriff auf die Verwaltungskonsole über MMC und er war immer aktiv. Bei IIS 7.0 ist dies anders. Hier ist die Remote-verwaltung über den IIS-Manager standardmäßig deaktiviert und muss explizit aktiviert werden. Damit die Remoteverwaltung von IIS 7.0 möglich ist, muss auf dem Servercomputer der Webverwaltungsdienst (WMSvc, Web Management Service) installiert sein. Außerdem müssen die Remoteverbindungen zu diesem Dienst aktiviert sein. WMSvc ist ein Windows-Dienst, der die Möglichkeit bietet, IIS 7.0-Sites und -Anwendungen mit Hilfe des IIS-Managers remote zu verwalten. Die Remotearchitektur des IIS-Managers ist in Abbildung 1.5 dargestellt.



Abbildung 1.5 Die Remotearchitektur des IIS-Managers

Der IIS 7.0-Manager ist anpassbar und erweiterbar. Er besitzt eine eigene Konfigurationsdatei namens administration.config, mit der es möglich ist, dem Tool eine benutzerdefinierte Funktionalität hinzu-zufügen. Alle hinzugefügten Verwaltungs-Plug-Ins werden in das Tool integriert und zusammen mit den IIS- und ASP.NET-Features aufgeführt.

Hinweis Um weitere Informationen zum IIS-Manager zu erhalten, lesen Sie bitte das sechste Kapitel, »Verwenden von IIS-Manager«. Weitere Informationen zu Appcmd.exe, WMI und der Microsoft.Web.Administration-API gibt es im siebten Kapitel.

DiagnoseIIS 7.0 führt wesentliche Verbesserungen der Diagnose und Behebung von Problemen ein, die durch Websites und Anwendungen verursacht werden. Sie können Probleme schneller beheben und die Ausfall-zeiten von Websites auf ein Mindestmaß reduzieren, wenn Sie die neuen leistungsfähigen Diagnose-möglichkeiten nutzen. Dazu zählen beispielsweise der Zugriff auf Laufzeitinformationen und die automatische Nachverfolgung fehlgeschlagener Anforderungen. Die in IIS 7.0 neuen Diagnose- und Problembehandlungsoptionen ermöglichen es Ihnen, Anforderungen, die auf dem Server verarbeitet werden, in Echtzeit zu verfolgen, und Fehler mit Hilfe eines detaillierten Ablaufverfolgungsprotokolls automatisch zu erfassen.

Zugriff auf LaufzeitinformationenIIS 7.0 enthält eine neue API namens RSCA (Runtime State and Control API), die Echtzeitstatus-informationen über Anwendungspools, Arbeitsprozesse, Sites, Anwendungsdomänen und laufende Anforderungen zur Verfügung stellt.

Die RSCA wurde entwickelt, damit die Administratoren einen tiefen Einblick in den aktuellen Zustand der Laufzeitobjekte erhalten, zu denen auch die aktuellen Arbeitsprozesse und die gegenwärtig von diesen Prozessen ausgeführten Anforderungen zählen. Außerdem soll den Administratoren mit RSCA die Möglichkeit geboten werden, ein und dieselbe API zur Steuerung dieser Objekte zu verwenden. Mit RSCA können die Administratoren detaillierte Laufzeitdaten abrufen, die früher nicht verfügbar waren.

Diese Informationen werden über eine native COM-API (Component Object Model) offen gelegt. Die API selbst ist in einem Wrapper eingeschlossen und wird durch diesen zur Verfügung gestellt. Dabei kann es sich um den neuen WMI-Provider von IIS 7.0, die Microsoft.Web.Administration-API, das Befehlszeilenverwaltungstool Appcmd.exe und den IIS-Manager handeln.



Administratoren, die mit dem IIS-Manager arbeiten, können beispielsweise Laufzeitinformationen abrufen, die Aufschluss darüber geben, welche Anforderungen gegenwärtig ausgeführt werden und wie lange dies bereits geschieht, welche URLs von ihnen aufgerufen werden, welche Clients die Anforderungen einreichten und wie ihr Status ist.

Ablaufverfolgung für AnforderungsfehlerIIS 7.0 produziert für den gesamten Anforderungs- und Antwortpfad detaillierte Ablaufverfolgungs-ereignisse, so dass Sie eine Anforderung auf ihrem Weg zu IIS, durch die IIS-Anforderungsverarbei-tungspipeline, in den Seitencode hinein und aus diesem wieder heraus bis zur Antwort nachverfolgen können. Mit Hilfe dieser ausführlichen Ablaufverfolgungsereignisse können Sie nicht nur den Verlauf des Anforderungspfades und alle Informationen zu möglichen, durch eine Anforderung verursachten Fehlern verstehen, sondern Sie erhalten ebenfalls Daten zur verstrichenen Zeit und zum Debuggen, die Ihnen helfen, Fehler zu beheben und den Ursachen für ein nicht mehr reagierendes System nach-zugehen.

Probleme, wie z.B. eine unzureichende Leistung bei einigen Anforderungen, Authentifizierungsfehler bei anderen Anforderungen und der Serverfehler 500, sind oft nur schwer zu beheben, wenn Sie die Spur des jeweiligen Problems nicht nachverfolgen. Hier kann die Ablaufverfolgung für Anforderungs-fehler hilfreich sein. Sie wurde entwickelt, um die auf eine Anforderung bezogenen Ablaufverfolgungs-ereignisse zu puffern und im Falle eines Fehlers auf dem Datenträger in einem Ablaufverfolgungs-protokoll zu speichern. Um die Protokollierung der Ablaufverfolgungsereignisse zu aktivieren, können Sie IIS 7.0 so konfigurieren, dass, abhängig von der verstrichenen Zeit oder den jeweiligen Antwort-fehlercodes, für jede betroffene Anforderung vollständige Ablaufverfolgungsprotokolle im XML-Format generiert werden.

Die Diagnosemöglichkeiten von IIS 7.0 können erweitert werden, indem beispielsweise neue Ablauf-verfolgungsereignisse in benutzerdefinierten Modulen definiert werden.

Hinweis Weitere Informationen zur Diagnose und Problembehandlung erhalten Sie im sechzehnten Kapitel, »Ablaufverfolgung und Problembehandlung«.

Windows-ProzessaktivierungsdienstIIS 7.0 stellt einen neuen protokollunabhängigen Windows-Prozessaktivierungsdienst (WAS; Windows Process Activation Service) zur Verfügung, der ein erweiterter und verallgemeinerter Nachfolger des Windows-Aktivierungsdienstes von IIS 6.0 ist. Das HTTP-Prozessaktivierungsmodell wurde von IIS 6.0 zusammen mit den Anwendungspools eingeführt. Dieser Dienst wurde für IIS 7.0 erweitert, damit er nicht mehr nur Webanwendungen zur Verfügung steht. Er kann Anforderungen und Nachrichten über jedes beliebige Protokoll empfangen und unterstützt die Aktivierung von frei wählbaren Protokoll-Listenern während des Betriebs. WAS ist nicht nur protokollunabhängig, sondern versorgt auch alle nachrichtenaktivierten Anwendungen mit einer intelligenten Ressourcenverwaltung, bedarfsorien-tierten Prozessaktivierung, Zustandsüberwachung und automatischen Fehlererkennung und Wieder-herstellung. Die WCF (Windows Communication Foundation) wird mit Protokolladaptern ausgeliefert, die die WAS-Fähigkeiten nutzen können. Das Nutzen dieser Fähigkeiten kann die Betriebssicherheit und den Ressourcenverbrauch der WCF-Dienste drastisch verbessern.

Hinweis Weitere Informationen zu WAS und zur Nicht-HTTP-Unterstützung in IIS 7.0 finden Sie im zweiten Kapitel.


Grundlegende Verwaltungsaufgaben 15

AnwendungskompatibilitätIIS 7.0 ist kompatibel mit älteren IIS-Versionen. Die meisten bereits vorhandenen ASP-, ASP.NET 1.1- und ASP.NET 2.0-Anwendungen sollten unter IIS 7.0 ohne Codeänderungen ausgeführt werden können, wenn die ISAPI-Kompatibilitätsunterstützung genutzt wird.

Alle bereits vorhandenen ISAPI-Erweiterungen und die meisten ISAPI-Filter funktionieren ebenfalls weiterhin. ISAPI-Filter, die mit der READ RAW DATA-Benachrichtigung arbeiten, werden jedoch von IIS 7.0 nicht unterstützt.

Für bereits vorhandene Active Directory-Dienstschnittstellen und WMI-Skripts bietet IIS 7.0 die gleichen Features wie ältere Versionen. Skripts können die alten Konfigurationsschnittstellen über die Metabasiskompatibilitätsschicht nutzen.

Hinweis Weitere Informationen zur Anwendungskompatibilität finden Sie im elften Kapitel, »Hosting von Anwendungsentwicklungsframeworks«.

Grundlegende VerwaltungsaufgabenDamit ein Webserver beginnen kann, Inhalte bereitzustellen, muss er über eine Grundkonfiguration ver-fügen: eine Site, eine Anwendung, ein virtuelles Verzeichnis und ein Anwendungspool. IIS 7.0 stellt eine Standardkonfiguration zur Verfügung. Diese Konfiguration besteht aus der Standardwebsite (Default Web Site) mit einer Stammanwendung, die dem physikalischen Verzeichnis %SystemDrive%\Inetpub\Wwwroot zugeordnet ist, und einem Standardanwendungspool namens DefaultAppPool, der die Stammanwendung enthält.

Sie werden jedoch wahrscheinlich eine eigene Site erstellen, dieser eine Anwendung hinzufügen, der Anwendung ein virtuelles Verzeichnis hinzufügen, einen neuen Anwendungspool erstellen und diesem die Anwendung zuordnen wollen. Die folgenden Abschnitte beschreiben, wie diese grundlegenden Verwaltungsaufgaben mit dem IIS-Manager gelöst werden.

Hinweis Informationen zur Durchführung anderer gebräuchlicher Verwaltungsaufgaben finden Sie in Anhang J, »Den IIS-Manager für übliche Verwaltungsaufgaben verwenden«.

Um den IIS-Manager aus der Programmgruppe Verwaltung heraus zu starten, rufen Sie den Internet-informationsdienste-Manager auf.

Websites erstellenEine Site ist ein Container für Anwendungen und virtuelle Verzeichnisse. Der Zugriff auf eine Site erfolgt über eindeutige Bindungen. Die Bindung besteht aus dem Bindungsprotokoll und den Bin-dungsinformationen. Das Bindungsprotokoll definiert das Protokoll, über das der IIS 7.0-Server und ein Webclient, z.B. ein Browser, miteinander kommunizieren. Die Bindungsinformationen legen die Daten fest, die für den Zugriff auf die Site verwendet werden. Das Bindungsprotokoll einer Website kann beispielsweise HTTP oder HTTPs sein, und die Bindungsinformationen sind eine Kombination aus IP-Adresse, Port und optionalem Hostheader.



Um mit dem IIS-Manager eine Website zu erstellen, gehen Sie wie folgt vor:

1. Erweitern Sie im Bereich Verbindungen den Serverknoten, klicken Sie mit der rechten Maustaste auf den Knoten Sites, und wählen Sie anschließend Website hinzufügen aus. Das gleichnamige Dialogfeld erscheint.

2. Geben Sie in das Feld Sitename einen Namen für Ihre Website ein, z.B. www.contoso.com.

3. Möchten Sie einen anderen als den vorgegebenen Anwendungspool zuweisen, klicken Sie auf Aus-wählen. Wählen Sie anschließend im Dialogfeld Anwendungspool auswählen und dort im Drop-down-Listenfeld Anwendungspool den gewünschten Anwendungspool und klicken Sie auf OK.

4. Geben Sie in das Feld Physikalischer Pfad den physikalischen Pfad des Websiteordners ein oder wählen Sie diesen Ordner nach einem Klick auf die Durchsuchen-Schaltfläche (...) aus.

Wenn der von Ihnen eingegebene physikalische Pfad auf einen freigegebenen Remoteordner ver-weist, klicken Sie auf Verbinden als und legen die notwendigen Anmeldeinformationen fest. Wenn für den Zugriff auf den Pfad keine Anmeldeinformationen erforderlich sind, wählen Sie im Dialog-feld Verbinden als die Option Anwendungsbenutzer (Pass-Through-Authentifizierung).

5. Klicken Sie optional auf Einstellungen testen, um die von Ihnen vorgenommenen Einstellungen zu überprüfen.

6. Konfigurieren Sie die gewünschten Bindungen für Ihre neue Site:

� Wenn Sie für den Websitezugriff HTTPS benutzen, ändern Sie im Dropdown-Listenfeld Typ das Protokoll. Wählen Sie anstelle von HTTP den Eintrag HTTPS.

� Wenn Sie der Site eine statische IP-Adresse fest zuordnen möchten, geben Sie diese in das Feld IP-Adresse ein. Wenn Sie über keine statische IP-Adresse für die Site verfügen, lassen Sie den Vorgabewert Keine zugewiesen unverändert.



� Wenn Ihre Site eine andere Portnummer als den Standardport 80 verwenden soll, geben Sie diese Nummer in das Feld Port ein.

� Soll Ihre Site einen Hostheader benutzen, geben Sie diesen Hostheadernamen in das Feld Host-name ein. Sie könnten beispielsweise www.contoso.com eingeben.

7. Soll die Website sofort verfügbar sein, aktivieren Sie das Kontrollkästchen Website sofort starten.

8. Klicken Sie auf OK. Die neue Website wird erstellt und erscheint im Bereich Verbindungen.

Anwendungen erstellenEine Anwendung ist eine Gruppe von Dateien, die Inhalte oder Dienste über Protokolle, wie z.B. HTTP, bereitstellen. Bei Erstellung einer Anwendung wird der Anwendungspfad zu einem Teil des URLs.

Eine Site kann viele Anwendungen enthalten, einschließlich der Standardanwendung der Site, die als Stammanwendung bezeichnet wird. Doch eine Anwendung ist nicht nur einer Site zugeordnet, sondern auch einem Anwendungspool, der die Anwendung von anderen Anwendungen in anderen Anwendungs-pools des Servers isoliert.

Um mit dem IIS-Manager eine Anwendung zu erstellen, gehen Sie wie folgt vor:

1. Klicken Sie im Bereich Verbindungen mit der rechten Maustaste auf die Site, in der die neue Anwendung ausgeführt werden soll. Wählen Sie anschließend Anwendung hinzufügen. Das Dialog-feld Anwendung hinzufügen erscheint.

2. Geben Sie in das Feld Alias einen Wert für den Anwendungs-URL ein, z.B. Werbung. Dieser Wert wird benutzt, um über einen URL auf die Anwendung zuzugreifen.

3. Möchten Sie einen anderen als den vorgegebenen Anwendungspool zuweisen, klicken Sie auf Aus-wählen. Wählen Sie anschließend im Dialogfeld Anwendungspool auswählen und dort im Drop-down-Listenfeld Anwendungspool den gewünschten Anwendungspool und klicken Sie auf OK.






6. Klicken Sie auf OK. Die neue Anwendung wird erstellt und erscheint im Bereich Verbindungen.



Virtuelle Verzeichnisse erstellenEin virtuelles Verzeichnis ist ein Verzeichnisname (der auch als Pfad bezeichnet wird). Dieses Ver-zeichnis ist auf dem lokalen Server oder auf einem Remoteserver einem physikalischen Verzeichnis zugeordnet. Der Name wird zu einem Teil des URLs, und eine von einem Browser ausgehende Anfor-derung, die sich auf diesen URL bezieht, greift auf die Inhalte im physikalischen Verzeichnis zu, z.B. auf eine Webseite oder eine Verzeichnisinhaltsliste.

Eine Anwendung kann viele virtuelle Verzeichnisse enthalten. Jede Anwendung muss über ein virtu-elles Stammverzeichnis verfügen, das die Anwendung dem physikalischen Verzeichnis zuordnet, das die Anwendungsinhalte enthält.

Um mit dem IIS-Manager ein virtuelles Verzeichnis zu erstellen, gehen Sie wie folgt vor:

1. Klicken Sie im Bereich Verbindungen mit der rechten Maustaste auf die Site, in der das virtuelle Verzeichnis erscheinen soll. Wählen Sie anschließend Virtuelles Verzeichnis hinzufügen. Das gleichnamige Dialogfeld erscheint.

2. Geben Sie in das Feld Alias einen Wert für den URL des virtuellen Verzeichnisses ein, z.B. Down-load. Dieser Wert wird benutzt, um über einen URL auf das virtuelle Verzeichnis zuzugreifen.




5. Klicken Sie auf OK. Das neue virtuelle Verzeichnis wird erstellt und erscheint im Bereich Verbin-dungen.



Anwendungspools erstellenEin Anwendungspool ist eine Gruppe von Anwendungen, für die ein Arbeitsprozess oder eine Gruppe von Arbeitsprozessen zuständig ist. Anwendungspools legen Grenzen für die in ihnen enthaltenen Anwendungen fest, so dass Anwendungen, die in verschiedenen Anwendungspools ausgeführt werden, voneinander isoliert sind.

Bei IIS 7.0 können ASP.NET-Anforderungen innerhalb von Anwendungspools in einem von zwei verwalteten Pipelinemodi ausgeführt werden: Integriert oder Klassisch. Im integrierten Modus ver-wendet der Server die vereinheitlichte (oder integrierte) Anforderungsverarbeitungspipeline, um eine Anforderung zu verarbeiten. Im klassischen Modus verarbeitet der Server die ASP.NET-Anforderungen mit Hilfe von zwei unterschiedlichen IIS- und ASP.NET-Pipelines, und zwar so, als würde die ent-sprechende Anwendung unter IIS 6.0 ausgeführt werden.

Um mit dem IIS-Manager einen Anwendungspool zu erstellen, gehen Sie wie folgt vor:

1. Erweitern Sie im Bereich Verbindungen den Serverknoten und klicken Sie mit der rechten Maus-taste auf den Knoten Anwendungspools. Wählen Sie anschließend Anwendungspool hinzufügen aus. Das gleichnamige Dialogfeld erscheint.



2. Geben Sie in das Feld Name einen beschreibenden Namen für den Anwendungspool ein, z.B. Werbung.

3. Wählen Sie im Dropdown-Listenfeld .NET Framework-Version die Version des .NET Frameworks, die von Ihren verwalteten Anwendungen, Modulen und Handlern benötigt wird. Wenn die Anwen-dungen, die innerhalb dieses Anwendungspools ausgeführt werden, auf das .NET Framework nicht angewiesen sind, wählen Sie Kein verwalteter Code.

4. Im Dropdown-Listenfeld Verwalteter Pipelinemodus können Sie eine der folgenden Optionen aus-wählen:

� Integriert Wählen Sie diese Option, wenn Sie die integrierte IIS- und ASP.NET-Anforde-rungsverarbeitungspipeline verwenden möchten. Dies ist der Standardmodus.

� Klassisch Wählen Sie diese Option, wenn Sie die IIS- und ASP.NET-Anforderungsverarbei-tungsmodi separat verwenden möchten.

5. Das Kontrollkästchen Anwendungspool sofort starten ist standardmäßig aktiviert. Wenn Sie nicht möchten, dass der Anwendungspool gestartet wird, deaktivieren Sie das Kontrollkästchen.

6. Klicken Sie auf OK. Der neue Anwendungspool wird erstellt und erscheint in der Anwendungs-poolliste.

Einem Anwendungspool eine Anwendung zuweisenSie können eine Anwendung einem eigenen Anwendungspool zuweisen, wenn Sie diese Anwendung von anderen auf dem Server ausgeführten Anwendungen isolieren möchten. Sie können einem Anwen-dungspool mehrere Anwendungen zuweisen, wenn diese dieselben Laufzeitkonfigurationseinstellungen verwenden, z.B. dieselben Arbeitsprozesseinstellungen oder dieselbe ASP.NET-Version.



Um mit dem IIS-Manager eine Anwendung einem Anwendungspool zuzuweisen, gehen Sie wie folgt vor:

1. Klicken Sie im Bereich Verbindungen mit der rechten Maustaste auf die Anwendung, die Sie einem anderen Anwendungspool zuordnen möchten und wählen Sie Anwendung verwalten und dann Erweiterte Einstellungen.

2. Markieren Sie auf der Seite Erweiterte Einstellungen den Eintrag Anwendungspool und klicken Sie auf die Durchsuchen-Schaltfläche (...). Das Dialogfeld Anwendungspool auswählen erscheint.

3. Wählen Sie den Anwendungspool, in dem die Anwendung ausgeführt werden soll.

4. Klicken Sie auf OK. Die Anwendung wird daraufhin dem Anwendungspool zugeordnet.

IIS 7.0 Features unter Windows Server 2008 und Windows VistaIIS 7.0 ist ein Bestandteil von Windows Server 2008 und Windows Vista. Die Verfügbarkeit der IIS 7.0-Features variiert jedoch zwischen Windows Server 2008 und den verschiedenen Editionen von Windows Vista.

Windows Server 2008 enthält alle IIS 7.0-Features. IIS 7.0 ist in allen Editionen von Windows Server 2008 verfügbar. Zwischen diesen Editionen gibt es keine Unterschiede hinsichtlich der IIS-Funk-tionalität. IIS 7.0 steht sowohl auf der 32-Bit- als auch auf der 64-Bit-Plattform zur Verfügung.


IIS 7.0 Features unter Windows Server 2008 und Windows Vista 23

IIS 7.0 wird auch von Windows Server 2008-Grund- oder Kerninstallationen unterstützt. Wenn Sie IIS 7.0 in Verbindung mit solch einem Kernserver verwenden, erhalten Sie einen Webserver, der auf ein Serverbetriebssystem aufsetzt, das nur die grundlegendsten Funktionen bietet. Es beansprucht weniger Festplattenkapazität und weniger Arbeitsspeicher, bietet eine kleinere Angriffsfläche und verursacht einen geringeren Wartungsaufwand. Wird IIS 7.0 auf einem Windows Server 2008-Kernserver installiert, weist es Unterschiede zu einer IIS 7.0-Installation auf einem gewöhnlichen Windows Server 2008-Server auf. Beim Kernserver gibt es keine Windows-Shell und auch kein .NET Framework. Dies bedeutet, dass beim Kernserver der IIS-Manager nicht verfügbar ist und Sie ASP.NET-Module, -Handler und -Anwen-dungen nicht ausführen lassen können. Sie können jedoch ASP-, PHP-, CGI- und andere nicht verwaltete Anwendungen ausführen lassen, wenn IIS 7.0 auf einem Kernserver installiert ist.

Hinweis Weitere Informationen zur Installation von IIS 7.0 auf einem Kernserver erhalten Sie im fünften Kapitel, »Installieren von IIS 7.0«.

Bei den Windows Vista-Editionen hält IIS 7.0 für die Webentwickler eine Webplattform zum Entwickeln und Testen von IIS 7.0-Webanwendungen bereit. Es ermöglicht außerdem die Prozess-aktivierung und stellt WCF-Anwendungen (Microsoft Windows Communication Foundation) eine Verwaltungsinfrastruktur zur Verfügung. Diese Infrastruktur wird vom Windows-Prozessaktivierungs-dienst bereitgestellt.

Die in den Windows Vista-Installationen verfügbaren IIS 7.0-Features sind wie folgt von der jeweiligen Windows Vista-Edition abhängig:

� Bei der Windows Vista-Edition Home Basic richten die IIS 7.0-Komponenten lediglich eine unterstützende Infrastruktur für WCF ein, stellen aber keinen Webserver zur Verfügung, der mit statischen Inhalten, klassischem ASP oder ASP.NET umgehen kann.

� Bei Windows Vista Home Premium sind die meisten IIS 7.0-Webserverfeatures verfügbar, die für die Websiteentwicklung benötigt werden. Der FTP-Server, die erweiterte Webauthentifizierung und -autorisierung sowie die Remoteverwaltung sind jedoch nicht verfügbar.

� Bei den Windows Vista-Editionen Business, Enterprise und Ultimate sind alle IIS 7.0-Features mit Ausnahme der Remoteverwaltung verfügbar.

Tabelle 1.1 listet die in Windows Server 2008 und den Editionen von Windows Vista enthaltenen Features auf. Innerhalb der Tabelle sind die Features in die folgenden Kategorien unterteilt:

� Allgemeine HTTP-Features

� Anwendungsentwicklungsfeatures

� Statusüberwachungs- und Diagnosefeatures

� Sicherheitsfeatures

� Leistungsfeatures

� Verwaltungstools

� Windows-Prozessaktivierungsdienst

� FTP-Publishingdienstfeatures (File Transfer Protocol)

� Maximale Anzahl gleichzeitiger Verbindungen



Innerhalb jeder Kategorie ist die Featureverfügbarkeit wie folgt beschrieben:

� Standard Das Feature ist während der Installation von IIS 7.0 standardmäßig ausgewählt. Sie können entscheiden, das Feature nicht zu installieren, wenn Sie es nicht benötigen.

� Verfügbar Das Feature ist während der Installation von IIS 7.0 verfügbar, aber nicht standardmäßig ausgewählt. Sie können das Feature installieren, wenn Sie es benötigen.

� Nicht verfügbar Das Feature ist während der Installation von IIS 7.0 nicht verfügbar und kann somit nicht installiert werden.

Tabelle 1.1 IIS 7.0 Features unter Windows Server 2008 und Windows Vista

Featurename Windows Server 2008-Editionen

Windows Vista-Editionen

Ultimate, Business und Enterprise

Home Premium Home Basic

Allgemeine HTTP-Features

Statischer Inhalt Standard Standard Standard Nicht verfügbar

Standarddokument Standard Standard Standard Nicht verfügbar

Verzeichnis durchsuchen Standard Standard Standard Nicht verfügbar

HTTP-Fehler Standard Standard Standard Standard

HTTP-Umleitung Standard Standard Standard Standard

Anwendungsentwicklungsfeatures

ASP.NET Verfügbar Verfügbar Verfügbar Nicht verfügbar

.NET-Erweiterbarkeit Standard Standard Standard Standard

ASP Verfügbar Verfügbar Verfügbar Nicht verfügbar

CGI Verfügbar Verfügbar Verfügbar Nicht verfügbar

ISAPI-Erweiterungen Verfügbar Verfügbar Verfügbar Nicht verfügbar

ISAPI-Filter Verfügbar Verfügbar Verfügbar Nicht verfügbar

Serverseitiges Include Verfügbar Verfügbar Verfügbar Nicht verfügbar

Statusüberwachungs- und Diagnosefeatures

HTTP-Protokollierung Standard Standard Standard Standard

Protokollierungstools Standard Standard Standard Standard

Anforderungsüberwachung Standard Standard Standard Standard

Ablaufverfolgung Standard Standard Standard Standard

Benutzerdefinierte Protokollierung Verfügbar Verfügbar Verfügbar Nicht verfügbar

ODBC-Protokollierung Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar


IIS 7.0 Features unter Windows Server 2008 und Windows Vista 25

Sicherheitsfeatures

Standardauthentifizierung Verfügbar Verfügbar Verfügbar Nicht verfügbar

Windows-Authentifizierung Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar

Digest Authentication Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar

Authentifizierung über Clientzertifikat-zuordnung

Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar

Authentifizierung über IIS-Clientzertifikat-zuordnung

Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar

URL-Autorisierung Verfügbar Verfügbar Verfügbar Verfügbar

Anforderungsfilterung Verfügbar Verfügbar Verfügbar Verfügbar

IP- und Domäneneinschränkungen Verfügbar Verfügbar Verfügbar Verfügbar

Performance Features

Komprimierung statischer Inhalte Standard Standard Standard Standard

Komprimierung dynamischer Inhalte Verfügbar Verfügbar Verfügbar Verfügbar

Verwaltungstools

IIS-Verwaltungskonsole (IIS-Manager) Standard Standard Standard Nicht verfügbar

IIS-Verwaltungsskripts und -tools Verfügbar Verfügbar Verfügbar Verfügbar

Verwaltungsdienst Verfügbar Verfügbar Verfügbar Nicht verfügbar

Kompatibilität mit der IIS 6.0-Verwaltung Verfügbar Verfügbar Verfügbar Verfügbar

Kompatibilität mit der IIS-Metabasis Verfügbar Verfügbar Verfügbar Verfügbar

Kompatibilität mit WMI für IIS 6.0 Verfügbar Verfügbar Verfügbar Nicht verfügbar

IIS 6.0-Skripttools Verfügbar Verfügbar Verfügbar Nicht verfügbar

IIS 6.0-Verwaltungskonsole Verfügbar Verfügbar Verfügbar Nicht verfügbar

Windows-Prozessaktivierungsdienstfeatures

Prozessmodell Standard Standard Standard Standard

.NET-Umgebung Verfügbar Verfügbar Verfügbar Verfügbar

Konfigurations-APIs Verfügbar Verfügbar Verfügbar Verfügbar

Tabelle 1.1 IIS 7.0 Features unter Windows Server 2008 und Windows Vista (Fortsetzung)







ZusammenfassungIIS 7.0 wurde von Grund auf neu gestaltet und aufgebaut. IIS 7.0 bietet gegenüber seinen Vorgängern wesentliche Vorteile und sorgt dafür, dass die Entwicklung, Bereitstellung, Konfiguration und Ver-waltung von Webanwendungen und der Webinfrastruktur einfacher und effizienter als jemals zuvor ist.

IIS 7.0 bietet viele neue leistungsfähige Features und Funktionen an, die im Folgenden aufgeführt sind:

� Modularität Die IIS 7.0-Architektur ist vollständig aus einzelnen Komponenten zusammengesetzt. Auf diese Weise können die Administratoren festlegen, welche Features auf dem Webserver installiert und ausgeführt werden sollen. Mit den mehr als vierzig Featuremodulen, die unabhängig voneinander installiert werden können, ist es den Administratoren möglich, die poten-tielle Angriffsfläche zu verkleinern und die Speicheranforderungen des Servers zu verringern.

� Erweiterbarkeit Die grundlegenden Webserverfeatures von IIS 7.0 wurden mit einem neuen Satz reichhaltiger öffentlicher APIs erstellt, die auch von Entwicklern verwendet werden können, um einem Webserver Funktionalität hinzuzufügen oder diese zu erweitern bzw. zu ersetzen. Diese APIs sind als native Win32-APIs sowie als verwaltete .NET Framework-APIs verfügbar. Entwickler können außerdem die IIS-Konfiguration erweitern und IIS-Manager-Erweiterungen erstellen, die sich nahtlos in die Verwaltungskonsole einfügen lassen.

� Vereinheitlichtes verteiltes Konfigurationssystem IIS 7.0 bietet ein vereinheitlichtes, verteiltes und dateibasiertes Konfigurationssystem zum Speichern aller IIS- und ASP.NET-Einstellungen an. Das Speichern geschieht in einem XML-Klartextformat und innerhalb einer Konfigurationsdatei-hierarchie, wo die Konfigurationsdateien zusammen mit den Website- und Anwendungsinhalten verwahrt werden. Dieses Konfigurationssystem ermöglicht die gemeinsame xcopy-Bereitstellung von Konfigurationen, Anwendungscode und Inhalten, und es vereinfacht die gemeinsame Nutzung der Konfiguration innerhalb einer Webfarm.

� Neue Verwaltungstools IIS 7.0 bietet Verwaltungstools an, die die Verwaltung der Webinfra-struktur vereinfachen und mit denen die Administratoren die administrative Kontrolle über Sites und Anwendungen an Entwickler und Inhaltsbesitzer delegieren können. IIS 7.0 enthält eine neue Verwaltungskonsole mit einer grafischen Oberfläche, den IIS-Manager, ein neues Befehlszeilen-tool, Appcmd.exe, einen neuen WMI-Anbieter für die Automatisierung von Verwaltungsaufgaben

FTP-Publishingdienstfeatures (File Transfer Protocol)

FTP-Server Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar

FTP-Verwaltungskonsole Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar

Maximale Anzahl gleichzeitiger Verbindungen

Maximale Anzahl gleichzeitiger Verbindungen

Unbegrenzt 10 3 3

Tabelle 1.1 IIS 7.0 Features unter Windows Server 2008 und Windows Vista (Fortsetzung)






Weitere Informationen 27

und eine neue verwaltete API. All diese Tools unterstützen die einheitliche und gemeinsame Ver-waltung von IIS- und ASP.NET-Einstellungen. Administratoren und Entwickler können ebenfalls Windows PowerShell für den Skriptzugriff auf Konfigurationsinformationen verwenden. Dieser Zugriff ist auf der gesamten Webplattform möglich.

� Integrierte Diagnose Mit IIS 7.0 können Administratoren und Entwickler Ausfallzeiten ver-ringern, wenn sie die neuen Möglichkeiten zur Diagnose und Problembehandlung nutzen. IIS 7.0 legt Laufzeitdiagnoseinformationen offen, wie z.B. Daten über die gegenwärtig ausgeführten Anforderungen. IIS 7.0 kann außerdem so konfiguriert werden, dass es automatisch detaillierte Ablaufverfolgungsereignisse für fehlgeschlagene Anforderungen protokolliert, die sich auf fehlerhafte Websites und Anwendungen beziehen.

Weitere InformationenDiese Quellen enthalten zusätzliche, auf dieses Kapitel bezogene Informationen und Tools:

� Weitere Informationen zur IIS 7.0-Anforderungsverarbeitung finden Sie im zweiten Kapitel, »Grundlagen der IIS 7.0-Architektur«.

� Weitere Informationen zur Modularität finden Sie im dritten Kapitel, »Verstehen der modularen Basis«.

� Weitere Informationen zur IIS 7.0-Erweiterbarkeit finden Sie im zwölften Kapitel, »Verwalten von Webservermodulen«, sowie im dreizehnten Kapitel, »Konfigurations- und Benutzeroberflächen-erweiterungen verwalten«.

� Um weitere Informationen zum vereinheitlichten, verteilten Konfigurationssystem zu erhalten, lesen Sie bitte das vierte Kapitel, »Verstehen des Konfigurationssystems«.

� Weitere Informationen zu den Verwaltungstools finden Sie im sechsten Kapitel, »Verwenden von IIS-Manager«, und im siebten Kapitel, »Verwenden von Befehlszeilentools«.

� Weitere Informationen zu den Problembehandlungsmöglichkeiten von IIS 7.0 und deren Verwen-dung finden Sie im sechzehnten Kapitel, »Ablaufverfolgung und Problembehandlung«, und im siebzehnten Kapitel, »Optimieren der Leistung«.


29

K A P I T E L 2

Grundlagen der IIS 7.0-Architektur

Inhalt dieses Kapitels:� Übersicht über die IIS 7.0-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

� IIS 7.0-Kernkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

� Anforderungsverarbeitung im Anwendungspool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

� Verarbeitung von Nicht-HTTP-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

� Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

� Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Dieses Kapitel wirft einen Blick auf die gesamte Anforderungsverarbeitungsarchitektur von IIS 7.0. Verglichen mit seinen Vorgängern wurde IIS 7.0 komplett überarbeitet. Wie bereits im vorherigen Kapitel erwähnt wurde, gibt es grundlegende, auf die Architektur bezogene Neuerungen, die nach-folgend beschrieben sind:

� Modularität Die Grundfunktionalität des IIS 7.0-Webservers ist mit Hilfe von mehr als vierzig integrierten systemeigenen und verwalteten Modulen implementiert. Da die ASP.NET-Laufzeit in IIS integriert ist, können sowohl systemeigene als auch verwaltete Module Anforderungen bedienen, die sich auf jeden beliebigen Inhaltstypen beziehen. Wir werden uns später in diesem Kapitel mit der integrierten Anforderungsverarbeitungspipeline von IIS 7.0 beschäftigen.

� Erweiterbarkeit IIS 7.0 ist vollständig erweiterbar und stellt einen Satz öffentlicher APIs zur Verfügung, mit deren Hilfe Entwickler die Features und Funktionalität von IIS erweitern können. Die Kernwebservermodule von IIS 7.0 wurden unter Verwendung neuer öffentlicher APIs erstellt, die als native Win32-APIs und als verwaltete .NET-APIs verfügbar sind. Doch die Entwickler können nicht nur den Webserver, sondern auch die IIS-Konfiguration erweitern. Darüber hinaus können sie Erweiterungen für den IIS-Manager erstellen. Die gesamte IIS 7.0-Erweiterbarkeit ist im zwölften Kapitel, »Verwalten von Webservermodulen«, sowie im dreizehnten Kapitel, »Konfigurations- und Benutzeroberflächenerweiterungen verwalten«, beschrieben.

� Konfigurationssystem Bei IIS 7 sind die IIS- und ASP.NET-Konfiguration vereinheitlicht. IIS 7.0 speichert alle IIS- und ASP.NET-Einstellungen gemeinsam in XML-Dateien, die zusammen eine verteilte Konfigurationshierarchie bilden und auch als Konfigurationsspeicher bezeichnet werden. Die Einstellungen selbst werden im Klartextformat gespeichert. Diese Hierarchie ersetzt den alten Konfigurationsspeicher, die Metabasis. Später in diesem Kapitel werden wir einen Blick darauf werfen, wie der Konfigurationsspeicher im Rahmen der Anforderungsverarbeitung genutzt wird. Die IIS 7.0-Konfigurationshierarchie, das Konfigurationsschema und die Konfigurationseinstel-lungen werden außerdem ausführlich im vierten Kapitel, »Verstehen des Konfigurationssystems.


30 Kapitel 2: Grundlagen der IIS 7.0-Architektur

� Verwaltungshilfsmittel IIS 7.0 stellt verschiedene Verwaltungstools zur Verfügung, mit denen es möglich ist, IIS- und ASP.NET-Einstellungen gemeinsam zu verwalten. Sie ermöglichen außerdem das Delegieren der administrativen Kontrolle an Benutzer, die für den Servercomputer über keine administrativen Rechte verfügen. IIS 7.0 enthält eine neue Verwaltungskonsole mit einer grafischen Oberfläche, den IIS-Manager, ein neues Befehlszeilentool, Appcmd.exe, einen neuen WMI-Anbieter für die Automatisierung von Verwaltungsaufgaben und eine neue verwaltete API. Die Verwaltungstools sind ausführlich im sechsten Kapitel, »Verwenden von IIS-Manager«, und im siebten Kapitel, »Verwenden von Befehlszeilentools«, beschrieben.

� Diagnose und Problembehandlung Die Diagnose- und Problembehandlungsmöglichkeiten von IIS 7.0 tragen dazu bei, dass Administratoren und Entwickler die Effizienz verbessern und die Ausfallzeiten verringern können. Da IIS 7.0 außerdem sein Prozessmodell für Nicht-HTTP-Anwendungen und -Dienste offen legt, können auch diese die Diagnosemöglichkeiten nutzen. Wir werden uns später in diesem Kapitel mit der Verarbeitung von Nicht-HTTP-Anforderungen in IIS 7.0 beschäftigen. Die Diagnose- und Problembehandlungsmöglichkeiten von IIS 7.0 werden im sechzehnten Kapitel, »Ablaufverfolgung und Problembehandlung«, ausführlich erläutert.

Um die Auswirkungen dieser und anderer Architekturänderungen zu verstehen, müssen wir wissen, wie IIS 7.0 Anforderungen verarbeitet. Der Schwerpunkt dieses Kapitels ist deshalb die gesamte Anfor-derungsverarbeitungsarchitektur von IIS 7.0. Wir werden mit den IIS 7.0-Kernkomponenten beginnen und uns mit deren Rolle bei der Verarbeitung einer HTTP-Anforderung beschäftigen. Danach werfen wir einen Blick darauf, wie eine Anforderung ausgeführt wird, wobei wir uns auf die integrierte Anfor-derungsverarbeitungspipeline und die Modularität des Kernwebservers konzentrieren. Schließlich erörtern wir die Nicht-HTTP-Anforderungsverarbeitung in IIS 7.0.

Übersicht über die IIS 7.0-ArchitekturIIS 7.0 besteht aus mehreren Kernkomponenten, die zusammenarbeiten, um HTTP-Clientanforde-rungen zu verarbeiten. Bei der Anforderungsverarbeitung hat jede Komponente bestimmte Aufgaben, wie z.B. das Entgegennehmen von an den Server gerichteten Anforderungen, die Aktivierung und Verwaltung von Prozessen und das Ausführen von Anforderungen. Abbildung 2.1 zeigt die IIS 7.0-Architektur und -Kernkomponenten.

Die in Abbildung 2.1 dargestellten Kernkomponenten sind nachfolgend beschrieben:

� HTTP-Protokollstapel (HTTP.sys) HTTP.sys ist der im Kernelmodus arbeitende Protokoll-listener, der darauf achtet, ob HTTP- und HTTPS-Anforderungen eingehen.

� W3SVC (World Wide Web Service Publishing Service) W3SVC ist ein HTTP-Listener-Adapter. Er kommuniziert mit HTTP.sys und dem Windows-Prozessaktivierungsdienst und versorgt HTTP.sys mit Konfigurationsinformationen.

� Windows-Prozessaktivierungsdienst (WAS oder WPAS; Windows Process Activation Service) Der WAS-Dienst ermöglicht die Verwaltung von Arbeitsprozessen. Er startet und beendet Anwen-dungspools und sorgt für deren Wiederverwendung. Darüber hinaus überwacht er zur Laufzeit den Zustand von Arbeitsprozessen. Außerdem ruft er Konfigurationsinformationen aus dem Konfigura-tionsspeicher ab.

� Konfigurationsspeicher Der Konfigurationsspeicher ist eine aus verteilten XML-Dateien bestehende Hierarchie, die sowohl IIS- als auch ASP.NET-Einstellungen speichert. Serverweit gültige IIS-Konfigurationsinformationen sind in der globalen IIS-Konfigurationsdatei


Übersicht über die IIS 7.0-Architektur 31

applicationHost.config enthalten, die sich an oberster Stelle der Hierarchie befindet. Die globalen .NET Framework-Konfigurationsdateien, machine.config und die web.config-Stammdatei, befinden sich ebenfalls ganz oben in der Hierarchie.

� Arbeitsprozess (w3wp.exe) W3wp.exe ist ein dauerhaft ausgeführter Prozess, der Anforderungen verarbeitet und Antworten generiert. Die Anforderungen werden innerhalb eines Arbeitsprozesses ausgeführt. Mehrere Arbeitsprozesse können gleichzeitig laufen. Für die Ausführung von Arbeits-prozessen stehen zwei Modi zur Verfügung: der integrierte .NET-Modus, bei dem die integrierte IIS- und ASP.NET-Anforderungsverarbeitungspipeline verwendet wird, und der klassische Modus (der von IIS 6.0 verwendet wird), bei dem die IIS- und die ASP.NET-Anforderungsverarbeitung nicht miteinander verflochten sind. Diese Modi werden später in diesem Kapitel im Abschnitt »Anforderungsverarbeitung im Anwendungspool« erörtert.

Abbildung 2.1 IIS 7.0-Architektur

Die IIS 7.0-Kernkomponenten haben wichtige Funktionen bei der Verarbeitung von HTTP-Anfor-derungen. Bevor wir uns jedoch damit beschäftigen, welche Rolle die IIS 7.0-Kernkomponenten in der Anforderungsverarbeitung spielen, müssen wir wissen, wie der Server bestimmt, welcher Arbeits-prozess die jeweilige Anforderung ausführen soll.



Wenn beim Server eine von einem Client stammende HTTP-Anforderung eingeht, wird der Pfad im Anforderungs-URL geparst, um die Site und Anwendung zu ermitteln, auf die sich die Anforderung bezieht. Jede Anwendung wird innerhalb eines Anwendungspools ausgeführt. Für einen Anwendungs-pool können mehrere Arbeitsprozesse zuständig sein.

Wenn IIS 7.0 eine auf eine Anwendung bezogene Anforderung empfängt, ordnet IIS diese einem Arbeitsprozess zu, der für den Anwendungspool, in dem sich die Anwendung befindet, verantwortlich ist. Wenn es sich um die erste Anforderung für diesen Anwendungspool handelt, wird der Arbeits-prozess gestartet, und die Serverfunktionalität wird in den Prozess geladen. Danach wird die Anfor-derung an den Arbeitsprozess übergeben. Der Arbeitsprozess führt die Anforderung aus, und die resultierende HTTP-Antwort wird an den Client zurückgegeben.

Abbildung 2.2 zeigt die gesamte HTTP-Anforderungsverarbeitung und die Interaktion zwischen den IIS 7.0-Komponenten.

Abbildung 2.2 HTTP-Anforderungsverarbeitung unter IIS 7.0


IIS 7.0-Kernkomponenten 33

Bei IIS 7.0 setzt sich die HTTP-Anforderungsverarbeitung, wie in Abbildung 2.2 gezeigt, aus den folgenden Schritten zusammen:

1. Eine von einem Client stammende HTTP-Anforderung geht beim Server ein. HTTP.sys fängt die Anforderung ab.

2. HTTP.sys prüft, ob es über die Konfigurationsinformationen verfügt, die für die Anwendung gelten, an die die Anforderung gerichtet ist.

� Wenn HTTP.sys über diese Konfigurationsinformationen verfügt, leitet es die Anforderung an den entsprechenden Arbeitsprozess weiter (siehe Schritt 7).

� Ist HTTP.sys nicht im Besitz der Konfigurationsinformationen, kontaktiert es den Dienst W3SVC, der die Informationsanforderung an WAS weiterleitet.

3. WAS ruft die Konfigurationsinformationen von der globalen IIS-Konfigurationsdatei application-Host.config ab.

4. WAS prüft innerhalb des Anwendungspools, an den sich die Anforderung richtet, ob der Arbeits-prozess vorhanden ist. Ist der Arbeitsprozess nicht vorhanden, startet WAS diesen für den Anwen-dungspool.

5. WAS übergibt die Konfiguration, die in Form von Anwendungspool- und Anwendungskonfigura-tionseinstellungen vorliegt, an W3SVC.

6. W3SVC verwendet die von WAS empfangene Konfiguration, um HTTP.sys zu konfigurieren und zu aktualisieren.

7. HTTP.sys leitet die Anforderung an den Arbeitsprozess weiter.

8. Der Arbeitsprozess initiiert eine Anforderungsverarbeitungspipeline für die Ausführung der Anforderung. Eine Anforderungsverarbeitungspipeline ist eine feste Folge von Komponenten, die bestimmte Aufgaben bei der Verarbeitung einer Anforderung haben. Am Ende dieser Verarbeitung wird eine Antwort generiert und an HTTP.sys zurückgegeben. Wir werden die Anforderungsver-arbeitungspipeline später in diesem Kapitel im Abschnitt »Anforderungsverarbeitung im Anwen-dungspool« erörtern.

9. HTTP.sys sendet eine Antwort zum Client.

IIS 7.0-KernkomponentenIn diesem Abschnitt untersuchen wir die IIS 7.0-Kernkomponenten und deren Aufgaben bei der Prozessaktivierung und Anforderungsverarbeitung.

HTTP.sysHTTP.sys ist der Protokolllistener, der darauf achtet, ob HTTP- und HTTPS-Anforderungen eingehen. HTTP.sys wurde mit IIS 6.0 eingeführt und diente dort als spezifischer Protokolllistener für HTTP-Anforderungen. Bei IIS 7.0 unterstützt HTTP.sys ebenfalls SSL (Secure Sockets Layer). Bei IIS 6.0 war Lsass.exe dafür zuständig.

HTTP.sys ist ein im Kernelmodus arbeitender Gerätetreiber für den HTTP-Protokollstapel. Er ist Bestandteil des Netzwerksubsystems von Windows-Betriebssystemen. Seit IIS 6.0 ersetzt dieser Kernelmodustreiber die Windows Sockets-API (Winsock). Dabei handelte es sich um eine im Benutzer-modus arbeitende Komponente, die von älteren IIS-Versionen verwendet wurde, um HTTP-Anforde-rungen zu empfangen und HTTP-Antworten zu versenden.



Wenn ein Clientbrowser eine Webseite von einer Site anfordert, die sich auf einem IIS 7.0-Server befindet, fängt HTTP.sys die Anforderung über die entsprechende Sitebindung des Servercomputers ab und übergibt sie dem Arbeitsprozess zur Verarbeitung. Nachdem die Anforderung verarbeitet wurde, gibt HTTP.sys eine Antwort an den Clientbrowser zurück.

Abgesehen vom Abfangen und Zurückgeben von HTTP-Anforderungen ist HTTP.sys auch für die folgenden Aufgaben verantwortlich:

� Vorverarbeitung und Sicherheitsfilterung der eingehenden HTTP-Anforderungen

� Einreihen der HTTP-Anforderungen in Warteschlangen (für die Anwendungspools)

� Zwischenspeichern der ausgehenden HTTP-Antworten

Abbildung 2.3 zeigt die Anforderungswarteschlangen und den Antwortcache von HTTP.sys.

Abbildung 2.3 HTTP-Anforderungswarteschlange und -Antwortcache

Eine Anforderungswarteschlange und ein Antwortcache, die von einem kernelbasierten HTTP-Listener verwaltet werden, verringern den Overhead, der mit einem Kontextwechsel zum Benutzermodus einhergeht, und führen wie folgt zu Leistungsverbesserungen:

� Anforderungs-Queuing im Kernelmodus Anforderungen führen zu einem geringeren Overhead beim Kontextwechsel, da der Kernel Anforderungen direkt an den richtigen Arbeitsprozess weiterleitet. Wenn kein Arbeitsprozess verfügbar ist, um eine Anforderung entgegenzunehmen, verwahrt die Kernelmodus-Anforderungswarteschlange die Anforderung, bis ein Arbeitsprozess diese aufnimmt.

� Caching im Kernelmodus Anforderungen, die sich auf zwischengespeicherte Antworten beziehen, werden ohne Wechsel zum Benutzermodus bedient.

HTTP.sys verwaltet eine Anforderungswarteschlange pro Arbeitsprozess. Es sendet die empfangenen HTTP-Anforderungen zu der Warteschlange des Arbeitsprozesses, der für den Anwendungspool zuständig ist, in dem sich die jeweils angeforderte Anwendung befindet. HTTP.sys legt für jede Anwendung einen Eintrag in der Routingtabelle des URI-Namespace an. Mit den Daten der Routing-tabelle wird ermittelt, welcher Anwendungspool auf Anforderungen aus welchen Teilen des Name-space antwortet. Jede Anforderungswarteschlange ist einem Anwendungspool zugeordnet. Innerhalb von HTTP.sys ist jeder Anwendungspool einer Anforderungswarteschlange sowie einem oder mehreren Arbeitsprozessen zugeordnet.

Wenn eine fehlerhafte Anwendung einen Arbeitsprozessfehler verursacht, erfolgt keine Unterbrechung der Verarbeitung. Der Fehler ist für den Endnutzer auch nicht erkennbar, da der Kernel die Anforde-rungen in Warteschlangen einreiht, während der WAS-Dienst einen neuen Arbeitsprozess für diesen Anwendungspool startet. Wenn der WAS-Dienst einen fehlerhaften Arbeitsprozess entdeckt, startet er einen neuen Arbeitsprozess, sofern ausstehende Anforderungen darauf warten, bedient zu werden. Obwohl die im Benutzermodus stattfindende Anforderungsverarbeitung temporär unterbrochen wird,



bemerkt der Benutzer den Fehler nicht, da die TCP/IP-Verbindungen aufrecht erhalten und Anforde-rungen auch weiterhin in den Warteschlangen abgelegt und verarbeitet werden. Nur die Anforderungen, die in einem Arbeitsprozess ausgeführt werden, wenn bei diesem ein Fehler auftritt, führen dazu, dass die entsprechenden Benutzer eine Fehlermeldung erhalten. Die Anforderungen, die bis zu diesem Zeitpunkt noch nicht verarbeitet wurden, werden an den neuen Arbeitsprozess weitergeleitet.

HTTP.sys verarbeitet empfangene Anforderungen ausschließlich, indem es eine gespeicherte Antwort aus seinem internen Zwischenspeicher abruft. Deshalb wird anwendungsspezifischer Code niemals im Kernelmodus geladen, sondern innerhalb eines Arbeitsprozesses verarbeitet, der im Benutzermodus ausgeführt wird. Dadurch ist es unmöglich, dass Fehler im Anwendungscode den Kernel beeinflussen oder zu Systemausfällen führen.

WWW-PublishingdienstVerglichen mit IIS 6.0 hat sich der WWW-Publishingdienst (World Wide Web Publishing Service, W3SVC) von IIS 7.0 wesentlich verändert.

Bei IIS 6.0 war der W3SVC-Dienst für die Verwaltung von HTTP.sys, die Konfiguration und die Verarbeitung sowie für die Leistungsüberwachung verantwortlich, wie Abbildung 2.4 zeigt.

Abbildung 2.4 W3SVC in IIS 6.0

Bei IIS 7.0 teilen sich zwei Dienste diese Funktionalität: W3SVC und ein Dienst, der in IIS 7.0 neu ist und den Namen WAS trägt. Diese beiden Dienste werden im selben Svchost.exe-Prozess unter der LocalSystem-Identität ausgeführt und nutzen dieselben Binärdateien. Die IIS 7.0-Dienste W3SVC und WAS sind in Abbildung 2.5 dargestellt.

Abbildung 2.5 W3SVC und WAS bei IIS 7.0



Bei IIS 7.0 agiert W3SVC als Listeneradapter für den HTTP-Listener HTTP.sys. Listeneradapter sind Komponenten, die die Kommunikation zwischen WAS und Protokolllistenern einrichten. WAS enthält eine Listeneradapterschnittstelle, die eine Kommunikation mit Listeneradaptern ermöglicht.

W3SVC ist dafür verantwortlich, HTTP.sys zu konfigurieren sowie im Falle einer Konfigurations-änderung zu aktualisieren und WAS zu benachrichtigen, wenn eine Anforderung in die Warteschlange eingestellt wird. Darüber hinaus erfasst W3SVC auch weiterhin die Websiteindikatoren. Es liest jedoch nicht mehr Konfigurationsinformationen aus dem Konfigurationsspeicher und es verwaltet auch nicht mehr Anwendungspools und Arbeitsprozesse. Stattdessen ist nun WAS für das Lesen der Konfiguration und die Prozessaktivierung und -verwaltung verantwortlich.

Die folgende Liste fasst zusammen, welche Unterschiede es zwischen den W3SVC-Diensten von IIS 7.0 und IIS 6.0 hinsichtlich der Funktionalität gibt:

� Konfigurationsverwaltung

� In IIS 6.0 liest W3SVC die Konfigurationsinformationen aus dem IIS 6.0-Konfigurations-speicher, der Metabasis.

� Bei IIS 7.0 liest W3SVC die Konfigurationsinformationen nicht mehr aus dem Konfigurations-speicher. Stattdessen liest WAS die Konfigurationsinformationen aus dem IIS 7.0-Konfigura-tionsspeicher, applicationHost.config, und übergibt sie W3SVC.

� Verwaltung von HTTP.sys

� Bei IIS 6.0 konfiguriert und aktualisiert W3SVC den Listener HTTP.sys. Der Dienst verwendet dazu die aus der Metabasis eingelesenen Konfigurationsinformationen.

� Bei IIS 7.0 konfiguriert und aktualisiert W3SVC den Listener HTTP.sys unter Verwendung der von WAS entgegengenommenen Konfigurationsinformationen. Als Listeneradapter für das HTTP-Protokoll kontrolliert W3SVC die Kommunikation zwischen WAS und HTTP.sys.

� Prozessverwaltung

� Bei IIS 6.0 verwaltet W3SVC die Anwendungspools und Arbeitsprozesse, und der Dienst ist auch für das Starten, Beenden und die Wiederverwendung von Arbeitsprozessen zuständig. Darüber hinaus überwacht W3SVC den Zustand der Arbeitsprozesse und initiiert den Schutz vor schnellen Fehlerfolgen, um den Start neuer Prozesse zu verhindern, falls mehrere Arbeits-prozesse innerhalb einer bestimmten Zeit fehlschlagen.

� Bei IIS 7.0 ist W3SVC nicht mehr für die Verwaltung von Arbeitsprozessen verantwortlich. WAS ist nun hierfür zuständig.

� Leistungsüberwachung

� Bei IIS 6.0 überwacht W3SVC die Leistung und stellt Leistungsindikatoren für Websites und den IIS-Cache zur Verfügung.

� Auch bei IIS 7.0 erfasst W3SVC weiterhin die Websiteindikatoren.

Hinweis Da Leistungsindikatoren ein Bestandteil von W3SVC bleiben, sind sie HTTP-spezifisch und gelten somit nicht für WAS.



Windows-ProzessaktivierungsdienstDas HTTP-Prozessaktivierungsmodell wurde von IIS 6.0 zusammen mit den Anwendungspools eingeführt. Für IIS 7.0 wurde dieser Dienst erweitert und wird nun Windows-Prozessaktivierungsdienst (Windows Process Activation Service, WAS) genannt. Er kann Anforderungen und Nachrichten über jedes beliebige Protokoll empfangen und unterstützt die Aktivierung von während des Betriebs frei wählbaren Protokolllistenern.

Bei IIS 7.0 verwaltet WAS die Anwendungspoolkonfiguration und Arbeitsprozesse. In IIS 6.0 ist W3SVC hierfür zuständig. Wie in Abbildung 2.5 dargestellt, besteht WAS aus den folgenden Komponenten:

� Ein Konfigurationsmanager, der die Anwendungs- und Anwendungspoolkonfiguration aus dem Konfigurationsspeicher liest

� Ein Prozessmanager, der bereits vorhandenen Arbeitsprozessen Anwendungspools zuordnet und dafür verantwortlich ist, neue Instanzen von W3wp.exe zu starten, um neue Anwendungspools als Reaktion auf Aktivierungsanforderungen zu hosten

� Eine Listeneradapterschnittstelle, die definiert, wie externe Listener die von ihnen empfangenen Aktivierungsanforderungen dem WAS-Dienst mitteilen. Der W3SVC-Dienst kontrolliert beispiels-weise die Kommunikation mit HTTP.sys und teilt dem WAS-Dienst über die Listeneradapter-schnittstelle die HTTP-Aktivierungsanforderungen mit.

Beim Start liest der WAS-Konfigurationsmanager Informationen aus dem Konfigurationsspeicher und übergibt sie dem HTTP-Listeneradpater, W3SVC, der für die Kommunikation mit dem HTTP-Listener HTTP.sys verantwortlich ist. Nachdem W3SVC die Konfigurationsinformationen empfangen hat, konfiguriert der Dienst den Listener HTTP.sys und bereitet ihn darauf vor, den Anforderungseingang zu überwachen.

Der WAS-Konfigurationsmanager ruft die folgenden Informationen aus dem Konfigurationsspeicher ab:

� Globale Konfigurationsinformationen

� Protokollkonfigurationsinformationen

� Die Anwendungspoolkonfiguration, z.B. Informationen zum Verarbeitungskonto

� Die Sitekonfiguration, z.B. Bindungen und Anwendungen

� Die Anwendungskonfiguration, z.B. die aktivierten Protokolle und die Anwendungspools, denen die Anwendung zugeordnet ist

Wenn sich die Konfiguration ändert, erhält der WAS-Konfigurationsmanager eine entsprechende Benachrichtigung, woraufhin er W3SVC unter Verwendung der neuen Informationen aktualisiert. Nachdem W3SVC mit der neuen Konfiguration ausgestattet wurde, aktualisiert und konfiguriert der Dienst den Listener HTTP.sys. Wenn Sie beispielsweise einen Anwendungspool hinzufügen, verarbeitet der Konfigurationsmanager die Konfigurationsänderungen und teilt diese dem Dienst W3SVC mit, der dann HTTP.sys aktualisiert, um die Anwendungspoolwarteschlange hinzuzufügen oder zu löschen.

Der WAS-Prozessmanager ist für die Verwaltung von Arbeitsprozessen verantwortlich. Zu den Ver-waltungsaufgaben zählen beispielsweise das Starten von Arbeitsprozessen und die Verwaltung von Informationen über die ausgeführten Arbeitsprozesse. Er ermittelt außerdem, wann ein Arbeitsprozess gestartet und wiederverwendet werden kann und wann ein Arbeitsprozess neu gestartet werden sollte, weil er nicht mehr reagiert und keine weiteren Anforderungen verarbeiten kann.



Wenn HTTP.sys eine Clientanforderung abfängt, stellt der WAS-Prozessmanager fest, ob bereits ein Arbeitsprozess ausgeführt wird. Wenn ein Anwendungspool bereits über einen Arbeitsprozess, der Anforderungen bedient, verfügt, übergibt HTTP.sys die Anforderung zur Verarbeitung an den Arbeits-prozess. Wenn dem Anwendungspool kein Arbeitsprozess zugeordnet ist, startet der Prozessmanager einen neuen Arbeitsprozess, so dass HTTP.sys die Anforderung zur Verarbeitung an diesen Prozess übergeben kann.

WAS unterstützt zusätzlich zu HTTP auch andere Protokolle. Das für HTTP verwendete Konfigura-tions- und Prozessmodell steht auch Nicht-HTTP-Anwendungen und -Diensten zur Verfügung. Wir werden später in diesem Kapitel im Abschnitt »Verarbeitung von Nicht-HTTP-Anforderungen« einen Blick auf diese Möglichkeit werfen.

KonfigurationsspeicherBei IIS 6.0 werden die Konfigurationsdaten in der XML-basierten Metabasis gespeichert. IIS 7.0 nutzt diese Metabasis nicht mehr. Stattdessen werden die Konfigurationseinstellungen in einem verteilten, aus XML-Dateien bestehenden Konfigurationssystem gespeichert, das IIS- und ASP.NET-Einstellungen kombiniert.

Die verteilte Konfigurationshierarchie enthält die globalen, computerweit gültigen .NET Framework-Konfigurationsdateien, machine.config und die web.config-Stammdatei, die globale IIS-Konfigura-tionsdatei applicationHost.config und die verteilten web.config-Konfigurationsdateien, die sich wie in Abbildung 2.6 dargestellt in den Websites, Anwendungen und Verzeichnissen befinden.

Abbildung 2.6 Der verteilte Konfigurationsspeicher von IIS 7.0



Da Konfigurationsdateien zusammen mit Website- und Anwendungsinhalten gespeichert werden, erlaubt dieses Konfigurationssystem die gemeinsame xcopy-Bereitstellung von Konfigurationen, Anwendungscode und Inhalten. Serveradministratoren können deshalb die Site- und Anwendungs-verwaltung an Benutzer delegieren, die auf dem Servercomputer über keine administrativen Rechte verfügen. Auch die gemeinsame Nutzung von Konfigurationen innerhalb einer Webfarm wird auf diese Weise vereinfacht.

IIS speichert die serverweit gültige Konfiguration in der applicationHost.config-Datei, die sich im Ordner %SystemRoot%\System32\Inetsrv\Config befindet. Der WAS-Dienst ruft aus dieser Datei Konfigurationsinformationen zu Anwendungspools und Anwendungen ab.

IIS 7.0 bietet mehrere Verwaltungstools und APIs (Application Programming Interface) an, die inner-halb des Konfigurationssystems von IIS 7.0 Konfigurationen lesen und schreiben. Die Konfigurations-dateien sind XML-Dateien, deren Inhalt im Klartext vorliegt, so dass Sie den Windows-Editor benutzen könnten, um mit einer IIS 7.0-Konfiguration zu arbeiten, sofern Sie dies wünschen. Doch selbst bei einfachen web.config-Dateien würde eine solche Vorgehensweise schnell zu Fehlern führen, weshalb sie möglichst vermieden werden sollte.

Um die Verwaltung zu vereinfachen, bietet IIS 7.0 einen überarbeiteten, aufgabenbasierten und feature-orientierten IIS-Manager mit einer grafischen Benutzeroberfläche sowie ein Befehlszeilentool namens Appcmd.exe für die Webserverwaltung an. Für den programmgesteuerten Zugriff gibt es eine COM-API, mit der die Konfiguration von einem C++-Programm aus verwaltet werden kann, und eine .NET-API (Microsoft.Web.Administration) für .NET-Programme. Die meisten Features des IIS-Managers wurden unter Verwendung dieser neuen .NET-API implementiert. Ein IIS 7.0-WMI-Anbieter (Windows Management Instrumentation) für das Scripting wird ebenfalls angeboten, und zwar zu-sammen mit dem alten IIS 6.0-WMI-Anbieter, der aus Gründen der Abwärtskompatibilität zu bereits vorhandenen Skripts zur Verfügung gestellt wird.

Die Microsoft.Web.Administration-API, Appcmd.exe und der WMI-Anbieter setzen auf die COM-API auf. Dieser neue Verwaltungsstack ist in Abbildung 2.7 dargestellt.

Abbildung 2.7 Der IIS 7.0-Verwaltungsstack

Hinweis Weitere Informationen zum IIS 7.0-Konfigurationssystem und zur globalen applicationHost.config-Datei finden Sie im vierten Kapitel, »Verstehen des Konfigurationssystems«.



Der alte Konfigurationsspeicher, die Metabasis, ist nicht mehr Bestandteil von IIS 7.0. IIS 7.0 bietet jedoch aus Gründen der Abwärtskompatibilität ein optionales Feature für die Kompatibilität mit der Metabasis an, das den Dienst IISADMIN installiert (IIS Administration Service, IIS-Verwaltungs-dienst), der bei IIS 6.0 die Metabasis schreibt und liest. Das Feature für die Kompatibilität mit der Metabasis installiert außerdem den Prozess Inetinfo.exe, der den Dienst IISADMIN hostet. Diese beiden Komponenten bilden die Translationsschicht, die als ABO-Mapper bezeichnet wird (Admin Base Objects). Der ABO-Mapper verwendet die alten ABO-APIs für die Arbeit mit der Metabasis, wobei die Konfigurationseinstellungen jedoch direkt in den IIS 7.0-Konfigurationsdateien gespeichert werden. Wenn Sie das Feature für die Kompatibilität mit der Metabasis nicht installieren, setzt IIS 7.0 den Dienst IISADMIN oder den Prozess Inetinfo.exe nicht ein.

ArbeitsprozesseDie Aufgabe eines Arbeitsprozesses besteht darin, Anforderungen zu verarbeiten. Ein Arbeitsprozess ist ein in sich geschlossener, dauerhaft ausgeführter Benutzermodusprozess, der in Form einer aus-führbaren Datei namens w3wp.exe vorliegt.

Jeder Arbeitsprozess stellt die grundlegende Webserverfunktionalität zur Verfügung. Das Ergebnis der Anforderungsverarbeitung innerhalb des Arbeitsprozesses besteht darin, dass eine Antwort generiert und an den Client zurückgegeben wird. Jeder Arbeitsprozess benutzt HTTP.sys, um Anforderungen zu empfangen und Antworten zu versenden.

Ein Arbeitsprozess bedient einen Anwendungspool. Ein Anwendungspool gruppiert eine oder mehrere Anwendungen. Aus diesem Grund können Sie bestimmte Konfigurationseinstellungen auf Anwendungs-gruppen und auf die Arbeitsprozesse anwenden, die diese Anwendungen bedienen.

Jede Anwendung wird innerhalb eines Anwendungspools ausgeführt. Für einen Anwendungspool können mehrere Arbeitsprozesse zuständig sein. Ein Arbeitsprozess kann aber immer nur einen Anwendungspool bedienen. Mehrere Arbeitsprozesse, die für verschiedene Anwendungspools zuständig sind, können wie in Abbildung 2.8 dargestellt gleichzeitig ausgeführt werden.

Abbildung 2.8 Prozess- und Anwendungsisolation

Die Arbeitsprozessgrenzen trennen die Anwendungspools voneinander, so dass jeder Anwendungscode innerhalb einer isolierten Umgebung arbeiten kann. Einzelne Anwendungen können dann in einem in sich geschlossenen Arbeitsprozess ausgeführt werden. Das Arbeitsprozessisolationsmodell wurde erstmals mit IIS 6.0 eingeführt. Dieses Modell verhindert, dass Anwendungen, die innerhalb eines Anwendungspools ausgeführt werden, auf Anwendungen in anderen Anwendungspools des Servers einwirken. Auf diese Weise wird eine Abschirmung von Anwendungen erreicht.



Innerhalb eines Arbeitsprozesses stellen Anwendungsdomänen Anwendungsgrenzen für .NET-Anwendungen dar. Jede .NET-Anwendung wird in einer eigenen Anwendungsdomäne (AppDomain) ausgeführt, wie Abbildung 2.8 zeigt. Eine Anwendungsdomäne lädt den Code der Anwendung bei deren Start. Für die virtuellen Verzeichnisse innerhalb einer Anwendung ist dieselbe AppDomain zuständig, der auch die Anwendung zugeordnet ist.

Für die Ausführung von Anforderungen innerhalb eines Arbeitsprozesses stehen zwei Modi zur Verfügung: der integrierte .NET-Modus, in dem IIS- und ASP.NET-Anforderungen dieselbe integrierte Anforderungsverarbeitungspipeline verwenden, und der klassische Modus, in dem zwei separate Pipelines für die IIS- und die ASP.NET-Verarbeitung genutzt werden. Sie können einen Anwendungs-pool konfigurieren, um festzulegen, in welchem der beiden Modi ASP.NET-Anforderungen ausgeführt werden sollen. Im nächsten Abschnitt konzentrieren wir uns auf die Anforderungsverarbeitungs-architektur innerhalb der Arbeitsprozesse, die die Anwendungspools bedienen.

Direkt von der Quelle: Anwendungspoolisolierung bei IIS 7.0Das mit IIS 6.0 eingeführte Anwendungspooldesign bildete die Grundlage für eine höhere Sicher-heit, die dadurch erzielt wurde, dass mehrere Anwendungen voneinander isoliert wurden. Es war aber auch die Basis für die Verbesserung der Fehlertoleranz des Webservers. Auch IIS 7.0 nutzt dieses Konzept und unterstützt nicht mehr das alte IIS 5.0-Isolationsmodell. Die meisten Features, die schon bei IIS 6.0 für den Erfolg von Anwendungspools verantwortlich waren, wurden beibe-halten, darunter die Möglichkeit, jeden Anwendungspool mit verschiedenen Anmeldeinformationen auszuführen und intelligente Zustandsüberwachungs- und Wiederverwendungseinstellungen zur Aufrechterhaltung der Anwendungszuverlässigkeit zu konfigurieren.

IIS 7.0 geht jedoch noch einen Schritt weiter, indem es eine automatisierte Anwendungspool-isolation über automatisch generierte SIDs (Security Identifiers, Sicherheits-IDs) bietet. Außerdem isoliert es automatisch die Konfiguration auf der Serverebene, so dass diese nur von dem Anwen-dungspool gelesen werden kann, auf den sich die Konfiguration auswirkt. Dies führt dazu, dass die Konfiguration vollständig isolierter Webanwendungen durch den Einsatz von Anwendungspools einfacher als jemals zuvor ist.

Darüber hinaus bietet IIS 7.0 unter Windows Server 2008 eine Vielzahl von Leistungsverbesse-rungen, die eine größere Anzahl von auf einem einzelnen Webserver konfigurierten und aktiven Anwendungspools ermöglichen. Erreicht wird dies über Arbeitsprozesse, die weniger Ressourcen verbrauchen, und eine intelligentere Arbeitsprozessverwaltung. Diese Verbesserungen führen dazu, dass Webhostinganbieter jede einzelne Anwendung einfach in einem separaten Anwendungspool ablegen können, um für die betroffenen Anwendungen die maximale Sicherheits- und Fehlerisola-tion zu erzielen.

Achten Sie darauf, die von der Anwendungspoolisolation gebotenen Möglichkeiten voll auszuschöpfen, wenn Sie die Infrastruktur Ihrer Webanwendungen planen.

Mike Volodarsky

IIS-Kernserver Program Manager



Anforderungsverarbeitung im AnwendungspoolBei IIS 7.0 sind zwei Modi für einen Anwendungspool verfügbar: der integrierte Modus und der klassische Modus. Wenn Sie einen Anwendungspool für den integrierten Modus konfigurieren, ver-arbeitete IIS 7.0 die ASP.NET-Anforderungen unter Verwendung der integrierten IIS- und ASP.NET-Anforderungsverarbeitungspipeline. Wenn Sie einen Anwendungspool für den klassischen Modus konfigurieren, verarbeitete IIS 7.0 die ASP.NET-Anforderungen unter Verwendung separater IIS- und ASP.NET-Anforderungsverarbeitungspipelines, wie dies bei IIS 6.0 der Fall ist.

Auf demselben Servercomputer können mehrere Anwendungspools ausgeführt werden, die für ver-schiedene Modi konfiguriert wurden. Sie können den Modus für einen Anwendungspool festlegen, indem Sie im IIS-Manager die Einstellung Verwalteter Pipelinemodus konfigurieren.

Um mit dem IIS-Manager den ASP.NET-Verarbeitungsmodus für einen Anwendungspool zu konfigu-rieren, gehen Sie wie folgt vor:

1. Erweitern Sie im IIS-Manager den Serverknoten und markieren Sie im Bereich Verbindungen den Knoten Anwendungspools.

2. Markieren Sie auf der Seite Anwendungspools den Anwendungspool, den Sie konfigurieren möchten.

3. Klicken Sie im Bereich Aktionen unter Anwendungspool bearbeiten auf Grundeinstellungen.


Anforderungsverarbeitung im Anwendungspool 43

4. Wählen Sie im Dialogfeld Anwendungspool bearbeiten und dort im Dropdown-Listenfeld Verwal-teter Pipelinemodus den gewünschten Modus (Integriert oder Klassisch) und klicken Sie auf OK.

Klassischer ModusDer klassische Modus dient bei IIS 7.0 der Abwärtskompatibilität mit IIS 6.0. Wenn Sie einen Anwen-dungspool für den klassischen Modus konfigurieren, verarbeitete IIS 7.0 die ASP.NET-Anforderungen unter Verwendung von zwei separaten IIS- und ASP.NET-Anforderungsverarbeitungspipelines, wie dies bei IIS 6.0 der Fall ist. Um den klassischen Modus von IIS 7.0 zu verstehen, werfen wir zunächst einen Blick darauf, wie ASP.NET-Anforderungen in IIS 6.0 verarbeitet werden.

Abbildung 2.9 zeigt die ASP.NET-Anforderungsverarbeitung bei IIS 6.0. Bei allen IIS-Versionen bis zur Versionsnummer 6.0 stellt ASP.NET als eigenständiges Anwendungsframework eine Verbindung zum Webserver her. Bei diesen IIS-Versionen ist ASP.NET in Form einer ISAPI-Erweiterung (Internet Server Application Programming Interface) implementiert.

Abbildung 2.9 ASP.NET-Anforderungsverarbeitung unter IIS 6.0



Bei IIS 6.0 ist die ASP.NET-ISAPI-Erweiterung (aspnet_isapi.dll) für die Verarbeitung der Inhaltstypen verantwortlich, die für diese Erweiterung registriert sind, z.B. ASPX und ASMX. Für diese Anforde-rungen bietet es leistungsfähige Features an, wie z.B. die Formularauthentifizierung und die Ausgabe-zwischenspeicherung von Antworten. Doch nur Inhaltstypen, die für ASP.NET registriert sind, können diese Dienste nutzen. Andere Inhaltstypen – einschließlich ASP-Seiten, statische Dateien, Bilder und CGI-Anwendungen (Common Gateway Interface) – können nicht auf diese Features zugreifen.

Eine Anforderung, die sich auf einen ASP.NET-Inhaltstypen bezieht, wird zunächst von IIS verarbeitet und dann an aspnet_isapi.dll weitergeleitet. Aspnet_isapi.dll hostet die ASP.NET-Anwendung und das Anforderungsverarbeitungsmodell. Dadurch ergeben sich gewissermaßen zwei separate Serverpipe-lines, eine für native ISAPI-Filter- und -Erweiterungskomponenten und eine weitere für verwaltete Anwendungskomponenten. ASP.NET-Komponenten werden vollständig innerhalb der ASP.NET-ISAPI-Erweiterung und ausschließlich für solche Anforderungen ausgeführt, die in der IIS-Skript-zuordnungskonfiguration ASP.NET zugeordnet sind. Anforderungen, die sich auf Nicht-ASP.NET-Inhalte beziehen, wie z.B. ASP-Seiten oder statische Dateien, werden von IIS oder anderen ISAPI-Erweiterungen verarbeitet und sind für ASP.NET nicht sichtbar.

Darüber hinaus sind bestimmte Funktionen für ASP.NET selbst dann nicht verfügbar, wenn sie sich auf ASP.NET-Ressourcen beziehen. Grund hierfür sind Laufzeitbeschränkungen. Es ist beispielsweise nicht möglich, den Satz ausgehender HTTP-Anforderungsheader vor der Übermittlung zum Client zu modifizieren, da dies hinter dem ASP.NET-Ausführungspfad geschehen müsste.

Abbildung 2.10 ASP.NET-Anforderungsverarbeitung im klassischen Modus unter IIS 7.0



Beim klassischen Modus von IIS 7.0 werden ASP.NET-Anforderungen ebenfalls mithilfe der ASP.NET-ISAPI-Erweiterung verarbeitet, wie Abbildung 2.10 zeigt. Der Kernwebserver besteht bei IIS 7.0 vollständig aus einzelnen Komponenten, wohingegen er bei IIS 6.0 monolithisch ist. Die ASP.NET-Anforderungen werden im klassischen Modus jedoch genauso von asnet_isapi.dll verarbeitet, wie dies bei IIS 6.0 der Fall ist. Nachdem die Anforderung von asnet_isapi.dll verarbeitet wurde, wird sie durch IIS hindurch zurückgeleitet, um die Antwort zu senden.

Der klassische Modus von IIS 7.0 weist dieselben grundlegenden Einschränkungen auf wie die ASP.NET-Verarbeitung unter IIS 6.0. Diese Einschränkungen sind nachfolgend aufgeführt:

� Die von ASP.NET-Modulen bereitgestellten Dienste sind für Nicht-ASP.NET-Anforderungen nicht verfügbar.

� Einige Verarbeitungsschritte werden doppelt ausgeführt, z.B. die Authentifizierung.

� Einige Einstellungen müssen an zwei Orten verwaltet werden, z.B. die Autorisierung, die Ablauf-verfolgung und die Ausgabezwischenspeicherung.

� ASP.NET-Anwendungen haben keinen Einfluss auf bestimmte Abschnitte der IIS-Anforderungs-verarbeitung, die vor und hinter dem ASP.NET-Ausführungspfad liegen. Grund hierfür ist die Position der ASP.NET-ISAPI-Erweiterung innerhalb der Serverpipeline.

Der klassische Modus wird nur aus Gründen der Abwärtskompatibilität mit IIS 6.0 angeboten. Kurz gesagt sollten Sie eine Anwendung nur dann einem im klassischen Modus arbeitenden Anwendungs-pool hinzufügen, wenn sie im integrierten Modus nicht funktioniert.

Hinweis Weitere Informationen zur Anwendungskompatibilität unter IIS 7.0 finden Sie im elften Kapitel, »Hosting von Anwendungsentwicklungsframeworks«.

Der integrierte .NET-ModusWenn ein Anwendungspool für den integrierten .NET-Modus konfiguriert ist, können Sie die Vorzüge der integrierten Anforderungsverarbeitungsarchitektur von IIS 7.0 und ASP.NET nutzen.

Bei IIS 7.0 ist die ASP.NET-Laufzeit im Kernwebserver integriert. Die IIS- und ASP.NET-Anforderungs-pipelines sind kombiniert, wodurch eine vereinheitlichte (also integrierte) Anforderungsverarbeitungs-pipeline zur Verfügung gestellt wird, auf die sowohl systemeigene als auch verwaltete Module zugreifen können.

Die IIS 7.0-Anforderungsverarbeitungspipeline wird von der Engine des Kernwebservers imple-mentiert. Durch sie ist es möglich, dass mehrere voneinander unabhängige Module Dienste für dieselbe Anforderung bereitstellen können. Alle Webserverfeatures werden als eigenständige Module imple-mentiert. Es gibt über vierzig separate systemeigene und verwaltete Module. Jedes Modul imple-mentiert ein bestimmtes Webserverfeature oder eine bestimmte Webserverfunktionalität wie z.B. die Protokollierung oder Ausgabezwischenspeicherung.

Hinweis Eine vollständige Liste der integrierten systemeigenen und verwalteten IIS 7.0-Module finden Sie in Anhang C, »Liste der IIS 7.0-Module«.

Systemeigene Module werden als DLLs (Dynamic Link Library) implementiert, die auf öffentlichen und in C++ geschriebenen IIS 7.0-Erweiterbarkeits-APIs basieren. Verwaltete Module werden in IIS 7.0 als verwaltete Frameworkklassen implementiert, die auf dem ASP.NET-Integrationsmodell



basieren. (IIS 7.0 hat die bereits vorhandenen HttpModule-API für ASP.NET integriert.) Beide dieser APIs ermöglichen es den Modulen, an der IIS 7.0-Anforderungsverarbeitungspipeline teilzuhaben und auf alle Ereignisse aller Anforderungen zuzugreifen.

Eine integrierte IIS 7.0-Anforderungsverarbeitungspipeline ist in Abbildung 2.11 dargestellt. Eine Pipeline ist eine geordnete Folge von systemeigenen und verwalteten Modulen, die als Reaktion auf Anforderungen bestimmte Aufgaben ausführen. Wenn ein Arbeitsprozess in einem Anwendungspool eine Anforderung von HTTP.sys empfängt, durchläuft die Anforderung mehrere Phasen in einer bestimmten Reihenfolge. Das Ergebnis der Verarbeitung besteht darin, dass eine Antwort generiert und an HTTP.sys zurückgesendet wird.

Jede Phase der Pipeline löst ein Ereignis aus. Systemeigene und verwaltete Module abonnieren die Ereignisse der Pipelinephasen, die für sie relevant sind. Wenn das Ereignis ausgelöst wird, werden die systemeigenen und verwalteten Module, die das jeweilige Ereignis abonniert haben, benachrichtigt und erledigen ihren Teil der Arbeit, um die Anforderung zu verarbeiten. Das Pipelineereignismodell ermöglicht die Ausführung mehrerer Module während der Anforderungsverarbeitung.

Abbildung 2.11 Die integrierte Verarbeitungspipeline von IIS 7.0



Die meisten Pipelineereignisse sind für bestimmte Aufgabentypen vorgesehen, wie z.B. für die Authentifizierung, Autorisierung, Zwischenspeicherung und Protokollierung. Die folgende Liste beschreibt die Phasen und zugehörigen Ereignisse der Anforderungsverarbeitungspipeline:

� Anforderungsbeginn In dieser Phase beginnt die Anforderungsverarbeitung. Das Ereignis BeginRequest wird ausgelöst.

� Anforderungsauthentifizierung In dieser Phase wird der anfordernde Benutzer authentifiziert. Das Ereignis AuthenticateRequest wird ausgelöst.

� Anforderungsautorisierung In dieser Phase wird das Ereignis AuthorizeRequest ausgelöst. Zu diesem Zeitpunkt wird geprüft, ob der authentifizierte Benutzer auf die angeforderte Ressource zugreifen darf. Wenn der Zugriff verweigert wird, erfolgt die Zurückweisung der Anforderung.

� Auflösen des Caches In dieser Phase wird das Ereignis ResolveRequestCache ausgelöst. Es wird geprüft, ob die Antwort auf die Anforderung aus dem Cache abgerufen werden kann.

� Handlerzuordnung In dieser Phase wird das Ereignis MapRequestHandler ausgelöst. Es wird der für die Anforderung benötigte Handler ermittelt.

� Zustandsabruf In dieser Phase wird das Ereignis AcquireRequestState ausgelöst. Es wird der für die Anforderung benötigte Handler abgerufen.

� Vor der Handlerausführung In dieser Phase wird das Ereignis PreExecuteRequestHandler ausgelöst. Diese Stufe signalisiert, dass der Handler kurz vor der Ausführung steht. Zu diesem Zeitpunkt erfolgt die Vorverarbeitung, sofern erforderlich.

� Handlerausführung In dieser Phase wird das Ereignis ExecuteRequestHandler ausgelöst. Der Handler wird ausgeführt und generiert die Antwort.

� Zustandsfreigabe In dieser Phase wird das Ereignis ReleaseRequestState ausgelöst. Der Anforde-rungszustand wird wieder freigegeben.

� Cacheaktualisierung In dieser Phase wird der Cache aktualisiert. Das Ereignis UpdateRequestCache wird ausgelöst.

� Anforderungsprotokollierung In dieser Phase wird die Anforderung protokolliert. Das Ereignis LogRequest wird ausgelöst.

� Anforderungsende In dieser Phase wird das Ereignis EndRequest ausgelöst, was darauf hindeutet, dass die Anforderungsverarbeitung abgeschlossen wird.

Module, die ein Ereignis abonnieren, stellen bestimmte Dienste zur Verfügung, die sich auf die jeweilige Phase der Pipeline beziehen. Abbildung 2.12 zeigt beispielsweise mehrere systemeigene und verwaltete Module, die das Ereignis AuthenticateRequest für die Anforderungsauthentifizierungsphase abonnieren. Dazu zählen die Module für die Standardauthentifizierung, Windows-Authentifizierung, ASP.NET-Formularauthentifizierung und anonyme Authentifizierung. Die Module für die Standard-, Windows- und anonyme Authentifizierung sind systemeigene Module, wohingegen die Formular-authentifizierung von einem verwalteten Modul bereitgestellt wird.



Abbildung 2.12 Systemeigene und verwaltete Module in der integrierten Verarbeitungspipeline

Die integrierte .NET-Pipeline bietet gegenüber den älteren IIS-Versionen besondere Vorteile, die nachfolgend aufgeführt sind:

� Dienste, die sowohl von systemeigenen als auch von verwalteten Modulen zur Verfügung gestellt werden, können auf alle Anforderungen angewendet werden.

Alle Dateitypen können Features nutzen, die bei IIS 6.0 ausschließlich verwaltetem Code zur Ver-fügung standen. Sie können nun beispielsweise die ASP.NET-Formularauthentifizierung und die URL-Autorisierung (Uniform Resource Locator) für statische Dateien, ASP-Dateien, statische CGI-Dateien und alle anderen Dateitypen in Ihren Sites und Anwendungen verwenden.

� Doppelt vorhandene Features für IIS und ASP.NET gibt es nicht mehr.

Wenn ein Client beispielsweise eine verwaltete Datei anfordert, ruft der Server das entsprechende Authentifizierungsmodul in der integrierten Pipeline auf, um den Client zu authentifizieren. Bei frü-heren IIS-Versionen durchlief dieselbe Anforderung sowohl die IIS- als auch die ASP.NET-Pipe-line, um authentifiziert zu werden. Weitere vereinheitlichte IIS- und ASP.NET-Funktionen sind die URL-Autorisierung, die Ablaufverfolgung, benutzerdefinierte Fehler und die Ausgabezwischen-speicherung.



� Alle Module werden an einem Ort verwaltet, wodurch auf dem Server die Site- und Anwendungs-verwaltung vereinfacht wird.

Anstatt einige Features unter IIS und andere in der ASP.NET-Konfiguration zu verwalten, gibt es nun nur noch einen Ort, um Serverfeatures zu implementieren, zu konfigurieren, zu überwachen und zu nutzen. Beispielsweise können IIS und ASP.NET aufgrund ihres zur Laufzeit wirksamen Zusammenschlusses dieselbe Konfiguration verwenden, um Servermodule zu aktivieren und zu nutzen und Handlerzuordnungen zu konfigurieren.

� IIS kann mit verwaltetem ASP.NET-Modulen erweitert werden.

Durch IIS 7.0 wird es möglich, dass ASP.NET-Module während des Betriebs direkt an die Server-pipeline angeschlossen werden können. Dies ist vergleichbar mit der Modulentwicklung unter Verwendung der nativen C++-IIS-API. ASP.NET-Module können in allen Laufzeitphasen der Anforderungsverarbeitungspipeline und – unter Berücksichtigung der systemeigenen Module – in jeder beliebigen Reihenfolge ausgeführt werden. Die ASP.NET-API wurde außerdem erweitert, um eine größere Kontrolle über die Anforderungsverarbeitung als bisher zu bieten.

Hinweis Um weitere Informationen zum Erweitern von IIS 7.0 zu erhalten, lesen Sie bitte das zwölfte Kapitel, »Ver-walten von Webservermodulen«.

Implementierung der ASP.NET-IntegrationObwohl systemeigene und verwaltete Module dasselbe Konzept implementieren, wenn es um logische Module geht, verwenden sie zwei unterschiedliche APIs. Um ein integriertes Pipelinemodell für systemeigene und verwaltete Module zu ermöglichen, stellt IIS 7.0 ein spezielles systemeigenes Modul namens Managed-Engine zur Verfügung. Das Modul Managed-Engine ist eigentlich ein Integrations-Wrapper für ASP.NET-Module. Mithilfe dieses Wrappers können verwaltete Module so agieren, als würde es sich um systemeigene IIS-Module und -Handler handeln. Es dient als Proxy für Ereignis-benachrichtigungen und leitet den benötigten Anforderungszustand an die verwalteten Module weiter. Zusammen mit der ASP.NET-Engine richtet es die integrierte Pipeline ein. Es ist außerdem dafür verantwortlich, die Konfiguration der verwalteten Module und Handler zu lesen.

Wenn eine Anforderung ein verwaltetes Modul benötigt, erzeugt das Modul Managed-Engine eine AppDomain, in der das verwaltete Modul die notwendige Verarbeitung durchführen kann, z.B. das Authentifizieren eines Benutzers mithilfe der Formularauthentifizierung. Abbildung 2.13 zeigt das Modul Managed-Engine mit dem verwalteten Modul für die Formularauthentifizierung, das innerhalb einer AppDomain ausgeführt wird.

Alle verwalteten Module sind vom Modul Managed-Engine abhängig und können ohne dieses nicht ausgeführt werden. Damit die integrierte Pipeline und ASP.NET-Anwendungen unter IIS 7.0 funk-tionieren können, muss das Modul Managed-Engine installiert und aktiviert sein.



Abbildung 2.13 Das Modul Managed-Engine

Unter Windows Server 2008 wird das Modul Managed-Engine als Bestandteil der Komponenten Rollendienst und .NET-Erweiterbarkeit installiert. Unter Windows Vista wird es als Bestandteil der Komponente .NET-Erweiterbarkeit installiert.

Hinweis Um weitere Informationen zur ASP.NET-Integration zu erhalten, lesen Sie bitte das zwölfte Kapitel.

Gültigkeitsbereiche von ModulenModule können auf verschiedenen Ebenen installiert und aktiviert werden. Auf der Serverebene aktivierte Module stellen einen Satz Standardfeatures für alle Anwendungen auf dem Server zur Ver-fügung. Der globale IIS-Konfigurationsspeicher applicationHost.config hält eine gemeinsame Liste systemeigener und verwalteter Modul bereit. Immer dann, wenn WAS einen Arbeitsprozess aktiviert, ruft der Dienst die Konfiguration aus dem Konfigurationsspeicher ab, und der Arbeitsprozess lädt alle global gelisteten Module.

Native Module können nur auf der Serverebene installiert werden. Eine Installation auf der Anwen-dungsebene ist nicht möglich. Auf der Anwendungsebene können jedoch die globalen systemeigenen Module, die auf der Serverebene aktiviert sind, entfernt werden, und die Module, die installiert, aber nicht global aktiviert sind, können für die jeweilige Anwendung aktiviert werden.

Verwaltete Module können auf der Server-, Site- und Anwendungsebene hinzugefügt werden. Anwendungsspezifische Module werden bei der ersten an die Anwendung gerichteten Anforderung geladen. Verwaltete Anwendungsmodule können zusammen mit anderen Anwendungsdateien mithilfe von xcopy bereitgestellt werden.

Sie können im IIS-Manager sowohl systemeigene als auch verwaltete Module mithilfe des Module-Features verwalten.

Hinweis Weitere Informationen zur Verwaltung von Modulen finden Sie im zwölften Kapitel.



ModulreihenfolgeDas Pipelinemodell gewährleistet, dass der Webserver die typischen Verarbeitungsaufgaben in der richtigen Reihenfolge ausführt. Die Authentifizierung muss beispielsweise vor der Autorisierung erfolgen: das Authentifizieren des mit einer Anforderung verknüpften Benutzers in der Anforderungs-authentifizierungsphase muss geschehen, bevor in der Anforderungsautorisierungsphase überprüft wird, ob der Benutzer auf die angeforderte Ressource zugreifen darf.

Der Server verwendet die Modulsequenzliste im Konfigurationsabschnitt <modules>, um die richtige Reihenfolge für die Modulausführung in den einzelnen Phasen der Anforderungsverarbeitung festzulegen. Da die Module nur in den für sie relevanten Phasen ausgeführt werden, entstehen keine Probleme mit der Reihenfolge. Mehrere Module, die in derselben Phase ausgeführt werden, können jedoch untereinander Abhängigkeiten bezüglich der Priorität aufweisen. Die integrierten Authentifi-zierungsmodule, die in der Anforderungsauthentifizierungsphase ausgeführt werden, sollten beispiels-weise so zum Einsatz kommen, dass zunächst die stärksten und dann die jeweils schwächeren Anmeldeinformationen versuchsweise verwendet werden, so dass die Anforderung immer mit den stärksten verfügbaren Anmeldeinformationen authentifiziert wird.

Um Abhängigkeiten hinsichtlich der Priorität zu verwalten, kann der Administrator die Modulreihen-folge kontrollieren, indem er im Abschnitt <modules> die Reihenfolge ändert, in der die Module aufgelistet sind. Dies kann beispielsweise mit dem Module-Feature des IIS-Managers geschehen.

Um die Modulreihenfolge eines Servers einzusehen und optional zu ändern, gehen Sie wie folgt vor:

1. Markieren Sie im IIS-Manager und dort im Bereich Verbindungen den Serverknoten.

2. Öffnen Sie auf der Startseite des Servers das Feature Module.

3. Klicken Sie im Bereich Aktionen auf Sortierte Liste anzeigen.



4. Sie können die Position eines Moduls innerhalb der Verarbeitungssequenz ändern, indem Sie das Modul markieren und im Bereich Aktionen die Optionen Nach oben und Nach unten benutzen, um es innerhalb der Liste an die gewünschte Position zu verschieben.

Hinweis Informationen über die Standardreihenfolge der integrierten Module erhalten Sie im Anhang D, »Reihen-folge der Module«.

Verarbeitung von Nicht-HTTP-AnforderungenBei IIS 7.0 unterstützt WAS Nicht-HTTP-Protokolle, so dass Sie IIS verwenden können, um Anwen-dungen und Dienste zu hosten, die nicht auf HTTP basieren. Das WAS-Prozessmodell verallgemeinert das Prozessmodell für den HTTP-Server, indem es die HTTP-Abhängigkeit ausräumt. Da WAS unter IIS 7.0 die Anwendungspoolkonfiguration und Arbeitsprozesse verwaltet, kann dasselbe, für HTTP verwendete Konfigurations- und Prozessmodell auch für Anwendungen genutzt werden, die nicht auf HTTP basieren. Alle IIS-Prozessverwaltungfeatures, wie z.B. die bedarfsorientierte Aktivierung, die Überwachung des Prozesszustands, eine unternehmensfreundliche Verwaltung und der Schutz vor schnellen Fehlerfolgen, sind bei IIS 7.0 auch für Nicht-HTTP-Anwendungen verfügbar.

Um Dienste und Anwendungen zu unterstützen, die andere Protokolle als HTTP und HTTPS nutzen, können Sie auf Technologien wie WCF (Windows Communication Foundation) zurückgreifen. Das WAS-Prozessmodell ermöglicht es Anwendungen und Diensten, die auf WCF basieren, HTTP- und Nicht-HTTP-Protokolle in einer Hostingumgebung zu verwenden, die eine nachrichtenbasierte Akti-vierung unterstützt und die Möglichkeit bietet, auf nur einem Computer eine große Anzahl von Anwen-dungen zu hosten. WCF (Windows Communication Foundation) wird mit Protokolladaptern ausge-liefert, die die WAS-Fähigkeiten nutzen können, was zu einer Verbesserung der Zuverlässigkeit und des Ressourcenverbrauchs von WCF-Diensten führt.


Verarbeitung von Nicht-HTTP-Anforderungen 53

WAS kann Anforderungen und Nachrichten über jedes beliebige Protokoll empfangen und unterstützt während des Betriebs die Aktivierung von frei wählbaren Protokolllistenern. Protokolllistener empfangen protokollspezifische Anforderungen, übergeben diese zur Verarbeitung an IIS und senden schließlich die entsprechenden Antworten an die Anforderer zurück. Bei WCF weist ein Listeneradapter die Funktio-nalität eines Protokolllisteners auf. Abbildung 2.14 zeigt WAS bei Listeneradaptern für Nicht-HTTP-Protokolle.

Abbildung 2.14 Unterstützung von Nicht-HTTP-Protokollen bei WAS

Listeneradapter sind Windows-Dienste, die über bestimmte Netzwerkprotokolle Nachrichten empfan-gen und mit WAS kommunizieren, um eingehende Anforderungen an den richtigen Arbeitsprozess wei-terzuleiten. Die Listeneradapterschnittstelle wird verwendet, um den Eingang von Aktivierungsanfor-derungen mitzuteilen, die über die unterstützten Nicht-HTTP-Protokolle empfangen werden. Es gibt die folgenden Nicht-HTTP-Listeneradapter:

� NetTcpActivator für das TCP-Protokoll

� NetPipeActivator für Named Pipes

� NetMsmqActivator für das Message-Queuing (auch bekannt als MSMQ)

Wenn Sie die HTTP-Funktionalität nicht benötigen, können Sie WAS auch ohne W3SVC ausführen lassen. Sie können beispielsweise einen Webdienst über einen WCF-Listeneradapter wie NetTcpActivator verwalten. W3SVC muss dann nicht ausgeführt werden, sofern Sie nicht mit HTTP.sys eingehende HTTP-Anforderungen abfangen müssen.

Der globale IIS-Konfigurationsspeicher applicationHost.config kann die Konfiguration von Nicht-HTTP-Protokollen enthalten. Der TCP-Listeneradapter NetTcpActivator kann beispielsweise basierend auf Informationen konfiguriert werden, die WAS aus dem Konfigurationsspeicher liest. Nachdem NetTcpActivator konfiguriert wurde, wartet es auf den Eingang von Anforderungen, die das TCP-Protokoll verwenden. Wenn ein Listeneradapter eine Anforderung empfängt, startet WAS einen Arbeitsprozess, dem der Listeneradapter die Anforderung zur Verarbeitung übergibt. Diese Architektur ist in Abbil-dung 2.15 dargestellt.



Abbildung 2.15 Verarbeitung von Nicht-HTTP-Anforderungen unter IIS 7.0

Da WAS die Prozesse sowohl für HTTP- als auch für Nicht-HTTP-Protokolle verwaltet, können Sie Anwendungen, die unterschiedliche Protokolle nutzen, im selben Anwendungspool ausführen. Sie können eine Anwendung beispielsweise gleichzeitig über das HTTP- und über das TCP-Protokoll hosten.

Das WAS-Prozessmodell von IIS 7.0 ist nicht nur protokollunabhängig, sondern versorgt auch alle Arten von nachrichtenaktivierten Anwendungen mit einer intelligenten Ressourcenverwaltung, einer bedarfsorientierten Prozessaktivierung, einer Zustandsüberwachung und einer automatischen Fehler-erkennung und Wiederherstellung. Dadurch können diese Anwendungen das IIS-Prozessmodell nutzen, ohne denselben Ressourcenbedarf wie eine vollständige IIS-Installation aufzuweisen.

Hinweis Weitere Informationen zu Listeneradaptern finden Sie im Artikel »WAS-Aktivierungsarchitektur« unter http://msdn2.microsoft.com/de-de/library/ms789006.aspx.

ZusammenfassungIn diesem Kapitel haben wir einen Blick auf die gesamte Anforderungsverarbeitungsarchitektur von IIS 7.0 geworfen. IIS 7.0 besteht aus mehreren Kernkomponenten, die zusammenarbeiten, um HTTP-Anforderungen zu verarbeiten. Zu diesen Komponenten zählen:

� HTTP.sys, der HTTP-Protokolllistener der Kernelebene

� W3SVC (World Wide Web Service Publishing Service), der HTTP-Listeneradapter

� WAS (Windows Process Activation Service, Windows-Prozessaktivierungsdienst), ein Dienst, der die Prozessaktivierung und -verwaltung ermöglicht

� Konfigurationsspeicher, eine aus verteilten XML-Dateien bestehende Konfigurationshierarchie, die sowohl IIS- als auch ASP.NET-Einstellungen speichert

� Arbeitsprozess, w3wp.exe, der in sich geschlossene Benutzermodusprozess, der HTTP-Anforderungen ausführt und Antworten generiert



Jeder Arbeitsprozess bedient einen Anwendungspool. Ein Anwendungspool kann für einen von zwei verwalteten Pipelinemodi konfiguriert sein: den integrierten und den klassischen Modus. Abhängig von dieser Konfigurationseinstellung gibt es für eine ASP.NET-Anforderung zwei Möglichkeiten, um innerhalb des Arbeitsprozesses, der für den Anwendungspool zuständig ist, ausgeführt zu werden:

� Im integrierten Modus: Die IIS- und ASP.NET-Verarbeitung ist vereinheitlicht und erfolgt in einer integrierten Verarbeitungspipeline.

� Im klassischen Modus: Die IIS- und ASP.NET-Pipelines sind wie bei IIS 6.0 voneinander getrennt.

Die integrierte Verarbeitungspipeline bildet die Basis für die modulare IIS 7.0-Architektur. Sie sorgt dafür, dass mehr als vierzig integrierte, in sich geschlossene systemeigene und verwaltete Module, die die Webserverfunktionalität implementieren, auf die eingehenden Anforderungen zugreifen können. Die wichtigsten Vorzüge der integrierten Verarbeitungspipeline sind nachfolgend genannt:

� Dienste, die sowohl von systemeigenen als auch von verwalteten Modulen zur Verfügung gestellt werden, können auf alle Anforderungen angewendet werden.

� Doppelt vorhandene Features für IIS und ASP.NET gibt es nicht mehr.

� Alle Module werden an einem Ort verwaltet, wodurch auf dem Server die Site- und Anwendungs-verwaltung vereinfacht wird.

� IIS kann mit verwaltetem ASP.NET-Modulen erweitert werden.

Zusätzlich zur Ausführung von HTTP-Anforderungen unterstützt IIS 7.0 das Hosting von Nicht-HTTP-Anwendungen und -Diensten, die das Prozessmodell ebenfalls nutzen können.

Auf der Begleit-CD Auf der CD finden Sie weitere Tools und Ressourcen.


� Um weitere Informationen zum IIS 7.0-Konfigurationssystem zu erhalten, lesen Sie bitte das vierte Kapitel, »Verstehen des Konfigurationssystems«.

� Weitere Informationen zur Anwendungskompatibilität finden Sie im elften Kapitel, »Hosting von Anwendungsentwicklungsframeworks«.

� Um weitere Informationen zur integrierten Verarbeitungspipeline und zur Verwaltung von Web-servermodulen zu erhalten, lesen Sie bitte das zwölfte Kapitel, »Verwalten von Webservermodulen«.

� Eine vollständige Liste der integrierten systemeigenen und verwalteten IIS 7.0-Module finden Sie in Anhang C, »Liste der IIS 7.0-Module«.

� Informationen über die Standardreihenfolge der integrierten IIS 7.0-Module erhalten Sie im Anhang D, »Reihenfolge der Module«.

� Weitere Informationen zu Listeneradaptern finden Sie im Artikel »WAS-Aktivierungsarchitektur« unter http://msdn2.microsoft.com/de-de/library/ms789006.aspx.


57

K A P I T E L 3

Verstehen der modularen Basis

Inhalt dieses Kapitels:� Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

� Hauptvorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

� Integrierte Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64



Welche Bedeutung hat der modulare Webserverkern für IIS 7.0 (Microsoft Internet Information Services)? Wie sorgt er dafür, dass IIS 7.0 der bisher leistungsfähigste Microsoft-Webserver ist? Und was sind die integrierten Module, die mit IIS 7.0 ausgeliefert werden? Keine Sorge – am Ende dieses Kapitels werden Sie die Antworten auf all diese Fragen kennen und eine genaue Vorstellung vom Designkonzept haben, das sich hinter IIS 7.0 verbirgt. Sie werden einen Blick auf das Komponenten-design von IIS 7.0 werfen und die Gründe für die Überarbeitung der Architektur sowie die Vorzüge des neuen Designs kennen lernen. Sie erhalten außerdem detaillierte Informationen zu den mit IIS 7.0 ausgelieferten integrierten Modulen.

KonzepteDie komponentenbasierte Architektur ist eine der wichtigsten Änderungen, die an IIS 7.0 vorge-nommen wurden. Basis für diese Änderung waren Erfahrungen mit IIS 6.0 und das Feedback von Kunden. IIS 7.0 wartet mit einer vollständig überarbeiteten Architektur auf. Der Webserverkern ist nun in separate Komponenten unterteilt, die als Module bezeichnet werden. Als Webadministrator verfügen Sie jetzt erstmals über die Möglichkeit, einen IIS-Server aufzubauen, den Sie an Ihre Bedürfnisse anpassen können. Sie können integrierte Module einfach hinzufügen, wenn diese benötigt werden, oder, was noch besser ist, Sie fügen Funktionalität hinzu oder ersetzen diese, indem Sie Module verwenden, die Sie selbst entwickelt haben, die von kommerziellen Anbietern stammen oder die von der IIS.net-Entwicklergemeinschaft zur Verfügung gestellt werden. Auf diese Weise erhalten Sie mithilfe der modularen Engine genau die Funktionalität, die Sie vom Webserver benötigen, aber auch die Flexibilität, die es Ihnen ermöglicht, nicht gewünschte Module zu entfernen, um den Webserver besser zu sichern.

Wenngleich der Webserver das Zentrum der IIS 7.0-Modularität ist, werden die Features der gesamten Plattform in Form von Modulen implementiert. Der Verwaltungsstack ist beispielsweise modular. Um ausführliche Informationen über die Erweiterbarkeit des IIS 7.0-Webservers und Verwaltungsstacks zu erhalten, lesen Sie bitte das zwölfte Kapitel, »Verwalten von Webservermodulen«, und das dreizehnte Kapitel, »Konfigurations- und Benutzeroberflächenerweiterungen verwalten«.


58 Kapitel 3: Verstehen der modularen Basis

Die IdeenEin Modul gleicht einem Baustein in einem LEGO-Kasten eines Kindes. Dieser Kasten enthält viele Steine in vielen verschiedenen Farben und Formen. Wenn diese mit Bausteinen aus anderen Kästen kombiniert werden, können viele verschiedene Strukturen mit unterschiedlichen Formen zusammen-gesetzt werden. IIS 7.0 greift für das Design seines Frameworkfundaments auf die gleiche Idee zurück. Diese aus zusammensteckbaren Komponenten bestehende Architektur wird mit einem flexiblen Konfigurationssystem und einer erweiterbaren Benutzeroberfläche kombiniert. Sie ermöglicht durch den Einsatz von Modulen und Bausteinen das Hinzufügen und Entfernen von beliebigen Funktionali-täten, so dass Sie einen Webserver aufbauen können, der an die speziellen Bedürfnisse Ihres Unter-nehmens angepasst ist. Dieses neue und offene Design ist revolutionär für Microsoft und öffnet der Webplattform ganz neue Türen.

ModultypenIIS 7.0 wird mit ca. vierzig Modulen ausgeliefert, zu denen auch sicherheitsrelevante Authentifizie-rungsmodule und Module für die Komprimierung von Inhalten zählen. Module stellen die Features eines Webservers zur Verfügung und eine Webanwendung setzt sich aus vielen Modulen zusammen, die Anforderungen bedienen. Hinsichtlich des Aufgabenbereichs können Module in zwei Kategorien unterteilt werden. Es gibt Module, die Anforderungsdienste bereitstellen, z.B. die Komprimierung und die Authentifizierung, sowie Module, die für die Anforderungsbehandlung zuständig sind. Dazu zählt

So funktioniert es: Das modulare DesignIIS 7.0 wird mit vielen verschiedenen Modulen ausgeliefert. Jedes Modul ist eine Komponente (aber nicht im Sinne von COM [Component Object Model]), die bestimmte Dienste für die HTTP-Anforde-rungsverarbeitungspipeline des Webservers zur Verfügung stellt. StaticFileModule ist beispielsweise das Modul, das alle statischen Inhalte behandelt, wie zum Beispiel HTML-Seiten, Bilddateien usw. Andere Module ermöglichen die dynamische Komprimierung, die Standardauthentifizierung und all die anderen Features, die Sie in der Regel mit IIS verbinden. Module werden bei IIS 7.0 separat verwaltet. Sie können auf einfache Weise mithilfe des neuen Konfigurationssystems der Kernengine hinzugefügt oder aus dieser entfernt werden.

Intern stellt der IIS-Webserverkern die Anforderungsverarbeitungspipeline für auszuführende Module bereit. Er stellt außerdem Anforderungsverarbeitungsdienste zur Verfügung, wobei die für die Verarbeitungspipeline registrierten Module basierend auf registrierten Ereignisbenachrichti-gungen aufgerufen werden, um Anforderungen zu verarbeiten. Als Administrator können Sie nicht kontrollieren, für welche Ereignisse die Module programmiert wurden. Dies ist innerhalb des Moduls im Code festgelegt. Sie können jedoch kontrollieren, welche Module global geladen werden, und Sie können sogar kontrollieren, welche Module für eine bestimmte Site oder Anwendung geladen werden. Genaue Informationen zum Laden von Modulen finden Sie im zwölften Kapitel.

Immer dann, wenn der IIS 7.0-Arbeitsprozess gestartet wird, liest er die Serverkonfigurationsdatei und lädt alle global gelisteten Module. Anwendungsmodule werden geladen, sobald zum ersten Mal eine an die Anwendung gerichtete Anforderung eingeht. Es sind dieses modulare Design und dieses Konfigurationssystem, die dafür sorgen, dass Sie während des Betriebs Module zur Anforderungs-pipeline hinzufügen, in dieser ersetzen oder aus dieser entfernen können, wodurch die uneinge-schränkte Erweiterbarkeit des IIS 7.0-Webservers gewährleistet ist.


Konzepte 59

beispielsweise die Bereitstellung von statischen Dateien, ASP.NET-Seiten usw. Ungeachtet ihrer Auf-gabenbereiche sind Module die wichtigsten Zutaten für IIS 7.0. Entwickler können zwei Arten von IIS-Modulen erstellen:

� Verwaltete Module Ein verwaltetes Modul ist eine .NET Framework-Komponente, die auf dem ASP.NET-Erweiterbarkeitsmodell basiert. Die integrierte Verarbeitungsarchitektur von IIS 7.0 trägt dazu bei, dass ASP.NET-Anwendungsdienste nicht mehr ausschließlich auf Anforderungen beschränkt sind, die sich auf .ASPX-Seiten oder andere ASP.NET-Inhalte beziehen. Die verwalteten Module werden bei IIS 7.0 direkt an der Anforderungsverarbeitungspipeline des Webservers angeschlossen, weshalb sie genauso leistungsfähig wie die unter Berücksichtigung der nativen Erweiterbarkeitsschicht entwickelten Module sind. Um die von den ASP.NET-Modulen angebotenen Dienste für alle Anfor-derungen nutzen zu können, muss Ihre Anwendung in einem Anwendungspool ausgeführt werden, der im integrierten Modus arbeitet. Diese Integration ist mithilfe des ManagedEngine-Moduls möglich, das innerhalb der Anforderungsverarbeitungspipeline die .NET-Integration bereitstellt. Verwaltete Module werden nur dann global geladen, wenn der Anwendungspool ein integrierter Pool ist. Weitere Informationen zum neuen integrierten Pipelineverarbeitungsmodus finden Sie im zwölften Kapitel.

� Systemeigene Module Ein systemeigenes Modul ist eine in C++ geschriebene Microsoft Windows-DLL (Dynamic Link Library), die Anforderungsverarbeitungsdienste zur Verfügung stellt. Bei IIS 7.0 hat ein neuer Satz nativer (C++) Server-APIs (Application Programming Inter-face) die APIs für ISAPI-Filter und -Erweiterungen (Internet Server Application Programming Interface) ersetzt, die von früheren IIS-Versionen angeboten wurden. Diese neuen APIs wurden unter Verwendung eines objektorientierten Modells entwickelt und sind mit vielen leistungsfähigen Schnittstellen ausgestattet, so dass Sie die Anforderungsverarbeitung und Antwortbehandlung besser kontrollieren können. Viele Entwickler, die mit ISAPI und den neuen nativen Modul-APIs vertraut sind, berichten davon, dass es nun im Vergleich zu früheren IIS-Versionen sehr viel einfacher sei, mit nativem Code zu entwickeln.

Hinweis Ausführliche Informationen zur Entwicklung systemeigener Module finden Sie im englischen Artikel »How to Build a Native Code IIS7 Module Using C++« unter http://www.iis.net/go/938.

Entwickler können unter IIS 7.0 systemeigene und verwaltete Module auf dieselbe Art und Weise verwalten und konfigurieren. Lediglich bei der Bereitstellung von Modulen gibt es Unterschiede. Systemeigene Module werden global auf dem Server installiert und können für jede Anwendung aktiviert oder deaktiviert werden. Verwaltete Module können global aktiviert oder von jeder Anwen-dung zur Verfügung gestellt werden. Weitere Informationen zur Bereitstellung von Modulen erhalten Sie im zwölften Kapitel.

Module und KonfigurationDamit die Module IIS 7.0 bestimmte Features oder Dienste zur Verfügung stellen können, müssen sie im Konfigurationssystem registriert sein. Dieser Abschnitt des Buches wirft einen Blick auf die Beziehungen zwischen den Modulen und den verschiedenen Abschnitten in der Konfigurationsdatei und er bietet eine allgemeine Übersicht über die Moduleinstellungen im Konfigurationsspeicher. Weitere Informationen zum IIS 7.0-Konfigurationssystem, das auf XML basiert (Extensible Markup Language), finden Sie im vierten Kapitel, »Verstehen des Konfigurationssystems«.



Innerhalb des <system.webServer>-Abschnitts der Datei applicationHost.config (dies ist die Hauptdatei für die Serverkonfiguration) gibt es drei verschiedene Abschnitte, die sich auf Module beziehen:

� <globalModules> Dieser Abschnitt kann nur auf der Serverebene konfiguriert werden und definiert alle aus nativem Code bestehenden Module, die Dienste für Anforderungen bereitstellen. Die Moduldeklaration im Konfigurationsabschnitt legt ebenfalls die zugehörige DLL-Datei fest, die die Modulfeatures zur Verfügung stellt. Alle systemeigenen Module müssen – wie unter <modules> festgelegt – in diesem Abschnitt definiert oder registriert werden, bevor sie für die Nutzung durch die Anwendungen eingeschaltet oder aktiviert werden können.// Beispiel für den Konfigurationsabschnitt <globalModules> <globalModules> ... <add name="StaticCompressionModule" image="%windir%\...\compstat.dll" /> <add name="DefaultDocumentModule" image="%windir%\...\defdoc.dll" /> <add name="DirectoryListingModule" image="%windir%\...\dirlist.dll" /> ... </globalModules>

� <modules> Dieser Abschnitt kann auf der Server- und Anwendungsebene konfiguriert werden und definiert die für eine Anwendung aktivierten Module. Native Module sind zwar im Abschnitt <globalModules> registriert, müssen aber im Abschnitt <modules> aktiviert werden, bevor sie den Anwen-dungen ihre Anforderungsdienste zur Verfügung stellen können. Module, die aus verwaltetem Code bestehen, können jedoch direkt dem Abschnitt <modules> hinzugefügt werden. Sie können beispiels-weise der web.config-Datei einer Anwendung ein benutzerdefiniertes verwaltetes Modul für die Standardauthentifizierung hinzufügen. Sie können aber auch die applicationHost.config-Datei auf der Serverebene bereitstellen.// Beispiel für den Konfigurationsabschnitt <modules> <modules> ... <add name="BasicAuthenticationModule" /> <add name="WindowsAuthenticationModule" /> <add name="OutputCache" type="System.Web.Caching.OutputCacheModule" preCondition="managedHandler" /> <add name="Session" type="System.Web.SessionState.SessionStateModule" preCondition="managedHandler" /> ... </modules>

� <handlers> Dieser Abschnitt kann auf der Server-, Anwendungs- und URL-Ebene (Uniform Resource Locator) konfiguriert werden und definiert, wie Anforderungen behandelt werden. Er führt auch basierend auf dem URL und den HTTP-Verben die Handlerzuordnungen durch. Dazu wird das jeweilige Modul angegeben, das den entsprechenden Handler unterstützt. IIS 7.0 parst die Handlerzuordnungskonfiguration, um zu ermitteln, welche Module aufgerufen werden müssen, wenn eine bestimmte Anforderung eingeht.// Beispiel für den Konfigurationsabschnitt <handlers> <handlers accessPolicy="Script, Read"> ... <add name="ASPClassic" path="*.asp" verb="GET,HEAD,POST" modules="IsapiModule" scriptProcessor="...\asp.dll" resourceType="File" /> <add name="SecurityCertificate" path="*.cer" verb="GET,HEAD,POST"


Hauptvorteile 61

modules="IsapiModule" scriptProcessor="...\asp.dll" resourceType="File" /> <add name="SSINC-stm" path="*.stm" verb="GET,POST" modules="ServerSideIncludeModule" resourceType="File" /> ... </handlers>

HauptvorteileDie modulare IIS 7.0-Architektur bietet viele Vorteile gegenüber früheren IIS-Versionen. Dieser Abschnitt nennt die Vorteile, die sich aus diesem Design ergeben. Er beschreibt außerdem Szenarien, die verdeutlichen, wie ein Webadministrator diese Vorzüge nutzen kann, um einen stabilen Webserver aufzubauen.

SicherheitFür die heutigen Webanwendungen ist die Sicherheit einer der wichtigsten Aspekte. IIS 6.0 wird nur bei der Webserveredition von Windows Server 2003 standardmäßig installiert. Diese IIS 6.0-Standard-installation stellt ausschließlich statische Inhalte bereit. Jede andere Funktionalität ist deaktiviert. IIS 7.0 spiegelt die modulare Natur des Webservers wider und ermöglicht es dem Benutzer, nur die Module zu installieren, die für die jeweilige Anwendung notwendig sind. Binärdateien, die die anderen Features enthalten, werden nicht installiert, sondern in einem geschützten Installationscache des Betriebs-systems verwahrt. Dies bedeutet, dass Sie nicht dazu aufgefordert werden, eine CD einzulegen oder einen Zielort anzugeben, wenn Sie neue Updates installieren oder Features hinzufügen. Die Binär-dateien, die Sie nicht verwenden, werden auch nicht von den IIS-Arbeitsprozessen geladen. Sie werden stattdessen unter Quarantäne gestellt, so dass ein Zugriff darauf nicht möglich ist. Wenn Sicherheits-updates von Microsoft verfügbar sind, werden die nicht installierten Features im Installationscache ebenfalls vollständig aktualisiert. Dies trägt dazu bei, dass Service Packs nicht erneut angewendet werden müssen, wenn Sie nachträglich neue Features installieren.

Hinsichtlich der Sicherheit bietet das modulare Design mehrere wichtige Vorteile, von denen einige nachfolgend genannt sind:

� Minimale Angriffsfläche Dadurch, dass IIS 7.0 Ihnen die Möglichkeit bietet, nur die benötigten Komponenten zu installieren, wird die mögliche Angriffsfläche stark verkleinert. Die Angriffs-punkte sind auf die installierten Komponenten begrenzt, weil es nur für diese Komponenten Binärdateien gibt. Da nur die installierten Komponenten Ziel potentieller Exploits sein können, ist dies die beste Verteidigung. Bei der IIS 7.0-Standardinstallation werden beispielsweise nur ca. zehn Komponenten installiert, die die interne IIS-Protokollierung und -Verwaltung sowie die Bearbei-tung solcher Anforderungen ermöglichen, die sich auf statische Inhalte beziehen. Genau genommen sind dies die einzigen Punkte, die für potentielle Angriffe genutzt werden können.

� Geringerer Wartungsaufwand Das modulare Design bietet nicht nur eine neue Flexibilität beim Hinzufügen, Entfernen und Ersetzen von Komponenten, es hält mittels des selektiven Patchings auch ganz neue Wartungsmöglichkeiten bereit. Sie müssen Fixes oder Patches nur auf die benötigten oder installierten Komponenten anwenden. Nicht verwendete Komponenten oder Module, die nicht instal-liert wurden, erfordern keine sofortige Zuwendung. Außerdem gibt es keine Ausfallzeiten durch das Patching nicht installierter Komponenten. Dies bedeutet auch, dass weniger Verwaltungsarbeit für die routinemäßige Wartung und für Upgrades erforderlich ist. Wenn ein IIS 7.0-Server beispielsweise nur die Windows-Authentifizierung für seine Anwendungen nutzt, werden auf dem Server nur solche



Patches angewendet, die sich auf das Windows-Authentifizierungsmodul beziehen. Wenn dann das Modul für die Standardauthentifizierung Ziel eines bekannten Exploits ist, ist ein sofortiges Patching nicht notwendig, da dieses Modul nicht verwendet wird. Beachten Sie jedoch, dass Microsoft empfiehlt, immer alle Patches anzuwenden, um sicherzustellen, dass die nicht benutzten Module und Features stets auf dem neuesten Stand sind, so dass sie bedenkenlos nachträglich installiert werden können.

Wichtig Microsoft empfiehlt, dass Sie auf dem Server alle Patches installieren. Wenn Sie Patches auf Komponen-ten anwenden, die nicht genutzt werden, wird der Server nicht mit Ausfallzeiten konfrontiert. Wenn dann die Komponenten später installiert werden, werden automatisch die neuesten Versionen der entsprechenden Binär-dateien verwendet, so dass es nicht notwendig ist, die Patches neu anzuwenden.

� Vereinheitlichtes Sicherheitsmodell ASP.NET ist nun besser in IIS 7.0 integriert. Dadurch, dass systemeigene IIS 7.0-Module und verwaltete ASP.NET-Module an derselben Anforderungspipeline beteiligt sind, ergeben sich viele Vorteile, z.B. ein einheitliches Konfigurationssystem und einheit-liche Sicherheitsmodelle für IIS und ASP.NET. Hinsichtlich der Sicherheit können erweiterte ASP.NET-Sicherheitsdienste direkt an die IIS-Hauptpipeline für die Anforderungsverarbeitung angeschlossen und zusammen mit den IIS-Sicherheitsfeatures verwendet werden. Kurz gesagt ist es mit IIS 7.0 nun möglich, ASP.NET-Sicherheitsdienste für Nicht-ASP.NET-Anforderungen zu konfi-gurieren. Wenn beispielsweise bei älteren IIS-Versionen eine Anwendung sowohl aus PHP- als auch aus ASP.NET-Ressourcen bestand, konnte die ASP.NET-Formularauthentifizierung nur für die ASP.NET-Ressourcen genutzt werden. Das integrierte IIS 7.0-Prozessmodell ermöglicht nun die Formularauthentifizierung für PHP-, ASP.NET- und andere Arten von Ressourcen, wie zum Beispiel statische Inhalte (HTML, Bilder) und ASP-Seiten.

Direkt von der Quelle: Der sicherste Webserver der WeltAls wir während der TechEd 2005 IIS 7.0 einem großen Publikum präsentierten, war das auch mein erster TechEd-Auftritt. Meine erste Präsentation zeigte die Möglichkeiten, die sich aus der komponentenbasierten Architektur von IIS 7.0 ergaben. Wir nannten diese Präsentation scherzhaft »Der sicherste Webserver der Welt«.

Ein Teil der Demonstration bestand darin, dass ich zeigte, wie die Konfiguration in der Datei applicationHost.config bearbeitet wird. Ich entfernte alle Module und Handlerzuordnungen. Nach dem Speichern der Datei übernahm IIS die Änderungen und führte einen Neustart durch, wobei natürlich keine Module geladen wurden. Nachdem ich eine Anforderung der Standardwebsite eingereicht hatte, erhielt ich sofort eine leere Antwort vom Typ 200 zurück (diese Konfiguration gibt gegenwärtig einen Fehler aufgrund einer fehlenden Autorisierung vom Typ 401 zurück, weil keine Authentifizierungsmodule vorhanden sind). Der Server hatte keine Module geladen und führte deshalb nahezu keine Verarbeitung der Anforderung durch, weshalb auch keine Inhalte zurückge-geben wurden. Der Server war somit zum sichersten Webserver der Welt geworden. Nach einer kurzen Pause wies ich daraufhin, dass dieser Server zwar sicher, aber völlig nutzlos sei, und dann ging ich dazu über, die Funktionalität wieder hinzuzufügen, die ich für meine Anwendung benötigte.


Hauptvorteile 63

LeistungAufgrund der aus Komponenten bestehenden Architektur können Sie mit IIS 7.0 den Speicherver-brauch des Webservers genau kontrollieren. Module werden nur dann in den Speicher geladen, wenn sie installiert und aktiviert sind. Durch das Entfernen nicht benötigter IIS 7.0-Features werden weniger Komponenten geladen, um an die Verarbeitungspipeline angeschlossen zu werden – somit sind weniger Schritte notwendig, um eingehende Anforderungen zu verarbeiten. Dies führt insgesamt zu einer besseren Serverleistung. Gleichzeitig steht mehr freier Speicherplatz für Webanwendungen und das Betriebssystem zur Verfügung, wenn der Speicherverbrauch des IIS 7.0-Servers verringert wird. Bei IIS 6.0 wurden beispielsweise alle Authentifizierungsanbieter (Anonyme, Windows-, Digestauthentifi-zierung usw.) in den Arbeitsprozess geladen. Bei IIS 7.0 werden nur die benötigten Authentifizierungs-module geladen und in die Anforderungsverarbeitung eingebunden. Weitere Informationen zum Entfernen von nicht benötigten Modulen finden Sie im zwölften Kapitel.

ErweiterbarkeitBei älteren IIS-Versionen ist das Erweitern oder Hinzufügen von IIS-Features nicht einfach, weil dies nur mithilfe der ISAPI-Programmierung, einer eingeschränkten API-Unterstützung und einem eingeschränkten Zugriff auf die Informationen in der Anforderungsverarbeitungspipeline möglich ist. Mit der neuen auf Modulen basierenden Engine und der engen Verflechtung zwischen ASP.NET und IIS ist das Erweitern von IIS 7.0 sehr viel einfacher. IIS 7.0-Module können mit der neuen nativen C++-Webserver-API oder unter Verwendung der ASP.NET-Schnittstellen und der Funktionalität des .NET Frameworks entwickelt werden. Sie können nicht nur entscheiden, welche Features in den Webserver eingebunden werden sollen, sondern Sie können den Webserver auch erweitern, indem Sie Ihre eigenen benutzerdefinierten Komponenten hinzufügen, um eine bestimmte Funktionalität zur Verfügung zu stellen.

Sie könnten beispielsweise ein ASP.NET-Standardauthentifizierungsmodul entwickeln, das den Mitgliedschaftsdienst und eine SQL Server-Benutzerdatenbank anstelle des integrierten IIS-Standard-authentifizierungsfeatures verwendet, das ausschließlich mit Windows-Konten arbeitet. Kurz gesagt können Sie Ihren eigenen benutzerdefinierten Server aufbauen, der die Features bereitstellt, die Ihre Anwendungen benötigen. Sie können beispielsweise eine Gruppe von IIS 7.0-Servern ausschließlich für das Caching benutzen, oder Sie setzen ein benutzerdefiniertes Modul ein, das innerhalb einer Anwendung einen bestimmten Zweck erfüllt, wie z.B. die Implementierung eines eigenen Lastenausgleichsalgo-rithmus für ASP.NET-Anwendungen, der sich nach den Anforderungen der Kunden richtet. Weitere Informationen zu benutzerdefinierten Modulen unter IIS 7.0 finden Sie im zwölften Kapitel.

Ich hatte diese Demonstration schon früher einem ausgesuchten Publikum präsentiert und Beifall dafür erhalten, aber ich werde nie vergessen, wie das Publikum während der TechEd-Vorführung reagierte. Die Menschen im Publikum gerieten außer Rand und Band und ließen sich teilweise sogar zu stehenden Ovationen hinreißen. Das war eine überwältigende Bestätigung unserer Bemühungen, Administratoren die Möglichkeit zu bieten, einen Server von Grund auf neu und nur mit den wirklich benötigten Features aufzubauen, so dass ein einfach zu verwaltender Webserver mit der geringst-möglichen Angriffsfläche entsteht.

Mike Volodarsky




Integrierte ModuleModule, die mit IIS 7.0 ausgeliefert werden, sind in verschiedene Kategorien unterteilt, die sich nach den jeweiligen geleisteten Diensten richten. Tabelle 3.1 führt die verschiedenen Dienstkategorien auf und nennt einige integrierte Beispielmodule zu den Kategorien. Eine vollständige Modulliste finden Sie in Anhang C, »Liste der IIS 7.0-Module«.

Tabelle 3.1 Modulkategorien

Kategorie Modul

Anwendungsentwicklung CgiModule (%windir%\system32\inetsrv\cgi.dll)Ermöglicht die Unterstützung von CGI-Programmen (Common Gateway Interface)

FastCgiModule (%windir%\system32\inetsrv\iisfcgi.dll) Unterstützt FastCGI, eine leistungsfähige Alternative zu den alten CGI-Programmen

System.Web.SessionState.SessionStateModule (ManagedEngine)

Ermöglicht die Sitzungszustandsverwaltung, bei der spezifische Daten eines einzelnen Clients von einer Anwendung auf dem Server gespeichert werden

Systemzustand und Diagnose FailedRequestsTracingModule (%windir%\system32\inetsrv\iisfreb.dll)Besser bekannt als Anforderungsfehler-Ereignispufferung (Failed Request Event Buffering, FREB). Dieses Modul unterstützt die Nachverfolgung fehlgeschlagener Anforderungen. Die Defi-nitionen und Regeln, die eine fehlgeschlagene Anforderung beschreiben, können konfiguriert werden.

RequestMonitorModule (%windir%\system32\inetsrv\iisreqs.dll)Implementiert RSCA (Run-time State and Control API), eine API, mit der es möglich ist, Lauf-zeitinformationen abzufragen. Dazu zählen beispielsweise die gegenwärtig ausgeführten Anfor-derungen, der Ausführungsstatus einer Website (gestartet oder beendet) oder die gegenwärtig ausgeführten Anwendungsdomänen.

HTTP-Features ProtocolSupportModule (%windir%\system32\inetsrv\protsup.dll)Implementiert benutzerdefinierte Header oder Umleitungsantwortheader, behandelt HTTP TRACE- und OPTIONS-Verben und unterstützt die Keep-Alive-Konfiguration

Leistung TokenCacheModule (%windir%\system32\inetsrv\cachtokn.dll)Speichert im Cache Windows-Sicherheitstokens für auf Kennwörtern basierende Authentifizie-rungschemata (anonyme Authentifizierung, Standardauthentifizierung und IIS-Clientzertifikat-authentifizierung)

System.Web.Caching.OutputCacheModule (ManagedEngine)

Definiert die Ausgabezwischenspeicherungsrichtlinien einer ASP.NET-Seite oder eines Benutzer-steuerelements, das in einer Seite enthalten ist

Sicherheit RequestFilteringModule (%windir%\system32\inetsrv\modrqflt.dll)Stellt unter IIS 7.0 eine ähnliche Funktionalität wie URLSCAN zur Verfügung. Dazu wird ein leis-tungsfähiger Satz Sicherheitsregeln implementiert, um verdächtige Anforderungen in einer sehr frühen Phase abzuweisen.



Weitere Informationen zum Modulkonfigurationsspeicher sowie zu Modulabhängigkeiten und poten-tiellen Problemen beim Entfernen eines Moduls finden Sie in Anhang C.

ZusammenfassungDie wichtigsten von IIS 7.0 angebotenen Features stammen aus seinem modularen Design. Webadmi-nistratoren haben zum ersten Mal die volle Kontrolle über den IIS-Server. Es ist außerdem die erste IIS-Version, die vollständig erweiterbar ist. Sie definiert ein vereinheitlichtes Anforderungsverarbeitungs-modell, das ASP.NET in IIS integriert. Module sind die grundlegenden Bausteine eines IIS 7.0-Servers. IIS 7.0 bietet eine Vielzahl von Möglichkeiten zur Verwaltung von Modulen (die grundlegenden Elemente des IIS-Featuresatzes) an, so dass Sie effiziente Webserver mit einem geringen Speicher-verbrauch implementieren können, die für bestimmte Aufgaben optimiert sind. Wenn Sie viele Module auswählen, erhalten Sie auf Ihrem Server eine umfassende Funktionalität. Oder Sie entfernen nicht benötigte Features, um die Angriffsfläche zu verkleinern und die Leistung zu verbessern. Im zwölften Kapitel erfahren Sie mehr über die verschiedenen von IIS 7.0 unterstützten Module und deren Funk-tionsweise. Sie erfahren außerdem, wie Sie diese innerhalb der IIS-Umgebung richtig einsetzen und verwalten.


� Kapitel 4, »Verstehen des Konfigurationssystems«, enthält Informationen zum neuen auf XML basierenden Konfigurationssystem und zu wichtigen IIS 7.0-Konfigurationsdateien.

� Kapitel 12, »Verwalten von Webservermodulen«, enthält Informationen zum Laden und Verwalten von Modulen unter IIS 7.0.

� Kapitel 13, »Konfigurations- und Benutzeroberflächenerweiterungen verwalten«, enthält Informationen zur Erweiterung des IIS 7.0-Konfigurationssystems.

UrlAuthorizationModule (%windir%\system32\inetsrv\urlauthz.dll)Unterstützt auf Regeln basierende Konfigurationen für die Autorisierung von Inhalten

System.Web.Security.FormsAuthenticationModule (ManagedEngine)Implementiert die ASP.NET-Formularauthentifizierung für angeforderte Ressourcen

Serverkomponenten ConfigurationValidationModule (%windir%\system32\inetsrv\validcfg.dll)Verantwortlich für die Verifizierung der IIS 7.0-Konfiguration. Dies ist beispielsweise notwendig, wenn eine Anwendung im integrierten Modus ausgeführt wird, aber über Handler oder Module verfügt, die im Abschnitt <system.web> deklariert sind.

ManagedEngine/ManagedEngine64 (webengine.dll)Die Managed-Engine nimmt unter allen Modulen eine besondere Stellung ein, da sie dafür verantwortlich ist, die ASP.NET-Laufzeit in IIS zu integrieren

Tabelle 3.1 Modulkategorien (Fortsetzung)

Kategorie Modul



� Kapitel 14, »Implementieren von Sicherheitsstrategien«, enthält Informationen zu Sicherheitsstrategien.

� Anhang C, »Liste der IIS 7.0-Module«, enthält ausführliche Informationen zu jedem mit IIS 7.0 ausgelieferten integrierten Modul.

� Der englische Artikel »Develop a Native C/C++ Modules for IIS 7.0« auf der Web Resource-Seite unter http://www.iis.net/go/938 enthält wertvolle Informationen für Entwickler.


67

K A P I T E L 4

Verstehen des Konfigurationssystems

Inhalt dieses Kapitels:� Übersicht über das Konfigurationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

� Konfigurationsbearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

� Konfigurationsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

� Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

� Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112


Viele der neuen Features und Möglichkeiten von IIS 7.0 (Internet Information Services) sind auf dessen Konfigurationssystem zurückzuführen, das gänzlich überarbeitet wurde. Die Metabasis von früher wurde in ein an .NET angelehntes Konfigurationssystem verwandelt, das in vielerlei Hinsicht einfacher zu handhaben ist. Das neue Design bildet die Grundlage für die delegierte und zentralisierte Konfigura-tion, die ASP.NET-Integration, die xcopy-Bereitstellung der Konfiguration und viele andere Leistungs-merkmale.

Das IIS 7.0-Konfigurationssystem arbeitet meistens von Ihnen unbemerkt, und in diesen Fällen müssen Sie auch nicht wissen, was hinter den Kulissen geschieht. Wenn man jedoch dafür sorgt, dass ein System flexibler wird, führt dies oft zu einer größeren Komplexität, was auch für das IIS 7.0-Konfigurations-system gilt. Dieses Kapitel beschreibt ausführlich die Funktion der Konfiguration, so dass Sie eine genaue Vorstellung hiervon erhalten.

Abbildung 4.1 Das IIS 7.0-Konfigurationssystem


68 Kapitel 4: Verstehen des Konfigurationssystems

Wie Abbildung 4.1 zeigt, ist die gesamte IIS 7.0-Konfiguration aus mehreren Systemen zusammen-gesetzt, die sowohl zusammen als auch unabhängig voneinander arbeiten. Administratoren, die die .NET-Konfigurationsdateien und deren Arbeitsweise kennen, werden mit der IIS 7.0-Konfiguration schnell vertraut sein. Wenn Ihr bisheriger Kontakt mit der IIS-Konfiguration ausschließlich darin bestand, über ein Tool wie den Metabasis-Explorer darauf zuzugreifen, werden Sie sich etwas intensiver damit beschäftigen müssen, aber es lohnt sich.

Übersicht über das KonfigurationssystemDas IIS 7.0-Konfigurationssystem weist in vielerlei Hinsicht große Unterschiede zum Konfigurations-modell älterer IIS-Versionen – die Metabasis – auf. Die neue Architektur berücksichtigt die Anforde-rungen, die verlangen, dass das IIS 7.0-Konfigurationssystem besser verwaltbar sein und wichtige Bereitstellungsszenarien flexibler unterstützen sollte.

IIS 7.0-Konfigurationssystem basiert auf einer aus XML-Konfigurationsdateien bestehenden Hierarchie. Die Dateien enthalten strukturierte XML-Daten, die die Konfigurationsinformationen für IIS und seine Features beschreiben. Diese Hierarchie umfasst die .NET Framework-Konfigurationsdateien, machine.config und die web.config-Stammdatei, die IIS-Hauptkonfigurationsdatei namens applicationHost.config und verteilte web.config-Konfigurationsdateien, die sich innerhalb der Verzeichnisstruktur der Website befinden. Ein wichtiger Vorteil dieser Hierarchie ist die Fähigkeit, IIS- und ASP.NET-Konfigurationsinformationen zusammen an einem Ort zu speichern. Ein weiterer Vorteil ist die Fähigkeit, die IIS-Konfiguration zusammen mit den Inhalten der Website zu verwahren, so dass die Website portabel wird und weniger administrative Rechte notwendig sind, um die Website bereitzustellen.

Die Konfigurationsdateien in der Hierarchie enthalten Konfigurationsabschnitte, bei denen es sich um strukturierte XML-Elemente handelt, die Konfigurationseinstellungen für bestimmte IIS-Features beschreiben. Im Gegensatz zu dem von der Metabasis verwendeten Eigenschaft/Wert-Modell trägt das strukturierte XML-Format der IIS 7.0-Konfigurationsabschnitte dazu bei, dass die Konfiguration übersichtlicher wird und einfacher zu verstehen ist. Die Konfiguration wird dadurch selbsterklärend, so dass Sie sie einfach manuell bearbeiten können. Der Anwendungsentwickler kann beispielsweise die folgende Konfiguration in der web.config-Datei des Websitestammverzeichnisses platzieren, um das IIS-Standarddokumentfeature zu aktivieren und ein bestimmtes zu verwendendes Standarddokument zu konfigurieren.<system.webServer> <defaultDocument enabled="true"> <files> <add value="home.aspx" /> </files> </defaultDocument> </system.webServer>

Da das IIS 7.0-Konfigurationssystem dieselben web.config-Dateien wie das ASP.NET-Konfigurations-system verwendet, kann Ihre Anwendung ASP.NET- und IIS-Konfigurationseinstellungen Seite an Seite innerhalb derselben Datei zur Verfügung stellen. Da sich diese Datei inmitten Ihrer Anwendungsinhalte befindet, kann die Anwendung auf einem IIS-Server bereitgestellt werden, indem einfach ihre Inhalte kopiert werden. Eine zentrale Konfiguration muss hierzu nicht modifiziert werden.

Gleichzeitig kann der Serveradministrator die IIS-Konfiguration der Serverebene, z.B. die Website- und Anwendungspooldefinitionen, in der applicationHost.config-Datei der Serverebene ablegen. Diese Datei kann ebenfalls die Standardkonfiguration für andere IIS-Abschnitte enthalten, die standardmäßig von


Übersicht über das Konfigurationssystem 69

allen Websites des Servers geerbt werden. Im Gegensatz zu den web.config-Dateien einer Website, auf die der Website- oder Anwendungsadministrator zugreifen kann, ist ein Zugriff auf applicationHost.config nur durch den Serveradministrator möglich. Mithilfe der vom Konfigurationssystem angebotenen Konfigurationssperrmechanismen kann der Administrator festlegen, welche Konfiguration durch die Anwendungen unter Verwendung der verteilten web.config-Dateien modifiziert werden kann.

Insgesamt betrachtet bietet die neue Konfigurationsdateihierarchie sehr viel mehr Flexibilität als die IIS 6.0-Metabasis. Außerdem unterstützte sie wichtige Bereitstellungs- und Verwaltungsszenarien. Wir werden nun einen Blick auf die Arbeitsweise der Konfigurationsdateihierarchie und die Syntax der Konfigurationsabschnitte werfen.

KonfigurationsdateihierarchieDie Metabasis von früheren IIS-Versionen bestand aus einer einzelnen Konfigurationsdatei, Metabase.xml, die eine auf URLs basierende hierarchische Konfigurationsstruktur enthielt. Die Knoten dieser Struktur entsprachen URLs auf dem Server, und jeder Knoten enthielt einen Satz Eigenschaften, der zusammen mit den von den übergeordneten Knoten geerbten Eigenschaften die Konfiguration dieses URLs festlegte. Wenn Sie mit der IIS 6.0-Metabasis vertraut sind, wissen Sie vielleicht noch, dass diese Knoten über Pfade referenziert wurden, die ein ähnliches Erscheinungsbild wie das folgende aufwiesen: LM\W3SVC\1\ROOT (damit ist das Stammverzeichnis der Website mit der ID 1 gemeint).

Bei IIS 7.0 umfasst die Konfigurationsdateihierarchie mehrere Konfigurationsdateien. Anstatt also die gesamte URL-Hierarchie in einer einzelnen Datei abzubilden, stellt die Konfigurationsdateihierarchie die URL-Hierarchie dar. Jede Datei definiert eine Konfiguration, die, ausgehend von der Position dieser Datei in der Konfigurationshierarchie, implizit mit einer bestimmten URL-Ebene verknüpft ist. ApplicationHost.config enthält beispielsweise globale Einstellungen, die auf alle Sites des Servers angewendet werden, und die web.config-Datei im Stammverzeichnis der Website ist sitespezifisch – wenn sie sich in einem Anwendungsverzeichnis befindet, ist sie verzeichnisspezifisch. Web.config ist in der Regel einem URL wie http://www.contoso.com/appfolder zugeordnet. Beachten Sie, dass web.config optional verteilte Konfigurationsinformationen enthalten kann (für bestimmte Einstellungen ist dies standardmäßig der Fall). ApplicationHost.config kann site- und anwendungsspezifische Einstellungen enthalten, und dies ist auch oft so. Es gibt weitere Konfigurationsdateien, die ebenfalls mit IIS 7.0 zu tun haben und die wir später in diesem Kapitel behandeln werden. Aus Gründen der Einfachheit werden wir uns jedoch auf die Dateien konzentrieren, die zum Konfigurieren von Sites und Anwendungen eingesetzt werden und die in Tabelle 4.1 aufgeführt sind.

Tabelle 4.1 IIS 7.0-Konfigurationsdateien

Datei Speicherort Konfigurationspfad

machine.config %windir%\Microsoft .NET\Framework \<version>\config

MACHINE

web.config-Stammdatei %windir%\Microsoft .NET\Framework \<version>\config

MACHINE/WEBROOT

applicationHost.config %windir%\system32\ inetsrv\config

MACHINE/WEBROOT/APPHOST

Verteilte web.config-Dateien Websiteverzeichnisstruktur MACHINE/WEBROOT/APPHOST /<SiteName>/<VirtualPath>



Wie die Metabasis verwendet auch das IIS 7.0-Konfigurationssystem einen Konfigurationspfad, um die Ebene der Konfigurationshierarchie anzugeben, auf der eine bestimmte Konfigurationseinstellung vorgenommen werden soll. Diese Ebene entspricht sowohl dem URL-Namespace, für den die Konfigu-ration gilt, als auch einem Konfigurationspfad, der in Verbindung mit Befehlen (z.B. Appcmd) benutzt wird, um den richtigen Konfigurationsspeicher zu referenzieren. Auf diese Weise ist die IIS 7.0-Konfigu-rationsdateihierarchie dem URL-Namespace zugeordnet und verweist gleichzeitig auf die jeweilige Konfigurationsdatei, in der die entsprechende Konfiguration gespeichert ist.

Wenn das Konfigurationssystem die Konfiguration für einen bestimmten Konfigurationspfad abruft, verbindet es die Inhalte aller Konfigurationsdateien, die den jeweiligen Abschnitten des Pfades zuge-ordnet sind, zu einer Einheit, so dass für diesen Pfad ein gültiger Konfigurationssatz entsteht. Deshalb ist es möglich, web.config-Dateien anzugeben, die sich verteilt in der Verzeichnisstruktur der Website befinden. Auf diese Weise kann jeder Teil der Website eine bestimmte Konfiguration für seinen URL-Namespace festlegen, indem diese Konfiguration in einer web.config-Datei des entsprechenden Verzeichnisses abgelegt wird.

In diesem System lautet der Konfigurationspfad eines bestimmten URLs MACHINE/WEBROOT/APPHOST/<SiteName>/<VirtualPath>, wobei <SiteName> der Name der Site und <VirtualPath> der virtuelle Pfad des URLs ist. Wenn der Server die Konfiguration für diesen Pfad liest, verbindet er die Konfigurationen in machine.config, der web.config-Stammdatei, applicationHost.config und allen verteilten web.config-Dateien, die sich, ausgehend vom Stammverzeichnis der Site, in den physi-kalischen Verzeichnissen befinden, die den jeweiligen Abschnitten des virtuellen Pfades entsprechen.

Wichtig Die web.config-Stammdatei, die innerhalb des Konfigurationssystems WEBROOT entspricht, befindet sich in %windir%\Microsoft .NET\Framework \<version>\config. Sie sollte nicht mit einer web.config-Datei verwech-selt werden, die im Stammverzeichnis einer Website angeordnet ist und oft als Webstamm bezeichnet wird. Im ers-ten Fall ist die web.config-Datei gemeint, die von .NET verwendet wird und der Parent oder Stamm der web.config-Dateien aller Websites ist. Im zweiten Fall ist die web.config-Datei gemeint, die sich im Stammordner einer Website befindet. Die web.config-Datei im Stammverzeichnis einer Website erbt die Konfigurationseinstellungen, die sich in der von .NET verwendeten web.config-Stammdatei befinden.

Die für die IIS-Features geltenden Konfigurationen der Serverebene sind in der Datei application-Host.config gespeichert. Diese Datei speichert nur die Konfigurationen solcher Abschnitte, die global auf den gesamten Server angewendet werden können, sowie Konfigurationsstandards für andere Ab-schnitte, die von allen URLs auf dem Server geerbt werden, sofern nicht eine andere Datei, die sich innerhalb der Konfigurationshierarchie auf einer niedrigeren Ebene befindet, die Einstellungen dieser Abschnitte außer Kraft setzt.

Wollen Sie beispielsweise den Server so konfigurieren, dass das Durchsuchen von Verzeichnissen standardmäßig deaktiviert ist, platzieren Sie diese Konfiguration in der Datei applicationHost.config. Soll dann das Durchsuchen von Verzeichnissen für eine Anwendung namens /App1, die sich in der Standardwebsite befindet, erlaubt werden, legen Sie im physikalischen Stammverzeichnis der Anwen-dung eine web.config-Datei mit einer Konfiguration ab, die dieses Durchsuchen zulässt. Wenn eine Anforderung eingeht, die sich auf den Stamm der Standardwebsite bezieht, liest der Server die Konfiguration für den Pfad MACHINE/WEBROOT/APPHOST/Default Web Site/ und wendet die von applicationHost.config geerbte Konfiguration an, die das Durchsuchen von Verzeichnissen deaktiviert. Wenn jedoch eine auf die Anwendung bezogene HTTP-Anforderung eingeht, liest der Server die



Konfiguration für MACHINE/WEBROOT/APPHOST/Default Web Site/App1/, so dass auch der Konfigurationssatz einbezogen wird, der sich in der web.config-Datei der Anwendung befindet und der das Durchsuchen von Verzeichnissen für diesen URL aktiviert.

machine.config und die web.config-StammdateiObwohl machine.config und die web.config-Stammdatei .NET Framework-Konfigurationsdateien sind, werden sie im IIS-Konfigurationssystem abgebildet und von diesem gelesen. IIS 7.0 verfügt deshalb über die folgenden Möglichkeiten: Es kann seine Konfiguration zusammen mit der ASP.NET-Konfi-guration in den web.config-Dateien der Sites und Anwendungen verwahren, es kann innerhalb der verwalteten Pipeline .NET-Module nutzen, und es kann die .NET-Konfiguration in den IIS-Manager integrieren. Wie bereits erwähnt wurde, enthält machine.config computerweit gültige .NET Frame-work-Konfigurationseinstellungen, die von allen .NET-Anwendungen des Computers geladen werden, und die web.config-Stammdatei enthält spezifische ASP.NET-Konfigurationseinstellungen, die von allen ASP.NET-Anwendungen geladen werden. Diese Dateien können nur von Computeradministra-toren modifiziert werden.

Diese Dateien befinden sich in %windir%\Microsoft .NET\.NET Framework \<version>\config, wo <version> von der managedRuntimeVersion-Einstellung für den Anwendungspool festgelegt wird, in dem die Konfiguration gelesen wird. Deshalb enthalten IIS-Anwendungspools, die so eingerichtet sind, dass sie verschiedene Versionen des .NET Frameworks verwenden, automatisch die Konfigurations-dateien für die jeweils richtige .NET Framework-Version. Beachten Sie, dass ein Anwendungspool, genauso wie bei IIS 6.0, nicht mehr als eine Version des .NET Frameworks hosten kann.

applicationHost.configDie IIS-Hauptkonfigurationsdatei ist applicationHost.config, die sich im Verzeichnis %windir%\sys-tem32\inetsrv\config befindet. Sie kann nur von Computeradministratoren modifiziert werden.

ApplicationHost.config enthält nur solche Konfigurationsabschnitte und Einstellungen, die global für den gesamten Server sinnvoll sind. Sie enthält beispielsweise im Abschnitt <sites> die Definitionen der Sites, Anwendungen und virtuellen Verzeichnisse und im Abschnitt <applicationPools> die Anwendungs-pooldefinitionen. Andere globale Einstellungen finden sich im Konfigurationsabschnitt <globalModules>, der eine Liste der von allen IIS-Arbeitsprozessen geladenen systemeigenen Module enthält, und im Abschnitt <httpCompression>, der aktivierte Komprimierungsschemata und komprimierbare Inhaltstypen auflistet. Diese Abschnitte können auf den unteren Ebenen nicht überschrieben werden. Der Server liest sie nur auf der Ebene MACHINE/WEBROOT/APPHOST.

ApplicationHost.config speichert außerdem alle Standardeinstellungen für die IIS-Konfigurations-abschnitte, die von allen anderen URLs geerbt werden, bis andere Konfigurationsdateien, die sich innerhalb der Konfigurationshierarchie weiter unten befinden, diese Einstellungen außer Kraft setzen. Wenn Sie die Inhalte von applicationHost.config untersuchen, werden Sie feststellen, dass diese Datei in Wirklichkeit sogar alle IIS-Konfigurationsabschnitte deklariert. <configSections> <sectionGroup name="system.applicationHost"> <section name="applicationPools" allowDefinition="AppHostOnly" overrideModeDefault="Deny" /> <section name="sites" allowDefinition="AppHostOnly" overrideModeDefault="Deny" /> <section name="webLimits" allowDefinition="AppHostOnly" overrideModeDefault="Deny" /> …



</sectionGroup> <sectionGroup name="system.webServer"> <section name="asp" overrideModeDefault="Deny" /> <section name="caching" overrideModeDefault="Allow" /> <section name="cgi" overrideModeDefault="Deny" /> <section name="defaultDocument" overrideModeDefault="Allow" /> <section name="directoryBrowse" overrideModeDefault="Allow" /> … </sectionGroup> </configSections>

Sie haben vielleicht bemerkt, dass diese Abschnittsdefinitionen ein Element namens allowDefinition enthalten, das in unserem Beispiel auf AppHostOnly gesetzt wird. Die Einstellung allowDefinition weist dem Abschnitt einen Gültigkeitsbereich zu, der festlegt, wo der Abschnitt verwendet werden kann. In diesem Fall kann der Abschnitt Sites nur in applicationHost.config benutzt werden und ist an anderen Orten nicht zulässig. Sie sollten die allowDefinition-Standardeinstellungen auf keinen Fall ändern.

Schließlich enthält diese Datei ebenfalls Informationen darüber, welche Konfigurationsabschnitte auf niedrigeren Konfigurationsebenen außer Kraft gesetzt werden dürfen. Die Außerkraftsetzung auf unter-geordneten Ebenen (Childebenen) wird wie im vorherigen Beispiel gezeigt mit dem overrideModeDefault-Attribut der Konfigurationsabschnittsdeklaration gesteuert. Der Serveradministrator kann dieses Attribut benutzen, um das Delegieren von IIS-Features an Siteadministratoren zu kontrollieren. Wir werden uns mit dem Delegieren von Abschnitten später in diesem Kapitel im Abschnitt »Konfigurationsdelegierung« beschäftigen.

Verteilte web.config-DateienDie IIS 7.0-Konfigurationshierarchie trägt dazu bei, dass die Siteverzeichnisstruktur web.config-Konfigurationsdateien enthalten kann. Diese Dateien können neue Konfigurationseinstellungen festlegen oder solche Konfigurationseinstellungen außer Kraft setzen, die auf der Serverebene für den URL-Namespace gesetzt sind, der dem Verzeichnis entspricht, in dem sich die Dateien befinden (vorausgesetzt, die verwendeten Konfigurationsabschnitte wurden vom Administrator nicht gesperrt).

Dies ist die Grundlage für das Delegierungskonfigurationsszenario, bei dem Anwendungen die erforderlichen IIS-Einstellungen zusammen mit den Anwendungsinhalten verwahren können und das die einfache xcopy-Bereitstellung ermöglicht.

Da außerdem das ASP.NET-Konfigurationssystem diese Dateien ebenfalls liest, können sie sowohl IIS- als auch ASP.NET-Konfigurationseinstellungen enthalten.

redirection.configSie finden im Verzeichnis %windir%\system32\ inetsrv\config ebenfalls redirection.config. Die Datei wird benutzt, um Konfigurationseinstellungen für die freigegebene Konfiguration zu speichern. Sie ist nicht Teil der IIS 7.0-Konfigurationshierarchie, aber das Konfigurationssystem verwendet sie, um für die Datei applicationHost.config Umleitungen einzurichten.

Wenn sie benutzt wird, legt sie die Positions- und Zugriffsinformationen fest, die von IIS 7.0 benötigt werden, um applicationHost.config von einem Remoteort im Netzwerk aus zu laden, anstatt das lokale Verzeichnis inetsrv\config zu verwenden. Auf diese Weise können mehrere IIS 7.0-Server eine zentrale Konfigurationsdatei gemeinsam nutzen, was die Verwaltung vereinfacht. Weitere Informationen zur freigegebenen Konfiguration finden Sie später in diesem Kapitel im Abschnitt »Eine Konfiguration für mehrere Server«.



administration.configNur der IIS-Manager nutzt administration.config (ebenfalls nicht Bestandteil der IIS 7.0-Konfigura-tionshierarchie), um seine eigene Konfiguration festzulegen. Auch diese Datei befindet sich im Verzeichnis %windir%\system32\ inetsrv\config.

Zusätzlich zu anderen Informationen enthält administration.config die Liste der zu ladenden IIS-Manager-Erweiterungen. Diese Erweiterungen stellen die Features zur Verfügung, die Sie im IIS-Manager sehen. Wie IIS ist auch der IIS-Manager vollständig erweiterbar. Sie erfahren im zwölften Kapitel, »Verwalten von Webservermodulen«, mehr über das Erweiterbarkeitsmodell und die Konfiguration der Erweiterungen des IIS-Managers.

Temporäre .config-Dateien für AnwendungspoolsEines der neuen IIS 7.0-Features ist die erweiterte Anwendungspoolisolation. IIS 7.0 liest zur Laufzeit die applicationHost.config-Konfiguration und erzeugt daraus jeweils eine gefilterte Kopie für jeden Anwendungspool, die wie folgt gespeichert wird:

%systemdrive%\inetpub\temp\appPools\<ApplicationPoolName>.config

Die gefilterten Konfigurationsdateien enthalten nur die Anwendungspooldefinitionen für den jewei-ligen Anwendungspool (andere Anwendungspooldefinitionen, auch solche für benutzerdefinierte Anwendungspools, werden aussortiert). Weiterhin werden alle Sitedefinitionen und sitespezifischen Konfigurationen entfernt, die sich in den location-Tags solcher Sites befinden, die im jeweiligen Anwendungspool über keine Anwendungen verfügen.

Die für jeden Anwendungspool erzeugte temporäre Konfigurationsdatei ist dahingehend geschützt, dass sie nur von dem Anwendungspool gelesen werden kann, für den sie angelegt wurde. Dies gewährleistet, dass kein Arbeitsprozess (Anwendungspool) die Konfigurationseinstellungen eines anderen Arbeitsprozesses lesen kann.

Die Anwendungspoolkonfigurationsdateien sind nicht für die Verwendung im Rahmen von Updates vorgesehen, und weder Administratoren noch Entwickler sollten sie direkt oder indirekt bearbeiten. Ihr Einsatz bleibt vollständig transparent, ist aber Teil des Konfigurationssystems, weshalb wir sie an dieser Stelle erwähnt haben. Weitere Informationen erhalten Sie im vierzehnten Kapitel, »Implementieren von Sicherheitsstrategien«.

KonfigurationsdateisyntaxJede Konfigurationsdatei verwendet spezielle XML-Elemente, um Konfigurationsinformationen anzugeben. Diese Elemente werden als Konfigurationsabschnitte bezeichnet. Ein Konfigurations-abschnitt ist die grundlegende Konfigurationseinheit, die in der Regel das Verhalten eines bestimmten Teils oder Features des Webservers definiert.

Nachfolgend ist ein Beispiel für eine Konfigurationsdatei aufgeführt, die mehrere Konfigurations-abschnitte angibt:<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <asp> <cache diskTemplateCacheDirectory="%SystemDrive%\inetpub\temp\ ASP Compiled Templates" />



</asp> <defaultDocument enabled="true"> <files> <add value="index.html" /> <add value="default.aspx" /> </files> </defaultDocument> <directoryBrowse enabled="false" /> </system.webServer> <configuration>

Wie Sie sehen, handelt es sich hierbei um eine wohlgeformte XML-Datei mit einem zwingend erforderlichen <configuration>-Stammelement, das mehrere Unterelemente enthält. Diese Unterelemente sind entweder direkte Konfigurationsabschnittselemente oder Abschnittsgruppenelemente, wie z.B. <system.webServer>. Abschnittsgruppenelemente legen keine Einstellungen fest. Sie fassen lediglich verwandte Abschnittselemente zu einer Gruppe zusammen. Alle IIS-Webserverfeatures befinden sich beispielsweise in der Abschnittsgruppe <system.webServer>. Abschnitte sind die Elemente, die bestimmte Konfigurationseinstellungen enthalten (und in Fettschrift dargestellt sind).

Jedes Konfigurationsabschnittselement richtet sich nach einer bestimmten Struktur, die von seinem jeweiligen Schema definiert wird. Dieses Schema kontrolliert die Attribute, Childelemente und Datentypen, die innerhalb der Abschnitte zulässig sind, sowie verschiedene andere Beschränkungen der Konfigurationssyntax. Die Schemainformationen befinden sich in Konfigurationsschemadateien, die beim IIS 7.0-Konfigurationssystem registriert sind. Im Gegensatz zum ASP.NET-Konfigurations-system, das Code benutzt, um die Struktur seiner Konfiguration zu definieren, basiert das IIS 7.0-Konfigurationssystem vollständig auf deklarativen Schemainformationen. Wir werden diesen Schemamechanismus später in diesem Kapitel untersuchen.

Zusätzlich zu Abschnittsgruppen und den Konfigurationsabschnitten selbst können Konfigurations-dateien auch Abschnittsdeklarationen und location-Tags enthalten. Abschnittsdeklarationen sind notwendig, weil sie einen bestimmten Abschnitt deklarieren, bevor er verwendet werden kann. Sie zeigen außerdem an, zu welcher Abschnittsgruppe ein Abschnitt gehört. location-Tags tragen dazu bei, dass die Gültigkeit einer Konfiguration auf einen bestimmten Konfigurationspfad beschränkt werden kann, anstatt für den gesamten Namespace, dem die aktuelle Konfigurationsdatei entspricht, zu gelten.

Direkt von der Quelle: Beschränkungen der Größe von web.config-Dateien umgehenDas IIS 7.0-Konfigurationssystem legt standardmäßig eine Grenze von 100 KB für die Größe von web.config-Dateien fest. Dies geschieht aus Sicherheitsgründen, um eventuelle DoS-Angriffe (Denial-of-Service) auf den Server zu unterbinden, die durch die Bereitstellung sehr großer Konfigurationsdateien ermöglicht werden.

In den meisten Fällen und Situationen sollte diese Größe genügen, doch wie gehen Sie vor, wenn Ihre Konfigurationsdatei größer als 100 KB ist? Dies kann bei Anwendungen geschehen, die web.config-Dateien intensiv nutzen, um benutzerdefinierte Konfigurationen zu speichern. Um derart große Dateien zuzulassen, können Sie die Begrenzung außer Kraft setzen, indem Sie der Windows-Registrierung einen Schlüssel hinzufügen. Erzeugen Sie den folgenden Schlüssel:HKLM\Software\Microsoft\InetStp\Configuration



AbschnittsdeklarationenJeder in einer Konfigurationsdatei verwendete Abschnitt wird in applicationHost.config mit einer Abschnittsdeklaration deklariert. Abschnittsdeklarationen werden im Allgemeinen während der Installation des jeweiligen Features generiert und müssen normalerweise nicht manuell hinzugefügt werden. Nachfolgend ist beispielsweise ein Auszug aus der applicationHost.config-Konfigurations-datei aufgeführt, der alle IIS-Konfigurationsabschnitte deklariert: <configSections> <sectionGroup name="system.applicationHost"> <section name="applicationPools" allowDefinition="AppHostOnly" overrideModeDefault="Deny" /> <section name="sites" allowDefinition="AppHostOnly" overrideModeDefault="Deny" /> </sectionGroup> <sectionGroup name="system.webServer"> <section name="asp" overrideModeDefault="Deny" /> <section name="defaultDocument" overrideModeDefault="Allow" /> <section name="directoryBrowse" overrideModeDefault="Allow" /> <sectionGroup name="security"> <sectionGroup name="authentication"> <section name="anonymousAuthentication" overrideModeDefault="Deny" /> <section name="basicAuthentication" overrideModeDefault="Deny" /> </sectionGroup> <section name="authorization" overrideModeDefault="Allow" /> </sectionGroup> </sectionGroup> </configSections>

Dieses Fragment definiert mehrere IIS-Konfigurationsabschnitte, einschließlich der Abschnitte <sites> und <applicationPools>, die von WAS gelesen werden, und verschiedene Abschnitte für die Webserver-features, zu denen auch <asp> und <anonymousAuthentication> zählen. Wie Sie sehen, sind diese Abschnitte in den entsprechenden Abschnittsgruppen verschachtelt. Abschnittsdeklarationen können verschiedene Eigenschaften festlegen, die kontrollieren, wo der Abschnitt verfügbar ist. Zu diesen Eigenschaften zählen auch allowDefinition, die bestimmt, auf welcher Ebene der Konfigurationshierarchie der Abschnitt verwendet werden kann, und overrideModeDefault, die festlegt, ob untere Konfigurationsebenen den Abschnitt standardmäßig verwenden können. Nachdem der Abschnitt deklariert wurde, kann er in der aktuellen Konfigurationsdatei oder auf den Konfigurationsdateiebenen darunter verwendet werden, so dass er dort nicht neu deklariert werden muss (eine erneute Deklaration des Abschnitts würde sogar zu einem Konfigurationsfehler führen). Tatsächlich sind alle IIS-Konfigurationsabschnitte in applica-tionHost.config deklariert und somit in jeder web.config-Konfigurationsdatei einer Website verfügbar. Die Attribute allowDefinition und overrideModeDefault kontrollieren die Möglichkeit, diese Konfigurations-abschnitte auf den unteren Ebenen zu verwenden.

Erstellen Sie anschließend den folgenden DWORD-Wert:MaxWebConfigFileSizeInKB

Setzen Sie den Wert auf die gewünschte Dateigröße in Kilobyte (achten Sie darauf, dass Sie für die Eingabe des Wertes die Option Dezimal wählen), damit dies die neue computerweit gültige Grenze für die web.config-Dateigröße wird.



AbschnittsgruppenSie benutzen Abschnittsgruppenelemente, um verwandte Konfigurationsabschnitte in Gruppen zusammenzufassen. Wenn Sie einen Abschnitt deklarieren, geben Sie an, welcher Abschnittsgruppe er zugeordnet ist, indem Sie sein <section>-Element innerhalb des entsprechenden <sectionGroup>-Elements anordnen. Auf diese Weise wird die Abschnittsgruppe selbst implizit deklariert. Abschnittsgruppen können keine Attribute definieren und enthalten somit keine eigenen Konfigurationsinformationen. Abschnittsgruppen können ineinander verschachtelt sein, Abschnitte nicht. Stellen Sie sich Abschnitts-gruppen als eine Namespacekennung für Abschnitte vor.

Wenn Sie die Konfigurationsabschnitte angeben, müssen Sie sie der jeweiligen Deklaration gemäß innerhalb des entsprechenden Abschnittsgruppenelements anordnen. Wenn Sie beispielsweise die Konfiguration für den Abschnitt <authorization> festlegen, der in der Abschnittsgruppe <system.webServer>/<security> deklariert ist, muss der Konfigurationsabschnitt wie folgt in den entsprechenden Abschnitts-gruppenelementen verschachtelt sein:<configuration> <system.webServer> <security> <authorization bypassLoginPages="true" /> </security> </system.webServer> </configuration>

Tabelle 4.2 führt die meisten Abschnittsgruppen auf, die Sie standardmäßig im IIS 7.0-Konfigurations-system finden. Sie gibt außerdem Aufschluss darüber, welche Konfigurationen die Abschnittsgruppen enthalten und wo deren Deklaration erfolgt.

Tabelle 4.2 Abschnittsgruppen

Abschnittsgruppen Beschreibung Deklariert in

system.applicationHost Enthält globale protokollneutrale IIS-Konfigurationen, die vom Windows-Prozessaktivierungsdienst verwendet werden, ein-schließlich <sites>, <applicationPools>, <listenerAdapters> usw.

applicationHost.config

system.webServer Enthält alle Konfigurationen für die IIS-Webserverengine und -features, einschließlich <modules>, <handlers>, <serverRun-time>, <asp>, <defaultDocument> und viele weitere; enthält außerdem mehrere untergeordnete (Child) Abschnittsgruppen


system.webServer /security Enthält sicherheitsbezogene Webserverkonfigurationen, ein-schließlich <authorization>, <isapiCgiRestriction>, <requestFilte-ring> und weitere


system.webServer /security /authentication

Enthält Konfigurationen für alle Webserverfeatures, die sich auf die Authentifizierung beziehen, einschließlich <anonymous-Authentication>, <windowsAuthentication> und weitere




Die in der machine.config-Datei von .NET deklarierten Abschnittsgruppen sind aus Platzgründen in Tabelle 4.2 nicht aufgeführt. Diese Abschnitte steuern verschiedene Aspekte des .NET Framework-Verhaltens. Zu ihnen zählen system.net, system.xml.serialization usw.

AbschnitteDer Abschnitt configuration ist der Mittelpunkt des IIS 7.0-Konfigurationssystems, da er die grund-legende Konfigurationseinheit darstellt. Jeder Konfigurationsabschnitt besitzt eine bestimmte Struktur, die durch sein Schema definiert wird und verschiedene Attribute, Elemente und Elementauflistungen enthält, die notwendig sind, um die für das entsprechende IIS-Feature erforderliche Konfiguration zu beschreiben.

Ein Konfigurationsabschnitt kann (abhängig vom Schema) keines oder mehrere der in Tabelle 4.3 aufgeführten Elemente enthalten.

Die meisten Konfigurationsabschnitte geben Standardwerte für alle Attribute an, die in ihrem Schema definiert sind. Diese Werte bilden die Standardkonfiguration des jeweiligen Abschnitts, sofern sie in einer Konfigurationsdatei nicht anders definiert sind (Auflistungen sind standardmäßig immer leer). Jede Konfigurationsdatei kann ein Abschnittselement angeben, um den Wert der entsprechenden Attribute explizit zu setzen oder die Auflistungen im Abschnitt zu modifizieren. Der Abschnitt kann in mehreren Konfigurationsdateien angegeben werden, so dass das Konfigurationssystem die Inhalte aller

system.webServer /tracing Enthält Konfigurationen für Webserverfeatures, die sich auf die Ablaufverfolgung beziehen, einschließlich <traceFailed-Requests> und <traceProviderDefinitions>


system.web Enthält alle ASP.NET-Konfigurationen Framework machine.config

Tabelle 4.3 Konfigurationsabschnittselemente

Element Beschreibung

Attribute Ein benanntes XML-Attribut, das einen im Schema spezifizierten Typ verwendet. Zu den unterstützten Typen zählen int, string, timespan, enumerations und andere. Attribute können mit Validierungsregeln verknüpft sein, die die zulässigen Werte eingrenzen. Sie können außerdem über zusätzliche Metadaten verfügen, z.B. Standardwerte, oder sie legen fest, ob das Attribut angegeben werden muss, wenn der Abschnitt verwendet wird.

Childelemente Untergeordnete (Child) XML-Elemente, die wiederum andere Attribute und Childelemente enthalten können

Auflistungen Eine Auflistung ist ein Childelement, das andere Childelemente enthält (in der Regel <add>, <remove> und <clear>), die dazu verwendet werden können, Konfigurationselementlisten zu erstellen. Auflistungselemente sind mit Metadaten verknüpft, die das Verhalten der Elemente definieren. Dazu zählen auch Informationen darüber, welche Attribute als Auflistungselementschlüssel dienen, in welcher Reihenfolge Auflistungsele-mente hinzugefügt werden, wenn die Auflistungen verschiedener Konfigurationsdateien miteinander verbun-den werden usw.

Tabelle 4.2 Abschnittsgruppen (Fortsetzung)

Abschnittsgruppen Beschreibung Deklariert in



Instanzen dieses Abschnitts zusammenfügt, wenn es diesen Abschnitt für einen bestimmten Konfigura-tionspfad abruft. Das Zusammenfügen von Attributen führt dazu, dass die in den höheren Konfigura-tionsebenen festgelegten Werte außer Kraft gesetzt werden. Und das Zusammenfügen von Auflistungen führt dazu, dass Auflistungselemente abhängig von der Auflistungsverwendung hinzugefügt oder entfernt werden.

Nachfolgend ist beispielsweise der Inhalt einer web.config-Datei aufgeführt, die Sie im Stamm-verzeichnis einer PHP-Anwendung ablegen könnten. Die Datei enthält die Konfiguration für den Abschnitt <defaultDocument> und legt index.php als Standarddokument fest.<configuration> <system.webServer> <defaultDocument enabled="true"> <files> <add value="index.php" /> </files> </defaultDocument> </system.webServer> </configuration>

Diese Konfiguration setzt das in applicationHost.config oder in einer web.config-Datei einer höheren Ebene festgelegte globale enabled-Attribut außer Kraft, indem sie seinen Wert auf true setzt. Sie fügt der <files>-Auflistung außerdem einen neuen Eintrag hinzu, damit index.php als Standarddokument dienen kann. Wenn Konfigurationsdateien früher in der Hierarchie andere Standarddokumenttypen in der <files>-Auflistung definiert hätten, würde die für Ihre Anwendung geltende Auflistung diese Einträge sowie den Eintrag enthalten, den wir soeben innerhalb unseres Gültigkeitsbereichs hinzugefügt haben. Wenn die übergeordneten (Parent) Konfigurationsdateien das Standarddokumentfeature durch Setzen seines enabled-Attributs auf false deaktiviert hätten, würde unsere Konfiguration diesen Wert für die Anwendung außer Kraft setzen.

Der Abschnitt »Konfigurationsbearbeitung«, den Sie später in diesem Kapitel finden, beschreibt das Festlegen der Konfiguration mithilfe von Konfigurationsabschnitten.

KonfigurationsabschnittsschemaAlle IIS-Konfigurationsabschnitte sind in der Schemadatei IIS_Schema.xml definiert, die sich im Verzeichnis %windir%\system32\inetsrv\config\schema directory befindet. Um mehr über die Syntax eines Konfigurationsabschnitts zu erfahren, können Sie dessen Schema untersuchen. Nachfolgend finden Sie beispielsweise einen Auszug aus der Schemadefinition für den Konfigurationsabschnitt <defaultDocument>: <sectionSchema name="system.webServer/defaultDocument"> <attribute name="enabled" type="bool" defaultValue="true" /> <element name="files"> <collection addElement="add" clearElement="clear" removeElement="remove" mergeAppend="false"> <attribute name="value" type="string" isUniqueKey="true"/> </collection> </element> </sectionSchema>



Das Schema enthält die Definitionen für das enabled-Attribut und die <files>-Auflistung, die wir zuvor verwendet haben, um die Standarddokumentkonfiguration festzulegen. Wie Sie sehen, enthält dieses Schema weitaus mehr Informationen, als nur die Struktur des configuration-Abschnitts – es enthält auch verschiedene Metadaten über das Format und das Verhalten von Attributen und Auflistungen, wie z.B. Informationen über die möglichen Attributtypen und darüber, welche Attribute eindeutige Schlüssel für Auflistungen sind. <defaultDocument> ist ein recht einfacher Abschnitt, weshalb er die Flexibilität von Abschnittsschemainformationen nicht gänzlich verdeutlicht. Er ist jedoch ein gutes Beispiel dafür, wie Sie die Schemainformationen nutzen können, um Konfigurationsabschnitte zu definieren und deren Verhalten zu kontrollieren.

Hinweis Wenn Sie mit der IIS-Konfiguration arbeiten, müssen Sie wahrscheinlich nie mit einem Abschnittsschema arbeiten. Wenn Sie jedoch eine Referenz für die Struktur und die Semantik von IIS-Konfigurationsabschnitten benö-tigen, sollten Sie wissen, wo sich die Schemainformationen befinden. Sie sollten niemals versuchen, die IIS-Sche-madateien zu modifizieren. Wenn Sie aber neue IIS-Features entwickeln, können Sie benutzerdefinierte Konfigura-tionsschemadateien im Verzeichnis inetsrv\config\schema veröffentlichen, um im IIS-Konfigurationssystem neue Konfigurationsabschnitte zu verwenden.

Sie finden im Verzeichnis schema ebenfalls die Dateien FX_schema.xml und ASPNET_schema.xml, die die Schemadefinitionen für die .NET Framework- und ASP.NET-Konfigurationsabschnitte enthalten.

Das IIS 7.0-Konfigurationssystem ist vollständig erweiterbar. Benutzerdefinierte Konfigurationsabschnitte, die für das IIS 7.0-Konfigurationsschema registriert sind, verfügen über eigene Schemadateien, die im Verzeichnis schema veröffentlicht sind.

location-TagsEine in einer bestimmten Konfigurationsdatei festgelegte Konfiguration wird standardmäßig auf den gesamten URL-Namespace angewendet, der dieser Datei entspricht. Die in applicationHost.config enthaltene Konfiguration wird beispielsweise auf den gesamten Server angewendet, und die Konfi-guration, die in der web.config-Stammdatei einer Site festgelegt ist, gilt für die gesamte Site (sofern sie nicht von spezifischeren web.config-Dateien außer Kraft gesetzt wird). Meistens funktioniert das auch. Manchmal ist es jedoch notwendig, eine Konfiguration auf eine bestimmte Untermenge eines URL-Namespace oder auf einen bestimmten URL anzuwenden. Tags für Konfigurationsorte (location-Tags) sind der Mechanismus, der dies ermöglicht. Dazu wird ein Konfigurationspfad angegeben, für den die gesamte Konfiguration gilt, die innerhalb eines location-Tags angegeben ist.

Hier ist ein Beispiel für den Einsatz eines location-Tags, mit dem die Gültigkeit einer Konfiguration auf eine bestimmte Website beschränkt wird: <location path="Default Web Site"> <system.webServer> <directoryBrowse enabled="true" /> </system.webServer> </location>

Wenn dieses location-Tag in applicationHost.config angegeben ist, wendet es den <directoryBrowse>-Konfigurationsabschnitt auf den Konfigurationspfad MACHINE/WEBHOST/APPHOST/Default Web Site/ an.



Bei IIS 7.0 werden location-Tags für drei übliche Szenarien verwendet:

1. Definieren sitespezifischer Verzeichnis- oder Dateikonfigurationen in applicationHost.config. Dies ist notwendig, um eine spezifische Konfiguration für einen bestimmten Inhalt einer Website zu ver-wenden, ohne diese Konfiguration in der web.config-Datei der Site zu definieren. Dies ist beispiels-weise das Verfahren, das üblicherweise von Shared-Hostingsservern genutzt wird, um sitespezifi-sche Konfigurationen festzulegen, über die der Siteadministrator keine Kontrolle haben soll. Wenn im IIS-Manager oder mit einer der programmgesteuerten Schnittstellen Änderungen an der Konfi-guration vorgenommen werden, werden nicht delegierte Einstellungen mithilfe von location-Tags in applicationHost.config geschrieben.

2. Sperren oder Entsperren eines bestimmten Konfigurationsabschnitts für einen bestimmten Konfi-gurationspfad. Wenn Sie einen Konfigurationsabschnitt innerhalb eines location-Tags für einen bestimmten Pfad platzieren, können Sie das overrideMode-Attribut des location-Tags benutzen, um die-sen Konfigurationsabschnitt für diesen Pfad zu sperren oder wieder freizugeben. Dies ist beispiels-weise für Konfigurationsabschnitte erforderlich, die mit overrideModeDefault = Deny deklariert wurden, um in web.config-Dateien die delegierte Konfiguration wieder zuzulassen.

3. Festlegen der Konfiguration eines bestimmten nicht physikalischen URLs. Wenn Sie eine bestimmte Konfiguration auf einen URL anwenden möchten, der keinem physikalischen Verzeich-nis entspricht (eine Datei oder ein virtueller URL), müssen Sie die Konfiguration innerhalb eines physikalischen übergeordneten Verzeichnisses mithilfe eines location-Tags definieren.

Sie können ein location-Tag verwenden, um die gesamte Konfiguration für eine Site oder Anwen-dung in nur einer web.config-Datei zu verwahren, anstatt Teile davon auf viele verschiedene web.config-Dateien in verschiedenen Unterverzeichnissen zu verteilen.

Wir werden später in diesem Kapitel location-Tags ausführlicher erörtern.

Das IIS 7.0-Konfigurationssystem und die IIS 6.0-MetabasisBisher haben wir uns bis zu einem gewissen Grad mit den Inhalten und der Funktionsweise des Konfigurationssystems beschäftigt. Wir sollten jedoch noch einmal ein wenig zurückgehen und applicationHost.config selbst betrachten, anstatt uns auf die Inhalte dieser Datei zu konzentrieren.

Unterschiede zwischen dem IIS 7.0-Konfigurationssystem und der IIS 6.0-MetabasisDer IIS 6.0-Konfigurationsspeicher ist Metabase.xml. Er befindet sich in %windir%\system32\inetsrv. Für IIS 7.0 wurde Metabase.xml in applicationHost.config umgewandelt. Diese Datei befindet sich in %windir%\system32\inetsrv\config.

Weshalb hat das IIS-Team derart viel Zeit und Aufwand in solch eine groß angelegte Änderung der Struktur und Funktionsweise des Konfigurationssystems investiert? Primär, um einen Durchbruch bei der Leistung, Skalierbarkeit und Verwaltbarkeit zu erzielen. Das IIS 6.0-Konfigurationssystem basiert auf einem System, das für IIS 4.0 entworfen und implementiert wurde. IIS 4.0 ist Teil von Windows NT. Es war also Zeit für einen Neuentwurf mit neuen Designkriterien.

Das resultierende System ist etwas komplexer, da es sehr anspruchsvoll ist. Gleichzeitig ist es jedoch besser verwaltbar, skalierbar und flexibler. Tabelle 4.4 führt einige wichtige Unterschiede zwischen der IIS 6.0-Metabasis und den IIS 7.0-Konfigurationsdateien auf.



Kompatibilität mit der IIS 6.0-MetabasisTrotz der umfassenden Überarbeitung des Konfigurationssystems ist IIS 7.0 auch weiterhin abwärts-kompatibel mit älteren, bereits vorhandenen und auf die Metabasis bezogenen Konfigurationsskripts und -tools, die der Konfiguration des Servers dienen.

Dies wird durch die Bereitstellung einer Metabasisemulationsschicht erreicht, die die über die ABO-Schnittstellen (Active Base Objects) offen gelegten Metabasis-APIs ermöglicht, auf denen alle anderen Metabasistools und -Scripting-APIs basieren. Die Metabasisemulationsschicht, die auch als ABO-Mapper bezeichnet wird, führt eine sofortige Übersetzung der Metabasiskonfigurationsstruktur und der von den Aufrufern initiierten Metabasisaktionen durch, so dass diese im neuen Konfigurationssystem abgebildet werden. Alle auf die Metabasis bezogenen Schreib- und Lesevorgänge werden somit der entsprechenden IIS 7.0-Konfiguration zugeordnet.

Tabelle 4.4 Metabase.xml im Vergleich mit dem IIS 7.0-Konfigurationssystem

Feature Metabase.xml von IIS 6.0 IIS 7.0-Konfigurationssystem Bedeutung

Delegierte Konfiguration Nicht möglich – die gesamte Konfiguration ist zentral gespeichert und erfordert administrative Rechte, wenn Änderungen vorgenommen werden sollen

Sowohl die durch den Administ-rator kontrollierte Konfiguration in applicationHost.config als auch die delegierte Konfiguration in web.config-Dateien sind möglich

Administratoren können Konfigura-tionsaufgaben an Anwendungs-besitzer delegieren; Anwendungen können zusammen mit der gesamten Konfiguration per xcopy bereitgestellt werden

Struktureller Aufbau Eigenschaften sind nicht gruppiert

Stellt eine aus Abschnittsgruppen, Abschnitten, Elementen und Unterelementen bestehende Hierarchie zur Verfügung

Einfach zu lesen, zu durchsuchen und zu verwalten; Ermöglicht die Ver-wendung kürzerer Elementnamen, da alle Einträge in Abschnitten logisch gruppiert sind und nicht einfach nur aufgelistet werden

Vereinfachte Beschreibung von Eigenschaften mit mehreren Werten

Verwendet Multi-SZ- Schlüsseltypen und Bit-masken, um mit mehreren Elementwerten, wie z.B. AuthenticationProviders (NT) umgehen zu können

Verwendet Auflistungen mit einer einfachen add/remove/clear-Syn-tax, die auf der .NET Framework-Konfigurationssyntax und -ver-wendung basiert

Die Einstellungen können einfacher gelesen, bearbeitet und abgefragt werden und über mehrere Werte verfügen

Arbeitsspeicherbasierte Konfiguration im Vergleich mit dateibasierter Konfiguration

Die Metabasis ist ein Speicherkonstrukt, das in Metabase.xml geschrieben wird; Synchronisierungs-probleme können auftreten

Die Konfiguration ist dateibasiert; Konfigurationsänderungen werden direkt in die Konfigurationsdateien übernommen

Die IIS-Konfiguration ist immer voll-ständig in .config-Dateien abgebildet

Schemaerweiterbarkeit Für benutzerdefinierte Anwendungen schwierig zu erweitern; verhindert Innovationen von Seiten der Community

Basiert auf IIS_Schema.xml; das Schema kann einfach mithilfe von XML erweitert werden

Anwendungsentwickler können Anwendungseinstellungen einfacher in IIS 7.0 integrieren



Diese Dienstleistung bleibt für den Aufrufer transparent, so dass die bereits vorhandenen Installer, Konfigurationsskripts und -tools auch weiterhin so arbeiten, als würden sie unter IIS 6.0 ausgeführt. Der ABO-Mapper unternimmt jede Anstrengung, um alle IIS 6.0-Metabasiseigenschaften den entsprech-enden IIS 7.0-Konfigurationseigenschaften zuzuordnen. Letztendlich können fast alle Metabasiseigen-schaften der IIS 7.0-Konfiguration zugeordnet werden. Es gibt nur sehr wenige Ausnahmen.

Hinweis Sie finden unter der folgenden Adresse eine Dokumentation, die beschreibt, wie IIS 6.0-Metabasiseigen-schaften dem neuen IIS 7.0-Konfigurationsschema zugeordnet werden: http://msdn2.microsoft.com/en-us/library/aa347565.aspx.

Die Kompatibilität mit der Metabasis ist standardmäßig nicht aktiviert, und Sie benötigen sie auch nicht, wenn Sie keine alten IIS 6.0-Konfigurationsskripts ausführen oder Installer von Drittanbietern verwenden möchten, die ABO erfordern. Ist dies jedoch Ihr Wunsch, müssen Sie die Komponente für die Kompatibilität mit der IIS 6.0-Metabasis installieren. Sie wählen sie unter Windows Vista über die Systemsteuerung und die Gruppe Programme und Funktionen und schließlich auf der Seite Windows-Funktionen ein- oder ausschalten aus. Dort befindet sie sich in der Kategorie IIS/Metabasiskompa-tibilität. Wenn Sie mit Windows Server 2008 arbeiten, wählen Sie die Komponente im Server-Manager und dort in der IIS-Rolle aus, wie in Abbildung 4.2 dargestellt.

Abbildung 4.2 Installieren der IIS 6.0-Metabasiskompatiblität mit dem Server-Manager

Sie können auch die alten IIS 6.0-Konfigurationsskripts aus der Kategorie IIS 6.0-Metabasiskompa-tibilität heraus installieren. Sie erhalten dann Skripts wie adsutil.vbs und iisweb.vbs. Wir empfehlen Ihnen jedoch, die neuen, vom IIS 7.0-Konfigurationssystem angebotenen Konfigurationstools und -APIs für Ihre Konfigurationsskripts und Programme zu benutzen.



IIS 7.0 und die .NET-KonfigurationssystemeDie .NET-Konfigurationsdateien (machine.config, die web.config-Stammdatei und die web.config-Dateien von Anwendungen) verhalten sich unter IIS 7.0 genauso wie unter IIS 6.0. Eigentlich weiß das .NET-Konfigurationssystem gar nicht, dass es unter IIS 7.0 ausgeführt wird, und es liest auch keine der IIS 7.0-Konfigurationseinstellungen. IIS 7.0 hingegen ist sich der Anwesenheit von .NET bewusst. Die IIS 7.0-Konfigurationshierarchie enthält die .NET-Konfigurationsdateien der Serverebene, machine.config und die web.config-Stammdatei (zusätzlich zu applicationHost.config), aber das .NET-Konfigurationssystem berücksichtigt nicht die in applicationHost.config gespeicherte IIS-Konfiguration.

Einer der primären Vorteile dieses Designs ist, dass IIS 7.0-Konfigurationseinstellungen in denselben verteilten web.config-Konfigurationsdateien wie die ASP.NET-Konfigurationseinstellungen gespei-chert werden können. Dadurch wird es möglich, dass Anwendungen in den web.config-Dateien die Konfigurationen verwahren können, die sie benötigen, um auf der IIS-Plattform ausgeführt zu werden. Außerdem wird die einfache xcopy-Bereitstellung möglich.

Aus der Entwicklerperspektive betrachtet ist es außerdem möglich, dass die für IIS 7.0 entwickelten verwalteten Module unter Verwendung der IIS 7.0-Klasse Microsoft.Web.Administration und anderer .NET-Klassen genauso auf die .NET-Konfiguration zugreifen, wie sie dies mit den IIS 7.0-Konfigurations-abschnitten tun. Ähnlich hierzu können die IIS 7.0-Konfigurations-APIs verwendet werden, um in Szenarien, in denen die automatisierte Bereitstellung und Verwaltung zum Einsatz kommt, die .NET-Konfigurationsabschnitte zu verwalten.

Darüber hinaus bietet das IIS-Manager-Tool viele ASP.NET-Konfigurationsfeatures an. Sie können beispielsweise im IIS-Manager Datenbankverbindungszeichenfolgen konfigurieren und müssen dazu nicht die entsprechende .config-Datei öffnen. Der IIS-Manager ermöglicht es Ihnen außerdem, Benutzer und Rollen mithilfe des .NET-Rollen- und -Mitgliedschaftsanbieters zu verwalten. Dies ist sehr nützlich, wenn Benutzerinformationen für Features wie die Formularauthentifizierung verwaltet und IIS-Manager-Benutzer gespeichert werden müssen. Im sechsten Kapitel, »Verwenden von IIS-Manager«, erfahren Sie mehr über die Unterstützung von ASP.NET-Features im IIS-Manager.

Die Vereinheitlichung der .NET- und IIS 7.0-Konfigurationshierarchien führt zu einigen wenigen Problemen, deren Ursache darin besteht, dass die beiden Konfigurationssysteme unterschiedlich implementiert sind, aber mit derselben Konfigurationshierarchie und denselben Konfigurations-abschnitten arbeiten. Die Tatsache, dass das ASP.NET-Konfigurationssystem keine IIS 7.0-Konfigu-rationsabschnitte liest, schließt viele potentielle Probleme mit Verhaltensunterschieden aus. Einige Probleme bleiben jedoch auch weiterhin bestehen.

Die Ursache für eine der wichtigsten Einschränkungen sind die unterschiedlichen Verschlüsselungs-verfahren der beiden Konfigurationssysteme. Die .NET-Konfigurationsdateien können Benutzernamen und Kennwörter enthalten, die der Entwickler verschlüsselt hat. Wenn Sie eine solche .config-Datei betrachten, sehen Sie eine verschlüsselte Zeichenfolge anstelle von Klartext. Das Problem ergibt sich, weil IIS 7.0 und das .NET-Konfigurationssystem verschiedene Verfahren zur Verschlüsselung von Informationen verwenden. Das .NET-Konfigurationssystem unterstützt die Verschlüsselung auf der Abschnittsebene, so dass der gesamte Inhalt eines Konfigurationsabschnitts verschlüsselt wird. Das IIS 7.0-Konfigurationssystem unterstützt lediglich die Verschlüsselung auf der Attributebene, so dass nur bestimmte Attribute verschlüsselt werden. Deshalb erhalten Sie einen Fehler, wenn Sie versuchen, einen verschlüsselten ASP.NET-Konfigurationsabschnitt über das IIS 7.0-Konfigurationssystem oder eine der APIs zu lesen, die dieses System nutzen. Dies geschieht beispielsweise, wenn Sie einen der Konfigurationsabschnitte verschlüsseln, die der IIS-Manager benutzt, um die ASP.NET-Funktionalität zu verwalten. Ähnlich hierzu können Sie mit der IIS 7.0-Konfigurationsverschlüsselung keine



ASP.NET-Konfigurationsabschnitte verschlüsseln, da ASP.NET deren Inhalte nicht lesen könnte. Weitere Informationen zu diesem Problem und dessen Lösung erhalten Sie im vierzehnten Kapitel. Die Ursache einer weiteren Einschränkung ist ein Versionsproblem mit den .NET-Konfigurations-schemadateien, die vom IIS 7.0-Konfigurationssystem zur Verfügung gestellt werden. Zur Drucklegung dieses Buches bot das IIS 7.0-Konfigurationssystem lediglich Schemadateien für die .NET Framework 2.0-Konfiguration an, weshalb IIS 7.0 mit Problemen konfrontiert werden kann, wenn es eine Konfi-guration in eine Konfigurationsdatei für das .NET Framework 1.1 oder zukünftige Versionen des .NET Frameworks schreibt. Darüber hinaus können einige Tools des IIS 7.0-Konfigurationstacks nur dann in .NET Framework-Konfigurationsdateien schreiben, wenn es sich um die Framework-Version 2.0 handelt. Dazu zählt auch Appcmd.exe. Zukünftige IIS-Versionen werden dieses Problem möglicher-weise lösen.

Der Einsatz der IIS 7.0-Konfiguration in web.config-Dateien für ASP.NET kann ebenfalls zu einem Problem für solche ASP.NET-Anwendungen führen, die das .NET Framework 1.1 nutzen. Der Grund hierfür besteht darin, dass sich das ASP.NET-Konfigurationssystem nicht der IIS 7.0-Konfigurations-abschnitte bewusst ist, die sich in der Abschnittsgruppe <system.webServer> befinden (oder in benutzer-definierten Konfigurationsabschnitten, die Sie mithilfe der IIS 7.0- Abschnittserweiterung erstellt haben). Das Konfigurationssystem generiert einen Fehler, wenn es in web.config-Dateien auf diese Abschnitte trifft. ASP.NET 2.0 verwendet in machine.config eine spezielle Konfigurationsdeklaration, die <system.webServer> einem speziellen Konfigurationsabschnittshandlertyp zuordnet, der die Abschnitte ignoriert, wenn sie gefunden werden.<section name="system.webServer" type="System.Configuration.IgnoreSection, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

ASP.NET 1.1 enthält diese spezielle Konfigurationsdeklaration jedoch nicht, weil es veröffentlicht wurde, lange bevor die IIS 7.0-Entwicklung begann. Deshalb müssen Sie die Abschnittsdeklaration für <system.webServer> und andere benutzerdefinierte IIS 7.0-Abschnitte/-Abschnittsgruppen möglicherweise manuell hinzufügen, so dass Sie sie in web.config-Dateien verwenden können.

KonfigurationsbearbeitungDas IIS 7.0-Konfigurationssystem ist sehr flexibel, wenn es um die Bearbeitung der Serverkonfigura-tion geht. Da die Konfiguration im Klartext und in XML-Dateien gespeichert wird und eine gut strukturierte und für Menschen lesbare Syntax verwendet, können Sie sie mit Notepad oder Ihrem Lieblings-Texteditor manuell bearbeiten. Viele Menschen bevorzugen diese Vorgehensweise bei der Bearbeitung von Konfigurationen in verteilten web.config-Dateien, die sich innerhalb der Verzeichnis-struktur einer Site befinden.

Zusätzlich zur manuellen Konfigurationsbearbeitung bietet IIS 7.0 einen vollständigen Verwaltungs-stack an, der Tools und APIs für die Bearbeitung von Konfigurationen bereithält. Dazu zählt der IIS-Manager, ein gänzlich überarbeitetes, aufgabenbasiertes Programm mit einer grafischen Benutzer-oberfläche für die Verwaltung des größten Teils der IIS 7.0-Konfiguration. Dazu zählt ebenfalls das Befehlszeilentool Appcmd, mit dem Sie die Konfiguration schnell von der Befehlszeile aus bearbeiten können. Und dazu zählen auch mehrere administrative Skripts und APIs für die programmgesteuerte Konfigurationsbearbeitung, einschließlich der COM-Konfigurationsobjekte von IIS 7.0, auf die von nativen C++-Programmen aus zugegriffen werden kann (sie werden als Anwendungshostverwaltungs-objekte oder AHADMIN [Application Host Administration] bezeichnet), Windows-Skripts, eines WMI-Anbieters und neuer APIs für die von .NET-Programmen ausgehende Verwaltung der Konfiguration.


Konfigurationsbearbeitung 85

Hinweis Sie sollten wenn möglich Tools zur Bearbeitung der IIS 7.0-Konfiguration verwenden und diese nicht manuell ändern. Dies ist sehr viel einfacher und schützt davor, eine falsche Konfiguration zu erstellen.

Sie sollten auch für die Bearbeitung der Serverkonfiguration Tools verwenden, da dies gewährleistet, dass Sie mit dem zugrunde liegenden komplexen Konfigurationssystem auf die richtige Art und Weise interagieren und dass die Konfiguration unter Verwendung der richtigen Syntax geschrieben wird. Hierfür bietet sich der IIS-Manager an, da er eine vereinfachte aufgabenbasierte Ansicht vieler IIS 7.0-Features zur Verfügung stellt, so dass Sie deren Konfigurationsstruktur nicht verstehen müssen. Das Verwalten von IIS 7.0 mit dem IIS-Manager ist im sechsten Kapitel beschrieben.

Es gibt jedoch Situationen, in denen Sie eine Konfiguration manuell oder unter Verwendung maschinennaher Tools angeben müssen. Zu diesen Tools zählen Appcmd und programmgesteuerte Schnittstellen wie der von .NET zur Verfügung gestellte Namespace Microsoft.Web.Administration. In diesen Fällen müssen Sie die Struktur der Konfigurationsabschnitte und die Vererbung innerhalb der Konfigurationshierarchie verstehen, um auf die richtige Art und Weise vorgehen zu können. Der verbleibende Abschnitt beschäftigt sich mit den Grundlagen der IIS 7.0-Konfigurationsbearbeitung, damit Ihnen hierbei keine Fehler unterlaufen.

Hinweis Benutzen Sie in solchen Situationen, in denen der IIS-Manager die gewünschte Konfigurationsfunktio-nalität nicht anbietet, Appcmd zur Konfigurationsbearbeitung. Appcmd beherrscht die meisten Konfigurationsauf-gaben, die Sie auch durch eine manuelle Konfigurationsbearbeitung ausführen lassen können. Darüber hinaus bietet es den Vorteil einer zusätzlichen Validierung. Es erlaubt Ihnen außerdem, Konfigurationsaufgaben auf ande-ren Computern automatisch ausführen zu lassen, sofern Sie dies wünschen. Weitere Informationen zum Einsatz von Appcmd finden Sie im siebten Kapitel, »Verwenden von Befehlszeilentools«.

Vorsicht Bevor Sie die Konfiguration modifizieren, sollten Sie darauf achten, dass Sie den aktuellen Zustand gesichert haben, so dass Sie später gegebenenfalls zu diesem Zustand zurückkehren können. Lesen Sie später in diesem Kapitel den Abschnitt »Sichern der Konfiguration«, um weitere Informationen zum einfachen Sichern und Wiederherstellen der IIS-Konfiguration zu erhalten.

Auswahl des KonfigurationsortsIn diesem Kapitel wurde bereits die IIS 7.0-Konfigurationshierarchie beschrieben. Diese Hierarchie besteht aus mehreren Konfigurationsdateien, zu denen die .NET-Konfigurationsdateien, applica-tionHost.config und die in der Verzeichnisstruktur Ihrer Site verteilten web.config-Dateien zählen. Diese Hierarchie ermöglicht es Ihnen, eine Konfiguration einem URL-Namespace auf Ihrem Server zuzuordnen, indem Sie sie in der richtigen Konfigurationsdatei platzieren. Wenn der Server die Konfi-guration für eine bestimmte Website oder einen bestimmten URL liest, fügt er alle Konfigurations-dateien entlang des Konfigurationspfades zusammen. Dadurch werden die in den Dateien festgelegten Konfigurationen miteinander verbunden, um den für den gegebenen Pfad geltenden Konfigurationssatz zu erhalten.

Das Zusammenfügen der Konfigurationen führt dazu, dass eine am Anfang des Konfigurationspfades festgelegte Konfiguration immer an alle folgenden Pfade vererbt wird, sofern sie dort nicht außer Kraft gesetzt wird. Die in applicationHost.config festgelegte Konfiguration wird beispielsweise an alle Sites und URLs des Servers vererbt, bis sie in den entsprechenden web.config-Dateien außer Kraft gesetzt wird.



Tabelle 4.5 gibt Aufschluss darüber, wo Sie eine Konfiguration ablegen können, damit sie auf den gewünschten Gültigkeitsbereich angewendet wird.

Wenn Sie eine Konfiguration für eine bestimmte Site oder einen bestimmten URL angeben, können Sie wählen, ob Sie die Konfigurationen dem URL entsprechend in einer verteilten web.config-Datei oder aber in einer Konfigurationsdatei ablegen, die sich auf einer höheren Hierarchieebene befindet (z.B. applicationHost.config). Im zweiten Fall wenden Sie die Konfiguration mithilfe von location-Tags auf den gewünschten URL an. Beide Vorgehensweisen gehen mit Vor- und Nachteilen einher, die Sie überdenken sollten.

Wenn Sie mit location-Tags arbeiten, können Sie die gesamte Konfiguration an nur einem Ort ver-wahren, anstatt mehrere web.config-Konfigurationsdateien zu verwenden, die schwieriger aufzuspüren und zu verwalten sind. Wenn außerdem die Konfiguration an einer bestimmten Stelle des Konfigura-tionspfades gesperrt ist (Konfigurationen, die nur von Administratoren bearbeitet werden sollen, werden beispielsweise in der Regel in applicationHost.config gesperrt), sind Sie gezwungen, an dieser Stelle location-Tags zu benutzen, um Konfigurationen auf untergeordnete Pfade anzuwenden. Das Platzieren von Konfigurationen in verteilten web.config-Dateien hingegen trägt dazu bei, dass eine Site, Anwendung oder ein Verzeichnis portierbar wird und mithilfe von xcopy auf anderen Servern oder an anderen Orten innerhalb der Sitestruktur bereitgestellt werden kann, ohne an anderer Stelle eine Konfiguration ändern oder auf dem Server über administrative Rechte verfügen zu müssen. Dies ist eine sehr nützliche Option.

Zuletzt ein Hinweis zur Konfigurationsdelegierung – nicht alle Konfigurationsabschnitte dürfen standard-mäßig in verteilten web.config-Dateien angegeben werden. Der Serveradministrator bestimmt, welche Konfigurationsabschnitte delegiert werden dürfen, indem er sie in applicationHost.config freigibt. Dies kann negative Auswirkungen haben, wenn Sie Anwendungen ausführen lassen möchten, deren Konfi-guration sich in verteilten web.config-Dateien befindet. Würde in diesem Fall eine gesperrte Konfiguration angegeben, führte dies zu Fehlern. Wir werden uns mit der Verwaltung der Konfigurationsdelegierung später in diesem Kapitel im Abschnitt »Konfigurationsdelegierung« beschäftigen.

Konfigurationen festlegenUm eine Konfiguration festzulegen, benötigen Sie drei Informationen: den Namen des Abschnitts, der die gewünschte Konfigurationseinstellung enthält, die gewünschte Eigenschaft dieses Abschnitts und den Konfigurationspfad, auf den Sie die Einstellung anwenden möchten (wie im vorherigen Abschnitt beschrieben). Die ersten beiden Daten erhalten Sie in der Regel aus der Dokumentation zu dem Feature, das

Tabelle 4.5 Ablageorte für Konfigurationen

Konfiguration für Ablegen in

den gesamten Server applicationHost.config

eine bestimmte Site web.config-Datei im physikalischen Stammverzeichnis der Site

eine bestimmte Anwendung web.config-Datei im physikalischen Stammverzeichnis der Anwendung

ein bestimmtes virtuelles Verzeichnis web.config-Datei im physikalischen Stammverzeichnis des virtuellen Verzeichnisses

einen bestimmten URL Wenn der URL einem physikalischen Verzeichnis entspricht, in der web.config-Datei dieses Verzeichnisses; andernfalls in einer beliebigen übergeordneten web.config-Datei mit einem location-Tag für den URL



Sie konfigurieren möchten. Weitere Informationen zu den verfügbaren Konfigurationsabschnitten und deren Format finden Sie in den Schemadateien im Verzeichnis %windir%\system32\inetsrv\config\schema.

Wenn Sie diese Informationen kennen, können Sie in der Konfigurationsdatei das entsprechende Abschnittselement angeben.<configuration> <system.webServer> <defaultDocument … /> </system.webServer> <configuration>

Beachten Sie das Element <configuration> – dies muss immer das Stammelement jeder Konfigurations-datei sein. Beachten Sie ebenfalls das Element <system.webServer> – dies ist das Abschnittsgruppenelement des hier konfigurierten <defaultDocument>-Abschnitts (und aller anderen IIS 7.0-Konfigurationseinstel-lungen).

Konfigurationsabschnitte enthalten die Eigenschaften, die Sie konfigurieren können, wie z.B. defaultDocument. Das bloße Angeben eines Namens genügt jedoch nicht. Sie schalten das Standard-dokumentfeature ein oder aus und geben die Liste der Standarddokumente mithilfe der Attribute oder Auflistungselemente an, die dem Abschnitt zugeordnet sind.

Abschnittsattribute festlegenDie meisten Konfigurationseinstellungen werden mit Attributen ausgedrückt, die entweder vom Auflistungselement selbst oder von einem der untergeordneten Auflistungselemente zur Verfügung gestellt werden.

Um einen Wert für das Attribut anzugeben, setzen Sie diesen einfach. Dadurch wird ein möglicherweise vorhandener Standardwert oder ein Wert, auf den das Attribut früher im Konfigurationspfad gesetzt wurde, außer Kraft gesetzt. Nachfolgend ist ein Beispiel aufgeführt, das den enabled-Wert des <defaultDocument>-Abschnitts setzt.<defaultDocument enabled="true" />

Jedes Attribut ist von einem bestimmten Typ und kann mit zusätzlichen Validierungsregeln verknüpft sein, die in der Schemadefinition des Abschnitts definiert sind. Darüber hinaus können Attributen Standardwerte zugewiesen sein, die verwendet werden, wenn die Attribute in der Konfiguration nicht explizit auf andere Werte gesetzt werden. Dies ist für jeden Abschnitt dokumentiert, um Sie dabei zu unterstützen, die Attributwerte zu setzen.

Arbeiten mit KonfigurationsauflistungenZusätzlich zu Attributen können Konfigurationsabschnitte ebenfalls Auflistungen enthalten. Auf-listungen tragen dazu bei, dass ganze Elementlisten in einer Konfiguration verwendet werden können. Sie bieten außerdem zusätzliche Funktionen, wie z.B. das Hinzufügen oder Entfernen von Elementen auf mehreren Konfigurationsebenen. Darüber hinaus verhindern sie, dass Elemente doppelt hinzugefügt werden.

Auflistungen werden in der Regel mithilfe von drei verschiedenen Operationen konfiguriert: Hinzufügen von Auflistungselementen, Entfernen von Auflistungselementen und Löschen der gesamten Auflistung.



Hinzufügen von Elementen zu einer Auflistung mit <add />Um einer Auflistung Elemente hinzuzufügen, verwenden Sie normalerweise das Element <add /> und geben darin die gewünschten Attributwerte an. Nachfolgend ist beispielsweise ein Auszug aus der <files>-Auflistung des <defaultDocument>-Abschnitts von applicationHost.config aufgeführt, wie er sich nach der Installation präsentiert: <defaultDocument enabled="true"> <files> <add value="Default.htm" /> <add value="Default.asp" /> … </files> </defaultDocument>

In diesem Fall verwenden die Elemente in der <files>-Auflistung nur ein einzelnes Attribut namens value. Auflistungselemente sind jedoch nicht auf nur ein Attribut beschränkt – sie können beliebig viele Attribute, untergeordnete Elemente und selbst Unterauflistungen definieren. Tatsächlich verfügt jedes Auflistungselement sogar über dieselbe Schemaflexibilität wie jedes andere Konfigurationselement oder der Abschnitt selbst. Nachfolgend ist ein Beispiel aus dem <sites>-Abschnitt aufgeführt: <sites> <site name="Default Web Site" id="1"> <application path="/"> <virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" /> </application> <bindings> <binding protocol="http" bindingInformation="*:80:" /> </bindings> <traceFailedRequestsLogging enabled="true" /> </site> </sites>

Der Abschnitt <sites> ist eine Auflistung von <site>-Elementen (beachten Sie, dass er <site> als Namen für sein <add>-Element verwendet – dies ist eine vom IIS-Konfigurationsschema angebotene Möglichkeit, die aus Gründen der besseren Lesbarkeit von einigen Abschnitten genutzt wird). Jedes <site>-Element wiederum ist eine aus <application>-Elementen bestehende Auflistung, die ebenfalls eine aus <virtualDirectory>-Elementen bestehende Auflistung enthält. Jedes <site>-Element verfügt außerdem über ein untergeordnetes <bindings>-Element, das selbst eine aus Sitebindungen bestehende Auflistung ist. Im neunten Kapitel, »Verwalten von Websites«, finden Sie eine detaillierte Beschreibung der neuen Struktur von Sites, Anwendungen und virtuellen Verzeichnissen.

Glücklicherweise ist der <sites>-Abschnitt einer der kompliziertesten Abschnitte des gesamten IIS 7.0-Konfigurationsschemas. Die meisten anderen Abschnitte sind sehr viel einfacher.

Die meisten Auflistungen lassen nur eindeutige Elemente zu, um zu vermeiden, dass Elemente doppelt hinzugefügt werden. Dazu wird eines oder werden einige der Attribute des <add>-Auflistungselements als Auflistungsschlüssel gekennzeichnet. Wenn ein Eintrag mit einem Schlüssel angegeben wird, der bereits vorhanden ist, löst die Auflistung einen Konfigurationsfehler aus, sobald der Zugriff darauf erfolgt.

Wenn Sie auf einer bestimmten Konfigurationsebene Auflistungselemente hinzufügen, werden diese den bereits vorhandenen, von einer übergeordneten Ebene geerbten Elementen hinzugefügt. Der <defaultDocument>-Abschnitt kann dies beispielsweise nutzen, um in applicationHost.config einen Basissatz Standarddokumente anzugeben und dann auf der Ebene der Site oder des virtuellen Ver-zeichnisses spezifische Standarddokumente hinzuzufügen.



Die Reihenfolge der Auflistungselemente innerhalb einer Auflistung wird durch die Reihenfolge bestimmt, in der die Elemente hinzugefügt werden. Wenn Auflistungselemente von übergeordneten Konfigurationsebenen geerbt werden, werden sie vor den Auflistungselementen angeordnet, die auf der aktuellen Ebene angegeben sind. Dies gilt für die meisten Auflistungen, außer für diejenigen, die mit einer Stackreihenfolge arbeiten – diese Auflistungen platzieren die auf der aktuellen Ebene deklarierten Elemente vor den Elementen, die von übergeordneten Ebenen geerbt wurden. Dazu zählen z.B. der IIS-Abschnitt <handlers> und der ASP.NET-Abschnitt <authorization>.

Entfernen von Elementen aus einer Auflistung mit <remove />Aufgrund der Auflistungsvererbung ist es manchmal notwendig, Elemente zu entfernen, die auf einer höheren Konfigurationsebene deklariert wurden. Sie könnten beispielsweise für eine bestimmte Anwendung ein bestimmtes Modul aus der Konfigurationsauflistung <mdoules> entfernen, wenn die Ausführung dieses Moduls nicht notwendig ist. Weitere Informationen zur Verwaltung von Modulen finden Sie im zwölften Kapitel.

Hinweis Wenn Sie ein Auflistungselement entfernen möchten, das auf der aktuellen Konfigurationsebene hinzu-gefügt wurde, können Sie einfach das entsprechende <add>-Element löschen. Benutzen Sie <remove>, um Elemente zu entfernen, die auf höheren Konfigurationsebenen angegeben wurden.

Um dies zu tun können Sie das <remove>-Element benutzen. Jedes <remove>-Element gibt die Attribute an, die zusammen den Auflistungsschlüssel beschreiben, der das zu entfernende Element eindeutig identifi-ziert. Nachfolgend ist beispielsweise die Konfiguration aufgeführt, die Sie benutzen können, um Default.asp aus der <files>-Auflistung des <defaultDocument>-Abschnitts zu entfernen: <defaultDocument> <files> <remove value="Default.asp" /> </files> </defaultDocument>

Löschen von Auflistungen mit <clear />Manchmal möchten Sie die auf den übergeordneten Konfigurationsebenen definierten Auflistungs-elemente vollständig löschen und nur die benötigten Elemente angeben. Dies ist oft der Fall, wenn die aktuelle Konfigurationsebene die vollständige Kontrolle über die Inhalte der Auflistung benötigt und übergeordnete Elemente nicht erben darf.

Dies wird mit dem Element <clear/> erreicht. Das <clear/>-Element entfernt alle geerbten Auflistungs-elemente, so dass nur die Elemente übrig bleiben, die auf der aktuellen Ebene hinter dem <clear/>-Element hinzugefügt werden. Das folgende Beispiel löscht die Standarddokumentauflistung und fügt dann ein einzelnes Element hinzu, um sicherzustellen, dass nur Default.aspx als Standarddokument behandelt wird: <defaultDocument> <files> <clear/> <add value="Default.aspx" /> </files> </defaultDocument>



Wichtig Lassen Sie bei der Arbeit mit dem <clear/>-Element Vorsicht walten, da es die Vererbung von übergeord-neten Auflistungselementen an die aktuelle Konfigurationsebene oder deren untergeordneten Ebenen vollständig unterbindet. Dies bedeutet, dass, wenn der Administrator auf der Serverebene neue Auflistungselemente hinzufügt, diese nicht an die aktuelle Ebene weitergegeben werden. Benutzen Sie <clear/> deshalb nur dann, wenn Sie die vollständige Kontrolle über die Inhalte der Auflistung benötigen.

Konfigurationsfehler verstehenIm Gegensatz zu IIS 6.0 stellen die zugrunde liegenden Konfigurationssystem-APIs sicher, dass sich in die Konfiguration keine Fehler einschleichen, wenn sie mit Tools wie dem IIS-Manager und Appcmd oder programmgesteuert mit APIs wie Microsoft.Web.Administration bearbeitet wird. Versuche, eine fehlerhafte Konfiguration zu erzeugen, wie z.B. die Verwendung von Daten des falschen Typs für Attributwerte, der Versuch, nicht existierende Attribute zu setzen, oder der Einsatz von Daten, die außerhalb des zulässigen Wertebereichs liegen, werden somit abgefangen. Sogar das erneute Hinzufügen eines bereits vorhandenen Auflistungselements und der Versuch, eine auf einer übergeordneten Konfigurationsebene gesperrte Konfiguration anzugeben, werden verhindert. Aus diesem Grund sollten Sie immer die angebotenen Tools nutzen und nicht den manuellen Weg gehen, um eine Konfiguration anzugeben.

Hinweis Benutzen Sie die Tools, um Konfigurationen festzulegen – die meisten Fehler werden dadurch abgefan-gen, so dass Sie keine fehlerhafte Konfiguration generieren können.

Dennoch werden Sie manchmal in Situationen geraten, die zu einer fehlerhaften Konfiguration führen. Dies ist besonders dann möglich, wenn Sie die Konfiguration manuell bearbeiten und Ihnen bei der Abschnittsyntax Fehler unterlaufen oder Sie Attribute auf nicht unterstützte Werte setzen. Es ist jedoch auch in anderen Fällen möglich – z.B. wenn eine Anwendung, die eine Konfiguration definiert, auf einem Server bereitgestellt wird, der einige der verwendeten Abschnitte auf der Serverebene sperrt, was zu einer Sperrverletzung führen würde.

Deshalb ist es wichtig, die Ursachen für verschiedene Konfigurationsfehler zu verstehen und die daraus resultierenden Konfigurationsfehlerinformationen zu nutzen, um die Probleme zu lösen.

Vorsicht Führen Sie immer eine Sicherung der Konfiguration durch, bevor Sie Änderungen daran vornehmen. Später in diesem Kapitel im Abschnitt »Sichern der Konfiguration« erfahren Sie mehr über die Konfigurations-sicherung.

Es gibt verschiedene Arten von Konfigurationsfehlern, die vom Konfigurationssystem unterschiedlich behandelt werden und unterschiedliche Auswirkungen auf IIS haben. Tabelle 4.6 fasst einige der üblichen Fehlerursachen und die Auswirkungen dieser Fehler auf den Server zusammen.

Um die Ursachen für diese Fehler verstehen zu können, müssen Sie wissen, wie das Konfigurations-system Fehler behandelt. Fehler, die dazu führen, dass die gesamte Konfigurationsdatei nicht verfügbar ist, weil sie nicht gelesen werden kann oder unzulässigen XML-Code enthält (wie in Abbildung 4.3 dargestellt), unterbinden alle Versuche, eine Konfiguration aus dieser Datei zu lesen. Aus diesem Grund würden alle Operationen, für die ein Lesen der Datei notwendig wäre, fehlschlagen. Wenn es sich bei der Datei um applicationHost.config handelt, die von der IIS-Komponente für die IIS-Arbeitsprozess-verwaltung (der Windows-Prozessaktivierungsdienst) gelesen wird, wird der gesamte Server in den Offline-Zustand versetzt. In diesem Fall erhalten Sie keine detaillierte Anforderungsfehlermeldung, die



die Fehlerursache beschreibt, da der Server keine IIS-Arbeitsprozesse zur Bedienung der Anforderung starten kann. In diesem Fall werden die Fehlerinformationen von WPAS im EventLog-Protokoll des Systems protokolliert.

Wenn die Datei eine verteilte web.config-Datei ist, die einem bestimmten URL-Namespace entspricht, ist dieser Namespace nicht verfügbar. Die IIS-Arbeitsprozesse können jedoch gestartet werden und eine detaillierte Konfigurationsanforderungsfehlermeldung generieren, die die Ursache beschreibt und manchmal sogar die Position innerhalb der Datei nennt, an der der Fehler auftrat.

Bei allen anderen Fehlern in Konfigurationsabschnitten, die zulässigen XML-Code enthalten, schlagen nur die Zugriffe auf die betroffenen Abschnitte fehl. Wenn sich der Fehler in einem der von WPAS gelesenen system.applicationHost-Konfigurationsabschnitte befindet, z.B. in <sites> oder <applicationPools>, kann WPAS möglicherweise auch in diesem Fall keinen IIS-Arbeitsprozess starten, so dass der gesamte Server in den Offline-Zustand versetzt wird und Fehler im EventLog-Protokoll des Systems proto-kolliert werden. Wenn sich der Fehler in einem der bei jeder Anforderung gelesenen IIS-Kernkonfigura-tionsabschnitte befindet, z.B. <serverRuntime>, <modules> und <handlers>, geben alle Anforderungen, die sich auf den der unzulässigen Konfiguration entsprechenden URL-Namespace beziehen, Konfigurations-

Tabelle 4.6 Übliche Fehlerbedingungen

Fehler Auswirkung

Konfigurationsdatei enthält unzulässigen XML-Code

Wenn es sich um die machine.config-Datei des Frameworks, die web.config-Stammdatei oder die applicationHost.config-Datei von IIS 7.0 handelt: Der gesamte Server wird in den Offline-Zustand versetzt.Andernfalls: Alle URLs, die der Konfigurationsdatei und den Ebenen darunter entsprechen, geben Konfigurationsfehler zurück.

Zugriff auf Konfigurationsdatei ist nicht möglich: Die Datei wird von einem anderen Prozess blockiert, Zugriffsverweigerung, keine Netzwerkkonnektivität für UNC-Pfade

Wenn es sich um die machine.config-Datei des Frameworks, die web.config-Stammdatei oder die applicationHost.config-Datei handelt: Der gesamte Server wird in den Offline-Zustand versetzt.Andernfalls: Alle URLs, die der Konfigurationsdatei und den Ebenen darunter entsprechen, geben Konfigurationsfehler zurück.

Syntaxfehler im Konfigurationsabschnitt: Der Konfigurationsabschnitt enthält unerwartete Elemente oder Attribute, oder es fehlen Attribute, die angegeben werden müssen

Wenn sich der Fehler in einem der von WPAS gelesenen system.applica-tionHost-Konfigurationsabschnitte befindet, kann der Server in den Offline-Zustand versetzt werden.Wenn sich der Fehler in einem der Kernwebserverabschnitte befindet, geben alle Anforderungen, die sich auf die von den Fehlern betroffenen URLs beziehen, Konfigurationsfehler zurück.

Andernfalls geben Anforderungen, die solche Features nutzen, die den jeweiligen Konfigurationsabschnitt lesen, Konfigurationsfehler zurück.

Attributvalidierungsfehler: Es gibt einen unzu- lässigen Datentypen; die Überprüfung eines Werts anhand der Validierungsregeln schlägt fehl

Wie oben

Auflistungsvalidierungsfehler: Es gibt doppelt vorhandener Auflistungselemente.

Wie oben

Sperrverletzung: Angeben der Konfiguration eines Abschnitts oder Attributs, der/das auf einer über- geordneten Ebene gesperrt ist

Wie oben



fehler zurück. Diese Fehler geben exakt Aufschluss über den Grund für den fehlgeschlagenen Konfi-gurationszugriff. Dazu zählen auch Details wie die Zeilennummer und das Element oder Attribut, das die fehlerhafte Konfiguration aufweist, wie in Abbildung 4.4 dargestellt. Sie können diese Infor-mationen nutzen, um den Ort des Konfigurationssyntaxfehlers schnell ausfindig zu machen und das Problem zu lösen.

Abbildung 4.3 EventLog-Fehler, dessen Ursache unzulässiger XML-Code in applicationHost.config ist

Abbildung 4.4 IIS 7.0-Konfigurationsfehlermeldung


Konfigurationsverwaltung 93

Hinweis Um die ausführliche Konfigurationsfehlermeldung zu sehen, müssen Sie dem Server entweder eine lokale Anforderung übergeben oder ausführliche Fehlermeldungen aktivieren.

Für alle anderen Abschnitte gilt, dass nur die Anforderungen, die das Feature mit der fehlerhaften Konfiguration nutzen, Anforderungsfehler auslösen. Dies bedeutet ebenfalls, dass, wenn Ihnen ein Fehler in der Konfiguration eines nicht genutzten Features unterläuft (das Modul ist beispielsweise deaktiviert), keine Fehlermeldung ausgegeben und die unzulässige Konfiguration ignoriert wird.

Wenn sich der Fehler schließlich in einem ASP.NET-Konfigurationsabschnitt befindet, der von ASP.NET unter Verwendung des .NET-Konfigurationssystems gelesen wird, wird wahrscheinlich eine ASP.NET-Ausnahmefehlerseite angezeigt, die die Details zum Konfigurationsfehler enthält.

Hinweis Um ausführliche Informationen zu einer ASP.NET-Konfigurationsausnahme zu erhalten, müssen Sie dem Server entweder eine lokale Anforderung übergeben oder ausführliche ASP.NET-Fehlermeldungen aktivieren.

KonfigurationsverwaltungJe länger Sie mit der IIS-Konfiguration arbeiten, desto wahrscheinlicher ist es, dass Sie viele ver-schiedene Verwaltungsaufgaben lösen und die Konfiguration selbst bearbeiten müssen. Sie müssen deshalb insbesondere die Konfiguration sichern und wiederherstellen können, um bei unbeabsichtigten Änderungen oder beschädigten Konfigurationsdateien in der Lage zu sein, wieder zum ursprünglichen Zustand zurückzukehren. Dies ist sehr wichtig, da die Einfachheit, die mit der Bearbeitung der XML-Konfigurationsdateien von IIS einhergeht, dazu führt, dass sich schnell unerwünschte Änderungen einschleichen.

Wenn Sie mit der IIS-Konfiguration arbeiten, sollten Sie immer darauf achten, eine Sicherung zu erstellen, die Sie benutzen können, um zu dem Zustand vor den Änderungen zurückzukehren. Glück-licherweise sorgt IIS dafür, dass dies sehr einfach ist.

In diesem Abschnitt untersuchen wir die Verwaltungsaufgaben, die sich auf das Sichern und Wieder-herstellen der IIS-Konfiguration beziehen. Wir beschäftigen uns außerdem mit der Einrichtung einer von mehreren Servern gemeinsam genutzten Konfiguration und der Konfigurationsdelegierung, mit der es möglich ist, einen Teil der Konfiguration in verteilten web.config-Konfigurationsdateien anzugeben.

Sichern der KonfigurationBevor Sie Änderungen an den IIS-Konfigurationsdateien vornehmen, sollten Sie diese sichern. Sie können sie dann später wiederherstellen, falls Ihre Änderungen die Konfiguration beschädigt oder zu falschen Serveroperationen geführt haben. Der zweite Grund ist sehr wichtig – der Server scheint zunächst richtig zu arbeiten und erst später treten Probleme auf. Dann möchten Sie in der Regel zum vorherigen Konfigurationszustand zurückkehren.

Gewöhnlich ist es nicht notwendig, spezielle Vorkehrungen zu treffen, um eine delegierte Konfiguration zu sichern, die sich in den web.config-Dateien Ihrer Websitestruktur befindet. Diese Dateien werden schließlich zusammen mit Ihren Siteinhalten gesichert (dazu müssen Sie natürlich Sicherungen von Ihren Siteinhalten anfertigen).

Wenn Sie jedoch Änderungen an den Konfigurationsdateien der Serverebene vornehmen, sollten Sie die Serverkonfiguration sichern. IIS 7.0 sorgt glücklicherweise dafür, dass dies mit dem Befehlszeilen-hilfsmittel Appcmd sehr einfach ist.



Geben Sie Folgendes an einer administrativen Eingabeaufforderung ein:

%windir%\system32\inetsrv\ AppCmd Add Backup MyBackup

Daraufhin wird eine Sicherung der IIS-Konfigurationsdateien erzeugt, zu denen applicationHost.config, redirection.config und administration.config sowie benutzerdefinierte Schemadateien zählen, sofern vorhanden. Die Sicherung wird als benanntes Verzeichnis unter %windir%\system32\inetsrv\backup erstellt. Dazu wird der Name verwendet, den Sie dem Befehl Add Backup übergeben haben. Dieses Verzeichnis wird die gesicherten Dateien enthalten.

Hinweis Wenn Sie keinen Sicherungsnamen angeben, generiert Appcmd diesen automatisch unter Verwendung des aktuellen Datums und der aktuellen Zeit.

Sie können die auf Ihrem System durchgeführten Sicherungen mithilfe des Befehls List Backups auf-listen.%windir%\system32\inetsrv\AppCmd List Backups

Danach können Sie jede der aufgelisteten Sicherungen wiederherstellen, indem Sie den Befehl Restore Backup benutzen.%windir%\system32\inetsrv\AppCmd Restore Backup "MyBackup"

Der Restore-Befehl stellt alle im Sicherungsordner enthaltenen Dateien wieder her, wobei die aktuelle Serverkonfiguration von diesen Dateien überschrieben wird. Ein Bestätigungsdialogfeld gibt es nicht, so dass Sie immer zunächst die aktuelle Konfiguration sichern sollten, bevor Sie einen anderen Sicherungssatz wiederherstellen.

Ein Hinweis zur Sicherheit und Verschlüsselung von Konfigurationsdateien: Die Sicherung kopiert die Serverkonfigurationsdateien einfach in das Verzeichnis inetsrv\backup, das standardmäßig mit denselben NTFS-Berechtigungen wie das die Originaldateien enthaltene Verzeichnis inetsrv\config gesichert ist. Wenn die Dateien verschlüsselte Konfigurationen enthalten, bleiben diese Informationen in den gesicherten Kopien ebenfalls verschlüsselt. Während der Sicherung wird somit keine zusätzliche Verschlüsselung durchgeführt. Die Dateien sind deshalb nur dann geschützt, wenn sie sich im Siche-rungsverzeichnis befinden. Es ist nicht sicher, sie ohne zusätzlichen Schutz an einem anderen Ort abzulegen.

Arbeiten mit dem KonfigurationsverlaufIIS 7.0 prüft über den Dienst AppHostSvc in Abständen von zwei Minuten, ob applicationHost.config verändert wurde. In diesem Fall wird eine Sicherung dieser Datei angelegt. Sie finden die gesicherten Konfigurationsdateien standardmäßig im Ordner Inetpub\history. Sie können im Konfigurations-abschnitt <configHistory> sowohl den Verwahrungsort der Sicherungen als auch andere konfigurierbare Parameter ändern, wie Tabelle 4.7 zeigt.

Tabelle 4.7 <configHistory>-Attribute

Attribut Standardeinstellung Definition

Enabled True Dieser Wert gibt an, ob der Konfigurationsverlauf aktiviert oder deaktiviert ist

Path %systemdrive%\inetpub\history

Der Pfad, wo Verlaufsverzeichnisse erstellt und gespeichert werden



Wenn Sie nichts anderes angeben, werden die in Tabelle 4.7 aufgeführten Werte für Sie vorkonfiguriert. Um diese Werte zu modifizieren, müssen Sie dies manuell tun, da der IIS-Manager über keine Benut-zeroberfläche zur Konfiguration des entsprechenden applicationHost.config-Abschnitts verfügt. Sie können Appcmd hierfür verwenden. Der folgende Befehl ändert beispielsweise den Pfad zum Speichern von Sicherungen in %systemdrive%\MyWebHistory. Beachten Sie, dass der Pfad bereits vorhanden sein muss, da der Dienst andernfalls nicht funktioniert.%windir%\system32\inetsrv\Appcmd set config /section:configHistory "/path:%systemdrive%\MyWebHistory"

Sie können den Appcmd-Befehl Restore Backup benutzen, um eine Konfigurationsverlaufssicherung wiederherzustellen. Dies geschieht in derselben Weise wie die Wiederherstellung von Sicherungen, die mit dem Appcmd-Befehl Add Backup manuell durchgeführt wurden. Sie können alle verfügbaren Sicherungen (sowohl manuelle als auch Konfigurationsverlaufssicherungen) wie folgt auflisten:%windir%\system32\inetsrv\AppCmd List Backups

Weitere Informationen zu configHistory finden Sie in dem englischen Artikel »Using IIS7 Configuration History« unter http://learn.iis.net/page.aspx/129/using-iis-7-configuration-history/.

Exportieren und Importieren von KonfigurationenDie IIS 7.0-Konfiguration speichert standardmäßig keine verschlüsselten Daten und ist somit nicht wie in früheren Versionen an einen bestimmten Server gebunden. Die IIS 6.0-Metabasis war an einen lokalen Server gebunden und geschützt. Der Grund hierfür bestand darin, dass sie standardmäßig die Kennwörter für den anonymen und den IWAM-Benutzer enthielt. Wären diese Kennwörter in den Besitz Außenstehender gelangt, wäre es für diese möglich gewesen, sich an den Server anzumelden. Sie waren jedoch nach dem Zufallsprinzip gewählt und sehr komplex, wodurch ein hoher Grad an Sicherheit gewährleistet war.

Bei IIS 7.0 ist der anonyme Benutzer (IUSR) ein integriertes und kein lokales Konto, so dass ein Kennwort nicht erforderlich ist. Doch keine Sorge. Obwohl es kein Kennwort gibt, können Sie dieses integrierte Konto für die Anmeldung an den Server nutzen. Es gibt keine Möglichkeit, das Konto zu benutzen, um sich lokal oder remote anzumelden. Dies ist nur über IIS möglich. Es gibt auch kein IWAM-Konto mehr, weil der IIS 5-Anwendungsisolationsmodus kein Bestandteil von IIS 7.0 ist. Da es in applicationHost.config verschlüsselte Daten standardmäßig nicht mehr gibt, ist auch eine Bindung an einen einzelnen Server nicht mehr notwendig.

Dies bedeutet, dass Sie applicationHost.config von einem Server auf einen anderen kopieren können, aber nur, wenn Sie auch die Verschlüsselungsschlüssel der Server synchronisiert haben und der Ziel-server über dieselbe Inhalts- und Verzeichnisstruktur wie der ursprüngliche Server verfügt. Sind diese Voraussetzungen erfüllt, ist es sehr einfach, Konfigurationen zwischen Servern zu importieren und zu exportieren.

maxHistories 10 Die maximale Anzahl von Verzeichnissen, die von IIS 7.0 angelegt werden

Period 00:02:00 Die Zeit zwischen den Überprüfungen, die von IIS 7.0 durchgeführt werden, um zu ermitteln, ob Änderungen durchgeführt wurden

Tabelle 4.7 <configHistory>-Attribute (Fortsetzung)

Attribut Standardeinstellung Definition



Hinweis Um die applicationHost.config-Datei eines Servers auf einem anderen Server zu verwenden, müssen Sie sicherstellen, dass die Server dieselben Konfigurationsverschlüsselungsschlüssel benutzen. Der Grund hierfür besteht darin, dass applicationHost.config Verschlüsselungssitzungsschlüssel enthält, die selbst unter Verwendung des RSA-Konfigurationsschlüssels des Servers verschlüsselt wurden. Später in diesem Kapitel im Abschnitt »Eine Konfiguration für mehrere Server« erfahren Sie mehr über das Exportieren und Importieren von Serververschlüs-selungsschlüsseln.

Wenn Ihre Konfigurationsdateien verschlüsselte Informationen enthalten, zum Beispiel Anwendungspool-IDs, sind sie an den Server gebunden, auf dem die Verschlüsselung generiert wurde. Sie können die Konfi-gurationsschlüssel jedoch exportieren und importieren, damit mehrere Server dieselben verschlüsselten Konfigurationen gemeinsam nutzen können – dies ist eine der Voraussetzungen, die für das von IIS 7.0 unterstützte Feature erfüllt sein muss, das die Arbeit mit freigegebenen Konfigurationen ermöglicht. Später in diesem Kapitel erhalten Sie weitere Informationen zum Einrichten freigegebener Konfigurationen. Eine ausführliche Erläuterung der Konfigurationsverschlüsselung hält das vierzehnte Kapitel bereit.Im Gegensatz zu IIS 6.0 bietet IIS 7.0 keinen integrierten Mechanismus zum Exportieren einzelner Sitekonfigurationen an. Dieser Mechanismus existiert lediglich für die gesamte Serverkonfiguration. In den meisten Fällen kann eine Sitekonfiguration exportiert werden, indem die Sitedefinition auf dem Zielserver neu generiert wird. Dann werden die Siteinhalte einfach kopiert. Die einzelnen Konfigura-tionen befinden sich in den web.config-Dateien, die wiederum in der Verzeichnisstruktur der Site enthalten sind.Wenn sich die Sitekonfiguration jedoch innerhalb der location-Tags von applicationHost.config befindet, gibt es für deren Export keinen automatisierten Mechanismus. Sie können natürlich die Inhalte des configuration-Tags (einschließlich aller location-Tags) einfach kopieren und am Ende einer anderen applicationHost.config-Datei einfügen. Ein automatisierter Mechanismus wird vielleicht in Zukunft verfügbar sein.

KonfigurationsdelegierungDas neue IIS 7.0-Konfigurationssystem wurde entwickelt, um eine umfassende Unterstützung der Featuredelegierung zu bieten. Dieser Begriff hat bei IIS 7.0 eine besondere Bedeutung – die Möglich-keit, Features so zu kennzeichnen, dass sie auf der Site- oder Anwendungsebene von solchen Benutzern kontrolliert werden können, die keine Serveradministratoren sind, z.B. Websiteadministratoren oder Anwendungsmanager. Wie Sie noch sehen werden, arbeitet die Featuredelegierung Hand in Hand mit der Remoteverwaltung. Sie ist außerdem in den IIS-Manager integriert, so dass Sie sie konfigurieren können und gleichzeitig die Delegierungseinstellungen berücksichtigt werden, so dass der Zugriff auf gesperrte oder eingeschränkte Features nicht oder nur bedingt möglich ist.Es gibt zwei Möglichkeiten für die Implementierung der Featuredelegierung. Erstens ermöglicht es die Konfigurationshierarchie selbst, Konfigurationen in verteilten web.config-Dateien anzugeben. Kontrolliert werden diese in der Regel vom Siteadministrator oder Anwendungsentwickler, der kein Serveradminist-rator sein muss, um die in den Dateien enthaltenen Konfigurationen festzulegen oder zu ändern. Der Serveradministrator kontrolliert, welche Konfigurationen aufgrund der Delegierung in web.config-Dateien angegeben und welche Konfigurationen nur vom Serveradministrator in applicationHost.config festge-legt werden können. Diese Kontrolle wird mithilfe der Konfigurationssperrung erreicht, die auf der Abschnittsebene möglich ist, indem in applicationHost.config ein Abschnitt gesperrt wird, die aber auch feiner abgestuft erfolgen kann, indem bestimmte Konfigurationseinstellungen innerhalb eines bestimmten Konfigurationsabschnitts gesperrt werden. Die feiner abgestufte Konfigurationssperrung ist später in diesem Kapitel im Abschnitt »Spezifische Konfigurationssperrung« ausführlich beschrieben.



Die zweite Möglichkeit wird vom IIS-Manager implementiert, der ebenfalls Konfigurationsabschnitte sperren kann und die Möglichkeit bietet, die Delegierung der zugrunde liegenden Konfiguration zu verwalten. Er stellt außerdem die entsprechenden IIS-Manager-Benutzeroberflächenfeatures zur Ver-fügung, die notwendig sind, um die Remoteverwaltung nahtlos in dieses Tool zu integrieren. Die Ver-waltung der Featuredelegierung mithilfe des IIS-Managers hat den Vorteil, dass die korrekte Konfigura-tion der Delegierung immer gewährleistet ist. Der IIS-Manager berücksichtigt die Delegierungseinstel-lungen, so dass ein Remotebenutzer versteckte Features (die im IIS-Manager mit Nicht delegiert gekennzeichnet sind) nicht sehen kann. Er kann außerdem keine Änderungen an Features vornehmen, die im IIS-Manager mit Schreibgeschützt gekennzeichnet sind.

Wichtig Jeder Benutzer, der web.config-Dateien hochladen kann, kann die darin enthaltenen IIS 7.0- und ASP.NET-Einstellungen außer Kraft setzen. Wenn Sie den IIS-Manager benutzen, um eine Konfiguration anzugeben, werden die damit verbundenen Einstellungen richtig gespeichert, und die Benutzer können nur die Konfiguration ändern, für die sie Zugriffsrechte besitzen. Wenn eine web.config-Datei außerhalb des IIS-Managers erstellt und dann in die Site hoch-geladen wird, kann sie Konfigurationseinstellungen enthalten, die von den Delegierungseinstellungen nicht akzeptiert werden. In diesem Fall präsentiert IIS 7.0 einen auf die Konfigurationssperrung bezogenen Fehler, und vorherige, korrekte web.config-Daten können verlorengehen, da die ursprüngliche web.config-Datei außer Kraft gesetzt wurde.

Wenn Sie die Kontrolle an andere Benutzer delegieren, wird für diese der Anreiz groß sein, ihre Site- oder Anwendungskonfiguration mithilfe des IIS-Managers zu kontrollieren, da er nur die Features zeigt, die die Benutzer einsehen und verwenden dürfen.Die IIS 7.0-Features beziehen sich im Allgemeinen auf die Konfigurationsabschnitte in application-Host.config. Dies wurde bereits früher in diesem Kapitel erläutert, als es um Abschnittsdefinitionen und den mit jedem Abschnitt verknüpften Wert von overrideModeDefault ging. Der IIS-Manager ist natürlich das Haupttool für die Verwaltung der Konfigurationsabschnitte, und die Delegierung ist sehr viel einfacher zu verstehen und zu verwalten, wenn der IIS-Manager verwendet wird.

Delegieren von Einstellungen mit dem IIS-ManagerLassen Sie uns die verschiedenen Einstellungen im IIS-Manager untersuchen, die sich auf die Dele-gierung beziehen. Abbildung 4.5 zeigt, was Sie sehen, wenn Sie im Hierarchielistenfeld den Server-knoten markieren und im Featurebereich Delegierung von Features auswählen.

Abbildung 4.5 Delegierung von Features im IIS-Manager



Die Spalte Delegierung listet die aktuellen Delegierungseinstellungen für jedes Feature auf. Die Namen der verschiedenen Delegierungszustände sind nicht besonders aufschlussreich, weshalb Sie sie auch nicht deuten sollten:

� Nicht delegiert Wenn ein Feature mit Nicht delegiert gekennzeichnet ist, wird der entsprechende Konfigurationsabschnitt in applicationHost.config gesperrt, indem er innerhalb eines <location>-Tags angeordnet wird, dessen overrideMode-Wert auf Deny gesetzt ist. Wenn ein Feature mit Nicht delegiert gekennzeichnet ist, werden Änderungen, die Sie auf der Serverebene (wenn also im Hierarchie-listenfeld das Serversymbol markiert ist) an dem Feature vornehmen, in applicationHost.config gespeichert. Änderungen auf der Site- oder Anwendungsebene können nur vom Serveradminist-rator durchgeführt werden und werden in applicationHost.config mithilfe eines <location>-Tags gespeichert, um sie auf den richtigen Pfad anzuwenden. Wenn Remotebenutzer den IIS-Manager verwenden, um eine Verbindung zu einer Site oder Anwendung herzustellen, können Sie das Symbol eines solchen Features nicht sehen und seine Einstellungen nicht ändern. Wenn eine web.config-Datei hochgeladen wird, die Einstellungen für ein Nicht delegiert-Feature enthält, tritt ein Konfigurationsfehler auf.

� Schreibgeschützt Dasselbe wie Nicht delegiert. Jedoch können die Remotebenutzer das jeweilige Feature sehen. Das Ändern von Werten ist aber nicht möglich. Dies ist eine nützliche Einstellung, wenn Sie die Benutzer beispielsweise wissen lassen möchten, welche Authentifizierungsverfahren zur Verfügung stehen, aber das Aktivieren bzw. Deaktivieren dieser Verfahren durch die Benutzer soll nicht möglich sein.

� Lesen/Schreiben Wenn ein Feature mit Lesen/Schreiben gekennzeichnet ist, wird der ent-sprechende Konfigurationsabschnitt für verteilte web.config-Dateien freigegeben. Dazu wird der Konfigurationsabschnitt innerhalb eines <location>-Tags platziert, dessen overrideMode-Wert auf Allow gesetzt wurde. Alle Änderungen, die Sie auf der Serverebene an diesem Feature vornehmen, werden in applicationHost.config gespeichert. Änderungen, die Sie auf der Site- oder Anwendungs-ebene vornehmen, werden in der entsprechenden web.config-Datei gespeichert. (Eine Referen-zierung der Siteebene bezieht sich auf die web.config-Datei des Stammverzeichnisses der Site. Die Anwendungsebene bezieht sich auf die web.config-Datei, die sich innerhalb der Site in einem Ordner befindet, der als Anwendung gekennzeichnet wurde.) Wenn Sie den IIS-Manager benutzen, um eine Verbindung zu einer Site oder Anwendung herzustellen, können Remotebenutzer die Einstellungen sehen und ändern.

Wenn Sie mit Erweiterungen von Drittanbietern arbeiten, kann der IIS-Manager zusätzliche Dele-gierungswerte anzeigen, die für die jeweilige Erweiterung eine spezielle Bedeutung haben.Im achten Kapitel, »Remoteverwaltung«, erhalten Sie weitere Informationen zur Konfiguration der Featuredelegierung des IIS-Managers. Sie erfahren außerdem, wie Sie ermitteln, welche Benutzer über das Recht verfügen, die Webserverkonfigurationen remote zu verwalten.

Standardeinstellungen für die delegierte KonfigurationWie bereits erwähnt wurde, werden bei IIS 7.0 einige Einstellungen standardmäßig delegiert, wohin-gegen andere ausdrücklich gesperrt sind. Tabelle 4.8 stammt aus einer vorab veröffentlichten Version des IIS 7.0 Hosting Deployment Guide, den Sie bei IIS.net finden. Die Informationen in der Tabelle verraten, welche Features aus welchem Grund delegiert sind. Sie werden hinsichtlich dieser Standard-einstellungen vielleicht zu anderen Entscheidungen als das IIS-Team gelangen. Die globalen Einstel-lungen sind jedoch gut durchdacht, weshalb Sie daran keine Änderungen vornehmen sollten, sofern Sie nicht einen guten Grund hierfür haben.



Tabelle 4.8 Feature- und Delegierungseinstellungen

Feature Delegierte Einstellung Grund

.NET-Kompilierung Schreibgeschützt

(wurde geändert, war zunächst Lesen/ Schreiben)

Legt Einstellungen für die Verarbeitungsdirektiven der ASP.NET- Kompilierung fest, wie z.B. das temporäre KompilierungsverzeichnisVerhindert, dass Benutzer das temporäre Kompilierungsverzeichnis manuell festlegen

.NET-Globalisierung Lesen/Schreiben Legt Einstellungen für die Standardkultur und Globalisierungseigen-schaften für Webanforderungen fest

.NET-Profil Lesen/Schreiben Gibt Einstellungen für die Optionen an, die in ASP.NET-Anwendungen von Benutzern ausgewählt werden

.NET-Rollen Lesen/Schreiben Gibt Einstellungen für Gruppen an, die in Verbindung mit .NET-Benut-zern und der Formularauthentifizierung verwendet werden

.NET-Vertrauensebenen Schreibgeschützt

(wurde geändert, war zunächst Lesen/ Schreiben)

Legt die Vertrauensebene fest. Wenn Sie die Vertrauensebene, wie in der ASP.NET-Anleitung des Hosting Deployment Guide-Dokuments beschrieben, sperren, setzen Sie dieses Feature auf Schreibgeschützt, so dass es für den gesamten Server gesperrt ist.

Verhindert, dass Websitebesitzer die Vertrauensebene höher als der Serveradministrator ansetzen. Wenn beispielsweise vom Administrator eine benutzerdefinierte Vertrauensebene festgelegt wurde, sollte diese Einstellung auf Schreibgeschützt gesetzt werden, damit sie nicht außer Kraft gesetzt werden kann.

.NET-Benutzer Konfiguration Lesen/Schreiben

Legt Einstellungen für die Verwaltung solcher Benutzer fest, die Rollen zugeordnet sind und die Formularauthentifizierung nutzen

Anwendungseinstellungen Lesen/Schreiben Legt Einstellungen zum Speichern von Daten (Name/Wert-Paare) fest, die zur Laufzeit von aus verwaltetem Code bestehenden Anwendungen benutzt werden

ASP Schreibgeschützt Legt klassische ASP-Einstellungen fest

ASP.NET-Identitätswechsel Lesen/Schreiben Legt Einstellungen für den Identitätswechsel fest. Sitebesitzer können diese Funktionalität nutzen, um ihre Site unter einem anderen Sicher-heitskontext ausführen zu lassen.

Anonyme Authentifizierung Schreibgeschützt Legt Einstellungen für die anonyme Authentifizierung fest

Formularauthentifizierung Lesen/Schreiben Legt Einstellungen für die Formularauthentifizierung fest

Windows-Authentifizierung Schreibgeschützt Legt Einstellungen für die Windows-Authentifizierung fest

Autorisierungsregeln Lesen/Schreiben Bestimmt die Liste der Allow- (Zulassen) und Deny- (Verweigern) Regeln, die den Zugriff auf Inhalte kontrollieren

CGI Schreibgeschützt Legt Eigenschaften für CGI-Anwendungen fest

Sollte auf Schreibgeschützt gesetzt bleiben, um zu verhindern, dass die Benutzer Einstellungen ändern

Komprimierung Lesen/Schreiben Legt Einstellungen für die Konfiguration der Komprimierung fest

Verbindungszeichenfolgen Lesen/Schreiben Legt Verbindungszeichenfolgen fest, die von Anwendungen benutzt werden können



Standarddokument Lesen/Schreiben Legt die Standarddokumente einer Website festWenn diese Einstellung auf Lesen/Schreiben gesetzt bleibt, können die Benutzer ein benutzerdefiniertes Standarddokument für ihre Site angeben, ohne den Serveradministrator kontaktieren zu müssen

Verzeichnis durchsuchen Lesen/Schreiben Legt Einstellungen für das Durchsuchen von Verzeichnissen fest

Fehlerseiten Schreibgeschützt Legt fest, welche HTTP-Fehlerantworten zurückgegeben werden

Ablaufverfolgung für Anforderungsfehler

Lesen/Schreiben Legt Einstellungen für die Ablaufverfolgung fehlgeschlagener Anforde-rungen fest. Ermöglicht es den Benutzern, Regeln für die Ablaufverfol-gung von Anforderungen zu definieren, die auf bestimmten Parametern basieren. Zu diesen Parametern zählen z.B. die benötigte Zeit oder der Statuscode. Außerdem können die Benutzer Probleme mit ihrer Site diagnostizieren.

Delegierung von Features Nicht delegiert(wurde geändert, war zunächst Lesen/ Schreiben)

Legt Einstellungen für das Delegieren von Features an Anwendungen fest

Kann deaktiviert werden, sofern die Serveradministratoren dieses Feature für Sitebesitzer nicht aktivieren möchten

Handlerzuordnungen Lesen/Schreiben

HTTP-Antwortheader Lesen/Schreiben Gibt die HTTP-Header an, die den Antworten des Webservers hinzu-gefügt werden

ISAPI-Filter Schreibgeschützt Gibt ISAPI-Filter an, die die an die Site oder den Server gerichteten Anforderungen, z.B. ASP.NET-Anforderungen, verarbeiten

Protokollierung Nicht delegiert

Computerschlüssel Lesen/Schreiben Legt Hashing- und Verschlüsselungseinstellungen für Anwendungs-dienste fest, wie z.B. für den Anzeigezustand, die Formularauthentifi-zierung und den Dienst Mitgliedschaft und Rollen

MIME-Typen Schreibgeschützt Gibt an, welche Dateitypen als statische Dateien bereitgestellt werden können

Module Lesen/Schreiben Gibt systemeigene und verwaltete Codemodule an, die die an die Site oder den Server gerichteten Anforderungen verarbeiten

Ausgabezwischenspeicherung Lesen/Schreiben Legt Regeln für die Ausgabezwischenspeicherung fest

Seiten und Steuerelemente Lesen/Schreiben Legt Seiten- und Steuerelementeinstellungen für Anwendungen fest

Umleitungsregeln Lesen/Schreiben Legt Einstellungen für die Umleitung von Anforderungen zu anderen Dateien oder URLs fest

Sitzungszustand Lesen/Schreiben Legt Einstellungen für den Sitzungszustand und Formularauthentifizie-rungscookies fest

SMTP-E-Mail Lesen/Schreiben Gibt E-Mail-Adressen und Übermittlungsoptionen für E-Mails an, die von einer Site versendet werden

SSL-Einstellungen Schreibgeschützt Legt Einstellungen für SSL fest

Tabelle 4.8 Feature- und Delegierungseinstellungen (Fortsetzung)

Feature Delegierte Einstellung Grund



Direkte Konfiguration der DelegierungMit dem IIS-Manager können Sie die Delegierung vieler IIS-Features verwalten. Die zugrunde liegende Konfigurationsdelegierung können Sie aber nur für solche Features verwalten, die im IIS-Manager über entsprechende Benutzeroberflächenseiten verfügen. Wenn Sie für diese Features den IIS-Manager-Delegierungsstatus auswählen, werden ebenfalls die erforderlichen Konfigurationsdelegierungs-einstellungen generiert, die kontrollieren, ob die entsprechenden Konfigurationsabschnitte auf der Site- oder Anwendungsebene verwendet werden können.

Es gibt jedoch Situationen, in denen Sie die Konfigurationsdelegierung direkt verwalten möchten. Dieses ist beispielsweise der Fall, wenn es für einen Konfigurationsabschnitt kein entsprechendes IIS-Manager-Feature gibt. Für das IIS 7.0-Feature URL-Filterung gab es beispielsweise zur Drucklegung dieses Buches keine Benutzeroberflächenkomponente. In diesen Fällen können Sie direkt mit dem Konfigurationssystem arbeiten oder das Befehlszeilentool Appcmd verwenden, um die gewünschte Konfigurationsdelegierung zu konfigurieren.

Die erste Möglichkeit, einen bestimmten Konfigurationsabschnitt zu delegieren, ergibt sich bei dessen Deklaration. Dort kann das Attribut overrideModeDefault verwendet werden (lesen Sie dazu auch früher in diesem Kapitel den Abschnitt »Abschnittsdeklarationen«). Einige der integrierten IIS 7.0-Konfi-gurationsabschnitte, wie z.B. <defaultDocument>, lassen die Delegierung standardmäßig zu, indem Sie in ihren Deklarationen das Attribut auf Allow (Zulassen) setzen, während andere, wie z.B. <serverRuntime>, dies nicht tun und stattdessen Deny (Verweigern) verwenden. Diese Entscheidung wird in der Regel vom Entwickler des Features getroffen, das den jeweiligen Konfigurationsabschnitt liest. Sie basiert auf der Frage, ob die Featurekonfiguration standardmäßig an Benutzer delegiert werden soll, die keine Serveradministratoren sind.

Vorsicht Ändern Sie die overrideModeDefault-Einstellung nicht in Abschnittsdeklarationen, um die entsprechenden Abschnitte zu sperren. Die Empfehlungen des IIS-Teams für die Delegierungsstandardeinstellungen sind gut durch-dacht. Wenn Sie eine Standardeinstellung global außer Kraft setzen möchten, sollten Sie location-Tags benutzen, die den "*"-Pfad (oder den Null-Pfad "") referenzieren.

Die overrideModeDefault-Einstellung in den Abschnittsdeklarationen von applicationHost.config legt den Standardwert für die Delegierung fest. Sie können den Delegierungsstatus eines jeden Konfigurations-abschnitts modifizieren, indem Sie ihn sperren oder entsperren. Das Entsperren von Abschnitten ist oft notwendig, um in den web.config-Dateien Ihrer Website bestimmte Konfigurationen für bestimmte Abschnitte festlegen zu können. Oder Sie möchten bestimmte andere Abschnitte sperren, wenn die Websites auf Ihrem Server die dazugehörigen Einstellungen in applicationHost.config nicht außer Kraft setzen sollen.

Um einen Abschnitt zu entsperren, können Sie das Befehlszeilentool Appcmd.exe wie folgt verwenden:%windir%\system32\inetsrv\AppCmd Unlock Config /section:<SectionName>

Dabei ist <SectionName> der Name des Abschnitts, z.B. system.webServer/serverRuntime.

Um einen Abschnitt zu sperren, der gegenwärtig entsperrt ist, können Sie den folgenden Befehl benutzen:%windir%\system32\inetsrv\AppCmd Lock Config /section:<SectionName>



Das Sperren oder Entsperren eines Abschnitts generiert in applicationHost.config ein location-Tag, das den Delegierungsstatus des Konfigurationsabschnitts festlegt, indem es das overrideMode-Attribut auf Allow oder Deny setzt. Wenn wir beispielsweise den zuvor gezeigten Befehl benutzen, um den Abschnitt <serverRuntime> zu entsperren, erzeugen wir in applicationHost.config den folgenden Code: <location path="" overrideMode="Allow"> <system.webServer> <serverRuntime /> </system.webServer> </location>

Desgleichen können Sie Konfigurationsabschnitte nur für einen bestimmten Konfigurationspfad sperren oder entsperren, indem Sie diesen Pfad im Befehl angeben. Auf diese Weise könnten Sie beispielsweise einen Konfigurationsabschnitt für den gesamten Server sperren, aber einer einzelnen Site die Möglichkeit bieten, die Einstellungen dieses Abschnitts außer Kraft zu setzen.%windir%\system32\inetsrv\AppCmd Unlock Config "Default Web Site/" /section:system.webServer/serverRuntime /commit:apphost

In diesem Beispiel entsperren wir den Abschnitt <serverRuntime> nur für Default Web Site und übernehmen (/commit) die Änderungen in applicationHost.config (dies ist erforderlich). Dadurch wird in applica-tionHost.config ein location-Tag generiert, der das path-Attribut verwendet, um sich selbst nur auf Default Web Site/ anzuwenden.

Auf diese Weise können Sie die Konfigurationsdelegierung für eine Abschnittsebene verwalten, ohne hierfür viel Zeit investieren zu müssen. Manchmal ist es jedoch notwendig, die Delegierung eines Abschnitts zuzulassen, aber die Kontrolle über eine bestimmte Einstellung innerhalb des Abschnitts nicht abzugeben. Dies ist mithilfe einer feiner abgestuften Konfigurationssperrung möglich, die später in diesem Kapitel im Abschnitt »Spezifische Konfigurationssperrung« beschrieben wird.

Weitere Konfigurationsmöglichkeiten für die RemoteverwaltungDamit ein Benutzer eine Site oder Anwendung mithilfe des IIS-Managers remote verwalten kann, müssen den Inhalten bestimmte Berechtigungen zugewiesen werden. Das Konto für den Dienst WMSvc (Web Management Service) muss über Lese- und Schreibberechtigungen für web.config verfügen, um eine Remoteverbindung herstellen zu können. Lesen Sie auch das achte Kapitel, das ausführliche Informationen hierzu enthält.

Spezifische KonfigurationssperrungBisher haben wir die Möglichkeit untersucht, Konfigurationsabschnitte für die Delegierung zu sperren und zu entsperren, und wir haben das location-Tag benutzt, um für eine Site oder ein Verzeichnis Einstellungen festzulegen, die die geerbten Standardeinstellungen außer Kraft setzen. Die Feature-delegierung kontrolliert, ob in einer Konfigurationsdatei einer bestimmten Ebene ein vollständiger Abschnitt verwendet werden kann. Es gibt jedoch Fälle, in denen ein Konfigurationsabschnitt einen Teil der Konfiguration enthält, der delegiert werden soll, während ein anderer Teil gesperrt werden soll.

Um auch solche Szenarien berücksichtigen zu können, bietet Ihnen das Konfigurationssystem mithilfe der so genannten spezifischen Konfigurationssperrung die Möglichkeit einer feiner abgestuften Kontrolle darüber, welche einzelnen Konfigurationseinstellungen delegiert werden sollen. Die spezifische Konfigurationssperrung wird durch den Einsatz spezieller Sperrdirektiven ermöglicht, die vom Konfigurationssystem unterstützt werden.



Um mit der spezifischen Konfigurationssperrung arbeiten zu können, müssen Sie die Konfiguration mit einem anderen Hilfsmittel als dem IIS-Manager bearbeiten. Der IIS-Manager unterstützt gegenwärtig keine spezifischen Sperrungen.

Hinweis Die Semantik der spezifischen Sperrung basiert auf dem ASP.NET-Konfigurationssystem. Wenn Sie mit diesem vertraut sind, sollte Ihnen auch die Arbeit mit der spezifischen Sperrung nicht schwerfallen.

Die spezifische Konfigurationssperrung wird mit einem der in Tabelle 4.9 aufgeführten speziellen Attribute erreicht.

lockAttributes, lockAllAttributesExceptDie Konfigurationsdirektive lockAttributes kann für ein Konfigurationselement angegeben werden, um bestimmte Attribute des Elements zu sperren, so dass diese auf niedrigeren Konfigurationsebenen nicht verwendet werden können. Die lockAttributes-Direktive gibt eine kommagetrennte Liste mit Attributnamen an, die für das aktuelle Element zulässig sind.

Um beispielsweise zuzulassen, dass der Abschnitt <defaultDocument> delegiert, aber das Feature selbst nicht deaktiviert werden kann, setzen wir das enabled-Attribut wie folgt auf true und sperren es anschließend mit der Direktive lockAttributes:<defaultDocument enabled="true" lockAttributes="enabled"> <files> <add value="Default.htm" /> <add value="Default.asp" /> <add value="index.htm" /> <add value="index.html" /> <add value="iisstart.htm" /> <add value="default.aspx" /> </files> </defaultDocument>

In diesem Beispiel weist lockAttributes IIS 7.0 an, keine Änderungen am enabled-Attribut zuzulassen. Würde der Webadministrator somit versuchen, das Standarddokumentfeature zu deaktivieren (enabled="false"), erhielte er die in Abbildung 4.6 dargestellte Fehlermeldung.

Tabelle 4.9 Spezifische Konfigurationssperrung

Sperrdirektive Verwendungszweck

lockAttributes Sperrt bestimmte Attribute, um zu verhindern, dass diese angegeben werden

lockAllAttributesExcept Sperrt alle Attribute des Elements, die nicht den angegebenen Attributen entsprechen

lockElements Sperrt die angegebenen Elemente, um zu verhindern, dass diese angegeben werden (deshalb werden alle Attribute und untergeordneten Elemente der angegebenen Elemente gesperrt)

lockAllElementsExcept Sperrt alle Elemente des aktuellen Elements, außer die angegebenen Elemente

lockItem Sperrt das aktuelle Auflistungselement, um zu verhindern, das entfernt wird



Abbildung 4.6 Fehlermeldung aufgrund einer Konfigurationssperrung

Wie Sie in Abbildung 4.6 sehen können, wird die Sperrverletzung genannt und die fehlerverursachende Zeile in web.config ist deutlich hervorgehoben. Das Entfernen dieser Zeile würde in diesem Fall zur Behebung des Problems führen.

Die lockAllAttributesExcept-Form der Attributsperrung ist für die Situationen vorgesehen, in denen Sie alle Attribute eines Elements bis auf wenige Ausnahmen sperren möchten. In diesem Fall können Sie dieses Element anstelle von lockAttributes verwenden und die Attribute angeben, die entsperrt bleiben sollen.

lockElements, lockAllElementsExceptDie lockElements-Direktive ermöglicht es Ihnen, ein bestimmtes untergeordnetes Element des aktuellen Elements (und nicht ein Attribut) zu sperren. Dies verhindert, dass dieses Element auf einer niedrigeren Konfigurationsebene verwendet wird. Die lockElements-Direktive gibt eine kommagetrennte Liste mit den Namen der zu sperrenden Elemente an.

Sie können die lockElements-Direktive beispielsweise nutzen, um zu verhindern, dass die <files>-Auf-listung des <defaultDocument>-Abschnitts angegeben wird. Auf diese Weise wird vermieden, dass niedrigere Konfigurationsebenen den Inhalt der Standarddokumentliste ändern.<defaultDocument enabled="true" lockElements="files" > <files> <add value="Default.htm" /> <add value="Default.asp" /> <add value="index.htm" /> <add value="index.html" /> <add value="iisstart.htm" /> <add value="default.aspx" /> </files> </defaultDocument>



Diese Konfiguration verhindert, dass ein Webadministrator die in der Standarddokumentliste aufgeführten Dateien ändert. Das Ein- und Ausschalten des Features (über das enabled-Attribut) ist jedoch möglich.

Die lockElements-Direktive kann ebenfalls verwendet werden, um Auflistungen zu sperren. Mit dem Sperren bestimmter Auflistungselemente (wie z.B. <add>, <remove> und <clear>) wird erreicht, dass die Auflistung beispielsweise nicht geändert oder Elemente nicht daraus gelöscht werden können, während das Hinzufügen von neuen Elementen jedoch weiterhin möglich ist.

Wenn Sie beispielsweise das <add>-Element (oder das Element, das für die Auflistung als <add>-Element dient) sperren, können der Auflistung auf niedrigeren Konfigurationsebenen keine neuen Elemente hinzugefügt werden. Wenn Sie stattdessen die Elemente <remove> und <clear> sperren, ist es auf den niedrigeren Ebenen nicht möglich, Elemente aus der Auflistung zu entfernen. Neue Elemente können jedoch hinzugefügt werden.

Die lockAllElementsExcept-Direktive kann für Konfigurationselemente verwendet werden, die über mehrere Unterelemente verfügen, die Sie bis auf eine Ausnahme sperren möchte. In der Praxis wird diese Direktive wahrscheinlich kaum Verwendung finden, aber es ist eine Option, die zur Verfügung steht, sollten Sie sie einmal benötigen.

lockItemDie lockItem-Direktive sperrt bestimmte Auflistungselemente, so dass diese nicht entfernt bzw. modifiziert werden können. Sie ist das Gegenstück zur Direktive lockElements, die verhindert, dass alle Elemente in der Auflistung entfernt werden, indem sie das Element <remove> sperrt. Die Direktive wird für jedes Auflistungselement angegeben, das gesperrt werden soll. Sie erwartet einen booleschen Wert.

Lassen Sie uns zu unserem Beispiel zurückkehren. Die Webadministratoren sollen der Standard-seitenliste neue Einträge hinzufügen, aber Default.aspx nicht aus der Liste entfernen können. Sie können die Seite in applicationHost.config sperren. Dazu müssen Sie den entsprechenden Konfigurationsabschnitt finden. <defaultDocument> <files> <add value="Default.htm" /> <add value="Default.asp" /> <add value="index.htm" /> <add value="index.html" /> <add value="iisstart.htm" /> <add value="default.aspx" lockItem="true" /> </files> </defaultDocument>

Auf diese Weise wird vermieden, dass auf den niedrigeren Konfigurationsebenen der Eintrag Default.aspx explizit entfernt werden kann. Außerdem ist es nicht möglich, alle Elemente der Auflistung mit <clear/> zu entfernen. Das Hinzufügen neuer Einträge zur Auflistung ist aber auch weiterhin möglich.

Eine wichtige Verwendungsmöglichkeit von lockItem ist in applicationHost.config implementiert. Wenn Sie den Abschnitt <modules> untersuchen, werden Sie feststellen, dass die Module mit der auf true gesetzten lockItem-Direktive hinzugefügt werden. Dies bedeutet, dass, wenn IIS 7.0 in einer web.config-Datei oder innerhalb eines location-Tags auf ein <clear>- oder <remove>-Element trifft, das ein gesperrtes Modul referenziert, ein Sperrungsfehler zurückgegeben wird. Diese Sperrungen sind standardmäßig aktiviert, weil die Delegierung für Module aktiviert ist, damit .NET-Anwendungen Module hinzufügen können. Dies ist eine übliche Option. Durch das Delegieren des Abschnitts <modules> ist es jedoch



ebenfalls möglich, Module aus web.config zu entfernen. Dies könnte dazu führen, dass ein Benutzer versehentlich eine instabile oder nicht funktionierende Konfiguration generiert. Damit dies nicht geschieht, aber gleichzeitig die größtmögliche Kompatibilität mit .NET gewährleistet bleibt, werden Module so deklariert, dass lockItem auf true gesetzt ist.

Eine Konfiguration für mehrere ServerEin ganz neues Feature von IIS 7.0 ist die Möglichkeit, dass mehrere Webserver eine einzelne Konfi-gurationsdatei gemeinsam nutzen. Dieses Feature wurde mit Blick auf Webfarmen für den Lastenaus-gleich entwickelt, um dort eine Synchronisierung mehrerer Serverkonfigurationen zu vermeiden. Diesbezüglich ist die gemeinsam genutzte Konfiguration (die auch als freigegebene Konfiguration bezeichnet wird) ein hervorragendes Feature, das sich in vielen Webfarmumgebungen als äußerst nützlich erweisen wird.

Hinweis Die freigegebene Konfiguration allein ist keine vollständige Webfarmlösung, da durch sie die Notwendig-keit, Anwendungsinhalte und lokale Komponenten – wie SSL-Zertifikate oder im globalen Assemblycache regist-rierte .NET-Assemblys – zu synchronisieren, nicht entfällt.

Die freigegebene Konfiguration aktivierenSie können die freigegebene Konfiguration mit dem IIS-Manager aktivieren. Sie finden das Symbol der freigegebenen Konfiguration im Featurebereich des IIS-Managers, sofern im Hierarchielistenfeld der Serverknoten markiert ist. Es ist unten im Featurebereich unter Verwaltung aufgeführt, wie in Abbildung 4.7 dargestellt.

Abbildung 4.7 Das Symbol der freigegebenen Konfiguration im IIS-Manager



Hinweis Es ist möglich, die freigegebene Konfiguration ohne den IIS-Manager zu aktivieren. Dazu müssen Sie die IIS-Konfiguration bearbeiten und alle erforderlichen Importierungsschritte manuell ausführen. Sie sollten jedoch mit dem IIS-Manager arbeiten, da er die meisten dieser Schritte automatisiert und das Einrichten der freigegebenen Konfiguration viel einfacher gestaltet, als dies der Fall wäre, wenn Sie sich für die manuelle Vorgehensweise ent-scheiden würden.

Funktionsweise der freigegebenen KonfigurationDie grundlegende Idee, die sich hinter der freigegebenen Konfiguration verbirgt, besteht darin, die IIS 7.0-Hauptkonfigurationsdateien in einem freigegebenen UNC-Pfad abzulegen und dafür zu sorgen, dass alle Server in der Farm den Remotekonfigurationsspeicher so verwenden, als würde es sich um einen lokalen Speicher handeln. Wenn Sie darüber hinaus Befehlszeilentools anweisen, die Einstellungen eines die freigegebene Konfiguration nutzenden Servers zu ändern, werden diese Anweisungen zum freigegebenen Speicher umgeleitet. Das Ergebnis ist, dass, wenn Sie mit zehn Servern arbeiten, die eine Konfiguration gemeinsam nutzen, und Sie z.B. einen Anwendungspool hinzufügen, alle zehn Server sofort über diesen Pool verfügen können.

Das Einrichten der freigegebenen Konfiguration erfordert drei Hauptschritte: Zuerst müssen Sie einen Speicherort erstellen, für den Sie die richtigen Berechtigungen und eine Benutzeridentität verwenden, die für den Zugriff auf die Inhalte verwendet wird. Zweitens müssen Sie die Konfigurationsdateien exportieren, so dass sie an zentraler Stelle verfügbar sind. Drittens müssen Sie die Server einrichten, damit sie die freigegebenen anstelle der lokalen Konfigurationsdateien verwenden. Danach sind die Server alle funktionell identisch.

Schritt 1: Vorbereiten der freigegebenen KonfigurationDer IIS-Manager muss die Remotekonfiguration unter der Identität eines Benutzers schreiben. Er muss somit mit den Anmeldeinformationen eines lokalen Benutzers oder eines Domänenbenutzers ausge-stattet werden, der über die entsprechenden Berechtigungen verfügt. Die erste Aufgabe besteht deshalb darin, einen Benutzer zu erstellen, der über die erforderlichen Berechtigungen verfügt. Dann müssen dem freigegebenen Speicherort die NTFS-Berechtigungen für diesen Benutzer zugewiesen werden.

1. Erstellen Sie einen Benutzer, den Sie verwenden, um den Lese- und Schreibzugriff auf die frei-gegebenen Konfigurationsdateien zu ermöglichen. Dabei kann es sich um einen lokalen Benutzer handeln, dessen Anmeldeinformationen auf jedem Server gleich sind, oder es ist ein Domänen-benutzer, sofern die Server zu einer Domäne zusammengeschlossen sind.net user ConfigAccess HighSecurePasswordhere /add

2. Erstellen Sie einen Ordner, der die freigegebenen Konfigurationsdateien enthält. Dies kann einer der Webserver oder der Dateiserver sein. Die einzige Voraussetzung, die erfüllt sein muss, ist, dass alle Server über einen freigegebenen UNC-Standardpfad darauf zugreifen können.

3. Konfigurieren Sie den Ordner für die freigegebene Konfiguration mit den entsprechenden Freigabe-berechtigungen. Wir benutzen in diesem Beispiel den Ordner SharedConfig.Net share sharedconfig$=%SystemDrive%\sharedconfig /grant:ConfigUser,Read /grant:Administrators,Full /grant:System,Full

4. Untersuchen Sie genau die Konfiguration des Servers, der als Quelle für die freigegebene Konfigu-ration dienen soll. Die von Ihnen exportierte IIS 7.0-Konfiguration wird von allen anderen Servern gemeinsam genutzt. Nehmen Sie sich deshalb ein wenig Zeit, um sicherzustellen, dass sie korrekt ist. Sie können die Konfiguration natürlich ändern, nachdem Sie die freigegebene Konfiguration aktiviert haben. Die Änderungen wirken sich dann allerdings auf mehrere Server gleichzeitig aus.



5. Sichern Sie die vorhandenen Konfigurationsdateien von einer administrativen Eingabeaufforderung aus. Verwenden Sie dazu die folgenden Befehle:windir%\system32\inetsrv appcmd add backup SharedConfigBackup

Schritt 2: Die Konfigurationsdateien exportieren1. Markieren Sie im IIS-Manager den Serverknoten und führen Sie einen Doppelklick auf dem Sym-

bol Freigegebene Konfiguration aus.

2. Klicken Sie im Bereich Aktionen auf Konfiguration exportieren, um das gleichnamige Dialogfeld zu öffnen, wie in Abbildung 4.8 dargestellt.

3. Geben Sie unter Konfigurationsspeicherort in das Textfeld Physikalischer Pfad den UNC-Pfad zur freigegebenen Konfiguration ein.

Hinweis Sie können die Konfigurationsdateien in einen lokalen, nicht freigegebenen Pfad exportieren und dann manuell in den freigegebenen Ordner kopieren, wenn Sie diese Vorgehensweise bevorzugen.

Abbildung 4.8 Das Dialogfeld Konfiguration exportieren

4. Klicken Sie auf Verbinden als und geben Sie die Anmeldeinformationen ein, mit denen der Zugriff auf den freigegebenen Pfad möglich ist. Sie können an dieser Stelle auch administrative Anmeldeinforma-tionen eingeben. Die Anmeldeinformationen werden nur für diesen einmaligen Export benötigt und nicht für den regulären Zugriff auf die freigegebenen Konfigurationseinstellungen verwendet.

Vorsicht Benutzen Sie nicht die Anmeldeinformationen, die Sie erstellt haben, um vom Webserver aus auf die Konfiguration zuzugreifen. Diese Anmeldeinformationen sollten über keinen Schreibzugriff für die freigegebene Konfiguration verfügen.



5. Geben Sie unter Verschlüsselungsschlüssel ein Kennwort ein, das für den Schutz exportierter Ver-schlüsselungsschlüssel verwendet wird, wenn diese den Server verlassen. Sie müssen dieses Kenn-wort auf jedem Server angeben, der die freigegebenen Konfigurationsdateien verwenden wird, damit dieser die exportierten Verschlüsselungsschlüssel importieren kann. Beachten Sie, dass das Kennwort mindestens acht Zeichen lang sein, ein Sonderzeichen und eine Zahl enthalten und sowohl Groß- als auch Kleinschreibung verwenden muss, um akzeptiert zu werden. Zur Drucklegung dieses Buches war eine automatisierte Erstellung des Verschlüsselungsschlüssels noch nicht möglich.

6. Klicken Sie auf OK. Im Anschluss daran erhalten Sie die Meldung, dass das Exportieren erfolgreich war.

Sie haben jetzt die freigegebene Konfiguration noch nicht aktiviert, sondern nur einen Satz Dateien erstellt, der für die freigegebene Konfiguration verwendet werden kann. Bevor Sie fortfahren, möchten Sie vielleicht wissen, was (und was nicht) kopiert wurde. Lesen Sie den Einschub »Untersuchen der exportierten Konfigurationsdateien«, um weitere Informationen zu erhalten.

Untersuchen der exportierten KonfigurationsdateienÖffnen Sie das Verzeichnis, in das Sie die Dateien exportiert haben, und betrachten Sie die Inhalte. Sie finden dort eine Kopie von applicationHost.config, administration.config und eine verschlüsselte Datei namens ConfigEncryptedKey.key. Die .key-Datei wird verwendet, um die in den .config-Dateien gespeicherten verschlüsselten Informationen zu entschlüsseln. Damit dies funktioniert, müssen alle Server der Farm einen gemeinsamen geheimen Schlüssel kennen. Aus diesem Grund müssen Sie einen starken Schlüssel eingeben, wenn Sie diese Konfigurationseinstellungen exportieren. In den Konfi-gurationsdateien sind standardmäßig keine verschlüsselten Informationen enthalten, da der anonyme Benutzer nun ein integriertes Konto ist, das kein Kennwort mehr erfordert, weil es nicht für eine Anmeldung an den Server genutzt werden kann. Darüber hinaus wurde das unter IIS 4.0, IIS 5.0 und IIS 6.0 verwendete IWAM-Konto verworfen. Viele Unternehmen verwenden jedoch eine eindeutige Identität als Prinzipal für Anwendungspools und sonst den anonymen IIS-Benutzer, um die Sicherheit zu vergrößern und spezifischere Details in Überwachungsprotokollen zur Verfügung zu stellen.

Die mit dem IIS-Manager erstellten Kennwörter für UNC-Pfade, Anwendungspoolprinzipale und benutzerdefinierte anonyme Benutzer werden verschlüsselt und in den Konfigurationsdateien gespeichert. Diese verschlüsselten Elemente können auf anderen IIS 7.0-Servern nicht einfach entschlüsselt werden. Die freigegebene Konfiguration macht dies jedoch möglich, weil Sie die Verschlüsselungsschlüssel des Servers, dessen Konfiguration exportiert werden soll, exportieren und auf allen anderen Computern, die die freigegebene Konfiguration nutzen sollen, wieder importieren können.

Sie sollten beachten, dass Sie keine web.config-Dateien, benutzerdefinierten Module, Webseiteinhalte, Zertifikate oder andere Dateien vorfinden werden, die sich auf die Serverkonfiguration beziehen. Die zentralisierte Konfiguration ermöglicht nur die gemeinsame Nutzung von applicationHost.config und administration.config. Alle anderen Elemente, die notwendig sind, damit die Server eine identische Funktionalität aufweisen, müssen durch Prozesse verwaltet werden, die Sie außerhalb von IIS 7.0 initiieren.

Beachten Sie, dass Sie vom IIS-Team Tools oder Updates zu diesem Feature erwarten können, nachdem Windows Server 2008 veröffentlicht wurde. Diese Hilfsmittel dienen der einfacheren Replikation und Synchronisierung.



Schritt 3: Die freigegebene Konfiguration aktivierenSie können die freigegebene Konfiguration nun aktivieren. In der Regel beginnen Sie mit dem Server, den Sie zum Exportieren der freigegebenen Konfiguration verwendet haben. Das Exportieren der Konfiguration veranlasst den Server nicht, mit der Verwendung der exportierten Einstellungen auto-matisch zu beginnen. Es ist sogar so, dass, wenn Sie an diesem Punkt Änderungen an der IIS 7.0-Konfiguration vornehmen, Sie diese nur auf dem lokalen Server sehen. Solange Sie die freigegebene Konfiguration nicht erneut exportieren, wird sie diese neuen Änderungen nicht widerspiegeln.

Die Prozedur ist einfach und für jeden Server gleich:

1. Aktivieren Sie im Feature Freigegebene Konfiguration das Kontrollkästchen Freigegebene Konfigu-ration aktivieren.

2. Geben Sie den physikalischen Pfad, den Benutzernamen und das Kennwort ein, also die Daten, die Sie benutzt haben, um den freigegebenen Speicherort und den Benutzer für diesen Ort zu erstellen. In unserem Beispiel wäre dies:Pfad: \\Contoso\SharedConfig\ Benutzer: ConfigAccess Kennwort: HierDasHochsicherheitskennwort

3. Klicken Sie im Bereich Aktionen auf Übernehmen. Geben Sie im folgenden Dialogfeld das Kenn-wort ein, das Sie benutzt haben, um die Einstellungen zu exportieren. Daraufhin sehen Sie die in Abbildung 4.9 dargestellte Meldung.

Abbildung 4.9 Verschlüsselungsschlüssel sichern

Diese Meldung teilt Ihnen mit, dass, wenn Sie sich dazu entschließen würden, zu Ihren lokalen Einstellungen zurückzukehren, der IIS-Manager Ihre Verschlüsselungsschlüssel wiederherstellen würde, so dass sie für Ihre lokalen Konfigurationsdateien verwendet werden könnten. Andernfalls könnten alle Kennwörter, die Sie im Konfigurationssystem für UNC-Pfade, benutzerdefinierte anonyme Benutzer oder Anwendungspoolidentitäten eingegeben hätten, von IIS nicht mehr ent-schlüsselt werden.

4. Klicken Sie auf OK, um das Meldungsdialogfeld zu schließen. Daraufhin wird eine weitere Mel-dung angezeigt, die Sie darüber informiert, dass Sie dem IIS-Manager schließen und erneut öffnen und den Webverwaltungsdienst neu starten müssen, damit die Änderungen berücksichtigt werden. Wenn Sie den IIS-Manager schließen und neu öffnen, werden die freigegebenen Konfigurations-dateien anstelle der lokalen Dateien geladen. Das Neustarten des Verwaltungsdienstes führt dazu, dass die Remoteverwaltungsanforderungen umgeleitet werden.

Sie müssen diesen Vorgang auf jedem Server wiederholen.


Zusammenfassung 111

Überlegungen zur freigegebenen KonfigurationDie freigegebene Konfiguration hilft, den administrativen Aufwand zu verringern, der mit dem Repli-zieren der Konfiguration für die Server einer Webfarm einhergeht. Es handelt sich jedoch nicht um ein Verwaltungstool für Webfarmen. Sie sind auch weiterhin selbst für das Replizieren aller Inhalte und solcher Konfigurationseinstellungen verantwortlich, die für einen Server der Farm von lokaler Natur sind. Dazu zählen Einstellungen zur Inhaltsreplikation, zur Verzeichnisstrukturverwaltung, zu SSL-Zertifikaten, zur Wiederverwendung von Diensten, zu Betriebssystemupdates, zur Registrieren von COM-Objekten, zum Platzieren neuer Inhalte im globalen .NET-Assemblycache, zur Netzwerk-konfiguration und andere Einstellungen, die lokal gespeichert werden.

Stellen Sie sich vor, Sie möchten einen Anwendungspool vom klassischen in den integrierten Modus versetzen. Dies ist eine der wenigen Einstellungen, die dazu führen, dass ein Anwendungspool recycelt wird. Änderungen, die sich auf die Anwendungspoolumgebung auswirken, wie z.B. der Typ des Anwen-dungspools oder die Poolidentität, verursachen ein Recycling all Ihrer Anwendungspools auf allen Shared-Servern, was dazu führen kann, dass Ihre Webanwendung für kurze Zeit nicht verfügbar ist. In Anbetracht dieses und anderer Szenarien, z.B. Inhaltsaktualisierungen, benötigen Sie ein Verfahren, um Updates sukzessive anzuwenden, so dass Sie die Einstellungen präziser kontrollieren können.

Wenn Sie beispielsweise eine Konfigurationsänderung durchführen müssen, die einen Recycelvorgang zur Folge hat, sollten Sie die Einstellungen von einem zweiten Server in einen neuen freigegebenen Ordner exportieren. Nur dieser Server verwendet dann diesen Speicherort, während die anderen Server der Farm weiterhin Anforderungen bedienen. Sie wenden anschließend die gewünschten Updates nur auf diesen Server an und testen die Ergebnisse. Wenn Sie zufrieden sind, verweisen Sie auch die anderen Shared-Server nacheinander auf den neuen freigegebenen Speicherort. Sollten währenddessen Probleme auftreten, können Sie ein Rollback zur vorherigen Konfiguration durchführen. Wenn keine Probleme auftreten, können Sie damit fortfahren, die einzelnen Server zum neuen Speicherort umzuleiten, bis schließlich alle Server die neue Konfiguration verwenden.

ZusammenfassungDas IIS 7.0-Konfigurationssystem ist die Basis für viele wichtige Bereitstellungs- und Verwaltungs-funktionen des Servers. Es ermöglicht zum ersten Mal Szenarien wie die delegierte Konfigurations-verwaltung, die echte xcopy-Bereitstellung von IIS-Anwendungen und die gemeinsame Nutzung einer Konfiguration durch mehrere Server.

In diesem Kapitel haben Sie sich mit den Grundlagen der Bearbeitung von Webserverkonfigurationen beschäftigt und wesentliche Konfigurationsverwaltungsaufgaben ausgeführt, wie z.B. das Sichern von Konfigurationen und das Einrichten einer freigegebenen Konfiguration für mehrere Server einer Web-farm.

Das Konfigurationssystem ist der Kern des IIS 7.0-Verwaltungsstacks, der verschiedene Möglichkeiten der Serververwaltung bietet. Um zu erfahren, wie IIS mithilfe einer grafischen Benutzeroberfläche verwaltet wird, lesen Sie bitte das sechste Kapitel. Im siebten Kapitel erfahren Sie mehr über die Verwaltung der IIS 7.0-Konfiguration über die Befehlszeile.



Das IIS 7.0-Konfigurationssystem ist der ganzheitlichen IIS 7.0-Erweiterbarkeit gemäß vollständig erweiterbar, weshalb Webservermodule von Drittanbietern ihre Konfiguration im IIS 7.0-Konfigura-tionssystem speichern können. Diese Erweiterbarkeit ermöglicht es den Entwicklern, dieselben Konfigurationsmöglichkeiten und Verwaltungstools zu nutzen, die auch von IIS 7.0 verwendet werden. Ein Administrator könnte beispielsweise ein benutzerdefiniertes Feature mit Appcmd konfigurieren, oder ein Entwickler könnte .NET benutzen, um den Featurestatus und die Featurekonfiguration zu verwalten.

Weitere Informationen zum Schutz von Konfigurationen auf Ihrem Server, wozu auch der Einsatz der Konfigurationsverschlüsselung und die richtige Nutzung der Konfigurationsisolation zählen, erhalten Sie im vierzehnten Kapitel.


� Die IIS 7.0-Webreferenz befindet sich unter http://msdn2.microsoft.com/en-us/library/ms691259.aspx.

� Sie können auf der IIS-Website unter http://www.iis.net und in den IIS 7.0-Online-Hilfedateien nach Konfigurationsinformationen suchen.

� Informationen darüber, wie sich die IIS 6.0-Metabasiseigenschaften dem IIS 7.0-Konfigurationsschema zuordnen lassen, finden Sie unter http://msdn2.microsoft.com/en-us/library/aa347565.aspx.

� Der Artikel »Using IIS7 Configuration History« unter http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Configuring-the-IIS7-Runtime/Understanding-AppHost-Service/Using-IIS7-Configuration-History?Page=1 enthält weitere Informationen zu configHistory.


113

T E I L I I

Bereitstellung

In diesem Teil:IIS 7.0 installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


115

K A P I T E L 5

Installieren von IIS 7.0

Inhalt dieses Kapitels:� Planen der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

� Nach der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

� Behandlung von Installationsproblemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

� IIS 7.0 entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142




Windows Server 2008 spielt bei der Installation und Konfiguration Ihres Webservers eine wichtige Rolle. Das Setup von IIS 7.0 (Internet Information Services) ist modular aufgebaut und ermöglicht es Ihnen, das Einrichten Ihres Webservers vollständig zu kontrollieren.

Windows Server 2008 führt neue Hilfsmittel zur Installation von IIS 7.0 ein. Sie können den Server-Manager benutzen, ein Tool mit einer grafischen Benutzeroberfläche, oder Sie arbeiten mit zwei Befehlszeilentools: dem Paketmanager (Pkgmgr.exe) und ServerManagerCMD. Zusätzlich zu den neuen Tools unterstützt IIS 7.0 auch die alten Skripts, die ADSI (Active Directory Service Interfaces) oder WMI (Windows Management Instrumentation) verwenden.

Abgesehen von den verschiedenen Möglichkeiten, IIS 7.0 zu installieren, können Sie mit dem neuen auf XML basierenden Konfigurationssystem, das mit Windows Server 2008 eingeführt wurde, Ihre Buildbasisdateien auf andere Computer kopieren. Nachdem Sie Ihr Masterimage erstellt haben, können Sie die IIS 7.0-Konfigurationsdateien auf einen anderen IIS 7.0-Server kopieren. Die neue modulare Architektur ermöglicht es Ihnen, einen Server zu konzipieren und zu implementieren, der Ihren Bedürfnissen gerecht wird.

Bevor Sie beginnen, IIS 7.0 zu installieren, ist ein wenig Planung notwendig.

Planen der InstallationIIS 7.0 weist eine modulare Architektur auf, die es Ihnen ermöglicht, genau zu bestimmen, welche Features auf dem Webserver installiert und ausgeführt werden sollen. Die Webserverfeatures sind in mehr als vierzig Module unterteilt, die unabhängig voneinander installiert werden können, so dass Sie über die Möglichkeit verfügen, die potentielle Angriffsfläche zu verringern. (Lesen Sie das dritte Kapitel, »Verstehen der modularen Basis«, um weitere Details zu erhalten.) Eine kleinere Installation führt außerdem dazu, dass weniger Patches installiert werden müssen. Wenn Sie eine Standardinstalla-tion implementieren, wird IIS 7.0 mit zehn Modulen installiert und liefert als anonymer Benutzer nur statische Inhalte. Wahrscheinlich benötigen Sie jedoch eine umfassendere Funktionalität.


116 Kapitel 5: Installieren von IIS 7.0

Um die modulare Architektur voll ausnutzen zu können, sollten Sie Ihre IIS 7.0-Installation planen, damit diese den Anforderungen der Anwendungen entspricht, die Sie bereitstellen möchten. Dieses Kapitel enthält spezifische Informationen darüber, welche Module Sie benötigen, um verschiedene Arbeitspensen bewältigen zu können. Wenn Sie die Anzahl der installierten Module verringern, ist es einfacher, Ihre in der Produktionsumgebung befindlichen Anwendungen zu warten und zu überwachen und Probleme zu beheben.

Wenn Sie Ihre Installation planen, sollten Sie darüber nachdenken, mit welchem Installationstool Sie arbeiten möchten. Der Server-Manager (der automatisch gestartet wird, wenn Sie sich an Windows Server 2008 anmelden) stellt eine intuitive Benutzeroberfläche zur Verfügung, mit der Sie kontrollieren können, welche Rollen und Features installiert werden sollen. Der Server-Manager kümmert sich auch automatisch um alle mit den verschiedenen Modulen einhergehenden Abhängigkeiten. Sie können den Server-Manager benutzen, um zu bestimmen, welche Module für ein bestimmtes Arbeitspensum erforderlich sind. Danach können Sie diese Informationen nutzen, um Ihre Installation unter Verwen-dung von Befehlszeilentools zu automatisieren. Die Benutzeroberfläche des Server-Managers ist bei Server Core-Installationen von Windows Server 2008 nicht verfügbar.

ServerManagerCMD ist die Befehlszeilenversion des Server-Managers. Dabei handelt es sich um eine aus verwaltetem Code bestehende ausführbare Datei, die besonders für die Automatisierung Ihrer Serverinstallationen geeignet ist. Die Arbeit mit ServerManagerCMD als Installationswerkzeug, das über die Befehlszeile gesteuert wird, ist sehr einfach, da das Programm die Serverrollen, Rollendienste und deren Abhängigkeiten kennt. Sie können beispielsweise mit nur einem Befehl alle Komponenten installieren, die notwendig sind, um einen statischen Webserver einzurichten. Andere Rollen und Features, wie z.B. das Message Queuing, können auf ähnliche Weise installiert werden. ServerMana-gerCMD ist als globales Tool vorgesehen, das auf der Serverebene verwendet wird. ServerMana-gerCMD ist bei Server Core-Installationen nicht verfügbar.

Der Paketmanager ist ein Befehlszeilentool, das für benutzerdefinierte und automatisierte Installationen von IIS 7.0 vorgesehen ist. Der Paketmanager bietet die größtmögliche Flexibilität und besonders detaillierte Konfigurationsmöglichkeiten für Ihre IIS 7.0-Installationen. Im Gegensatz zum Server-Manager müssen Sie bei der Arbeit mit dem Paketmanager jedoch die Module und deren Abhängig-keiten kennen. Wenn Sie nicht die richtigen Module und die damit verknüpften Abhängigkeiten installieren, wird Ihr Server nicht wie erwartet arbeiten. Der Paketmanager ist für alle Versionen von Windows Server 2008 verfügbar.

Welche dieser Tools Sie benutzen, ist von Ihrer Umgebung abhängig. Wenn Sie den Installations-vorgang nicht automatisieren müssen, genügt der Server-Manager. Wenn Sie den Einsatz von Servern in einem Unternehmen oder bei einem Webhoster planen, werden der Paketmanager und ServerMana-gerCMD für Sie interessant sein. Aber vielleicht möchten Sie sich nur für eines dieser Werkzeuge entscheiden, anstatt den Umgang mit beiden zu erlernen. Wenn Sie nur den Einsatz von Server Core-Computern planen, ist der Paketmanager Ihre einzige Option, und er ist für diese Aufgabe bestens geeignet. Wenn Sie nicht beabsichtigen, Server Core-Computer bereitzustellen, ist ServerMana-gerCMD eine Option. Unabhängig davon, für welches Tool Sie sich entscheiden, stellt IIS 7.0 mehrere Hilfsmittel zur Verfügung, die Sie bei der Automatisierung Ihrer Serverinstallationen unterstützen. Sie finden eine Erläuterung des Paketmanagers und von ServerManagerCMD später in diesem Kapitel in den Abschnitten »ServerManagerCMD verwenden« und »Den Paketmanager verwenden«.


Planen der Installation 117

Installationsszenarien für IIS 7.0Ein bei Windows Server 2008 neues Konzept sind Setups, die sich nach dem späteren Arbeitsschwer-punkt richten. Einige übliche Arbeitsschwerpunktszenarien, die unter Windows Server 2008 zur Verfü-gung stehen, sind nachfolgend aufgeführt:

� Webserver für statische Inhalte (Standardinstallation)

� ASP.NET

� Klassisches ASP

� Auf FastCGI basierende Anwendungen

� Verwaltete IIS-Module und .NET-Erweiterbarkeit

� Vollständige IIS-Installation

� Server Core Web Edition

Webserver für statische Inhalte (Standardinstallation)Ein Webserver mit dem Rollendienst Statischer Inhalt ist die Standardinstallation und gleichzeitig das Arbeitsschwerpunktsetup, das vorwiegend zum Einsatz kommt, weil es auch Bestandteil anderer Arbeitsschwerpunkt- und Produktionsinstallationen ist. Die standardmäßig ausgewählten Setupop-tionen von IIS 7.0 stellen alle IIS-Module zur Verfügung, die für diese Konfiguration notwendig sind. Zu diesen Modulen zählen solche, die verantwortlich für die Bereitstellung von statischen HTML-Dateien, Dokumenten und Bildern sind. Ein derart konfigurierter Webserver unterstützt außerdem Standarddokumente, das Durchsuchen von Verzeichnissen, die Protokollierung und die anonyme Authentifizierung. Die IIS-Manager-Konsole wird ebenfalls installiert.

Tabelle 5.1 listet alle Komponenten auf, die standardmäßig ausgewählten, wenn Sie IIS 7.0 installieren. Die Tabelle enthält auch die entsprechenden Updatenamen. Updatenamen sind Namen, die zur Durch-führung von Paketmanager-Installationen verwendet werden.

Tabelle 5.1 Installationskomponenten für den Standardserver

Server-Manager Updatename

Statischer Inhalt IIS-StaticContent

Standarddokument IIS-DefaultDocument

Verzeichnis durchsuchen IIS-DirectoryBrowsing

HTTP-Fehler IIS-HttpErrors

HTTP-Protokollierung IIS-HttpLogging

Protokollierungstools IIS-LoggingLibraries

Anforderungsüberwachung IIS-RequestMonitor

Anforderungsfilterung IIS-RequestFiltering

Komprimierung statischer Inhalte IIS-HttpCompressionStatic

IIS-Verwaltungskonsole IIS-ManagementConsole



Um mithilfe des Paketmanagers die IIS-Features für einen Webserver zu installieren, der ausschließlich statische Inhalte bereitstellt, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl: (Der Befehl wurde aus Gründen der besseren Lesbarkeit formatiert.)start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures; IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing; IIS-HttpErrors;IIS-HealthAndDiagnostics;IIS-HttpLogging; IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security; IIS-RequestFiltering;IIS-HttpCompressionStatic; IIS-WebServerManagementTools;IIS-ManagementConsole; WAS-WindowsActivationService;WAS-ProcessModel; WAS-NetFxEnvironment;WAS-ConfigurationAPI

Um mithilfe von ServerManagerCMD die IIS-Features für einen Webserver zu installieren, der aus-schließlich statische Inhalte bereitstellen soll, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:ServerManagerCMD.exe –install Web-Server

ASP.NETDer Microsoft ASP.NET-Webserver ist wahrscheinlich der am meisten verwendete Arbeitsschwer-punktserver. ASP.NET ist bei Entwicklern sehr beliebt. IIS 7.0 und ASP.NET wurden für eine enge Zusammenarbeit entworfen und ASP.NET nimmt bei IIS 7.0 eine besondere Stellung ein. Entwickler können verwalteten Code auf derselben Ebene bereitstellen, auf der sich auch die systemeigenen Module befinden. Die integrierte Pipeline ermöglicht diese Funktionalität. Die Module für einen auf statische Inhalte spezialisierten Webserver bilden zusammen mit bestimmten ASP.NET-Optionen den ASP.NET-Schwerpunktserver.Tabelle 5.2 führt alle Komponenten auf, die installiert werden, wenn Sie Ihren Server als ASP.NET-Schwerpunktserver konfigurieren. Die Tabelle enthält auch die entsprechenden Updatenamen.

Tabelle 5.2 Installationsoptionen für den ASP.NET-Schwerpunktserver












ASP.NET IIS-ASPNET

.NET-Erweiterbarkeit IIS-NetFxExtensibility

ISAPI IIS-ISAPIFilter

ISAPI-Erweiterungen IIS-ISAPIExtensions



Um mithilfe des Paketmanagers IIS-Features für den ASP.NET-Schwerpunktserver zu installieren, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer; IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument; IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-ApplicationDevelopment; IIS-ASPNET;IIS-NetFxExtensibility;IIS-ISAPIExtensions; IIS-ISAPIFilter;IIS-HealthAndDiagnostics;IIS-HttpLogging; IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security; IIS-RequestFiltering;IIS-HttpCompressionStatic; IIS-WebServerManagementTools;IIS-ManagementConsole; WAS-WindowsActivationService;WAS-ProcessModel; WAS-NetFxEnvironment;WAS-ConfigurationAPI

Um mithilfe von ServerManagerCMD die IIS-Features für den ASP.NET-Schwerpunktserver zu installieren, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:ServerManagerCmd.exe -install Web-Server ServerManagerCmd.exe -install Web-ASP-NET ServerManagerCmd.exe -install Web-NET-Ext ServerManagerCmd.exe -install Web-Filtering ServerManagerCmd.exe -install Web-ISAPI-Filter ServerManagerCmd.exe -install Web-ISAPI-Ext

Klassisches ASPBevor Microsoft ASP.NET veröffentlichte, war klassisches ASP die Programmiersprache, die haupt-sächlich für IIS verwendet wurde. Viele Websites nutzen noch heute klassisches ASP und IIS 7.0 unterstützt dies. Sie können ihre klassischen ASP-Anwendungen einfach portieren, so dass sie unter IIS 7.0 ausgeführt werden. Sie können die Vorzüge neuer Hilfsmittel und Verfahren nutzen, z.B. die Diagnose, Protokollierung und Problembehandlung, und gleichzeitig mit Ihren bereits vorhandenen Anwendungen arbeiten, so dass Sie das Beste aus beiden Welten erhalten. Sie sind in der Lage, Ihr klassisches ASP beizubehalten und zur selben Zeit die Vorzüge von IIS 7.0 zu nutzen. Die Module für statische Dateien bilden zusammen mit bestimmten klassischen ASP-Optionen den ASP-Schwerpunkt-server.

Tabelle 5.3 führt alle Komponenten auf, die installiert werden, wenn Sie Ihren Server als klassischen ASP-Schwerpunktserver konfigurieren. Die Tabelle enthält auch die entsprechenden Updatenamen.

Tabelle 5.3 Installationsoptionen für den klassischen ASP-Schwerpunktserver













Um mithilfe des Paketmanagers die IIS-Features für den klassischen ASP-Schwerpunktwebserver zu installieren, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer; IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument; IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-ApplicationDevelopment; IIS-ASP;IIS-ISAPIExtensions;IIS-HealthAndDiagnostics; IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor; IIS-Security;IIS-RequestFiltering;IIS-HttpCompressionStatic; IIS-WebServerManagementTools;IIS-ManagementConsole; WAS-WindowsActivationService;WAS-ProcessModel; WAS-NetFxEnvironment;WAS-ConfigurationAPI

Um mithilfe von ServerManagerCMD die IIS-Features für den klassischen ASP-Schwerpunktweb-server zu installieren, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:ServerManagerCmd.exe -install Web-Server ServerManagerCmd.exe -install Web-ASP ServerManagerCmd.exe -install Web-Filtering ServerManagerCmd.exe -install Web-ISAPI-Ext

FastCGI-SchwerpunktserverFastCGI ist eine Alternative zu CGI (Common Gateway Interface). Dabei handelt es sich um eine sprachunabhängige Erweiterung von CGI, die eine hohe Leistung bietet, ohne an eine bestimmte Serverplattform gebunden zu sein.

Hinweis Um weitere Informationen zum FastCGI-Modul für IIS zu erhalten, lesen Sie bitte Bill Staples Blog unter http://blogs.iis.net/bills/archive/2006/10/31/PHP-on-IIS.aspx. Das Blog beschreibt, wie Sie Ihre PHP-Anwendungen mit IIS 7.0- und FastCGI-Modulen erweitern können.

Eines der Designziele von Windows Server 2008 ist die Bereitstellung einer allgemeinen Webserver-plattform für alle Anwendungstypen. Dazu zählen Anwendungen, die auf Microsoft-Technologien basieren, wie z.B. ASP.NET und klassischem ASP, aber auch andere Technologien wie PHP.

Tabelle 5.4 führt alle Komponenten auf, die installiert werden, wenn Sie Ihren Server als FastCGI-Schwerpunktserver konfigurieren. Die Tabelle enthält auch die entsprechenden Updatenamen.


ASP IIS-ASP

ISAPI-Erweiterungen IIS-ISAPI-Extensions

Tabelle 5.4 Installationsoptionen für einen FastCGI-Schwerpunktserver





Tabelle 5.3 Installationsoptionen für den klassischen ASP-Schwerpunktserver (Fortsetzung)




Um mithilfe des Paketmanagers die IIS-Features für einen FastCGI-Schwerpunktserver zu installieren, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer; IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument; IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-ApplicationDevelopment; IIS-CGI;IIS-HealthAndDiagnostics;IIS-HttpLogging; IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security; IIS-RequestFiltering;IIS-HttpCompressionStatic; IIS-WebServerManagementTools;IIS-ManagementConsole; WAS-WindowsActivationService;WAS-ProcessModel; WAS-NetFxEnvironment;WAS-ConfigurationAPI

Um mithilfe von ServerManagerCMD die IIS-Features für einen FastCGI-Schwerpunktserver zu installieren, benutzen die folgende Befehlszeile:ServerManagerCmd.exe -install Web-Server ServerManagerCmd.exe -install Web-CGI

Schwerpunktserver für verwaltete IIS-Module und .NET-ErweiterbarkeitEs ist möglich, .NET zu nutzen, ohne ASP.NET installiert zu haben. Sie fragen sich vielleicht, in welchen Situationen ein solcher Schwerpunktserver benötigt wird. Stellen Sie sich vor, Sie haben eigene benutzerdefinierte HTTP-Module entwickelt, die an Ihre Umgebung angepasst sind. (Dazu könnten Komponenten für das Handling verschiedener Inhalte, Umleitungen, die Sitzungsverwaltung, die Protokollierung und andere benutzerdefinierte Anwendungskomponenten zählen.) Ein solcher Serverschwerpunkt ermöglicht es Ihnen, Server einzurichten, die nur die Module aufweisen, die für Ihre Anwendungen notwendig sind. Sie verfügen dann über die volle IIS 7.0-Leistung, während der Ressourcenbedarf des Webservers äußerst gering ist, wodurch er sicherer wird. Und trotzdem erfüllt dieser Server all Ihre Anforderungen. Die Module für statische Dateien bilden zusammen mit den verwalteten IIS-Modulen und den Modulen für die .NET-Erweiterbarkeit diesen Schwerpunkttyp.

Tabelle 5.5 führt alle Komponenten auf, die installiert werden, wenn Sie Ihren Server als Schwerpunkt-server für verwaltete IIS-Module und die .NET-Erweiterbarkeit konfigurieren. Die Tabelle enthält auch die entsprechenden Updatenamen.








CGI IIS-CGI

Tabelle 5.4 Installationsoptionen für einen FastCGI-Schwerpunktserver (Fortsetzung)




Um mithilfe des Paketmanagers die IIS-Features für Schwerpunktserver zu installieren, die verwaltete IIS-Module und die .NET-Erweiterbarkeit nutzen, verwenden Sie im Fenster der Eingabeaufforderung den folgenden Befehl:start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer; IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument; IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-ApplicationDevelopment; IIS-NetFxExtensibility;IIS-ISAPIExtensions;IIS-ISAPIFilter; IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries; IIS-RequestMonitor;IIS-Security;IIS-RequestFiltering; IIS-HttpCompressionStatic;IIS-WebServerManagementTools; IIS-ManagementConsole;WAS-WindowsActivationService; WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

Um mithilfe von ServerManagerCMD die IIS-Features für Schwerpunktserver zu installieren, die verwaltete IIS-Module und die .NET-Erweiterbarkeit nutzen, verwenden Sie im Fenster der Eingabe-aufforderung den folgenden Befehl:ServerManagerCmd.exe -install Web-Server ServerManagerCmd.exe -install Web-Net-Ext

Vollständige IIS-InstallationWenn Sie alle von IIS 7.0 angebotenen Optionen untersuchen möchten, können Sie innerhalb einer Testumgebung eine vollständige Installation von IIS 7.0 durchführen. Falls Sie alle Module (über vierzig) installieren, können Sie die gesamte Funktionalität nutzen. In einer echten Entwicklungs-umgebung ist eine vollständige Installation jedoch nicht empfehlenswert, da Probleme auftreten könnten, wenn Sie Ihre Anwendungen anschließend in eine Produktionsumgebung migrierten, in der nicht alle Module genutzt würden. Wenn Sie in Ihrer Entwicklungsumgebung nur die wirklich benötigten Module und Features installieren, werden Sie verstehen, welche Module aus welchen Gründen notwendig sind. Dies trägt außerdem dazu bei, dass der Ressourcenbedarf Ihres Produktions-servers nicht zu groß wird, was wiederum eine größere Sicherheit zur Folge hat. Je weniger Module Sie

Tabelle 5.5 Installationsoptionen für Server, die verwaltete IIS-Module und die .NET-Erweiterbarkeit nutzen















einsetzen, desto besser wird auch die Leistung Ihrer Anwendungen sein. Und je besser Sie Ihre Entwicklungsumgebung an Ihren Produktionsserver anpassen, desto wahrscheinlicher ist es, dass der Übergang von der Entwicklung zu Produktion reibungslos verläuft.

Tabelle 5.6 führt alle Komponenten auf, die installiert werden, wenn Sie sich für eine vollständige Installation von IIS 7.0 entscheiden. Die Tabelle enthält auch die entsprechenden Updatenamen.

Tabelle 5.6 Komponenten für eine vollständige Serverinstallation


Internet Information Services IIS-WebServerRole

World Wide Web Services IIS-WebServer

Allgemeine HTTP-Features IIS-CommonHttpFeatures





HTTP-Umleitung IIS-HttpRedirect

Anwendungsentwicklung IIS-ApplicationDevelopment

ASP.NET IIS-ASPNET


ASP IIS-ASP

CGI IIS-CGI

ISAPI-Erweiterungen IIS-ISAPIExtensions

ISAPI-Filter IIS-ISAPIFilter

Serverseitiges Include IIS-ServerSideInclude

Systemzustand und Diagnose IIS-HealthAndDiagnostics

HTTP-Protokollierung IIS-HTTPLogging



Ablaufverfolgung IIS-HttpTracing

Benutzerdefinierte Protokollierung IIS-CustomLogging

ODBC-Protokollierung IIS-ODBCLogging

Sicherheit IIS-Security

Standardauthentifizierung IIS-BasicAuthentication

Windows-Authentifizierung IIS-WindowsAuthentication

Digestauthentifizierung. IIS-DigestAuthentication

Authentifizierung über Clientzertifikatzuordnung IIS-ClientCertificateMappingAuthentication



Um mithilfe des Paketmanagers die IIS-Features für eine vollständige Serverinstallation zu installieren, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer; IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument; IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect; IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility; IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter; IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging; IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing; IIS-CustomLogging;IIS-ODBCLogging;IIS-Security; IIS-BasicAuthentication;IIS-WindowsAuthentication; IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication; IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization; IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;

Authentifizierung über IIS-Clientzertifikatzuordnung IIS-IISCertificateMappingAuthentication

URL-Autorisierung IIS-URLAuthorization


IP- und Domäneneinschränkungen IIS-IPSecurity

Leistung IIS-Performance


Komprimierung dynamischer Inhalte IIS-HttpCompressionDynamic

Verwaltungstools IIS-WebServerManagementTools


IIS-Verwaltungsskripts und -tools IIS-ManagementScriptingTools

Verwaltungsdienst IIS-ManagementService

Kompatibilität mit der IIS 6-Verwaltung IIS-IIS6ManagementCompatibility

Kompatibilität mit der IIS-Metabasis IIS-Metabase

Kompatibilität mit WMI für IIS 6 IIS-WMICompatibility

IIS 6-Skripttools IIS-LegacyScripts

IIS 6-Verwaltungskonsole IIS-LegacySnapIn

FTP-Publishingdienst IIS-FTPPublishingService

FTP-Server IIS-FTPServer

FTP-Verwaltungskonsole IIS-FTPManagement

Windows-Prozessaktivierungsdienst WAS-WindowsActivationService

Prozessmodell WAS-ProcessModel

.NET-Umgebung WAS-NetFxEnvironment

Konfigurations-APIs WAS-ConfigurationAPI

Tabelle 5.6 Komponenten für eine vollständige Serverinstallation (Fortsetzung)




IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic; IIS-WebServerManagementTools;IIS-WebServerManagementTools; IIS-ManagementConsole;IIS-ManagementScriptingTools; IIS-ManagementService;IIS-IIS6ManagementCompatibility; IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts; IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer; IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel; WAS-NetFxEnvironment;WAS-ConfigurationAPI

Um mithilfe von ServerManagerCMD die IIS-Features für eine vollständige Serverinstallation zu installieren, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:ServerManagerCMD.exe –install Web-Server –allSubFeatures

Tabelle 5.7 führt alle ServerManagerCMD-Updatenamen auf. Möchten Sie mit ServerManagerCMD eine vollständige Installation durchführen, sollten Sie darauf achten, dass Sie dazu lediglich den Parameter -a benötigen. Lesen Sie Tabelle 5.7, wenn Sie nur bestimmte Module installieren möchten.

Tabelle 5.7 Vollständige Liste der ServerManagerCMD-Updatenamen


Allgemeine HTTP-Features Web-Common-Http

Statischer Inhalt Web-Static-Content

Standarddokument Web-Default-Doc

Verzeichnis durchsuchen Web-Dir-Browsing

HTTP-Fehler Web-Http-Errors

HTTP-Umleitung Web-Http-Redirect

Anwendungsentwicklung Web-App-Dev

ASP.NET Web-Asp-Net

.NET-Erweiterbarkeit Web-Net-Ext

ASP Web-ASP

CGI Web-CGI

ISAPI-Erweiterungen Web-ISAPI-Ext

ISAPI-Filter Web-ISAPI-Filter

Serverseitiges Include Web-Includes

Systemzustand und Diagnose Web-Health

HTTP-Protokollierung Web-Http-Logging

Protokollierungstools Web-Log-Libraries

Anforderungsüberwachung Web-Request-Monitor

Ablaufverfolgung Web-Http-Tracing

Benutzerdefinierte Protokollierung Web-Custom-Logging

ODBC-Protokollierung Web-ODBC-Logging

Sicherheit Web-Security



Server Core Web Edition-SchwerpunktserverMit Windows Server 2008 wurde Server Core eingeführt, ein vollständiges Befehlszeilen-Shell-Betriebssystem.

Hinweis Eine gute Einleitung zum Thema IIS 7.0 Server Core ist unter http://www.iis.net/articles/view.aspx/IIS7/Explore-IIS7/Getting-Started/IIS7-on-Server-Core verfügbar.

Standardauthentifizierung Web-Basic-Auth

Windows-Authentifizierung Web-Windows-Auth

Digestauthentifizierung Web-Digest-Auth

Authentifizierung über Clientzertifikatzuordnung Web-Client-Auth

Authentifizierung über IIS-Clientzertifikatzuordnung Web-Cert-Auth

URL-Autorisierung Web-Url-Auth

Anforderungsfilterung Web-Filtering

IP- und Domäneneinschränkungen Web-IP-Security

Leistung Web-Performance

Komprimierung statischer Inhalte Web-Stat-Compression

Komprimierung dynamischer Inhalte Web-Dyn-Compression

Verwaltungstools Web-Mgmt-Tools

IIS-Verwaltungskonsole Web-Mgmt-Console

IIS-Verwaltungsskripts und -tools Web-Scripting-Tools

Verwaltungsdienst Web-Mgmt-Service

Kompatibilität mit der IIS 6-Verwaltung Web-Mgmt-Compat

Kompatibilität mit der IIS 6-Metabasis Web-Metabase

Kompatibilität mit WMI für IIS 6 Web-WMI

IIS 6-Skripttools Web-Lgcy-Scripting

IIS 6-Verwaltungskonsole Web-Lgcy-Mgmt-Console

FTP-Publishingdienst Web-Ftp-Publishing

FTP-Server Web-Ftp-Server

FTP-Verwaltungskonsole Web-Ftp-Mgmt-Console

Windows-Prozessaktivierungsdienst WAS

Prozessmodell WAS-Process-Model

.NET-Umgebung WAS-NET-Environment

Konfigurations-APIs WAS-Config-APIs

Tabelle 5.7 Vollständige Liste der ServerManagerCMD-Updatenamen (Fortsetzung)




Server Core bietet eine Installationsoption, die einen Server generiert, der eine Art Appliance darstellt. Herkömmliche Benutzeroberflächenkomponenten wie der Microsoft Internet Explorer unter Windows Media Player werden nicht installiert. Server Core Web Edition ist besonders dann für das IIS 7.0-Hosting geeignet, wenn Sie mit klassischem ASP, statischen und auf PHP basierenden Inhalten, ISAPI (Internet Server Application Programming Interface) oder mit anderen Webanwendungen arbeiten möchten, die kein .NET erfordern. Server Core bietet keine ASP.NET- und .NET-Funktionalität. Doch selbst ohne ASP.NET können Sie Server Core Web Edition für verschiedene Serverschwerpunkte verwenden. Sie können Server Core beispielsweise benutzen, um Bilder bereitzustellen. Für diesen Serverschwerpunkt sind nur zwei Module erforderlich: StaticFileModule und AnonymousAuthentica-tionModule. Das folgende Beispiel zeigt die Leistungsfähigkeit und Flexibilität der modularen IIS 7.0-Architektur.

Installieren von IIS 7.0 unter Server Core Web EditionUm IIS 7.0 unter Server Core Web Edition zu installieren, gehen Sie wie folgt vor:

1. Installieren Sie Server Core Web Edition und konfigurieren Sie die Server Core-Instanz mit einer IP-Adresse. Sie müssen mit zwei Befehlen arbeiten, um eine IP-Adresse für Ihren Server zu konfi-gurieren. Geben Sie den folgenden Befehl an der Eingabeaufforderung ein:netsh interface ipv4 show interfaces

Sie erhalten dann eine ähnliche Ausgabe wie die folgende:Idx Met MTU Status Name --- --- ----- ----------- ------------------- 2 10 1500 connected Local Area Connection 1 50 4294967295 connected Loopback Pseudo-Interface

Geben Sie anschließend den folgenden Befehl an der Eingabeaufforderung ein (ersetzen Sie die IP-Informationen durch die entsprechenden Werte Ihrer Umgebung):netsh interface ipv4 set address name="2" source=static address=192.168.0.10 mask=255.255.255.0 gateway=192.168.0.1

2. Um nun eine Standardinstallation von IIS 7.0 durchzuführen, lassen Sie an der Eingabeaufforde-rung den folgenden Befehl ausführen:start /w pkgmgr /iu:IIS-WebServerRole;WAS-WindowsActivationService; WAS-ProcessModel

3. Sichern Sie die aktuelle applicationHost.config-Datei, indem Sie an der Eingabeaufforderung den folgenden Befehl eingeben:%windir%\System32\Inetsrv\appcmd add backup “ContosoComConfig”

4. Öffnen Sie mit dem Windows-Editor die Datei %windir%\System32\Inetsrv\Config\Applicati-onHost.config. Dazu nehmen Sie an der Eingabeaufforderung die folgende Eingabe vor:Notepad %windir%\system32\inetsrv\config\applicationHost.config

5. Lokalisieren Sie den Abschnitt für die globalen Module und ändern Sie ihn wie folgt: <globalModules> <add name="StaticFileModule" image="%windir%\system32\inetsrv\static.dll" /> <add name="AnonymousAuthenticationModule" image="%windir%\system32\inetsrv\authanon.dll" /> <add name="HttpLoggingModule" image="%windir%\system32\inetsrv\loghttp.dll" /> </globalModules>



6. Lokalisieren Sie in applicationHost.config den Abschnitt Modules und ändern Sie ihn wie folgt: <modules> <add name="StaticFileModule" lockItem="true" /> <add name="AnonymousAuthenticationModule" lockItem="true" /> <add name="HttpLoggingModule" lockItem="true" /> </modules>

7. Öffnen Sie auf einem Remotecomputer einen Browser und besuchen Sie http://<IPAdresseVonSer-verCore>/welcome.png.

Daraufhin sollte das Begrüßungsbild angezeigt werden.

Auf dem Server Core-Computer können Sie von einer Eingabeaufforderung aus verifizieren, dass nur drei auf IIS 7.0 bezogene Module geladen sind. Lassen Sie dazu an der Eingabeaufforderung den folgenden Befehl ausführen:tasklist /m /fi "Imagename eq w3wp.exe"

Sie erhalten dann eine ähnliche Ausgabe wie die folgende:Imagename PID Module ========================= ======== ============================================ w3wp.exe 1108 ntdll.dll, kernel32.dll, ADVAPI32.dll, RPCRT4.dll, msvcrt.dll, USER32.dll, GDI32.dll, ole32.dll, IISUTIL.dll, CRYPT32.dll, MSASN1.dll, USERENV.dll, Secur32.dll, WS2_32.dll, NSI.dll, IMM32.DLL, MSCTF.dll, LPK.DLL, USP10.dll, NTMARTA.DLL, WLDAP32.dll, PSAPI.DLL, SAMLIB.dll, w3wphost.dll, OLEAUT32.dll, nativerd.dll, XmlLite.dll, IISRES.DLL, rsaenh.dll, CLBCatQ.DLL, mlang.dll, comctl32.dll, SHLWAPI.dll, iiscore.dll, W3TP.dll, w3dt.dll, HTTPAPI.dll, slc.dll, faultrep.dll, VERSION.dll, mswsock.dll, DNSAPI.dll, NLAapi.dll, IPHLPAPI.DLL, dhcpcsvc.DLL, WINNSI.DLL, dhcpcsvc6.DLL, wshtcpip.dll, wship6.dll, static.dll, authanon.dll, loghttp.dll

Beachten Sie, dass die letzten drei DLLs (Dynamic Link Library) static.dll, authanon.dll und loghttp.dll sind. Die DLLs werden in derselben Reihenfolge geladen, in der sie in applicationHost.config aufgelistet sind. Die anderen Module sind auf das Betriebssystem bezogen.

Dieses Beispiel zeigt einen leichten, aber flexiblen Server, der Bilder bereitstellen und Hits in den IIS-Standardprotokollen verzeichnen kann. Sie können Ihre gewohnten Programme zum Generieren von Webberichten verwenden, um die bereitgestellten Bilder nachzuverfolgen.

Vorsicht Sichern Sie Ihre applicationHost.config-Datei, bevor Sie diese manuell bearbeiten. Wenn Sie dies tun, können Sie Ihren Server in den ursprünglichen Zustand zurückversetzen, sobald sich Probleme ergeben. Das Wiederherstellen Ihrer applicationHost.config-Datei sollte nicht zur Gewohnheit werden. Sie sollten den Wiederher-stellungsbefehl nur dann geben, wenn Probleme auftreten oder Sie wie in diesem Beispiel den Server in den ursprünglichen Zustand zurückversetzen möchten.



Durch die modulare Architektur von Windows Server 2008 ist es möglich, das Server-Setup anzu-passen. Mit Ausnahme des zuvor präsentierten Server Core-Schwerpunktservers stellen die in diesem Kapitel vorgestellten Beispiele übliche Schwerpunktszenarien dar, die Aufschluss darüber geben, wie Sie IIS 7.0 an die Bedürfnisse Ihrer Anwendungen anpassen.

Hinweis Um weitere Informationen darüber zu erhalten, wie Sie IIS 7.0 bei einer Server Core-Installation von Windows Server 2008 verwalten, besuchen Sie bitte http://blogs.iis.net/metegokt/archive/2007/06/26/administering-iis7-on-server-core-installations-of-windows-server-2008.aspx.

Möglichkeiten der Installation von IIS 7.0Server-Manager, der Paketmanager (Pkgmgr.exe) und ServerManagerCMD sind drei grundlegende Tools, die Sie für die Installation von IIS 7.0 verwenden können. Wenn Sie IIS 7.0 in einem Unter-nehmen einrichten, sollten Sie außerdem einige Alternativen kennen. Die folgenden Abschnitte ent-halten wesentliche Hinweise und Tipps, die Sie berücksichtigen sollten, wenn Sie mit den verschie-denen Tools und Optionen für die IIS 7.0-Installation arbeiten.

Mit dem Server-Manager arbeitenBevor Sie IIS 7.0 installieren, sollten Sie sich der Tatsache bewusst sein, dass es Benutzerkonten mit geringstmöglichen Rechten (Least-Privileged User Accounts, LUA) gibt. Das Ziel der Benutzerkonten-steuerung von Windows besteht darin, das Gefahrenpotenzial und die Angriffsfläche zu verkleinern. Sie verlangt, dass für alle Benutzer der Standardbenutzermodus verwendet wird. Wenn Sie sich nicht über das integrierte Konto des lokalen Administrators angemeldet haben, können Sie, wie in Abbildung 5.1 dargestellt, gelegentlich mit Sicherheitswarnungen in Form von Dialogfeldern konfrontiert werden.

Abbildung 5.1 Windows-Sicherheit (Benutzerkontensteuerung)

Administratorrechte für den lokalen BenutzerStellen Sie sicher, dass Sie sich entweder über das integrierte Administratorkonto anmelden oder Ihre Anwendungen unter Verwendung der Anmeldeinformationen für das integrierte Administratorkonto starten. Dazu können Sie das Befehlszeilentool runas benutzen. Um beispielsweise den Windows-Editor zu starten, können Sie den folgenden Befehl aufrufen:runas /user:Administrator Notepad.exe

Sie werden dann aufgefordert, das Kennwort des Administratorkontos einzugeben.



Hinweis Es ist nützlich, mit einer Eingabeaufforderung zu arbeiten, die bereits über erhöhte Rechte verfügt. Sie können eine solche Shell mit dem folgenden Befehl starten:runas /user:administrator cmd.exe

Jede Anwendung, die Sie aus dieser Eingabeaufforderung heraus starten, arbeitet ebenfalls mit den erhöhten Rechten, so dass Sie das Befehlszeilentool runas nicht verwenden müssen.

IIS 7.0 mit dem Server-Manager installierenDer Server-Manager stellt eine einzelne Konsole zur Verfügung, mit der Sie unter Windows Server 2008 alle administrativen Aufgaben lösen können. Wenn Sie sich zum ersten Mal an Windows Server 2008 anmelden, sollte der Server-Manager automatisch gestartet werden. Um den Server-Manager manuell aus dem Startmenü heraus zu starten, klicken Sie auf Alle Programme, Verwaltung und dann auf Server-Manager.

Führen Sie die folgenden Schritte aus, um die Webserverrolle (IIS) mithilfe des Server-Managers zu installieren:

1. Starten Sie den Server-Manager.

2. Markieren Sie Rollen und klicken Sie auf Rollen hinzufügen.

3. Befolgen Sie die Anweisungen des Assistenten zum Hinzufügen von Rollen und wählen Sie die IIS-Features, die Sie installieren möchten.

Hinweis Der folgende Artikel leitet Sie durch die IIS 7.0-Installation mithilfe des Server-Managers: http://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Install-IIS7-on-Longhorn-Server?Page=2.

Den Paketmanager verwendenOptionale Windows-Features können sowohl unter Windows Vista als auch unter Windows Server 2008 mit dem Paketmanager (pkgmgr) installiert werden. Der Paketmanager wird mithilfe der folgenden Befehlszeilensyntax gesteuert:start /w pkgmgr.exe /iu:update1:update2...

Hinweis Wenn Sie den Paketmanager ohne den ersten Parameter /w ausführen lassen, gibt der Befehl pkgmgr die Steuerung sofort an Sie zurück, so dass Sie nicht wissen, wann die Installation abgeschlossen ist.

Die nachstehende Liste führt die gebräuchlichsten Befehle des Paketmanagers auf. Um eine voll-ständige Liste der verfügbaren Befehle zu erhalten, lassen Sie die folgende Anweisung ausführen:Pkgmgr.exe /?

� /iu:{update name}; Gibt die zu installierenden Updates über den jeweiligen Updatenamen an. Sie können mehrere zu installierenden Updates festlegen, indem Sie diese durch Semikola voneinander trennen.

� /uu:{update name}; Gibt die zu deinstallierenden Updates an. Sie können mehrere zu deinstal-lierende Updates festlegen, indem Sie diese durch Semikola voneinander trennen. Es muss mindes-tens ein Update-Name angegeben werden.

� /n:{unattend XML} Gibt eine XML-Datei an, die Informationen zu einer unbeaufsichtigten Instal-lation enthält. (Weitere Informationen zur Durchführung einer unbeaufsichtigten Installation erhal-ten Sie später in diesem Kapitel im Abschnitt »Antwortdateien für unbeaufsichtigte Installationen«.)



Hinweis Weitere Informationen über IIS.NET und den Paketmanager finden Sie unter http://www.iis.net//articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Install-IIS7-from-the-Command-Line.

ServerManagerCMD verwendenSie können ServerManagerCMD in Verbindung mit der Benutzeroberflächenversion des Server-Managers verwenden, um auf dem Server Rollen und Features abzufragen, zu installieren und zu entfernen. ServerManagerCMD zeigt außerdem alle Rollen, Rollendienste und verfügbaren Features an und es gibt Aufschluss darüber, welche dieser Komponenten auf dem Computer installiert sind. Sie können an der Eingabeaufforderung den folgenden Befehl ausführen lassen:ServerManagerCMD.exe -query

Abbildung 5.2 zeigt ein Beispiel für die resultierende Ausgabe.

Wollten Sie beispielsweise die Webserverrolle installieren, könnten Sie den folgenden Befehl ver-wenden:ServerManagerCmd -install Web-Server

Sie können die Installationsaktionen außerdem in einem XML-Dokument wie dem folgenden ver-merken (die xmlns-Zeichenfolge wurde aus Gründen der besseren Lesbarkeit in mehrere Zeilen umbrochen):<ServerManagerConfiguration Action="Install" xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager /Configuration/2007/1"> <Role Id="Web-Server"/> </ServerManagerConfiguration>

Abbildung 5.2 Eine ServerManagerCMD-Abfrage der aktuellen Module



Wäre der XML-Code in einer Datei namens WebServerInstall.xml gespeichert, könnten Sie im Fenster der Eingabeaufforderung den folgenden whatIf-Parameter benutzen, um zu ermitteln, welche Kompo-nenten gemäß der Eingabedatei installiert würden.ServerManagerCmd.exe -inputPath WebServerInstall.xml –whatIf

Die resultierende Ausgabe ist in Abbildung 5.3 dargestellt.

Abbildung 5.3 ServerManagerCMD-Ausgabe bei Einsatz des Parameters -whatIf

Um die Webserverinstallation tatsächlich durchzuführen, lassen Sie den folgenden Befehl ausführen:ServerManagerCmd –inputPath WebServerInstall.xml

Denken Sie daran, dass Sie mit der folgenden Abfrage arbeiten können, wenn Sie ermitteln möchten, welche Rollen und Features installiert sind:ServerManagerCmd -query

Um die Liste der installierten Rollen und Features in einer XML-Datei zu speichern, benutzen Sie den folgenden Befehl:ServerManagerCmd -query currentConfig.xml

Wenn Sie die Datei Currentconfig.xml betrachten, finden Sie alle Informationen, die Ihnen verraten, welche Rollen und Features auf einem Server installiert werden.

Nachfolgend ist die vollständige Syntax von ServerManagerCMD aufgeführt: -query [<query.xml>] [-logPath <log.txt>] -install <name> [-setting <setting name>=<setting value>]* [-allSubFeatures] [-resultPath <result.xml> [-restart] | -whatIf] [-logPath <log.txt>] -remove <name> [-resultPath <result.xml> [-restart] | -whatIf] [-logPath <log.txt>] -inputPath <answer.xml> [-resultPath <result.xml> [-restart] | -whatIf] [-logPath <log.txt>] -help | -? -version



Switch-Parameter: -query [<query.xml>] Zeigt eine Liste aller verfügbaren Rollen, Rollendienste und Features an, und gibt Aufschluss darüber, welche dieser Komponenten auf dem Computer installiert sind. (Kurzform: -q) Wenn <query.xml> angegeben ist, werden die Informationen ebenfalls im XML-Format in einer Datei namens query.xml gespeichert. -inputPath <answer.xml> Installiert oder entfernt die Rollen, Rollendienste und Features, die in einer XML-Antwortdatei angegeben sind. <answer.xml> steht für den Pfad und Namen der Antwortdatei. (Kurzform: -ip) -install <name> Installiert auf dem Computer die Rolle, den Rollendienste oder das Feature, das mit dem Parameter <name> angegeben wird. (Kurzform: -i) -setting <setting name>=<setting value> Wird mit dem Parameter -install verwendet, um die erforderlichen Einstellungen für die Installation anzugeben. (Kurzform: -s) -allSubFeatures Wird mit dem Parameter -install verwendet, dem der Name der zu installierenden Rolle, des Rollendienstes oder des Features übergeben wird. Alle untergeordneten Rollendienste und Features werden ebenfalls installiert. (Kurzform: -a) -remove <name> Entfernt die Rolle, den Rollendienst oder das Feature von dem Computer, der mit dem Parameter <name> angegeben wurde. (Kurzform: -r) -resultPath <result.xml> Speichert das Ergebnis der ServerManagerCmd.exe-Operation im XML-Format in einer <result.xml>-Datei. (Kurzform: -rp) -restart Startet den Computer automatisch neu, sofern ein Neustart erforderlich ist, um die Operation abzuschließen. -whatIf Zeigt an, welche Operationen in der Datei answer.xml angegeben sind und auf dem aktuellen Computer ausgeführt werden sollen. (Kurzform: -w) -logPath <log.txt> Legt einen nicht der Vorgabe entsprechenden Speicherort für die Protokolldatei fest. (Kurzform: -l) -help Zeigt Hilfeinformationen an. (Kurzform: -?) -version Zeigt die Version des gegenwärtig ausgeführten Server-Manager-Befehls, Microsoft-Schutzmarkeninformationen und die Betriebssystemversion an. (Kurzform: -v)

Beispiele: ServerManagerCmd.exe -query ServerManagerCmd.exe -install Web-Server -resultPath installResult.xml ServerManagerCmd.exe -inputPath install.xml -whatIf

Antwortdateien für unbeaufsichtigte InstallationenDie unter Windows Server 2008 und IIS 7.0 verwendeten Antwortdateien für unbeaufsichtigte Installa-tionen liegen nun im Gegensatz zu früheren Windows-Versionen im XML-Format vor. Eine Antwort-datei stellt ein einheitliches, wiederholbares Verfahren für die Installation von IIS 7.0 auf mehreren Servern dar. Der Paketmanager und ServerManagerCMD können mit Antwortdateien arbeiten. Jedes Tool verlangt ein etwas anderes Format, wenn es mit einer Antwortdatei arbeitet. Dieser Abschnitt untersucht Beispielantwortdateien für beide Tools.


Der Paketmanager ist ein systemeigenes Tool von Windows Server 2008, das zum Installieren von IIS 7.0 zur Verfügung gestellt wird. Um ein wenig mit nicht beaufsichtigten Installationen zu experimen-tieren, benutzen Sie den Windows-Editor und erstellen die folgende Beispielantwortdatei, die Sie unter Unattend.xml speichern.

Auf der Begleit-CD Diese Antwortdatei befindet sich auch auf der diesem Buch beiliegenden CD.

Sie müssen die version- und processorArchitecture-Einstellungen für Ihre Umgebung ermitteln und im folgenden Code die fett gedruckten Zeilen entsprechend ändern, bevor Sie mit dem Paketmanager eine unbeaufsichtigte Installation durchführen können.

Hinweis Um die Versionsnummer abzurufen, öffnen Sie den Windows-Explorer, wechseln zu %windir%\ System32, klicken mit der rechten Maustaste auf Regedt32.exe und wählen Eigenschaften. Öffnen Sie die Registerkarte Details, lokalisieren Sie die Eigenschaft Dateiversion (wie in Abbildung 5.4 dargestellt), und benutzen Sie diesen Wert in Ihrer Unattend.xml-Datei für die Einstellung version. Um die Architekturinformationen abzurufen, lassen Sie im Fenster der Eingabeaufforderung den Befehl Set ausführen und suchen nach der Variablen processor_architecture.

Abbildung 5.4 Die Dateiversion ermitteln

<?xml version="1.0" ?> <unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"> <servicing>  <package action="configure"> <assemblyIdentity


name="Microsoft-Windows-Foundation-Package" version="6.0.XXXX.XXXXX" language="neutral" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> <selection name="IIS-WebServerRole" state="true"/> <selection name="WAS-WindowsActivationService" state="true"/> <selection name="WAS-ProcessModel" state="true"/> <selection name="WAS-NetFxEnvironment" state="true"/> <selection name="WAS-ConfigurationAPI" state="true"/> </package> </servicing> </unattend>

Um den Installationsvorgang zu starten, geben Sie an der Eingabeaufforderung den folgenden Befehl ein:pkgmgr /n:unattend.xml

Sie können Ihre XML-Antwortdatei für die unbeaufsichtigte Installation in einem freigegebenen Netzwerkordner speichern und den Paketmanager auf diese Datei verweisen. Die Arbeit mit nur einer Installationsdatei vereinfacht die Verwaltung Ihrer Installationen.

ServerManagerCMD ist die Befehlszeilenversion des Server-Managers. Die Syntax der Antwortdatei für unbeaufsichtigte Installationen unterscheidet sich ein wenig von der entsprechenden Paketmanager-Syntax. Mit Ausnahme der Server Core-Edition können Sie ServerManagerCMD für alle Versionen von Windows Server 2008 verwenden.

Nachfolgend ist eine Beispieldatei aufgeführt, die Sie für ServerManagerCMD verwenden können. Das Beispiel zeigt die Installation eines Webservers für statische Inhalte. Speichern Sie die folgenden Daten auf Ihrem lokalen Datenträger in einer Datei namens Default.xml (auch hier wurde die xmlns-Zeichen-folge aus Gründen der besseren Lesbarkeit umbrochen).

Auf der Begleit-CD Diese Datei befindet sich ebenfalls auf der dem Buch beiliegenden CD.

<ServerManagerConfiguration Action="Install" xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager /Configuration/2007/1"> <Role Id="Web-Server" /> </ServerManagerConfiguration>

Um diese Antwortdatei mit ServerManagerCMD zu benutzen, öffnen Sie die Eingabeaufforderung und nehmen die folgende Eingabe vor:ServerManagerCMD.exe –inputPath Default.xml

Hinweis Weitere Informationen zu ServerManagerCMD und verschiedenen Schwerpunktservern finden Sie unter http://blogs.iis.net/metegokt/archive/2007/04/13/installing-iis-7-0-using-servermanagercmd-exe.aspx.

Sysprep/Neues SetupsystemSysprep wird seit Jahren verwendet, um Standardabbilddateien als Teil der Serverbereitstellung vorzu-bereiten. Windows Server 2008 und IIS 7.0 unterstützen Bereitstellungen, die auf Sysprep basieren. Alternativ zu einer bei jeder Bereitstellung eines neuen Servers erfolgenden Durchführung einer unbe-aufsichtigten Installation können Sie einen einzelnen Server aufbauen und darauf IIS 7.0 – Ihrer



Umgebung entsprechend – installieren und konfigurieren. Wenn Sie mit Sysprep arbeiten, können Sie ein Programm zur Erstellung von Abbildern verwenden, z.B. ImageX, das im WAIK (Windows Auto-mated Installation Kit) enthalten ist. Danach benutzen Sie beispielsweise WDS (Windows Deployment Services), um das Abbild auf den Servern in Ihrer Umgebung bereitzustellen.

Eine Einschränkung, die Sie kennen sollten, wenn Sie Sysprep für eine IIS 7.0-Installation verwenden, ist, dass die Computerschlüsselwerte verschlüsselt und in der Datei applicationHost.config gespeichert werden. Wenn das Abbild auf einen neuen Computer übertragen wird, müssen Sie die Computer-schlüsselwerte als Teil des Postbuildvorgangs bei der ersten Anmeldung korrigieren. Die Art der ersten Anmeldung kann abhängig davon variieren, welche Tools Sie benutzen, um Abbilder in Ihrer Umge-bung bereitzustellen.

Automatische InstallationenMicrosoft hat mit Windows Server 2003 Service Pack 2 (SP2) WDS (Windows Deployment Services) eingeführt.

Windows Server 2008 enthält bereits WDS (Windows Deployment Services). Dabei handelt es sich um den Nachfolger von RIS (Remote Installation Services). WDS verwendet PXE (Pre-Boot Execution Environment), um ein Sysprep-Abbild oder eine Skriptinstallation bereitzustellen.

Unabhängig davon, für welches Tool Sie sich entscheiden, bieten Windows Server 2008 und IIS 7.0 verschiedene Optionen an, die Ihre Serverbereitstellungen vereinfachen.

Hinweis Weitere Informationen zu WDS finden Sie unter http://technet2.microsoft.com/WindowsVista/en/library/9e197135-6711-4c20-bfad-fc80fc2151301033.mspx?mfr=true.

Weitere Informationen zur in Windows Server 2008 enthaltenen WDS-Rolle finden Sie unter http://technet2. microsoft.com/windowsserver2008/en/library/b279dfef-892e-4b12-bb6b-c250cf8c95f41033.mspx?mfr=true.

Windows Server 2008-Setup für optionale FeaturesDie mit Windows Server 2008 eingeführten Hilfsmittel ersetzen die vorherigen Installationstools, wie z.B. Sysocmgr.exe und Setup.exe. Eine allgemeine Installationsbasis bietet viele Vorteile. Windows Server 2008 verfügt deshalb über eine aus verschiedenen Komponenten bestehende Installations-architektur.

Hinweis Weitere Informationen zur Installation optionaler Features finden Sie unter http://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Understanding-Setup-in-IIS7.

Direkt von der Quelle: Welche Features sollen in IIS 7.0 enthalten sein?Während der Entwicklung von Windows Vista dachte das IIS-Team darüber nach, wie das neue modulare Design von IIS 7.0 auf die neuen Installationstechnologien von Windows Vista abgestimmt werden könnte. (Windows Vista und Windows Server 2008 gründen auf derselben Codebasis, so dass viele Windows Server 2008-Technologien zuerst in Windows Vista zu finden waren.) Obwohl natürlich viele spezifische Probleme gelöst werden mussten, entbrannte eine philosophische Debatte darüber, was standardmäßig mit IIS 7.0 installiert werden sollte.


Nach der Installation 137

Nach der InstallationSobald die Installation abgeschlossen ist, besteht eine Ihrer ersten Aufgaben darin, die Dateien appli-cationHost.config, administration.config und redirection.config zu sichern. Diese befinden sich im Ordner %windir%\System32\Inetsrv\Config. Sie können Kopien von diesen Dateien entweder manuell oder wie folgt mit dem Backup-Befehl von Appcmd.exe anlegen:// Eine Sicherung mit Appcmd durchführen %windir%\system32\inetsrv\appcmd.exe add backup "MyBackup"

Diese Aktion kopiert wichtige Dateien in den Ordner %windir%\System32\Inetsrv\Backup\MyBackup. Die Dateien administration.config, applicationHost.config, mbschema.xml, metabase.xml und redirection.config werden an diesem Ort gespeichert.

Nachdem Sie Ihre Konfiguration gesichert haben, verschaffen Sie sich auf der Seite der Webserverrolle (IIS) einen Überblick über den Status von IIS. Verwenden Sie die IIS-Manager-Konsole, um die von Ihnen installierten IIS-Features zu konfigurieren.

Wenn IIS 6.0 installiert wird, besitzt es viele Fähigkeiten, wie z.B. die Digestauthentifizierung, die Komprimierung, die Standarddokumentbehandlung und andere Features, die als selbstverständlich erachtet werden, weil sie immer präsent sind. Bei IIS 7.0 sind diese und andere Features einzelne .dll-Dateien, die mithilfe der verschiedenen Installationstechnologien des Betriebssystems (Server-Manager, ServerManagerCMD oder Paketmanager) installiert oder entfernt werden können. Die Frage, die sich dem IIS-Team stellte, war, ob IIS 7.0 standardmäßig mit den Features installiert werden sollte, die auch bei einer Standardinstallation von IIS 6.0 zum Einsatz kommen, oder ob – weil die neue Architektur modular ist – eine kleine Untermenge der Features genügen würde.

Das Argument für eine IIS 6.0-Äquivalenz ist, dass die Kunden dies erwarten. Außerdem wurde die Standardinstallation von IIS 6.0 immer als sicher erachtet. Das Argument für einen reduzierten Featuresatz ist, dass das allgemein anerkannte Verfahren darin besteht, nur den benötigten Mindest-satz zu installieren und die Kunden explizit entscheiden zu lassen, ob weitere Features genutzt werden sollen.

Letztendlich fiel die Entscheidung auf den Mindestfeaturesatz und ich glaube, dass dies die richtige Entscheidung war. Wenn Sie sich dazu entschließen, ausschließlich die Webserverrolle (IIS) und keine weiteren Optionen zu installieren, besitzt IIS 7.0 nur die Fähigkeit, statische, anonyme Inhalte bereitzustellen. Sie müssen zusätzliche Features explizit auswählen.

Das Schöne ist, dass der Server-Manager und ServerManagerCMD die für die zugrunde liegenden Pakete festgelegte Abhängigkeiten berücksichtigen, die die Installationskomponenten für die ver-schiedenen Subsysteme bestimmen. Wenn ein Kunde somit ASP.NET installieren möchte, muss er nur diese Option auswählen und das Installationssystem installiert automatisch ISAPI und andere Features, die notwendig sind, um das verlangte Feature zu unterstützen. Auf diese Weise kommt der Kunde in den Genuss eines vorgefertigten sicheren Produkts, wobei das Hinzufügen von Funktio-nalität zum Server sehr einfach ist.

Brett Hill



Ordner und InhalteBenutzen Sie die folgende Aufzählung, um Ihre Installation zu überprüfen. Diese Schlüsseldateien und -ordner speichern die wichtigen Inhalte und Binärdateien von IIS 7.0.

� %windir%\system32\inetsrv Installationsstammordner für alle IIS-Prozesse

� %windir%\system32\inetsrv\config Enthält alle IIS-Konfigurationsdateien, einschließlich applicationHost.config, administration.config und redirection.config. Diese Konfigurationsdateien speichern alle wichtigen, auf IIS bezogenen Konfigurationsinformationen und Daten.

� %windir%\system32\inetsrv\config\schema Speichert alle XML-Schemadefinitionsdateien, die von den Konfigurationsdateien verwendet werden

� %SystemDrive%\inetpub Standardstammordner für IIS-Inhalte. Beachten Sie, dass empfohlen wird, Websites auf einem anderen Laufwerk als %SystemDrive% abzulegen.

� %SystemDrive%\inetpub\AdminScripts Enthält Skripts, die für die Verwaltung von IIS und den damit verbundenen Diensten benötigt werden. Dieser Ordner wird standardmäßig nicht installiert. Dieser Ordner wird nur dann installiert, wenn Kompatibilitätskomponenten installiert werden.

� %SystemDrive%\inetpub\custerr Speicherort für alle benutzerdefinierten IIS-Fehlerwebseiten. Dies ist ein neuer Speicherort unter IIS 7.0.

� %SystemDrive%\inetpub\history Enthält die Konfigurationssicherungen, die von den IIS 7.0-Features für den Konfigurationsverlauf (ConfigHistory) automatisch angelegt wurden. Lesen Sie das vierte Kapitel, »Verstehen des Konfigurationssystems«, um weitere Informationen zu erhalten.

� %SystemDrive%\inetpub\ftproot FTP-Standardstammordner für den integrierten FTP-Publishingdienst

� %SystemDrive%\inetpub\logs\failedreqlogfiles Speicherort für alle Ereignisablaufverfol-gungen für Anforderungsfehler. Dies ist ein neuer Speicherort unter IIS 7.0.

Hinweis Die Protokolle für den integrierten FTP-Publishingdienst und den SMTP-Dienst werden standardmäßig in %windir%\System32\LogFiles gespeichert.

� %SystemDrive%\inetpub\mailroot Stammordner für alle auf den SMTP-Dienst bezogenen Prozesse. Wird standardmäßig nicht installiert.

� %SystemDrive%\inetpub\temp Wird von ASP.NET und IIS verwendet, um kompilierte ASP-Vorlagen und temporär komprimierte IIS-Dateien zu speichern

� %SystemDrive%\inetpub\wwwroot Stammordner für die Standardwebsite (Default Web Site). Beachten Sie, dass empfohlen wird, Websites auf einem anderen Laufwerk als %SystemDrive% abzulegen.

� %windir%\IIS7.log Setupprotokolldateien zum Aufzeichnen der Installation

� %windir%\system32\inetsrv\config\applicationHost.config Von IIS verwendete Kernkonfi-gurationsdatei. Dies ist die Hauptdatei, die die Metabasis von früheren IIS-Versionen ersetzt.


Nach der Installation 139

RegistrierungDie IIS 7.0-Installation zeichnet auch im folgenden Registrierungsschlüssel Informationen darüber auf, was installiert wurde:HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\.

Dieser Registrierungsschlüssel führt nur die Elemente auf, die gegenwärtig installiert sind. Module, die noch nicht installiert oder die deinstalliert wurden, werden nicht aufgelistet.

Hinweis Weitere Informationen zu diesem Thema und eine Referenztabelle, die jeden Registrierungsschlüssel-wert aufführt, finden Sie unter http://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Dis-cover-Installed-Components.

DiensteTabelle 5.8 ist eine Liste der Systemdienste, die während der Installation einer Webserverrolle installiert werden, wenn alle Rollendienst ausgewählt sind.

ÜberprüfungUm die Webserverrolle (IIS) zu überprüfen, können Sie den Server-Manager öffnen und die Serverrolle Webserver (IIS) auswählen. Daraufhin wird eine zentrale Konsole zur Verfügung gestellt, mit der es möglich ist, Ereignisprotokolle, auf IIS bezogene Dienste und andere verwandte Dienste einzusehen. Sie können die IIS-Manager-Konsole auch direkt aus der Programmgruppe Verwaltung heraus öffnen (der Eintrag heißt Internetinformationsdienste-Manager). Eines der in der IIS-Manager-Konsole ent-haltenen Features, das Sie verwenden können, um Ihre Installation überprüfen, ist Module. Führen Sie einen Doppelklick auf Module aus, um zu ermitteln, ob die richtigen Module installiert sind.

Tabelle 5.8 Liste der Systemdienste, die mit der Webserverrolle installiert werden

Dienstname Beschreibung

ASP.NET-Statusdienst Unterstützt die prozessexterne ASP.NET-Sitzungszustandsverwaltung. Wenn die-ser Dienst beendet wird, werden keine Out-of-Process-Anforderungen verarbeitet.

IIS-Verwaltungsdienst Ermöglicht diesem Server die Verwaltung von FTP-Metabasisdiensten. Wenn die-ser Dienst beendet wird, kann der Server weder die Metabasis- noch FTP-Sites ausführen.

Webverwaltungsdienst Bietet Remote- und delegierte Verwaltungsfunktionen für Administratoren zur Ver-waltung des Webservers, der Websites und der Anwendungen auf dem Computer

Windows-Prozessaktivierungsdienst (WAS) Bietet Dienste zur Prozessaktivierung, Ressourcenverwaltung und Zustandsverwal-tung von Anwendungen, die eine Aktivierung durch Nachrichten unterstützen

WWW-Publishingdienst Stellt die Webkonnektivität und die Webverwaltung mithilfe des IIS-Managers zur Verfügung

FTP-Publishingdienst (integriert) Ermöglicht es dem aktuellen Server, als FTP-Server (File Transfer Protocol) zu fungieren



WebbenutzeroberflächeIIS 7.0 verwendet einen vollständig neuen IIS-Manager. Diese Anwendung nutzt nur eine Benutzer-oberfläche, um alle IIS 7.0-Website- und ASP.NET-Einstellungen zu verwalten. Windows Server 2008 stellt außerdem den Internetinformationsdienste 6.0-Manager zur Verfügung, mit dem die integrierten Dienste FTP-Publishing und SMTP verwaltet werden können. Kapitel 6, »Verwenden von IIS-Manager«, hält weiterführende Informationen zur Arbeit mit dem IIS-Manager bereit.

Benutzer und Gruppen unter Windows Server 2008Für IIS 7.0 wurden Windows Server 2008 neue Konten und Gruppen hinzugefügt. Das Konto IUSR ersetzt das Konto IUSR_MachineName. Dies ist die Standardidentität, die verwendet wird, wenn die anonyme Authentifizierung aktiviert ist. Das Konto IUSR_MachineName wird auch weiterhin generiert und verwendet, aber nur dann, wenn der FTP-Server installiert ist. Falls FTP nicht installiert ist, wird das Konto nicht erzeugt.

Die Gruppe IIS_IUSRS ersetzt die Gruppe IIS_WPG. Die integrierte IIS_IUSRS-Gruppe darf auf alle erforderlichen Datei- und Systemressourcen zugreifen, so dass ein Konto als Anwendungspoolidentität agieren kann, wenn es dieser Gruppe hinzugefügt wird.

Sowohl das Konto IUSR als auch die Gruppe IIS_IUSRS sind in Windows Server 2008 integriert. Das IUSR-Konto ist ein eingeschränktes Konto und erfordert deshalb kein Kennwort. Dies ermöglicht es Ihnen, xcopy.exe /o zu benutzen, um Dateien zusammen mit den entsprechenden Besitzer- und ACL-Informationen (Access Control List) problemlos auf andere Computer zu kopieren. (Beachten Sie, dass diese Benutzerkonten nicht lokalisiert sind. Unabhängig von der Sprache, die Sie für Ihre Windows-Installation verwendet haben, heißt das IIS-Konto immer IUSR, und der Gruppenname lautet immer IIS_IUSRS.) Das IUSR-Konto ist vom selben Kontotyp wie die Konten NETZWERKDIENST und LOKALER DIENST. Es hat auf allen Computern dieselbe SID (Security Identifier).

Behandlung von InstallationsproblemenDer neue deklarative XML-Installationsprozess stellt umfassende und detaillierte Protokollinforma-tionen zur Verfügung. Dies kann hilfreich sein, wenn Sie feststellen möchten, ob die Installation erfolgreich war. Sie können auf verschiedene Bereiche zurückgreifen, um den erfolgreichen Abschluss der Installation überprüfen. Sie können mit den herkömmlichen Windows-Ereignisprotokollen, der Datei IIS7.log und der ServerManagerCMD-Protokolldatei arbeiten. Die zuletzt genannte Datei wird erzeugt, wenn Sie den entsprechenden ServerManagerCMD-Parameter angeben (lesen Sie dazu auch später in diesem Kapitel den Abschnitt »Andere Protokollierungsoptionen«).

EreignisprotokolleSie können die integrierten Ereignisprotokolle Anwendung, Sicherheit und System benutzen, um Probleme zu analysieren und zu ermitteln, ob Ihre Installation erfolgreich war. Dies sind wichtige Informationsquellen, die vom Betriebssystem gepflegt werden. Die Ereignisprotokolle katalogisieren alle Ereignisse. Dazu zählen auch Fehler, die während einer fehlgeschlagenen Installation aufgetreten sind. Auf diese Weise können Sie spezifische Fehler nachverfolgen.


Behandlung von Installationsproblemen 141

IIS 7.0-ProtokollDie neue auf verschiedenen Komponenten basierende Installation bietet eine umfassende und detail-lierte Protokollierung von Informationen, die Ihnen bei der Behandlung von Installationsproblemen helfen. Die meisten Fehler werden durch Benutzer verursacht, die nicht als Administratoren angemeldet sind oder über keine administrativen Rechte verfügen. IIS bietet ein detailliertes Protokoll an, das sich in der Datei %windir%\IIS7.log befindet. Dieses Protokoll enthält einfach zu lesende und beschrei-bende Texte zur Installation jeder einzelnen Komponente. Sie können diese Informationen benutzen, um Probleme zu behandeln, die sich auf Ihre gesamte IIS-Installation oder auf die Installation einer bestimmten Komponente beziehen. Nachfolgend ist ein Beispiel für das IIS-Protokoll aufgeführt:[05/09/2007 00:43:31] [ ***** IIS 7.0 Component Based Setup ***** ] [05/09/2007 00:43:31] "C:\Windows\System32\inetsrv\iissetup.exe" /install SharedLibraries [05/09/2007 00:43:31] Created NetFrameworkConfigurationKey [05/09/2007 00:43:32] Set ACLs on NetFrameworkConfigurationKey [05/09/2007 00:43:32] Created iisWasKey [05/09/2007 00:43:32] Created iisWasKey user key [05/09/2007 00:43:32] Created iisConfigurationKey [05/09/2007 00:43:33] Created iisConfigurationKey user key [05/09/2007 00:43:33] Set ACLs on iisConfigurationKey [05/09/2007 00:43:33] iisConfigurationKey already exists [05/09/2007 00:43:33] Created AesProvider [05/09/2007 00:43:33] Created IISWASOnlyAesProvider [05/09/2007 00:43:33] Install of component SharedLibraries succeeded! [05/09/2007 00:43:33] Success! [05/09/2007 00:43:33] [ End of IIS 7.0 Component Based Setup ]

Immer dann, wenn Sie Installationsprobleme behandeln müssen, ist IIS7.log die erste Anlaufstelle, um nach Fehlern zu suchen.

Andere ProtokollierungsoptionenServerManagerCMD bietet umfassende Protokollierungsmöglichkeiten. Dieser Abschnitt beschreibt, wie die Protokollierung durchgeführt wird, wenn Sie mit ServerManagerCMD arbeiten.

Und die aus Ihrer Installation resultierende Ausgabe zu erfassen, verwenden Sie den folgenden Befehl:ServerManagerCMD.exe –install Web-Server –resultPath InstallResults.xml –logPath InstallResults.txt

Um die aus einer Deinstallation resultierende Ausgabe zu erfassen, benutzen Sie den folgenden Befehl:ServerManagerCMD.exe –remove Web-Server –resultPath UnInstallResults.xml –logPath UnInstallResults.txt

Jedes dieser Ergebnisprotokolle enthält detaillierte Informationen, die Ihnen helfen können, Probleme zu beheben oder den Installationsstatus zu ermitteln. Sie können einen Texteditor wie zum Beispiel den Windows-Editor benutzen, um die Ergebnisse zu betrachten. Wenn Sie mit einem Fehler konfrontiert wurden, können Sie diesen lokalisieren, indem Sie mit der Suchfunktion Ihres Texteditors arbeiten.



Der Paketmanager (pkgmgr.exe) bietet ebenfalls die Möglichkeit der Protokollierung. Er hilft Ihnen auf diese Weise, Probleme zu beheben, die während der Bereitstellung aufgetreten sind. Die Position des Protokollierungsordners und der Protokollierungsdatei ist %windir%\Logs\CBS\CBS.log. Nachfolgend ist ein Auszug zu sehen, der das Protokoll zu einem ausgeführten Befehl zeigt. Dabei handelt es sich um den Befehl, der zum Installieren der Webserverstandardrolle verwendet wird:2007-11-20 05:27:44, Info CBS Pkgmgr: aufgerufen mit: "pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS- ommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS- irectoryBrowsing;IIS-HttpErrors;IIS-HealthAndDiagnostics;IIS- ttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security;IIS- equestFiltering;IIS-HttpCompressionStatic;IIS-WebServerManagementTools; IS-ManagementConsole;WAS-WindowsActivationService;WAS-ProcessModel;WAS- etFxEnvironment;WAS-ConfigurationAPI" 2007-11-20 05:27:44, Info CSI 0000001@2007/11/20:13:27:44.373 WcpInitialize (wcp.dll version 0.0.0.5) aufgerufen (stack @0x700e7ee9 @0xca1672 @0xc9b8fa @0xc9c378 @0x77cb1cc2 @0x77d88785)

IIS 7.0 entfernenDer Server-Manager, ServerManagerCMD und der Paketmanager ermöglichen nicht nur eine einfache Installation von IIS 7.0, sie bieten auch effiziente und einfache Möglichkeiten, um bestimmte Features oder die gesamte Serverrolle Webserver (IIS) zu entfernen.

Die Benutzeroberfläche unter Windows Server 2008 und Windows VistaUm IIS oder die Webserverrolle mit dem Server-Manager zu deinstallieren, gehen Sie wie folgt vor:

1. Starten Sie den Server-Manager, indem Sie im Startmenü auf Alle Programme, Verwaltung und dann auf Server-Manager klicken. Das Fenster des Server-Managers wird daraufhin angezeigt.

2. Markieren Sie im Server-Manager den Eintrag Rollen.

3. Das Fenster Rollenübersicht wird wie in Abbildung 5.5 dargestellt angezeigt.

4. Klicken Sie auf den Link Rollen entfernen, um den Assistenten zum Entfernen von Rollen zu öffnen.

5. Klicken Sie auf Weiter, um die Seite Serverrollen entfernen anzeigen zu lassen.

6. Deaktivieren Sie, wie in Abbildung 5.6 dargestellt, das Kontrollkästchen vor Webserver (IIS), um die Webserverrolle zu deinstallieren.


IIS 7.0 entfernen 143

Abbildung 5.5 Die Rollenübersicht des Server-Managers

Abbildung 5.6 Deaktivieren Sie das Kontrollkästchen vor Webserver (IIS), um die Webserverrolle zu deinstallieren



7. Klicken Sie auf Weiter, um die Seite Entfernungsauswahl bestätigen anzeigen zu lassen, wie in Abbildung 5.7 dargestellt.

Abbildung 5.7 Die Bestätigungsseite des Assistenten zum Entfernen von Rollen

8. Klicken Sie auf Entfernen.

9. Klicken Sie auf Schließen, um zum Server-Manager zurückzukehren. Abhängig von den deinstal-lierten Rollen werden Sie möglicherweise dazu aufgefordert, den Computer neu zu starten. Wenn Sie zum Server-Manager zurückkehren, wird die Webserverrolle entfernt worden sein.

Die BefehlszeilenmethodeSie können entweder den Paketmanager oder ServerManagerCMD benutzen, um die Webserverrolle zu deinstallieren.

Den Paketmanager verwendenDieser Abschnitt zeigt, wie Sie den Paketmanager benutzen, um IIS zu deinstallieren. Dieses Beispiel setzt voraus, dass zuvor alle Komponenten installiert wurden. Hier ist die verwendete Syntax:start /w pkgmgr.exe /uu:{<update name>}

Der Parameter /uu:{<update name>} gibt die zu deinstallierenden Updates an. Sie können mehrere Updates auflisten, indem Sie diese durch Semikola voneinander trennen. Mindestens ein Updatename muss angegeben werden.

Hinweis /uu zeigt eine Deinstallation an. Hinter dem Parameter müssen die gewünschten Updatenamen ange-geben werden.


Zusammenfassung 145

Der folgende Paketmanagerbefehl deinstalliert alle Komponenten, die sich auf die Serverrolle Web-server (IIS) beziehen:start /w pkgmgr.exe /uu:IIS-WebServerRole;IIS-WebServer; IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument; IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect; IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility; IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter; IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging; IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing; IIS-CustomLogging;IIS-ODBCLogging;IIS-Security; IIS-BasicAuthentication;IIS-WindowsAuthentication; IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication; IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization; IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance; IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic; IIS-WebServerManagementTools;IIS-ManagementConsole; IIS-ManagementScriptingTools;IIS-ManagementService; IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility; IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService; IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService; WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

ServerManagerCMD verwendenSie können ebenfalls ServerManagerCMD benutzen, um die Webserverrolle zu deinstallieren. Verwen-den Sie für die Deinstallation die folgende Syntax:ServerManagerCMD.exe –remove Web-Server

Um eine detaillierte Protokollierung der Deinstallation zu erhalten, können Sie, wie im folgenden Beispiel gezeigt, die Ergebnisse und die Befehlszeilensyntax in eine Protokolldatei namens ServerManagerCMD_Uninstall.txt leiten:ServerManagerCMD.exe –remove Web-Server –resultPath results.xml –logPath ServerManagerCMD_Uninstall.txt

ZusammenfassungWir haben die verschiedenen Möglichkeiten behandelt, die Ihnen zur Verfügung stehen, um die Webserverrolle, bestimmte Rollendienste und IIS 7.0-Features zu installieren. Windows Server 2008 bietet unterschiedliche Verfahren für die Installation, Konfiguration und Deinstallation von IIS 7.0 an. Die zusätzlichen Protokollierungsfeatures helfen Ihnen, Installationsprobleme zu beheben. Die Infor-mationen in diesem Kapitel sollen dazu beitragen, die Installation von IIS 7.0 zu vereinfachen und die Konfiguration zu beschleunigen. Verglichen mit einem Plätzchenteig geben Ihnen diese Informationen verschiedene Ausstechformen an die Hand, die Sie benutzen können, um IIS 7.0 wie einen Teig in Ihrem Unternehmen auszurollen und an den erforderlichen Stellen den jeweiligen Wünschen entsprechend zu formen.




� Navigieren Sie im TechCENTER unter IIS.net (http://www.iis.net/default.aspx?CategoryID= 13&tabid=2) zu Setup and Migration.

� Besuchen Sie die IIS7-Setup and Migration-Foren unter http://forums.iis.net/1047.aspx.

� Weitere Informationen zum FastCGI-Modul für IIS finden Sie in Bill Staples Blog unter http://blogs.iis.net/bills/archive/2006/10/31/PHP-on-IIS.aspx.

� Eine gute Einleitung zum Thema IIS 7.0 Server Core ist unter http://www.iis.net/articles/view.aspx/IIS7/Explore-IIS7/Getting-Started/IIS7-on-Server-Core verfügbar.

� Um weitere Informationen zur Verwaltung von IIS 7.0-Installationen unter Windows Server 2008 Server Core zu erhalten, lesen Sie http://blogs.iis.net/metegokt/archive/2007/06/26/administering-iis7-on-server-core-installations-of-windows-server-2008.aspx.

� Der folgende Artikel leitet Sie durch eine IIS-Installation mit dem Server-Manager: http://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Install-IIS7-on-Longhorn-Server?Page=2.


147

T E I L I I I

Verwaltung

In diesem Teil:Verwenden von IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Verwenden von Befehlszeilentools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Remoteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Verwalten von Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Verwalten von Anwendungen und Anwendungspools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Hosting von Anwendungsentwicklungsframeworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309Verwalten von Webservermodulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Konfigurations- und Benutzeroberflächenerweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . 401Implementieren von Sicherheitsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427


149

K A P I T E L 6

Verwenden von IIS-Manager

Inhalt dieses Kapitels:� Übersicht über den IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

� Den IIS-Manager starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

� Die Benutzeroberfläche des IIS-Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

� Features verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

� Anpassung und Erweiterbarkeit des IIS 7.0-Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

� Remoteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180



Der IIS-Manager ist ein Verwaltungstool für IIS 7.0 (Internet Information Services), das über eine grafische Benutzeroberfläche verfügt. Er stellt eine sich intuitiv erschließende, feature- und aufgaben-orientierte Verwaltungskonsole für die Arbeit mit IIS 7.0- und ASP.NET-Einstellungen zur Verfügung. Die Benutzeroberfläche ist sehr spezifisch und ermöglicht es Ihnen, aus nur einer Konsole heraus IIS 7.0-Server und ASP.NET-Anwendungen zu konfigurieren. Mit dem IIS-Manager können Sie die delegierte Verwaltung einrichten, damit Anwendungsbesitzer ihre Anwendungen remote verwalten können, wozu keine administrativen Rechte für den Zugriff auf den Server erforderlich sind. Der IIS-Manager ist hochgradig anpassbar und stellt eine Erweiterbarkeitsplattform zur Verfügung, die Sie verwenden können, um Ihre eigenen Features für die Verwaltung von benutzerdefinierten Einstellungen und Anwendungen einzubringen.

In diesem Kapitel konzentrieren wir uns auf die Benutzeroberfläche des IIS-Managers, erörtern die Feature- und Konfigurationszuordnung und sprechen über das Anpassen und die Erweiterbarkeit des IIS-Managers. Wir werden außerdem einen Blick darauf werfen, wie der IIS-Manager für die Remoteverwaltung konfiguriert wird.

Hinweis Eine ausführliche Erläuterung der Remoteverwaltung finden Sie im achten Kapitel, »Remoteverwaltung«. Wie Sie den IIS-Manager benutzen, um gebräuchliche Verwaltungsaufgaben zu lösen, lesen Sie im Anhang J, »Durchführen von Administrationsaufgaben im Internetinformationsdienste-Manager«.

Übersicht über den IIS-ManagerDer IIS-Manager ist ein Serververwaltungstool, das es Ihnen ermöglicht, mit nur einer Benutzerober-fläche IIS 7.0- und ASP.NET-Features zu konfigurieren. Sie können Systemzustands- und Diagnose-informationen einsehen und den Serverbetrieb einschließlich aller gegenwärtig ausgeführten Anforde-


150 Kapitel 6: Verwenden von IIS-Manager

rungen überwachen. Darüber hinaus können Sie die Mitgliedschaft verwalten. Mit seiner aufgaben-orientierten, sich intuitiv erschließenden Benutzeroberfläche zielt das Tool darauf ab, Verwaltungs-aufgaben zu vereinfachen und die mit der Verwaltung einhergehende Komplexität zu verringern.

Verglichen mit der Verwaltungskonsole früherer IIS-Versionen ist der IIS 7.0-Manager sehr viel einfacher zu bedienen. Bei früheren IIS-Versionen war die Serververwaltungskonsole in Form eines MMC-Snap-Ins (Microsoft Management Console) mit der Bezeichnung Inetmgr.exe implementiert. Die Benutzeroberfläche des MMC-Snap-Ins bestand aus Registerkarten mit Konfigurationseinstel-lungen. IIS 7.0 arbeitet mit sehr viel mehr Einstellungen, und eine größere Anzahl von Einstellungen hätte in der alten Verwaltungskonsole dazu geführt, dass zusätzliche Registerkarten erforderlich gewesen wären. Viele Registerkarten erschweren jedoch das Auffinden einer Einstellung und die Durchführung von Verwaltungsaufgaben.

Für IIS 7.0 wurde das Serververwaltungstool von Grund auf neu entworfen und entwickelt. Die IIS 7.0-Verwaltungskonsole ist kein MMC-Snap-In, sondern eine benutzerfreundliche Windows Forms-Anwendung, die eine einfach zu bedienende, feature- und aufgabenorientierte Benutzeroberfläche für IIS- und ASP.NET-Features zur Verfügung stellt. Wie bei den vorherigen IIS-Versionen heißt auch die IIS 7.0-Manager-Anwendung Inetmgr.exe. Und auch sie befindet sich im Ordner %SystemRoot%\Sys-tem32\Inetsrv. Aber lassen Sie sich nicht täuschen. Trotz desselben Namens und Speicherorts handelt es sich um einen vollständig anderen IIS-Manager!

Eine der wichtigsten Fähigkeiten des IIS-Managers ist die delegierte Verwaltung. Mithilfe der dele-gierten Verwaltung bietet der IIS-Manager den Anwendungsbesitzern die Möglichkeit, ihre Anwen-dungen remote zu verwalten, ohne über administrative Rechte für den Zugriff auf den Server verfügen zu müssen. Benutzer von gehosteten Diensten können diese Möglichkeit nutzen, um den IIS-Manager auf ihren Desktops ausführen zu lassen und ihre Sites und Anwendungen remote auf dem Server zu ver-walten, der diese Sites und Anwendungen hostet. Eine sichere Delegierung administrativer Verantwort-lichkeiten kann dazu beitragen, dass ein Serveradministrator viel Zeit spart und dass Webverwaltungs-engpässe seltener werden. Der Serveradministrator hat natürlich die volle Kontrolle darüber, welche Features an Site- und Anwendungsbesitzer delegiert werden.

Der IIS-Manager ermöglicht die Remoteverwaltung über HTTPS-Verbindungen, die Firewalls passieren können. Dabei werden für die Authentifizierung sowohl auf Windows basierende als auch andere Anmeldeinformationen unterstützt. Zusätzlich zu den Windows-Anmeldeinformationen kann der IIS-Manager alternative Anmeldeinformationsspeicher nutzen, um Benutzer zu identifizieren. IIS-Manager-Anmeldeinformationen sind besonders dann nützlich, wenn Sie nicht für alle Remotebenutzer Windows-Konten erstellen möchten, oder wenn die Anmeldeinformationen bereits in einem nicht von Windows genutzten Authentifizierungssystem gespeichert sind und Sie nur diesen einen Speicher verwenden möchten.

Um eine Verbindung zum Server herzustellen, verwendet der IIS-Manager HTTPS. Mit diesem Proto-koll wird eine Verbindung zu WMSvc (Web Management Service, Webverwaltungsdienst) hergestellt. WMSvc ist ein Windows-Dienst, der die Möglichkeit bietet, IIS 7.0-Sites und -Anwendungen mit Hilfe des IIS-Managers remote zu verwalten. WMSvc überwacht standardmäßig alle nicht zugewiesenen IP-Adressen in Verbindung mit Port 8172 daraufhin, ob Anforderungen eingehen. Sie können jedoch bei Bedarf einen anderen Port und eine IP-Adresse konfigurieren. Nachdem die Verbindung eingerichtet wurde, sendet der IIS-Manager bei entsprechenden, innerhalb der Benutzeroberfläche stattfindenden Benutzeraktionen Verwaltungsdienstanforderungen, z.B. die Anforderungen, eine Konfigurations-einstellung in einer web.config-Datei zu ändern. Wenn der Webverwaltungsdienst vom IIS-Manager


Übersicht über den IIS-Manager 151

eine Anforderung erhält, führt er die angeforderte Aktion aus und gibt eine Antwort zurück. Alle Interaktionen zwischen dem IIS-Manager auf dem Remotecomputer und WMSvc auf dem Servercomputer erfolgen über HTTPS. Diese Architektur ist in Abbildung 6.1 dargestellt.

Abbildung 6.1 Der IIS-Manager und der Webverwaltungsdienst

Die meisten Anforderungen, die der IIS-Manager an den Webverwaltungsdienst richtet, beziehen sich darauf, Informationen aus der Konfigurationsdateihierarchie des Servers zu lesen oder in diese Dateien zu schreiben. Dazu zählen die applicationHost.config-Datei, die web.config-Stammdatei des .NET Frameworks und die web.config-Dateien der Sites, Anwendungen und Verzeichnisse. Andere IIS-Manager-Anforderungen verlangen das Lesen des Laufzeitstatus und die Arbeit mit Anbietern auf dem Server.

Darüber hinaus ist der IIS-Manager erweiterbar. Er besitzt eine eigene Konfigurationsdatei, administ-ration.config, die das Hinzufügen von benutzerdefinierter Funktionalität ermöglicht. Alle hinzuge-fügten Verwaltungs-Plug-Ins werden in den IIS-Manager integriert und zusammen mit den IIS- und ASP.NET-Features aufgelistet. Aus dieser Perspektive betrachtet ist der IIS-Manager nicht bloß eine Anwendung, sondern vielmehr eine erweiterbare Plattform, die von den Entwicklern genutzt werden kann, um eigene Features zur Verwaltung benutzerdefinierter Einstellungen einzubringen.



Den IIS-Manager startenSie können den IIS-Manager aus der Programmgruppe Verwaltung heraus starten oder Sie lassen von der Befehlszeile oder dem Windows-Explorer aus %SystemRoot%\System32\Inetsrv\Inetmgr.exe aus-führen. Die Startseite des IIS-Managers ist in Abbildung 6.2 dargestellt.

Abbildung 6.2 Die Startseite des IIS-Managers

Hinweis Um auf dem Servercomputer den IIS-Manager mit administrativen Rechten ausführen zu lassen, sollten Sie sich nicht als Administrator anmelden, sondern in einem nicht administrativen Benutzerkontext den Befehl runas benutzen, z.B. runas /user:<AdministratorAccount> "%SystemRoot%\system32\inetsrv\inetmgr.exe".

Die Startseite ermöglicht es Ihnen, eine der zuletzt genutzten Verbindungen zu öffnen, indem Sie in der Liste Letzte Verbindungen einen Doppelklick darauf ausführen. Sie können neue Verbindungen erstellen, indem Sie in der Liste unter Verbindungsaufgaben die gewünschte Aufgabe anklicken. Sie müssen möglicherweise Kontoanmeldeinformationen angeben, um eine neue Verbindung erstellen zu können.

Die Startseite enthält außerdem Links zu IIS-Onlineressourcen und sie ermöglicht es Ihnen, aktuelle Online-News abzurufen. Die Newsanzeige ist standardmäßig deaktiviert. Um News zu aktivieren, klicken Sie rechts oben im Bereich IIS-News auf IIS News aktivieren.


Die Benutzeroberfläche des IIS-Managers 153

Die Benutzeroberfläche des IIS-ManagersDer IIS-Manager wurde für IIS 7.0 vollständig überarbeitet. Das Look and Feel unterscheidet sich von früheren IIS-Versionen. Die IIS-Manager-Navigation erinnert mehr an einen Browser mit einer Adressleiste, ähnlich dem Windows-Explorer. Wenn Sie einen Server, eine Site oder eine Anwendung auswählen, gleicht die entsprechende, im Hauptbereich dargestellte Featureliste der Systemsteuerung. Wenngleich einige Benutzeroberflächenelemente denen vorheriger IIS-Versionen entsprechen, hat sich die Oberfläche größtenteils verändert. Abbildung 6.3 zeigt das typische Erscheinungsbild des IIS-Managers, wenn im Hauptbereich die Serverfeatures angezeigt werden.

Abbildung 6.3 IIS-Manager: Startseite des Servers

Das IIS-Manager-Fenster ist in verschiedene Abschnitte unterteilt. Im oberen Bereich des IIS-Manager-Fensters gibt es zwei Leisten:

� Die Navigationsleiste, die Schaltflächen und eine Adressleiste für die einfache Navigation innerhalb der Benutzeroberfläche zur Verfügung stellt

� Die Menüleiste, die drei Menüs bereithält: Datei, Ansicht und Hilfe (?)

Der Hauptteil des IIS-Manager-Fensters ist in drei Bereiche unterteilt:

� Der Bereich Verbindungen einschließlich der darin enthaltenen Symbolleiste ermöglicht es Ihnen, eine Verbindung zu Servern, Sites und Anwendungen herzustellen. Die Verbindungen werden in einer hierarchischen Struktur dargestellt.



� Der zentrale Bereich, der auch als Arbeitsbereich bezeichnet wird, zeigt Seiten mit Informationen an und ermöglicht es Ihnen, Einstellungen zu ändern. Der Arbeitsbereich verwendet zwei Ansichten: Features und Inhalt.

� In der Ansicht Features können Sie die Features des gegenwärtig ausgewählten Konfigurations-pfades betrachten und konfigurieren. Jedes IIS-Manager-Feature ist in der Regel einem Konfi-gurationsabschnitt zugeordnet, der das entsprechende Webserverfeature kontrolliert.

� Die Ansicht Inhalt stellt die Inhalte, die sich auf den gegenwärtig ausgewählten Konfigurations-pfad beziehen, schreibgeschützt dar. Wenn Sie die Ansicht Inhalt aktiviert haben und in der hie-rarchischen Struktur des Bereichs Verbindungen einen Knoten auswählen, wird dessen Inhalt im Arbeitsbereich aufgelistet.

� Der Bereich Aktionen ist aufgabenorientiert. Die Liste der angezeigten Aufgaben ist vom jeweiligen Kontext abhängig und bezieht sich auf den gegenwärtig markierten Knoten und das gegenwärtig ausgewählte Feature.

Lassen Sie uns einen etwas genaueren Blick auf diese Bereiche der Benutzeroberfläche werfen.

Direkt von der Quelle: Die Ansichten Inhalt und Features … Wofür?Sehr früh in der Entwicklungsphase des IIS-Managers wies dieser noch ein ganz anderes Erschein-ungsbild auf. Er unterschied sich radikal von dem, was IIS 6.0 und frühere Versionen boten. Er besaß beispielsweise keine hierarchische Struktur für die Navigation durch die Objekte. Er arbeitete wie heutige Webbrowser mit mehreren Registerkarten, um verschiedene Objekte zu verwalten. Die Startseite besaß Links und Bilder, deren Layout äußerst komplex war. Und es gab noch viele andere Merkmale, in denen er sich von der finalen IIS 7.0-Version unterschied. Damals erschienen uns all diese Unterschiede sinnvoll – wir hatten immer gedacht, dass frühere Versionen des IIS-Managers die Inhalte zu sehr betont hätten. Die Benutzeroberflächen dieser Versionen listeten die Dateien und Ordner der Sites auf, aber wenn es darum ging, eine Einstellung zu ändern, wurde letztendlich ein kleines modales Dialogfeld mit vielen Registerkarten angezeigt, das über eine zu kleine Benutzeroberfläche verfügte, auf der nur wenige Einstellungen aufgeführt werden konnten. Ein solches Dialogfeld war in seiner Funktionalität stark eingeschränkt (es gab beispielsweise keine Möglichkeit der Sortierung, Gruppierung, Filterung usw.). Unsere Vorstellung von IIS 7.0 bestand darin, der Benut-zeroberfläche Raum für die eigentliche Aufgabe des Tools – die Verwaltung der Konfiguration – zu bieten und dabei die Möglichkeiten des Benutzers auszuweiten.

Dann begannen wir damit, einige Untersuchungen zur Benutzerfreundlichkeit durchzuführen, und es stellte sich heraus, dass wir nicht in allen Punkten Recht gehabt hatten. Die Untersuchungsteilnehmer machten einige Bedenken geltend und sagten uns, dass viele Features, von deren Nutzen wir über-zeugt gewesen waren, nicht so nützlich seien. Andere Features wiederum, die wir als nicht erforder-lich erachtet hatten, waren für die Benutzer wichtig. Das Auffallendste, das wir lernten, bezog sich auf das Hierarchielistenfeld: Es erwies sich für fast jeden Benutzer als äußerst wichtiges Feature. Es half den Benutzern, die Hierarchie des Systems zu verstehen und zu erkennen, welche Konfiguration eine Änderung erfuhr. Deshalb war dies natürlich das erste Feature, das wir wieder zurückbrachten!

Die Benutzer wünschten sich außerdem eine ähnliche Ansicht wie jene, die frühere Versionen hauptsächlich boten: eine Liste der Ordner und Dateien. Darüber hinaus vermissten einige Benutzer die Möglichkeit, mit der rechten Maustaste auf ein Objekt zu klicken, um über das Kontextmenü das entsprechende Eigenschaftendialogfeld aufzurufen.



NavigationsleisteDie obere Leiste des IIS-Managers ist die Navigationsleiste, mit deren Hilfe Sie durch die Benutzer-oberfläche navigieren können. Die Navigationsleiste enthält:

� Die Adressleiste, die den gesamten Pfad bis zur aktuellen Position innerhalb der Benutzeroberfläche zeigt

� Navigationsschaltflächen, die abhängig von ihrer Position oder Auswahl innerhalb der Benutzer-oberfläche entweder verfügbar oder abgeblendet sind. Sie bieten die übliche Funktionalität:

� Die Schaltfläche Zurück zeigt die vorherige Seite des Seitenverlaufs an.

� Die Schaltfläche Weiter zeigt die jeweils nächste Seite des Seitenverlaufs an.

� Die Schaltfläche Seite aktualisieren aktualisiert die Ansicht des Objekts, das gegenwärtig inner-halb der Benutzeroberfläche ausgewählt ist.

� Die Schaltfläche Beenden unterbricht die gegenwärtig innerhalb der Benutzeroberfläche ausge-führte Aktion.

� Die Schaltfläche Startseite wechselt zur Startseite der aktuellen Auswahl.

� Die Schaltfläche Hilfe öffnet eine Liste mit Links, die zu den Hilfetexten führen.

Der Bereich VerbindungenOben im Bereich Verbindungen befindet sich eine Symbolleiste, von der aus Sie Verbindungen zu Webservern, Sites und Anwendungen herstellen können.

Wenn Sie vom Bereich Verbindungen aus eine Verbindung zu einem Webserver, einer Site oder einer Anwendung herstellen, wird die Verbindung in Form einer hierarchischen Struktur in den Bereich geladen. Diese Struktur zeigt die der Verbindung untergeordneten Knoten wie folgt an:

� Wenn Sie eine Verbindung zu einem Server herstellen, zeigt die Struktur die Serververbindung mit den Anwendungspools und den Sites des Servers an.

An diesem Punkt entschieden wir, dass wir uns nach diesen Vorgaben richten wollten. Die Probleme, die sich durch kleine modale Dialogfelder und viele Registerkarten ergeben, sollten jedoch vermieden werden.

Die Ansicht Inhalt war die Lösung des Problems. Wenn Sie mit der Ansicht Inhalt arbeiten, erhalten Sie fast dasselbe Look and Feel, das Sie von früheren Versionen des IIS-Managers kennen. Auf diese Weise können Sie sich bis zu jedem beliebigen Objekt durchhangeln, einen Klick mit der rechten Maustaste darauf ausführen und im folgenden Kontextmenü den Eintrag zum Ändern der entsprech-enden Einstellungen auswählen. Jedoch wählen Sie in diesem Fall im Kontextmenü nicht den Eintrag Eigenschaften, sondern Zur Ansicht "Features" wechseln, was denselben Effekt hat.

Letztendlich waren wir glücklich darüber, dass wir beide Ansichten anbieten konnten. Die Ergeb-nisse der Untersuchungen zur Benutzerfreundlichkeit verbesserten sich umgehend, und den Benut-zern gefällt der neue IIS-Manager. Es war eine großartige Erfahrung, bei jeder Entscheidung auf das Feedback von Kunden zurückgreifen und sich die Zeit nehmen zu können, um die meisten Design-entscheidungen wieder und wieder zu überprüfen.

Carlos Aguilar Mares

Senior Development Lead, IIS



� Wenn Sie eine Verbindung zu einer Site herstellen, zeigt die Struktur die Siteverbindung mit den Anwendungen innerhalb dieser Site an.

� Wenn Sie eine Verbindung zu einer Anwendung herstellen, zeigt die Struktur die Anwendungs-verbindung mit den physikalischen und virtuellen Verzeichnissen innerhalb dieser Anwendung an.

Hinweis Sie können in der hierarchischen Struktur auch einen Dateiknoten anzeigen lassen, und zwar innerhalb der Verbindung, zu der die Datei gehört. Um einen Dateiknoten hinzuzufügen, wechseln Sie zur Ansicht Inhalt, mar-kieren die Datei und wechseln mithilfe des Bereichs Aktionen oder des Kontextmenüs zurück zur Ansicht Features.

Die Symbolleiste im Bereich Verbindungen enthält die folgenden Schaltflächen:

� Neue Verbindung erstellen Öffnet ein Menü mit drei Optionen: Mit einem Server verbinden, Mit einer Site verbinden oder Mit einer Anwendung verbinden. Die Auswahl einer Option ruft den entsprechenden Verbindungsassistenten auf, so dass Sie eine Verbindung zu einem Webserver, einer Site oder einer Anwendung herstellen können.

Hinweis Dieselben Optionen sind auf der Startseite (in der Liste unter Verbindungsaufgaben) und im Menü Datei verfügbar.

� Aktuelle Verbindungen speichern Speichert die Verbindungsinformationen für die aktuellen Verbindungen im Hierarchielistenfeld.

� Nach oben Verschiebt die Auswahl im Hierarchielistenfeld um eine Ebene nach oben.

� Verbindung löschen Entfernt die ausgewählte Verbindung aus der hierarchischen Struktur. Wenn der gegenwärtig ausgewählte Knoten nicht der Verbindungsknoten ist, wird die übergeordnete Verbindung aus dem Hierarchielistenfeld entfernt. Ist beispielsweise, wenn der Benutzer auf diese Schaltfläche klickt, ein virtuelles oder physikalisches Verzeichnis markiert, wird die übergeordnete Anwendung entfernt.

Neue Verbindungen erstellenUm eine neue Verbindung zu erstellen, klicken Sie in der Symbolleiste des Bereichs Verbindungen auf die Schaltfläche Neue Verbindung erstellen und wählen die gewünschte Aktion. Sie können diese Aktionen ebenfalls aus dem Menü Datei oder auf der Startseite auswählen. Wenn Sie die entsprechende Aktion an einem dieser Orte auswählen, wird immer derselbe Assistent geöffnet.

Wenn Sie eine Verbindung zu einem Server herstellen möchten, fordert der Assistent Sie auf, den Servernamen einzugeben, wie in Abbildung 6.4 dargestellt. Wenn WMSvc auf dem Server einen anderen Port als 8172 (die Standardportnummer) überwacht, müssen Sie die Portnummer mit einem vorange-stellten Doppelpunkt angeben, zum Beispiel www.contoso.com:8080. Wenn Sie eine Verbindung zum lokalen Computer herstellen möchten, geben Sie localhost anstelle eines Servernamens ein. Der Assistent verlangt anschließend von Ihnen die Eingabe der für die Verbindung erforderlichen Benutzer-anmeldeinformationen. Nur Serveradministratoren können eine Verbindung zu einem Server herstellen. Schließlich können Sie einen beschreibenden Namen für diese Verbindung eingeben. Dieser Name wird in der hierarchischen Struktur des Bereichs Verbindungen für den Knoten dieser Serververbindung verwendet.



Abbildung 6.4 Der Assistent zum Herstellen von Serververbindungen

Wenn Sie eine Verbindung zu einer Site herstellen möchten, fordert der Assistent Sie auf, den Namen des Servers, der die Site hostet, sowie den Sitenamen einzugeben, wie in Abbildung 6.5 dargestellt. Wenn WMSvc auf dem Server einen anderen Port als 8172 überwacht, müssen Sie die Portnummer angeben. Der Assistent verlangt anschließend von Ihnen die Eingabe der für die Verbindung erforder-lichen Benutzeranmeldeinformationen. Serveradministratoren und designierte Siteadministratoren können Verbindungen zu Websites herstellen. Schließlich ermöglicht es Ihnen der Assistent, einen beschreibenden Namen für diese Verbindung einzugeben. Dieser Name wird im Hierarchielistenfeld für den Knoten der Siteverbindung verwendet.

Abbildung 6.5 Der Assistent zum Herstellen von Siteverbindungen



Wenn Sie eine Verbindung zu einer Anwendung herstellen möchten, fordert der Assistent Sie auf, den Namen des Servers, der die Anwendung hostet, den Namen der Site, dem die Anwendung zugeordnet ist, und den vollständigen Namen der Anwendung einzugeben, zu dem auch der Pfad zur Anwendung innerhalb der Site zählt (siehe Abbildung 6.6). Wenn WMSvc auf dem Server einen anderen Port als 8172 überwacht, müssen Sie die Portnummer angeben. Der Assistent verlangt anschließend von Ihnen die Eingabe der für die Verbindung erforderlichen Benutzeranmeldeinformationen. Serveradminist-ratoren, Administratoren der Site, die der Anwendung übergordnet ist, und designierte Anwendungs-administratoren können eine Verbindung zu einer Anwendung herstellen. Schließlich ermöglicht es Ihnen der Assistent, einen beschreibenden Namen für diese Verbindung einzugeben. Dieser Name wird im Hierarchielistenfeld für den Knoten der Anwendungsverbindung verwendet.

Hinweis Informationen zur Behebung von Problemen mit Remoteverbindungen finden Sie im achten Kapitel.

Abbildung 6.6 Der Assistent zum Herstellen von Anwendungsverbindungen

ArbeitsbereichDer Arbeitsbereich ist der zentrale Bereich des IIS-Managers. Er befindet sich zwischen den Bereichen Verbindungen und Aktionen. Der Arbeitsbereich zeigt Seiten an, die Features auflisten und andere Informationen zur Verfügung stellen und mit deren Hilfe Sie Einstellungen ändern können.

Der Arbeitsbereich bietet zwei Ansichten an: Features und Inhalt. Sie können zwischen diesen Ansichten wechseln, indem Sie die Schaltflächen unten im Arbeitsbereich benutzen, wie in Abbil- dung 6.7 dargestellt.

Abbildung 6.7 Die Schaltflächen der Ansichten Features und Inhalt



Die Ansicht FeaturesWenn Sie die Ansicht Features aktivieren, werden die Features für das im Bereich Verbindungen markierte Objekt angezeigt. Bei diesem Objekt kann es sich um einen Server, eine Site, eine Anwendung, ein virtuelles Verzeichnis, einen Ordner oder eine Datei handeln. Abbildung 6.3 zeigt beispielsweise die Featureliste, die angezeigt wird, wenn der Benutzer im Bereich Verbindungen eine Serververbindung markiert.

Jedes Feature greift auf die Konfigurationsabschnitte der .config-Dateihierarchie zu, indem es Daten daraus liest oder darin schreibt. Die Ansicht Features ermöglicht es Ihnen, Konfigurationseinstellungen für Features zu betrachten und zu ändern.

StartseiteWenn Sie im Hierarchielistenfeld einen Knoten eines Servers, einer Site, einer Anwendung, eines virtuelles Verzeichnisses, eines Ordners oder einer Datei markieren, wird für dieses Objekt eine entsprechende Startseite angezeigt. Die Startseite zeigt eine Liste mit Features für diesen Knoten an.

Wenn Sie beispielsweise im Hierarchielistenfeld einen Siteknoten markieren, wird die Startseite zu dieser Site angezeigt. In Abbildung 6.8 ist dies für die Site www.contoso.com zu sehen.

Abbildung 6.8 Nach Bereich gruppierte Startseite einer Site

Die Featureliste auf einer Startseite kann nach Bereich oder nach Kategorie gruppiert, in verschiedenen Layouts betrachtet und nach Featurename oder Beschreibung sortiert werden.



Die Features des IIS-Managers sind in Tabelle 6.1 aufgeführt. Die Tabelle hält zu jedem Feature eine kurze Beschreibung bereit und nennt den Bereich und die Kategorie, dem/der das Feature zugeordnet ist. Sie enthält außerdem den Gültigkeitsbereich des jeweiligen Features (Hierarchieebenen und die Startseiten, auf denen das Feature erscheint).

Tabelle 6.1 Features des IIS-Managers

Feature Beschreibung Bereich Kategorie Gültigkeitsbereich

.NET-Kompilierung Konfiguriert Eigenschaften für die Kompilierung von verwaltetem Code

ASP.NET Anwendungs-entwicklung

Server, Site, Anwendung, virtu-elles Verzeichnis, Ordner, Datei

.NET-Globali-sierung

Konfiguriert Globalisierungseigen-schaften für verwalteten Code



.NET-Profil Konfiguriert Optionen für das Feature ASP.NET-Profil, das innerhalb von ASP.NET-Anwendungen Benutzer-informationen überwacht


Site, Anwendung, virtual direc-tory, Ordner, Datei

.NET-Rollen Konfiguriert Rollen für das Feature ASP.NET-Rollen. Diese Rollen können für .NET-Benutzer und die Formularauthentifizierung verwendet werden.

ASP.NET Sicherheit Site, Anwendung, virtual direc-tory, Ordner, Datei

.NET-Vertrauens-ebenen

Konfiguriert Vertrauensebenen für verwaltete Module, Handler und Anwendungen

ASP.NET Sicherheit Server, Site, Anwendung, virtu-elles Verzeichnis, Ordner, Datei

.NET-Benutzer Verwaltet Benutzer für das Feature ASP.NET-Mitgliedschaft

ASP.NET Sicherheit Site, Anwendung, virtuelles Verzeichnis, Ordner, Datei

Anwendungs-einstellungen

Konfiguriert Name/Wert-Paare, die zur Laufzeit von aus verwaltetem Code bestehenden Anwendungen verwendet werden können



Authentifizierung Konfiguriert Authentifizierungs-einstellungen für Sites und Anwen-dungen

IIS Sicherheit Server, Site, Anwendung, virtu-elles Verzeichnis, Ordner, DateiHinweis: Einige Optionen inner-halb des Authentifizierungs-features sind ausschließlich auf der Serverebene verfügbar

Komprimierung Konfiguriert Einstellungen für die Komprimierung von Antworten

IIS Leistung Server, Site, Anwendung, virtu-elles Verzeichnis, Ordner, Datei

Verbindungs-zeichenfolgen

Konfiguriert Zeichenfolgen, die von ASP.NET-Anwendungen verwendet werden können, um Verbindungen zu Datenquellen herzustellen


Server, Site, Anwendung, virtuelles Verzeichnis, Ordner, Datei

Standarddokument Konfiguriert Standarddateien, die zurückgegeben werden, wenn Clients den Verzeichnisstamm anfordern

IIS HTTP-Features Server, Site, Anwendung, virtuelles Verzeichnis, Ordner, Datei



Verzeichnis durchsuchen

Legt fest, ob IIS eine Verzeichnisliste anzeigt, wenn Clients einen Ver-zeichnisstamm anfordern

IIS HTTP-Features Server, Site, Anwendung, virtu-elles Verzeichnis, Ordner, Datei

Fehlerseiten Konfiguriert Seiten, die beim Auftreten von HTTP-Fehlern zurückgegeben werden


Ablaufverfolgung für Anforderungs-fehler

Konfiguriert die Protokollierung der Ablaufverfolgung für Anforderungs-fehler

IIS Systemzustand und Diagnose


Delegierung von Features

Konfiguriert den Standarddelegie-rungsstatus für Features, die sich im IIS-Manager auf niedrigeren Ebenen befinden

Verwaltung Sicherheit Stammknoten der Verbindung (Server, Site, Anwendung)

Handler-zuordnungen

Legt Handler fest, die für Antworten auf bestimmte Anforderungstypen zuständig sind

IIS Server-komponenten


HTTP-Umleitung Legt Regeln für das Umleiten von eingehenden Anforderungen zu einer anderen Datei oder einem anderen URL fest


HTTP-Antwort-header

Konfiguriert HTTP-Header, die den Antworten vom Webserver hinzuge-fügt werden


IIS-Manager-Berechtigungen

Konfiguriert Benutzer, die in Sites oder Anwendungen, für die sie die entsprechenden Berechtigungen besitzen, delegierte Features einrich-ten können

Verwaltung Sicherheit Server

IIS-Manager- Benutzer

Verwaltet IIS-Manager-Benutzer Verwaltung Sicherheit Server

ISAPI- und CGI-Einschränkungen

Schränkt bestimmte ISAPI-Erweite-rungen (Internet Server Application Programming Interface) und CGI-Programme (Common Gateway Inter-face) auf dem Webserver ein oder aktiviert diese

IIS Sicherheit Server

ISAPI-Filter Legt ISAPI-Filter fest, die die IIS-Funktionalität modifizieren


Server, Site

Protokollierung Konfiguriert, wie IIS auf dem Webser-ver Anforderungen protokolliert



Tabelle 6.1 Features des IIS-Managers (Fortsetzung)




Die Features auf der Startseite können in Gruppen angezeigt werden. Mit dem Dropdown-Listenfeld Gruppieren nach in der Symbolleiste der Startseite oder der Option Gruppieren nach im Menü Ansicht können Sie wie folgt festlegen, wie Features in Gruppen organisiert werden sollen:

Computerschlüssel Konfiguriert Hashing- und Verschlüs-selungseinstellungen für ASP.NET-Anwendungsdienste, z. B. Anzeige-zustand, Formularauthentifizierung, Mitgliedschaft und Rollen und ano-nyme Authentifizierung



MIME-Typen Konfiguriert Dateinamenserweite-rungen und die damit verbundenen Inhaltstypen, die als statische Dateien bereitgestellt werden


Module Konfiguiert Module für systemeigenen und verwalteten Code, die auf dem Webserver Anforderungen ver-arbeiten



Ausgabezwischen-speicherung

Legt Regeln für die Zwischen-speicherung von Antwortinhalten im Ausgabecache fest

IIS Leistung Server, Site, Anwendung, virtu-elles Verzeichnis, Ordner, Datei

Seiten und Steuerelemente

Konfiguriert Einstellungen für ASP.NET-Seiten und -Steuerelemente



Anbieter Konfiguriert Anbieter für anbieter-abhängige Anwendungsdienste



Serverzertifikate Anfordern und Verwalten von Zertifi-katen für Websites, die SSL (Secure Sockets Layer) verwenden

IIS Sicherheit Server

Sitzungszustand Konfiguriert Sitzungszustandsein-stellungen und Einstellungen für Formularauthentifizierungscookies


Server, Site, Anwendung, virtu-elles Verzeichnis, Ordner

Freigegebene Konfiguration

Konfiguriert die freigegebene Konfiguration

Management Andere Server

SMTP-E-Mail Konfiguriert E-Mail-Adressen und Übermittlungsoptionen für das Versenden von E-Mails aus Web-anwendungen heraus



SSL-Einstellungen Legt Anforderungen für SSL und Clientzertifikate fest

IIS Sicherheit Site, Anwendung, virtuelles Verzeichnis, Ordner, Datei

Arbeitsprozesse Zeigt Informationen über Arbeits-prozesse und die darin ausgeführten Anforderungen an


Server

Tabelle 6.1 Features des IIS-Managers (Fortsetzung)




� Wenn Sie die Option Bereich auswählen, werden ASP.NET- und IIS-Features getrennt voneinander in zwei Gruppen angezeigt (für den Serverknoten eines lokalen Computers wird darüber hinaus die Gruppe Verwaltung angezeigt):

� ASP.NET

� IIS

Hinweis Wird die IIS-Standardinstallation erweitert, können zusätzliche Gruppen angeboten werden. Das Hinzu-fügen des Medienpakets sorgt beispielsweise dafür, dass zusätzlich die Gruppe Medien angezeigt wird.

Ein Beispiel für die Gruppierung nach Bereich ist in Abbildung 6.8 dargestellt. Tabelle 6.1 zeigt, welchem Bereich jedes IIS-Manager-Feature zugeordnet ist.

� Die Auswahl der Option Kategorie zeigt die ASP.NET- und IIS-Features in sechs Kategorien an (für den Serverknoten eines lokalen Computers kann eine weitere Kategorie namens Andere angezeigt werden):

� Anwendungsentwicklung

� Systemzustand und Diagnose

� HTTP-Features

� Leistung

� Sicherheit

� Serverkomponenten

Ein Beispiel für die Gruppierung nach Kategorie ist in Abbildung 6.9 zu sehen. Tabelle 6.1 zeigt, welcher Kategorie jedes IIS-Manager-Feature zugeordnet ist.

Abbildung 6.9 Die nach Kategorie gruppierte Startseite



� Die Auswahl der Option Keine Gruppierung listet alle Features in alphabetischer Reihenfolge auf, wie in Abbildung 6.10 dargestellt.

Abbildung 6.10 Die Startseite ohne Featuregruppierung

Mithilfe der auf der Symbolleiste der Startseite angeordneten Schaltfläche Ansichten oder der Option Ansicht, die Sie im Menü Ansicht finden, können Sie verschiedene Layouts für die Featureliste auswählen:

� Die Ansicht Details listet die Features in einer Tabelle auf. Die erste Spalte jedes Features enthält ein kleines Symbol und einen Namen und in der zweiten Spalte ist eine kurze Beschreibung aufgeführt. In dieser Ansicht können Sie die Features in auf- oder absteigender Reihenfolge nach dem Namen oder der Beschreibung sortieren. Dazu klicken Sie auf die entsprechende Spalten-überschrift. Die Sortierung erfolgt innerhalb der Featuregruppen. Abbildung 6.11 zeigt beispiels-weise die Ansicht Details für die Startseite einer Site, wobei sowohl ASP.NET- als auch IIS-Gruppen nach Featurename sortiert sind.



Abbildung 6.11 Die Ansicht Details für die Startseite einer Site

� Die Ansicht Symbole zeigt eine Liste mit Symbolen an. Diese Ansicht erinnerte ein wenig an die Systemsteuerung. Es handelt sich um die Standardansicht.

� Die Ansicht Kacheln zeigt kleinere Symbole zusammen mit dem jeweiligen Featurenamen an.

� Die Ansicht Liste zeigt eine Liste mit Featurenamen an.

Features werden verwendet, um Konfigurationen zu betrachten und zu ändern. Wenn Sie beispielsweise die Standarddateien einer Site konfigurieren möchten, führen Sie auf der Startseite dieser Site einen Doppelklick auf dem Feature Standarddokument aus, um die gleichnamige Seite (siehe Abbildung 6.12) zu öffnen und die gewünschten Änderungen vorzunehmen.

Beachten Sie den Konfigurationsvermerk, der sich links in der Statusleiste im unteren Bereich des IIS-Managers befindet (siehe Abbildung 6.12). Der Vermerk verweist auf die web.config-Datei dieser Site. Wenn die Einstellungen eines Features angezeigt werden, führt die Statusleiste die Konfigurationsdatei auf, in der die Konfigurationseinstellungen zu diesem Feature gespeichert sind. In diesem Beispiel handelt es sich um die web.config-Datei der Site www.contoso.com.



Abbildung 6.12 Das Feature Standarddokument

SeitenlayoutsDie auf den Featureseiten dargestellten Informationen und Konfigurationseinstellungen können mithilfe verschiedener Layouts präsentiert werden. Bezogen auf das Seitenlayout gibt es drei Arten von Featureseiten:

� Listenseiten

� Eigenschaftenseiten

� Dialogseiten

Das Layout, das vorwiegend für eine Seite genutzt wird, ist die Listenseite. Eine Listenseite enthält eine Liste, die in Form einer Tabelle angezeigt wird. Mit dem Dropdown-Listenfeld Gruppieren nach können Sie die Liste nach den Spaltenwerten gruppieren. Darüber hinaus können Sie die Daten nach den Werten einer Spalte sortieren lassen, indem Sie auf die Überschrift dieser Spalte klicken. Ein Beispiel für eine Listenseite ist in Abbildung 6.13 dargestellt. Es handelt sich um die Seite des Features Fehlerseiten.

Die Seiten Sites und Anwendungspools sind Listenseiten, mit denen Sie die Listeneinträge filtern können. Dazu wird in einer Spalte nach Einträgen gesucht, die einer Suchzeichenfolge entsprechen. Geben Sie die Suchzeichenfolge im Dropdown-Listenfeld Filter an, und wählen Sie die zu filternde Spalte aus dem Dropdown-Listenfeld Start aus. Abbildung 6.14 zeigt die Seite Sites mit den verfüg-baren Spaltenfiltern.



Abbildung 6.13 Die Seite Fehlerseiten: ein Beispiel für das Listenseitenlayout

Abbildung 6.14 Die Seite Sites filtern

Auf der Seite Sites können Sie in den folgenden Spalten suchen:

� Sitename

� Hostname

� IP-Adresse

� Port

� Physikalischer Pfad

� Protokoll



Auf der Seite Anwendungspools können Sie in den folgenden Spalten suchen:

� Name

� .NET Framework-Version

� Identität

� Verwalteter Pipelinemodus

Die Filterfunktionalität ist für Listenseiten mit einer großen Anzahl von Einträgen – z.B. bei Servern, die sehr viele Sites hosten – besonders dann nützlich, wenn Sie einen Eintrag schnell lokalisieren möchten.

Das Eigenschaftenseitenlayout wird ebenfalls oft verwendet. Eine Eigenschaftenseite stellt ein Eigen-schaftenraster mit einem Look and Feel dar, das dem eines Eigenschaftenrasters von Microsoft Visual Studio gleicht. Wenn Sie im Raster eine Eigenschaft markieren, erscheint im unteren Bereich eine Beschreibung dieser Eigenschaft. Mit dem Dropdown-Listenfeld Anzeige, das sich im oberen Bereich des Eigenschaftenrasters befindet, können Sie festlegen, wie die Eigenschaftennamen angezeigt werden sollen:

� Anzeigenamen (Standardeinstellung)

� Konfigurationsnamen

� Beide Namen Wenn Sie diese Option wählen, werden die Anzeigenamen gefolgt von den Konfi-gurationsnamen in eckigen Klammern angezeigt.

Nachdem Sie in einem Raster Änderungen vorgenommen haben, klicken Sie im Bereich Aktionen auf Übernehmen, um die Änderungen zu speichern. Wenn Sie das Eigenschaftenraster verlassen, ohne auf Übernehmen zu klicken, fordert der IIS-Manager Sie auf, die Änderungen zu speichern, da diese andernfalls verloren gehen.

Abbildung 6.15 zeigt das Eigenschaftenraster .NET-Kompilierung, das die Anzeigenamen darstellt.

Abbildung 6.15 Die Seite .NET-Kompilierung: ein Beispiel für ein Eigenschaftenseitenlayout



Der dritte Layouttyp ist die Dialogseite. Dialogseiten arbeiten mit Kontrollkästchen, Textfeldern und Optionsfeldern. Nachdem Sie in einer Dialogseite eine Auswahl vorgenommen haben, klicken Sie im Bereich Aktionen auf Übernehmen, um die Änderungen zu speichern. Wenn Sie die Dialogseite verlassen, ohne auf Übernehmen zu klicken, fordert der IIS-Manager Sie auf, die Änderungen zu speichern, da diese andernfalls verloren gehen.

Abbildung 6.16 zeigt die Seite des Features Sitzungszustand, die ein gutes Beispiel für eine Dialogseite ist. Sie sehen dort die Optionsfelder für die Einstellungen zum Sitzungszustandmodus, die Textfelder für die Verbindungszeichenfolge und das Timeout sowie ein Kontrollkästchen zur Aktivierung einer benutzerdefinierten Datenbank.

Abbildung 6.16 Die Seite Sitzungszustand: ein Beispiel für ein Dialogseitenlayout

Die Ansicht InhaltWenn Sie die Ansicht Inhalt aktivieren, wird der eigentliche Inhalt des im Bereich Verbindungen ausgewählten Objekts angezeigt. Wenn Sie beispielsweise im Hierarchielistenfeld den Knoten einer Site markieren, werden die Inhalte dieser Site angezeigt. Dazu zählen auch virtuelle Verzeichnisse, Ordner und Dateien. Abbildung 6.17 zeigt die Ansicht Inhalt für die Site www.contoso.com, die das Standarddokument default.aspx, eine web.config-Sitekonfigurationsdatei, eine Anwendung und ein virtuelles Verzeichnis enthält.



Abbildung 6.17 Die Ansicht Inhalt

Die Ansicht Inhalt ist eine schreibgeschützte Ansicht. Sie können in dieser Ansicht keine Dateien oder Ordner erstellen, kopieren, verschieben oder löschen. Sie können in der Ansicht Inhalt zum markierten Inhalt navigieren, indem Sie im Bereich Aktionen auf Durchsuchen oder mit der rechten Maustaste auf den Inhalt klicken.

Sie können innerhalb der Ansicht Inhalt navigieren, indem Sie einen Doppelklick auf einem Objekt ausführen, woraufhin Sie dessen Inhalte einsehen. Wenn Sie in der Ansicht Inhalt beispielsweise einen Doppelklick auf einem Verzeichnis ausführen, wird der Inhalt dieses Verzeichnisses im Arbeitsbereich angezeigt, und der Verzeichnisknoten wird im Hierarchielistenfeld des Bereichs Verbindungen markiert.

Sie können die Ansicht Inhalt aktivieren, indem Sie im unteren Bereich des IIS-Managers auf Ansicht "Inhalt" oder im Hierarchielistenfeld mit der rechten Maustaste auf einen Knoten klicken und im folgenden Kontextmenü Zur Ansicht "Inhalt" wechseln auswählen.

Die Ansicht Inhalt arbeitet mit dem Listenlayout. Sie können die Inhalte filtern, indem Sie in den Spalten Name und Typ nach einer Suchzeichenfolge suchen lassen, die Sie im Dropdown-Listenfeld Filter angeben. Darüber hinaus können Sie die Liste nach dem Namen oder Typ sortieren lassen, indem Sie auf die entsprechende Spaltenüberschrift klicken. Des Weiteren ist eine Gruppierung des Inhalts nach dem Typ möglich. Dazu verwenden Sie das Dropdown-Listenfeld Gruppieren nach.

Wenn Sie in der Ansicht Inhalt ein Objekt markieren, z.B. ein Verzeichnis oder eine Datei, können Sie die Features dieses Objekts konfigurieren, indem Sie zur Ansicht Features wechseln. Sie können die Ansicht Features aktivieren, indem Sie im unteren Bereich des IIS-Managers auf Ansicht "Features" oder im Bereich Aktionen auf Zur Ansicht "Features" wechseln klicken. Es ist aber auch möglich, in der Ansicht Inhalt mit der rechten Maustaste auf ein Objekt zu klicken und im folgenden Kontextmenü Zur Ansicht "Features" wechseln auszuwählen.


Features verstehen 171

Hinweis Die einzige Möglichkeit, die Konfiguration für eine Datei festzulegen, besteht darin, zur Ansicht Inhalt zu wechseln, die Datei zu markieren und dann mithilfe des Bereichs Aktionen oder des Kontextmenüs, das nach einem Rechtsklick angezeigt wird, die Ansicht Features wieder zu aktivieren.

Wenn Sie sich in der Ansicht Inhalt befinden, können Sie die Windows-Eigenschaften des markierten Objekts (z.B. eine Datei oder ein Verzeichnis) betrachten. Und die Windows-Eigenschaften eines in der Ansicht Inhalt markierten Objekts anzeigen zu lassen, wählen Sie entweder im Bereich Aktionen den Eintrag Berechtigungen bearbeiten oder Sie klicken mit der rechten Maustaste auf das Objekt.

Der Bereich AktionenDer Bereich Aktionen wird verwendet, um IIS-, ASP.NET- und IIS-Manager-Einstellungen zu konfi-gurieren. Sie können den Bereich Aktionen benutzen, um Dialogfelder und Assistenten zu öffnen, mit deren Hilfe Sie im IIS-Manager bestimmte Aufgaben ausführen können, wie z.B. das Erstellen einer Site, das Konfigurieren der Authentifizierung oder das Hinzufügen einer Verbindungszeichenfolge zu einer Anwendung.

Die Einträge im Bereich Aktionen sind aufgabenorientiert. Die Liste der angezeigten Aufgaben ist kontextspezifisch und davon abhängig, welches Objekt gegenwärtig markiert ist, z.B. ein markierter Knoten im Hierarchielistenfeld des Bereichs Verbindungen, und welches Feature oder welcher Inhalt im Arbeitsbereich ausgewählt ist.

Abbildung 6.3 zeigt beispielsweise, dass, wenn im Hierarchielistenfeld ein Serverknoten markiert ist, der Bereich Aktionen Aufgaben anzeigt, die sich auf die Ebene der Serververbindung beziehen, wie z.B. das Starten und Beenden des Webservers oder das Delegieren eines Features. Abbildung 6.8 zeigt, dass, wenn ein Siteknoten im Bereich Verbindungen markiert ist, der Bereich Aktionen Aufgaben anzeigt, die sich auf die Ebene der Siteverbindung beziehen, z.B. das Starten und Beenden oder das Bearbeiten der Bindungen dieser Website.

Die Einträge im Bereich Aktionen sind auch im Kontextmenü verfügbar, wenn Sie im IIS-Manager mit der rechten Maustaste auf ein Objekt klicken.

Features verstehenDie Features des IIS-Managers arbeiten mit den entsprechenden Konfigurationsabschnitten in der .config-Dateihierarchie, um Daten daraus zu lesen oder darin zu schreiben. Das Feature Anwendungs-einstellungen entspricht beispielsweise dem <appSettings>-Abschnitt in den web.config-Dateien, wohin-gegen das Feature Verzeichnis durchsuchen dem <directoryBrowse>-Element im <system.webServer>-Abschnitt entspricht.

Nur wenige Ausnahmen lesen und schreiben Konfigurationen in andere Dateien außerhalb von IIS, die nicht der Hierarchie der Konfigurationsdateien zugehören. Das Feature Serverzertifikate erhält seine Einstellungen beispielsweise aus dem Zertifikatspeicher des lokalen Servers, und das Feature Verwaltungsdienst ruft seine Einstellungen aus der Windows-Registrierung des lokalen Servers ab.



Die Zuordnung von Features zu ModulenDie Features des IIS-Managers und die entsprechenden Konfigurationsabschnitte in den .config-Dateien sind in Tabelle 6.2 aufgelistet.

Die Tabelle führt zusätzlich die Servermodule auf, die auf die Konfigurationsabschnitte zugreifen. Für jedes Servermodul sind sowohl der Modulname als auch der Typ bzw. der DLL-Name aufgeführt, wobei der Typ bzw. der DLL-Name in Klammern angegeben ist.

In einigen Fällen kann der IIS-Kernwebserver, der IIS-Manager, das .NET Framework oder die ASP.NET-Laufzeit (jeweils in eckigen Klammern angegeben) direkt mit einem Konfigurationsab-schnitt arbeiten.

Tabelle 6.2 Zuordnung von IIS-Manager-Features zur Konfiguration und zu Modulen

Featurename Konfigurationsabschnitt Verwendet von

.NET-Kompilierung system.web/compilation [ASP.NET-Kompilierungssystem]

.NET-Globalisierung system.web/globalization [ASP.NET-Laufzeit]

.NET-Profil system.web/profile Profil (System.Web.Profile.ProfileModule)

.NET-Rollen system.web/roleManager Rollendienst, RoleManager (System.Web. Security.RoleManagerModule) und der konfi-gurierte standardmäßige Rollenanbieter

.NET-Vertrauensebenen system.web/trust [ASP.NET-Laufzeit]

.NET-Benutzer system.web/membership [Mitgliedschaftsdienst, der konfigurierte standardmäßige Mitgliedschaftsanbieter]

[Authentifizierung] Anonym system.webServer/security/anonymousAuthentication

AnonymousAuthenticationModule (authanon.dll)

[Authentifizierung] Standard system.webServer/security/basicAuthentication

BasicAuthenticationModule (authbas.dll)

[Authentifizierung] Digest system.webServer/security/digestAuthentication

DigestAuthenticationModule (authmd5.dll)

[Authentifizierung] Formular system.web/authentication FormsAuthentication (System.Web.Security. FormsAuthenticationModule)

[Athentifizierung] Windows system.webServer/security/windowsAuthentication

WindowsAuthenticationModule (authsspi.dll)

Anwendungseinstellungen appSettings [ASP.NET-Anwendungscode]

ASP system.webServer/asp (indirect) IsapiModule (isapi.dll)

Autorisierungsregeln system.webServer/security/authorization

UrlAuthorizationModule (urlauthz.dll)

CGI system.webServer/cgi CgiModule (cgi.dll)

Komprimierung system.webServer/httpCompressionsystem.webServer/urlCompression

DynamicCompressionModule (compdyn.dll)

StaticCompressionModule (compstat.dll)

Verbindungszeichenfolgen connectionStrings [ASP.NET-Features und -Anwendungscode]



Standarddokument system.webServer/defaultDocument

DefaultDocumentModule (defdoc.dll)

Verzeichnis durchsuchen system.webServer/directoryBrowse DirectoryListingModule (dirlist.dll)

Fehlerseiten system.webServer/httpErrors CustomErrorModule (custerr.dll)

Ablaufverfolgung für Anforderungsfehler

system.webServer/tracing/traceFailedRequestssystem.webServer/tracing/traceProviderDefinitions

FailedRequestsTracingModule (iisfreb.dll)

Handlerzuordnungen system.webServer/handlers [IIS-Serverkern]

HTTP-Umleitung system.webServer/httpRedirect HttpRedirectionModule (redirect.dll)

HTTP-Antwortheader system.webServer/httpProtocol ProtocolSupportModule (protsup.dll)

IIS-Manager-Berechtigungen administration.config: system.webServer/management

[IIS-Manager, Webverwaltungsdienst (WMSvc)]

IIS-Manager-Benutzer administration.config: system.webServer/management

[IIS-Manager, Webverwaltungsdienst (WMSvc)]

Einschränkungen für IPv4-Adressen und Domänen

system.webServer/ipSecurity IpRestrictionModule (iprestr.dll)

ISAPI- und CGI-Einschränkungen

system.webServer/security/isapiCgiRestriction

CgiModule (cgi.dll)

IsapiModule (isapi.dll)

ISAPI-Filter system.webServer/isapiFilters IsapiFilterModule (filter.dll)

Protokollierung system.applicationHost/logsystem.webServer/httpLogging

[IIS Server Core]

HttpLoggingModule (loghttp.dll)

Computerschlüssel system.web/machineKey [ASP.NET-Laufzeit und Features, die die Verschlüsselung nutzen]

Verwaltungsdienst Registry:HKLM\SOFTWARE\Microsoft\WebManagement\Server

[Webverwaltungsdienst (WMSVC)]

MIME-Typen system.webServer/staticContent StaticFileModule (static.dll)

Module system.webServer/globalModulessystem.webServer/modules

[IIS-Serverkern]

Ausgabezwischenspeicherung system.webServer/caching HttpCacheModule (cachhttp.dll)

Seiten und Steuerelemente system.web/pages [ASP.NET]

Anbieter system.web/membershipsystem.web/roleManagersystem.web/profile

[Features für ASP.NET-Rollen, -Mitgliedschaft und -Profile]

Serverzertifikate [Local Machine Certificate Store] [Betriebssystem, HTTP.SYS, Windows-Anwendungen]

Tabelle 6.2 Zuordnung von IIS-Manager-Features zur Konfiguration und zu Modulen (Fortsetzung)




Speicherort der KonfigurationWenn die Featurekonfigurationseinstellungen geändert werden, schreibt der IIS-Manager diese Einstellungen in eine Konfigurationsdatei. Abhängig von der Verbindungsebene (Server, Site oder Anwendung) und den Sperrungen in der Konfigurationsdateihierarchie sind die IIS-Manager-Feature-einstellungen mit Lesen/Schreiben oder Schreibgeschützt gekennzeichnet.

Serververbindungen können in die Konfigurationsdateien der Serverebene, also applicationHost.config und die web.config-Stammdatei, und in alle verteilten web.config-Dateien dieses Servers schreiben. Nur der Administrator eines Servercomputers kann eine Verbindung zu einem Server herstellen. Die Features auf der Serverebene können die Konfigurationsdateien verwenden, um sowohl daraus zu lesen als auch darin zu schreiben. Selbst wenn in applicationHost.config ein Konfigurationsabschnitt gesperrt ist, ist das entsprechende Feature bei einer Serververbindung mit Lesen/Schreiben gekennzeichnet. Die Konfigurationsänderungen werden in applicationHost.config in ein <location>-Tag geschrieben.

Siteverbindungen können lediglich in die web.config-Dateien schreiben, die sich im Stammordner der Site oder auf den Ebenen darunter befinden. Serveradministratoren und designierte Siteadministratoren können Verbindungen zu Websites herstellen. Wenn in applicationHost.config ein Konfigurations-abschnitt gesperrt ist, ist das entsprechende Feature bei dieser Siteverbindung mit Schreibgeschützt gekennzeichnet, weil Siteverbindungen nicht in applicationHost.config schreiben können (auch nicht in ein <location>-Tag).

Anwendungsverbindungen können lediglich in die web.config-Dateien schreiben, die sich im Stamm-ordner der Anwendung oder auf den Ebenen darunter befinden. Serveradministratoren, Administ-ratoren der Site, die der Anwendung übergordnet ist, und designierte Anwendungsadministratoren können eine Verbindung zu einer Anwendung herstellen. Wenn in applicationHost.config oder in der web.config-Datei der Site ein Konfigurationsabschnitt gesperrt ist, ist das entsprechende Feature bei dieser Anwendungsverbindung mit Schreibgeschützt gekennzeichnet.

Vorausgesetzt, dass ein Feature nicht schreibgeschützt ist und Einstellungen gespeichert werden können, definieren zwei Regeln, in welche Dateien die Konfigurationseinstellungen zu diesem Feature geschrieben werden:

� ApplicationHost.config gegen die web.config-Stammdatei bei Konfigurationen der Serverebene:

� Wenn das Feature im IIS-Manager im Bereich ASP.NET aufgeführt ist, wird eine Konfiguration der Serverebene in die web.config-Stammdatei des .NET Frameworks geschrieben.

Serverseitiges Include system.webServer/serverSideInclude

ServerSideIncludeModule (iis_ssi.dll)

Sitzungszustand system.web/sessionStatesystem.web/sessionPageState

Session (System.Web. SessionState.SessionStateModule)

Freigegebene Konfiguration redirection.config: configurationRedirection [IIS-Konfigurationssystem]

SMTP-E-Mail system.net/mailSettings/smtp [.NET Framework]

SSL-Einstellungen system.webServer/access [IIS-Serverkern]

Arbeitsprozesse applicationHost.config: system.applicationHost/applicationPools

[Windows-Prozessaktivierungsdienst}

Tabelle 6.2 Zuordnung von IIS-Manager-Features zur Konfiguration und zu Modulen (Fortsetzung)




� Wenn das Feature im IIS-Manager im Bereich IIS aufgeführt ist, wird eine Konfiguration der Serverebene in die applicationHost.config-Datei geschrieben.

� Die einzige Ausnahme bildet die Formularauthentifizierung, bei der es sich um ein Authentifi-zierungsfeature im IIS-Bereich handelt. Die Konfiguration der Formularauthentifizierung wird in die web.config-Stammdatei geschrieben.

Hinweis Der IIS-Manager speichert eine Featurekonfiguration der Serverebene entweder in applicationHost.con-fig oder in der web.config-Stammdatei. Für welche dieser Dateien der IIS-Manager sich entscheidet, ist davon abhängig, wo der entsprechende Konfigurationsabschnitt definiert ist. Wenn der Abschnitt in applicationHost.config definiert ist, wird die Konfiguration dort gespeichert. Andernfalls wird sie in der web.config-Stammdatei gespeichert.

� Gesperrte gegen nicht gesperrte Konfigurationen der Site- und Anwendungsebene:

� Alle ASP.NET-Konfigurationsabschnitte und einige wenige IIS-Konfigurationsabschnitte sind standardmäßig nicht gesperrt. Bei nicht gesperrten Abschnitten schreibt der IIS-Manager in die web.config-Datei einer Site, wenn die Konfiguration dieser Site geändert wurde, oder in die web.config-Datei einer Anwendung, wenn die Konfiguration dieser Anwendung geändert wurde.

� Die meisten IIS-Konfigurationsabschnitte sind standardmäßig gesperrt. Bei gesperrten Abschnitten schreibt der IIS-Manager immer in applicationHost.config. Dies geschieht selbst dann, wenn die Konfigurationen von Sites und Anwendungen geändert werden.

Der IIS-Manager ermittelt mithilfe der folgenden Logik, wo eine Konfiguration gespeichert werden soll: Er versucht immer, die Konfiguration in der Konfigurationsdatei zu speichern, die sich in der Hierarchie in nächster Nähe zum konfigurierten Objekt befindet. Bei einer Verzeichniskonfiguration versucht der IIS-Manager beispielsweise, die Einstellungen in der web.config-Datei dieses Verzeichnisses zu speichern. Bei Anwendungskonfigurationen versucht er, in die web.config-Datei der jeweiligen Anwendung zu schreiben usw. Wenn jedoch der entsprechende Abschnitt in der nächstgelegenen Datei gesperrt ist, verwendet der Manager die nächstgelegene übergeordnete Datei und versucht dort, den Speichervorgang mithilfe eines location-Tags auszuführen. Wenn der Abschnitt in der übergeordneten Konfigurationsdatei gesperrt ist, setzt der IIS-Manager diesen Vorgang fort, bis er die oberste Konfigurationsdatei der jewei-ligen Verbindung erreicht. Wenn der Abschnitt auch dort gesperrt ist, wird die Konfiguration als schreib-geschützt erachtet.

Wenn Sie Featurekonfigurationseinstellungen bearbeiten, zeigt der IIS-Manager Ihnen den Verwah-rungsort der Datei an, in der diese Einstellungen gespeichert werden. Der Speicherort der Konfigura-tionsdatei wird unten links im IIS-Manager dargestellt und mit dem Präfix Konfiguration eingeleitet. Das folgende Format wird verwendet:

Konfiguration: 'konfigurationsdateiobjektpfad' konfigurationsdateiname

konfigurationsdateiobjektpfad ist der Pfad zum Konfigurationsdateiobjekt. Lassen Sie uns einige Beispiele betrachten:

� 'localhost' Wird auf dem lokalen Computer für Konfigurationen der Serverebene angezeigt. Bei IIS-Features folgt die applicationHost.config-Datei. Bei ASP.NET-Features folgt die web.config-Stammdatei. Abbildung 6.15 zeigt die Seite des Features .NET-Kompilierung als Beispiel für den zuletzt genannten Fall.

� www.contoso.com Wird als Pfad zur web.config-Datei im physikalischen Ordner www.contoso.com angezeigt (hinter www.contoso.com folgt web.config).



konfigurationsdateiname ist der Name der Zielkonfigurationsdatei. Dazu einige Beispiele:

� applicationHost.config für IIS-Features Bei einer Serververbindung zeigt die Statusleiste für das Feature Verzeichnis durchsuchen beispielsweise den folgenden Text an:

Konfiguration: 'localhost' applicationHost.config

� web.config-Stammdatei für ASP.NET-Features Bei einer Serververbindung zeigt die Status-leiste für das Feature .NET-Vertrauensebenen beispielsweise den folgenden Text an:

Konfiguration: 'localhost' web.config (Stamm)

� web.config, eine web.config-Zieldatei Die Statusleiste zeigt für die Site www.contoso.com und das Feature Sitzungszustand beispielsweise den folgenden Text an, wie in Abbildung 6.16 dargestellt:

Konfiguration: 'www.contoso.com' web.config

location path (engl. für Speicherortpfad) ist der Pfad zu dem Ort, an dem das konfigurierte Objekt gespeichert ist. (Weitere Informationen zu Speicherortpfaden finden Sie im vierten Kapitel, »Verstehen des Konfigurationssystems«.) Dieser Teil des Textes erscheint nur dann, wenn der Konfigura-tionsabschnitt, der dem Feature entspricht, auf einer höheren Ebene gesperrt ist. Beispielsweise zeigt die Statusleiste in Abbildung 6.13 für die Site www.contoso.com und das Feature Fehlerseiten den folgenden Text an:

Konfiguration: 'localhost' applicationHost.config , <location path="www.contoso.com">

Gültigkeitsbereich der FeaturesDie Startseiten der Knoten auf den verschiedenen Ebenen des Hierarchielistenfelds können unter-schiedliche Features anzeigen. Tabelle 6.1 zeigt, wo jedes Feature standardmäßig angezeigt wird.

Ob auf der Startseite ein Feature für ein markiertes Objekt angezeigt wird, ist von drei Faktoren abhängig:

� Objektebene Einige Features sind nur auf bestimmte Ebenen anwendbar.

� Delegierung Wenn die Delegierung eines Features auf Nicht delegiert gesetzt ist, erscheint dieses Feature nicht auf der Startseite.

� Lokale Verbindung oder Remoteverbindung Einige Features werden nur bei lokalen Verbindungen angezeigt.

Die meisten Features des IIS-Managers sind auf alle Knoten des Hierarchielistenfelds anwendbar: Server, Site, Anwendung, virtuelles Verzeichnis, Ordner und Datei. Diese Features erscheinen auf den Startseiten aller Ebenen. Es gibt jedoch Ausnahmen für die Serverebene. Einige Features stehen aus-schließlich auf der Serverebene zur Verfügung. Sie konfigurieren serverweit gültige Konfigurationen, Daten oder Informationen. Diese Features erscheinen nur auf der Startseite eines Servers:

� IIS-Manager-Benutzer

� IIS-Manager-Berechtigungen

� ISAPI- und CGI-Einschränkungen

� Serverzertifikate (dieses Feature wird bei Remoteverbindungen nicht angezeigt)

� Verwaltungsdienst (dieses Feature wird bei Remoteverbindungen nicht angezeigt)

� Arbeitsprozesse

� Active Directory- und Clientzertifikatoptionen, die Bestandteil des Authentifizierungsfeatures sind


Anpassung und Erweiterbarkeit des IIS 7.0-Managers 177

Darüber hinaus erscheinen einige Features auf allen Startseiten außer der des Servers. Dabei handelt es sich um die Features, die sich auf die Anwendungskonfiguration beziehen und deshalb auf der Server-ebene nicht sinnvoll sind. Es gibt weitere Features, wie z.B. SSL, für die dies gilt. Diese Features sind:

� .NET-Benutzer

� .NET-Rollen

� .NET-Profil

� SSL-Einstellungen

Eine weitere Ausnahme ist das Feature Delegierung von Features, das nur für den Stammknoten einer Verbindung angezeigt wird, wie z.B. für einen Server-, Site- oder Anwendungsknoten. Dieses Feature ist für virtuelle Verzeichnisse und Ordner nicht verfügbar.

Des Weiteren wirken sich die Einstellungen zur Featuredelegierung darauf aus, ob ein Feature im IIS-Manager angezeigt wird oder nicht. Ausführliche Informationen zur Featuredelegierung finden Sie im achten Kapitel.

Anpassung und Erweiterbarkeit des IIS 7.0-ManagersDer IIS-Manager ist nicht bloß eine Anwendung, sondern eine erweiterbare Plattform, die von Entwicklern genutzt werden kann, um eigene Features zur Verwaltung benutzerdefinierter Einstellungen und Anwendungen einzubringen. Entwickler können die Benutzeroberfläche verändern, bereits vorhandene Features entfernen und neue Verwaltungsfeatures hinzufügen.

IIS 7.0 wird mit einer API (Application Programming Interface) ausgeliefert, die es den Entwicklern ermöglicht, die Benutzeroberfläche des IIS-Managers zu verändern und auf dem Server benutzer-definierte Einstellungen und Anwendungen zu verwalten. Diese API bietet beispielsweise im Rahmen der Erweiterbarkeit die Möglichkeit, Benutzeroberflächenfeatures zu entwickeln, die in Form von Listen-seiten, Eigenschaftenrastern und Dialogseiten dargestellt werden. Aber auch die Entwicklung eines benutzerdefinierten Designs für den Bereich Aktionen und von Assistenten und Dialogfeldern ist möglich. Darüber hinaus können dem Bereich Verbindungen benutzerdefinierte Knoten hinzugefügt werden.

Direkt von der Quelle: IIS-Manager – gegründet auf der öffentlichen Erweiterbarkeits-APIWährend der Entwicklung des neuen IIS-Managers entschieden wir, dass die Erweiterbarkeit ein Kernfeature und der IIS-Manager eine echte Plattform sein sollte, so dass nicht nur wir, sondern auch andere Entwickler dazu in der Lage sein würden, seine Funktionalität zu erweitern. Um sicherzu-stellen, dass wir eine flexible API entwickelten, entschlossen wir uns dazu, alle Features unter Verwendung dieser API zu implementieren, so dass keines unserer Features ein spezieller Fall innerhalb des Produkts sein würde. Aus diesem Grund weist die IIS-Installation mehrere DLLs auf, wie z.B. Microsoft.Web.Management.Iis.dll und Microsoft.Web.Management.Aspnet.dll. Indem wir diese strengen Richtlinien befolgten und die API außerhalb des Kernframeworks erstellten, gewähr-leisteten wir, dass alles, was wir entwickelten, von anderen erweitert oder durch eigene Implemen-tierungen ersetzt werden konnte. Dies war natürlich eine Herausforderung, führte aber gleichzeitig dazu, dass unsere Plattform flexibel genug wurde, um zu gewährleisten, dass zusätzliche IIS-Features, wie z.B. FTP, WebDAV usw., einen Platz im IIS-Manager finden können.

Carlos Aguilar Mares

Senior Development Lead, IIS



Der IIS-Manager wurde für eine verteilte Client/Server-Architektur entworfen. Darüber hinaus verfügt der IIS-Manager über eine modulare Infrastruktur, bei der jedes Benutzeroberflächenfeature eine eigene Entität bildet. Jedes Feature befolgt das Client/Server-Paradigma. Diese Architektur des IIS-Managers trennt die Logik, die die Servereinstellungen modifiziert, von dem Code, der diese Ein-stellungen für jedes Benutzeroberflächenfeature in einer benutzerfreundlichen Weise darstellt.

Jedes IIS-Manager-Feature besteht aus zwei Komponenten:

� Ein clientseitiges Modul, das für die Benutzeroberfläche zuständig ist

� Ein serverseitiger Moduldienst, der die Einstellungen auf dem Server modifiziert

Diese Architektur ist in Abbildung 6.18 dargestellt. Die IIS-Manager-Erweiterungen müssen diese Architektur befolgen. Die in der API enthaltene Basisklasse sorgt dafür, dass dies geschieht.

Der erste Schritt zur Bereitstellung einer neuen IIS-Erweiterung besteht darin, deren Client- und Server-komponenten im globalen Assemblycache (GAC) des Servers zu installieren. Der zweite Schritt ist die Registrierung der neuen Erweiterung beim IIS-Manager. Jede Erweiterung muss einzeln beim IIS-Manager registriert werden. Der IIS-Manager gründet auf einer Erweiterbarkeit des Konfigurations-systems, die das einfache Hinzufügen von benutzerdefinierter Funktionalität ermöglicht.

Der IIS-Manager benutzt eine spezielle Datei namens administration.config, die die IIS-Manager-Konfiguration definiert. Die Datei administration.config befindet sich auf dem Server im Ordner %SystemRoot%\System32\Inetsrv\Config. Administration.config ist eine XML-Konfigurationsdatei, die eine Liste der in den IIS-Manager integrierten Features und Erweiterungen enthält. Beim Start des IIS-Managers wird diese Datei überprüft, um zu ermitteln, welche Features im IIS-Manager angezeigt werden sollen. Wenn der IIS-Manager eine Remoteverbindung herstellt, vergleicht der Webver-waltungsdienst die auf dem Server verfügbaren Modulanbieter mit den auf dem Client verfügbaren Modulanbietern. Wenn auf dem Server eine neue Erweiterung verfügbar ist, wird der Client dazu aufgefordert, diese Erweiterung herunterzuladen und zu installieren.

Die IIS 7.0-Verwaltungs- und Administrations-APIDie API befindet sich in zwei Assemblies, die auf dem Server ein Framework zur Modifizierung der Benutzeroberfläche des IIS-Managers und zur Entwicklung neuer Features für die Verwaltung benutzerdefinierter Anwendungen zur Verfügung stellen. Diese Assemblies sind:

� Microsoft.Web.Management.dll Diese Assembly stellt das Framework zur Verfügung, mit dem Entwickler neue Benutzeroberflächenfeatures erstellen und Modifikationen am IIS-Manager vornehmen können. Sie bietet eine Basisklasse und andere Funktionen an, durch die neu entwickelte Erweiterungen mit einem Look and Feel dargestellt werden, das dem der integrierten IIS- und ASP.NET-Features entspricht. Sie unterstützt aber nicht das Ändern der Einstellungen auf dem Server.

� Microsoft.Web.Administration.dll Diese Assembly stellt das Framework zur Verfügung, mit dem Entwickler die Einstellungen auf dem Server ändern können. Sie gibt den Entwicklern ein programmgesteuertes Verfahren an die Hand, mit dem es möglich ist, auf die Webserverkonfigu-rationen und die Verwaltungsinformationen zuzugreifen und diese zu aktualisieren. Sie unter-stützt nicht das Hinzufügen von Benutzeroberflächenerweiterungen oder -funktionalität. Die meisten Features des IIS-Managers nutzen diese API, um die Konfigurationseinstellungen auf dem Server zu verwalten.


Anpassung und Erweiterbarkeit des IIS 7.0-Managers 179

Abbildung 6.18 Die Client/Server-Architektur für IIS-Manager-Features

Der <moduleProviders>-Abschnitt in der Datei administration.config definiert alle im System registrierten IIS-Manager-Erweiterungen. Um eine Erweiterung zu registrieren, müssen Sie dem <moduleProviders>-Abschnitt den voll qualifizierten Typnamen des Modulanbieters dieser Erweiterung und dem <modules>-Abschnitt den Modulnamen hinzufügen. Abhängig vom gewünschten Gültigkeitsbereich der Erweite-rung müssen Sie möglicherweise den entsprechenden Modulnamen dem zugehörigen <location path>-Abschnitt hinzufügen, der die Sites und Anwendungen definiert, für die diese Erweiterung im IIS-Manager angezeigt wird. Der folgende Auszug aus administration.config zeigt im <moduleProviders>-Abschnitt einen integrierten Modulanbieter für das Modul DefaultDocument und im <modules>-Abschnitt den Modulnamen DefaultDocument. Der zuletzt genannte Abschnitt verwendet den Speicherortstammpfad, so dass alle Sites und Anwendungen des Servers darauf zugreifen können.<moduleProviders>  <add name="DefaultDocument" type="Microsoft.Web.Management.Iis.DefaultDocument DefaultDocumentModuleProvider, Microsoft.Web.Management.Iis, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> </moduleProviders>  <location path="."> <modules> <add name="DefaultDocument" /> … </modules> </location>


Nachdem Sie die Erweiterung registriert haben, wird der Client beim nächsten Start des IIS-Managers dazu aufgefordert, die Clientkomponente dieser Erweiterung herunterzuladen und zu installieren.

Hinweis Weitere Informationen zur Erweiterung des IIS-Managers und zur Erstellung benutzerdefinierter Konfigurationsabschnitte in .config-Dateien finden Sie im dreizehnten Kapitel, »Konfigurations- und Benutzeroberflächenerweiterungen verwalten«.

RemoteverwaltungRemoteverbindungen sind im IIS-Manager standardmäßig nicht verfügbar. Um ein unter Windows Server 2008 ausgeführtes IIS 7.0-System remote zu verwalten, müssen Sie die Clientcomputer ent-sprechend einrichten und den Server für die Remoteverwaltung konfigurieren.

Um ein unter Windows Server 2008 ausgeführtes IIS 7.0-System von Clientcomputern aus remote zu verwalten, auf denen Windows Vista Service Pack 1 (SP1), Windows Server 2003 SP1 oder Windows XP SP2 ausgeführt wird, müssen Sie auf diesen Clientcomputern den IIS-Manager installieren und dann eine Verbindung zu den Sites und Anwendungen des Servers herstellen, die Sie verwalten möchten. Sie können den IIS-Manager für diese Betriebssysteme unter der folgenden Adresse beziehen: http://iis.net/downloads.

Auf dem Server müssen Sie die Remoteverwaltung von IIS 7.0 über den IIS-Managers explizit akti-vieren. Dies geschieht anders als bei IIS 6.0, wo der Remotezugriff auf die Verwaltungskonsole über das MMC-Snap-In erfolgte und immer aktiv war. Für die Remoteverwaltung von IIS 7.0 muss der Webverwaltungsdienst (WMSvc) auf dem Server installiert sein und ausgeführt werden. Darüber hinaus müssen Remoteverbindungen zu diesem Dienst ermöglicht werden.

Der Webverwaltungsdienst ist standardmäßig nicht installiert – Sie müssen ihn manuell installieren. Während der Installation können Sie die IP-Adresse und die Portnummer angeben, die der Dienst überwachen soll, oder Sie akzeptieren die Voreinstellungen: Keine zugewiesen für die IP-Adresse und 8172 für die Portnummer. Eine ausführliche Anleitung zur Installation von WMSvc finden Sie im achten Kapitel.

Nachdem Sie den Webverwaltungsdienst installiert haben, wird im IIS-Manager auf der Startseite des Servers das Feature Verwaltungsdienst angezeigt. Sie können dann dieses Feature konfigurieren, um die zu bedienenden Remoteverbindungen zu aktivieren.

Um Remoteverbindungen zu aktivieren, gehen Sie unter IIS wie folgt vor:

1. Markieren Sie im Bereich Verbindungen den Serverknoten. Die Startseite des Servers wird angezeigt.

2. Führen Sie einen Doppelklick auf dem Feature Verwaltungsdienst auf, um die Seite des Features Verwaltungsdienst zu öffnen.

3. Klicken Sie auf der Seite des Features Verwaltungsdienst und dort im Bereich Aktionen auf Beenden, um den Dienst zu beenden.

4. Aktivieren Sie das Kontrollkästchen Remoteverbindungen aktivieren. Dies ermöglicht es dem Server-administrator, eine Verbindung zum Server sowie zu Sites und Anwendungen remote herzustellen.


Zusammenfassung 181

Hinweis Die Einstellung, die die Remoteverwaltung ermöglicht, wird in der Windows-Registrierung in einem dword-Wert namens EnableRemoteManagement gespeichert. Dies geschieht unter dem Registrierungsschlüssel HKLM\SOFT-WARE\Microsoft\WebManagement\Server.

5. Wenn Sie möchten, dass Benutzer ohne administrative Rechte die Sites und Anwendungen des Servers verwalten können, wählen Sie für diese Benutzer die Art der Anmeldeinformationen. Kon-figurieren Sie andere Einstellungen, sofern dies erforderlich ist, z.B. Verbindungs- und Protokollie-rungsoptionen und IPv4- und Domäneneinschränkungen. Klicken Sie im Bereich Aktionen auf Übernehmen, um die Änderungen zu speichern, und dann auf Starten, um den Dienst zu starten.

Hinweis Eine ausführliche Erläuterung der Remoteverwaltung, die sich auch mit Webverwaltungsdiensteinstellun-gen befasst, erhalten Sie im achten Kapitel.

ZusammenfassungDer IIS-Manager wurde für IIS 7.0 von Grund auf neu erstellt und unterscheidet sich stark von dem MMC-Snap-In, das für frühere IIS-Versionen verwendet wurde. Der IIS-Manager von IIS 7.0 ist eine Clientanwendung mit einer sich intuitiv erschließenden, feature- und aufgabenorientierten spezifischen Benutzeroberfläche, die die mit den Verwaltungsaufgaben einhergehende Komplexität wesentlich verringert.

Der IIS-Manager ermöglicht die gemeinsame Verwaltung von IIS- und ASP.NET-Features mit nur einem Tool. Die Features des IIS-Managers sind den Konfigurationsabschnitten in den .config-Dateien zugeordnet und stellen eine einfach zu bedienende Benutzeroberfläche für die Arbeit mit komplexen, in der .config-Dateihierarchie verborgenen Einstellungen zur Verfügung.



Der IIS-Manager ist hochgradig anpassbar und bietet eine erweiterbare Plattform, die von Entwicklern genutzt werden kann, um eigene administrative Features für die Verwaltung benutzerdefinierter Einstellungen und Anwendungen einzubringen.

Der IIS-Manager unterstützt die Remoteverwaltung und die Delegierung von Features, so dass Benutzer, die auf dem Server über keine administrativen Rechte verfügen, Sites und Anwendungen von ihren Clientcomputern aus remote verwalten können.

Weitere Informationen� Informationen zum Befehlszeilentool Appcmd.exe, zum WMI-Management-Anbieter und

PowerShell erhalten Sie im siebten Kapitel, »Verwenden von Befehlszeilentools«.

� Informationen zur Remoteverwendung des IIS-Managers finden Sie im achten Kapitel, »Remoteverwaltung«.

� Informationen zur Erweiterung des IIS-Managers bietet das dreizehnte Kapitel, »Konfigurations- und Benutzeroberflächenerweiterungen verwalten«.

� Eine Liste der Verwaltungsaufgaben, die vorwiegend mit dem IIS-Manager ausgeführt werden, finden Sie in Anhang J, »Durchführen von Administrationsaufgaben im Internetinformationsdienste-Manager«.

� Eine Einführung in die Arbeit mit dem IIS 7.0-Manager erhalten Sie unter http://www.iis.net//articles/view.aspx/IIS7/Use-IIS7-Administration-Tools/IIS-Manager-Administration-Tool/Getting-Started-with-IIS-Manager.


183

K A P I T E L 7

Verwenden von Befehlszeilentools

Inhalt dieses Kapitels:� Befehlszeilentools für die Verwaltung benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

� Appcmd.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

� Erste Schritte mit Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

� Die Grundverben verwenden: List, Add, Set und Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

� Arbeiten mit der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

� Mit Anwendungen, virtuellen Verzeichnissen und Anwendungspools arbeiten . . . . . . . . . . . . . . . 207

� Mit Webservermodulen arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

� Ausgeführte Arbeitsprozesse und Anforderungen untersuchen . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

� Mit der Ablaufverfolgung für Anforderungsfehler arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

� Microsoft.Web.Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

� Windows PowerShell und IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

� WMI-Anbieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

� COM-Objekte für die IIS 7.0-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219




Befehlszeilentools für die Verwaltung benutzenEs ist nicht immer möglich oder sinnvoll, den IIS-Manager für bestimmte Verwaltungsaufgaben zu verwenden. IIS-Administratoren (Internet Information Services; Internetinformationsdienste) müssen oft Befehlszeilentools für bedarfsorientierte oder automatisierte Vorgänge benutzen. Häufige Verwaltungsaufgaben wie zum Beispiel die Erstellung und Konfiguration von Sites, Anwendungspools und virtuellen Verzeichnissen können mithilfe von Befehlszeilentools und Programmierschnittstellen effizienter gelöst werden.

Dieses Kapitel konzentriert sich auf die Verwaltung von IIS 7.0 über die Befehlszeile. Dazu wird Appcmd.exe verwendet, ein einzelnes Befehlszeilentool, das verschiedene Skripts und Tools früherer IIS-Versionen ersetzt. Appcmd wird standardmäßig installiert und ist sofort für die Verwaltung von IIS über die Befehlszeile verfügbar. Es kann benutzt werden, um fast jeden IIS 7.0-Verwaltungsvorgang innerhalb kürzester Zeit von der Befehlszeile aus manuell auszuführen oder eine große Anzahl von Konfigurationsoperationen effizient zu automatisieren.


184 Kapitel 7: Verwenden von Befehlszeilentools

Zusätzlich zu Appcmd bietet IIS 7.0 viele andere Automatisierungsoptionen an, für die die Entwicklung von benutzerdefiniertem Skriptcode erforderlich ist. Diese Optionen sind für komplexere Automati-sierungsvorgänge oder solche Aufgaben geeignet, die im Kontext eines anderen Programms ausgeführt werden müssen. Diese Optionen werden in diesem Kapitel nicht ausführlich behandelt, doch am Ende des Kapitels finden Sie einige Quellenverweise, so dass Sie mehr darüber erfahren können.

Zu diesen Optionen zählen:

� Microsoft.Web.Administration Benutzen Sie den Namespace Microsoft.Web.Administration (MWA), um von einer auf dem .NET Framework basierenden Anwendung aus häufige Verwal-tungsaufgaben auszuführen.

� Windows PowerShell Installieren Sie dieses Windows Server 2008-Feature, um IIS innerhalb einer Befehlszeilenumgebung zu konfigurieren und zu verwalten. (Windows PowerShell ist für Computer, die mit dem Betriebssystem Windows Vista, Windows Server 2003 oder Windows XP arbeiten, auch als kostenloser Download erhältlich.)

� WMI-Anbieter Der neue WMI-Anbieter (Windows Management Instrumentation) bietet die Möglichkeit, die IIS 7.0-Konfiguration mithilfe von Skripts zu verwalten, die das WMI-Objekt-modell nutzen.

� COM-Objekte für die IIS 7.0-Konfiguration Sie können die COM-Objekte für die IIS 7.0-Konfiguration (Component Object Model) direkt von C++-Programmen, Skripts oder verwaltetem Code aus verwenden, um auf das IIS 7.0-Konfigurationssystem zuzugreifen.

Wenn Sie zwischen der über die Befehlszeile erfolgenden und der programmgesteuerten IIS 7.0-Verwaltung wählen, ist Ihre Entscheidung oft von Ihren Präferenzen hinsichtlich des Programmier-modells und von der Umgebung abhängig, in der die Verwaltungsfunktionalität benötigt wird. Sie sollten auch die Vorzüge und Einschränkungen der verfügbaren Optionen berücksichtigen, die in Tabelle 7.1 beschrieben sind.

Tabelle 7.1 Vorzüge und Einschränkungen der Optionen zur Verwaltung über die Befehlszeile

Option Vorteile Nachteile

Appcmd � Schnelle Verwaltung, für die kein Code erforderlich ist

� Funktioniert bei vollständigen Windows- und bei Server Core-Installationen

� Bietet neben den COM-Konfigurationsobjekten bei vielen Operationen die beste Leistung

� Keine Unterstützung der Remoteverwaltung

� Erfordert administrative Rechte

� Die Befehlszeile kann bei komplexen Ver-waltungsvorgängen Einschränkungen unter-liegen

Microsoft.Web.Administration � Beste Option für .NET Framework-Pro-gramme

� Unterstützt die Remoteverwaltung

� Code ist erforderlich

� Ist für Server Core nicht verfügbar, kann aber für die Remoteverwaltung von Server Core-Servern verwendet werden

COM-Konfigurationsobjekte � Beste Option für native C++-Programme und Skripts

� Funktioniert bei vollständigen Windows- und bei Server Core-Installationen

� Unterstützt die Remoteverwaltung

� Bietet die beste Leistung

� Code ist erforderlich


Appcmd.exe 185

Appcmd.exeAppcmd.exe ist ein neues in IIS 7.0 enthaltenes Befehlszeilentool. Es ermöglicht die meisten Web-serververwaltungsvorgänge über eine einzelne, sich intuitiv erschließende Befehlszeilenschnittstelle. Dieses Tool ersetzt viele Befehlszeilentools und Skripts, die von IIS 6.0 zur Verfügung gestellt wurden, um die wesentlichen Verwaltungsaufgaben zu lösen.

Mit Appcmd verfügt ein Webserveradministrator an der Befehlszeile über die folgenden Möglich-keiten:

� Websites, Anwendungen virtuelle Verzeichnisse und Anwendungspools hinzufügen und konfigurieren

� Webservermodule installieren, aktivieren und konfigurieren

� Sites starten und beenden und Anwendungspools wiederverwenden

� Gegenwärtig ausgeführte Arbeitsprozesse und Anforderungen auflisten

� Die IIS- und ASP.NET-Konfiguration durchsuchen, anzeigen und modifizieren

� Die Einstellungen zu Ablaufverfolgung für Anforderungsfehler konfigurieren

Besonders erwähnenswert ist die Möglichkeit, die IIS-Konfiguration einzusehen und zu bearbeiten. Sie ermöglicht es den Administratoren, jeden beliebigen Konfigurationsvorgang unabhängig vom zu konfigurierenden Feature schnell auszuführen oder zu automatisieren. Die restliche Funktionalität dient allgemeinen Konfigurations- und Verwaltungsaufgaben.

Appcmd.exe ist für die lokale Verwaltung des Webservers vorgesehen (es unterstützt unter IIS 7.0 keine Remoteverwaltung) und die Benutzer müssen über administrative Rechte verfügen, wenn sie mit dem Tool arbeiten möchten. Soll eine Remoteverwaltung durchgeführt oder der Webserver von Benutzern konfiguriert werden, die keine Serveradministratoren sind, benötigen Sie die Remotedelegierung, die der IIS-Manager anbietet. Weitere Informationen hierzu erhalten Sie im achten Kapitel, »Remoteverwaltung«.

WMI � Unterstützt die Remoteverwaltung� Funktioniert bei vollständigen Windows-

und bei Server Core-Installationen� Ermöglicht eine Remoteverwaltung, die von

anderen Windows-Betriebssystemen aus erfolgen kann

� Code ist erforderlich� Führt zu einem WMI-Overhead

� Erfordert administrative Rechte

PowerShell � Bietet die Flexibilität der Windows PowerShell-Befehlszeilenumgebung

� Unterstützt unter Windows Server 2008 die Remoteverwaltung nicht direkt

� Ist für Server Core nicht verfügbar, kann aber für die Remoteverwaltung von Server Core-Servern verwendet werden

� Erfordert die Entwicklung benutzerdefinierter Cmdlets

Tabelle 7.1 Vorzüge und Einschränkungen der Optionen zur Verwaltung über die Befehlszeile (Fortsetzung)

Option Vorteile Nachteile



Erste Schritte mit AppcmdAppcmd.exe befindet sich im Verzeichnis %SystemRoot%\System32\Inetsrv. Da dieses Verzeichnis standardmäßig kein Bestandteil der Umgebungsvariablen PATH ist, müssen Sie es entweder PATH hinzufügen oder immer den vollständigen Pfad zum Befehl benutzen, wenn Sie Appcmd-Anweisungen ausführen lassen möchten. Sollten Sie sich für die letzte Möglichkeit entscheiden, können Sie Appcmd beispielsweise wie folgt aufrufen:%systemroot%\system32\inetsrv\Appcmd list sites

Bei den in diesem Kapitel aufgeführten Befehlen verzichten wir auf die Angabe des vollständigen Pfades, wenn wir Appcmd-Anweisungen präsentieren. Sie müssen somit entweder das Inetsrv-Verzeichnis der Umgebungsvariablen PATH hinzufügen oder jeden Befehl mit dem gesamten Pfad vervollständigen.

Hinweis Um Appcmd.exe ausführen zu können, müssen Sie entweder das Inetsrv-Verzeichnis der Umgebungs-variablen PATH hinzufügen oder den vollständigen, zu Appcmd.exe führenden Pfad verwenden. Erst dann können die Appcmd-Befehle ihre Arbeit verrichten.

Um Appcmd aufrufen zu können, müssen Sie am lokalen Computer als Mitglied der Gruppe Administ-ratoren angemeldet sein. Wenn Sie darüber hinaus Appcmd unter Windows Vista verwenden, müssen Sie das Tool als Administrator ausführen, um sicherzustellen, dass die Benutzerkontensteuerung die korrekte Ausführung des Tools nicht verhindert. Dazu sollten Sie die Appcmd-Befehle aus einer hochgestuften Eingabeaufforderung heraus aufrufen. Sie erhalten eine hochgestufte Eingabeauf-forderung, wenn Sie diese mit der Option Als Administrator ausführen starten. Öffnen Sie dazu das Startmenü, klicken Sie auf Alle Programme, wählen Sie Zubehör, und klicken Sie mit der rechten Maustaste auf Eingabeaufforderung, um im folgenden Kontextmenü Als Administrator ausführen zu wählen.

Hinweis Um Appcmd benutzen zu können, müssen Sie als Mitglied der Gruppe Administratoren angemeldet sein. Unter Windows Vista müssen Sie die Appcmd-Befehle aus einer Eingabeaufforderung heraus aufrufen, die sie mit der Option Als Administrator ausführen gestartet haben.

Appcmd verwendet eine Syntax, die an die natürliche Sprache angelehnt ist und zuerst das Verb und dann das Objekt nennt. Dies ist ein Unterschied zu einigen anderen Windows-Tools, die mit einer Syntax arbeiten, bei der zuerst das Objekt und dann das Verb angegeben wird, um Befehle für verschiedene Objektkontexte zu ermöglichen (ein Beispiel für ein solches Tool ist netsh). Um beispiels-weise auf dem Server die Websites aufzulisten, die das Site-Objekt verwenden, benutzen Sie den folgenden Befehl:Appcmd list sites

Jeder Befehl gibt eine oder mehrere Objektinstanzen oder Nachrichten aus, die während der Befehls-ausführung generiert werden. Der vorherige Befehl könnte beispielsweise die folgende Ausgabe erzeugen:SITE "Default Web Site" (id:1,bindings:http/*:80:,state:Started) SITE "TestSite" (id:2,bindings:http/*:80:testsite,state:Started)

Die Ausgabe ist eine Liste von Site-Objekten samt deren Bezeichnern (Default Web Site, TestSite). Die Liste führt außerdem einige wichtige Attribute des Objekts auf (id, bindings, state).


Erste Schritte mit Appcmd 187

Appcmd unterstützt eine große Anzahl von Objekten, und die meisten Objekte unterstützen einen Standardsatz Verben, wie z.B. List, Add, Set und Delete. Einige Objekte besitzen zusätzliche Verben, die objektspezifisch sind. Alle Verben akzeptieren Parameter, mit denen Sie das Verhalten eines jeden Befehls anpassen können. Schließlich akzeptieren einige Verben einen speziellen Parameter, der Bezeichner genannt wird und die Instanz des Objekts eindeutig identifiziert, für die das jeweilige Verb ausgeführt werden soll. Der Bezeichner ist eine objektspezifische Benennung.

Sie können beispielsweise den Befehl Delete Site in Verbindung mit dem Sitenamen als Bezeichner benutzen, um eine Website zu löschen, wie das folgende Beispiel zeigt:Appcmd Delete Site "TestSite"

Dies führt zur folgenden Ausgabe:SITE object "TestSite" deleted

Die Appcmd-Syntax und die Liste der unterstützten Objekte werden im folgenden Abschnitt »Die Syntax von Appcmd« näher erläutert.

Die Syntax von AppcmdAppcmd verwendet die folgende Syntax:Appcmd <Verb> <Objekt> [Bezeichner] [/Parameter:Wert]

Diese Syntax besteht aus den folgenden Teilen:

� Verb Das Verb ist die Aktion, die für das angegebene Objekt ausgeführt werden soll. Jedes Objekt unterstützt einen festen Satz Verben, und jedes Verb kann die Verwendung von Bezeichnern und Parametern ermöglichen, wobei es bisweilen Parameter gibt, die angegeben werden müssen. Die meisten Objekte unterstützen grundlegende Befehle, wie z.B. List, Add, Set und Delete, und einige Objekte bieten zusätzliche Befehle an. Das Verb muss immer angegeben werden. Es unterscheidet nicht zwischen Groß- und Kleinschreibung.

� Objekt Das Objekt ist der Name des Verwaltungsobjekts, für das das angegebene Verb aufgerufen wird. Zusammen mit dem Verb bestimmt es den eigentlichen auszuführenden Befehl. Die unter-stützten Objekte sind in Tabelle 7.2 aufgeführt. Das Objekt muss immer angegeben werden. Es unterscheidet nicht zwischen Groß- und Kleinschreibung.

� Bezeichner Der Bezeichner ist ein optionales Argument, das dem Objekt folgt. Sie können ihn benutzen, um eine spezielle Instanz des Objekts, für das der Befehl ausgeführt werden soll, eindeu-tig zu identifizieren. Er ist für die meisten Befehle, die Aktionen für bestimmte Objektinstanzen ausführen, zwingend erforderlich. Dazu zählen beispielsweise die Befehle Set und Delete. Der Bezeichner weist ein objektspezifisches Format auf, das zur Identifizierung der Instanzen des jeweiligen Objekts verwendet wird, und er kann zwischen Groß- und Kleinschreibung unter-scheiden, muss dies aber nicht. Informationen zum Format des Bezeichners finden Sie in den Abschnitten dieses Kapitels, die sich mit den einzelnen Objekten beschäftigen.

� Parameter Verben können Parameter unterstützen, die im Format /Name:Wert angegeben werden und die Ausführung des jeweiligen Befehls steuern. Die Parameternamen unterscheiden nicht zwischen Groß- und Kleinschreibung, bei den Werten kann dies jedoch der Fall sein. Informationen zu den unterstützten Parametern finden Sie in den Abschnitten dieses Kapitels, die sich mit den einzelnen Objekten beschäftigen. Darüber hinaus bietet das Tool selbst einige allgemeine Parameter an, die sich auf die Ausführung jedes Befehls auswirken. Informationen zu diesen Parametern finden Sie später in diesem Kapitel im Abschnitt »Allgemeine Parameter«.



Jeder Appcmd-Befehl muss mindestens das Objekt und das Verb angeben. Möchten Sie beispielsweise das List-Verb des Site-Objekts benutzen, um die Websites des Servers aufzulisten, können Sie den folgenden Befehl verwenden:Appcmd List Site

Sie können dem List-Verb des Site-Objekts einen optionalen Bezeichner übergeben, mit dem Sie die Website eindeutig identifizieren, an deren Auflistung Sie interessiert sind. Das Site-Objekt verwendet den Websitenamen als eindeutigen Bezeichner (nicht die Website-ID). Um somit nach einer spezifi-schen Website namens Default Web Site zu suchen, können Sie die folgende Syntax verwenden:Appcmd List Site "Default Web Site"

Alternativ hierzu können Sie optionale Parameter anstelle des Bezeichners verwenden, um nach allen Websiteinstanzen zu suchen, die bestimmte Attribute aufweisen. Sie können sogar alle Konfigurations-attribute der Websitedefinition als Parameter des List Site-Befehls angeben, um nach den Sites zu suchen, deren Konfigurationsparameter auf die festgelegten Werte gesetzt sind. Um beispielsweise alle Websites zu finden, deren serverAutoStart-Konfigurationsattribut auf false gesetzt ist, können Sie die folgende Syntax benutzen:Appcmd List Site /serverAutoStart:false

Eine Liste der unterstützten Objekte und Verben finden Sie im folgenden Abschnitt »Unterstützte Objekte«.

Unterstützte ObjekteAppcmd unterstützt die in Tabelle 7.2 aufgelisteten Objekte und die dazugehörigen Befehle.

Tabelle 7.2 Von Appcmd unterstützte Objekte

Objekt Beschreibung Befehle

Site (Sites) Websites verwalten List, Set, Add, Delete, Start, Stop

App (Apps) Anwendungen verwalten List, Set, Add, Delete

Vdir (Vdirs) Virtuelle Verzeichnisse verwalten List, Set, Add, Delete

Apppool (Apppools) Anwendungspools verwalten List, Set, Add, Delete, Start, Stop, Recycle

Config (Configs) IIS-Konfigurationsabschnitte verwalten List, Set, Search, Lock, Unlock, Clear, Reset, Migrate

Wp (Wps) Listet die gegenwärtig ausgeführten Arbeits- prozesse auf

List

Request (Requests) Listet die gegenwärtig ausgeführten HTTP- Anforderungen auf

List

Module (Modules) Verwaltet Webservermodule List, Set, Add, Delete, Install, Uninstall

Backup (Backups) Verwaltet Konfigurationssicherungen List, Add, Delete, Restore

Trace (Traces) Verwaltet die Konfiguration der Ablaufverfolgung für Anforderungsfehler und Ablaufverfolgungsprotokolle

List, Configure, Inspect



Hinweis Beachten Sie, dass in der Spalte Objekt ebenfalls der Plural jedes Objektnamens aufgeführt ist. Der Grund hierfür besteht darin, dass Appcmd einen Alias für jedes Objekt zur Verfügung stellt und diesen verwendet, damit auch die Pluralform des Objektnamens für dessen Referenzierung verwendet werden kann. Deshalb können Sie den Befehl List Sites (plural) benutzen, um Websites aufzulisten, während Sie z.B. Set Site (singular) ver-wenden, um ein Konfigurationsattribut einer Website festzulegen.

Die einzelnen Objekte und die dazugehörigen Befehle werden später in diesem Kapitel ausführlich beschrieben. Sie erhalten ebenfalls Informationen über die unterstützten Objekte, Verben und die Syntax jedes Verbs, wenn Sie die integrierte Appcmd-Befehlszeilenhilfe verwenden. Mehr dazu im folgenden Abschnitt »Die Hilfe nutzen«.

Die Hilfe nutzenDa Appcmd solch eine Vielfalt an Objekten und Verben bietet und jedes Verb über verschiedene Para-meter verfügt, stellt das Programm ein umfassendes Hilfesystem zur Verfügung, das Sie beim Erlernen der Verwendung des Tools unterstützt.

Es gibt bei Appcmd drei verschiedene Ebenen der Hilfe:

1. Die übergeordnete Hilfe. Zeigt eine Liste der vom Appcmd unterstützten Objekte und die allgemei-nen Toolparameter an, die Sie für jeden Befehl verwenden können. Um diese Hilfe aufzurufen, lassen Sie Appcmd ohne Parameter oder mit dem Parameter /? ausführen, zum Beispiel Appcmd /?.

2. Die Objekthilfe. Zeigt die Liste der Verben an, die von einem bestimmten Objekt unterstützt wer-den. Um diese Hilfe aufzurufen, benutzen Sie den Parameter /?, der dem Objektnamen folgen muss, z.B. Appcmd Site /?.

3. Die Verbhilfe. Zeigt die Liste der Parameter an, die von einem bestimmten Verb eines bestimmten Objekts unterstützt werden. Darüber hinaus werden Anwendungsbeispiele angezeigt. Um diese Hilfe aufzurufen, benutzen Sie den Parameter /?, der dem Verb- und Objektnamen folgen muss, z.B. Appcmd List Site /?.

Diese drei Ebenen verdeutlichen, wie die Benutzer das Hilfesystem von Appcmd in der Regel benutzen, um zu erfahren, wie ein bestimmter Befehl ausgeführt wird. Sie können zuerst die Liste der unter-stützten Objekte mit der übergeordneten Hilfe anzeigen lassen. Die daraus resultierende Ausgabe enthält die Liste der unterstützten Objekte, wie nachfolgend gezeigt:Allgemeines IIS-Befehlszeilen-Verwaltungstool APPCMD (Befehl) (Objekttyp) <ID> </Parameter1:Wert1 ...> Unterstützte Objekttypen: SITE Verwaltung von virtuellen Sites APP Verwaltung von Anwendungen VDIR Verwaltung von virtuellen Verzeichnissen ... (Rufen Sie mit "/?" eine Liste der vom entsprechenden Objekt unterstützten Befehle auf, z. B. "appcmd.exe site /?".) Allgemeine Parameter: /? Kontextbezogene Hilfemeldung anzeigen



/text<:value> Ausgabe im Textformat generieren (Standard) /text:* Alle Objekteigenschaften in der Detailansicht anzeigen /text:<Attribut> Wert des angegebenen Attributs für jedes Objekt anzeigen /xml Ausgabe im XML-Format generieren Hiermit generieren Sie eine Ausgabe, die an einen anderen Befehl im "/in"-Modus übergeben werden kann. ... Verwenden Sie das Ausrufezeichen "!", um Parameter anzugeben, die denselben Namen haben wie die allgemeinen Parameter, beispielsweise "/!debug:value" zum Festlegen einer Konfigurationseigenschaft "debug".

Die übergeordnete Hilfe zeigt zusätzlich die Liste der allgemeinen Toolparameter an, die die Aus-führung des Programms unabhängig vom Befehl kontrollieren. Weitere Informationen zu diesen Parametern erhalten Sie später in diesem Kapitel im Abschnitt »Allgemeine Parameter«.

Sie können nun spezifische Informationen zu einem bestimmten Objekt abrufen, indem Sie die Syntax Appcmd Objekt /? verwenden. Daraufhin wird eine Liste der unterstützten Verben angezeigt. Um beispiels-weise die vom Site-Objekt unterstützten Verben aufzulisten, benutzen Sie die folgende Anweisung:Appcmd Site /?

Die Ausgabe präsentiert sich wie folgt:Verwaltung von virtuellen Sites APPCMD (Befehl) SITE <ID> <-Parameter1:Wert1 ...> Unterstützte Befehle: list Virtuelle Sites auflisten set Virtuelle Site konfigurieren add Neue virtuelle Site hinzufügen delete Virtuelle Site löschen start Virtuelle Site starten stop Virtuelle Site beenden (Rufen Sie mit /? die Hilfe für die einzelnen Befehle ab, z. B. "appcmd.exe add site /?".)

Der letzte Schritt besteht darin, die spezifische Syntax des benötigten Verbs mit der Syntax Appcmd Verb Objekt /? abzurufen. Um beispielsweise die spezifische Syntax des Befehls List Site zu erhalten, benutzen Sie die folgende Anweisung:Appcmd List Site /?

Dies führt zur folgenden Ausgabe:Virtuelle Sites auflisten APPCMD list SITE <ID> <-Parameter1:Wert1 ...> Listet die virtuellen Sites auf dem Computer auf. Mit diesem Befehl kann eine bestimmte Site über die ID oder URL gesucht werden, oder es können null oder mehrere Sites gesucht werden, die den angegebenen Siteattributen entsprechen. Unterstützte Parameter: identifier Sitename oder URL der gesuchten Site



/site.name Sitename oder URL der gesuchten Site (identisch mit der ID) /? Dynamische Eigenschaften der Site anzeigen, mit denen ein oder mehrere Siteobjekte gesucht werden können Beispiele: appcmd list sites Alle Sites auf dem Computer auflisten appcmd list site "Default Web Site" Site "Default Web Site" suchen appcmd list site http://localhost/app1 Der angegebenen URL zugeordnete Site suchen appcmd list site /serverAutoStart:false Alle Sites suchen, deren "serverAutoStart"-Konfigurationseigenschaft auf "false" festgelegt ist

Beachten Sie, dass die Hilfeausgabe die Liste der unterstützten Parameter einschließlich der Bezeichner enthält. Der hier aufgeführte Parameter /? gibt an, dass Sie ebenfalls die von jeder Objektinstanz bereitgestellten dynamischen Parameter verwenden können. Beim List Site-Befehl können Sie jedes der in der Websitedefinition angegebenen Konfigurationsattribute als Parameter festlegen, um nach allen Websiteinstanzen zu suchen, denen die angegebenen Parameterwerte zugewiesen sind.

Hinweis Um die Liste der dynamischen Parameter abzurufen, können Sie das Verb Set für eine mit einem Bezeich-ner angegebene Objektinstanz und den Parameter /? verwenden. Dies führt dazu, dass die unterstützten Attribute aufgelistet werden. Zum Beispiel: Appcmd Set Site "Default Web Site" /?. Dabei handelt es sich sicherlich nicht um die ideale Vorgehensweise. Es ist jedoch eine Möglichkeit, um die dynamischen Parameter, die Sie für jeden, dyna-mische Objektparameter unterstützenden Befehl verwenden können, schnell anzeigen zu lassen.

Die Liste der Beispiele zu jedem Befehl ist sehr praktisch, da sie zeigt, wie der jeweilige Befehl oft genutzt wird. Beim Websiteobjekt zeigt die Liste beispielsweise, wie Sites aufgelistet werden, und zwar alle Sites, Sites, die dem angegebenen Bezeichner (Name) entsprechen, Sites, die einen bestimmten URL bedienen, und Sites, die einem bestimmten Konfigurationsparameterwert entsprechen.

Hinweis Achten sie darauf, die Beispiele zu einem Verb zu betrachten, um schnell ein Gespür für die verschiedenen Möglichkeiten der Verwendung des Befehls zu bekommen.

Die Ausgabe von Appcmd verstehenDie Ausgabe von Appcmd enthält in der Regel eine Liste mit Elementen. Bei Befehlen, die Objekt-instanzen zurückgeben, wie z.B. der Befehl List, handelt es sich um eine Liste mit Objektinstanzen. Bei Befehlen, die Aktionen für bestimmte Objektinstanzen ausführen, handelt es sich um eine Liste mit Nachrichten, die Aufschluss über die ausgeführte Aktion geben.



Die Ausgabe des Befehls List Site enthält beispielsweise eine Liste mit Instanzen von Websiteobjekten. Dazu ein Beispiel:SITE "Default Web Site" (id:1,bindings:http/*:80:,state:Started) SITE "TestSite" (id:2,bindings:http/*:80:testsite,state:Started)

Appcmd benutzt standardmäßig eine benutzerfreundliche Listenansicht, die den Objekttyp, den Bezeichner, der für die anschließenden Befehle zur Identifizierung der jeweiligen Instanz benötigt wird, und mehrere allgemeine Attribute jeder Objektinstanz aufführt. Beim Site-Objekt ist dies die ID der Website, die Liste der konfigurierten Bindungen und der Status der Website (der angibt, ob sie gestartet oder beendet ist).

Jede Instanz des Site-Objekts enthält mehr Attribute, als in der benutzerfreundlichen Listenansicht zu sehen sind. Um diese Parameter anzeigen zu lassen, stehen Ihnen mehrere Optionen zur Verfügung:

� Textansicht In dieser Ansicht werden alle Attribute aller Objektinstanzen in einer hierarchischen Eigenschaft/Wert-Struktur angezeigt.

� Parametereinzelansicht In dieser Ansicht können Sie für jede Objektinstanz den Wert eines bestimmten Attributs anzeigen lassen.

� Konfigurationsansicht In dieser Ansicht wird das jeder Objektinstanz zugrunde liegende Element als Konfigurationsfragment angezeigt.

Hinweis Wenn Sie eine Liste der allgemeinen Parameter benötigen, lesen Sie später in diesem Kapitel den Abschnitt »Allgemeine Parameter«.

Die Textansicht bietet die Möglichkeit, die Attribute aller Objektinstanzen schnell anzeigen zu lassen. Um die Textansicht zu verwenden, benutzen Sie den allgemeinen Parameter /text:*. Nachfolgend ist beispielsweise ein Teil der Ausgabe des Befehls List Sites aufgeführt, der mit dem Parameter /text:* aufgerufen wurde:SITE SITE.NAME:"Default Web Site" SITE.ID:"1" bindings:"http/*:80:,https/*:443: state:"Started" [site] name:"Default Web Site" id:"1" serverAutoStart:"true" [bindings] [binding] protocol:"http" bindingInformation:"*:80:" [binding] protocol:"https" bindingInformation:"*:443:" [limits] maxBandwidth:"4294967295" maxConnections:"4294967295" connectionTimeout:"00:02:00"

Wie Sie sehen können, enthält diese Ausgabe mehr Informationen zu jeder Websiteinstanz als die Standardausgabe.



Wenn Sie nur an bestimmten Attributen jeder Objektinstanz interessiert sind, können Sie wahlweise die Parametereinzelansicht einsetzen. Dazu benutzen Sie den allgemeinen Parameter /text:ParameterName, wobei ParameterName das Attribut ist, dessen Wert Sie anzeigen lassen möchten. Nachfolgend ist die Ausgabe des Befehls List Sites aufgeführt, für den der Parameter /text:ParameterName verwendet wurde, damit nur die Sitenamen angezeigt werden:Default Web Site TestSite

Schließlich können Sie die Konfigurationsansicht benutzen, um das mit jeder Objektinstanz verknüpfte Konfigurationselement als Konfigurationsfragment anzeigen zu lassen. Dazu verwenden Sie den allgemeinen Parameter /config, der die explizit gesetzte Konfiguration anzeigt, oder den Parameter /config:*, der die gesamte Konfiguration anzeigt. Das Config-Objekt verwendet standardmäßig dieses Format. Nachfolgend ist die Ausgabe des Befehls List Sites aufgeführt, für den der Parameter /config verwendet wurde:<site name="Default Web Site" id="1"> <bindings> <binding protocol="http" bindingInformation="*:80:" /> <binding protocol="https" bindingInformation="*:443:" /> </bindings> <limits /> <logFile /> <traceFailedRequestsLogging enabled="true" /> <applicationDefaults /> <virtualDirectoryDefaults /> <application path="/"> <virtualDirectoryDefaults /> <virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot" /> </application> </site>

Sie können ebenfalls den Parameter /xml benutzen, um die Ergebnisse von Appcmd-Befehlen in Form von XML auszugeben. Dieser Parameter kann verwendet werden, um die Ergebnisse eines Appcmd-Befehls an einen anderen Befehl weiterzuleiten, so dass mehrere aufeinander bezogene Befehle im Rahmen einer Befehlsverknüpfung miteinander verkettet werden können.

Hinweis Weitere Informationen zur Befehlsverknüpfung finden Sie unter http://mvolo.com/blogs/serverside/archive/2007/06/19/Do-complex-IIS-management-tasks-easily-with-appcmd-command-piping.aspx.

Der XML-Ausgabemodus kann genutzt werden, um die Ergebnisse von Appcmd-Befehlen in andere Softwareprogramme zu exportieren und Massenoperationen durchzuführen.

Hinweis Weitere Informationen zu Massenoperationen finden Sie unter http://mvolo.com/blogs/serverside/archive/2007/10/06/Create-IIS7-websites-and-application-pools-fast-with-appcmd.aspx.



Allgemeine ParameterZusätzlich zu spezifischen Verbparametern unterstützt Appcmd auch allgemeine Parameter, die sich auf die Ausführung aller Appcmd-Befehle auswirken. Diese Parameter sind in Tabelle 7.3 aufgeführt.

Wenn Sie einem Befehl einen Parameter übergeben, der denselben Namen wie ein allgemeiner Para-meter hat, können Sie dem Parameter zur besonderen Kennzeichnung ein Ausrufezeichen (!) voran-stellen. Müssten Sie beispielsweise das commit-Konfigurationsattribut für den fiktiven Konfigurations-abschnitt mysection setzen, könnten Sie die folgende Syntax benutzen:appcmd set config /section:mysection /!commit:somevalue

Tabelle 7.3 Allgemeine Appcmd-Parameter

Parameter Beschreibung

/? Zeigt eine kontextbezogene Hilfe an. Weitere Informationen hierzu finden Sie früher in diesem Kapitel im Abschnitt »Die Hilfe nutzen«.

/text Erzeugt eine Ausgabe im Textformat. Dies ist die Standardeinstellung. Sie können ebenfalls /text:* angeben, um eine detaillierte Textansicht anzeigen zu lassen, die für jedes Objekt alle Attribute aufführt. Alternativ hierzu können Sie den Parameter /text: angeben, um für jedes Objekt nur den Wert des angegebenen Attributs anzeigen zu lassen. Weiterführende Informationen finden Sie später in diesem Kapitel im Abschnitt »Die Ausgabe von App-cmd verstehen«.

/xml Generiert eine Ausgabe im XML-Format. Sie können dieses Format verwenden, um die Ausgabe des Tools zu speichern oder zu einem anderen Programm zu transportieren. Es bildet die Basis für die Befehlsverknüpfung.

- oder /in Führt den Befehl für den von der Standardeingabe bereitgestellten Datensatz aus. Benutzen Sie diesen Para-meter, um Appcmd-Befehle für Objektsätze ausführen zu lassen, die von der Ausgabe eines anderen Befehls zur Verfügung gestellt werden.

/config Zeigt die zu jedem aufgelisteten Objekt gehörende Konfiguration an. Sie können ebenfalls /config:* benutzen, um die gesamte Konfiguration einschließlich der von den Schemastandards geerbten Werte anzeigen zu lassen.

/metadata Zeigt Konfigurationsmetadaten an, wenn Konfigurationsobjekte aufgelistet werden und /text:* verwendet wird. Dazu zählen auch Informationen zu den Typen der Konfigurationsattribute.

/commit Kontrolliert das Speichern einer Konfiguration. Die Konfiguration wird standardmäßig in dem Konfigurationspfad gespeichert, auf den sie angewendet wird. Dabei wird die delegierte Konfiguration bevorzugt, sofern die Konfi-guration auf der Website-, Anwendungs- oder URL-Ebene festgelegt wird. Sie können dies jedoch mit diesem Parameter unabhängig von dem Konfigurationspfad kontrollieren, auf den die Konfiguration angewendet wird. Sie können einen festen Konfigurationspfad angeben oder apphost, machine bzw. webroot für die entsprechende Konfigurationsdateiebene des Servers verwenden. Alternativ hierzu können Sie die Werte Site, App und Parent benutzen, um das jeweilige Segment des aktuellen Konfigurationspfades zu speichern. Weitere Informationen finden Sie später in diesem Kapitel im Einschub »Wo die Konfiguration gespeichert wird«.

/debug Zeigt Debuginformationen zur Ausführung aller Befehle an. Dazu zählen auch die für die Ausführung benötigte Zeit, die übergebenen Parameter, die Anzahl der zurückgegebenen Objekte und alle Fehler. Sie können diese Informationen nutzen, um Appcmd-Befehle zu debuggen oder zu optimieren.



Bereichsoperatoren verwendenWenn Sie das List-Verb für ein Appcmd-Objekt benutzen, können Sie Parameter einbinden, um die zurückgegebenen Ergebnisse anhand von Attributwerten zu filtern, die Sie zu diesem Zweck angeben. Wenn Sie beispielsweise nach allen Sites suchen, deren serverAutoStart-Attribut auf false gesetzt ist, können Sie die folgende Syntax verwenden:appcmd list sites /serverAutoStart:false

Hinweis Weitere Informationen zur Verwendung des List-Befehls zum Auflisten von Objekten finden Sie später in diesem Kapitel im Abschnitt »Objekte mit dem List-Befehl auflisten und auffinden«.

Das Filtern mithilfe genau angegebener Objektattributwerte ist jedoch bisweilen mit zu vielen Ein-schränkungen verbunden. Sie müssen oft nach Objekten suchen, deren Attributwerte innerhalb eines bestimmten Bereichs liegen. Appcmd ermöglicht dies durch den Einsatz von Bereichsoperatoren, mit denen Objekte gefiltert werden können, deren Attributwerte einem bestimmten Ausdruck und nicht einem festen Wert entsprechen.

Wollten wir beispielsweise alle Websites mit einer ID über 300 aufspüren, könnten wir den Operator >= wie folgt benutzen:appcmd list sites "/id:$>=300"

Hinweis Da in einer Befehlszeile die Zeichen > und < einen speziellen Zweck erfüllen, sollten Sie darauf achten, einen Parameter, der Bereichsoperatoren enthält, vollständig in Anführungszeichen einzuschließen.

Sie können für jedes unterstützte Attribut Bereichsoperatoren angeben, indem Sie die $OPVAL-Syntax verwenden, wobei OP (Operator) dem Bereichsoperator und VAL (engl. für Value; Wert) dem Wert des Operators entspricht.

Tabelle 7.4 zeigt die unterstützten Operatoren.

Tabelle 7.4 Von Appcmd unterstützte Operatoren

Operator Beschreibung

> Größer-als-Operator für numerische Attribute. Entspricht allen Attributwerten, die größer als der angegebene Wert sind. /id:$>10 entspricht beispielsweise 11, aber nicht 9.

>= Größer-gleich-Operator für numerische Attribute. Entspricht allen Attributwerten, die größer als der oder gleich dem angegebenen Wert sind. /id:$>=10 entspricht beispielsweise 10, aber nicht 9.

< Kleiner-als-Operator für numerische Attribute. Entspricht allen Attributwerten, die kleiner als der angegebene Wert sind. /id:$<10 entspricht beispielsweise 9, aber nicht 10.

<= Kleiner-gleich-Operator für numerische Attribute. Entspricht allen Attributwerten, die kleiner als der oder gleich dem angegebenen Wert sind. /id:$<=10 entspricht beispielsweise 10, aber nicht Ziffer 11.

= Entspricht-Ausdruck mit Platzhalterzeichen für Zeichenfolgenattribute. Der Platzhalterzeichenausdruck kann die Zeichen * und ? enthalten. /name:$=*Site entspricht beispielsweise MySite und Default Web Site, aber nicht Site 1.

<> Logisches NICHT-Operator. Entspricht allen Objekten, die nicht über den genau angegebenen Attributwert verfügen. /name:$<>MySite entspricht beispielsweise jedem Namen außer MySite. Dieser Operator unterstützt kleine Platzhalterzeichen.



Sie können die Bereichsoperatoren verwenden, um nach Objekten zu suchen, deren Attribute den von Ihnen angegebenen Bereichsbedingungen entsprechen. Um beispielsweise alle Sites zu finden, die beendet sind und den Namen Site N besitzen, wobei N eine einstellige Ziffer ist, können Sie die folgende Syntax benutzen:appcmd list sites /state:stopped "/name:$=Site ?"

Häufige Fehler bei der Arbeit mit Appcmd vermeidenWenn Sie mit Appcmd arbeiten, sollten Sie einige Besonderheiten der Befehlszeile kennen, so dass Sie nicht plötzlich mit einem unerwarteten Verhalten konfrontiert werden. Benutzen Sie die folgenden Techniken, um sich aus Schwierigkeiten herauszuhalten:

� Umschließen Sie den Bezeichner und die Befehlsparameter mit Anführungszeichen ("), um sicherzustellen, dass alle Parameterinhalte innerhalb der Befehlszeile richtig gruppiert sind. Dies gilt besonders dann, wenn Leerzeichen oder spezielle Zeichen wie > oder < darin enthalten sind. Sie sollten dies ebenfalls tun, wenn Sie Skripts oder Batchdateien schreiben, die Appcmd-Befehle aufrufen. Zum Beispiel: appcmd list sites "/id:$>10". Dies ist eine Einschränkung, die die Befehls-zeilenshell und nicht Appcmd betrifft.

� Achten Sie darauf, die Standard-ASCII-Zeichen für die Parametertrennzeichen - und / sowie die doppelten (") und einfachen (') Anführungszeichen anstelle der erweiterten Zeichen (“) und (’) zu verwenden. Wenn Befehle per E-Mail versendet oder in Microsoft Office-Programme eingefügt werden, können aus den normalen Zeichen die erweiterten Versionen werden, die andere Zeichen-codes besitzen und deshalb von der Befehlszeilenshell oder von Appcmd möglicherweise nicht rich-tig verarbeitet werden. Verwenden Sie deshalb auch sicherheitshalber anstelle von - das Zeichen /, um Parameternamen einzuleiten. Benutzen Sie beispielsweise /parameter und nicht -parameter.

� Achten Sie auf Parameter, die mit den Zeichen \" enden, da die Kombination \" ein Escapezeichen für das doppelte Anführungszeichen (") ist und nicht das Ende des Parameters kennzeichnet. Um Verwechselungen zu vermeiden, benutzen Sie das Zeichen doppelt (\\). Zum Beispiel: "/physicalPath:c:\test\\".

Die Grundverben verwenden: List, Add, Set und DeleteDie meisten Appcmd-Objekte unterstützen einen grundlegenden Satz Verben: List, Add, Set und Delete. Diese Verben stellen für fast alle Objekte eine einheitliche Funktionalität zur Verfügung. Sobald Sie ein Gespür für die Arbeitsweise dieser Verben entwickelt haben, wird die Bedienung von Appcmd nicht mehr schwierig sein.

Objekte mit dem List-Befehl auflisten und auffindenDas List-Verb ist eines der nützlichsten Verben, und Appcmd bietet es für all seine Objekttypen an. Es listet alle verfügbaren Instanzen eines Objekttyps auf, so dass Sie nach einer bestimmten Objektinstanz suchen können. Sie können auch Attribute angeben, um Abfragen zum Auffinden von Objektinstanzen zu initiieren.

Sie können mithilfe der folgenden Appcmd-Syntax das List-Verb benutzen, um alle Objektinstanzen eines bestimmten Objekttyps aufzulisten:appcmd list Objekt


Die Grundverben verwenden: List, Add, Set und Delete 197

Dabei ist Objekt das Objekt, dessen Instanzen Sie auflisten lassen möchten. Um beispielsweise alle auf Ihrem Server konfigurierten Websites anzeigen zu lassen, benutzen Sie die folgende Anweisung:appcmd list sites

Sie können ebenfalls Parameter angeben, so dass Sie die Liste auf solche Websites beschränken, die die von Ihnen angegebenen Attribute besitzen. Die für diese Operation verfügbare Attributliste basiert auf der Konfigurationsdefinition der Website und enthält ebenfalls alle Attribute, die von Appcmd für jedes Site-Objekt generiert wurden (wie z.B. das Attribut State).

Möchten Sie beispielsweise alle Sites anzeigen lassen, die beendet wurden, geben Sie den folgenden Befehl ein:appcmd list sites /state:Stopped

Die Ausgabe dieses Befehls gibt nur die Sites zurück, deren Status (state) Stopped (beendet) ist. Sie können dem Befehl beliebig viele Parameter übergeben. Möchten Sie beispielsweise die Sites abfragen, die beim Start des Servers nicht automatisch gestartet, aber gegenwärtig ausgeführt werden, können Sie den folgenden Befehl benutzen:appcmd list sites /serverAutoStart:false /state:Started

Zusätzlich zur Angabe exakter Attributwerte für die Abfrage von Objekten können Sie mithilfe der Appcmd-Bereichsoperatoren Ausdrücke verwenden, um eine Abfrage auszuweiten. Sie können beispielsweise wie folgt alle Websites mit einer ID über 300 anzeigen lassen:appcmd list sites "/id:$>300"

Die unterstützten Bereichsoperatoren sind Ungleich (logisches NICHT), Größer-als, Größer-gleich, Kleiner-als, Kleiner-gleich und ein Entspricht-Ausdruck mit Platzhalterzeichen für Zeichenfolgen-werte. Weitere Informationen zur Verwendung von Bereichsoperatoren finden Sie früher in diesem Kapitel im Abschnitt »Bereichsoperatoren verwenden«.

Letztendlich können Sie auch immer nach einer speziellen Websiteinstanz suchen, indem Sie deren eindeutigen Bezeichner, also den Namen der Website angeben. Beim Auflisten von Objekten wird der Bezeichner für jede Objektinstanz angezeigt, damit er für eine spätere Referenzierung dieses Objekts verwendet werden kann. Um beispielsweise die Website mit dem Namen Default Web Site zu lokalisieren, benutzen Sie die folgende Syntax:appcmd list site "Default Web Site"

Darüber hinaus unterstützt das Site-Objekt einen URL als Bezeichner. In diesem Fall löst das Tool unter Verwendung der Bindungsinformationen aller Websites den URL automatisch auf, um die entspre-chende Website zu erhalten. Dies funktioniert auch beim Auflisten der Objekte App und Vdir. Um bei-spielsweise die Website anzuzeigen, die konfiguriert wurde, um den URL http://localhost/test.html zu bedienen, können Sie die folgende Syntax verwenden:appcmd list site "http://localhost/test.html"

Denken Sie daran, dass das List-Verb für alle Objekttypen verwendet werden kann. Zusätzlich zur Anzeige von Websites können Sie Anwendungspools, Anwendungen, virtuelle Verzeichnisse, Arbeitsprozesse und aktive HTTP-Anforderungen auflisten. Testen Sie das List-Verb mit allen unterstützten Objekttypen. Lesen Sie Tabelle 7.2 oder lassen Sie den Befehl Appcmd.exe /? ausführen, wenn Sie wissen möchten, welche Objekttypen unterstützt werden.



Objekte mit dem Add-Verb erstellenViele Appcmd-Objekte unterstützen die Erstellung neuer Objektinstanzen. Sie können beispielsweise neue Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools erstellen. Wie Sie vielleicht schon erraten haben, benutzen Sie das Add-Verb, um diese Aufgaben auszuführen. Das Add-Verb hat in der Regel die folgende Syntax:appcmd add Objekt [/Parameter:Wert]*

Dabei ist Objekt das Objekt, dessen Instanz Sie erstellen. Das Add-Verb eines Objekts verlangt die Angabe bestimmter Parameter, die während der Erstellung der Objektinstanz verwendet werden. Darüber hinaus können Sie für das Add-Verb oft zusätzliche Parameter angeben, die normalerweise vom Set-Verb angeboten werden, damit diese Attribute direkt nach der Objekterstellung gesetzt werden. Sie können die Liste der Parameter, die für das Verb angegeben werden müssen, über die Add-Befehl-Hilfe zu diesem Verb abrufen. Um beispielsweise zu erfahren, wie eine Site hinzugefügt wird, können Sie den folgenden Befehl aufrufen:appcmd add site /?

Die Ausgabe dieser Hilfeanforderung über die Befehlszeile zeigt, dass Sie eine Site hinzufügen können, indem Sie die Parameter name, bindings und physicalPath angeben. Das nachfolgende Beispiel zeigt, wie eine Website mit dem Add Site-Befehl hinzugefügt wird:appcmd add site /name:MyWebSite /bindings:"http/*:81:" /physicalPath:"c:\inetpub\wwwroot"

Hinweis Weitere Informationen zur Verwendung von Appcmd für die Erstellung von Websites finden Sie im neun-ten Kapitel, »Verwalten von Websites«.

Die Ausgabe des Add-Befehls zeigt in der Regel die vom Befehl erstellten Objekte. Im vorherigen Beispiel hat der Add Site-Befehl eine neue Website, eine Stammanwendung und ein virtuelles Stammverzeichnis erzeugt.

Hinweis Im Gegensatz zu den Befehlen Set und Delete akzeptiert der Add-Befehl keinen Bezeichner. Der Grund hierfür besteht darin, dass der Add-Befehl keinen Bezeichner benötigt, um nach einem bereits vorhandenen Objekt zu suchen – er erzeugt ein neues Objekt und verlangt, dass die zugrunde liegenden Parameter, die natürlich auch den Bezeichner für spätere Suchen beinhalten können, zur Verfgügung gestellt werden, so dass das Objekt gene-riert werden kann. Wenn Sie beispielsweise den Add Site-Befehl benutzen, müssen Sie den /name-Parameter zur Verfügung stellen, anstatt den Namen als Bezeichner anzugeben.

Bereits vorhandene Objekte mit dem Set-Verb ändernZusätzlich zur Erstellung neuer Objekte mit dem Add-Verb können Sie ebenfalls die Konfigurations-attribute bereits vorhandener Objekte ändern. Dazu benutzen Sie das Set-Verb mit der folgenden Syntax:appcmd set Objekt Bezeichner [/Parameter:Wert …]

Dabei ist Objekt das Objekt, dessen Instanz Sie ändern möchten. Das Set-Verb verlangt vom Bezeichner, dass dieser die zu modifizierende Objektinstanz eindeutig identifiziert. Um die Richtigkeit zu gewährleisten, muss der exakte Bezeichner verwendet werden. Benutzen Sie für das Site-Objekt beispielsweise den Sitenamen anstelle eines URLs.


Die Grundverben verwenden: List, Add, Set und Delete 199

Hinweis Im Gegensatz zur Vorgehensweise beim Add-Verb identifizieren Sie die gewünschte Objektinstanz nicht durch die Angabe spezifischer Objektparameter, wie z.B. /name beim Site-Objekt. Stattdessen müssen Sie den Bezeichner benutzen, um die Objektinstanz eindeutig zu identifizieren.

Um herauszufinden, welche Attribute Sie ändern können, indem Sie diese als Parameter des Set-Verbs angeben, benutzen Sie die Hilfe zum Verb. Um beispielsweise festzustellen, welche Parameter Sie in Verbindung mit dem Befehl Set Site verwenden können, benutzen Sie die folgende Anweisung:appcmd set site /?

Wenn die angezeigte Parameterliste /? enthält, bedeutet dies, dass Sie Konfigurationsparameter setzen können, die auf der Hilfeseite nicht aufgeführt sind. Dies ist bei fast allen Appcmd-Objekten der Fall, weil diese über verknüpfte Konfigurationsinformationen verfügen, die Sie modifizieren können. Um zu ermitteln, welche Konfigurationsattribute Sie für das Set-Verb verwenden können, müssen Sie die Attribute eines bereits vorhandenen Objekts untersuchen. Dazu benutzen Sie das List-Verb in Ver-bindung mit der detaillierten Textansicht oder das Verb Set mit dem Parameter /?. Möchten Sie bei-spielsweise die Objekteigenschaften einsehen, die Sie für jedes Site-Objekt setzen können, hilft die folgende Syntax weiter.appcmd set site "Default Web Site" /?

Hinweis Sie müssen eine bereits vorhandene Objektinstanz angeben, wenn Sie das Set-Verb mit dem Parameter /? benutzen, um die unterstützten Parameter auflisten zu lassen. Andernfalls erhalten Sie die Standardhilfeseite des Verbs.

Die Ausgabe dieses Befehls ist eine Liste aller Parameter, die Sie für das Set-Verb (aber auch bei Abfragen für das List-Verb) des Objekts verwendet werden können. Nachfolgend ist beispielsweise die Ausgabe des vorherigen Befehls aufgeführt:-name -id -serverAutoStart -bindings.[protocol='string',bindingInformation='string'].protocol -bindings.[protocol='string',bindingInformation='string'].bindingInformation -limits.maxBandwidth -limits.maxConnections …

Hinweis Weitere Informationen zur Referenzierung und zum Setzen von Konfigurationsattributen sowie zur Modifizierung von Konfigurationsauflistungen finden Sie später in diesem Kapitel im Abschnitt »Arbeiten mit der Konfiguration«.

Objekte mit dem Delete-Verb entfernenKein Konfigurationshilfsmittel wäre vollständig, ohne Ihnen die Möglichkeit zu bieten, Daten zu entfernen. Appcmd stellt eine anschauliche Syntax zum Entfernen von Konfigurationen zur Verfügung. Dabei handelt es sich um das Verb Delete, mit dem Objekte gelöscht werden.appcmd delete Object identifier

Das Delete-Verb verlangt ähnlich wie das Set-Verb, dass mit dem Bezeichner die zu löschende Objekt-instanz eindeutig identifiziert wird. Um die Richtigkeit zu gewährleisten, muss der exakte Bezeichner verwendet werden. Benutzen Sie für das Site-Objekt beispielsweise den Sitenamen anstelle eines URLs.



Hinweis Im Gegensatz zur Vorgehensweise beim Add-Verb identifizieren Sie die gewünschte Objektinstanz nicht durch die Angabe spezifischer Objektparameter, wie z.B. /name beim Site-Objekt. Stattdessen müssen Sie den Bezeichner benutzen, um die Objektinstanz eindeutig zu identifizieren.

Sie können beispielsweise eine Website löschen, indem Sie wie folgt den Befehl Delete Site benutzen:appcmd delete site "MyNewWebSite"

Vorsicht Wenn Sie eine Website löschen, werden automatisch auch alle darin enthaltenen Definitionen von Anwendungen und virtuellen Verzeichnissen gelöscht. Die Inhalte bleiben jedoch erhalten.

Arbeiten mit der KonfigurationEine der wichtigsten Aufgaben, für die Appcmd verwendet wird, ist die Bearbeitung der IIS 7.0-Konfiguration. Appcmd-Befehle sind bestens geeignet, um Konfigurationsänderungen zu kapseln, so dass Sie sie anderen Benutzern zeigen, für eine spätere Verwendung speichern oder zur Automati-sierung von Verwaltungsaufgaben verwenden können. Für die meisten Konfigurationsaufgaben gilt, dass es sehr zeitaufwändig ist, sie mit dem IIS-Manager auszuführen. Deshalb greift die IIS 7.0-Onlinehilfe genauso wie dieses Buch auf Appcmd zurück, um zu demonstrieren, wie solche Aufgaben gelöst werden.

Obwohl Sie die Konfiguration für die Hauptobjekte des Webservers – wie zum Beispiel Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools – über die entsprechenden Appcmd-Objekte verwalten können, werden die meisten Konfigurationsabschnitte nicht über solche Objekte offen gelegt. Stattdessen benutzen Sie das Config-Objekt, um Konfigurationseinstellungen zu bearbeiten. Mit dem Config-Objekt können Sie jeden Konfigurationsabschnitt des IIS 7.0-Konfigurationsstacks bearbeiten (und zwar unabhängig davon, ob es sich um einen integrierten oder einen von einem Drittanbieter hinzugefügten Abschnitt handelt).

Das Config-Objekt unterstützt die in Tabelle 7.5 aufgelisteten Verben.

Tabelle 7.5 Unterstützte Verben des Config-Objekts

Verb Beschreibung

List Die Konfiguration des angegebenen Konfigurationsabschnitts für den angegebenen URL oder Konfigurationspfad anzeigen

Set Die Konfiguration des angegebenen Konfigurationsabschnitts für den angegebenen URL oder Konfigurationspfad festlegen

Search Ermitteln, wo die Konfiguration definiert ist

Lock Einen bestimmten Konfigurationsabschnitt sperren, damit dieser nicht an die untergeordneten Konfigurationsebenen delegiert werden kann

Unlock Einen bestimmten Konfigurationsabschnitt entsperren, damit dieser an die untergeordneten Konfigurationsebenen delegiert werden kann

Clear Einen Konfigurationsabschnitt, eine Konfigurationsauflistung oder ein Konfigurationsattribut löschen

Reset Wird vom Windows-Setup benutzt, um jeden integrierten Konfigurationsabschnitt auf die Setup-Standardwerte zurück-zusetzen; Sie sollten diesen Befehl nicht benutzen

Migrate Migriert die ASP.NET-Konfigurationsabschnitte in eine IIS-Konfiguration, damit der integrierte Pipelinemodus genutzt werden kann; lesen Sie das elfte Kapitel, »Hosting von Anwendungsentwicklungsframeworks«, um weitere Informationen zu erhalten


Arbeiten mit der Konfiguration 201

Sie können den Befehl List Config verwenden, um die Konfiguration für einen angegebenen URL oder Konfigurationspfad anzeigen zu lassen, wobei entweder die gesamte Konfiguration oder nur ein bestimmter Konfigurationsabschnitt angezeigt wird. Sie können den Befehl Set Config benutzen, um die Konfiguration eines Konfigurationsabschnitts für einen bestimmten URL oder Konfigurationspfad festzulegen. Schließlich können Sie mit dem Befehl Clear Config die Konfiguration eines bestimmten Abschnitts für einen angegebenen URL oder Konfigurationspfad löschen. Sie können außerdem den Delegierungsstatus von Konfigurationsabschnitten verwalten, indem Sie mit den Befehlen Lock Config und Unlock Config arbeiten. Weitere Informationen zur Verwaltung der Delegierung von Konfigurations-abschnitten finden Sie im vierten Kapitel, »Verstehen des Konfigurationssystems«.

Die meisten Konfigurationsbefehle ermöglichen den Einsatz von Bezeichnern, die beim Config-Objekt den Konfigurationspfad repräsentieren, für den Sie den Befehl ausführen lassen. Wenn Sie den Bezeichner nicht angeben, wird standardmäßig MACHINE/WEBROOT/APPHOST verwendet. Dieser Pfad referen-ziert die Konfiguration der Webserverebene, die sich in der Datei applicationHost.config befindet. Sie können den Bezeichner sowohl als Konfigurationspfad im Format SiteName/UrlPfad (z.B. Default Web Site/myapp) oder in Form eines gewöhnlichen URLs (z.B. http://localhost/myapp) angeben. Wenn Sie sich für die erste Möglichkeit entscheiden, fügt Appcmd automatisch das Präfix MACHINE/WEBROOT/APPHPOST an, um den Konfigurationspfad zu bilden. Nutzen Sie die zweite Möglichkeit, löst Appcmd den URL unter Verwendung der Websitebindungen in einen Konfigurationspfad auf.

Um beispielsweise die Einstellungen des system.webServer/asp-Abschnitts von http://localhost/myapp anzeigen zu lassen, können Sie den folgenden Befehl verwenden:appcmd list config "Default Web Site/myapp"

Oder Sie benutzen den folgenden Befehl:appcmd list config "http://localhost/myapp"

Weitere Informationen zu Konfigurationspfaden finden Sie im vierten Kapitel.

Konfigurationen mit dem Befehl List Config betrachtenUm eine Konfiguration zu betrachten, können Sie den Befehl List Config benutzen. Dieser Befehl weist die folgende Syntax auf:appcmd list config Konfigurationspfad [/section:Abschnittsname]

Konfigurationspfad ist der Konfigurationspfad oder URL, der auf die Stelle der Konfiguration verweist, die Appcmd lesen soll. Wenn Sie auf diese Angabe verzichten, verwendet Appcmd den Konfigurationspfad MACHINE/WEBROOT/APPHOST, um die Konfiguration der Webserverebene zu lesen. Denken Sie daran, dass Appcmd die tatsächliche, auf den angegebenen Pfad bezogene Konfiguration liest, bei der es sich um ein Produkt aus mehreren zusammengefügten Konfigurationspfaden der Hierarchie handelt, die dem angegebenen Konfigurationspfad entsprechen. Deshalb ist dies etwas anderes, als das bloße Öffnen der am Ende des angegebenen Pfades vorhandenen Konfigurationsdatei mit dem Windows-Editor.

Wenn der Parameter /section nicht angegeben wird, listet Appcmd die Konfigurationen aller Konfigura-tionsabschnitte auf. Dies ist eine große Menge, weshalb Sie in der Regel den Namen des aufzulistenden Abschnitts angeben möchten. Wenn Sie nicht wissen, wie der Abschnittsname lautet, können Sie alle registrierten Abschnitte mit dem folgenden Trick anzeigen lassen:appcmd list config /section:?

Damit werden alle Abschnitte aufgelistet. Sie können hinter dem Fragezeichen (?) Platzhalterzeichen benutzen, um nach Abschnitten mit einem bestimmten Namen zu suchen. ?*security* zeigt beispiels-weise alle Abschnitte an, deren Namen die Zeichenfolge security enthalten.



Die Ausgabe des Befehls List Config nutzt standardmäßig die Konfigurationsansicht. Um weitere Informationen zur Auswahl der Ausgabeansicht zu erhalten, lesen Sie bitte früher in diesem Kapitel den Abschnitt »Die Ausgabe von Appcmd verstehen«.

Konfigurationen mit dem Befehl Set Config festlegenDer Befehl Set Config ist sehr vielseitig und ermöglicht es Ihnen, Konfigurationseigenschaften festzu-legen oder zu bearbeiten. Dieser Befehl verwendet die folgende Syntax.appcmd list config Konfigurationspfad [/section:Abschnittsname] [/Attribut:Wert] [/+Attribut] [/-Attribut]

Konfigurationspfad ist wie bei dem Befehl List Config der Konfigurationspfad oder URL, auf den Appcmd die Konfigurationsänderungen anwendet. Wenn Sie auf diese Angabe verzichten, verwendet Appcmd den Konfigurationspfad MACHINE/WEBROOT/APPHOST, um die Konfiguration auf die Webserverebene anzu-wenden. Appcmd schreibt die Konfiguration standardmäßig in die Datei, die im Konfigurationspfad entspricht. Dies ermöglicht die Erstellung einer delegierten Konfiguration.

Sie können die Konfigurationseinstellung jedoch auch auf einer höheren Ebene der Konfigurations-hierarchie speichern, indem Sie sie mit einem location-Tag auf den angegebenen Konfigurationspfad anwenden. Dies ist beispielsweise dann erforderlich, wenn der zu bearbeitende Konfigurationsabschnitt gesperrt ist, und es somit nicht möglich ist, die Konfigurationseinstellungen auf den gewünschten Konfigurationspfad anzuwenden. Das eigentliche Speichern geschieht mit dem Parameter /commit. Weitere Informationen finden Sie früher in diesem Kapitel im Abschnitt »Allgemeine Parameter« und im vierten Kapitel.

Direkt von der Quelle: Wo die Konfiguration gespeichert wirdEs ist wichtig, dass Sie verstehen, dass es einen Unterschied gibt, und zwar zwischen dem Konfi-gurationspfad, auf den die Konfiguration angewendet wird, und dem Konfigurationspfad, wo sie gespeichert wird. Beide sind standardmäßig identisch, aber Sie können sie trennen, indem Sie die Konfigurationsänderungen auf einer höheren Konfigurationsebene speichern und mithilfe eines location-Tags auf den Pfad anwenden, den Sie für den Befehl angegeben haben. Dazu können Sie den von Appcmd angebotenen /commit-Parameter benutzen. Das eigentliche Speichern geschieht mit dem Parameter /commit.

Wenn Sie diesen Parameter benutzen, können Sie explizit einen Konfigurationspfad festlegen, wo die Einstellungen gespeichert werden sollen. Sie können für bestimmte Konfigurationsdateien der Serverebene machine, webroot oder apphost angeben, sofern alle Konfigurationen in Dateien gespeichert werden sollen, die der Administrator kontrolliert. Dies ist eine nützliche Option, wenn die Konfigu-rationsabschnitte gesperrt sind und in den verteilten web.config-Dateien nicht angegeben werden dürfen.

Alternativ hierzu können Sie site oder app benutzen, um die Änderungen im der web.config-Datei zu speichern, die der Stammwebsite oder Stammanwendung des angegebenen Konfigurationspfades entspricht. Schließlich können Sie den parent-Wert verwenden, um das übergeordnete Pfadsegment des angegebenen URLs auszuwählen.



Der Parameter /section muss beim Set Config-Befehl immer angegeben werden und er muss einen gültigen Konfigurationsabschnitt bezeichnen, dessen Konfiguration Sie festlegen möchten.

Hinweis Sie können den Befehl List Config benutzen, um den Konfigurationsabschnitt zu finden, an dem Sie interessiert sind.

Benutzen Sie zusätzliche Parameter, um Änderungen an der Konfiguration vorzunehmen. Zu diesen Änderungen zählen z.B. das Setzen von Attributwerten und das Hinzufügen, Entfernen und Bearbeiten von Auflistungselementen. Diese Themen sind ausführlich im nächsten Abschnitt, »Konfigurations-attribute setzen« und später in diesem Kapitel im Abschnitt »Konfigurationsauflistungen verwalten« beschrieben.

Konfigurationsattribute setzenUm mit dem Set Config-Befehl Konfigurationsattribute für einen bestimmten Abschnitt festzulegen, geben Sie jedes zu setzende Attribut als Parameter und den Attributwert als Parameterwert an. Um beispielsweise das allowDoubleEscaping-Attribut des Abschnitts system.webServer/security/requestFiltering zu setzen, können Sie die folgende Syntax verwenden:appcmd set config /section:system.webServer/security/requestFiltering /allowDoubleEscaping:true

Einige Konfigurationsabschnitte enthalten Unterelemente. Um die Attribute solcher Abschnitte zu referenzieren, können Sie die Punktnotation (.) benutzen, mit der Sie den vollständigen Elementpfad zum Attribut angeben. Der Elementpfad ist, ausgehend vom jeweiligen Abschnitt, ein relativer Pfad, so dass er nicht für die Attribute des Abschnittselements verwendet wird, die sich auf oberster Ebene befinden. Um beispielsweise allowUnlisted im fileExtensions-Element des bereits von uns bearbeiteten Abschnitts zu setzen, können Sie die folgende Syntax benutzen:appcmd set config /section:system.webServer/security/requestFiltering /fileExtensions.allowUnlisted:false

Hinweis Sie können mehrere Parameter angeben, um in nur einem Befehl mehrere Konfigurationsattribute eines Abschnitts festzulegen. Sie können jeden Parameter aber nur einmal angeben. Aufgrund eines Fehlers wird immer nur der letzte Wert berücksichtigt, wenn Sie dasselbe Attribut mehrmals angeben.

Sie sollten die Werte site, app oder parent einsetzen, wenn Sie eine Konfiguration auf einen bestimmten URL anwenden möchten, der keinem Verzeichnis entspricht, da Appcmd andernfalls die erforderliche web.config-Datei nicht generieren kann. Darüber hinaus können Sie diese Werte verwenden, um eine Konfiguration für mehrere URLs in nur einer verteilten web.config-Datei zu platzieren, die sich im Website- oder Anwendungsstamm befindet. Auf diese Weise können Sie auch weiterhin die Vorzüge der verteilten Konfiguration nutzen, während gleichzeitig eine zu große Zahl verteilter web.config-Dateien vermieden wird.

Die richtige Wahl ist von Ihrer Strategie für die Konfigurationsdelegierung und davon abhängig, welche Anforderungen Sie definieren, wenn Sie eine portierbare Konfiguration aufbauen möchten.

Mike Volodarsky




Sie können ebenfalls die /-Attribut-Syntax benutzen, um die in einer Konfiguration für ein Attribut gesetzten Werte zu entfernen und die Konfiguration somit auf den Wert zurückzusetzen, der von der übergeordneten Konfigurationsebene geerbt oder von der Schemadefinition für diesen Konfigurations-abschnitt als Standard definiert wird. Um beispielsweise den zuvor von uns explizit gesetzten Wert des Attributs allowDoubleEscaping zu löschen, können Sie die folgende Syntax verwenden:appcmd set config /section:system.webServer/security/requestFiltering /-allowDoubleEscaping

Konfigurationsauflistungen verwaltenSie können für Konfigurationsabschnitte, die Auflistungen enthalten, den Befehl Set Config benutzen, um neue Auflistungselemente hinzuzufügen, bereits vorhandene Elemente zu entfernen oder die in einem vorhandenen Element enthaltene Konfiguration zu bearbeiten.

Um ein Auflistungselement hinzuzufügen, können Sie die Syntax /+Elementpfad.[Attribut='Wert',…] verwenden, wobei Elementpfad der Pfad zum Auflistungselement ist, der die Punktnotation (.) verwendet. Jedes Attribut/Wert-Paar repräsentiert das entsprechende Attribut des Auflistungselements. Sie müssen die Werte aller vorgeschriebenen Attribute angeben, um ein neues Auflistungselement zu erstellen, und

Direkt von der Quelle: Berücksichtigung der Groß- und Kleinschreibung in AppcmdBei Parameternamen unterscheidet Appcmd nicht zwischen Groß- und Kleinschreibung. Das bedeutet, dass Sie sich keine Gedanken darum machen müssen, ob die von Ihnen gesetzten Konfigurations-attribute groß oder klein geschrieben werden. Das zugrunde liegende Konfigurationssystem berück-sichtigt jedoch bei Attributnamen die Groß- und Kleinschreibung. Tritt somit der recht unwahrschein-liche Fall ein, dass ein Konfigurationselement zwei Attribute besitzt, die sich ausschließlich hinsicht-lich der Groß- und Kleinschreibung voneinander unterscheiden, können Sie das zweite Attribut nicht referenzieren, weil Appcmd immer mit dem ersten Attribut arbeiten wird. Diese Entscheidung war das Ergebnis einer hitzigen Diskussion, bei der es um Korrektheit kontra Verwendbarkeit ging, wobei die Wahl auf eine optimale allgemeine Benutzererfahrung fiel. Der Möglichkeit, Attributnamen zu ver-wenden, die zwischen Groß- und Kleinschreibung unterscheiden, sollte in der Regel kein Vorrang eingeräumt werden, da dies für die Benutzer sehr verwirrend sein kann und äußerst fehleranfällig ist. Denken Sie deshalb sorgfältig nach, bevor Sie Konfigurationsabschnitte erstellen, die über mehrere Attribute verfügen, deren Namen sich lediglich hinsichtlich der Groß- und Kleinschreibung voneinander unterscheiden.

Auch die Namen der mit dem Parameter /section angegebenen Konfigurationsabschnitte unterscheiden nicht zwischen Groß- und Kleinschreibung, obwohl es möglich ist, mit mehreren Abschnitten zu arbeiten, die sich ausschließlich hinsichtlich der Groß- und Kleinschreibung voneinander unter-scheiden.

Letztendlich erleichtert die fehlende Berücksichtigung der Groß- und Kleinschreibung bei Attribut- und Abschnittsnamen den Einsatz des Tools für Konfigurationsaufgaben. Denken Sie jedoch daran, dass Konfigurationsattributswerte selbst oft zwischen Groß- und Kleinschreibung unterscheiden, je nachdem, wie die Webserverfeatures die Werte interpretieren.

Mike Volodarsky




Sie können optional andere vom Auflistungselement unterstützte Attribute festlegen. Um beispiels-weise der Auflistung im fileExtensions-Element des Abschnitts system.webServer/security/requestFiltering einen neuen Eintrag hinzuzufügen, können Sie den folgenden Befehl benutzen:appcmd set config /section:system.webServer/security/requestFiltering /+fileExtensions.[fileExtension='.test',allowed='true']

Hinweis Wenn Sie nicht alle vorgeschriebenen Attribute des neuen Auflistungselements angeben, führt der Set Config-Befehl zu einem Fehler mit der Meldung Das Element enthält nicht die erforderlichen Attribute.

Der vorherige Befehl erzeugt in der fileExtensions-Auflistung ein untergeordnetes Element, dessen allowed-Attribut auf den angegebenen Wert gesetzt wird. Beachten Sie, dass Sie bei einem Abschnitt, der selbst eine Auflistung ist, lediglich den Ausdruck in den eckigen Klammern und nicht einen Element-pfad angeben müssen.

Sie können festlegen, wo in der Auflistung das neue Element hinzugefügt werden soll. Das Element wird bei Auflistungen, die im Konfigurationsschema für den Anhängen-Zusammenführungsmodus konfiguriert sind, standardmäßig am Ende der Auflistung hinzugefügt, während es bei Auflistungen, die für den Voranstellen-Zusammenführungsmodus konfiguriert sind, am Anfang angeordnet wird. Sie können diese Standardposition außer Kraft setzen, indem Sie den Positionsqualifizierer verwenden, der @start, @end und @Position sein kann, wobei Position die mit dem Index 0 beginnende Position innerhalb der Auflistung ist. Der Positionsqualifizierer sollte in der von den eckigen Klammern eingeschlossenen Liste der erste Eintrag sein. Um beispielsweise das Element, das Sie mit dem vorherigen Befehl hinzu-gefügt haben, am Anfang der Auflistung anzuordnen, können Sie die folgende Syntax verwenden:appcmd set config /section:system.webServer/security/requestFiltering /+fileExtensions.[@start,fileExtension='.test',allowed='true']

Hinweis Wenn die Auflistung bereits über ein Element verfügt, das für die Schlüsselattribute dieselben Werte wie das hinzuzufügende Element verwendet, meldet der Set Config-Befehl den Fehler Doppelter Auflistungseintrag kann nicht hinzugefügt werden.

Um ein Auflistungselement zu entfernen, benutzen Sie die Syntax /-elementpath.[attribute='value',…]. Sie müssen Attribut/Wert-Paare für alle Attribute angeben, die zusammen den Auflistungsschlüssel bilden, der das zu entfernende Auflistungselement eindeutig identifiziert. Um beispielsweise das im vorherigen Beispiel hinzugefügte Auflistungselement wieder zu entfernen, benutzen Sie die folgende Syntax:appcmd set config /section:system.webServer/security/requestFiltering /-fileExtensions.[fileExtension='.test']

Da das Attribut fileExtension der einzige eindeutige Schlüssel der Auflistung ist, genügt seine Angabe, um das gewünschte Element zu entfernen.

Anstatt Schlüsselattribute festzulegen, können Sie Auflistungselemente auch entfernen, indem Sie die bereits besprochenen Positionsqualifizierer verwenden. Um beispielsweise das erste Element in der Auflistung zu entfernen, benutzen Sie die folgende Syntax:appcmd set config /section:system.webServer/security/requestFiltering /-fileExtensions.[@start]



Um schließlich die Attribute eines bestimmten Auflistungselements zu setzen, können Sie entweder die Standardnotation für Elementpfade zum Setzen von Konfigurationsattributen verwenden, oder Sie greifen zum Auswählen des gewünschten Auflistungselements auf den Auflistungsindexerausdruck in eckigen Klammern zurück. Um zum Beispiel das allowed-Attribut des zuvor von uns hinzugefügten Auflistungseintrags zu setzen, können Sie die folgende Syntax verwenden:appcmd set config /section:system.webServer/security/requestFiltering /fileExtensions.[fileExtension='.test'].allowed:true

Beachten Sie, dass Sie das Element ähnlich wie beim Löschen von Auflistungselementen mithilfe des eindeutigen Schlüssels der Auflistung identifizieren müssen. Beachten Sie auch, dass sich das von Ihnen gesetzte Attribut außerhalb des von den eckigen Klammern umschlossenen Ausdrucks befindet – die Attribute innerhalb des von den eckigen Klammern umschlossenen Ausdrucks dienen der ein-deutigen Identifizierung des Elements, das Sie modifizieren möchten. Aus diesem Grund müssen Sie die Notation für Elementpfade benutzen, um das Attribut eines Auflistungselements zu setzen. Wie zuvor können Sie anstelle der Schlüsselattribute auch den Positionsqualifizierer benutzen, um das Auflistungselement zu identifizieren.

Die Konfigurationsdelegierung verwaltenSie können das Config-Objekt ebenfalls benutzen, um die Konfigurationsdelegierung zu verwalten, um zu ermitteln, welche Konfigurationsabschnitte in den verteilten web.config-Konfigurationsdateien erlaubt sind und um eine spezifischere Konfigurationssperrung für bestimmte Elemente, Attribute und Auflistungen zu konfigurieren. Appcmd unterstützt dies wie folgt:

� Lock Config-Befehl Sperrt einen Konfigurationsabschnitt, um zu verhindern, dass er auf einer bestimmten Konfigurationsebene oder darunter delegiert wird

� Unlock Config-Befehl Entsperrt einen Konfigurationsabschnitt, um zuzulassen, dass er auf einer bestimmten Konfigurationsebene oder darunter delegiert wird

� Set Config-Befehl Legt spezielle Konfigurationsattribute fest, einschließlich lockAttributes, lockElements und lockItem, um eine spezifische Konfigurationssperrung zu konfigurieren

Um mehr über den Einsatz von Appcmd zum Sperren und Entsperren von Abschnitten zu erfahren, lesen Sie bitte das vierte Kapitel. Weitere Informationen zur spezifischen Konfigurationssperrung finden Sie im vierten Kapitel und dort im Abschnitt »Spezifische Konfigurationssperrung«.

Konfigurationssicherungen verwaltenAppcmd stellt ein Backup-Objekt zur Verfügung, mit dem Sie globale Konfigurationsdateien sichern und wiederherstellen können. Das Erstellen einer Sicherung ist mit dem Add-Verb des Backup-Objekts sehr einfach, wie das folgende Beispiel zeigt:appcmd add backup

Der Aufruf dieses Befehls generiert eine neue Sicherung, deren Name auf dem aktuellen Datum und der aktuellen Uhrzeit basiert. Das Format lautet wie folgt: JJJJMMTTZhhmmss (dabei steht JJJJ für die vier Ziffern des Jahres, MM für die zwei Ziffern des Monats, TT für die zwei Ziffern des Tages, Z für das Trennzeichen zwischen Datum und Uhrzeit, hh für die zwei Ziffern der Stunde, mm für die zwei Ziffern der Minute und ss für die zwei Ziffern der Sekunde). Möchten Sie einen eigenen Namen für die Sicherung angeben, können Sie dies am Ende der Appcmd-Anforderung tun:appcmd add backup "MyServerBackup"


Mit Anwendungen, virtuellen Verzeichnissen und Anwendungspools arbeiten 207

Wenn Sie das List-Verb in Verbindung mit dem Backup-Objekt benutzen, sehen Sie Ihre neu erstellte Sicherung:appcmd list backup

Um eine Konfigurationssicherungen wiederherzustellen, verwenden Sie das Restore-Verb zusammen mit dem Namen der wiederherzustellenden Sicherung. Um beispielsweise eine Sicherung namens MyServerBackup wiederherzustellen, geben Sie Folgendes ein:appcmd restore backup "MyServerBackup"

Hinweis Die Sicherungsdateien werden automatisch in Unterverzeichnissen des Ordners %SystemRoot%\ System32\Inetsrv\Backup gespeichert, die die Namen der jeweiligen Sicherungsinstanzen erhalten. Wenn Sie eine neue Sicherung erstellen, befinden sich unter den gesicherten Dateien auch administration.config und applica-tionHost.config.

Weitere Informationen zur Verwaltung von IIS 7.0-Konfigurationssicherungen finden Sie im vierten Kapitel und dort im Abschnitt »Sichern der Konfiguration«.

Mit Anwendungen, virtuellen Verzeichnissen und Anwendungspools arbeitenAppcmd ist ein effektives Hilfsmittel für die Erstellung und Konfiguration vieler Webserver-Schlüssel-objekte, zu denen Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools zählen. Die Appcmd-Objekte Site, App, Vdir und Apppool bieten ein einfaches Verfahren zur Verwaltung dieser Objekte, auch wenn Sie die meisten Aufgaben, die sich auf diese Objekte beziehen, unter Verwendung des Config-Objekts und somit durch direkte Bearbeitung der Konfigurationsdateien lösen können.

Das Site-Objekt ermöglicht das einfache Auflisten von Websites sowie die Erstellung neuer und die Konfiguration bereits vorhandener Websites. Sie können beispielsweise in nur einem Schritt eine Website erstellen, indem Sie den Befehl Add Site benutzen:ppcmd add site /name:MySite /bindings:http/*:81: /physicalPath:c:\mysite

Dieser Befehl generiert eine neue Website für Port 81. Darüber hinaus erzeugt er eine Stammanwen-dung und ein virtuelles Stammverzeichnis, das auf C:\mysite verweist. Sie können die Website auch separat erstellen, indem Sie auf die Angabe des Parameters physicalPath verzichten und die Anwen-dungen und virtuellen Verzeichnisse der Site mit den Befehlen Add App und Add Vdir erzeugen.

Sie können das Objekt List Sites benutzen, um die Websites des Servers aufzulisten oder anhand bestimmter Attribute oder eines URLs nach Websites zu suchen. Um beispielsweise zu ermitteln, welche Website so konfiguriert ist, dass sie die an http://localhost:83 gerichteten Anforderungen bedient, können Sie die folgende Syntax verwenden:appcmd list sites http://localhost:83

Um alle Sites zu finden, die gegenwärtig beendet sind, benutzen Sie die folgende Syntax:appcmd list sites /state:Stopped

Sie können Websites auch manuell starten und beenden. Dazu benutzen Sie die Befehle Start Site und Stop Site. Ausführliche Informationen bezüglich der Verwendung von Appcmd zum Auflisten, Erstellen und Konfigurieren von Websites und virtuellen Verzeichnissen finden Sie im neunten Kapitel.



Sie verfügen ebenfalls über die Möglichkeit, Anwendungen, virtuelle Verzeichnisse und Anwendungs-pools ähnlich wie Websites zu erstellen, aufzulisten und zu bearbeiten. Das zehnte Kapitel, »Verwalten von Anwendungen und Anwendungspools«, verrät Ihnen, wie Sie Anwendungen und Anwendungspools erstellen und konfigurieren.

Mit Webservermodulen arbeitenDas Appcmd-Objekt Module stellt einfach zu verwendende Methoden für die Installation, Aktivierung und Verwaltung von Webservermodulen zur Verfügung. Auch hier können Sie den größten Teil der mit diesem Objekt einhergehenden Aufgaben unter Verwendung des Config-Objekts lösen, das die Konfi-gurationsdateien direkt bearbeitet.

Sie können beispielsweise systemeigene Module mit dem Befehl Install Module installieren:appcmd install module /name:MyNativeModule /image:c:\mymodule.dll

Sie können denselben Befehl benutzen, um neue verwaltete Module hinzuzufügen:appcmd add module /name:MyManagedModules /type:MyModules.MyManagedModule

Sie verfügen außerdem über die Möglichkeit, festzulegen, welche Module auf Ihrem Webserver oder für Ihre Anwendung aktiviert sind, indem Sie Module hinzufügen oder entfernen.

Ausführliche Informationen zur Verwendung von Appcmd, um Webservermodule zu installieren, zu aktivieren und zu konfigurieren, finden Sie im zwölften Kapitel, »Verwalten von Webservermodulen«.

Ausgeführte Arbeitsprozesse und Anforderungen untersuchenDas Betrachten und Ändern von Konfigurationsdaten ist nicht das Einzige, was Sie mit Appcmd anstellen können. Sie können ebenfalls den Laufzeitstatus des Webservers untersuchen, indem Sie die gegenwärtige ausgeführten Arbeitsprozesse und sogar Anforderungen auflisten lassen.

Ausgeführte IIS-Arbeitsprozesse auflistenSie können den Befehl List Wp benutzen, um alle gegenwärtig ausgeführten IIS-Arbeitsprozesse aufzu-listen. Dieser Befehl verwendet die folgende Syntax:appcmd list wp [pid] [/apppool.name:string] [/wp.name:string]

Der Befehl List Wp unterstützt die Verwendung der Prozess-ID (PID) als Bezeichner zur Lokalisierung des angegebenen IIS-Arbeitsprozesses. Darüber hinaus können Sie mit dem Parameter /apppool.name einen Anwendungspoolnamen angeben, um die IIS-Arbeitsprozesse aufzulisten, die dem entsprechenden Anwendungspool zugeordnet sind.

Um beispielsweise alle gegenwärtig ausgeführten IIS-Arbeitsprozesse aufzulisten, können Sie die folgende Syntax benutzen:appcmd list wp

Die Ausgabe dieses Befehls enthält alle Prozess-IDs aller IIS-Arbeitsprozesse sowie die zugehörigen Anwendungspools:WP "3284" (applicationPool:DefaultAppPool)


Ausgeführte Arbeitsprozesse und Anforderungen untersuchen 209

Gegenwärtig ausgeführte Anforderungen auflistenSie können nicht nur die gegenwärtig ausgeführten Arbeitsprozesse anzeigen lassen, sondern auch einen genaueren Blick auf die Arbeit des Webservers werfen, indem Sie die gegenwärtig ausgeführten Anforderungen auflisten. Auf diese Weise erhalten Sie eine Momentaufnahme der gegenwärtigen Systemaktivität und Sie erfahren, welche Anforderungen bereits seit längerer Zeit ausgeführt werden (was auf ein Problem hindeuten kann).

Sie können die gegenwärtig ausgeführten Anforderungen mit dem Befehl List Request auflisten lassen. Um beispielsweise eine Liste aller Anforderungen zu erhalten, die gegenwärtig auf dem Server ausgeführt werden, benutzen Sie die folgende Syntax:appcmd list requests

Die Ausgabe führt alle Anforderungen aus, die zum Zeitpunkt der Abfrage in allen IIS-Arbeitspro-zessen ausgeführt wurden:REQUEST "fd00000180000004" (url:GET /wait.aspx?sleep=10000, time:4072 msec, client:localhost, stage:ExecuteRequestHandler, module:ManagedPipelineHandler)

Wie Sie sehen, enthält jedes angezeigte Anforderungsobjekt einige Informationen über die gegenwärtig ausgeführte Anforderung. Dazu zählen:

� Der Anforderungs-URL und das dazugehörige Verb� Die Zeitdauer der Anforderungsausführung� Der Client, der die Anforderung initiiert hat� Die Pipelinephase, in der sich die Anforderung gegenwärtig befindet, und das Modul, das

gegenwärtig ausgeführt wirdSie können die Informationen über die Ausführungsdauer, die aktuelle Pipelinephase und das aktuelle Modul verwenden, um Probleme mit nicht reagierenden Anforderungen und Leistungseinbußen zu behandeln, indem Sie den exakten URL und in einigen Fällen auch das die Leistungseinbuße verursachende Modul genau bestimmen.Das Auflisten aller Anforderungen auf dem Server ist oft zu arbeitsaufwändig und gibt zu viele Infor-mationen zurück, die in den meisten Fällen nicht benötigt werden. Deshalb können Sie verschiedene Filter einsetzen, um nur die relevanten Anforderungen aufzulisten. Wie dies funktioniert, erfahren Sie bei einem Blick auf die genaue Syntax des Befehls List Requests:appcmd list requests [identifier] [/site.name:string] [/wp.name:string] [/apppool.name:string] [/elapsed:uint] [/url:string] [/verb:string] [ClientIp:string] [/stage:string] [/module:string]

Dieser Befehl unterstützt die in Tabelle 7.6 aufgeführten Parameter.

Tabelle 7.6 Parameter für den Befehl List Requests


identifier Der Anforderungsbezeichner, mit dem eine bestimmte Anforderung mehrmals abgefragt werden kann. Der Anfor-derungsbezeichner ist eine nach dem Zufallsprinzip generierte Zeichenfolge wie z.B. fd00000180000004, die angezeigt wird, wenn Anforderungen von Appcmd aufgelistet werden.

site.name Der Name der Site, auf die sich die angezeigte gegenwärtig ausgeführte Anforderung bezieht

wp.name Die PID des IIS-Arbeitsprozesses, für den die gegenwärtig ausgeführten Anforderungen angezeigt werden sollen. Dies verbessert die Effizienz der Abfrage, da nur der angegebene IIS-Arbeitsprozess abgefragt wird.



Mit der Ablaufverfolgung für Anforderungsfehler arbeitenDas Appcmd-Objekt Trace bietet ein einfaches Verfahren zur Aktivierung und Verwendung des Features Ablaufverfolgung für Anforderungsfehler, mit dessen Hilfe unter IIS 7.0 Serverprobleme diagnostiziert werden können.

Hinweis Weitere Informationen zur Verwendung der Ablaufverfolgung für Anforderungsfehler finden Sie im sech-zehnten Kapitel, »Ablaufverfolgung und Problembehandlung«.

Mit dem Trace-Objekt können Sie Folgendes tun:

� Die Ablaufverfolgung für Anforderungsfehler für eine Website aktivieren und deaktivieren

� Auf Anforderungsfehler bezogene Ablaufverfolgungsregeln für URLs verwalten

� Nach Protokolldateien für die Ablaufverfolgung für Anforderungsfehler suchen und diese untersuchen

Die Ablaufverfolgung für Anforderungsfehler aktivierenUm die auf Anforderungsfehler bezogene Ablaufverfolgung für einen bestimmten URL einzuschalten, müssen Sie das Feature zunächst für die jeweilige Website aktivieren. Dies ist mit Appcmd und dem Befehl Configure Trace möglich:appcmd configure trace SiteName /enablesite

Der Parameter /enablesite aktiviert die Verwendung der auf Anforderungsfehler bezogenen Ablaufverfolgung, und zwar für die Site, die mit dem Bezeichner SiteName angegeben wird (dieser

apppool.name Der Anwendungspoolname, für den die gegenwärtig ausgeführten Anforderungen angezeigt werden sollen. Dies verbessert die Effizienz der Abfrage, da nur die IIS-Arbeitsprozesse des angegebenen Anwendungspools abge-fragt werden.

elapsed Die Mindestausführungsdauer einer Anforderung in Millisekunden, die erreicht sein muss, damit die Anforderung angezeigt wird. Anforderungen, deren Ausführungsdauer unter diesem Wert liegt, werden nicht zurückgegeben. Dies kann die Effizienz der Abfrage verbessern, wenn weniger Anforderungen zurückgegeben werden. Mit dem Attribut elapsed ist es möglich, nicht reagierende Anforderungen effektiv zu ermitteln.

url Der URL der Anforderung. Sie können den genauen URL angeben oder mit Platzhalterausdrücken arbeiten, um die Anforderungen anzeigen zu lassen, die sich nur auf bestimmte URLs beziehen (beachten Sie, dass der URL auch Abfragezeichenfolgen enthalten kann).

clientip Die IP des anfordernden Clients. Diese kann abhängig von der Clientverbindung sowohl im IPv4- als auch im IPv6-Format angegeben werden.

stage Die Anforderungsverarbeitungsphase. Benutzen Sie diesen Parameter, um nur solche Anforderungen anzeigen zu lassen, die gegenwärtig in der angegebenen Anforderungsverarbeitungsphase ausgeführt werden. Eine Liste der zulässigen Anforderungsverarbeitungsphasen finden Sie im zwölften Kapitel und dort im Abschnitt »Die Anforde-rungsverarbeitungspipeline«.

module Der Name des Moduls. Benutzen Sie diesen Parameter, um nur solche Anforderungen anzeigen zu lassen, die vom angegebenen Modul verarbeitet werden.

Tabelle 7.6 Parameter für den Befehl List Requests (Fortsetzung)



Mit der Ablaufverfolgung für Anforderungsfehler arbeiten 211

Bezeichner kann ebenfalls ein URL sein; in diesem Fall aktiviert Appcmd die Ablaufverfolgung für die entsprechende Site). Um beispielsweise die auf Anforderungsfehler bezogene Ablaufverfolgung für die Site Default Web Site zu aktivieren, benutzen Sie die folgende Syntax:appcmd configure trace "Default Web Site" /enablesite

Hinweis Achten Sie darauf, die Ablaufverfolgung für Anforderungsfehler mit dem Parameter /disablesite zu deak-tivieren, wenn Sie sie nicht benötigen.

Sie können ebenfalls den Parameter /disablesite benutzen, um die auf Anforderungsfehler bezogene Ablaufverfolgung für eine Website zu deaktivieren, sofern Sie diese Funktionalität nicht benötigen. Auf diese Weise behalten Sie die für die URLs der Site konfigurierten Ablaufverfolgungsregeln bei und schalten die Ablaufverfolgung einfach auf der Websiteebene ein oder aus.

Ablaufverfolgungsregeln für Anforderungsfehler aufstellenUm die Ablaufverfolgung für Anforderungsfehler zu protokollieren, müssen Sie Regeln aufstellen, die die Fehlerbedingungen definieren, unter denen eine Ablaufverfolgungsprotokollierung initiiert wird. Sie müssen außerdem die zu erfassenden Ablaufverfolgungsereignisse festlegen. Dazu benutzen Sie den /enable-Parameter des Configure Trace-Befehls. Dieser hat die folgende Syntax:appcmd Configure Trace <URL> /enable [/path:string] [/areas:string] [/verbosity:level] [/timetaken:timespan] [/statuscodes:string]


Tabelle 7.7 Parameter des Befehls Configure Trace


path Der URL-Pfad, für den die Regel aktiviert wird. Dies kann eine Erweiterung im Format .erweiterung oder – soll die Regel für alle Anforderungen aktiviert werden – das Sternchen (*) sein. Wenn Sie auf die Angabe verzichten, wird der Vorgabewert (*) verwendet.

areas Die Liste der nachzuverfolgenden Anbieter und der dazugehörigen Bereiche. Die Angabe erfolgt in der Form "Anbieter/Bereich1,Bereich2:Ausführlichkeitsgrad,...", wobei die Bereichsliste und der Ausführlichkeitsgrad nicht für jeden Anbietereintrag angegeben werden müssen. Wenn Sie auf die Angabe verzichten, werden alle registrierten Anbieter und deren Unterbereiche sowie der Ausführlichkeitsgrad Verbose (Ausführlich) verwendet.

verbosity Der Ausführlichkeitsgrad eines Ereignisses, der dazu führt, dass die Anforderung die Fehlerbedingung erfüllt und das Ablaufverfolgungsprotokoll generiert wird. Sie können diesen Parameter verwenden, um Ablaufverfolgungs-protokolle zu generieren, wenn z.B. ein Ereignis mit dem Ausführlichkeitsgrad Warning oder Error eintritt. Zulässige Werte sind Ignore, CriticalError, Error und Warning. Erfolgt keine Angabe, ist Warning die Vorgabe.

timetaken Die Ausführungszeit (im Zeitspannenformat), die verstrichen sein muss, damit die Anforderung die Fehlerbedin-gung erfüllt und das Ablaufverfolgungsprotokoll generiert wird. Sie können diesen Parameter benutzen, um Ablauf-verfolgungsprotokolle nur dann generieren zu lassen, wenn die Anforderung die angegebene Ausführungszeit überschreitet. Auf diese Weise erfassen Sie langsame oder nicht reagierende Anforderungen. Erfolgt keine Angabe, ist die Vorgabe eine Minute.

statuscodes Antwortstatuscodes, die gegeben sein müssen, damit die Anforderung die Fehlerbedingung erfüllt und das Ablauf-verfolgungsprotokoll generiert wird. Die Angabe erfolgt im Format "status.substatus,…", wobei substatus nicht angegeben werden muss. Sie können diesen Parameter benutzen, um das Ablaufverfolgungsprotokoll für Anfor-derungen generieren zu lassen, die zu Fehlern mit bestimmten Antwortfehlercodes führen. Erfolgt keine Angabe, ist die Vorgabe "500,400,401,403".



Wenn Sie den /enable-Befehl ohne Angabe des Parameters /path verwenden, wird ein Eintrag für alle Anforderungen erzeugt, die sich auf URLs mit dem Pfad "*" beziehen. Sie können beispielsweise die folgende Syntax benutzen, um die Ablaufverfolgung für Anforderungsfehler unter Verwendung der Standardkonfiguration zu aktivieren:appcmd configure trace "Default Web Site/" /enable

Daraufhin wird für den Konfigurationsabschnitt system.webServer/tracing/traceFailedRequests die folgende Konfiguration generiert: <tracing> <traceFailedRequests> <add path="*.aspx"> <traceAreas> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" /> </traceAreas> <failureDefinitions statusCodes="404" /> </add> <add path="*"> <traceAreas> <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module" verbosity="Verbose" /> <add provider="ASP" areas="" verbosity="Verbose" /> <add provider="ISAPI Extension" areas="" verbosity="Verbose" /> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" /> </traceAreas> <failureDefinitions timeTaken="00:01:00" statusCodes="500,400,401,403" verbosity="Warning" /> </add> </traceFailedRequests> </tracing>

Beachten Sie, dass die Regel den Pfad "*" verwendet, damit sie auf alle Anforderungen angewendet wird, die sich auf die URL-Ebene beziehen, auf der die Konfiguration festgelegt wird bzw. auf die Ebenen darunter. Außerdem verwendet die Regel alle registrierten Ablaufverfolgungsanbieter und -bereiche mit dem Ausführlichkeitsgrad Verbose und sie arbeitet mit den standardmäßigen Fehler-definitions-Triggern.

Sie können den Parameter /path angeben, um zusätzliche Regeln für bestimmte Erweiterungen aufzustellen, z.B. um die Ablaufverfolgung nur für ASPX-Seiten zu aktivieren:appcmd configure trace "Default Web Site/" /enable /path:*.aspx

Sie können anstelle von /enable den Parameter /disable benutzen, um Regeln zu entfernen. Dabei geben Sie den Parameter /path an, um festzulegen, welche Regel Sie entfernen möchten. Wenn Sie auf die Angabe des Parameters /path verzichten, versucht das Tool, Regeln unter Verwendung des Pfades "*" zu entfernen.

Sie können zusätzlich sowohl die Liste der von jeder Regel erfassten Ablaufverfolgungsanbieter und -bereiche sowie die Fehlerdefinitionen für die Regel außer Kraft setzen, indem Sie die in Tabelle 7.7 aufgeführten Parameter verwenden. Um beispielsweise eine Ablaufverfolgungsregel für Anfor-derungsfehler zu konfigurieren, die lediglich die Ereignisse vom ASP.NET-Anbieter abfängt und ausschließlich Protokolldateien für den Statuscode 404 generiert, verwenden Sie die folgende Syntax:appcmd configure trace "Default Web Site/" /enable /path:*.aspx /areas:ASPNET/Infrastructure,Module,Page,AppServices /statuscodes:404


Mit der Ablaufverfolgung für Anforderungsfehler arbeiten 213

Ablaufverfolgungsprotokolle für Anforderungsfehler durchsuchenAppcmd ermöglicht nicht nur die Aktivierung und Konfiguration der Ablaufverfolgung für Anforderungsfehler, sondern bietet auch eine einfache Möglichkeit, um die Ablaufverfolgungsprotokolldateien zu durchsuchen. Sie können mithilfe dieser Möglichkeit das Ablaufverfolgungsprotokoll schnell durchsuchen und sogar Ereignisse darin aufspüren, was für die Diagnose bestimmter Probleme sehr hilfreich ist.

Sie können die vorhandenen Ablaufverfolgungsprotokolldateien mit dem Befehl List Trace durchsuchen. Dieser Befehl weist die folgende Syntax auf:appcmd list traces [identifier] [/url:string] [/site.name:string] [apppool.name:string][/statuscode:string] …

Dieser Befehl akzeptiert die in Tabelle 7.8 aufgeführten Parameter.

Sie können zusätzlich andere Attribute des Ablaufverfolgungsobjekts angeben, mit deren Hilfe die Ergebnisse gefiltert werden sollen. Um die verfügbaren Attribute anzeigen zu lassen, listen Sie die Ablaufverfolgungsprotokolle mit dem Parameter /text:* auf. Um beispielsweise alle Ablaufverfol-gungsprotokolle für eine bestimmte Website anzeigen zu lassen, verwenden Sie die folgende Syntax:appcmd list traces /site.name:"Default Web Site"

Um alle Ablaufverfolgungsprotokolle für einen bestimmten URL aufzulisten, benutzen Sie die folgende Syntax:appcmd list traces /site.name:"Default Web Site" /url:http://localhost/myapp/test.html

Die Ausgabe des Befehls nennt, wie im folgenden Beispiel gezeigt, die Ablaufverfolgungsobjekte, den Ablaufverfolgungsprotokollbezeichner, den URL der Anforderung, den Statuscode und den Arbeits-prozess:TRACE "Default Web Site/fr000021.xml" (url:http://localhost:80/myapp/test.html,statuscode:200,wp:3284) TRACE "Default Web Site/fr000022.xml" (url:http://localhost:80/,statuscode:200,wp:3284)

Tabelle 7.8 Parameter des Befehls List Trace


identifier Der eindeutige Bezeichner eines Ablaufverfolgungsprotokolls, der im Format SiteName/logfilename.xml ange-geben wird. Sie können diesen Bezeichner benutzen, um in einem bestimmten Ablaufverfolgungsprotokoll zu suchen.

url Der URL der Anforderung. Appcmd unterstützt standardmäßig partielle URLs und führt für eine normalisierte Version des URLs einen Präfixabgleich durch.

site.name Der Name der Website, für die die Anforderungsprotokolle angezeigt werden sollen. Der Einsatz dieses Para-meters kann die Effizienz des Befehls verbessern, da nur die Protokolle für die angegebene Website abgerufen werden.

apppool.name Der Name des Anwendungspools, für den die Anforderungsprotokolle angezeigt werden sollen

statuscode Der Statuscode der Anforderung



Wird ein Ablaufverfolgungsprotokoll im Modus /text:* angezeigt, weist es viele zusätzliche Attribute auf (die Sie bei der Arbeit mit dem Befehl List Traces ebenfalls zum Filtern der resultierenden Ausgabe verwenden können).TRACELOG TRACE.NAME:"Default Web Site/fr000022.xml" PATH:"C:\inetpub\logs\FailedReqLogFiles\W3SVC1\fr000022.xml" URL:"http://localhost:80/myapp/test.html" STATUSCODE:"200" SITE.ID:"1" SITE.NAME:"Default Web Site" WP.NAME:"3284" APPPOOL.NAME:"DefaultAppPool" verb:"GET" remoteUserName:"Administrator" userName:"Administrator" tokenUserName:"contoso\Administrator" authenticationType:"Basic" activityId:"{00000000-0000-0000-0300-0080010000FD}" failureReason:"STATUS_CODE" triggerStatusCode:"200"

Beachten Sie, dass das Protokoll weitere Informationen zur Anforderung bereithält. Dazu zählen auch der Authentifizierungstyp und der Grund für die fehlgeschlagene Anforderung. Es enthält auch den physikalischen Pfad zur Protokolldatei, so dass Sie diese unter Verwendung des Stylesheets für die auf Anforderungsfehler bezogene Ablaufverfolgung in einem Browser öffnen können, um eine ausführ-liche Diagnose durchzuführen.

Schließlich können Sie eine Ablaufverfolgungsprotokolldatei auch nach bestimmten Ereignissen durchsuchen, um schnell die Ereignisse zu finden, die zu einem Anforderungsfehler geführt haben. Dazu können Sie den Befehl Inspect Trace benutzen. Dieser Befehl hat die folgende Syntax:appcmd inspect trace <identifier> [/event.name:string] [/name:string] [/level:int] [/providerid:string]


Tabelle 7.9 Parameter für den Befehl Trace Command


identifier Der Bezeichner des Ablaufverfolgungsprotokolls. Muss angegeben werden.

event.name Der eindeutige Bezeichner des Ereignisses innerhalb dieses Ablaufverfolgungsprotokolls. Die Angabe erfolgt in der Form ablaufverfBezeichner#index, wie bei Default Web Site/fr000001.xml#174. Sie können diese Bezeichner-ID benutzen, um innerhalb des Ablaufverfolgungsprotokolls nach einem bestimmten Ereignis zu suchen.

name Der Anzeigenamen des Ereignisses. Benutzen Sie diesen Parameter, um bestimmte Ereignisse zu filtern.

level Der numerische Ausführlichkeitsgrad eines Ereignisses. Benutzen Sie diesen Parameter, um Ereignisse mit einem bestimmten Ausführlichkeitsgrad zu filtern, wie z.B. Warning, Error oder CriticalError.

providerid Die GUID (Globally Unique Identifier, global eindeutiger Bezeichner) des Anbieters, der das jeweilige Ereignis generiert hat


Microsoft.Web.Administration 215

Sie können außerdem weitere Attribute des Ablaufverfolgungsobjekts angeben, die zum Filtern der Ergebnisse verwendet werden sollen. Um die verfügbaren Attribute anzeigen zu lassen, untersuchen Sie ein Ablaufverfolgungsprotokoll mit dem Parameter /text:*.

Sie können den Befehl Inspect Trace benutzen, um schnell das Ereignis aufzuspüren, das die gewünschte Fehlerbedingung aufweist. Um beispielsweise alle Ereignisse des Ablaufverfolgungsprotokolls auf-listen zu lassen, deren Ausführlichkeitsgrad Warning oder höher ist, benutzen Sie die folgende Syntax:appcmd list traces "Default Web Site/fr000001.xml" "/level:$>4"

Um nach einem bestimmten Ereignis zu suchen, verwenden Sie diese Syntax:appcmd list traces "Default Web Site/fr000001.xml" "/name:WARNING_ _SEND_CUSTOM_ERROR"

Sie können diese einfachen Techniken mithilfe der Befehlsverknüpfung kombinieren, um mehrere Ablaufverfolgungsprotokolldateien innerhalb kurzer Zeit zu analysieren. Lesen Sie das Blog unter http://mvolo.com/blogs/serverside/archive/2007/06/19/Do-complex-IIS-management-tasks-easily-with-AppCmd-command-piping.aspx, um weitere Informationen zu erhalten.

Microsoft.Web.AdministrationEine weitere Möglichkeit des Zugriffs auf Konfigurationsdaten bietet die verwaltete API (Application Programming Interface), die sich in der Assembly Microsoft.Web.Administration (MWA) befindet. Die MWA-Assembly ermöglicht es Ihnen, auf eine Konfiguration zuzugreifen und diese zu ändern. Darüber hinaus können Sie über die Verwaltungsobjekte der obersten Ebene auf einige Eigenschaften und Statusdaten von Serverobjekten zugreifen. Zu diesen Verwaltungsobjekten zählen Sites, Anwendungspools und Arbeitsprozesse.

Die folgenden Abschnitte beschreiben, wie MWA für allgemeine Verwaltungsaufgaben verwendet wird. Diese Abschnitte setzen voraus, dass Sie mit verwaltetem Code und der Programmiersprache C# ein wenig vertraut sind. Da sich dieses Buch nicht an Entwickler richtet, enthalten diese Abschnitte keine umfassende Erläuterung zur Verwendung von MWA in allen möglichen Szenarien.

Sites mit MWA erstellenDas folgende Beispiel nutzt MWA, um eine neue Site namens Fabrikam Site für Port 8080 zu erstellen, die C:\inetpub\wwwroot\fabrikam als Stammverzeichnis für die Inhalte verwendet:using System; using Microsoft.Web.Administration; namespace Example { class Program { static void Main(string[] args) { ServerManager mgr = new ServerManager(); Site site = mgr.Sites.Add("Fabrikam", @"C:\inetpub\wwwroot\fabrikam", 8080); site.ServerAutoStart = true; mgr.CommitChanges(); } } }



Beachten Sie, dass im Beispiel das Objekt ServerManager verwendet wird. Dies ist der Einstiegspunkt für alle Aktionen, die mit den MWA-APIs arbeiten. Das ServerManager-Objekt ermöglicht den Zugriff auf Eigenschaften, Methoden und Auflistungen, die wiederum den Zugriff auf andere Klassen der Assembly ermöglichen. Obwohl Serverdaten auch direkt über XML oder Status-APIs verwaltet werden können, ist mit MWA und den zugehörigen APIs ein einfacher Zugriff auf diese Daten möglich.

Lassen Sie uns jetzt einen Blick auf die Verwendung der Sites-Auflistung werfen, auf die über die Sites-Eigenschaft der ServerManager-Objektinstanz zugegriffen wird. Die Sites-Auflistung ermöglicht den Zugriff auf alle Sites, die gegenwärtig für das System konfiguriert sind. Sie können Sites hinzufügen und entfernen und bereits vorhandene Sites bearbeiten.

Sie können auch auf die Eigenschaften einzelner Sites zugreifen. Im folgenden Beispiel setzen Sie die Autostart-Option einer Site auf true. Sie können viele Siteeigenschaften direkt über die Klasse Site modifizieren. Sie können außerdem wie folgt über den entsprechenden Namen auf eine aus Sites bestehende Auflistung zugreifen:mgr.Sites["Fabrikam"].ServerAutoStart = true;

Die letzte besonders erwähnenswerte Zeile ist der Aufruf der Methode CommitChanges. Bis zum Aufruf dieser Zeile erfolgen alle Änderungen ausschließlich im Arbeitsspeicher und werden nicht in das Konfigurationssystem übernommen.mgr.CommitChanges();

CommitChanges muss immer dann aufgerufen werden, wenn Sie eine Konfiguration aktualisieren möchten. Wenn Ihr Programm CommitChanges nicht aufruft, gehen die innerhalb Ihrer Anwendung vorgenommenen Konfigurationsänderungen verloren.

Nachdem die Änderungen gespeichert wurden, sollten Sie Ihre Sitekonfiguration in der application-Host.config-Datei sehen können. Ihre Konfiguration sollte einen ähnlichen Abschnitt wie den folgen-den enthalten:<site name="Fabrikam" id="1000" serverAutoStart="true"> <application path="/"> <virtualDirectory path="/" physicalPath="c:\inetpub\wwwroot\fabrikam" /> </application> <bindings> <binding protocol="http" bindingInformation=":8080:" /> </bindings> </site>

Anwendungspools mit MWA erstellenSie können die MWA-APIs ebenfalls benutzen, um Anwendungspools zu erstellen und diese einer Site zuzuweisen. Das folgende Beispiel zeigt die dazu notwendige Vorgehensweise:using System; using Microsoft.Web.Administration; namespace Example { class Program { static void Main(string[] args) { ServerManager mgr = new ServerManager(); ApplicationPool pool = mgr.ApplicationPools.Add("FabrikamPool"); pool.ManagedPipelineMode = ManagedPipelineMode.Classic;


Microsoft.Web.Administration 217

Site = mgr.Sites["Fabrikam"]; site.Applications[0].ApplicationPoolName = @"FabrikamPool"; mgr.CommitChanges(); } } }

Die erste Zeile dieses Beispiels sollte Ihnen vertraut sein. Sie benutzen das ServerManager-Objekt, um einen Verweis auf die Fabrikam-Site abzurufen. In der nächsten Zeile fügen Sie einen Anwendungspool hinzu, indem Sie die Add-Methode der Auflistung ApplicationPoolsCollection benutzen, die von der Eigen-schaft ApplicationPools zurückgegeben wird:ApplicationPool pool = mgr.ApplicationPools.Add("FabrikamPool");

Sie möchten für Ihren Anwendungspool den klassischen Pipelinemodus verwenden. Dies wird in der nächsten Zeile festgelegt, die mit der ManagedPipelineMode-Eigenschaft der ApplicationPool-Klasse arbeitet:pool.ManagedPipelineMode = ManagedPipelineMode.Classic;

Anschließend greifen Sie auf die Stammanwendung der Fabrikam-Site zu und setzen den Anwendungspool auf Ihren neu erstellten FabrikamPool:Site = mgr.Sites["Fabrikam"]; site.Applications[0].ApplicationPoolName = @"FabrikamPool";

Schließlich möchten Sie die Änderungen speichern:mgr.CommitChanges();

Die Konfiguration festlegenDer folgende Code demonstriert, wie die Microsoft.Web.Administration-APIs verwendet werden, um das Standarddokument von Default Web Site zu aktivieren:using System; using Microsoft.Web.Administration; namespace Example { class Program { static void Main(string[] args) { ServerManager mgr = new ServerManager(); Configuration config = mgr.GetWebConfiguration( "Default Web Site"); ConfigurationSection section = config.GetSection( "system.webServer/defaultDocument"); ConfigurationAttribute enabled = section.GetAttribute("enabled"); enabled.Value = true; mgr.CommitChanges(); } } }



In diesem Abschnitt benutzen Sie die Klasse Configuration, um direkt auf einen Konfigurationsabschnitt zuzugreifen und den Wert eines Knotens zu setzen. Dazu müssen Sie zuerst mit der GetWebConfiguration-Methode des Server-Managers auf die Webkonfigurationsstammdatei zugreifen: ServerManager mgr = new ServerManager(); Configuration config = mgr.GetWebConfiguration( "Default Web Site");

Daraufhin wird eine Instanz der Configuration-Klasse an die Anwendung zurückgegeben. Benutzen Sie die Objektinstanz, um direkt auf einen Konfigurationsabschnitt zuzugreifen und dann das Attribut anzufordern, dass Sie ändern möchten:ConfigurationSection section = config.GetSection( "system.webServer/defaultDocument"); ConfigurationAttribute enabled = section.GetAttribute("enabled");

Nehmen Sie zuletzt die Änderung am Attribut vor, und lassen Sie dieser Änderung einen Aufruf von CommitChanges folgen, der zur Aktualisierung des Konfigurationssystems führt: enabled.Value = true; mgr.CommitChanges();

Sie können Microsoft.Web.Administration für viele weitere Aufgaben nutzen. Machen Sie sich über die MSDN-Referenz mit einigen Eigenschaften und Methoden der Assembly vertraut. Sie werden feststellen, dass die meisten Aufgaben über die API gelöst werden können, was oft sehr viel einfacher als eine direkte Bearbeitung der Konfiguration ist.

Windows PowerShell und IIS 7.0Windows PowerShell bietet eine funktionsreiche Befehlsshell an. Windows PowerShell nutzt die Vorzüge der Microsoft C#-Skriptsprache und verwendet ein auf dem .NET Framework basierendes Objektmodell, um leistungsfähige Funktionen für die Umleitung von Objekten und die dynamische Bearbeitung von Ergebnissätzen zur Verfügung stellen. Sie können Befehle direkt von der Befehlszeile aus, aber auch aus Skripts heraus aufrufen.

Wenn Sie mit Windows PowerShell arbeiten, benutzen Sie integrierte Befehle, die als Cmdlets bezeichnet werden. Diese werden genauso wie die Befehle oder Hilfsmittel genutzt, die Sie an der Befehlszeile verwenden. Cmdlets sind sowohl einfach als auch leistungsfähig. Ihre Namen ergeben sich aus einer einfach zu verstehenden Wortpaarung:

� New- Erzeugt eine neue Instanz eines Elements oder Objekts

� Remove- Entfernt eine Instanz eines Elements oder Objekts

� Set- Modifiziert bestimmte Einstellungen eines Objekts

� Get- Ruft ein bestimmtes Objekt oder eine Untermenge eines Objekts ab

Das Cmdlet Get-Credential ruft beispielsweise basierend auf einem Kennwort ein Anmeldeinformations-objekt ab. Sie erhalten eine Liste aller Cmdlets, indem Sie an der Eingabeaufforderung von Windows PowerShell help * eingeben.

Wenn neue Cmdlets für die Verwaltung von IIS-Servern veröffentlicht werden, können Sie diese über Server-Updates oder heruntergeladene Installationspakete installieren.


COM-Objekte für die IIS 7.0-Konfiguration 219

Die folgenden Bücher stellen hervorragende Quellen dar, wenn Sie mehr über den Einsatz von Windows PowerShell unter IIS 7.0 erfahren möchten:

� Microsoft IIS 7.0 Taschenratgeber für Administratoren von William R. Stanek (Microsoft Press, 2007)

� Microsoft Windows PowerShell Step by Step (englisch) von Ed Wilson (Microsoft Press, 2007)

� Windows PowerShell Scripting Guide (englisch) von Ed Wilson (Microsoft Press, 2007)

WMI-AnbieterIIS 7.0 unterstützt auch weiterhin den alten WMI-Anbieter, der unter IIS 6.0 zur Verwaltung des Webservers verwendet wurde. Dieser WMI-Anbieter stellt seine Dienste über den Rollendienst IIS 6-Metabasiskompatibilität zur Verfügung, der die IIS 6.0-Konfigurationseinstellungen und -aktionen in die IIS 7.0-Konfigurationsstruktur übersetzt. Um bereits vorhandene, mit dem WMI-Objektmodell von IIS 6.0 arbeitende Skripts zu benutzen, müssen Sie den Rollendienst IIS 6-WMI-Kompatibilität installieren (Kategorie Verwaltungstools\IIS 6-Verwaltungskompatibilität), sofern Sie unter Windows Server 2008 die Webserverrolle im Server-Manager verwalten. Alternativ hierzu benutzen Sie unter Windows Vista die Seite Windows-Funktionen ein- oder ausschalten. Um mehr über die IIS 6.0-Metabasiskompatibilitätsschicht zu erfahren, lesen Sie bitte das vierte Kapitel.

Hinweis Um Konfigurationsskripts zu verwenden, die Aufrufe an das alte WMI-Objektmodell von IIS 6.0 richten, müssen Sie den Rollendienst IIS 6-WMI-Kompatibilität installieren.

Die Übersetzungsschicht zwischen einem WMI-Skript, dem Metabasisformat und dem neuen Konfi-gurationssystem kann bei der Konfigurationszuordnung zu leichten Abweichungen führen, sofern Sie alte IIS 6.0-Konfigurationsskripts und -APIs verwenden. Deshalb wird empfohlen, bereits vorhandene Skripts zu migrieren, so dass diese die neuen Konfigurations-APIs benutzen. Sie würden sich dann für den Einsatz des neuen WMI-Anbieters entscheiden, der den direkten Zugriff auf das neue Konfigura-tionssystem ermöglicht und ein anderes Objektmodell als der WMI-Anbieter von IIS 6.0 verwendet.

Hinweis Um unter IIS 7.0 den neuen WMI-Anbieter zu nutzen, müssen Sie den Rollendienst IIS-Verwaltungs-skripts und -tools installieren. Installieren Sie nicht den Rollendienst IIS 6-WMI-Kompatibilität, wenn Sie den neuen WMI-Provider verwenden möchten.

Um weitere Informationen zum Objektmodell des WMI-Anbieters zu erhalten, lesen Sie die Online-dokumentation, die unter http://msdn2.microsoft.com/en-us/library/aa347459.aspx verfügbar ist.

COM-Objekte für die IIS 7.0-KonfigurationSie können auch direkt die COM-Objekte für die IIS 7.0-Konfiguration benutzen, um unter IIS 7.0 die IIS-Konfiguration zu verwalten und auf die Verwaltungsfunktionalität zuzugreifen. Sie können aus nativen C++-Programmen, .NET-Anwendungen oder Skriptumgebungen heraus auf diese COM-Objekte zugreifen. Im letzten Fall stellen die COM-Konfigurationsobjekte eine einfachere Alternative für die Nutzung des WMI-Anbieters dar, weil sie einerseits eine einfachere Syntax besitzen und andererseits der Overhead der WMI-Infrastruktur nicht gegeben ist.



Diese COM-Objekte sind ebenfalls verfügbar, wenn IIS 7.0 installiert ist, und sie sind nicht von irgendwelchen externen Komponenten abhängig. Sie erfordern keine Installation des .NET Frame-works.

Um mehr über den Einsatz der COM-Objekte für die IIS 7.0-Konfiguration zu erfahren, lesen Sie bitte die Onlinedokumentation zu den Klassen Microsoft.ApplicationHost.WritableAdminManager und Microsoft.Appli-cationHost.AdminManager.

ZusammenfassungIn diesem Kapitel haben Sie die verfügbaren Optionen für die Verwaltung von IIS 7.0 über die Befehls-zeile kennen gelernt. Dabei wurde besonders Appcmd behandelt – das einheitliche Befehlszeilentool für die IIS 7.0-Verwaltung –, mit dem die meisten grundlegenden IIS 7.0-Verwaltungsaufgaben ausgeführt werden können.

Sie können Appcmd benutzen, um grundlegende IIS 7.0-Objekte einfach zu verwalten. Dazu zählen Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools. Sie können mit dem Pro-gramm Webserverkonfigurationen generisch bearbeiten und alle erforderlichen Konfigurations-aufgaben ausführen. Darüber hinaus können mit Appcmd auch andere Schlüsselaufgaben bequem gelöst werden, wie z.B. die Verwaltung von Webservermodulen, das Konfigurieren der Ablauf-verfolgung für Anforderungsfehler und die Sicherung und Wiederherstellung von Konfigurationen.

Der Vorteil von Appcmd besteht darin, dass zur effektiven Verwaltung des Webservers keine Pro-grammierung erforderlich ist. Wenn Sie jedoch Verwaltungsaufgaben aus einer Programmierumgebung heraus lösen müssen, stehen Ihnen mehrere Optionen zur Entwicklung einer umfassenden Verwaltungs-automatisierung zur Verfügung. Zu diesen Optionen zählen die Microsoft.Web.Adminstration-API für .NET Framework-Anwendungen und der neue WMI-Anbieter. Sie können außerdem benutzerdefinierte Windows PowerShell-Skripts entwickeln. Weitere Informationen zur Nutzung dieser Optionen finden Sie in der MSDN-Onlinedokumentation und in den entsprechenden Artikeln unter http://www.iis.net.



� Artikel zur Verwaltung von IIS über die Befehlszeile finden Sie unter http://www.iis.net. Lesen Sie die MSDN-Dokumentation, um mehr über Appcmd, Microsoft.Web.Administration und WMI zu erfahren.

� Das vierte Kapitel, »Verstehen des Konfigurationssystems«, hält weitere Informationen zum Konfigurationssystem von IIS 7.0 bereit.

� Das sechste Kapitel, »Verwenden von IIS-Manager«, bietet zusätzliche Informationen zur Verwaltung von IIS 7.0 mit dem IIS-Manager.


221

K A P I T E L 8

Remoteverwaltung

Inhalt dieses Kapitels:� Der IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

� Webverwaltungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222



Auf der Begleit-CD Auf der CD finden Sie weitere Tools und Ressourcen .

Die Möglichkeit, einen Server remote zu verwalten, stellt für Administratoren eine wichtige Voraus-setzung dar. Administratoren müssen oft auf dem Server globale Verwaltungsaufgaben ausführen, wie z.B. das Ändern der Einstellungen eines Anwendungspools oder die Konfiguration der Standardproto-kollierungsregeln. Sie müssen aber auch spezifischere Aufgaben lösen, wie z.B. die Aktivierung der Ablaufverfolgung für eine bestimmte Anwendung. Serveradministratoren sind jedoch nicht die einzigen Benutzer, die Einstellungen auf dem Server konfigurieren müssen. In einer gehosteten Umge-bung sollten die Benutzer beispielsweise die Einstellungen ihrer Sites remote bearbeiten können. In einer Unternehmensumgebung könnte es sein, dass die Entwickler Anwendungseinstellungen ändern müssen, obwohl sie keine Administratoren des jeweiligen Computers sind. Solche Aufgaben müssen in der Regel ohne physikalischen Zugriff auf den Server gelöst werden können. IIS (Internet Information Services; Internetinformationsdienste) bietet Ihnen erstmals mit Version 7.0 alle benötigten Konfigura-tionstools, und zwar unabhängig davon, ob Sie ein Serveradministrator oder ein Hoster sind, der seinen Benutzern den Remotezugriff ermöglichen möchte.

IIS 7.0 stellt verschiedene Tools zur Verfügung, mit denen Sie das System von einem Remotecomputer aus verwalten können. Einige dieser Tools sind nachfolgend aufgeführt:

� Der IIS 7.0-Manager (Internet Information Services), bei dem es sich um ein Benutzeroberflächentool für die Verwaltung über HTTPS handelt

� Die AHADMIN-COM-Bibliothek (Application Host Administration-API), die von Skripts und Anwendungen verwendet werden kann

� Die aus verwaltetem Code bestehende Bibliothek Microsoft.Web.Administration, die in Anwendungen benutzt werden kann, die ebenfalls aus verwaltetem Code bestehen

� Der neue WMI-Anbieter (Windows Management Instrumentation), der Skripts oder verwalteten Code verwendet, um Konfigurationen zu verwalten


222 Kapitel 8: Remoteverwaltung

Dieses Kapitel erläutert, wie die vom IIS-Manager angebotene Remotingplattform eingerichtet und genutzt wird. Diese Remotingplattform bietet eine neue Infrastruktur für die Remoteverwaltung von Websites und führt verschiedene Erweiterungen ein, wie z.B. die Delegierung, die Remoteverwaltung über HTTPS und viele weitere neue Features und Konfigurationsoptionen, die Sie mit der Flexibilität ausstatten, die Sie zur Verwaltung von IIS 7.0 benötigen. Dazu zählt auch die Möglichkeit, IIS unter Verwendung nichtadministrativer Windows-Konten zu verwalten.

Der IIS-ManagerDer IIS-Manager besitzt eine überarbeitete Benutzeroberfläche, mit deren Hilfe der Zugriff auf die Konfigurationseinstellungen von IIS 7.0 und ASP.NET über ein integriertes Tool möglich ist. Er wurde von Grund auf neu als einfach zu erweiternde Plattform entworfen, die die Arbeit mit allen Webplatt-formeinstellungen vereinheitlicht. Teil dieses Plattformentwurfs ist eine Remotinginfrastruktur für integrierte Features, aber auch für die Features von Drittanbietern. Weitere Informationen zum IIS-Manager finden Sie im sechsten Kapitel, »Verwenden von IIS-Manager«.

Um einen Server remote zu verwalten, muss der IIS-Manager mit einem separaten IIS 7.0-Dienst zusammenarbeiten, der WMSvc heißt (Web Management Service, Webverwaltungsdienst). Dieser wird als Teil des Rollendienstes IIS-Verwaltungsskripts und -tools installiert.

Hinweis Um ein unter Windows Server 2008 ausgeführtes IIS 7.0-System remote zu verwalten, muss auf dem Clientcomputer der IIS-Manager vorhanden sein. Standardmäßig ist nur Windows 2008 dazu in der Lage. Sie können jedoch eine entsprechende Unterstützung für Windows XP Service Pack 2 (SP2), Windows 2003 SP1 und Windows Vista SP1 für die x86- und x64-Versionen dieser Betriebssysteme herunterladen. Die Adresse lautet: http://iis.net/downloads.

WebverwaltungsdienstDer Webverwaltungsdienst ist ein IIS 7.0-Dienst, der auf dem IIS-Server ausgeführt wird – also dem Server, der remote verwaltet werden soll. Er stellt zwei wichtige Features zur Verfügung:

� Er kümmert sich für den IIS-Manager um die Remoteverwaltung, indem er die HTTPS-Anforde-rungen überwacht, die von den mit dem IIS-Manager arbeitenden Remotebenutzern eingehen. Er führt dann die angeforderten Operationen lokal aus.

� Er ermöglicht Windows Benutzern ohne administrative Rechte und Nicht-Windows-Benutzern den Zugriff, und zwar unabhängig davon, ob sie den IIS-Manager lokal oder von einem Remote-computer aus verwenden.

Hinweis Dieser Dienst funktioniert nicht unter Windows Vista. Dies bedeutet, dass ein unter Windows Vista ausgeführtes IIS-System nicht mithilfe des IIS-Managers remote verwaltet werden kann.

Windows Server 2008 Server Core kann nicht mit verwaltetem Code arbeiten, so dass der Webverwal-tungsdienst für eine solche Konfiguration nicht installiert werden kann.


Webverwaltungsdienst 223

InstallationDer Webverwaltungsdienst ist nicht Teil der IIS 7.0-Standardinstallation, sondern ein optionaler Rollendienst, der installiert werden und dessen Starttyp konfiguriert werden muss. Um ihn zu installieren, können Sie den Server-Manager oder das Befehlszeilentool ServerManagerCMD benutzen. Für die Installation mithilfe des Server-Managers gehen Sie wie folgt vor:

1. Starten Sie den Server-Manager.

2. Markieren Sie im Server-Manager den Knoten Rollen.

3. Klicken Sie innerhalb der Rollengruppe Webserver (IIS) auf Rollendienste hinzufügen.

4. Klicken Sie unter Verwaltungstools auf Verwaltungsdienst und dann auf Weiter.

5. Klicken Sie auf Installieren.

Abbildung 8.1 zeigt das Dialogfeld Rollendienst auswählen.

Abbildung 8.1 Rollendienste des Server-Managers

Um den Webverwaltungsdienst mit ServerManagerCMD zu installieren, lassen Sie die folgende Befehlszeile ausführen:ServerManagerCMD -install Web-Mgmt-Service

Weitere Informationen zur Installation von Features finden Sie im fünften Kapitel, »Installieren von IIS 7.0«.



WMSvc-KonfigurationNachdem der Webverwaltungsdienst installiert wurde, müssen Sie einige Konfigurationsänderungen vornehmen, um den Dienst an Ihre Umgebung anzupassen. Besonders wichtige Konfigurationsauf-gaben sind:

� die Konfiguration des Dienstes für den automatischen Start

� das Ermöglichen von Remoteverbindungen, die Auswahl des SSL-Zertifikats und das Festlegen der IP-Konfiguration

� das Festlegen von IPv4-Adressbeschränkungen

� das Konfigurieren von Verbindungsauthentifizierungsoptionen

Den automatischen Start des Dienstes konfigurierenNach der Installation ist der Webverwaltungsdienst für einen manuellen Start konfiguriert, so dass ein erneuter Start nicht automatisch erfolgt, wenn der Dienst beendet wurde. Diese Situation wäre beispielsweise nach einem Neustart des Computers gegeben. Um somit die Remoteverwaltung nach Beendigung des Webverwaltungsdienstes wieder zu aktivieren, müsste jemand den Dienst manuell starten. Aus diesem Grund ist es wichtig, den Dienst so einzurichten, dass er automatisch startet, wodurch gewährleistet wird, dass die Remoteverwaltung ständig aktiv ist. Sie können dazu die Konsole Dienste oder das Befehlszeilentool Sc.exe verwenden.

Webverwaltungsdienst-SetupDie Installation des Webverwaltungsdienstes nimmt folgende Änderungen an Ihrem Server vor:

� Der Dienst wird so konfiguriert, dass er unter Verwendung des Kontos Lokaler Dienst ausgeführt wird. Dank der Dienstisolation, die ein neues Feature von Windows Server 2008 und Windows Vista ist, werden jedoch alle für den Dienst benötigten Ressourcen über eine WMSvc-spezifische SID (Security Identifier; Sicherheits-ID) namens NT Service\WMSvc geschützt.

� Der Ordner %SystemDrive%\Inetpub\Logs\Wmsvc wird erstellt und NT Service\WMSvc erhält die Berechtigung, diesen Ordner zu modifizieren.

� Es wird eine neue Regel für die Firewall für eingehende Verbindungen aufgestellt. Diese Regel trägt den Namen Webverwaltungsdienst (HTTP) und sie wird für TCP-Port 8172 erstellt und aktiviert.

� Für den Computer wird ein neues selbstsigniertes SSL-Zertifikat (Secure Sockets Layer) gene-riert. Dazu wird ein Name im Format WMSvc-computername verwendet.

� In HTTP.sys wird die SSL-Konfiguration für den Dienst so konfiguriert, dass das selbstsignierte Zertifikat verwendet wird und Port 8172 dafür reserviert ist.

� Die Konfiguration wird in den Registrierungsschlüssel HKLM\Software\Microsoft\WebManage-ment\Server geschrieben.

� Der ASP.NET-Infrastruktur werden Berechtigungen gewährt:� Berechtigungen zum Schreiben und Ändern im .NET Framework-Verzeichnis für temporäre

ASP.NET-Dateien

� Leseberechtigungen für das Verzeichnis %SystemRoot%\System32\Inetsrv\config

� Berechtigungen zum Ändern des ASP.NET-Registrierungsschlüssels CompilationMutexName



Um den Dienst mithilfe der Konsole Dienste für den automatischen Start zu konfigurieren, gehen Sie wie folgt vor:

1. Starten Sie aus der Programmgruppe Verwaltung heraus die Konsole Dienste.

2. Führen Sie einen Doppelklick auf Webverwaltungsdienst aus.

3. Wählen Sie im Dropdown-Listenfeld Starttyp den Eintrag Automatisch und klicken Sie auf OK.

Abbildung 8.2 zeigt das Dialogfeld Eigenschaften von Webverwaltungsdienst.

Abbildung 8.2 Das Dialogfeld Eigenschaften von Webverwaltungsdienst

Um den Dienst mithilfe des Befehlszeilentools Sc.exe (Services Configuration; Dienstkonfiguration) für den automatischen Start zu konfigurieren, lassen Sie in einer Eingabeaufforderung in folgendem Befehl ausführen:sc config WMSvc start= auto

Hinweis WMSvc ist der Name des Dienstes in der Dienstkonfigurationsdatenbank. Achten Sie in der vorherigen Befehlszeile darauf, hinter dem Gleichheitszeichen (=) ein Leerzeichen anzugeben. Der Befehl wird andernfalls nicht richtig ausgeführt.

Remoteverbindungen, SSL-Zertifikat und IP-KonfigurationDer Webverwaltungsdienst ist standardmäßig so konfiguriert, dass zur Durchführung von Verwaltungs-aufgaben nur lokale Verbindungen zum Dienst hergestellt werden können. Auf diese Weise können delegierte Benutzer (Nichtadministratoren) am lokalen Computer eine Verbindung zum Server her-stellen, um ihre Sites und Anwendungen zu verwalten. Von einem Remotecomputer aus können die Benutzer jedoch keine Verbindung herstellen. Um dies zuzulassen, müssen Sie Remoteverbindungen mit dem IIS-Manager-Feature Verwaltungsdienst aktivieren.



Außerdem wird während des Setups unter Verwendung von HTTP.sys ein selbstsigniertes Zertifikat generiert, das für die SSL-Registrierung an Port 8172 verwendet wird. Dieses Zertifikat ist für die schnelle Einrichtung einer Testkonfiguration geeignet. Es wird jedoch nachdrücklich empfohlen, dass Sie ein von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestelltes Zertifikat beantragen, das von den Benutzern verwendet wird, um eine Verbindung zum Server herzu-stellen. Bei einem integrierten selbstsignierten Zertifikat wird auf jedem Remotecomputer, der eine Verbindung zum Server herstellen möchte, eine Warnmeldung angezeigt, die wissen will, ob das Zertifikat vertrauenswürdig ist und die Verbindung zum Server wirklich hergestellt werden soll. Diese Meldung ermöglicht es dem Benutzer, detaillierte Informationen zum Zertifikat einzusehen. Abbildung 8.3 zeigt die Serverzertifikatwarnung, die den Benutzern präsentiert wird, wenn sie ein selbstsigniertes Zertifikat verwenden.

Abbildung 8.3 Serverzertifikatwarnung

Um diese Warnung zu vermeiden, müssen Sie bei Ihrer eigenen vertrauenswürdigen Zertifizierungs-stelle oder bei einer bekannten externen Zertifizierungsstelle ein gültiges Zertifikat für die Server-authentifizierung beantragen und dieses anschließend konfigurieren. Ein solches Zertifikat kann mithilfe verschiedener Tools auf dem Server installiert werden. Zu diesen Tools zählen die Konsole Zertifikate und das IIS-Manager-Feature Serverzertifikate. Nachdem das Zertifikat auf dem Computer installiert wurde, können Sie den Webverwaltungsdienst über das IIS-Manager-Feature Verwaltungs-dienst so konfigurieren, dass er das Zertifikat verwendet. Gehen Sie dazu wie folgt vor:

1. Starten Sie über die Programmgruppe Verwaltung den Internetinformationsdienste-Manager.

2. Markieren Sie im Bereich Verbindungen den Knoten des IIS-Computers, und führen Sie in der Ansicht Features einen Doppelklick auf Verwaltungsdienst aus. Um Änderungen vornehmen zu können, müssen Sie den Webverwaltungsdienst zunächst beenden.

3. Im oberen Bereich der Seite können Sie dafür sorgen, dass Remoteverbindungen möglich sind, indem Sie ein Häkchen in das Kontrollkästchen vor Remoteverbindungen aktivieren setzen.

4. Im Bereich Verbindungen können Sie die IP-Adresse und den Port festlegen, an die/den Sie den Dienst binden möchten. Sie können auch das SSL-Zertifikat auswählen, indem Sie mit dem Drop-down-Listenfeld SSL-Zertifikat arbeiten, das alle für die Serverauthentifizierung verfügbaren Zertifikate enthält.

5. Klicken Sie, nachdem Sie alle erforderlichen Änderungen vorgenommen haben, auf Übernehmen, um den Dienst zu starten.



Abbildung 8.4 zeigt die Konfigurationseinstellungen des Verwaltungsdienstes.

Abbildung 8.4 Das Verwaltungsdienst-Feature

Hinweis Wenn der Webverwaltungsdienst ausgeführt wird, sind die Optionen des Features Verwaltungsdienst deaktiviert. Um die Konfiguration zu ändern, müssen Sie im Bereich Aktionen auf Beenden klicken.

Hinweis Wenn Sie den vom Dienst verwendeten Port ändern und Remoteverbindungen zulassen möchten, müs-sen Sie eine Firewallausnahme für den neuen Port definieren. Andernfalls ist eine Verbindungsherstellung nicht möglich. Während des Setups wird standardmäßig eine Firewallausnahme namens Webverwaltungsdienst (HTTP) für Port 8172 hinzugefügt und aktiviert. Wenn somit die Remotebenutzer den Servernamen in das Dialogfeld Mit Server verbinden eingeben, müssen sie im Textfeld Servername auch den neuen Port angeben (z.B. MyServer-Machine:8173). Weitere Informationen zum Dialogfeld Mit Server verbinden finden Sie später in diesem Kapitel im Abschnitt »Mit der Remoteverwaltung arbeiten«.

Alle vom Feature Verwaltungsdienst konfigurierten Einstellungen sind in der Windows-Registrierung unter dem folgenden Schlüssel gespeichert:HKLM\SOFTWARE\Microsoft\WebManagement\Server



Tabelle 8.1 führt die Registrierungseinträge des Webverwaltungsdienstes auf.

Wie bereits erwähnt wurde, führt eine direkt in der Registrierung erfolgende Änderung einiger Werte, wie z.B. IPAddress, Port oder SslCertificateHash, nicht dazu, dass der Dienst diese Werte automatisch verwendet. Der Grund hierfür besteht darin, dass sie über die Benutzeroberfläche in der URL-Regist-rierung und SSL-Konfiguration von HTTP.sys festgelegt werden. Wenn Sie somit diese Einstellungen automatisch konfigurieren möchten, müssen Sie sowohl die Registrierung manuell aktualisieren als auch eine entsprechende Registrierung bei HTTP.sys durchführen, was mit dem Befehlszeilentool für die Netzwerkkonfiguration (Netsh.exe) möglich ist. Danach starten Sie den Webverwaltungsdienst neu.

IPv4-AdressbeschränkungenWenn der Webverwaltungsdienst ausgeführt wird und Remoteverbindungen aktiviert sind, ist es mög-lich, über jede IP-Adresse eine Verbindung zum Server herzustellen. Mit dem Verwaltungsdienst können Sie für eine bessere Sicherheit sorgen, indem Sie eine bestimmte IP-Adresse oder einen IP-

Tabelle 8.1 Registrierungseinträge für den Webverwaltungsdienst

Wert Beschreibung

EnableLogging Gibt an, ob die Protokollierung aktiviert werden soll. Der Vorgabewerte ist 1 (aktiviert).

EnableRemoteManagement Gibt an, ob der Dienst Remoteverbindungen oder nur lokale, delegierte Verbindungen ermög-lichen soll. Der Vorgabewerte ist 0 (nicht zulässig). Setzen Sie ihn auf 1, um Remoteverbindungen zuzulassen.

IPAddress Gibt die IP-Adresse an, an die der Dienst gebunden ist. Die Vorgabe ist Keine zugewiesen.

Hinweis: Das Ändern dieses Wertes in der Windows-Registrierung hat keine Auswirkungen, da der IIS-Manager die SSL-Konfiguration und die URL-Reservierung mithilfe von HTTP.sys durchführt. (Dies wird später in diesem Kapitel ausführlich erläutert.)

LoggingDirectory Gibt das Verzeichnis an, in dem die Protokolldateien generiert werden sollen. Der Vorgabewert hierfür ist %SystemDrive%\Inetpub\logs\Wmsvc.

Port Legt den Port fest, der vom Dienst verwendet werden soll. Der Vorgabewert ist 8172.Hinweis: Das Ändern dieses Wertes in der Windows-Registrierung hat keine Auswirkungen, da der IIS-Manager die SSL-Konfiguration und die URL-Reservierung mithilfe von HTTP.sys durchführt. (Dies wird später in diesem Kapitel ausführlich erläutert.)

RemoteRestrictions Stellt eine serialisierte Version der Liste zur Verfügung, die die konfigurierten IP-Adress-beschränkungen enthält. Dieser Wert sollte nicht direkt bearbeitet werden.

RequiresWindowsCredentials Legt fest, ob Windows-Anmeldeinformationen oder auch IIS-Manager-Anmeldeinformationen für Remoteverbindungen zulässig sind. Der Vorgabewert ist 1, und er legt fest, dass nur Windows-Anmeldeinformationen erlaubt sind. Setzen Sie ihn auf 0, damit beide Arten von Anmeldeinfor-mationen verwendet werden können. (Weitere Informationen zu diesem Thema finden Sie später in diesem Kapitel im Abschnitt »Verbindungsauthentifizierungsoptionen«.)

SelfSignedSslCertificateHash Enthält das Zertifikathash des während des Setups generierten selbstsignierten Zertifikats

SslCertificateHash Legt das für SSL zu verwendende Zertifikathash fest

Hinweis: Das Ändern dieses Wertes in der Windows-Registrierung hat keine Auswirkungen, da der IIS-Manager die SSL-Konfiguration und die URL-Reservierung mithilfe von HTTP.sys durchführt. (Dies wird später in diesem Kapitel ausführlich erläutert.)



Adressbereich festlegen, der bzw. dem Sie den Zugriff gewähren oder verweigern möchten. Sie können außerdem den Zugriff für alle Clients konfigurieren, die in der Liste nicht aufgeführt sind. Die hierfür erforderliche Konfiguration ist einfacher zu verstehen, wenn sie anhand von Beispielen erläutert wird:

� Eine bestimmte Gruppe von Clients zulassen. Um dies zu konfigurieren, wählen Sie im Dropdown-Listenfeld Zugriff für nicht angegebene Clients den Eintrag Verweigern aus, so dass nur die in der Einschränkungsliste aufgeführten Clients zulässig sind. Sie müssen außerdem alle gewünschten Clients oder IP-Adressbereiche mithilfe der Schaltfläche Zulassen hinzufügen. Abbildung 8.5 zeigt ein Beispiel für diese Konfiguration.

Abbildung 8.5 IPv4-Adresseinschränkung, die nur eine bestimmte Gruppe von Clients zulässt

� Eine bestimmte Gruppe von Clients ablehnen. Um dies zu konfigurieren, wählen Sie im Dropdown-Listenfeld Zugriff für nicht angegebene Clients den Eintrag Zulassen aus. Bei dieser Auswahl dürfen alle Clients außer diejenigen, die in der Einschränkungsliste aufgeführt sind, auf den Server zugreifen. Sie benutzen anschließend die Schaltfläche Verweigern, um alle Clients oder IP-Adressbereiche hinzuzufügen, die Sie ablehnen möchten. Abbildung 8.6 zeigt ein Beispiel für diese Konfiguration.

Hinweis Diese Einstellungen beziehen sich ausschließlich auf IPv4-Adressen. Um sie zu ändern, müssen Remoteverbindungen aktiviert sein.

Hinweis Die vom Webverwaltungsdienst verwendete IPv4-Einschränkungsliste unterscheidet sich von den unter IIS für den Webserver konfigurierten Einschränkungen für IPv4-Adressen und -Domänen. Beide werden unab-hängig voneinander ausschließlich vom jeweiligen zugehörigen Dienst verwendet.

Abbildung 8.6 IPv4-Adresseinschränkung, die eine Zugriffsverweigerung für eine bestimmte Clientgruppe festlegt



VerbindungsauthentifizierungsoptionenEines der leistungsfähigsten Features der delegierten Konfiguration unter IIS 7.0 besteht darin, dass Benutzer ohne administrative Rechte ihre Site- und Anwendungseinstellungen in eigenen web.config-Dateien konfigurieren können. Der Webverwaltungsdienst weitet diese Möglichkeit sogar noch aus, indem er nicht nur die Benutzeroberfläche hierfür zur Verfügung stellt, sondern dafür sorgt, dass die Benutzer ihre eigenen web.config-Dateien ändern können, ohne ein Windows-Benutzerkonto besitzen zu müssen. Solche Benutzer werden als IIS-Manager-Benutzer bezeichnet und können mithilfe des IIS-Managers konfiguriert werden. Wenn Sie eine klare Vorstellung von den Unterschieden zwischen diesen Authentifizierungsmodellen haben, können Sie eine Strategie wählen, die für Ihre Umgebung besonders geeignet ist.

Windows-Anmeldeinformationen Für die Aktivierung der Remoteverwaltung wird der Einsatz von Windows-Anmeldeinformationen empfohlen, da Windows Ihnen eine robuste Lösung für die Verwal-tung von Benutzern und Gruppen und zum Aufstellen von Richtlinien, wie z.B. Kontokennwortricht-linien, bietet. Darüber hinaus hält Windows mehrere Tools bereit, die diese Verwaltungsaufgaben vereinfachen. Wenn Sie mit den Windows-Anmeldeinformationen arbeiten, wird jede Aktion eines Remotebenutzers unter dessen Identität auf dem Server ausgeführt. Dies bedeutet, dass Sie die Sicher-heitsmechanismen von Windows nutzen können, wie z.B. ACLs (Access Control List, Zugriffssteue-rungsliste), um die Ressourcen auf dem Server besser zu schützen. Außerdem können Sie diese Mechanismen genauer steuern. Das bedeutet natürlich, dass Sie dem jeweiligen Benutzer spezifische Zugriffsrechte für die Ressourcen gewähren müssen, die ihm obliegen. Sie müssen insbesondere Schreibrechte für die web.config-Dateien gewähren, die vom Benutzer verwaltet werden.

Windows-Administratoren sind die einzigen Benutzer, die eine Verbindung zu einem Server herstellen und diesen vollständig verwalten können, und sie können immer eine Verbindung zum Server und zu jeder Site oder Anwendung herstellen. Windows-Benutzer, die über keine administrativen Rechte verfügen, können lediglich eine Verbindung zu ihren Sites und Anwendungen herstellen und dies ist auch nur dann möglich, wenn der Administrator ihnen entsprechende Zugriffsrechte gewährt hat.

IIS-Manager-Anmeldeinformationen IIS-Manager-Anmeldeinformationen stellen eine Alternative für solche Situationen dar, in denen die Erstellung von Windows-Konten für alle Remotebenutzer keine Option ist, oder wenn die Benutzer, die eine Verbindung herstellen können sollen, bereits in einem anderen Authentifizierungssystem gespeichert sind, z.B. in einer benutzerdefinierten Datenbank, und Sie mit nur diesem einen Speicher arbeiten möchten. IIS-Manager-Benutzer verwenden ausschließlich eine Kombination aus Benutzername und Kennwort und entsprechen in keinerlei Hinsicht Windows-Prinzipalen. Deshalb werden ihre Anforderungen immer unter der Prozessidentität ausgeführt, die über die Anmeldungseinstellung des Webverwaltungsdienstes konfiguriert wird. Der Webverwaltungsdienst ist standardmäßig so konfiguriert, dass er das Konto Lokaler Dienst verwendet, doch dank des Dienst-isolationsfeatures von Windows Server 2008 können Sie die dienstspezifische SID NT Service\WMSvc verwenden, um den Zugriff auf Inhalte und Ressourcen zu schützen.

Ein Nachteil, der mit der Nutzung der IIS-Manager-Anmeldeinformationen einhergeht, besteht darin, dass Sie immer derselben Identität (NT Service\WMSvc) Zugriffsrechte für alle nutzbaren Ressourcen gewähren müssen, und zwar unabhängig davon, zu welcher Site oder Anwendung der jeweilige Benutzer eine Ver-bindung herstellt. Dies bedeutet, dass auf der Betriebssystemebene keine Isolation gegeben ist. Dies sollte jedoch kein Problem darstellen, da die integrierten IIS-Manager-Features so entwickelt wurden, dass ein Benutzer außerhalb seines Gültigkeitsbereichs keine Aktionen initiieren kann. Die Funktionalität des IIS-Managers ist jedoch erweiterbar und es ist wichtig, dass Sie IIS-Manager-Verwaltungsfeatures nur von vertrauenswürdigen Quellen installieren, da sie innerhalb von WMSvc ausgeführt werden.



Ein interessantes Merkmal der Arbeit mit IIS-Manager-Benutzern ist, dass diese Funktionalität mithilfe einer erweiterbaren Architektur entwickelt wurde, die von Ihnen ersetzt werden kann. Auf diese Weise erhalten Sie die Möglichkeit, die Authentifizierung und Autorisierung anhand eines eigenen Benutzer-speichers durchzuführen. Dabei kann es sich um eine bereits vorhandene Datenbank, einen LDAP-Anbieter oder etwas anderes handeln. Weitere Informationen finden Sie unter http://msdn2.microsoft. com/Microsoft.Web.Management.Server.ManagementAuthenticationProvider.aspx.

Die integrierte Implementierung des Authentifizierungsanbieters verwendet unsere Konfigurations-APIs, um die Anmeldeinformationen eines Benutzers in einer Datei namens administration.config zu speichern, welche sich im Verzeichnis %SystemRoot%\System32\Inetsrv\Config befindet. Zu den in dieser Datei gespeicherten Anmeldeinformationen zählen der Benutzername und das SHA256-Hash des zugehörigen Kennwortes. Diese Verfahrensweise ist besonders dann nützlich, wenn das IIS-Feature Freigegebene Konfiguration aktiviert wird. Sie stellt eine einfache und bequeme Möglichkeit dar, um mit einer Benutzerliste zu arbeiten, die für mehrere Computer zentral verwaltet wird.

Wenn Sie mit IIS-Manager-Anmeldeinformationen arbeiten, ist auch die Frage, ob Ihre Sites oder Anwendungen auf einem Remotecomputer gespeichert und über einen UNC-Pfad (Universal Naming Convention) verfügbar sind, von besonderer Bedeutung. Wenn die von den IIS-Manager-Benutzern initiierten Operationen unter der Prozessidentität ausgeführt werden und der Webverwaltungsdienst standardmäßig die Identität Lokaler Dienst verwendet, können die IIS-Manager-Benutzer solche Ressourcen, die sich außerhalb des lokalen Computers befinden, nicht verwalten, es sei denn, Sie ändern die Anmeldeidentität des Webverwaltungsdienstes.

Tabelle 8.2 fasst die Benutzertypen und deren Merkmale zusammen.

Tabelle 8.2 Benutzertypen und deren Merkmale

Benutzertyp Gültigkeitsbereich der Verbindung Ausführungsidentität

Windows-Administratoren Windows-Administratoren dürfen immer eine Verbindung zum Server und zu jeder beliebigen Site und Anwendung des Computers herstellen

Jede Aktion des Servers wird unter der Identität des aufrufenden Windows- Administrators ausgeführt

Windows-Benutzer Windows-Benutzer dürfen lediglich Verbindungen zu Sites und Anwendungen herstellen, sofern ihnen über das Feature IIS-Manager-Berechtigungen die entspre-chenden Zugriffsrechte gewährt wurden. Gewöhnliche Windows-Benutzer können somit niemals eine Verbin-dung herstellen, um den gesamten Server zu verwalten. Sie können lediglich für Sites oder Anwendungen zuständig sein.

Jede Aktion des Servers wird unter der Identität des aufrufenden Windows- Benutzers ausgeführt

IIS-Manager-Benutzer IIS-Manager-Benutzer dürfen nur dann Verbindungen zu Sites oder Anwendungen herstellen, wenn mithilfe des Features Verwaltungsdienst IIS-Manager-Benutzer zugelassen wurden und wenn ihnen über das Fea- ture IIS-Manager-Berechtigungen die entsprechenden Zugriffsrechte gewährt wurden. Sie dürfen niemals eine Verbindung herstellen, um den gesamten Server zu verwalten. Sie können lediglich für Sites und Anwen-dungen zuständig sein.

Jede Aktion des Servers wird unter der Prozessidentität ausgeführt, die mit der Dienstanmeldeidentität konfiguriert wird. Aus Gründen der Einfachheit können Sie davon ausgehen, dass es sich hierbei immer um NT Service\WMSvc handelt.



Die Remoteverwaltung verwaltenDer vorherige Abschnitt konzentrierte sich auf die Aktivierung des Dienstes und vermittelte einen ersten Einblick. In diesem Abschnitt werden die Aufgaben behandelt, die Sie in Verbindung mit der Remoteverwaltung regelmäßig ausführen müssen, z.B. das Hinzufügen neuer Benutzer, das Gewähren von Berechtigungen und das Anpassen der Delegierung.

Benutzer und Berechtigungen verwaltenDie Vorgehensweise zum Verwalten von Benutzern und Berechtigungen kann abhängig davon vari-ieren, welche Authentifizierungsoption Sie gewählt haben. Die folgenden Abschnitte sind keine detaillierte Anleitung hinsichtlich der Vorkehrungen, die es für die Arbeit mit einer Website zu treffen gilt (engl. Provisioning), sondern vielmehr einige der Schritte, die zur Bereitstellung einer einfachen Site erforderlich sind. Weitere Informationen zu den notwendigen Vorkehrungen erhalten Sie, wenn Sie unter http://iis.net nach Secure Hosting oder mit einer Suchmaschine nach den Begriffen Provisioning und IIS suchen.

Windows-Anmeldeinformationen Wenn Sie mit Windows-Benutzern arbeiten, können Sie jedes native Windows-Tool zur Erstellung und Verwaltung von Benutzern verwenden. Windows-Benutzer, die nur Sites oder Anwendungen verwalten, müssen kein Mitglied der Gruppe Administratoren oder einer anderen Gruppe sein. Eine einfache Möglichkeit, Benutzer hinzuzufügen, ist der Einsatz des Befehlszeilentools Net.exe. Um beispielsweise einen neuen lokalen Windows-Benutzer namens DelegatedUser1 hinzuzufügen, können Sie einfach die folgende Befehlszeile ausführen lassen:net user /add DelegatedUser1 Str0ngP@ssw0rd!

Sie können nun eine Site namens DelegatedUser1Site erstellen und deren Inhalte und Konfiguration für den Benutzer schützen, so dass nur dieser die entsprechenden Einstellungen bearbeiten kann. Die folgenden Befehlszeilen erzeugen ein Verzeichnis, gewähren dem Benutzer Modifizierungsrechte für diesen Ordner und registrieren ihn mithilfe von Appcmd bei IIS 7.0 als Site:Mkdir c:\Sites\DelegatedUser1Site icacls c:\Sites\DelegatedUser1Site /grant DelegatedUser1:(OI)(CI)(M) %windir%\system32\inetsrv\appcmd.exe add site /name:"DelegatedUser1Site"/physicalPath:c:\Sites\DelegatedUser1Site /bindings:http/*:8080:

Hinweis Lange Befehle werden bisweilen in mehrere Zeilen umbrochen, damit sie auf die gedruckte Seite passen.

Nachdem Sie den Benutzer und die Site erstellt und konfiguriert haben, können Sie das Feature IIS-Manager-Berechtigungen aufrufen und dem neu erstellten Benutzer Zugriffsrechte gewähren, so dass er seine eigene Site verwalten kann. Diese Aufgabe kann auch unter Verwendung von Windows PowerShell mithilfe von verwaltetem Code und der Microsoft.Web.Management-API automatisiert werden, was später in diesem Kapitel beschrieben wird.

Die folgenden Schritte gewähren dem Benutzer DelegatedUser1 die Berechtigungen, die er benötigt, um eine Verbindung zur Site DelegatedUser1Site herzustellen:

1. Starten Sie aus der Programmgruppe Verwaltung heraus den Internetinformationsdienste-Manager.2. Erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers sowie den Knoten Sites und

markieren Sie innerhalb der hierarchischen Struktur die Site DelegatedUser1Site.3. Führen Sie einen Doppelklick auf dem Feature IIS-Manager-Berechtigungen aus.4. Klicken Sie im Bereich Aktionen auf Benutzer zulassen, geben Sie im Textfeld unter Windows

DelegatedUser1 ein, und klicken Sie auf OK. Beachten Sie, dass Sie in diesem Textfeld auch den Namen einer Gruppe eingeben können, um ganze Windows-Gruppen zuzulassen.



Abbildung 8.7 zeigt das Dialogfeld Benutzer zulassen. Beachten Sie, dass, wenn auf der Verwaltungs-dienstseite nur Windows-Anmeldeinformationen aktiviert sind, im oberen Teil des Bereichs Aktionen eine entsprechende Meldung angezeigt wird und im Dialogfeld Benutzer zulassen die Option IIS-Manager deaktiviert ist. Sie können auch die Schaltfläche Auswählen benutzen, um nach bereits vorhandenen Windows-Benutzern und -Gruppen zu suchen.

Abbildung 8.7 Das Dialogfeld Benutzer zulassen für Windows-Benutzer

Wenn Sie die vorherigen Schritte befolgt haben, kann nun der Benutzer DelegatedUser1 den IIS-Manager verwenden, um remote oder lokal eine Verbindung zu dieser Site herzustellen und sie zu verwalten.

IIS-Manager-Anmeldeinformationen Wenn Sie mit IIS-Manager-Anmeldeinformationen arbeiten, können Sie den IIS-Manager verwenden, um Benutzer zu verwalten. Wie bereits früher in diesem Kapitel erwähnt wurde, wurde diese Funktionalität unter Verwendung einer erweiterbaren Architektur und eines anbieterbasierten Modells entwickelt. Die integrierte Funktionalität verwendet administra-tion.config, um den Benutzernamen und das SHA256-Hash des Kennwortes zu speichern, so dass Sie nicht einfach den Windows-Editor benutzen können, um administration.config zu bearbeiten und Benutzer hinzuzufügen. Wir empfehlen zwei Verfahrensweisen für das Hinzufügen von Benutzern: Arbeiten Sie mit dem IIS-Manager oder verwenden Sie die zugrunde liegende, aus verwaltetem Code bestehende API (Microsoft.Web.Management). Glücklicherweise sind Aufrufe von Objekten, die aus verwal-tetem Code bestehen, mit Windows PowerShell sehr einfach, und Sie werden noch erfahren, wie Sie dieses Tool verwenden, um IIS-Benutzer ohne die Hilfe des IIS-Managers zu verwalten. Nachfolgend ist ein Beispiel aufgeführt, das dem vorherigen gleicht und das einen neuen Benutzer namens IISUser1 erstellt und für diesen eine neue Site einrichtet. Der Benutzer IISUser1 kann die Site dann verwalten.

Zuerst erstellen wir eine Site namens IisUser1Site und schützen den Inhalt und die Konfiguration, so dass NT Service\WMSvc die Einstellungen bearbeiten kann. Die folgenden Befehlszeilen erstellen das Verzeichnis, gewähren dem Dienst Modifizierungsberechtigungen für diesen Ordner und registrieren ihn mithilfe von Appcmd bei IIS 7.0 als Site:Mkdir c:\Sites\IISUser1Site icacls c:\Sites\IISUser1Site /grant "NT Service\WMSvc":(OI)(CI)(M) %windir%\system32\inetsrv\appcmd.exe add site /name:"IISUser1Site" /physicalPath:c:\Sites\IISUser1Site /bindings:http/*:8081:

Mit den Features IIS-Manager-Benutzer und IIS-Manager-Berechtigungen erstellen Sie schließlich den Benutzer und weisen ihm die entsprechenden Berechtigungen zu.

1. Starten Sie aus der Programmgruppe Verwaltung heraus den Internetinformationsdienste-Manager.

2. Markieren Sie im Bereich Verbindungen den Knoten des IIS-Computers und führen Sie einen Dop-pelklick auf dem Feature IIS-Manager-Benutzer aus.



3. Klicken Sie im Bereich Aktionen auf Benutzer hinzufügen, geben Sie im Textfeld Benutzername IISUser1 ein, vermerken Sie ein sicheres Kennwort, bestätigen Sie dieses und klicken Sie auf OK.

Abbildung 8.8 zeigt das Dialogfeld Benutzer hinzufügen.

Abbildung 8.8 Das Dialogfeld Benutzer hinzufügen

Nachdem der Benutzer erstellt wurde, können Sie die Site markieren und das Feature IIS-Manager-Berechtigungen in derselben Weise wie für Windows-Benutzer verwenden, um die Zugriffsrechte für die Site festzulegen.

Die folgenden Schritte gewähren dem Benutzer IISUser1 die Berechtigungen, die er benötigt, um eine Verbindung zur Site IISUser1Site herzustellen:

1. Starten Sie aus der Programmgruppe Verwaltung heraus den Internetinformationsdienste-Manager.

2. Erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers sowie den Knoten Sites, und markieren Sie innerhalb der hierarchischen Struktur die Site IISUser1Site.

3. Führen Sie einen Doppelklick auf dem Feature IIS-Manager-Berechtigungen aus.

4. Klicken Sie im Bereich Aktionen auf Benutzer zulassen und wählen Sie die Option IIS-Manager. Geben Sie im Textfeld IISUser1 ein und klicken Sie auf OK.

Abbildung 8.9 zeigt das Dialogfeld Benutzer zulassen mit ausgewählter IIS-Manager-Option. Beachten Sie, dass Sie auf die Schaltfläche Auswählen klicken können, um eine Liste mit bereits vorhandenen IIS-Manager-Benutzern zu erhalten.

Hinweis Wenn Sie mit der Seite IIS-Manager-Berechtigungen arbeiten, um Zugriffsrechte für IIS-Manager-Benutzer zu gewähren, müssen Sie sicherstellen, dass der Verwaltungsdienst so konfiguriert wurde, dass Windows-Anmeldeinformationen und IIS-Manager-Anmeldeinformationen verwendet werden können. Andernfalls ist im Dialogfeld Benutzer zulassen die Option IIS-Manager deaktiviert.

Abbildung 8.9 Das Dialogfeld Benutzer zulassen für IIS-Manager-Benutzer



Wenn Sie die vorherigen Schritte befolgt haben, wird dem Benutzer IISUser1 der Zugriff auf seine Site gewährt und da wir die integrierte Authentifizierung verwenden, wird er unter Verwendung einer ähnlichen Syntax wie der folgenden in %SystemRoot%\System32\Inetsrv\Config\Administration.config gespeichert:<system.webServer> <management> <authentication defaultProvider="ConfigurationAuthenticationProvider"> <providers> <add name="ConfigurationAuthenticationProvider" type="Microsoft.Web.Management.Server.ConfigurationAuthenticationProvider, ..." /> </providers> <credentials> <add name="IISUser1" password="DE499719..." /> </credentials> </authentication> <authorization defaultProvider="ConfigurationAuthorizationProvider"> <providers> <add name="ConfigurationAuthorizationProvider" type="Microsoft.Web.Management.Server.ConfigurationAuthorizationProvider, ... " /> </providers> <authorizationRules> <scope path="/DelegatedUser1Site"> <add name="CONTOSO\DelegatedUser1" /> </scope> <scope path="/IISUser1Site"> <add name="IISUser1" /> </scope> </authorizationRules> </authorization> ...

Windows PowerShell zur Verwaltung von IIS-Benutzern und -Berechtigungen verwenden Möchten Sie die Erstellung von IIS-Benutzern oder das Ausstatten von Windows- bzw. IIS-Benutzern mit IIS-Manager-Berechtigungen automatisieren, sollten Sie hierzu die zugrunde liegende API verwenden, die vom IIS-Manager-Erweiterbarkeitsmodell in Microsoft.Web.Management offen gelegt wird. In diesem Fall gibt es zwei statische Klassen, die Sie aufrufen können, um die Authentifizierung und Autorisierung von IIS-Benutzern zu verwalten. Glücklicherweise gestaltet Windows PowerShell diese Aufgabe sehr einfach.

Um einen neuen IIS-Benutzer namens IisUser2 zu erstellen und diesem das Recht zu gewähren, eine Verbindung zur Site IisUser1Site herzustellen, können Sie innerhalb einer Windows PowerShell-Konsole die folgenden Befehle ausführen lassen:

Hinweis Windows PowerShell ist ein installierbares Feature von Windows Server 2008 und Sie können das Tool mithilfe des Server-Managers installieren.



# Zuerst die Assembly Microsoft.Web.Management laden [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Management") # Einen neuen IIS-Benutzer erstellen [Microsoft.Web.Management.Server.ManagementAuthentication]::CreateUser("Iis User2", "Str0ngP@ssw0rd!") # Dem Benutzer Berechtigungen zuweisen, damit er eine Verbindung zur Website IisUser1Site herstellen kann [Microsoft.Web.Management.Server.ManagementAuthorization]::Grant("IisUser2", "IisUser1Site", 0)

Da diese API intern den in administration.config konfigurierten Anbieter verwendet, um Aufrufe zu verarbeiten, werden die Einstellungen ohne Nennung des Anbieterspeichers korrekt gespeichert. Deshalb funktioniert der Code, obwohl nirgendwo angegeben ist, dass der Benutzername in administ-ration.config und das Kennwort als SHA256-Hash gespeichert werden muss. Wenn ein Entwickler seinen eigenen Authentifizierungs- oder Autorisierungsanbieter erstellt, funktioniert der vorherige Code ebenfalls mit diesem Benutzerspeicher, und zwar unabhängig davon, ob es sich dabei um eine Datenbank oder etwas anderes handelt.

Delegierung von FeaturesDer vorherige Abschnitt hat beschrieben, wie Benutzer erstellt werden und wie diesen Benutzern die Möglichkeit gewährt wird, eine Remoteverbindung herzustellen, so dass sie ihre Sites und Anwen-dungen verwalten können. Es wurde jedoch noch kein Wort darüber verloren, welche Einstellungen diese Benutzer sehen und konfigurieren dürfen, sobald sie verbunden sind, und wie Sie dies konfi-gurieren. An dieser Stelle kommt die Featuredelegierung ins Spiel.

Abbildung 8.10 Die Seite Delegierung von Features



Mit der Featuredelegierung können Sie festlegen, welche Optionen die Benutzer, die eine Verbindung hergestellt haben, nicht sehen können sollen, welche Features schreibgeschützt sind und welche Fea-tures von den Benutzern geändert werden dürfen. Sie können beispielsweise bestimmen, dass alle Sites die Einstellungen zum Durchsuchen von Verzeichnissen modifizieren dürfen, während der Zugriff auf die CGI-Einstellungen schreibgeschützt ist. Gleichzeitig könnten Sie festlegen, dass die Benutzer einer bestimmten Site oder Anwendung die Erlaubnis besitzen, CGI-Einstellungen zu ändern, und dass andere Anwendungen die CGI-Einstellungen nicht sehen dürfen (folglich sollten Sie sie aus der Featureansicht dieser Anwendungen entfernen).

Abbildung 8.10 zeigt die Seite Delegierung von Features mit den Standardeinstellungen für alle Sites des Servers.

Diese Seite kennt zwei Betriebsmodi. Der erste ist der Standarddelegierungsmodus, der aktiv ist, wenn Sie die Seite zum ersten Mal aufrufen und mit dem Sie den Delegierungszustand aller untergeordneten Objekte (engl. Children) des gegenwärtig markierten Objekts festlegen können. Abbildung 8.10 zeigt beispielsweise die Standardeinstellungen für alle Sites des Servers. Der zweite Betriebsmodus ist der benutzerdefinierte Sitedelegierungsmodus und er ermöglicht es Ihnen, die Site oder Anwendung zu wählen, für die Sie den Delegierungszustand konfigurieren möchten. Abbildung 8.11 zeigt die Ansicht Benutzerdefinierte Sitedelegierung. Beachten Sie das Dropdown-Listenfeld Sites, mit dem Sie die Site auswählen können, die Sie anpassen möchten. Alle Änderungen wirken sich dann ausschließlich auf die ausgewählte Site bzw. Anwendung und deren Children aus.

Abbildung 8.11 Die Seite Benutzerdefinierte Sitedelegierung



DelegierungszuständeAuf der Seite Delegierung von Features gibt die Spalte Delegierung den Delegierungszustand jedes Features an. Mit den darin enthaltenen Werten legen Sie die verschiedenen Zustände fest, z.B. ob ein Feature für die untergeordneten Sites oder Anwendungen sichtbar sein soll. Tabelle 8.3 zeigt die möglichen Werte und das entsprechende Verhalten der integrierten Features des IIS-Managers.

Hinweis Die Liste der Delegierungszustände variiert abhängig vom verwalteten Feature, da jedes einzelne Feature die Delegierungszustände und deren Einstellungen selbst definiert. Wenn Sie Features von Drittanbietern verwenden, können deren Werte und Verhaltensweisen anders als bei den soeben beschriebenen Features imple-mentiert sein.

Tabelle 8.3 Delegierungszustände

Delegierung Beschreibung

Lesen/Schreiben Vollständig delegiert und die Benutzer können die Featureeinstellungen ändern. Wenn das Feature mit Konfigurationsabschnitten arbeitet, werden diese Abschnitte entsperrt, so dass sie innerhalb der web.con-fig-Dateien der Sites, Anwendungen oder Ordner, die sich unterhalb des aktuellen Objekts befinden, modifiziert werden können. Das Entsperren der Konfigurationsabschnitte führt außerdem dazu, dass der IIS-Manager alle Einstellungen tiefstmöglich im Konfigurationspfad speichert, so dass die Einstellungen für eine Site oder Anwendung möglichst in deren web.config-Datei gespeichert wird.

Schreibgeschützt Schreibgeschützt, so dass die delegierten Benutzer die Featureeinstellungen lediglich einsehen, aber nicht ändern können. Wenn das Feature mit Konfigurationsabschnitten arbeitet, werden diese gesperrt, so dass sie in den web.config-Dateien unterhalb des aktuellen Objekts nicht modifiziert werden können. Das Sperren dieser Konfigurationsabschnitte führt dazu, dass der IIS-Manager alle Einstellungen für die untergeordneten Objekte im aktuellen Konfigurationspfad speichert und dort location-Pfade für die Objekte verwendet. Wenn beispielsweise ein Feature auf der Serverebene mit Schreibgeschützt gekenn-zeichnet wird, werden alle Einstellungen für die entsprechenden Sites und Anwendungen unter Verwen-dung von location-Pfaden in applicationHost.config und nicht in den web.config-Dateien dieser Sites und Anwendungen gespeichert.

Nicht delegiert Wird delegierten Benutzern nicht angezeigt. Wenn das Feature mit Konfigurationsabschnitten arbeitet, werden diese wie bei der Einstellung Schreibgeschützt gesperrt. Darüber hinaus wird das Feature aus administration.config entfernt, so dass die Benutzer es nicht sehen können.

Konfiguration lesen/schreiben

Wie Lesen/Schreiben, wird aber auch für Features mit Einstellungen oder Daten verwendet, die außerhalb von IIS gespeichert und verwaltet werden. Wird für Features wie ASP.NET-Rollen und ASP.NET-Benutzer verwendet, die mit solchen externen Featureeinstellungen arbeiten, wozu beispielsweise auch der im Konfigurationssystem zu verwendende Anbieter zählt. Dieser spezifische Anbieter verarbeitet jedoch die eigentlichen Daten und diese können vom IIS-Manager nicht geschützt werden. In diesem Fall bedeutet Konfiguration lesen/schreiben, dass delegierte Benutzer den Konfigurationsteil des Features ändern können. Die Konfigurationsabschnitte des Features werden entsperrt, so dass in den entsprechenden web.config-Dateien eine Modifizierung möglich ist.

Konfiguration schreibgeschützt

Wie Schreibgeschützt, ist aber ein spezieller Delegierungszustand für ASP.NET-Features, die Einstellun-gen sowohl in der Konfiguration als auch in einem anderen Speicher ablegen, z.B. in einer Datenbank. In diesem Fall bedeutet Konfiguration schreibgeschützt, dass delegierte Benutzer den Konfigurationsteil des Features nicht ändern können. Die Konfigurationsabschnitte des Features werden gesperrt. Die vom Anbieter verwalteten Daten können jedoch auch weiterhin vom Benutzer modifiziert werden.



Wie bereits in Tabelle 8.3 erwähnt wurde, gründet die Featuredelegierung auf den Sperrmechanismen des im vierten Kapitel, »Verstehen des Konfigurationssystems«, beschriebenen Konfigurationssystems und auf der Erweiterbarkeit des IIS-Managers in administration.config. Besonders erwähnenswert ist, dass der IIS-Manager das Konfigurationssystem nutzt, um zu ermitteln, wo die Konfigurations-einstellungen zu jedem Feature gespeichert werden sollen. Um anzugeben, wo die Einstellungen gespeichert werden, zeigt der IIS-Manager in der Statusleiste die bei Änderungen zu modifizierende Konfigurationsdatei an.

Abbildung 8.12 zeigt, wie sich die Statusleiste präsentiert, wenn Sie ein delegiertes Feature für eine Anwendung namens BlogApp verwalten, die Default Web Site zugeordnet ist. In diesem Fall wird die Einstellung in der web.config-Datei der Anwendung gespeichert.

Abbildung 8.12 Die Statusleiste gibt an, dass Änderungen in web.config gespeichert werden

Abbildung 8.13 zeigt, wie sich die Statusleiste präsentiert, wenn Sie ein nicht delegiertes Feature für eine Anwendung namens BlogApp verwalten, die Default Web Site zugeordnet ist. In diesem Fall werden die Einstellungen in applicationHost.config gespeichert und es wird der Speicherortpfad (location-Tag) Default Web Site/BlogApp verwendet.

Abbildung 8.13 Die Statusleiste gibt an, dass Änderungen in applicationHost.config gespeichert werden

Wenn Sie den Server verwalten, finden Sie die Seite Delegierung von Features ausschließlich auf der Serverebene. Sie können dort lediglich die Delegierungseinstellungen für die Sites konfigurieren. Um Delegierungseinstellungen für Anwendungen anzupassen, müssen Sie eine direkte Verbindung zu der Site herstellen, die Sie verwalten möchten. Dies ist mit der IIS-Manager-Option Mit einer Site verbinden möglich. Nachdem die Verbindung hergestellt wurde, finden Sie die Seite Delegierung von Features auf der Siteebene und Sie können die Einstellungen für alle Anwendungen der Site ändern. Alternativ hierzu können Sie mit der benutzerdefinierten Anwendungsdelegierung arbeiten, um die Einstellungen einer bestimmten Anwendung zu ändern. Um mehr über die verschiedenen Verbindungstypen zu erfahren, lesen Sie später in diesen Kapitel den Abschnitt »Mit der Remoteverwaltung arbeiten«.

Die Seite Benutzerdefinierte Sitedelegierung ermöglicht es Ihnen, Einstellungen zwischen Sites zu kopieren. (Diese Funktionalität ist auch auf der Seite Benutzerdefinierte Anwendungsdelegierung verfügbar.) Auf diese Weise können Sie einfach sicherstellen, dass zwei Sites dieselbe Delegierungs-ebene verwenden. Die restlichen Standardeinstellungen Ihrer Sites müssen dazu nicht geändert werden. Abbildung 8.14 zeigt das Dialogfeld Delegierung kopieren. In diesem Fall werden die Delegierungs-einstellungen von IisUser1Site nach DelegatedUser1Site kopiert.

Hinweis Die Delegierungskonfiguration wird sowohl in administration.config als auch in applicationHost.config gespeichert. Dies bedeutet, dass bei aktivierter freigegebener Konfiguration die Delegierungskonfiguration auto-matisch von allen Servern, die für die Arbeit mit der freigegebenen Konfiguration konfiguriert sind, gemeinsam genutzt wird, weil die Server auch beide Dateien gemeinsam nutzen.



Abbildung 8.14 Das Dialogfeld Delegierung kopieren

Mit der Remoteverwaltung arbeitenMöchten Sie im IIS-Manager die Remoteverwaltung nutzen, müssen Sie eine Verbindung zu einem Remotecomputer herstellen, der den Webverwaltungsdienst ausführt. Um eine größere Flexibilität zu bieten, hält der IIS-Manager drei Verbindungstypen bereit, die bezogen auf die Verwaltung Unter-schiede hinsichtlich der Konfigurationstiefe, des Gültigkeitsbereichs und der Funktionalität aufweisen: Mit einem Server verbinden, Mit einer Site verbinden, Mit einer Anwendung verbinden. Abbildung 8.15 zeigt diese drei Optionen im Datei-Menü des IIS-Managers. Sie finden diese Optionen ebenfalls auf der Startseite und im Kontextmenü des Bereichs Verbindungen.

Abbildung 8.15 Verbindungsoptionen des IIS-Managers



Serververbindungen ermöglichen es dem Serveradministrator, den gesamten Server zu verwalten. Der Administrator besitzt dann die volle Kontrolle über jede Einstellung und jedes Feature des Computers. Nur Windows-Benutzer mit administrativen Rechten können solche Verbindungen herstellen. Für solche Benutzer bedeutet eine Konfigurationssperrung schlimmstenfalls, dass eine Konfiguration an anderer Stelle gespeichert wird. Es sind die einzigen Benutzer, die in applicationHost.config und der web.config-Stammdatei Änderungen vornehmen können.

Siteverbindungen erlauben sowohl Serveradministratoren als auch Siteadministratoren (delegierte Benutzer, denen das Recht gewährt wurde, eine Verbindung zu einer Site herzustellen), eine voll-ständige Site einschließlich all ihrer Anwendungen zu verwalten. Ihr Gültigkeitsbereich ist auf die jeweilige Site beschränkt und es ist nicht möglich, eine Konfigurationsdatei der Serverebene zu modi-fizieren, z.B. applicationHost.config oder die web.config-Stammdatei. Wenn auf der Serverebene die Konfiguration für einen Konfigurationsabschnitt gesperrt ist, ist das entsprechende Feature automatisch schreibgeschützt, so dass keine Änderungen zulässig sind.

Anwendungsverbindungen ermöglichen es Serveradministratoren, Siteadministratoren und Anwen-dungsadministratoren (delegierte Benutzer, denen das Recht gewährt wurde, eine Verbindung zu einer Anwendung herzustellen), eine vollständige Anwendung einschließlich aller Ordner und virtuellen Verzeichnisse, aber mit Ausnahme untergeordneter Anwendungen zu verwalten. Ihr Gültigkeitsbereich ist auf die Anwendung beschränkt und es ist nicht möglich, Konfigurationsdateien der Server- oder Siteebene zu ändern. Wenn die Konfiguration auf der Siteebene oder für einen übergeordneten Ordner gesperrt ist, ist das Feature automatisch schreibgeschützt, so dass keine Änderungen zulässig sind.

Abbildung 8.16 zeigt das Dialogfeld Mit Anwendung verbinden.

Abbildung 8.16 Anwendungsverbindungsinformationen im Dialogfeld Mit Anwendung verbinden

Sobald Sie auf Weiter klicken, werden Sie dazu aufgefordert, Anmeldeinformationen in das Dialogfeld einzugeben, wie in Abbildung 8.17 dargestellt. Wie bereits erwähnt wurde, können dies Anmelde-informationen für Windows- oder IIS-Manager-Benutzer sein.



Abbildung 8.17 Benutzeranmeldeinformationen im Dialogfeld Mit Anwendung verbinden

Nachdem die Verbindung hergestellt wurde, sehen Sie im Bereich Verbindungen einen ganz neuen Eintrag, der Aufschluss über den Verbindungstyp und den Namen des Benutzers gibt, der die Verbin-dung initiiert hat. In der rechten unteren Ecke der Statusleiste sehen Sie den Namen des für die Verbindung verwendeten Servers, den Port und den Benutzernamen. Auf der Startseite sind nur die Features zu sehen, die delegiert wurden (entweder Schreibgeschützt oder Lesen/Schreiben). Abbildung 8.18 zeigt, dass das ASP-Feature einer Anwendungsverbindung schreibgeschützt ist, weil seine Konfiguration standardmäßig gesperrt ist.

Abbildung 8.18 Das ASP-Feature, das bei einer Anwendungsverbindung schreibgeschützt ist



Hinweis Wenn Sie einen anderen Port als 8172 verwenden, müssen Sie diesen bei der Verbindungsherstellung im Textfeld Servername eingeben, z.B. MyMachine:8173.

ProblembehandlungDie häufigsten Quellen für Probleme mit der Remoteverwaltung sind durch zwei Fehlermeldungen gekennzeichnet: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden und 401 - Nicht autorisiert.

Die Verbindung mit dem Remoteserver kann nicht hergestellt werdenWenn Sie versuchen, eine Remoteverbindung herzustellen und vom Remoteserver keine Antwort erhalten, werden Sie mit einer Fehlermeldung wie Die Verbindung mit dem Remoteserver kann nicht hergestellt werden konfrontiert. Sie können diese Fehlermeldung aus verschiedenen Gründen erhalten, von denen einige nachfolgend aufgeführt sind:

� Der Webverwaltungsdienst wurde auf dem Remotecomputer nicht gestartet. Wie bereits früher in diesem Kapitel erwähnt wurde, ist der Webverwaltungsdienst dafür zuständig, eingehende Remote-anforderungen entgegenzunehmen. Er muss ausgeführt werden.

� Eine Firewall blockiert die Clientanforderungen. Stellen Sie sicher, dass die Firewall nicht den Port blockiert, den der Webverwaltungsdienst verwendet. Der Dienst nutzt standardmäßig Port 8172 und definiert automatisch eine Windows-Firewallausnahme für diesen Port. Wenn Sie jedoch den Port ändern, müssen Sie selbst eine solche Firewallausnahme definieren.

� Der Client oder Server verwenden unterschiedliche Konfigurationen. Wenn Sie mit einem anderen Port als 8172 arbeiten, geben Sie diesen im Dialogfeld Mit Server verbinden und dort im Textfeld Servername an.

Administration.config und die FeaturedelegierungAdministration.config ist die Datei, die alle Einstellungen für den IIS-Manager und die Remote-verwaltung enthält. Sie verwendet wie das IIS-Konfigurationssystem Konfigurationsabschnitte, um die Einstellungen in logische Einheiten zu unterteilen. Die wichtigsten Abschnitte sind <moduleProviders> und <modules>. Der Abschnitt <moduleProviders> enthält die zentrale Liste der Features, die ein Serveradministrator nutzen kann, wenn er mit dem IIS-Manager arbeitet. Er enthält somit die Liste der Features, die verfügbar sind, wenn eine Serververbindung aktiv ist. Der Abschnitt <modules> enthält die Liste der Module, die für delegierte Verbindungen (Site- und Anwendungsverbindungen) verwendet werden. Wenn ein Feature ausschließlich im Abschnitt <moduleProviders> aufgelistet ist, zeigen nur Serververbindungen dieses Feature an. Soll das Feature allen Sites zur Verfügung stehen, können Sie es innerhalb eines location-Tags mit dem speziellen Pfad "." der <modules>-Liste hinzu-fügen. Der Pfad "." gibt an, dass das Feature von jedem genutzt werden kann. Alternativ hierzu können Sie es im Namen der Site angeben, wenn es nur für diese Site verfügbar sein soll. Die Seite Delegierung von Features modifiziert die <modules>-Liste, wenn Sie den Delegierungszustand ändern. Erwähnenswert ist, dass für Anwendungen die Delegierung in einer anderen administration.config-Datei gespeichert wird, die sich im übergeordneten physikalischen Pfad der Site befindet.



� Die Konfigurationseinstellungen in HTTP.sys sind nicht richtig konfiguriert. Diese Konfiguration wird gesetzt, wenn Sie im IIS-Manager das Feature Verwaltungsdienst verwenden. In diesem Fall müssen Sie sicherstellen, dass die URL-Reservierung und die SSL-Konfiguration richtig registriert sind. Dazu können Sie das Befehlszeilentool Netsh.exe benutzen. Die Ausgabe eines richtig konfigurierten Computers ist nachfolgend dargestellt. Beachten Sie, dass einige Felder Unterschiede aufweisen können, besonders die Felder für den Port und das Zertifikathash.netsh http show urlacl URL-Reservierungen: ------------------- Reservierte URL: https://*:8172/ Benutzer: NT SERVICE\WMSvc Abhören: Yes Delegieren: No SDDL: D:(A;;GX;;;S-1-5-80-257763619-...) netsh http show sslcert SSL-Zertifikatbindungen: ------------------------ IP:Port: 0.0.0.0:8172 Zertifikathash: c2e18a3307cd594079f48870caad5131fe4204f5 Anwendungskennung: {00000000-0000-0000-0000-000000000000} Zertifikatspeichername: MY Clientzertifikatsperre überprüfen: Enabled Sperre nur mithilfe des zwischengespeicherten Zertifikats prüfen: Disabled Verwendungsprüfung: Enabled Sperraktualisierungszeit: 0 URL-Abrufzeitlimit: 0 Steuerelement-ID: (null) Steuerelement-Speichername: (null) DS-Zuordnungsverwendung: Disabled Clientzertifikat aushandeln: Disabled

Wenn die HTTP.sys-Konfiguration nicht korrekt ist, können Sie versuchen, im IIS-Manager das Feature Verwaltungsdienst zu bearbeiten, um das Problem zu beheben. Eine etwas fortgeschrittenere Option besteht darin, Netsh.exe zu verwenden, um die Werte manuell zu konfigurieren.

401 - Nicht autorisiertSie können aus verschiedenen Gründen mit diesem Fehler konfrontiert werden. Einige dieser Gründe sind nachfolgend aufgeführt:� Der Benutzername oder das Kennwort ist ungültig. Wenn ein ungültiger Benutzername oder ein

unzulässiges Kennwort für den Zugriff auf den Webverwaltungsdienst verwendet wird, wird im Sicherheitsprotokoll der Windows-Ereignisanzeige ein entsprechender Eintrag vermerkt. Dieser enthält alle erforderlichen Informationen, wie das folgende Beispiel zeigt:Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: LOCAL SERVICE Kontoname: LOKALER DIENST Kontodomäne: NT AUTHORITY Anmelde-ID: 0x3e5



Anmeldetyp: 8 Konto, für das die Anmeldung fehlgeschlagen ist: Kontoname: Administrator Kontodomäne: CARLOSAG1-IIS Fehlerinformationen: Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort. Status: 0xc000006d Unterstatus: 0xc0000064 Prozessinformationen: Aufrufprozess-ID: 0x8d8 Aufrufprozessname: D:\Windows\System32\inetsrv\WMSvc.exe

� Der delegierte Benutzer, der entweder ein Windows- oder ein IIS-Manager-Benutzer ist, darf auf die Site oder Anwendung nicht zugreifen. In diesem Fall wird dem Windows-Anwendungsprotokoll ein Eintrag mit den folgenden Quellinformationen hinzugefügt: IIS-IISManager und die Ereignis-ID 1105. Diese Daten werden im Windows-Anwendungsprotokoll protokolliert. Der entsprechende Eintrag ist wie folgt aufgebaut:IISWMSVC_AUTHORIZATION_FAILED Der Benutzer 'IisUser1'ist nicht autorisiert für den Pfad '/Default Web Site' Process:WMSvc User=NT AUTHORITY\LOCAL SERVICE

Möchten Sie dieses Problem beheben, können Sie im IIS-Manager zu der betreffenden Site oder Anwendung wechseln und das Feature IIS-Manager-Berechtigungen benutzen, um dem delegierten Benutzer die Berechtigung zum Anmelden zu gewähren.

� Ein delegierter Benutzer versucht, eine Serververbindung herzustellen. Wie bereits erwähnt wurde, können nur Windows-Benutzer mit administrativen Rechten eine Verbindung zum Server herstel-len. Wenn ein delegierter Benutzer versucht, sich mit einem Server zu verbinden, wird ihm dies ver-weigert. In diesem Fall wird dem Windows-Anwendungsprotokoll ein Eintrag mit den folgenden Quellinformationen hinzugefügt: IISManager und die Ereignis-ID 1104. Der Eintrag ist wie folgt aufgebaut:IISWMSVC_AUTHORIZATION_SERVER_NOT_ALLOWED Nur Windows-Administratoren dürfen Verbindungen über eine Serververbindung herstellen. Andere Benutzer müssen die Aufgabe zum Herstellen einer Verbindung mit einer Site oder Anwendung verwenden, um Verbindungen herstellen zu können. Prozess:WMSvc Benutzer=IisUser1

ProtokollierungEs ist hilfreich, die Protokollierungsvorgänge des Webverwaltungsdienstes zu verstehen. Die Protokoll-dateien sind standardmäßig im Ordner %SystemDrive%\Inetpub\Logs\Wmsvc\ gespeichert. Auf der Ebene darunter finden Sie einen Ordner namens W3SVC1, der alle Protokolldateien enthält, die die Aktivität des Webverwaltungsdienstes im Einzelnen erfassen. Eine Protokolldatei verwendet das W3C-Protokolldateiformat (World Wide Web Consortium), um die gesamte Aktivität des Servers zu proto-



kollieren. Dieses Format wird von HTTP.sys verwaltet und ist ein textbasiertes ASCII-Format, das einfach zu lesen und zu verstehen ist. Felder werden durch Leerzeichen voneinander getrennt und Zeitangaben werden im UTC-Format (Universal Coordinated Time) aufgezeichnet. Weitere Informa-tionen zu diesem Format finden Sie im fünfzehnten Kapitel, »Protokollierung«. Tabelle 8.4 zeigt die Liste der Felder, die in einer Protokolldatei für jede vom Dienst verarbeitete Anforderung zur Verfügung stehen.

Sie untersuchen die Protokolldatei am besten mit einem Tool namens Log Parser, das es Ihnen ermög-licht, Abfragen auf einfache Weise und mithilfe einer auf SQL basierenden Syntax durchzuführen. Der folgende Abschnitt erklärt die dazu notwendige Vorgehensweise.

Hinweis Log Parser ist ein Hilfsmittel, das die Abfrage von textbasierten Protokoll-, XML- und CSV-Dateien ermög-licht. Sie können Log Parser herunterladen, indem Sie die Seite http://www.microsoft.com/downloads aufrufen und nach Log Parser suchen. Sie führen Abfragen innerhalb der Log Parser-Eingabeaufforderung durch. Um die Einga-beaufforderung zu öffnen, starten Sie Log Parser aus der gleichnamigen Programmgruppe heraus.

Remoteverwaltungsprotokolle mit Log Parser untersuchenLog Parser ist ein leistungsfähiges Tool, das den Zugriff auf verschiedene Dateiformate ermöglicht und hierfür eine einfache, universelle Abfragesyntax anbietet. Dieser Abschnitt des Kapitels stellt einige nützliche Abfragen vor, die zeigen, wie Log Parser für das Webverwaltungsdienstprotokoll genutzt wird. Alle folgenden Abfragen können mit dem Befehlszeilentool LogParser.exe ausgeführt werden, das ein Bestandteil von Log Parser ist. Benutzen Sie dazu die folgende Syntax:LogParser.exe "<ABFRAGE>" -i W3C

Das Argument -i gibt an, dass als Protokolleingabeformat W3C verwendet wird.

Tabelle 8.4 Felder in der Protokolldatei

Feld Beschreibung

date, time Das Datum und die Uhrzeit der Aktivität im UTC-Format

s-ip Die IP-Adresse des Servers

cs-method Die verwendete HTTP-Methode, z.B. GET oder POST

cs-uri-stem Das Ziel der Aktion; Remoteclientanforderungen verwenden meistens /service.axd als Ziel

cs-uri-query Die Abfrageinformationen für das Ziel; für /service.axd bestehen diese Informationen aus dem verwendeten Modul, der aufgerufenen Methode und, sofern Sie delegierte Verbindungen nutzen, dem Site- und Anwen-dungspfad

s-port Der verwendete Server-Port

cs-username Der Benutzer, der die Anforderung generiert hat

c-ip Die IP-Adresse des Clients

cs(User-Agent) Der Clienttyp zu diesem Aufruf, einschließlich Name und Versionsinformationen

sc-status Der HTTP-Statuscode

sc-substatus Der HTTP-Unterstatuscode

sc-win32-status Der Windows-Statuscode

time-taken Die Zeit, die für die Ausführung der Anforderung benötigt wurde



Übersicht über die Statuscodes Die folgende Abfrage zeigt eine Tabelle an, die alle generierten Statuscodes enthält und Aufschluss darüber gibt, wie oft jeder Statuscodes auftrat:SELECT TOP 25 STRCAT(TO_STRING(sc-status), STRCAT('.', TO_STRING(sc-substatus))) As Status, COUNT(*) AS Hits FROM c:\inetpub\logs\wmsvc\w3svc1\*.log WHERE cs-uri-stem='/Service.axd' GROUP BY Status ORDER BY Status ASC Status Hits ------ ---- 200.0 264 401.1 7 401.2 89 403.6 2

Anzahl der Anforderungen pro Benutzer Die folgende Abfrage zeigt die Anzahl der Anforde-rungen, die von jedem Benutzer initiiert wurden:SELECT TOP 25 cs-username As User, COUNT(*) as Hits FROM c:\inetpub\logs\wmsvc\w3svc1\*.log WHERE User Is Not Null GROUP BY User ORDER BY Hits DESC User Hits -------------- ---- administrator 219 DelegatedUser1 75 IisUser1 19

Häufigkeit der Verwendung eines Moduls Die folgende Abfrage nutzt die Informationen in der Anforderung, um zu ermitteln, wie oft ein Modul verwendet wurde:SELECT TOP 25 EXTRACT_VALUE(cs-uri-query,'Module') as Module, COUNT(*) As Hits FROM d:\inetpub\logs\wmsvc\w3svc1\*.log WHERE Module IS NOT NULL GROUP BY Module ORDER By Hits DESC Module Hits ----------------- ---- Framework 138 WebObjects 90 AppSettings 51 ConnectionStrings 16 ClassicAsp 7

Anzahl der delegierten Aufrufe pro Site Die folgende Abfrage listet die Anzahl der Aufrufe auf, die von delegierten Verbindungen initiiert wurden. Dabei handelt es sich entweder um Site- oder Anwen-dungsverbindungen. Diese werden nach Site gruppiert aufgelistet.SELECT TOP 25 TO_LOWERCASE(EXTRACT_VALUE(cs-uri-query,'Site')) as Site, COUNT(*) As Hits FROM c:\inetpub\logs\wmsvc\w3svc1\*.log WHERE Site IS NOT NULL



GROUP BY Site ORDER By Hits DESC Site Hits -------------------- ---- default%20web%20site 305 delegateduser1site 8

ZusammenfassungIIS 7.0 führt eine neue Remoteverwaltungsarchitektur ein, die es Benutzern ohne administrative Rechte ermöglicht, eine Remoteverbindung zu einem unter Windows Server 2008 ausgeführten IIS 7.0-System herzustellen und dieses zu verwalten. Diese Remoteverwaltung erfolgt über HTTPS, was sowohl über das Internet als auch über das Intranet möglich ist, und sie ist flexibel, weil Windows- und IIS-Manager-Benutzer IIS 7.0 verwalten können. Darüber hinaus kann der Serveradministrator festlegen, mit welchen Features delegierte Benutzer arbeiten dürfen.


� Informationen zur Remoteverwendung von Microsoft.Web.Administration.ServerManager finden Sie unter http://msdn2.microsoft.com/en-us/library/Microsoft.Web.Administration.Servermanager.OpenRemote.aspx.

� Weitere Informationen zum WMI-Anbieter von IIS 7.0 finden Sie unter http://msdn2.microsoft.com/en-us/library/aa347459.aspx.


249

K A P I T E L 9

Verwalten von Websites

Inhalt dieses Kapitels:� Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools . . . . . . . . . . . . . . . . . . . 249

� Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

� Virtuelle Verzeichnisse verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

� Remoteinhalte verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272



Die Website ist der grundlegende Baustein der Funktionalität des IIS-Servers (Internet Information Services). Sie definiert die vom Server zur Verfügung gestellten Inhalte und Dienste und gibt an, wie diese von anfordernden Clients genutzt werden können. IIS 7.0 hält eine Gruppe von Tools für die Erstellung und Verwaltung von Websites bereit, z.B. den IIS-Manager und das Befehlszeilentool Appcmd, und es bietet die Möglichkeit, die Serverkonfiguration direkt oder programmgesteuert über APIs (Application Programming Interface) zu bearbeiten. Obwohl die Verwaltung von Websites unter IIS 7.0 in vielerlei Hinsicht Ähnlichkeiten zur entsprechenden Vorgehensweise bei früheren IIS-Ver-sionen aufweist, zeigt die Benutzeroberfläche des IIS-Managers deutliche Unterschiede. Wenn Sie IIS 7.0-Websites verwalten, sollten Sie verstehen, wie die verbesserte Websitedefinitionsstruktur das Layout Ihrer Anwendungsinhalte beeinflusst und wie die Websitekonfiguration in den IIS 7.0-Konfi-gurationsdateien beschrieben ist.

Websites, Anwendungen, virtuelle Verzeichnisse und AnwendungspoolsWie frühere IIS-Versionen sorgt auch IIS 7.0 dafür, dass der Serveradministrator Anwendungsinhalte auf dem Server bereitstellen kann, indem er Websites, Webanwendungen, Anwendungspools und virtuelle Verzeichnisse erstellt. IIS 7.0 definiert klar erkennbare Beziehungen zwischen diesen Objek-ten, die den Zweck eines Objekts und dessen Laufzeitverhalten präziser ausdrücken. Bei IIS 6.0 kann eine Website beispielsweise mehrere virtuelle Verzeichnisse enthalten, die alle als Anwendungen gekennzeichnet sein können, sofern Sie bestimmte Konfigurationseigenschaften gesetzt haben. Unter IIS 7.0 ist eine Website ein Container für Anwendungen, die wiederum virtuelle Verzeichnisse enthal-ten können. Bei dieser Struktur wird eine Anwendung zu einem übergeordneten Container für Laufzeit-funktionalität und dient als isolierte logische Objekteinheit, die mit einem spezifischen Anwendungs-pool verknüpft ist. Das virtuelle Verzeichnis wird dabei einfach zu einem Mechanismus, der bestimmte Teile des Anwendungs-URL-Namespace (Uniform Resource Locator) einem bestimmten physikali-schen Verzeichnis zuordnet, in dem die Anwendungsinhalte gespeichert sind.


250 Kapitel 9: Verwalten von Websites

Auch IIS 7.0 arbeitet mit Anwendungspools, um die Ausführung von Anwendungen zu isolieren. Lassen Sie uns einen etwas genaueren Blick auf die Objekte für Webanwendunen, Anwendungspools, virtuelle Verzeichnisse und Sites werfen.

WebsitesEine Website ist ein übergeordneter Container für IIS-Inhalte und -Funktionalität. Er enthält Anwen-dungen, die, bezogen auf die Laufzeit, Teile der Website voneinander abgrenzen, und die aus Gründen der Isolation in verschiedenen Anwendungspools angeordnet werden können. Die Anwendungen wiederum definieren virtuelle Verzeichnisse, die den Anwendungs-URL-Namespace unterteilen und diese Teile physikalischen Verzeichnissen zuordnen, in denen sich die Anwendungsinhalte befinden (weitere Informationen zu Anwendungen und virtuellen Verzeichnissen folgen in Kürze).

Die Website legt außerdem Bindungen fest. Dabei handelt es sich um Informationen, die den Verbin-dungsendpunkt beschreiben, der von den Clients verwendet wird, um auf die Website zuzugreifen. Jede Bindung legt das Bindungsprotokoll (z.B. HTTP oder HTTPS) und die protokollspezifische Bindungs-konfiguration fest (z.B. die HTTP-Bindungskonfiguration von IP-Adressen, der Port und Hostheader-details).

Es sind mehrere Bindungen zulässig, so dass der Zugriff auf eine Website von verschiedenen End-punkten aus erfolgen kann, und zwar entweder mit demselben Protokoll oder mit mehreren verschie-denen Protokollen. Bezogen auf das Protokoll können Sie beispielsweise HTTPS für eine sichere Kommunikation und zusätzlich HTTP für den Standardzugriff konfigurieren. Alternativ hierzu können Sie mehrere Websites konfigurieren, indem Sie nur eine IP, aber verschiedene Hostheaderkonfigura-tionen verwenden. Seit der Einführung von WAS (Windows Process Activation Service) in IIS 7.0 können Sie außerdem gehostete Webdienste bereitstellen, wenn Sie mit WCF (Windows Communica-tion Foundation) und Named Pipes, TCP, MSMQ (Message Queuing) oder zusätzlich zu HTTP und HTTPS mit benutzerdefinierten Protokollen arbeiten.

Sie finden später in diesem Kapitel im Abschnitt »Die Bindungen einer Website konfigurieren« weitere Informationen zum Konfigurieren von Websitebindungen.

Direkt von der Quelle: Ein echter AnwendungsserverIIS 6.0 stellt Webanwendungen eine Arbeitsprozessarchitektur für die zuverlässige und sichere Verar-beitung von Anforderungen zur Verfügung. Die W3SVC-Architektur (World Wide Web Publishing Service) von IIS trennt die vom Kernelmodustreiber HTTP.sys durchgeführte Überwachung eingehen-der HTTP-Anforderungen von deren Verarbeitung, die durch die in die IIS-Arbeitsprozesse geladene IIS-Webserverengine erfolgt. Der W3SVC-Dienst ist ebenfalls für die Verwaltung der IIS-Arbeitspro-zesse verantwortlich und erzeugt diese bei Bedarf, damit die von HTTP.sys eingehenden Anforde-rungen verarbeitet werden. Er verwaltet außerdem den Zustand und die Lebensdauer der Arbeitspro-zesse, wodurch die Stabilität und Verfügbarkeit des Webservers gewährleistet wird. Bei IIS 6.0 hat diese Architektur zu einer drastischen Verbesserung der Ausfallsicherheit von Webanwendungen geführt, weil der Anwendungscode von den langlebigen Systemkomponenten isoliert wurde, die dafür zuständig sind, dass die Verfügbarkeit des Servers bei einem Fehler, Speicherverlust und bei Anwen-dungsabstürzen bestehen bleibt.


Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools 251

Die Websitekonfiguration wird in der Datei applicationHost.config und dort im <site>-Element des Konfigurationsabschnitts <sites> deklariert. Die folgende Konfiguration zeigt beispielsweise zwei für den Webserver konfigurierte Websites. Die Site mit der ID 1 ist Contoso Corp zugeordnet und besitzt zwei Bindungen (eine HTTP-Bindung an Port 80 mit http://www.contoso.com als Hostheader sowie ein HTTPS-Protokoll, das über Port 443 verwendet wird). Die Website Fabrikam Inc. hingegen ist an alle IP-Adressen des Webservers gebunden und verwendet den eindeutigen Hostheader http://www.fabri-kam.com.<sites> <site name="Contoso Corp" id="1"> <application path="/"> <virtualDirectory path="/" physicalPath="d:\contoso" /> </application> ... <bindings> <binding protocol="http" bindingInformation="*:80:www.contoso.com" /> <binding protocol="https" bindingInformation="*:443:www.contoso.com" /> </bindings> ... </site> <site name="Fabrikam Inc" id="2"> <application path="/"> <virtualDirectory path="/" physicalPath="d:\fabrikam" /> </application> <bindings> <binding protocol="http" bindingInformation="*:80:www.fabrikam.com" /> </bindings> ...

Bei IIS 7.0 nutzt auch der neue Arbeitsprozessaktivierungsdienst diese Architektur, um ein zuver-lässiges Framework für das Hosten von Webanwendungen zur Verfügung zu stellen. Er geht jedoch noch einen Schritt weiter, weil er diese Architektur verwendet, um nachrichtenorientierte Anwen-dungen unabhängig vom Protokoll zu aktivieren und zu hosten. Der ehemalige Webaktivierungs-dienst ist deshalb nun der Windows-Prozessaktivierungsdienst. Er unterstützt die erweiterbare Listeneradapterarchitektur, mit der Listeneradapterkomponenten Nachrichten über jedes beliebige Protokoll empfangen und Pools von Arbeitsprozessen aktivieren können, wobei diese Prozesse die Anwendungskomponenten hosten, die mit einem Listeneradapter kommunizieren und eingehende Nachrichten verarbeiten können.

Der IIS 7.0-Webserver war das erste Produkt, das diese Architektur verwendet. WCF (Windows Communication Foundation) ist das zweite Produkt und unterstützt das Hosten von Anwendungen unter Verwendung von net.tcp, net.pipe, net.msmq und anderer Protokolle. FTP 7.0, der vom IIS-Team stammende FTP-Server der nächsten Generation, ist das dritte Produkt und er sorgt dafür, dass IIS-Websites mithilfe des FTP-Protokolls zu Publishingendpunkten werden. Wir erwarten, dass bald noch mehr Anwendungen entwickelt werden, die dann die WAS-Architektur (Windows Process Activation Service) nutzen, um betriebssichere Anwendungen über die Protokolle der Zukunft zu hosten.

Mike Volodarsky,




</site> ... <siteDefaults> <logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" /> <traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" /> </siteDefaults> <applicationDefaults applicationPool="DefaultAppPool" /> <virtualDirectoryDefaults allowSubDirConfig="true" /> </sites>

Standardeinstellungen für neue Websites befinden sich im Abschnitt <sites>. Bei der Beispielkonfigura-tion enthält die Websitestandardkonfiguration Einstellungen zur Websiteprotokollierung und zur Ablaufverfolgung für Anforderungsfehler.

Als Nächstes werfen wir einen Blick auf die in der Webseitedefinition enthaltene Konfiguration von Anwendungen und virtuellen Verzeichnissen.

AnwendungenEine Anwendung ist eine Gruppe von Inhalten, Skripts und/oder ausführbaren Dateien, die den Benutzern eine bestimmte Funktionalität bietet. Das Anwendungskonzept ist besonders für Anwendungsframeworks wie ASP oder ASP.NET von Bedeutung, da diese eine Laufzeitausführungsumgebung für die zugehörigen Inhalte erzeugen und gemeinsam genutzte Zustandsdaten bereitstellen können. Bei den vorherigen IIS-Versionen war es möglich, bestimmte virtuelle Verzeichnisse als Anwendungen zu kennzeichnen, um den Anwendungsstamm für die entsprechenden Anwendungsframeworks anzugeben. Davon abgesehen bot IIS keine spezielle Unterstützung von Anwendungen.

IPv6Windows Server 2008 und Windows Vista haben IPv6 standardmäßig aktiviert. Die meisten Server nutzen dieses Protokoll aber noch nicht. Es wird jedoch erwartet, dass IPv6 in den nächsten Jahren zu-sehends mehr Verbreitung findet, da die US-Regierung und das Militär aufgrund der Flexibilität und Sicherheit des Standards für dessen schnelle Einführung sorgen. Sowohl Vista als auch Windows Server 2008 unterstützten IPv6 auf vielen Ebenen, vom Netzwerk bis hin zu verschiedenen Anwen-dungen. IIS 6.0 bietet nur eine begrenzte IPv6-Unterstützung, da Sie eine solche Adresse nicht in den IIS-Manager eingeben können. Würden Sie einer Netzwerkkarte eine IPv6-Adresse zuweisen und für Ihre Website die Standardeinstellung Keine zugewiesen verwenden, würde alles wie erwartet funktionieren. Sie könnten jedoch auch mithilfe von Hostheadern oder eindeutigen Portnummern spezifische IP-Adressen verwenden (andernfalls wären Sie auf eine Website beschränkt). Der IIS 7.0-Manager ermöglicht es Ihnen, eine IPv6-Adresse (z.B. 3ffe:ffff:101:ffff:230:6eff:fe04:d9ff) für Websites einzugeben. Die Eingabe erfolgt genauso wie bei einer IPv4-Adresse, so dass Sie eine Einschränkung wie bei IIS 6.0 nicht mehr befürchten müssen. Dies sind gute Neuigkeiten für die-jenigen, die die vielen neuen Features von IPv6 nutzen möchten.

Unter http://technet.microsoft.com/en-us/network/bb530961.aspx erhalten Sie weitere Informationen.



Bei IIS 7.0 wird die Anwendung innerhalb der Websitestruktur zu einem übergeordneten Container, mit dem es möglich ist, den Rahmen der Anwendungsfunktionalität für die Anwendungsframeworks festzulegen und die jeweilige Anwendung von anderen Anwendungen zu isolieren, indem sie im gewünschten Anwendungspool abgelegt wird. Ein eindeutiger virtueller Pfad identifiziert jede Anwen-dung und dient somit der Unterteilung des Website-URL-Namespace in mehrere Anwendungen.

Die Anwendung selbst enthält virtuelle Verzeichnisse, die Teile des Anwendungs-URL-Namespace physikalischen Verzeichnissen zuordnen, in denen sich die Anwendungsinhalte befinden. Jede Anwen-dung enthält mindestens ein virtuelles Verzeichnis, das als virtuelles Stammverzeichnis bezeichnet wird und das den Stamm des Anwendungs-URL-Namespace dem physikalischen Stammverzeichnis der Anwendung zuordnet. Sie finden später in diesem Kapitel im Abschnitt »Virtuelle Verzeichnisse« weitere Informationen zu virtuellen Verzeichnissen.

Stellen Sie sich den Unterschied zwischen Anwendungen und virtuellen Verzeichnissen wie folgt vor: Eine Anwendung ist eine Gruppe von Inhalten und Diensten, die zusammen innerhalb derselben Aus-führungsumgebung (in einem spezifischen IIS-Arbeitsprozess und vielleicht in einem spezifischen Anwendungsframeworkkontext wie ASP oder ASP .NET) ausgeführt werden. Ein virtuelles Verzeich-nis ist der physikalische Speicherort der Anwendungsinhalte. Es definiert, wo die Inhalte auf dem Datenträger gespeichert sind und wie der Zugriff darauf erfolgen soll.

Der folgende <sites>-Abschnitt aus der applicationHost.config-Datei zeigt, wie die Definitionen von Sites, Anwendungen und virtuellen Verzeichnissen deklariert werden können.<sites> <site name="Contoso Corp" id="1"> <application path="/"> <virtualDirectory path="/" physicalPath="d:\contoso" /> <virtualDirectory path="/images" physicalPath="g:\images" /> </application> <application path="/payment" applicationPool="MyAppPool"> <virtualDirectory path="/" physicalPath="d:\KDbank" /> </application> ... </site> ... </sites>

Jede Anwendung besitzt einen Startpunkt, besser bekannt als Anwendungsstamm. Wenn Sie mit dem IIS-Manager eine neue Website erstellen, erzeugt dieser eine Stammanwendung mit dem virtuellen Pfad /. Die Anwendungsgrenze gilt für jede Datei und für jedes Verzeichnis unterhalb des Stammverzeichnisses, sofern Sie innerhalb der Website nicht einen anderen Anwendungsstartpunkt angeben. Gleichzeitig er-zeugt der IIS-Manager auch für die Anwendung ein virtuelles Stammverzeichnis, dessen virtueller Pfad / ist. Der physikalische Pfad ist das Stammverzeichnis der Website.

Im vorherigen Beispiel ist <application path="/"> der Stammpfad der Anwendung. Innerhalb derselben Konfiguration sind zwei Anwendungen definiert. Das Stammverzeichnis der Website ist durch den Eintrag für das virtuelle Verzeichnis <virtualDirectory path="/" physicalPath="d:\contoso" /> gekennzeichnet. Die zweite Anwendung ist /payment, die mit <virtualDirectory path="/" physicalPath="d:\KDbank" /> definiert ist. Beachten Sie, dass der Anwendungspool MyAppPool die Anwendung payment hostet, wohingegen die Stammanwendung DefaultAppPool verwendet, der in den Standardanwendungspooleinstellungen des Konfigurationsabschnitts <sites> definiert ist. Im nächsten Abschnitt erfahren Sie mehr über Anwen-dungspools.



Virtuelle VerzeichnisseEin virtuelles Verzeichnis ist die Zuordnung eines Teils eines Anwendungs-URL-Namespace zu einem physikalischen Speicherort, in dem sich die entsprechenden Inhalte befinden. Dabei kann es sich um ein Verzeichnis im lokalen Dateisystem oder einen UNC-Pfad (Universal Naming Convention) zu einer Netzwerkfreigabe handeln. Eine Anwendung enthält in der Regel ein virtuelles Stammverzeichnis, das den gesamten URL-Namespace dem entsprechenden physikalischen Speicherortstamm zuordnet. Sie können jedoch zusätzliche virtuelle Verzeichnisse erstellen, um Teile Ihrer Anwendung Ordnern zuzu-ordnen, die sich auf dem lokalen Computer in einem anderen Pfad bzw. auf einem anderen Volume oder sogar in einem nicht lokalen, freigegebenen Netzwerkordner befinden. Darüber hinaus kann jedes virtuelle Verzeichnis die Anmeldeinformationen festlegen, die für den Zugriff auf seine Inhalte verwendet werden sollen.

Wenn Sie beispielsweise eine Intranetwebsite für die Finanzabteilung entwickeln, müssen Sie nicht alle Standardbilddateien des Unternehmens von der Unternehmenswebsite in die neue Website kopieren. Sie können stattdessen in der Finanzwebsite ein neues virtuelles Verzeichnis erstellen und dieses dem physikalischen Ordner zuordnen, der sich auf dem Server der Unternehmenswebsite befindet und die Bilddateien enthält.

Bei IIS 7.0 muss jede Website eine Stammanwendung enthalten, und jede Anwendung muss ein virtu-elles Stammverzeichnis enthalten. Dies bedeutet, dass jede Website über ein virtuelles Stammverzeich-nis verfügt, das auf das physikalische Stammverzeichnis der Website verweist. Sie können zusätzliche virtuelle Verzeichnisse oder zusätzliche Anwendungen mit virtuellen Verzeichnissen hinzufügen. Die virtuellen Verzeichnisse werden in der applicationHost.config-Konfigurationsdatei und dort in der <site>-Konfigurationsauflistung als Children der jeweiligen Anwendung angelegt.

Hinweis Im Gegensatz zu IIS 6.0 sind virtuelle Verzeichnisse immer in Anwendungen enthalten. Darüber hinaus können virtuelle Verzeichnisse nicht mit Anwendungspools verknüpft werden. Dies ist nur mit Anwendungen mög-lich. Dies zeigt einmal mehr, dass die Anwendung der Laufzeitcontainer für die Funktionalität der Website ist, und das virtuelle Verzeichnis ist der physikalische Speicherort für die Anwendungsinhalte.

Lassen Sie uns zum vorherigen Beispiel zurückkehren, wo sich in der Contoso Corp.-Website zwei Anwendungen befinden. Jede Anwendung enthält einen Satz virtuelle Verzeichnisse, die Teile der Anwendung den physikalischen Speicherorten zuordnen, in denen sich die Inhalte befindet, die im Rahmen der Anwendung bereitgestellt werden. Beachten Sie das virtuelle Verzeichnis /images in der Stammanwendung der Website. Es ist so für die Website konfiguriert, dass es auf Dateien außerhalb des Webanwendungsstamms verweist.

Später in diesem Kapitel hält der Abschnitt »Virtuelle Verzeichnisse verwalten« eine ausführliche Erläuterung von virtuellen Verzeichnissen bereit.

AnwendungspoolsDas Anwendungspoolkonzept wurde erstmals mit IIS 6.0 eingeführt. Ein Anwendungspool verwendet einen separaten IIS-Arbeitsprozess (W3WP.exe), um die Anforderungen zu verarbeiten, die sich auf die mit dem Anwendungspool verknüpften Webanwendungen beziehen. Anwendungspools dienen als Grenze zwischen den IIS 7.0-Anwendungen, wobei alle IIS-Features und Anwendungslaufzeitum-gebungen in einem separaten IIS-Arbeitsprozess gehostet werden. Dabei kümmert sich der Arbeits-



prozess um die Anwendungsanforderungsverarbeitung. Jeder IIS-Arbeitsprozess ist von anderen Arbeitsprozessen unabhängig, was bedeutet, dass jeder Prozess eine eigene Prozess-ID, einen eigenen Arbeitsspeicherbereich und eine eigene Lebensdauer besitzt.

Anwendungen, die in verschiedenen Arbeitsprozessen ausgeführt werden, sind voneinander isoliert, so dass sich der Absturz eines Arbeitsprozesses in der Regel nicht auf den Betrieb der anderen Prozesse auswirkt. Dies verbessert die Stabilität und Verfügbarkeit von Anwendungen, da fehlerhafte Programme andere, auf demselben IIS-Server ausgeführte Anwendungen nicht beeinflussen.

Außerdem kann ein Anwendungspool als Sicherheitsandbox dienen, so dass verschiedene Anwen-dungen in IIS-Arbeitsprozessen ausgeführt werden können, die unter verschiedenen Anwendungspool-identitäten gestartet wurden. Aus diesem Grund können Sie Anwendungen isolieren, indem Sie den der jeweiligen Anwendungspoolidentität gewährten Zugriff auf die entsprechenden Anwendungsinhalte und Serverressourcen kontrollieren. Auf diese Weise werden die Anwendungen im jeweiligen Anwen-dungspool zur Laufzeit in separaten Speicherbereichen isoliert und die entsprechenden Anwendungs-ressourcen auf dem Server werden mithilfe von Windows-ACLs (Access Control List) voneinander isoliert.

Hinweis Die Anwendungspoolisolation in Kombination mit der richtigen Ressourcenzugriffskontrolle ist der einzige zuverlässige Mechanismus, um mehrere auf dem Server ausgeführte Anwendungen voneinander zu isolieren. Weitere Informationen zur Konfiguration der Anwendungspoolisolation finden Sie im vierzehnten Kapitel, »Imple-mentieren von Sicherheitsstrategien«.

Wenn Sie im IIS-Manager eine Website erstellen, wird automatisch ein neuer Anwendungspool erzeugt und die Stammanwendung der Site wird für die Ausführung in diesem Pool konfiguriert. Wenn Sie eine Site programmgesteuert erstellen, müssen Sie jeder Anwendung der Site den gewünschten Anwendungs-pool explizit zuweisen (andernfalls wird der als Standard konfigurierte Anwendungspool verwendet). Sie können einen Anwendungspool ebenfalls manuell erstellen, sofern Sie möchten, dass bestimmte Anwen-dungen in diesem Pool ausgeführt werden.

Darüber hinaus können Sie verschiedene Laufzeiteinstellungen für einen Anwendungspool festlegen, die die Ausführung der Anforderungen betreffen, die sich auf die im Pool gehosteten Anwendungen beziehen. Einige dieser Einstellungen sind nachfolgend aufgeführt:

� Die .NET Framework-Version, die angibt, welche Version der CLR (Common Language Runtime) in den IIS-Arbeitsprozess geladen wurde und welche ASP.NET-Version somit für die ASP.NET-Anwendungen im Anwendungspool verwendet wird.

� Der ASP.NET-Integrationsmodus (Integriert [Standard] oder Klassisch). Wirkt sich auf die Arbeits-weise von ASP.NET-Anwendungen in diesem Anwendungspool aus.

� Die Bitness des Anwendungspools bei 64-Bit-Betriebssystemen. Wirkt sich darauf aus, ob dieser Anwendungspool unter Verwendung des SYSWOW64-Emulationsmodus native 64-Bit-Kompo-nenten oder gewöhnliche 32-Bit-Komponenten lädt.

Bei IIS 7.0 ist somit die Auswahl eines richtig konfigurierten Anwendungspools für die Definition des korrekten Laufzeitverhaltens von Webanwendungen sehr wichtig.

Anwendungspools werden im zehnten Kapitel, »Verwalten von Anwendungen und Anwendungspools« ausführlich erläutert.



VerwaltungsaufgabenBei der Installation von IIS wird eine Website namens Default Web Site erstellt, die eine einzelne Stammanwendung enthält, deren virtuelles Stammverzeichnis dem Ordner %systemdrive%\inetpub\ wwwroot zugeordnet ist. Sie können diese Standardwebsite so konfigurieren, dass sie Ihre Webanwen-dung bereitstellt, oder Sie generieren eine neue Website, um die Anwendung zu veröffentlichen.

Hinweis Sie sollten Ihre Webinhalte auf einem Laufwerk ablegen, das nicht das Systemlaufwerk ist.

Für die typischen IIS 6.0-Verwaltungsaufgaben stehen die von der IIS 6.0-Verwaltungskonsole ange-botenen Assistenten zur Verfügung. Unter IIS 7.0 können Sie die IIS-Manager-Konsole benutzen, um Websites zu erstellen und zu verwalten.

Darüber hinaus können Sie das Befehlszeilentool Appcmd.exe verwenden, um von der Befehlszeile aus eine Website und die zugehörige Konfiguration zu verwalten. Sie können außerdem eine der zahlreichen programmatischen APIs für die Verwaltung der IIS-Konfiguration benutzen, z.B. Microsoft Web Administration oder WMI (Windows Management Instrumentation), oder Sie bearbeiten direkt die Serverkonfigurationsdateien, z.B. applicationHost.config oder web.config. Beachten Sie jedoch, dass die direkte Bearbeitung der Konfigurationsdateien nicht empfohlen wird.

Hinweis IIS 7.0 unterstützt auch weiterhin die alten IIS 6.0-Konfigurationsskripts, zu denen ADSUTIL.VBS, IIS-WEB.VBS, IISVDIR.VBS und andere zählen. Diese Skripts werden ausschließlich aus Gründen der Kompatibilität angeboten und erfordern die Installation der IIS 6.0-Kompatibilitätskomponenten. Es wird dringend empfohlen, dass Sie das neue Befehlszeilentool Appcmd.exe oder die programmatischen APIs einsetzen, um die IIS-Konfiguration zu verwalten, da die alten Tools in bestimmten Fällen zu einer nicht beabsichtigten Konfiguration führen können. Der Grund hierfür besteht darin, dass sie für das neue Konfigurationssystem nicht optimiert wurden.

In diesem Abschnitt des Kapitels lernen Sie einige übliche administrativen Aufgaben für die Verwal-tung von IIS-Websites kennen, für deren Bearbeitung sowohl der IIS-Manager als auch Appcmd verwendet wird. Auch die Änderungen, die sich dadurch an den Konfigurationsdateien ergeben, werden präsentiert.

Eine neue Website hinzufügenSie können mit IIS 7.0 neue Webistes erstellen, um Ihre Webanwendungen und -dienste zu veröffent-lichen. Bevor Sie eine neue Website erstellen, sollten Sie darüber nachdenken, wie der Zugriff darauf erfolgen soll. Dazu legen Sie die IP-Adressen, Ports und (optional) die Hostheader fest, die für den Empfang von Anforderungen für die Site verwendet werden sollen. Sie nutzen diese Informationen, um die Protokollbindungen für die Website zu konfigurieren.

Bei IIS 7.0 dient jede Website als logischer Container für Webanwendungen und virtuelle Verzeich-nisse. Wenn Sie mit IIS 7.0 eine neue Website hinzufügen, erzeugt IIS vier verschiedene Objekte:

� Eine Website, die den Sitenamen, die ID, Bindungen und (optional) weitere Einstellungen definiert

� Eine Stammanwendung

� Ein virtuelles Stammverzeichnis für die Stammanwendung, wobei der URL-Namespace / dem physikalischen Stammverzeichnis der Website zugeordnet wird

� Einen Anwendungspool (sofern Sie mit dem IIS-Manager arbeiten), der die Stammanwendung der Website hostet (sofern Sie nicht selbst einen der bereits vorhandenen Anwendungspools auswählen)


Verwaltungsaufgaben 257

Wichtig Um die Sicherheit aufrechtzuerhalten, sollten Sie sich unter Verwendung eines Kontos, das nicht über administrative Rechte verfügt, an Ihren Computer anmelden. Benutzen Sie anschließend den Runas-Befehl, um den IIS-Manager als Administrator auszuführen. Nehmen Sie an der Eingabeaufforderung beispielsweise die folgende Eingabe vor:runas /user:<admin_acct> "%windir%\system32\inetsrv\inetmgr.exe"

Um mit dem IIS-Manager eine Website zu erstellen, erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers. Klicken Sie innerhalb der hierarchischen Struktur mit der rechten Maustaste auf den Knoten Sites, und wählen Sie anschließend Website hinzufügen aus. Das Ergebnis ist in Abbildung 9.1 dargestellt.

Abbildung 9.1 Eine Website mit dem IIS-Manager hinzufügen

Das Dialogfeld Website hinzufügen ermöglicht es Ihnen, eine neue Website zu erstellen. Dazu geben Sie alle grundlegenden Informationen an, die zur Erstellung der Website benötigt werden: eine einzelne Bildung, die Stammanwendung, das virtuelle Stammverzeichnis und standardmäßig einen neuen Anwendungspool, der die Anwendung hostet. Sie können ebenfalls bestimmte Anmeldeinformationen festlegen, die für den Zugriff auf die Siteinhalte im virtuellen Stammverzeichnis verwendet werden sollen. Weitere Informationen zur Erstellung und Verwaltung virtueller Verzeichnisse finden Sie später in diesem Kapitel im Abschnitt »Virtuelle Verzeichnisse verwalten«.

Möchten Sie zusätzliche Modifizierungen an den Websiteeinstellungen vornehmen, können Sie fest-legen, dass die neue Website nicht sofort gestartet werden soll. Sie wird dann im beendeten Zustand belassen, so dass Sie zusätzliche Konfigurationen vornehmen können, bevor Sie die Site später manuell starten. Weitere Informationen zum Starten und Beenden von Websites finden Sie später in diesem Kapitel im Abschnitt »Websites starten und beenden«.

Sie können ebenfalls den folgenden Appcmd-Befehl benutzen, um eine neue Website hinzuzufügen.appcmd add site /name:string /id:uint /bindings:string /physicalPath:string

Tabelle 9.1 beschreibt die Parameter dieses Befehls.



Hinweis Wenn Sie den vollständigen Pfad %windir%\system32\inetsrv\appcmd.exe angeben, können Sie die Beispiele von jedem beliebigen Pfad aus nachvollziehen, ohne das Verzeichnis wechseln zu müssen.

Das folgende Beispiel erstellt eine neue Website mit der ID 9, dem Sitenamen Fabrikam HR (für die Personalabteilung – engl. Human Resources – des fiktiven Unternehmens Fabrikam), hr.fabrikam.com als Hostheader Wert und dem HTTP-Standardport als Zugriffsport. Der Stammpfad der Website wird dem physikalischen Ordner d:\fabrikamHR zugeordnet.appcmd add site /name:"Fabrikam HR" /id:9 /bindings:http/*:80:hr.fabrikam.com /physicalPath:"d:\fabrikamHR"


Beachten Sie die Befehlsausgabe, die zeigt, dass drei verschiedene Objekte erstellt wurden (für die Site, die Anwendung und das virtuelle Verzeichnis). Wenn Sie hingegen mit dem IIS-Manager arbeiten, werden vier Objekte erstellt, da der IIS-Manager standardmäßig eine neue Anwendung für die neue Website erzeugt. Der Grund hierfür besteht darin, dass physicalPath angegeben wurde, und IIS generiert die Stamm-anwendung immer zusammen mit der Definition des virtuellen Stammverzeichnisses der Website.Das SITE-Objekt "Fabrikam HR/" wurde hinzugefügt Das APP-Objekt "Fabrikam HR/" wurde hinzugefügt Das VDIR-Objekt "Fabrikam HR/" wurde hinzugefügt

Tabelle 9.1 Appcmd-Syntax zum Hinzufügen einer Website


name Dieses Feld muss mindestens angegeben werden. string repräsentiert den Anzeigenamen der Website.

Wenn IIS im Wert des Elementattributs /name oder /id einen Fehler aufgrund eines doppelten Vorkommens entdeckt, schlägt der Befehl fehl, und die Website wird nicht erstellt.

id Eine vorzeichenlose Ganzzahl, die die Website-ID angibt. Wenn dieser Wert nicht angegeben wird, ermittelt IIS 7.0 die höchste ID der bereits vorhandenen Websites, addiert diese mit 1 und verwendet das Ergebnis als ID für die neue Website.

Wenn IIS im Wert des Elementattributs /name oder /id einen Fehler aufgrund eines doppelten Vorkommens entdeckt, schlägt der Befehl fehl, und die Website wird nicht erstellt.

bindings Eine Liste der Bindungszeichenfolgen, die durch Doppelpunkte voneinander getrennt angegeben werden. Dazu zählen das Protokoll und die zugehörigen Bindungsinformationen. HTTP- und HTTPS-Bindungsinforma-tionen enthalten die IP-Adresse, den Port und den Hostheader. Jede Bindungszeichenfolge wird im Format [protocol]/[bindingInformation] angegeben, wobei [bindingInformation] für die Protokolle HTTP und HTTPS das Format [ip|*]:[port]:[host header] aufweist. http/*:80:www.contoso.com gibt beispielsweise an, dass der Host-headername der Website http://www.contoso.com lautet und dass die Site an alle IP-Adressen und Port 80 gebunden ist.

physicalPath Repräsentiert den Stammanwendungspfad der Website. Der Pfad kann sich auf dem lokalen Computer befinden, z.B. d:\fabrikamhr, oder auf einem Remoteserver, zum Beispiel \\remoteserver\share. Sie können für einen freigegebenen Remoteserver ein eigenes Verbindungsbenutzerkonto festlegen, das über die ent-sprechenden Zugriffsrechte für den freigegebenen Remoteordner verfügt.Wenn physicalPath nicht angegeben wird, werden die Stammanwendung und das virtuelle Stammverzeichnis nicht automatisch erstellt und müssen später manuell hinzugefügt werden.



Wenn Sie wie im folgenden Beispiel physicalPath nicht angeben, wird nur das Siteobjekt erstellt, weil IIS nicht über genügend Informationen verfügt, um die zugehörige Anwendung und das virtuelle Verzeich-nis zu erzeugen. Deshalb wird die Website zwar erstellt, aber nicht gestartet, was erst möglich ist, wenn Sie physicalPath konfigurieren.appcmd add site /name:"Fabrikam Finance" /bindings:http/*:80/finance.fabrikam.com

Vorsicht Wenn Sie mit Appcmd eine neue Website generieren, ohne Bindungsinformationen oder physicalPath anzugeben, wird die Website erstellt, aber Sie können sie nicht starten.

Nachfolgend ist das <site>-Element der Fabrikam HR-Website zu sehen, die wie im ersten Beispiel dieses Abschnitts mit Appcmd erzeugt wurde.<sites> ... <site name="Fabrikam HR" id="9"> <application path="/"> <virtualDirectory path="/" physicalPath="d:\fabrikamHR" /> </application> <bindings> <binding protocol="http" bindingInformation="*:80:hr.fabrikam.com" /> </bindings> </site> ... </sites>

Die Bindungen einer Website konfigurierenWebsitebindungen legen protokollspezifische Endpunkte fest, an denen die auf die jeweilige Website bezogenen Anforderungen empfangen werden. Jede Bindung definiert das Protokoll und die proto-kollspezifischen Bindungsinformationen.

Hinweis Server, die zusätzliche Protokolle unterstützen, zum Beispiel net.tcp von WCF (Windows Communication Foundation) und ftp von FTP 7.0, können unter Verwendung dieser Protokolle Bindungen einrichten. Lesen Sie die Dokumentationen zu diesen Produkten, um die vom jeweiligen Protokoll verwendeten Bindungsinformationen in Erfahrung zu bringen.

IIS-Websites enthalten in der Regel Bindungen, die mit den Protokollen HTTP oder HTTPS arbeiten. Diese Bindungen legen Endpunktinformationen fest, die die IP-Adresse, die Portnummer und (sofern vorhanden) den Hostheader bestimmen. An diese Elemente wird die Website beim Start gebunden. Dadurch wird es möglich, dass IIS-Websites unter Verwendung der folgenden Konfigurationen gehostet werden können:

� Eine Website, die alle verfügbaren Netzwerkschnittstellen und einen bestimmten Port überwacht

� Eine Website, die eine bestimmte Netzwerkschnittstelle/IP-Adresse und einen bestimmten Port überwacht. Dies kann nützlich sein, wenn der Zugriff auf eine Website auf die Clients eines bestimmten Netzwerks, z.B. ein internes Netzwerk oder localhost, beschränkt werden soll.

� Eine Website, die einen bestimmten Port und einen bestimmten Hostheader überwacht



Darüber hinaus ist es möglich, auf demselben Server mehrere Websites zu hosten, indem Bindungen verwendet werden, die unterschiedliche Ports, IP-Adressen oder Hostheader zur Unterscheidung der Sites nutzen. Nachfolgend sind verschiedene Möglichkeiten für mehrere Websitebindungen genannt:

� Mehrere Websites, die verschiedene Ports überwachen

� Mehrere Websites, die denselben Port, aber verschiedene Netzwerkschnittstellen/IP-Adressen überwachen. Dies kann z.B. geschehen, damit über interne und externe IP-Adressen des Servers auf verschiedene Websites zugegriffen werden kann. Sie können diese Technik ebenfalls verwenden, um mehrere Websites zu hosten, wenn jede Website eigene, an die Netzwerkschnittstellen des Servers gebundene IP-Adressen besitzt.

� Mehrere Websites, die denselben Port und dieselben Netzwerkschnittstellen/IP-Adressen, aber unterschiedliche Hostheader überwachen. Dieses Verfahren wird meistens verwendet, um mehrere öffentliche Websites zu hosten. Darüber hinaus nutzen Shared Webhostingserver diese Technik.

Hinweis Seien Sie vorsichtig, wenn Sie für die Liste der Netzwerkschnittstellen einer HTTP- oder HTTPS-Sitebin-dung Keine zugewiesen oder * verwenden. Dies führt zu einer Konfiguration, die dafür sorgt, dass die Bindung alle Netzwerkschnittstellen überwacht, die noch nicht von anderen Bindungen genutzt werden. Die von der Bindung überwachten Netzwerkschnittstellen sind somit davon abhängig, welche anderen gegenwärtig aktiven Sites mit Bindungen arbeiten, die denselben Port in Verbindung mit den Netzwerkschnittstellen des Servers nutzen. Um vorhersehbare Ergebnisse zu erhalten, sollten Sie darüber nachdenken, die Liste der Adressen anzugeben, mit denen die jeweilige Bindung arbeiten soll.

Um schließlich durch eine Kombination dieser Konfigurationen die gewünschten Zugriffsmöglich-keiten zu erhalten, können Sie für jede Site mehrere Bindungen verwenden.

Hinweis Wenn jede Website ein separates SSL-Zertifikat (Secure Sockets Layer) erfordert, ist es nicht möglich, mehrere Websites zu hosten, die Hostheader am selben Port/an derselben Netzwerkschnittstelle verwenden. Weitere Informationen erhalten Sie im vierzehnten Kapitel.

Bei IIS 7.0 können Sie den IIS-Manager benutzen, um Bindungsinformationen über den Link Bin-dungen im Bereich Aktionen zu konfigurieren. Mit IIS 7.0 können Sie für eine Website andere Proto-kollbindungen als HTTP und HTTPS angeben. Es ist aber nicht mehr möglich, einen Unterstrich (_) im Hostheadernamen zu benutzen.

Um mit dem IIS-Manager für eine Website bereits vorhandene Bindungen zu ändern oder neue Bindungen zu konfigurieren, erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers. Erweitern Sie anschließend auch den Knoten Sites. Markieren Sie in der hierarchischen Sites-Struktur die Website, die Sie verwalten möchten, und klicken Sie im Bereich Aktionen auf den Link Bindungen. Das Ergebnis ist in Abbildung 9.2 zu sehen. Markieren Sie die gewünschte Bindungskonfiguration und klicken Sie auf Bearbeiten. Klicken Sie alternativ hierzu auf Entfernen, um die Bindung zu löschen.

Hinweis Wenn Sie eine HTTPS-Bindung konfigurieren, müssen Sie das SSL-Zertifikat für die Bindung auswählen, wobei die möglichen SSL-Zertifikate bereits installiert sein müssen. Wenn Sie die Bindungsinformationen einer Website bearbeiten, können Sie die Zertifikatinformationen einsehen, indem Sie im Dialogfeld Sitebindung hinzu-fügen auf die Schaltfläche Anzeigen klicken. Weitere Informationen zur Konfiguration von SSL unter IIS 7.0 finden Sie im vierzehnten Kapitel.



Abbildung 9.2 Websitebindungen mit dem IIS-Manager konfigurieren

Benutzen Sie die folgende Appcmd-Syntax, um die Bindungen einer bestimmten Website anzeigen zu lassen.appcmd list site SiteName

Um die Bindungen einer Website zu konfigurieren, verwenden Sie den folgenden Befehl.appcmd set site SiteName /bindings:string


Hinweis Weitere Informationen zur Verwendung von Appcmd, um Bindungen und das Bindungsformat festzu-legen, finden Sie im siebten Kapitel, »Verwenden von Befehlszeilentools«.

Die folgende Syntax listet detaillierte Informationen zur Fabrikam HR-Website auf. Dazu zählen auch die Bindungsinformationen.appcmd list site "Fabrikam HR"

Wie der folgende Code zeigt, gibt die Ausgabe Aufschluss darüber, dass die Fabrikam HR-Website an das HTTP-Protokoll, Port 80, alle IP-Adressen (*) sowie den Hostheaderwert hr.fabrikam.com gebunden ist:SITE "Fabrikam HR" (id:9,bindings:http/*:80:hr.fabrikam.com,state:started)

Um myhr.fabrikam.com zusätzlich zu hr.fabrikam.com als neuen Hostheader zu konfigurieren, verwenden Sie die folgende Syntax:appcmd set site "Fabrikam HR" /+bindings.[protocol='http',bindingInformation='*:80:myhr.fabrikam.com']

Tabelle 9.2 Appcmd-Syntax zum Festlegen von Bindungen


SiteName Der Anzeigename der Website

bindings Eine Liste der Bindungszeichenfolgen, die durch Doppelpunkte voneinander getrennt angegeben werden. Dazu zählen das Protokoll und die zugehörigen Bindungsinformationen. HTTP- und HTTPS-Bindungs-informationen enthalten die IP-Adresse, den Port und den Hostheader. Jede Bindungszeichenfolge wird im Format [protocol]/[bindingInformation] angegeben, wobei [bindingInformation] für die Protokolle HTTP und HTTPS das Format [ip|*]:[port]:[host header] aufweist. Der Hostheaderwert kann ausgelassen werden, wenn kein spezifischer Hostheader angegeben werden soll.

Die Bindungsliste ersetzt den aktuellen Bindungssatz der Site.



Die voranstehende Syntax fügt am Ende der bereits vorhandenen Fabrikam-Bindungsinformationen eine weitere Bindung hinzu, die einen neuen Hostheader, das HTTP-Protokoll, alle IP-Adressen und Port 80 festlegt. Wenn Sie mit Blick auf das vorherige Beispiel die bereits vorhandenen Bindungs-informationen ändern möchten, so dass aus myhr.fabrikam.com askhr.fabrikam.com wird, können Sie die folgende Syntax benutzen:appcmd set site "Fabrikam HR" /bindings.[bindingInformation=’*:80:myhr.fabrikam.com’].bindingInformation:*:80:askhr. fabrikam.com

Die Bindungen einer Website werden in deren <site>-Element gespeichert. Nachfolgend ist das <site>-Element in der applicationHost.config-Datei zu sehen, nachdem die vorherigen Appcmd-Beispiele ausgeführt wurden:<sites> ... <site name="Fabrikam HR" id="9"> <application path="/"> <virtualDirectory path="/" physicalPath="d:\fabrikamHR" /> </application> <bindings> <binding protocol="http" bindingInformation="*:80:hr.fabrikam.com" /> <binding protocol="http" bindingInformation="*:80:askhr.fabrikam.com" /> </bindings> </site> ... </sites>

Die Websiteverwendung einschränkenSie können wie bei früheren IIS-Versionen Websiteeinschränkungen konfigurieren, wie z.B. die maxi-mal verfügbare Bandbreite, die maximale Anzahl gleichzeitiger Verbindungen und den Verbindungs-timeout. Sie können auf diese Möglichkeiten zurückgreifen, um dafür zu sorgen, dass die Websites weniger intensiv genutzt werden oder dass einige Websites eine größere Anzahl gleichzeitiger Verbin-dungen und/oder eine größere Bandbreite als andere Sites nutzen können. Sie können drei Einschrän-kungen konfigurieren:

� Nutzung der Bandbreite (maxBandwidth)

� Maximale Anzahl gleichzeitiger Verbindungen (maxConnections)

� Verbindungstimeout (connectionTimeout)

Die Bandbreitenbegrenzung legt für die Website die nutzbare Netzwerkbandbreite fest, die niemals überschritten werden darf. Der Kerneltreiber HTTP.sys sorgt für eine dynamische Bandbreitendrosse-lung. Bei IIS 6.0 wird die Drosselung in Kilobytes pro Sekunde (Kbps) angegeben. Bei IIS 7.0 erfolgt die Angabe in Bytes pro Sekunde. Dabei gilt ein Mindestwert von 1024 Bytes pro Sekunde. Wenn die Drosselung aktiviert ist, hält sich HTTP.sys an den konfigurierten Grenzwert und stellt sicher, dass die Site das angegebene Bandbreitenlimit niemals überschreitet.



Wichtig IIS gewährleistet keine präzise Bandbreitenbegrenzung für einzelne, auf die jeweilige Website bezogene Verbindungen oder Anforderungen. Es stellt lediglich sicher, dass die Bandbreitennutzung den konfigurierten Grenzwert insgesamt nicht überschreitet.

Der Verbindungsgrenzwert legt die maximale Anzahl von gleichzeitigen Verbindungen fest, die für eine bestimmte Website zulässig sind. Wenn Sie die Anzahl der Verbindungen zu einer Website einschrän-ken, bedeutet dies eine Einsparung von Systemressourcen. Sie könnten beispielsweise für eine Website mit einer niedrigen Priorität die Anzahl der Verbindungen begrenzen, so dass dem System mehr Verbin-dungen oder Ressourcen für Websites mit einer hohen Priorität oder für ausgelastete Websites zur Verfügung stünden. Wenn IIS den für eine Website konfigurierten Verbindungsgrenzwert erreicht, sendet es die HTTP 503-Fehlermeldung zum Clientbrowser, die Aufschluss darüber gibt, dass der Dienst nicht verfügbar ist. Darüber hinaus fügt IIS dem HTTP-Fehlerprotokoll (httperr*.log unter %windir%\system32\logfiles\httperr\) einen ConnLimit-Eintrag hinzu.

Der Verbindungstimeout legt die Zeit fest, die vergehen muss, bis IIS eine inaktive Benutzerverbindung trennt. Durch das Schließen nicht belegter oder ungültiger Verbindungen bzw. von Verbindungen, die sich im Leerlauf befinden, sorgt IIS dafür, dass eine größere Zahl zulässiger Benutzerverbindungen möglich ist und dass diesen mehr Ports zur Verfügung stehen. Der Verbindungstimeout ist standard-mäßig auf 120 Sekunden gesetzt.

Sie können im IIS-Manager mit nur einem Dialogfeld alle drei Einschränkungen gleichzeitig festlegen. Um mit dem IIS-Manager für eine bestimmte Website die Anzahl der gleichzeitigen Verbindungen und die Bandbreite zu begrenzen, erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers und danach den Knoten Sites. Markieren Sie in der hierarchischen Sites-Struktur die Website, deren Einstellungen Sie ändern möchten und klicken Sie im Bereich Aktionen auf den Link Limits. Das Ergebnis ist in Abbildung 9.3 zu sehen.

Abbildung 9.3 Die Websiteverwendung mit dem IIS-Manager einschränken

Benutzen Sie den folgenden Appcmd-Befehl, um den Verbindungsgrenzwert und die Bandbreitendrosselung einer Website anzeigen zu lassen oder zu konfigurieren:appcmd set site SiteName /limits.connectionTimeout:integer /limits.maxBandwidth:integer /limits.maxConnections:integer




Da sich die Einstellungen zu den Websiteeinschränkungen auf ein <site>-Element beziehen, können Sie nicht Appcmd verwenden, um bestimmte Elementwerte auflisten zu lassen. Stattdessen müssen Sie das <site>-Element der Website detailliert auflisten und die Werte mit dem /config-Parameter untersuchen. Der folgende Befehl fragt die Fabrikam HR-Websitedetails ab:appcmd list site /site.name:"Fabrikam HR" /config

Beachten Sie bei der Ausgabe, dass der Verbindungsgrenzwert und die Bandbreitendrosselung der Website im <limits>-Element des <site>-Elements definiert sind. Die folgende Syntax schränkt die Fabrikam HR-Website dahingehend ein, dass sie maximal 500 Verbindungen unterstützt und eine Bandbreite von 10 MB nicht überschreiten darf:appcmd set site "Fabrikam HR" /limits.maxBandwidth:10485760 /limits.maxConnections:500

Nachfolgend ist das <limits>-Element zu sehen, dessen Attribute maxBandwidth und maxConnections unter Verwendung der vorherigen Syntax konfiguriert wurden:<sites> ... <site name="Fabrikam HR" id="9"> <application path="/"> <virtualDirectory path="/" physicalPath="d:\fabrikamHR" /> </application> <bindings> <binding protocol="http" bindingInformation="*:80:hr.fabrikam.com" /> <binding protocol="http" bindingInformation="*:80:askhr.fabrikam.com" /> </bindings> <limits maxBandwidth="10485760" maxConnections="500" /> </site> ... </sites>

Die Websiteprotokollierung und Ablaufverfolgung für Anforderungsfehler konfigurierenNachdem eine Website erstellt wurde, können Sie festlegen, wie die auf diese Website bezogenen Anforderungen protokolliert werden sollen. Dazu können Sie das Protokollierungsformat, den Speicherort der Protokolldateien und einen Zeitplan für die Erstellung von Protokolldateien auswählen. Sie können die Protokollierungseinstellungen ändern, indem Sie die Website im Hierarchielistenfeld

Tabelle 9.3 Appcmd-Syntax zum Festlegen des Verbindungsgrenzwertes und der Bandbreitendrosselung


SiteName Der Anzeigename der Website

limits.connectionTimeout integer legt den HTTP-Verbindungstimeoutwert im Zeitspannenformat (hh:mm:ss) fest. 00:02:00 ist beispielsweise der Standardwert von 2 Minuten.

limits.maxBandwidth integer legt die Bandbreitendrosselung für die Website in Bytes fest. Der Wert muss eine Ganzzahl zwischen 1024 und 214783647 sein.

limits.maxConnections integer legt die maximale Anzahl gleichzeitiger Verbindungen zur Website fest. Der Wert muss eine Ganzzahl zwischen 0 und 4294967295 sein.



markieren und im Featurehauptbereich einen Doppelklick auf dem Symbol des Features Protokol-lierung ausführen. Im fünfzehnten Kapitel, »Protokollierung«, erfahren Sie mehr über die Konfiguration und Verwendung von Anforderungsprotokollen.

Wenn Sie außerdem Hilfe bei der Behebung von Problemen benötigen, können Sie die Ablaufver-folgung für Anforderungsfehler aktivieren, so dass für fehlgeschlagene Anforderungen detaillierte Anforderungsausführungsprotokolle erstellt werden. Sie können im IIS-Manager auf die Einstellungen zur Ablaufverfolgung für Anforderungsfehler zugreifen, indem Sie im Hierarchielistenfeld die Website markieren und dann einen Doppelklick auf Ablaufverfolgung für Anforderungsfehler ausführen. Im Dialogfeld zur Bearbeitung der Ablaufverfolgungseinstellungen können Sie die Ablaufverfolgung für Anforderungsfehler aktivieren, den Speicherort angeben und festlegen, wie viele Ablaufverfolgungs-dateien maximal für die Website generiert werden dürfen.

Um mehr darüber zu erfahren, wie Sie die Ablaufverfolgung für Anforderungsfehler nutzen können, um Fehler schnell zu diagnostizieren und zu beheben, lesen Sie bitte das sechzehnte Kapitel, »Ablaufverfolgung und Problembehandlung«.

Websites starten und beendenWenn eine Website erstellt wird, ist sie automatisch so konfiguriert, dass sie mit der Überwachung eingehender Anforderungen beginnt, sobald der W3SVC-Dienst (World Wide Web Service Publishing Service) gestartet wurde. Eine Website, die eingehende Anforderungen aktiv überwacht, wird als gestartet erachtet.

Sie können eine Website beenden, um temporär zu verhindern, dass sie neue Anforderungen entge-gennimmt. Das Beenden einer Website bricht keine gegenwärtig ausgeführten Anforderungen ab und wirkt sich auch nicht auf gegenwärtig aktive IIS-Arbeitsprozesse und Anwendungen aus, die der Site zugeordnet sind. Um mehr über das Entladen von gegenwärtig aktiven Anwendungen und IIS-Arbeits-prozessen zu erfahren, lesen Sie das zehnte Kapitel.

Das Beenden einer Website ist eine temporäre Aktion, die bei einem Neustart des W3SVC-Dienstes hinfällig wird. Wenn Sie den automatischen Start einer Website verhindern möchten, können Sie dies konfigurieren.

Sie sehen den aktuellen Status einer Website, wenn Sie im IIS-Manager die Websiteliste anzeigen lassen. Sie können eine Website in der Liste starten oder beenden, indem Sie (im Hierarchielistenfeld oder in der Websiteliste) mit der rechten Maustaste darauf klicken, das Untermenü Website verwalten öffnen und Starten oder Beenden auswählen.

Hinweis Wenn Sie den IIS-Manager benutzen, um eine Website zu starten, kennzeichnet er die Site so, da sie beim Start von IIS automatisch gestartet wird. Das Befehlszeilentool Appcmd.exe tut dies nicht, so dass Sie selbst die Einstellung zum automatischen Start festlegen können.

Sie können Websites ebenfalls mit dem Befehlszeilentool Appcmd.exe starten und beenden. Um die Statusinformationen der Websites des Servers auflisten zu lassen, verwenden Sie die folgende Syntax:appcmd list sites

Die resultierende Siteliste gibt Aufschluss darüber, ob die jeweilige Site gestartet oder beendet ist.SITE "Default Web Site" (id:1,bindings:http/*:80:,state:Started)



Sie können optional den Parameter /state mit den Werten started oder stopped verwenden, um nur die gestarteten oder beendeten Websites anzeigen zu lassen.

Um eine beendete Website zu starten, verwenden Sie die folgende Syntax:appcmd start site SiteName

Um eine gestartete Website zu beenden, können Sie den folgenden Befehl benutzen:appcmd stop site SiteName

In beiden Fällen ist SiteName der Name der zu startenden oder zu beendenden Site.

Wie bereits erwähnt wurde, führt das Starten oder Beenden einer Website mit Appcmd nicht dazu, dass eine Änderung hinsichtlich des automatischen Starts der Site beim Starten oder Herunterfahren des IIS-Kerndienstes erfolgt. Um dies zu ändern, können Sie die serverAutoStart-Konfigurationseigenschaft der Website setzen. Sie können beispielsweise wie folgt festlegen, dass Default Web Site nicht automatisch gestartet werden soll:appcmd set site "Default Web Site" /serverAutoStart:false

Sie können sowohl die Befehle Start Site und Stop Site als auch die Anweisung Set Site benutzen, um eine Website unabhängig von den Neustarts des W3SVC-Dienstes einheitlich zu beenden und zu starten.

Virtuelle Verzeichnisse verwaltenSie können virtuelle Verzeichnisse verwenden, um Anwendungsinhalte zu veröffentlichen, die nicht dem virtuellen Stammverzeichnis einer Anwendung untergeordnet sind. Der Einsatz von virtuellen Verzeichnissen stellt eine effektive Möglichkeit dar, um die URL-Struktur Ihrer Anwendung, die dem Client präsentiert wird, von der physikalischen Struktur der Anwendungsinhalte zu trennen. Sie benötigen virtuelle Verzeichnisse außerdem, wenn sich Ihre Anwendungsinhalte an verschiedenen physikalischen Speicherorten befinden.

Ein neues virtuelles Verzeichnis hinzufügenSie können ein virtuelles Verzeichnis erstellen, um eine virtuelle Pfadzuordnung für Ressourcen festzu-legen, die sich außerhalb des Stammverzeichnisses der Website finden. Wie bereits in diesem Kapitel beschrieben wurde, sind bei IIS 7.0 virtuelle Verzeichnisse und Webanwendungen zwei verschiedene Objekttypen, die jedoch in enger Beziehung zueinander stehen. Dies führt bei der Erstellung virtueller Verzeichnisse zu den folgenden Überlegungen:

� Jede Webanwendung muss ein virtuelles Stammverzeichnis (der Pfad /) besitzen, das einem physi-kalischen Pfad zugeordnet ist, der zum physikalischen Anwendungsstamm wird. Wenn Sie eine Anwendung erstellen, erzeugen Sie ebenfalls deren virtuelles Stammverzeichnis.

� Alle virtuellen Verzeichnisse müssen einer vorhandenen Anwendung zugeordnet sein. Wenn Sie somit ein virtuelles Verzeichnis erstellen, müssen Sie es einer bereits vorhandenen Anwendung hinzufügen oder eine neue Anwendung erstellen, die den gewünschten virtuellen Pfad aufweist.

� Wenn das virtuelle Verzeichnis für ein Anwendungsframework als Anwendungsstamm dienen, aktivierte IIS-Module konfigurieren oder mit einem bestimmten Anwendungspool verknüpft sein soll, müssen Sie stattdessen eine Anwendung erstellen.

Um mit dem IIS-Manager ein virtuelles Verzeichnis zu erstellen, erweitern Sie im Bereich Verbin-dungen den Knoten des IIS-Computers und dann den Knoten Sites. Markieren Sie die Website, in der Sie ein virtuelles Verzeichnis erstellen möchten. Sie können ebenfalls die markierte Website erweitern


Virtuelle Verzeichnisse verwalten 267

und den Knoten einer untergeordneten Anwendung oder eines untergeordneten Ordners auswählen, der bzw. dem Sie das virtuelle Verzeichnis hinzufügen möchten. Klicken Sie mit der rechten Maustaste auf den gewünschten Knoten und wählen Sie Virtuelles Verzeichnis hinzufügen aus.

Im daraufhin angezeigten Dialogfeld können Sie den Alias des virtuellen Verzeichnisses angeben, der mit dem aktuellen Pfad der Hinzufügung kombiniert wird, um den virtuellen Pfad des virtuellen Verzeichnisses zu bestimmen. Sie können ebenfalls den physikalischen Pfad festlegen, dem der URL-Namespace des virtuellen Verzeichnisses zugeordnet werden soll.

Anmeldeinformationen für den Zugriff auf das virtuelle Verzeichnis konfigurierenDer Webserver greift standardmäßig unter Verwendung der IIS-Arbeitsprozessidentität auf die Inhalte im physikalischen Pfad des virtuellen Verzeichnisses zu und stellt zusätzlich sicher, dass der mit der Anforderung verknüpfte authentifizierte Benutzer, der die Anforderungsidentität darstellt, auf die angeforderte Ressourcen zugreifen kann. Dies bedeutet, dass die folgenden Identitäten auf die Inhalte im freigegebenen Ordner zugreifen können müssen:

� Die Anwendungspoolidentität (ist standardmäßig NETZWERKDIENST)

� Der anonyme Benutzer (ist standardmäßig IUSR), sofern die anonyme Authentifizierung erlaubt ist

� Die Identität des authentifizierten Benutzers für alle Benutzer, die auf die Inhalte des virtuellen Verzeichnisses zugreifen dürfen. Wenn es sich um einen Windows-Benutzer handelt, kommen die Authentifizierungsmethoden Windows-Authentifizierung oder Standardauthentifizierung zum Einsatz.

Hinweis Der Standard für virtuelle Verzeichnisse ist identisch mit dem Pass-Through-Authentifizierungs-mechanismus, der bei IIS 6.0 für die Zuordnung von virtuellen Verzeichnissen zu UNC-Pfaden verwendet wird.

Wenn Sie möchten, dass der Webserver einen bestimmten Satz Anmeldeinformationen verwendet, über die der Zugriff auf die Ressourcen im virtuellen Verzeichnis möglich ist, können Sie diese Anmelde-informationen im Dialogfeld Verbinden als konfigurieren. Wenn Sie diese Anmeldeinformationen angeben, nutzt der Webserver immer diese Identität und nicht die IIS-Arbeitsprozessidentität, um auf alle Inhalte und Konfigurationen im entsprechenden virtuellen Verzeichnis zuzugreifen. Darüber hinaus wird dann auch nicht mehr geprüft, ob der mit der Anforderung verknüpfte authentifizierte Benutzer auf die physikalischen Ressourcen zugreifen kann.

Hinweis Wenn angegeben, verwendet IIS immer die Anmeldeinformationen für ein virtuelles Verzeichnis, um auf die Inhalte und Konfigurationsdateien dieses Verzeichnisses zuzugreifen, und zwar unabhängig davon, ob es sich bei dem physikalischen Speicherort des virtuellen Verzeichnisses um einen lokalen Ordner oder einen freigegebe-nen Netzwerkordner handelt. Dies ist anders als bei IIS 6.0, wo die zur Verfügung gestellten Anmeldeinformationen nur dann zum Einsatz kommen, wenn der physikalische Speicherort eine Netzwerkfreigabe ist, die durch einen UNC-Pfad gekennzeichnet ist.

Dies ist ein einfaches Verfahren, um Zugriff auf die Inhalte zu erhalten, die sich in freigegebenen Netzwerkordnern befinden. Überlegungen zur Verwendung von virtuellen Verzeichnissen, die auf die physikalischen Inhalte einer nicht lokalen Netzwerkfreigabe verweisen, werden später in diesem Kapitel im Abschnitt »Remoteinhalte verwalten« beschrieben.



Virtuelle Verzeichnisse mit Appcmd erstellenSie können virtuelle Verzeichnisse ebenfalls mit dem Befehlszeilentool Appcmd und dem folgenden Befehl erstellen:appcmd add vdir /app.name:string /path:string /physicalPath:string /userName:string /password:string /logonMethod:enum /allowSubDirConfig:bool

Die Parameter dieses Befehls sind in Tabelle 9.4 aufgeführt.

Das folgende Beispiel fügt innerhalb der Contoso Corp.-Website ein neues virtuelles Verzeichnis namens images hinzu:appcmd add vdir /app.name:"Contoso Corp/" /path:/images /physicalPath:g:\images

Die Befehlsausgabe zeigt, dass IIS ein VDIR-Objekt erstellt, das der Contoso Corp.-Stammanwendung zugeordnet ist. Die Zuordnung des virtuellen Verzeichnisses generiert den URL http://www.contoso.com/ images, der auf die Bilddateien im physikalischen Ordner g:\images verweist.Das VDIR-Objekt "Contoso Corp/images" wurde hinzugefügt

Virtuelle Verzeichnisse konfigurierenWenn Sie ein virtuelles Verzeichnis hinzufügen oder ändern, sollten Sie dessen Beziehung zur Web-anwendung verstehen. Wenn Sie beispielsweise auf einen Ordner mit Bilddateien verweisen möchte, der sich in einem freigegebenen Netzwerkordner befindet, muss das virtuelle Verzeichnis selbst keine Anwendung sein. Stattdessen kann es ein Teil der Stammanwendung der Website sein.

Tabelle 9.4 Appcmd-Syntax zum Hinzufügen eines virtuellen Verzeichnisses


app.name Der Pfad der übergeordneten Anwendung, der das virtuelle Verzeichnis hinzugefügt wird. Dieser Para-meter muss angegeben werden.

path Der virtuelle Pfad des virtuellen Verzeichnisses. Er ist, ausgehend vom virtuellen Pfad der übergeord-neten Anwendung, ein relativer Pfad. Dieser Parameter muss angegeben werden.

physicalPath Der physikalische Pfad des virtuellen Verzeichnisses. Dieser Parameter muss angegeben werden.

userName Der Benutzername für den Zugriff auf die Inhalte des virtuellen Verzeichnisses. Wenn Sie für die Erstellung des virtuellen Verzeichnisses auf diese Angabe verzichten, wird standardmäßig die Pass-Through-Authentifizierung verwendet.

password Das Kennwort, das zusammen mit dem Benutzernamen verwendet werden soll, um auf die Inhalte des virtuellen Verzeichnisses zuzugreifen.

logonMethod Die Anmeldemethode, die zur Erstellung des Anmeldetokens für die Anmeldeinformationen des virtu-ellen Verzeichnisses verwendet werden soll. Kann Interactive, Batch, Network oder ClearText sein. Der Vorgabewert ist ClearText. Weitere Informationen zu diesen Typen finden Sie im Artikel »LogonUser Function« unter http://msdn2.microsoft.com/en-us/library/aa378184.aspx.

allowSubDirConfig Boolescher der Wert, der angibt, ob der Webserver in den Unterverzeichnissen dieses virtuellen Ver-zeichnisses nach Konfigurationsdateien suchen wird. Wenn Sie diesen Wert auf false setzen, kann dies bei Servern mit einer sehr großen Anzahl von web.config-Dateien zu einer besseren Leistung führen. Gleichzeitig wird jedoch verhindert, dass die IIS-Konfiguration aus Unterverzeichnissen gelesen wird. Der Vorgabewert ist true.



Um Änderungen an einem bereits vorhandenen virtuellen Verzeichnis vorzunehmen, markieren Sie dieses und klicken im Bereich Aktionen auf Grundeinstellungen. Das Ergebnis ist in Abbildung 9.4 zu sehen. Um ein virtuelles Verzeichnis zu löschen, markieren Sie es und klicken im Bereich Aktionen auf Entfernen.

Vorsicht Das Entfernen eines virtuellen Verzeichnisses hat keine Löschung der Inhalte zur Folge, die sich in dem zugeordneten Pfad des physikalischen Dateisystems befinden. Lediglich die Zuordnung zwischen dem URL-Alias und dem physikalischen Ordner wird entfernt.

Beachten Sie ebenfalls, dass es nicht möglich ist, dass virtuelle Stammverzeichnis einer Website oder Anwendung zu entfernen.

Abbildung 9.4 Ein virtuelles Verzeichnis mit dem IIS-Manager konfigurieren

Um die Konfigurationseinstellungen zu einem bereits vorhandenen virtuellen Verzeichnis festzulegen, verwenden Sie den folgenden Befehl:appcmd set vdir VirtualDirectoryName /physicalPath:string /userName:string /password:string /logonMethod:enum /allowSubDirConfig:bool

Um ein bereits vorhandenes virtuelles Verzeichnis zu löschen, nutzen Sie die folgende Syntax:appcmd delete vdir VirtualDirectoryName

Die Parameter dieser Befehle sind in Tabelle 9.5 aufgeführt.

Tabelle 9.5 Appcmd-Syntax zum Konfigurieren eines virtuellen Verzeichnisses

Parameter Description

VirtualDirectoryName Der vollständige virtuelle Pfad des virtuellen Verzeichnisses, der das Verzeichnis eindeutig identifiziert. Dieser Pfad muss angegeben werden, damit ein bereits vorhandenes virtuelles Verzeichnis bearbeitet oder gelöscht werden kann.

physicalPath Der physikalische Pfad der virtuellen Zuordnung

userName Der Benutzername für den Zugriff auf die Inhalte des virtuellen Verzeichnisses. Wenn Sie für die Erstellung des virtuellen Verzeichnisses auf diese Angabe verzichten, wird standardmäßig die Pass-Through-Authentifizierung verwendet.

password Das Kennwort, das zusammen mit dem Benutzernamen verwendet werden soll, um auf die Inhalte des virtuellen Verzeichnisses zuzugreifen



Um ein bereits vorhandenes virtuelles Verzeichnis zu löschen, müssen Sie den vollständigen virtuellen Pfad des virtuellen Verzeichnisses wie im folgenden Beispiel angeben:appcmd delete vdir "Contoso Corp/oldimages"

Stellen Sie sich vor, dass die Rechtsabteilung von Contoso Corp. neue Unternehmensbilder auf ihrem Server veröffentlicht hat. Um die Zuordnung des virtuellen Verzeichnisses zu ändern und ein benutzer-definiertes Benutzerkonto namens Webuser anzugeben, über das der Zugriff auf die Remotefreigabe erfolgen soll, setzen Sie den folgenden Befehl ein:appcmd set vdir "Contoso Corp/images" /physicalPath:\\ContosoLegal\pub\images\ /userName:"Webuser" /password:"passw@rd1"

Die Konfiguration des virtuellen Verzeichnisses ist zusammen mit den Siteinformationen in der applicationHost.config-Datei und dort im <virtualDirectory>-Element des <site>-Elements definiert. Nachfolgend ist die Konfiguration aufgeführt, die sich aus der Ausführung des vorherigen Befehls ergibt: <site name="Contoso Corp" id="1"> <application path="/"> <virtualDirectory path="/" physicalPath="d:\contoso" /> <virtualDirectory path="/images" physicalPath="\\ContosoLegal\pub\images" userName:"Webuser" password= "[enc:AesProvider:oGSyoej3RKswi3gsrYarpbMQrx0rVIY6nFHkPmjQAhE=:enc]"/> </application> <application path="/payment" applicationPool="MyAppPool"> <virtualDirectory path="/" physicalPath="d:\KDbank" /> </application> ... </site>

Beachten Sie, dass die Benutzeranmeldeinformationen für ein virtuelles Verzeichnis standardmäßig in der applicationHost.config-Datei gespeichert und mithilfe des Microsoft-AES-Kryptografieanbieters (Advanced Encryption Standard) verschlüsselt werden. Der Anwendungspfad / kennzeichnet die Stammanwendung der Website und gibt an, dass das virtuelle Verzeichnis /images der Stamm-anwendung zugeordnet ist.

logonMethod Die Anmeldemethode, die zur Erstellung des Anmeldetokens für die Anmeldeinformationen des virtuel-len Verzeichnisses verwendet werden soll. Kann Interactive, Batch, Network oder ClearText sein. Der Vorgabewert ist ClearText. Weitere Informationen zu diesen Typen finden Sie im Artikel »LogonUser Function« unter http://msdn2.microsoft.com/en-us/library/aa378184.aspx.

allowSubDirConfig Boolescher der Wert, der angibt, ob der Webserver in den Unterverzeichnissen dieses virtuellen Ver-zeichnisses nach Konfigurationsdateien suchen wird. Wenn Sie diesen Wert auf false setzen, kann dies bei Servern mit einer sehr großen Anzahl von web.config-Dateien zu einer besseren Leistung führen. Gleichzeitig wird jedoch verhindert, dass die IIS-Konfiguration aus Unterverzeichnissen gelesen wird. Der Vorgabewert ist true.

Tabelle 9.5 Appcmd-Syntax zum Konfigurieren eines virtuellen Verzeichnisses (Fortsetzung)




Nach virtuellen Verzeichnissen suchenWenn Sie Websites mit hunderten von virtuellen Verzeichnissen und Anwendungen verwalten, müssen Sie bisweilen ein bestimmtes virtuelles Verzeichnis oder eine Gruppe von virtuellen Verzeichnissen lokalisieren, das bzw. die einer bestimmten Anwendung oder Website zugeordnet ist. IIS 6.0 bietet nur eingeschränkte Tools und Features an, um bestimmte virtuelle Verzeichnisse aufzuspüren. Bei IIS 7.0 ermöglicht es Ihnen jedoch der IIS-Manager, die für den Webserver definierten virtuellen Verzeichnisse schnell zu lokalisieren und auflisten zu lassen.

Um mit dem IIS-Manager virtuelle Verzeichnisse zu suchen und aufzulisten, erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers sowie den Knoten Sites und markieren die Website, deren virtuelle Verzeichnisse Sie auflisten lassen möchten. Klicken Sie im Bereich Aktionen auf Virtuelle Verzeichnisse anzeigen. Das Ergebnis ist in Abbildung 9.5 dargestellt.

Wenn das virtuelle Verzeichnis selbst keine Anwendung und der Stammanwendung der Website zugeordnet ist, wird es in der Spalte Anwendungspfad als Stammanwendung aufgeführt. Die Spalte Identität zeigt das Anforderungsbenutzerkonto an, das für den Zugriff auf die Inhalte des virtuellen Verzeichnisses als Anforderungsidentität verwendet wird.

Hinweis Wenn das Feld Identität keine Daten enthält, wird die Pass-Through-Authentifizierung für den Zugriff auf die Inhalte verwendet. Bei der anonymen Authentifizierung ist beispielsweise das Konto IUSR die Anforderungs-identität.

Abbildung 9.5 Virtuelle Verzeichnisse mit dem IIS-Manager anzeigen lassen



Benutzen Sie den folgenden Appcmd-Befehl, um die Zuordnungsinformationen für virtuelle Verzeichnisse anzeigen zu lassen:appcmd list vdir VirtualDirectoryPath /app.name:string

Die Parameter dieses Befehls sind in Tabelle 9.6 aufgeführt.

Der folgende Befehl fragt die Konfigurationsdetails zum virtuellen Verzeichnis /images ab:appcmd list vdir "Contoso Corp/images"

Wie die resultierende Ausgabe zeigt, ist das virtuelle Verzeichnis einer UNC-Freigabe zugeordnet:VDIR "Contoso Corp/images" (physicalPath:\\ContosoLegal\pub\images)

Um alle virtuellen Verzeichnisse des Webservers aufzulisten, geben Sie den folgenden Befehl ein:appcmd list vdir

Die resultierende Ausgabe listet alle virtuellen Verzeichnisse auf, wie das folgende Beispiel zeigt:VDIR "Contoso Corp/" (physicalPath:d:\contoso) VDIR "Contoso Corp/images" (physicalPath:\\ContosoLegal\pub\images) VDIR "Contoso Corp/payment" (physicalPath:d:\KDbank) VDIR "Fabrikam HR/" (physicalPath:d:\FabrikamHR)

Sie können ebenfalls Filterausdrücke angeben, die auf den Konfigurationseigenschaften der virtuellen Verzeichnisse basieren (z.B. auf dem Pfad oder Benutzernamen), um alle virtuellen Verzeichnisse aufzulisten, die diesen Filterausdrücken entsprechen. Zusätzlich können Sie nach virtuellen Verzeich-nissen suchen, die einer bestimmten Site zugeordnet sind. Um mehr darüber zu erfahren, wie Appcmd für die Suche nach Objekten eingesetzt wird, lesen Sie bitte das siebte Kapitel.

Remoteinhalte verwaltenDie Dateien, aus denen eine Webanwendung besteht, werden in der Regel im lokalen Dateisystem des IIS-Servers gespeichert. Obwohl dies durchaus sinnvoll ist, wenn Sie mit nur wenigen Webanwendungen arbeiten, ist es in einer großen oder komplexen Umgebung – z.B. bei einem Hostingsunternehmen, das über viele Server verteilte Webfarmen mit tausenden von Websites unterhält, oder bei einer komplexen Anwendung, die aus vielen kleinen Anwendungen besteht, die wiederum auf viele verschiedene Server verteilt sind, welche von verschiedenen Parteien verwaltet werden – fast unmöglich, die Anwendungs-inhalte lokal zu hosten.

Für einige Szenarien benötigen Sie möglicherweise mehr als nur einen Webserver, um eine Webanwen-dung bereitzustellen, die ein hohes Datenverkehrsaufkommen aufweist. Obwohl es natürlich möglich ist, dieselben Inhalte auf viele Webserver zu kopieren, damit diese dieselbe Anwendung bereitstellen, führt dies zu einem zusätzlichen administrativen Aufwand, weil Sie sicherstellen müssen, dass die

Tabelle 9.6 Appcmd-Syntax für die Suche nach virtuellen Verzeichnissen


VirtualDirectoryPath Eine Zeichenfolge, die den vollständigen virtuellen Pfad des virtuellen Verzeichnisses repräsentiert. Wird der Wert nicht angegeben, zeigt die Abfrage alle virtuellen Verzeichnisse des Webservers an.

Diese Zeichenfolge kann auch ein URL sein. In diesem Fall wird der URL in das nächstgelegene virtuelle Verzeichnis aufgelöst.

app.name Der virtuelle Anwendungspfad. Wenn der Wert angegeben wird, werden alle virtuellen Verzeichnisse zurückgegeben, die der Anwendung zugeordnet sind.


Remoteinhalte verwalten 273

Inhalte auf allen Servern synchronisiert werden. Darüber hinaus könnten durch die Replikation Prob-leme verursacht werden, die sich möglicherweise auf die Verfügbarkeit der Anwendung und die Intakt-heit der Inhalte auswirken würden. Noch wichtiger ist, dass die Verwaltung von Inhalten über ver-schiedene Server hinweg zu einem zusätzlichen Aufwand führt, da auch die Benutzerzugriffskonten sowie die Zugriffsberechtigungen für die Inhaltsdateien verwaltet werden müssen. All dies steigert die Komplexität der gesamten Bereitstellung. Das lokale Speichern von Inhalten mag zu einer Leistungs-steigerung führen, weist aber hinsichtlich der Skalierung Ihrer Anwendung viele Nachteile auf.

Um diese Probleme zu umgehen, können Sie mit IIS 7.0 Webanwendungen hosten, deren Inhalt sich in einem freigegebenen Netzwerkordner befindet. Mehrere Webserver können dann eine Verbindung zu den Inhalten herstellen, die sich auf dem entsprechenden Dateiserver befinden. Obwohl dies oft dazu führt, dass der mit dem Zugriff auf die Inhalte einhergehende Overhead zunimmt, gibt es wichtige Vorteile, die für die Einrichtung eines zentralisierten Remotespeichers für Inhalte sprechen. Einige dieser Vorteile sind nachfolgend aufgeführt:

� Geringerer Verwaltungsaufwand Anstatt auf vielen Webservern die Dateisystemsicherheit einzurichten, verwalten Sie den Zugriff auf das Dateisystem nur dort, wo sich der zentralisierte Inhaltsspeicher befindet. Auf diese Weise werden die Verwaltungsaufgaben verringert, die sich auf die Benutzerkonten und den Inhalt beziehen. Diese Aufgaben müssen bei einem lokalen Hosting der Inhalte nur noch für den zentralisierten Inhaltsspeicher und nicht für viele verschiedene Server ausgeführt werden.

� Bessere Fehlertoleranz Um die Verfügbarkeit von Inhalten zu verbessern, können diese von Microsoft Cluster, DFS (Distributed File System) oder sogar von SAN- (Storage Area Network) bzw. NAS-Geräten (Network Attached Storage) gehostet werden.

� Bessere Kosteneffizienz Bei einem Vergleich der Fehlertoleranzsysteme aller Webserver, z.B. RAID (Redundant Array of Inexpensive Disks). Wird die Fehlertoleranz nur für den zentralisierten Inhaltsspeicher implementiert, ist dies kostengünstiger und die Arbeit mit Dateifreigabe-Clustern erfordert seltener eine Hardwarewartung, als der Einsatz eines RAID-Systems in jedem Server einer Webfarm.

Dieser Abschnitt beschreibt die Schlüsselkonzepte für den Zugriff auf Remoteinhalte, die zum Ein-richten vom Remoteinhalten erforderlichen Schritte, Sicherheitsüberlegungen zum Zugriff auf Remote-inhalte und die Konfiguration von Remoteinhalten. Diese Konzepte beziehen sich in der Regel auf die Verwaltung von Remoteinhalten in verschiedenen Umgebungen, z.B. bei Dateifreigabe-Clustern und NAS-Geräten.

Anwendungen für die Arbeit mit Remoteinhalten konfigurierenWenn Sie virtuelle Verzeichnisse verwenden, um eine Zuordnung zu Remoteinhalten zu erhalten, werden diese, in einem Remotenetzwerkpfad befindlichen Inhalte zu einem Teil des Anwendungs-URL-Namespace oder der gesamten Anwendung.

Um eine Anwendung für die Arbeit mit Remoteinhalten zu konfigurieren, müssen Sie Folgendes tun:

1. Setzen Sie den physikalischen Pfad des virtuellen Stammverzeichnisses der Website oder Web-anwendung auf den Netzwerkpfad, der die Inhalte zur Verfügung stellt. Wenn Sie nur einen Teil der Anwendung für die Arbeit mit Remoteinhalten zuordnen möchten, können Sie einfach inner-halb dieser bereits vorhandenen Anwendung ein virtuelles Verzeichnis mit dem gewünschten Pfad erstellen. Das Erstellen von virtuellen Verzeichnissen ist früher in diesem Kapitel im Abschnitt »Ein neues virtuelles Verzeichnis hinzufügen« ausführlich beschrieben.



2. Wählen Sie das gewünschte Sicherheitsmodell für den Zugriff auf die Netzwerkinhalte. Sie können entweder die aktuellen Anmeldeinformationen in Verbindung mit der Pass-Through-Authentifi-zierung verwenden oder einen festen Benutzer angeben, dessen Anmeldeinformationen für den Zugriff genutzt werden sollen.

3. Erstellen Sie die Dateifreigabe, die die Remoteinhalte auf dem Netzwerkserver hostet, und gewäh-ren Sie dieser Dateifreigabe die erforderlichen Rechte.

Das Sicherheitsmodell für den Zugriff auf Remoteinhalte auswählenUm das richtige Sicherheitsmodell auszuwählen, sollten Sie berücksichtigen, wie der Webserver auf die Remoteinhalte zugreift. Die folgenden Zugriffe sind notwendig:

� Die web.config-Dateien in der Verzeichnisstruktur der Remoteinhalte – damit die delegierte Konfiguration von Remoteinhalten korrekt durchgeführt werden kann, versucht IIS 7.0, die web.config-Konfigurationsdateien aller Remoteinhaltsverzeichnisse zu lokalisieren und zu lesen. IIS greift immer zuerst auf eine Konfigurationsdatei zu, bevor der Zugriff auf die Inhalte erfolgt und der authentifizierte Benutzer bekannt ist. Deshalb müssen entweder feste Anmeldeinformationen für die virtuellen Verzeichnisse festgelegt werden oder die IIS-Arbeitsprozessidentität muss über das Recht verfügen, auf die Remoteinhaltsfreigabe zuzugreifen, um die Inhalte zu lesen.

� Die Inhalte – IIS-Features, wie z.B. der Handler für statische Dateien, und Anwendungsframeworks greifen ebenfalls auf die Inhaltsdateien der Remoteinhaltsfreigabe zu. Wenn für das virtuelle Ver-zeichnis feste Anmeldeinformationen festgelegt wurden, werden diese genutzt. Andernfalls wird die Identität des gegenwärtig authentifizierten Benutzers verwendet, um auf diese Dateien zuzu-greifen. Wenn die anonyme Authentifizierung aktiviert ist, kommt für diesen Zugriff die anonyme Benutzeridentität zum Zuge.

Hinweis Die meisten IIS 7.0-Module und Anwendungsframeworks verwenden für den Zugriff auf Inhalte die festen Anmeldeinformationen eines virtuellen Verzeichnisses oder die Identität des authentifizierten Benutzers. In bestimmten Fällen kann es jedoch sein, dass die IIS-Arbeitsprozessidentität eingesetzt wird. Diese muss dann auf die entsprechenden Inhalte zugreifen können. Bei ASP.NET ist dies standardmäßig so. Andere Anwendungsframe-works müssen Sie möglicherweise zunächst konfigurieren, damit die richtige Identität verwendet wird. Lesen Sie das elfte Kapitel, »Hosting von Anwendungsentwicklungsframeworks«, um genaue Informationen über die Ausfüh-rungsidentität von bekannten Anwendungsframeworks zu erhalten.

In der Regel können Sie zwei verschiedene Sicherheitsmodelle für die Konfiguration des Zugriffs auf die Remoteinhaltsfreigabe verwenden:

� Pass-Through-Authentifizierung Bei diesem Modell greift der Webserver unter Verwendung der IIS-Arbeitsprozessidentität und der Identität des mit der Anforderung verknüpften authentifizierten Benutzers auf die Remoteinhalte zu. Dies ist das Standardmodell.

� Feste Anmeldeinformationen Bei diesem Modell verwendet der Webserver immer die für ein virtuelles Verzeichnis konfigurierten festen Anmeldeinformationen, um auf die Remoteinhalte zuzugreifen.

Diese Optionen gleichen denen, die von IIS 6.0 angeboten werden. Die Notwendigkeit, auf web.config-Dateien zugreifen zu müssen, erschwert jedoch die Konfiguration des Remoteinhaltszugriffs unter Ver-wendung der Pass-Through-Authentifizierung, da der authentifizierte Benutzer nicht verfügbar ist,


Remoteinhalte verwalten 275

wenn der Webserver web.config-Dateien lesen muss. Deshalb ist es notwendig, dass die IIS-Arbeits-prozessidentität auf die Remoteinhaltsfreigabe zugreifen kann. Andernfalls müssen feste Anmelde-informationen verwendet werden.

Hinweis Es ist möglich, die Verwendung von web.config-Dateien im virtuellen Verzeichnis zu deaktivieren. Dazu setzen Sie in der Definition des virtuellen Verzeichnisses das allowSubDirConfig-Attribut auf false. Eine verteilte Konfiguration mithilfe von web.config-Dateien innerhalb dieses virtuellen Verzeichnisses ist dann nicht mehr mög-lich. Die Pass-Through-Authentifizierung kann jedoch in diesem Fall genutzt werden. Weitere Informationen erhal-ten Sie im vierzehnten Kapitel.

Darüber hinaus weisen verschiedene Anwendungsframeworks jeweils andere Verhaltensweisen auf, wenn das Pass-Through-Authentifizierungsmodell genutzt wird. Einige Anwendungsframeworks, wie z.B. ASP.NET, verwenden die IIS-Arbeitsprozessidentität. Andere, z.B. ASP, arbeiten immer mit der Identität des authentifizierten Benutzers. Der Einsatz der Pass-Through-Authentifizierung erschwert die Verwaltung des Zugriffs auf die Remoteinhalte. Deshalb wird meistens das Modell mit den festen Anmeldeinformationen empfohlen, um unter IIS 7.0 den Zugriff auf Remoteinhalte einzurichten.

Das Modell mit den festen Anmeldeinformationen ist einfacher zu handhaben, da es vom Authentifi-zierungsmechanismus des Webservers nicht abhängig ist und nicht alle Benutzer des Webservers über Zugriffsrechte für die Remoteinhaltsfreigabe verfügen müssen. Es verlangt außerdem keine Konfigura-tion der Delegierung und des Protokollübergangs, was bei vielen IIS 7.0-Authentifizierungsmecha-nismen notwendig ist, wenn die authentifizierte Identität für den Zugriff auf die Remotenetzwerk-freigabe verwendet werden soll. Das Modell mit den festen Anmeldeinformationen ist somit innerhalb einer Netzwerkumgebung wesentlich einfacher zu konfigurieren und zu verwalten.

Da es jedoch nicht die Identität des authentifizierten Benutzers für den Zugriff auf die Remoteinhalte verwendet, können für diese keine ACLs für die Autorisierung und Überwachung genutzt werden.

Hinweis Das Modell mit den festen Anmeldeinformationen lässt nicht zu, dass NTFS-ACLs (NTFS File System) für die Überwachung und Autorisierung von authentifizierten Benutzern verwendet werden. IIS 7.0 bietet das URL-Autorisierungsfeature an, mit dem innerhalb der Konfiguration deklarative Autorisierungsregeln definiert werden können, die auf den authentifizierten Benutzer angewendet werden. Darüber hinaus ist es nun möglich, benutzer-definierte Autorisierungslösungen mithilfe von IIS 7.0-Modulen schnell zu implementieren. Ähnlich hierzu kann eine Überwachung erfolgen, indem die Anforderungsprotokolle untersucht oder ein benutzerdefiniertes IIS 7.0-Über-wachungsmodul entwickelt wird. Weitere Informationen zur Verwendung von benutzerdefinierten IIS 7.0-Modulen finden Sie im zwölften Kapitel, »Verwalten von Webservermodulen«.

Sie können die Pass-Through-Authentifizierung anstelle der festen Anmeldeinformationen verwenden, wenn:

� Sie aus Gründen der Autorisierung oder Überwachung mit der Identität des authentifizierten Benut-zers auf die Remoteinhalte zugreifen müssen, und Sie das URL-Autorisierungsfeature von IIS und die benutzerdefinierte Autorisierung bzw. die protokollbasierte oder benutzerdefinierte Überwach-ung über IIS 7.0-Module nicht nutzen können.

� sich Ihr Webserver und Ihr Dateiserver in einer Domänenumgebung befinden.



� Sie einen Authentifizierungsmechanismus verwenden, der das Delegieren von authentifizierten Benutzeridentitäten (Standardauthentifizierung, auf Kerberos basierende Windows-Authentifi-zierung) an die Remotenetzwerkfreigabe ermöglicht, oder wenn Sie eine eingeschränkte Dele-gierung und den Protokollübergang konfiguriert haben, um die Delegierung für andere Authentifi-zierungsmechanismen zu ermöglichen.

� Sie keine anonyme Authentifizierung nutzen oder diese so konfiguriert haben, dass sie eine benut-zerdefinierte Identität für den Zugriff auf die Netzwerkfreigabe verwendet.

� Sie die Verwendung von verteilten web.config-Konfigurationsdateien innerhalb des virtuellen Verzeichnisses deaktiviert haben oder die Anwendungspoolidentität ein Domänenkonto, das auf die Netzwerkfreigabe zugreifen kann, zum Lesen von web.config-Konfigurationsdateien verwendet.

Um mehr über die Konfiguration des Zugriffs auf Serverressourcen zu erfahren, lesen Sie bitte das vierzehnte Kapitel, in dem auch erklärt wird, wie Sie mit dem Pass-Through-Authentifizierungsmodell arbeiten, um den Zugriff auf Remoteinhalte zu konfigurieren.

Feste Anmeldeinformationen für den Zugriff auf Remoteinhalte konfigurierenUm feste Anmeldeinformationen für die Konfiguration des Zugriffs auf Remoteinhalte zu verwenden, müssen Sie für das virtuelle Verzeichnis, das auf die Remotefreigabe verweist, den Benutzernamen und das Kennwort festlegen. Dieser Benutzername und dieses Kennwort müssen einem gültigen lokalen Konto des Dateiservers oder einem Domänenkonto entsprechen, das auf die mit dem virtuellen Ver-zeichnis verknüpfte Netzwerkfreigabe zugreifen kann, um Inhalte daraus zu lesen.

Sie können dies im IIS-Manager tun, wenn Sie eine neue Website oder Anwendung bzw. ein neues virtuelles Verzeichnis erstellen oder wenn Sie ein bereits vorhandenes virtuelles Verzeichnis bearbeiten. Sie können dies ebenfalls mithilfe des Befehlszeilentools Appcmd tun, indem Sie ein neues virtuelles Verzeichnis erstellen oder ein bereits vorhandenes virtuelles Verzeichnis bearbeiten.

Hinweis Im Gegensatz zu IIS 6.0, das mit den Metabasiseigenschaften UNCUserName und UNCPassword arbeitet, verwendet IIS immer die Anmeldeinformationen für das virtuelle Verzeichnis (sofern angegeben), um auf die darin enthaltenen Inhalte und Konfigurationsdateien zuzugreifen, und zwar unabhängig davon, ob der physikalische Spei-cherort des virtuellen Verzeichnisses lokal oder eine Remotenetzwerkfreigabe ist. Dies bedeutet, dass Sie feste Zugriffsanmeldeinformationen für jedes virtuelle Verzeichnis festlegen können. Dabei spielt es keine Rolle, ob das Verzeichnis auf einen lokalen Pfad oder einen nicht lokalen UNC-Pfad verweist.

Um mehr über die Konfiguration fester Anmeldeinformationen für virtuelle Verzeichnisse zu erfahren, lesen Sie früher in diesem Kapitel den Abschnitt »Virtuelle Verzeichnisse verwalten«.

Den Zugriff auf Remoteinhalte gewährenNachdem Sie das Sicherheitsmodell für den Zugriff auf die Remoteinhalte ausgewählt und den Web-server so konfiguriert haben, dass er mit diesem Modell arbeitet, müssen Sie den Zugriff auf die Netz-werkfreigabe mit den Remoteinhalten gewähren. Dazu müssen Sie die Netzwerkfreigabe auf dem Dateiserver erstellen und die erforderlichen Zugriffsrechte sowohl für die Freigabe als auch für die zugrunde liegenden Dateien im Dateisystem festlegen.


Zusammenfassung 277

Um dies zu erreichen, gehen Sie in der Regel wie folgt vor:

1. Erstellen Sie das physikalische Verzeichnis für die Remoteinhalte, auf die später über das virtuelle Verzeichnis zugegriffen wird.

2. Geben Sie dieses Verzeichnis mit dem gewünschten Freigabenamen frei. Benutzen Sie dazu den Windows-Explorer.

3. Konfigurieren Sie die Freigabeberechtigungen, damit die von IIS verwendete Identität eine Verbin-dung zur Freigabe herstellen kann. Die Identität muss mindestens Leserechte und möglicherweise die Rechte Schreiben bzw. Vollzugriff besitzen, sofern Sie IIS auch für die Veröffentlichung nutzen. Wenn Sie mit festen Anmeldeinformationen für das virtuelle Verzeichnis arbeiten möchten, ist dies die Identität, deren Anmeldeinformationen Sie für das virtuelle Verzeichnis verwenden müssen. Die Identität muss entweder ein lokales Konto des Servers oder ein Domänenkonto sein.

Hinweis Lesen Sie das vierzehnte Kapitel, um weitere Informationen zur Konfiguration der Berechtigungen für Pass-Through-Authentifizierungsszenarien zu erhalten.

4. Konfigurieren Sie die NTFS-Berechtigungen für das von der Freigabe verwendete Remoteinhalts-verzeichnis. Gehen Sie dazu genauso wie für die Netzwerkfreigabe vor. Behalten Sie die vorhande-nen NTFS-Berechtigungen für das Verzeichnis bei, um sicherzustellen, dass Administratoren und das lokale System auch weiterhin über alle Zugriffsrechte verfügen.

Vorsicht Es wird empfohlen, IIS keine Berechtigungen zu gewähren, die über den Lesezugriff hinausgehen. Wenn der Webserver angegriffen wird, könnten umfassendere Rechte dazu führen, dass der Angreifer die Kontrolle über die Remotefreigabe erhält. Vergeben Sie nur dann mehr Rechte, wenn Sie mit IIS Inhalte veröffentlichen, z.B. wenn Sie mit WebDAV (Web-based Distributed Authoring and Versioning) arbeiten. In allen anderen Fällen sollten Sie ein separates Konto für die Veröffentlichung von Inhalten im Remoteinhaltsverzeichnis erstellen.

Vorsicht Wenn das von IIS für den Zugriff auf die Remoteinhalte verwendete Konto auf dem Remotenetzwerk-server über administrative Rechte verfügt, kann ein Angreifer im Falle einer Gefährdung die vollständige Kontrolle über den Dateiserver erlangen. Benutzen Sie auf dem Dateiserver niemals Identitäten mit administrativen Rechten, um auf die Remoteinhalte zuzugreifen.

Wenn Sie die Berechtigungen für den Zugriff auf die Freigabe sowie die NTFS-Berechtigungen fest-legen möchten, sollten Sie darüber nachdenken, nicht mit einzelnen Benutzern, sondern mit einer Gruppe zu arbeiten, der die zulässigen Identitäten zugeordnet sind. Dies vereinfacht die Verwaltung des Zugriffs auf die Remoteinhalte. Es ist besonders dann hilfreich, wenn die Pass-Through-Authentifi-zierung verwendet wird, um einer großen Anzahl von authentifizierten Benutzern den Zugriff zu gewähren.

ZusammenfassungIn diesem Kapitel haben Sie das Fundament einer IIS 7.0-Website kennen gelernt. Sie haben einen Blick darauf geworfen, wie der IIS-Manager und das Befehlszeilentool Appcmd verwendet werden, um Websites zu erstellen und zu verwalten. Wie Sie diese Hilfsmittel benutzen, um andere wichtige Verwaltungsaufgaben zu lösen, erfahren Sie im sechsten Kapitel, »Verwenden von IIS-Manager«, und im siebten Kapitel.



Sie haben ebenfalls erfahren, wie virtuelle Verzeichnisse genutzt werden, um die physikalische Struktur von Websiteinhalten zu kontrollieren und dafür zu sorgen, dass eine Website Inhalte von einer Remote-freigabe verwendet. Weitere Informationen zum Sichern von Websiteinhalten und zu fortgeschrittene-ren Szenarien, die sich auf den Inhaltszugriff beziehen und mit der Pass-Through-Authentifizierung und der eingeschränkten Delegierung arbeiten, finden Sie im vierzehnten Kapitel.

Das nächste Kapitel, Kapitel 10, erläutert, wie Anwendungen und Anwendungspools verwaltet werden, um einen zuverlässigen und sicheren Betrieb von Websites zu gewährleisten. Sie können ebenfalls das elfte Kapitel lesen, das weitere Informationen zur Verwendung von IIS 7.0 als Anwendungsserver bereithält. Dort ist auch das Hosten von Anwendungen unter Verwendung spezifischer Anwendungs-frameworks beschrieben. Zu diesen Frameworks zählen beispielsweise ASP, ASP.NET und PHP.


� Das vierte Kapitel, »Verstehen des Konfigurationssystems«, enthält Informationen zum neuen auf XML basierenden Konfigurationssystem und zu wichtigen IIS 7.0-Konfigurationsdateien.

� Das sechste Kapitel, »Verwenden von IIS-Manager«, hält Informationen über den Einsatz des IIS-Managers unter IIS 7.0 bereit.

� Das siebte Kapitel, »Verwenden von Befehlszeilentools«, beschreibt die Arbeit mit dem Befehls-zeilenhilfsmittel Appcmd unter IIS 7.0.

� Das zehnte Kapitel, »Verwalten von Anwendungen und Anwendungspools«, informiert über die Ver-waltung von Webanwendungen und Anwendungspools unter IIS 7.0.

� Das elfte Kapitel, »Hosting von Anwendungsentwicklungsframeworks«, hält Informationen zur Arbeit mit Anwendungsframeworks unter IIS 7.0 bereit.

� Das zwölfte Kapitel, »Verwalten von Webservermodulen«, enthält Informationen zur Konfiguration und Verwaltung systemeigener und verwalteter IIS 7.0-Module.

� Das vierzehnte Kapitel, »Implementieren von Sicherheitsstrategien«, beschreibt die Bereitstellung von SSL-Zertifikaten für Websites sowie verschiedene IIS 7.0-Sicherheitskonfigurationen.

� Das fünfzehnte Kapitel, »Protokollierung«, informiert über die verschiedenen Protokollierungs-verfahren, die von IIS 7.0 unterstützt werden.

� Das sechzehnte Kapitel, »Ablaufverfolgung und Problembehandlung«, enthält Informationen zur Aktivierung der Ablaufverfolgung für Anforderungsfehler sowie zu den Problembehandlungs-möglichkeiten von IIS 7.0.

� Mike Volodarskys Blog mit dem Titel »Creating IIS 7 Sites, Applications and Virtual Directories« beschäftigt sich mit den neuen Objektdefinitionen in IIS 7.0. Sie finden das Blog unter http://mvolo.com/blogs/serverside/archive/2007/07/12/Creating-IIS7-sites_2C00_-applications_2C00_-and-virtual-directories.aspx.


279

K A P I T E L 1 0

Verwalten von Anwendungen und Anwendungspools

Inhalt dieses Kapitels:� Webanwendungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

� Anwendungspools verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

� Arbeitsprozesse und Anforderungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302




Im neunten Kapitel, »Verwalten von Websites«, haben Sie die grundlegende Websitestruktur kennen gelernt und die Beziehungen zwischen den IIS-Schlüsselobjekten (Internet Information Services) untersucht, zu denen die Objekte für Anwendungen, virtuelle Verzeichnisse und Anwendungspools zählen.

In diesem Kapitel werden Sie sich eingehend mit der Verwaltung von IIS-Anwendungen und der Erstel-lung und Verwaltung von Anwendungspools beschäftigen, damit Sie Ihre IIS-Anwendungen voneinander isolieren können, was aus Gründen der Betriebssicherheit und der Sicherheit im Allgemeinen geschieht. Darüber hinaus werden die neuen Möglichkeiten zur Überwachung der Arbeit von Anwendungen und Anwendungspools vorgestellt.

Webanwendungen verwaltenEine Webanwendung ist ein Container, der aus der Perspektive der Laufzeitausführung betrachtet die Möglichkeit bietet, einen Teil des URL-Namespace einer Website abzusondern, wodurch die Ausfüh-rung der Containerinhalte potentiell von anderen Anwendungen isoliert und/oder der Laufzeitstatus (abhängig von der Anwendungsframeworktechnologie) von verschiedenen URLs der Anwendung gemeinsam genutzt werden kann. Ein Beispiel hierfür ist die Zuweisung eines Anwendungspools zu einer bestimmten Anwendung, wodurch diese durch eine Prozessgrenze von anderen Anwendungen isoliert wird. Die Anwendung ist außerdem die Ebene, auf der ASP.NET-Anwendungsdomänen und ASP-Anwendungen erstellt werden.

Bei IIS 7.0 muss jede Website eine Stammanwendung enthalten. Die Inhalte unterhalb dieses Stamm-pfades gehören ebenfalls zur Anwendung, aber nur bis zur nächsten Anwendung im selben Pfad. Das Webanwendungsobjekt von IIS 7.0 weist deutliche Unterschiede zu einem virtuellen Verzeichnis auf, da es einen eindeutigen virtuellen Pfad für jede Anwendung bildet, der Teil des URL-Namespace der Website ist. Jede Anwendung enthält mindestens ein virtuelles Verzeichnis, das als virtuelles Stamm-


280 Kapitel 10: Verwalten von Anwendungen und Anwendungspools

verzeichnis bezeichnet wird und das den Stamm des Anwendungs-URL-Namespace dem physikali-schen Stammverzeichnis der Anwendung zuordnet. Andererseits sind nicht alle virtuelle Verzeichnisse als Anwendungsstamm definiert, weil sie einfach keine Anwendungsstartpunkte, sondern anderen Anwendungen zugeordnet sind.

Webanwendungen erstellenBevor Sie dem Webserver eine neue Anwendung hinzufügen, sollten Sie darüber nachdenken, ob die Funktionalität innerhalb einer bereits vorhandenen Anwendung gehostet werden kann oder ob hierfür eine separate Anwendung notwendig ist. In der Regel erstellen Sie eine Anwendung unter einer der folgenden Bedingungen:

� Sie müssen Ihre Inhalte oder die Funktionalität in einem gesonderten Anwendungspool hosten, um sie aus Gründen der Ausfallsicherheit und der Sicherheit im Allgemeinen vom Rest der Website zu isolieren.

� Sie müssen Ihre Inhalte oder die Funktionalität in einem gesonderten Anwendungspool hosten, um den integrierten .NET-Modus konfigurieren zu können. Sie erstellen außerdem eine Anwendung, wenn die .NET Framework-Version oder die Bitness verglichen mit der übergeordneten Anwen-dung Unterschiede aufweist.

� Sie benötigen eine separate ASP- oder ASP.NET-Anwendung.

� Sie müssen den für Ihre Inhalte oder Funktionalität aktivierten IIS-Modulsatz erweitern, verringern oder modifizieren.

Stellen Sie sich beispielsweise vor, dass Sie neue Inhalte hinzufügen (z.B. Bilddateien), die keine eigene ASP.NET-Anwendungsdomäne erfordern und nicht in einem gesonderten Anwendungspool verwahrt werden müssen. Das entsprechende virtuelle Verzeichnis images sollte dann nicht als Webanwendung, sondern als normales virtuelles Verzeichnis konfiguriert werden, das den URL dem Verzeichnis zuordnet, das die Bilddateien enthält. Wenn Sie andererseits in einem Webportalsystem mit Einkaufswagenfunk-tionalität eine neue Zahlungsmethode anbieten möchten (z.B. für die Zahlung mit Kreditkarten) und Sie mit Drittanbieterkomponenten oder alten Komponenten arbeiten, die eine benutzerdefinierte Anpassung des Anwendungspools verlangen, dann sollten Sie eine neue Anwendung erstellen, die von einem geson-derten Anwendungspool gehostet wird. Die Anwendungsisolation hilft Ihnen, eine bessere Verfügbarkeit zu erzielen, da eine in einem eigenen Anwendungspool gehostete Anwendung von verschiedenen Arbeits-prozessen bedient wird. Sollte dann die neue Zahlungsmethodenanwendung Probleme verursachen, hätte dies keine Auswirkungen auf die Shopping-Webportalhautpanwendung.

Sie können Anwendungen für jeden beliebigen URL in Ihrer Website erstellen. Wenn Sie bei IIS 7.0 mit dem IIS-Manager eine neue Website hinzufügen, erzeugt das Tool automatisch eine Stammanwendung. Der IIS-Manager generiert außerdem standardmäßig einen neuen Anwendungspool und verknüpft diesen mit der Stammanwendung der Website. Mit dem IIS-Manager können Sie eine neue Webanwen-dung erzeugen, indem Sie entweder eine neue Anwendung direkt hinzufügen oder ein bereits vorhan-denes virtuelles Verzeichnis in eine Anwendung konvertieren. (Sie können auch später noch eine neue Anwendung für eine bereits vorhandene Website erstellen, selbst wenn es dort kein virtuelles Verzeich-nis gibt.) Unabhängig davon, für welche Möglichkeit Sie sich entscheiden, sollten Sie wissen, wie die Anwendung mit anderen Anwendungen interagiert und in welchem Anwendungspool die Webanwen-dung zu finden ist.


Webanwendungen verwalten 281

Wichtig Aus Sicherheitsgründen wird empfohlen, dass Sie sich an Ihrem Computer unter Verwendung eines Kontos anmelden, das über keine Administratorrechte verfügt. Dann benutzen Sie den runas-Befehl, um den IIS-Manager unter der Identität des Administrators ausführen zu lassen. Nehmen Sie an der Eingabeaufforderung beispielsweise die folgende Eingabe vor:runas /user:<admin_konto> "%windir%\system32\inetsrv\inetmgr.exe"

Um mit dem IIS-Manager eine neue Webanwendung zu erstellen, erweitern Sie im Hierarchielistenfeld des Bereichs Verbindungen den Knoten des IIS-Computers und dann den Knoten Sites. Klicken Sie mit der rechten Maustaste auf die Website, in der Sie eine Anwendung erstellen möchten, und wählen Sie Anwendung hinzufügen aus. Das Ergebnis ist in Abbildung 10.1 zu sehen.

Abbildung 10.1 Mit dem IIS-Manager eine neue Webanwendung erstellen

Der IIS-Manager generiert für die Anwendung automatisch ein virtuelles Stammverzeichnis. Dazu verwendet er den physikalischen Pfad, den Sie während der Anwendungserstellung angegeben haben. Sie können ebenfalls die Anmeldeinformationen konfigurieren, die für den Zugriff auf die Inhalte im Anwendungsstamm verwendet werden sollen, indem Sie die in Abbildung 10.1 dargestellte Option Verbinden als nutzen. Weitere Informationen zur Erstellung virtueller Verzeichnisse und zum Einstellen der Zugriffsanmeldeinformationen erhalten Sie im neunten Kapitel.

Um ein bereits vorhandenes physikalisches oder virtuelles Verzeichnis in einer Anwendung zu konver-tieren, erweitern Sie im Hierarchielistenfeld des Bereichs Verbindungen den Knoten des IIS-Computers und dann den Knoten Sites. Klicken Sie mit der rechten Maustaste auf das gewünschte Verzeichnis bzw. virtuelle Verzeichnis der Website und wählen Sie In Anwendung konvertieren aus, wie in Abbildung 10.2 dargestellt.

Daraufhin wird für diesen virtuellen Pfad automatisch eine Anwendung erzeugt und der entsprechende physikalische Pfad wird als virtuelles Stammverzeichnis der Anwendung eingerichtet. Ein bereits vor-handenes virtuelles Verzeichnis wird, sofern vorhanden, gelöscht und seine Einstellungen werden auf das neue virtuelle Stammverzeichnis der Anwendung übertragen.

Sie können die folgende Appcmd-Syntax benutzen, um eine neue Webanwendung hinzuzufügen:appcmd add app /site.name:string /path:string /physicalPath:string /applicationPool:string /enabledProtocols:string



Abbildung 10.2 Ein bereits vorhandenes physikalisches oder virtuelles Verzeichnis mit dem IIS-Manager in einen neuen Anwendungsstamm konvertieren

Tabelle 10.1 beschreibt die Parameter dieser Syntax.

Tabelle 10.1 Appcmd-Syntax zum Hinzufügen einer Webanwendung


site.name Der Name der Website, der die Anwendung hinzugefügt wird. Dieser Parameter muss angegeben werden.

path Der virtuelle Pfad der Anwendung. Die Pfadangabe muss mit / beginnen, z.B. /Stock. Dieser Parameter muss angegeben werden.

physicalPath Der physikalische Pfad des virtuellen Stammverzeichnisses der Anwendung. Bei Angabe dieses Wertes wird ein virtuelles Stammverzeichnis erstellt.

applicationPool Der Anwendungspool zum Hosten der Anwendung. Wird dieser Wert nicht angegeben, benutzt die Anwendung den Standardanwendungspool (DefaultAppPool).

enabledProtocols Eine Liste mit den Namen der Protokolle, die von dieser Anwendung benutzt werden können. Mehrere Protokolle werden durch Kommata voneinander getrennt angegeben. Der Standard ist HTTP.



Dieser Befehl kann nicht verwendet werden, um zusätzliche Einstellungen zu dem virtuellen Stamm-verzeichnis anzugeben, das erzeugt wird, wenn Sie den Parameter physicalPath angeben. Um zusätzliche Einstellungen festzulegen, zum Beispiel den Benutzernamen und das Kennwort für das virtuelle Verzeichnis, müssen Sie den Appcmd-Befehl SET VDIR einsetzen, mit dem Sie das virtuelle Stammver-zeichnis der Anwendung bearbeiten. Weitere Informationen hierzu finden Sie im neunten Kapitel.

Sie können die folgende Appcmd-Syntax mit den in Tabelle 10.2 beschriebenen Parametern verwenden, um eine bereits vorhandene Webanwendung zu ändern:appcmd set app AppName /path:string /applicationPool:string /enabledProtocols:string

Das folgende Beispiel erzeugt für Fabrikam HR (Human Resources; Personalabteilung) eine neue Webanwendung namens Stock. Der Anwendungsinhaltspfad wird dem physikalischen Ordner d:\fabrikamStock zugeordnet.appcmd add app /site.name:"Fabrikam HR" /path:/Stock /physicalPath:"d:\fabrikamStock"

Beachten Sie die Befehlsausgabe. Zwei Objekte wurden erzeugt: ein Objekt für die Anwendung und ein weiteres für das virtuelle Verzeichnis. Da das Beispiel den Parameter /physicalPath angibt, muss die Webanwendung ein virtuelles Stammverzeichnis enthalten. Wenn somit die neue Anwendung erstellt wird, wird auch automatisch eine Zuordnung zu einem virtuellen Stammverzeichnis generiert.Das APP-Objekt "Fabrikam HR/Stock" wurde hinzugefügt. Das VDIR-Objekt "Fabrikam HR/Stock" wurde hinzugefügt.

Wenn der Parameter /physicalPath nicht angegeben wird, erfolgt lediglich die Erstellung des APP-Objekts, da Appcmd nicht genügend Informationen besitzt, um das zugehörige virtuelle Verzeichnis zu gene-rieren. Nachfolgend ist ein Beispiel für einen solchen Befehl aufgeführt:appcmd add app /site.name:"Fabrikam HR" /path:/Benefit

Appcmd ermöglicht diese Verfahrensweise für Szenarien, in denen Sie das virtuelle Verzeichnis erst im zweiten Schritt erstellen können oder in denen Sie zusätzliche Einstellungen zum virtuellen Verzeichnis angeben müssen, die vom Befehl ADD APP nicht unterstützt werden. Das Ergebnis ist, dass Sie, wenn Sie diese Website mit dem IIS-Manager verwalten, eine Fehlermeldung erhalten, die Sie darüber infor-miert, dass für die Anwendung das entsprechende virtuelle Verzeichnis nicht vorhanden ist. Um diesen Fehler zu beheben, benutzen Sie Appcmd und fügen der Anwendung ein virtuelles Verzeichnis hinzu.

Hinweis Es ist nicht möglich, unter Verwendung des Appcmd-Befehls SET APP und des Parameters physicalPath ein virtuelles Stammverzeichnis für eine Anwendung zu erstellen.

Tabelle 10.2 Appcmd-Syntax zum Ändern einer Webanwendung


AppName Der virtuelle Pfad der Webanwendung

path Der virtuelle Pfad der Anwendung. Die Pfadangabe muss mit / beginnen, z.B. /Stock.

applicationPool Der Anwendungspool zum Hosten der Anwendung

enabledProtocols Eine Liste mit den Namen der Protokolle, die von dieser Anwendung benutzt werden können. Mehrere Protokolle werden durch Kommata voneinander getrennt angegeben. Der Standard ist HTTP.



Um einen bereits vorhandenen Anwendungsaliasnamen zu ändern (was mit dem IIS-Manager nicht möglich ist), können Sie den neuen Anwendungsnamen im Parameter /path angeben. Die folgende Syntax ändert beispielsweise den Anwendungspfad, so dass aus /myImages /images wird:appcmd set app /app.name:"Fabrikam HR/myImages" /path:/images

Um ein bereits vorhandenes Verzeichnis in eine Anwendung zu konvertieren, müssen Sie das bereits vorhandene virtuelle Verzeichnis zunächst löschen. Um dann die neue Anwendung zu erstellen, benutzen Sie das ADD-Verb zusammen mit dem Parameter /physicalPath. Auf diese Weise wird das neue virtuelle Stammverzeichnis der Anwendung automatisch generiert und verweist auf den richtigen physikalischen Pfad. (Oder Sie führen später eine manuelle Erstellung des virtuellen Stammverzeichnisses durch.) Der folgende Appcmd-Befehl entfernt beispielsweise das virtuelle Verzeichnis Payment aus dem Website-stamm und erzeugt es danach neu, und zwar als Anwendung, die in einem eigenen Anwendungspool ausgeführt wird:appcmd delete vdir "Fabrikam HR/Payment" appcmd add app /site.name:"Fabrikam HR" /path:/payment /physicalPath:"d:\HRPayment" /applicationPool: "HR Payment"

Beachten Sie, dass der erste Befehl das virtuelle Verzeichnis aus der Stammanwendung der Website entfernt. Da es sich hierbei lediglich um ein virtuelles Verzeichnis handelt, das sich in der Stamm-anwendung befindet, können Sie die DELETE APP-Syntax nicht benutzen, weil diese nur für Anwendungen zur Verfügung steht. Beim Löschen einer Anwendung löscht IIS nicht die physikalischen Dateisystem-inhalte des zugeordneten Pfades. Es löscht lediglich die Zuordnungsbeziehung zwischen dem Anwen-dungs-URL-Alias und dem physikalischen Ordner.

Vorsicht Entfernen Sie nicht die Stammanwendung einer Website. Das Löschen der Stammanwendung mit Appcmd würde die Website beenden.

Bevor sie eine neue Webanwendung erstellen oder ein bereits vorhandenes Verzeichnis in eine Anwen-dung konvertieren, fügte der IIS-Webkern dem <site>-Element der applicationHost.config-Datei ein neues <application>-Element hinzu. Gleichzeitig definiert ein <virtualDirectory>-Element unter dem <application>-Element den Anwendungsstammspfad. Nachfolgend ist die <site>-Konfiguration der neu erstellten Stock-Anwendung in der Website Fabrikam HR zu sehen:<sites> ... <site name="Fabrikam HR" id="9"> <application path="/"> <virtualDirectory path="/" physicalPath="d:\fabrikamHR" /> <virtualDirectory path="/images" physicalPath="g:\images" /> </application> <application path="/Stock"> <virtualDirectory path="/" physicalPath="d:\fabrikamStock" /> </application> <application path="/payment" applicationPool="HR Payment"> <virtualDirectory path="/" physicalPath="d:\HRPayment" /> </application> ... </site> ... </sites>



Webanwendungen auflistenIIS 6.0 bietet keine Möglichkeit, um nach einer bestimmten Webanwendung zu suchen und deren Daten anzeigen zu lassen. Bei IIS 7.0 können Sie sowohl mit dem IIS-Manager als auch mit Appcmd Web-anwendungen einfach lokalisieren und abfragen.

Um im IIS-Manager eine Liste der Webanwendungen anzeigen zu lassen, erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers und den Knoten Sites und markieren die Website, deren Webanwendungen angezeigt werden sollen. Klicken Sie im Bereich Aktionen auf Anwendungen anzei-gen, um wie in Abbildung 10.3 dargestellt die Liste der Webanwendungen zu erhalten, die Sie sortieren, filtern und gruppieren können.

Abbildung 10.3 Webanwendungen mit dem IIS-Manager auflisten

Benutzen Sie die folgende Appcmd-Syntax, um eine Abfrage zu starten, die eine Liste von Webanwen-dungen zurückgibt:appcmd list app AppPath /site.name:string /apppool.name:string

Tabelle 10.3 beschreibt die Parameter dieser Syntax.



Das folgende Beispiel fragt die Konfigurationsdetails der Webanwendung Stock ab:appcmd list app "Fabrikam HR/Stock"

Wie die folgende Ausgabe zeigt, wird die Stock-Anwendung im Anwendungspool Fabrikam Stock ausgeführt:APP ""Fabrikam HR/Stock" (applicationPool:Fabrikam Stock)

Um alle Webanwendungen des Webservers aufzulisten, benutzen Sie den folgenden Befehl:appcmd list app

Die resultierende Ausgabe listet wie nachfolgend gezeigt alle Webanwendungen auf:APP "Contoso Corp/"" (applicationPool:DefaultAppPool) APP "Contoso Corp/payment" (applicationPool:MyAppPool) APP "Fabrikam HR/" (applicationPool:DefaultAppPool) APP "Fabrikam HR/Stock" (applicationPool:Fabrikam Stock)

Um alle mit Fabrikam HR verknüpften Anwendungen anzeigen zu lassen, verwenden Sie den folgen-den Befehl:appcmd list app /site.name:"Fabrikam HR"

Dieses Beispiel fragt das Konfigurationssystem ab und zeigt alle Anwendungsobjekte an, die zur Web-site Fabrikam HR gehören. Die resultierende Ausgabe präsentiert sich wie folgt:APP "Fabrikam HR/" (applicationPool:DefaultAppPool) APP "Fabrikam HR/Stock" (applicationPool:Fabrikam Stock)

Um nach einer Anwendung zu suchen, die von einem bestimmten Anwendungspool gehostet wird, können Sie den Parameter /apppool.name benutzen. Um beispielsweise alle Anwendungen aufzulisten, die dem Anwendungspool DefaultAppPool zugeordnet sind, benutzen Sie den folgenden Befehl:appcmd list app /apppool.name:"DefaultAppPool"

Dies würde zur folgenden Ausgabe führen:APP "Contoso Corp/" (applicationPool:DefaultAppPool) APP "Fabrikam HR/" (applicationPool:DefaultAppPool)

Um alle Stammanwendungen aller Websites zu finden, arbeiten Sie mit dem folgenden Befehl:appcmd list app /path:"/"

Wenn Sie im Befehl /path:"/" angeben, weisen Sie IIS an, nach allen Anwendungen zu suchen, deren path-Attribut / ist, oder alle Anwendungen des Servers aufzulisten, die Stammanwendungen ihrer

Tabelle 10.3 Appcmd-Syntax zum Abfragen einer Webanwendungsliste


AppPath Der Name der Webanwendung. Der Name der Anwendung ist der Websitename kombiniert mit dem virtuellen Pfad der Anwendung. Wird der Parameter nicht angegeben, zeigt die Abfrage alle Webanwendungen des Webservers an.

Er kann ebenfalls einen URL angeben. Appcmd zeigt dann die Anwendung an, die diesen URL enthält.

site.name Der Name der übergeordneten Website. Bei Angabe dieses Parameters werden alle Anwendungen der angegebenen Website aufgelistet.

apppool.name Der Name des Anwendungspools. Bei Angabe dieses Parameters werden alle Anwendungen aufgelistet, die diesem Anwendungspool zugeordnet sind.


Anwendungspools verwalten 287

Websites sind. Sie können zum Filtern der Ausgabe auch jeden anderen Parameter des Anwendungs-objekts benutzen. Um weitere Informationen zur Suche nach Objekten zu erhalten, lesen Sie bitte das siebte Kapitel, »Verwenden von Befehlszeilentools«.

Anwendungspools verwaltenAnwendungspools erleichtern das Hosten von Webanwendungen – die dieselbe Konfiguration verwenden – in eigenen IIS-Arbeitsprozessen. Anwendungspools ermöglichen es Ihnen, Anwendungen aus Gründen der besseren Sicherheit, Zuverlässigkeit und Verfügbarkeit zu isolieren. Der Arbeitsprozess dient als Prozessgrenze, die die Anwendungspools voneinander trennt, so dass mögliche Probleme eines Arbeits-prozesses oder einer Anwendung keine Auswirkungen auf andere Anwendungen oder Arbeitsprozesse haben. Stellen Sie sich beispielsweise vor, dass Sie eine alte ASP-Anwendung installieren möchten, die ältere Komponentenobjekte verwendet. Um die anderen Anwendungen in der Websites zu schützen, können Sie einen neuen Anwendungspool erstellen und die alte Anwendung in diesem neuen Anwen-dungspool hosten. In diesem Fall würde sich ein Absturz der alten Anwendung nicht auf die anderen Anwendungen auswirken, da die alte Anwendung von einem anderen Anwendungspool bereitgestellt wird.

Jeder Anwendungspool kann mit mehreren Arbeitsprozessen arbeiten, die dem Anwendungspool ihre Dienste zur Verfügung stellen. Jeder Arbeitsprozess kann jedoch immer nur einem Anwendungspool zugeordnet sein.

WebgärtenEin Anwendungspool mit mehr als einem Arbeitsprozess wird als Webgarten bezeichnet. Viele Arbeitsprozesse, die dieselbe Anwendung bedienen, können bisweilen zu einer besseren Durchsatz-leistung und Anwendungsreaktionszeit führen. Beachten Sie, dass jeder Arbeitsprozess eines Web-gartens eigene Prozessthreads und einen eigenen Arbeitsspeicherbereich besitzt. Wenn die Anwen-dung mit prozessinternen Sitzungsvariablen arbeitet, wird sie nicht richtig funktionieren, weil dieselben Benutzeranforderungen von verschiedenen Arbeitsprozessen entgegengenommen werden, die wiederum nicht mit gemeinsam genutzten Sitzungsdaten arbeiten. ASP.NET-Anwendungen können dieses Problem umgehen, indem Sie eine prozessexterne Sitzungsverwaltung nutzen, wie zum Beispiel den Sitzungszustandsdienst oder einen auf SQL Server basierenden Sitzungszustand.

Webgärten sind meistens nicht empfehlenswert, weil sie zu Leistungseinbußen führen können, was nur in sehr spezifischen Fällen nicht geschieht, z.B. wenn:

� Ihre Anwendung synchrone Anforderungen initiiert, die über einen längeren Zeitraum ausge-führt werden und die Parallelität beeinträchtigen.

� Ihre Anwendung instabil ist und oft abstürzt, so dass der Einsatz mehrerer Prozesse hilft, die Verfügbarkeit aufrechtzuerhalten. (In diesem Fall bestünde die beste Lösung natürlich darin, die Fehler in der Anwendung zu beheben.)

� Ihre Anwendung über nicht genügende prozessweite Ressourcen verfügt oder mit prozessweiten Sperrungen arbeitet, die die Parallelität wesentlich beeinträchtigen.

In den meisten dieser Fälle sollten Sie Ihre Anwendung überarbeiten, so dass sie Anforderungen, die über einen längeren Zeitraum ausgeführt werden, asynchron ausführt, prozessweite Sperrungen ausschließt und Abstürze verhindert. Dies ist längerfristig betrachtet eine bessere Lösung als der Einsatz von Webgärten.



Überlegungen zu AnwendungspoolsWenn IIS 7.0 installiert wird, gibt es standardmäßig zwei vordefinierte Anwendungspools. Wie Tabelle 10.4 zeigt, gibt es zwei Anwendungspools mit unterschiedlichen Arbeitsprozessmodellen. Die Rolle Webserver (IIS) erzeugt den Anwendungspool DefaultAppPool, der der Standardanwendungspool für neue Anwendungen ist. Das Setup des Rollendienstes ASP.NET generiert den klassischen .NET-Anwendungspool (Classic .NET AppPool), damit ASP.NET-Anwendungen im klassischen ASP.NET-Integrationsmodus ausgeführt werden können. Sie können Anwendungen für die Ausführung in diesen Standardanwendungspools konfigurieren, aber Sie können auch neue Anwendungspools erstellen.

Hinweis Der Anwendungspool Classic .NET AppPool wird während der Installation von ASP.NET 2.0 erstellt. Die Installation des .NET Framework 1.1 ruft das Tool aspnet_regiis.exe auf, um ASP.NET 1.1 zu installieren. Dabei wird der ASP.NET 1.1-Anwendungspool erzeugt.

Keiner der beiden Anwendungspools wird bei der Installation von IIS 7.0 standardmäßig erstellt. Weitere Informa-tionen darüber, wie diese Anwendungspools verwendet werden, um die ASP.NET-Versionen von ASP.NET-Anwendungen zu verwalten, finden Sie im elften Kapitel, »Hosting von Anwendungsentwicklungsframeworks«.

Bevor Sie einen neuen Anwendungspool erstellen, sollten Sie – aus verschiedenen Blickwinkeln betrach-tet – darüber nachdenken, ob ein solcher Anwendungspool notwendig ist. Da jeder Anwendungspool die Dienste von mindestens einem dedizierten Arbeitsprozess beansprucht, nimmt mit der Zahl der Anwen-dungspools auch die Zahl der Arbeitsprozesse zu, die im System ausgeführt werden, um auf dem Server die Anforderungen zu verarbeiten, die sich auf die jeweiligen Anwendungen beziehen. Dies kann die Systemleistung insgesamt beeinträchtigen, weil jeder Arbeitsprozess Systemressourcen verbraucht, wie z.B. Prozessorzeit und Arbeitsspeicher. Dennoch führt der Einsatz von separaten Anwendungspools für verschiedene Anwendungen bei den meisten Administratoren niemals zu irgendwelchen Problemen.

Hinweis Aus Gründen der Ausfallsicherheit sollten Sie immer versuchen, für jede Anwendung (und Website) einen eigenen Anwendungspool zu verwenden. Dies ermöglicht es Ihnen eventuell, die Vorteile zu nutzen, die mit dem Prinzip der Vergabe von geringstmöglichen Rechten einhergehen. Dabei gewähren Sie jeder Anwendungspooliden-tität die geringstmöglichen Rechte, was dazu beiträgt, dass die Anwendungen voneinander isoliert werden. Lesen Sie das vierzehnte Kapitel, »Implementieren von Sicherheitsstrategien«, um Techniken für die Anwendungspooliso-lation kennenzulernen.

Wenn Sie mit tausenden von Pools arbeiten oder Ihre Leistungsdaten zeigen, dass die Konfiguration mehrerer Pools zu Leistungseinbußen führt, sollten Sie den Einschub »Kapazitätsanalyse für eine große Anzahl von Anwendungspools« lesen. Microsoft empfiehlt selbst für Shared Hostingserver eine Isola-tion, bei der jede Site einen eigenen Pool erhält, weil IIS 7.0 in diesem Fall eine bessere Sitedichte bietet.

Tabelle 10.4 Vordefinierte Anwendungspools

Anwendungspool .NET Framework Verwalteter Pipelinemodus Identität

Classic .NET AppPool Version 2.0 Klassisch NetworkService

DefaultAppPool Version 2.0 Integriert NetworkService



Berücksichtigen Sie die folgenden Faktoren, bevor Sie neue Anwendungspools erstellen:

� Sicherheit Sie können einen neuen Anwendungspool erstellen und eine benutzerdefinierte Anwendungspoolidentität mit Zugriffsrechten konfigurieren, wenn eine Anwendung für bestimmte Ressourcen einen benutzerdefinierten Zugriff verlangt. Eine benutzerdefinierte Anwendung, die die Systemkonfiguration aktualisiert, ist ein Beispiel für solch eine Situation. Ein weiteres Beispiel sind Anwendungen, die zwei verschiedenen Kunden zugeordnet sind, und jeder Kunde darf nur auf die für ihn bestimmten Inhalte zugreifen. Kapitel 14 beschäftigt sich ausführlich mit diesen Themen.

� Ausfallsicherheit Sie können einen neuen Anwendungspool erstellen, um instabile oder neue Anwendungen zu isolieren. Sie können beispielsweise eine Anwendung isolieren, die mit alten Komponenten arbeitet und gelegentlich abstürzt, oder Sie sondern neue, zu integrierende Anwen-dungen ab, die sich noch in der Testphase befinden. Das Isolieren solcher Anwendungen verbessert die Ausfallsicherheit der anderen Anwendungen, da sich Fehler, die bei veralteten oder Testanwen-dungen auftreten, nicht auf die anderen Anwendungen auswirken werden.

� Anpassung Sie können einen neuen Anwendungspool erstellen, wenn eine Anwendung andere Anwendungspooleinstellungen erfordert. Solch eine Situation entsteht, wenn Sie mit einer alten Anwendung arbeiten, die unter Verwendung des klassischen Prozessmodells ausgeführt werden muss, während andere Anwendungen im integrierten Modus laufen. (Der integrierte Modus wird im elften Kapitel erläutert.) Bei IIS 7.0 sind der ASP.NET-Integrationsmodus und die .NET Frame-work-Version auf der Anwendungspoolebene konfigurierbar. Darüber hinaus können Sie, wenn Sie einen neuen Anwendungspool erstellen, einen eindeutigen Satz Arbeitsprozesseinstellungen konfigurieren (wie z.B. das Intervall für die Wiederverwendung des Anwendungspools oder die Warteschlangengröße), die sich von den allgemeinen Anwendungspooleinstellungen unterscheiden. Vielleicht möchten Sie auch Anwendungen abhängig vom Anwendungstyp isolieren. Sie könnten beispielsweise verschiedene Anwendungspools für ASP und ASP.NET verwenden.

Hinweis Obwohl IIS 7.0 die Parallelausführung von Anwendungen unterstützt, die mit verschiedenen .NET Frame-work-Versionen arbeiten, sollten Sie wissen, dass verschiedene .NET Framework-Anwendungen auch verschie-dene Anwendungspools erfordern, da jeder Anwendungspools immer nur einer .NET Framework-Laufzeitversion zugeordnet ist.

Kapazitätsanalyse für eine große Anzahl von AnwendungspoolsEs gibt keine feste Formel, um die maximale Anzahl von Arbeitsprozessen zu ermitteln, die auf einem Server ausgeführt werden können. Wie beim Ermitteln der maximalen Anzahl von Websites, die unter IIS 7.0 gehostet werden können, müssen Sie für viele gleichzeitig ausgeführte Arbeitsprozesse Kapa-zitätsanalysen durchführen, um die Gesamtleistung des Systems zu bewerten. Die Analyse sollte darin bestehen, einen Blick auf den Speicherverbrauch der Anwendung bei hoher Auslastung, die Auswir-kungen der Wiederverwendung, die Anzahl gleichzeitiger Anforderungen pro Anwendung usw. zu werfen. Auf die Leistung bezogene Auslastungstests helfen bei dieser Analyse. Sie können Microsoft Visual Studio Team Edition sowie das Webkapazitätsanalysetool (Web Capacity Analysis Tool, WCAT) benutzen, wenn Sie Unterstützung bei diesen Auswertungen benötigen. Als Webadministrator müssen Sie einschätzen, wie wichtig dedizierte Anwendungspools sind. Danach müssen Sie für Ihren Web-server die richtige Balance zwischen Anwendungsisolation und Durchsatzleistung finden. Weitere Informationen zu WCAT erhalten Sie unter http://www.iis.net/downloads/default.aspx?tabid=34&g= 6&i=1466.



Einen neuen Anwendungspool hinzufügenUm mit dem IIS-Manager einen neuen Anwendungspool zu erstellen, erweitern Sie im Bereich Verbin-dungen den Knoten des IIS Computers und navigieren zum Knoten Anwendungspools. Klicken Sie mit der rechten Maustaste auf den Knoten Anwendungspools und wählen Sie Anwendungspool hinzufügen. Alternativ hierzu klicken Sie im Bereich Aktionen auf Anwendungspool hinzufügen. Das Ergebnis ist in Abbildung 10.4 dargestellt.

Abbildung 10.4 Mit dem IIS-Manager einen neuen Anwendungspool hinzufügen

Hinweis Wenn Sie den IIS-Manager benutzen, um einen Anwendungspool hinzuzufügen, aktivieren Sie das Kontrollkästchen Anwendungspool sofort starten, sofern Sie den Anwendungspool direkt nach seiner Erstellung starten möchten.

Wenn eine Anwendung eine Anforderung von einem nicht ausgeführten Anwendungspool entgegennimmt, gibt IIS 7.0 den HTTP-Fehler 503 an den Clientbrowser zurück. Dieser Fehler informiert darüber, dass ein Dienst nicht verfügbar ist.

Nachdem Sie einen Anwendungspool erstellt haben, können Sie entweder eine neue Anwendung darin ausführen lassen oder Sie weisen den neuen Anwendungspool einer bereits vorhandenen Anwendungen zu. Um einen Anwendungspool einer bereits vorhandenen Anwendung zuzuweisen, benutzen Sie den IIS-Manager. Erweitern Sie im Hierarchielistenfeld des Bereichs Verbindungen den Knoten des IIS-Compu-ters und dann den Knoten Sites. Erweitern Sie auch den Knoten der Website, die die gewünschte Anwen-dung enthält. Markieren Sie diese Anwendung und klicken Sie im Bereich Aktionen auf Grundeinstel-lungen. Klicken Sie auf die Schaltfläche Auswählen, um den neuen Anwendungspool aus der Liste der verfügbaren Anwendungspools auszuwählen, wie in Abbildung 10.5 dargestellt.

Abbildung 10.5 Einen Anwendungspool mit dem IIS-Manager einer bereits vorhandenen Anwendung zuweisen



Vorsicht Wird einer ausgeführten Anwendung ein neuer Anwendungspool zugewiesen oder erfolgt für solch eine Anwendung ein Anwendungspoolwechsel, kann dies dazu führen, dass die Anwendung zwar in den neuen Arbeits-prozess des neu zugewiesenen Anwendungspools geladen wird, dieser aber die Anwendungsdaten oder -variablen im alten Arbeitsprozess nicht sehen kann. Die Anwendung wird dann die begonnene Bearbeitung der Anforderungen aus dem alten Arbeitsprozess abschließen. Nachdem jedoch die Änderungen vorgenommen und vom ursprünglichen Arbeitsprozess erkannt wurden, empfängt die Anwendung von dort keine weiteren Folgeanforderungen mehr.

Benutzen sie die folgende Appcmd-Syntax, um einen neuen Anwendungspool zu erstellen:appcmd add apppool /name:string /managedPipelineMode:enum /managedRuntimeVersion:string

Um die Eigenschaften eines bereits vorhandenen Anwendungspools zu setzen, verwenden Sie die folgende Syntax:appcmd set apppool ApppoolName /managedPipelineMode:enum /managedRuntimeVersion:string

Tabelle 10.5 beschreibt die Parameter von ADD APPPOOL und SET APPPOOL.

Der folgende Befehl erzeugt einen neuen Anwendungspool mit dem Namen Fabrikam Stock:appcmd add apppool /name:"Fabrikam Stock"

Die nachfolgend gezeigte Ausgabe verrät, dass dem Konfigurationsspeicher ein neues Anwendungspoolobjekt hinzugefügt wurde:Das APPPOOL-Objekt "Fabrikam Stock" wurde hinzugefügt

Um die Grundeinstellungen des neuen Anwendungspools zu ändern, z.B. das Prozessmodell und die .NET-Laufzeitversion, benutzen Sie den SET-Befehl. Die folgende Anweisung rekonfiguriert den neu erstellten Farbrikam Stock-Anwendungspool für die Ausführung unter .NET, Laufzeitversion 1.1 und sie ändert das Prozessmodell, so dass der klassische ISAPI-Modus genutzt wird.appcmd set apppool /apppool.name:"FabrikamStock" /managedRuntimeVersion:"v1.1" /managedPipelineMode:"Classic"

Hinweis Damit das .NET Framework, Version 1.1, unterstützt werden kann, müssen Sie es installieren. Während dieser Installation wird standardmäßig ein neuer Anwendungspool namens ASP.NET 1.1 erzeugt. Dieser neue Anwendungspool ist so konfiguriert, dass er für die Ausführung das klassische Arbeitsprozessmodell und das .NET Framework, Laufzeitversion 1.1, verwendet. Weitere Informationen zur ASP.NET-Versionsverwaltung finden Sie im elften Kapitel.

Tabelle 10.5 Appcmd-Syntax zum Konfigurieren von Anwendungspooleigenschaften


name Der Name des neuen Anwendungspools. Muss zum Hinzufügen eines Anwendungspools ange-geben werden.

AppPoolName Der Anwendungspoolname. Muss zur Bearbeitung eines bereits vorhandenen Anwendungspools angegeben werden.

managedRuntimeVersion Gibt die .NET-Laufzeitversion für den Anwendungspool an. Kann "v1.1", "v2.0" oder "" für keine CLR (Common Language Runtime) sein. Zukünftige Versionen des .NET Frameworks werden neue Versionszeichenfolgen unterstützen. Der Standard ist v2.0.

managedPipelineMode Der ASP.NET-Integrationsmodus des Anwendungspools. Zulässige Werte sind Classic und Integrated. Die Vorgabe ist Integrated.



Sobald der neue Anwendungspool bereit ist, können Sie entweder eine neue Anwendung darin aus-führen lassen oder den Pool einer bereits vorhandenen Anwendung zuweisen. Die folgende Syntax konfiguriert beispielsweise die bereits vorhandene Stock-Anwendung, so dass sie im Anwendungspool Farbrikam Stock ausgeführt wird:appcmd set app "Fabrikam HR/Stock" /applicationPool:"Fabrikam Stock"

Vorsicht Wenn Sie mit Appcmd arbeiten, um den Anwendungspool einer Anwendung festzulegen, prüft das Befehlszeilentool nicht, ob der angegebene Anwendungspool im Konfigurationssystem vorhanden ist. Gibt es den Anwendungspool nicht, kann die Anwendung zur Laufzeit nicht geladen werden.

Wenn Sie einen neuen Anwendungspool hinzufügen, erzeugt das Konfigurationssystem in der applicationHost.config-Datei im Abschnitt <applicationPools> ein neues Anwendungspoolelement. Das Element enthält den Namen des Anwendungspools, das Arbeitsprozessmodell und die Prozessidentität, sofern sich diese Angaben von den Standardeinstellungen unterscheiden. Nachfolgend ist die <applica-tionPools>-Konfiguration des neu erstellten Farbrikam Stock-Anwendungspools aufgeführt, die sich in dem Abschnitt für die .NET Framework-Laufzeitversion 1.1 befindet:<applicationPools> <add name="DefaultAppPool" /> <add name="Classic .NET AppPool" managedPipelineMode="Classic" /> <add name="ASP.NET 1.1" managedRuntimeVersion="V1.1" managedPipelineMode="Classic" /> <add name="Fabrikam Stock" managedRuntimeVersion="V1.1" managedPipelineMode="Classic" /> <applicationPoolDefaults> <processModel identityType="NetworkService" /> </applicationPoolDefaults> </applicationPools>

Wenn Sie einer bereits vorhandenen Anwendung einen neuen Anwendungspool zuweisen, wird innerhalb des <site>-Elements das <application>-Element vom IIS-Webkern aktualisiert. Weitere Informationen finden Sie später in diesem Kapitel, im Abschnitt »Webanwendungen verwalten«.

Anwendungspoolidentitäten verwaltenSie können die Identität, unter der Arbeitsprozesse im Anwendungspool ausgeführt werden, konfigurieren, indem Sie dem Anwendungspool ein Konto zuweisen. Die Konfiguration der Anwendungspoolidentität ist ein wichtiger Aspekt der IIS 7.0-Sicherheit, da sie die Identität des Arbeitsprozesses bestimmt, wenn dieser auf Ressourcen zugreift. Bei IIS 5.0 wird der Prozess unter dem Konto LocalSystem ausgeführt. Dies wirkt sich wesentlich auf die Sicherheit aus, weil das Benutzerkonto über umfassende Zugriffsrechte verfügt. Bei IIS 6.0 änderte sich dies mit der Einführung eines Anwendungspools, für den NetworkService die Standardanwendungspoolidentität ist. IIS 7.0 verwendet dieselben vordefinierten Arbeitsprozess-identitäten wie IIS 6.0. Tabelle 10.6 zeigt die integrierten Anwendungsidentitäten von IIS 7.0.

Sie können basierend auf den integrierten Konten benutzerdefinierte Benutzerkonten erstellen, unter deren Identitäten die Arbeitsprozesse ausgeführt werden sollen. Kapitel 14 beschäftigt sich ausführlich hiermit. Sie erfahren später in diesem Kapitel im Abschnitt »Die Anwendungspoolidentität konfigurieren« mehr über die Konfiguration eines benutzerdefinierten Kontos als Anwendungspoolidentität.



Sicherheitskontenänderungen bei IIS 7.0Bei IIS 7.0 wurde sowohl das anonyme Benutzerkonto (IUSR_computername) als auch die Benutzer-gruppe IIS_WPG entfernt und durch integrierte Systemkonten anstelle normaler Benutzer- und Gruppen-konten ersetzt. Die Nutzung einer integrierten vordefinierten SID (Security Identifier) gewährleistet, dass bei einem IIS 7.0-Remotecomputer dieselben Konten vorhanden sind. Der Einsatz integrierter Konten trägt außerdem dazu bei, dass Sie sich nicht mit Problemen beschäftigen müssen, die Benutzeranmelde-informationen betreffen, wie z.B. die Gültigkeitsdauer von Kennwörtern. Während der IIS 7.0-Installation werden die folgenden integrierten Konten erstellt:

� IUSR Das Standardbenutzerkonto für die anonyme Identität; ersetzt das Konto IUSR_computer-name

� IIS_IUSRS Neue integrierte Benutzergruppe; ersetzt die Gruppe IIS_WPG

Hinweis IUSR_computername wird erzeugt, wenn unter Windows Server 2008 der Rollendienst FTP-Publishing-dienst (früher unter IIS 6.0 der FTP-Dienst) installiert ist.

IIS 7.0 für zwei zusätzliche Erweiterungen ein, die sich auf die Anwendungspoolidentität beziehen und auf die Änderungen aufsetzen, die die Sicherheitsbenutzer- und Sicherheitsgruppenkonten betreffen:

� Anonymes Konto als Anwendungspoolidentität Legt das anonyme Konto als Anwendungs-poolidentität fest. (Setzen Sie einfach im Konfigurationsabschnitt anonymousAuthentication das userName-Attribut auf einen leeren Wert. Um dieses neue Feature kennen zu lernen, lesen Sie bitte das vier-zehnte Kapitel.) Der Hauptvorteile der Konfiguration des anonymen Benutzers als Anwendungs-poolidentität besteht darin, dass Sie nicht die Sicherheit für ein separates Konto verwalten müssen.

� Automatische IIS_IUSRS-Mitgliedschaft Wenn Sie bei IIS 6.0 eine benutzerdefinierte Anwen-dungspoolidentität konfigurieren, muss das benutzerdefinierte Konto ein Mitglied von IIS_WPG sein, weil diese Benutzergruppe über vorkonfigurierte Zugriffsberechtigungen und das Recht verfügt, Arbeitsprozesse zu starten. Bei IIS 7.0 besitzt die Benutzergruppe IIS_IUSRS ähnliche Zugriffsberechtigungen und Rechte. Das benutzerdefinierte Konto muss jedoch nicht explizit der Gruppe IIS_IUSRS hinzugefügt werden, da dies bei IIS 7.0 implizit geschieht. (Die Anwendungs-poolidentität wird aber nicht der Gruppe IIS_IUSRS hinzugefügt. Die Gruppen-SID wird zur

Tabelle 10.6 Integrierte Anwendungspoolidentitäten

Identität Beschreibung

LocalSystem LocalSystem ist ein integriertes Konto, das auf dem Server über administrative Rechte verfügt. Es kann sowohl auf lokale Ressourcen als auch auf Remoteressourcen zugreifen. Das Konto besitzt im Prinzip ähnliche Zugriffs-rechte wie das Konto des Systemadministrators. Es kann uneingeschränkt auf lokale Ressourcen zugreifen. Anwendungspools sollte diese Identität niemals zugewiesen werden. (Wenn eine Anwendung diese Identität ver-langt, ist das ein Zeichen dafür, dass sie schlecht geplant wurde, und Sie sollten in diesem Fall ernsthaft darüber nachdenken, die Anwendung zu überarbeiten, so dass sie nicht mehr administrative Rechte erfordert.)

LocalService Das Konto LocalService ist ein spezielles integriertes Konto, das ähnlich wie ein authentifiziertes lokales Benutzerkonto über reduzierte Rechte verfügt. Es besitzt keine Netzwerkzugriffsrechte.

NetworkService NetworkService ist ein integriertes Konto, das ähnlich wie ein authentifiziertes lokales Benutzerkonto über reduzierte Rechte verfügt. Es kann als Computerkonto auf Remoteressourcen zugreifen. Es ist das Standard-konto, das von IIS-Anwendungspools verwendet wird, und es kann eingeschränkt auf Ressourcen zugreifen, die sich auf dem lokalen Computer und auf Remotecomputern befinden.



Laufzeit in das Arbeitsprozesstoken eingefügt, so dass es als Mitglied von IIS_IUSRS agiert. An der lokalen Benutzerdatenbank oder an der Active Directory-Verzeichnisdienst-Domänengruppen-mitgliedschaft werden keine Änderungen vorgenommen.)

Wünschen Sie das IIS 6.0-Verhalten, können Sie die IIS_IUSRS-Gruppenmitgliedschaft manuell konfigurieren. Diese Einstellung wird für einzelne Anwendungspools vorgenommen, so dass Sie für den Anwendungspool, dessen Gruppenmitgliedschaft manuell konfiguriert werden soll, das benutzerdefinierte Konto der Gruppe IIS_IUSRS explizit hinzufügen müssen. Die folgende Appcmd-Syntax konfiguriert DefaultAppPool für die manuelle IIS_IUSRS-Gruppenmitgliedschaft:appcmd set apppool "DefaultAppPool" /processModel.manualGroupMembership:True

Die Anwendungspoolidentität konfigurierenNetworkService ist ein Konto mit reduzierten Zugriffsrechten. Vielleicht möchten Sie deshalb die Arbeits-prozessidentität gemäß Ihren geschäftlichen Anforderungen ändern. Eine Sicherheitsanwendung könnte beispielsweise den Zugriff auf Systemressourcen erfordern, für die NetworkService nicht die notwen-digen Rechte besitzt. In diesem Fall könnten Sie den Arbeitsprozess unter der Identität eines benutzer-definierten Kontos mit den erforderlichen Zugriffsrechten ausführen lassen. Das vierzehnte Kapitel beschäftigt sich mit der Verwaltung von Anwendungspoolidentitäten, wobei auch die Sicherheit behandelt wird.

Direkt von der Quelle: Anwendungspools für Sandbox-Anwendungen verwendenDer Anwendungspool ist für IIS-Anwendungen das grundlegende Isolationselement, weil er den Anwendungscode in einem gesonderten IIS-Arbeitsprozess isoliert und die Abschirmung des externen Zugriffs von den Ressourcen innerhalb des Prozesses ermöglicht, indem ACLs (Access Control List) auf die Anwendungspoolidentität angewendet und dieser Identität Rechte gewährt oder verweigert werden. Der Einsatz von Anwendungspools macht es möglich, eine gründlichere Isolation zwischen den Anwendungen desselben Servers zu erzielen, als dies mit anderen Techniken, z.B. dem Identitäts-wechsel oder dem teilweise vertrauenswürdigen ASP.NET-Sandboxing, möglich ist.

IIS 7.0 geht noch einen Schritt weiter und sorgt dafür, dass Anwendungspools in Isolationsszenarien effektiv genutzt werden können. Dazu stellt es automatisch eine eindeutige Konto-SID (Security Identifier) für jeden Anwendungspool zur Verfügung. Diese SID kann für die Sicherung der Ressour-cen des Anwendungspools mithilfe von ACLs verwendet werden. Der Windows-Prozessaktivierungs-dienst (auch bekannt als WAS) generiert solche SIDs automatisch, so dass Sie nicht gezwungen sind, benutzerdefinierte Anwendungspoolidentitäten zu erstellen und zu benutzen. Noch wichtiger ist, dass IIS 7.0 ebenfalls die globale Serverkonfiguration automatisch isoliert, indem es für jeden Anwendungs-pool gefilterte Kopien der Konfigurationsdatei applicationHost.config generiert, die nur die Konfigura-tionen enthalten, die den jeweiligen Anwendungspool betreffen. Konfigurationen für andere Anwen-dungspools, z.B. deren Anwendungspooldefinitionen und Identitätsinformationen, sind darin nicht enthalten.

Zusammen mit der größeren Arbeitsprozessdichte tragen diese Verbesserungen dazu bei, dass es noch nie einfacher war, mithilfe von Anwendungspools echte Sandbox-Anwendungsumgebungen zu schaffen.

Mike Volodarsky




Um mit dem IIS-Manager die Anwendungspoolidentität zu konfigurieren, erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers und markieren den Knoten Anwendungspools. Markieren Sie auf der Seite Anwendungspools den Anwendungspool, für den Sie das Identitätskonto ändern möchten. Klicken Sie im Bereich Aktionen auf Erweiterte Einstellungen. Markieren Sie im Dialogfeld Erweiterte Einstellungen und dort im Abschnitt Prozessmodell die Eigenschaft Identität und klicken Sie auf die Schaltfläche zum Durchsuchen (...), um das Dialogfeld Identität des Anwendungspools anzeigen zu lassen, das in Abbildung 10.6 dargestellt ist.

Abbildung 10.6 Die Anwendungspoolidentität mit dem IIS-Manager konfigurieren

Vorsicht Wenn Sie die Anwendungspoolidentität ändern, fährt IIS 7.0 den aktuellen Arbeitsprozess herunter, sofern er ausgeführt wird, und initiiert einen neuen Arbeitsprozess mit der ausgewählten Benutzeridentität. Dies wirkt sich auf die Verfügbarkeit der Anwendung aus, und während des Anwendungspoolwechsels gehen Sitzungs-daten verloren.

Benutzen Sie die folgende Appcmd-Syntax und die in Tabelle 10.7 beschriebenen Parameter, um die Anwendungspoolidentität zu konfigurieren:appcmd set apppool ApppoolName /processModel.identityType:enum /processModel.userName:string /processModel.password:string

Das folgende Beispiel ändert die Arbeitsprozessstandardidentität des Anwendungspools Fabrikam Stock, so dass aus NetworkService LocalService wird:appcmd set apppool "Fabrikam Stock" /processModel.identityType:LocalService

Die identityType-Enumeration unterscheidet innerhalb des Konfigurationsspeichers zwischen Groß- und Kleinschreibung. Wenn Sie den richtigen Wert eingeben, führt Appcmd den Befehl erfolgreich aus und gibt eine ähnliche Ausgabe wie die folgende zurück:

Tabelle 10.7 Appcmd-Syntax zum Konfigurieren der Anwendungspoolidentität


ApppoolName Der Name des Anwendungspools

processModel.identityType Der Identitätstyp (identityType) repräsentiert entweder ein integriertes Konto wie LocalService, LocalSystem oder NetworkService bzw. ein benutzerdefiniertes Konto (SpecificUser), das für den Anwendungspool verwendet werden soll

processModel.userName Der Benutzerkontoname für die benutzerdefinierte Anwendungspoolidentität

processModel.password Das Benutzerkontokennwort für die benutzerdefinierte Anwendungspoolidentität



Das APPPOOL-Objekt "Fabrikam Stock" wurde geändert.

Wenn Sie einen falschen Wert eingeben, erhalten Sie die folgenden Fehlermeldungen:FEHLER (Meldung: Unbekanntes Attribut "identityType". Grund: Enumeration muss einen der Werte von LocalSystem, LocalService, NetworkService, SpecificUser aufweisen.)

Um eine benutzerdefinierte Anwendungsarbeitsprozessidentität zu konfigurieren, geben Sie SpecificUser als identityType-Attributwert an. Dann legen Sie die Benutzeranmeldeinformationen mit den Eigen-schaften userName und password fest.appcmd set apppool /apppool.name:"Fabrikam Stock" /processModel.identityType:SpecificUser /processModel.userName:"MyAppUsr" /processModel.password:"passw@rd1"

Das vorherige Beispiel konfiguriert das Benutzerkonto MyAppUsr als Fabrikam Stock-Anwendungs-poolidentität und legt als Kontokennwort passw@rd1 fest.

IIS speichert Änderungen an der Anwendungspoolidentität in der applicationHost.config-Datei und dort im Abschnitt <applicationPools>. Der Elementwert enthält den Namen des Anwendungspools, das Arbeitsprozessmodell und die Prozessidentität, sofern sich diese Angaben von den Standardein-stellungen unterscheiden. Nachfolgend ist die <applicationPools>-Konfiguration der benutzerdefinierten Arbeitsprozessidentität aufgeführt, die für den Anwendungspool Farbrikam Stock konfiguriert wurde.<applicationPools> ... <add name="Fabrikam Stock" managedRuntimeVersion="V1.1" managedPipelineMode="Classic"> <processModel identityType="SpecificUser" userName="MyAppUsr" password="[enc:AesProvider:oGSyoej3RKswi3gsrYarpbMQrx0rVIY6nFHkPmjQAhE= :enc]/> </add> ... </applicationPools>

Erweiterte AnwendungspoolkonfigurationObwohl die Anwendungspoolkonfiguration von IIS 7.0 der von IIS 6.0 gleicht, wurde die Konfigura-tionsoberfläche zusammen mit dem IIS-Manager überarbeitet. Alle Einstellungen sind nun innerhalb dieser Oberfläche sichtbar und konfigurierbar. Die meisten Konfigurationseinstellungen, die z.B. die Anwendungswiederverwendung und den Schutz vor schnellen Fehlerfolgen betreffen, unterscheiden sich nicht von ihren IIS 6.0-Pendants. Dieser Abschnitt beschreibt einige wichtige Konfigurationen, die bei IIS 7.0 neu sind.

Das Laden von Benutzerprofilen ermöglichenDie Anwendungslogik einer typischen Webanwendung enthält in der Regel Code zum Lesen und Schreiben von Daten. Solche Anwendungen benötigen meistens Lese- und Schreibzugriffsrechte für das temporäre Windows-Verzeichnis %Temp%. Stelle Sie sich beispielsweise vor, eine ASP-Anwen-dung arbeitet mit einer Microsoft Access-Datenbank. Bei IIS 6.0 gewährt das Betriebssystem standard-mäßig allen Benutzern – auch dem Arbeitsprozesskonto, und zwar unabhängig von der Prozessidentität – Lese- und Schreibzugriffsrechte für das temporäre Verzeichnis. Obwohl dieses Standardverhalten von IIS 6.0 dazu führt, dass Webanwendungen ohne Probleme ausgeführt werden, kann die Sicherheit beeinträchtigt werden, weil alle Arbeitsprozesse dasselbe temporäre Verzeichnis gemeinsam nutzen.



Um das Sicherheitsrisiko zu vermindern, bietet Ihnen IIS 7.0 die Möglichkeit, das Benutzerkontoprofil während des Starts eines Arbeitsprozesses zu laden. Daraus ergibt sich eine eigene Umgebung mit ver-schiedenen temporären Ordnern für jede Prozessidentität. Doch nur das Prozesskonto kann standard-mäßig auf das temporäre Verzeichnis der Prozessidentität zugreifen. Muss eine Webanwendung auf ein temporäres Verzeichnis zugreifen, müssen Sie den entsprechenden Benutzerkonten Zugriff gewähren. Das Laden von Benutzerprofilen ist bei IIS 7.0 standardmäßig deaktiviert, was zu einem Verhalten wie bei IIS 6.0 führt. Wenn Benutzerprofile aktiviert sind, ist es möglich, dass einige Anwendungen nicht mehr funktionieren, z.B. Anwendungen, die mit Microsoft Access-Datenbanken arbeiten. Der Grund hierfür besteht darin, dass die Standardanwendungspoolidentität, NetworkService, nicht auf das Temp-Verzeichnis zugreifen kann, das von der Access-Datenbankengine verwendet wird.

Hinweis Das Laden von Benutzerprofilen ist unter Windows Vista standardmäßig aktiviert. Unter Windows Server 2008 und Windows Vista Service Pack 1 (SP1) ist es jedoch deaktiviert. Sie sollten ebenfalls wissen, dass das Laden von Benutzerprofilen für jeden Anwendungspool einzelnen konfiguriert wird.

Nach der Installation von Windows Vista SP1 und der Neuinstallation von IIS 7.0 ist die Einstellung loadUserProfile standardmäßig deaktiviert.

Um unter IIS 7.0 mit dem IIS-Manager Benutzerprofile zu aktivieren, erweitern Sie im Bereich Ver-bindungen den Knoten des IIS-Computers und markieren den Knoten Anwendungspools. Markieren Sie auf der Seite Anwendungspools den Anwendungspool, dessen Einstellung zum Laden eines Benut-zerprofils Sie ändern möchten, und klicken Sie im Bereich Aktionen auf Erweiterte Einstellungen. Markieren Sie im Dialogfeld Erweiterte Einstellungen und dort im Abschnitt Prozessmodell die Eigenschaft Benutzerprofil laden und wählen Sie im Dropdown-Listenfeld den Eintrag True, wie in Abbildung 10.7 dargestellt.

Abbildung 10.7 Benutzerprofile mit dem IIS-Manager aktivieren



Nachdem Sie die Einstellung Benutzerprofil laden aktiviert haben, müssen Sie den entsprechenden Benutzerkonten den Zugriff auf das temporäre Verzeichnis des Kontoprofils gewähren, weil standard-mäßig nur die Prozessidentität auf die Profilverzeichnisse zugreifen kann. Der integrierte Kontoprofil-ordner ist standardmäßig im Verzeichnis %systemRoot%\ServiceProfiles\ gespeichert. Der Ordner der Arbeitsprozessstandardidentität (NetworkService) befindet sich unter %systemRoot%\ServiceProfiles\ NetworkService\AppData\Local\Temp. Weitere Informationen zum Gewähren von Zugriffsberechti-gungen für das temporäre Verzeichnis finden Sie im Microsoft Knowledge Base-Artikel unter http://support.microsoft.com/kb/926939/.

Benutzen Sie die folgende Appcmd-Syntax und die in Tabelle 10.8 beschriebenen Parameter, um für einen Anwendungspool das Laden eines Benutzerprofils zu aktivieren:appcmd set apppool "apppool name" /processModel.loadUserProfile:Boolean

Der folgende Code aktiviert das Laden von Benutzerprofilen für den Anwendungspool DefaultAppPool.appcmd set apppool /apppool.name:"DefaultAppPool" /processModel.loadUserProfile:true

Bei einer erfolgreichen Ausführung des Befehls sehen Sie die folgende Ausgabe. Nachdem Sie das Benutzerprofil aktiviert haben, sollten Sie nicht vergessen, die notwendigen Kontozugriffsrechte wie zuvor beschrieben zu gewähren.Das APPPOOL-Objekt "DefaultAppPool" wurde geändert

Genauso wie alle anderen Änderungen, die an einem Anwendungspool vorgenommen werden, wird auch die Profileinstellung zusammen mit dem Anwendungspool im <applicationPools>-Abschnitt der applicationHost.config-Datei definiert. Der loadUserProfile-Attributwert wird mit dem processModel-Element deklariert. Nachfolgend ist die <applicationPools>-Konfiguration der Einstellung zum Laden von Benutzerprofilen für den Anwendungspool DefaultAppPool aufgeführt:<applicationPools> <add name="DefaultAppPool"> <processModel loadUserProfile="true" /> </add> <add name="Classic .NET AppPool" managedPipelineMode="Classic" /> ... <applicationPoolDefaults> <processModel identityType="NetworkService" /> </applicationPoolDefaults> </applicationPools>

Die Wiederverwendung von Anwendungspools überwachenDie effektive Überwachung der Wiederverwendung von Anwendungspools ermöglicht es Ihnen, den Zustand eines Anwendungspools einzuschätzen. Sie erhalten außerdem eine detaillierte Beschreibung zu jedem Wiederverwendungsereignis und die Überwachung hilft Ihnen, Probleme mit der Anwen-ungsverfügbarkeit zu beheben. Bei IIS 6.0 können ähnliche Ereignisprotokollierungen ausschließlich

Tabelle 10.8 Appcmd-Syntax zum Aktivieren des Ladens von Benutzerprofilen


apppool name Die Zeichenfolge repräsentiert den Anwendungspoolnamen

processModel.loadUserProfile Gibt an, ob der Arbeitsprozess das Benutzerprofil während des Starts laden soll



über ein Befehlszeilentool konfiguriert werden und nicht alle Anwendungspoolereignisse werden erfasst. Beispielsweise wird das Herunterfahren eines Anwendungspools nach einer bestimmten Leer-laufzeit nicht registriert. Weitere Informationen zu IIS 6.0-Anwendungspoolwiederverwendungs-ereignissen finden Sie im Microsoft Knowledge Base-Artikel unter http://support.microsoft.com/kb/332088/. Bei IIS 7.0 kann die Überwachung von Wiederverwendungsereignissen nun mit dem IIS-Manager konfiguriert werden. Das schließt auch die auf Anwendungspools bezogenen Wiederverwen-dungsereignisse mit ein. Tabelle 10.9 zeigt die Ereignisprotokoll-ID und Detailinformationen zu jedem Wiederverwendungsereignis.

Wird ein Arbeitsprozess herutergefahren, weil die Leerlaufzeit (die Vorgabe ist 20 Minuten) über-schritten wurde, vermerkt WAS das folgende Ereignisprotokoll:Ereignis-ID: 5186 Beschreibung: Ein Arbeitsprozess mit der Prozess-ID '%1' für den Anwendungspool '%2' wurde aufgrund von Inaktivität heruntergefahren. Das Timeout für den Anwendungspool wurde auf %3 Minuten festgelegt. Bei Bedarf wird ein neuer Arbeitsprozess gestartet.

Tabelle 10.9 Wiederverwendungsereignisse für Anwendungspools

Ereignis/Attributwert Beschreibung Ereignis-ID

Geänderte Anwendungspool-konfiguration (ConfigChange)

Die Arbeitsprozesse für Anwendungspool '%1' werden aufgrund mindes-tens einer Konfigurationsänderung in den Anwendungspooleigenschaften, die zum Starten der Prozesse erforderlich sind, wieder verwendet

System 5080

ISAPI-Fehlermeldung (IsapiUnhealthy)

ISAPI '%1' hat sich selbst aufgrund des folgenden Fehlers als fehlerhaft gemeldet: '%2'

ISAPI '%1' hat sich selbst als fehlerhaft gemeldet. ISAPI hat keine Fehler-ursache angegeben.

Anwendung 2262

Anwendung 2263

Modul-Fehlermeldung (ReportUnhealthy)

Eine Anwendung hat gemeldet, dass sie fehlerhaft ist. Der Arbeitsprozess fordert eine Wiederverwendung an. Grund: %1. Fehler in den Daten.

Anwendung 2299

Manuelle Wiederverwendung (OnDemand)

Ein Administrator hat einen Löschvorgang aller Arbeitsprozesse in Anwendungspool '%1' angefordert

System 5079

Überschrittenes Limit für den privaten Speicher (PrivateMemory)

Ein Arbeitsprozess mit der Prozess-ID '%1' für den Anwendungspool '%2' hat die Wiederverwendung angefordert, da das Bytelimit für den privaten Speicher erreicht wurde

System 5117

Regelmäßige Zeitintervalle (Time)

Ein Arbeitsprozess mit der Prozess-ID '%1' für den Anwendungspool '%2' hat die Wiederverwendung angefordert, da der Arbeitsprozess das zulässige Verarbeitungszeitlimit erreicht hat

System 5074

Anforderungslimit überschritten (Requests)

Ein Arbeitsprozess mit der Prozess-ID '%1' für den Anwendungspool '%2' hat die Wiederverwendung angefordert, da das zulässige Anforderungslimit erreicht wurde

System 5075

Bestimmte Zeit (Schedule) Ein Arbeitsprozess mit der Prozess-ID '%1' für den Anwendungspool '%2' hat die Wiederverwendung angefordert, da die geplante Wiederverwen-dungszeit erreicht wurde

System 5076

Limit für den virtuellen Speicher überschritten (Memory)

Ein Arbeitsprozess mit der Prozess-ID '%1' für den Anwendungspool '%2' hat die Wiederverwendung angefordert, da das Limit für den virtuellen Speicher erreicht wurde

System 5077



Die folgenden Wiederverwendungsereignisse werden standardmäßig protokolliert:

� Überschrittenes Limit für den privaten Speicher (Standardwert 0 [KB], kein Limit)

� Regelmäßige Zeitintervalle (Standardwert 1740 [Minuten], 29 Stunden)

� Limit für den virtuellen Speicher überschritten (Standardwert 0 [KB], kein Limit)

Um mit dem IIS-Manager die Protokollierung weiterer Wiederverwendungsereignisse für Anwen-dungspools zu aktivieren, erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers und markieren den Knoten Anwendungspools. Markieren Sie auf der Seite Anwendungspools den Anwen-dungspool, für den Sie die Protokollierung bestimmter Wiederverwendungsereignisse aktivieren möchten. Klicken Sie anschließend im Bereich Aktionen auf Erweiterte Einstellungen. Blättern Sie im Dialogfeld Erweiterte Einstellungen nach unten zum Abschnitt Wiederverwendung, erweitern Sie den Knoten Protokolleintrag für Wiederverwendungsereignis generieren, markieren Sie den gewünschten Ereignis-protokolleintrag und wählen Sie im Dropdown-Listenfeld True, um die Protokollierung dieses Ereignisses zu aktivieren (siehe Abbildung 10.8).

Hinweis Sie müssen alle relevanten Eigenschaften konfigurieren, wenn ein Wiederverwendungsereignis proto-kolliert werden soll. Wenn Sie beispielsweise die Option Anforderungslimit überschritten aktivieren, müssen Sie für die Eigenschaft Anforderungslimit ein Limit angeben. Andernfalls wird der Vorgabewert 0 verwendet, der angibt, dass für den Anwendungspool kein Anforderungslimit konfiguriert ist. Ein Ereignisprotokoll würde dann nicht generiert, weil es kein Limit gäbe, dessen Überschreitung überprüft werden könnte.

Abbildung 10.8 Anwendungswiederverwendungsereignisse mit dem IIS-Manager aktivieren



Benutzen Sie die folgende Appcmd-Syntax und die in Tabelle 10.10 beschriebenen Parameter, um die Protokollierung verschiedener Wiederverwendungsereignisse für Anwendungspools zu konfigurieren:appcmd set apppool "ApppoolName" /recycling.logEventOnRecycle:flags

Die folgende Syntax aktiviert für den Anwendungspool DefaultAppPool die Protokollierung aller Wiederverwendungsereignisse:appcmd set apppool "DefaultAppPool" /recycling.logEventOnRecycle:"Time, Requests, Schedule, Memory, IsapiUnhealthy, OnDemand, ConfigChange, PrivateMemory"

Um die gesamte Ereignisprotokollierung zu deaktivieren, entfernen Sie einfach alle Attributflags. Der folgende Befehl deaktiviert beispielsweise für den Anwendungspool Test die Protokollierung aller Wiederverwendungsereignisse:appcmd set apppool "Test" /recycling.logEventOnRecycle:""

Wie bereits erwähnt wurde, ist es wichtig, dass Sie zugehörige Einstellungen konfigurieren, wenn Sie für Anwendungspools die Protokollierung von Wiederverwendungsereignissen aktivieren. Sie müssen z.B. für einen Anwendungspool ein Anforderungslimit angeben, wenn ein Ereignisprotokoll generiert werden soll, sobald die Arbeitsprozesse des Anwendungspools bei Erreichen des Limits wiederver-wendet werden. Die folgende Syntax setzt das Anforderungslimit auf 500 und aktiviert für den Anwen-dungspool Test die Protokollierung des Ereignisses Anforderungslimit überschritten:appcmd set apppool "Test" /recycling.periodicRestart.requests:500 /recycling.logEventOnRecycle:"Requests"

Beachten Sie den Parameter /recycling.periodicRestart. Alle Wiederverwendungsoptionen eines Anwen-dungspools werden unter diesem Element konfiguriert. Es enthält die folgenden Knoten zum Fest- legen der Wiederverwendungsoptionen eines Anwendungspools: .memory für virtuelle Speicherlimits, .privateMemory für die Begrenzung des privaten Speichers, .schedule für regelmäßige Zeitintervalle und .time für bestimmte Zeiten.

Genauso wie alle anderen Änderungen, die an einem Anwendungspool vorgenommen werden, wird auch die Protokollierung von Wiederverwendungsereignissen zusammen mit dem Anwendungspool im <applicationPools>-Abschnitt der applicationHost.config-Datei definiert. Der Typ des Ereignisprotokoll-eintrags wird im <recycling>-Element deklariert und die Limits oder Einschränkungen zu jeder Einstel-lung werden im Unterelement <periodicRestart> definiert. Nachfolgend ist die <applicationPools>-Konfigura-tion aufgeführt, die sich aus dem vorherigen Beispiel ergibt:<applicationPools> <add name="DefaultAppPool"> <recycling logEventOnRecycle="Requests"> <periodicRestart request="500" /> </recycling> </add>

Tabelle 10.10 Appcmd-Syntax zum Konfigurieren der Protokollierung von Wiederverwendungsereignissen


ApppoolName Die Zeichenfolge repräsentiert den Anwendungspoolnamen.

recycling.logEventOnRecyle Legt die Wiederverwendungsereignisoptionen fest. Zu den Flags zählen Time, Requests, Schedule, Memory, IsapiUnhealthy, OnDemand, ConfigChange und PrivateMemory.



<add name="Classic .NET AppPool" managedPipelineMode="Classic" /> <applicationPoolDefaults> <processModel identityType="NetworkService" /> </applicationPoolDefaults> </applicationPools>

Arbeitsprozesse und Anforderungen verwaltenDer Arbeitsprozess ist bei IIS 7.0 das Herz und die Seele einer Webanwendung. Er wird in W3WP.exe ausgeführt und ist für die Verarbeitung von Anwendungsanforderungen verantwortlich. Bei IIS 6.0 werden Arbeitsprozesse vom WWW-Publishingdienst (World Wide Web) verwaltet, bei IIS 7.0 hingegen wurde die Kernengine überarbeitet, so dass nun WAS im Besitz der Arbeitsprozesse ist.

Bei IIS 6.0 kann eine Abfrage von Arbeitsprozessinformationen, wie z.B. die PID (Prozess-ID) der gegenwärtig ausgeführten Arbeitsprozesse samt dem dazugehörigen Anwendungspool, ausschließlich über das Befehlszeilenskript lisapp.vbs erfolgen. Mit IIS 6.0 ist es außerdem nicht möglich, das Innere eines Arbeitsprozesses zu untersuchen, um einen Blick auf den gegenwärtigen Anforderungsstatus zu werfen. Wenn Sie jedoch mit ETW (Event Tracing for Windows; Ereignisnachverfolgung für Windows) vertraut sind, können Sie IIS-Komponenten als Anbieter benutzen, die Nachverfolgungsdaten und Ereignisse an ETW senden, so dass Sie einen Blick auf die Anforderungsverarbeitungsdetails in einem Arbeitsprozess werfen können. Obwohl ETW ein leistungsfähiges Hilfsmittel für die auf Anforde-rungen basierende Nachverfolgung ist, ist seine Implementierung nicht einfach. Es besitzt keine Benutzeroberfläche und ist nicht wirklich Bestandteil der IIS-Kernarchitektur.

IIS 7.0 gestaltet die Verwaltung von Arbeitsprozessen einfacher als jemals zuvor. Möglich ist dies mit dem IIS-Manager und Appcmd. Dank der neuen Kernarchitektur ist nun ein auf Anforderungen basierendes Nachverfolgungsfeature in IIS 7.0 integriert. Sie können im IIS-Manager die in einem bestimmten Arbeitsprozess befindlichen aktuellen Anforderungen mit einigen wenigen Mausklicks einfach abfragen. Alternativ hierzu können Sie Appcmd benutzen, um den Laufzeitstatus abzufragen. Zu den zur Verfügung gestellten Informationen zählen das HTTP-Verb der jeweiligen Anforderungen, der Name der angeforderten Resource, der Verarbeitungsstatus der Anforderung und das Modul, das die Anforderungen gegenwärtig verarbeitet.

Arbeitsprozesse und Anforderungen überwachenDurch die Überwachung von Arbeitsprozessen erhalten Sie eine Übersicht über den Verbrauch der Webserverressourcen. Sie können diese Informationen ebenfalls nutzen, um einen fehlerhaften Arbeits-prozess zu beenden, der ständig die gesamten CPU-Ressourcen beansprucht, oder um eine fehlerhafte Anwendung zu stoppen, die die Arbeitsprozesse mit Anforderungen konfrontiert, die über einen langen Zeitraum ausgeführt werden. Um mit dem IIS-Manager die aktuellen Arbeitsprozesse und den Anfor-derungsstatus abzufragen, markieren Sie im Bereich Verbindungen den Knoten des IIS-Computers und führen im Bereich der Ansicht Features einen Doppelklick auf Arbeitsprozesse aus. Die Seite Arbeits-prozesse ist in Abbildung 10.9 dargestellt.

Um eine Liste der gegenwärtig ausgeführten Anforderungen zu erhalten, markieren Sie einen Arbeits-prozess und klicken im Bereich Aktionen auf Aktuelle Anforderungen anzeigen. Alternativ hierzu klicken Sie mit der rechten Maustaste auf einen Arbeitsprozess und wählen Aktuelle Anforderungen anzeigen aus. Die Seite Anforderungen ist in Abbildung 10.10 dargestellt.


Arbeitsprozesse und Anforderungen verwalten 303

Abbildung 10.9 Aktuelle Arbeitsprozesse mit dem IIS-Manager abfragen

Benutzen Sie die folgende Appcmd-Syntax, um eine Liste der Arbeitsprozesse anzeigen zu lassen:appcmd list wp PID /apppool.name:string

Abbildung 10.10 Aktuelle Anforderungen mit dem IIS-Manager anzeigen lassen



Die in der Regel verwendeten Parameter sind in Tabelle 10.11 beschrieben.

Sie können den folgenden Appcmd-Befehl benutzen, um eine Liste der gegenwärtig ausgeführten Anforderungen anzeigen zu lassen:appcmd list request RequestId /apppool.name:string /elapsed:integer /site.name:string /wp.name:integer

Die in der Regel verwendeten Parameter sind in Tabelle 10.12 beschrieben.

Wenn Sie Appcmd benutzen, um Arbeitsprozessinformationen abzufragen, ist die Ausgabe weniger umfangreich als beim IIS-Manager. Appcmd zeigt nur die Prozess-ID und den Namen des Anwen-dungspools an, der vom Arbeitsprozess bedient wird. Um alle Arbeitsprozesse eines IIS 7.0-Servers aufzulisten, verwenden Sie den folgenden Befehl:appcmd list wp

Wenn Webanwendungen ausgeführt werden, listet der vorherige Befehl die gegenwärtig ausgeführten Arbeitsprozesse auf. Die folgende Ausgabe zeigt beispielsweise drei ausgeführte Arbeitsprozesse, die alle unterschiedliche Anwendungspools bedienen:WP "1120" (applicationPool:DefaultAppPool) WP "3918" (applicationPool:MyAppPool) WP "3320" (applicationPool:Fabrikam Stock)

Hinweis Die RSCA-Objekte (Runtime State and Control API) innerhalb der IIS-Webserverkernengine stellen Lauf-zeitinformationen zu den Arbeitsprozessen zur Verfügung.

Um die Arbeitsprozessdaten zu einem bestimmten Anwendungspool abzufragen, benutzen Sie den folgenden Befehl:appcmd list wp /apppool.name:"DefaultAppPool"

Tabelle 10.11 Appcmd-Syntax zum Auflisten von Arbeitsprozessen


PID Die Prozess-ID des aufzulistenden Arbeitsprozesses. Erfolgt keine Angabe, werden alle Arbeitsprozesse aufgelistet.

apppool.name Der Name des Anwendungspools, dessen Arbeitsprozesse angezeigt werden sollen

Tabelle 10.12 Appcmd-Syntax zum Auflisten ausgeführter Anforderungen


RequestId Der eindeutige Bezeichner der Anforderung, sofern bekannt. Erfolgt keine Angabe, werden alle Anforde-rungen aufgelistet.

apppool.name Der Name des Anwendungspools, dessen Anforderungen angezeigt werden sollen

elapsed Die Verarbeitungszeit in Millisekunden, die vergangen sein muss, damit eine Anforderung aufgelistet wird

site.name Der Name der Website, für die die Anforderungen angezeigt werden sollen. Alternativ hierzu können Sie über /site.id eine Website-ID angeben.

wp.name integer repräsentiert die Prozess-ID eines bestimmten Arbeitsprozesses, dessen Anforderungen angezeigt werden sollen.


Arbeitsprozesse und Anforderungen verwalten 305

In einem Webgarten, wo mehr als ein Arbeitsprozess denselben Anwendungspool bedient, könnten Sie eine ähnliche Ausgabe wie die folgende erhalten, weil drei verschiedene Arbeitsprozesse den Anwen-dungspool DefaultAppPool bedienen:WP "1951" (applicationPool:DefaultAppPool) WP "3593" (applicationPool:DefaultAppPool) WP "3039" (applicationPool:DefaultAppPool)

Um alle Arbeitsprozesse aufzulisten, die zu einer Website gehören, listen Sie zunächst alle Anwen-dungen dieser Website auf und leiten dann die Ergebnisse an eine andere Abfrage weiter. Der folgende Befehl zeigt beispielsweise alle Arbeitsprozesse, die Contoso Corp. zugeordnet sind:appcmd list app /site.name:"Contoso Corp" /xml | appcmd list wp /in

Wären den Anwendungen von Contoso Corp. gegenwärtig zwei ausgeführte Anwendungspools (DefaultAppPool und MyAppPool) zugeordnet, würde die Ausgabe zwei Arbeitsprozesse mit den entsprechenden Detailinformationen anzeigen.WP "1120" (applicationPool:DefaultAppPool) WP "3918" (applicationPool:MyAppPool)

Um Webanwendungen oder Anwendungspools zu ermitteln, in denen ein bestimmter Arbeitsprozess seine Dienste verrichtet, verwenden Sie den folgenden Befehl:appcmd list wp "1120" /xml | appcmd list app /in

Der erste Teil des Befehls listet wie im vorherigen Code die Arbeitsprozessdetails in XML-Format auf. Dazu zählt auch der Anwendungspoolname. Eine mögliche Beispielausgabe dieses Zwischenschritts ist nachfolgend aufgeführt:<?xml version="1.0" encoding="UTF-8"?> <appcmd> <WP WP.NAME="1120" APPPOOL.NAME="DefaultAppPool" /> </appcmd>

Die XML-Ausgabe wird dann als Eingabe an den zweiten Teil des Befehls übergeben, der alle zum Anwendungspool gehörenden Anwendungen auflistet. Wenn die Stammanwendungen von Contoso Corp. und Fabrikam HR im Anwendungspool DefaultAppPool ausgeführt werden, erhalten Sie die folgende endgültige Ausgabe des vorherigen vollständigen Befehls:APP "Contoso Corp/" (applicationPool:DefaultAppPool) APP "Fabrikam HR/" (applicationPool:DefaultAppPool)

Um einen Blick in einen Arbeitsprozess auf die gegenwärtig ausgeführten Anforderungen zu werfen, können Sie mit Appcmd das LIST-Verb zum Abfragen des REQUEST-Objekts benutzen. Die folgende Syntax zeigt beispielsweise alle gegenwärtig ausgeführten Anforderungen eines IIS 7.0-Webservers:appcmd list request

Die resultierende Ausgabe, die nachfolgend aufgeführt ist, verrät, dass IIS gegenwärtig drei ASP-Anforderungen verarbeitet:REQUEST "f80000008000000e" (url:GET /profile.asp, time:330 msec, client:10.10.29.12, stage:ExecuteRequestHandler, module:IsapiModule) REQUEST "f80000008000000f" (url:POST /loginform.asp, time:123 msec, client:10.11.3.99, stage:ExecuteRequestHandler, module:IsapiModule) REQUEST "f800000080000010" (url:GET /account.asp, time:200 msec, client:10.10.29.88, stage:ExecuteRequestHandler, module:IsapiModule)

Sie können den Parameter /text:* benutzen, um alle zurückgegebenen Anforderungsattribute anzeigen zu lassen. Sie erhalten dann mehr nützliche Informationen, als in der zuvor gezeigten einfachen Ansicht.



Um für einen bestimmten Anwendungspool alle aktuellen Anforderungen aufzulisten, benutzen Sie den folgenden Befehl:appcmd list request /apppool.name:"DefaultAppPool"

Alternativ hierzu können Sie die folgende Anweisung verwenden, um die aktuellen, auf die Website Contoso Corp. bezogenen Anforderungen anzeigen zu lassen, die seit mehr als 60 Sekunden verarbeitet werden:appcmd list request /elapsed:"$>60000" /site.name:"Contoso Corp"

Das Abfragen eines REQUEST-Objekts versorgt Sie mit Echtzeitinformationen über die gegenwärtig verar-beiteten Anforderungen und es kann Ihnen helfen, Anforderungen zu identifizieren, die seit langer Zeit ausgeführt werden, was für die Behandlung von Anwendungsproblemen besonders wichtig ist. Der folgende Befehl listet die Arbeitsprozesse aller Anwendungspools auf, bei denen die Anforderungs-verarbeitung viel Zeit beansprucht (Anforderungen, deren Verarbeitung länger als 60 Sekunden dauert). Diese Anwendungspools werden recycelt.appcmd list request /time:"$>60000" /xml | appcmd list apppool /in /xml | appcmd recycle apppool /in

Beachten Sie die vorherige Syntax. Obwohl sie die Anwendungsverfügbarkeit durch das Recyceln von Anwendungspools verbessert, geben bereits vorhandene Anforderungen und Sitzungsdetails während des Recyclings verloren. Um den Verlust von Sitzungsvariablen zu verhindern, empfehlen wir, dass Sie für Ihre Webanwendungen auf eine prozessexterne Sitzungsverwaltung zurückgreifen. Obwohl die auf Anforderungen basierende Nachverfolgung über das REQUEST-Objekt Sie mit Echtzeitinformationen ver-sorgt, erhalten Sie nicht alle Informationen zu den Ereignissen, die im Rahmen der Anforderungsverar-beitung auftreten. Um Probleme mit Anforderungen zu beheben, sollten Sie die Ablaufverfolgung für Anforderungsfehler aktivieren, so dass Sie detaillierte Ereignisbenachrichtigungen abfangen können, die innerhalb der Verarbeitungspipeline generiert wurden. Weitere Informationen zur Ablaufverfolgung für Anforderungsfehler finden Sie im sechzehnten Kapitel, »Ablaufverfolgung und Problembehandlung«.

ZusammenfassungDas Webanwendungskonzept ist ein sehr wichtiges IIS 7.0-Konzept, das einen Container für die Funk-tionalität von IIS 7.0-Websites definiert. Sie können Anwendungen erstellen und verwalten, um die Ausführungsparameter für die Funktionalität Ihrer Website zu kontrollieren. Sie können ebenfalls Anwendungen isolieren, indem Sie sie mit einem Anwendungspool verknüpfen. Der Anwendungspool wird auch weiterhin aus Gründen der Zuverlässigkeit und Sicherheit für die Isolation der Anwendungs-ausführung verwendet.

In diesem Kapitel haben Sie sich mit der grundlegenden Erstellung und Verwaltung von IIS-Anwen-dungen und Anwendungspools sowie mit dem Einsatz von Tools zur Überwachung des Betriebs solcher Anwendungen und Pools beschäftigt.

Lesen Sie auch das vierzehnte Kapitel, um mehr über die Nutzung von Anwendungspools zur Abschirmung von Webanwendungen und zur Einschränkung von Rechten zu erfahren. Weitere Infor-mationen zum Konfigurieren von Anwendungsframeworks für Ihre Anwendungen finden Sie im elften Kapitel.




� Das vierte Kapitel, »Verstehen des Konfigurationssystems«, enthält Informationen zum neuen auf XML basierenden Konfigurationssystem und zu wichtigen IIS 7.0-Konfigurationsdateien.

� Das neunte Kapitel, »Verwalten von Websites«, enthält Informationen zur Verwaltung von Websites und virtuellen Verzeichnissen unter IIS 7.0.

� Das elfte Kapitel, »Hosting von Anwendungsentwicklungsframeworks«, hält Informationen zur Konfi-guration verschiedener Anwendungsframeworks unter IIS 7.0 bereit. Dazu zählen z.B. ASP, ASP.NET und CGI.

� Das vierzehnte Kapitel, »Implementieren von Sicherheitsstrategien«, beschreibt die Konfiguration von Anwendungspools mit Blick auf die Sicherheit sowie andere Sicherheitsüberlegungen, die der Sicherung von IIS 7.0 dienen.

� Das sechzehnte Kapitel, »Ablaufverfolgung und Problembehandlung«, enthält Informationen zur Aktivierung der Ablaufverfolgung für Anforderungsfehler sowie zur Nachverfolgungsprotokoll-datei von IIS 7.0.

� WCAT (Web Capacity Analysis Tool) ist ein kostenlos erhältliches Tool von Microsoft, mit dem auf einem IIS-Webserver Kapazitätsanalysen durchgeführt werden können. Um dieses Tool herunterzu-laden, besuchen Sie bitte http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1466.

� Der Microsoft Knowledge Base-Artikel 332088, "How to Modify Application Pool Recycling Events in IIS 6.0" (für den eine maschinelle Übersetzung in die deutsche Sprache vorliegt), hält Informationen zur Konfiguration der Überwachung von IIS 6.0-Anwendungspoolwiederverwen-dungsereignissen bereit. Sie finden diesen Artikel unter http://support.microsoft.com/kb/332088.

� Der Microsoft Knowledge Base-Artikel 926939, "Error Message when You Request an ASP Page That Connects to an Access Database in IIS 7.0" (für den eine maschinelle Übersetzung in die deutsche Sprache vorliegt), informiert über Probleme mit Access-Datenbanken, die sich auf die loadUserProfile-Einstellung von IIS 7.0 beziehen. Sie finden diesen Artikel unter http://support.microsoft.com/kb/926939.


309

K A P I T E L 1 1

Hosting von Anwendungsentwicklungs-frameworks

Inhalt dieses Kapitels:� IIS als Anwendungsentwicklungsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

� ASP.NET-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

� ASP-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

� PHP-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

� Anwendungsframeworks ermöglichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337




IIS als AnwendungsentwicklungsplattformWie viele andere Webservertechnologien diente auch IIS (Internet Information Services) ursprünglich nur einem Zweck: der Bedienung von Browsersclients mit statischen Inhalten, wie z.B. HTML-Dokumen- ten und Bildern. Dazu wurde das HTTP-Protokoll verwendet. Neue Anforderungen an Webseiteanwen-dungen verlangten schließlich die Einbindung dynamischer Inhalte. Daraufhin wurde IIS eine einfache CGI-Unterstützung (Common Gateway Interface) hinzugefügt, die die dynamische Generierung von Webinhalten durch die Ausführung von Programmen ermöglichte. Die Programme, die gewöhnlich in C oder C++ verfasst waren, basierten in der Regel auf keinem Anwendungsentwicklungsframework.

Das Web heute ist sehr viel komplexer, mit einer Vielzahl von Entwicklungsframeworks und Anwen-dungsumgebungen zur Erstellung dynamischer Webanwendungen, einschließlich ASP (Active Server Pages), PHP (PHP Hypertext Preprocessor), Perl, Python, Flash Server, Java Servlets und ASP.NET. Diese Frameworks fangen den größten Teil der Komplexität ab, die mit der Entwicklung von Web-anwendungen einhergeht, und sie bieten außerdem umfassende Bibliotheken und Steuerelemente für eine nachhaltige Benutzererfahrung. Darüber hinaus implementieren sie Schlüsselfunktionen, wie z.B. die Verwaltung des Sitzungszustand, den Zugriff auf Datenbanken, die Anpassung von Inhalten usw.

IIS hat sich mit dem Web zu einer Plattform für das Hosting verschiedener Anwendungsentwicklungs-framework-Technologien entwickelt. IIS 3.0 hat die ASP-Skriptumgebung eingeführt, die für die Er-stellung von Windows-basierten, dynamischen Serveranwendungen oft genutzt wurde (die letzte ASP-Version war 3.0, die zusammen mit IIS 5.0 veröffentlicht wurde). Beginnend mit IIS 5.0 unter Windows 2000 wurde erstmals ASP.NET durch das .NET Framework 1.0 unterstützt. Dies ist seither das bevorzugte Webanwendungsentwicklungsframework für Windows. Mittlerweile hat das ISAPI-Erweiterungsmodell


310 Kapitel 11: Hosting von Anwendungsentwicklungsframeworks

(Internet Server Application Programming Interface) auch andere Anwendungsframeworks möglich gemacht, z.B. PHP und Perl, so dass diese ihren Weg in die IIS-Umgebung finden können.

Abgesehen vom Hosten der Webanwendungsframeworks unter Windows bietet die IIS-Umgebung weitere wertvolle Leistungsmerkmale. Sie stellt ein fehlertolerantes Modell zum Hosten solcher Anwendungen im Rahmen von IIS-Websites und Anwendungspools zur Verfügung, wodurch eine ausfallsichere Ausführung und Verfügbarkeit gewährleistet wird. Dieses Modell ermöglicht außer- dem das Hosten vieler Anwendungen auf demselben Server und bildet die Grundlage für die Isolation dieser Anwendungen voneinander, so dass sie nicht die Ausführung der jeweils anderen Anwendungen beeinflussen oder auf deren Inhalte zugreifen können. Da dies auf der IIS-Ebene geschieht, stellt das Modell den Administratoren einen vereinheitlichten Mechanismus zur Verfügung, um Anwen-dungsinhalte bereitzustellen und die damit verbundene Konfiguration zu verwalten. Dazu wird eine einzelne Gruppe von Tools und Technologien verwendet.

IIS implementiert außerdem ein breites Spektrum an Anforderungsverarbeitungfunktionalität. Dazu zählen die Authentifizierung, die sichere Kommunikation über SSL (Secure Sockets Layer), die Antwortkomprimierung, die Anforderungsprotokollierung usw. Wenn Webanwendungen von IIS gehostet werden, können sie unabhängig von der Anwendungsframeworktechnologie den größten Teil dieser Funktionalität nutzen.

Hinweis Um eine Übersicht über die Webserververbesserungen zu erhalten, die unter IIS 7.0 Anwendungen betreffen, lesen Sie das erste Kapitel, »Einführung in IIS 7.0«.

IIS 7.0 hebt das Konzept eines Anwendungsservers auf eine neue Ebene. Es bietet erstens ein leistungs-fähiges modulares Erweiterbarkeitsmodell an, mit dem es möglich ist, den Server selbst zu erweitern, indem beliebige Teile seines integrierten Featuresatzes ersetzt oder neue Funktionalität hinzugefügt wird. Es bietet außerdem die Möglichkeit, den Server mit dem .NET Framework zu erweitern, und zwar über die Nutzung der integrierten ASP.NET-Plattform. Auf diese Weise können neue leistungsfähige Umge-bungen für die Zusammenarbeit realisiert werden, z.B. eine Website, die selbst unter Verwendung anderer Anwendungsframeworktechnologien vollständig mit der formularbasierten ASP.NET-Authentifizierung geschützt wird. Diese Verbesserungen machen IIS 7.0 zu einer attraktiven Entwicklungsplattform und sie ermöglichen es den Entwicklern, die Funktionalität einer Webanwendung unabhängig von der Anwen-dungsframeworktechnologie einfach zu erweitern. Zweitens führen die auf die Erweiterbarkeit bezogenen Verbesserungen dazu, dass Entwickler IIS 7.0 sehr viel einfacher mit neuen Anwendungsframeworks verbinden können, indem sie die Plattform zur Erweiterung des IIS-Kerns nutzen.

IIS 7.0 geht noch weiter und bietet eine integrierte Unterstützung neuer Webanwendungsframeworks. Dies wird durch das FastCGI-Protokoll möglich. Viele Anwendungsframeworks von Drittanbietern nutzen das FastCGI-Protokoll, zum Beispiel PHP und Ruby on Rails. FastCGI bietet beim Hosten dieser Anwendungen eine bessere Ausfallsicherheit und Leistung als gewöhnliche CGI-Programme oder ISAPI-Erweiterungen. Während der Entwicklung von Windows Server 2008 arbeitete das IIS-Team sogar direkt mit Zend und der PHP-Community zusammen, um mithilfe des FastCGI-Protokolls ein zuverlässiges PHP-Hosting über die IIS-Plattform zu ermöglichen. Aufgrund des Erfolgs der PHP-Initiative werden in nächster Zukunft sicherlich noch mehr Anwendungsframeworks von Drittanbietern erstmals von der IIS-Plattform unterstützt.

Anwendungsframeworks unterstützenDie Standardinstallation von IIS 7.0 stellt lediglich die Mindestfunktionalität zur Verfügung, die für einen statischen Webserver erforderlich ist. Bei einer Standardinstallation kann der Webserver somit für


IIS als Anwendungsentwicklungsplattform 311

den Client statische Dateien, wie z.B. HTML-Dokumente oder Bilder, direkt bereitstellen, ohne eine dynamische Verarbeitung durchführen zu müssen. Diese Funktionalität wird von dem IIS 7.0-Modul für statische Dateien unterstützt, das so konfiguriert ist, dass es bestimmte statische Dateien unterstützt, deren Dateinamenserweiterungen in der MIME-Typen-Konfiguration von IIS aufgelistet sind.

Wenn Sie nach der Standardinstallation versuchen, auf dem Webserver zusätzliche Anwendungsinhalte bereitzustellen, kann sich bei einer Anforderung dieser Inhalte eine der folgenden Situationen ergeben:

� Die angeforderte Ressource hat eine Dateinamenserweiterung, die sie als statische Datei kenn-zeichnet, weil sie als solche in der entsprechenden Webserverkonfiguration vermerkt ist. Diese Ressource wird ohne Verarbeitung in der vorliegenden Form an den Client übermittelt.

� Die angeforderte Ressource wird nicht als statische Datei erkannt. Das Modul für statische Dateien weist die Anforderung mit dem Fehler 404.3 (Nicht gefunden) ab, wie in Abbildung 11.1 darge-stellt. (Wenn Sie die Datei remote anfordern, erhalten Sie aus Sicherheitsgründen – die benutzer-definierte Fehler betreffen – standardmäßig einen allgemeinen 404-Fehler.)

Abbildung 11.1 Ein 404.3-Fehler, der Aufschluss darüber gibt, dass eine Resource anhand der Dateinamenserweiterung nicht als statische Datei erkannt wurde

Mit diesem in Abbildung 11.1 dargestellten Fehler können Sie immer rechnen, wenn Sie Inhalte anfordern, die der Webserver nicht kennt. Auf diese Weise wird vermieden, dass Ressourcen, die dem Webserver nicht bekannt sind, als statische Dateien bereitgestellt werden. Würden die dem Webserver unbekannten Ressourcen in der vorliegenden Form übermittelt, könnte dies eine unerwünschte Offen-legung von Anwendungsquellcode oder anderer nicht verarbeitbarer Ressourcen zur Folge haben. Um dieses Problem zu beheben, können Sie eine der folgenden Lösungen nutzen:



� Wenn die Ressource eine statische Datei ist, registrieren Sie ihre Dateinamenserweiterung und den entsprechenden MIME-Typ, damit sie bereitgestellt werden kann.

� Wenn die Ressource ein Skript oder eine andere Anwendungsressource ist, die von einem Anwen-dungsframework dynamisch verarbeitet werden muss, müssen Sie dieses Anwendungsframework installieren und eine Handlerzuordnung konfigurieren, um das Anwendungsframework den gewün-schten Inhalten zuzuordnen.

Die verbleibenden Abschnitte dieses Kapitels beschreiben, wie gebräuchliche Anwendungsframeworks – einschließlich ASP, ASP.NET und PHP – installiert und konfiguriert werden. Es werden außerdem allgemeine Techniken zur Konfiguration anderer Anwendungsframeworks vorgestellt.

Um mehr darüber zu erfahren, wie neue Inhaltstypen als statische Dateien bereitgestellt werden, lesen Sie später in diesem Kapitel den Abschnitt »Die Verarbeitung von neuen statischen Dateien konfigurieren«.

Unterstützte AnwendungsframeworksDurch die Beibehaltung der Unterstützung alter ISAPI-Erweiterungen und CGI-Programme ermög-licht IIS 7.0 auch weiterhin den Einsatz aller Anwendungsframeworktechnologien, die bereits mit früheren Versionen von IIS zusammenarbeiteten. Darüber hinaus stellt IIS 7.0 das FastCGI-Protokoll zur Verfügung, mit dem es möglich ist, Frameworks wie PHP, Python usw. innerhalb der IIS-Umgebung zu hosten. Tabelle 11.1 listet einige Anwendungsframeworks auf, die heute von IIS 7.0 offiziell unterstützt werden (dabei handelt es sich um die Frameworks, die vom IIS-Team getestet wurden).

ASP.NET nimmt eine besondere Stellung unter diesen Anwendungsframeworks ein, da es mit dem neuen Integrationsmodus arbeitet, der es Ihnen ermöglicht, ASP.NET zu benutzen, um den IIS-Web-server mithilfe von verwaltetem Code zu erweitern. Auf diese Weise wird ASP.NET zum .NET-Erweiterbarkeitsmodell für die Entwicklung von IIS-Features. Außerdem können bereits vorhandene ASP.NET-Features von einem IIS-Anwendungsframework genutzt werden. Die Änderungen, die an der ASP.NET-Unterstützung vorgenommen wurden, um dies zu ermöglichen, sind später in diesem Kapitel näher erläutert. Dort erfahren Sie auch, wie diese Änderungen genutzt werden.

Zusätzlich zu den in Tabelle 11.1 aufgeführten Frameworks wird IIS auch von den Anwendungs-frameworks vieler Drittanbieter unterstützt. Dies geschieht mithilfe des alten ISAPI-Erweiterungs-mechanismus. Zu diesen Frameworks zählen Cold Fusion, Perl, Python und Tcl. Die Unterstützung des FastCGI-Protokolls führt dazu, dass viele Open Source-Frameworks, die für Apache und andere Webserver entwickelt wurden, auch unter IIS ausgeführt werden können, z.B. Ruby on Rails usw. Sie sind in Tabelle 11.1 nicht aufgelistet, weil das IIS-Team sie zur Drucklegung dieses Buches noch nicht

Tabelle 11.1 Unterstützte Anwendungsframeworks

Framework Unterstützte Versionen Integrationsmodell

ASP.NET ASP.NET 1.1, ASP.NET 2.0 und zukünftige Versionen

Klassisch (ISAPI-Erweiterung): ASP.NET 1.1, ASP.NET 2.0

Integriert: ASP.NET 2.0+

ASP ASP 3.0 ISAPI-Erweiterung

PHP PHP 4.4.6+, PHP 5.2.1+ für FastCGI, PHP 3.0+ für ISAPI- und CGI-Modi

FastCGI (empfohlen)

ISAPI-Erweiterung (für Produktionsumgebungen nicht empfohlen)


ASP.NET-Anwendungen hosten 313

offiziell getestet hatte. Viele dieser Anwendungsframeworks arbeiten problemlos mit IIS 7.0 zusam-men, andere weisen bestimmte Probleme auf, die in zukünftigen Versionen behoben sein werden, so dass auch hier eine korrekte Funktionsweise gewährleistet sein wird. Das IIS-Team plant, die ent-sprechenden Anbieter und Communities zu beauftragen, diese Anwendungstechnologien zu erstellen, um zu gewährleisten, dass sie innerhalb der IIS-Umgebung ausgeführt werden können und die Features der IIS-Plattform effektiv nutzen.

In diesem Kapitel konzentrieren wir uns auf den Einsatz von ASP.NET-, ASP- und PHP-Anwendungen in IIS 7.0 und erörtern bestimmte Überlegungen zum Hosting dieser Frameworks. Am Ende dieses Kapitels werden außerdem Techniken zum Hosten zusätzlicher Frameworks vorgestellt, mit deren Hilfe Sie die Nutzung bereits vorhandener und zukünftiger Anwendungsframeworks unter IIS 7.0 planen können.

ASP.NET-Anwendungen hostenASP.NET ist die Anwendungsframeworkplattform, die für die Entwicklung funktionsreicher Weban-wendungen, welche innerhalb einer IIS-Umgebung eingesetzt werden sollen, besonders geeignet ist. IIS 7.0 geht hierbei noch einen Schritt weiter, weil es ASP.NET 2.0 in seine Anforderungsverarbeitungs-pipeline integriert. Dies führt dazu, dass ASP.NET nicht mehr nur ein Anwendungsframework ist, das auf dem Webserver aufsetzt, sondern eine originalgetreue .NET-API für die Erweiterung des Web-serverkerns.

Dieses Design weist viele Vorteile für die IIS 7.0-Plattform auf. Erstens ermöglicht es die Entwicklung modularer Webserverfeatures, wozu die Leistungsfähigkeit des .NET Frameworks und die umfassen-den ASP.NET-Features genutzt werden. Zweitens trägt es dazu bei, dass auf dem Webserver viele der bereits vorhandenen ASP.NET-Anwendungsdienste unabhängig vom Framework verwendet werden können. Dies gilt sowohl für ASP.NET- als auch für andere Anwendungsframeworks. Serveradminist-ratoren können somit beispielsweise nur jeweils eine Logik für die Authentifizierung, den Sitzungs-zustand und andere ASP.NET-Features einheitlich für eine vollständige Website verwenden, und zwar unabhängig davon, mit welchem Anwendungsframework die Site arbeitet.

Direkt von der Quelle: Gewährleisten der Abwärtskompatibilität mit ASP.NET-AnwendungenUm die Integration von ASP.NET zu ermöglichen, mussten wir die ASP.NET 2.0-Engine von Grund auf überarbeiten. Die neue Architektur machte viele Designänderungen erforderlich, die die Arbeits-weise von ASP.NET unter IIS 7.0 und die Konfigurationsweise von ASP.NET-Anwendungen betrafen. Diese Änderungen mussten sich zwangsläufig auf die Kompatibilität mit bereits vorhan-denen ASP.NET-Anwendungen auswirken.

Wir wollten jedoch sicherstellen, dass bereits vorhandene ASP.NET-Anwendungen im neuen ASP.NET-Integrationsmodus auch weiterhin richtig arbeiten würden. Die Gewährleistung der Abwärtskompati-bilität war ein wichtiges Design- und Implementierungsziel für die integrierte ASP.NET-Pipeline. Wäh-rend der Entwicklung des Projekts erwies sich dies als große Herausforderung.



Der Rest dieses Abschnitts erläutert die wichtigsten Konzeptänderungen, die die Arbeitsweise von ASP.NET unter IIS 7.0 betreffen und bei deren Erarbeitung das Ziel im Vordergrund stand, die neue Form der Webservererweiterbarkeit zu ermöglichen und gleichzeitig die Kompatibilität mit bereits vorhandenen ASP.NET-Anwendungen beizubehalten.

Den integrierten und den klassischen ASP.NET-Modus verstehenIIS 7.0 bietet zwei Modi für das Hosting von ASP.NET-Anwendungen an: Integriert und Klassisch. Der integrierte Modus ist der neue Modus, der eine enge Verflechtung mit dem IIS-Webserver bietet und der es ASP.NET-Anwendungen ermöglicht, als vom Anwendungsframework unabhängige Webserver-features verwendet zu werden. Dieser Modus ist der IIS 7.0-Standardmodus und bietet in den meisten Fällen eine Abwärtskompatibilität mit bereits vorhandenen ASP.NET-Anwendungen. Die Konfigura-tion einiger bereits vorhandener ASP.NET-Anwendungen muss bisweilen ein wenig geändert werden, damit diese im integrierten Modus richtig funktionieren. Der Server erkennt viele dieser notwendigen Änderungen automatisch und hilft bei der Migration, indem er solche Anwendungen in nur einem Schritt auf den integrierten Modus vorbereitet. Wir werden später in diesem Kapitel die Migration ausführlich erörtern.

Der klassische Modus bietet die Option, ASP.NET-Anwendungen auf dieselbe Weise auszuführen, wie dies in früheren Versionen von IIS geschah. Der klassische Modus hält keinen der zusätzlichen Vorzüge bereit, die mit dem integrierten Modus einhergehen. Er ist als Ausweichlösung für solche ASP.NET-Anwendungen gedacht, auf die sich die mit dem integrierten Modus verbundenen Änderungen aus-wirken.

Hinweis Verwechseln Sie die Integrationsmodi von ASP.NET (Integriert und Klassisch) nicht mit dem IIS-Arbeits-prozessisolationsmodus. Dabei handelt es sich um zwei ganz unterschiedliche Konzepte. IIS 7.0 unterstützt nur den IIS 6.0-Prozessisolationsmodus. Der IIS 5.0-Isolationsmodus wird nicht mehr unterstützt. ASP.NET wird unabhängig vom ASP.NET-Integrationsmodus immer prozessintern ausgeführt.

Die Unterschiede zwischen den beiden ASP.NET-Integrationsmodi sind in Abbildung 11.2 dargestellt. Im klassischen Modus wird ASP.NET als ISAPI-Erweiterung in IIS integriert, die nur die ihr zuge-ordneten Anforderungen verarbeitet. Diese Erweiterung richtet eine zweite Anforderungsverarbei-tungspipeline für ASP.NET-Anforderungen ein. Im integrierten Modus werden die von den ASP.NET-

Letztendlich wurde dieses Ziel größtenteils für IIS 7.0 erreicht. Bestimmte Bereitstellungs- und Entwicklungsaspekte wirken sich jedoch auf das Verhalten von ASP.NET-Anwendungen unter IIS 7.0 aus. Wenn Sie mit diesen Änderungen konfrontiert werden, sollten Sie daran denken, dass sie zur Unterstützung der neuen Funktionalitätsebenen von ASP.NET-Anwendungen und des Webservers im Allgemeinen erforderlich waren. Für die meisten dieser Änderungen existieren einfache Work-arounds, die es Ihren Anwendungen ermöglichen, die Vorzüge des integrierten Modus zu nutzen. In einigen wenigen Fällen werden Sie dazu tendieren, Ihre Anwendungen für die Ausführung im klassischen Modus zu konfigurieren, um diesen Änderungen aus dem Weg zu gehen – in diesem Fall werden Sie jedoch die vielen Verbesserungen, die sich durch den integrierten Modus ergeben, nicht nutzen können.

Mike Volodarsky




Modulen und -Handlern bereitgestellten ASP.NET-Features an die Anforderungsverarbeitungspipeline von IIS angeschlossen, so dass mehrere Pipelines vermieden werden und die einzelne Pipeline für alle an den Server gerichteten Anforderungen ausgeführt wird.

Abbildung 11.2 Integration von ASP.NET in IIS 7.0

Der integrierte Modus bietet mehrere wichtige Vorteile – sowohl für bereits vorhandene als auch für neue ASP.NET-Anwendungen –, die ihn für den Betrieb unter IIS 7.0 prädestinieren:

� ASP.NET-Anwendungsdienste können in der gesamten Website einheitlich verwendet werden und sind nicht ausschließlich auf ASP.NET-Inhalte beschränkt. Dazu zählen solche ASP.NET-Features wie die Formularauthentifizierung, Rollen, die Ausgabezwischenspeicherung und alle von Modulen zur Verfügung gestellten benutzerdefinierten ASP.NET-Dienste, die Teil der Anwendung sind. Diese Möglichkeit verringert auch die Verwaltungskomplexität, da nur ein Satz Funktionalität für die gesamte Website verwaltet werden muss.

� Es ist möglich, ASP.NET anstelle von maschinennahen C++-Schnittstellen zu benutzen, um mit verwaltetem Code solche Module zu entwickeln, die Kernwebserverfeatures bereitstellen. Auf diese Weise wird die Zeit, die zur Entwicklung und Bereitstellung neuer Serverfunktionen not-wendig ist, drastisch verringert.

� Wichtige ASP.NET- und IIS-Konfigurationen werden vereinheitlicht, was die Verwaltung von Anwendungen vereinfacht.

� Bei Shared Server-Umgebungen, z.B. Shared Hostingservern oder Abteilungsservern, kann der Administrator dafür sorgen, dass Anwendungen wichtige Webserverfunktionen bereitstellen dürfen. Dies geschieht unter Verwendung von verwalteten Modulen. Administrative Rechte oder die globale Installation von Webserverfeatures auf dem Server sind hierfür nicht notwendig.



Hinweis Der integrierte Modus ist nicht erforderlich, um IIS- und ASP.NET-Konfigurationseinstellungen in den-selben web.config-Dateien zu speichern. Er ist ebenfalls nicht erforderlich, um neue IIS 7.0-Features wie die URL-Autorisierung und die Ausgabezwischenspeicherung nutzen zu können. Diese Fähigkeiten sind Bestandteil der Webserverplattform und sie sind nicht vom ASP.NET-Integrationsmodus abhängig.

Mit IIS 7.0 ist es möglich, auf demselben Server mehrere ASP.NET-Anwendungen gleichzeitig auszu-führen, die verschiedene Modi verwenden (Integriert bzw. Klassisch). Der ASP.NET-Integrations-modus kann somit für jeden Anwendungspool ausgewählt werden. Deshalb ist es einfach, die meisten ASP.NET-Anwendungen im integrierten Standardmodus ausführen zu lassen, während für die Anwen-dungen, denen dieser Modus Probleme bereitet, der klassische Modus verwendet wird. Später in diesem Kapitel wird die Auswahl des Integrationsmodus für Anwendungen ausführlich erläutert.

Selbst wenn Ihre Anwendung nicht sofort die Vorzüge des integrierten Modus nutzt, sollten Sie sich dennoch für diesen entscheiden – auch dann, wenn bestimmte Änderungen am Code notwendig sind. Der Grund hierfür besteht darin, dass die Arbeit im integrierten Modus gewährleistet, dass die Anwen-dung darauf vorbereitet ist, heute und in Zukunft verfügbare spezifische Webserverfeatures des integ-rierten Modus zu nutzen. Darüber hinaus werden zukünftige Versionen von IIS den klassischen Modus möglicherweise nicht mehr unterstützen. Alle Schritte, die Sie heute einleiten können, um alle Abhän-gigkeiten vom klassischen Modus auszuschließen, tragen somit dazu bei, dass künftige Migrationen zu neuen IIS-Versionen einfacher sein werden. Der klassische Modus ist eher als temporäre Lösung gedacht, um Anwendungen die Möglichkeit zu bieten, sich in Richtung IIS 7.0 zu bewegen. Er stellt keinesfalls eine langfristige Option dar.

Mehrere ASP.NET-Versionen gleichzeitig ausführenIIS hat schon immer die gleichzeitige Ausführung verschiedener ASP.NET-Versionen unterstützt, damit ASP.NET-Anwendungen gehostet werden konnten, die mit verschiedenen Versionen des .NET Frame-works arbeiteten. Dies wurde durch die Zuordnung der im entsprechenden .NET Framework-Versions-verzeichnis enthaltenen ISAPI-Erweiterung Aspnet_isapi.dll zu den ASP.NET-Inhaltstypen der jewei-ligen Anwendung ermöglicht. Das folgende Skript führt beispielsweise dazu, dass ASP.NET 2.0 verwendet wird, um Anforderungen zu verarbeiten, die sich auf .aspx-Seiten beziehen:.aspx,E:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ aspnet_isapi.dll,1,GET,HEAD,POST,DEBUG

Administratoren verwendeten oft das Tool Aspnet_regiis.exe, das sich im Verzeichnis %systemRoot%\ Microsoft.NET\Framework\version befand, um ASP.NET für ältere IIS-Versionen zu installieren. Dazu wurden entweder auf dem gesamten Server oder für eine bestimmte Anwendung Handlerzuordnungen für die entsprechende Version erstellt. Mit diesem Tool konnten Administratoren Skriptzuordnungen von verschiedenen ASP.NET-Versionen zu den jeweiligen ASP.NET-Anwendungen erzeugen, so dass diese unterschiedlichen ASP.NET-Versionen Seite an Seite ausgeführt werden konnten.

Dieser Ansatz war jedoch für Fehlkonfigurationen anfällig, die zu Problemen führten, welche dem ASP.NET-Produktsupport-Team besonders häufig gemeldet wurden. Das berüchtigtste dieser Probleme trat auf, wenn zwei Anwendungen, die mit verschiedenen ASP.NET-Versionen arbeiteten, im selben Anwendungspool abgelegt wurden. Da pro Prozess nur eine Version der CLR (Common Language Runtime) möglich ist, wurde die Anwendung, die als zweite angefordert wurde, nicht geladen. Das hatte unerwartete und unvorhersehbare Fehler zur Folge.



IIS 7.0 arbeitet mit einer neuen Form der ASP.NET-Versionsverwaltung, die sich des Umstandes bewusst ist, dass in jedem IIS-Arbeitsprozess nur eine ASP.NET-Version genutzt werden darf. Bei IIS 7.0 wird deshalb die für jeden IIS-Anwendungspool verwendete ASP.NET-Version mit dem Konfigurationsattribut managedRuntimeVersion explizit konfiguriert. Die ASP.NET-Handlerzuordnungen werden nicht für die Ver-sionsauswahl verwendet. Stattdessen werden sie auf dem Server vom ASP.NET-Setup global registriert und mit den entsprechenden Versionsvorbedingungen konfiguriert, so dass sie in jedem Anwendungspool basierend auf ihrer konfigurierten CLR-Version automatisch ausgewählt werden. Nachfolgend ist für ein System, das mit ASP.NET 1.1 und ASP.NET 2.0 arbeitet, ein Auszug aus dem Konfigurationsabschnitt system.webServer/handlers aufgeführt.<add name="ASPNET-ISAPI-1.1-PageHandlerFactory" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.Net\Framework\v1.1.4322\aspnet_isapi dll" preCondition="classicMode,runtimeVersionv1.1,bitness32" /> <add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" /> <add name="PageHandlerFactory-ISAPI-2.0" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="%systemroot%\Microsoft.NET\Framework\v2.0.50727\ aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness32"/>

Die Vorbedingung runtimeVersion wird verwendet, um die *.aspx-Handlerzuordnung auf eine bestimmte ASP.NET-Version vorzubereiten, so dass sie in Anwendungspools, die mit der entsprechenden Version der verwalteten Laufzeit arbeiten, automatisch ausgewählt werden kann. Da diese Handlerzuordnungen global installiert werden, müssen Sie nicht Aspnet_regiis.exe benutzen, um die ASP.NET-Version für eine Anwendung auszuwählen oder ASP.NET-Handlerzuordnungen für die richtige Version manuell zu erstellen.

Wenn Sie das managedRuntimeVersion-Konfigurationsattribut eines jeden IIS-Anwendungspools auf die gewünschte Version setzen, gewährleisten Sie, dass alle Anwendungen in diesem Pool die korrekte ASP.NET-Version verwenden. Somit wird der Anwendungspool zu der Stelle, an der die Versions-verwaltung für ASP.NET-Anwendungen erfolgt.

Hinweis Benutzen Sie nicht das Tool Aspnet_regiis.exe, um die ASP.NET-Versionen für Ihre Anwendungen zu installieren und zu verwalten. Wählen Sie die gewünschte Version stattdessen mithilfe der Anwendungspools aus.

Dem Konfigurationsattribut managedRuntimeVersion können die folgenden Werte zugewiesen werden: v1.1, v2.0 und "" (leer). Wenn Sie es auf einen leeren Wert setzen, wird keine CLR-Version in den Anwen-dungspool geladen, so dass darin keine ASP.NET-Anwendung ausgeführt werden kann.

Um sicherzustellen, dass Ihre Anwendung eine bestimmte ASP.NET-Version verwendet, können Sie entweder einen neuen IIS-Anwendungspool generieren, den Sie so einrichten, dass er mit der richtigen ASP.NET-Version arbeitet, oder Sie nutzen einen der bereits vorhandenen Anwendungspools, der für die gewünschte Version konfiguriert wurde. Weitere Informationen zur Auswahl eines vorinstallierten Anwendungspools mit der richtigen ASP.NET-Version finden Sie später in diesem Kapitel im Abschnitt »Den richtigen Anwendungspool für die benötigte ASP.NET-Version und den entsprechenden Integrationsmodus auswählen«.



ASP.NET installierenBevor Sie ASP.NET-Anwendungen mit IIS 7.0 hosten können, müssen Sie ASP.NET installieren. IIS 7.0 unterstützt die folgenden Versionen des ASP.NET-Frameworks:

� ASP.NET 2.0

Dies ist die unter Windows Vista und Windows Server 2008 verfügbare ASP.NET-Standardversion, die Bestandteil des .NET Frameworks, Version 3.0, ist und unter Windows Vista über Programme und Funktionen und unter Windows Server 2008 über den Server-Manager als Rollendienst installiert werden kann. ASP.NET 2.0 unterstützt sowohl den integrierten als auch den klassischen Modus.

� ASP.NET 1.1

Ist kein Bestandteil des Betriebssystems. Sie können jedoch die .NET Framework 1.1-Redistribu-table zusammen mit dem .NET Framework 1.1 Service Pack 1 (SP1) herunterladen und installieren, um ASP.NET 1.1 zu installieren. ASP.NET 1.1 unterstützt lediglich den klassischen Betriebsmodus.

ASP.NET 1.0 und das .NET Framework 1.0 werden nicht mehr unterstützt. Wenn Sie ASP.NET 1.0-Anwendungen ausführen lassen möchten, müssen Sie diese upgraden, so dass sie unter ASP.NET 1.1 laufen.

Nach der Installation von ASP.NET müssen Sie eine IIS 7.0-Anwendung erstellen, die Ihre ASP.NET-Anwendung hostet. Sie müssen außerdem möglicherweise einen gesonderten Anwendungspool erstellen, so dass Sie den integrierten oder klassischen ASP.NET-Betriebsmodus auswählen können. Vielleicht müssen Sie auch die Konfiguration Ihrer Anwendung migrieren, so dass diese im integrierten Modus korrekt ausgeführt wird. Wir werden später in diesem Kapitel im Abschnitt »ASP.NET-Anwendungen bereitstellen« einen genauen Blick auf diese Aufgaben werfen.

ASP.NET 2.0 installierenASP.NET 2.0 kann unter Windows Vista über Programme und Funktionen und unter Windows Server 2008 über den Server-Manager als Rollendienst installiert werden. Die Installation führt alle Schritte zum Einrichten der IIS-Konfiguration aus, die benötigt wird, um ASP.NET 2.0 sowohl im klassischen als auch im integrierten Modus auszuführen. Aspnet_regiis.exe muss dann nicht mehr verwendet werden, um ASP.NET für IIS zu registrieren. Unter IIS 7.0 sollten Sie dieses Tool generell nicht benutzen, um ASP.NET zu installieren.

Vorsicht Benutzen Sie nicht Aspnet_regiis.exe, um ASP.NET 2.0 unter IIS 7.0 zu installieren.

Sie können außerdem eine weitere Option nutzen. Wenn Sie nicht die gesamte ASP.NET-Funktionalität benötigen, wie z.B. die Unterstützung von ASPX-Seiten und die integrierten ASP.NET-Handler und -Module, müssen Sie ASP.NET nicht vollständig installieren. Sie können stattdessen die .NET-Erweiterbar-keitskomponente installieren, die dafür sorgt, dass auf dem Server benutzerdefinierte ASP.NET-Module und -Handler von Anwendungen genutzt werden können, die im integrierten Modus ausgeführt werden. Dies ist eine nützliche Option, wenn Sie im integrierten ASP.NET-Modus arbeiten möchten, um andere Anwendungsframeworks mit benutzerdefinierten ASP.NET-Modulen zu erweitern und das ASP.NET-Anwendungsframework selbst nicht benötigen.

Hinweis Wenn Sie anstelle von ASP.NET die .NET-Erweiterbarkeitskomponente installieren, können Anwendun-gen, die im integrierten Modus arbeiten, ASP.NET-Handler und -Module nutzen. Das ASP.NET-Anwendungsframe-work selbst (Unterstützung von ASPX-Seiten usw.) wird nicht installiert, so dass auch keine ASP.NET-Anwendungen möglich sind, die den klassischen Modus nutzen.



Weitere Informationen zur Installation von IIS 7.0-Komonenten über das Windows-Setup finden Sie im fünften Kapitel, »Installieren von IIS 7.0«.

ASP.NET 1.1 installierenIm Gegensatz zu ASP.NET 2.0 ist ASP.NET 1.1 kein Bestandteil des Betriebssystems. Um es zu installieren, müssen Sie die .NET Framework 1.1-Redistributable und das .NET Framework Service Pack 1 (SP1) herunterladen und installieren. Das Update ist notwendig, um ASP.NET 1.1-Anwen-dungen ausführen zu können.

Um ASP.NET 1.1 zu installieren, gehen Sie wie folgt vor:

1. Installieren Sie die Komponente IIS 6-Metabasiskompatibilität. Mit dieser Komponente werden die Metabasiskompatibilitäts-APIs installiert, die ASP.NET 1.1 benutzt, um sich selbst zu installieren und zur Laufzeit die IIS-Konfiguration zu lesen. Sie können die IIS 6-Metabasiskompatibilität unter Windows Vista über Programme und Funktionen und unter Windows Server 2008 über den Server-Manager als Rollendienst installieren.

2. Laden Sie die .NET Framework 1.1-Redistributable herunter und installieren Sie diese.

3. Laden Sie das .NET Framework 1.1 Service Pack 1 (SP1) herunter und installieren Sie dieses.

4. Aktivieren Sie in den ISAPI- und CGI-Einschränkungen den Eintrag ASP.NET v1.1.4322. Sie können dies mit dem IIS-Manager oder wie folgt mit Appcmd.exe tun:%systemroot%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis –enable

5. Fügen Sie der machine.config-Datei des Frameworks 1.1 und dort dem Abschnitt system.webServer den Handler IgnoreSection hinzu. Dies ist notwendig, weil ASP.NET 1.1 nicht die IIS 7.0-Konfiguration kennt, die in web.config-Dateien gespeichert werden kann. Fügen Sie dem <configSections>-Element die folgenden Einstellungen hinzu:</configSections> … <section name="system.webServer" type="System.Configuration.IgnoreSection" /> </configSections>

Die Installation des .NET Frameworks ruft automatisch Aspnet_regiis.exe -i auf, um ASP.NET 1.1 zu installieren. Windows Server 2008 und Windows Vista SP1 verwenden einen Anwendungskompatibili-tätsshim, um den Aufruf dieses Tools abzufangen und die erforderliche IIS 7.0-Konfiguration für die Registrierung von ASP.NET 1.1 zu generieren. Diese Konfiguration setzt sich wie folgt zusammen:

� ASP.NET 1.1-Handlerzuordnungen, die auf der Serverebene erzeugt werden und für die Vorbedin-gungen definiert sind, die dafür sorgen, dass diese Zuordnungen nur in solchen Anwendungspools verwendet werden, die für das .NET Framework 1.1 konfiguriert sind.

� Der Anwendungspool ASP.NET 1.1, der standardmäßig von ASP.NET 1.1-Anwendungen genutzt werden kann. Dieser Anwendungspool ist immer (auch bei 64-Bit-Betriebssystemen) für die Aus-führung im 32-Bit-Modus und die Nutzung des klassischen ASP.NET-Integrationsmodus konfi-guriert.

Vorsicht Benutzen Sie nicht das Tool Aspnet_regiis.exe, um ASP.NET 1.1 unter IIS 7.0 zu installieren oder eine bestimmte Anwendung für die Arbeit mit ASP.NET 1.1 zu konfigurieren. Legen Sie stattdessen jede Anwendung, die mit dieser ASP.NET-Version arbeiten soll, im angebotenen ASP.NET 1.1-Anwendungspool ab oder erstellen Sie einen neuen Anwendungspool, der das .NET Framework 1.1 verwendet. Weitere Informationen finden Sie früher in diesem Kapitel im Abschnitt »Mehrere ASP.NET-Versionen gleichzeitig ausführen«.



Wenn Sie neue Anwendungspools erstellen, um ASP.NET 1.1-Anwendungen zu hosten, muss für jeden Anwendungspool:

� das managedRuntimeVersion-Konfigurationsattribut auf v1.1 gesetzt werden.

� das managedPipelineMode-Konfigurationsattribut auf Classic gesetzt werden. ASP.NET 1.1 unterstützt nicht die Ausführung im integrierten Modus.

� bei 64-Bit-Betriebssystemen das Konfigurationsattribut enable32BitAppOnWin64 auf true gesetzt werden. ASP.NET 1.1 unterstützt keine Ausführung im nativen 64-Bit-Modus.

ASP.NET-Anwendungen bereitstellenNachdem Sie die korrekte ASP.NET-Version installiert haben, können Sie ASP.NET-Anwendungen auf dem Server bereitstellen. Gehen Sie dazu wie folgt vor:

1. Erstellen Sie eine IIS-Anwendung.

2. Platzieren Sie die Anwendung in einem Anwendungspool mit der richtigen ASP.NET-Version und dem entsprechenden Integrationsmodus.

3. Stellen Sie die ASP.NET-Anwendungsinhalte bereit.

4. Migrieren Sie die ASP.NET-Anwendungskonfiguration, damit die Anwendung im integrierten Modus ausgeführt werden kann (dies ist optional und nur für ASP.NET 2.0-Anwendungen erfor-derlich, die im integrierten Modus ausgeführt werden und migriert werden müssen).

Eine IIS-Anwendung erstellenObwohl Sie ASP.NET-Seiten für jede Anwendung, jedes virtuelle Verzeichnis und jedes Unterver-zeichnis bereitstellen können, möchten Sie eine ASP.NET-Anwendung und all ihre Inhalte in der Regel in einer gesonderten IIS-Anwendung zur Verfügung stellen. Der Grund hierfür besteht darin, dass sich die Elemente einer ASP.NET-Anwendung – z.B. Global.asax, das /BIN-Verzeichnis, das /App_Code-Verzeichnis und andere /App_-Verzeichnisse – im Stamm einer IIS-Anwendung befinden müssen. Ähnlich hierzu müssen viele ASP.NET-Konfigurationseinstellungen in der web.config-Stammdatei der Anwendung vorgenommen werden, damit sie Wirkung zeigen. Darüber hinaus werden Sie oft die Inhalte einer ASP.NET-Anwendung von anderen Inhalten isolieren wollen, weil sie auf einer anderen Anwendungsebene konfiguriert werden müssen oder Zustandsdaten verwenden, die mit der aktuellen Anwendungsebene nicht kompatibel sind.

Diese Anforderung ist nicht neu, obwohl IIS 7.0 Anwendungen strenger definiert als vorherige IIS-Versionen. Deshalb müssen Sie sicherstellen, dass die ASP.NET-Anwendung im virtuellen Stamm-verzeichnis einer IIS-Anwendung bereitgestellt wird, und manchmal müssen Sie zu diesem Zweck eine neue Anwendung erzeugen. Sie können dies mit dem IIS-Manager oder wie folgt mit Appcmd tun:%systemroot%\system32\inetsrv\appcmd.exe add app "/site.name:SiteName" "/path:VirtualPathOfApplication" "/physicalPath:PhysicalRootDirectoryOfApplication"

Sie müssen möglicherweise ebenfalls eine gesonderte IIS-Anwendung erstellen, so dass diese in dem Anwendungspool platziert werden kann, der die richtige .NET Framework-Version und den entsprech-enden ASP.NET-Integrationsmodus verwendet. Dies wird gleich im Anschluss erläutert.

Weitere Informationen zur Erstellung und Verwaltung von Anwendungen erhalten Sie im zehnten Kapitel, »Verwalten von Anwendungen und Anwendungspools«.



Den richtigen Anwendungspool für die benötigte ASP.NET-Version und den entsprechenden Integrationsmodus auswählenNachdem Sie die Anwendung erstellt haben, müssen Sie sie so konfigurieren, dass sie einen Anwen-dungspool nutzt, der mit der richtigen ASP.NET-Version und dem entsprechenden Integrationsmodus arbeitet. Im Gegensatz zu IIS 6.0 wird die von der Anwendung verwendete ASP.NET-Version nun auf der Anwendungspoolebene festgelegt, was mit dem Konfigurationsattribut managedRuntimeVersion geschieht. Dies gewährleistet eine vorab festgelegte Zuordnung zwischen IIS-Arbeitsprozessen und den von diesen Prozessen geladenen CLR-Versionen. Ähnlich hierzu wird auch der ASP.NET-Integrationsmodus für jeden einzelnen Anwendungspool gesetzt, was mit dem Konfigurationsattribut managedPipelineMode geschieht. Sie müssen diese Einstellungen Ihren Absichten entsprechend konfigurieren, um sicherzu-stellen, dass Ihre Anwendung im richtigen Anwendungspool platziert wird. Tabelle 11.2 beschreibt diese Einstellungen.

Da alle neuen Anwendungen standardmäßig den Anwendungspool DefaultAppPool verwenden, arbeiten sie im integrierten ASP.NET 2.0-Modus, weil DefaultAppPool für diesen Modus konfiguriert ist. Soll eine ASP.NET 2.0-Anwendung im klassischen Modus ausgeführt werden, können Sie den vorinstallierten Anwendungspool Classic .NET AppPool nutzen.%systemroot%\system32\inetsrv\appcmd.exe set app "ApplicationPath" "/applicationPool:Classic .NET AppPool"

Wenn Sie eine ASP.NET 1.1-Anwendung ausführen lassen möchten, können Sie diese im bereits vorhandenen Anwendungspool ASP.NET 1.1 platzieren (der während der Installation von ASP.NET 1.1 vom .NET Framework 1.1-Setup erstellt wird).%systemroot%\system32\inetsrv\appcmd.exe set app "ApplicationPath" "/applicationPool:ASP.NET 1.1"

Sie können auch neue Anwendungspools erstellen und deren Konfigurationsattribute managedPipelineMode und managedRuntimeVersion setzen, damit Ihre neue Anwendung richtig gehostet wird. Weitere Informa-tionen zur Erstellung und Verwaltung von Anwendungspools finden Sie im zehnten Kapitel.

Tabelle 11.2 Standardanwendungspools für verschiedene ASP.NET-Versionen

Gewünschte Umgebung Anwendungspooleinstellungen

ASP.NET 1.1 managedRuntimeVersion: v1.1

managedPipelineMode: Classic

Kann den Anwendungspool ASP.NET 1.1 verwenden

Integrierter ASP.NET 2.0-Modus managedRuntimeVersion: v2.0

managedPipelineMode: Integrated

Kann den Standardanwendungspool DefaultAppPool verwenden

Klassischer ASP.NET 2.0-Modus managedRuntimeVersion: v2.0managedPipelineMode: Classic

Kann den Anwendungspool Classic .NET AppPool verwenden



ASP.NET 2.0-Anwendungen für die Verwendung des integrierten Modus migrierenNachdem Sie eine IIS-Anwendung erstellt und im richtigen Anwendungspool platziert haben, können Sie im Stammverzeichnis dieser Anwendung die entsprechenden Inhalte bereitstellen. Ihre Anwendung sollte dann bereit für die Ausführung sein.

Wie bereits erwähnt wurde, arbeiten die meisten bereits vorhandenen ASP.NET 2.0-Anwendungen ohne Probleme im integrierten Modus. In einigen Fällen sind jedoch Konfigurationsänderungen erfor-derlich, damit die Anwendung korrekt funktioniert. Diese Änderungen müssen vorgenommen werden, weil IIS 7.0 im integrierten Modus einige ASP.NET-Konfigurationen übernimmt, damit die Integration erfolgen kann. Wenn Ihre ASP.NET-Anwendung einen der betroffenen und in Tabelle 11.3 aufgeführten Konfigurationsabschnitte definiert, erhalten Sie eine Fehlermeldung, sobald Sie die Inhalte dieser Anwendung anfordern, wie in Abbildung 11.3 dargestellt.

Abbildung 11.3 Serverfehler, der Aufschluss darüber gibt, dass eine Migration erforderlich ist, damit die Anwendung im integrierten Modus arbeiten kann

Der Fehler gibt an, dass die Anwendung eine nicht unterstützte ASP.NET-Konfiguration enthält. Im Bereich Wahrscheinlichste Ursachen ist zu sehen, dass es sich dabei um den Konfigurationsabschnitt system.web/httpModules handelt. Die Fehlerseite schlägt außerdem Schritte zur Behebung des Problems vor (die in Abbildung 11.3 nicht dargestellt sind). Einer dieser Vorschläge bezieht sich auf das Migrieren der Anwendungskonfiguration mit dem Befehlszeilentool Appcmd.exe (näheres hierzu folgt gleich).

Tabelle 11.3 beschreibt Fälle, in denen dieser Fehler ausgelöst wird, und nennt die zur Problembehebung notwendigen Migrationsschritte.



Die ersten beiden Fälle beziehen sich auf die Integration von ASP.NET-Handlern und -Modulen in die IIS-Handler- und Modulkonfiguration. Im integrierten Modus werden ASP.NET-Module und -Handler direkt in der IIS-Webserverpipeline ausgeführt und nicht in den ASP.NET-Konfigurationsabschnitten system.web/httpModules und system.web/httpHandlers, sondern in den IIS-Abschnitten system.webServer/modules und system.webServer/handlers konfiguriert. Sie können die notwendige Konfigurationsmigration automatisch durchführen lassen, indem Sie den Appcmd-Befehl Migrate Config benutzen.%systemroot%\system32\inetsrv\AppCmd Migrate Config "ApplicationPath"

ApplicationPath ist der Konfigurationspfad der zu migrierenden Anwendung. Dieser Befehl führt eine automatische Konfigurationsmigration durch, so dass die Anwendung im integrierten Modus korrekt arbeitet.

Der letzte Fall bedarf einer näheren Erläuterung. ASP.NET-Anwendungen, die so konfiguriert sind, dass sie für eine Anforderung die Identität des authentifizierten Benutzers annehmen, können diese Identitäts-übernahme traditionell für die Dauer der gesamten Anforderung aufrechterhalten. Im integrierten Modus ist die Identitätsübernahme erst nach der AuthenticateRequest-Phase möglich, aber ASP.NET-Module können bereits früher in der Anforderungsverarbeitungspipeline ausgeführt werden. Dies ist in der Regel kein Problem, da ASP.NET-Module zu Beginn der Anforderungsverarbeitungspipeline üblicherweise nicht auf die Identitätsübernahme zurückgreifen müssen. IIS empfiehlt jedoch, Anwendungen, die die Identitäts-übernahme nutzen, sicherheitshalber im klassischen Modus auszuführen. Wenn Sie wissen, dass Sie nicht mit benutzerdefinierten ASP.NET-Modulen arbeiten, die in den Phasen BeginRequest und AuthenticateRequest darauf angewiesen sind, eine bestimmte Identität anzunehmen, können Sie diese Empfehlung ignorieren, indem Sie die Konfigurationsvalidierung für Ihre Anwendung deaktivieren. Die dazu notwendige Vorgehensweise wird gleich erläutert.

Nachdem die Migration durchgeführt wurde, generiert Appcmd eine spezielle Konfiguration, die eine weitere Validierung der Anwendung ausschließt. (Sie können diese Konfiguration nach der Migration auch selbst manuell erstellen.) Die ASP.NET-Anwendung kann dann ihre frühere ASP.NET-Konfigura-tion, die für den klassischen Modus oder frühere IIS-Versionen verwendet wurde, beibehalten. Zusätzlich wird die migrierte Konfiguration zur Verfügung gestellt, so dass ein sicherer Wechsel zwischen klassi-schem und integriertem Modus und zu Vorgängerplattformen möglich ist. Sie können diese Konfiguration ebenfalls verwenden, um die Validierung zu deaktivieren, so dass <identity impersonate="true" /> zu keinem Validierungsfehler führt. Eine solche Konfiguration ist wie folgt aufgebaut:<system.webServer> <validation validateIntegratedModeConfiguration="false" /> </system.webServer>

Tabelle 11.3 ASP.NET-Konfiguration, die für den integrierten Modus migriert werden muss

Situation Empfohlene Aktion

Die Anwendung definiert im Konfigurations-abschnitt system.web/httpModules benutzer-definierte Module

Entfernen Sie die Moduleinträge aus dem Abschnitt system.web/httpModules und ordnen Sie sie im IIS-Abschnitt system.webServer/modules an. Das Migrationstool kann dies automatisch tun.

Die Anwendung definiert im Konfigurations-abschnitt system.web/httpHandlers benutzer-definierte Handlerzuordnungen

Entfernen Sie die Handlereinträge aus dem Abschnitt system.web/httpHandlers und ordnen Sie sie im IIS-Abschnitt system.webServer/handlers an. Das Migra-tionstool kann dies automatisch tun.

Die Anwendung ermöglicht im Konfigurations-abschnitt system.web/identity den Anforde-rungsidentitätswechsel

Konfigurieren Sie die Anwendung für den klassischen Modus oder so, dass sie diesen Fehler ignoriert



Sobald diese Konfiguration der web.config-Datei der Anwendung hinzugefügt wurde, versucht IIS 7.0 nicht mehr, die ASP.NET-Konfiguration zu validieren. Nachdem Sie die Anwendung somit einmal migriert haben, müssen Sie sicherstellen, dass Konfigurationsänderungen in den Konfigurations-abschnitten sowohl für den klassischen als auch für den integrierten Modus gespeichert werden.

Die Vorzüge des integrierten ASP.NET-Modus nutzenWenn Sie Ihre Anwendung im integrierten Modus bereitstellen, können Sie die Vorzüge der ASP.NET-Integration nutzen. Der Hauptvorteil ist die Möglichkeit, innerhalb Ihrer Anwendung die von den ASP.NET-Modulen angebotenen Dienste für alle Anforderungen in Anspruch zu nehmen, und zwar unabhängig davon, ob sich diese Anforderungen auf ASP.NET-Inhalte, statische Dateien oder andere Anwendungsinhalte wie ASP oder PHP beziehen. Dies ist besonders für Entwickler von Bedeutung, die nun schnell neue Module unter Verwendung vertrauter ASP.NET-APIs erstellen können, um Dienste für die gesamte Website zur Verfügung zu stellen. Die Entwicklung mit komplizierten nativen und auf C++ basierenden Webserver-APIs, wie z.B. ISAPI, ist dazu nicht mehr notwendig. Diese Module können in Form von Webserverfeatures, die Dienste wie die Authentifizierung anbieten, oder kleineren anwen-dungsspezifischen Modulen vorliegen, deren Dienstleistungen z.B. Umleitungen oder serverseitige URL-Umschreibungen sind.

Weiterführende Informationen Weitere Informationen zur Entwicklung verwalteter Module und verwaltete Beispielmodule finden Sie unter http://mvolo.com/blogs/serverside/archive/2007/08/15/Developing-IIS7-Web-server-features-with-the-.NET-framework.aspx.

Darüber hinaus können bereits vorhandene Anwendungen mithilfe des integrierten ASP.NET-Modus sofort damit beginnen, ihre bereits vorhandenen Module oder die bereits vorhandenen Module, die Bestandteil von ASP.NET sind, zu nutzen. Ein bekanntes Beispiel hierfür ist der Einsatz des integrierten ASP.NET-Formularauthentifizierungsmoduls, um eine formularbasierte Authentifizierung für die gesamte Website zur Verfügung zu stellen, so dass die leistungsfähigen ASP.NET-Anmeldesteuer-elemente und die Mitgliedschaftsfunktionalität für die Benutzerverwaltung verwendet werden können.

Weiterführende Informationen Weitere Informationen zur Verwendung der Formularauthentifizierung für den Schutz einer ganzen Website finden Sie unter http://www.iis.net/articles/view.aspx/IIS7/Extending-IIS7/Getting-Started/How-to-Take-Advantage-of-the-IIS7-Integrated-Pipel.

Tabelle 11.4 listet die ASP.NET-Module auf, die innerhalb von im integrierten Modus arbeitenden Anwen-dungen verwendet werden können, um Dienste für die gesamte Website zur Verfügung zu stellen.

Alle integrierten ASP.NET-Module sind standardmäßig so konfiguriert, dass sie nur für ASP.NET-Inhaltstypen ausgeführt werden. Dies geschieht, um für Anwendungen, die im integrierten Modus ausgeführt werden, eine Abwärtskompatibilität zu gewährleisten. Damit ein ASP.NET-Modul für alle auf Ihre Anwendung bezogenen Anforderungen ausgeführt wird, müssen Sie innerhalb der Anwendung die managedHandler-Vorbedingung aus dem entsprechenden Konfigurationselement des Konfigura-tionsabschnitts system.webServer/modules entfernen. Sie können dies mit dem IIS-Manager tun, indem Sie im Hierarchielistenfeld Ihre Anwendung markieren, einen Doppelklick auf dem Symbol Module aus-führen, auf das gewünschte Modul doppelklicken, um es zu bearbeiten, und das Kontrollkästchen Nur für ASP.NET-Anwendungen und verwaltete Handler aufrufen deaktivieren, wie in Abbildung 11.4 dargestellt.



Abbildung 11.4 Mit dem IIS-Manager das Formularauthentifizierungsmodul für die Ausführung bei allen Anforderungen konfigurieren

Neue auf der Anwendungsebene hinzugefügte Module werden standardmäßig für alle Anforderungen ausgeführt, sofern Sie dies nicht explizit verbieten. Weitere Informationen zur Aktivierung der Ausfüh-rung von ASP.NET-Modulen für alle Anforderungen finden Sie im zwölften Kapitel, »Verwalten von Webservermodulen«.

Zusätzliche Überlegungen zur BereitstellungDieser Abschnitt beschreibt einige zusätzliche Überlegungen zur Bereitstellung von ASP.NET-Anwen-dungen, die unter IIS 7.0 ausgeführt werden.

Grundlegende Veränderungen im integrierten ASP.NET 2.0-ModusDie meisten ASP.NET 2.0-Anwendungen arbeiten korrekt, wenn sie nach der notwendigen Konfigurations-migration im integrierten Modus gehostet werden. An einigen Anwendungen müssen jedoch grundlegende Änderungen vorgenommen werden. Möglicherweise sind Änderungen am Anwendungscode notwendig, oder die Anwendung muss im klassischen Modus ausgeführt werden. Weitere Informationen zur Auswahl des ASP.NET-Integrationsmodus für eine Anwendung finden Sie früher in diesem Kapitel im Abschnitt »ASP.NET-Anwendungen bereitstellen«.

Tabelle 11.4 Module, die im integrierten Modus für alle Webseiteinhalte zur Verfügung stehen

Modul Verwendungszweck

FormsAuthentication Schützt die gesamte Website mit der formularbasierten Authentifizierung von ASP.NET. Dazu werden die ASP.NET-Anmeldesteuerelemente und der Mitgliedschaftsdienst verwendet.

UrlAuthorization Schützt die gesamte Website mit deklarativen Zugriffsteuerungsregeln für Benutzer und Rollen, die in der Konfiguration festgelegt sind (Sie können ebenfalls das IIS-Modul UrlAuthorization benutzen)

RoleManager Bietet eine umfassende Rollenunterstützung für jede Authentifizierungsmethode, die den ASP.NET-Rollen-dienst verwendet. Wird in der Regel zusammen mit UrlAuthorization für eine deklarative Zugriffssteuerung oder ein benutzerdefiniertes Autorisierungsschema benutzt.

OutputCache Speichert Anwendungsantworten zur Wiederverwendung im ASP.NET-Ausgabecache, um wesentliche Leistungssteigerungen zu erzielen. Dies erfordert in der Regel zusätzlichen Code zum Konfigurieren des Ausgabecaches.



Die erforderlichen grundlegenden Änderungen und Workarounds sind unter http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx beschrieben.

ASP.NET-Anwendungen über Remote-UNC-Freigaben hostenASP.NET-Anwendungen werden standardmäßig mit der Anwendungspoolidentität ausgeführt. In einigen Fällen können ASP.NET-Anwendungen ebenfalls konfiguriert werden, um die Identität des authentifizierten Benutzers anzunehmen. In diesem Fall nehmen Anwendungen, die den anonymen Zugriff gestatten, die Identität des anonymen Benutzers an, bei dem es sich standardmäßig um das integrierte Konto IUSR handelt. Andernfalls nehmen sie die Identität des authentifizierten Benutzers an.

Wenn die Anwendung über eine UNC-Freigabe (Universal Naming Convention) gehostet wird, besitzen der anonyme Standardbenutzer (IUSR) und die standardmäßige Anwendungspoolidentität (Netzwerkdienst) nicht die notwendigen Rechte, um auf die Remotenetzwerkfreigabe zuzugreifen. Deshalb müssen Sie sich für eine der folgenden Optionen entscheiden, um eine ASP.NET-Anwendung so zu konfigurieren, dass sie über eine UNC-Freigabe problemlos genutzt werden kann:

� Konfigurieren Sie feste Anmeldeinformationen für das virtuelle Stammverzeichnis der Anwen-dung, auf das über eine UNC-Freigabe zugegriffen wird. Diese Anmeldeinformationen müssen über das Recht verfügen, auf die Remotefreigabe zuzugreifen. Der Webserver und die ASP.NET-Anwendung nehmen dann immer die mit diesen Anmeldeinformationen verbundene Identität und nicht die Prozessidentität oder die Identität des authentifizierten Benutzers an. Diese Option wird für die meisten Fälle empfohlen.

� Konfigurieren Sie eine benutzerdefinierte Anwendungspoolidentität, die auf die Freigabe zugreifen kann. Wenn Sie mit der anonymen Authentifizierung arbeiten, richten Sie diese so ein, dass sie die Anwendungspoolidentität verwendet, um auf die Anwendungsressourcen zuzugreifen. Sie können diese Option für solche Situationen nutzen, in denen Sie Ihren Anwendungspool für die Verwen-dung eines Domänenkontos konfigurieren und dieses Domänenkonto einsetzen, um die Anwen-dung zu isolieren und den Zugriff auf die Netzwerkressourcen zu kontrollieren.

Wenn Sie eine benutzerdefinierte Anwendungspoolidentität benutzen, sollten Sie ebenfalls mit dem Tool Aspnet_regiis.exe arbeiten, um sicherzustellen, dass die benutzerdefinierte Anwendungspool-identität über die notwendigen Berechtigungen zur Ausführung von ASP.NET verfügt.Aspnet_regiis.exe -ga Domain\UserName

Domain ist die Domäne und UserName ist der Benutzername des benutzerdefinierten Kontos. Dies gewähr-leistet, dass das benutzerdefinierte Konto auf dem Webserver über alle notwendigen Berechtigungen verfügt, um ASP.NET-Anwendungen auszuführen.

Darüber hinaus sollten Sie die folgenden Einschränkungen kennen, die sich auf das Hosting von ASP.NET-Anwendungen über eine UNC-Freigabe beziehen:

� ASP.NET-Anwendungen unterstützen keine Aufteilung von virtuellen Verzeichnissen in Remote-UNC-Freigaben und lokale Verzeichnisse. Das virtuelle Stammverzeichnis muss sich in einer UNC-Freigabe befinden, damit diese untergeordnete virtuelle Verzeichnisse besitzen kann.


ASP-Anwendungen hosten 327

� Wenn die ASP.NET-Anwendung im Konfigurationsabschnitt system.webServer/identity eine benutzer-definierte Anwendungsidentität festlegt, wird diese Identität für eine UNC-Freigabe angenommen, weshalb sie ebenfalls Zugriffsrechte für diese Freigabe besitzen muss.

Sollen die in den ASP.NET-Anwendungen von UNC-Freigaben enthaltenen .NET-Assemblies (im Verzeichnis /BIN oder /App_Code) korrekt arbeiten, müssen Sie ebenfalls die UNC-Codezugriffsicher-heitsrichtlinie für den freigegebenen Netzwerkpfad bearbeiten. Dazu können Sie wie folgt das Befehls-zeilenhilfsmittel Caspol.exe benutzen (wobei \\myshare\mydir\ der Pfad zum virtuellen Verzeichnis ist):%systemroot%\Microsoft.NET\Framework\version\Caspol.exe –m –ag 1. –url "file://\\myshare\mydir\*" FullTrust

Denken Sie daran, dass andere von der Website oder Anwendung genutzte Anwendungsframeworks anders auf die jeweiligen Inhalte zugreifen können, so dass Sie das Zugriffsmodell auswählen müssen, das für alle Anwendungskomponenten sinnvoll ist und das den mit der Berechtigungsverwaltung einhergehenden Overhead auf ein Mindestmaß reduziert. Dies ist in der Regel das Modell mit den festen Anmeldeinformationen für ein virtuelles Verzeichnis. Weitere Informationen zur Zugriffs-konfiguration finden Sie im vierzehnten Kapitel, »Implementieren von Sicherheitsstrategien«.

ASP-Anwendungen hostenIIS 7.0 unterstützt auch weiterhin ASP-Anwendungen, verbessert oder verändert die ASP-Unter-stützung aber nicht, wie dies bei ASP.NET der Fall ist. ASP-Anwendungen profitieren jedoch von der besseren Konfigurierbarkeit und den neuen Webserverfeatures, die von IIS 7.0 angeboten werden. Darüber hinaus bietet die integrierte ASP.NET-Pipeline die Möglichkeit, nützliche ASP.NET-Features für ASP-Anwendungen einzusetzen, so dass innerhalb kürzester Zeit eine Funktionalitätserweiterung möglich ist, ohne die gesamte Anwendung in ASP.NET neu schreiben zu müssen.

Hinweis ASP.NET stellt Webanwendungen einen sehr viel reichhaltigeren Satz Webserverfunktionalität zur Verfügung, ermöglicht mithilfe von Microsoft Visual Studio-Tools eine schnelle Entwicklung und bietet eine bessere Interoperabilität mit den Features des .NET Frameworks und der Windows-Plattform.

In den nächsten Abschnitten dieses Kapitels werden wir die Schritte erörtern, die notwendig sind, um ASP zu installieren und ASP-Anwendungen unter IIS 7.0 bereitzustellen.

ASP installierenAufgrund der modularen Natur von IIS 7.0 ist die ASP-Unterstützung eine eigenständige Komponente, die installiert werden muss, bevor ASP-Anwendungen auf dem Server ausgeführt werden können. ASP kann unter Windows Vista mithilfe der Komponente Programme und Funktionen und unter Windows Server 2008 unter Verwendung des Server-Managers als Rollendienst installiert werden. Weitere Infor-mationen zur Installation von IIS 7.0-Komponenten über das Windows-Setup oder die Befehlszeile finden Sie im fünften Kapitel.

Die Installation von ASP führt automatisch zur Installation der ISAPI-Erweiterungsfunktionalität, weil ASP in Form der ISAPI-Erweiterung ASP.dll implementiert wird. Außerdem wird die ISAPI-Erweite-rung ASP.dll im Konfigurationsabschnitt system.webServer/security/isapiCgiRestriction automatisch aktiviert, damit sie auf dem Server ausgeführt werden kann. Nachdem die ASP-Komponente installiert wurde, sollten Ihre ASP-Anwendungen funktionieren.



ASP-Anwendungen bereitstellenDie Arbeitsweise von ASP-Anwendungen unter IIS hat sich bei IIS 7.0 nicht verändert. Demzufolge sollten ASP-Anwendungen problemlos funktionieren. Sie müssen Handlerzuordnungen für ASP nicht manuell erstellen, weil dies das Windows-Setup für Sie auf der Serverebene übernimmt, sobald die ASP-Unterstützung installiert wird. Es fügt außerdem dem Konfigurationsabschnitt system.webServer/security/isapiCgiRestriction die ISAPI-Erweiterung ASP.dll hinzu, damit diese ausgeführt werden kann. Deshalb ist es nicht notwendig, diese Aufgabe wie bei IIS 6.0 (wo Sie in der Einschränkungsliste für Webdiensterweiterungen eine entsprechende Aktivierung vornehmen müssen) manuell zu lösen. Um eine ASP-Anwendung bereitzustellen, müssen Sie lediglich die folgenden Schritte ausführen:

1. Erstellen Sie eine IIS-Anwendung.

2. Stellen Sie die Inhalte der ASP-Anwendung bereit.

ASP-Anwendungen müssen ähnlich wie ASP.NET-Anwendungen innerhalb einer IIS-Anwendung angeordnet werden. Diese Anforderung ist nicht neu, obwohl IIS 7.0 Anwendungen strenger definiert als vorherige IIS-Versionen. Deshalb müssen Sie sicherstellen, dass die ASP.NET-Anwendung im virtuellen Stammverzeichnis einer IIS-Anwendung bereitgestellt wird, und manchmal müssen Sie zu diesem Zweck eine neue Anwendung erzeugen. Sie können dies dem IIS-Manager oder wie folgt mit Appcmd tun:%systemroot%\system32\inetsrv\appcmd.exe add app "/site.name:SiteName" "/path:VirtualPathOfApplication" "/physicalPath:PhysicalPathOfApplication"

Weitere Informationen zur Erstellung und Verwaltung von Anwendungen finden Sie im zehnten Kapitel.

Sie können ebenfalls einzelne ASP-Seiten für bereits vorhandene Anwendungen oder virtuelle Ver-zeichnisse Ihres Servers bereitstellen. In diesem Fall werden diese Seiten zu einem Bestandteil der jeweiligen Anwendung. Wenn Ihre ASP-Anwendung jedoch Funktionalität auf der Anwendungsebene enthält, z.B. die Datei Global.asa, müssen Sie sicherstellen, dass die Anwendungsinhalte im Stamm der entsprechenden IIS-Anwendung bereitgestellt werden. In einigen Fällen werden Sie außerdem eine gesonderte Anwendung erstellen wollen, um Ihre Anwendungsfunktionalität von anderen Anwen-dungen zu isolieren – z.B. wenn Ihre ASP-Seiten Zustandsdaten im ASP-Objekt Application speichern.

Hinweis Die .NET Framework-Version und der ASP.NET-Integrationsmodus des Anwendungspools, der eine ASP-Anwendung hostet, haben keine Auswirkungen auf diese ASP-Anwendung. Deshalb können ASP-Anwendungen unabhängig von diesen Einstellung in allen Anwendungspools ausgeführt werden. Damit jedoch ASP-Anwendun-gen die von den verwalteten Modulen angebotenen Dienste nutzen können, müssen sie sich in Anwendungspools befinden, die den integrierten ASP.NET-Modus unterstützen.

Schließlich möchten Sie vielleicht die Vorzüge der Erstellung einer gesonderten Anwendung nutzen, um Ihre Anwendung durch die Anordnung in einem separaten Anwendungspool zu isolieren. Dies kann zu einer zusätzlichen Stabilität führen, weil zwischen Ihrer ASP-Anwendung und anderen Anwen-dungen auf dem Server eine Prozessgrenze errichtet wird. Sie können dann Berechtigungen für die Anwendungsinhalte festlegen, so dass nur Ihr Anwendungspool darauf zugreifen darf.

Weitere Informationen zum Isolieren von Anwendungen erhalten Sie im vierzehnten Kapitel.


ASP-Anwendungen hosten 329

Zusätzliche Überlegungen zur BereitstellungDieser Abschnitt beschreibt zusätzliche Überlegungen zur Bereitstellung von ASP-Anwendungen, so dass diese unter IIS 7.0 gehostet werden können.

Skriptfehler anzeigen lassenAus Gründen der Sicherheit verhindert IIS 7.0 standardmäßig, dass Skriptfehler zum Browser gesendet werden. Sie können dieses Verhalten aktivieren, indem Sie im Konfigurationsabschnitt system.webServer/asp das Konfigurationsattribut scriptErrorSentToBrowser setzen. Dies ist wie folgt mit Appcmd.exe möglich:%systemroot%\system32\inetsrv\Appcmd set config ConfigurationPath /section:system.WebServer/asp /scriptErrorSentToBrowser:true

ConfigurationPath ist der optionale Konfigurationspfad, für den diese Einstellung gesetzt werden soll. Wenn Sie auf die Angabe verzichten, ist der Standard der gesamte Server.

Sie können zusätzlich das IIS 7.0-Feature Benutzerdefinierte Fehler konfigurieren, damit detaillierte Fehlerinformationen zum Browser gesendet werden. IIS 7.0 sendet standardmäßig nur dann detaillierte Fehlerantworten, wenn die entsprechende Anforderung vom lokalen Server aus erfolgte. Remoteclients erhalten eine allgemeine Fehlermeldung. Weitere Informationen zur Konfiguration benutzerdefinierter Fehler finden Sie im vierzehnten Kapitel.

Standardmäßige Deaktivierung von übergeordneten PfadenSeit IIS 6.0 ist die Möglichkeit, übergeordnete Pfadsegmente ("..") in Aufrufen von ASP-Funktionen wie Server.MapPath zu verwenden, nicht mehr gegeben. Auf diese Weise soll verhindert werden, dass Dateien außerhalb des Anwendungsstamms geöffnet werden. Dies kann bei einigen Anwendungen, die solche übergeordneten Pfade zur Erstellung von Dateipfaden oder in #include-Direktiven verwenden, zu Problemen führen.

Trifft dies auch auf Ihre Anwendung zu, erhalten Sie Fehlermeldungen wie »Die Include-Datei 'Datei-name' darf kein '..' zur Angabe des übergeordneten Verzeichnisses enthalten« oder »Im Pfadparameter für die MapPath-Methode dürfen die Zeichen '..' nicht verwendet werden«. Wenn Sie mit einem solchen Fehler konfrontiert werden, können Sie die Anwendung modifizieren, damit sie übergeordnete Pfade nicht mehr benutzt. Oder Sie aktivieren übergeordnete Pfade, sofern Sie sicher sind, dass deren Einsatz kein Sicherheitsrisiko darstellt. Dazu setzen Sie im Konfigurationsabschnitt system.webServer/asp das Konfigurationsattribut enableParentPaths. Dies ist mit Appcmd.exe wie folgt möglich:%systemroot%\system32\inetsrv\Appcmd set config ConfigurationPath /section:system.WebServer/asp /enableParentPaths:true

Wie zuvor ist ConfigurationPath der optionale Konfigurationspfad, für den diese Einstellung gesetzt werden soll. Wenn Sie auf die Angabe verzichten, ist der Standard der gesamte Server.

ASP-Anwendungen über Remote-UNC-Freigaben hostenASP-Anwendungen nehmen wie alle ISAPI-Erweiterungen standardmäßig die Identität des authentifi-zierten Benutzers an, wenn sie Skripts ausführen und auf Ressourcen zugreifen. Bei Anwendungen, die den anonymen Zugriff gestatten, ist der authentifizierte Benutzer standardmäßig das integrierte Konto IUSR. Sie können die anonyme Authentifizierung auch so konfigurieren, dass die Anwendungspool-identität anstelle eines gesonderten Kontos genutzt wird.



Wenn die Anwendung über eine UNC-Freigabe (Universal Naming Convention) gehostet wird, besitzen der anonyme Standardbenutzer (IUSR) und die standardmäßige Anwendungspoolidentität (Netzwerk-dienst) nicht die notwendigen Rechte, um auf die Remotenetzwerkfreigabe zuzugreifen. Deshalb müssen Sie sicherstellen, dass der Anwendungspool und der authentifizierte Benutzer das Recht für den Zugriff auf die Netzwerkfreigabe erhalten. Dazu nutzen Sie in der Regel eine der folgenden Optionen:

� Konfigurieren Sie feste Anmeldeinformationen für die virtuellen Verzeichnisse der Anwendung, auf die über eine UNC-Freigabe zugegriffen wird. Diese Anmeldeinformationen müssen über das Recht verfügen, auf die Remotefreigabe zuzugreifen. Die ASP-Anwendung nimmt dann immer die mit diesen Anmeldeinformationen verbundene Identität und nicht die Identität des authentifizierten Benutzers an.

� Konfigurieren Sie eine benutzerdefinierte Anwendungspoolidentität, die auf die Freigabe zugreifen kann. Wenn Sie mit der anonymen Authentifizierung arbeiten, richten Sie diese so ein, dass sie die Anwendungspoolidentität verwendet. Wenn Sie mit anderen Authentifizierungsverfahren arbeiten, sollten Sie sicherstellen, dass alle authentifizierten Benutzer auf die Netzwerkfreigabe zugreifen können.

Weitere Informationen zur Zugriffskonfiguration finden Sie im vierzehnten Kapitel.

PHP-Anwendungen hostenIIS 7.0 bietet eine integrierte Unterstützung des FastCGI-Protokolls, das hinsichtlich des Hostens von PHP-Anwendungen effizienter und zuverlässiger als CGI oder ISAPI (die beiden anderen von PHP unterstützen Verfahren) ist. Beim FastCGI-Protokoll entsteht nicht der Overhead, der mit der Erstellung von Prozessen für einzelne Anforderungen einhergeht und kennzeichnend für das CGI-Protokoll unter Windows ist. Dieser Overhead wird vermieden, indem Prozesse in Pools verwahrt und für die Verar-beitung von Anforderungen wiederverwendet werden. Dadurch, dass gewährleistet ist, dass gleichzeitig nur eine Anforderung pro FastCGI-Prozess verarbeitet wird, bleibt die notwendige Single-Threaded-Umgebung erhalten, die von nicht-threadsicheren Anwendungsframeworks benötigt wird.

Direkt von der Quelle: Die Geschichte der PHP-Unterstützung in IISIIS unterstützt schon lange das PHP-Anwendungsframework. Die PHP-Standarddistributionen bieten zwei Schnittstellen für IIS an: eine mit CGI kompatible ausführbare Datei und eine ISAPI-Erweiterung. Beide Modi weisen jedoch bestimmte Einschränkungen auf, die das IIS 7.0-Hosting von PHP-Anwendungen in einer Produktionsumgebung oft unmöglich machen.

Der CGI-Modus ist oft mit Leistungseinbußen verbunden, weil für die Verarbeitung jeder Anfor-derung ein neuer PHP-CGI-Prozess gestartet werden muss. Diese erhöhte Prozessgenerierung schränkt die Leistung auf der Windows-Plattform drastisch ein. Der ISAPI-Modus leidet nicht unter Leistungsproblemen, weil ISAPI eine prozessinterne Multithreadingkomponente ist, die keine neuen Prozesse startet und deshalb eine hohe Leistung bieten kann. Die PHP-Skriptengine und die meisten vorwiegend verwendeten PHP-Erweiterungen wurden früher nicht unter dem Aspekt der Thread-sicherheit entwickelt, was in der ISAPI-Multithreadingumgebung oft zu Instabilitäten und Abstürzen führte. Selbst nachdem die PHP-Skriptengine threadsicher gestaltet worden war, blieben viele häufig genutzte OpenSource-Erweiterungen nicht threadsicher, weshalb viele im ISAPI-Modus gehostete PHP-Anwendungen weiterhin Instabilitäten aufwiesen.


PHP-Anwendungen hosten 331

Im Rest dieses Abschnitts werfen wir einen Blick auf die Schritte, die notwendig sind, damit PHP-Anwendungen unter IIS 7.0 ausgeführt werden können.

PHP-Anwendungen bereitstellenUm die Arbeit mit PHP zu ermöglichen, müssen Sie zunächst FastCGI auf dem Server installieren. Danach müssen Sie das PHP-Framework selbst herunterladen und installieren.

FastCGI installierenBevor Sie PHP im FastCGI-Modus ausführen können, müssen Sie FastCGI auf dem Server installieren.

Hinweis FastCGI kann ebenfalls verwendet werden, um andere mit FastCGI kompatible Anwendungsframeworks zu hosten. Später in diesem Kapitel, im Abschnitt »Mit FastCGI arbeitende Frameworks bereitstellen«, erfahren Sie mehr über den Einsatz von FastCGI zum Hosten von Anwendungsframeworks.

Die FastCGI-Unterstützung ist Bestandteil von Windows Vista SP1 und Windows Server 2008. FastCGI kann unter Windows Vista mithilfe der Komponente Programme und Funktionen als Teil der CGI-Komponente und unter Windows Server 2008 mithilfe des Server-Managers als Rollendienst installiert werden.

Hinweis Die FastCGI-Unterstützung war unter Windows Vista kein Bestandteil von IIS 7.0, wurde aber mit dem SP1 nachträglich hinzugefügt. Sie müssen somit SP1 installieren, um unter Windows Vista FastCGI nutzen zu können. In Windows Server 2008 ist es standardmäßig enthalten.

Bei IIS 7.0 dachten wir lange darüber nach, was notwendig ist, damit IIS zu einer optimalen Anwen-dungsplattform wird. Wir kamen überein, dass hierzu die Unterstützung einer breiten Palette von Anwendungsframeworks notwendig sei und dass sichergestellt werden müsse, dass diese Frame-works nicht nur zuverlässig unter IIS arbeiten, sondern ebenfalls die leistungsfähigen IIS 7.0- und integrierten ASP.NET-Features nutzen können. Wir stellten fest, dass die PHP-Probleme auch bei anderen Open Source-Anwendungsframeworks üblich waren, und so wurde das FastCGI-Projekt geboren. Ich kündigte zusammen mit Bill Staples, dem IIS-Product Unit Manager, im September 2006 dieses Projekt als integralen Bestandteil unserer Zusammenarbeit mit Zend an, dem Entwickler von PHP. Unser Ziel bestand darin, die IIS-Plattform mit einer äußerst stabilen PHP-Unterstützung zu versorgen. Sie finden den ersten Blogeintrag hierzu unter http://mvolo.com/blogs/serverside/archive/2006/09/29/Making-PHP-rock-on-Windows_2F00_IIS.aspx. Weitere Informationen zur Geschichte des FastCGI-Projekts erhalten Sie im unter http://mvolo.com/blogs/serverside/archive/2007/11/12/FastCGI-for-IIS-6.0-is-released-on-Download-Center.aspx.

Mittlerweile wurde Windows Server 2008 mit einer FastCGI-Unterstützung ausgestattet. Für IIS 6.0 kann diese Unterstützung heruntergeladen werden. Sie öffnet die Türen zum IIS-Hosting von PHP-Anwendungen in Produktionsumgebungen. Wir arbeiten auch mit anderen Anwendungsframework-Communities zusammen, um sicherzustellen, dass sie die FastCGI-Umgebung erfolgreich nutzen können, und wir hoffen, dass immer mehr Anwendungsframeworks FastCGI verwenden werden, um besser mit IIS zusammenzuarbeiten.

Mike Volodarsky




Sobald die CGI-Komponente installiert ist, steht FastCGI auf dem Webserver zur Verfügung. Das FastCGI-Modul ist ein eigenständiges Modul, das vom CGI-Modul getrennt ist, aber beide werden als Teil des CGI-Setups installiert (die Gründe hierfür sind historisch bedingt). Die alleinige Installation von FastCGI und CGI führt nicht automatisch dazu, dass Sie auf Ihrem Server CGI- oder FastCGI-Programme ausführen lassen können. Sie müssen die ausführbare PHP-FastCGI-Datei zunächst manu-ell aktivieren, damit eine entsprechende Ausführung möglich ist.

PHP installierenSie können die PHP-Framework-Builds von http://www.php.net/downloads herunterladen. Sie können von derselben Site ebenfalls die PECL-Bibliothek (PHP Extension Community Library) herunterladen. Dabei können Sie zwischen den folgenden beiden Optionen wählen:

� Die Win32-Standardbinärdateien herunterladen

� Die nicht-threadsicheren Win32-Binärdateien herunterladen

Hinweis Sie können ebenfalls einen auf MSI basierenden Installer herunterladen. Dieser Installer kann jedoch problematische Konfigurationen generieren, weshalb diese Vorgehensweise nicht empfohlen wird.

Die nicht-threadsicheren Binärdateien sind für die FastCGI-Ausführungsumgebung optimiert. Diese Umgebung verlangt keine Threadsicherheit, weil pro Anforderung ein Prozess ausgeführt wird. Die Binärdateien verursachen somit eine drastische Leistungssteigerung, weil der mit der Threadsicherheit einhergehende Overhead nicht mehr gegeben ist. Deshalb werden sie für die FastCGI-Umgebung von IIS 7.0 empfohlen.

Vorsicht Benutzen Sie die threadsicheren Standardbibliotheken, wenn Sie beabsichtigen, PHP in der ISAPI-Umgebung einzusetzen. Dies kann jedoch zu Instabilitäten führen und wird nicht empfohlen, da nicht alle PHP-Erweiterungen threadischer sind. Benutzen Sie FastCGI mit den nicht-threadsicheren PHP-Binärdateien, um eine optimale Leistung und Stabilität zu erzielen.

Nach dem Herunterladen der PHP-Binärdateien können Sie sie einfach in ein Verzeichnis Ihres Computers entpacken und eine Standardinstallation durchführen, bei der bisweilen die empfohlene php.ini-Konfigurationsdatei im PHP-Verzeichnis in Php.ini umbenannt und modifiziert werden muss, damit Ihre PHP-Anwendungen ausgeführt werden können. Sie sollten mindestens die in Tabelle 11.5 aufgeführten .INI-Einstellungen von PHP konfigurieren.

Tabelle 11.5 PHP-.INI-Einstellungen für FastCGI unter IIS 7.0

PHP-.INI-Einstellung Beschreibung

cgi.fix_pathinfo=1 Gewährleistet, dass für die CGI-Servervariablen PATH_INFO und PATH_TRANSLATED die richtigen Werte verwendet werden. Früher setzte PHP PATH_TRANSLATED auf SCRIPT_FILENAME und ignorierte PATH_INFO. Die aktuelle Einstellung veranlasst PHP, pfadbezogene Variablen so zu setzen, dass sie der CGI-Spezifikation entsprechen.

fastcgi.impersonate = 1 Diese Einstellung ermöglicht es PHP, die Identität des authentifizierten Benutzers anzunehmen. Vielleicht möchten Sie diese Einstellung nutzen. Weitere Informationen hierzu finden Sie später in diesem Kapitel im Abschnitt »Konfigurieren der PHP-Ausführungsidentität«.



Sie müssen möglicherweise weitere Einstellungen konfigurieren, die sich auf die von Ihnen verwendete PHP-Anwendung beziehen, um beispielsweise eine benötigte PHP-Erweiterungsbibliothek zu laden. Darüber hinaus möchten Sie vielleicht einige FastCGI-Einstellungen setzen, um die Leistung an die Bedürfnisse Ihrer PHP-Anwendung anzupassen. Dies wird später in diesem Kapitel im Abschnitt »Die Verfügbarkeit von PHP-Anwendungen sicherstellen« beschrieben.

Um schließlich zuzulassen, dass PHP von IIS aus verwendet werden kann, müssen Sie sicherstellen, dass IIS über Lesezugriffsrechte für das Verzeichnis verfügt, das die PHP-Framework-Dateien und die Anwendungsinhalte enthält. IIS-Anwendungspools werden standardmäßig unter der Identität Netz-werkdienst ausgeführt und sind somit Mitglieder der Gruppe Benutzer, die über Lesezugriffsrechte für die meisten Verzeichnisse des Servers verfügt. Wenn Netzwerkdienst jedoch nicht auf das entspre-chende Verzeichnis zugreifen kann oder Sie eine benutzerdefinierte Anwendungspoolidentität verwen-den, können Sie der Gruppe IIS_IUSRS die Rechte Lesen und Ausführen gewähren, damit IIS auf die PHP-Frameworkdateien zugreifen kann.

PHP-Anwendungen bereitstellenDamit PHP-Anwendungen unter Verwendung von FastCGI ausgeführt werden können, müssen Sie wie folgt vorgehen:

1. Erstellen Sie einen FastCGI-Anwendungseintrag für jede PHP-Version.

2. Erstellen Sie eine FastCGI-Handlerzuordnung, damit *.php-Skripts von der ausführbaren PHP-Datei verarbeitet werden, die mit FastCGI kompatibel ist.

Da der IIS-Manager den ersten Schritt automatisch ausführt, wenn Sie die entsprechende Handler-zuordnung erstellen, werden wir lediglich das Generieren dieser Zuordnung erörtern.

FastCGI-Handlerzuordnungen für PHP erstellenWenn die FastCGI-Unterstützung und das PHP-Framework auf dem Server installiert sind, können Sie dafür sorgen, dass PHP-Skripts unter Verwendung von FastCGI ausgeführt werden. Erstellen Sie dazu eine IIS-Handlerzuordnung, die das FastCGI-Modul benutzt, um auf PHP-Skripts bezogene Anforde-rungen unter Verwendung der ausführbaren PHP-FastCGI-Datei zu verarbeiten. Diese Zuordnung kann dem Server global hinzugefügt werden, damit PHP-Skripts in allen Websites des Servers ausgeführt werden können. Sie kann aber auch für eine bestimmte Site oder einen spezifischen URL hinzugefügt werden, damit die Ausführung von PHP-Skripts nur dort möglich ist.

Das Erstellen dieser Handlerzuordnung ist mit dem IIS-Manager schnell erledigt. Markieren Sie zunächst im Hierarchielistenfeld den Knoten des Servers oder der gewünschten Site, je nachdem, welchen Gültig-keitsbereich Sie für die Handlerzuordnung vorgesehen haben. Führen Sie anschließend einen Doppelklick auf Handlerzuordnungen aus. Weitere Informationen zur Erstellung und Verwaltung von IIS-Handler-zuordnungen finden Sie im zwölften Kapitel und dort im Abschnitt »Handlerzuordnungen hinzufügen«.

Sie können die Handlerzuordnung für PHP erstellen, indem Sie wie in Abbildung 11.5 dargestellt die Aktion Modulzuordnung hinzufügen verwenden, im Dropdown-Listenfeld Modul den Eintrag FastCGIModule auswählen und den Pfad zur ausführbaren Datei PHP-CGI.EXE angeben, die sich in Ihrem PHP-Installationsverzeichnis befindet.



Abbildung 11.5 Mit dem IIS-Manager eine FastCGI-Handlerzuordnung für PHP hinzufügen

Wenn Sie auf OK klicken, um die Zuordnung zu erstellen, wird ein Dialogfeld angezeigt, das von Ihnen wissen möchte, ob für die ausführbare Datei Php-cgi.exe ein FastCGI-Anwendungseintrag erzeugt werden soll, wie in Abbildung 11.6 dargestellt. Dies ist notwendig, um Php-cgi.exe mit FastCGI ausführen zu können (dies ist vergleichbar mit dem Hinzufügen einer ausführbaren CGI-Datei zur Einschränkungsliste für Weberweiterungen bei IIS 6.0).

Abbildung 11.6 Dialogfeld zum Bestätigen der Modulzuordnung

Wenn Sie in diesem Dialogfeld auf OK klicken, wird die erforderliche FastCGI-Anwendungskonfi-guration automatisch erzeugt. Eine manuelle Konfiguration ist nicht erforderlich. Dieses Dialogfeld wird nur einmal angezeigt, wenn ein Pfad zur ausführbaren Datei Php-cgi.exe zum ersten Mal ange-geben wird. Es bietet die Generierung eines globalen FastCGI-Anwendungseintrags für die jeweilige ausführbare Datei an. Dies bedeutet, dass Sie das Dialogfeld nur einmal für jede PHP-Version zu Gesicht bekommen, die Sie auf dem Server im Rahmen einer Handlerzuordnung einrichten. Da für jede eindeutige ausführbare Datei ein eigener FastCGI-Anwendungseintrag erzeugt wird, können Sie auf Ihrem Server PHP-Anwendungen hosten, die mit verschiedenen PHP-Frameworkversionen arbeiten. Um mit mehreren Versionen gleichzeitig zu arbeiten, erstellen Sie einfach separate PHP-Handlerzuord-nungen, indem Sie die jeweiligen Versionen der ausführbaren Datei Php-cgi.exe für verschiedene Sites auf dem Server konfigurieren. Der IIS-Manager bietet Ihnen für jede Version an, einen FastCGI-Anwendungseintrag zu erzeugen.

Der FastCGI-Anwendungseintrag definiert zusätzliche Einstellungen, die z.B. Aufschluss über die maximale Anzahl von Anforderungen geben, die eine einzelne Instanz des Php-cgi.exe-Prozesses ausführen kann, aber auch darüber, wie viele dieser Prozesse gleichzeitig erzeugt werden dürfen. Später in diesem Kapitel im Abschnitt »Mit FastCGI arbeitende Frameworks bereitstellen« erfahren Sie mehr über die Konfiguration anderer FastCGI-Anwendungseinstellungen über die Befehlszeile.



Zusätzliche Überlegungen zur BereitstellungWenn PHP in der FastCGI-Umgebung ausgeführt wird, sollten Sie auch einige weitere Überlegungen zur Bereitstellung berücksichtigen. Diese sind nachfolgend aufgeführt:

� Das Festlegen der Ausführungsidentität für PHP-Skripts

� Das Gewährleisten der Verfügbarkeit von PHP-Anwendungen durch Konfigurieren der Parallelität und Prozesslebensdauer

Diese Überlegungen beziehen sich auf das FastCGI-Prozessmodell, das sich darauf auswirkt, wie PHP-Prozesse im FastCGI-Modus erzeugt und zur Verarbeitung von PHP-Anforderungen verwendet werden. Das FastCGI-Prozessmodell ist später in diesem Kapitel im Abschnitt »Mit FastCGI arbeitende Frameworks bereitstellen« ausführlich erläutert. Wenn Sie mit FastCGI nicht besonders vertraut sind, sollten Sie diesen Abschnitt lesen, bevor sie sich dem Abschnitt »Konfigurieren der PHP-Ausführungsidentität« zuwenden.

Konfigurieren der PHP-AusführungsidentitätPHP-Skripts werden standardmäßig unter der Prozessidentität des Php-cgi.exe-Arbeitsprozesses ausgeführt. Im Gegensatz zu CGI, das für die Verarbeitung jeder Anforderung einen neuen Prozess startet und diesen Prozess unter der Identität des von IIS authentifizierten Benutzers ausführt, sind FastCGI-Arbeitsprozesse langlebig und werden immer unter derselben Identität wie der übergeordnete Anwendungspool ausgeführt. Dies bedeutet, das PHP-Skripts mithilfe der Identität des Anwendungs-pools ausgeführt werden, dem die IIS-Anwendung zugeordnet ist, die das Skript enthält. Dies lässt sich sehr gut mit dem IIS-Modell vereinbaren und es ermöglicht Ihnen, in der gesamten Site den Zugriff auf Ressourcen einheitlich zu verwalten. Es ermöglicht Ihnen außerdem, PHP-Anwendungen unter Ver-wendung der Anwendungspoolisolation sicher zu isolieren, also in derselben Weise wie dies auch für andere Siteinhalte geschieht. Weitere Informationen zur Anwendungspoolisolation finden Sie im vierzehnten Kapitel.

Hinweis Im Gegensatz zu CGI werden FastCGI-Anwendungsprozesse, wozu auch der PHP-Prozess Php-cgi.exe zählt, immer unter der Identität des Anwendungspools ausgeführt, dem die PHP-Anwendung zugeordnet ist.

Einige PHP-Anwendungen sind jedoch darauf angewiesen, PHP-Skripts unter der Identität des authenti-fizierten Benutzers auszuführen. Dies wird oft als Möglichkeit genutzt, um mithilfe des von IIS authen-tifizierten Benutzers den Zugriff auf andere von der Anwendung verwendete Ressourcen zu autorisieren und Benutzer voneinander zu isolieren. PHP-Anwendungen, die im CGI- oder ISAPI-Modus ausgeführt werden, nehmen sogar standardmäßig die Identität des authentifizierten Benutzers an. Historisch betrach-tet war dieser Identitätswechsel sehr wichtig, um die Ausführungsberechtigungen von PHP-Skripts einzu-schränken. Dies geschah, weil es möglich war, dass der übergeordnete IIS-Prozess unter der Identität des Kontos LocalSystem ausgeführt wurde (bei IIS 5.0 und vorherigen Versionen). Diese Anforderung ist bei IIS 7.0 hinfällig, weil IIS-Anwendungspools standardmäßig so konfiguriert sind, dass sie mit den einge-schränkten Berechtigungen des Kontos Netzwerkdienst ausgeführt werden.

Sollen PHP-Skripts in der FastCGI-Umgebung unter der Identität des authentifizierten Benutzers aus-geführt werden, können Sie PHP entsprechend konfigurieren. Obwohl der Php-cgi.exe-Prozess in diesem Fall auch weiterhin unter der Identität des übergeordneten Anwendungspools ausgeführt wird, nimmt die PHP-Engine bei der Ausführung von PHP-Skripts die Identität des authentifizierten Benutzers an. Dazu wird in der PHP-Konfigurationsdatei Php.ini die fastcgi.impersonate-Einstellung auf 1 gesetzt.



; FastCGI unter IIS (bei auf WINNT basierenden Betriebssystemen) unterstützt die ; Möglichkeit, einen Identitätswechsel auf Grundlage des Sicherheitstokens des ; aufrufenden Clients durchzuführen. Dies ermöglicht es IIS, den Sicherheitskontext zu ; definieren, in dem die Anforderung ausgeführt wird. Setzen Sie die Einstellung auf 1, ; wenn eine Ausführung unter IIS erfolgt. Die Vorgabe ist 0. fastcgi.impersonate = 1

Hinweis Der Identitätswechsel zeigt nur dann Auswirkungen, wenn ein authentifizierter Benutzer verfügbar ist und dieser einen gültigen Windows-Prinzipal repräsentiert. Authentifizierungsschemata, die nicht auf Windows basieren, z.B. die Formularauthentifizierung, unterstützen keinen Identitätswechsel.

Wenn der Identitätswechsel und die anonyme Authentifizierung zum Einsatz kommen, werden PHP-Skripts standardmäßig unter der IUSR-Identität ausgeführt (bei IIS 7.0 ist dies der anonyme Benutzer). Sie können die Identität des anonymen Benutzers im Konfigurationsabschnitt system.webServer/security/authentication/anonymousAuthentication ändern und dafür sorgen, dass der anonyme Benutzer zur Identität eines Arbeitsprozesses wird. Das vierzehnte Kapitel hält weitere Informationen zur anonymen IIS 7.0-Authentifizierung bereit.

Hinweis FastCGI unter IIS 7.0 unterstützt die Annahme der Identität des authentifizierten Benutzers. Zur Druck-legung dieses Buches wurde dies jedoch ausschließlich vom PHP-Framework unterstützt. Andere Frameworks, die FastCGI nutzen, werden unter der Identität des übergeordneten Anwendungspools ausgeführt.

PHP-Anwendungen über Remote-UNC-Freigaben hostenWenn PHP-Anwendungen über Remote-UNC-Freigaben ausgeführt werden, müssen Sie sicherstellen, das der Php-cgi.exe-Prozess auf die Anwendungsinhalte in der UNC-Freigaben zugreifen kann. Auf-grund der beiden früher in diesem Kapitel beschriebenen Mechanismen zur Ausführung von PHP können Sie zwischen zwei Optionen wählen, um diesen Zugriff zu konfigurieren:

� Wenn Sie den Identitätswechsel nutzen, konfigurieren Sie feste Anmeldeinformationen für das virtuelle Verzeichnis, das die PHP-Anwendungsinhalte über eine Remote-UNC-Freigabe hostet. PHP nimmt dann die zu diesen Anmeldeinformationen passende Identität an, wenn es auf die Inhalte zugreift und Skripts ausführt. Diese Option wird empfohlen.

� Wenn Sie den Identitätswechsel nicht nutzen, stellen Sie sicher, dass die Anwendungspoolidentität auf die UNC-Freigabe zugreifen kann.

Weitere Informationen zur Zugriffskonfiguration finden Sie im vierzehnten Kapitel.

Die Verfügbarkeit von PHP-Anwendungen sicherstellenDer FastCGI-Hostingsmodus bietet mehrere Einstellungen an, die konfiguriert werden können, um die Leistung und Verfügbarkeit von PHP-Anwendungen anzupassen. Diese Einstellungen sind im globalen Konfigurationsabschnitt system.webServer/fastCgi und dort im jeweiligen FastCGI-Anwendungseintrag verfügbar, der für jede eindeutige vom System verwendete Php-cgi.exe-Version definiert ist.

Weiterführende Informationen Um mehr über diese Einstellungen und darüber zu erfahren, wie sie konfiguriert werden, lesen Sie später in diesem Kapitel den Abschnitt »FastCGI-Anwendungseinstellungen modifizieren«.

Diese Einstellungen müssen bisweilen konfiguriert werden, um die Verfügbarkeit von PHP-Anwendungen zu gewährleisten. Dazu wird das FastCGI-Poolverhalten angepasst. Besonders die instanceMaxRequests-Einstellung der PHP-FastCGI-Anwendungen, die die maximale Anzahl der von


Anwendungsframeworks ermöglichen 337

jedem Php-cgi.exe-Prozess verarbeiteten Anforderungen vor dem Herunterfahren des Prozesses festlegt, muss auf eine Zahl unter dem PHP-Anforderungslimit gesetzt werden. Dieses Limit ist standardmäßig 500 und Sie können es ändern, indem Sie in der FastCGI-Anwendungskonfigura-tion die Umgebungsvariable PHP_FCGI_MAX_REQUESTS setzen (Lesen Sie den Abschnitt »FastCGI-Anwendungseinstellungen modifizieren«, um weitere Informationen darüber zu erhalten, wie in der Konfigura-tion Umgebungsvariablen für FastCGI- Anwendungen gesetzt werden). Der instanceMaxRequests-Vorgabe-wert ist 200, der unter dem PHP-Standard liegt. Es wird jedoch empfohlen, beide auf 10.000 zu setzen, um eine optimale Leistung zu erzielen.

Lesen Sie später in diesem Kapitel den Abschnitt »FastCGI-Anwendungseinstellungen modifizieren«, um mehr über die verfügbaren Einstellungen zu erfahren. Lesen Sie auch den Abschnitt »Die Verfügbarkeit von FastCGI-Anwendungen sicherstellen«, um zu erfahren, wie Sie diese Einstellungen setzen müssen, um die Verfügbarkeit von FastCGI-Anwendungen zu verbessern.

Anwendungsframeworks ermöglichenIIS 7.0 bietet mehrere Optionen für das Hosting von Anwendungsframeworks von Drittanbietern an, die davon abhängig sind, welchen Weg die Entwickler dieser Anwendungsframeworks gewählt haben, um eine Schnittstelle zu IIS anzubieten. Die Optionen sind nachfolgend aufgeführt:

� Native IIS 7.0-Module

Anwendungsframeworks, die mit nativen IIS 7.0-Modul-APIs in IIS integriert werden, um Anfor-derungen zu verarbeiten

� ASP.NET-Handler

Anwendungsframeworks, die unter Verwendung von ASP.NET-Handler-APIs in IIS integriert werden

� ISAPI-Erweiterungen

Anwendungsframeworks, die unter Verwendung alter ISAPI-Erweiterungs-APIs in IIS integriert werden

� FastCGI-Anwendungen

Anwendungsframeworks, die ausführbare Dateien anbieten, die über das offene FastCGI-Protokoll in IIS integriert werden

� CGI-Anwendungen

Anwendungsframeworks, die ausführbare Dateien anbieten, die über das offene CGI-Protokoll in IIS integriert werden

Um mit einer der zuvor aufgeführten Optionen dafür zu sorgen, dass Anwendungsframeworks mit IIS 7.0 zusammenarbeiten, müssen Sie eine Handlerzuordnung erstellen, die die Anforderungen den spezifischen Erweiterungen der Handlerkomponente des Anwendungsframeworks zuweist. Diese Komponente kann eine der zuvor aufgeführten Optionen nutzen, um eine Schnittstelle zu IIS zur Ver-fügung zu stellen. Wie Sie Handlerzuordnungen für jeden dieser Handlertypen erstellen, erfahren Sie im zwölften Kapitel und dort im Abschnitt »Handlerzuordnungen hinzufügen«.

Sie können die Handlerzuordnung auf der Serverebene oder für eine bestimmte Website, Anwendung, ein virtuelles Verzeichnis oder einen URL erstellen. Danach können Anforderungen, die sich auf die Ebene der Zuordnung beziehen, zur Verarbeitung an das Anwendungsframework weitergeleitet werden.



Hinweis Dieser Abschnitt beschreibt allgemeine Verfahren zur Integration von Anwendungsframeworks in IIS 7.0. Sie sollten die Dokumentation zum jeweiligen Framework lesen, um sich über mögliche frameworkspezifische Konfigurationsschritte zu informieren. Dieses Kapitel enthält spezielle Informationen zu den Frameworks ASP.NET, ASP und PHP.

Sie können für all diese Optionen IIS-Module benutzen, um zusätzliche Anforderungsverarbeitungs-dienste zur Verfügung zu stellen. Dazu zählen auch die von IIS angebotenen Authentifizierungsmecha-nismen, die Autorisierung, die Ausgabezwischenspeicherung, die Antwortkomprimierung und die Protokollierung. Darüber hinaus können Sie ebenfalls für Anwendungen, die im integrierten Modus ausgeführt werden, die Dienste nutzen, die von verwalteten (ASP.NET) Modulen bereitgestellt werden. Die dazu notwendige Vorgehensweise ist unabhängig vom Anwendungsframework für alle Anforde-rungen gleich. Weitere Informationen hierzu finden Sie früher in diesem Kapitel im Abschnitt »Die Vorzüge des integrierten ASP.NET-Modus nutzen«.

Der Rest dieses Abschnitts erläutert die Besonderheiten der Optionen zur Integration von Anwendungs-frameworks. Dazu zählt auch der Einsatz des neuen FastCGI-Moduls zum Hosten von Anwendungs-frameworks, die mit FastCGI kompatibel sind, z.B. PHP.

Weiterführende Informationen Spezifische Informationen zur PHP-Bereitstellung finden Sie früher in diesem Kapitel im Abschnitt »PHP-Anwendungen hosten«.

Die Verarbeitung von neuen statischen Dateien konfigurierenDie Standardinstallation von IIS 7.0 bietet eine grundlegende Dateiserverfunktionalität, die von StaticFile-Module zur Verfügung gestellt wird. Dieses Modul ist standardmäßig so konfiguriert, dass es sich um alle Anforderungen kümmert, die von anderen Handlern außer Acht gelassen werden. Dies bedeutet, dass jede Anforderung einer Ressource, die keinem Handler zugeordnet ist, von StaticFileModule behandelt wird.

StaticFileModule bedient nur Anforderungen, die sich auf solche Ressourcen beziehen, deren Datei-namenserweiterungen hierfür konfiguriert sind. Dies ist sehr wichtig, da andernfalls alle unbekannten Ressourcen im bedienbaren Namespace der Anwendung, einschließlich aller Datendateien und Anwen-dungsskripts, als statische Dateien bereitgestellt werden.

Die Liste der zulässigen statischen Dateien befindet sich im Konfigurationsabschnitt system.webServer/staticContent. Dies ist das Äquivalent zur MIME-Typkonfiguration von IIS 6.0. Bei IIS 7.0 wurde die Liste der zulässigen statischen Dateien erweitert und enthält nun moderne Dateitypen wie diejenigen, die von Shockwave, Microsoft Silverlight und Microsoft Office 2007 verwendet werden. Sie können die Liste der statischen Dateien auf jeder Konfigurationsebene bearbeiten, so dass Anwendungen benutzerdefinierte Dateitypen ohne Auswirkungen auf den gesamten Server hinzufügen oder entfernen können.

Wenn Ihre Anwendung einen Dateityp enthält, der als statische Datei bereitgestellt werden soll, aber im genannten Abschnitt noch nicht registriert ist, müssen Sie seine Dateinamenserweiterung und den damit verbundenen MIME-Inhaltstypen hinzufügen, bevor eine Bereitstellung erfolgen kann.

Sie können hierzu den IIS-Manager benutzen. Erweitern Sie im Bereich Verbindungen den Knoten des IIS-Computers und den Knoten Sites, und markieren Sie die Ebene, auf der Sie MIME-Typen konfigu-rieren möchten. (Sie können MIME-Typen auf der Ebene einer Site, eines Verzeichnisses und eines virtuellen Verzeichnisses konfigurieren.) Führen Sie einen Doppelklick auf dem Feature MIME-Typ aus, um die gleichnamige Seite anzeigen zu lassen, wie in Abbildung 11.7 dargestellt.



Abbildung 11.7 MIME-Typen mit dem IIS-Manager konfigurieren

Sie können MIME-Typen auch mit Appcmd konfigurieren. Um einen MIME-Typeintrag hinzuzufügen, benutzen Sie die folgende Syntax:%systemroot%\system32\inetsrv\Appcmd set config /section:system.WebServer/staticContent "ConfigurationPath" "/+[fileExtension='string',mimeType='string']"

Um einen MIME-Typeintrag zu löschen und auf diese Weise zu verhindern, dass die damit verknüpfte Dateinamenserweiterung als statische Datei bereitgestellt wird, benutzen Sie die folgende Syntax:%systemroot%\system32\inetsrv\Appcmd set config /section:system.WebServer/staticContent "ConfigurationPath" "/-[fileExtension=’string’]"

Die Parameter dieser Befehle sind in Tabelle 11.6 beschrieben.

Die MIME-Typkonfiguration wird nur dann verwendet, wenn in der IIS 7.0-Handlerzuordnungs-konfiguration die Dateinamenserweiterung nicht bereits einem anderen Handler zugeordnet ist.

Tabelle 11.6 Parameter zum Hinzufügen von MIME-Typen


ConfigurationPath Der Konfigurationspfad, auf den diese Konfiguration angewendet werden soll

fileExtension Die hinzuzufügende oder zu löschende Dateinamenserweiterung

mimeType Der MIME-Typ der Dateinamenserweiterung. Dieser wird im Header der Antwort als Inhaltstyp (content-type) versendet, wenn die Inhalte der verknüpften Ressourcen zum Client übermittelt werden.



Vorsicht Fügen Sie keine MIME-Typeinträge für Ressourcen hinzu, die nicht als statische Datei bereitgestellt werden dürfen, z.B. Anwendungsskriptdateien oder Datendateien. Wenn das Framework, das in der Regel für diese Ressourcen zuständig ist, entfernt wird, kann der Webserver diese Dateien versehentlich so bereitstellen, als wären ihre MIME-Typen in der Konfiguration für statische Inhalte registriert.

Frameworks basierend auf systemeigenen IIS 7.0-Modulen bereitstellenDas systemeigene IIS 7.0-Modul stellt die bevorzugte Vorgehensweise zur Integration von Anwen-dungsframeworks in IIS 7.0 und zukünftige Versionen von IIS dar, weil es die höchste Leistung und eine maximale Funktionalität für das jeweilige Anwendungsframework bietet. Es ist außerdem ein-facher, in Anlehnung an ein solches Modul zu entwickeln, zumal es sehr viel leistungsfähiger als die für frühere IIS-Versionen verfügbare ISAPI-Erweiterungs-API ist. Da es sich jedoch bei diesem Modul um die neueste mit IIS 7.0 eingeführte API handelt, wird sie noch relativ selten genutzt (was sich ändern wird, sobald die Entwickler IIS 7.0 angenommen haben). Das Hinzufügen von Anwendungsframe-works, die auf systemeigenen IIS 7.0-Modulen basieren, erfordert administrative Rechte auf dem Server.

Um ein Anwendungsframework bereitzustellen, das diesen Mechanismus nutzt, gehen Sie wie folgt vor:

1. Installieren Sie auf dem Server das systemeigene Modul. Dazu sind administrative Rechte erforderlich.

2. Aktivieren Sie das systemeigene Modul (was in der Regel im Rahmen der Installation automatisch geschieht) auf dem Server oder für eine bestimmte Anwendung, für die das Modul verwendet wer-den soll.

3. Erstellen Sie einen modulbasierten Handlerzuordnungseintrag, der dem Modul den gewünschten URL-Pfad zuordnet. Tun Sie dies auf der Serverebene oder für eine bestimmte Site, Anwendung oder einen URL.

4. Installieren Sie optional das entsprechende Konfigurationsschema und die Benutzeroberflächener-weiterungen für die Konfiguration Ihres Moduls. Legen Sie anschließend die spezifische Modul-konfiguration fest. Die dazu notwendige Vorgehensweise ist im dreizehnten Kapitel, »Konfigura-tions- und Benutzeroberflächenerweiterungen verwalten«, beschrieben.

Detaillierte Informationen zum Ausführen jeder dieser Schritte finden Sie im zwölften Kapitel.

Da IIS 7.0-Module von einem IIS-Arbeitsprozess prozessintern geladen werden, wird das Anwendungs-framework standardmäßig unter der Identität des übergeordneten IIS-Anwendungspools ausgeführt (sofern nicht das Framework speziell die Fähigkeit implementiert, die Identität des authentifizierten Benutzers anzunehmen oder beliebige Anmeldeinformationen zu verwenden, wie dies bei ASP.NET der Fall ist). Dies bedeutet, dass Sie Berechtigungen für die Anwendungsframeworkdateien festlegen müssen, damit ein IIS-Arbeitsprozess diese lesen kann. Dazu gewähren Sie der Gruppe IIS_IUSRS Lesezugriffsrechte.

Wenn Sie darüber hinaus Ihre Anwendungen aus Gründen der Ausfallsicherheit oder der Sicherheit im Allgemeinen isolieren möchten, müssen Sie die IIS-Anwendung als Isolationseinheit verwenden, indem Sie verschiedene Anwendungen in verschiedenen IIS-Anwendungspools platzieren. Im vierzehnten Kapitel erfahren Sie mehr über die Anwendungsisolation aus Sicherheitsgründen.



Frameworks basierend auf ASP.NET-Handlern bereitstellenDer Einsatz von ASP.NET-Handlern ist verglichen mit der Verwendung systemeigener Module die zweitbeste Option, weil die Entwickler auf den größten Teil der Funktionalität von systemeigenen IIS 7.0-Modulen zurückgreifen können und die Entwicklungszyklen sehr kurz sind. ASP.NET-Handler bilden wie IIS 7.0-Module eine Multithreadingumgebung, so dass sie vorwiegend für threadsichere Anwendungsframeworks geeignet sind. Im Gegensatz zu den anderen Anwendungsframework-optionen sind für das Einrichten von ASP.NET-Handlern in der Anwendungskonfiguration keine administrativen Rechte erforderlich.

Die Schritte zur Bereitstellung eines Anwendungsframeworks, das ASP.NET-Handler verwendet, sind nachfolgend aufgeführt:

1. Stellen Sie die ASP.NET-Handlerassembly auf dem Server bereit (im globalen Assemblycache). Alternativ hierzu können Sie sie als Teil einer bestimmten Anwendung bereitstellen (in den Verzeich-nissen /BIN oder /App_Code). Die letzte Option ist besonders dann geeignet, wenn Sie Anwendungs-frameworks auf Servern bereitstellen, für die Sie keine administrativen Berechtigungen besitzen.

2. Erstellen Sie einen Zuordnungseintrag für einen verwalteten Handler, der auf der Serverebene oder auf der Ebene einer bestimmten Site, Anwendung oder eines URLs dem ASP.NET-Handlertyp den gewünschten URL-Pfad zuordnet.

3. Installieren Sie optional das entsprechende Konfigurationsschema und die Benutzeroberflächener-weiterungen für die Konfiguration Ihres Handlers. Legen Sie anschließend die handlerspezifische Konfiguration fest. Die dazu notwendige Vorgehensweise ist im dreizehnten Kapitel beschrieben.

Genaue Informationen zu jedem dieser Schritte finden Sie im zwölften Kapitel. Beachten Sie, dass der Ort, an dem ASP.NET-Handlerzuordnungen hinzugefügt werden, davon abhängig ist, ob die Ziel-anwendung den klassischen oder integrierten .NET-Integrationsmodus nutzt. Im integrierten Modus können Sie die Handlerzuordnung direkt der IIS-Handlerzuordnungsliste im Konfigurationsabschnitt system.webServer/handlers oder mithilfe des IIS-Managers hinzufügen. Im klassischen Modus müssen Sie die Handlerzuordnung dem ASP.NET-Konfigurationsabschnitt system.web/httpHandlers hinzufügen, und Sie müssen (was ebenfalls mit dem IIS-Manager möglich ist) in den IIS-Handlerzuordnungen eine Skriptzuordnung der entsprechenden Dateinamenserweiterung zur ISAPI-Erweiterung ASPNET_ ISAPI.dll konfigurieren.

ASP.NET-Handler sind wie systemeigene IIS 7.0-Module prozessinterne Komponenten, die von einem IIS-Arbeitsprozess geladen werden. Im Gegensatz zu systemeigenen IIS 7.0-Modulen werden ASP.NET-Handler jedoch innerhalb einer ASP.NET-Anwendung geladen und ausgeführt. Die ASP.NET-Anwen-dung kann zusätzlich die Inhalte und die Anforderungsausführung mithilfe der teilweisen Vertrauens-würdigkeit isolieren.

Obwohl ASP.NET-Handler standardmäßig unter der Identität des IIS-Arbeitsprozesses ausgeführt werden, können sie ebenfalls mithilfe der ASP.NET-Konfiguration system.webServer/identity so konfigu-riert werden, dass sie die Identität des authentifizierten Benutzers oder eine beliebige andere Identität annehmen. Um sicherzustellen, dass Ihr Anwendungsframework auf die gewünschten Dateien zugrei-fen kann, sollten Sie dafür sorgen, dass diese Dateien vom IIS-Arbeitsprozess gelesen werden können, indem Sie der Gruppe IIS_IUSRS Lesezugriffsrechte gewähren.

Wenn Sie darüber hinaus Ihre Anwendungen aus Gründen der Ausfallsicherheit oder der Sicherheit im Allgemeinen isolieren möchten, müssen Sie die IIS-Anwendung als Isolationseinheit verwenden, indem Sie verschiedene Anwendungen in verschiedenen IIS-Anwendungspools platzieren. Im vier-zehnten Kapitel erfahren Sie mehr über die Anwendungsisolation aus Sicherheitsgründen.



Frameworks basierend auf ISAPI-Erweiterungen bereitstellenISAPI-Erweiterungen stellten bisher die bevorzugte Vorgehensweise dar, um Schnittstellen zwischen Anwendungsframeworks und früheren Versionen von IIS zu bilden. Aus diesem Grund verwenden viele der heutigen Anwendungsframeworks eine ISAPI-Erweiterung, wenn sie innerhalb der IIS-Umgebung gehostet werden. ISAPI-Erweiterungen bilden wie IIS 7.0-Module und ASP.NET-Handler eine Multi-threadingumgebung, so dass sie vorwiegend für threadsichere Anwendungsframeworks geeignet sind. Für das Hinzufügen von ISAPI-Erweiterungen sind administrativen Rechte erforderlich.

Die Schritte zur Bereitstellung eines Anwendungsframeworks, das ISAPI-Erweiterungen verwendet, sind nachfolgend aufgeführt:

1. Erstellen Sie einen auf einer Skriptzuordnung basierenden Handlerzuordnungseintrag, der den gewünschten URL-Pfad der ISAPI-Erweiterung zuordnet.

2. Dies kann auf der Serverebene oder für eine bestimmte Site, Anwendung oder einen URL geschehen. Dazu sind administrative Rechte erforderlich.

Hinweis Der IIS-Manager kann den ISAPI-Erweiterungseintrag im Konfigurationsabschnitt system.webServer/security/isapiCgiRestriction automatisch erstellen, wenn Sie die Handlerzuordnung generieren. Dazu müssen Sie als Serveradministrator verbunden sein.

Genaue Informationen zu jedem dieser Schritte finden Sie im zwölften Kapitel.

ISAPI-Erweiterungen sind wie systemeigene IIS 7.0-Module prozessinterne Komponenten, die von einem IIS-Arbeitsprozess geladen werden. Im Gegensatz zu systemeigenen IIS 7.0-Modulen nehmen sie jedoch standardmäßig die Identität des authentifizierten Benutzers an, sofern dieser verfügbar ist. Deshalb werden sie in der Regel unter der Identität des anonymen IIS-Benutzers (standardmäßig IUSR) ausgeführt oder es wird die Identität des authentifizierten Benutzers verwendet, wenn dieser verfügbar und mit einem Windows-Prinzipal verknüpft ist.

Einige Anwendungsframeworks könnten jedoch auf diesen Identitätswechsel zurückgreifen und statt-dessen unter der Identität des IIS-Arbeitsprozesses ausgeführt werden. Bei IIS 7.0 ist es außerdem möglich, dafür zu sorgen, dass der anonyme Benutzer die Identität des IIS-Arbeitsprozesses annimmt, so dass für anonyme Anforderungen ein entsprechendes Verhalten erzielt wird.

Wenn Sie wie zuvor Ihre Anwendungen aus Gründen der Ausfallsicherheit oder der Sicherheit im Allge-meinen isolieren möchten, müssen Sie die IIS-Anwendung als Isolationseinheit verwenden, indem Sie verschiedene Anwendungen in verschiedenen IIS-Anwendungspools platzieren. Im vierzehnten Kapitel erfahren Sie mehr über die Anwendungsisolation aus Sicherheitsgründen.

Mit FastCGI arbeitende Frameworks bereitstellenFastCGI ist bei IIS 7.0 eine neue Anwendungsframeworkoption. Im Gegensatz zu ISAPI-Erweiterungen, IIS 7.0-Modulen und ASP.NET-Handlern – bei den letzten beiden handelt es sich um spezifische IIS-Erweiterungsmechanismen – benutzt FastCGI das FastCGI-Protokoll, um eine Schnittstelle zu den Anwendungsframeworks zur Verfügung zu stellen. Auf diese Weise können verschiedene bereits vor-handene Anwendungsframeworks, die schon auf anderen Webserverplattformen FastCGI unterstützen, mit IIS zusammenarbeiten. Das FastCGI-Protokoll weist gegenüber CGI, das schon lange von IIS unter-stützt wird, eine wesentlich bessere Leistung auf. Dabei hält es sich an die Bedingung, die eine Anforde-rung pro Prozess verlangt. Diese Bedingung existiert aufgrund der fehlenden Threadsicherheit im jewei-ligen Anwendungsframework oder in der Anwendung, die das Framework verwendet.



Die FastCGI-Unterstützung wird über das FastCGI-Modul implementiert. Dieses Modul verwaltet einen Pool, der aus einem oder mehreren FastCGI-Prozessen für jede ausführbare FastCGI-Anwen-dungsdatei besteht, die global auf dem Server konfiguriert ist. Wenn eine Anforderung, die dem FastCGI-Modul und der entsprechenden FastCGI-Anwendung zugeordnet ist, eingeht, wird sie unter Verwendung des FastCGI-Protokolls an einen der Prozesse im entsprechenden FastCGI-Prozesspool weitergeleitet. Der FastCGI-Anwendungsprozess verarbeitet dann die Anforderung und gibt die Ant-wort an das FastCGI-Modul zurück, das sie in die eigentliche Antwort schreibt. Im Gegensatz zu CGI sind die FastCGI-Anwendungsprozesse langlebig und werden für aufeinander folgende Anforde-rungen wiederverwendet, wodurch der Overhead vermieden wird, der mit dem Starten und Zerstören von Anwendungsprozessen für jede Anforderung einhergeht.

Um ein Anwendungsframework bereitzustellen, das FastCGI verwendet, gehen Sie wie folgt vor:

1. Erstellen Sie einen modulbasierten Handlerzuordnungseintrag, der den gewünschten URL-Pfad dem Modul FastCGIModule zuordnet. Dazu geben Sie den Pfad der ausführbaren FastCGI-Datei und die Argumente an, die an diese ausführbare Datei (der Skriptverarbeiter) übergeben werden sollen. Sie können dies auf der Serverebene oder für eine bestimmte Site, Anwendung oder einen URL tun.

2. Erstellen Sie einen FastCGI-Anwendungseintrag für die ausführbare FastCGI-Datei. Wenn Sie die Handlerzuordnung mit dem IIS-Manager hinzufügen, wird dieser Eintrag nach einer entsprechen-den Bestätigung automatisch erzeugt, sofern Sie als Serveradministrator verbunden sind. Sie müs-sen ein Serveradministrator sein, um diesen Eintrag erzeugen zu können.

Nachdem der FastCGI-Anwendungseintrag für die angegebene ausführbare FastCGI-Datei auf dem Server erstellt wurde (dies erfordert administrative Rechte), kann er genutzt werden, um auf jeder entsprechenden Konfigurationsebene Handlerzuordnungen zu erstellen. Dies bedeutet, dass jede Anwendung auf dem Server eine bestimmte ausführbare FastCGI-Datei des Anwendungsframeworks nutzen kann, nachdem diese vom Serveradministrator zugelassen wurde.

Im Gegensatz zu CGI, das für die Verarbeitung jeder Anforderung einen neuen Prozess startet und diesen Prozess unter der Identität des von IIS authentifizierten Benutzers ausführt, sind FastCGI-Arbeitsprozesse langlebig und werden immer unter derselben Identität wie der übergeordnete Anwen-dungspool ausgeführt. Dies bedeutet, das die ausführbaren Dateien des FastCGI-Anwendungsframe-works und deren Skripts mithilfe der Identität des Anwendungspools ausgeführt werden, dem die IIS-Anwendung zugeordnet ist, die die Skripts enthält. Dies lässt sich sehr gut mit dem IIS-Modell verein-baren, und es ermöglicht Ihnen, in der gesamten Site den Zugriff auf auf Ressourcen einheitlich zu verwalten. Es ermöglicht Ihnen außerdem, FastCGI-Anwendungen unter Verwendung der Anwen-dungspoolisolation sicher zu isolieren, also in derselben Weise, wie dies auch für andere Siteinhalte geschieht. Weitere Informationen zur Anwendungspoolisolation finden Sie im vierzehnten Kapitel.

FastCGI-Anwendungseinstellungen modifizierenWenn Sie für die ausführbare FastCGI-Datei einen FastCGI-Anwendungseintrag erstellen, steht Ihnen eine Vielzahl von Optionen zur Verfügung, die Sie konfigurieren können, um das Verhalten des entsprechenden FastCGI-Prozesspools zu bearbeiten. Tabelle 11.7 beschreibt diese Optionen.



Unter Windows Server 2008 bietet der IIS-Manager keine Möglichkeit, um diese Einstellungen zu modifizieren. Wenn Sie diese Einstellungen somit ändern möchten, müssen Sie die Konfiguration direkt bearbeiten oder Appcmd bzw. eine der programmatischen APIs verwenden. Um beispielsweise mit Appcmd einen neuen FastCGI-Anwendungseintrag zu erstellen, dessen instanceMaxRequests-Attribut auf 10 gesetzt wird, können Sie die folgende Syntax verwenden:%systemroot%\system32\inetsrv\AppCmd.exe Set Config /section:system.webServer/fastCgi "/+[fullPath='Path',arguments='Arguments'instanceMaxRequests='10']"

Tabelle 11.7 Parameter für die Bearbeitung von FastCGI-Anwendungsdefinitionen

Einstellung Beschreibung

fullPath Der vollständige Pfad zur ausführbaren FastCGI-Datei

Arguments Die Argumente, die an die ausführbare FastCGI-Datei übergeben werden sollen

maxInstances Die maximale Anzahl der Prozesse, die für diese Anwendung gestartet werden können. Der Vorgabe-wert ist 4.

idleTimeout Die Zeit in Sekunden, die nach der Verarbeitung der letzten Anforderung durch einen FastCGI-Prozess vergehen muss, bevor der Prozess aufgrund von Inaktivität heruntergefahren wird. Der Standard ist 300 Sekunden.

activityTimeout Die Zeit in Sekunden, die während der Anforderungsverarbeitung auf eine Aktivität vom FastCGI-Prozess gewartet werden soll. Danach wird ein Deadlock vorausgesetzt und der Prozess wird zwangs-weise heruntergefahren. Dabei handelt es sich gewissermaßen um ein Skripttimeout. Der Standard ist 30 Sekunden.

requestTimeout Die Zeit in Sekunden, die einem FastCGI-Prozess maximal zur Verfügung steht, um eine Anforderung zu verarbeiten. Der Standard ist 90 Sekunden.

instanceMaxRequests Die Anzahl der Anforderungen, die jeder FastCGI-Prozess verarbeiten darf, bevor er heruntergefahren wird. Der Standard ist 200.

Protocol Das FastCGI-Protokoll, das verwendet werden soll, um eine Verbindung zum FastCGI-Prozess herzu-stellen. Die beiden zulässigen Werte sind NamedPipe und Tcp. Der Standard ist NamedPipe.

queueLength Die maximale Anzahl der Anforderungen, die während des Wartens auf den nächsten verfügbaren Fast-CGI-Prozess in die Warteschlange gestellt werden dürfen. Wird diese Zahl überschritten, werden die Anforderung mit dem Fehlercode 503 zurückgewiesen. Der Vorgabewert ist 1000.

flushNamedPipe Gibt an, ob bei der Nutzung von Named Pipes die Daten im Rahmen einer Flushoperation zum FastCGI-Prozess gesendet werden sollen. Dies kann für einige FastCGI-Anwendungen notwendig sein, die andernfalls nicht mehr reagieren würden, während sie auf die Daten von FastCgiModule warteten. Der Vorgabewert ist false.

rapidFailsPerMinute Gibt an, wie viele FastCGI-Prozessfehler pro Minute zulässig sind. Wenn die Anzahl der Fehler diesen Wert innerhalb von 60 Sekunden überschreitet, generiert FastCGI keine weiteren Prozesse für die FastCGI-Anwendung. Der Standard ist 10.

environmentVariables Ermöglicht die Angabe einer Auflistung mit zusätzlichen Umgebungsvariablen für den FastCGI-Anwendungsprozess. Jedes environmentVariable-Elemente innerhalb der Auflistung kann den Namen der Umgebungsvariablen und deren Wert angeben.



Path muss angegeben werden und ist der Pfad zur ausführbaren Datei. Arguments sind die optionalen zu übergebenden Argumente. Sie können ebenfalls jedes der anderen in Tabelle 11.7 aufgeführten Attribute angeben, um dieses wie bei instanceMaxRequests auf einen bestimmten Wert zu setzen.

Um die bereits vorhandenen Einträge aufzulisten, können Sie die folgende Syntax verwenden:%systemroot%\system32\inetsrv\AppCmd.exe List Config /section:system.WebServer/fastCgi

Sie können ebenfalls bestimmte Attribute eines bereits vorhandenen Elements setzen. Um z.B. das idleTimeout-Attribut auf 60 Sekunden zu setzen, können Sie die folgende Syntax benutzen:%systemroot%\system32\inetsrv\AppCmd.exe Set Config /section:system.WebServer/fastCgi "/[fullPath='Path',arguments='Arguments'].idleTimeout:60"

Path und Arguments sind Schlüssel, die zum Auffinden eines entsprechenden bereits vorhandenen Anwen-dungseintrags verwendet werden. Sie können diese Syntax benutzen, um jedes der in Tabelle 11.7 aufgeführten Attribute zu setzen.

Die Verfügbarkeit von FastCGI-Anwendungen sicherstellenDas Verhalten Ihres Anwendungsframeworks, die jeweilige Anwendung und die gesamte Webserver-konfigurationen bestimmen, wie Sie die FastCGI-Anwendungseinstellungen anpassen müssen, damit Ihre Anwendung eine optimale Leistung erbringt und immer verfügbar ist. Sie müssen möglicherweise Folgendes tun:

� Anpassen der maxInstances-Standardeinstellung, die auf mindestens vier Prozesse gesetzt werden sollte, um eine bessere Anforderungsparallelität zu erzielen. Obwohl dies auf Ihrem Server zu einer größeren CPU-Auslastung führen kann, weil mehr Prozesse erzeugt werden, kann es dazu beitra-gen, dass die Ansprechempfindlichkeit Ihrer Anwendung zunimmt. Dies gilt besonders dann, wenn die Anwendung zeitintensive Datenbank- oder Netzwerkoperationen initiiert.

� Verkleinern der idleTimeout-Einstellung, um nicht genutzte FastCGI-Prozesse in Zeiten geringer Aktivität herunterzufahren. Dies kann besonders für Shared Hostingserver erforderlich sein, die mit mehreren Anwendungspools und damit auch mit mehreren FastCGI-Prozesspools pro FastCGI-Anwendung arbeiten.

� Wenn Ihre Anwendung außerdem mit vielen Anforderungen konfrontiert wird, die ein temporäres Queuing zur Folge haben, müssen Sie möglicherweise queueLength heraufsetzen, um in Zeiten starker Anforderungsaktivitäten für eine höhere Warteschlangengröße zu sorgen.

� Anpassen von instanceMaxRequests zur Verbesserung der Leistung. Dazu erhält jeder Prozess die Möglichkeit, eine größere Zahl von Anforderungen zu bearbeiten, bevor er heruntergefahren wird. Dies kann die Anwendungsstabilität beeinflussen, wenn Ihre Anwendung über zu wenig Speicher verfügt oder im Laufe der Zeit ein instabiles Verhalten entwickelt. Es ist außerdem wichtig, dass instanceMaxRequests unter dem entsprechenden internen Anforderungslimit der ausführbaren FastCGI-Datei bleibt. Andernfalls könnte es geschehen, dass das FastCGI-Modul nicht mehr korrekt arbeitet, sobald der FastCGI-Prozess aufgrund seines internen Anforderungslimits unerwartet beendet wird.

� Anpassen von activityTimeout und requestTimeout, um Fehler bei Skripts zu vermeiden, die viel Zeit benötigen, um eine Antwort zurückzugeben oder ihre Arbeit abzuschließen.



Weiterführende Informationen PHP weist standardmäßig ein internes Anforderungslimit von 500 Anforderungen auf, das mit der Umgebungsvariablen PHP_FCGI_MAX_REQUESTS global auf dem Server oder speziell für den FastCGI-Anwendungseintrag geändert werden kann. Lesen Sie früher in diesem Kapitel den Abschnitt »Die Verfügbarkeit von PHP-Anwendungen sicherstellen«, um weitere Informationen zu erhalten.

Der exakte Wert dieser Einstellung ist von den Besonderheiten des Anwendungsframeworks, der Anwen-dung, der gesamten Webserverumgebung und der Serverhardware abhängig. Deshalb ist es schwierig, spezifische Empfehlungen auszusprechen. Sie müssen Leistungstests durchführen, um zur gewünschten Einstellungen zu gelangen und Ihren Leistungs- und Verfügbarkeitsanforderungen gerecht zu werden. Weitere Informationen zum Testen der Leistung erhalten Sie im siebzehnten Kapitel, »Optimieren der Leistung«.

Mit CGI arbeitende Frameworks bereitstellenIIS 7.0 unterstützt auch weiterhin CGI-Anwendungen, die das offene CGI-Protokoll verwenden, um mit dem Webserver zu kommunizieren. Das CGI-Protokoll verlangt, dass für jede neue Anforderung ein neuer CGI-Prozess gestartet wird, der die Anforderung bearbeitet. Dies wirkt sich sehr nachteilig auf die Windows-Leistung aus. FastCGI ist eine Alternative, die anstelle von CGI verwendet werden sollte, weil sie aufgrund der Wiederverwendung von Prozessen eine bessere Leistung bietet. Für Anwendungsframe-works, die FastCGI nicht unterstützen, und für die nativen IIS-Mechanismen ist CGI jedoch eine Option.

Um einen CGI-Programm bereitzustellen, gehen Sie wie folgt vor:

1. Erstellen Sie einen auf einer Skriptzuordnung basierenden Handlerzuordnungseintrag, der den gewünschten URL-Pfad und alle benötigten Argumente der ausführbaren CGI-Datei zuordnet. Dies kann auf der Serverebene oder für eine bestimmte Site, Anwendung oder einen URL geschehen.

2. Fügen Sie der Konfiguration system.webServer/security/isapiCgiRestriction die ausführbare CGI-Datei hinzu. Dazu sind administrative Rechte erforderlich. Dies ist ein notwendiger Schritt, damit auf dem Webserver die Kombination aus eindeutigem Pfad zur ausführbaren CGI-Datei und Argumen-ten ausgeführt werden kann.

Alternativ hierzu unterstützt CGI auch die Möglichkeit, .exe-Dateien zu starten, die sich innerhalb Ihrer Anwendung befinden, sofern der Client die jeweilige ausführbare Datei direkt anfordert. Dazu müssen für das Verzeichnis Ausführungsberechtigungen gewährt werden und der authentifizierte Benutzer muss Ausführungsberechtigungen für die ausführbaren Dateien erhalten.

Verwenden Sie stattdessen eine Handlerzuordnung und einen Skriptprozessor, der so konfiguriert ist, dass er auf das CGI-Programm verweist, sind nur Skriptberechtigungen erforderlich. In beiden Fällen müssen die genauen Befehlszeilen (der Pfad zum CGI-Programm und alle zu übergebenden Argumente) im Konfigurationsabschnitt system.webServer/security/isapiCGIRestriction aufgeführt werden.

Hinweis Der IIS-Manager kann im Konfigurationsabschnitt system.webServer/security/isapiCgiRestriction den Eintrag für die ausführbare CGI-Datei nach einer entsprechenden Bestätigung automatisch erstellen, wenn Sie die Handlerzuordnung erzeugen. Dazu müssen Sie als Serveradministrator verbunden sein.

Genaue Informationen zu jedem dieser Schritte finden Sie im zwölften Kapitel.

Hinweis Es ist nicht möglich, für den CGI-Prozess benutzerdefinierte Umgebungsvariablen zu setzen. CGI übergibt dem CGI-Prozess immer einen festen Satz Servervariablen als Umgebungsvariablen, wie dies in der CGI-Protokollspezifikation definiert ist. Wenn Ihr Anwendungsframework das FastCGI-Protokoll unterstützt und Sie FastCGI verwenden, können Sie benutzerdefinierte Umgebungsvariablen verwenden.



Da CGI immer dann, wenn eine Anforderung eingeht, einen neuen Prozess startet, wird dieser unter der Identität des authentifizierten Benutzers ausgeführt (sofern verfügbar). Dies ist das Standardverhalten. Deshalb werden die CGI-Prozesse und die von diesen Prozessen ausgeführten Skripts standardmäßig unter der Identität des authentifizierten Benutzers oder bei anonymen Anforderungen unter der Identität des anonymen IIS-Benutzers (IIS_IUSR) ausgeführt. Sie können dieses Verhalten auf dem Computer global deaktivieren, indem Sie das createProcessAsUser-Attribut im Konfigurationsabschnitt system.web-Server/cgi auf false setzen.

Sie können CGI-Konfigurationseinstellungen mit dem IIS-Manager, mit Appcmd von der Befehlszeile aus oder unter Verwendung der Konfigurations-APIs festlegen. Der Konfigurationsabschnitt system.web-Server/cgi ist global und kann deshalb nur einen Satz Einstellungen für den gesamten Server aufweisen. Sie können eine Konfiguration in diesem Abschnitt festlegen, indem Sie die folgende Appcmd-Syntax verwenden:%systemroot%\system32\inetsrv\Appcmd set config /section:system.WebServer/cgi [/createCGIWithNewConsole:bool] [/createProcessAsUser:bool] [/timeout:timespan]

Die zum Setzen von CGI-Konfigurationen benötigten Parameter sind in Tabelle 11.8 aufgeführt.

Hinweis Wenn Sie für den Anwendungspool ein benutzerdefiniertes Konto verwenden, müssen Sie dem benutzer-definierten Konto die Benutzerrechte Anpassen von Speicherkontingenten für einen Prozess und Ersetzen eines Tokens auf Prozessebene gewähren. Sie können dies mit der Konsole für die Einstellungen der lokalen Sicherheits-richtlinie tun.

Darüber hinaus können Sie ein CGI-Prozesslimit konfigurieren, das für alle IIS-Arbeitsprozesse gleich-zeitig aktiv sein kann. Wird die Zahl überschritten, werden alle folgenden eingehenden CGI-Anforde-rungen, die an den jeweiligen Arbeitsprozess gerichtet sind, in die Warteschlange gestellt, bis die Anzahl der CGI-Prozesse das Limit unterschreitet. Diese Einstellung kann ausschließlich in der Windows-Registrierung konfiguriert werden, indem im Registrierungsschlüssel HKLM\System\CurrentControlSet\ Services\W3SVC\Parameters\ der DWORD-Wert MaxConcurrentCgisExecuting erstellt wird. Wird dieser Wert nicht gesetzt, beträgt das Limit standardmäßig 256 CGI-Prozesse pro IIS-Arbeitsprozess.

Vorsicht Denken Sie daran, dass das Starten einer großen Anzahl von CGI-Prozessen einen Webserver schnell überfordern kann. Der Grund hierfür ist der Speicheroverhead eines jeden Prozesses und der mit dem Starten neuer Prozesse verbundene Aufwand. Eine solche Überlastung zeigt sich besonders dann, wenn Sie mit mehreren Anwendungspools arbeiten, da das Limit für jeden einzelnen IIS-Arbeitsprozess gilt. Deshalb müssen Sie das MaxConcurrentCgisExecuting-Limit möglicherweise auf einen sehr viel geringeren Wert setzen. Denken Sie darüber nach, FastCGI anstelle von CGI zu benutzen, um diesen Overhead zu verringern.

Tabelle 11.8 Parameter zum Setzen von CGI-Konfigurationen

Einstellung Beschreibung

createCGIWithNewConsole Gibt an, ob ein CGI-Prozess mit einer neuen Konsole erstellt werden soll. Der Vorgabewert ist false.

createProcessAsUser Gibt an, ob ein CGI-Prozess unter der Identität des authentifizierten Benutzers erstellt werden soll. Der Vorgabewert ist true.

Timeout Das Anforderungstimeout in Sekunden, nach dessen Ablauf der CGI-Prozess beendet wird. Der Standard ist 15 Minuten.



ZusammenfassungIIS 7.0 bietet viele Optionen für das Hosting von Anwendungsframeworktechnologien. Dabei wurde die Anzahl dieser Optionen im Vergleich zu früheren IIS-Versionen noch vergrößert, indem die integrierte Unterstützung des FastCGI-Protokolls eingeführt wurde. Zusammen mit anderen Anwendungsframe-workschnittstellen, z.B. ISAPI-Erweiterungen, ASP.NET-Handler und systemeigene IIS 7.0-Module, öffnet dies die Tür zu vielen Anwendungsframeworks, die früher nicht auf IIS abzielten.

IIS ermöglicht aber nicht bloß das Hosting von Anwendungsframeworktechnologien, sondern bietet einen umfassenden Satz Features und Verwaltungsfunktionen an, die die Möglichkeiten eines jeden Anwendungsframeworks erweitern. Zusammen mit dem neuen ASP.NET-Integrationsmodus, der die IIS-Erweiterbarkeit auf der Webserverebene ermöglicht, können diese Technologien die Leistungs-fähigkeit des .NET Frameworks und von ASP.NET nutzen, ohne zu diesen Technologien migrieren zu müssen. Weitere Informationen zur Erweiterung von IIS 7.0 erhalten Sie im zwölften Kapitel.

In diesem Kapitel haben Sie erfahren, wie IIS als Anwendungsframeworkplattform verwendet wird und wie gebräuchliche Anwendungsplattformen, wie z.B. ASP.NET, ASP und PHP, installiert und bereit-gestellt werden. Sie haben außerdem erfahren, wie Sie unter IIS die allgemeinen Optionen zum Hosten von Anwendungsframeworks nutzen, um Anwendungsframeworks von Drittanbietern hinzuzufügen.

Um mehr über das Sichern und Isolieren von Anwendungen unter IIS 7.0 zu erfahren, sollten Sie im vierzehnten Kapitel die empfohlenen Vorgehensweisen lesen.


� Die offizielle IIS-Website finden Sie unter http://www.iis.net.

� Die offizielle ASP.NET-Website finden Sie unter http://www.asp.net.

� Die offizielle PHP-Website finden Sie unter http://www.php.net.

� Um mehr über die Installation und Verwaltung von Webservermodulen zu erfahren, lesen Sie bitte das zwölfte Kapitel, »Verwalten von Webservermodulen«.

� Um zu erfahren, wie Sie die Sicherheit des Webservers und der Anwendungsframeworks verbessern können, lesen Sie das vierzehnte Kapitel, »Implementieren von Sicherheitsstrategien«.

� Um einen Blog zu lesen, der regelmäßig Informationen zum Hosting von Anwendungen wie ASP.NET und PHP unter IIS bereitstellt, besuchen Sie bitte http://mvolo.com.


349

K A P I T E L 1 2

Verwalten von Webservermodulen

Inhalt dieses Kapitels:� IIS 7.0-Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

� Webservererweiterbarkeit zur Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353



IIS 7.0-ErweiterbarkeitInnerhalb des IIS 7.0-Teams (Internet Information Services) gibt es den Running Gag, dass jede IIS-Version eine vollständige Neufassung der vorherigen Version sein muss. Wenn man jedoch einen Blick auf die Geschichte dieses Produkts wirft, gab es für jede Neufassung einen ernsten Grund. IIS 6.0, das mit Windows Server 2003 ausgeliefert wurde, war in Folge der bedenklichen Sicherheitslücken, die im Sommer 2001 durch CodeRed und Nimbda verursacht wurden, eine Neufassung von IIS 5.1 (Windows XP). Diese Neufassung, deren Hauptaugenmerk darin bestand, einen extrem zuverlässigen, schnellen und sicheren Webserver zu generieren, war ein überwältigender Erfolg – wie die durch die extreme Zuverlässigkeit und Sicherheit bedingte IIS 6.0-Erfolgsgeschichte bis heute bestätigt.

Auch IIS 7.0 ist wieder eine vollständige Neufassung des Webservers, diesmal jedoch aus einem anderen Grund – um die zuverlässige und sichere Codebasis von IIS 6.0 in eine leistungsfähige Webanwendungs-plattform der nächsten Generation zu transformieren. Um dies zu erreichen, unternimmt die IIS 7.0-Version jede Anstrengung, um eine vollständige Plattformerweiterbarkeit zur Verfügung zu stellen. Das Ergebnis? Der Webserver mit der bestmöglichen Funktionsfülle, Flexibilität und Erweiterbarkeit, die Microsoft umsetzen konnte.

Die erweiterbare Architektur von IIS 7.0 verbirgt sich hinter fast allen wichtigen Verbesserungen, die diese Version bietet. Fast die gesamte Funktionalität des Webservers, beginnend mit den Webserver-laufzeitfeatures bis hin zur Konfiguration und den IIS-Manager-Features, können durch Drittanbieter entfernt oder ersetzt werden. Dies ermöglicht es den Kunden, vollständige Lösungen zu erstellen, die die von den jeweiligen Anwendungen benötigte Funktionalität liefern.

Darüber hinaus gründet auch der Featuresatz von IIS 7.0 auf demselben Erweiterbarkeitsmodell, das von Drittanbietern verwendet werden kann, um den Server weiter anzupassen. Dies ist ein Schlüssel-konzept, das gewährleistet, dass das den Drittanbietern zur Verfügung stehende Erweiterbarkeitsmodell so leistungsfähig und flexibel ist, dass selbst die integrierten Features damit erstellt werden können. Außerdem gibt es eine einheitliche Vorgehensweise zur Verwaltung von Webserverfeatures, und zwar unabhängig davon, ob es sich dabei um die integrierten IIS 7.0-Features oder Features von Drittan-bietern handelt. Dies ist der Kern der Modularität von IIS 7.0. Diese Modularität in Verbindung mit dem Erweiterbarkeitsmodell ermöglicht es Ihnen, Ihren Webserver in einen effizienten, spezialisierten Server zu verwandeln, der genau das bietet, was Sie benötigen, und sonst nichts.


350 Kapitel 12: Verwalten von Webservermodulen

Mit IIS 7.0 können Sie erstmals:

� einen Webserver mit einem geringen Ressourcenbedarf und einer kleinen Angriffsfläche erstellen, der für einen bestimmten Arbeitsschwerpunkt optimiert ist.

� jedes integrierte Feature durch ein benutzerdefiniertes Feature ersetzen, das Sie selbst entwickelt oder von einem externen unabhängigen Softwareanbieter erworben haben.

� vollständige End-to-End-Lösungen erstellen, die sich nahtlos in den Webserver integrieren. Bei-spiel hierfür sind Anforderungsverarbeitungfunktionalität sowie die Konfiguration, Diagnose und Verwaltung.

Bisher betraf die Erweiterbarkeit hauptsächlich die Entwickler. Bei IIS 7.0 ist sie jedoch ebenfalls für die Bereitstellung und den Betrieb des Webservers von Bedeutung. Deshalb müssen die IT-Mitarbeiter in diesem Bereich über ein solides Fachwissen verfügen. Die Fähigkeit, die Features, aus denen der Web-server besteht, richtig bereitzustellen, zu konfigurieren und anzupassen, ist wichtig, um eine funktionelle, skalierbare und sichere IIS-Produktionsumgebung zu erhalten. Die richtige Nutzung der Flexibilität von IIS 7.0 ermöglicht es Ihnen, Webserverbereitstellungen zu realisieren, die nur wenige Ressourcen ver-brauchen und schnell und sicher sind. Andererseits muss die mit dieser Flexibilität einhergehende Komplexität richtig verwaltet werden, so dass Sie einen fehlerfreien Betrieb gewährleisten und die Gesamtbetriebskosten Ihrer Webserverfarm verringern können.

Dieses Kapitel wirft aus der Sicht des IT-Experten einen Blick auf die von IIS 7.0 zur Verfügung gestellte End-to-End-Erweiterbarkeitsplattform. In diesem Kapitel erfahren Sie, wie der modulare Featuresatzes von IIS 7.0 verwaltet wird, um eine effiziente, zuverlässige und sichere IIS-Umgebung einzurichten.

Die IIS 7.0-Erweiterbarkeitsarchitektur auf einen BlickDie IIS 7.0-Webserverplattform ist ein komplexes System, das aus vielen Bestandteilen besteht, die für den Betrieb, die Verwaltung und die Unterstützung der darauf ausgeführten Webanwendungen notwendig sind. Dazu zählen der Webserver selbst, das Konfigurationssystem, das den Webserver und seine Features unterstützt, der Verwaltungsstack, der ein Objektmodell für die Verwaltung des Servers bereitstellt, APIs (Application Programming Interface) für die Laufzeitstatusüberwachung und verschiedene Verwaltungs-tools und APIs, mit deren Hilfe der Benutzer auf die Konfiguration- und Verwaltungsfunktionalität zu-greifen kann. Jedes dieser Subsysteme stellt eine öffentliche Erweiterbarkeitsschicht zur Verfügung, auf die die integrierte Funktionalität in Form von modularen Komponenten aufsetzt. Dieses Design unterstützt sowohl die Serverspezialisierung als auch die Anpassung des Servers mithilfe zusätzlicher Features von Drittanbietern bzw. durch das Ersetzen integrierter Features. Abbildung 12.1 zeigt eine Übersicht über die Erweiterbarkeitsarchitektur.

Die Erweiterbarkeitsfunktionalität konzentriert sich in der Webserverengine, die HTTP-Anforderungen empfängt, diese verarbeitet (oft mithilfe eines Anwendungsframeworks wie ASP.NET oder PHP) und Antworten an den Client zurückgibt. Hier findet das eigentliche Geschehen statt – IIS 7.0 wird mit mehr als vierzig Webservermodulen ausgeliefert, die für alles verantwortlich sind, von der Authentifizierung, Sicherheit und Antwortkomprimierung bis hin zu Leistungserweiterungen und zur Unterstützung von Anwendungsframeworks wie ASP. Diese Module nutzen eines der beiden von IIS 7.0 zur Verfügung gestellten Laufzeiterweiterbarkeitsmodelle – das neue C++-Kernerweiterbarkeitsmodell oder das integ-rierte ASP.NET-Erweiterbarkeitsmodell –, die beide die Flexibilität bieten, die integrierte IIS 7.0-Funktionalität zu ersetzen oder eine eigene neue Funktionalität hinzuzufügen.


IIS 7.0-Erweiterbarkeit 351

Abbildung 12.1 Die IIS 7.0-Erweiterbarkeit erstreckt sich über den Webserver, das Konfigurationssystem und den IIS-Manager

Wie Sie jedoch wissen, ist IIS weitaus mehr als eine Laufzeitengine für die Verarbeitung von Anforde-rungen. Es bietet ebenfalls ein brandneues verteiltes Konfigurationssystem für die Konfiguration der Funktionalität des Webservers und seiner Module, das viele Features aufweist, die entwickelt wurden, um die Konfiguration zu vereinfachen, die Konfiguration an Nicht-Administratoren zu delegieren und Konfigurationseinstellungen zusammen mit den jeweiligen Anwendungen per xcopy bereitzustellen. In Angesicht der zunehmenden Webserverkomplexität ist das Konfigurationssystem wichtiger als jemals zuvor und es muss die Vielzahl individueller Konfigurationen und betriebsbedingter Anforderungen, die von modernen Anwendungen festgelegt werden, unterstützen.

Das IIS 7.0-Team hat das Konfigurationssystem so entwickelt, dass es jede dieser Herausforderungen meistert und dies auch den Lösungen von Drittanbietern durch den Einsatz der Konfigurationserweiter-barkeit ermöglicht. Die Konfigurationskomponenten greifen genauso wie die Webserverfeatures auf dieselbe Konfigurationserweiterbarkeitsschicht zurück, die genutzt werden kann, um benutzerdefinierte Konfigurationen für die Webservermodule von Drittanbietern zu erstellen. Dies bedeutet, dass jedes benutzerdefinierte Webservermodul seine eigenen Konfigurationseinstellungen einfach offen legen kann, die dann in denselben Konfigurationsdateien gespeichert und mit denselben Standard-APIs und -Tools verwaltet werden können wie der Rest der IIS 7.0-Konfiguration.

Zusätzlich zu einer statischen dateibasierten Konfiguration unterstützt IIS 7.0 Verwaltungsobjekte, die eine dynamische Konfiguration und die Verwaltungsfunktionalität über das IIS 7.0-Konfigurations-objektmodell ermöglichen. Auf diese Weise können neue IIS-Verwaltungsobjekte hinzugefügt oder eine benutzerdefinierte Verwaltungsfunktionalität über bereits vorhandene IIS-Objekte, z.B. das Site- oder Anwendungspoolobjekt, offen gelegt und von den Standard-APIs und -Tools verwendet werden. Der Verwaltungsstack ist ebenfalls erweiterbar und auch die IIS-Verwaltungsobjekte nutzen das Erweiterbarkeitsmodell.

Schließlich bietet selbst der IIS-Manager (der das alte MMC-Programm InetMgr.exe ersetzt) eine eigene Erweiterbarkeitsfunktionalität, damit ihm Verwaltungseiten mit einer grafischen Benutzeroberfläche hinzugefügt werden können, die wiederum die Navigations-, Delegierungs- und Remoteverwaltungs-möglichkeiten nutzen.



Zusammen bilden diese Erweiterbarkeitsmechanismen die Grundlage für End-to-End-Lösungen, die für IIS 7.0 entwickelt werden können, wobei benutzerdefinierte Webserverfeatures eine benutzer-definierte Konfiguration und Verwaltungsfunktionalität aufweisen und gleichzeitig die Möglichkeiten nutzen können, die von der Benutzeroberfläche des IIS-Managers geboten werden.

Die Erweiterbarkeit verwaltenDie modulare Architektur dient als Grundlage für viele neue aufregende IIS 7.0-Funktionen, von der Möglichkeit, spezialisierte Server einzurichten, bis hin zur Sicherung und Optimierung der Serverleistung. Sie hält aber auch ein hohes Maß an Komplexität für den Administrator bereit. Diese Komplexität gilt es zu verwalten, um sich die Vorzüge des Komponentensystems nutzbar zu machen. Das führt zu einer Verlagerung der Erweiterbarkeitsplanung und -verwaltung in Richtung der IT-Abteilung, so dass nicht mehr allein die Entwickler für diese Aufgaben verantwortlich sind, wie dies früher der Fall war. Dies-bezüglich konzentriert sich dieses Kapitel auf alle Aufgaben, die mit der Verwaltung der Erweiterbarkeit und weniger mit der Entwicklung unter Verwendung von Erweiterbarkeitskomponenten zu tun haben.

Das erste Thema von Interesse ist natürlich die Installation der Erweiterbarkeitskomponenten, so dass Sie sie auf dem Server verwenden können. Die integrierten IIS 7.0-Features sind vollständig im Windows-Setup enthalten und können unter Windows Server 2008 mithilfe des Server-Managers und unter Windows Vista mit der Option Windows-Funktionen ein- oder ausschalten installiert werden (weitere Informationen hierzu finden Sie im fünften Kapitel, »Installieren von IIS 7.0«). Das Windows-Setup besitzt alle Informationen, die notwendig sind, um diese Komponenten zu installieren und unter Verwendung der IIS 7.0-Konfigurations-APIs zu konfigurieren. Deshalb erfordert die Installation dieser Komponenten in der Regel kein zusätzliches Eingreifen, obwohl in einigen Fällen eine zusätzliche Konfiguration notwendig ist, damit die Verfügbarkeit der Komponenten für bestimmte Anwendungen auf dem Server bestimmt werden kann.

Dies gilt jedoch nicht für Drittanbieterkomponenten, die von unabhängigen Softwareanbietern oder hausintern von Ihrem Entwicklungsteam erstellt wurden. Ohne die Unterstützung des Windows-Setups müssen Drittanbieterkomponenten unter direkter Verwendung der IIS 7.0-Konfiguration installiert werden. Dabei ist es oft notwendig, spezielle Bereitstellungs- und Installationsoptionen für Ihre Komponenten zu berücksichtigen. Da die Möglichkeit, IIS 7.0 an spezifische Anwendungslösungen anzupassen, oft auf der IIS 7.0-Modularität beruht, ist es besonders wichtig, die Erweiterbarkeitskomponenten von IIS 7.0 richtig zu installieren und den auf dem Server aktivierten Featuresatz ordnungsgemäß zu verwalten. Glücklicher-

Direkt von der QuelleIIS 7.0 repräsentiert eine Systemarchitektur, die auf ihrer eigenen Erweiterbarkeit basiert, anstatt diese nachträglich hinzuzufügen. Fast alle Komponenten des Servers, einschließlich der Webserver-features, der Konfiguration dieser Features und der Verwaltungsseiten des IIS-Managers, gründen auf denselben Erweiterbarkeitsmodellen, die auch von Drittanbietern genutzt werden können. Im Laufe der vier Jahre, die ich an diesem Projekt arbeitete, konnte ich dieses Leistungsvermögen selbst erleben, da sich mir die einmalige Gelegenheit bot, sowohl den Kern der Erweiterbarkeitsplattform als auch die Features, die diese Plattform nutzen, zu konzipieren und zu entwickeln. In gewisser Weise war IIS 7.0 selbst unser bester Kunde, weil es uns dabei half, die Plattform richtig aufzubauen, bevor die ersten echten Kunden damit arbeiteten.

Mike Volodarsky

Program Manager, IIS 7.0


Webservererweiterbarkeit zur Laufzeit 353

weise bietet IIS 7.0 viele Verwaltungstools an, die zur Durchführung der Installationsaufgaben verwendet werden können. Ausgerüstet mit dem richtigen Fachwissen können Sie somit zu einem Experten werden, wenn es um die Bereitstellung der IIS 7.0-Erweiterbarkeit geht. In dieser Hinsicht beschreibt dieses Kapitel, wie Webservermodule installiert und verwaltet werden. Sie erfahren im dreizehnten Kapitel, »Konfigurations- und Benutzeroberflächenerweiterungen verwalten«, wie die Konfiguration und die IIS-Manager-Erweiterungen verwaltet werden.

Nachdem die Bereitstellung behandelt wurde, lernen Sie einige häufige Konfigurations- und Verwaltungs-aufgaben für jeden Erweiterbarkeitstyp kennen. Obwohl diese Aufgaben nicht immer notwendig sind, tragen sie häufig dazu bei, dass Ihre Komponenten in bestimmten Situationen genau das tun, was Sie erwarten. Sie sorgen außerdem dafür, dass z.B. Ihre Module in der richtigen Reihenfolge ausgeführt werden und in einer gemischten 32-Bit/64-Bit-Umgebung korrekt funktionieren. Diese Aufgaben sind von Erweiterbarkeitstyp zu Erweiterbarkeitstyp unterschiedlich und basieren größtenteils auf Erfahrung, die die Microsoft-Entwickler während der Entwicklung von IIS 7.0 im Rahmen der Entwicklung und Verwendung der Erweiterbarkeitsschichten gesammelt haben.

IIS 7.0 legt genauso wie IIS 6.0 viel Wert auf die Sicherheit und bietet standardmäßig zusätzliche Sperrungen. Darüber hinaus führt es neue Sicherheitsfeatures ein, die Ihnen helfen, Ihre Webserver-bestände noch besser zu sichern. Eine äußerst effektive Möglichkeit, die Sicherheit Ihres Servers zu verbessern, besteht darin, die Komponentenarchitektur zu nutzen und alle nicht benötigten Kompo-nenten zu entfernen, so dass Ihr Server die geringstmögliche Angriffsfläche bietet. Wenn Sie neue Komponenten hinzufügen, sollten Sie sich der zunehmend großen Angriffsfläche Ihres Servers bewusst sein und Sie sollten in diesem Fall die möglichen Auswirkungen des neuen, auf dem Server ausge-führten Codes kennen. Ein hinreichendes Verständnis der Auswirkungen von Webserverkomponenten auf die Sicherheit ist wichtig, um eine sichere Betriebsumgebung aufrechtzuerhalten und die Vorzüge der IIS 7.0-Erweiterbarkeitsfunktionalität nutzen zu können, ohne die Sicherheit zu gefährden.

Dieses Kapitel vermittelt das Wissen, das Sie benötigen, um Webservermodule sicher bereitzustellen, und es beschreibt Sicherheitsstrategien, die Sie nutzen können , um Ihren Server abzuriegeln. Sie lernen außerdem die Besonderheiten kennen, die Sie berücksichtigen sollten, wenn Sie einen Shared Hosting-server oder Abteilungsserver konfigurieren, was bedingt, dass Nicht-Administratoren Erweiterbarkeits-komponenten veröffentlichen können. Weitere Informationen zur Sicherung der Konfiguration und zu IIS-Manager-Erweiterungen finden Sie im dreizehnten Kapitel.

Webservererweiterbarkeit zur LaufzeitDas Webservererweiterbarkeitsmodell bildet die Basis der modularen IIS 7.0-Architektur, so dass Web-server bereitgestellt werden können, die einen nur geringen Ressourcenverbrauch und eine kleine Angriffsfläche aufweisen und hochspezialisiert sind. All dies ist möglich, weil die integrierten IIS 7.0-Features als plugfähige Module implementiert sind, die auf dieselben Erweiterbarkeits-APIs aufsetzen, die auch für Drittanbietermodule zur Verfügung stehen. Sie werden außerdem mit denselben Konfigura-tions- und Verwaltungstools konfiguriert und verwaltet.

Was ist ein Modul?Funktionell betrachtet ist ein Modul eine Webserverkomponente, die an der Verarbeitung einiger oder aller Anforderungen beteiligt ist und in der Regel einen Dienst anbietet, der jeden beliebigen Funktions-bereich abdecken kann, von bestimmten Authentifizierungsverfahren (z.B. das Modul für die Windows-Authentifizierung) bis hin zur Aufzeichnung und Anzeige der gegenwärtig ausgeführten Anforde-



rungen (z.B. das Modul für die Anforderungsüberwachung). Die Module werden an verschiedenen Stellen der Anforderungsverarbeitungspipeline ausgeführt und beeinflussen diese Verarbeitung, indem sie die vom Webservererweiterbarkeitsmodell offen gelegten APIs verwenden. Die meisten Module bieten voneinander unabhängige Dienste an, um einer Webanwendung bestimmte Funktionen hinzu-zufügen oder den Webserver anderweitig zu erweitern.

Der Anwendungsentwickler oder IT-Administrator kann dann den Webserver aus der benötigten Funk-tionalität zusammensetzen, indem er bestimmt, welche Module für die Anwendung aktiviert werden. Dies ist vergleichbar mit dem Zusammensetzen von LEGO-Steinen. IIS 7.0 ermöglicht eine genaue Kontrolle darüber, welche Module aktiviert werden sollen, so dass Administratoren die Funktionalität des gesamten Servers, aber auch spezifischer Anwendungen (was später in diesem Kapitel behandelt wird) festlegen können.

Technisch betrachtet werden IIS 7.0-Module entweder als native DLLs (Dynamic Link Library) imple-mentiert, die basierend auf dem neuen nativen C++-Erweiterbarkeitsmodell von IIS 7.0 entwickelt wurden, oder in Form von verwalteten .NET Framework-Klassen, die das neue ASP.NET-Integrations-modell nutzen, das in IIS 7.0 verfügbar ist. Beide APIs ermöglichen es den Modulen, zu einem Bestand-teil der IIS 7.0-Anforderungsverarbeitungspipeline zu werden und die Anforderungs- und Antwort-verarbeitung bei Bedarf zu manipulieren. Obwohl diese beiden Erweiterbarkeitsmodelle zwei verschie-dene APIs nutzen und sowohl aus der Sicht des Entwicklers als auch aus der Perspektive des IT-Admi-nistrators viele unterschiedliche Merkmale aufweisen, implementieren beide das Konzept eines logi-schen Moduls. IIS 7.0 kann deshalb sowohl C++- als auch .NET Framework-Entwicklern eine einheit-liche Entwicklungsabstraktionsschicht für die Erweiterung des Webservers zur Verfügung stellen. Das Konzept eines logischen Moduls führt ebenfalls dazu, dass IIS 7.0 dem Administrator eine größtenteils vereinheitlichte Verwaltung der Webserverfeatures ermöglicht. Informationen zu den Unterschieden zwischen systemeigenen und verwalteten Webservermodulen und dazu, wie sich diese Unterschiede auf die Installation und Verwaltung von Modulen auswirken, finden Sie später in diesem Kapitel im Abschnitt »Unterschiede zwischen verwalteten (.NET) und systemeigenen (C++) Modulen«.

Die AnforderungsverarbeitungspipelineDie Anforderungsverarbeitungspipeline von IIS 7.0 ist die Basis der modularen Architektur, die es mehreren voneinander unabhängigen Modulen ermöglicht, verschiedene nützliche Dienste für dieselbe Anforderung zur Verfügung zu stellen.

Hinweis Bei IIS 7.0 führte die Webserverengine selbst nur einen geringen Teil der Verarbeitung durch. Den größten Teil der Anforderungsverarbeitung erledigen die Module.

Die Pipeline selbst ist im Wesentlichen ein deterministischer Statusträger, der es den Modulen ermöglicht, im Verlauf einer festgelegten Reihenfolge von Verarbeitungsphasen (auch bekannt als Ereignisse), mit einer Anforderung zu interagieren. Wie Abbildung 12.2 zeigt, durchläuft der Statusträger beim Empfang einer Anforderung alle Phasen vom Anfang bis zum Ende, wobei er die entsprechenden Ereignisse auslöst und jedem Modul die Möglichkeit bietet, die gewünschte Phase zu nutzen, um die vorgesehenen Arbeiten zu verrichten.

Die meisten Ereignisse in der Anforderungsverarbeitungspipeline sind für einen bestimmten Aufgabentyp vorgesehen, z.B. für die Authentifizierung, die Autorisierung, das Caching oder die Protokollierung. Module, die diese Ereignisse abonnieren, können einen spezifischen Dienst für die jeweilige Phase zur Verfügung stellen. Das Authentifizierungsereignis ist beispielsweise das Ziel vieler IIS 7.0-Module, einschließlich des Moduls für die Windows-Authentifizierung (NTLM- und Kerberos-Authentifizierung),



die Standardauthentifizierung, die ASP.NET-Formularauthentifizierung usw. Während der Anforderungs-verarbeitung ermöglichen diese Ereignisse die Ausführung mehrerer Module und typischer Webserverver-arbeitungsaufgaben in der richtigen Reihenfolge. Die Ermittlung des mit der Anforderung verknüpften Benutzers (Authentifizierungsphase) muss beispielsweise geschehen, bevor überprüft wird, ob dieser Benutzer auf die angeforderte Ressource zugreifen darf (Autorisierungsphase).

Abbildung 12.2 Die Anforderungsverarbeitungspipeline

Es gibt andere Ereignisse, die eine zusätzliche Flexibilität bieten, so dass Module während der Anforde-rungsverarbeitung bestimmte Aufgaben zu bestimmten Zeitpunkten ausführen können (in der Regel zwischen den Ereignissen, die für spezielle Situationen vorgesehen sind, wie die Authentifizierung und Autorisierung). Tabelle 12.1 listet alle Ereignisse und einige IIS 7.0-Module auf, die diese Ereignisse abonnieren.

Tabelle 12.1 Anforderungsverarbeitungsereignisse

Ereignis Beschreibung Module

BeginRequest Die Anforderungsverarbeitung beginnt Modul für die Anforderungsfilterung, Modul für IP-Ein-schränkungen

AuthenticateRequest Der für die Anforderung authentifizierte Benutzer wird ermittelt

Authentifizierungsmodule, einschließlich des Moduls für die Windows-Authentifizierung, Standardauthentifizierung und ASP.NET-Formularauthentifizierung

AuthorizeRequest Der Zugriff auf die angeforderte Res-source wird für den authentifizierten Benutzer überprüft, und die Anforderung wird bei einer Zugriffsverweigerung zurückgewiesen

Modul für die URL-Autorisierung



Es ist wichtig, zu verstehen, dass die meisten Module während der Anforderungsverarbeitung für dieselben Anforderungen und denselben jeweiligen Antwortstatus ausgeführt werden und die Operation der anderen Module beeinflussen können, obwohl sie in sich geschlossen sind und voneinander unab-hängige Dienste anbieten. In einigen Fällen sind diese Beziehungen Teil eines formellen Schemas (wie z.B. des Authentifizierungs- und Autorisierungsschemas), während sie in anderen Situationen unbeab-sichtigt sind. Im letzten Fall kann es sein, dass einige Module nicht kompatibel miteinander sind oder es ist eine bestimmte Reihenfolge notwendig, damit eine korrekte Funktionsweise gewährleistet ist. Die Reihenfolge von Modulen wird später in diesem Kapitel im Abschnitt »Die Modulreihenfolge kontrol-lieren« behandelt.

Unterschiede zwischen verwalteten (.NET) und systemeigenen (C++) ModulenWie bereits erwähnt, unterstützt IIS sowohl 7.0 Module, die mit der nativen C++-API von IIS 7.0 entwickelt wurden, als auch so genannte verwaltete Module, für deren Entwicklung die ASP.NET-Modul-API genutzt wurde.

ResolveRequestCache Der Server prüft, ob die Antwort auf die Anforderung aus dem Cache abgerufen werden kann

Modul für die IIS-Ausgabezwischenspeicherung, Modul für die ASP.NET-Ausgabezwischenspeicherung

MapRequestHandler Der Handler wird für die Anforderung ermittelt

AcquireRequestState Der mit der Anforderung verknüpfte Zustand wird abgerufen

Modul für den ASP.NET-Sitzungszustand

PreExecuteRequestHandler Der Server steht kurz vor der Ausführung des Handlers

ExecuteRequestHandler Der Anforderungshandler wird ausge-führt und generiert die Antwort

Alle Module, die Anforderungen behandeln, einschließlich des Moduls für statische Dateien, des Moduls zum Auflisten von Verzeichnissen, des Standarddokumentmoduls, des ISAPI-Erweiterungsmoduls und des ASP.NET-Moduls PageHandler

ReleaseRequestState Der Zustand wird freigegeben Modul für den ASP.NET-Sitzungszustand

UpdateRequestCache Der Cache wird aktualisiert Modul für die IIS 7.0-Ausgabezwischenspeicherung, Modul für die ASP.NET-Ausgabezwischenspeicherung

LogRequest Die Anforderung wird protokolliert Modul für die benutzerdefinierte Protokollierung

EndRequesta Die Anforderungsverarbeitung steht kurz vor dem Abschluss

Modul für die Anforderungsüberwachung

a) Abgesehen vom EndRequest-Ereignis gibt es zu allen Ereignissen in dieser Tabelle ein entsprechendes Post-Ereignis, z.B. PostBeginRequest und BeginRequest. Post-Ereignisse existieren primär, um Modulen eine zusätzliche Flexibilität zu bieten, so dass sie zwischen bestimmten Ereignissen bestimmte Aufgaben ausführen können.

Tabelle 12.1 Anforderungsverarbeitungsereignisse (Fortsetzung)

Ereignis Beschreibung Module



Die C++-Modul-API von IIS 7.0 ersetzt als neues natives Erweiterbarkeitsmodell für IIS 7.0 und zukünftige IIS-Versionen die alte ISAPI-Filter- und -Erweiterungs-API. Bereits vorhandene ISAPI-Filter und -Erweiterungen werden auch weiterhin unterstützt, doch den Entwicklern wird geraten, das Modulerweiterbarkeitsmodell zu nutzen, um neue Serverkomponenten zu erstellen. Selbst die Unter-stützung von ISAPI-Filtern und -Erweiterungen ist bei IIS 7.0 in Form eines systemeigenen Moduls implementiert, das mit dieser neuen nativen API entwickelt wurde und ISAPI-DLLs hostet und aus-führt. Module, die unter Verwendung der neuen nativen API entwickelt wurden, gleichen ISAPI-Filtern in der Hinsicht, dass es sich um Win32-DLLs handelt, die von jedem IIS-Arbeitsprozess prozessintern geladen werden und die Verarbeitung jeder Anforderung beeinflussen können. Da sie mit den Rechten und Berechtigungen des IIS-Arbeitsprozesses ausgeführt werden, gehen sie mit denselben Sicherheits-auswirkungen einher und müssen somit für den Serveradministrator vertrauenswürdig sein.

Hier enden jedoch alle Ähnlichkeiten, weil IIS 7.0-Module eine verbesserte und sehr viel leistungs-fähigere C++-API verwenden sowie eine größere Zahl von Erweiterungsmöglichkeiten durch das Abonnieren von Ereignissen in der Anforderungsverarbeitungspipeline nutzen und komplexere Auf-gaben lösen können. Die neue C++-API vereinfacht außerdem die Entwicklung auf dem Server und vermindert mögliche Probleme mit der Ausfallsicherheit, mit denen die zu komplexe ISAPI-Schnitt-stelle zu kämpfen hatte. Aus diesem Grund stellen die systemeigenen IIS 7.0-Module eine besonders wichtige – und auch einfache und zuverlässige – Möglichkeit dar, um IIS zu erweitern.

IIS 7.0 bietet außerdem erstmals in der Geschichte der Internetinformationsdienste ein unverfälschtes und auf ASP.NET basierendes .NET-Erweiterbarkeitsmodell. Dies führt dazu, dass Entwickler einen besseren Zugang zur Serverentwicklung erhalten und Serverfeatures schneller erstellen können, sofern sie die leistungsfähigen Features von ASP.NET und dem .NET Framework nutzen. Dies wird durch die neue ASP.NET-Integrationsengine möglich, die dafür sorgt, dass aus dem einfachen ASP.NET-Anwen-dungsframework ein erstklassiger Erweiterbarkeitsmechanismus für IIS 7.0 wird.

Die Erweiterung von IIS mithilfe des .NET Frameworks ermöglicht es Ihnen als Serveradministrator, die IIS-Erweiterbarkeit an Anwendungsbesitzer zu delegieren, die auf dem Server über keine Administ-ratorrechte verfügen. Dies wird durch das auf CAS (Code Access Security, Codezugriffssicherheit) basierende ASP.NET-Hostingsmodel möglich, das Einschränkungen für die Codeausführung in ASP.NET-Anwendungen definiert, wenn diese für die teilweise Vertrauenswürdigkeit konfiguriert sind. Im Gegensatz zu systemeigenen Modulen, die mit allen Rechten des IIS-Arbeitsprozesses ausgeführt werden, kann die Ausführung verwalteter ASP.NET-Module mit eingeschränkten Rechten erfolgen, so dass sich die Module nicht negativ auf den Server selbst oder auf die anderen Anwendungen auswirken. IIS 7.0-Anwendungen können somit IIS-Features für den Server bereitstellen, ohne hierfür administ-rative Aktionen initiieren (z.B. die Installation von COM-Objekten oder ISAPI-Filtern) und die Sicher-heit des Servers gefährden zu müssen.

Tabelle 12.2 fasst die Unterschiede zwischen systemeigenen und verwalteten Modulen zusammen.

Tabelle 12.2 Systemeigene und verwaltete Module im Vergleich

Systemeigene Module Verwaltete Module

Entwickelt mit C++-Modul-API von IIS 7.0 ASP.NET-Modul-API, jede .NET-Sprache

Repräsentiert durch Win32-DLL .NET-Klasse in einer .NET-Assembly-DLL

Ausführungsgültigkeitsbereich IIS-Arbeitsprozess ASP.NET-Anwendungsdomäne

Ausführungsberechtigung IIS-Arbeitsprozessidentität IIS-Arbeitsprozessidentität, zusätzlich Einschränkungen durch die ASP.NET-Vertrauensebene



Die IIS 7.0-Konfiguration berücksichtigt Unterschiede zwischen systemeigenen und verwalteten Modulen. Außerdem ermöglicht sie es den Administratoren, die eingeschränkte Ausführung bei verwalteten Modulen zu nutzen, weil verwaltete Module für einzelne Anwendungen hinzugefügt werden können, indem sie zusammen mit den Anwendungsinhalten ein Paket bilden. Die anwendungsbasierte Bereitstellung von verwalteten Modulen lässt eine einfache xcopy-Bereitstellung von IIS-Anwendungen zu, da diese ihre eigenen IIS-Konfigurationen und -Module festlegen können.

Bereitstellungsmodell Global für den gesamten Server Global für den gesamten Server durch Nutzung des globalen .NET-Assemblycaches oder xcopy-Bereitstellung innerhalb einer bestimmten Anwendung

Bereitstellungsberechtigung Nur Administratoren Anwendungsbesitzer können die Module zusammen mit einer Anwendung bereitstellen

So funktioniert es: Die integrierte ASP.NET-PipelineMit dem von IIS 7.0 angebotenen vereinheitlichten Pipelinemodell können sowohl systemeigene Module, die unter Verwendung des nativen IIS 7.0-Erweiterbarkeitsmodels entwickelt wurden, als auch verwaltete Module, für deren Entwicklung das ASP.NET-Modulmodell genutzt wurde, an der Anforderungsver-arbeitung des Webservers teilnehmen (sofern sie im integrierten ASP.NET-Modus arbeiten). System-eigene und verwaltete Module können sich in alle Phasen der Anforderungsverarbeitung einbringen und mit einem gemeinsamen Satz systeminterner Anforderungs- und Antwortobjekte arbeiten.In der Praxis sind ASP.NET und IIS jedoch zwei gesonderte Softwareprodukte. Darüber hinaus ver-wendet der integrierte ASP.NET-Modus die ASP.NET-Standardschnittstellen, die für frühere IIS-Versionen verwendet wurden, um über das ASP.NET-Anwendungsframework Anforderungsverarbei-tungsdienste zur Verfügung zu stellen. Aber wie ist dann eine solch enge Verflechtung möglich?Die Antwort liefert das spezielle systemeigene Module ManagedEngine, das unter IIS 7.0 installiert wird, wenn eine Installation der Windows-Setup-Komponente (Windows Vista) bzw. des Rollendienstes (Windows Server 2008) .NET-Erweiterbarkeit erfolgt. Dieses Modul implementiert die Engine für den integrierten ASP.NET-Modus, die es der ASP.NET-Anforderungsverarbeitungspipeline ermög-licht, die IIS-Anforderungsverarbeitungspipeline zu überlagern, in der Rolle des Vermittlers Ereig-nisbenachrichtigungen zu behandeln und den notwendigen Anforderungsstatus weiterzuleiten. Dies alles geschieht, um die Pipelineintegration zu unterstützen. Dieses Modul ist dafür verantwortlich, in der Modul- und Handlerkonfiguration von IIS die Einträge für die verwalteten Module und Handler zu lesen und mit der neuen ASP.NET-Engineimplementierung von System.Web.dll zusammenzu-arbeiten, um die integrierte Pipeline einzurichten. Es ermöglicht somit den ASP.NET-Modulen und -Handlern, als IIS-Module und -Handler zu agieren.Wenn Sie somit in der IIS-Modulliste das Modul ManagedEngine sehen, sollten Sie ihm einen gewissen Respekt zollen – es ist wohl das komplexeste und leistungsfähigste Modul, das jemals für IIS 7.0 geschrieben wurde. Denken Sie außerdem daran, dass dieses Modul präsent sein muss, wenn Sie die integrierte Pipeline nutzen möchten und ASP.NET-Anwendungen in Anwendungspools ausgeführt werden sollen, die mit dem integrierten IIS 7.0-Modus arbeiten.Mike VolodarskyIIS-Kernserver Program Manager

Tabelle 12.2 Systemeigene und verwaltete Module im Vergleich (Fortsetzung)

Systemeigene Module Verwaltete Module



IIS 7.0 ermöglicht ebenfalls eine einheitliche Verwaltung von Modulen. Dabei spielt es keine Rolle, ob es sich um systemeigene oder verwaltete Module handelt. Die Administratorenen verwenden immer eine Standardvorgehensweise, um den Featuresatz zu verwalten. Später in diesem Abschnitt erfahren Sie, wie sich die Installationen von systemeigenen und verwalteten Modulen voneinander unter-scheiden. Außerdem werden Sie einige Standardverwaltungsaufgaben kennen lernen.

Module installierenDie Module, die unter Windows Vista oder Windows Server 2008 den IIS 7.0-Featuresatz bilden, können mithilfe des Windows-Setups installiert werden. Dank der modularen Architektur lässt Windows-Setup eine sehr spezifische Installation der IIS 7.0-Features zu – Sie können die meisten IIS 7.0-Module (zusammen mit allen unterstützenden Konfigurations- und Verwaltungsfeatures) separat installieren. Sie können außerdem den Rollendienst .NET-Erweiterbarkeit installieren, der für die Ausführung von ver-walteten ASP.NET-Modulen unter IIS 7.0 benötigt wird, oder den ASP.NET-Rollendienst, der ebenfalls alle verwalteten ASP.NET-Module und -Handler für die Ausführung von ASP.NET-Anwendungen installiert. Im fünften Kapitel erfahren Sie mehr über die Installation von IIS 7.0-Features.

Das Windows-Setup benutzt dieselben IIS 7.0-Konfigurations-APIs, mit denen Sie auf dem Server ein Drittanbietermodul manuell installieren können. Außerdem arbeitet das Windows-Setup mit dem Befehlszeilentool Appcmd.exe, um Modulinstallationen durchzuführen. Dies ist aber nur eine Möglichkeit, um unter IIS 7.0 Module zu installieren. Später in diesem Kapitel werden Sie einen Blick auf die gebräuchlichsten Installationsmöglichkeiten werfen, also auf den IIS-Manager und Appcmd.exe, und Sie werden sich mit der direkten Bearbeitung der Serverkonfiguration beschäftigen. Natürlich können Sie auch eine der programmatischen APIs benutzen, z.B. die .NET-API Microsoft.Web.Administ-ration, die COM-Konfigurationsobjekte von IIS 7.0 (aus einem C++-Programm oder Skript heraus) oder WMI. Sie haben die Wahl.

Systemeigene Module installierenUm ein systemeigenes Modul zu installieren, muss es in der Konfigurationsdatei applicationHost.config auf der Serverebene im Konfigurationsabschnitt system.webServer/globalModules registriert sein. Da nur Serveradministratoren auf diese Datei zugreifen können, erfordert die Installation systemeigener Module auf dem Server administrative Rechte. Dies ist so vorgesehenen – systemeigener Code, der in einem IIS-Arbeitsprozess ausgeführt wird, stellt immer ein potentielles Sicherheitsrisiko dar, weshalb sich die Administratoren sicher sein müssen, dass die Quelle des Moduls vertrauenswürdig ist.

Der Abschnitt globalModules enthält für jedes auf dem Server installierte systemeigene Modul einen Ein-trag, der den Modulnamen und das Modulabbild angibt, also den physikalischen Pfad zur Modul-DLL. <globalModules> <add name="UriCacheModule" image="%windir%\System32\inetsrv\cachuri.dll" /> <add name="FileCacheModule" image="%windir%\System32\inetsrv\cachfile.dll" /> <add name="TokenCacheModule" image="%windir%\System32\inetsrv\cachtokn.dll" /> <add name="HttpCacheModule" image="%windir%\System32\inetsrv\cachhttp.dll" /> <add name="StaticCompressionModule"



image="%windir%\System32\inetsrv\compstat.dll" /> <add name="DefaultDocumentModule" image="%windir%\System32\inetsrv\defdoc.dll" /> ... </globalModules>

Das Attribut image ist eine erweiterte Zeichenfolge, was bedeutet, dass sie Umgebungsvariablen ent-halten kann (wie dies bei Modulen, die vom Windows-Setup installiert wurden, der Fall ist). Dies wird auch empfohlen, um sicherzustellen, dass die Datei applicationHost.config portierbar bleibt und auf Server mit unterschiedlichen Systemlaufwerken kopiert werden kann.

Hinweis Die DLLs von systemeigenen Modulen sollten sich im lokalen Dateisystem des Servers und nicht am Ziel von Remotenetzwerkfreigaben befinden. Der Grund hierfür besteht darin, dass der Server versucht, die Module unter der Identität des Anwendungspools und nicht unter der Identität des authentifizierten Benutzers oder der konfigurierten UNC-Identität (Universal Naming Convention) zu laden. Diese Identitäten können in der Regel nicht auf Netzwerkfreigaben zugreifen.

Die Registrierung eines systemeigenen Moduls weist die IIS-Arbeitsprozesse in allen Anwendungs-pools an, die Modul-DLL zu laden. Der Konfigurationsabschnitt globalModules ist auch einer der wenigen Abschnitte, die eine Wiederverwendung von IIS-Arbeitsprozessen initiieren, sobald Änderungen erfolgen. Dies bedeutet, dass Sie neue Module installieren oder bereits vorhandene Module deinstal-lieren können und IIS automatisch auf diese Änderungen reagiert, so dass Sie nicht manuell dafür sorgen müssen, dass Anwendungspools wieder verwendet und IIS-Dienste neu gestartet werden oder IISRESET ausgeführt wird.

Hinweis Durch das Hinzufügen eines Moduls zu globalModule weisen Sie die IIS-Arbeitsprozesse an, die Modul-DLL zu laden. Dies allein führt jedoch nicht dazu, dass das Modul ausgeführt wird. Um dies zu erreichen, müssen Sie das Modul zusätzlich auf dem Server für eine bestimmte Anwendung aktivieren.

Nachdem das Modul installiert wurde, wird es von allen IIS-Arbeitsprozessen des Servers geladen. Leider ist es mit IIS 7.0 nicht möglich, systemeigene Module für einen bestimmten Anwendungspool zu installieren, so dass es keine einfache Möglichkeit gibt, ein systemeigenes Modul lediglich in einen bestimmten Anwendungspool und nicht in die anderen Pools zu laden.

Hinweis Dennoch ist es möglich, mit IIS 7.0 ausgewählte systemeigene Module in einen bestimmten Anwen-dungspool zu laden. Dazu werden für den Anwendungspoolnamen Vorbedingungen verwendet. Lesen Sie später in diesem Kapitel den Abschnitt »Modulvorbedingungen verstehen«, um weitere Informationen hierzu zu erhalten. Obwohl das Laden von systemeigenen Modulen auf diese Weise möglich ist, sollten Sie dieses Verfahren in der Regel nicht nutzen, da der damit einhergehende Verwaltungsaufwand sehr groß ist.

Das Laden des Moduls allein genügt jedoch nicht, damit das Modul ausgeführt wird. Es muss ebenfalls aktiviert werden, indem sein Name im Konfigurationsabschnitt system.webServer/modules aufgelistet wird. Dies ist ein wichtiges Merkmal, das eine flexiblere Kontrolle des aktivierten Modulsatzes ermöglicht. Im Gegensatz zum Abschnitt globalModules, der lediglich auf der Serverebene angegeben werden kann, ist es möglich, den Konfigurationsabschnitt modules auf der Anwendungsebene festzulegen, z.B. in der web.config-Datei des Anwendungsstamms. Jede Anwendung kann dann die aktivierten Module kontrollieren, die die auf die Anwendung bezogenen Anforderungen verarbeiten.



In der Regel wird ein systemeigenes Modul während seiner Installation sofort auf der Serverebene (in applicationHost.config) aktiviert, so dass es standardmäßig für alle Anwendungen des Servers aktiviert ist (mit Ausnahme der Anwendungen, die in ihrer Konfiguration das Modul explizit entfernen). Dies gilt für die meisten integrierten systemeigenen Module. <modules> <add name="HttpCacheModule" /> <add name="StaticCompressionModule" /> <add name="DefaultDocumentModule" /> ... <modules>

Ein systemeigenes Modul wird aktiviert, indem sein Name einfach in der Auflistung modules aufgeführt wird.

Hinweis Wenn sich der Abschnitt modules ändert, muss keine erzwungene Wiederverwendung von IIS-Arbeits-prozessen erfolgen. Stattdessen reagieren die Prozesse automatisch auf die Änderungen und wenden den resul-tierenden Modulsatz automatisch auf alle folgenden Anforderungen an. ASP.NET-Anwendungen, deren Modul-konfiguration sich ändert, werden jedoch neu gestartet.

Systemeigene Module deinstallieren

Vorsicht Bevor Sie Module entfernen, sollten Sie darüber nachdenken, welche Auswirkungen dies auf die Sicher-heit und Leistung Ihres Servers haben könnte. Der Abschnitt »Webservermodule sichern«, den Sie später in diesem Kapitel finden, behandelt diese Auswirkungen ausführlich.

Um ein systemeigenes Modul zu deinstallieren, müssen Sie den entsprechenden Moduleintrag aus der globalModules-Liste entfernen. Dies verhindert, dass das Modul in die IIS-Arbeitsprozesse des Servers geladen wird. Das Entfernen des Moduls aus globalModules führt dazu, dass alle IIS-Arbeitsprozesse eine ordnungsgemäße Wiederverwendung initiieren.

Wenn außerdem ein systemeigenes Modul aus der Liste globalModules entfernt wird, müssen die Verweise darauf, die sich in der Liste modules befinden, ebenfalls entfernt werden. Andernfalls generieren alle an den Server oder eine Anwendung gerichteten Anforderungen, die normalerweise zu einer Aktivierung

Einblicke in globale WebserverereignisseWenn Sie sich den Abschnitt globalModules genau ansehen, werden Sie feststellen, dass einige Module, zum Beispiel TokenCacheModule, zwar an dieser Stelle, aber nicht in der modules-Liste aufgeführt sind. Bedeutet dies, dass diese Module standardmäßig deaktiviert sind? Nein, nicht ganz.

Systemeigene Module, die in einen IIS-Arbeitsprozess geladen wurden, können auf globale Server-ereignisse reagieren. Dabei handelt es sich um Ereignisse, die nicht mit der Anforderungsverarbei-tung verknüpft sind. Diese Ereignisse ermöglichen es den systemeigenen Modulen, auf der Arbeits-prozessebene bestimmte Serverfunktionen zu erweitern, z.B. indem sie die Möglichkeit bieten, Anmeldetokens zur Erzielung einer besseren Leistung zwischenzuspeichern.

Systemeigene Module, die eine solche globale Funktionalität bieten, müssen in der modules-Liste nicht aufgeführt sein. Sollen sie ihre Funktionalität zur Verfügung stellen, genügt es, wenn sie in einen Arbeitsprozess geladen werden. Eine Anforderungsverarbeitungfunktionalität kann jedoch ausschließlich von Modulen geboten werden, die in der modules-Liste aufgelistet sind.



des fehlenden Moduls führen würden, einen HTTP 500-Fehler (Interner Serverfehler). Dieser Fehler tritt erst dann nicht mehr auf, wenn der entsprechenden Moduleintrag entfernt wurde. In der Regel sollten Sie die Moduleinträge gleichzeitig aus globalModules und modules entfernen. Wenn Sie dies jedoch in zwei separate Schritte aufteilen, führt die Änderung des Abschnitts modules zu keiner Initiierung der Arbeitsprozesswiederverwendung – IIS reagiert automatisch auf diese Änderung, indem es jede betroffene Anwendung neu startet. Achten Sie darauf, eine Konfigurationssicherung für den Fall durchzuführen, dass Sie die ursprüngliche Konfiguration später wiederherstellen müssen.

Wenn Sie ein systemeigenes Modul deinstallieren, dass ein Bestandteil des IIS 7.0-Featuresatzes ist, sollten Sie stattdessen über das Windows-Setup die entsprechende IIS-Komponente (Windows Vista) oder den entsprechenden Rollendienst (Windows Server 2008) deinstallieren. Dies hat den Vorteil, dass auch die Binärdateien des Moduls und die entsprechenden Konfigurationskomponenten entfernt werden. Außerdem wird der Windows-Setup-Infrastruktur angezeigt, dass das entsprechende Feature nicht installiert ist. Die Binärdateien bleiben im Installationscache des Betriebssystems erhalten, wo aus-schließlich das TrustedInstaller-Subsystem des Betriebssystems darauf zugreifen kann. Dies gewähr-leistet, dass Sie diese Module später neu installieren können und dass alle erforderlichen Patches auf diese Binärdateien angewendet werden, was selbst dann geschieht, wenn diese Patches auf Ihrem Server nicht installiert sind.

Vorsicht Sie sollten integrierte IIS 7.0-Module nicht manuell entfernen. Benutzen Sie stattdessen das Windows-Setup, um das entsprechende Feature oder den jeweiligen Rollendienst zu deinstallieren.

Wenn ein benutzerdefiniertes Modul deinstalliert wird und die darauf folgende Wiederverwendung aller IIS-Arbeitsprozesse abgeschlossen ist, können Sie bei Bedarf die Binärdateien des Moduls vom Com-puter entfernen.

Lesen Sie später in diesem Kapitel die Abschnitte »Verwaltete Module mit dem IIS-Manager instal-lieren und verwalten« und »Verwaltete Module mit Appcmd installieren und verwalten«, um eine ausführliche Anleitung zur Deinstallation eines systemeigenen Moduls mithilfe des IIS-Managers oder des Befehlszeilentools Appcmd zu erhalten.

Verwaltete Module installierenVerwaltete Module, die unter Verwendung der ASP.NET-APIs entwickelt wurden, müssen nicht global auf dem Server installiert werden. Stattdessen müssen Sie – ähnlich wie klassische ASP.NET-Anwen-dungen früherer IIS-Versionen – lediglich in der Konfiguration der Anwendung, die die Module benötigt, aktiviert werden. Dies ermöglicht die einfache xcopy-Bereitstellung von Anwendungen, die verwaltete Module enthalten, da diese im Gegensatz zu den systemeigenen Modulen keine admi-nistrativen Rechte für die Bereitstellung erfordern.

Verwaltete Module sind somit besonders für solche Situationen geeignet, in denen der Anwendungs-administrator über keine administrativen Rechte für den Server verfügt, z.B. bei Shared Hosting-servern oder Abteilungsservern. Solche Anwendungen können nun Webserverfeatures bereitstellen, ohne den Serveradministrator bitten zu müssen, eine globale und vertrauenswürdige Komponente zu installieren, was oft nicht möglich ist. In diesen Umgebungen kann der Serveradministrator die Ausführung verwalteter Module kontrollieren, indem er die Vertrauenswürdigkeit von ASP.NET-Anwendungen einschränkt. Später in diesem Kapitel behandelt der Abschnitt »Webservermodule sichern« ausführlich die Beschränkung der Ausführung von verwalteten Modulen. Dort erhalten Sie außerdem Informationen zum Einschränken der Modulerweiterbarkeit.



Hinweis Die Ausführung verwalteter Module erfordert die Installation der Windows-Setup-Komponente (Windows Vista) bzw. des Rollendienstes (Windows Server 2008) .NET-Erweiterbarkeit. Dadurch wird das Modul ManagedEngine installiert, das es verwalteten Modulen ermöglicht, in Anwendungspools ausgeführt zu werden, die im integrierten Modus arbeiten.

Die Installation der Setup-Komponente/des Rollendienstes ASP.NET führt dazu, dass die Komponente .NET-Erweiterbarkeit installiert wird. Außerdem werden die vom ASP.NET-Framework verwendeten Module und Handler-zuordnungen hinzugefügt. Des Weiteren werden die klassischen ASP.NET-Handlerzuordnungen installiert, die dafür sorgen, dass Anwendungspools, die im klassischen Integrationsmodus arbeiten, ASP.NET mithilfe des alten ASPNET_ISAPI.dll-Integrationsmechanismus ausführen können.

Um ein verwaltetes Modul zu installieren, muss das Modul lediglich dem Konfigurationsabschnitt modules hinzugefügt werden. Dies ist derselbe Abschnitt, der auch installierte systemeigene Module aktiviert. Verwaltete Module müssen jedoch nicht im Konfigurationsabschnitt globalModules aufgelistet werden. Der Abschnitt modules stellt die aktivierten Module somit einheitlich dar, und zwar unabhängig davon, ob sie systemeigen oder verwaltet sind. Da dieser Konfigurationsabschnitt nach unten bis zur Anwendungsebene delegiert werden kann, ist es möglich, dass eine Anwendung alle aktivierten Module (systemeigen oder verwaltet) mithilfe der eigenen modules-Konfiguration festlegen kann. Nachfolgend finden Sie ein voll-ständiges Beispiel für den modules-Konfigurationsabschnitt der Serverebene, nachdem das ASP.NET-Feature installiert wurde: <modules> <add name="HttpCacheModule" /> <add name="StaticCompressionModule" /> <add name="DefaultDocumentModule" /> <add name="DirectoryListingModule" /> ... <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="managedHandler" /> <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" /> <add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" /> ... </modules>

Wie Sie sehen, enthält dieser Abschnitt sowohl systemeigene Module, die einfach durch das name-Attribut identifiziert werden, als auch verwaltete Module, die zusätzlich ein type-Attribut angeben. Der Server ermittelt für jede Anwendung die Assemblys zu den aktivierten Modulen, indem er im Abschnitt globalModules die Namen der systemeigenen Module abruft. Bei verwalteten Modulen lädt er direkt den jeweiligen .NET-Typ. Der Typ ist der vollqualifizierte .NET-Typname, der sich auf die Klasse bezieht, die dieses Modul implementiert, und der in eine Assembly aufgelöst wird, die Teil des Anwendungs-pakets oder im GAC (Globaler Assemblycache) des Computers installiert ist.

Wichtig ASP.NET-Anwendungen, die im Konfigurationsabschnitt system.web/httpModules Module und im Konfi-gurationsabschnitt system.web/httpHandlers ASP.NET-Handlerzuordnungen definieren, müssen ihre Konfigurationen migrieren, so dass die entsprechenden IIS-Konfigurationsabschnitte system.webServer/modules und system.webServer/handlers daraus werden. Dies ist notwendig, um im integrierten Modus arbeiten zu können. Der Server erinnert Sie mit einem HTTP 500-Fehler an diese Bedingung, wenn Sie versuchen, eine noch nicht migrierte Anwendung im



integrierten Modus auszuführen. Sie können eine Anwendung einfach mit dem Befehl Appcmd Migrate Config ApplicationPath migrieren. Um zu erfahren, weshalb dies notwendig ist, und um die Optionen kennen zu lernen, die Ihnen für die Ausführung alter ASP.NET-Anwendungen zur Verfügung stehen, lesen Sie bitte das elfte Kapitel, »Hosting von Anwendungsentwicklungsframeworks«.

Verwaltete Module enthaltende Assemblys bereitstellenVerwaltete Module sind Klassen, die in .NET-Assemblys implementiert sind. Um eine delegierte Bereit-stellung von verwalteten Modulen zu ermöglichen, bietet der Server verschiedene Optionen für die Bereitstellung der Modulassemblys an, so dass diese sowohl global auf dem Server als auch nur für eine bestimmte Anwendung hinzugefügt werden können. Diese Optionen sind in Tabelle 12.3 beschrieben.

Die Modulassembly auf der Serverebene bereitstellen Soll ein Modul auf dem Server global für alle Anwendungen installiert werden, muss es für den GAC (Globaler Assemblycache) des Computers registriert werden. Bevor die verwaltete Assembly vom GAC bereitgestellt werden kann, muss sie vom Entwickler verstärkt signiert werden (weitere Informationen zu verstärkt signierten .NET-Assemblies finden Sie unter http://msdn2.microsoft.com/en-us/library/xc31ft41.aspx). Microsoft Visual Studio vereinfacht den Signierungsprozess. Danach kann die verwaltete Assembly mit dem folgenden Befehl zum GAC hinzugefügt werden:gacutil.exe /if AssemblyPath

Hinweis Das Befehlszeilentool gacutil.exe ist in der .NET Framework-Laufzeitinstallation, die Bestandteil des Betriebssystems ist, nicht enthalten, so dass Sie das .NET Framework SDK herunterladen müssen, um es zu erhal-ten. Sobald Sie es heruntergeladen haben, können Sie es auf andere Computer kopieren, um es dort zu benutzen.

Nachdem Ihre Assembly dem GAC hinzugefügt wurde, können Sie alle darin enthaltenen Module dem modules-Abschnitt der Serverebene hinzufügen, indem Sie die entsprechenden Modultypen angeben. Der Typname muss vollqualifiziert sein. Dies bedeutet, dass er den vollständigen Namespacepfad zur Klasse enthalten muss (z.B. System.Web.Security.FormsAuthenticationModule). Da ASP.NET für die Generierung Ihres Moduls die Assembly lokalisieren muss, die diesen Typ enthält, muss die Assembly entweder in der Konfigurationsauflistung system.web/compilation/assemblies aufgeführt oder unter Verwendung der Notation für starke Namen im Typnamen enthalten sein. Das nachfolgende Beispiel zeigt den starken Namen des integrierten Moduls FormsAuthentication:System.Web.Security.FormsAuthenticationModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=x86

Tabelle 12.3 Bereitstellungsoptionen für verwaltete Module

Bereitstellungsoption Speicherort der Assembly Ort der Modulregistrierung

Server GAC (Globaler Assemblycache) modules-Abschnitt der Serverebene in applica-tionHost.config

Anwendung Assembly im /BIN-Verzeichnis einer Anwendung

ODER

Quellcode im /App_Code-Anwendungsverzeichnis

modules-Abschnitt der Anwendungsebene in der web.config-Datei des Anwendungsstamms



Hinweis Sie erhalten den Assemblyteil des starken Namens, indem Sie mit dem Tool gacutil.exe arbeiten, das Sie bereits für die Installation der Assembly im GAC (Globaler Assemblycache) verwendet haben. Lassen Sie den Befehl gacutil.exe /l AssemblyName ausführen, damit der starke Name der Assembly angezeigt wird. Den Assemblynamen müssen Sie angeben, die Angabe der verbleibenden Abschnitte des starken Assemblynamens ist nicht notwendig. ASP.NET versucht dann, eine Assembly basierend auf den von Ihnen angegebenen Attributen zu finden.

Sie fragen sich möglicherweise, weshalb die Standardmoduleinträge für ASP.NET-Module keine starken Namen, sondern vollqualifizierte Typnamen angeben. Der Grund hierfür besteht darin, dass die über-geordnete Assembly dieser Module, System.Web.dll, so konfiguriert ist, dass sie von ASP.NET-Anwen-dungen automatisch vorab geladen wird (da sie in der web.config-Stammdatei des .NET Frameworks in der Konfigurationsauflistung system.web/compilation/assemblies aufgeführt ist). ASP.NET kann deshalb die Typen der integrierten ASP.NET-Module lokalisieren, indem es die vorab geladenen Assemblies durch-sucht. Die Angabe der Assemblysignatur in der Modultypzeichenfolge ist hierfür nicht erforderlich.

Die Modulassembly zusammen mit der Anwendung bereitstellen Soll ein Modul nur in einer bestimmten Anwendung verfügbar sein, kann es zusammen mit der Anwendung per xcopy bereit-gestellt werden. Eine globale Registrierung auf dem Server ist nicht notwendig. In diesem Fall kann der Anwendungsbesitzer zwischen zwei Möglichkeiten wählen, um das Modul zur Verfügung zu stellen: als kompilierte .NET-Assembly-DLL im /BIN-Unterverzeichnis des Anwendungsstamms oder als Quellcode im /App_Code-Unterverzeichnis des Anwendungsstamms.

Hinweis Es ist nicht notwendig, die Assembly im /BIN-Unterverzeichnis der Anwendung zu signieren.

Das /App_Code-Bereitstellungsmodell ist mehr für Entwicklungs- und Testumgebungen geeignet, da es die Bearbeitung des Modulquellcodes auf dem Live-Server ohne Neukompilierung der Modul-DLL ermöglicht. Das /BIN-Bereitstellungsmodell wird für Produktionsserver empfohlen, da hierfür keine Laufzeitkompilierung der Assembly erforderlich ist. Außerdem ist dies eine kompaktere Möglichkeit als das Quellcodeverfahren, wenn es darum geht, eine große Codebasis bereitzustellen.

Da der zusammen mit einer Anwendung bereitgestellte Modultyp nur in dieser Anwendung verfügbar ist, kann er auch nur dort verwendet werden (im Gegensatz zu Assemblies im globalen Assemblycache, die für alle Anwendungen des Servers verfügbar sind). Um das Modul hinzuzufügen, müssen Sie lediglich dem modules-Konfigurationsabschnitt der web.config-Datei des Anwendungsstamms den vollqualifizierten Typ hinzufügen. Bei Modulen, deren Assembly sich im /BIN-Verzeichnis befinden, können Sie optional den Assemblynamen angeben, obwohl dies nicht notwendig ist – ASP.NET lädt standardmäßig alle /BIN-Assemblies vorab. Dies gilt auch für Module, die in Form von Quellcode im /App_Code-Verzeichnis bereitgestellt werden, da AST .NET diese automatisch kompilierte und lädt.

Die gemeinsame Verwahrung von verwalteten IIS 7.0-Modulen und Anwendungen am selben Ort bietet die außerordentliche Möglichkeit, in sich geschlossene Anwendungen zu erstellen, die per xcopy auf einem Server bereitgestellt und sofort eingesetzt werden können, ohne eine Funktionalität auf dem Server global installieren zu müssen.

Lesen Sie später in diesem Kapitel auch den Abschnitt »Einschränken der Erweiterbarkeit«, um die Sicherheitsauswirkungen der Delegierung von verwalteten Modulen zu verstehen und zu erfahren, wie diese kontrolliert wird.



Verwaltete Module deinstallieren

Vorsicht Bevor Sie Module entfernen, sollten Sie wissen, wie sich diese Aktion auf die Sicherheit und die Leistung des Servers auswirken kann. Weitere Informationen hierzu finden Sie später in diesem Kapitel im Abschnitt »Web-servermodule sichern«.

Im Gegensatz zu systemeigenen Modulen können Sie verwaltete Module installieren, indem Sie sie einfach zur modules-Liste hinzufügen. Die Deinstallation verwalteter Module ist mit deren Deaktivierung identisch und erfordert nur einen Schritt.

Verwaltete Module, die als Bestandteil der ASP.NET-Installation installiert wurden, können nicht einzeln mithilfe des Windows-Setups (Windows Vista) oder Server-Managers (Windows Server 2008) deinstalliert werden. Wenn Sie somit eines dieser Module entfernen möchten, müssen Sie dies manuell tun, indem Sie den entsprechenden Eintrag aus dem modules-Abschnitt entfernen. Achten Sie darauf, eine Konfigurationssicherung für den Fall durchzuführen, dass Sie die ursprüngliche Konfiguration später wiederherstellen müssen.

Später in diesem Kapitel finden Sie den Abschnitt »Aktivierte Module festlegen«, der das Entfernen verwalteter Module beschreibt. Werfen Sie auch einen Blick auf die Abschnitte »Verwaltete Module mit dem IIS-Manager installieren und verwalten« sowie »Verwaltete Module mit Appcmd installieren und verwalten«, die Sie ebenfalls später in diesem Kapitel finden, um zu erfahren, wie Sie den IIS-Manager oder das Befehlszeilentool Appcmd benutzen, um verwaltete Module zu entfernen.

Modulvorbedingungen verstehenDie modulare Architektur von IIS 7.0 ist darauf angewiesen, dass festgelegt werden kann, welche Module auf dem Server und auf der Anwendungsebene installiert und aktiviert werden sollen. Manch-mal genügt es nicht, diese Entscheidung aufgrund einer statischen Konfiguration zu treffen, so dass der Entschluss, ein Modul in einem bestimmten Szenario zu verwenden, von Faktoren abhängig sein kann, die nur zur Laufzeit gegeben sind. Um diese Funktionalität zu unterstützen, führt IIS 7.0 das Konzept der Vorbedingungen ein. Dabei handelt es sich um konfigurierte Bedingungen, die der Server zur Laufzeit auswertet, um zu ermitteln, ob ein bestimmtes Modul verwendet werden soll.

Die folgenden Arten von Vorbedingungen werden unterstützt:

� Vorbedingungen zum Laden von Modulen Diese Vorbedingungen können im Konfigurations-abschnitt globalModules mit den installierten systemeigenen Modulen verknüpft sein, und sie bestimmen, ob ein bestimmtes Modul von einem Arbeitsprozess bei dessen Start geladen wird. Wenn die Auswertung einer Vorbedingung ergibt, dass diese nicht erfüllt ist, wird das Modul nicht in den Arbeitsprozess geladen. Diese Vorbedingungen können ebenfalls im Konfigurationsabschnitt isapiFilters verwendet werden, um das Laden von ISAPI-Filtern zu kontrollieren.

� Vorbedingungen zum Aktivieren von Modulen Diese Vorbedingungen können im Konfigura-tionsabschnitt modules mit den aktivierten Modulen verknüpft sein und sie bestimmen, ob ein bestimmtes Modul für eine bestimmte Anwendung (oder Anforderung) aktiviert ist. Wenn die Auswertung einer Vorbedingung ergibt, dass diese nicht erfüllt ist, wird das Modul nicht ausgeführt.

� Vorbedingungen für Handlerzuordnungen Diese Vorbedingungen können im Konfigurations-abschnitt handlers mit den Handlerzuordnungen verknüpft sein und sie bestimmen, ob beim Zuordnen von Anforderungen zu Handlern eine bestimmte Handlerzuordnung berücksichtigt werden soll. Wenn die Auswertung einer Vorbedingung ergibt, dass diese nicht erfüllt ist, wird die Handlerzuordnung ignoriert.



In all diesen Fällen können mehrere Vorbedingungszeichenfolgen angegeben werden. Der Konfigurations-eintrag kommt dann zum Einsatz, wenn alle Vorbedingungen erfüllt sind. Wenn eine der Vorbedingungen nicht erfüllt ist, wird das Modul abhängig davon, in welchem Rahmen die Vorbedingung verwendet wird, nicht geladen, nicht aktiviert oder die Handlerzuordnung wird nicht berücksichtigt. Nachfolgend ist ein Beispiel für das ASP.NET-Setup aufgeführt, das Vorbedingungen nutzt, um das systemeigene Modul ManagedEngine nur in solche Anwendungspools zu laden, die im integrierten Modus arbeiten, Frame-work-Version 2.0 ausführen und für die Ausführung im 32-Bit-Modus konfiguriert sind:<globalModules> … <add name="ManagedEngine" image="%windir%\Microsoft.NET\Framework\v2.0.50727\webengine.dll" preCondition="integratedMode,runtimeVersionv2.0,bitness32" /> </globalModules>

Tabelle 12.4 führt die unterstützten Vorbedingungszeichenfolgen auf und nennt die Szenarien, in denen die Vorbedingungen genutzt werden können.

Die Vorbedingungen bitness32 und bitness64 treffen eine Auswahl basierend auf der Bitness des Arbeits-prozesses und können verwendet werden, um Module selektiv in 32-Bit- oder 64-Bit-Anwendungspools zu laden. Bei gemischten 32/64-Bit-IIS-Umgebungen kann es notwendig sein, systemeigene 32-Bit-Module ausschließlich in 32-Bit-Anwendungspools zu laden, weil IIS die nativen 32-Bit-DLLs nicht in einen 64-Bit-Arbeitsprozess laden kann. Deshalb sollten systemeigene 32-Bit-Module die bitness32-Vorbedingung konfigurieren, die dafür sorgt, dass diese Module ausschließlich in 32-Bit-Anwendungs-pools geladen werden. Weitere Informationen zur Ausführung von IIS im gemischten 32/64-Bit-Modus erhalten Sie später in diesem Kapitel im Abschnitt »Module in x64-Umgebungen installieren«.

Die Vorbedingungen classicMode und integratedMode treffen eine Auswahl basierend auf dem konfi-gurierten managedPipelineMode-Attribut des jeweiligen Anwendungspools. Zusammen mit der run-timeVersion-Vorbedingung bieten sie eine Basis für die ASP.NET-Versionsverwaltung unter IIS 7.0. Sie

Tabelle 12.4 Vorbedingungszeichenfolgen

Vorbedingung Anwendbar auf

bitness32, bitness64

Trifft eine Auswahl basierend auf der Bitness des Anwendungspools

globalModules, isapiFilters, modules, handlers

classicMode, integratedMode

Trifft eine Auswahl basierend auf dem konfigurierten verwalteten Pipeline- modus des Anwendungspools


runtimeVersionv1.1, runtimeVersionv2.0

Trifft eine Auswahl basierend auf der konfigurierten .NET-Laufzeitversion des Anwendungspools


appPoolName=Name, appPoolName!=Name

Trifft eine Auswahl basierend auf dem Anwendungspoolnamen; diese Vorbe-dingung kann verwendet werden, um ein systemeigenes Modul selektiv in einen bestimmten Anwendungspool zu laden


managedHandler

Trifft eine Auswahl basierend auf Zuordnungen verwalteter Handler

nur modules



ermöglichen außerdem die Auswahl der richtigen ASP.NET-Handlerzuordnungen, die abhängig vom Integrationsmodus des Anwendungspools getroffen wird. In Anwendungspools, die entweder den klassischen ASP.NET-Integrationsmodus oder eine .NET-Version verwenden, die keine direkte Integ-ration unterstützt, setzt IIS 7.0 alte auf ISAPI basierende Handlerzuordnungen für ASP.NET ein. Diese beiden Arten von Handlerzuordnungen werden auf der Serverebene konfiguriert und sie verwenden die Vorbedingungen classicMode/integratedMode und runtimeVersion, um die richtigen Handlerzuordnungen basierend auf dem Pipelinemodus und der Framework-Version des Anwendungspools automatisch auszuwählen.

Sie können die Vorbedingung applicationPoolName nutzen, um Module und Handlerzuordnungen für einen bestimmten Anwendungspool selektiv zu laden bzw. zu aktivieren. Es gibt einen IIS 7.0-Mechanismus, mit dem es möglich ist, bestimmte benutzerdefinierte Szenarien primär auf Shared Webhostingsservern zu realisieren. IIS 7.0 setzt diesen Mechanismus jedoch standardmäßig nicht ein.Schließlich sorgt die Vorbedingung managedHandler dafür, dass Module nur für Anforderungen aktiviert werden, die sich auf ASP.NET-Handler beziehen. Für ASP.NET-Anwendungen, die im integrierten Modus arbeiten, aktiviert IIS 7.0 die Ausführung von verwalteten Modulen für alle Anforderungen, und zwar unabhängig davon, ob diese Anforderungen ASP.NET-Handlern zugeordnet sind oder nicht. Aller-dings verwenden alle ASP.NET-Module standardmäßig bereits die Vorbedingung managedHandler, damit sie nur für solche Anforderungen ausgeführt werden, die sich auf verwaltete Handler beziehen. Deshalb kann die Erstellung der ASP.NET-Anwendungsdomäne (appdomain) hinausgezögert werden, bis die erste auf einen ASP.NET-Handler bezogene Anforderung eingeht. Die managedHandler-Vorbedingung kann für verwaltete und systemeigene Module entfernt werden, damit diese für alle Inhaltstypen ausgeführt werden. Um beispielsweise zuzulassen, dass die formularbasierte ASP.NET-Authentifizierung für alle Siteinhalte erfolgt, müssen Sie die managedHandler-Vorbedingung für das FormsAuthentication-Modul entfernen. Weitere Informationen hierzu erhalten Sie später in diesem Kapitel im Abschnitt »Verwaltete Module für alle Anforderungen ausführen lassen«.Vorbedingungen lösen unter IIS 7.0 viele wichtige Probleme. Sie können jedoch auch die Verwaltungs-komplexität steigern. Wenn sie falsch konfiguriert sind, können sie außerdem zu einem unerwarteten Verhalten führen. Das größte Problem, das in Verbindung mit Vorbedingungen auftreten kann, wird durch solche Vorbedingungen verursacht, die verhindern, dass Module geladen oder aktiviert oder Handlerzuordnungen verwendet werden. Das Resultat kann eine fehlende Funktionalität sein. Obwohl die Module bzw. Handlerzuordnungen präsent sind, können die jeweiligen Vorbedingungen zu Inak-tivität führen. Diese Probleme sind schwer zu diagnostizieren, da sich eine fehlende Funktionalität nicht immer in Fehlern manifestiert.Ein anderes übliches Problem ist die Vorbedingungsinkonsistenz, bei der die betroffene Konfiguration inkorrekte Vorbedingungen aufweist, die zu Konfigurationsfehlern führen. Wenn ein systemeigenes Modul beispielsweise die auf das Laden bezogene Vorbedingung bitness32 definiert, der entsprechende Aktivierungseintrag in der modules-Liste dies aber nicht tut, generieren die an die 64-Bit-Anwendungs-pools gerichteten Anforderungen einen auf ein ungültiges Modul verweisenden Fehler, da das aktivierte Modul nicht geladen wurde. Wenn ähnlich hierzu eine Handlerzuordnung auf ein Modul verweist, dessen auf die Aktivierung bezogene Vorbedingung in der modules-Liste die Aktivierung des Moduls verhindert, werden Anforderungen, auf die diese Handlerzuordnung zutrifft, mit einem Fehler konfrontiert.Um diese Probleme zu vermeiden, sollten Sie sich immer in Erinnerung rufen, dass mithilfe von Vorbe-dingungen primär der Einsatz von Modulen/Handlerzuordnungen verhindert werden soll, und zwar in solchen Situationen, in denen diese Komponenten Probleme verursachen würden. Achten Sie darauf, dass Vorbedingungen die Verfügbarkeit eines Moduls nicht einschränken, wenn es benötigt wird.



Denken Sie ebenfalls an die Beziehungen zwischen den verschiedenen Konfigurationsabschnitten, in denen Vorbedingungen definiert sind. Die mithilfe von Vorbedingungen definierten Einschränkungen müssen von den Vorbedingungen zum Laden, über die Aktivierungsvorbedingungen bis hin zu den Vorbedingungen für die Handlerzuordnungen eines Moduls eine Kette bilden. Wenn beispielsweise in globalModules eine Vorbedingung zum Laden auf bitness32 gesetzt ist, muss die Aktivierungsvorbedingung des entsprechenden Moduleintrags im modules-Abschnitt mindestens dieselbe Vorbedingung aufweisen. Wenn das Modul in einer Handlerzuordnung der handlers-Konfiguration referenziert wird, muss auch die Vorbedingung dieses Eintrags mindestens die Vorbedingungszeichenfolge des entsprechenden modules-Eintrags enthalten (der wiederum mindestens die Vorbedingung des entsprechenden globalModules-Eintrags enthalten muss).

Module in x64-Umgebungen installierenWenn IIS 7.0 für eine 64-Bit-Version des Betriebssystems installiert wird, arbeitet es standardmäßig im nativen 64-Bit-Modus. Dies bedeutet, dass alle Anwendungspools native 64-Bit-Arbeitsprozesse erzeugen und 64-Bit-Versionen der IIS-Kernenginekomponenten und -Module laden. Wenn jedoch IIS 7.0 den Anwendungspools erlaubt, den 32 Bit-Emulationsmodus namens wow64 zu nutzen, unterstützt es sowohl native 64-Bit- als auch 32-Bit-Anwendungen. Im Gegensatz zu IIS 6.0, das ebenfalls die Möglichkeit bietet, mit wow64 zu arbeiten, kann die Bittiefe bei IIS 7.0 für jeden Anwendungspool separat konfiguriert werden, weshalb es möglich ist, auf demselben Server native 64-Bit- und 32-Bit-Anwendungen Seite an Seite zu hosten.

Jeder Anwendungspool, dessen enable32BitAppOnWin64-Eigenschaft auf true gesetzt ist, erzeugt 32-Bit-Arbeitsprozesse und lädt die 32-Bit-Versionen des IIS-Kerns und der Module. Dies ist möglich, weil das IIS-Setup für 64-Bit-Betriebssysteme sowohl die 64-Bit- als auch die 32-Bit-Versionen aller IIS-Komponenten und -Module installiert – die nativen 64-Bit-Versionen werden im Standardverzeichnis %windir%\System32\Inetsrv gespeichert, und die 32-Bit-Versionen befinden sich im Verzeichnis %windir%\Syswow64\Inetsrv. Wenn IIS zur Laufzeit versucht, Module, die sich im Verzeichnis %windir%\System32\Inetsrv befinden, in die 32-Bit-Version eines wow64-Arbeitsprozesses zu laden, sorgt das Umleitungsfeature des wow64-Dateisystems automatisch dafür, dass der Dateizugriff zum \Syswow64-Verzeichnis umgeleitet wird, wo sich die 32-Bit-Versionen der DLLs befinden.

Dieser Mechanismus ermöglicht es den im system32-Verzeichnis installierten IIS- oder Drittanbieter-modulen, 32-Bit-Versionen im \Syswow64-Verzeichnis zur Verfügung zu stellen und die korrekte Version abhängig von der Bitness des Arbeitsprozesses automatisch zu laden.

Der Grund dafür, dass es gemischte 64-Bit- und 32-Bit-Umgebungen gibt, besteht darin, dass bestimmte Funktionen als 64-Bit-Versionen nicht verfügbar sind, so dass die entsprechenden Arbeitsprozesse im 32-Bit-Modus arbeiten müssen. Dies ist oft bei ASP-Anwendungen notwendig, die prozessinterne 32-Bit-Versionen von COM-Komponenten, 32-Bit-ISAPI-Filter oder systemeigene 32-Bit-Module aufrufen. Ähnlich hierzu gibt es Komponenten, die nur als 64-Bit-Versionen verfügbar sind und somit nicht in 32-Bit-Arbeitsprozessen zulässig sind. Um ein solches Szenario zu unterstützen, müssen Sie system-eigene Module, ISAPI-Filter und ISAPI-Erweiterungen so installieren können, dass IIS niemals versucht, eine 32-Bit-Komponente in einen 64-Bit-Arbeitsprozess und umgekehrt zu laden. IIS 7.0 unterstützt dies über die Vorbedingung für die Bitness (lesen Sie dazu auch früher in diesem Kapitel den Abschnitt »Modulvorbedingungen verstehen«), mit der systemeigene Module, ISAPI-Filter und Handlerzuord-nungen anzeigen können, ob sie ausschließlich in 32-Bit- oder 64-Bit-Anwendungspools verfügbar sind.



Handlerzuordnungen, die Anforderungen der 32-Bit-Version der ASP.NET-ISAPI zuordnen, benutzen beispielsweise die Vorbedingung bitness32, um sicherzustellen, dass sie ausschließlich innerhalb von 32-Bit-Arbeitsprozessen verwendet werden.<handlers accessPolicy="Read, Script"> <add name="PageHandlerFactory-ISAPI-2.0" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0" /> … </handlers>

Die 64-Bit-Version des .NET Frameworks registriert dieselbe Zuordnung auch für die 64-Bit-Version von aspnet_isapi.dll. Diese Zuordnung verwendet die Vorbedingung bitness64, so dass sie nur in 64-Bit-Arbeitsprozessen zum Einsatz kommt.

Die Verwendung der Vorbedingungen bitness32 und bitness64 trägt somit dazu bei, dass systemeigene Module, ISAPI-Filter und ISAPI-Erweiterungen, die in der Handlerzuordnungskonfiguration ange-geben sind, direkt auf 64-Bit- oder 32-Bit-Anwendungspools abzielen können, ohne den Umleitungs-mechanismus des Dateisystems nutzen zu müssen.

Allgemeine ModulverwaltungsaufgabenIIS 7.0 ermöglicht Ihnen nicht die Auswahl der auf dem Server zu installierenden Module, sondern Sie können auch angeben, welche Module auf dem Server und selbst für eine bestimmte Anwendung aktiviert werden sollen. Darüber hinaus müssen Sie bisweilen auch andere Aspekte der Modul-operation konfigurieren, zum Beispiel die relative Modulreihenfolge oder die speziellen Szenarien, in denen Module ausgeführt werden sollen. Dieser Abschnitt beschreibt einige dieser allgemeinen Modulverwaltungsaufgaben.

Aktivierte Module festlegenZwar gibt es Unterschiede hinsichtlich der Installation von systemeigenen und verwalteten Modulen, doch die aktivierten Module werden im Modulkonfigurationsabschnitt einheitlich dargestellt. Indem Sie im modules-Abschnitt die Moduleinträge bearbeiten, können Sie festlegen, welche Module auf dem Server (Standard) oder für eine bestimmte Anwendung arbeiten dürfen:

� Das Hinzufügen eines Moduls auf der Serverebene sorgt dafür, dass es für alle Anwendungen des Servers ausgeführt werden kann, außer für Anwendungen, die das Modul explizit entfernt haben.

� Das Entfernen eines Moduls auf der Serverebene sorgt dafür, dass es für alle Anwendungen des Servers nicht ausgeführt werden kann. Dies gilt nicht für Anwendungen, die das Modul explizit wieder hinzugefügt haben.

� Das Hinzufügen eines Moduls auf der Anwendungsebene sorgt dafür, dass es für diese spezielle Anwendung ausgeführt werden kann.

� Das Entfernen eines Serverebenenmoduls auf der Anwendungsebene sorgt dafür, dass dieses Modul aus dieser Anwendung entfernt wird, während andere Anwendungen es weiterhin benutzen können.

Kurz gesagt bieten alle Module, die auf der Serverebene aktiviert sind, einen Standardfeaturesatz für alle Anwendungen des Servers an. Jede Anwendung kann dann diesen Featuresatz anpassen, indem sie in ihrem modules-Abschnitt nicht benötigte Module entfernt und zusätzliche Module hinzufügt. Denken



Sie bitte daran, dass, obwohl Sie auf der Anwendungsebene neue verwaltete Module hinzu-fügen können, neue systemeigene Module auf der Serverebene installiert werden müssen, um auf der Anwendungsebene aktiviert werden zu können. Dies bedeutet, dass Anwendungen keine neuen system-eigenen Module einführen können – Sie können lediglich bereits vorhandene aktivierte systemeigene Module entfernen oder wieder hinzufügen, wenn diese auf der Serverebene installiert, aber nicht aktiviert sind.

Hinweis Sie können die für Ihre Anwendung aktivierten Module mit dem IIS-Manager verwalten. Nachdem Sie Ihre Anwendung im Hierarchielistenfeld markiert und das Feature Module geöffnet haben, nutzen Sie die Aktion Ver-waltetes Modul hinzufügen, um ein neues verwaltetes Modul hinzuzufügen, die Aktion Systemeigene Module konfigurieren, um bereits vorhandene systemeigene Module zu aktivieren oder zu deaktivieren, oder die Aktionen Bearbeiten und Entfernen, um bereits vorhandene Moduleinträge in der Liste zu bearbeiten bzw. zu entfernen. Lesen Sie später in diesem Kapitel den Abschnitt »Verwaltete Module mit dem IIS-Manager installieren und ver-walten«, um weitere Informationen zu erhalten.

Hinweis Sie können ebenfalls das Befehlszeilentool Appcmd benutzen, um aktivierte Module zu verwalten. Lesen Sie später in diesem Kapitel den Abschnitt »Verwaltete Module mit Appcmd installieren und verwalten«, um weitere Informationen zu erhalten.

Verwaltete Module für alle Anforderungen ausführen lassenDie Möglichkeit, IIS mit verwalteten Modulen zu erweitern, die für alle Inhaltstypen ausgeführt werden, ist eine der wichtigsten Neuerungen von IIS 7.0. Aus Gründen der Abwärtskompatibilität sind jedoch alle integrierten ASP.NET-Module so konfiguriert, dass sie ausschließlich für Anforderungen ausgeführt werden, die sich auf verwaltete (ASP.NET) Handler beziehen. Deshalb sind nützliche ASP.NET-Dienste, wie z.B. die Formularauthentifizierung, nur für auf ASP.NET-Inhaltstypen bezogene Anforderungen ver-fügbar und werden nicht auf Anforderungen angewendet, die sich auf statische Inhalte oder ASP-Seiten beziehen. Das ASP.NET-Setup sorgt hierfür, indem es jedem ASP.NET-Modulelement die managedHandler-Vorbedingung hinzufügt, sobald es dem Konfigurationsabschnitt modules hinzugefügt wird. Lesen Sie früher in diesem Kapitel den Abschnitt »Modulvorbedingungen verstehen«, um weitere Informationen zu erhalten.

Deshalb ist es notwendig, diese Vorbedingung für jedes ASP.NET-Modul zu entfernen, dessen Dienste für alle Anwendungsinhalte genutzt werden sollen. Dazu muss das jeweilige modules-Element mit Appcmd oder dem IIS-Manager bearbeitet werden oder Sie entfernen die mit dem Modulelement verknüpfte Vorbedingung manuell. Soll dies auf der Anwendungsebene für ein Modulelement geschehen, das von der Konfiguration der Serverebene geerbt wurde, ist es notwendig, das Modulelement zu entfernen und ohne Vorbedingung neu zu definieren.<modules> <remove name="FormsAuthentication" /> <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> </modules>

Dies löscht den managedHandler-Standardwert des preCondition-Attributs und sorgt dafür, dass das Forms-Authentication-Modul für alle Anforderungen ausgeführt wird.

Wenn Sie zur Bearbeitung des Modulelements den IIS-Manager oder Appcmd verwenden, wird diese Konfiguration automatisch generiert, wenn Sie Änderungen auf der Anwendungsebene vornehmen.



Hinweis Neue von Ihnen hinzugefügte Module weisen die Vorbedingung managedHandler standardmäßig nicht auf und werden somit für alle Anforderungen ausgeführt. Möchten Sie ein verwaltetes Modul auf die ausschließliche Ausführung von Anforderungen beschränken, die sich auf verwaltete Handler beziehen, müssen Sie die managedHandler-Vorbedingung manuell hinzufügen.

Alternativ hierzu können Sie Ihre Anwendung so konfigurieren, dass sie alle managedHandler-Vorbedin-gungen ignoriert und immer alle verwaltete Module für alle Anforderungen ausführt. Die Vorbedingung muss dazu nicht aus den Moduleinträgen entfernt werden. Sie erreichen dies, indem Sie im Konfigura-tionsabschnitt modules die Konfigurationsoption runAllManagedModulesForAllRequests setzen.<modules runAllManagedModulesForAllRequests="true" />

Die Modulreihenfolge kontrollierenDas Pipelinemodell für die Modulausführung ist der Grund dafür, dass oft die Modulreihenfolge von Bedeutung ist, wenn gewährleistet werden soll, dass sich der Server wie erwartet »verhält«. Module, die beispielsweise versuchen, den authentifizierten Benutzer zu ermitteln, müssen vor Modulen ausgeführt werden, die den Zugriff auf angeforderte Ressourcen verifizieren, da im letzten Fall bekannt sein muss, wer der authentifizierter Benutzer ist. Die Einhaltung dieser Reihenfolge wird fast immer durch die verschiedenen Phasen der Anforderungsverarbeitungspipeline erzwungen. Wenn Module ihre Arbeit in der richtigen Phase verrichteten, werden Probleme mit der Reihenfolge automatisch vermieden. In einigen Fällen können jedoch mehrere Module, die eine ähnliche Aufgabe ausführen – und somit in derselben Phase ausgeführt werden –, von der Reihenfolge abhängig sein. Einen bekanntes Beispiel sind die integrierten Authentifizierungsmodule. Sie werden während der Phase AuthenticateRequest ausgeführt, was in der richtigen Reihenfolge vom stärksten bis zum schwächsten Authentifizierungs-verfahren geschehen sollte, damit eine Anforderung mit den sichersten verfügbaren Anmeldeinforma-tionen authentifizierten wird. Der Administrator kann solche relativen Abhängigkeiten von der Modul-reihenfolge kontrollieren, indem er im Abschnitt modules die Reihenfolge ändert, in der die Module aufgelistet sind.

Dies funktioniert, weil der Server die Reihenfolge im Konfigurationsabschnitt modules verwendet, um die Reihenfolge der Modulausführung innerhalb jeder Anforderungsverarbeitungsphase festzulegen. Indem Sie in der Liste Modul A vor Modul B anordnen, sorgen Sie dafür, dass Modul A vor Modul B ausgeführt wird.

Dies bedeutet ebenfalls, dass, wenn eine Anwendung ein neues Modul aktiviert (indem ein neues verwaltetes Modul hinzugefügt oder ein systemeigenes Modul, das zuvor nicht aktiviert war, aktiviert wird), dieses Modul aufgrund der Konfigurationsauflistungsvererbung hinter den Modulen aufgelistet wird, die von höheren Konfigurationsebenen aktiviert wurden. Dies kann bisweilen zu einem Problem führen, wenn das neue Modul vor einem bereits vorhandenen und auf einer höheren Ebene definierten Modul ausgeführt werden soll, da das Konfigurationssystem keine Möglichkeit bietet, geerbte Ele-mente neu zu ordnen. In diesem Fall besteht die einzige Lösung darin, die modules-Auflistung auf der Anwendungsebene zu löschen und alle Elemente in der richtigen Reihenfolge neu hinzuzufügen. <modules> <clear/> <add name="HttpCacheModule" /> … <add name="MyNewModule" type="Modules.MyNewModule" /> … <modules>



Hinweis Sie können ebenfalls den IIS-Manager benutzen, um die Reihenfolge festzulegen. Nachdem Sie Ihre Anwendung in dem Hierarchielistenfeld markiert und das Feature Module geöffnet haben, wählen Sie die Aktion Sortierte Liste anzeigen und nutzen die Optionen Nach oben und Nach unten, um die Reihenfolge einzustellen. Wenn Sie dieses Feature nutzen, verwendet das Tool den bereits besprochenen <clear/>-Ansatz, um die Module für Ihre Anwendung neu zu ordnen.

Vorsicht Wenn Sie den <clear/>-Ansatz nutzen, trennen Sie die Modulkonfiguration der Anwendung von der entsprechenden Konfiguration der Serverebene. Alle auf der Serverebene vorgenommenen Änderungen (das Entfernen oder Hinzufügen von Modulen) wirken sich dann nicht mehr auf die Anwendung aus und müssen, sofern erforderlich, manuell weitergegeben werden.

Handlerzuordnungen hinzufügenObwohl Module in der Regel für alle Anforderungen ausgeführt werden, weshalb sie meistens inhalts-unabhängige Dienste anbieten, können einige Module als Handler agieren. Handler sind dafür verant-wortlich, für einen bestimmten Inhaltstyp eine Antwort zu generieren und sie sind in der Handler-zuordnungskonfiguration von IIS 7.0 bestimmten Verb/Erweiterung-Kombinationen zugeordnet. Der Server ist dafür verantwortlich, den richtigen Handler basierend auf der Handlerzuordnungskonfigura-tion zuzuordnen und er ist ebenfalls dafür verantwortlich, diesen Handler während der Anforderungs-verarbeitungsphase ExecuteRequest aufzurufen, damit die Antwort zur jeweiligen Anforderung generiert wird. Beispiele für Handler sind das Modul StaticFileModule, das statische Dateien bereitstellt, Directory-ListingModule, das Verzeichnislisten anzeigt, und das ASP.NET-Modul PageHandler, das ASP.NET-Seiten kompiliert und ausführt.

Der theoretisch wichtigste Unterschied zwischen Modulen und Handlern besteht darin, dass der Server den Handler auswählt, der zum Generieren einer Antwort auf die Anforderung einer bestimmten Ressource verwendet werden soll, wohingegen Module in der Regel alle Anforderungen ressourcen-unabhängig verarbeiten und meistens keine Antworten produzieren. Aus diesem Grund wird ein Handler nur dann für eine Anforderung ausgeführt, wenn er vom Server entsprechend zugeordnet wurde. Wenn Sie mit IIS 6.0 vertraut sind, ist dies vergleichbar mit dem Unterschied zwischen ISAPI-Erweiterungen, die lediglich eine Verarbeitung nur für bestimmte Dateinamenserweiterungen durch-führen, und ISAPI-Filtern, die alle Anforderungen abfangen.

Die meisten Anwendungsframeworks einschließlich ASP.NET, ASP, PHP und ColdFusion werden als Handler implementiert, die URLs mit bestimmten Dateinamenserweiterungen verarbeiten.

Sie registrieren auf dem Server einen Handler, indem Sie in der Auflistung des Konfigurationsabschnitts system.webServer/handlers einen Handlerzuordnungseintrag erstellen. Dieses Konzept weist gewisse Ähn-lichkeiten mit dem der Skriptzuordnungskonfiguration früherer IIS-Versionen auf, wurde aber für IIS 7.0 erweitert, um eine größere Flexibilität bieten und mehr Handlertypen unterbringen zu können. Für Anwendungen, die im integrierten Modus arbeiten, unterstützt dieser Abschnitt ebenfalls verwaltete Handler, die bei älteren IIS-Versionen im ASP.NET-Konfigurationsabschnitt httpHandlers registriert wurden.

Nachdem der Server eine Anforderung empfangen hat, untersucht er die für den Anforderungs-URL konfigurierte Handlerzuordnungsauflistung und wählt die erste Handlerzuordnung aus, deren Pfad-maske und Verb der Anforderung entsprechen. Später, während der Phase ExecuteRequestHandler, wird die Handlerzuordnung verwendet, um ein Modul für die Anforderungsbehandlung aufzurufen.

Jeder Handlerzuordnungsauflistungseintrag kann die in Tabelle 12.5 beschriebenen Attribute angeben.



Die Informationen in einer Handlerzuordnung werden wie folgt verwendet.

1. Zunächst wird die Vorbedingung verwendet, um zu ermitteln, ob die Handlerzuordnung in einem bestimmten Anwendungspool zum Einsatz kommen soll. Schlägt eine der Vorbedingungen fehl, wird die Zuordnung ignoriert.

2. Der Pfad und das Verb werden mit dem Anforderungs-URL und -Verb verglichen. Die erste Über-einstimmung wird ausgewählt. Werden keine Übereinstimmungen gefunden, wird ein 404.4-Fehler (Nicht gefunden) ausgelöst.

3. Wenn die accessPolicy-Konfiguration die requireAccess-Anforderung an die Handlerzuordnung nicht erfüllt, wird ein 403-Fehler (Zugriff verweigert) ausgelöst.

4. Wenn resourceType auf File, Directory oder Either gesetzt ist, stellt der Server sicher, dass die physikalische Ressource existiert und vom angegebenen Typ ist. Andernfalls wird ein 404-Fehler (Nicht gefunden) ausgelöst. Außerdem wird überprüft, ob der authentifizierte Benutzer auf die zugeordnete Dateisystem-ressource zugreifen darf. Wenn resourceType auf Unspecified gesetzt ist, wird diese Überprüfung nicht durchgeführt.

Tabelle 12.5 Von Handlerzuordnungen angegebene Attribute

Attribut Beschreibung

name (muss angegeben werden) Der Name der Handlerzuordnung

path (muss angegeben werden) Die Pfadmaske, die dem Anforderungs-URL entsprechen muss, damit diese Handlerzuordnung ausgewählt werden kann

verb (muss angegeben werden) Die Liste der Verben, von denen eines mit dem Anforderungsverb übereinstimmen muss, damit diese Handlerzuordnung ausgewählt werden kann

resourceType Gibt an, ob die dem Anforderungs-URL zugeordnete physikalische Ressource eine bereits vorhandene Datei oder ein Verzeichnis bzw. nicht festgelegt sein muss (wenn die physikalische Ressource nicht vorhanden sein muss)

requireAccess Die accessFlag-Ebene, die für die Ausführung dieses Handlers erforderlich ist

precondition Die Vorbedingung, die bestimmt, ob diese Handlerzuordnung berücksichtigt wird

allowPathInfo Gibt an, ob die Servervariablen PATH_INFO und PATH_TRANSLATED das Pfadinformationssegment enthalten; kann in einigen CGI-Programmen oder ISAPI-Erweiterungen, die nicht richtig mit den Pfadinformationen umgehen, zu Sicherheitsverletzungen führen

responseBufferLimit Die maximale Anzahl von Antwortbytes, die für diese Handlerzuordnung gepuffert werden sollen. Die Antwortpufferung ist neu in IIS 7.0 und ermöglicht es den Modulen, die Antwortdaten zu bearbeiten, bevor sie zum Client gesendet werden. Die Vorgabe ist 4 MB. Der Wert wird jedoch aus Gründen der Abwärtskompatibilität für ISAPI-Erweiterungen, die mit den alten APIs installiert wurden, automatisch auf 0 gesetzt.

Modules Die Liste der Module, die bei einer Auswahl dieser Zuordnung versuchen, die Anforderung zu behandeln

scriptProcessor Zusätzliche an das Modul übergebene Informationen, die festlegen, wie sich die Handler-zuordnung verhalten soll. Wird vom ISAPI-Erweiterungsmodul, CGI-Modul und FastCGI-Modul verwendet.

type Der Typ des verwalteten Handlers, der die Anforderung behandelt, wenn diese Zuordnung ausgewählt wird



Hinweis Bei IIS 7.0 können Sie über das path-Attribut Pfadmasken für die Suche nach Übereinstimmungen mit dem Anforderungs-URL angeben, die sehr viel komplexer als bei früheren IIS-Versionen sein können. Die alten Masken erlaubten lediglich die Angabe von * oder .ext, wobei .ext die URL-Erweiterung ist. IIS 7.0 ermöglicht es Ihnen, eine Pfadmaske zu nutzen, die mehrere, durch einen Schrägstrich (/) voneinander getrennte URL-Seg-mente und Platzhalterzeichen wie * oder ? enthalten kann.

Obwohl die meisten IIS 7.0-Handler auf der Serverebene hinzugefügt und von allen Anwendungen des Servers geerbt werden, können Sie auf jeder beliebigen Ebene zusätzliche Handler festlegen. Auf unteren Ebenen hinzugefügte Handlerzuordnungen werden bei einer entsprechenden Übereinstimmung zuerst verarbeitet, so dass neue Handler solche Handler, die auf einer höheren Konfigurationsebene deklariert wurden, außer Kraft setzen können. Wenn Sie somit für eine Ihrer Anwendungen ein Pfad/Verb-Paar einem anderen Handler zuordnen möchten, müssen Sie keinen auf der Serverebene hinzuge-fügten Handler entfernen – fügen Sie diese Handlerzuordnung einfach Ihrer Anwendungskonfiguration hinzu.

Hinweis IIS 7.0 unterstützt auch weiterhin Platzhalterzuordnungen, die es einem Handler ermöglichen, wie ein Filter zu agieren und alle Anforderungen zu verarbeiten bzw. die Anforderungsverarbeitung mithilfe einer unterge-ordneten Anforderung an einen anderen Handler zu delegieren. Obwohl die meisten dieser Szenarien mittlerweile mit normalen Modulen implementiert werden können, nutzen immer noch einige wenige alte ISAPI-Erweiterungen dieses Modell (auch einige ASP.NET-Konfigurationen). Um eine Platzhalterzuordnung zu erstellen, müssen Sie die Attribute path und verb auf das Sternchen (*), das requireAccess-Attribut auf None und das requireAccess-Attribut auf Either setzen.

HandlerzuordnungstypenDie Handlerkonfiguration arbeitet zwar mit einer standardmäßigen Zuordnung von Handlern zu Anfor-derungen, unterstützt aber auch viele andere Handlertypen, wie Tabelle 12.6 zeigt.

Tabelle 12.6 Handlertypen

Handlertyp Konfiguration IIS 7.0-Beispiele

Systemeigene(s) Modul(e)Das Modul muss das ExecuteRequest-Handler-Ereignis unterstützen

modules gibt die Liste der systemeigenen Module an, die diese Anforderung behandeln (in der Regel wird nur ein Modul angegeben)

TraceVerbHandler, OptionsVerbHandler, StaticFileModule, DefaultDocument-Module, DirectoryBrowsingModule

ASP.NET-Handler

Die Anwendung muss den integrierten ASP.NET-Modus verwenden

type gibt den vollqualifizierten .NET-Typ an, der ASP.NET-Handlerschnittstellen implementiert

PageHandlerFactory von ASP.NET (aspx-Seite), WebResourceHandler von ASP.NET

ISAPI-Erweiterung modules gibt das ISAPIModule an; scriptPro-cessor gibt den Pfad zur zu ladenden ISAPI-Erweiterungs-DLL an

ASP.dll (asp-Seiten)

CGI-Programm modules gibt das CGIModule an; scriptPro-cessor gibt den Pfad zur ausführbaren CGI- Datei an

Jede ausführbare CGI-Datei

FastCGI-Programm modules gibt das FastCGIModule an; script-Processor gibt den Pfad und die Argumente für eine ausführbare FastCGI-Datei an, die im FastCGI-Konfigurationsabschnitt registriert ist

Jede ausführbare FastCGI-Datei (wie z.B. PHP-CGI.EXE)



Im Gegensatz zu den Skriptzuordnungen früherer IIS-Versionen, deren Unterstützung von ISAPI-Erwei-terungen und CGI-Programmen hartcodiert war, gibt es bei IIS 7.0 keine solche Hartcodierung – alle Handlertypen setzen auf die systemeigene oder verwaltete Modul-API auf. IIS 7.0 unterstützt ISAPI-Erweiterungen, indem es diese mit ISAPIModule hostet. CGI-Programme werden mit dem CGI-Modul unterstützt und die neue Unterstützung von FastCGI-Programmen wird mit FastCgiModule ermöglicht. Die Module IsapiModule, CgiModule und FastCgiModule sind wie StaticFileModule systemeigene Module, unterstützen aber die Möglichkeit, eine Schnittstelle zu externen Handlerframeworks zu bilden, um mithilfe der ISAPI-, CGI- und FastCGI-Protokolle Anforderungen zu behandeln.

Wenn Sie einen Blick auf die Handlerzuordnungen werfen, die standardmäßig von einer vollständigen IIS 7.0-Installation erstellt werden, sehen Sie Folgendes: <handlers accessPolicy="Read, Script"> <add name="ASPClassic" path="*.asp" verb="GET,HEAD,POST" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" esourceType="File" /> <add name="ISAPI-dll" path="*.dll" verb="*" modules="IsapiModule" resourceType="File" requireAccess="Execute" allowPathInfo="true" /> ... <add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" /> ... <add name="PageHandlerFactory-ISAPI-2.0" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0" /> ... <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" /> </handlers>

Dieses Konfigurationsfragment ist ein gutes Beispiel dafür, wie abschnittsübergreifend die von Ihnen erzeugten Handlerzuordnungen sein können. Zuerst ist da die IsapiModule-Handlerzuordnung, die die Ausführung von ASP-Seiten mithilfe der ISAPI-Erweiterung ASP.dll ermöglicht. Dann folgt die IsapiModule-Zuordnung, die direkte auf ISAPI-Erweiterungen bezogene Anforderungen unterstützt, wobei sich diese Erweiterungen in Anwendungsverzeichnissen befinden müssen, die eine Ausfüh-rungsberechtigung erfordern.

Dann finden Sie zwei Zuordnungen des ASP.NET-Moduls PageHandlerFactory, das die Verarbeitung von ASPX-Seiten unterstützt. Die erste Zuordnung verwendet die ISAPI-Erweiterung aspnet_isapi.dll, um eine Anforderung zu verarbeiten, und die zweite nutzt den integrierten Modus für eine direkte Ausfüh-rung von ASP.NET-Handlern. Jede dieser Zuordnungen arbeitet mit einer Vorbedingung, um sicherzu-stellen, dass in jedem Anwendungspool, der auf dem ASP.NET-Integrationsmodus basiert, nur eine Zuordnung aktiv ist. Im klassischen Modus arbeitende Anwendungspools nutzen die ISAPI-Zuord-nung, und im integrierten Modus arbeitende Anwendungspools greifen auf die integrierte Zuordnung zurück. Weitere Informationen zur ASP.NET-Integration und ASP.NET-Handlerzuordnungen erhalten Sie im elften Kapitel. Schließlich gibt es noch die alles abfangende Handlerzuordnung für statische Dateien, die allen Anforderungen zugeordnet ist, die nicht den Kriterien der anderen Handlerzuord-nungen entsprechen. Dazu werden sowohl der Pfad als auch das Verb dieser Zuordnung auf das



Sternchen (*) gesetzt. Dies ist vergleichbar mit früheren IIS-Versionen, wo alle Anforderungen, die keiner Skriptzuordnung einer ISAPI-Erweiterung zugeordnet waren, vom Handler für statische Dateien behan-delt wurden. Diese Zuordnung zeigt außerdem, wie Sie dafür sorgen können, dass mehrere Module versuchen, eine Anforderung als Teil einer einzelnen Handlerzuordnung zu behandeln. StaticFileModule versucht zuerst, eine physikalische Datei bereitzustellen, wenn diese vorhanden ist, dann führt DefaultDocu-mentModule die Standarddokumentumleitung durch, und schließlich versucht DirectoryBrowsingModule, eine Verzeichnisliste bereitzustellen.

Später in diesem Kapitel in den Abschnitten »Verwaltete Module mit dem IIS-Manager installieren und verwalten« und »Verwaltete Module mit Appcmd installieren und verwalten« erfahren Sie mehr darüber, wie Sie Handlerzuordnungen mit dem IIS-Manager und Appcmd erstellen.

Verwaltete Module mit dem IIS-Manager installieren und verwaltenDer IIS-Manager bietet eine leistungsfähige Benutzeroberfläche für die Verwaltung von Modulen auf dem Server an. Diese Benutzeroberfläche kann auf der Server- und Anwendungsebene für die Instal-lation systemeigener und verwalteter Module und zur Verwaltung aktivierter Module verwendet werden.

Das Feature Module stellt diese Funktionalität zur Verfügung und es kann auf zwei verschiedenen Ebenen verwendet werden, wo es eine jeweils leicht abgewandelte Funktionalität bietet:

� Auf der Serverebene vom Serveradministrator, um auf dem Server systemeigene Module zu installieren, neue verwaltete Module hinzuzufügen und Module zu konfigurieren, die auf dem Server standardmäßig aktiviert sind

� Auf der Anwendungsebene vom Server- oder Siteadministrator, um neue verwaltete Module hinzuzufügen und Module zu konfigurieren, die für die jeweilie Anwendung aktiviert sind

Für die Arbeit auf der Serverebene können Sie im Hierararchielistenfeld den Knoten des Computers markieren und anschließend einen Doppelklick auf Module ausführen, um wie in Abbildung 12.3 auf das Feature Module zuzugreifen.

SicherheitswarnungDer Umstand, dass die alles abfangende Zuordnung StaticFileModule verwendet, bedeutet, dass Anforderungen von Ressourcen, für die bis jetzt noch kein Handler konfiguriert ist, einen 404.3-Fehler (Nicht gefunden) verursachen, wenn sie nicht in der MIME-Typkonfiguration des Servers aufgelistet sind. Dieser Fehler zeigt in der Regel an, dass Sie entweder dem staticContent-Konfigura-tionsabschnitt des Servers einen MIME-Zuordnungseintrag für die Namenserweiterung der Datei hinzufügen müssen, damit diese heruntergeladen werden kann, oder Sie müssen eine Handlerzuord-nung hinzufügen, damit die Datei richtig verarbeitet wird. Dies ist eine wichtige Sicherheitsmaß-nahme, die verhindert, dass auf dem Server Skripts in Form von Quellcode heruntergeladen werden, für die bis jetzt noch nicht die richtigen Handlerzuordnungen installiert sind. Weitere Informationen zum Hinzufügen von MIME-Typeinträgen finden Sie im elften Kapitel.



Abbildung 12.3 Das Feature Module im IIS-Manager

Sie sehen dann die Liste der auf der Serverebene aktivierten Module, die der Modulliste im Konfigura-tionsabschnitt modules der applicationHost.config-Datei der Serverebene entspricht. Der Name jedes Moduls wird angezeigt. Für systemeigene Module wird ebenfalls der Pfad zur Abbild-DLL angezeigt. Bei verwalteten Modulen ist außerdem der Modultypname zu sehen. Sie finden auf dieser Seite drei verfügbare Aktionen:

� Verwaltetes Modul hinzufügen Ermöglicht es Ihnen, der Liste der aktivierten Module ein neues verwaltetes Modul hinzuzufügen. Im resultierenden Dialogfeld können Sie den Namen Ihres neuen Moduls sowie den Modultyp angeben.

Sie können im Dropdown-Listenfeld Typ einen Modultyp auswählen. Dieses Listenfeld enthält alle verfügbaren Modultypen, die von den Assemblys im globalen Assemblycache des Computers bereitgestellt werden. Diese Assemblies sind im system.web/compilation/assemblies-Abschnitt der web.config-Stammdatei des .NET Frameworks aufgelistet. Sie können auch Ihren eigenen Typ ange-



ben, wenn dieser noch nicht aufgelistet ist. Aktivieren Sie das Kontrollkästchen Nur für ASP.NET-Anwendungen und verwaltete Handler aufrufen, wenn Ihr Modul die managedHandler-Vorbedingung nut-zen und nur für Anforderungen ausgeführt werden soll, die sich auf ASP.NET-Handler beziehen (lesen Sie den Abschnitt »Modulvorbedingungen verstehen«, um weitere Informationen hierzu zu erhalten).

� Systemeigene Module konfigurieren Ermöglicht es Ihnen, bereits installierte systemeigene Module zu aktivieren, ein neues systemeigenes Modul zu installieren oder ein bereits vorhandenes systemeigenes Modul zu deinstallieren.

Sie können hier installierte, aber noch nicht aktivierte systemeigene Module aktivieren, indem Sie diese auswählen. Sie können ebenfalls die Schaltfläche Registrieren benutzen, um ein neues sys-temeigenes Modul zu installieren, die Schaltfläche Bearbeiten, um den Namen oder Pfad eines installierten Moduls zu bearbeiten, oder die Schaltfläche Entfernen, um das markierte systemeigene Modul zu deinstallieren.

� Sortierte Liste anzeigen Ermöglicht es Ihnen, die Module in der richtigen Reihenfolge anzeigen zu lassen, so dass Sie diese einstellen können, indem Sie mit den Aktionen Nach oben und Nach unten arbeiten. Wenn dies auf der Serverebene geschieht, können Sie die Module neu ordnen, ohne zuvor die modules-Auflistung löschen zu müssen (lesen Sie früher in diesem Kapitel den Abschnitt »Die Modulreihenfolge kontrollieren«, um weitere Informationen zu erhalten).

Wenn Sie außerdem in der Liste einen Moduleintrag markieren, werden drei zusätzliche Aktionen angezeigt:

1. Bearbeiten. Mit dieser Aktion können Sie den Moduleintrag bearbeiten. Bei systemeigenen Modulen können Sie die Installationsinformationen des markierten Moduls direkt ändern. Dazu zählen der Name und der Pfad zur nativen Abbild-DLL. Bei verwalteten Modulen können Sie den Modulnamen und den Modultyp bearbeiten.

2. Sperren/Entsperren. Mit diesen Aktionen können Sie auf der Serverebene ein bestimmtes Modul-element sperren, so dass es auf der Anwendungsebene nicht entfernt oder modifiziert werden kann. Lesen Sie später in diesem Kapitel den Abschnitt »Einschränken der Erweiterbarkeit«, um weitere Informationen zum Sperren von Modulen zu erhalten.

3. Entfernen. Mit dieser Aktion können Sie den Moduleintrag entfernen. Bei systemeigenen Modulen wird das jeweilige Modul standardmäßig deaktiviert. Bei verwalteten Modulen wird der entspre-chende Moduleintrag entfernt, so dass Sie das Modul, sollten Sie es später auf der Anwendungs-ebene wieder hinzufügen, dort wieder aktivieren müssen.



Um auf der Anwendungsebene auf das Feature Module zuzugreifen, markieren Sie im Hierarchie-listenfeld die Anwendung, die Sie verwalten möchten. Führen Sie anschließend einen Doppelklick auf dem Symbol des Features Module aus. Ihnen wird daraufhin dieselbe Ansicht wie zuvor präsentiert. Es gibt jedoch die folgenden Unterschiede:

� Sie können nicht mehr mithilfe des Dialogfelds Systemeigene Module konfigurieren neue system-eigene Module hinzufügen. Der Grund hierfür besteht darin, dass systemeigene Module für den gesamten Server installiert werden und Sie administrative Rechte besitzen müssen, um eine solche Installation durchzuführen. Sie können lediglich bereits installierte systemeigene Module akti-vieren, die noch nicht für Ihre Anwendung aktiviert wurden.

� Sie können nicht mehr die Informationen zu systemeigenen Modulen oder zu auf der Serverebene aktivierten verwalteten Modulen bearbeiten. (Sie können aber weiterhin die Modulinformationen zu den verwalteten Modulen bearbeiten, die Ihrer Anwendung hinzugefügt wurden.)

� Sie können Module nicht sperren/entsperren.

� Wenn Sie außerdem verwaltete Module hinzufügen, untersucht das Tool alle Assemblies in den /BIN- und /App_Code-Quelldateien daraufhin, ob möglicherweise weitere hinzuzufügende Module vorhanden sind.

� Sie können die Aktion Auf geerbt zurücksetzen verwenden, um die Änderungen, die auf der Anwen-dungsebene am Konfigurationsabschnitt modules vorgenommen wurden, zu verwerfen und zur Standardmodulkonfiguration der Serverebene zurückzukehren.

Trotz dieser Einschränkungen kann der Siteadministrator den IIS-Manager benutzen, um neue verwal-tete Module zu installieren oder den Modulfeaturesatz der Anwendung zu verwalten. Dazu muss er auf dem Computer über keine administrativen Rechte verfügen. Dies ist angesichts der Fähigkeit des IIS-Managers, eine delegierte Remoteverwaltung für Anwendungsbesitzer zuzulassen, besonders nützlich. Natürlich können auch Serveradministratoren den IIS-Manager nutzen, um Module uneingeschränkt zu verwalten.

Handlerzuordnungen mit dem IIS-Manager erstellen und verwaltenDer IIS-Manager bietet ebenfalls eine einfach zu bedienende Benutzeroberfläche für die Verwaltung von Handlerzuordnungen, so dass die mit der manuellen Bearbeitung von Handlerzuordnungen einher-gehende Komplexität nicht mehr gegeben ist. Diese Funktionalität wird vom Feature Handlerzuord-nungen zur Verfügung gestellt, auf das sowohl Server- als auch Siteadministratoren zugreifen können.

Nachdem Sie den Knoten markiert haben, für den Sie die Handlerzuordnungen verwalten möchten, können Sie das Feature wählen, indem Sie einen Doppelklick auf dem Symbol Handlerzuordnungen ausführen. Daraufhin wird die Ansicht Handlerzuordnungen angezeigt, wie in Abbildung 12.4 dargestellt.

Hier finden Sie eine Liste der Handlerzuordnungen, die den Handlerzuordnungsnamen, den Pfad und andere nützliche Informationen enthält. Die Spalte Handler fasst zusammen, wie der Handler implemen-tiert ist, indem sie entweder für systemeigene Handler die Modulliste oder für verwaltete Handler den Typ anzeigen. Die Spalte Pfad gibt den resourceType der Handlerzuordnung an. Die Spalte Zustand gibt Aufschluss darüber, ob der Handler aktiviert ist (dies gilt nur für Handlerzuordnungen, die IsapiModule oder CgiModule verwenden), und sie zeigt an, ob die von der Zuordnung festgelegte ISAPI-Erweiterung bzw. das entsprechende CGI-Programm in der system.webServer/security/isapiCgiRestrictions-Konfiguration aktiviert ist (analog zur Webdiensteinschränkungsliste von IIS 6.0).



Abbildung 12.4 Das Feature Handlerzuordnungen im IIS-Manager

Das Tool bietet viele Möglichkeiten, um neue Handlerzuordnungen hinzuzufügen. Diese werden in Typen unterteilt, um die Handlerzuordnungserstellung zu vereinfachen:

� Verwalteten Handler hinzufügen Diese Aktion ermöglicht es Ihnen, eine Handlerzuordnung für einen ASP.NET-Handler zu erstellen. Diese Zuordnung ist nur in Anwendungspools möglich, die mit dem integrierten Modus arbeiten. Sie ist in Abbildung 12.5 dargestellt.

Abbildung 12.5 Das Dialogfeld Verwalteten Handler hinzufügen



In diesem Dialogfeld geben Sie die Pfadmaske für die Handlerzuordnung sowie den ASP.NET-Handlertyp an, der die entsprechende Verarbeitung durchführen soll. Ähnlich wie beim Hinzufügen verwalteter Module sucht das Tool in den Assemblies des globalen Assemblycaches (Globaler Assemblycache), die in der compilation/assemblies-Auflistung von ASP.NET referenziert sind, nach verwendbaren Typen. Wenn Sie den Handler auf der Anwendungsebene hinzufügen, sucht das Tool ebenfalls nach Anwendungsassemblies. Sie können das Dialogfeld Einschränkungen benutzen, um auch die Verbliste für die Handlerzuordnung festzulegen (die andernfalls standardmäßig auf "*" gesetzt wäre), um die Zuordnung auf physikalische Ressourcen wie eine Datei oder ein Verzeichnis zu beschränken (standardmäßig wird hierzu keine Angabe gemacht) und um bei Bedarf Zugriffs-ebenen für die Ausführung der Zuordnung festzusetzen (der Standard ist Skript). Sie sollten hier die strengstmöglichen Einstellungen anstelle der Standardwerte verwenden, um eine zusätzliche Sicherheit zu erzielen.

� Skriptzuordnung hinzufügen Diese Aktion ermöglicht es Ihnen, ähnlich wie bei einer IIS 6.0-Skriptzuordnung eine Handlerzuordnung für eine ISAPI-Erweiterung oder ein CGI-Programm zu erstellen. Dies ist in Abbildung 12.6 dargestellt.

Abbildung 12.6 Das Dialogfeld Skriptzuordnung hinzufügen

Dies ist vergleichbar mit dem vorherigen Dialogfeld. Anstelle des .NET-Handlertyps wählen Sie jedoch im lokalen Dateisystem des Servers die gewünschte ISAPI-Erweiterung, DLL oder ausführ-bare CGI-Programmdatei. Wenn Sie mit diesem Dialogfeld arbeiten, wird außerdem, sofern Sie dies bestätigen, automatisch der isapiCgiRestriction-Eintrag generiert, damit die ISAPI-Erweiterung oder das CGI-Programm auf dem Server ausgeführt werden kann.

� Skriptzuordnung mit Platzhalter hinzufügen Entspricht weitgehend dem Dialogfeld Skriptzu-ordnung hinzufügen. Sie können jedoch eine Skriptzuordnung mit Platzhalter erstellen, die alle übereinstimmenden Anforderungen abfängt.

� Modulzuordnung hinzufügen Dies ist die interessanteste Aktion, da sie es Ihnen ermöglicht, eine allgemeine Handlerzuordnung zu erstellen, die systemeigene Module und optional einen Skriptprozessor angibt. Sie können dieses Dialogfeld verwenden, um Handlerzuordnungen für ISAPI-Erweiterungen, CGI und FastCGI sowie einfache Handlerzuordnungen für systemeigene Module zu erstellen, wie in Abbildung 12.7 dargestellt.



Abbildung 12.7 Das Dialogfeld Modulzuordnung hinzufügen

Das Dialogfeld ermöglicht Ihnen die Angabe des Moduls (außerdem zeigt es eine Liste der verfüg-baren systemeigenen Module an, obwohl nicht alle davon als Handler fungieren können) und der aus-führbaren Datei (der Skriptprozessor). Es bietet außerdem, sofern Sie dies bestätigen, eine spezielle Behandlung von IsapiModule-, CgiModule- und FastCgiModule-Handlerzuordnungen an, indem es automa-tisch die entsprechende isapiCgiRestrictions- oder FastCGI-Konfiguration erzeugt, die für ein fehler-freies Funktionieren der Zuordung notwendig ist.

Hinweis Es ist nicht möglich, Vorbedingungen über das Feature Handlerzuordnungen zu bearbeiten. Stattdessen generiert das Tool automatisch die richtigen Vorbedingungen für die Handlerzuordnungen, damit diese richtig funk-tionieren. Wenn Sie die Vorbedingungen ändern möchten, müssen Sie die Konfiguration mit Appcmd oder anderen Konfigurations-APIs direkt bearbeiten.

Zusätzlich zum Hinzufügen neuer Handlerzuordnungen können Sie ebenfalls bereits vorhandene Handler-zuordnungen bearbeiten oder löschen, indem Sie in der Liste das gewünschte Element markieren und die daraufhin verfügbaren Aktionen Bearbeiten oder Entfernen benutzen. Auf der Serverebene können Sie Handlerzuordnungen auch sperren, um zu verhindern, dass sie auf einer niedrigeren Ebene entfernt werden. Dies ist jedoch weniger effektiv, als das Sperren von Modulen, da Handlerzuordnungen außer Kraft gesetzt werden können, indem neue Handlerzuordnungen für denselben Pfad/dasselbe Verb hinzugefügt werden.

Sie können ebenfalls die Aktion Sortierte Liste anzeigen benutzen, um Handlerzuordnungen zu ordnen. Denken Sie daran, dass das Tool, genauso wie bei den Modulen, zum Anordnen von geerbten Elemen-ten <clear/> benutzt. Auf diese Weise wird die handlers-Auflistung gelöscht und die übergeordneten Elemente werden der aktuellen Konfigurationsebene erneut hinzugefügt, wodurch die Konfiguration von der übergeordneten Handlerzuordnungskonfiguration getrennt wird.

Wenn Sie als Siteadministrator Handlerzuordnungen bearbeiten, nutzen Sie, unabhängig davon, ob Sie diese Zuordnungen für Ihre Site, Anwendung oder einen URL innerhalb Ihrer Site verwalten, fast immer dieselbe Funktionalität. Das Tool fordert Sie jedoch nicht auf, ISAPI-Erweiterungen und CGI- sowie FastCGI-Programme zu aktivieren, die noch nicht auf der Serverebene vom Administrator aktiviert wurden.



Verwaltete Module mit Appcmd installieren und verwaltenDas Befehlszeilentool Appcmd ermöglicht die Verwaltung von Modulen auf höchster Ebene. Zu Beginn können Sie die IIS-Konfiguration immer mit dem Appcmd-Objekt Config bearbeiten, um all die Aufgaben auszuführen, die für die Installation und Verwaltung von Modulen notwendig sind. Das Tool bietet jedoch auch ein module-Objekt an, das häufige Modulverwaltungsaufgaben direkt unterstützt. Aus diesem Grund ruft das Windows-Setup Appcmd auf, um Module zu installieren. Appcmd stellt oft die schnellste Mög-lichkeit dar, um Module zu installieren und zu verwalten. Appcmd ist außerdem das einzige Tool, das für die Verwaltung von Modulen unter Windows Server 2008 Server Core zur Verfügung steht, da der IIS-Manager von dieser Betriebssystemversion nicht unterstützt wird.

Appcmd befindet sich im Verzeichnis %windir%\System32\Inetsrv, das in der PATH-Variablen standard-mäßig nicht aufgeführt ist, weshalb Sie den vollständigen Pfad zum Tool angeben müssen, um es ausführen zu lassen.%windir%\system32\inetsrv\AppCmd

Sie müssen als Administrator angemeldet sein, wenn Sie mit Appcmd arbeiten. Achten Sie ebenfalls darauf, Appcmd-Befehle von einer hochgestuften Eingabeaufforderung aus zu initiieren (klicken Sie auf Start, mit der rechten Maustaste auf Eingabeaufforderung, und wählen Sie Als Administrator aus-führen). Lesen Sie das siebte Kapitel, »Verwenden von Befehlszeilentools«, um weitere Informationen zu diesem Tool zu erhalten. Wenn Sie beim Erlernen von Appcmd den Überblick verlieren, rufen Sie die integrierte Befehlszeilenhilfe auf, die Parameter erklärt und Beispiele zur Verfügung stellt.AppCmd module /? - Alle Befehle des module-Objekts anzeigen AppCmd install module /? - Eine Anleitung zur Verwendung des Befehls install module anzeigen

Der Hilfetext zum MODULE-Objekt verrät, dass das Tool die folgenden Befehle unterstützt:

� List Ermöglicht es Ihnen, Module zu untersuchen, die auf der Serverebene oder für eine bestimmte Anwendung aktiviert sind

� Install Ermöglicht es Ihnen, auf dem Server neue systemeigene Module zu installieren

� Uninstall Ermöglicht es Ihnen, auf dem Server gegenwärtig installierte systemeigene Module zu deinstallieren

� Add Ermöglicht es Ihnen, neue Module hinzuzufügen. Sie können ebenfalls ein installiertes systemeigenes Modul für eine bestimmte Anwendung aktivieren.

� Delete Ermöglicht es Ihnen, ein verwaltetes Modul zu deaktivieren. Sie können ebenfalls ein systemeigenes Modul für eine bestimmte Anwendung deaktivieren.

� Set Ermöglicht es Ihnen, im Konfigurationsabschnitt modules bestimmte Einträge zu bearbeiten, um den Namen oder die Vorbedingungen eines Moduls bzw. die Typinformationen verwalteter Module zu ändern

Im nächsten Abschnitt erhalten Sie einige Beispiele für den Einsatz dieser Befehle, damit Sie mit Appcmd Module verwalten können.

Module installieren und deinstallierenDie module-Befehle Install und Uninstall unterstützen – Sie werden es erraten haben – die Installation und Deinstallation systemeigener Module auf dem Server.

Um systemeigene Module zu installieren, können Sie die folgende Syntax verwenden:AppCmd Install Module /name:string /image:string [/precondition:string] [/add:bool] [/lock:bool]



Dieser Befehl akzeptiert die in Tabelle 12.7 beschriebenen Parameter.

Der einfachste Fall ist die Installation eines Moduls durch Angabe seines Namens und Abbildpfades.AppCmd install module /name:MyNativeModule /image:c:\modules\mymodule.dll

Dies führt zur Installation und automatischen Aktivierung des Moduls auf der Serverebene, so dass es standardmäßig von allen IIS-Arbeitsprozessen geladen und für alle Anwendungen aktiviert wird. Wollten Sie das Modul installieren, aber nur für bestimmte Anwendungen aktivieren, würden Sie zusätzlich den Parameter /add:false verwenden. Dann könnten Sie später den Befehl Appcmd Add Module mit dem Parameter /app.name benutzen, um das Modul für eine bestimmte Anwendung zu aktivieren. Möchten Sie hingegen das Modul installieren und aktivieren und verhindern, dass Anwendungen es deaktivieren, können Sie den Parameter /lock:true in den install-Befehl aufnehmen. Sie können ebenfalls den precondition-Parameter auf einen der unterstützten Werte setzen (lesen Sie früher in diesem Kapitel den Abschnitt »Modulvorbedingungen verstehen«), um zu kontrollieren, in welche Anwendungspools das Modul geladen werden darf, so dass es dort verfügbar ist.

Zur Deinstallation eines Moduls können Sie die folgende Syntax verwenden:AppCmd Uninstall Module ModuleName

Dieser Befehl erwartet den Modulnamen als Bezeichner.

Tipp Der uninstall-Befehl verwendet im Gegensatz zum Install-Befehl, der mit dem Parameter /name arbeitet, das Appcmd-Standardschema für Bezeichner, um den Modulnamen anzugeben. Dies geschieht, damit alle Befehle, die für bestimmte vorhandene Objektinstanzen ausgeführt werden, das Bezeichnerformat verwenden können, anstatt verschiedene Parameternamen für die Identifizierung von Objekten angeben zu müssen.

Nachfolgend ist ein Beispiel dafür aufgeführt, wie Sie das zuvor installierte Modul deinstallieren können:AppCmd uninstall module MyNativeModule

Hinweis Dies führt automatisch dazu, dass das Modul auf der Serverebene deaktiviert wird, was auch sinnvoll ist, weil eine fehlerhafte Konfiguration entstehen würde, wenn das Modul nach seiner Deinstallation noch aktiviert wäre. Möchten Sie jedoch, aus welchen Gründen auch immer, ein Modul deinstallieren, aber aktiviert lassen (dies würde auf dem gesamten Server zu Anforderungsfehlern führen), können Sie den Parameter /remove:false angeben.

Tabelle 12.7 Appcmd-Parameter für den Install Module-Befehl


name (muss angegeben werden) Modulname

image (muss angegeben werden) Der Pfad zur Modul-DLL

preCondition Optional. Gibt die Liste der für das Modul gültigen Vorbedingungen an, die sich auf das Laden beziehen. Kontrolliert, sofern angegeben, ob das Modul von den IIS-Arbeitsprozessen eines bestimmten Anwendungspools geladen wird. Die Vorgabe ist eine leere Zeichenfolge.

add Optional. Gibt an, ob das Modul auch auf der Serverebene aktiviert werden soll. Die Vorgabe ist TRUE.

lock Optional. Gibt an, ob der Moduleintrag gesperrt werden soll, so dass er von Anwendungen nicht angezeigt werden kann. Diese Einstellung wird nur dann angewendet, wenn das Modul aktiviert wurde. Die Vorgabe ist FALSE.



Module aktivieren und deaktivierenSie können die Befehle Add Module und Delete Module benutzen, um die Module zu verwalten, die auf dem Server oder für eine bestimmte Anwendung aktiviert sind. Sie können den Befehl Add Module ebenfalls verwenden, um neue verwaltete Module hinzuzufügen. Diese Befehle modifizieren den Konfigurations-abschnitt modules, der die Einträge für aktivierte systemeigene Module enthält und verwaltete Module definiert. Deshalb können Sie viele verschiedene Aufgaben ausführen, die sich auf die Modulverwal-tung beziehen.

Der Add Module-Befehl wird vorwiegend verwendet, um neue verwaltete Module hinzuzufügen. Da systemeigene Module zunächst auf dem Server installiert werden müssen, bevor sie aktiviert werden können, ist für deren Installation und automatische Aktivierung der Befehl Install Module besser geeignet. Sie können ein verwaltetes Module auf der Serverebene oder für eine bestimmte Anwendung hinzu-fügen, indem Sie die folgende Syntax verwenden:AppCmd Add Module /name:string [/type:string] [/precondition:string] [/app.name:string] [/lockItem:bool]

Dieser Befehl unterstützt die in Tabelle 12.8 beschriebenen Parameter.

Um beispielsweise auf der Serverebene ein neues verwaltetes Modul hinzuzufügen, können Sie wie folgt vorgehen:AppCmd add module /name:MyManagedModule /type:MyModules.MyModule

Das Modul ist dann standardmäßig für alle Anwendungen des Servers aktiviert. Möchten Sie es lediglich der Stammanwendung der Standardwebsite hinzufügen, geben Sie zusätzlich den Parameter /app.name: "Default Web Site/" an. Sie könnten ebenfalls den Parameter preCondition auf einen der unterstützten Werte setzen (lesen Sie früher in diesem Kapitel den Abschnitt »Modulvorbedingungen verstehen«), um zu kontrollieren, für welche Anwendungspools und Anforderungen das Modul aktiviert wird.

Sie können, wie beim Erstellen neuer Konfigurationsauflistungseinträge, ebenfalls mit dem Parameter lockItem arbeiten, um den Moduleintrag zu sperren. Niedrigere Konfigurationsebenen verfügen dann nicht mehr über die Möglichkeit, den Modulkonfigurationseintrag zu entfernen. Sie können dies nutzen,

Tabelle 12.8 Parameter von Appcmd Add Module


name (muss angegeben werden) Modulname

type (muss angegeben werden) Der vollqualifizierte .NET-Typ des Moduls. Wird das Modul auf der Serverebene hinzugefügt, muss der Typ in einer Assembly definiert sein, die für den globalen Assemblycache des Computers registriert ist. Wenn es für eine bestimmte Anwendung hinzugefügt wird, kann es zusammen mit dieser bereitgestellt werden. Lesen Sie den Abschnitt »Verwaltete Module enthaltende Assemb-lies bereitstellen«, um weitere Informationen zu erhalten.

preCondition Optional. Gibt die Liste der für das Modul gültigen Aktivierungsvorbedingungen an. Kontrolliert, sofern angegeben, ob das Modul in bestimmten Anwendungspools und für bestimmte Anforde-rungen aktiviert ist. Die Vorgabe ist eine leere Zeichenfolge.

app.name Optional. Gibt den Anwendungspfad für die hinzuzufügenden Module an. Die Vorgabe ist eine leere Zeichenfolge, was gleichbedeutend mit der Serverebene ist.

lockItem Optional. Gibt an, ob der Moduleintrag gesperrt werden soll, so dass er auf niedrigeren Konfigu-rationsebenen nicht entfernt werden kann.



wenn Sie auf der Serverebene verwaltete Module hinzufügen, damit diese nicht auf der Anwendungs-ebene deaktiviert werden. Dies wird später in diesem Kapitel im Abschnitt »Einschränken der Erweiter-barkeit« ausführlich erläutert.

Der Befehl Add Module wird auch oft benutzt, um ein bisher noch nicht aktiviertes systemeigenes Modul zu aktivieren. Wenn Sie beispielsweise ein systemeigenes Modul mit dem Parameter /add:false installiert haben, so dass es zwar installiert, aber nicht aktiviert ist, können Sie es direkt aktivieren.AppCmd add module /name:MyNativeModule

Sie können hier den Parameter /app.name verwenden, um die Anwendung anzugeben, für die das Modul aktiviert werden soll. Dies funktioniert nur bei systemeigenen Modulen. Wenn Sie verwaltete Module für eine bestimmte Anwendung neu aktivieren, müssen Sie immer den Typ angeben, da diese Infor-mation, anders als bei systemeigenen Modulen, nirgendwo sonst verfügbar ist.

Sie können den Befehl Delete Module verwenden, um das Gegenteil zu erreichen – um ein gegenwärtig aktiviertes Modul zu deaktivieren. Sie können diesen Befehle ebenfalls einsetzen, um auf der Server-ebene oder für eine bestimmte Anwendung systemeigene Module bzw. verwaltete Module zu deakti-vieren. Dies ist mit der folgenden Syntax möglich.AppCmd Delete Module ModuleName [/app.name:string]

Tipp Der delete-Befehl verwendet im Gegensatz zum add-Befehl, der mit dem Parameter /name arbeitet, das Appcmd-Standardschema für Bezeichner, um den Modulnamen anzugeben. Dies geschieht, damit alle Befehle, die für bestimmte vorhandene Objektinstanzen ausgeführt werden, das Bezeichnerformat verwenden können, anstatt verschiedene Parameternamen für die Identifizierung von Objekten angeben zu müssen.

Um beispielsweise ein auf der Serverebene aktiviertes Modul zu deaktivieren, gehen Sie wie folgt vor:AppCmd delete module MyModule

Dies funktioniert bei verwalteten und systemeigenen Modulen, allerdings mit einer kleinen Einschrän-kung: Wenn Sie ein systemeigenes Modul deaktivieren, können Sie es einfach mit dem Befehl Add Module /name:ModuleName wieder aktivieren. Wenn Sie jedoch ein verwaltetes Modul deaktivieren, müssen Sie dessen vollständigen Typ angeben, um es wieder zu aktivieren. Wenn Sie ein verwaltetes Modul auf der Ebene, wo es zuerst definiert wurde, löschen, können die Typinformationen, die Sie möglicherweise für ein späteres erneutes Hinzufügen benötigen, verloren gehen.

Aktivierte Module untersuchenZusätzlich zum Installieren/Deinstallieren und Aktivieren/Deaktivieren von Modulen unterstützt Appcmd mit dem LIST-Befehl auch eine Untersuchung der aktivierten Module. Dies kann sich als nützlich erweisen, wenn Sie Probleme mit Modulen diagnostizieren, weil Sie auf diese Weise schnell ermitteln können, welche Module für eine bestimmte Anwendung aktiviert sind oder ob ein bestimmtes Modul aktiviert ist.

Der List Module-Befehl wird wie die LIST-Befehle anderer Appcmd-Objekte verwendet und ermöglicht es Ihnen, alle Module anzeigen zu lassen und mit einer spezifischen Abfrage nach bestimmten Modulen zu suchen. Die einfachste Verwendungsmöglichkeit besteht darin, alle Module auflisten zu lassen, die auf der Serverebene aktiviert sind.AppCmd list modules

Um festzustellen, welche Module für eine bestimmte Anwendung aktiviert sind, benutzen Sie den Para-meter /app.name:AppPath, um den Anwendungspfad anzugeben, für den die aktivierten Module angezeigt werden sollen.



Hinweis Da Anwendungen bestimmte Module entfernen oder neue hinzufügen können, weicht ihr Modulsatz oft von dem des Servers ab. Wenn Sie Probleme mit einer Anwendung untersuchen, sollten Sie deshalb darauf achten, die Modulliste dieser Anwendung zu überprüfen.

Sie können ebenfalls Abfragen angeben, die auf Modulattributen wie precondition und type basieren, um die Module zu finden, die diese Attribute nutzen. Um beispielsweise nach allen verwalteten Modulen zu suchen, deren managedHandler-Vorbedingung gesetzt ist, können Sie den folgenden Code verwenden:AppCmd list modules "/type:$<>" "/precondition:$=*managedHandler*"

Sie können ebenfalls nach spezifischen Modulen suchen, indem Sie den Modulnamen als Bezeichner angeben.AppCmd list module DefaultDocumentModule

Handlerzuordnungen erstellen und verwaltenObwohl Appcmd das übergeordnete Objekt Module für die Verwaltung von Modulen anbietet, bietet es keine übergeordnete Ansicht der Handlerzuordnungskonfiguration. Sie können jedoch immer das CONFIG-Objekte nutzen, um den Konfigurationsabschnitt system.webServer/handlers direkt zu verwalten und alle notwendigen Handlerzuordnungsverwaltungsaufgaben auszuführen.

Eine vollständige Beschreibung der Auflistungsbearbeitungssyntax des CONFIG-Objekts ist im Rahmen dieses Abschnitts nicht möglich (lesen Sie dazu das siebte Kapitel), aber nachfolgend sind einige Beispiele aufgeführt, die zeigen, wie die Syntax genutzt wird, um grundlegende Handlerzuordnungs-verwaltungsaufgaben zu lösen.

Handlerzuordnungen hinzufügenUm einem systemeigenen Modul eine Handlerzuordnung hinzuzufügen, lassen Sie den folgenden Befehl ausführen (bitte ohne manuelle Zeilenumbrüche eingeben):AppCmd set config /section:handlers "/+[name='TestHandler',path='*test', verb='GET,POST,HEAD',modules='TestModule']"


Daraufhin wird eine Handlerzuordnung der Serverebene hinzugefügt, die GET-, POST- und HEAD-Anforde-rungen, die sich auf *.test-URLs beziehen, dem systemeigenen Modul TestModule zuordnet. Lediglich die Attribute name, path und verb müssen angegeben werden (außerdem sollte das modules-Attribut der Handler-zuordnung des systemeigenen Moduls gesetzt werden). Alle anderen anwendbaren Attribute können Sie optional setzen. Sie könnten beispielsweise ebenfalls, wie im folgenden Beispiel gezeigt, den Konfigurationspfad festlegen, für den diese Zuordnung hinzugefügt werden soll, anstatt diese auf der Serverebene anzuordnen.

Um einen verwalteten Handlertyp eine Handlerzuordnung hinzuzufügen, lassen Sie den folgenden Befehl (bitte ohne manuelle Zeilenumbrüche eingegeben) ausführen:AppCmd set config "Default Web Site/" /section:handlers "/+[name='ASPNHandler',path='*.aspn',verb='*', type='MyHandlers.ASPNHandler',precondition='integratedMode']"

Daraufhin wird für den Stamm der Website Default Web Site eine Handlerzuordnung hinzugefügt, die dem .NET-Handlertyp MyHandlers.ASPNHandler alle Anforderungen zuordnet, die sich auf *.aspn-URLs beziehen. Beachten Sie, dass ebenfalls eine Vorbedingung für die Handlerzuordnung definiert ist, die festlegt, dass sie nur in solchen Anwendungspools verwendet werden darf, die im integrierten Modus



arbeiten. Dies ist für mit verwalteten Typen verknüpfte Handlerzuordnungen notwendig, da nur der integrierte Modus das direkte Hinzufügen von verwalteten Handlertypen innerhalb von IIS-Handler-zuordnungen unterstützt.

Handlerzuordnungen bearbeitenUm eine Handlerzuordnung zu bearbeiten, verwenden Sie den folgenden Code:AppCmd set config /section:handlers /[name='TestHandler'].verb:GET

Hier wird das verb-Attribut der über den Namen TestHandler identifizierten Handlerzuordnung auf den neuen Wert GET gesetzt. Beachten Sie, dass das name-Attribut als eindeutiger Auflistungsschlüssel für den Konfigurationsabschnitt handlers dient.

Sie können diese Syntax nutzen, um alle Handlerzuordnung so Attribute zu bearbeiten. Sie können ebenfalls eine auf der Default Web Site/-Ebene erzeugte Handlerzuordnung bearbeiten, indem Sie diesen Pfad hinter dem SET CONFIG-Befehl angeben.

Handlerzuordnungen löschenUm eine Handlerzuordnung zu löschen, können Sie das Präfix /- verwenden, mit dessen Hilfe Sie Konfigurationsauflistungselemente entfernen.AppCmd set config /section:handlers /-[name='TestHandler']

Dies löscht die zuvor von Ihnen erstellte Handlerzuordnung, die über den Namen TestHandler identifiziert wird. Sie können ebenfalls eine auf der Default Web Site/-Ebene erzeugte Handlerzuordnung löschen, indem Sie diesen Pfad hinter dem SET CONFIG-Befehl angeben.

Der ISAPI-CGI-Einschränkungsliste (früher Webdiensteinschränkungsliste) Einträge hinzufügenWenn Sie Handlerzuordnungen erstellen, die CgiModule oder IsapiModule benutzen, um CGI-Programme oder ISAPI-Erweiterungen zu unterstützen, müssen Sie ebenfalls das jeweilige CGI-Programm oder die jeweilige ISAPI-Erweiterung zulassen, indem Sie der ISAPI-CGI-Einschränkungsliste einen entspre-chenden Eintrag hinzufügen. Bei IIS 6.0 ist diese Liste als Webdiensteinschränkungsliste bekannt. Sie ist eine wichtige Sicherheitsmaßnahme, um die Ausführung von Drittanbietercode auf dem Server zu kontrollieren.

Um beispielsweise der Liste system.webServer/security/isapiCgiRestriction eine ISAPI-Erweiterungs-DLL hinzuzufügen, benutzen Sie den folgenden Befehl:appcmd set config /section:isapiCgiRestriction /+[path='c:\myisapi.dll', allowed='true']

Um einen bereits in der Liste vorhandenen Eintrag zuzulassen (oder nicht zuzulassen), benutzen Sie den folgenden Befehl:appcmd set config /section:isapiCgiRestriction /[path='c:\myisapi.dll'].allowed:true

Um einen Eintrag aus der Liste zu entfernen, verwenden Sie den folgenden Befehl:appcmd set config /section:isapiCgiRestriction /-[path='c:\myisapi.dll']

Sie können in dieser Liste sowohl CGI-Programme (ausführbare Dateien) als auch ISAPI-Erweite-rungen (DLLs) angeben.



Hinweis Ausführbare Dateien von FastCGI-Programmen werden der isapiCgiRestriction-Liste nicht hinzugefügt. Sie müssen stattdessen im system.webServer/fastCGI-Konfigurationsabschnitt registriert werden, damit FastCGI-Anwendungspools für diese ausführbaren Dateien erstellt werden können.

Webservermodule sichernDie Erweiterbarkeitsarchitektur von IIS 7.0 basiert größtenteils auf der Erkenntnis, dass es nicht der Server, sondern die darauf ausgeführte Anwendung ist, die den Unterschied ausmacht. Wie die Geschichte zeigt, ist es in der Regel leider auch die Anwendung, die der Grund für Sicherheitsver-letzungen ist. Der bei IIS 6.0 auf Sperrungen basierende Sicherheitsansatz – der die Möglichkeit einschränkt, neuen Code auf dem Server auszuführen und der die Rechte dieses Codes beschränkt – erwies sich hinsichtlich der Verringerung von Sicherheitslücken auf dem Webserver als immens erfolg-reich. Bei IIS 7.0 müssen die Serveradministratoren nun einen Mittelweg zwischen der durch das neue Erweiterbarkeitsmodell hervorgebrachten Funktionalität und der Serversicherheit finden. Deshalb ist es jetzt wichtiger als jemals zuvor, die Auswirkungen zu verstehen, die die Erweiterbarkeit des Servers auf die Sicherheit hat. Sie sollten wissen, wie diese Erweiterbarkeit eingeschränkt werden kann, um eine Schwächung der Sicherheit Ihres Servers zu verhindern.

Wenn es darum geht, den Server zu sichern, ist eines der größten Probleme, mit denen die Administ-ratoren heute konfrontiert werden, der Umgang mit der Komplexität des Systems und die Fähigkeit, wichtige empfohlene Sicherheitspraktiken anzuwenden, anstatt sich in Details zu verlieren. Dieser Ansatz ermöglicht es Ihnen, das allgemeine Sicherheitsrisiko für den Server wesentlich zu verringern, obwohl er kein Ersatz für ein richtiges Sicherheitsrisikomodell und Penetrationstests auf der Anwen-dungsebene ist. Im Grunde müssen Sie in der Lage sein, die folgende Frage zu beantworten: Voraus-gesetzt, Sie können nicht darauf vertrauen, dass der auf Ihrem Server ausgeführte Code absolut narren-sicher ist, wie können Sie dann kontrollieren, was dieser Code darf und was er nicht darf, und wie können Sie gleichzeitig verhindern, dass Ihr Server gefährdet ist, wenn dieser Code Sicherheitslücken aufweist?

Um diese Frage zu beantworten, sollten Sie sich der Antwort in mehreren Schritten nähern. Zuerst müssen Sie wissen, wie Sie die Angriffsfläche des Servers auf ein Mindestmaß verringern, indem Sie die gesamte Funktionalität entfernen, die für den Betrieb des Servers nicht notwendig ist. Zweitens müssen Sie die Berechtigungen des auf dem Server ausgeführten Codes verstehen und diese so weit wie möglich einschränken. Schließlich dürfen Sie nicht die Kontrolle über die Erweiterbarkeit verlieren, die auf dem Server zulässig ist. Dazu müssen Sie verhindern, dass unerwünschte Funktionalität hinzu-gefügt oder erwünschte Funktionalität entfernt wird. Sie sollten ebenfalls die im vierzehnten Kapitel, »Implementieren von Sicherheitsstrategien«, beschriebenen Verfahren nutzen, um einzelne Features zu sichern.

Die Komponentenarchitektur für die Verringerung der Angriffsfläche des Servers nutzenUm einen Webserver vollständig zu sichern, müssen Sie ihn vom Netzwerk trennen, den Netzstecker herausziehen und das Gerät einbetonieren. Dies würde die Sicherheit gewährleisten, da jede gefährliche Interaktion mit dem System ausgeschlossen wäre. Da dies jedoch auch zu einem nutzlosen Webserver führen würde, müssen Sie andere Wege finden, um das Sicherheitsprinzip zur Verringerung der Angriffs-fläche anwenden zu können.



Die Fähigkeit von IIS 7.0, nahezu alle Features des Webservers entfernen zu können, ist sehr wichtig, da sie es uns ermöglicht, die Gefahr eines möglicherweise in solchen Features vorhandenen bekannten oder unbekannten Angriffswegs zu eliminieren. Darüber hinaus verringert das Entfernen zusätzlicher Funktionalität den Verwaltungsaufwand und die Möglichkeit, dass Ihr Server in den Offlinezustand gezwungen wird, wenn Patches für die entfernten Features verfügbar werden. Sie können diese Fähig-keit wie folgt nutzen:

1. Ermitteln Sie die Features, die Sie für Ihren Server/Ihre Anwendung benötigen.

2. Installieren Sie mit dem Windows-Setup nur die benötigten IIS 7.0-Features.

3. Entfernen Sie manuell alle von Ihrer Anwendung nicht benötigten Module.

Am Ende des zweiten Schrittes sollten Sie über die notwendige globale Mindestfunktionalität für Ihren Server verfügen. Sie können dann die Angriffsfläche weiter verkleinern, indem Sie die Module deakti-vieren, die Sie für Ihre Anwendungen nicht benötigen. Dies ist natürlich nur in solchen Fällen möglich, in denen eine Anwendung eine etwas andere Serverfunktionalität benötigt.

In einigen anderen Fällen müssen Sie Module für den gesamten Server deaktivieren, wenn das Setup-paket keine detailliertere Auswahl zulässt. Dies trifft oft auf die ASP.NET-Komponente zu, für die immer alle ASP.NET-Module und -Handler installiert werden, und zwar unabhängig davon, ob diese von Ihrer Anwendung benötigt werden.

Direkt von der Quelle: Der sicherste Webserver der WeltAls während der TechEd 2005 IIS 7.0 vorgestellt wurde, zeigte meine erste Präsentation »den sicher-sten Webserver der Welt«, der sich aus der komponentenbasierten Architektur von IIS 7.0 ergab.

Ein Teil der Demonstration bestand darin, dass ich zeigte, wie die Konfiguration in der Datei applicationHost.config bearbeitet wird. Ich entfernte alle Module und Handlerzuordnungen. Nach dem Speichern der Datei übernahm IIS die Änderungen und führte einen Neustart durch, wobei natürlich keine Module geladen wurden. Nachdem ich eine Anforderung der Standardwebsite ein-gereicht hatte, erhielt ich sofort eine leere Antwort vom Typ 200 zurück (diese Konfiguration gibt gegenwärtig einen Fehler aufgrund einer fehlenden Autorisierung vom Typ 401 zurück, weil keine Authentifizierungsmodule vorhanden sind). Der Server hatte keine Module geladen und führte deshalb nahezu keine Verarbeitung der Anforderung durch, weshalb auch keine Inhalte zurückge-geben wurden. Der Server war somit zum sichersten Webserver der Welt geworden. Nach einer kurzen Pause wies ich daraufhin, dass dieser Server zwar sicher, aber völlig nutzlos sei, und dann ging ich dazu über, die Funktionalität wieder hinzuzufügen, die ich für meine Anwendung benötigte.

Ich hatte diese Demonstration schon früher einem ausgesuchten Publikum präsentiert und Beifall dafür erhalten, aber ich werde nie vergessen, wie das Publikum während der TechEd-Vorführung reagierte. Die Menschen im Publikum gerieten außer Rand und Band und ließen sich teilweise sogar zu stehenden Ovationen hinreißen. Das war eine überwältigende Bestätigung unserer Bemühungen, Administratoren die Möglichkeit zu bieten, einen Server von Grund auf neu und nur mit den wirklich benötigten Features aufzubauen, so dass ein einfach zu verwaltender Webserver mit der geringst-möglichen Angriffsfläche entsteht.

Mike Volodarsky

Program Manager, IIS 7.0



Klingt einfach, richtig? Leider hält der erste Schritt die größte Herausforderung bereit, also die Ermittlung der von Ihrer Anwendung benötigten Features. Dazu müssen Sie wissen, welche Funktionalität sicher entfernt werden kann, so dass sich keine negativen Auswirkungen auf den Betrieb Ihrer Anwendung ergeben und deren Sicherheit nicht gefährdet wird. Sie haben richtig gelesen – Sie können dafür sorgen, dass Ihr Server sehr viel weniger sicher ist, wenn Sie ein sicherheitsrelevantes Feature entfernen. Wenn Sie beispielsweise ein Autorisierungsmodul entfernen, das für die Überprüfung des Zugriffs auf eine Verwaltungsseite Ihrer Anwendung verantwortlich ist, kann dies dazu führen, dass anonyme Benutzer Ihren Server verwalten können! Ähnlich hierzu kann das Entfernen bestimmter Features eine geringere Leistung und Stabilität zur Folge haben. Es kann aber auch dazu beitragen, dass Ihre Anwendung schlicht und einfach nicht mehr funktioniert.

Vorsicht Es ist möglich, dass die IIS-Konfiguration ein IIS-Feature für die Bereitstellung einer bestimmten Funktion einrichtet, der Server diese Funktion aber nicht bieten kann, wenn das für diese Funktion verantwortliche Modul nicht aktiviert ist. Dies kann geschehen, wenn jemand das Modul deaktiviert oder dessen Vorbedingungen so konfiguriert, dass es in einem bestimmten Anwendungspool nicht ausgeführt werden kann. Deshalb müssen Sie sicherstellen, dass die benötigten Module vorhanden und mit den richtigen Vorbedingungen versehen sind, so dass der korrekte Betrieb Ihrer Anwendung gewährleistet bleibt.

Es ist somit wichtig, dass Sie verstehen, welche Features von Ihren Anwendungen benötigt werden und für welche Features dies nicht gilt. Um dies zu erfahren, können Sie Tabelle 12.9 konsultieren, die beschreibt, welche Rolle jedes integrierte IIS 7.0-Modul spielt, dessen Entfernung auf dem Server Auswirkungen auf die Sicherheit haben kann.

Tabelle 12.9 Funktion und Sicherheitsauswirkungen der integrierten Module

Modul Zweck und Effekt bei Entfernung

Modul für die anonyme Authentifizierung

Zweck: Authentifiziert eine Anforderung unter Verwendung der Identität des anonymen Benutzers, wenn kein anderer Authentifizierungsmechanismus existiert

Bei Entfernung: Der Zugriff auf Ressourcen wird für anonyme Anforderungen verweigert

Modul für die Standard-authentifizierung

Zweck: Unterstützt die Standardauthentifizierung

Bei Entfernung: Clients können nicht mithilfe der Standardauthentifizierung authentifiziert werden

Modul für die Authenti-fizierung über eine Zertifikatzuordnung

Zweck: Unterstützt die ClientzertifikatauthentifizierungBei Entfernung: Clients können nicht mithilfe von Clientzertifikaten authentifiziert werden

Modul für die Konfigura-tionsdelegierung

Zweck: Validiert ASP.NET-Konfigurationen im integrierten Modus

Bei Entfernung: Warnung – ASP.NET-Anwendungen, die unter Verwendung der alten Konfiguration Module und Handler definieren, werden ebenfalls im integrierten Modus ausgeführt, doch die Module werden nicht geladen. Dies kann bei nicht migrierten ASP.NET-Anwendungen zu einem unerwarteten Verhalten und Sicherheitsrisiken führen.

CustomError-Modul Zweck: Detaillierte Fehlernachrichten werden für IIS-Fehler nicht generiert

Bei Entfernung: Warnung – Anwendungsfehlerinformationen werden möglicherweise zu den Remote-clients gesendet



Standardmäßige Authentifizierung

Zweck: Unterstützt das ASP.NET-Ereignis DefaultAuthentication_OnAuthenticateWenn ASP.NET so konfiguriert ist, dass es den Formularauthentifizierungsmodus verwendet, kann ein Entfernen dieses Moduls bei anonymen Anforderungen zu Fehlern in anderen ASP.NET-Modulen führenBei Entfernung: Warnung – Das Ereignis DefaultAuthentication_OnAuthenticate wird nicht ausgelöst, so dass jeder benutzerdefinierte Authentifizierungscode, der von diesem Ereignis abhängig ist, nicht aus-geführt wird. Dies ist nicht üblich.

Modul für die Digest-authentifizierung

Zweck: Unterstützt die DigestauthentifizierungBei Entfernung: Clients können nicht unter Verwendung der Digestauthentifizierung authentifiziert werden

Dateiautorisierung Zweck: Verifiziert, dass der authentifizierte Client Zugriff auf die physikalischen Ressourcen hat

Bei Entfernung: Warnung – Der authentifizierte Benutzer kann möglicherweise auf Ressourcen zugreifen, für die er keine Berechtigungen besitzt

Formularauthentifizierung Zweck: Unterstützt die formularbasierte AuthentifizierungBei Entfernung: Clients können nicht unter Verwendung der Formularauthentifizierung authentifiziert werden

HttpCache-Modul Zweck: Unterstützt die IIS-Ausgabezwischenspeicherung und das Zwischenspeichern von Antworten im Kernelcache

Bei Entfernung: Warnung – Es erfolgt keine Ausgabezwischenspeicherung, was möglicherweise zu einer größeren Auslastung des Servers und im schlimmsten Fall zu einer DoS-Situation (Denial-of-Service) führen kann

HttpLogging-Modul Zweck: Unterstützt die Anforderungsprotokollierung

Bei Entfernung: Warnung – Anforderungen werden nicht protokolliert

Modul für die Authenti-fizierung über die IIS- Zertifikatzuordnung

Zweck: Unterstützt die auf der IIS-Konfiguration basierende Clientzertifikatauthentifizierung

Bei Entfernung: Clients können nicht unter Verwendung der auf der IIS-Konfiguration basierenden Clientzertifikatauthentifizierung authentifiziert werden

HttpRedirection-Modul Zweck: Unterstützt Umleitungsregeln, die auf der Konfiguration basieren

Bei Entfernung: Warnung – Wenn die Anwendung auf Umleitungsregeln angewiesen ist, um den Zugriff auf Inhalte zu beschränken, kann ein Entfernen dieses Moduls dazu führen, dass Ressourcen, die andernfalls geschützt wären, verfügbar werden

IsapiFilter-Modul Zweck: Unterstützt ISAPI-Filter

Bei Entfernung: Warnung – ISAPI-Filter, die einen Zugriff durchsetzen oder andere Sicherheitsfunktio-nen aufweisen, werden nicht ausgeführt

OutputCache Zweck: Unterstützt die Ausgabezwischenspeicherung von ASP.NET-Antworten

Bei Entfernung: Warnung – Die Ausgabezwischenspeicherung von ASP.NET-Antworten erfolgt nicht, was möglicherweise zu einer größeren Auslastung des Servers und im schlimmsten Fall zu einer DoS-Situation (Denial-of-Service) führen kann

RequestFiltering-Modul Zweck: Setzt verschiedene Anforderungseinschränkungen durch und schützt versteckte Inhalte

Bei Entfernung: Warnung – Ein Entfernen dieses Moduls kann dazu führen, dass geschützte Inhalte bereit-gestellt werden. Es kann außerdem unspezifische Sicherheitsverletzungen verursachen, deren Ursache darin besteht, dass alle Anforderungen ungefiltert von der Anwendung entgegengenommen werden.

Tabelle 12.9 Funktion und Sicherheitsauswirkungen der integrierten Module (Fortsetzung)




Sie sollten nach der Bereitstellung immer überprüfen, ob die Anwendung wirklich über alle benötigten Module verfügt. Darüber hinaus sollten Sie die Anwendung im Falle einer Modulkonfigurations-änderung immer testen, um sicherzustellen, dass sie mit dem neuen Modulsatz problemlos funktioniert. Ausgerüstet mit dem Wissen um die Module, die sicher entfernt werden können, verfügen Sie über die Möglichkeit, die Modularität von IIS 7.0 zu nutzen, um die Angriffsfläche Ihres Servers zu verkleinern, ohne dessen Sicherheit einzuschränken.

Die Berechtigungen des auf Ihrem Server ausgeführten Codes verstehen und einschränkenNachdem Sie nun die Angriffsfläche Ihres Servers auf ein akzeptierbares Minimum verkleinert haben, müssen Sie noch die verbleibende Funktionalität sichern. Dies geschieht in der Regel mithilfe von zwei Verfahren: durch das Einschränken des Anwendungsinputs, indem Sicherheitsfeatures wie die Autori-sierung und Anforderungsfilterung (die IIS 7.0-Version von UrlScan) genutzt werden, und durch das Einschränken der Berechtigungen, mit denen der Anwendungscode ausgeführt wird, so dass dieser selbst bei einer Kompromittierung nur begrenzten Schaden anrichten kann. Weitere Informationen zu diesen beiden Ansätzen erhalten Sie im vierzehnten Kapitel.

Der erste Ansatz ist eine Erweiterung des bereits vorgestellten Verfahrens zur Verringerung der Angriffsfläche. Er versucht, möglichst viele Angriffswege zu blockieren, indem er den Serverinput einschränkt. Der zweite Ansatz nutzt das Prinzip der Vergabe von geringstmöglichen Berechtigungen und konzentriert sich darauf, was geschieht, wenn die Funktionalität auf dem Server kompromittiert

RoleManager Zweck: Unterstützt die ASP.NET-RollenfunktionalitätBei Entfernung: Warnung – Rollen für die authentifizierten Benutzer sind möglicherweise nicht ver-fügbar, was sich auf Autorisierungsentscheidungen auswirken kann. In der Regel schränkt dies den Zugriff lediglich ein, doch in einigen Fällen, wenn der Zugriff basierend auf Rollen verweigert wird, kann es dazu führen, dass nicht autorisierte Benutzer Zugriff erhalten.

Modul für die statische Komprimierung

Zweck: Unterstützt die Komprimierung statischer Ressourcen

Bei Entfernung: Warnung – Ein Entfernen dieses Moduls kann für die Site zu einem höheren Band-breitenverbrauch führen, weil dann die Komprimierung statischer Inhalte deaktiviert ist

URL-Autorisierung Zweck: Unterstützt deklarative Zugriffsregeln

Bei Entfernung: Warnung – URL-Zugriffsautorisierungsregeln werden ignoriert, und nicht autorisierte Benutzer können Zugriff erhalten

Modul für die ASP.NET-URL-Autorisierung

Zweck: Unterstützt deklarative ASP.NET-Zugriffsregeln

Bei Entfernung: Warnung – ASP.NET-URL-Autorisierungszugriffsregeln werden ignoriert, und nicht autorisierte Benutzer können Zugriff erhalten

Windows-Authenti-fizierung

Zweck: Unterstützt die NTLM- und Kerberos-AuthentifizierungBei Entfernung: Clients können nicht unter Verwendung der NTLM- oder Kerberos-Windows-Authenti-fizierung authentifiziert werden

Modul für die Windows-Authentifizierung

Zweck: Unterstützt das Auslösen des ASP.NET-Ereignisses WindowsAuthentication_OnAuthentication

Bei Entfernung: Warnung – Das Ereignis WindowsAuthentication_OnAuthenticate wird nicht ausgelöst, so dass jeder benutzerdefinierte ASP.NET-Authentifizierungscode, der von diesem Ereignis abhängig ist, nicht ausgeführt wird. Beachten Sie, dass dieses Modul für die Windows-Authentifizierung nicht not-wendig ist.

Tabelle 12.9 Funktion und Sicherheitsauswirkungen der integrierten Module (Fortsetzung)




wird. Wenn Sie wissen, wie der Erweiterbarkeitscode im IIS-Kontext ausgeführt wird, können Sie dessen Berechtigungen verringern, was eine Kompromittierung des Servers oft erschwert oder sogar unmöglich macht. Dieses Wissen hilft Ihnen außerdem, zu verstehen, welche Vertrauensebenen beim Hinzufügen von Features oder Anwendungskomponenten zum Server verwendet werden sollten.

Tabelle 12.10 beschreibt die Berechtigungen, mit denen IIS-Webservermodule auf dem Server aus-geführt werden.

Die IIS-Erweiterbarkeitskomponenten werden meistens in über längere Zeiträume ausgeführten IIS-Arbeitsprozessen gehostet (alles, außer CGI- und FastCGI-Programme, die prozessextern ausgeführt werden), die mit der konfigurierten Anwendungspoolidentität (standardmäßig NETZWERKDIENST) arbeiten. Dazu zählen systemeigene Module, aber auch ISAPI-Erweiterungen und -Filter (verwaltete Module und Handler zählen ebenfalls dazu, stellen aber ein zusätzliches eingeschränktes Ausführungs-modell zur Verfügung, das später in diesem Kapitel beschrieben wird). Dieser Code kann somit alles tun, wozu auch die Anwendungspoolidentität in der Lage ist. Was erlaubt ist, bestimmen die Berechti-gungen, die der Identität vom System gewährt wurden, sowie die Rechte für Windows-Ressourcen, die von den entsprechenden ACLs stammen. Beim Übergang von IIS 5.1 zu IIS 6.0 erfolgte eine Berechti-gungseinschränkung. Arbeitete IIS 5.1 noch mit der Identität Lokaler Dienst, verwendete IIS 6.0 bereits die NETZWERKDIENST-Identität. Dies stellte eine grundlegende Verbesserung der Sicherheit dar, die dazu führte, dass IIS 6.0 einen bemerkenswerten Sicherheitsrekord aufstellte. Im vierzehnten Kapitel erfahren Sie, wie Sie das Einschränken der Berechtigungen von IIS-Anwendungspools nutzen können.

Denken Sie daran, dass trotz aller anderen möglicherweise zum Einsatz kommenden Einschränkungs-maßnahmen (einschließlich der Codezugriffssicherheit von ASP.NET), die Berechtigungen und Rechte des den Code enthaltenden Arbeitsprozesses festlegen, was dieser Code darf und was er nicht darf (bei einem Identitätswechsel müssen Sie ebenfalls die Rechte und Berechtigungen berücksichtigen, die mit

Tabelle 12.10 Modulberechtigungen

Feature Ausführungsgültigkeitsbereich Berechtigungsebene Wer hinzufügen darf

Systemeigene Module IIS-Arbeitsprozess Anwendungspoolidentität Administrator

Verwaltete Module und Handler

ASP.NET-Anwendungsdomäne (appdomain)

Anwendungspoolidentität

ODER

Authentifizierter Benutzer

UNDDurch ASP.NET-Vertrauensebene eingeschränkt

Anwendungsbesitzer

ISAPI-Filter IIS-Arbeitsprozess Anwendungspoolidentität Administrator

ISAPI-Erweiterungen IIS-Arbeitsprozess Authentifizierter Benutzer (Standard)

ODERAnwendungspoolidentität

Administrator

CGI-Programme CGI-Programmprozess (Einzelan-forderung)

Authentifizierter Benutzer (Standard)ODER

Anwendungspoolidentität

Administrator

FastCGI-Programme FastCGI-Programmprozess Anwendungspoolidentität Administrator



der angenommenen Identität verknüpft sind). Wenn Sie somit anders ausgedrückt dem Server Code hinzufügen – selbst wenn es sich nur um Anwendungscode handelt – sollten Sie davon ausgehen, dass dieser Code alles tun kann, wozu auch Ihr Arbeitsprozess in der Lage ist. Indem Sie Anwendungspools mit den geringstmöglichen Berechtigungen verwenden, können Sie im Falle einer Anwendungs-kompromittierung den Schaden am Server äußerst gering halten.

Eine andere Situation ergibt sich, wenn Sie mit verwalteten (ASP.NET) Modulen und Handlerkompo-nenten arbeiten. Diese Komponenten werden innerhalb einer ASP.NET-Anwendung gehostet und nicht nur durch den IIS-Arbeitsprozess, sondern auch durch die für die ASP.NET-Anwendungsdomäne (appdomain) konfigurierte CAS-Richtlinie (Code Access Security, Codezugriffssicherheit) beschränkt. Dies bedeutet, dass verwaltete Module und Handler mit Berechtigungen ausgeführt werden können, die weniger umfassend als die von der IIS-Arbeitsprozessidentität gewährten Berechtigungen sind.

ASP.NET-Anwendungen sind so konfiguriert, dass sie mit voller Vertrauenswürdigkeit ausgeführt werden, was bedeutet, dass sie nicht zusätzlich eingeschränkt sind. Wenn eine Anwendung über den Konfigurationsabschnitt system.web/trust für die Ausführung unter Verwendung einer geringeren Vertrau-ensebene konfiguriert wird, können Sie für die Ausführung von .NET-Code zusätzliche Einschrän-kungen festlegen, die verwaltete Module von der Durchführung bestimmter Aktionen und den Zugriff auf solche Ressourcen ausschließen, die sich außerhalb der Anwendungsunterverzeichnisse befinden. Weitere Informationen zu den integrierten Vertrauensebenen finden Sie im vierzehnten Kapitel.

Hinweis Sie können den IIS-Manager ebenfalls verwenden, um die Standardvertrauensebene für ASP.NET-Anwendungen oder die Vertrauensebene für eine bestimmte Anwendung Ihres Servers zu konfigurieren.

Die empfohlene Vertrauensebene ist Mittel. Auf dieser Vertrauensebene ist es der Anwendung nicht möglich, auf Ressourcen zuzugreifen, die ihr nicht zugeordnet sind, obwohl sie weiterhin die meisten ASP.NET-Features nutzen und Code ausführen kann, der ihren Betrieb betrifft. Auf dieser Vertrauens-ebene sind viele Anwendungen, die innerhalb desselben Anwendungspools ausgeführt werden, größ-tenteils voneinander isoliert, weshalb diese Ebene für das Shared Hosting verwendet werden sollte (obwohl es besser ist, jeden Kunden in einem separaten, vollständig isolierten Anwendungspool zu hosten), wo gehostete Anwendungen Code auf den Server uploaden dürfen.

Sie sollten, wo dies möglich ist, die Vertrauensebene Mittel nutzen, um die Berechtigungen der verwal-teten Komponenten Ihrer Anwendungen weiter einzuschränken. Achten Sie aber darauf, dass einige ASP.NET-Anwendungen oder Module bei einer mittleren Vertrauenswürdigkeit nicht funktionieren. Der Grund hierfür ist die Nutzung von .NET-APIs, die eine höhere Vertrauensebene verlangen. Die Zahl solcher Anwendungen geht jedoch aufgrund von API-Verbesserungen im .NET Framework 2.0+ und Anwendungsverbesserungen, die einen Betrieb bei teilweiser Vertrauenswürdigkeit ermöglichen, stetig zurück. Die ASP.NET-Laufzeit kann außerdem bei einer teilweisen Vertrauenswürdigkeit mit Leistungseinbußen konfrontiert werden. Dies sollte im Einzelfall überprüft werden, um festzustellen, ob dieser Faktor ausschlaggebend genug ist, um höhere Vertrauensebenen zu rechtfertigen.

Hinweis Obwohl ASP.NET-Vertrauensebenen eine zusätzliche Möglichkeit bieten, um die Ausführung von ver-walteten Code auf Ihrem Server einzuschränken, sollten Sie sie nicht als Ersatz für das Einschränken der Berechtigungen des hostenden IIS-Arbeitsprozesses verwenden.

CGI- und FastCGI-Programme werden nicht innerhalb des IIS-Arbeitsprozesses gehostet, sondern in eigenen, vom IIS-Arbeitsprozess generierten Prozessen ausgeführt. CGI-Programme werden standard-mäßig unter der Identität des authentifizierten Benutzers ausgeführt, obwohl Sie sie für die Ausführung



unter der Identität des Arbeitsprozesses konfigurieren können. Wenn Sie deshalb CGI-Programme verwenden, sollten Sie sich des Umstandes bewusst sein, dass der Code über die Berechtigungen des aufrufenden Benutzers verfügt. Wenn dieser Benutzer auf dem Server ein Administrator ist, kann der Code administrative Aufgaben ausführen, die zu einer Kompromittierung des Servers führen, sofern der Code erfolgreich für einen Angriff genutzt wird.

Hinweis Wenn Sie im Rahmen eines Identitätswechsels mit der anonymen Authentifizierung arbeiten, wird das neue IIS_IUSR-Konto benutzt, um die auf CGI, FastCGI und ISAPI-Erweiterungen basierenden Anwendungen auszuführen (sofern der Server nicht so konfiguriert ist, dass stattdessen die Prozessidentität zum Einsatz kommt). Wenn Sie das IIS_IUSR-Konto nur benutzen, um für den ausführenden Code geringere Berechtigungen zu erhal-ten, als die Arbeitsprozessidentität zur Verfügung stellt, sollten Sie darüber nachdenken, stattdessen die Arbeits-prozessidentität zu benutzen, weil Sie dann ein Konto weniger verwalten müssen. Setzen Sie dazu das userName-Attribut des Abschnitts anonymousAuthentication auf "".

FastCGI-Programme werden immer unter der Identität des IIS-Arbeitsprozesses ausgeführt, so dass sie dieselben Berechtigungen wie ein in diesem Prozess ausgeführter Code besitzen. FastCGI bietet einem FastCGI-Programm die Möglichkeit, die Identität des authentifizierten Benutzers anzunehmen, was mit PHP im FastCGI-Modus möglich ist. In diesem Fall muss dem im Arbeitsprozess ausgeführten Code dieselbe Aufmerksamkeit wie bei der Ausführung von CGI-Programmen geschenkt werden.

Wichtig In vielen Fällen nimmt der Servercode die Identität des authentifizierten Benutzers an. Dies geschieht standardmäßig für alle ISAPI-Erweiterungen, ASP-Seiten, PHP-Seiten, die im CGI-, ISAPI- oder FastCGI-Modus ausgeführt werden, und ASP.NET-Anwendungen, die einen Identitätswechsel ermöglichen. Wenn der Identitäts-wechsel genutzt wird, sollten Sie wissen, dass der Code mit äußerst umfassenden Berechtigungen ausgeführt wird, sofern die Anforderung von einem Benutzer eingereicht wird, der auf dem Computer über administrative Berechti-gungen verfügt. Sie sollten ernsthaft darüber nachdenken, administrativen Benutzern die Arbeit mit Ihrer Anwen-dung nur dann zu gestatten, wenn dies absolut notwendig ist.

Das Fazit lautet somit, dass Sie der Quelle des auf Ihrem Server ausgeführten Codes so weit trauen müssen, wie die Berechtigungsebene, auf der die Ausführung erfolgt, reicht. Wenn Sie dem Code nicht vertrauen, müssen Sie gewährleisten, dass er auf einer niedrigeren Berechtigungsebene ausgeführt wird, indem Sie ihn durch eine Anwendungspoolidentität mit nur wenigen Rechten einschränken. Handelt es sich um nativen Code, ist dies alles, was Sie tun können. Ist der Code verwaltet, können Sie die Ebenen der teilweisen ASP.NET-Vertrauenswürdigkeit verwenden, um ihn weiter einzuschränken. Dies ist die Basis, die notwendig ist, damit Anwendungscode von Drittanbietern auf Ihrem Server ausgeführt werden kann.

Wenn Sie dem Code vertrauen, können Sie ihn gegen unvorhergesehene Sicherheitslücken abhärten, indem Sie seine Berechtigungen mit den zuvor in diesem Kapitel beschriebenen Techniken möglichst umfassend einschränken. Obwohl Sie niemals ganz sicher sein können, dass ein Code vollkommen gegen Angriffe gewappnet ist, kann das Prinzip der Vergabe von geringstmöglichen Berechtigungen dazu bei-tragen, dass die Gefahr von Schäden wesentlich verringert oder sogar ganz ausgeschlossen wird.

Einschränken der ErweiterbarkeitNun, da Sie einen Webserver mit einer minimalen Angriffsfläche erstellt haben, der mit den geringst-möglichen Berechtigungen ausgeführt wird, müssen Sie sicherstellen, dass sich dieser Zustand nicht verändert. Wenn Sie mit einem dedizierten Server arbeiten, ist dies weniger ein Problem, weil Sie die



Konfiguration kontrollieren, die festlegt, welche Komponenten aktiviert sind und wie diese ausgeführt werden. Wenn Sie jedoch die Anwendungsverwaltung an jemand anderem delegieren, wie dies bei Shared Hostingsservern und manchmal auch Abteilungsservern der Fall ist, ändert sich die Situation.

Um dies zu verstehen, werfen wir zunächst einen Blick auf die Unterschiede, die hinsichtlich der Dele-gierung der Erweiterbarkeit zwischen IIS 6.0 und IIS 7.0 bestehen. Bei IIS 6.0 kontrolliert der Administ-rator die Serverfunktionalität mithilfe der Metabasis. Wenn ein Benutzer .php3-Seiten über die PHP-Skript Engine bereitstellen möchte, muss er den Administrator kontaktieren, damit dieser eine Handlerzuordnung für die Anwendung des Benutzers erstellt. Dasselbe gilt für das Hinzufügen oder Entfernen eines ISAPI-Filters. Bei IIS 7.0 können Anwendungen in einigen Fällen mithilfe des delegierten Konfigurationssystems Funktionalität entfernen oder hinzufügen. Hierfür sind keine Änderungen auf der Administratorebene notwendig. Auf diese Weise wird die xcopy-Bereitstellung von Anwendungen unterstützt, die ihre eigene Konfiguration und Funktionalität definieren, und die Gesamtbetriebskosten werden verringert. Aus der Sicherheitsperspektive betrachtet ist dies jedoch nicht immer wünschenswert. Deshalb kann der Administ-rator genau kontrollieren, welche Änderungen auf der Anwendungsebene zulässig sind. Dazu wird mithilfe der Konfigurationssperrung die Konfigurationsdelegierung der Konfigurationsabschnitte system.webServer/handlers and system.webServer/modules kontrolliert.

Bei der IIS 7.0-Standardinstallation sind diese beiden Abschnitte auf der Serverebene gesperrt. Dies bedeutet, dass Anwendung A keine neuen Module hinzufügen oder neue Handlerzuordnungen erstellen kann, und Anwendung B kann bereits vorhandene Module oder Handlerzuordnungen nicht entfernen oder ändern.

Dies ist ein sehr eingeschränkter Zustand, der verhindert, dass viele ASP.NET-Anwendungen richtig funktionieren, weil diese oft neue Module deklarieren und neue Handlerzuordnungen erstellen müssen. In diesem Zustand können IIS-Anwendungen in der Regel keine Handlerzuordnungen und Module in ihren Konfigurationen definieren. Deshalb werden diese Abschnitte entsperrt, sobald auf dem Server der Rollendienst .NET-Erweiterbarkeit oder ASP.NET installiert wird. Anwendungen können dann eine Konfiguration festlegen, mit der Folgendes möglich ist:

1. Neue verwaltete Module aktivieren/hinzufügen.

2. Bereits vorhandene Module deaktivieren/entfernen.

3. Neue Handlerzuordnungen hinzufügen.

4. Bereits vorhandene Handlerzuordnungen außer Kraft setzen/entfernen.

Für das Hinzufügen neuer systemeigener Module ist es erforderlich, dass diese auf der Serverebene installiert werden, und für das Hinzufügen neuer ISAPI-Filter/-Erweiterungen und CGI-/FastCGI-Programme sind ebenfalls Konfigurationsänderungen auf der Serverebene notwendig (die Abschnitte isapiCgiRestrictions und fastCgi). Deshalb können Anwendungen keinen neuen nativen Code einführen. Sie können jedoch neue verwaltete Module und Handler einführen. Aus diesem Grund müssen Server-administratoren in solchen Shared-Umgebungen, wo die Anwendungen von den Administratoren als nicht vertrauenswürdig eingestuft werden, eine der folgenden Optionen wählen:

� Durch Sperren der Abschnitte modules und handlers verhindern, dass neue verwaltete Module/Handler hinzugefügt werden. Dies führt dazu, dass viele Anwendungen nicht mehr funktionieren (besonders ASP.NET-Anwendungen, die im integrierten Modus ausgeführt werden).

� Die Vertrauensebene der Anwendung auf die mittlere Vertrauenswürdigkeit setzen, um die Aus-führung des verwalteten Codes zu beschränken.

� Einen Anwendungspool mit geringen Berechtigungen benutzen, um die Anwendung zu hosten.


Zusammenfassung 399

Die Anwendung kann auch standardmäßig jedes der auf der Serverebene definierten Module deaktivieren. Dies kann ein Problem darstellen, wenn der Serveradministrator die Präsenz eines bestimmten Moduls verlangt, z.B. eines Moduls zur Überwachung der Bandbreite oder eines Protokollierungsmoduls, das den Betrieb der Anwendung überwacht. Um der Deaktivierung entgegenzuwirken, kann der Serveradminist-rator jedes Modul sperren, das auf der Serverebene nicht entfernt werden soll. Die Anwendung ist dann nicht mehr dazu in der Lage. Um eine solche Sperrung durchzuführen, wird auf der Serverebene im Konfigurationsabschnitt modules jedem gewünschten Modulelement das Attribut lockItem = "true" hinzu-gefügt. Wenn der modules-Abschnitt nicht gesperrt ist, führt das ASP.NET-Setup automatisch Sperrungen der systemeigenen Module durch, die nicht entfernt werden sollen (in bestimmten Fällen können Sie einige dieser Module entsperren, wenn es Ihnen nichts ausmacht, dass diese dann von der Anwendung deaktiviert werden können).

Da die Anwendung ebenfalls neue Handlerzuordnungen erstellen kann, ist es ihr möglich, auf der Serverebene definierte Zuordnungen außer Kraft zu setzen. Das Sperren funktioniert hier nicht, weil neue Zuordnungen Vorrang vor früheren Zuordnungen haben, weshalb es nicht notwendig ist, bereits vorhan-dene Zuordnungen zu entfernen, um sie zu anderen Handlertypen umzuleiten. Die Fähigkeit, innerhalb der Anwendung Anforderungen einem anderen Handler neu zuzuordnen, stellt außerhalb des Bereichs der Codeausführung, die bereits durch die Anwendungsvertrauensebene und/oder die Anwendungspool-identität kontrolliert wird, kein Sicherheitsrisiko dar. Der handlers-Abschnitt bietet das accessPolicy-Attribut an, das festlegt, welche Zugriffsebenen Handlern gewährt werden. Dieses Attribut ist auf der Serverebene standardmäßig gesperrt, so dass die Anwendung es nicht modifizieren kann.

Auch die Konfiguration der Anwendungsvertrauensebene sollte auf der Serverebene gesperrt werden. Dies ist standardmäßig nicht der Fall – weshalb eine Anwendung ihre eigene Vertrauensebene auf eine vollständige Vertrauenswürdigkeit heraufstufen kann, um die Einschränkungen, mit denen die Ausfüh-rung des .NET-Codes belegt ist, aufzuheben. Serveradministratoren, die für Anwendungen das auf der teilweisen Vertrauenswürdigkeit basierende Sicherheitsmodell verwenden, sollten in der web.config-Datei des Frameworkstamms diese Konfiguration immer sperren, um zu verhindern, dass sie außer Kraft gesetzt wird. Sie können dies ganz einfach mit dem folgenden Appcmd-Befehl tun:AppCmd lock config /section:trust /commit:MACHINE/WEBROOT

Dies verhindert, das Anwendungen in der web.config-Datei des Frameworkstamms die Einstellung für die Vertrauensebene außer Kraft setzen.


ZusammenfassungDie modulare Architektur von IIS 7.0-Webservers bildet die Basis für viele wichtige Produktions-szenarien. Mit ihrer Hilfe können Sie spezialisierte Server erstellen, die nur wenige Ressourcen verbrauchen, und eine reichhaltige Zusatzfunktionalität nutzen, die durch eine End-to-End-Erweiter-barkeit ermöglicht wird. Obwohl die Verwaltung der Webservererweiterbarkeit traditionell eine Ent-wicklerdomäne ist, wird sie unter IIS 7.0 zu einem zentralen Thema für IT-Mitarbeiter. Auf diese Weise bieten sich dem Administrator neue Möglichkeiten, aber gleichzeitig wird er auch mit neuen Heraus-forderungen konfrontiert. Ausgerüstet mit dem richtigen Know-How können Sie die Modularität des Servers effektiv nutzen, um heute Ihre Geschäftsziele mithilfe der integrierten IIS 7.0-Features zu erreichen und morgen Ihren Server zu erweitern, indem Sie Microsoft- oder Drittanbietermodule verwenden.



In den nächsten beiden Kapiteln behandeln wie das vom Konfigurationssystem angebotene Erweiter-barkeitsmodell, den Verwaltungsstack und den IIS-Manager, der die End-to-End-Erweiterbarkeit des Servers abrundet.


� Das elfte Kapitel, »Hosting von Anwendungsentwicklungsframeworks«, hält Informationen zur Akti-vierung und zum Hosting gängiger Anwendungsframeworkstechnologien unter IIS 7.0 bereit.

� Das vierzehnte Kapitel, »Implementieren von Sicherheitsstrategien«, informiert über Serversperrungen.

� Der Blog unter http://www.mvolo.com behandelt ausführlich viele Themen zur IIS 7.0-Erweiter-barkeit und Modulverwaltung.

� Die Website http://www.iis.net hält Artikel zur Erweiterung von IIS 7.0 bereit.

� Die englische IIS 7.0-Betriebsanleitung finden Sie unter http://technet2.microsoft.com/windowsserver2008/en/library/d0de9475-0439-4ec1-8337-2bcedacd15c71033.mspx.


401

K A P I T E L 1 3

Konfigurations- und Benutzeroberflächen-erweiterungen verwalten

Inhalt dieses Kapitels:� Übersicht über den Verwaltungsstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

� Konfigurationserweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

� Verwaltungserweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

� IIS-Manager-Erweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419



Ein Blick auf die Geschichte von IIS (Internet Information Services) zeigt, wie wichtig ein flexibles und verwaltbares Konfigurationssystem ist. Was in Form von wenigen Registrierungseinstellungen begann, entwickelte sich zur Metabasis von IIS 5.0, einem Binärspeicher für die Verwaltung einer auf URLs basierenden Konfiguration, die von IIS 6.0 durch eine auf XML basierende Metabasis ersetzt wurde. IIS 7.0 ist ein weiterer Schritt in Richtung bessere Verwaltbarkeit, für die ein verteiltes auf XML basierendes Konfigurationssystem verwendet wird, das eine delegierte Verwaltung sowie eine Anwendungsbereit-stellung über xcopy ermöglicht. IIS 7.0 geht jedoch noch einen Schritt weiter – es weiß, dass die Verwalt-barkeit nicht beim Webserver enden darf und sich bis über die Anwendung hinweg ausweiten muss, damit eine in sich geschlossene End-to-End-Verwaltung möglich ist. Dies ist einer der wichtigsten Gründe dafür, dass das IIS 7.0-Konfigurationssystem und der gesamte Verwaltungsstack genauso wie der Webserver vollständig erweiterbar sind, so dass Drittanbietermodule und Anwendungskomponenten ihre Konfigura-tionen auf dieselbe Weise verfügbar machen können, wie dies auch dem Server möglich ist.

Übersicht über den VerwaltungsstackIIS 7.0 stellt nicht nur eine erweiterbare Plattform für die Erstellung von Webserverfeatures zur Ver-fügung, sondern es konzentriert sich ebenfalls intensiv darauf, seine Verwaltbarkeit zu verbessern und die Anwendungsentwicklung zu vereinfachen. Der Eckpfeiler dieser Anstrengung ist der neue Verwal-tungsstack, der um das neue Konfigurationssystem herum entwickelt wurde, um einen vollständigen Satz APIs (Application Programming Interface) und Tools für die Arbeit mit der IIS-Konfiguration und die Durchführung von Verwaltungsaufgaben bereitzustellen.

Das IIS 7.0-Konfigurationssystem weist einige wesentliche Einschränkungen seines Vorgängers, der IIS 6.0-Metabasis, nicht mehr auf. Zunächst ist es nicht mehr auf den zentralisierten Konfigurationsspeicher beschränkt, auf den nur der Administrator zugreifen konnte. Stattdessen unterstützt es eine aus XML-Konfigurationsdateien bestehende Hierarchie, zu der auch solche Dateien zählen, die zusammen mit den


402 Kapitel 13: Konfigurations- und Benutzeroberflächenerweiterungen verwalten

Anwendungsinhalten kopiert und bereitgestellt werden können. Dies ist die Basis der vereinfachten xcopy-Bereitstellung von IIS-Anwendungen und der Verwaltung von delegierten Konfigurationen.

Der dateibasierte Konfigurationsansatz vereinfacht die Anwendungsbereitstellung und Aufgaben wie das Sichern und Wiederherstellen von Konfigurationen. Das Format der Konfiguration ist kompatibel mit dem des ASP.NET-Konfigurationssystems, so dass IIS- und ASP.NET-Konfigurationen Seite an Seite innerhalb derselben Konfigurationsdateien existieren können. Die Konfiguration selbst wird in Form von einfachem, strukturiertem XML ausgedrückt, das manuell oder mithilfe von Entwick-lungstools bearbeitet werden kann.

Hinweis Im vierten Kapitel, »Verstehen des Konfigurationssystems«, erfahren Sie mehr über das IIS 7.0-Konfigurationssystem.

Wenngleich nicht mehr als der Windows-Editor notwendig ist, um mit der IIS 7.0-Konfiguration zu arbeiten, bietet der IIS 7.0-Verwaltungsstack (siehe Abbildung 13.1) ein breites Spektrum an Tools an, die für wichtige Entwicklungs- und Verwaltungsszenarien verwendet werden können. Er stellt ein Komponentenobjektmodell (Component Object Model) für die programmgesteuerte Konfigurations-verwaltung über C++-Programme, einen neuen WMI-Anbieter (Windows Management Instrumen-tation) für das Scripting und den Namespace Microsoft.Web.Administration für .NET Framework-Anwendungen zur Verfügung. Darüber hinaus bietet er den überarbeiteten IIS-Manager für die Web-serververwaltung mithilfe einer grafischen Benutzeroberfläche und Appcmd.exe an, ein Tool, mit dem es möglich ist, den Webserver über die Befehlszeile zu verwalten.

Abbildung 13.1 Der IIS 7.0-Verwaltungsstack

Es sollte nicht überraschen, dass der gesamte IIS 7.0-Verwaltungsstack genauso wie der Webserver selbst vollständig erweiterbar ist. Alle Konfigurationen für integrierte IIS 7.0-Features werden grund-sätzlich unter Verwendung eines öffentlich erweiterbaren Schemamechanismus beschrieben. Dies ist derselbe Mechanismus, der auch zum Hinzufügen von Konfigurationsabschnitten verwendet wird. Dies ermöglicht es neuen Webservermodulen, die eigenen benutzerdefinierten Konfigurationen auf dieselbe Weise offen zu legen, wie dies die IIS 7.0-Features tun – indem sie sie in denselben Konfigurations-dateien ablegen, in denen sich auch die IIS-Konfigurationsdaten befinden. Der Zugriff auf diese Konfi-gurationen ist dann über alle Standardkonfigurationstools und -APIs möglich.


Konfigurationserweiterungen verwalten 403

Zusätzlich zum Hinzufügen neuer Konfigurationen unterstützt das Konfigurationssystem auch das Hinzu-fügen von Verwaltungserweiterungen oder die Erweiterung bereits vorhandener Konfigurationsabschnitte, um neue, über die dateibasierte Konfiguration hinausgehende Verwaltungsfunktionen zur Verfügung zu stellen. Eine solche Funktionalität wird über öffentliche Konfigurationssystem-APIs für die Verwaltungs-clients offen gelegt. Zu diesen Clients zählen die verschiedenen IIS 7.0-Verwaltungstools und -APIs. Dies fördert die Wiederverwendung von Verwaltungsfunktionalität, weil solche Erweiterungen nur einmal installiert werden müssen und dann über alles Standardverwaltungstools und -APIs genutzt werden können.

Schließlich bietet auch der IIS-Manager seine eigene Erweiterbarkeitsarchitektur an, die es Drittanbietern ermöglicht, benutzerdefinierte Verwaltungsdienste und entsprechende Benutzeroberflächenelemente zu integrieren, damit die Endanwender diese Funktionalität nutzen können.

In diesem Kapitel werden Sie in die Erweiterbarkeitsarchitektur des IIS 7.0-Verwaltungsstacks ein-tauchen. Sie werden erfahren, wie Erweiterungen hinzugefügt werden, um eine neue Verwaltungs-funktionalität zur Verfügung zu stellen, und wie diese Erweiterungen innerhalb einer Produktions-umgebung richtig verwaltet und gesichert werden.

Konfigurationserweiterungen verwaltenKonfigurationserweiterungen sind Erweiterungen des Konfigurationssystems. Das Konfigurations-system bildet den Kern des IIS 7.0-Verwaltungsstacks. Sein Hauptzweck besteht darin, eine Schnitt-stelle zum Lesen und Schreiben von IIS-Konfigurationen zur Verfügung zu stellen, die von der Web-serverlaufzeit und den Modulen verwendet wird und die über die Tools und APIs im Verwaltungsstack verwaltet wird. Die Konfigurationsdaten selbst werden in einer XML-Dateihierarchie gespeichert und in so genannte Konfigurationsabschnitte unterteilt. Im vierten Kapitel erfahren Sie mehr über die Konfigurationsdateihierarchie und die Struktur der Konfigurationsabschnitte.

Jeder Konfigurationsabschnitt ist ein XML-Element, das Attribute, Unterelemente und Auflistungen von untergeordneten Elementen (Childelemente) enthalten kann, die die Konfigurationsdaten des Abschnitts beschreiben. Diese Daten können innerhalb der Konfigurationsdateihierarchie an verschiedenen Orten angegeben werden, um Konfigurationseinstellungen für bestimmte Konfigurationspfade festzulegen. Die folgende Konfiguration des <defaultDocument>-Abschnitts, die sich in der web.config-Datei einer Anwendung befindet, fügt beispielsweise Index.php als zulässiges Standarddokument hinzu und aktiviert das Standarddokumentfeature für diese Anwendung:<configuration> <system.webServer> <defaultDocument enabled="true"> <files> <add value="index.php" /> </files> </defaultDocument> </system.webServer> </configuration>

In der Regel besitzt jedes Webservermodul einen eigenen Abschnitt, und der Webserverkern definiert mehrere Abschnitte, wie z.B. <sites>, <applicationPools> und <serverRuntime>. Der Abschnitt configuration ist für das Konfigurationssystem der Ausgangspunkt für die Erweiterbarkeit, weil er benutzerdefinierten Webserverfeatures die Möglichkeit bietet, eigene Konfigurationsabschnitte zur Verfügung zu stellen. Die dazu notwendige Vorgehensweise entspricht der von IIS 7.0-Features.



Im Gegensatz zum ASP.NET-Konfigurationssystem, das auf .NET-Klassen angewiesen ist, die die Basisklasse System.Configuration.Section implementieren müssen, um die Inhalte jedes Konfigura-tionsabschnitts verstehen zu können, ist das IIS-Konfigurationssystem deklarativ. Jeder Konfigurations-abschnitt wird definiert, indem er auf dem Server sein Schema registriert, wodurch es dem Konfigura-tionssystem möglich wird, die Konfigurationsdaten für diesen Abschnitt zu verarbeiten. Durch Ändern des Schemas können Sie dem System neue Konfigurationsabschnitte hinzufügen bzw. bereits vorhan-dene Abschnitte entfernen oder erweitern, so dass diese mehr Funktionalität enthalten.

Wir werden nun einen genauen Blick auf den Konfigurationsschemamechanismus werfen und uns damit beschäftigen, wie dieser verwendet werden kann, um benutzerdefinierte Konfigurations-abschnitte hinzuzufügen.

Direkt von der Quelle: Die Geschichte von den beiden Teams und den beiden KonfigurationssystemenDie Geschichte des ASP.NET-Teams war hinsichtlich der Mitglieder und Technologien schon immer mit der des IIS-Teams verflochten. Nach der Veröffentlichung von IIS 5.1 arbeiteten einige IIS-Teammitglieder (bevor sie sich wieder um IIS 6.0 kümmerten) weiter an einem Projekt, dessen Ziel darin bestand, den Webserver unter Verwendung des .NET Frameworks völlig neu zu gestalten. Scott Guthrie war einer der Entwickler dieses Projekts, der später für die Entwicklung von ASP.NET verantwortlich war.

Zu Beginn des Jahres 2004, als sich das ASP.NET-Team inmitten der ASP.NET 2.0-Entwicklung befand, schloss sich der Kreis wieder. Das IIS-Team wurde erneut mit dem ASP.NET-Team zusam-mengelegt, um die Gruppe »Webplattform und -tools« zu bilden. Einer der Hauptgründe für diese Neuorganisation war die Absicht, die Vorzüge des ASP.NET-Konfigurationssystems zu nutzen, das eine einheitliche IIS- und ASP.NET-Konfiguration versprach. Außerdem sollte die Grundlage für die delegierte Verwaltung der IIS-Konfiguration geschaffen werden.

Im Verlauf des Jahres arbeitete das IIS-Team daran, das ASP.NET-Konfigurationssystem für den Webserver der nächsten Generation, IIS 7.0, nutzen zu können. Unglücklicherweise erwies sich das ASP.NET-Konfigurationssystem als zu komplex für IIS, das eine extreme Stabilität und Leistung verlangt, die für ASP.NET-Anwendungen nicht erforderlich ist. Die Möglichkeit, dieselben Konfigu-rationsdateien zu nutzen und ASP.NET- und IIS-Konfigurationen gemeinsam angeben zu können, war jedoch unserer Meinung nach für die Kunden zu wichtig, als dass wir dieses Ziel hätten aufgeben können. Deshalb wurde das neue IIS 7.0-Konfigurationssystem geboren. Das Team hat es von Grund auf neu entwickelt, damit es die Stabilitätsanforderungen eines IIS-Arbeitsprozesses erfüllt und dennoch mit dem ASP.NET-Konfigurationssystem syntaktisch kompatibel ist.

Abgesehen von der Vereinheitlichung der Konfiguration, bot mir die Zusammenlegung der beiden Teams die Gelegenheit, die Entwicklung der ASP.NET 2.0-Kerninfrastruktur und des IIS 7.0-Web-serverdesigns zu leiten. Im Laufe der folgenden Jahre war ich für die Planung und die Entwicklung beider Projekte verantwortlich, was sehr hilfreich war, da ich auf diese Weise dafür sorgen konnte, dass ASP.NET in IIS 7.0 integriert wurde und wichtige IIS 7.0-Features, wie z.B. die URL-Autori-sierung und die Ausgabezwischenspeicherung, ihren Weg in IIS fanden.

Mike Volodarsky




KonfigurationsabschnittsschemataDie Definitionen der Konfigurationsabschnittsschemata sind in XML-Dateien gespeichert, die sich im Verzeichnis %windir%\System32\Inetsrv\Config\Schema befinden. Nach der Installation verfügt IIS 7.0 über die folgenden Schemadateien:

� IIS_schema.xml Definiert alle IIS-Konfigurationsabschnitte

� ASPNET_schema.xml Definiert alle in der Root.config-Datei des Frameworks deklarierten ASP.NET-Konfigurationsabschnitte

� FX_schema.xml Definiert alle in der machine.config-Datei deklarierten .NET Framework-Konfigurationsabschnitte

� rscaext.xml Definiert Verwaltungserweiterungen der Konfigurationsabschnitte <sites> und <applicationPools>, um Laufzeitstatusinformationen und Steuerungs-APIs verfügbar zu machen. (Verwaltungserweiterungen werden später in diesem Kapitel im Abschnitt »Verwaltungserweiterungen verwalten« behandelt.)

Vorsicht Versuchen Sie niemals, die integrierten IIS-Schemadateien zu modifizieren. Sie können neue Schemata hinzufügen, um neue Konfigurationsabschnitte zu definieren, und Sie können sogar bereits vorhandenen Konfi-gurationsabschnitten Funktionalität dynamisch hinzufügen, indem Sie neue Schemadateien veröffentlichen, was später in diesem Kapitel im Abschnitt »Verwaltungserweiterungen verwalten« beschrieben ist.

Diese Dateien definieren das von IIS und den dazugehörigen Features verwendete Schema der Konfigu-rationsabschnitte, die in einem bestimmten Format vorliegen müssen. Diese Dateien sind nicht dafür vorgesehen, modifiziert zu werden (lediglich das Windows-Setup darf dies). Deshalb sind sie geschützt, so dass nur TrustedInstaller darin schreiben darf. Dies bedeutet ebenfalls, dass es nicht notwendig ist, diese Schemadateien zu sichern, da sie geschützt sind und mithilfe des Setups wiederhergestellt werden können (benutzerdefinierte Schemadateien sollten jedoch gesichert werden).

Hinweis Weitere Informationen zur Konfigurationssicherung finden Sie im vierten Kapitel, »Verstehen des Konfi-gurationssystems«.

Das IIS 7.0-Konfigurationssystem wird nicht von ASP.NET oder anderen .NET Framework-Programmen verwendet, um die Inhalte von .NET Framework- und ASP.NET-Konfigurationsabschnitten zu lesen, die in der machine.config-Datei des Frameworks oder den web.config-Stammdateien angegeben sind. Die .NET- und ASP.NET-Programme greifen auf das .NET-Konfigurationssystem (das vom ASP.NET-Team entwickelt wurde) zurück, um diese Konfigurationen zu lesen. Sie fragen sich nun möglicherweise, wes-halb das IIS-Konfigurationssystem Schemainformationen für diese Konfigurationsabschnitte bereithält. Der Grund hierfür besteht darin, dass der IIS 7.0-Verwaltungsstack über die Möglichkeit verfügen soll, die ASP.NET-Konfiguration zu verwalten, damit Administratoren die gesamte Serverkonfiguration mit nur einem Satz Tools und APIs verwalten können. Obwohl ASP.NET eine eigene API für die Verwaltung der .NET-Konfiguration anbietet (System.Configuration.dll), unterstützt es nicht die IIS-Konfiguration und stellt auch nicht Tools zur Verfügung, die mit denen des IIS 7.0-Verwaltungsstacks vergleichbar wären. Darüber hinaus unterstützt ASP.NET die Automatisierung nicht im selben Maße wie der Verwaltungs-stack.



Die IIS-Schemadateien können jedoch ausschließlich für .NET Framework 2.0 benutzt werden. Auf-grund von Konfigurationsänderungen ist die Nutzung für andere .NET Framework-Versionen nicht möglich. Vielleicht wird das IIS-Team in Zukunft eine Lösung für die verschiedenen Versionen des .NET-Konfigurationsschemas anbieten. Für IIS 7.0 ist eine solche Lösung jedoch noch nicht verfügbar. Bei einigen Tools des IIS-Verwaltungsstacks (einschließlich des Befehlszeilentools Appcmd), die mit der machine.config-Datei und den web.config-Stammdateien arbeiten, ist die .NET-Frameworkversion v2.0.50727 sogar fest im Programmcode verankert, so dass diese Tools nicht benutzt werden können, um für andere .NET Framework-Versionen die Konfiguration der Computerebene zu bear-beiten.

Das nachfolgende Beispiel zeigt, wie der <defaultDocument>-Konfigurationsabschnitt für das Standard-dokumentfeature in IIS_schema.xml definiert ist: <sectionSchema name="system.webServer/defaultDocument"> <attribute name="enabled" type="bool" defaultValue="true"/> <element name="files"> <collection addElement="add" clearElement="clear" removeElement="remove" mergeAppend="false"> <attribute name="value" type="string" isUniqueKey="true"/> </collection> </element> </sectionSchema>

Die Schemadefinition gibt jedes Attribut an und definiert, welche Childelemente und Elementauf-listungen im Abschnitt enthalten sein können. Zusätzlich zur Definition der XML-Struktur stellt die Schemadefinition verschiedene Metadaten für Attribute, Childelemente und Auflistungen zur Ver-fügung, die das Verhalten des Konfigurationssystems bezüglich des Abschnitts kontrollieren. Sie gibt beispielsweise an, dass der Typ des enabled-Attributs Boolean ist, dass sein Vorgabewert true lautet, und dass das value-Attribut des Auflistungselements der Auflistungsschlüssel ist.

Die Hauptschemadatei IIS_schema.xml enthält die Beschreibung der Schemainformationen, die für jeden Abschnitt angegeben werden können. Diese Abschnittsinformationen können die in Tabelle 13.1 aufgeführten Elemente enthalten.

Tabelle 13.1 Schemaelemente

Schemaelement Beschreibung

<sectionSchema>-Element Enthält alle Schemainformationen eines Konfigurationsabschnitts sowie den vollqualifizierten Namen des Abschnitts (der aus dem Abschnittsgruppenpfad und dem Abschnittsnamen besteht)

<attribute>-Element Definiert ein Attribut, das im Konfigurationsabschnitt und in dessen Childelementen verwendet werden kann. Das Element gibt den Namen, den Datentyp und andere anwendbare Informationen an, z.B. den Standardwert, Validierungsinformationen und Informationen darüber, ob das Attribut angegeben werden muss oder verschlüsselt werden soll.

<element>-Element Definiert ein Childelement, das zusätzliche Attribute und weitere Childelemente und Auflistungen festlegen kann

<collection>-Element Definiert eine Konfigurationsauflistung, die eine Liste von Elementen enthalten kann. Diese Ele-mente werden über Attribute indiziert, die als Auflistungsschlüssel gekennzeichnet sind. Unterstützt auch verschiedene Auflistungsregeln, z.B. für geordnete Listen und das hierarchische Zusammen-fügen von Elementen.



Jedes dieser Elemente unterstützt verschiedene Schemaeigenschaften, die das jeweilige Verhalten des Konfigurationssystems bezüglich des definierten Konfigurationsabschnitts kontrollieren. Weitere Informationen darüber, wie Sie diese Eigenschaften verwenden, um das Verhalten eines Konfigura-tionsabschnitts festzulegen, finden Sie in den Kommentaren der Konfigurationsdatei IIS_Schema.xml.

Hinweis Die Schemadateien sind lokale Serverdateien. Wenn Sie eine freigegebene Konfiguration verwenden, um applicationHost.config über eine Netzwerkfreigabe zu hosten, müssen Sie sicherstellen, dass die benötigten Schemadateien auf jedem Server installiert sind, der die Konfigurationsdatei referenziert. Server, die nicht über die erforderlichen Schemadateien verfügen, können die Konfigurationsabschnitte, für die keine Schemainformationen vorhanden sind, nicht lesen. Dies gilt jedoch nur für Schemadateien, die standardmäßig kein Bestandteil von IIS 7.0 sind. Wenn sie ein solcher Bestandteil sind, werden sie zusammen mit IIS 7.0 installiert.

Möchten Sie neue Konfigurationsabschnitte hinzufügen oder dafür sorgen, dass bereits vorhandene Abschnitte weitere Konfigurationsinformationen aufnehmen oder eine erweiterte Verwaltungsfunktio-nalität zur Verfügung stellen, müssen Sie zusätzlich XML-Dateien mit Abschnittsschemainformationen einbinden. Bevor neue Konfigurationsabschnitte in den Konfigurationsdateien verwendet werden können, müssen sie außerdem deklariert werden. Dies ist nachfolgend beschrieben.

Vorsicht Versuchen Sie niemals, Schemadateien, die ein Bestandteil der IIS 7.0-Installation sind, zu löschen oder zu modifizieren. Im Gegensatz zu Modulen werden die meisten dieser Schemakomponenten zusammen mit der IIS 7.0-Installation eingerichtet. Würden sie entfernt, könnte dies dazu führen, dass die Teile des Systems, die mit den in den Schemakomponenten definierten Konfigurationsabschnitten arbeiten, nicht mehr funktionieren. Auch sollten Sie die Schemainformationen der integrierten IIS 7.0-Konfigurationsabschnitte nicht modifizieren, da die Kern-komponenten darauf angewiesen sind, dass die spezifische Struktur dieser Schemata erhalten bleibt. Aus diesem Grund sind diese Schemadateien mit ACLs (Access Control List) verknüpft, die lediglich TrustedInstaller Zugriffs-rechte gewähren, so dass eine Modifizierung nicht möglich ist. Sie können jedoch bereits vorhandenen IIS-Abschnitten neue Verwaltungserweiterungen hinzufügen, indem Sie neue Schemadateien hinzufügen. Dieses Thema wird später in diesem Kapitel im Abschnitt »Verwaltungserweiterungen verwalten« behandelt.

Konfigurationsabschnitte deklarierenSobald ein Konfigurationsabschnittsschema an dem dafür vorgesehenen Ort verfügbar ist, verfügt das Konfigurationssystem über die Möglichkeit, die Konfigurationsdaten des Abschnitts zu verarbeiten. Bevor der Abschnitt jedoch in einer Konfigurationsdatei verwendet werden kann, muss er irgendwo in der Konfigurationsdateihierarchie deklariert werden. Dies ist notwendig, damit der Administrator bestimmte Verhaltensweisen des Konfigurationsabschnitts kontrollieren kann, die nicht einfach verwaltet werden könnten, wenn sie innerhalb des Schemas festgelegt wären.

Die Deklaration erfolgt, indem dem integrierten Konfigurationsabschnitt <configSections> ein <section>-Element hinzugefügt wird. Jede Deklaration kann in Abschnittsgruppen verschachtelt sein. Dabei handelt es sich im Wesentlichen um Gruppierungskonstrukte für Konfigurationsabschnitte (Abschnitte können jedoch nicht ineinander verschachtelt werden). Der folgende Code deklariert beispielsweise den Konfigurationsabschnitt <defaultDocument>, der Teil der Abschnittsgruppe system.webServer ist, die sich in applicationHost.config befindet. Bei dem Code handelt es sich um einen Auszug. Tatsächlich werden hier viele weitere Konfigurationsabschnitte deklariert.



Hinweis Sie können ein wenig über bestimmte Konfigurationsabschnitte erfahren, indem Sie einen Blick auf die Abschnittsgruppe werfen, der die Abschnitte zugeordnet sind. IIS-Konfigurationsabschnitte, welche die von WAS (Windows Process Activation Service) verwendete globale Serverkonfiguration definieren, zu der auch die Konfi-gurationsabschnitte <sites> und <applicationPools> zählen, befinden sich beispielsweise in der Konfigurations-abschnittsgruppe system.applicationHost. Webserverkonfigurationsabschnitte befinden sich in der Abschnittsgruppe system.webServer. ASP.NET-Konfigurationsabschnitte sind der Abschnittsgruppe system.Web zugeordnet. Wenn Sie Ihre eigenen Abschnitte definieren, können Sie auch eine eigene Abschnittsgruppe erstellen (indem Sie sie einfach in der Konfigurationsdatei deklarieren) und diese in einer der bereits vorhandenen Abschnittsgruppen platzieren, oder Sie deklarieren Ihre Gruppe auf der obersten Hierarchieebene.

<configSections> … <sectionGroup name="system.webServer"> … <section name="defaultDocument" overrideModeDefault="Allow" /> <sectionGroup name="system.webServer"> <configSections>

Diese Deklaration gibt an, dass der Abschnitt defaultDocument in der Datei applicationHost.config und in allen Konfigurationsdateien, die sich innerhalb der Hierarchie unterhalb von applicationHost.config befinden, verwendet werden kann. Sie gibt außerdem an, das niedrigere Konfigurationsebenen den Abschnitt außer Kraft setzen dürfen, so dass es möglich wird, die Kontrolle über diesen Abschnitt an eine Anwendung zu delegieren.

Wichtig Bevor Sie Konfigurationsdateien bearbeiten, sollten Sie diese immer sichern, so dass Sie die Konfigura-tion gegebenenfalls wiederherstellen können. Der Anwendungshost-Hilfsdienst speichert automatisch in Abständen von zwei Minuten Snapshots der Konfigurationsdateien, die sich auf der Serverebene befinden. Wenn Ihnen dieses Maß an Sicherheit genügt, müssen Sie keine Änderungen vornehmen.

Um die Konfiguration vor einer Änderung manuell zu sichern, verwenden Sie den Befehl %windir%\System32\ Inetsrv\ Appcmd Add Backup <BackupName>. Um eine zuvor durchgeführte Sicherung wiederherzustellen, können Sie mit dem Befehl %windir%\System32\Inetsrv\Appcmd Restore Backup <BackupName> arbeiten. Um die von Ihnen und dem Konfigurationsverlauf durchgeführten und wiederherstellbaren Sicherungen aufzulisten, benutzen Sie den Befehl %windir%\System32\Inetsrv\Appcmd List Backups. Weitere Informationen zum Sichern und Wieder-herstellen von Konfigurationen finden Sie im vierten Kapitel.

Jede Deklaration kann die in Tabelle 13.2 beschriebenen Informationen festlegen.

Tabelle 13.2 Festlegen von Deklarationen

Deklaration Beschreibung

Name Der Name des Konfigurationsabschnitts. Dieser Name muss zusammen mit dem Abschnittsgruppennamen den Namen der Abschnittsschemadefinition ergeben. Die Angabe ist erforderlich.

allowDefinition Die Ebene, auf der dieser Abschnitt konfiguriert werden darf, z.B. MachineOnly, MachineToApplication, AppHostOnly und Everywhere. Dies entspricht den Teilen der Konfigurationshierarchie, in denen der Konfi-gurationsabschnitt verwendet werden darf. Die Vorgabe ist Everywhere.

overrideModeDefault Gibt an, ob die Konfiguration dieses Abschnitts auf den Ebenen unterhalb der aktuellen Datei, in der die Deklaration erfolgt, definiert werden darf. Abschnitte, die diese Einstellung auf Deny setzen, sperren die Konfiguration auf dieser Ebene, so dass eine Delegierung nicht möglich ist. Der Standardwert ist Allow.



Obwohl die Schemadefinitionen für Konfigurationsabschnitte global im Verzeichnis %windir%\ System32\Inetsrv\Config\Schema definiert sind, können sich die Abschnittsdeklarationen auf verschie-denen Ebenen der Konfigurationshierarchie befinden, so dass der jeweilige Abschnitt nur auf dieser Ebene oder darunter verfügbar ist. Die IIS 7.0-Konfigurationshierarchie deklariert Konfigurations-abschnitte standardmäßig wie folgt:

� Machine.config-Datei des Frameworks Deklariert .NET-Konfigurationsabschnitte, die für alle .NET-Programme und nicht nur für ASP.NET verfügbar sind. Alle .NET-Programme erhalten ihre Konfiguration aus dieser Datei.

� Web.config-Datei des Frameworkstamms Deklariert spezifische ASP.NET Abschnitte, die nur in Webanwendungen zur Verfügung stehen. ASP.NET-Programme erhalten, sofern entsprechende Lesevorgänge stattfinden, eine zusammengeführte Konfiguration, die aus machine.config und dieser Datei stammt.

� ApplicationHost.config Deklariert IIS-Konfigurationsabschnitte. IIS-Konfigurationsnutzer lesen ihre Konfiguration aus der machine.config-Datei des Frameworks, der web.config-Stammdatei und dieser Datei.

� Verteilte web.config-Dateien Enthalten Konfigurationseinstellungen für site/application und deklarieren bisweilen anwendungsspezifische Konfigurationsabschnitte (in der Regel ASP.NET-Konfigurationsabschnitte, die über System.Configuration-APIs verwendet werden).

Zwei weitere Konfigurationsdateien deklarieren ebenfalls Konfigurationsabschnitte: redirection.config und administration.config. Diese Dateien sind in der Regel kein Teil der Konfigurationshierarchie von Webanwendungen, obwohl sie in bestimmten Fällen zum Einsatz kommen. Das Konfigurationssystem verwendet redirection.config, um Zugriffe auf applicationHost.config an Netzwerkordner weiterzu-leiten, damit in Webfarms freigegebene Konfigurationen möglich sind. Der IIS-Manager verwendet administration.config, um konsolenspezifische Konfigurationen festzulegen, einschließlich einer Liste der IIS-Manager-Erweiterungen, die von der Konsole geladen werden (weitere Informationen hierzu finden Sie später in diesem Kapitel im Abschnitt »Die Funktionsweise von IIS-Manager-Erweiterungen«).

allowLocation Gibt an, ob dieser Abschnitt mithilfe von location-Tags für einen bestimmten Pfad angegeben werden kann. Die Standardeinstellung ist true.

type Der .NET-Abschnittshandlertyp, der für die Verarbeitung dieses Abschnitts verantwortlich ist. Diese Angabe ist für Konfigurationsabschnitte erforderlich, die vom .NET-Konfigurationssystem gelesen werden. Für IIS-Konfigurationsabschnitte muss diese Einstellung somit nicht gesetzt werden (es sei denn, das .NET-Konfigu-rationssystem soll ebenfalls darauf zugreifen). Keiner der IIS-Konfigurationsabschnitte definiert dieses Attri-but. Wenn Sie in der machine.config-Datei des Frameworks oder in den verteilten web.config-Dateien der Verzeichnisstruktur Ihrer Website einen Konfigurationsabschnitt deklarieren, können Sie dieses Attribut auf den speziellen Typ System.Configuration.IgnoreSection setzen, damit das ASP.NET-Konfigurationssystem keine Fehler generiert.

requirePermission Gibt an, ob teilweise vertrauenswürdige .NET-Anwendungen die Inhalte dieses Abschnitts mithilfe der .NET-API System.Configuration (ASP.NET-Konfigurationssystem oder der API Microsoft.Web.Administration (IIS-Konfigurationssystem) lesen dürfen. Wenn Sie als Wert false verwenden, können diese Abschnitte von teilweise vertrauenswürdigen Anwendungen nicht gelesen werden. Die Standardeinstellung ist true.

Tabelle 13.2 Festlegen von Deklarationen (Fortsetzung)

Deklaration Beschreibung



Hinweis Weitere Informationen zur Konfigurationsdateihierarchie finden Sie im vierten Kapitel.

Entwickler nutzen die Abschnittsdeklarationen oft, um den Standarddelegierungsstatus von Konfigurations-abschnitten zu kontrollieren und den Gültigkeitsbereich einzuschränken, innerhalb dessen eine Konfigura-tion angegeben werden kann. Das erste geschieht, um Nicht-Administratoren davon abzuhalten, bestimmte Konfigurationsabschnitte in web.config-Dateien außer Kraft zu setzen, auf die diese Benutzer zugreifen können. Im zweiten Fall wird die Nutzung des Konfigurationsabschnitts auf die Ebene beschränkt, wo der Abschnitt von dem entsprechenden Webserverfeature gelesen wird. WAS und IIS-Arbeitsprozesse lesen beispielsweise nur auf der Serverebene den Konfigurationsabschnitt <sites>, weshalb dieser mit allowDefini-tion = AppHostOnly deklariert ist. Die Delegierung von Konfigurationsabschnitten wird später in diesem Kapitel behandelt, wenn wir uns mit Konfigurationssperrung beschäftigen.

Neue Konfigurationsabschnitte installierenAusgerüstet mit dem Wissen um Schemadefinitionen und Deklarationen, wird das Hinzufügen eines neuen Konfigurationsabschnitts zu einem aus zwei Schritten bestehenden Vorgang:

1. Das Abschnittsschema registrieren.

2. Den Abschnitt in der gewünschten Konfigurationsdatei deklarieren.

Um das Abschnittsschema zu registrieren, benutzen Sie das in IIS_schema.xml beschriebene Format. Unter Verwendung dieses Formats erzeugen Sie eine XML-Datei, die die Definition des Abschnitts enthält. Dann kopieren Sie sie in das Verzeichnis %windir%\System32\Inetsrv\Config\Schema. Da das IIS 7.0-Konfigurationssystem eine prozessinterne Komponente ist, müssen Sie jeden Prozess, der den neuen Konfigurationsabschnitt lesen soll, neu starten, damit er veranlasst wird, die neue Schemadatei zu laden. Dies bedeutet in der Regel, dass die Wiederverwendung des Zielanwendungspools initiiert werden muss, oder es müssen IIS-Dienste von einer Befehlszeile aus mithilfe von Iisreset.exe neu gestartet werden, was zu einem Neustart der Arbeitsprozesse in allen Anwendungspools führt.

Hinweis Um die Schemaänderungen zu übernehmen, müssen Sie nicht alle IIS-Dienste neu starten, da nicht alle Dienste versuchen werden, auf Ihren neuen Abschnitt zuzugreifen. Es sollte genügen, jeden IIS-Anwendungspool, der Modul- oder Anwendungskomponenten enthält, die mit dem neuen Konfigurationsabschnitt arbeiten, neu zu starten.

Um den Konfigurationsabschnitt zu deklarieren, müssen Sie auf der Ebene, wo der Abschnitt verfügbar sein soll, dem <configSections>-Abschnitt das Abschnittsdeklarationselement hinzufügen. Die meisten IIS-Konfigurationsabschnitte sollten in applicationHost.config deklariert werden, so dass sie auf der Serverebene, aber auch in delegierten web.config-Anwendungsdateien verwendet werden können.

Wenn der Abschnitt für verschiedene Versionen des .NET-Frameworks unterschiedlich konfiguriert werden soll, sollten Sie ihn in der machine.config-Datei des .NET Frameworks oder in der web.config- Stammdatei deklarieren. Hier werden die restlichen .NET Framework- und ASP.NET-Abschnitte dekla-riert. Webserverfeatures, die innerhalb eines IIS-Arbeitsprozesses auf eine Konfiguration zugreifen, erhalten diese von den Konfigurationsdateien der Framework-Version, die vom managedRuntimeVersion-Attribut des jeweiligen Anwendungspools festgelegt wird.

Wenn Sie den Abschnitt nur für eine bestimmte Website oder Anwendung nutzen möchten, können Sie ihn in einer web.config-Datei dieser Anwendung deklarieren. Sie können diese Konfiguration dann jedoch nicht für andere Anwendungen lesen, und es ist auch nicht möglich, auf der Serverebene die



Grundkonfiguration für diesen Abschnitt anzugeben, so dass dieser von mehreren Anwendungen genutzt werden könnte.

Das ist alles. Sobald Ihre Abschnittsdefinitionen registriert und der Abschnitt auf der richtigen Konfi-gurationsebene deklariert ist, können Sie ihn in den Konfigurationsdateien zusammen mit der rest-lichen IIS-Konfiguration angeben.

Konfigurationsabschnitte sichernIm Gegensatz zu Webservermodulen enthalten Konfigurationsabschnitte keinen Code und stellen deshalb kein großes Risiko für das System dar. Zur Drucklegung dieses Buches gab es keine Möglichkeit, die Sicherheit des Servers durch die Installation neuer Konfigurationsabschnitte zu beeinträchtigen. Sie können das Risiko jedoch vergrößern, indem Sie Code enthaltende Verwaltungserweiterungen instal-lieren, die später in diesem Kapitel im Abschnitt »Verwaltungserweiterungen verwalten« beschrieben werden.

Die Sicherung der Konfiguration ist ein äußerst umfassendes Thema, das ausführlich im vierzehnten Kapitel, »Implementieren von Sicherheitsstrategien«, behandelt wird. In diesem Abschnitt beschäftigen wir uns mit spezifischen Aspekten der Konfigurationssicherheit, die Sie berücksichtigen sollten, wenn

Das Tool Iisschema.exeIm Gegensatz zum Registrieren eines Abschnittsschemas, wofür die Schemadatei einfach in das Ver-zeichnis %windir%\System32\Inetsrv\Config\Schema kopiert werden muss, erfordert eine Abschnitts-deklaration das Einfügen von Code in den Abschnittsdeklarationsbereich einer bestimmten Konfigura-tionsdatei. Unter Windows Server 2008 und Windows Vista SP1 (Service Pack 1) ist dies von einer .NET-Anwendung aus möglich, die dazu die API Microsoft.Web.Administration nutzt, oder mithilfe eines Skripts, wofür WMI bzw. die COM-Objekte für die IIS 7.0-Konfiguration notwendig sind. Dies geschieht mit dem Befehlszeilentool Iisschema.exe, das die Installation und Verwaltung von Konfigurationsabschnitten drastisch vereinfacht. Sie können das Tool ebenfalls benutzen, um schnell zu überprüfen, welche Abschnitte auf dem Server oder einer bestimmten Konfigurationsebene installiert und deklariert sind.

Sie können beispielsweise die Schemadatei schnell installieren und alle darin definierten Abschnitte in applicationHost.config automatisch deklarieren lassen, indem Sie den folgenden Befehl aufrufen:

IisSchema.exe /install <schemafile.xml>

Alternativ hierzu können Sie bestimmte Konfigurationsabschnitte für bestimmte Konfigurations-pfade deklarieren und spezifische Abschnittsdeklarationsattribute setzen, indem Sie den Befehl Iisschema.exe /reg <SectionName> /path:<ConfigPath> nutzen. Sie können ebenfalls alle bereits vorhandenen Deklarationen modifizieren oder alle für einen bestimmten Konfigurationspfad deklarierten Konfigurationsabschnitte auflisten lassen.

Um Hilfe zu allen vom Tool unterstützten Parametern zu erhalten, lassen Sie es ohne Parameter ausführen:

IisSchema.exe

Das Tool Iisschema.exe ist in den Begleitdateien zu diesem Buch enthalten. Sie können unter http://mvolo.com/blogs/serverside/archive/2007/08/04/IISSCHEMA.EXE-_2D00_-A-tool-to-register-IIS7-configuration-sections.aspx mehr über dieses Hilfsmittel erfahren und es dort auch herunter-laden.



Sie einen neuen Konfigurationsabschnitt hinzufügen. Befolgen Sie aber auch die im vierzehnten Kapitel vorgestellten allgemeinen Richtlinien zur Sicherung der Konfiguration Ihres Servers.

Wenn Sie einen neuen Konfigurationsabschnitt hinzufügen, sollten Sie einige Überlegungen anstellen. Zunächst einmal dient die Konfiguration dem Zweck, das Verhalten des Servers zu verändern. Deshalb ist es wichtig, die Kontrolle darüber zu behalten, wer die Konfiguration modifizieren darf und wie verhindert werden kann, dass der Betrieb des Servers gestört wird.

IIS 7.0 schränkt standardmäßig die Möglichkeit ein, die Konfiguration in den Konfigurationsdateien der Serverebene zu ändern. Dies ist nur Administratoren möglich. Auf Servern, wo die Kontrolle über die Anwendungsinhalte an Nicht-Administratoren delegiert wird, können solche Benutzer jedoch ebenfalls die Konfigurationen in den delegierten web.config-Dateien festlegen und auf diese Weise die Konfi-gurationen, die auf der Serverebene für diese Sites/Anwendungen gesetzt wurden, außer Kraft setzen. Selbst in Fällen, wo der Serveradministrator die Anwendungsinhalte kontrolliert, können Anwendungs-komponenten von Drittanbietern unerwünschte Konfigurationseinstellungen vornehmen. Aus diesem Grund müssen Administratoren bestimmen können, welche Konfigurationsabschnitte ausschließlich auf der Serverebene – wo der Serveradministrator die Kontrolle hat – genutzt, und welche Abschnitte auf der Anwendungsebene überschrieben werden dürfen. Der nächste Abschnitt behandelt die Konfigurationsdelegierung.

Zweitens können die Konfigurationsdaten selbst sensible Informationen enthalten, z.B. Kennwörter oder Verbindungszeichenfolgen. Deshalb möchten Sie vielleicht zusätzliche Vorsichtsmaßnahmen ergreifen, um eine unbeabsichtigte Offenlegung dieser Informationen zu verhindern. Dazu können Sie verlangen, dass beim Schreiben der Konfiguration bestimmte Teile des neuen Konfigurationsabschnitts automatisch verschlüsselt werden, so dass die Daten nicht in Form von Klartext gespeichert werden. Dies ergänzt den Schutz, der durch die Zugriffsbeschränkungen erreicht wird, mit denen die Konfigura-tionsdateien belegt sein können. Außerdem werden die Informationen vor einer Offenlegung geschützt, wenn die Dateien vom physikalischen Server heruntergenommen werden. In diesem Abschnitt werfen wir einen genaueren Blick auf diese Möglichkeiten.

Die Konfigurationsdelegierung kontrollierenWenn Sie einen Shared Server ausführen, auf dem der Serveradministrator nicht dieselbe Person wie der Site- oder Anwendungsadministrator ist, sollten Sie sich Gedanken darüber machen, welche Konfi-gurationsabschnitte auf der Site- oder Anwendungsebene außer Kraft gesetzt werden dürfen. Sie sollten nicht zulassen, dass ein Konfigurationsabschnitt delegiert werden kann, der es einer Anwendung ermöglicht, die Sicherheit des Servers zu kompromittieren, dessen Leistung drastisch zu vermindern oder Zugriff auf die Konfigurationen oder Daten anderer Anwendungen zu erhalten.

Der grundlegende Mechanismus, mit dem die Delegierung eines neuen Abschnitts kontrolliert werden kann, besteht darin, zu verhindern, dass der Abschnitt auf einer niedrigeren Ebene außer Kraft gesetzt werden kann, sofern er nicht explizit vom Administrator entsperrt wurde. Dazu muss in der Abschnittsdeklaration das allowOverrideDefault-Attribut auf False gesetzt werden. Die meisten in applicationHost.config deklarierten IIS-Konfigurationsabschnitte nutzen diese Technik.

Hinweis Sie können in der Abschnittsdeklaration ebenfalls das allowDefinition-Attribut verwenden, um die Nut-zung des Abschnitts auf die Gültigkeitsbereiche Machine oder ApphostOnly zu beschränken. Dieses Attribut sollte jedoch niemals eingesetzt werden, um die Delegierung des Abschnitts zu kontrollieren, weil es, im Gegensatz zu allowOverrideDefault, vom Administrator nicht »entsperrt« werden kann. Das Attribut allowDefinition ist dafür vor-gesehen, die Nutzung des Abschnitts auf Konfigurationsebenen zu beschränken, wo der Abschnitt anwendbar ist, und zwar abhängig davon, wie der jeweilige Laufzeitnutzer den Abschnitt interpretiert.



Nachdem Sie in der Abschnittsdeklarationen allowOverrideDefault = False angegeben haben, können die niedrigeren Konfigurationsebenen diesen Abschnitt nicht mehr außer Kraft setzen. Administratoren könnten jedoch den Abschnitt später wieder entsperren, damit auf den unteren Ebenen eine Festlegung möglich wäre. Dazu müssten sie ihn mit einem location-Tag ummanteln, dass das Attribut overrideMode festlegen würde, um anzugeben, ob der Abschnitt gesperrt oder entsperrt wäre. Das folgende Beispiel zeigt einen Konfigurationsabschnitt, bei dem allowOverrideDefault="Deny" entsperrt ist: <location path="" overrideMode="Allow"> <system.webServer> <tracing> <traceFailedRequests /> </tracing> </system.webServer> </location>

Das Setzen von overrideMode auf Deny würde diesen Abschnitt sperren. Das Attribut path gibt an, für welchen Konfigurationspfad der location-Abschnitt verwendet wird. Dadurch bestimmt es den Gültig-keitsbereich der Sperrung bzw. Entsperrung. Der Wert "" bedeutet in diesem Fall, dass für alle Konfigu-rationsebenen eine Entsperrung erfolgt, wohingegen der Wert Default Web Site/ anzeigen würde, dass der Abschnitt nur für eine Site namens Default Web Site entsperrt würde.

Anstatt die Konfiguration direkt zu modifizieren, können Sie das Befehlszeilentool Appcmd benutzen, das diese Aufgabe vereinfacht. Um beispielsweise den Abschnitt <asp> zu entsperren, so dass er überall in der Konfigurationshierarchie verwendet werden kann, benutzen Sie den folgenden Code.%windir%\system32\inetsrv\AppCmd unlock config /section:asp

Darüber hinaus kann der Administrator diesen Abschnitt nur für eine bestimmte Site oder Anwendung entsperren und für andere Sites oder Anwendungen gesperrt lassen. Um beispielsweise den Abschnitt <asp> nur für die Anwendung Default Web Site/MyApp zu entsperren, benutzen Sie den folgenden Code:%windir%\system32\inetsrv\AppCmd unlock config "Default Web Site/MyApp" /section:<SectionName>

Mit dem Befehl Appcmd Lock Config kann der Administrator außerdem Abschnitte sperren, die gegenwärtig entsperrt sind. Er kann auch den IIS-Manager benutzen, um den Delegierungsstatus von Konfigurationsabschnitten zu verwalten.

Vorsicht Die Aufgabe der Konfigurationsdelegierung besteht darin, den Schreibzugriff auf die Konfigurationen von Shared Servern zu kontrollieren. Sie ist weniger für dedizierte Server geeignet, wo der Serveradministrator sowohl die Server- als auch die Sitekonfiguration kontrolliert. Es wird jedoch empfohlen, die Delegierung von Konfigura-tionsabschnitten immer zu beschränken, selbst auf dedizierten Servern, und einen Konfigurationsabschnitt spezi-fisch zu entsperren, wenn dieser auf der Anwendungsebene genutzt werden soll. Dies verringert das Risiko, dass der Anwendungscode zukünftig versehentlich unerwünschte Konfigurationseinstellungen ohne Wissen des Admi-nistrators festlegt. Das ist besonders dann hilfreich, wenn Anwendungen installiert werden, die von Drittanbietern stammen und dazu führen können, dass ihre web.config-Dateien irgendwann ungewollte Konfigurationen enthalten.

In einigen Fällen ist die Delegierungskontrolle der Abschnittsebene nicht flexibel genug. Sie müssen dann zulassen, dass nur bestimmte Teile eines Konfigurationsabschnitts außer Kraft gesetzt werden, während die anderen Teile gesperrt bleiben. Das Konfigurationssystem bietet hierfür die Attribut-, Element- und Auflistungssperrung an. Das vierte Kapitel enthält weitere Informationen zu diesen Sperrungen.



Sensible Konfigurationsdaten schützenDas IIS 7.0-Konfigurationssystem stellt einen Verschlüsselungsmechanismus zur Verfügung, der sensible Informationen schützen kann, so dass ein Angreifer, der Zugriff auf die physikalische Konfi-gurationsdatei erlangt, die geschützten Informationen nicht lesen kann. Dies dient primär dem Schutz der Konfigurationsdaten für den Fall, dass diese den Computer verlassen und nicht mehr durch ACLs geschützt sind. Auf dem Server sind die mit den Konfigurationsdateien verknüpften ACLs der Haupt-mechanismus zum Sichern des Zugriffs auf die Konfiguration.

Sie können die Konfigurationsverschlüsselung nutzen, um in einem IIS 7.0-Konfigurationsabschnitt den Wert eines Attributs manuell zu verschlüsseln. Wenn Sie jedoch wissen, dass Ihr Konfigurations-abschnitt sensible Daten enthält, sollten Sie die automatische Verschlüsselung verwenden, indem Sie in Ihrem Konfigurationsabschnittsschema die zu schützenden Attribute so kennzeichnen, dass diese immer verschlüsselt werden. Dies ist vergleichbar mit den verschlüsselten Eigenschaften der Metabasis früherer IIS-Versionen. Im Gegensatz dazu können Sie das neue Verschlüsselungsverfahren jedoch einfach nutzen, um jeden beliebigen Teil Ihrer eigenen Konfigurationsabschnitte zu verschlüsseln.

Hinweis Das IIS 7.0-Konfigurationssystem unterstützt im Gegensatz zum ASP.NET-Konfigurationssystem, das nur ganze Abschnitte verschlüsseln kann, die Verschlüsselung auf der Attributebene. Obwohl dies flexibler, manchmal auch sehr viel effizienter ist (es ermöglicht Ihnen, nur die sensiblen Daten eines Abschnitts zu verschlüsseln und den Rest unverschlüsselt zu lassen), gibt es einige ungünstige Nebeneffekte. Der erste ist, dass Sie nicht Aspnet_ regiis.exe oder die ASP.NET-Verschlüsselung verwenden können, um IIS-Konfigurationsabschnitte zu verschlüsseln.

Der zweite und wohl einschneidendste Nebeneffekt ist die Tatsache, dass Sie nicht den IIS-Verwaltungsstack benutzen können, um auf ASP.NET-Konfigurationen zuzugreifen, die mit der Verschlüsselung der Abschnittsebene verschlüsselt wurden. Sie können jedoch die Microsoft.Web.Administration-APIs nutzen, um von ASP.NET-Modulen und .NET-Anwendungen aus auf IIS-Konfigurationsabschnitte zuzugreifen. Sie müssen dazu nicht auf System.Con-figuration zurückgreifen. Schließlich ist es nicht möglich, die IIS-Verschlüsselung der Attributebene zu verwenden, um .NET Framework- oder ASP.NET-Konfigurationsabschnitte zu verschlüsseln.

Dies geschieht, indem die encrypted-Eigenschaft der gewünschten Attributdefinitionen Ihres Konfigura-tionsabschnittsschemas auf true gesetzt wird. Mehrere integrierte IIS 7.0-Konfigurationsabschnitte nutzen dieses Verfahren, um sicherzustellen, dass ihre sensiblen Inhalte verschlüsselt bleiben. Der Abschnitt anonymousAuthentication kennzeichnet beispielsweise das Attribut für das anonyme Benutzer-kennwort als verschlüsselt. <sectionSchema name="system.webServer/security/authentication/anonymousAuthentication"> … <attribute name="password" type="string" caseSensitive="true" encrypted="true" defaultValue="[enc:AesProvider::enc]" /> … </sectionSchema>

Durch die Angabe der encrypted-Eigenschaft innerhalb der Attributschemadefinition gewährleisten Sie, dass das Attribut immer dann, wenn eine Konfigurations-API oder ein entsprechendes Tool diesem Attribut Daten zuweist, in verschlüsselter Form gespeichert wird. Sie geben den Standardverschlüs-selungsanbieter, der vom Konfigurationssystem für diese Eigenschaft verwendet wird, an, indem Sie ihn wie im vorherigen Beispiel über den defaultvalue-Wert referenzieren.


Verwaltungserweiterungen verwalten 415

Die Verschlüsselung geschieht vom Schreiber unbemerkt. Wenn dieses Attribut außerdem von einem Aufrufer gelesen wird, der Zugriff auf den Konfigurationsverschlüsselungsschlüssel hat, wird auch die Entschlüsselung unbemerkt durchgeführt, so dass der Aufrufer den Wert dieses Attributs in Form von Klartext abruft.

Vorsicht Obwohl die Verschlüsselung Ihre Konfigurationsdaten vor unerlaubter Einsicht schützt, wenn jemand physikalisch auf die Datei zugreift, schützt sie Ihre Konfiguration nicht vor Code im IIS-Arbeitsprozess. Das Konfigu-rationssystem innerhalb eines Arbeitsprozesses entschlüsselt automatisch alle verschlüsselten Konfigurationen (sofern der Arbeitsprozess auf den Schlüsselcontainer zugreifen kann). Somit kann jeder Code innerhalb eines Arbeitsprozesses auf diese Informationen zugreifen. Außer der Nutzung der Anwendungspoolisolation zur Ver-meidung des Zugriffs auf Konfigurationen, die für andere Anwendungspools vorgesehen sind, gibt es keine andere Möglichkeit, um den Konfigurationszugriff auf eine bestimmte Komponente innerhalb eines Arbeitsprozesses zu beschränken und dafür zu sorgen, dass die Konfiguration für andere Komponenten im Prozess nicht verfügbar ist. Weitere Informationen zu Anwendungspoolisolation erhalten Sie im neunten Kapitel, »Verwalten von Websites«, und im vierzehnten Kapitel.

Im vierzehnten Kapitel erhalten Sie weitere Informationen über die Optionen, die Ihnen zur Verfügung stehen, um den Konfigurationszugriff mithilfe der Verschlüsselung zu schützen.

Verwaltungserweiterungen verwaltenDas IIS 7.0-Konfigurationssystem bietet ein strukturiertes Verfahren, mit dem es möglich ist, das Verhal-ten von IIS und den IIS-Features zu kontrollieren. Es legt gewissermaßen ein Objektmodell für IIS offen, mit dem Sie IIS-Objekte, wie z.B. Sites, Anwendungspools, Anwendungen und virtuelle Verzeichnisse untersuchen können. Das Konfigurationssystem ist außerdem über das Konfigurationsabschnittsschema erweiterbar, so dass eine zusätzliche Webserverfunktionalität seine Konfiguration über das Objektmodell offen legen kann.

Obwohl die Verwaltung der Webserverkonfiguration die primäre Aufgabe des IIS 7.0-Konfigurations-systems ist, hebt es das Konzept des Verwaltungsobjektmodells auf die nächste logische Stufe. Es ermöglicht den Konfigurationsabschnitten, dynamische Eigenschaften und Methoden offen zu legen, die an Code und nicht an statische Konfigurationsdaten gebunden sind.

Dies geschieht mithilfe von Verwaltungserweiterungen des Konfigurationssystems. Ein hervorragendes Beispiel dafür, wie nützlich Verwaltungserweiterungen für die IIS 7.0-Verwaltung sind, ist der IIS 7.0-Konfigurationsabschnitt <applicationPools>, der eine Auflistung von Anwendungspooldefinitionen und die dazugehörigen Konfigurationen enthält. IIS 7.0 bietet eine Schemaerweiterung für diesen Abschnitt an, die dynamische Attribute und Methoden hinzufügt, welche mit der RSCA (Runtime State and Control API, RSCA) verknüpft sind. Dies ermöglicht es dem Leser des Konfigurationsabschnitts <applicationPools>, Laufzeitinformationen zu jedem Anwendungspoolelement abzurufen. Zu diesen Informationen zählen:

� Der Status (gestartet/beendet)

� Die Liste der gegenwärtig im Anwendungspool ausgeführten Arbeitsprozesse

� Die Liste der gegenwärtig in jedem Arbeitsprozess ausgeführten Anforderungen

� Die Liste ASP.NET-Anwendungsdomänen, die gegenwärtig in jedem Arbeitsprozess geladen sind



Darüber hinaus werden Methoden offen gelegt, die es dem Aufrufer ermöglichen, die einzelnen Anwendungspools wiederzuverwenden oder eine ASP.NET-Anwendungsdomäne in einem bestimmten Arbeitsprozess zu entladen. All diese Funktionalität wird über dieselben APIs offen gelegt, die auch zur Steuerung des Konfigurationsobjektmodells verwendet werden, so dass die Grenze zwischen statischer Konfiguration und dem von den IIS-Objekten offen gelegten Laufzeitverhalten nicht mehr klar erkennbar ist.

Nachfolgend ist beispielsweise ein C#-Skript aufgeführt, das die IIS 7.0-Konfigurationsobjekte benutzt, um alle Anwendungspools des Systems, einige Konfigurationsinformationen dieser Pools und die gegenwärtig ausgeführten Arbeitsprozesse (über die RSCA-Verwaltungserweiterungen) aufzulisten: var adminManager = new ActiveXObject("Microsoft.ApplicationHost.AdminManager"); var appPoolsSection = adminManager.GetAdminSection( "system.applicationHost/applicationPools", "MACHINE/WEBROOT/APPHOST"); // // Die Auflistung der Anwendungspools durchlaufen // var appPoolsCollection = appPoolsSection.Collection; for(var i = 0; i < appPoolsCollection.Count; i++) { var appPoolElement = appPoolsCollection.Item(i); var name = appPoolElement.GetPropertyByName("name").Value; var appPoolStateProperty = appPoolElement.GetPropertyByName("state"); var state = appPoolStateProperty.Schema.PossibleValues.Item ( appPoolStateProperty.Value ).Name; WScript.Echo("Anwendungspool *" + name + "* (" + state + ")"); // // Die Auflistung der Arbeitsprozesse durchlaufen // var workerProcessesElement = appPoolElement.ChildElements.Item("workerProcesses"); var workerProcessCollection = workerProcessesElement.Collection; for(var wp = 0; wp < workerProcessCollection.Count; wp++) { var workerProcess = workerProcessCollection.Item(wp); WScript.Echo(" Arbeitsprozess - " + workerProcess.GetPropertyByName("processId").Value); } }

Eine Beispielausgabe dieses Skripts (die nachfolgend aufgeführt ist) zeigt die auf dem Computer konfigurierten Anwendungspools, deren Status und die Liste der in jedem Pool aktiven Arbeitsprozesse. Die letzten beiden Informationen stammen von der RSCA-Verwaltungserweiterung, obwohl die Pro-grammierung, die notwendig ist, um darauf zuzugreifen, sich nicht von dem programmgesteuerten Zugriff auf Konfigurationsattribute unterscheidet. Die Beispielausgabe ist wie folgt aufgebaut:


Verwaltungserweiterungen verwalten 417

Anwendungspool *DefaultAppPool* (Gestartet) Arbeitsprozess - 2900 Anwendungspool *Classic .NET AppPool* (Gestartet)

Zusätzlich zum Offenlegen von Laufzeitinformationen über das Konfigurationsobjektmodell, bieten die Verwaltungserweiterungen ebenfalls die einfache Möglichkeit, die Verwaltungs- oder Bereitstellungs-aufgaben zu Paketen zusammenzuschnüren und als Methoden der zugehörigen Konfigurations-abschnitte zur Verfügung zu stellen. Sie werden nun einen Blick auf die Funktionsweise von Verwaltungserweiterungen werfen.

Wie Verwaltungserweiterungen funktionierenEine Verwaltungserweiterung ist ein COM-Objekt, das die vom IIS 7.0-Konfigurationssystem veröffent-lichten Schnittstellen implementiert, um die Werte dynamischer Attribute zur Verfügung zu stellen und/oder dynamischer Methoden von Konfigurationsabschnitten auszuführen.

Es ist über die Abschnittsschemadefinition mit dem Abschnitt verknüpft. Die Definition dynamischer Attribute kann die COM-ProgId des COM-Verwaltungserweiterungobjekts einfach über die Schema-eigenschaft extension angeben. Das Schema kann ebenfalls Definitionen dynamischer Methoden enthalten, die Argumente entgegennehmen und Informationen zurückgeben können. Ein Beispiel für beides finden wir im RSCA-Erweiterungsschema, das sich in Rscaext.xml befindet. Es fügt den Konfi-gurationsabschnitten <sites> und <applicationPools> eine dynamische Funktionalität hinzu. <sectionSchema name="system.applicationHost/sites"> <collection addElement="site"> <attribute name="state" type="enum" extension="Microsoft.ApplicationHost.RscaExtension"> <enum name="Starting" value="0" /> <enum name="Started" value="1" /> <enum name="Stopping" value="2" /> <enum name="Stopped" value="3" /> <enum name="Unknown" value="4" /> </attribute> <method name="Start" extension="Microsoft.ApplicationHost.RscaExtension" /> <method name="Stop" extension="Microsoft.ApplicationHost.RscaExtension" /> </collection> </sectionSchema>

Das Schema fügt jedem <site>-Element ein state-Attribut hinzu, das an das COM-Objekt Microsoft.Appli-cationHost.RscaExtension gebunden ist. Es definiert außerdem die Methoden Start und Stop, die ebenfalls an diese Erweiterung gebunden sind.

Hinweis Sie haben vielleicht bemerkt, dass die Datei Rscaext.xml Schemadefinitionen dynamischer Attribute und Methoden für die bereits definierten Konfigurationsabschnitte <sites> und <applicationPools> enthält. Hier wird die Möglichkeit des Konfigurationssystems genutzt, Konfigurationsschemata zusammenzuführen, so dass neue Schemadateien bereits vorhandene Konfigurationsabschnitte erweitern und nicht nur neue Abschnitte hinzufügen können.

Wenn das Konfigurationsskript in einem Konfigurationsabschnitt auf dynamische Eigenschaften zugreift oder dynamische Methoden aufruft, erfolgt ein Aufruf der entsprechenden Verwaltungserweiterungen, damit diese den Attributwert zur Verfügung stellt oder die Methodenausführung initiiert. Wenn der



Aufrufer keine dynamischen Attribute verlangt und auch keine Methoden aufruft, wird die Verwaltungs-erweiterung niemals generiert und ausgeführt, und der Benutzer arbeitet auch weiterhin ausschließlich mit der statischen Konfiguration.

Verwaltungserweiterungen installierenUm Verwaltungserweiterungen zu installieren, müssen Sie sie im Abschnittsschema registrieren, ent-weder als Teil neuer Konfigurationsabschnittsdefinitionen oder indem Sie neue dynamische Attribut- und Methodendefinitionen für bereits vorhandene Konfigurationsabschnitte hinzufügen. Aus der Schemaperspektive betrachtet ist die Installation neuer Verwaltungserweiterungen vergleichbar mit der Installation neuer Konfigurationsabschnitte (lesen Sie früher in diesem Kapitel den Abschnitt »Neue Konfigurationsabschnitte installieren«).

Da Verwaltungserweiterungen an COM-Objekte gebunden sind, muss das COM-Objekt, das die benötig-ten Schnittstellen implementiert, im System registriert sein (dies geschieht in der Regel mit Regsvr32.exe oder bei .NET-COM-Objekten mit Regasm.exe). Die COM-Registrierungsinformationen müssen den ProgId-Anzeigenamen enthalten, der im Konfigurationsabschnittsschema referenziert wird.

Verwaltungserweiterungen sichernIm Gegensatz zu Konfigurationsabschnitten enthalten Verwaltungserweiterungen Code und können deshalb für Ihren Server ein Risiko darstellen. Verwaltungserweiterungen werden außerdem von Ver-waltungstools und -skripts aufgerufen, für deren Start in der Regel Administratoren verantwortlich sind, so dass ihr Code mit administrativen Berechtigungen ausgeführt wird. Viele Verwaltungserweiterungen benötigen sogar administrative Rechte, um arbeiten zu können. Dazu zählt auch die in IIS 7.0 enthaltene RSCA-Erweiterung.

Dies ist bei Webservermodulen anders, da diese standardmäßig in IIS-Arbeitsprozessen ausgeführt werden, für deren Ausführung Identitäten mit geringen Berechtigungen verwendet werden und die mithilfe der Codezugriffssicherheit von ASP.NET (bei verwalteten Modulen) noch weiter gesichert werden können. Verwaltungserweiterungen stellen deshalb für den Server ein höheres Risiko als Webservermodule dar.

Die Möglichkeit, Konfigurationsabschnittsschemata zu veröffentlichen, ist auf Administratoren beschränkt (was auch für die Registrierung von COM-Objekten auf dem Computer gilt). Auf diese Weise wird ausgeschlossen, dass nicht vertrauenswürdige Benutzer Verwaltungserweiterungen auf dem Computer registrieren können. Die Administratoren selbst müssen jedoch Vorsicht walten lassen, wenn sie Verwaltungserweiterungen installieren. Sie müssen der Quelle einer Erweiterung vertrauen.

Tabelle 13.3 zeigt einige typische Benutzer des Konfigurationssystems, die Verwaltungserweiterungen laden und aufrufen dürfen.


IIS-Manager-Erweiterungen verwalten 419

WAS, IIS-Arbeitsprozesse, die Metabasiskompatibilität und Appcmd.exe verwenden (aus unterschied-lichen Gründen) keine Verwaltungserweiterungen. Der WMI-Dienst, Skripts, die mit den COM-Objekten des Konfigurationssystems arbeiten, und .NET-Programme, die die Microsoft.Web.Administration-APIs nutzen, können jedoch auf die ausgeführten Verwaltungserweiterungen zugreifen und werden oft (was auch notwendig ist) mit administrativen Berechtigungen ausgeführt (dies geschieht, wenn der Aufrufer administrative Rechte besitzt). Deshalb gibt es keine einfache Möglichkeit, um Verwaltungs-erweiterungen abzuschirmen. Aus diesem Grund ist besondere Vorsicht vonnöten, wenn solche Erweiterungen auf dem Server installiert werden sollen.

IIS-Manager-Erweiterungen verwaltenZusätzlich zu den programmatischen Optionen und den Befehlszeilentools bietet der IIS 7.0-Verwaltungsstack ebenfalls ein Verwaltungstool mit einer grafischen Benutzeroberfläche an. Der IIS-Manager, der das alte MMC-Snap-In früherer IIS-Versionen ersetzt, wurde vollständig überarbeitet, um die Endbenutzer mit einer intuitiven, aufgabenorientierten Benutzeroberfläche für die Verwaltung des Servers zu versorgen. Das Tool, das in Abbildung 13.2 dargestellt ist, dient ebenfalls als Basis für die IIS 7.0-Remoteverwaltung, weil es eine auf HTTPS basierende sichere Remotekonnektivität und eine delegierte Siteverwaltung bietet. Weitere Informationen zur Verwendung des IIS-Managers finden Sie im sechsten Kapitel, »Verwenden von IIS-Manager«.

Der IIS-Manager stellt ganz im Sinne von IIS 7.0 seine eigene Erweiterbarkeitsplattform zur Verfügung, mit der Sie neue Benutzeroberflächenfeatures für die Verwaltung hinzufügen und das Erscheinungsbild und die Funktionalität der Oberfläche detailliert anpassen können. Dies vervollständigt das Bild von der Erweiterbarkeit des IIS 7.0-Verwaltungsstacks, weil es nun möglich ist, dass neue Konfigurations-abschnitte und Verwaltungserweiterungen, die auf der Konfigurationssystemebene hinzugefügt wurden, entsprechende Benutzeroberflächenelemente für die Verwaltung durch den Endbenutzer zur Verfügung stellen können. Diese Benutzeroberflächenerweiterungen profitieren ebenfalls von den Remoteverwal-tungs- und Delegierungsfähigkeiten, die das Tool bietet. Das Tool kümmert sich um die gesamte Netz-werkkonnektivität, um die Authentifizierung anhand von Windows- oder Nicht-Windows-Anmelde-informationsspeichern und um die delegierte Verwaltung, so dass sich eine Benutzeroberflächenerweite-rung ganz auf die eigentliche Verwaltungsaufgabe konzentrieren kann, ohne sich darum kümmern zu müssen, ob die Verwaltung lokal oder remote erfolgt.

Tabelle 13.3 Benutzer und Berechtigungen für Verwaltungserweiterungen

Benutzer Ausführungsberechtigung

WAS Nutzt keine Erweiterungen

IIS-Arbeitsprozesse Nutzt keine Erweiterungen

Metabasiskompatibilität (Inetinfo.exe) Nutzt keine Erweiterungen

WMI-Dienst Lokales System

Appcmd Nutzt keine Erweiterungen

IIS-Manager (Inetmgr.exe) Aufrufer (in der Regel der Administrator)

Konfigurationsskripts, Microsoft.Web.Administration-Programme Aufrufer (in der Regel der Administrator)



Abbildung 13.2 Der IIS-Manager

Die Funktionsweise von IIS-Manager-ErweiterungenDie Hauptaufgabe einer Benutzeroberflächenerweiterung besteht darin, die Benutzeroberflächen-elemente für die Verwaltung des jeweiligen Konfigurationsabschnitts oder zur Durchführung einer Verwaltungsaufgabe zur Verfügung zu stellen. Sie erfahren im sechsten Kapitel mehr über den IIS-Manager und die von ihm angebotenen Standardfeatures. Jede Benutzeroberflächenerweiterung besteht in der Regel aus den folgenden Komponenten:

� Das clientseitige Benutzeroberflächenmodul

Dies ist die clientseitige Komponente, die die Benutzeroberflächenelemente bereitstellt. Dazu zählen neue Benutzeroberflächenseiten und andere Anpassungen der Benutzeroberfläche des Tools. Es ruft außerdem den entsprechenden Moduldienst auf, um die erforderlichen Verwaltungsaufgaben zu initiieren.

� Der serverseitige Moduldienst

Dies ist die serverseitige Komponente, die die zugrunde liegende Verwaltungsfunktionalität zur Verfügung stellt. Sie ruft in der Regel Microsoft.Web.Administration-APIs auf, um auf den IIS 7.0-Verwaltungsstack zuzugreifen.


Die Trennung zwischen Clientbenutzeroberflächenfunktionalität und Serververwaltungsfunktionalität ist notwendig, um die Remoteverwaltung zu ermöglichen. Die clientseitige Komponente wird immer auf dem Client instanziiert, der wiederum auf demselben Computer wie der verwaltete Server oder aber auf einem Remotecomputer ausgeführt werden kann. Dabei stellt der Remotecomputer über den Ver-waltungsdienst des IIS-Managers eine Verbindung zum Server her. Der Moduldienst ist die server-seitige Komponente, die die zugrunde liegenden Verwaltungsaufgaben ausführt und immer auf dem Server instanziiert wird. Auf diese Weise muss sich die Verwaltungsfunktionalität in einer Benutzer-oberflächenerweiterung nicht selbst um die Remoteverwaltung kümmern, weil hierfür der Server verantwortlich ist.

Sowohl die clientseitigen als auch die serverseitigen Komponenten sind in Form von .NET-Assemblys mit starken Namen implementiert und müssen beide im GAC (Globaler Assemblycache, GAC) des Servers installiert und in der Serverkonfiguration registriert werden. Deshalb müssen beide Assemblys vom Entwickler signiert werden, bevor sie installiert werden können.

Der IIS-Manager verwendet eine eigene Konfigurationsdatei für die Serverebene, administration.config, die sich von der vom Webserver verwendeten Konfigurationsdatei für die Serverebene (applicationHost. config) unterscheidet. Sie befindet sich ebenfalls im Verzeichnis %windows%\System32\Inetsrv\Config. Der IIS-Manager benutzt diese Datei anstelle der web.config-Stammdatei des Frameworks, wenn er seine eigene Konfiguration liest. Diese Konfiguration enthält die Registrierungsinformationen für alle IIS-Manager-Erweiterungen.<moduleProviders>  <add name="Modules" type="Microsoft.Web.Management.Iis.Modules.ModulesModuleProvider, Microsoft.Web.Management.Iis, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="Handlers" type="Microsoft.Web.Management.Iis.Handlers.HandlersModuleProvider, Microsoft.Web.Management.Iis, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> … </moduleProviders>  <location path="."> <modules> <add name="Modules" /> <add name="Handlers" /> … </modules> </location>

In dem hier gezeigten Auszug werden zwei Benutzeroberflächenfeatures registriert, die IIS 7.0-Web-servermodule (das Modules-Feature) und Webserverhandlerzuordnungen (Handlers) verwalten. Sie werden außerdem standardmäßig für die delegierte Verwaltung aller Websites aktiviert.

Der Abschnitt <moduleProviders> definiert alle IIS-Manager-Erweiterungen, die im System registriert sind, und er gibt den zugehörigen vollqualifizierten Typnamen des entsprechenden Modulanbieters an. Jeder Modulanbieter ist dafür verantwortlich, zur Laufzeit die Typinformationen über die clientseitigen Benutzeroberflächenmodule und die entsprechenden serverseitigen Moduldienstkomponenten zur Verfügung zu stellen. Diese Informationen werden dann vom IIS-Manager und dem Verwaltungsdienst verwendet, um die richtigen Komponenten zu initialisieren.


Mit dem Abschnitt <modules> ist es möglich, die Benutzeroberflächenmodule für eine bestimmte Site selektiv zu aktivieren. Alle Benutzeroberflächenmodule sind standardmäßig für alle Sites aktiviert, da sie auf der Ebene "." hinzugefügt werden.

Hinweis Bei einer Remoteverwaltung muss nicht der Clientcomputer die Benutzeroberflächenerweiterungen auf dem Server registriert haben. Wenn der IIS-Manager eine Remoteverbindung zum Server herstellt, kann er die Clientkomponenten der auf dem Server registrierten Benutzeroberflächenerweiterungen herunterladen und die Benutzeroberflächenfeatures auf dem Client anzeigen.

IIS-Manager-Erweiterungen installierenDie Installation von IIS-Manager-Erweiterungen ist sehr einfach. Gehen sie dazu wie folgt vor:

1. Installieren Sie die Client- und Server-.NET-Assemblys im globalen Assemblycache des Servers.

2. Registrieren Sie den Modulanbieter in der Konfigurationsdatei administration.config und aktivieren Sie ihn gegebenenfalls für die delegierte Siteverwaltung.

Denken Sie daran, dass die Client- und Serverassemblys, aus denen die IIS-Manager-Erweiterung besteht, einen starken Namen besitzen müssen. Sie müssen somit vom Entwickler signiert worden sein.

Um den Modulanbieter zu registrieren, müssen Sie seinen vollqualifizierten Typ der Auflistung <moduleProviders> hinzufügen, und Sie müssen den ausgewählten Namen des Moduls innerhalb der administration.config-Konfigurationsdatei in der Auflistung <modules> aufführen. Dazu sollten Sie den vollqualifizierten Typnamen der Modulanbieterklasse kennen, der in der Regel vom Entwickler der Erweiterung vorgegeben wird.

Vorsicht Sie müssen der Codequelle vertrauen, wenn Sie auf dem Server Erweiterungen installieren, da diese mit administrativen Rechten ausgeführt werden können, wenn Sie auf Ihrem Computer den IIS-Manager starten.

IIS-Manager-Erweiterungen sichernIIS-Manager-Erweiterungen stellen genauso wie Verwaltungserweiterungen ein hohes Risiko für das Konfigurationssystem dar, weil sie Code enthalten, der auf dem Server mit administrativen Berechti-gungen ausgeführt werden kann. Wenn somit mithilfe dieser Erweiterungen böswillige Absichten verfolgt werden sollen oder die Erweiterungen kompromittiert sind, können sie jeden möglichen Schaden anrichten.

Tabelle 13.4 listet die Programme auf, die IIS-Manager-Erweiterungen laden, sowie die Berechtigungen, mit denen diese Programme ausgeführt werden.

Tabelle 13.4 Programme, die IIS-Manager-Erweiterungen laden

Programm Ausführungsberechtigung

IIS-Manager (Inetmgr.exe) Aufrufer (bei einer lokalen Serververwaltung in der Regel der Administrator)

Webverwaltungsdienst (Wmsvc.exe) Lokaler Dienst (NT Service\wmsvc)Authentifizierter Benutzer (wenn die Windows-Authentifizierung verwendet wird)



Wenn Sie den IIS-Manager lokal verwenden, um den Server zu verwalten, wird er unter der Identität des Benutzers ausgeführt, der das Tool gestartet hat. Da es sich hierbei in der Regel um lokale Admi-nistratoren handelt – dies ist für einen großen Teil der Serververwaltung auch notwendig, z.B. für die Erstellung von Sites und das Ändern der Konfiguration der Serverebene – werden die Erweiterungen des Tools meistens mit administrativen Rechten ausgeführt.

Wenn Sie den Webverwaltungsdienst nutzen, um den Server remote zu verwalten, wird er unter Verwen-dung des Kontos Lokaler Dienst (wird von der Dienstisolation NT Service\wmsvc zugeordnet) oder, wenn die Remoteverbindung mithilfe der Windows-Authentifizierung hergestellt wird, unter der Identität des authentifizierten Benutzers ausgeführt. Verwaltungserweiterungen werden nur dann mit administrativen Berechtigungen ausgeführt, wenn der Remotebenutzer ein Administrator des Computers ist und mithilfe der Windows-Authentifizierung authentifiziert wurde. Bei einer Nicht-Windows-Authentifizierung kann eine Erweiterung ebenfalls auf einige Serverressourcen zugreifen, die im Einzugsbereich der SID NT Service\wmsvc liegen. Dies bietet einen besseren Schutz, sollte die Verwaltungserweiterung durch einen Remoteangriff kompromittiert werden. Der Remoteverwaltungsdienst ist natürlich gesperrt, und eine Authentifizierung ist notwendig, um auf die Funktionalität dieses Dienstes zugreifen zu können. Deshalb kann er nur von solchen Benutzern verwendet werden, die über das Recht verfügen, den Server remote zu verwalten, und die mit den Erweiterungen arbeiten dürfen.

Da der IIS-Manager die delegierte Verwaltung von Websites unterstützt, kann Benutzern, die auf dem Server über keine administrativen Rechte verfügen, die Genehmigung erteilt werden, ihre Website-konfiguration remote (oder lokal) zu verwalten. Diese Verwaltung wird zu einem sehr großen Teil von der Konfigurationsdelegierung kontrolliert, aber der IIS-Manager bietet ebenfalls eine weitere Möglich-keit an, um festzulegen, welche Benutzeroberflächenfeatures den Siteadministratoren zur Verfügung stehen sollen. Dies ist wichtig, wenn Sie bedenken, dass neue Verwaltungserweiterungen Benutzer-oberflächenfeatures offen legen können, die über die Konfiguration hinausgehen und in einigen Fällen keine eigene Delegierungskontrolle implementieren.

In diesen Szenarien muss der Serveradministrator die Siteadministratoren vom Zugriff auf solche Benutzeroberflächenfeatures abhalten. Dies ist mit dem in Abbildung 13.3 dargestellten Feature Dele-gierung von Features möglich, das verfügbar ist, wenn Sie als Serveradministrator eine Verbindung zum Server hergestellt haben. Sie können das Feature vor Nicht-Administratoren verbergen, indem Sie seinen Delegierungszustand auf Nicht delegiert setzen. Oder konfigurieren Sie es so, dass seine Inhalte eingesehen werden können, aber der zugrunde liegende Zustand nicht geändert werden darf. Setzen Sie den Status des Features hierfür auf Schreibgeschützt. Denken Sie jedoch daran, dass die Verwal-tungserweiterungen selbst dafür verantwortlich sind, die Delegierung richtig zu implementieren. Wenn Sie diesbezüglich Zweifel hegen, sollten Sie die Option Nicht delegiert verwenden.

Wenn ein Remoteclient den IIS-Manager benutzt, um eine Verbindung zum Server herzustellen, vergleicht der IIS-Manager die auf dem Server verfügbaren Modulanbieter mit dem, was der Client anbietet. Wenn auf dem Server eine neue Erweiterung verfügbar ist, fordert der IIS-Manager den Client auf, diese Erweiterung herunterzuladen und zu installieren. Akzeptiert der Client, installiert der IIS-Manager die Erweiterung im Benutzerprofil (sie wird nicht im GAC installiert) und lädt sie in den IIS-Manager, der auf dem Clientcomputer möglicherweise unter Verwendung des Administratorkontos ausgeführt wird (auch wenn der Client keine administrativen Anmeldeinformationen benutzt hat, um eine Remoteverbindung zum Server herzustellen). Deshalb ist es für den Serveradministrator wichtig, der Erweiterungsquelle vertrauen zu können, und der Client muss dem Server vertrauen. Andernfalls könnte eine böswillige Erweiterung verwendet werden, um die Sicherheit des Clientcomputers zu kompromittieren, der über den IIS-Manager eine Verbindung zum Server herstellt.



Abbildung 13.3 Featuredelegierung

Sie können das vom IIS-Manager zur Verfügung gestellte, zertifikatbasierte Publisher-Vertrauens-modell nutzen, um zu gewährleisten, dass alle Erweiterungen, die Sie auf Ihrem Server installieren, von einem Publisher signiert sind, dem Sie vertrauen. Sie können ebenfalls die Clients so konfigurieren, dass sie diesem Publisher vertrauen, wodurch gewährleistet wird, dass der auf die Clientcomputer heruntergeladene Code sicher ist. Anders ausgedrückt sollten Sie keine Erweiterungen installieren, die von unbekannten oder nicht vertrauenswürdigen Publishern bzw. von unbekannten oder nicht vertrauenswürdigen Webservern stammen!

Vorsicht Installieren Sie keine Verwaltungserweiterungen, die von nicht vertrauenswürdigen Publishern stammen. Dies gilt besonders dann, wenn Sie mit einem Server verbunden sind, dem Sie nicht vertrauen.

Selbst wenn Sie den Download einer Erweiterung nicht akzeptieren, wird Ihre Remoteverwaltungs-sitzung auch weiterhin korrekt arbeiten, und Sie können jede vorhandene Verwaltungsfunktionalität mit Ausnahme der Erweiterung nutzen, die Sie nicht heruntergeladen haben. Wenn Sie das nächste Mal eine Verbindung herstellen, verfügen Sie wieder über die Möglichkeit, die Erweiterung herunterzuladen.

Hinweis Sollten die von Ihnen heruntergeladenen Erweiterungen, aus welchem Grund auch immer, geschädigt oder von Ihrem Client nicht mehr benötigt werden, können Sie den Erweiterungsdownloadcache leeren, indem Sie den Befehl Inetmgr.exe /reset benutzen.



ZusammenfassungWie der Webserver selbst bietet auch der IIS 7.0-Verwaltungsstack eine End-To-End-Erweiterbarkeit, um Drittanbieterkonfigurationen zu ermöglichen und Verwaltungslösungen anzubieten. Diese Erweiterbarkeit bildet gleichzeitig die Kernplattform des Verwaltungsstacks, wobei die gesamte integrierte Feature-konfigurations- und Verwaltungsfunktionalität auf diese Plattform aufbaut.

Sie können darauf zurückgreifen, um für Ihre benutzerdefinierten Webserverfeatures benutzerdefinierte Konfigurationen bereitzustellen und diese Konfigurationen mit den IIS 7.0-Konfigurationstools und -APIs zu verwalten, und zwar in derselben Weise, wie Sie die integrierte Serverkonfiguration verwalten. Sie können aber noch weiter gehen und die Funktionalität des Verwaltungsstacks erweitern, indem Sie neue Verwaltungserweiterungen hinzufügen, die umfassende IIS 7.0-Laufzeitdaten zur Verfügung stellen oder nützliche Verwaltungsfunktionen offen legen. Schließlich können Sie IIS-Manager-Erwei-terungen verwenden, um für diese Konfigurationen und Verwaltungsfunktionen eine integrierte Ver-waltung über Benutzeroberflächenelemente zu ermöglichen. Und Sie können die integrierte sichere Remoteverwaltung und Delegierung des IIS-Managers nutzen.

Dieses Kapitel schließt das Thema IIS 7.0-Erweiterbarkeit ab und gibt Ihnen das Wissen an die Hand, das Sie benötigen, um Erweiterungen des IIS 7.0-Verwaltungsstacks richtig bereitzustellen und zu sichern. Weitere Informationen zur Verwaltung der Laufzeitmodule des Webservers finden Sie im zwölften Kapitel, »Webservermodule verwalten«.


� Kapitel 14, »Implementieren von Sicherheitsstrategien«, enthält Informationen zum Sichern von Konfigurationen.

� Kapitel 4, »Verstehen des Konfigurationssystems«, beschreibt die Verwendung des Konfigurations-systems.

� Lesen Sie IIS.NET, wo Sie Artikel und Informationen zu IIS7 finden.

� Informationen zur Installation von IIS 7.0-Konfigurationsabschnitten mithilfe von IISSchema.exe finden Sie unter http://mvolo.com/blogs/serverside/archive/2007/08/04/IISSCHEMA.EXE-_2D00_ -A-tool-to-register-IIS7-configuration-sections.aspx.


427

K A P I T E L 1 4

Implementieren von Sicherheitsstrategien

Inhalt dieses Kapitels:� Sicherheitsänderungen unter IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

� Anwendungen für die Nutzung von geringstmöglichen Berechtigungen konfigurieren . . . . . . . . . 445

� Die Zugriffskontrolle implementieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

� Sichern der Kommunikation mit SSL (Secure Sockets Layer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

� Sichern der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493




Der Vorgänger von IIS 7.0 (Internet Information Services) – IIS 6.0 – hat die Messlatte für die Bereit-stellung einer sicheren Webserverplattform sehr hoch gelegt. IIS 7.0 gründet auf einem großen Teil der Featurecodebasis und Sicherheitspraktiken von IIS 6.0, die während der Entwicklung dieses Web-serversystems entstanden. Es basiert außerdem auf vielen Designprinzipien, die zu der durch die hervorragende Sicherheit bedingten IIS 6.0-Erfolgsgeschichte beitrugen. IIS 7.0 hat diese Prinzipien weiterentwickelt, um die Sicherheit des Webservers und der darauf ausgeführten Anwendungen zu verbessern. Zu diesen Prinzipien zählen das Konzept der standardmäßigen Sicherheit sowie das Ver-kleinern der Angriffsfläche und der Einsatz von geringstmöglichen Berechtigungen. Mit all diesen Mitteln soll verhindert werden, dass Anwendungssicherheitslücken erfolgreich von Angreifern genutzt werden können. Mit IIS 7.0 ist es einfacher als jemals zuvor, diese wichtigen Sicherheitsprinzipien anzu-wenden. Dazu bietet es eine Modularität an, die es Ihnen ermöglicht, Webserver mit einer minimalen Angriffsfläche zu erstellen und Anwendungen in isolierten Umgebungen ausführen zu lassen.

Viele dieser IIS 6.0-Sicherheitsfeatures sind unter IIS 7.0 auch weiterhin verfügbar. In diesem Kapitel werden wir uns zunächst mit den für IIS 7.0 veränderten Sicherheitsfeatures beschäftigen, aber auch mit den neuen von IIS 7.0 eingeführten Features, die helfen, die Webserver- und Anwendungssicherheit zu verbessern. Danach werfen wir einen Blick darauf, wie die allgemeinen Sicherheitsprinzipien zur Ver-kleinerung der Angriffsfläche und zur Arbeit mit geringstmöglichen Berechtigungen angewendet wer-den, um die Sicherheit des Webservers weiter zu verstärken. Schließlich wird der Einsatz von Sicher-heitsfeatures unter IIS 7.0 ausführlich erläutert. Zu diesen Features zählen die Authentifizierung, die Autorisierung, die Sicherung der Netzwerkkommunikation mit TLS (Transport Layer Security) und der Schutz der Konfiguration.


428 Kapitel 14: Implementieren von Sicherheitsstrategien

Sicherheitsänderungen unter IIS 7.0IIS 7.0 gründet auf der zentralen Sicherheitsbasis seines Vorgängers IIS 6.0. Deshalb wird ein sehr großer Teil der für IIS 6.0 entwickelten Sicherheitsprinzipien und -features auch heute noch verwendet. IIS 7.0 hat jedoch Verbesserungen eingeführt, die die Sicherheit des Webservers zusätzlich erweitern.

� Der anonyme Benutzer, der standardmäßig für die anonyme Authentifizierung konfiguriert ist, ist das neue integrierte IUSR-Konto. Dieses Konto ist integriert und erfordert kein Kenn-wort, das von Server zu Server erneuert und synchronisiert werden muss. Darüber hinaus bleiben die für das IUSR-Konto festgelegten Berechtigungen auch dann gültig, wenn sie auf einen anderen IIS 7.0-Server kopiert werden, weil das IUSR-Konto über eine bekannte SID (Security Identifier) verfügt, die auf jedem Computer gleich ist. Weitere Informationen finden Sie später in diesem Kapitel im Abschnitt »Anonyme Authentifizierung«.

� Die IIS_WPG-Gruppe wurde durch die integrierte Gruppe IIS_IUSRS ersetzt. Diese Gruppe ist integriert und sorgt dafür, dass die für sie gesetzten Berechtigungen gültig bleiben, wenn diese auf einen anderen IIS 7.0-Server kopiert werden. Dies ist möglich, weil die Gruppe eine bekannte SID (Security Identifier) besitzt. Darüber hinaus wird diese SID automatisch in das Arbeitspro-zesstoken eines IIS-Arbeitsprozesses eingefügt, so dass manuelle Gruppenmitgliedschaften für benutzerdefinierte Anwendungspoolidentitäten nicht mehr notwendig sind. Weitere Informationen finden Sie später in diesem Kapitel im Abschnitt »NTFS-Berechtigungen für den Mindestzugriff gewähren«.

� Die anonyme Authentifizierung kann so konfiguriert werden, dass sie die Anwendungs-poolidentität verwendet. Auf diese Weise müssen, wenn die anonyme Authentifizierung verwendet wird, für den Zugriff auf die Inhalte nur die Berechtigungen der Anwendungspool-identität überprüft werden, was die Berechtigungsverwaltung vereinfacht. Weitere Informationen finden Sie später in diesem Kapitel im Abschnitt »NTFS-Berechtigungen für den Mindestzugriff gewähren«.

� IIS-Arbeitsprozesse erhalten automatisch eine eindeutige Anwendungspool-SID (Security Identifier), die Sie für die Gewährung des Zugriffs auf den jeweiligen Anwendungspool verwenden können, wodurch die Anwendungsisolation möglich wird. Weitere Informationen erhalten Sie später in diesem Kapitel im Abschnitt »Anwendungen isolieren«.

� Die Konfigurationsisolation isoliert automatisch die Konfiguration der Serverebene für jeden Anwendungspool. Die in applicationHost.config enthaltene Konfiguration der Serverebene wird automatisch isoliert, indem gefilterte Kopien dieser Konfiguration für jeden Anwendungspool erstellt werden. Andere Anwendungspools können diese Kopie nicht lesen. Weitere Informationen hierzu finden Sie später in diesem Kapitel im Abschnitt »Die Konfigurationsisolation verstehen«.

� Virtuelle Verzeichnisse können feste Anmeldeinformationen festlegen, und zwar unabhängig davon, ob sie auf UNC-Freigaben (Universal Naming Convention) verweisen oder im lokalen Dateisystem vorhanden sind. Im Gegensatz zu IIS 6.0, das feste Anmeldeinformationen nur für den Zugriff auf UNC-Freigaben unterstützt, lässt IIS 7.0 solche Anmeldeinformationen für alle virtuellen Verzeichnisse zu.

� Die Windows-Authentifizierung wird standardmäßig im Kernel durchgeführt. Dies ver-bessert die Konfigurierbarkeit des Kerberos-Protokolls auf dem Server. Es verbessert außerdem die Leistung der Windows-Authentifizierung. Es kann sich jedoch auf einige Anwendungen, die mit


Sicherheitsänderungen unter IIS 7.0 429

benutzerdefinierten Clients arbeiten, nachteilig auswirken, wenn diese vorab Authentifizierungs-anmeldeinformationen für die erste Anforderung senden. Dieses Verhalten kann in der Konfigura-tion deaktiviert werden. Weitere Informationen hierzu finden Sie später in diesem Kapitel im Abschnitt »Windows-Authentifizierung«.

� Das neue Feature Anforderungsfilterung bietet eine erweiterte URLScan-Funktionalität. Sie können das neue Feature Anforderungsfilterung benutzen, um Ihren Webserver gegen Anforde-rungen zu schützen, die nicht dem Standard entsprechen oder suspekt erscheinen. Darüber hinaus können Sie verhindern, dass ein Zugriff auf bestimmte Ressourcen und Verzeichnisse erfolgt. Weitere Informationen finden Sie später in diesem Kapitel im Abschnitt »Anforderungsfilterung«.

� Mit dem neuen Feature URL-Autorisierung können Anwendungen den Zugriff auf Res-sourcen über konfigurationsbasierte Regeln steuern. Das neue Feature URL-Autorisierung ermöglicht flexible konfigurationsbasierte und auf Benutzer und Rollen bezogene Regeln, mit denen der Zugriff auf Anwendungsressourcen gesteuert werden kann. Es unterstützt außerdem die Nutzung des ASP.NET-Rollendienstes. Weitere Informationen finden Sie später in diesem Kapitel im Abschnitt »URL-Autorisierung«.

Darüber hinaus wurden für IIS 7.0 mehrere Änderungen an bereits vorhandenen Sicherheitsfeatures vorgenommen. Außerdem wurden mehrere beanstandete Sicherheitsfeatures entfernt, die sich negativ auf Anwendungen auswirken konnten. Diese Änderungen an den sicherheitsbezogenen Features sind nachfolgend aufgeführt:

� Die IIS 6.0-Digestauthentifizierung wird nicht mehr unterstützt. Sie wurde durch die erwei-terte Digestauthentifizierung (die nun einfach als Digestauthentifizierung bezeichnet wird) ersetzt, die nicht verlangt, dass ein Anwendungspool mit LocalSystem-Berechtigungen ausgeführt wird. Lesen Sie später in diesem Kapitel den Abschnitt »Digestauthentifizierung«, um weitere Informa-tionen zu erhalten.

� Die .NET Passport-Authentifizierung wird nicht mehr unterstützt. Die .NET Passport-Authentifizierung ist kein Bestandteil von Windows Vista und Windows Server 2008 und wird deshalb von IIS 7.0 nicht mehr unterstützt.

� Die IIS 6.0-URL-Autorisierung wird nicht mehr unterstützt. Die IIS 6.0-URL-Autorisierung ist zu komplex und wurde nicht oft verwendet. Sie wurde durch das neue konfigurationsbasierte Feature URL-Autorisierung ersetzt. Lesen Sie später in diesem Kapitel den Abschnitt »URL-Autorisierung«, um weitere Informationen zu erhalten.

� Die IIS 6.0-Teilauthentifizierung wird nicht mehr unterstützt. Die Teilauthentifizierung ermöglichte die IIS 6.0-Digestauthentifizierung (die es bei IIS 7.0 nicht mehr gibt) und synchroni-sierte Kennwörter für anonyme Konten (das anonyme Konto verwendet nun das neue integrierte IUSR-Konto, das kein Kennwort besitzt). Sie wird für IIS 7.0 nicht mehr benötigt und wurde deshalb nicht übernommen.

� Der IIS-Manager unterstützt nicht mehr die Konfiguration der Authentifizierung über die IIS-Clientzertifikatzuordnung. Sie können die Konfiguration direkt bearbeiten. Benutzen Sie dazu Appcmd von der Befehlszeile aus, oder verwenden Sie eine Konfigurations-API (Application Programming Interface), um dieses Feature zu konfigurieren. Weitere Informationen erhalten Sie später in diesem Kapitel im Abschnitt »Authentifizierung über IIS-Clientzertifikatzuordnungen«.



� Wenn ASP.NET-Anwendungen im integrierten Standardmodus ausgeführt werden, gibt es einige Unterschiede hinsichtlich der Authentifizierung und des Identitätswechsels. Dazu zählt auch, dass es nicht möglich ist, die Formularauthentifizierung und die IIS-Authentifizierungs-verfahren gleichzeitig zu benutzen. Es ist außerdem in bestimmten Phasen der Anforderungs-verarbeitung nicht möglich, die Identität des authentifizierten Benutzers anzunehmen. Weitere Informationen zu Sicherheitsänderungen, die sich auf ASP.NET-Anwendungen auswirken, finden Sie in der Liste unter http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx.

� Metabasis-ACLs (Access Control List) werden nicht mehr unterstützt. Mit dem neuen Konfigurationssystem ist es nicht möglich, Berechtigungen für einzelne Konfigurationseinstel-lungen festzulegen. IIS 7.0 stellt eine integrierte Unterstützung für das Delegieren von Konfigura-tionseinstellungen an Website- und Anwendungsbesitzer zur Verfügung, die die Metabasis-ACLs als Verfahren für die Konfigurationsdelegation ersetzt. Weitere Informationen finden Sie später in diesem Kapitel im Abschnitt »Kontrollieren der Konfigurationsdelegierung«.

� Die Überwachung der Metabasis wird nicht nur unterstützt. Die Möglichkeit, Änderungen an bestimmten Konfigurationseinstellungen zu überwachen, wird standardmäßig nicht unterstützt. Der Grund hierfür besteht darin, dass IIS 7.0 nicht mehr mit Metabasis-ACLs arbeitet.

Verkleinern der AngriffsflächeDas Verkleinern der Angriffsfläche des Webservers ist eine wichtige Strategie, mit der das Risiko verringert wird, dass ein Angreifer eine Sicherheitslücke erfolgreich ausnutzt. Das Prinzip der Angriffs-flächeverkleinerung betrifft nicht ausschließlich Webserver – es ist ein anerkanntes Verfahren, um allgemein die Sicherheit eines beliebigen Softwaresystems zu verbessern. Wenn es auf IIS 7.0 angewendet wird, bietet es die folgenden Vorteile:

� Es verringert die Anzahl der Features und Dienste, die der Webserver außenstehenden Clients anbietet, wodurch die Menge des Codes, die einem Angreifer für die Ausnutzung möglicher Sicher-heitslücken zur Verfügung steht, minimiert wird.

� Es verringert die Komplexität, was die sichere Konfiguration des Webservers vereinfacht.

� Wenn eine Sicherheitslücke entdeckt wird und die davon betroffene Komponente nicht installiert ist, wirkt sich dies nicht sonderlich auf die Betriebszeit des Webservers aus, da dieser nicht in den Offlinezustand versetzt werden muss, um sofort einen Patch zu installieren.

IIS 7.0 bietet Ihnen über seine modulare Architektur die beispiellose Möglichkeit, die Angriffsfläche des Webservers zu verringern, indem Sie Funktionalität entfernen und nur die Funktionen beibehalten, die zum Hosten Ihrer Anwendung absolut notwendig sind. Wenn Sie diese Möglichkeit nutzen, können Sie Webserver mit einem geringen Ressourcenbedarf und der geringstmöglichen Angriffsfläche bereit-stellen.

Nach der Installation des Mindestfeaturesatzes können Sie die Angriffsfläche des Webservers weiter verkleinern, indem Sie Ihre Anwendung für den Betrieb mit dieser minimalen Funktionalität konfi-gurieren. Sie könnten beispielsweise festlegen, welche Anwendungsressourcen bereitgestellt werden dürfen.



Im Rest dieses Abschnitts werfen wir einen Blick auf den Vorgang, der zur Verkleinerung der Angriffs-fläche des Webservers und Ihrer Anwendung notwendig ist. Dieser Vorgang besteht aus den folgenden Schritten:

1. Die Angriffsfläche des Webservers verkleinern

a. Nur die benötigten Webserverfeatures installieren

b. Nur die benötigten ISAPI-Filter (Internet Server Application Programming Interface) aktivieren

c. Nur die benötigten ISAPI-Erweiterungen aktivieren

d. Nur die benötigten CGI-Anwendungen (Common Gateway Interface) aktivieren

e. Nur die benötigten FastCGI-Anwendungen aktivieren

2. Die Angriffsfläche der Anwendung verkleinern

a. Nur die benötigten Module aktivieren

b. Den Mindestsatz Anwendungshandlerzuordnungen konfigurieren

c. Websiteberechtigungen festlegen

d. Den Mindestsatz MIME-Typen konfigurieren

Die modulare Architektur von IIS 7.0 bietet Ihnen die Möglichkeit, nur die Webserverfeatures zu instal-lieren, die für den Betrieb Ihres Webservers notwendig sind. Dies ist die Grundlage der Strategie zur Verkleinerung der Angriffsfläche.

Darüber hinaus können Sie auch weiterhin kontrollieren, welche Erweiterungen, die nicht auf das modulare Erweiterbarkeitsmodell von IIS 7.0 zurückgreifen, auf dem Server ausgeführt werden können. Dazu zählen ISAPI-Erweiterungen und -Filter sowie CGI- und FastCGI-Programm.

Den Mindestsatz Webserverfeatures installierenDer modulare Featuresatz von IIS 7.0 besteht aus mehr als vierzig einzelnen Webservermodulen, die verschiedene Anforderungsverarbeitungs- und Anwendungsdienste zur Verfügung stellen. Die Kern-engine des Webservers arbeitet nur mit dem absolut notwendigen Mindestmaß an Funktionalität, um Anforderungen zu empfangen und deren Verarbeitung an die Module weiterzuleiten. Sie können diese Architektur nutzen, um Webserver mit minimalen Angriffsflächen bereitzustellen, indem Sie nur die Module installieren, die für den Betrieb des Webservers benötigt werden.

Der von den IIS 7.0 zur Verfügung gestellte modulare Featuresatz ist im Windows-Setup integriert. Dies bedeutet, dass Sie die meisten IIS 7.0-Module installieren oder deinstallieren können, indem Sie IIS 7.0-Features unter Windows Vista mithilfe der Seite Windows-Funktionen ein- oder ausschalten bzw. unter Windows Server 2008 mithilfe des Server-Managers und der Webserverrolle installieren bzw. deinstallieren, wie in Abbildung 14.1 dargestellt. Jedes Feature entspricht in der Regel einem Modul (und in einigen Fällen auch mehreren Modulen) und installiert alle erforderlichen Konfigurations-informationen sowie alle Featureabhängigkeiten.

Die Standardinstallation von IIS 7.0 enthält nur die Features, die notwendig sind, damit IIS 7.0 als statischer Dateiwebserver arbeiten kann. In einigen Fällen wird dies für das Hosting Ihre Anwendungen nicht genügen, so dass Sie zusätzliche Features installieren müssen, z.B. für das Hosting von dynami-schen Anwendungstechnologien. Wenn Sie dies tun, werden Sie dazu aufgefordert, alle Abhängig-keiten von dem jeweiligen Feature ebenfalls zu installieren und die richtige Standardkonfiguration für dieses Feature festzulegen.



Abbildung 14.1 IIS 7.0 mit dem Assistenten zum Hinzufügen von Rollen installieren

Vorsicht Wenn Sie nicht sicher sind, was genau Sie benötigen, sollten Sie nicht alle IIS 7.0-Features installieren. Dies könnte die Angriffsfläche des Webservers unnötigerweise vergrößern.

Wenn gewährleistet ist, dass nur die benötigten Module installiert werden, können Sie die Angriffs-fläche des Webservers signifikant verkleinern. Dies hat die folgenden Vorteile:

� Sorgt dafür, dass ein Angreifer bekannte oder zukünftige Sicherheitslücken in nicht installierten Features nicht ausnutzen kann

� Verringert die mit der Verwaltung einhergehende Komplexität, so dass es einfacher ist, den Server sicher zu konfigurieren

� Verringert die Ausfallzeiten und Kosten, die entstehen, wenn auf Sicherheitslücken reagiert werden muss oder die Installation von Patches erforderlich wird. Wenn die gepachte Komponente nicht installiert ist, müssen Sie den Server nicht in den Offlinezustand versetzen, um den Patch durch-zuführen. Sie können den Patch dann außerdem später installieren, wenn Sie Zeit dafür haben, und müssen nicht sofort nach Entdecken der Sicherheitslücke tätig werden.

Hinweis Wenn Sie einen Patch auf eine Komponente eines nicht installierten Webserverfeatures anwenden, wird er im Installationscache des Betriebssystems gespeichert. Auf diese Weise wird die korrigierte Version automatisch verwendet, wenn Sie das Feature später installieren. Achten Sie deshalb darauf, immer alle Betriebssystemupdates zu installieren, selbst wenn das betroffene Feature gegenwärtig nicht auf dem Server verwendet wird.



Um die Angriffsfläche des Webservers zu verkleinern, sollten Sie wie folgt vorgehen:

1. Ermitteln Sie den von Ihren Anwendungen benötigten Featuresatz. In der Regel können Sie die Features bestimmen, die von Ihrer Anwendung benötigt werden, indem Sie die Liste der Setup-komponenten lesen und diese mit den Anforderungen Ihrer Anwendung vergleichen. Sie können oft die für bestimmte Anwendungsschwerpunkte empfohlenen Modulsätze als Richtlinie verwenden. Weitere Informationen zu Installationsschwerpunkten finden Sie unter http://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Install-Typical-IIS-Workloads?Page=2. Sie sollten beim Entfernen von sicherheitsrelevanten Webserverfeatures Vorsicht walten lassen, weil dies negative Auswirkungen auf die Sicherheit Ihres Servers haben könnte. Um eine Liste der Module einzusehen, die sich auf die Sicherheit auswirken, lesen Sie im zwölften Kapitel, »Verwal-ten von Webservermodulen«, den Abschnitt »Die Komponentenarchitektur für die Verringerung der Angriffsfläche des Servers nutzen«.

2. Installieren Sie nur die benötigten Features. Nachdem Sie die benötigten Features ermittelt haben, sollten Sie diese mit den entsprechenden Rollen- oder Featureassistenten installieren. Wei-tere Informationen zu den Optionen für die Installation von IIS 7.0-Features finden Sie im fünften Kapitel, »Installieren von IIS 7.0«. Wenn Sie unschlüssig sind, sollten Sie nicht einfach alle Fea-tures installieren, da dies zu einer unnötig großen Angriffsfläche führen würde.

3. Installieren Sie nur die benötigten Drittanbietermodule. Für einige IIS 7.0-Anwendungen ist die Installation von Drittanbietermodulen erforderlich, damit eine zusätzliche Funktionalität zur Verfügung steht bzw. integrierte IIS 7.0-Features ersetzt werden. Sie sollten bei der Installation von Modulen auf dem Webserver Vorsicht walten lassen und sicherstellen, dass Sie der Quelle ver-trauen. Die Installation nicht vertrauenswürdiger oder fehlerhafter Module kann die Sicherheit des Webservers kompromittieren und dessen Ausfallsicherheit und Leistung einschränken. Im zwölften Kapitel erhalten Sie Informationen zur Installation von Drittanbietermodulen.

4. Testen Sie Ihre Anwendung. Sie sollten Ihre Anwendung immer testen, um zu gewährleisten, dass sie unter dem installierten Featuresatz richtig ausgeführt wird. Ihre Anwendung kann Fehler verursachen, wenn ein benötigtes Modul nicht installiert ist. Die Symptome dieses Fehlers sind davon abhängig, welche Dienste das fehlende Modul zur Verfügung stellt. Wenn Ihr Test zu einem Fehler führt und Sie glauben, dass die Ursache hierfür ein fehlendes Feature ist, sorgen Sie durch die Installation dieses speziellen Features dafür, dass der Fehler nicht mehr auftritt. Tritt der Fehler auch weiterhin auf, deinstallieren Sie das Feature und starten einen neuen Versuch. Installie-ren Sie niemals blind mehrere oder alle Features, damit Ihre Anwendung funktioniert.

Wenn Sie auf demselben Webserver mehrere Anwendungen ausführen lassen, müssen Sie die Ober-menge der Module installieren, die von den einzelnen Anwendungen benötigt werden. Sie können die Angriffsfläche jeder Anwendung weiter verkleinern, indem Sie festlegen, welche Module auf der Anwendungsebene aktiviert sind. Die dazu notwendige Vorgehensweise wird später in diesem Kapitel im Abschnitt »Nur die benötigten Module aktivieren« beschrieben.

Für weitere Informationen zur Verwendung der Rollen- oder Featureassistenten für die Installation von IIS 7.0- und anderen verfügbaren Features lesen Sie bitte das fünfte Kapitel. Um mehr über die Installation und Aktivierung von Modulen (auch Drittanbietermodulen) zu erfahren, lesen Sie das zwölfte Kapitel.



Nur die benötigten ISAPI-Filter aktivierenIIS 6.0 unterstützt ISAPI-Filter, damit Drittanbieter die IIS-Anforderungsverarbeitung erweitern können. IIS 7.0 verwendet heute IIS 7.0-Module als neues empfohlenes Verfahren zur Erweiterung des Web-servers. Diese haben die ISAPI-Filter ersetzt. IIS 7.0 unterstützt jedoch aus Gründen der Abwärts-kompatibilität auch weiterhin ISAPI-Filter.

Hinweis Damit ISAPI-Filter unter IIS 7.0 genutzt werden können, muss der Rollendienst ISAPI-Filter installiert sein. Dieser Rollendienst installiert das Modul IsapiFilterModule, das das Hosting von ISAPI-Filtern unterstützt. Wenn das Modul entfernt wird, werden ISAPI-Filter nicht geladen. Dieser Rollendienst ist standardmäßig nicht aktiviert. Er wird jedoch bei der Installation des ASP.NET-Rollendienstes aktiviert.

Wenn Ihr Webserver ISAPI-Filter verwendet, um die Angriffsfläche des Webservers zu verkleinern, sollten Sie sicherstellen, dass nur die benötigten ISAPI-Filter aktiviert sind.

Hinweis Sie müssen ein Serveradministrator sein, um ISAPI-Filter aktivieren zu können.

Um ISAPI-Filter richtig zu konfigurieren, sollten Sie wie folgt vorgehen:

1. Wenn Ihr Webserver mit ISAPI-Filtern arbeiten soll, installieren Sie den Rollendienst ISAPI-Filter. Ohne diesen Rollendienst werden die ISAPI-Filter nicht geladen, weshalb ein Sicherheits-risiko entstehen kann, sofern diese Filter für eine sicherheitsrelevante Funktionalität verantwortlich sind.

2. Wenn Ihr Webserver nicht mit ISAPI-Filtern arbeiten muss, sollten Sie den Rollendienst ISAPI-Filter nicht installieren. Sie schließen auf diese Weise die Möglichkeit aus, dass auf dem Server unerwünschte ISAPI-Filter konfiguriert werden.

3. Bestimmen Sie die ISAPI-Filter, die Ihre Anwendung benötigt. Meistens benötigt Ihr Webser-ver keinen ISAPI-Filter (mit Ausnahme des ASP.NET-ISAPI-Filters; lesen Sie später in diesem Abschnitt den entsprechenden Hinweis). Deshalb müssen Sie ISAPI-Filter in der Regel nur dann konfigurieren, wenn Sie eine Anwendung migrieren, die zuvor unter einer früheren IIS-Version aus-geführt wurde und bestimmte ISAPI-Filter benötigt, oder wenn Sie einen neuen ISAPI-Filter eines Drittanbieters installieren.

4. Aktivieren Sie die benötigten ISAPI-Filter. Sie können mit dem IIS-Manager festlegen, welche ISAPI-Filter auf Ihrem Server und für eine bestimmte Website aktiviert werden sollen.

Um mit dem IIS-Manager ISAPI-Filter zu konfigurieren, klicken Sie im Hierarchielistenfeld auf den Knoten des Webservers oder der Website und führen einen Doppelklick auf dem Feature ISAPI-Filter aus, das in Abbildung 14.2 dargestellt ist. Seien Sie sehr vorsichtig, wenn Sie ISAPI-Filter von Dritt-anbietern installieren. Es ist wichtig, dass Sie der Quelle vertrauen können, von der Sie die Filter erhalten. Die Installation nicht vertrauenswürdiger oder fehlerhafter ISAPI-Filter kann die Sicherheit des Webservers kompromittieren oder dessen Ausfallsicherheit beeinträchtigen.

Hinweis IIS 7.0 installiert standardmäßig keine ISAPI-Filter. ASP.NET 1.1 und ASP.NET 2.0 installieren jedoch einen ISAPI-Filter namens ASP.NET_2.0.50727.0. Dieser Filter ist für die Ausführung von ASP.NET-Features erforderlich, die ohne Cookies arbeiten. Sie sollten diesen Filter nicht entfernen.



Abbildung 14.2 ISAPI-Filter mit dem IIS-Manager konfigurieren

Sie können ebenfalls kontrollieren, welche Filter für den Webserver oder eine bestimmte Website aktiviert sind, indem Sie direkt den Konfigurationsabschnitt system.webServer/isapiFilters bearbeiten. Dies ist mit dem Befehlszeilentool Appcmd oder einer anderen Konfigurations-API möglich.

Nur die benötigten ISAPI-Erweiterungen aktivierenIIS 6.0 unterstützt ISAPI-Erweiterungen, damit Drittanbieter die IIS-Anforderungsverarbeitung erwei-tern können, indem Antworten für bestimmte Inhaltstypen zurückgegeben werden. IIS 7.0 verwendet heute IIS 7.0-Module als neues empfohlenes Verfahren zur Erweiterung des Webservers. Diese haben die ISAPI-Erweiterungen ersetzt. IIS 7.0 unterstützt jedoch aus Gründen der Abwärtskompatibilität auch weiterhin ISAPI-Erweiterungen.

Hinweis Damit ISAPI-Filter unter IIS 7.0 genutzt werden können, muss der Rollendienst ISAPI-Erweiterungen installiert sein. Dieser Rollendienst installiert das Modul IsapiModule, das das Hosting von ISAPI-Erweiterungen unterstützt. Wenn das Modul entfernt wird, werden ISAPI-Erweiterungen nicht geladen. Dieser Rollendienst ist stan-dardmäßig nicht aktiviert. Er wird jedoch bei der Installation von ASP.NET aktiviert.

Heute verwenden dynamische Anwendungsframeworktechnologien oft ISAPI-Erweiterungen, um eine Schnittstelle zu IIS zu bilden. Deshalb ist es wahrscheinlich, dass Sie ISAPI-Erweiterungen nutzen müssen, wenn Sie mit dynamischen Anwendungstechnologien arbeiten möchten. Sowohl ASP.NET (bei Anwendungen, die im klassischen Modus arbeiten) als auch ASP werden beispielsweise in Form von ISAPI-Erweiterungen implementiert.



Wenn Ihr Webserver ISAPI-Erweiterungen verwendet, um die Angriffsfläche des Webservers zu verkleinern, sollten Sie sicherstellen, dass nur die benötigten ISAPI-Erweiterungen aktiviert sind.

Hinweis Sie müssen ein Serveradministrator sein, um ISAPI-Erweiterungen aktivieren zu können.

Um ISAPI-Erweiterungen richtig zu konfigurieren, sollten Sie wie folgt vorgehen:

1. Wenn Ihr Webserver mit ISAPI-Erweiterungen arbeiten soll, installieren Sie den Rollen-dienst ISAPI-Erweiterungen. Ohne diesen Rollendienst werden die ISAPI-Erweiterungen nicht geladen, und Anforderungen, die sich auf die den ISAPI-Erweiterungen zugeordneten Ressourcen beziehen, führen zu Fehlern.

2. Wenn Ihr Webserver nicht mit ISAPI-Erweiterungen arbeiten muss, sollten Sie den Rollen-dienst ISAPI-Erweiterungen nicht installieren. Sie schließen auf diese Weise die Möglichkeit aus, dass auf dem Server unerwünschte ISAPI-Erweiterungen konfiguriert werden.

3. Konfigurieren Sie die zulässigen ISAPI-Erweiterungen. Jede ISAPI-Erweiterung muss für die Ausführung auf dem Server zugelassen werden, bevor sie genutzt werden kann. Sie können den IIS-Manager benutzen, um alle ISAPI-Erweiterungen zu konfigurieren, die auf dem Server ausgeführt werden dürfen. Die dazu notwendige Vorgehensweise ist später in diesem Abschnitt beschrieben. Seien Sie sehr vorsichtig, wenn Sie ISAPI-Erweiterungen von Drittanbietern zulassen. Es ist wich-tig, dass Sie der Quelle vertrauen können, von der Sie die Erweiterungen erhalten. Die Installation nicht vertrauenswürdiger oder fehlerhafter ISAPI-Erweiterungen kann die Sicherheit des Web-servers kompromittieren oder dessen Ausfallsicherheit beeinträchtigen.

4. Konfigurieren Sie die gewünschten Handlerzuordnungen. Um ISAPI-Erweiterungen nutzen zu können, müssen Sie Handlerzuordnungen erstellen, die die zulässigen ISAPI-Erweiterungen be-stimmten Inhaltstypen Ihrer Anwendung zuzuordnen. Weitere Informationen zur Erstellung von Handlerzuordnungen für ISAPI-Erweiterungen finden Sie im zwölften Kapitel. Der sichere Umgang mit Handlerzuordnungen wird später in diesem Kapitel im Abschnitt »Den Mindestsatz Handlerzu-ordnungen konfigurieren« beschrieben.

Sie müssen jede ISAPI-Erweiterung, die auf dem Server ausgeführt werden soll, explizit genehmigen. Wenn Sie einen bestimmten ISAPI-Erweiterungspfad zulassen, kann jede Anwendung auf dem Server diese Erweiterung laden, sofern diese Anwendung eine Handlerzuordnung für diese Erweiterung konfiguriert. Tabelle 14.1 führt gebräuchliche ISAPI-Erweiterungen auf und beschreibt, wann diese installiert werden.

Bei IIS 6.0 müssen Sie die ISAPI-Erweiterungen für ASP und ASP.NET 2.0 gesondert zulassen. Bei IIS 7.0 werden diese ISAPI-Erweiterungen automatisch zugelassen, wenn Sie die entsprechenden Rollen-dienste installieren. Darüber hinaus verwenden nur ASP.NET-Anwendungen, die im klassischen Modus ausgeführt werden, ASP.NET 2.0-ISAPI-Erweiterungen. Es ist sicherer, die Rollen- bzw. Feature-

Tabelle 14.1 Häufig genutzte ISAPI-Erweiterungen

ISAPI-Erweiterung Standardstatus Bei Installation

ASP (Active Server Pages) Zugelassen Der Rollendienst ASP wird installiert

ASP.NET v1.1.4322 Nicht zugelassen .NET Framework v1.1 SP1 wird installiert

ASP.NET v2.0.50727 Zugelassen Der Rollendienst ASP.NET wird installiert



assistenten zu benutzen, um die Verfügbarkeit dieser Features zu kontrollieren, anstatt sie innerhalb der ISAPI- und CGI-Einschränkungen zuzulassen bzw. nicht zuzulassen. Für ASP.NET v1.1 müssen Sie die ISAPI-Erweiterung jedoch manuell aktivieren.

Bei IIS 6.0 können Sie eine ISAPI-Erweiterung in der Webdiensterweiterungseinschränkungsliste zulassen. Bei IIS 7.0 können Sie hierfür den IIS-Manager benutzen, indem Sie im Hierarchielistenfeld auf den Knoten des Webservers klicken und dann einen Doppelklick auf ISAPI- und CGI-Einschrän-kungen ausführen, um das in Abbildung 14.3 dargestellte Feature zu öffnen. Um eine neue ISAPI-Erweiterung hinzuzufügen, klicken Sie im Bereich Aktionen auf Hinzufügen und geben den genauen Pfad der ISAPI-Erweiterung ein. Wenn Sie die Ausführung der ISAPI-Erweiterung zulassen möchten, aktieren Sie das Kontrollkästchen Ausführung des Erweiterungspfads zulassen. Sie können ebenfalls bereits vorhandene Erweiterungen zulassen oder ablehnen.

Abbildung 14.3 Mit dem IIS-Manager und dem Feature ISAPI- und CGI-Einschränkungen ISAPI-Erweiterungen zulassen

Zusätzlich zur Verwendung des IIS-Managers können Sie ebenfalls den Konfigurationsabschnitt system.webServer/security/isapiCgiRestriction direkt bearbeiten, indem Sie das Befehlszeilentool Appcmd oder eine andere Konfigurations-API benutzen. Weitere Informationen zur Konfiguration aktivierter ISAPI-Erweiterungen finden Sie im zwölften Kapitel und dort im Abschnitt »Der ISAPI-CGI-Einschränkungsliste (früher Webdiensteinschränkungsliste) Einträge hinzufügen«.



Nur die benötigten CGI-Programme aktivierenIIS 7.0 unterstützt auch weiterhin CGI-Programme, die eine Möglichkeit darstellen, die Funktionalität des Webservers zu erweitern.

Hinweis Damit CGI-Programme unter IIS 7.0 genutzt werden können, muss der Rollendienst CGI installiert sein. Dieser Rollendienst installiert das Modul CgiModule, das das Starten von CGI-Programmen ermöglicht. Wenn das Modul entfernt wird, können CGI-Programme nicht genutzt werden. Dieser Rollendienst ist standardmäßig nicht aktiviert.

IIS 7.0 bietet standardmäßig keine CGI-Programme an, weshalb deren Verwendung nur dann möglich sein sollte, wenn Ihre Anwendung mit CGI-Programmen von Drittanbietern arbeitet. In diesem Fall sollten Sie sicherstellen, dass nur die benötigten CGI-Programme zugelassen werden, um die Größe der Angriffsfläche des Webservers zu minimieren.

Hinweis Sie müssen Serveradministrator sein, um CGI-Programme zulassen zu können.

Um CGI-Programme richtig zu konfigurieren, sollten Sie wie folgt vorgehen:

1. Wenn Ihr Webserver mit CGI-Programmen arbeiten soll, installieren Sie den Rollendienst CGI. Ohne diesen Rollendienst können die CGI-Programme nicht verwendet werden, so dass Anforderungen, die sich auf die den CGI-Programmen zugeordneten Ressourcen beziehen, Fehler verursachen.

2. Wenn Ihr Webserver nicht mit CGI-Programmen arbeiten muss, sollten Sie den Rollendienst CGI nicht installieren. Sie schließen auf diese Weise die Möglichkeit aus, dass auf dem Server unerwünschte CGI-Programme konfiguriert werden.

3. Konfigurieren Sie die zulässigen CGI-Programme. Jedes CGI-Programm muss für die Ausfüh-rung auf dem Server zugelassen werden, bevor es genutzt werden kann. Sie können den IIS-Mana-ger benutzen, um alle CGI-Programme zu konfigurieren, die auf dem Server ausgeführt werden dürfen. Die dazu notwendige Vorgehensweise ist später in diesem Abschnitt beschrieben. Seien Sie sehr vorsichtig, wenn Sie CGI-Programme von Drittanbietern zulassen. Es ist wichtig, dass Sie der Quelle vertrauen können, von der Sie ein Programm erhalten. Die Installation nicht vertrauens-würdiger oder fehlerhafter CGI-Programme kann die Sicherheit des Webservers kompromittieren oder dessen Ausfallsicherheit beeinträchtigen.

4. Konfigurieren Sie die gewünschten Handlerzuordnungen. Um CGI-Programme nutzen zu können, müssen Sie Handlerzuordnungen erstellen, die die zulässigen CGI-Programme bestimmten Inhaltstypen Ihrer Anwendung zuordnen. Weitere Informationen zur Erstellung von Handlerzu-ordnungen für CGI-Programme finden Sie im zwölften Kapitel. Der sichere Umgang mit Handler-zuordnungen wird später in diesem Kapitel im Abschnitt »Den Mindestsatz Handlerzuordnungen konfigurieren« beschrieben.

Wie bei den ISAPI-Erweiterungen müssen Sie auch jedes CGI-Programm, das auf dem Server ausge-führt werden soll, explizit genehmigen. Wenn Sie einen bestimmten CGI-Programmpfad zulassen, kann dieses CGI-Programm von jeder Anwendung auf dem Server gestartet werden, sofern diese Anwen-dung eine Handlerzuordnung für diese Erweiterung konfiguriert. Damit die Genehmigung gültig ist, muss der jeweilige CGI-Programmeintrag den vollständigen Pfad und die erforderlichen Argumente genau wie in der Handlerzuordnung angeben. CGI-Programme sind, ähnlich wie früher in diesem Kapitel im Abschnitt »Nur die benötigten ISAPI-Erweiterungen aktivieren« beschrieben, innerhalb des Features ISAPI- und CGI-Einschränkungen zulässig.



Nur die benötigten FastCGI-Programme aktivierenIIS 7.0 unterstützt FastCGI-Programme mithilfe des Features FastCGI, das viele Anwendungsframe-works zuverlässiger hostet als CGI.

Hinweis Damit FastCGI-Programme unter IIS 7.0 genutzt werden können, muss der Rollendienst CGI installiert sein. Dieser Rollendienst installiert das Modul FastCgiModule, das das Starten von FastCGI-Programmen ermöglicht. Wenn das Modul entfernt wird, können FastCGI-Programme nicht genutzt werden. Dieser Rollendienst ist standard-mäßig nicht aktiviert.

IIS 7.0 bietet standardmäßig keine FastCGI-Programme an, weshalb deren Verwendung nur dann möglich sein sollte, wenn Ihre Anwendung mit FastCGI-Programmen von Drittanbietern arbeitet. In diesem Fall sollten Sie sicherstellen, dass nur die benötigten FastCGI-Programme zugelassen werden, um die Größe der Angriffsfläche des Webservers zu minimieren.

Hinweis Sie müssen ein Serveradministrator sein, um FastCGI-Programme zulassen zu können.

Um FastCGI-Programme richtig zu konfigurieren, sollten Sie wie folgt vorgehen:

1. Wenn Ihr Webserver mit FastCGI-Programmen arbeiten soll, installieren Sie den Rollen-dienst CGI. Ohne diesen Rollendienst können die FastCGI-Programme nicht verwendet werden, so dass Anforderungen, die sich auf die den FastCGI-Programmen zugeordneten Ressourcen bezie-hen, Fehler verursachen.

2. Wenn Ihr Webserver nicht mit FastCGI-Programmen arbeiten muss, sollten Sie den Rollen-dienst CGI nicht installieren. Sie schließen auf diese Weise die Möglichkeit aus, dass auf dem Server unerwünschte FastCGI-Programme konfiguriert werden.

3. Konfigurieren Sie die zulässigen FastCGI-Programme. Jedes FastCGI-Programm muss für die Ausführung auf dem Server zugelassen werden, bevor es genutzt werden kann. Obwohl Sie die FastCGI-Programme, die auf dem Server ausgeführt werden dürfen, nicht mit dem IIS-Manager konfigurieren können, ist dies dennoch möglich, indem Sie den Konfigurationsabschnitt system.web-Server/fastCgi bearbeiten. Weitere Informationen zur Konfiguration von FastCGI-Programmen fin-den Sie im elften Kapitel, »Hosting von Anwendungsentwicklungsframeworks«. Seien Sie sehr vorsichtig, wenn Sie FastCGI-Programme von Drittanbietern zulassen. Es ist wichtig, dass Sie der Quelle vertrauen können, von der Sie die Programme erhalten. Die Installation nicht vertrauenswür-diger oder fehlerhafter FastCGI-Programme kann die Sicherheit des Webservers kompromittieren oder dessen Ausfallsicherheit beeinträchtigen.

4. Konfigurieren Sie die gewünschten Handlerzuordnungen. Um FastCGI-Programme nutzen zu können, müssen Sie Handlerzuordnungen erstellen, die die zulässigen FastCGI-Programme bestimmten Inhaltstypen Ihrer Anwendung zuordnen. Weitere Informationen zur Erstellung von Handlerzuordnungen für FastCGI-Programme finden Sie im zwölften Kapitel. Der sichere Umgang mit Handlerzuordnungen wird später in diesem Kapitel im Abschnitt »Den Mindestsatz Handlerzu-ordnungen konfigurieren« beschrieben.

Im Gegensatz zu ISAPI-Erweiterungen und CGI-Programmen werden FastCGI-Programme nicht über das Feature ISAPI- und CGI-Einschränkungen genehmigt. Stattdessen müssen Sie im Konfigurations-abschnitt system.webServer/fastCgi jeweils einen Eintrag für jedes zulässige FastCGI-Programm erstellen. Weitere Informationen zur Konfiguration von FastCGI-Programmen finden Sie im elften Kapitel.



Die Angriffsfläche der Anwendung verkleinernWenn nur die benötigten Webserverfeatures installiert und die aktivierten ISAPI-Erweiterungen, ISAPI-Filter und CGI- und FastCGI-Programme eingeschränkt werden, verkleinert dies die gesamte Angriffsfläche des Webservers. Sie können jedoch noch einen Schritt weiter gehen und die auf der Anwendungsebene verfügbare Funktionalität reduzieren, indem Sie die für jede Anwendung aktivierten Module begrenzen und die Ressourcen einschränken, die von der jeweiligen Anwendung bereitgestellt werden können.

Nur die benötigten Module aktivierenWenn Ihr Webserver so konfiguriert ist, dass nur eine dedizierte Anwendung ausgeführt wird, sollten Sie nur die Module installieren, die zum Hosten dieser Anwendung erforderlich sind. Wenn Ihr Web-server jedoch mehrere Anwendungen bereitstellt, müssen Sie die Obermenge der IIS-Features und Drittanbietermodule installieren, die von allen Anwendungen benötigt werden. In diesem Fall können Sie die Angriffsfläche jeder Anwendung verkleinern, indem Sie auf der Anwendungsebene alle Module deaktivieren, die für die jeweilige Anwendung nicht erforderlich sind.

Dazu können Sie für jede Anwendung die aktivierten IIS-Module (verwaltet oder systemeigen) konfi-gurieren. Dies ist mit dem IIS-Manager möglich: Markieren Sie im Hierarchielistenfeld den Knoten der gewünschten Anwendung, führen Sie einen Doppelklick auf Module aus, und entfernen Sie die Module, die von der Anwendung nicht benötigt werden. Weitere Informationen zum Entfernen von Modulen erhalten Sie im zwölften Kapitel.

Vorsicht Lassen Sie beim Entfernen von Modulen besondere Vorsicht walten, da dies, sofern sicherheitsrelevante Module z.B. für die Autorisierung betroffen sind, zu einer Schwächung der Anwendungssicherheit führen kann. Lesen Sie im zwölften Kapitel den Abschnitt »Webservermodule sichern«, um zu erfahren, wie Module entfernt werden und welche integrierten IIS-Module sicherheitsrelevant sind.

Wenn Sie einen Webserver betreiben, auf dem Kunden Anwendungsinhalte publizieren dürfen, sollten Sie daran denken, dass diese Benutzer standardmäßig neue verwaltete Module aktivieren können, die Bestandteile ihrer Anwendungen sind. Diese Module werden benötigt, um die auf die jeweiligen Anwendungen bezogenen Anforderungen zu verarbeiten. Die Benutzer können Module, die auf der Serverebene installiert und aktiviert sind, natürlich auch deaktivieren, sofern sie nicht standardmäßig gesperrt sind. Wenn Sie dies nicht wünschen, können Sie den Konfigurationsabschnitt system.webServer/modules sperren oder eine spezifischere Konfigurationssperrung einsetzen, damit es nicht möglich ist, bestimmte Module zu entfernen. Weitere Informationen zum Sperren von Modulen finden Sie im zwölften Kapitel und dort im Abschnitt »Einschränken der Erweiterbarkeit«.

Hinweis Es ist auf der Anwendungsebene nicht möglich, neue systemeigene Module hinzuzufügen. Demgemäß ist es auf der Anwendungsebene ebenfalls nicht möglich, die systemeigenen und mit den IIS-Features verknüpften Module zu entfernen, da das IIS-Setup diese auf der Serverebene sperrt.

Den Mindestsatz Handlerzuordnungen konfigurierenHandlerzuordnungen legen direkt fest, welche Ressourcentypen der Webserver bereitstellen kann. Dazu ordnen sie Namenserweiterungen oder URL-Pfade den Modulen oder ASP.NET-Handlern zu, die den jeweiligen Ressourcentyp verarbeiten können. Handlerzuordnungen werden ähnlich wie Module typischerweise auf der Serverebene installiert, wenn eine Installation von IIS-Features oder



Drittanbieteranwendungsframeworks erfolgt. Dies geschieht, damit alle Anwendungen auf dem Server die mit ihnen verknüpften Inhalte bereitstellen können.

Wenn Ihre Anwendung keine spezifischen Inhaltstypen bereitstellt und auch keine auf dem Webserver installierten Anwendungsframeworktechnologien nutzt, sollten Sie auf der Anwendungsebene im Konfi-gurationsabschnitt system.webServer/handlers die entsprechenden Handlerzuordnungseinträge entfernen, damit der Webserver nicht versucht, diese zur Bedienung von Anforderungen zu verwenden, die sich auf Ihre Anwendung beziehen. Dies verringert das Risiko, dass in Ihrer Anwendung eine bestimmte Skript-funktionalität unbeabsichtigt ausgeführt oder eine Sicherheitslücke eines bestimmten Anwendungsframe-works ausgenutzt wird. Beachten Sie, dass der letzte Fall selbst dann eintreten kann, wenn Ihre Anwen-dung keine Ressourcen oder Skripts für ein bestimmtes Anwendungsframework enthält. Möglich ist dies, wenn das Anwendungsframework eine Sicherheitslücke aufweist, die genutzt werden kann, bevor der Versuch erfolgt, das angeforderte Skript zu lokalisieren.

Verwenden Sie die folgenden Verfahren, um den Mindestsatz Handlerzuordnungen für Ihre Anwendung zu konfigurieren:

� Schauen Sie sich die Handlerzuordnungen an, um zu verstehen, welche Ressourcentypen in Ihrer Anwendung verarbeitet werden können. Denken Sie daran, dass der Webserver ver-suchen wird, für jede eingehende Anforderung die erste Handlerzuordnung zu verwenden, die dem URL-Pfad und Verb der eingehenden Anforderung entspricht. StaticFileModule verarbeitet in der Regel alle Anforderungen, die keiner Handlerzuordnung zugeordnet werden konnten, so dass die angefor-derte Ressource als statische Datei bereitgestellt wird, sofern ihre Dateinamenserweiterung in der MIME-Typkonfiguration der Anwendung aufgelistet ist. Weitere Informationen dazu, wie Handler-zuordnungen ausgewählt werden, finden Sie im zwölften Kapitel und dort im Abschnitt »Handlerzuordnungen hinzufügen«.

� Entfernen Sie alle nicht für Ihre Anwendung benötigten Handlerzuordnungen. Dazu können Sie die jeweiligen spezifischen Handlerzuordnungen entfernen. Wenn möglich entfernen Sie alle Handlerzuordnungen, indem Sie den Konfigurationsabschnitt system.webServer/handlers löschen und nur die Handlerzuordnungen wieder hinzufügen, die von Ihrer Anwendung benötigt werden.

� Denken Sie an Vorbedingungen. Da für Handlerzuordnungen Vorbedingungen gesetzt werden können, die verhindern, dass diese Zuordnungen in bestimmten Anwendungspools genutzt werden, kann es sein, dass einige Handlerzuordnungen ignoriert werden. Dies führt dazu, dass für die zu bedienende Anforderung eine andere passende Handlerzuordnung verwendet wird. Um Sicher-heitsprobleme zu vermeiden, sollten Sie darauf achten, nicht mehrere Handlerzuordnungen zu erstellen, die auf einer festen Reihenfolge beruhen und auf dieselben Anforderungen abzielen.

� Fügen Sie Handlerzuordnungen anwendbare Einschränkungen hinzu. Beim Hinzufügen neuer Handlerzuordnungen sollten Sie von Ressourcentypeinschränkungen Gebrauch machen, um die Handlerzuordnungen nur solchen Anforderungen zuzuordnen, die sich auf existierende physikalische Dateien oder Verzeichnisse Ihrer Anwendung beziehen. Dies kann helfen, böswillige Anforderungen zu stoppen, die sich auf Ressourcen beziehen, die in Ihrer Anwendung nicht vor-handen sind. Darüber hinaus können Sie die später in diesem Kapitel im Abschnitt »Websiteberechtigungen festlegen« beschriebenen Zugriffseinschränkungen verwenden.

Lesen Sie das zwölfte Kapitel, um mehr darüber zu erfahren, wie Handlerzuordnungen erstellt werden, wie sich Vorbedingungen darauf auswirken und wie Ressourcentypen und Zugriffsbeschränkungen verwendet werden.



Wenn Sie einen Webserver betreiben, auf dem Kunden Anwendungsinhalte publizieren können, sollten Sie daran denken, dass diese Benutzer die Handlerzuordnungen beliebig modifizieren können, um zu kontrollieren, wie die an ihre Anwendungen gerichteten Anforderungen verarbeitet werden. Diese Benutzer können neue Handlerzuordnungen für jedes aktivierte Modul hinzufügen, bereits vorhandene Handlerzuordnungen entfernen oder Anforderungen anderen Handlern zuordnen. Wenn Sie dies nicht wünschen, können Sie den Konfigurationsabschnitt system.webServer/handlers sperren. Weitere Informa-tionen zum Sperren von Handlerzuordnungen finden Sie im zwölften Kapitel und dort im Abschnitt »Einschränken der Erweiterbarkeit«.

Hinweis Handlerzuordnungen, die Anforderungen ISAPI-Erweiterungen (IsapiModule), CGI-Programmen (CgiModule) und FastCGI-Programmen (FastCgiModule) zuordnen, können auf der Webserverebene weiter einge-schränkt werden, und zwar durch die ISAPI- und CGI-Einschränkungen sowie die FastCGI-Programmkonfiguration, die nur vom Administrator festgelegt werden können.

Websiteberechtigungen festlegenWebsiteberechtigungen sind zusätzliche Einschränkungen, die für eine Website, Anwendung oder einen URL verwendet werden können, um festzulegen, welche Anforderungen IIS bedienen darf. Diese Berechtigungen werden auf zwei Ebenen implementiert. Zunächst gibt jede Handlerzuordnung die erforderliche Berichtigungsebene mit dem Attribut requireAccess an. Wenn eine Anforderung, die dieser Handlerzuordnung entspricht, eingeht und der angeforderte URL nicht über die erforderliche Berech-tigung verfügt, weist IIS die Anforderung mit dem Antwortstatuscode 403.X zurück. Bei einigen IIS-Komponenten sind bestimmte Berechtigungen hartcodiert. Diese Komponenten weisen eine Anforde-rung ab, wenn sie sich auf einen URL bezieht, der nicht über diese Berechtigungen verfügt.

Hinweis Websiteberechtigungen kontrollieren, welche Funktionalität aktiviert ist, um auf der Ebene eines bestimmten URLs verwendet werden zu können. Sie berücksichtigen nicht die Identität des anfordernden Benutzers und können deshalb bei der Implementierung der Zugriffskontrolle die IIS-Autorisierungsschemata nicht ersetzen.

Tabelle 14.2 führt die Berechtigungen auf, die einem bestimmten URL gewährt werden können.

Tabelle 14.2 Berechtigungstypen für URLs

Berechtigung Beschreibung

Keine Keine Berechtigungen werden gewährt

Lesen Der Lesezugriff auf Dateien und Verzeichnisse ist möglich

Dadurch wird insbesondere Folgendes aktiviert: der Handler für statische Dateien, der statische Dateien, Verzeichnislisten und Standarddokumente bereitstellt.

Skript Die Skriptverarbeitung wird aktiviert

Dadurch wird insbesondere Folgendes aktiviert: ISAPI-Erweiterungen, CGI-Programme, FastCGI-Pro-gramme und ASP.NET-Handler. ISAPI-Erweiterungen und CGI-Programme müssen einen festen Skript-prozessor angeben.

Ausführen Die Ausführung von ausführbaren Dateien wird aktiviert

Dadurch wird insbesondere Folgendes aktiviert: ISAPI-Erweiterungen und CGI-Programme ohne festgelegten Skriptprozessor (in diesem Fall wird die im Anforderungspfad angegebene Datei ausgeführt). Wenn diese Berechtigung gewährt wird, versucht IIS standardmäßig EXE-Dateien als CGI-Anwendungen auszuführen und DLL-Dateien als ISAPI-Erweiterungen zu laden, so dass diese nicht einfach heruntergeladen werden.



Im IIS-Manager können Sie die für eine Website, eine Anwendung oder einen URL gewährte Berech-tigung anzeigen lassen, indem Sie im Hierarchielistenfeld den entsprechenden Knoten markieren und dann auf Handlerzuordnungen doppelklicken. Sie können dann die Berechtigungen Lesen, Skript und Ausführen setzen, indem Sie im Bereich Aktionen auf Featureberechtigungen bearbeiten klicken. Die Handler, die eine nicht gewährte Berechtigung erfordern, werden unter Zustand mit Deaktiviert gekennzeichnet, damit Sie wissen, dass die auf diese Handler bezogenen Anforderungen zurück-gewiesen werden.

Sie können die Berechtigungen in der Konfiguration festlegen, indem Sie das accessPolicy-Attribut des Konfigurationsabschnitts system.web/handlers direkt bearbeiten, oder indem Sie hierfür Appcmd bzw. eine andere Konfigurations-API verwenden. Um beispielsweise dem /files-Unterverzeichnis von Default Web Site lediglich die Berichtigung Lesen zu gewähren, können Sie die folgende Appcmd-Syntax nutzen.%systemroot%\system32\inetsrv\Appcmd set config "Default Web Site/files" /section:handlers /accessPolicy:Read

Hinweis Wenn Sie einen Konfigurationspfad angeben, um eine Konfiguration auf eine bestimmte Website oder einen URL anzuwenden, erhalten Sie möglicherweise eine Fehlermeldung, die Aufschluss darüber gibt, dass die Konfiguration gesperrt ist. Der Grund hierfür besteht darin, dass die meisten sicherheitsrelevanten Konfigurations-abschnitte, zu denen auch alle Authentifizierungsabschnitte zählen, auf der Webserverebene gesperrt sind, damit eine Konfigurationsdelegation nicht möglich ist. Sie können diese Abschnitte entsperren, um eine delegierte Konfiguration zuzulassen, oder Sie übernehmen die Konfiguration in applicationHost.config, indem Sie für Ihre Appcmd-Befehle den Parameter /commit:apphost verwenden.

Halten Sie sich an die folgenden Richtlinien, wenn Sie Websiteberechtigungen festlegen:

� Entfernen Sie die Berechtigungen, die von den URLs nicht benötigt werden. Standardmäßig werden die Berechtigungen Lesen und Skript gewährt. Entfernen Sie für URLs, die keine dynami-schen Anwendungstechnologien ausführen müssen, die Berechtigung Skript. Gewähren Sie keine zusätzlichen Berechtigungen, wie z.B. Ausführen, wenn dies nicht notwendig ist.

� Denken Sie daran, dass Anwendungen Handlerzuordnungen konfigurieren können, die keine Berechtigungen erfordern. Anwendungen können standardmäßig bereits vorhandene Handler-zuordnungen so verändern bzw. neue Handlerzuordnungen so erstellen, dass diese keine Berech-tigungen erfordern. Stützen Sie sich deshalb nicht auf Websiteberechtigungen, wenn Sie kontrol-lieren möchten, welche Handlerzuordnungen von Anwendungen generiert werden dürfen, die

Quelle Bei älteren IIS-Versionen lässt diese Berechtigung WebDav-Anforderungen für den Zugriff auf den Quellcode von Skriptdateien zu. Bei IIS 7.0 gibt es keine spezielle Behandlung dieser Berechtigung.

Schreiben Bei älteren IIS-Versionen lässt diese Berechtigung WebDav-Anforderungen für das Schreiben von Dateien zu. Bei IIS 7.0 gibt es keine spezielle Behandlung dieser Berechtigung.

NoRemoteRead Verhindert, dass Remoteanforderungen die Berechtigung Lesen verwenden

NoRemoteScript Verhindert, dass Remoteanforderungen die Berechtigung Skript verwenden

NoRemoteExecute Verhindert, dass Remoteanforderungen die Berechtigung Ausführen verwenden

NoRemoteWrite Verhindert, dass Remoteanforderungen die Berichtigung Schreiben verwenden

Tabelle 14.2 Berechtigungstypen für URLs (Fortsetzung)

Berechtigung Beschreibung



eine delegierte Konfiguration verwenden. Die Einhaltung der Berechtigungen wird nur für solche integrierten IIS-Features garantiert, bei denen die Berechtigungsanforderungen hartcodiert sind. Dazu zählen der Handler für statische Dateien, IsapiModule, CgiModule und die ASP.NET-Handler. In anderen Fällen wird die Einhaltung der Berechtigungen nur dann garantiert, wenn der Konfigura-tionsabschnitt system.webServer/handlers gesperrt ist, so dass keine Änderungen an den vom Webserveradministrator festgelegten Handlerzuordnungen vorgenommen werden können. Weitere Informationen zum Sperren des Konfigurationsabschnitts handlers finden Sie im zwölften Kapitel und dort im Abschnitt »Einschränken der Erweiterbarkeit«.

Hinweis Im Gegensatz zu IIS 6.0 werden Websiteberechtigungen nicht mehr von Handlerzuordnungen mit Platz-haltern ignoriert. Bei IIS 7.0 erfordern sie dieselbe Berechtigungsebene wie Handlerzuordnungen ohne Platzhalter. Deshalb funktionieren Konfigurationen nicht mehr, in denen eine über Platzhalter zugeordnete ISAPI-Erweiterung für solche URLs verwendet wird, die die Berechtigung Skript nicht zulassen. Hier ist die Gewährung der Berechti-gung Skript erforderlich.

Den Mindestsatz MIME-Typen konfigurierenIIS-Handlerzuordnungen sind so vorkonfiguriert, dass sie alle Anforderungen, die keinem Modul zuge-ordnet sind, an StaticFileModule weiterleiten, damit die entsprechende physikalische Datei an den Client übermittelt wird (wenn die Datei nicht vorhanden ist, wird der Fehlerantwortcode 404 zurückgegeben).

Hinweis Bei IIS 7.0 wurden die MIME-Standardtypen aktualisiert und berücksichtigen nun viele der neuen üblichen Dateinamenserweiterungen.

StaticFileModule bedient aus Sicherheitsgründen nur solcher Dateien, deren Dateinamenserweite-rungen in der MIME-Typkonfiguration aufgelistet sind. Dieses Verhalten ist extrem wichtig, da andern-falls Anwendungen, die Skripts und andere von Anwendungsframeworktechnologien verarbeitete Inhalte enthalten, diese Ressourcen direkt bereitstellen könnten, wenn die entsprechenden Anwen-dungsframework-Handlerzuordnungen nicht installiert wären oder entfernt würden. In dieser Situation schützt die MIME-Typkonfiguration diese Ressourcen davor, an einen Client übermittelt zu werden. Sie gibt in diesem Fall den Fehler 404.3 an den betroffenen Client zurück.

Hinweis Weitere Informationen zu MIME-Typen erhalten Sie im elften Kapitel und dort im Abschnitt »Die Verarbei-tung von neuen statischen Dateien konfigurieren«.

Die IIS 7.0-Liste der MIME-Standardtypen sollte, bezogen auf die Sicherheit, für die meisten Anwen-dungen genügen. Sie können die MIME-Typen auf der Serverebene, für eine Website, eine Anwendung oder einen URL noch differenzierter konfigurieren, um festzulegen, welche Dateinamenserweiterungen von StaticFileModule bedient werden können. Wenn Sie diese Liste auf die Namenserweiterungen der Dateien reduzieren, deren Bereitstellung als sicher gilt, können Sie verhindern, dass versehentlich Dateien übermittelt werden, die Bestandteil einer Anwendung und nicht für den Download vorgesehen sind.

Vorsicht Die MIME-Typkonfiguration verhindert mithilfe von StaticFileModule lediglich, dass nicht aufgelistete Dateien direkt heruntergeladen werden. Sie verhindert nicht, dass über eine Anwendung auf die Ressourcen zugegriffen wird, und sie verhindert ebenfalls nicht, dass diese Ressourcen heruntergeladen werden, wenn sie benutzerdefinierten Handlern zugeordnet sind. Um Anwendungsressourcen zu schützen, die nicht für den Zugriff


Anwendungen für die Nutzung von geringstmöglichen Berechtigungen konfigurieren 445

vorgesehen sind, sollten Sie die entsprechenden Namenserweiterungen verbieten oder die Anforderungsfilterung benutzen, um die Inhalte in einem Verzeichnis zu platzieren, das als verstecktes Segment konfiguriert ist. Weitere Informationen hierzu erhalten Sie später in diesem Kapitel im Abschnitt »Anforderungsfilterung«.

Sie sollten die nachstehenden Richtlinien befolgen, um für eine sichere Konfiguration der MIME-Typenliste zu sorgen:

� Fügen Sie der MIME-Typkonfiguration keine Namenserweiterung einer Datei hinzu, die nicht direkt heruntergeladen werden soll. Gemeint sind alle Dateitypen, die von Anwendungen verwendet werden, z.B. ASP, ASPX, or MDB.

� Konfigurieren Sie für jede Anwendung den benötigten Mindestsatz MIME-Typen. Wenn möglich, konfigurieren Sie die MIME-Typen jeder Anwendung so, dass nur die wirklich benötigten Erweiterungen berücksichtigt werden. Auf diese Weise kann verhindert werden, dass neue zur Anwendung hinzugefügte Dateien versehentlich bereitgestellt werden. Wenn Ihre Anwendung beispielsweise XML-Dateien benutzt, um interne Daten zu speichern, sollten Sie sicherstellen, dass die Namenserweiterung .xml nicht in der MIME-Typkonfiguration Ihrer Anwendung aufgeführt ist, was nach einer Installation von IIS standardmäßig der Fall ist.

Anwendungen für die Nutzung von geringstmöglichen Berechtigungen konfigurierenAbgesehen von der Verkleinerung der Angriffsfläche, besteht die effektivste Strategie, das Risiko eines erfolgreichen Angriffs auf Ihren Webserver zu verringern, darin, Ihre Anwendungen so zu konfi-gurieren, dass diese mit den geringstmöglichen Berechtigungen ausgeführt werden. Dies minimiert den möglichen Schaden, den ein Angreifer anrichten kann, wenn er bekannte oder zukünftige Sicherheits-lücken erfolgreich ausnutzt. Ähnlich wie das Verkleinern der Angriffsfläche ist dieses Verfahren nicht darauf beschränkt, nur bestimmte Bedrohungen abzuwehren – es ist für jede Bedrohung geeignet, mit der Ihre Anwendung heute oder in Zukunft konfrontiert werden kann.

Der Schlüssel zum Einschränken der Berechtigungen des Anwendungscodes innerhalb der IIS-Umgebung ist das Wissen um die Identität, unter der dieser Code ausgeführt wird. Sie müssen ebenfalls wissen, wie Sie dieser Identität nur die wirklich benötigten Berechtigungen zuweisen und ihre Rechte hinsichtlich des Zugriffs auf Serverressourcen einschränken. Um die geringstmöglichen Berechtigungen zu erhalten, werden wir uns mit den folgenden Verfahren auseinander setzen:

� Die Nutzung einer Anwendungspoolidentität, die nur über wenige Berechtigungen verfügt

� Das Setzen von NTFS-Berechtigungen (NTFS File System), um einen minimalen Zugriff zu gewähren

� Das Verringern der Vertrauenswürdigkeit von ASP.NET-Anwendungen

� Das Isolieren von Anwendungen

Diese Verfahren werden im nächsten Abschnitt beschrieben.



Eine über wenige Berechtigungen verfügende Anwendungspoolidentität verwendenDer Code einer Webanwendung wird in der Regel im Rahmen eines IIS-Arbeitsprozesses und unter der für den Anwendungspool konfigurierten Identität ausgeführt. Aus diesem Grund ist die Nutzung einer Anwendungspoolidentität, die über die geringstmöglichen Berechtigungen verfügt, die primäre Methode zum Einschränken der dem Anwendungscode gewährten Berechtigungen und Rechte.

IIS-Anwendungspools sind standardmäßig so konfiguriert, dass sie unter der Identität des integrierten Kontos NETZWERKDIENST ausgeführt werden, das auf dem Webserver über eingeschränkte Rechte verfügt. Jeder gestartete IIS-Arbeitsprozess ist außerdem automatisch Mitglied der Gruppe in IIS_ IUSRS. Diese Gruppe ersetzt die unter IIS 6.0 verwendete Gruppe IIS_WPG und ist notwendig, um alle IIS-Arbeitsprozesse des Computers zu identifizieren. Das IIS-Setup kann aus Gründen der Abwärts-kompatibilität die Gruppe IIS_WPG auch weiterhin erstellen. In diesem Fall wird IIS_IUSRS zu einem Mitglied dieser Gruppe.

Darüber hinaus können bestimmte Codeteile Ihre Anwendung unter der Identität des mit der jeweiligen Anforderung verknüpften authentifizierten Benutzers ausgeführt werden. Tabelle 14.3 beschreibt die Identitäten, die in Ihrer Anwendung verwendet werden können.

Wenn Sie mit Authentifizierungsschemata arbeiten, die Windows-Tokens produzieren, wie z.B. die Windows-Authentifizierung oder die Standardauthentifizierung, sollten Sie für den Fall, dass Benutzer mit umfassenden Berechtigungen auf Ihre Anwendung zugreifen, daran denken, dass die Anwendung

Tabelle 14.3 Anwendungsidentitäten

Identitätstyp Wird verwendet, wenn . . . Identitäten

Anwendungspoolidentität � auf Dateien zugegriffen wird, die für die Ausführung des IIS-Arbeitsprozesses notwendig sind

� auf web.config-Dateien zugegriffen wird

� (standardmäßig) FastCGI-Anwendungen ausgeführt werden

� (standardmäßig) ASP.NET-Anwendungen ausgeführt werden

� Standardmäßig NETZWERKDIENST; andernfalls die konfigurierte Anwendungs-poolidentität

� IIS_IUSRS-Gruppe

� Die SID des Anwendungspools (IIS APP-POOL\ <ApppoolName>)

Authentifizierter Benutzer � auf statische Dateien zugegriffen wird

� ISAPI-Erweiterungen ausgeführt werden

� (standardmäßig) CGI-Programme aus-geführt werden

� FastCGI-Anwendungen ausgeführt werden (sofern ein Identitätswechsel verwendet wird)

� ASP.NET-Anwendungen ausgeführt werden (sofern ein Identitätswechsel verwendet wird)

� Standardmäßig IUSR, sofern die anonyme Authentifizierung verwendet wird; andernfalls der konfigurierte anonyme Benutzer oder die Anwendungspool-identität

� Der authentifizierter Benutzer, wenn Windows-Token-Authentifizierungs-verfahren verwendet werden

Virtuelles Verzeichnis mit festen Anmeldeinformationen (wenn konfiguriert)

� auf die Anwendungsinhalte zugegriffen wird

� Die Anmeldeinformationen des konfigu-rierten virtuellen Verzeichnisses



dann mit diesen nicht beabsichtigten Berechtigungen ausgeführt wird. Deshalb wird empfohlen, dass Sie Benutzern, die auf dem Server über administrative Rechte verfügen, nicht gestatten, auf Ihre Anwendung zuzugreifen. Weitere Informationen zur Identität, unter der die einzelnen Anwendungs-frameworks ausgeführt werden, finden Sie im elften Kapitel.

Vorsicht Wenn Sie mit Authentifizierungsschemata arbeiten, die Windows-Identitäten generieren, werden Ihre Anwendungen möglicherweise unter der Identität des authentifizierten Benutzers ausgeführt.

Wenn Sie hingegen mit der anonymen Authentifizierung arbeiten, können Sie den anonymen Benutzer so konfigurieren, dass dieser die Anwendungspoolidentität verwendet. Sie stellen so sicher, dass der gesamte Code immer unter dieser Identität ausgeführt wird. Auf diese Weise wird die Verwaltung der Zugriffsrechte des Arbeitsprozesses wesentlich vereinfacht. Später in diesem Kapitel im Abschnitt »Anonyme Authentifizierung« erfahren Sie mehr über diese Konfiguration.

Hinweis Um die Zugriffsverwaltung zu vereinfachen, konfigurieren Sie den Benutzer für die anonyme Authenti-fizierung so, dass die Anwendungspoolidentität verwendet wird.

Wenn Sie für Ihre Anwendungen die Anwendungspoolidentität auswählen, sollten Sie die nach-stehenden Richtlinien befolgen, um die Sicherheit Ihres Webservers zu erhalten oder zu verbessern:

� Stellen Sie sicher, dass der Anwendungspoolidentität keine sensiblen Berechtigungen oder Rechte für den Zugriff auf Ressourcen gewährt werden. Webadministratoren, die mit Zugriffsverweigerungsfehlern konfrontiert werden, tendieren oft dazu, der Anwendungspool-identität einen vollständigen oder nicht erforderlichen Zugriff auf Ressourcen zu gewähren. Dies erhöht die Berechtigungen des Arbeitsprozesses und vergrößert das Risiko einer ernsthaften Gefähr-dung, wenn der Code im Arbeitsprozess kompromittiert wird. Gewähren Sie dem Arbeitsprozess lediglich den Mindestzugriff, der für die Arbeit der Anwendung notwendig ist. Wenn dieser Mindest-zugriff Berechtigungen oder Rechte erfordert, über die normalerweise nur administrative Benutzer verfügen, sollten Sie das Design Ihrer Anwendung überdenken.

� Benutzen Sie für IIS-Anwendungspools keine administrativen Identitäten oder Identitäten mit umfassenden Berechtigungen. Benutzen Sie niemals LocalSystem, Administrator oder ein anderes Konto mit umfassenden Berechtigungen als Anwendungspoolidentität. Sagen Sie einfach nein!

� Denken Sie darüber nach, eine Identität mit weniger umfassenden Berechtigungen zu ver-wenden. Denken Sie darüber nach, ein Konto mit weniger umfassenden Berechtigungen für den IIS-Arbeitsprozess zu benutzen, sofern Ihre Anwendung dies zulässt. Im Gegensatz zu IIS 6.0 integriert IIS 7.0 die neue Gruppe IIS_IUSRS automatisch in den Arbeitsprozess, so dass Sie nicht dafür sorgen müssen, dass die neue Identität das Mitglied einer Gruppe wird.

� Ordnen Sie Code mit unterschiedlichen Berechtigungsanforderungen in verschiedenen Anwendungspools an. Wenn sich auf Ihrem Server mehrere Anwendungen befinden, die ver-schiedene Berechtigungsebenen erfordern (z.B. könnte eine Anwendung die Berechtigung benö-tigen, etwas in die Webanwendung hineinzuschreiben, während eine andere Anwendung diese Berechtigung nicht verlangt), verwahren Sie sie in zwei verschiedenen Anwendungspools.



� Wenn Sie mit der anonymen Authentifizierung arbeiten, konfigurieren Sie den anonymen Benutzer so, dass er die Anwendungspoolidentität annimmt. Wenn Sie dafür sorgen, dass der Anwendungscode immer mit der Anwendungspoolidentität ausgeführt wird, vereinfacht dies die Konfiguration der Zugriffsrechte für Ihre Anwendung.

� Gewähren Sie einen Mindestzugriff. Wenn Sie der Anwendungspoolidentität Zugriffsrechte gewähren, sollten dies nur die wirklich benötigten Rechte sein. Sie können diesen Mindestzugriff in Verbindung mit der getrennten Verwahrung von Anwendungen in verschiedenen Anwendungspools einsetzen, um die geringstmöglichen Berechtigungen für Ihre Anwendungen zu erhalten. Sollen alle IIS-Anwendungspools auf eine Ressource zugreifen können, gewähren Sie diesen Zugriff der Gruppe IIS_IUSRS. Soll nur ein bestimmter Anwendungspool auf eine Ressource zugreifen können, benutzen Sie die eindeutige Anwendungspoolidentität. Alternativ hierzu verwenden Sie die automatische Anwendungspool-SID, die den Namen APPPOOL\<ApppoolName> trägt (dies ist nicht für UNC-Inhalte, sondern nur für lokale Inhalte möglich). Gewähren Sie keine Zugriffsrechte für NETZWERKDIENST, da dann der Zugriff auf alle Dienste möglich ist, die auf dem Server unter der Identität des Netzwerkdienstes ausgeführt werden.

NTFS-Berechtigungen für den Mindestzugriff gewährenAlle Dateien, die für die Arbeit der IIS-Arbeitsprozesse benötigt werden, gewähren der Gruppe IIS_ IUSRS standardmäßig Zugriffsrechte, was gewährleistet, dass die IIS-Arbeitsprozesse unabhängig von der ausgewählten Anwendungspoolidentität funktionieren. Es ist jedoch Ihre Aufgabe, den Zugriff auf die Anwendungsinhalte zu gewähren, so dass der Webserver und die Anwendung erfolgreich auf diese Ressourcen zugreifen können. Darüber hinaus ist es ebenfalls Ihre Aufgabe, den Zugriff auf die zusätz-lichen von einem IIS-Arbeitsprozess verwendeten Ressourcen zu gewähren. Dazu zählen z.B. ISAPI-Erweiterungen, CGI-Programme oder benutzerdefinierte Verzeichnisse, die für die Protokollierung oder die Ablaufverfolgung von Anforderungsfehlern konfiguriert wurden.

Tabelle 14.4 gibt die Zugriffsebenen an, die der Webserver in der Regel für verschiedene Arten von Ressourcen benötigt.

Tabelle 14.4 Zugriffsebenen für Webserverressourcen

Art der Ressource Identität Benötigtes Zugriffsrecht

Inhalte (physikalischer Pfad eines virtuellen Verzeichnisses sowie die Ebenen darunter)

� Inhalte (physikalischer Pfad eines virtuellen Verzeichnisses sowie die Ebenen darunter)

ODER

� Authentifizierter Benutzer� IIS-Arbeitsprozessidentität (Anwendungs-

poolidentität)

� Lesen� Schreiben, sofern Ihre Anwendung

Dateien in das virtuelle Verzeichnis schreiben muss (das Gewähren der Berechtigung Schreiben wird nicht empfohlen)

Zusätzliche Ressourcen, die von den IIS-Features verwendet werden: CGI-Programme, ISAPI-Erweiterungen, native Module-DLLs (DLL #####), Kompilierungsverzeichnisse, Ver-zeichnisse für die Ablaufverfolgung von Anforderungsfehlern, Proto-kollierungsverzeichnisse usw.

� IIS-Arbeitsprozessidentität (Anwendungs-poolidentität)

� Lesen� Ausführen, bei CGI-Programmen

� Schreiben, für Komprimierungs- oder Protokollierungsverzeichnisse oder wenn der Webserver Daten schreiben muss



Wenn Sie den Zugriff auf Verzeichnisse mit Inhalten gewähren, können Sie eines der folgenden Verfahren nutzen:

� IIS_IUSRS-Zugriffsrechte gewähren. Dies ermöglicht es allen IIS-Arbeitsprozessen, auf die Inhalte zuzugreifen, wenn die Anwendungspoolidentität oder die anonyme Authentifizierung verwendet wird. Sie können dann jedoch nicht mehrere Anwendungspools voneinander isolieren. Wenn ein auf Windows basierendes Authentifizierungsschema verwendet wird, müssen Sie ebenfalls allen authentifizierten Benutzern, die mit Ihrer Anwendung arbeiten können sollen, Zugriffsrechte gewähren.

� Der Identität des Anwendungspools der Anwendung Zugriffsrechte gewähren. Nur die IIS-Arbeitsprozesse, die in dem Anwendungspool mit der konfigurierten Identität ausgeführt werden, können dann auf die Inhalte zugreifen. Wenn Sie mit der anonymen Authentifizierung arbeiten, müssen Sie zusätzlich den anonymen Benutzer auf die Anwendungspoolidentität setzen. Verwenden Sie ein auf Windows basierendes Authentifizierungsschema, müssen Sie ebenfalls allen authentifi-zierten Benutzern, die mit Ihrer Anwendung arbeiten können sollen, Zugriffsrechte gewähren. Dieser Ansatz bildet die Grundlage für die Anwendungspoolisolation. Weitere Informationen erhalten Sie später in diesem Kapitel im Abschnitt »Anwendungen isolieren«.

� Feste Anmeldeinformationen für das virtuelle Verzeichnis der Anwendung konfigurieren und diesen Anmeldeinformationen Zugriffsrechte gewähren. Dies veranlasst den IIS-Arbeits-prozess, unter Verwendung der festen Anmeldeinformationen auf die Inhalte zuzugreifen, und zwar unabhängig von der Identität des authentifizierten Benutzers. Diese Option wird oft verwendet, wenn der Zugriff auf Remote-UNC-Freigaben gewährt werden soll. Dies geschieht, um die Schwie-rigkeiten zu vermeiden, die sich ergeben können, wenn die Identitäten von authentifizierten Benut-zern delegiert werden sollen, um auf eine Remotenetzwerkfreigabe zuzugreifen. Es kann ebenfalls sehr effizient sein, wenn, unabhängig vom authentifizierten Benutzer (der auf die Anwendungs-poolidentität gesetzt werden kann, sofern benutzerdefinierte Anwendungspoolidentitäten ver-wendet werden), der Zugriff auf Inhalte für eine einzelne Identität verwaltet werden soll. Schließ-lich kann dieses Verfahren genutzt werden, um den Zugriff auf die Anwendung zu kontrollieren, wenn Sie innerhalb desselben Anwendungspools mehrere Anwendungen gleichzeitig hosten.

Hinweis Wenn Sie den IIS-Manager benutzen, um die Anwendung remote zu verwalten, müssen Sie dem Konto NT Service\WMSvc ebenfalls das Zugriffsrecht Lesen gewähren. Weitere Informationen hierzu erhalten Sie im achten Kapitel, »Remoteverwaltung«.

Wenn Sie mit einem Authentifizierungsschema arbeiten (abgesehen von der anonymen Authentifi-zierung), das Windows-Identitäten für authentifizierte Benutzer generiert, wie dies bei den meisten IIS-Authentifizierungsschemata der Fall ist, müssen Sie ebenfalls sicherstellen, dass alle authentifizierten Benutzer, die mit Ihrer Anwendung arbeiten sollen, auf deren Inhalte zugreifen können. Der Grund hierfür besteht darin, dass der Webserver die Identität des authentifizierten Benutzers verwendet, um auf Anwendungsinhalte zuzugreifen. Auch viele Anwendungsframeworks nehmen standardmäßig die Identität des authentifizierten Benutzers an, wenn Anwendungscode ausgeführt und auf Anwendungs-ressourcen zugegriffen wird.

Wenn Sie mehreren Windows-Benutzern die Arbeit mit der Anwendung erlauben möchten, sollten Sie all diese Benutzer einer bestimmten Gruppe hinzufügen und dieser Gruppe den Zugriff auf die Anwen-dungsinhalte gewähren. Wenn Sie mit festen Anmeldeinformationen arbeiten, müssen Sie den authen-



tifizierten Benutzern außerdem keine Zugriffsrechte gewähren. IIS und der Anwendungscode nehmen in diesem Fall immer die Identität an, die mit den festen Anmeldeinformationen für das jeweilige virtuelle Verzeichnis verbunden ist. Weitere Informationen zum Einrichten von festen Anmeldeinfor-mationen finden Sie im neunten Kapitel, »Verwalten von Websites«, und dort im Abschnitt »Remoteinhalte verwalten«.

Befinden sich Ihre Inhalte an einem Ort, der über eine UNC-Freigabe erreicht wird, müssen Sie wahrscheinlich mit festen Anmeldeinformationen arbeiten, da die meisten IIS-Authentifizierungs-schemata keine Windows-Tokens produzieren, die für Remotenetzwerkfreigaben verwendet werden können (mit Ausnahme der Standardauthentifizierung und der Authentifizierung über die IIS-Client-zertifikatzuordnung). Eine Alternative besteht darin, Ihren Webserver für die eingeschränkte Delegation und den Protokollübergang zu konfigurieren, damit die Tokens von authentifizierten Benutzern für Remotefreigaben verwendet werden können. Das Konfigurieren von festen Anmeldeinformationen für virtuelle Verzeichnisse, auf die über UNC-Freigaben zugegriffen wird, ist jedoch sehr viel einfacher, weshalb es anstelle der Delegation empfohlen wird. Weitere Informationen hierzu finden Sie später in diesem Kapitel im Abschnitt »UNC-Authentifizierung«.

Hinweis Im Gegensatz zu IIS 6.0, wo der authentifizierte Benutzer (außer bei ASP.NET-Anwendungen) genügt, um auf die Verzeichnisse mit den Inhalten zuzugreifen, verlangt IIS 7.0 ebenfalls die IIS-Arbeitsprozessidentität für diese Art des Zugriffs. Erst dann können die web.config-Konfigurationsdateien gelesen werden. Dies geschieht, bevor IIS den authentifizierten Benutzer ermittelt.

Einschränken der Vertrauenswürdigkeit von ASP.NET-AnwendungenZusätzlich zum Einschränken der Anwendungsausführungsrechte, wofür eine Anwendungspool-identität mit geringen Berechtigungen zum Einsatz kommt, können Sie die .NET-Teile Ihrer Anwen-dung zusätzlich abschirmen, indem Sie mit ASP.NET-Vertrauensebenen arbeiten. Die ASP.NET-Teile der Anwendung sind die ASP.NET-Anwendungen selbst sowie verwaltete Module, die Dienste für jede Anwendung zur Verfügung stellen, die im integrierten ASP.NET-Modus ausgeführt wird.

ASP.NET-Vertrauensebenen verwenden die CAS-Infrastruktur (Code Access Security) des .NET Frameworks, um die Ausführung des Anwendungscodes einzuschränken. Dazu wird ein Satz Code-berechtigungen definiert, der kontrolliert, was der Anwendungscode darf und was nicht. ASP.NET-Anwendungen und verwaltete Module werden standardmäßig auf der Vertrauensebene Full (volle Vertrauenswürdigkeit) ausgeführt, so dass die Ausführung nicht eingeschränkt ist. Auf dieser Vertrau-ensebene kann eine Anwendung alle Aktionen initiieren, die bei den gegebenen Windows-Berechti-gungen und Ressourcenzugriffsrechten zulässig sind.

Sie können die Vertrauensebene von ASP.NET-Anwendungen herabsetzen, um deren Ausführung ein-zuschränken. Dies ist eine sehr effektive Möglichkeit, um geringere Berechtigungen für Ihre Anwen-dung zu erhalten. Sie verfügen standardmäßig über die in Tabelle 14.5 beschriebenen Optionen, die von den Richtliniendateien für die ASP.NET-Vertrauenswürdigkeit definiert werden.

Es wird empfohlen, dass Sie ASP.NET-Anwendungen unter Verwendung der Vertrauensebene Medium ausführen. Auf dieser Vertrauensebene kann die Anwendung nicht auf Ressourcen außerhalb ihres Gültigkeitsbereichs zugreifen, und sie kann keine Operationen ausführen, die die Sicherheit des Web-servers insgesamt kompromittieren würden. In diesem Fall sollten Sie jedoch die Anwendung testen, um sicherzustellen, dass sie nicht aufgrund von fehlenden erforderlichen Berechtigungen Sicherheits-ausnahmefehler verursacht. Sie sollten ebenfalls die Leistung der Anwendung testen, um zu über-prüfen, ob sich die eingeschränkte Vertrauensebene negativ darauf auswirkt.



Hinweis Die Vertrauensebene Medium wird empfohlen, um die Ausführung von ASP.NET-Anwendungen und verwalteten Modulen einzuschränken und wenn mehrere Anwendungen auf einem Shared Webserver ausgeführt werden sollen.

Sie können den IIS-Manager benutzen, um die Vertrauensebenen für ASP.NET-Anwendungen und ver-waltete Module zu konfigurieren, indem Sie einen Doppelklick auf .NET-Vertrauensebenen ausführen. Dies ist für den gesamten Server oder nur für eine bestimmte Anwendung möglich. Der Knoten der Anwendung muss vor Aktivierung des Features .NET-Vertrauensebenen markiert werden. Sie können die Vertrauensebene auch direkt setzen, indem Sie im Konfigurationsabschnitt system.web/trust das level-Attribut ändern.

Vorsicht Der Konfigurationsabschnitt system.web/trust ist standardmäßig nicht gesperrt, was bedeutet, dass jede Anwendung ihre eigene Vertrauensebene konfigurieren kann. Wenn Sie dies nicht wünschen, sperren Sie den Kon-figurationsabschnitt auf der Serverebene.

Anwendungen isolierenAnwendungspools stellen eine hervorragende Möglichkeit da mehrere auf demselben Computer ausge-führte Anwendungen sowohl hinsichtlich der Verfügbarkeit als auch in Bezug auf die Sicherheit von-einander zu isolieren. Daraus ergeben sich die folgenden Vorteile:

� Treten in einer Anwendung Fehler, Instabilitäten und Leistungsverluste auf, wirkt sich dies nicht auf Anwendungen in anderen Anwendungspools aus.

Tabelle 14.5 Standardvertrauensebenen

.NET-Vertrauensebene Ausführungseinschränkungen Rechte

Full (intern) Keine Alle

High (web_hightrust.config) Keine/.NET Alles ist möglich, außer das Aufrufen von nativem Code

Medium (web_mediumtrust.config) Die Anwendung ist innerhalb ihres Gültig-keitsbereichs vertrauenswürdig, sollte aber andere Anwendungen oder den Rest des Computers nicht beeinflussen können

� Zugriff auf Dateien im Anwendungsstamm

� Mit SQL- und OLEDB-Datenbanken verbinden� Verbindungen zu Webdiensten des lokalen

Computers herstellen� Threads und Ausführung für die eigenen

Anforderungen beeinflussen

Low (web_lowtrust.config) Die Anwendung ist nicht sehr vertrauens-würdig; für Anwendungen, die integrierte ASP.NET-Features verwenden können, aber keinen benutzerdefinierten Code ausführen dürfen

Nur Lesezugriff innerhalb des Anwendungs-stamms

Minimal (web_minimaltrust.config) Anwendung ist nicht vertrauenswürdig; die Möglichkeit, die integrierten ASP.NET-Fea-tures zu benutzen, ist extrem eingeschränkt

Minimale Berechtigungen für die Ausführung von Code



� Anwendungen, die in einem anderen Anwendungspool ausgeführt werden, können den Zugriff auf ihre Ressourcen ausschließlich auf diesen Pool beschränkten, so dass andere Anwendungen nicht darauf zugreifen können.

Die empfohlene Vorgehensweise zum Isolieren von Anwendungen besteht darin, jede Anwendung in einem eigenen Anwendungspool zu platzieren. IIS 7.0 vereinfacht in diesem Fall die Anwendungs-isolation, indem es automatisch eine eindeutige Anwendungspoolsicherheits-ID, die auch als Anwen-dungspool-SID bezeichnet wird, mit dem IIS-Arbeitsprozess jedes Anwendungspools verknüpft. Jede Anwendungspool-SID wird basierend auf dem Anwendungspoolnamen generiert und hat selbst den Namen IIS APPPOOL\ <ApppoolName>. Die Anwendungspool-SID sorgt dafür, dass Anwendungen schnell isoliert werden können. Dazu werden NTFS-Berechtigungen für die Anwendungsinhalte fest-gelegt, um die entsprechenden Zugriffsrechte nur der Anwendungspool-SID zu gewähren, die mit dem Anwendungspool der betreffenden Anwendung verknüpft ist.

Hinweis Sie können Anwendungen schnell voneinander isolieren, indem Sie für deren Anwendungsinhalte Berechtigungen festlegen, damit der Zugriff darauf nur über die Anwendungspool-SID des entsprechenden Anwendungspools möglich ist.

Um für eine effektive und auf der Anwendungspool-SID basierende Isolation zu sorgen, gehen Sie wie folgt vor:

1. Konfigurieren Sie die anonyme Authentifizierung so, dass die Anwendungspoolidentität verwendet wird.

2. Gewähren Sie der SID IIS APPPOOL\ <ApppoolName> den Zugriff auf die Anwendungsinhalte.

3. IIS_IUSRS, IIS_WPG oder einer anderen Anwendungspoolidentität, die möglicherweise von einem anderen Anwendungspool verwendet wird, darf kein Zugriff auf die Anwendungsinhalte gewährt werden.

4. Konfigurieren Sie separate Speicherorte für alle temporären Verzeichnisse und Hilfsverzeichnisse die von IIS und den Anwendungen für jede Anwendung oder jeden Anwendungspool verwendet werden, und legen Sie die Berechtigungen für diese Verzeichnisse fest, damit nur die jeweilige SID IIS APPPOOL\ <ApppoolName> darauf zugreifen kann.

Tabelle 14.6 zeigt einige gebräuchliche Verzeichnisse, die von IIS und ASP.NET-Anwendungen ver-wendet werden. Die Verzeichnisse müssen für jede Website oder Anwendung für die Isolation konfi-guriert werden, indem die Berechtigungen festgelegt werden, die notwendig sind, damit ausschließlich der betreffende Anwendungspool darauf zugreifen kann.

Tabelle 14.6 Übliche von IIS und ASP.NET-Anwendungen verwendete Verzeichnisse

Verzeichnis Konfiguriert in . . .

Inhaltsverzeichnisse Physikalischer Pfad eines virtuellen Verzeichnisses

Windows-Verzeichnis TEMP (%TEMP% oder %TMP%): wird von Windows-Komponenten verwendet

Setzen Sie im processModel-Element eines Anwendungspools das loadUserProfile-Attribut auf true. Dies veranlasst das TEMP-Verzeichnis, auf %SystemDrive%\Users\%UserName%\AppData\Local\Temp zu verweisen.

Verzeichnis für Websiteprotokollierungs- dateien

directory-Attribut des logFile-Elements einer Site. Der Standard ist %System-Drive%\Inetpub\Logs\LogFiles.

Verzeichnis für Anforderungsfehlerprotokolle einer Website

directory-Attribut des traceFailedRequestsLogging-Elements einer Site. Der Standard ist %SystemDrive%\Inetpub\Logs\FailedReqLogFiles.


Die Zugriffssteuerung implementieren 453

Hinweis Die Anwendungspool-SIDs können ausschließlich zum Isolieren von lokalen Inhalten verwendet werden. Wenn Sie mit Inhalten arbeiten, die über eine UNC-Freigabe zur Verfügung gestellt werden, müssen Sie entweder eine benutzerdefinierte Anwendungspoolidentität benutzen oder für jedes virtuelle Verzeichnis feste Anmeldeinfor-mationen konfigurieren. Danach verwenden Sie die Identität, um den Zugriff auf die Netzwerkfreigabe zu gewähren.

IIS 7.0 ermöglicht über die Konfigurationsisolation eine automatische Isolation der Serverebenen-konfiguration. Eine Aktivierung ist nicht notwendig, da sie automatisch erfolgt. Weitere Informationen zur Konfigurationsisolation finden Sie später in diesem Kapitel im Abschnitt »Die Konfigurationsisolation verstehen«.

Hinweis Die Serverebenenkonfiguration in applicationHost.config wird mithilfe der Konfigurationsisolation auto-matisch isoliert.

Die .NET Framework-Konfigurationen in machine.config und der web.config-Stammdatei – sowie die Konfigurationen in den verteilten web.config-Dateien, die Teil der Websiteverzeichnisstruktur sind – werden jedoch nicht isoliert. Um die verteilten web.config-Dateien richtig zu isolieren, setzen Sie die entsprechenden Berechtigungen für die Inhaltsverzeichnisse, wie dies früher in diesem Abschnitt bereits beschrieben wurde.

Die Zugriffssteuerung implementierenWebanwendungen erfordern die Möglichkeit, den Zugriff auf ihre Inhalte einzuschränken, sensible Ressourcen zu schützen und nur bestimmte Benutzer für den Zugriff auf Ressourcen zu autorisieren. IIS 7.0 bietet einen umfassenden Satz Features an, den Sie nutzen können, um den Zugriff auf Anwen-dungsinhalte zu kontrollieren. Diese Features können gemäß der Rolle, die sie bei der Bestimmung des Zugriffs auf eine angeforderte Ressource spielen, in zwei Kategorien unterteilt werden:

� Authentifizierung Authentifizierungsfeatures ermitteln die Identität des anfordernden Clients, die benötigt wird, um zu bestimmen, ob dieser Client Zugriff erhalten soll.

� Autorisierung Autorisierungsfeatures verwenden die authentifizierte Identität der Anforderung oder andere anwendbare Informationen, um zu ermitteln, ob der Client auf die angeforderte Ressource zugreifen darf. Autorisierungsfeatures sind in der Regel auf Authentifizierungsfeatures angewiesen,

Verzeichnis für die statische IIS-Komprimierung Wird automatisch isoliert, indem für jeden Anwendungspool ein Unterverzeichnis erstellt wird, auf das für die jeweilige Anwendungspool-SID eine ACL angewendet wird.

ASP.NET-Verzeichnis Temp: wird vom ASP.NET-Kompilierungssystem verwendet

tempDirectory-Attribut im system.web/compilation-Abschnitt einer Anwendung. Der Standard ist %SystemRoot%\Microsoft.NET\Framework\<version>\Temporary ASP.NET Files.

Cacheverzeichnis für ASP-Vorlagen Wird automatisch isoliert, indem für jede Anwendungspool-SID ACLs auf die jeweilige Datei angewendet werden.

Tabelle 14.6 Übliche von IIS und ASP.NET-Anwendungen verwendete Verzeichnisse (Fortsetzung)

Verzeichnis Konfiguriert in . . .



wenn es um die Ermittlung der authentifizierten Identität geht. Einige Autorisierungsfeatures gewähren oder verweigern den Zugriff jedoch abhängig von anderen Aspekten der Anforderung oder der angeforderten Ressource. Ein solcher Aspekt ist beispielsweise die Anforderungsfilterung.

IIS 7.0 unterstützt die meisten Authentifizierungs- und Autorisierungsfeatures, die bereits in IIS 6.0 verfügbar waren, und es führt einige zusätzliche Features ein. Diese Features (Rollendienste) sind nachfolgend in der Reihenfolge beschrieben, in der sie während der Anforderungsverarbeitung angewendet werden:

1. IP- und Domäneneinschränkungen. Werden verwendet, um den Zugriff auf solche Anforderun-gen einzuschränken, die von Clients initiiert werden, die bestimmten IP-Adressbereichen oder Domänennamen zugeordnet sind. Die Standardinstallation nutzt dieses Feature nicht.

2. Anforderungsfilterung. Die Anforderungsfilterung wird, vergleichbar mit dem in früheren Ver-sionen von IIS verwendeten Hilfsmittel UrlScan, eingesetzt, um den Zugriff auf Anforderungen einzuschränken, indem festgelegte Grenzen eingehalten und verdächtige Muster ausgeschlossen werden. Darüber hinaus wird die Anforderungsfilterung verwendet, um den Zugriff auf bekannte Anwendungsinhalte einzuschränken, die nicht dafür vorgesehen sind, an Remoteclients übermittelt zu werden. Die Anforderungsfilterung ist ein Teil der IIS 7.0-Standardinstallation, und sie ist standardmäßig so konfiguriert, dass sie Anforderungen filtert.

3. Authentifizierungsfeatures. IIS 7.0 bietet mehrere Authentifizierungsfeatures an, die Sie zur Ermittlung der Identität des Clients verwenden können, der die jeweilige Anforderung einreicht. Dazu zählen die Standardauthentifizierung, die Digestauthentifizierung, die Windows-Authentifi-zierung (NTLM und Kerberos) und viele andere. Das Feature Anonyme Authentifizierung ist Teil der IIS-Standardinstallation, und es wird standardmäßig aktiviert.

4. Autorisierungsfeatures. IIS 7.0 bietet das neue Feature URL-Autorisierung an, mit dem Sie in der Konfiguration deklarative Zugriffsteuerungsregeln erstellen können, um bestimmten Benutzern oder Rollen Zugriffsrechte zu gewähren. Darüber hinaus wird für Authentifizierungsschemata, die Windows-Benutzeridentitäten hervorbringen, eine auf NTFS-ACLs basierende Autorisierung unterstützt. IIS verwendet standardmäßig die auf NTFS-ACLs basierende Autorisierung.

Hinweis Bei IIS 7.0 sind all diese Rollendienste in Form von Webservermodulen verfügbar, die einzeln installiert und deinstalliert und optional für jede Anwendung deaktiviert oder aktiviert werden können. Seien Sie vorsichtig, wenn Sie Module für die Authentifizierung, Autorisierung sowie andere Zugriffsteuerungsmodule entfernen, da Sie auf diese Weise versehentlich dafür sorgen können, dass nicht autorisierte Benutzer Zugriff erhalten oder Ihre Anwendung anfällig für böswillige Anforderungen wird. Im zwölften Kapitel enthält der Abschnitt »Webservermodule sichern« eine Liste der sicherheitsrelevanten Module, die mit IIS 7.0 ausgeliefert werden, und er enthält außerdem einige Überlegungen zur Entfernung dieser Module.

Sie sollten die Zugriffsteuerungsfeatures nutzen, um zu gewährleisten, dass nur solche Benutzer auf Ressourcen zugreifen können, die über die entsprechenden Zugriffsrechte verfügen. Dazu müssen Sie für Ihre Anwendung die richtigen Authentifizierungs- und Autorisierungsfeatures konfigurieren.

Außerdem sollten Sie auf die Anforderungsfilterung zurückgreifen, um die Nutzung der Anwendung so umfassend wie möglich einzuschränken. Dazu erstellen Sie Einschränkungen für Inhaltstypen, URLs und andere Anforderungsparameter. Auf diese Weise können Sie die Anwendung präventiv vor einer nicht vorgesehenen Verwendung und noch nicht bekannten zukünftigen Sicherheitslücken schützen.



IP- und DomäneneinschränkungenMit dem Rollendienst IP- und Domäneneinschränkungen können Sie für Clients, die Anforderungen aus einem bestimmten IP-Adressbereich heraus initiieren oder die mit einem bestimmten Domänen-namen verknüpft sind, den Zugriff auf Ihre Anwendung einschränken. Dieses Feature hat sich seit IIS 6.0 kaum verändert.

Hinweis Der Rollendienst IP- und Domäneneinschränkungen ist nicht Teil der IIS-Standardinstallation. Sie können ihn unter Windows Vista mithilfe des Windows-Setups über die Kategorie IIS\Sicherheit und unter Windows Server 2008 mithilfe des Server-Managers über die Webserverrollenkategorie Sicherheit manuell installieren. Das zwölfte Kapitel enthält weitere Informationen zur Installation und Aktivierung von Modulen.

Sie können dieses Feature benutzen, um bestimmten IP-Adressbereichen oder Domänennamen Zugriffs-rechte zu gewähren oder zu verweigern. Der Rollendienst IP- und Domäneneinschränkungen versucht, die konfigurierten Regeln auf die IP-Quelladresse jeder eingehenden Anforderung anzuwenden, und zwar in der Reihenfolge, in der die Regeln in der Konfiguration festgelegt sind. Wenn eine Regel auf eine Anforderung angewendet werden kann und sie eine Zugriffsverweigerung bedingt, wird die Anforderung mit dem HTTP-Fehlercode 403.6 abgewiesen. Erlaubt die Regel den Zugriff, darf die Anforderung die Verarbeitung fortsetzen (alle weiteren Regeln werden ignoriert).

Sie können beliebig viele Regeln für die Zugriffsgewährung bzw. -verweigerung angeben, und Sie können festlegen, ob der Zugriff gewährt oder verweigert werden soll, wenn keine Regel angewendet werden konnte.

� Den Zugriff standardmäßig verweigern und eine Allow-Regel erstellen, um nur einem bestimmten IPv4-Adressbereich, z.B. dem lokalen Subnetz, den Zugriff zu gewähren. Sie können dies tun, um nur den Clients des lokalen Netzwerks oder einer bestimmten Remote-IP-Adresse Zugriffsrechte zu gewähren.

� Den Zugriff standardmäßig gewähren und eine Deny-Regel erstellen, um nur einer bestimmten IP-Adresse oder einem bestimmten IPv4-Adressbereich den Zugriff zu verweigern. Sie können dies tun, um nur einer bestimmten verdächtigen IP-Adresse den Zugriff zu verweigern.

Vorsicht Wird der Zugriff standardmäßig erlaubt und nur bestimmten IP-Adressbereichen verweigert, trägt dies nicht zur Sicherheit bei, da Angreifer dann andere IP-Adressen verwenden können, um auf Ihre Anwendung zuzugreifen. Außerdem sind Clients, die anstelle von IP-Adressen IPv6-Adressen verwenden, nicht von Deny-Regeln betroffen, die sich auf IPv4-Adressbereiche beziehen.

Wenn Sie den Zugriff auf Ihre Anwendung auf die Clients des lokalen Netzwerks beschränken möchten, können Sie eine weitere Verteidigungsmaßnahme implementieren, indem Sie festlegen, dass Ihre Site-bindung nur Anforderungen von IP-Adressen entgegennehmen soll, die mit dem privaten Netzwerk verknüpft sind. Wenn Ihr Server sowohl mit privaten als auch mit öffentlichen IP-Adressen arbeitet, können in diesem Fall nur noch aus dem privaten Netzwerk Anforderungen eingehen, die sich auf Ihre Site beziehen. Sie sollten diese Möglichkeit in Verbindung mit den IP- und Domäneneinschränkungen nutzen, wenn dies möglich ist. Weitere Informationen zur Erstellung von Websitebindungen erhalten Sie im neunten Kapitel.

Obwohl Sie Regeln erstellen können, die einen Domänennamen anstelle einer IP-Adresse verwenden, wird dies nicht empfohlen. Der Grund hierfür besteht darin, dass Einschränkungen, die auf Domänen-namen basieren, bei jeder Anforderung ein DNS-Reverse-Lookup (Domain Name System) für jede



Client-IP-Adresse erfordern, was sich negativ auf die Leistung Ihres Servers auswirken kann. Das Feature ermöglicht standardmäßig keine auf Domänennamen basierende Regeln.

Um die IP- und Domäneneinschränkungsregeln zu konfigurieren, müssen Sie wie folgt vorgehen:

1. Benutzen Sie den IIS-Manager zur Konfiguration der Regeln, indem Sie im Hierarchielistenfeld den Knoten des Servers, einer Site oder einen Knoten unterhalb einer Site markieren. Führen Sie anschließend einen Doppelklick auf dem in Abbildung 14.4 dargestellten Feature Einschränkungen für IPv4-Adressen und Domänen aus.

2. Benutzen Sie im Bereich Aktionen die Optionen Zulassungseintrag hinzufügen bzw. Ablehnungs-eintrag hinzufügen, um Zulassungs- oder Ablehnungsregeln zu erstellen.

3. Sie können ebenfalls die Aktion Featureeinstellungen bearbeiten verwenden, um den Standard-zugriff (Zulassen oder Verweigern) zu konfigurieren und festzulegen, ob auf Domänennamen basierende Regeln zulässig sind.

Abbildung 14.4 IP- und Domäneneinschränkungen mit dem IIS-Manager konfigurieren

Hinweis Obwohl Sie im Rahmen des Features IP- und Domäneneinschränkungen mit IPv6-Adressen arbeiten können, ist es mit dem IIS-Manager nicht möglich, Regeln für IPv6-Adressen zu konfigurieren. Außerdem können Regeln, die für IPv4-Adressen aufgestellt wurden, nicht auf Anforderungen angewendet werden, die über IPv6-Verbindungen eingehen.

Hinweis Der Konfigurationsabschnitt ipSecurity ist auf der Serverebene standardmäßig gesperrt. Sie können diesen Abschnitt mit dem Befehl Appcmd Unlock Config entsperren, um in den web.config-Dateien der Site-, Anwendungs- oder URL-Ebene Regeln für IP- und Domäneneinschränkungen anzugeben.

Sie können IP- und Domäneneinschränkungen ebenfalls mit Appcmd oder anderen Konfigurations-APIs konfigurieren. Dazu bearbeiten Sie den Konfigurationsabschnitt system.webServer/security/ipSecurity.



AnforderungsfilterungDas Feature Anforderungsfilterung ist eine verbesserte Version des Tools UrlScan, das ein Bestandteil früherer IIS-Versionen ist. Das Feature Anforderungsfilterung definiert Einschränkungen für das Format des angeforderten URLs und für dessen Inhalte, um eine Anwendung vor möglichen Sicherheitslücken zu schützen, die sich aus einer Missachtung dieser Einschränkungen ergeben könnten. Bei IIS 6.0 und früheren IIS-Versionen haben diese Einschränkungen die Ausnutzung der meisten bekannten Sicherheits-lücken von Webanwendungen vereitelt, z.B. anwendungsspezifische Pufferüberläufe, die das Ergebnis zu langer böswilliger URLs und Abfragezeichenfolgen sind. Obwohl der Webserver selbst, beginnend mit IIS 6.0, so entwickelt wurde, dass er für diese Art von Angriffen nicht anfällig ist, sind diese Einschrän-kungen auch weiterhin nützlich, da sie bekannte und unbekannte zukünftige Sicherheitslücken des Webservers und der darauf ausgeführten Anwendungen erst gar nicht entstehen lassen.

Zusätzlich zum Erzwingen der Einhaltung von Anforderungseinschränkungen, kann das Feature Anforderungsfilterung dazu verwendet werden, den Zugriff auf bestimmte Anwendungsressourcen zu verweigern, die nicht dafür vorgesehen sind, an Webclients übermittelt zu werden, die sich aber im entsprechenden Namespace einer Anwendung befinden. Zu diesen Dateien zählen die web.config-Konfigurationsdateien für IIS und ASP.NET sowie die Inhalte der /BIN- und /App_Code-Verzeichnisse von ASP.NET-Anwendungen.

Sie können die Anforderungsfilterung für die folgenden Aufgaben verwenden:

� Anforderungslimits festlegen Konfigurieren Sie Limits für die Länge und Codierung von URLs, die Länge von Abfragezeichenfolgen, die Länge des POST-Entitätskörpers von Anforderungen, zulässige Anforderungsverben und die maximale Länge von einzelnen Anforderungsheadern.

� Zulässige Erweiterungen konfigurieren Konfigurieren Sie, welche Dateinamenserweiterungen zulässig sind oder abgelehnt werden, und zwar unabhängig von den ausgewählten Handlerzuord-nungen.

� Zu verbergende URL-Segmente konfigurieren Konfigurieren Sie, welche URL-Segmente nicht bedient werden, um Teile Ihrer URL-Hierarchie zu verbergen.

� Abzulehnende URL-Sequenzen konfigurieren Konfigurieren Sie, welche URL-Muster nicht zulässig sind, um die Ausnutzung bekannter Sicherheitslücken zu verhindern, die bestimmte URL-Muster verwenden.

IIS 7.0 benutzt standardmäßig die Anforderungsfilterung, um Anforderungen zurückzuweisen, die verdächtige Payloads enthalten, und um zu verhindern, dass bestimmte Inhalte vom Webserver über-mittelt werden. Sie können diese Funktionalität ebenfalls nutzen, um den Input Ihrer Anwendung weiter einzuschränken oder zu verhindern, dass zusätzliche URLs, Verzeichnisse und Dateien oder Datei-namenserweiterungen vom Server übermittelt werden.

Vorsicht Die Anforderungsfilterung ist eine wichtige Sicherheitskomponente und darf nur dann entfernt werden, wenn zweifelsfrei feststeht, dass sie nicht benötigt wird. Es ist immer besser, die Anforderungsfilterungslimits durch Änderungen an der Konfiguration zu lockern, anstatt das Modul für die Anforderungsfilterung zu deinstallieren oder zu entfernen.

Für die Konfiguration der Anforderungsfilterung gibt es keine entsprechende IIS-Manager-Seite, so dass diese Einstellungen mit dem IIS-Manager nicht gesetzt werden können. Um sie zu setzen, können Sie an der Befehlszeile Appcmd.exe oder andere Konfigurations-APIs verwenden und den Konfigurations-



abschnitt system.webServer/security/requestFiltering direkt konfigurieren. Der Abschnitt requestFiltering ist standardmäßig nicht gesperrt, so dass Sie die Anforderungsfilterungskonfiguration in den web.config-Dateien der Site-, Anwendungs- oder URL-Ebene festlegen können.

Der Rest dieses Abschnitts stellt einige übliche Aufgaben für die Konfiguration der Anforderungs-filterung vor.

Anforderungslimits setzenSie können die Anforderungsfilterung nutzen, um noch restriktivere Anforderungslimits zu konfi-gurieren, sofern Ihre Anwendung dies zulässt. Dies könnte geschehen, um die Möglichkeiten eines Angreifers, Ihre Anwendung mit böswilligem Input zu gefährden, weiter einzuschränken. Es gibt aber auch Momente, in denen Sie die standardmäßigen Anforderungslimits lockern müssen, damit Ihre Anwendung richtig funktioniert, z.B. wenn Ihre Anwendung lange Abfragezeichenfolgen verwendet, die das Standardlimit von 2048 Zeichen überschreiten.

Sie müssen möglicherweise die von der Anforderungsfilterung angewendeten Anforderungslimits modifizieren, wenn einige der Standardlimits die Nutzung Ihrer Anwendung stören.

Sie können wie folgt Appcmd benutzen, um Anforderungsfilterungslimits zu setzen.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/requestFiltering [/allowDoubleEscaping:bool] [/allowHighBitCharacters:bool] [/requestLimits.maxAllowedContentLength:uint] [/requestLimits.maxUrl:uint] [/requestLimits.maxQueryString:uint]

Dieser Befehl verwendet die in Tabelle 14.7 beschriebenen Parameter.

Tabelle 14.7 Parameter für Anforderungsfilterungslimits


ConfigurationPath Der Konfigurationspfad, für den diese Konfiguration gesetzt werden soll

allowDoubleEscaping Gibt an, ob Anforderung-URLs, die doppelt kodierte Zeichen enthalten, zulässig sind. Angreifer verwenden manchmal doppelt kodierte URLs, um Sicherheitslücken im Autorisierungscode auszunutzen, die sich auf die Kanonisierung beziehen. Wenn sich ein URL nach zwei Normalisierungsversuchen nicht genauso wie nach dem ersten Versuch präsentiert, wird die Anforderung mit dem Antwortstatuscode 404.11 zurück-gewiesen. Der Standard ist false.

allowHighBitCharacters Gibt an, ob im URL Nicht-ASCII-Zeichen zulässig sind. Wird im URL ein High-Bit-Zeichen entdeckt, wird die Anforderung mit dem Antwortstatuscode 404.12 zurückgewiesen. Die Vorgabe ist true.

requestLimits.maxAllowedContentLength Die Maximallänge des Entitätskörpers der Anforderung (in Bytes). Wenn dieses Limit überschritten wird, wird die Anforderung mit dem Antwortstatuscode 404.13 zurückge-wiesen. Der Vorgabewert ist 30.000.000 bytes (ungefähr 28 Megabyte).

requestLimits.maxUrl Die Maximallänge des absoluten URL-Pfads (in Zeichen). Wenn dieses Limit über-schritten wird, wird die Anforderung mit dem Antwortstatuscode 404.14 zurückgewiesen. Der Vorgabewert ist 4096 Zeichen.

requestLimits.maxQueryString Die Maximallänge von Abfragezeichenfolgen (in Zeichen). Wenn dieses Limit über-schritten wird, wird die Anforderung mit dem Antwortstatuscode 404.15 zurückgewiesen. Der Vorgabewert ist 2048 Zeichen.



Hinweis Sie können ebenfalls für jeden Header das Limit für die Länge des Anforderungsheaders konfigurieren, indem Sie im Abschnitt system.webServer/security/requestFiltering der headerLimits-Auflistung die entsprechenden Limits hinzufügen. Wenn eine Anforderung ein konfiguriertes Headerlimit überschreitet, wird sie mit dem Antwort-statuscode 404.10 zurückgewiesen. Darüber hinaus können Sie die zulässigen Verben festlegen, indem Sie diese Verben der verbs-Auflistung hinzufügen. Wenn eine Anforderung ein unzulässiges Verb angibt, wird sie mit dem Antwortstatuscode 404.6 zurückgewiesen.

Zulässige Erweiterungen konfigurierenDer Webserver verarbeitet standardmäßig nur solche Dateinamenserweiterung, für die eine entsprechende Handlerzuordnung existiert. StaticFileModule verarbeitet standardmäßig alle nicht zugeordneten Erweite-rungen. StaticFileModule kümmert sich jedoch nur um die im Konfigurationsabschnitt system.webServer/staticContent aufgelisteten Erweiterungen (die bei IIS 6.0 und früheren IIS-Versionen auch als MimeMaps bekannt waren). Die Handlerzuordnungskonfiguration und die Konfiguration der statischen Inhalte dienen somit als zweistufiges Verfahren, um zu kontrollieren, welche Erweiterungen für einen bestimmten URL bereitgestellt werden dürfen.

Sie können jedoch die Anforderungsfilterung als ein tiefergehendes Verteidigungsmittel verwenden, um Anforderungen abzuweisen, die sich auf eine bestimmte Dateinamenserweiterung beziehen. Zuvor sollten Sie jedoch sicherstellen, dass diese Erweiterung nicht bei den IIS-Handlerzuordnungen und in der Liste der statischen Inhalte konfiguriert wurde. Dies gewährleistet, dass die auf diese Erweiterung bezogenen Anforderungen sehr früh in der Anforderungsverarbeitungspipeline abgewiesen werden, und zwar bevor sie von den zuvor erwähnten Konfigurationen zurückgewiesen werden.

Um mit Appcmd eine unzulässige bzw. explizit zugelassene Erweiterung hinzuzufügen, verwenden Sie die folgende Syntax.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/requestFiltering /+fileExtensions.[fileExtension='string',allowed='bool']

Die Zeichenfolge fileExtension wird im Format .erweiterung angegeben.

Um mit Appcmd eine unzulässige Erweiterung zu löschen, benutzen Sie die folgende Syntax.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/requestFiltering /-fileExtensions.[fileExtension='string']

Diese Befehle verwenden die in Tabelle 14.8 beschriebenen Parameter.

Sie können diese Konfiguration für eine bestimmte Site, Anwendung oder einen URL festlegen, indem Sie den früher in diesem Abschnitt vorgestellten Befehlen den entsprechenden Konfigurationspfad übergeben.

Tabelle 14.8 Parameter zum Löschen unzulässiger Erweiterungen



fileExtension Die Dateinamenserweiterung im Format .erweiterung, die zugelassen oder untersagt werden soll

allowed Gibt an, ob die Erweiterung zugelassen oder untersagt ist



Hinweis Alternativ hierzu können Sie die fileExtensions-Auflistung konfigurieren, um alle nicht aufgelisteten Erweiterungen zu verbieten, wodurch die Verwendung der zugelassenen Erweiterungen explizit ermöglicht wird. Diese Vorgehensweise zur Verkleinerung der Angriffsfläche ist möglicherweise effektiver als das Verbieten be-stimmter Erweiterungen. Sie müssen hierfür jedoch die Liste der Erweiterungen kennen, die für Ihre Anwendung zulässig sind. Um diese Möglichkeit zu nutzen, setzen Sie das allowUnlisted-Attribut der fileExtensions-Auflistung für den gewünschten Konfigurationspfad auf false.

Zu verbergende URL-Segmente konfigurierenSie können ebenfalls verhindern, dass ein bestimmtes URL-Segment bedient wird. ASP.NET nutzt diese Technik, um Anforderungen abzuweisen, die sich auf /BIN-, /App_Code- und andere spezielle /App_xxx-Verzeichnisse beziehen, die wiederum ASP.NET-Anwendungsressourcen enthalten, welche von der Anwendung nicht übermittelt werden dürfen. Sie können Ihre eigenen speziellen Verzeichnisse für solche Inhalte erstellen, die nicht übermittelt werden sollen, und diese Verzeichnisse mit verbor-genen URL-Segmenten schützen. Um beispielsweise zu verhindern, dass Inhalte aus Verzeichnissen übermittelt werden, die den Namen data tragen, können Sie ein verborgenes Segment namens data erstellen.

Direkt von der Quelle: Spezielle ASP.NET-Verzeichnisse schützenDie Debatte über den Schutz spezieller Verzeichnisse mit solchen Inhalten, die nicht direkt über-mittelt werden dürfen, z.B. das ASP.NET-Verzeichnis /BIN, reicht bis in die Zeit von IIS 5.0 zurück. Das ASP.NET-Team unternahm mehrere Versuche, um dieses Ziel zu erreichen. Zuerst wurden für IIS 5.0 die Leseberechtigungen für das /BIN-Verzeichnis gelöscht. Dies geschieht während des Starts einer ASP.NET-Anwendung. Schließlich wurde dem ASP.NET-ISAPI-Filter Code hinzugefügt, der Anforderungen untersagte, die das /BIN-Segment enthielten.

Während der Entwicklung von ASP.NET 2.0 hatte ich die Gelegenheit, die Lösung dieses Problems für die verschiedenen neuen, von ASP.NET 2.0 eingeführten Verzeichnisse (z.B. das neue App_Code-Verzeichnis) zu beaufsichtigen. Unglücklicherweise stellte das Löschen der Leseberechtigungen für diese Verzeichnisse keine Lösung mehr dar, weil ASP.NET bei IIS 6.0 nicht über das Recht verfügte, in die IIS-Metabasis zu schreiben. Da es kein allgemeines Webserverfeature für den Schutz spezieller Verzeichnisse gab, bestand unsere einzige Option darin, dem ISAPI-Filter die Möglichkeit hinzuzu-fügen, neue Verzeichnisse zu sperren. Verständlicherweise war der anstrengendste Teil dieses Projekts die Befragung der Community hinsichtlich der bevorzugten Namen für diese speziellen Verzeichnisse. Dies löste eine intensive Diskussion aus, und die Vorschläge für die Verzeichnisnamen änderten sich ständig, von Application_Code über App$_Code bis hin zu App_Code. Am Ende hatten wir die ganzen Namensänderungen so satt, dass der Entwicklungsmanager für uns alle Hüte bestellte, auf denen App$ stand.

IIS 7.0 bietet nun eine allgemeine Lösung für den Schutz spezieller Verzeichnisse, eine Lösung, die während der Installation von ASP.NET genutzt wird, um die speziellen Verzeichnisse dieses Frameworks zu schützen. ISAPI-Filter sind hierfür nicht mehr erforderlich. Darüber hinaus stellen verborgene URL-Segmente ein allgemeines Verfahren dar, das von jedem verwendet werden kann, um geschützte Verzeichnisse für die eigenen Anwendungen zu konfigurieren, ohne speziellen Code für eine solche Sperrung schreiben zu müssen.

Mike Volodarsky




Um mit Appcmd ein verborgenes URL-Segment hinzuzufügen, verwenden Sie die folgende Syntax.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/requestFiltering /+hiddenSegments.[segment='string']

Die Segmentzeichenfolge gibt das zu schützende Segment an.

Um ein verborgenes URL-Segment mit Appcmd zu löschen, benutzen Sie die folgende Syntax.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/requestFiltering /-hiddenSegments.[segment='string']

Hinweis Es ist nicht wie bei Dateinamenserweiterungen möglich, die nicht konfigurierten Segmente zu verbieten. Sie können nur bestimmte Segmente verbieten, indem Sie sie mit dem vorherigen Befehl hinzufügen.

Sie können die Konfiguration für eine bestimmte Site, Anwendung oder einen URL vornehmen, indem Sie den vorherigen Befehlen den entsprechenden Konfigurationspfad übergeben.

Abzulehnende URL-Sequenzen konfigurierenIn einigen Fällen möchten Sie vielleicht Anforderungen zurückweisen, deren URL bestimmte Sequenzen enthält, auch wenn es sich dabei um unvollständige Segmente handelt. Wenn es nicht möglich ist, die Anwendung selbst zu korrigieren, ist dies eine effektive Möglichkeit, um eine Anwendung vor bestimm-ten URL-Mustern zu schützen, die Probleme verursachen.

Um mit Appcmd eine abzulehnende URL-Sequenz hinzuzufügen, verwenden Sie die folgende Syntax.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/requestFiltering /+denyURLSequences.[sequence='string']

Die Sequenzzeichenfolge gibt die abzulehnende Sequenz an.

Um eine abzulehnende URL-Sequenz mit Appcmd zu löschen, benutzen Sie die folgende Syntax.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/requestFiltering /-denyURLSequences.[sequence='string']

Hinweis Es ist nicht wie bei Dateinamenserweiterungen möglich, die nicht konfigurierten URL-Sequenzen zu verbieten. Sie können nur bestimmte Sequenzen verbieten, indem Sie sie mit dem vorherigen Befehl hinzufügen.

Sie können die Konfiguration für eine bestimmte Site, Anwendung oder einen URL vornehmen, indem Sie den vorherigen Befehlen den entsprechenden Konfigurationspfad übergeben.

AutorisierungWie bereits erwähnt wurde, ist die Autorisierung die zweite Phase der Ermittlung, ob ein Client über das Recht verfügt, eine bestimmte Anforderung zu initiieren. Während der Autorisierung wird überprüft, ob die während der Authentifizierungsphase ermittelte Benutzeridentität auf die angeforderten Ressourcen zugreifen darf.



IIS 7.0 bietet mehrere Autorisierungsverfahren an, mit denen der Zugriff auf Ressourcen gesteuert werden kann:

� Auf NTFS-ACLs basierende Autorisierung IIS 7.0 verifiziert standardmäßig, dass die Identität des authentifizierten Benutzers über das Recht verfügt, auf die physikalische Datei oder den physi-kalischen Ordner zuzugreifen, die/der dem angeforderten URL entspricht. Diese Überprüfung wird nur für solche Anforderungen durchgeführt, die physikalischen Dateien oder Verzeichnissen zuge-ordnet sind und Authentifizierungsmethoden nutzen, die Windows-Tokens generieren. Dieses Autorisierungsverfahren geht mit mehreren Verwendungseinschränkungen einher, die später in diesem Abschnitt ausführlich erläutert werden.

� URL-Autorisierung Der neue IIS 7.0-Rollendienst URL-Autorisierung ermöglicht es Anwen-dungen, deklarative konfigurationsbasierte Regeln zu erstellen, um zu ermitteln, welche authen-tifizierten Benutzer und/oder Rollen das Recht besitzen, auf eine Website oder bestimmte URLs innerhalb dieser Website zuzugreifen. Dieses Feature ersetzt die URL-Autorisierung von IIS 6.0, die nicht mehr unterstützt wird.

� URL-Autorisierung von ASP.NET Das ASP.NET-Feature URL-Autorisierung, das seit ASP.NET 1.0 verfügbar ist, gleicht der URL-Autorisierung von IIS. Die Konfigurationssyntax und die Regel-verarbeitung weisen jedoch leichte Unterschiede auf. ASP.NET-Anwendungen, die heute dieses Feature nutzen, können es für die Steuerung des Zugriffs auf alle Webseiteinhalte konfigurieren, sofern sie im integrierten ASP.NET-Modus ausgeführt werden.

Darüber hinaus können Entwickler benutzerdefinierte Autorisierungsfeatures zur Verfügung stellen, indem sie unter Verwendung der nativen Modul-APIs von IIS 7.0 oder der ASP.NET-APIs (bei Anwen-dungen, die im integrierten ASP.NET-Modus arbeiten) entsprechende Module entwickeln. Sie können sogar die meisten bereits vorhandenen ASP.NET-Autorisierungsmodule sofort in Anwendungen nutzen, die den integrierten ASP.NET-Modus verwenden. Die Entwicklung benutzerdefinierter Autori-sierungsfeatures, die Geschäftsregeln für die Autorisierung implementieren und die leistungsfähige ASP.NET-Mitgliedschaft und -Rolleninfrastruktur nutzen können, wird dadurch sehr viel einfacher. Weitere Informationen zur Installation und Verwendung benutzerdefinierter Module finden Sie im zwölften Kapitel.

Vorsicht Lassen Sie beim Konfigurieren oder Entfernen von Autorisierungsmodulen besondere Vorsicht walten. Wenn Sie ein Autorisierungsmodul entfernen, das zum Einschränken des Zugriffs auf eine Anwendung verwendet wird, können Teile dieser Anwendung für nicht autorisierte Benutzer zugänglich werden. Lesen Sie im zwölften Kapitel den Abschnitt »Webservermodule sichern«, um weitere Informationen zum Entfernen sicherheitsrelevanter Module zu erhalten.

Im verbleibenden Abschnitt werden wir einen genauen Blick auf die Autorisierungsfeatures werfen.

Auf NTFS-ACLs basierende AutorisierungDie IIS 7.0-Serverengine führt (im Gegensatz zu einem Modul) automatisch eine auf NTFS-ACLs basierende Autorisierung durch. Während dieser Autorisierung überprüft der Webserver, ob die Identität des authentifizierten Benutzers über das Recht verfügt, auf die angeforderte physikalische Datei oder den angeforderten physikalischen Ordner zuzugreifen.



Hinweis Die auf NTFS-ACLs basierende Autorisierung ist ein Teil des IIS-Webserverkerns und wird somit immer zusammen mit dem Webserver installiert. Obwohl sie nicht deinstalliert oder deaktiviert werden kann, können Sie eine der in der folgenden Liste aufgeführten Anforderungen entfernen, damit Ihre Anwendung diese Art der Autorisierung nicht nutzt.

Diese Autorisierung erfolgt automatisch, wenn alle nachstehenden Bedingungen erfüllt sind:

� Die Identität des authentifizierten Benutzers muss über ein Windows-Token verfügen. Wenn die Anforderung mithilfe eines Authentifizierungsverfahrens authentifiziert wird, das keine Windows-Tokens zur Verfügung stellt, z.B. die Formularauthentifizierung, wird diese Autorisierung nicht durchgeführt.

� Die für die Anforderung ausgewählte Handlerzuordnung gibt als Ressourcentyp File, Directory oder Either an. Einige Zuordnungen arbeiten mit dem Ressourcentyp Unspecified, um Anforderungen zu ermöglichen, die sich auf virtuelle URLs beziehen, die auf dem Datenträger über keine entspre-chende physikalische Ressource verfügen. Für solche Handlerzuordnungen wird diese Art der Autorisierung nicht durchgeführt.

Hinweis Die meisten ASP.NET-Handlerzuordnungen sind standardmäßig mit Unspecified gekennzeichnet. ASP.NET verfügt jedoch über eine zusätzliche Funktionalität, die gewährleistet, dass die Zugriffsprüfung erfolgt, wenn der URL einer physikalischen Datei oder einem entsprechenden Ordner zugeordnet ist (mit Ausnahme von Inhalten, die sich in einem virtuellen Verzeichnis befinden, das seine Dateien über einen UNC-Pfad speichert).

� Der angeforderte URL ist einer physikalischen Datei oder einem physikalischen Ordner zuge-ordnet, die/der sich auf dem Datenträger befindet. Wenn die Datei oder das Verzeichnis nicht vorhanden ist, führt IIS keine Prüfung durch.

� Das virtuelle Verzeichnis, auf das sich eine initiierte Anforderung bezieht, definiert keine festen Anmeldeinformationen für den Zugriff. Wenn ein virtuelles Verzeichnis feste Anmeldeinforma-tionen verwendet, werden diese für den Zugriff auf alle Inhalte des Verzeichnisses genutzt, so dass IIS die Zugriffsmöglichkeiten des authentifizierten Benutzers nicht überprüfen muss.

Damit Sie die auf NTFS-ACLs basierende Autorisierung erfolgreich nutzen können, müssen außerdem die folgenden Bedingungen erfüllt sein:

� Für die physikalischen Ressourcen sind ACLs konfiguriert, die dafür sorgen, dass jedem authenti-fizierten Benutzer der Zugriff richtig gewährt bzw. verweigert wird. Dies geschieht in der Regel, indem alle zulässigen Benutzer in einer Gruppe gesammelt werden und dieser Gruppe der Zugriff auf die Inhalte gewährt wird.

� Wenn das virtuelle Verzeichnis, auf das sich eine initiierte Anforderung bezieht, auf eine Remote-UNC-Freigabe verweist und keine festen UNC-Anmeldeinformationen angibt, muss die Identität des authentifizierten Benutzers an den Remoteserver delegiert werden können. Dies erfordert die Standardauthentifizierung, oder die eingeschränkte Delegierung bzw. der Protokollübergang muss konfiguriert sein. Weitere Informationen finden Sie später in diesem Kapitel im Abschnitt »UNC-Authentifizierung«.

Aufgrund dieser Einschränkungen und des Aufwands, der mit der Verwaltung von NTFS-ACL-Berechti-gungen für mehrere Benutzer einhergeht, wird die auf NTFS-ACLs basierende Autorisierung nicht als allgemeines Verfahren empfohlen, um den Zugriff auf IIS-Ressourcen einzuschränken Benutzen Sie sie nur dann, wenn Ihre Anwendung die zuvor genannten Anforderungen erfüllt und Sie ACLs als Autori-



sierungsverfahren verwenden möchten (z.B. wenn Sie statische Ressourcen für Benutzer mit Domänen- oder lokalen Computerkonten zur Verfügung stellen, und für diese Ressourcen bereits die richtigen Berechtigungen konfiguriert wurden).

Da diese Autorisierung für physikalische Ressourcen automatisch durchgeführt wird, müssen Sie alle benötigten Ressourcen so konfigurieren, dass diese den authentifizierten Identitäten, die mit Ihrer Anwendung arbeiten müssen, Zugriffsrechte gewähren. Lesen Sie in diesem Kapitel den Abschnitt »NTFS-Berechtigungen für den Mindestzugriff gewähren«, um weitere Informationen zur richtigen Konfiguration von NTFS-ACLs für die NTFS-ACL-Autorisierung zu erhalten.

URL-AutorisierungDas IIS 7.0-Feature URL-Autorisierung ist neu. Es bietet die Möglichkeit, deklarative Zugriffsteuerungsregeln zu konfigurieren, die den Zugriff auf Ressourcen abhängig vom authentifizierten Benutzer und dessen Rollenmitgliedschaft gewähren bzw. verweigern.

Hinweis Die URL-Autorisierung ist kein Bestandteil der IIS-Standardinstallation. Sie können Sie unter Windows Vista über die Windows-Funktionen und die Kategorie IIS und unter Windows Server 2008 über den Server-Mana-ger und die Webserverrollenkategorie Sicherheit installieren. Das zwölfte Kapitel hält weitere Informationen zur Installation und Aktivierung von Modulen bereit.

Im Gegensatz zur auf NTFS-ACLs basierenden Autorisierung weist die URL-Autorisierung die folgenden Vorteile auf:

� Sie ist nicht an Authentifizierungsschemata gebunden, die Windows-Identitäten produzieren. Sie kann in Verbindung mit jedem Authentifizierungsschema verwendet werden, das benutzerdefinierte authentifizierte Benutzeridentitäten generiert, z.B. die Formularauthentifizierung.

� Mit ihr ist es möglich, Regeln für bestimmte URLs zu konfigurieren, die nicht Dateien oder Ver-zeichnissen zugrunde liegen. Deshalb ist sie nicht an bestimmte Ressourcentypen gebunden, und sie ist nicht darauf angewiesen, dass Dateien oder Verzeichnisse vorhanden sind.

� Sie speichert Autorisierungsregeln in der Konfiguration und nicht in NTFS-ACLs. Diese Regeln sind einfacher zu erstellen und zu verwalten, und Sie können in verteilten web.config-Dateien angegeben werden, die ein Bestandteil der Anwendung sind und zusammen mit dieser auf anderen Servern bereitgestellt oder von Server zu Server kopiert werden.

� Sie integriert sich in den ASP.NET-Dienst Mitgliedschaft und Rollen, der es benutzerdefinierten Authentifizierungs- und Rollenverwaltungsmodulen ermöglicht, die authentifizierten Benutzer und deren Rollen zur Verfügung zu stellen. Sie können die ASP.NET-Formularauthentifizierung zusammen mit dem Dienst Mitgliedschaft und Rollen benutzen, um für Ihre Anwendung schnell einen datengesteuerten Speicher für Benutzer- und Rollenanmeldeinformationen bereitzustellen.

Hinweis Das IIS 7.0-Feature URL-Autorisierung ist neu. Es hat keinen Bezug zum gleichnamigen IIS 6.0-Feature URL-Autorisierung, das zu komplex sowie schwierig zu konfigurieren ist und nicht oft verwendet wird. Das IIS 6.0-Feature URL-Autorisierung ist in IIS 7.0 nicht enthalten.

Das ASP.NET-Feature URL-Autorisierung hat das neue URL-Autorisierungsfeature inspiriert, das eine ähnliche Funktionalität implementiert. Es gibt jedoch einige wichtige Unterschiede hinsichtlich der Konfiguration und Verarbeitung von Regeln. Diese Unterschiede werden später in diesem Abschnitt behandelt.



Einschränken des Zugriffs mit der URL-AutorisierungUm mithilfe der URL-Autorisierung den Zugriff auf Ihre Anwendung einzuschränken, müssen Sie URL-Autorisierungsregeln konfigurieren. Diese Regeln können auf der Webserverebene konfiguriert werden. Alternativ hierzu können Sie sie für eine bestimmte Website, Anwendung oder einen URL konfigurieren. Mithilfe der URL-Autorisierung ist es sehr einfach, den Zugriff auf jeden beliebigen Teil Ihrer Website auf bestimmte Benutzer oder Rollen zu beschränken.

Es gibt die folgenden Regeln:

� Zulassen Eine Zulassungsregel gewährt den Zugriff auf die angeforderte Ressource und erlaubt das Fortsetzen der Anforderungsverarbeitung.

� Verweigern Eine Ablehnungsregel verweigert den Zugriff auf die angeforderte Ressource, wodurch die Anforderung zurückgewiesen wird.

Beide Regeln können einen Satz Benutzer, Rollen und/oder Verben festlegen, der von der URL-Autori-sierung verwendet wird, um die jeweilige Regel auf die Anforderungen anzuwenden. Kann eine Regel angewendet werden, erfolgt die damit verbundene Aktion (Gewährung oder Ablehnung). Wenn die Anforderung abgelehnt wird, bricht die URL-Autorisierung die Anforderungsverarbeitung mit dem Antwortstatuscode 401 (nicht autorisiert) ab. Wenn keine Regel angewendet werden kann, wird die jeweilige Anforderung ebenfalls abgelehnt.

Die Ablehnungsregeln werden immer vor den Zulassungsregeln verarbeitet, was bei der URL-Autori-sierung von ASP.NET nicht der Fall ist. Die relative Reihenfolge zwischen den Verweigerungs- und Zulassungsregeln untereinander spielt keine Rolle. Außerdem spielt auch die Reihenfolge zwischen den Regeln, die auf übergeordneten Konfigurationsebenen definiert wurden, und den Regeln der aktuellen Konfigurationsebene keine Rolle, weil alle Ablehnungsregeln aller Ebenen immer zuerst verarbeitet werden. Dann folgen alle Zulassungsregeln. Wenn keine Regel angewendet werden kann, besteht das Standardverhalten darin, die Anforderung zurückzuweisen.

Die URL-Autorisierung konfiguriert auf der Webserverebene standardmäßig eine Regel, die allen Benutzern Zugriff gewährt. Sie können den Zugriff auf Ihre Website oder Teile davon einschränken, indem Sie mithilfe der folgenden Verfahren Autorisierungsregeln erstellen:

� Löschen Sie die Standardzulassungsregel für alle Benutzer, und erstellen Sie explizit Zulassungsre-geln für Benutzer und Rollen, die auf die aktuelle URL-Ebene zugreifen können sollen. Auf diese Weise werden alle Anforderungen zurückgewiesen, sofern nicht der authentifizierte Benutzer oder die entsprechende Rolle der konfigurierten Zulassungsregel entspricht. Dies ist die empfohlene Vor-gehensweise, da sie gewährleistet, dass nur die konfigurierten Benutzer und Rollen auf die jeweili-gen Ressourcen zugreifen können. Allen anderen Benutzern wird der Zugriff verweigert.

� Erstellen Sie explizit Ablehnungsregeln für Benutzer und Rollen, die auf die aktuelle URL-Ebene nicht zugreifen können sollen. Diese Vorgehensweise ist geeignet, um nur den angegebenen Benut-zern und Rollen den Zugriff zu verweigern. Es ist jedoch keine übliche Sicherheitsmaßnahme, da die Benutzer und Rollen in der Regel nicht gebunden sind. Eine Ausnahme hiervon ist die Erstel-lung einer Regel zum Ablehnen aller anonymen Benutzer, damit der Zugriff ausschließlich auf die authentifizierten Benutzer beschränkt wird.



Hinweis Wenn Sie die Zugriffsteuerungsregeln für Ihre Anwendung definieren, sollten Sie Rollen und nicht einzelnen Benutzern Zugriffsrechte gewähren. Dies vereinfacht die Verwaltung der Autorisierungsregeln, wenn im Laufe der Zeit weitere Benutzer hinzugefügt werden.

Lesen Sie den folgenden Abschnitt »URL-Autorisierungsregeln erstellen«, um weitere Informationen zur Konfiguration von URL-Autorisierungsregeln zu erhalten.

URL-Autorisierungsregeln erstellenSie können URL-Autorisierungsregeln mit dem IIS-Manager konfigurieren, indem Sie im Hierarchie-listenfeld den gewünschten Knoten markieren und einen Doppelklick auf Autorisierungsregeln aus-führen. In dem daraufhin angezeigten Fenster, das in Abbildung 14.5 zu sehen ist, finden Sie eine Liste der Regeln, die für die von Ihnen markierte Ebene gelten. Diese Liste enthält sowohl die auf den höheren Konfigurationsebenen konfigurierten Regeln als auch die Regeln, die für die aktuelle Konfi-gurationsebene konfiguriert wurden.

Abbildung 14.5 URL-Autorisierungsregeln konfigurieren

Sie können bereits vorhandene Autorisierungsregeln (einschließlich der nicht gesperrten übergeord-neten Autorisierungsregeln) löschen, indem Sie sie in der Liste markieren und im Bereich Aktionen auf Entfernen klicken. Sie können eine Zulassungs- oder Ablehnungsregel hinzufügen, indem Sie im Bereich Aktionen auf Zulassungsregel hinzufügen oder Ablehnungsregel hinzufügen klicken. Abbildung 14.6 zeigt eine Zulassungsregel, die verwendet werden kann, um allen Benutzern, bestimmten Benut-zern oder Rollen den Zugriff zu gewähren.



Abbildung 14.6 Eine URL-Autorisierungszulassungsregel hinzufügen

Sie können URL-Autorisierungsregeln ebenfalls bearbeiten, indem Sie sie direkt im Konfigurations-abschnitt system.webServer/security/authorization konfigurieren. Dazu benutzen Sie das Befehlszeilenhilfs-mittel Appcmd oder die Konfigurations-APIs. Dieser Konfigurationsabschnitt ist standardmäßig nicht gesperrt, um das Speichern von URL-Autorisierungsregeln in den web.config-Dateien Ihrer Anwen-dung zu ermöglichen, so dass sie zusammen mit den entsprechenden Anwendungsinhalten auf anderen Webservern bereitgestellt werden können.

Um mit Appcmd eine URL-Autorisierungsregeln hinzuzufügen, können Sie die folgende Syntax benutzen.%systemroot%\system32\inetsrv\Appcmd.exe set config [ConfigurationPath] /section:system.webServer/security/authorization "/+[users='string',roles='string',verbs='string',accessType=’enum’]"

Um eine URL-Autorisierungsregel mit Appcmd zu löschen, können Sie die folgende Syntax verwenden%systemroot%\system32\inetsrv\Appcmd.exe set config [ConfigurationPath] /section:system.webServer/security/authorization "/-[users='string',roles='string',verbs='string']"

Die Parameter dieser Befehle sind in Tabelle 14.9 beschrieben.

Tabelle 14.9 Parameter zum Hinzufügen von URL-Autorisierungsregeln



users Die kommagetrennte Liste der Benutzernamen, die von dieser Regel zugelassen oder abgelehnt werden. Jeder Benutzername wird mit dem Benutzernamen des für die jeweilige Anforderung ermittelten authentifizier-ten Benutzers verglichen, und die Regel wird angewendet, sobald eine Übereinstimmung mit einem einzelnen Benutzer (oder einer Rolle) gegeben ist. Benutzen Sie für Windows-Identitäten, die Domänenkonten repräsen-tieren, das Format für Domänenbenutzernamen (domain\user) anstelle des vollqualifizierten Domänennamen-formats ([email protected]). Benutzen Sie das Sternchen (*), um alle Benutzer auszuwählen, und das Fragezeichen (?), um auf anonyme Benutzer zu verweisen. Der Vorgabewert ist "".



ASP.NET-Rollen für die URL-Autorisierung verwendenFür Anwendungen, die im integrierten ASP.NET-Modus arbeiten, kann das Feature ASP.NET-Rollen konfiguriert werden, um für jeden authentifizierten Benutzer anwendungsspezifische Rollen zur Ver-fügung zu stellen. Die URL-Autorisierung von IIS 7.0 kann ähnlich wie das ASP.NET-Feature URL-Autorisierung Zugriffsregeln angeben, die Rollen verwenden, welche vom Feature .NET-Rollen oder einem anderen ASP.NET-Modul zur Verfügung gestellt werden, um anwendungsspezifische Autori-sierungsschemata zu implementieren. Weitere Informationen zum Einrichten des Features ASP.NET-Rollen finden Sie unter http://msdn2.microsoft.com/en-us/library/9ab2fxh0.aspx.

Wenn das Feature .NET-Rollen aktiviert und ein Rollenanbieter für Ihre Anwendung konfiguriert ist, können Sie URL-Autorisierungsregeln konfigurieren, die sich auf die Rollen Ihrer Anwendung stützen. Um sicherzustellen, dass die Rollen für solche Anforderungen, die sich auf Nicht-ASP.NET-Inhalts-typen beziehen, verfügbar sind, sollten Sie die managedHandler-Vorbedingung des RoleManager-Moduls entfernen. Wie Sie dafür sorgen, dass verwaltete Module nach Entfernen der managedHandler-Vorbe-dingung für alle Anforderungen ausgeführt werden, erfahren Sie im zwölften Kapitel und dort im Abschnitt »Verwaltete Module für alle Anforderungen ausführen lassen«.

Sie können Rollen auch direkt mit dem IIS-Manager erstellen, indem Sie im Hierarchielistenfeld den Knoten einer Anwendung markieren und einen Doppelklick auf .NET-Rollen ausführen. Auf der darauf-hin angezeigten Seite können Sie bereits vorhandene Rollen verwalten, neue Rollen mit dem für die Anwendung konfigurierten Rollenanbieter erstellen und Anwendungsbenutzer mit Rollen verknüpfen.

AuthentifizierungDie Authentifizierung ist die Ermittlung der Identität des Benutzers, der eine an den Webserver gerichtete Anforderung initiiert. Die Autorisierungsfeatures können dann diese Identität benutzen, um die auf be-stimmte Ressourcen oder Teile der Anwendung bezogene Anforderungen zuzulassen oder abzulehnen. In einigen Fällen kann der Webserver oder die Anwendung diese Identität annehmen, um auf Ressourcen zuzugreifen. Schließlich kann die Anwendung die Identität nutzen, um die Anwendung an den anfordernden Benutzer anzupassen.

IIS 7.0 verfügt über die folgenden Authentifizierungsfeatures:

� Anonyme Authentifizierung Dieses Authentifizierungsverfahren stellt eine konfigurierte Windows-Identität für alle anonymen Benutzer der Anwendung zur Verfügung. Clientanmeldeinformationen müssen hierfür nicht bereitgestellt werden. Diese Art der Authentifizierung wird verwendet, um anonyme (nicht authentifizierte) Zugriffe zuzulassen.

roles Die kommagetrennte Liste der von dieser Regel zugelassenen oder abgelehnten Rollen. Für jede Rolle wird die Rollenmitgliedschaft anhand des für die Anforderung ermittelten authentifizierten Benutzers getestet, und die Regel wird angewendet, sobald eine Übereinstimmung mit einer einzelnen Rolle (oder einem einzelnen Benutzer) gegeben ist. Der Vorgabewert ist "".

verbs Die kommagetrennte Liste der Verben (die Groß-/Kleinschreibung wird beachtet), die mit dem Anforderungs-verb verglichen wird. Erfolgt eine Angabe, muss eines der Verben mit dem Anforderungsverb übereinstimmen, damit die Regel angewendet wird. Der Vorgabewert ist "".

accessType Gibt an, ob die Regel den Zugriff zulassen oder verweigern soll. Akzeptierte Werte sind Allow und Deny. Dieser Parameter muss zum Hinzufügen einer Regel angegeben werden.

Tabelle 14.9 Parameter zum Hinzufügen von URL-Autorisierungsregeln (Fortsetzung)




� Standardauthentifizierung Dieses Authentifizierungsverfahren ermöglicht es dem Client, den Benutzernamen und das Kennwort in Form von Klartext an den Webserver zu übermitteln. Die Standardauthentifizierung ist in RFC 2617 definiert und wird von fast allen Browsern unterstützt.

� Digestauthentifizierung Dieses Authentifizierungsverfahren ist eine Version der Standard-authentifizierung, die etwas sicherer ist. Sie ermöglicht es dem Client, Benutzeranmeldeinforma-tionen mithilfe eines aus dem Benutzernamen und dem Kennwort bestehenden Hash zur Verfügung zu stellen. Die Digestauthentifizierung ist in RFC 2617 definiert und wird von den meisten Brow-sern unterstützt. Die Implementierung, die in IIS 7.0 verwendet wird, wurde bei IIS 6.0 als erweiterte Digestauthentifizierung bezeichnet.

� Windows-Authentifizierung Dieses Authentifizierungsverfahren unterstützt die Windows-Authentifizierungsprotokolle NTLM (NT LAN Manager) und Kerberos.

� Authentifizierung über Clientzertifikatzuordnung Mit diesem Authentifizierungsverfahren können SSL-Clientzertifikate unter Verwendung von Active Directory-Verzeichnisdiensten Windows-Konten zugeordnet werden.

� Authentifizierung über IIS-Clientzertifikatzuordnung Mit diesem Authentifizierungsver-fahren können SSL-Clientzertifikate über die in der IIS-Konfiguration gespeicherten 1:1- oder n:1-Zuordnungen Windows-Konten zugeordnet werden.

� UNC-Authentifizierung Hierbei handelt es sich nicht um ein echtes Authentifizierungsverfahren im eigentlichen Sinne, weil diese Art der Authentifizierung nicht zum Einrichten der Identität des anfordernden Clients verwendet werden kann. IIS 7.0 nutzt die UNC-Authentifizierung, um eine Identität zu generieren, die auf die Remoteinhalte einer UNC-Freigabe zugreifen kann.

Darüber hinaus verwenden IIS 7.0-Anwendungen, die im integrierten ASP.NET-Modus ausgeführt werden, ein für IIS und ASP.NET vereinheitlichtes Authentifizierungsmodell. Auf diese Weise können bereits vorhandene ASP.NET-Authentifizierungsmodule oder neue verwaltete Authentifizierungs-module, die mit den ASP.NET-APIs entwickelt wurden, für alle Inhalte der Anwendung genutzt werden. Wenn ASP.NET installiert ist, sind außerdem die folgenden Authentifizierungsmethoden verfügbar:

� Formularauthentifizierung Dieses ASP.NET-Authentifizierungsverfahren unterstützt die formularbasierte Authentifizierung anhand von Anmeldeinformationsspeichern, die während des Betriebs ausgetauscht werden können. Dies geschieht über den ASP.NET-Mitgliedschaftsdienst. Weitere Informationen zum Schützen von Websiteinhalten über die ASP.NET-Formularauthentifi-zierung finden Sie unter http://www.iis.net/articles/view.aspx/IIS7/Extending-IIS7/Getting-Started/How-to-Take-Advantage-of-the-IIS7-Integrated-Pipel.

Die folgenden IIS 6.0-Authentifizierungsverfahren werden nicht mehr unterstützt:

� IIS 6.0-Digestauthentifizierung Die erweiterte IIS 7.0-Digestauthentifizierung wird nun als einziges Digestauthentifizierungsverfahren angeboten.

� .NET Passport-Authentifizierung Passport wird von Windows Server 2008 nicht mehr unter-stützt, weshalb dieses Verfahren ebenfalls nicht mehr unterstützt wird.

Entwickler können außerdem benutzerdefinierte Authentifizierungsfeatures zur Verfügung stellen, die mit der neuen nativen Modul-API von IIS 7.0 oder mit den ASP.NET-APIs (für Anwendungen, die den integrierten Modus verwenden) entwickelt wurden. Anwendungen, die im integrierten Modus ausge-führt werden, können sogar die meisten bereits vorhandenen benutzerdefinierten ASP.NET-Authentifi-



zierungsmodule sofort nutzen, um überall in einer Site eine Authentifizierung durchzuführen. Weitere Informationen zur Installation und Verwendung von benutzerdefinierten Modulen finden Sie im zwölften Kapitel.

Sie können mehrere Authentifizierungsverfahren für Ihre Website, Anwendung oder Teile davon konfigurieren, um diese mit einer benutzerbasierten Autorisierung zu schützen, den Identitätswechsel für den Zugriff auf Ressourcen zu ermöglichen oder die Anpassung einer Anwendung zuzulassen.

Hinweis IIS 7.0 verlangt, dass jede Anforderung authentifiziert wird. Deshalb muss mindestens ein Authentifizie-rungsverfahren aktiviert sein, das für jede Anforderung einen authentifizierten Benutzer zur Verfügung stellen kann.

Im verbleibenden Abschnitt wird jedes Authentifizierungsverfahren behandelt.

Anonyme AuthentifizierungMithilfe der anonymen Authentifizierung können Clients auf öffentliche Bereiche Ihrer Website zugrei-fen, ohne Anmeldeinformationen zur Verfügung stellen zu müssen. Die anonyme Authentifizierung ist das unter IIS 7.0 verwendete Authentifizierungsstandardverfahren.

Hinweis Die anonyme Authentifizierung ist Teil der IIS-Standardinstallation, und sie ist standardmäßig aktiviert. Sie können sie manuell installieren oder deinstallieren, indem Sie das Modul AnonymousAuthnenticationModule instal-lieren bzw. deinstallieren. Lesen Sie das zwölfte Kapitel, um weitere Informationen zur Installation und Aktivierung von Modulen zu erhalten.

Die anonyme Authentifizierung wird auf alle Anforderungen angewendet, die über keine mit anderen Authentifizierungsverfahren ermittelte authentifizierte Benutzeridentität verfügen. Damit dies möglich ist, wird für solche Anforderungen die Identität des authentifizierten Benutzers auf die Windows-Identität gesetzt, die dem konfigurierten anonymen Benutzerkonto entspricht.

Vorsicht Achten Sie darauf, die anonyme Authentifizierung für die Teile Ihrer Website zu deaktivieren, auf die anonyme Benutzer nicht zugreifen dürfen. Dies ist auch dann notwendig, wenn Sie andere Authentifizierungs-verfahren verwenden.

Die anonyme Authentifizierung ist standardmäßig so konfiguriert, dass sie das neue integrierte Konto IUSR verwendet. Sie greift nicht mehr auf das Konto IUSR_ComputerName zurück, das unter IIS 6.0 standardmäßig für die anonyme Authentifizierung genutzt wird. Da IUSR ein integriertes Konto ist, besitzt es kein Kennwort, das in regelmäßigen Abständen geändert oder zwischen mehreren Servern synchronisiert werden müsste. Außerdem weist das Konto IUSR auf allen Computern dieselbe SID auf, was ebenfalls darauf zurückzuführen ist, dass es sich um ein integriertes Konto handelt. Deshalb bleiben ACLs, die dieses Konto referenzieren, gültig, wenn sie von einem IIS 7.0-Server auf einen anderen kopiert werden.

Wenn Sie die anonyme Authentifizierung nutzen, stehen Ihnen die folgenden Möglichkeiten zur Verfügung:

� Das integrierte IUSR-Konto verwenden. Dies ist der Standard.

� Ein benutzerdefiniertes Konto verwenden. Sie können ein benutzerdefiniertes Konto konfi-gurieren, das anstelle des Kontos IUSR für anonyme Anforderungen verwendet werden soll.



� Die Anwendungspoolidentität verwenden. Sie können die anonyme Authentifizierung so konfigurieren, dass anstelle eines separaten anonymen Kontos die Identität des IIS-Arbeitsprozesses (Anwendungspoolidentität) verwendet wird.

Sie können die Anwendungspoolidentität verwenden, um die Verwaltung des Ressourcenzugriffs zu vereinfachen. Dies gewährleistet, dass der Zugriff auf Ressourcen immer unter der Anwendungspool-identität erfolgt, und zwar unabhängig davon, ob der Webserver unter Verwendung der Anwendungs-poolidentität auf Anwendungsressourcen zugreift oder ob er bzw. die Anwendung die Identität des authentifizierten Benutzers für den Zugriff auf Ressourcen annimmt. Auf diese Weise müssen Sie die Zugriffsrechte nur für eine Identität verwalten. Lesen Sie früher in diesem Kapitel den Abschnitt »NTFS-Berechtigungen für den Mindestzugriff gewähren«, um weitere Informationen zum Setzen von Berechtigungen zu erhalten.

Sie können mit dem IIS-Manager arbeiten, um die anonyme Authentifizierung zu aktivieren oder zu deaktivieren und die Optionen für den anonymen Benutzer zu setzen. Markieren Sie im Hierarchie-listenfeld den gewünschten Knoten, und führen Sie einen Doppelklick auf Authentifizierung aus. Markieren Sie in der Liste den Eintrag Anonyme Authentifizierung, und benutzen Sie im Bereich Aktionen die Optionen Aktivieren, Deaktivieren oder Bearbeiten, um diese Art der Authentifizierung zu konfigurieren.

Sie können die Authentifizierungskonfiguration auch direkt bearbeiten. Benutzen Sie das Befehls-zeilenhilfsmittel Appcmd.exe oder die Konfigurations-APIs, um den Abschnitt system.webServer/security/anonymousAuthentication zu konfigurieren. Appcmd bietet dazu die folgende Syntax an.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/anonymousAuthentication [/enabled:bool] [/username:string] [/password:string] [/logonMethod:enum]

Die Parameter dieses Befehls sind in Tabelle 14.10 beschrieben.

Tabelle 14.10 Parameter für die Konfiguration der anonymen Authentifizierung und des anonymen Benutzers


ConfigurationPath Der Konfigurationspfad, für den diese Konfiguration gesetzt werden soll. Wenn Sie diesen Parameter angeben, müssen Sie ebenfalls den Parameter /commit:apphost benutzen, um für den Fall, dass die Konfiguration auf die Website- oder URL-Ebene angewendet wird, Fehler aufgrund von Sperrungen zu vermeiden.

enabled Gibt an, ob die anonyme Authentifizierung aktiviert oder deaktiviert werden soll

username Der Benutzername, der für die anonyme Authentifizierung verwendet werden soll. Setzen Sie diesen Wert auf "", um mit der Anwendungspoolidentität zu arbeiten. Der Standard ist IUSR.

password Das Kennwort, das verwendet werden soll, wenn ein benutzerdefiniertes Konto für die anonyme Authen- tifizierung zum Einsatz kommt

logonMethod Das für den anonymen Benutzer zu verwendende Anmeldeverfahren. Zulässige Werte sind Interactive, Batch, Network und ClearText. Der Vorgabewert ist ClearText. Weitere Informationen zu Anmeldetypen erhalten Sie unter http://msdn2.microsoft.com/en-us/library/aa378184.aspx.



StandardauthentifzierungDie Standardauthentifizierung implementiert das Standardauthentifizierungsprotokoll, ein HTTP-Authentifizierungsstandardschema, das in RFC 2617 definiert ist und größtenteils von der HTTP-Clientsoftware unterstützt wird. Diese Art der Authentifizierung ermöglicht es dem Client, sowohl den Benutzernamen als auch das Kennwort in Form von Klartext zu übermitteln, und sie verwendet diese Anmeldeinformationen, um eine lokale Anmeldung an den Webserver oder die Webserverdomäne durchzuführen. Die Anmeldeinformationen müssen deshalb einem gültigen lokalen Konto oder einem Domänenkonto entsprechen, und sie führen dazu, dass die Anforderung mit einem Windows-Token authentifiziert wird, das diesem Konto entspricht.

Hinweis Die Standardauthentifizierung ist nicht Teil der IIS-Standardinstallation. Sie können sie unter Windows Vista mithilfe der Option Windows-Funktionen ein- oder ausschalten über die Kategorie Sicherheit installieren. Und Sie können sie unter Windows Server 2008 mithilfe des Server-Managers über die Webserverrollenkategorie Sicherheit installieren. Das zwölfte Kapitel enthält weitere Informationen zur Installation und Aktivierung von Modulen.

Die Standardauthentifizierung ist ein anfragebasiertes Authentifizierungsschema. Wenn die Standard-authentifizierung aktiviert ist und die erste Anforderung eines Clients auf eine Ressource abzielt, für die eine Authentifizierung erforderlich ist, wird die Anforderung mit dem Statuscodes 401 (nicht autorisiert) und dem Antwortheader WWW-Authenticate: basic zurückgewiesen. Wenn der Client die Standard-authentifizierung unterstützt, wird der Benutzer gewöhnlich dazu aufgefordert, die Anmeldeinforma-tionen einzugeben. Danach wird die Anforderung mit den Anmeldeinformationen erneut an den Web-server übermittelt. Das Modul für die Standardauthentifizierung stellt dann fest, dass diese Anforderung über Anmeldeinformationen verfügt, und es versucht, die Anforderung zu authentifizieren, indem es eine Anmeldung mit diesen Anmeldeinformationen durchführt. Der Client sendet diese Anmeldeinforma-tionen in der Regel zusammen mit jeder folgenden Anforderung, die sich auf denselben URL oder auf einen URL bezieht, der sich unterhalb des in der ursprünglich authentifizierten Anforderung enthaltenen URLs befindet.

Vorsicht Das bloße Aktivieren der Standardauthentifizierung bedeutet nicht, dass für Ihre Anwendung eine Authenti-fizierung notwendig ist. Sie müssen die anonyme Authentifizierung entweder deaktivieren und/oder URL-Autorisie-rungsregeln oder NTFS-Berechtigungen konfigurieren, die den Zugriff für den anonymen Benutzer verweigern.

Die Standardauthentifizierung ist nicht sicher, da sie die Anmeldeinformationen in Form von Klartext übermittelt, so dass ein Angreifer diese in seinen Besitz bringen kann, indem er die Anforderungspakete auf der Netzwerkebene abfängt. Dieses Risiko kann verringert werden, indem SSL zur Sicherung des Kommunikationskanals zwischen Client und Server verwendet wird. Wenn SSL eingesetzt wird, um alle Anforderungen, die Anmeldeinformationen enthalten, zu schützen, ist die Standardauthentifi-zierung durchaus eine sichere Option. Weitere Informationen zur Konfiguration einer sicheren Kommunikation mithilfe von SSL finden Sie später in diesem Kapitel im Abschnitt »Sichern der Kommunikation mit SSL (Secure Sockets Layer)«.

Vorsicht Die Standardauthentifizierung kann dazu führen, dass Anmeldeinformationen von böswilligen Benutzern abgefangen werden, da sie unverschlüsselt zum Webserver übermittelt werden. Wenn Sie mit der Standardauthen-tifizierung arbeiten, sollten Sie SSL benutzen, um die Website zu sichern.



Da die Standardauthentifizierung die Anmeldung auf dem Webserver lokal durchführt, kann das resul-tierende Windows-Token ohne Konfiguration der Delegation oder des Protokollübergangs verwendet werden, um auf die Ressourcen eines Remoteservers zuzugreifen. Lesen Sie später in diesem Kapitel den Abschnitt »Die Authentifizierungsdelegierung verstehen«, um weitere Informationen zu erhalten.

Die Standardauthentifizierung sorgt standardmäßig für eine Zwischenspeicherung des Anmeldetokens für den entsprechenden Benutzernamen und das Kennwort im Tokencache. Während dieser Zeit ist das Token innerhalb des Prozesses verfügbar. Wenn der Arbeitsprozess kompromittiert wird und das Token einen Benutzer mit umfassenden Berechtigungen repräsentiert, kann böswilliger Code dieses Token benutzen, um Berechtigungen heraufzustufen. Wenn Sie dem Code im Prozess nicht vertrauen, können Sie das Zwischenspeichern von Tokens entweder deaktivieren, indem Sie das entsprechende Modul deinstallieren, oder Sie setzen die Dauer des Zwischenspeicherns von Tokens mit dem Wert HKLM\ SYSTEM\CurrentControlSet\Services\InetInfo\Parameters\UserTokenTTL auf die gewünschte Sekundenzahl herab.

Sie können den IIS-Manager verwenden, um die Standardauthentifizierung zu aktivieren oder zu deak-tivieren und die Optionen für das Anmeldeverfahren zu konfigurieren. Markieren Sie im Hierarchie-listenfeld den gewünschten Knoten, und führen Sie einen Doppelklick auf Authentifizierung aus. Markieren Sie in der folgenden Liste den Eintrag Standardauthentifizierung, und benutzen Sie im Bereich Aktionen die Optionen Aktivieren, Deaktivieren und Bearbeiten, um diese Art der Authenti-fizierung zu konfigurieren.

Sie können die Authentifizierungskonfiguration auch direkt bearbeiten. Benutzen Sie das Befehls-zeilenhilfsmittel Appcmd.exe oder die Konfigurations-APIs, um den Abschnitt system.webServer/security/basicAuthentication zu konfigurieren. Appcmd bietet dazu die folgende Syntax an.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/basicAuthentication [/enabled:bool] [/realm:string] [/defaultLogonDomain:string] [/logonMethod:enum]


Tabelle 14.11 Parameter für die direkte Konfiguration der Standardauthentifizierung



enabled Gibt an, ob die Standardauthentifizierung aktiviert oder deaktiviert werden soll

realm Der Standardauthentifizierungsbereich, der dem Client aus informatorischen Gründen mitgeteilt wird. Der Webserver verwendet diesen Bereich während der Anmeldung nicht.

defaultLogonDomain Die Domäne, die vom Server für die Anmeldung unter Verwendung der vom Client zur Verfügung gestell-ten Anmeldeinformationen benutzt wird. Wenn der vom Client übermittelte Benutzername die Domäne angibt, wird diese verwendet. Erfolgt keine Angabe, wird die Computerdomäne verwendet. Der Vorgabe-wert ist "".

logonMethod Das für die Anmeldung zu verwendende Anmeldeverfahren. Zulässige Werte sind Interactive, Batch, Network und ClearText. Der Vorgabewert ist ClearText. Weitere Informationen zu Anmeldetypen erhalten Sie unter http://msdn2.microsoft.com/en-us/library/aa378184.aspx.



DigestauthentifizierungDas Feature Digestauthentifizierung implementiert das Digestauthentifizierungsprotokoll, ein HTTP-Authentifizierungsstandardschema, das in RFC 2617 definiert ist und von einem Teil der HTTP-Client-software unterstützt wird. Im Gegensatz zur Standardauthentifizierung sendet der Client ein aus dem Benutzernamen und Kennwort bestehendes MD5-Hash zum Server, so dass die Anmeldeinformationen nicht in Form von Klartext über das Netzwerk übermittelt werden. Das Digestauthentifizierungsschema von IIS 7.0 war unter IIS 6.0 als erweiterte Digestauthentifizierung bekannt (IIS 7.0 unterstützt die IIS 6.0-Digestauthentifizierung nicht mehr). Die Digestauthentifizierung authentifiziert eine Anforderung mit einem Windows-Token, das dem Active Directory-Konto des Benutzers entspricht (sofern die Authentifizierung erfolgreich war).

Hinweis Die Digestauthentifizierung ist nicht Teil der IIS-Standardinstallation. Sie können sie unter Windows Vista mithilfe der Option Windows-Funktionen ein- oder ausschalten über die Kategorie Sicherheit manuell installieren. Und Sie können sie unter Windows Server 2008 mithilfe des Server-Managers über die Webserverrollenkategorie Sicher-heit installieren. Das zwölfte Kapitel enthält weitere Informationen zur Installation und Aktivierung von Modulen.

Die Digestauthentifizierung ist wie die Standardauthentifizierung ein problemorientiertes Authentifi-zierungsschema. Wenn die Digestauthentifizierung aktiviert ist und die erste Anforderung eines Clients auf eine Ressource abzielt, für die eine Authentifizierung erforderlich ist, wird die Anforderung mit dem Statuscodes 401 (nicht autorisiert) und dem Antwortheader WWW-Authenticate: digest zurück-gewiesen. Der Header enthält außerdem weitere vom Digestauthentifizierungsschema benötigte Informationen. Wenn der Client die Digestauthentifizierung unterstützt, wird der Benutzer gewöhnlich dazu aufgefordert, die Anmeldeinformationen einzugeben. Danach wird die Anforderung mit dem Anmeldeinformationshash und den einstweiligen Anfrageinformationen erneut an den Webserver übermittelt. Das Modul für die Digestauthentifizierung stellt dann fest, dass diese Anforderung über ein Anmeldeinformationshash verfügt, und es versucht, das Hash zu authentifizieren, indem es dieses mit dem in Active Directory gespeicherten Hash vergleicht. Der Client sendet das Hash in der Regel zusammen mit jeder folgenden Anforderung, die sich auf denselben URL oder auf einen URL bezieht, der sich unterhalb des in der ursprünglich authentifizierten Anforderung enthaltenen URLs befindet.

Der Webserver und die darauf zugreifenden Clients müssen die folgenden Anforderungen erfüllen, damit die IIS 7.0-Digestauthentifizierung verwendet werden kann:

� Sowohl der Webserver als auch die Clients, die mit Ihrer Anwendung arbeiten, müssen Mitglieder derselben Domäne sein, oder der Client muss Mitglied einer Domäne sein, der der Webserver vertraut.

� Die Clients müssen den Microsoft Internet Explorer 5 oder eine neuere Version verwenden.

� Ein Benutzer muss über ein gültiges Windows-Benutzerkonto verfügen, das auf dem Domänen-controller im Active Directory-System gespeichert ist.

� Der Domänencontroller muss mit Windows Server 2003 oder Windows Server 2008 arbeiten.

Im Gegensatz zur IIS 6.0-Digestauthentifizierung verlangt die IIS 7.0-Digestauthentifizierung keine Anwendungspoolidentität, die auf LocalSystem gesetzt ist. Sie sollten auf dem Server sogar ganz auf LocalSystem oder eine andere Identität mit administrativen Rechten als Anwendungspoolidentität verzichten. Weitere Informationen zur Konfiguration von geringstmöglichen Berechtigungen für Anwendungspools finden Sie früher in diesem Kapitel im Abschnitt »Anwendungen für die Nutzung von geringstmöglichen Berechtigungen konfigurieren«.



Vorsicht Das bloße Aktivieren der Digestauthentifizierung bedeutet nicht, dass für Ihre Anwendung eine Authenti-fizierung notwendig ist. Sie müssen die anonyme Authentifizierung entweder deaktivieren und/oder URL-Autorisie-rungsregeln oder NTFS-Berechtigungen konfigurieren, die den Zugriff für den anonymen Benutzer verweigern.

Das authentifizierte Token ist nicht wie bei der Standardauthentifizierung für den Zugriff auf Remote-ressourcen geeignet. Damit ein solcher Zugriff möglich ist, muss die eingeschränkte Delegierung oder der Protokollübergang konfiguriert werden. Weitere Informationen finden Sie später in diesem Kapitel im Abschnitt »Die Authentifizierungsdelegierung verstehen«.

Sie können den IIS-Manager verwenden, um die Digestauthentifizierung zu aktivieren oder zu deakti-vieren. Markieren Sie im Hierarchielistenfeld den gewünschten Knoten, und führen Sie einen Doppel-klick auf Authentifizierung aus. Markieren Sie in der folgenden Liste den Eintrag Digestauthentifi-zierung, und benutzen Sie im Bereich Aktionen die Optionen Aktivieren, Deaktivieren und Bearbeiten, um diese Art der Authentifizierung zu konfigurieren.

Sie können die Digestauthentifizierungskonfiguration auch direkt bearbeiten. Benutzen Sie das Befehls-zeilenhilfsmittel Appcmd.exe oder die Konfigurations-APIs, um den Abschnitt system.webServer/security/digestAuthentication zu konfigurieren. Appcmd bietet dazu die folgende Syntax an.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/digestAuthentication [/enabled:bool] [/realm:string]


Windows-AuthentifizierungDas Windows-Authentifizierungsschema ermöglicht die Authentifizierung von Windows-Clients mit zwei Windows-Authentifizierungsprotokollen, NTLM (NT LAN Manager) und Kerberos. Beide Schemata sehen für die Authentifizierung des Clients einen verschlüsselten Datenaustausch zwischen dem Client und dem Server vor.

Hinweis Die Digestauthentifizierung ist nicht wie bei Windows Server 2003 Teil der IIS-Standardinstallation, und sie ist auch nicht standardmäßig aktiviert. Sie können sie unter Windows Vista mithilfe der Option Windows-Funk-tionen ein- oder ausschalten über die Kategorie Sicherheit manuell installieren. Und Sie können sie unter Windows Server 2008 mithilfe des Server-Managers über die Webserverrollenkategorie Sicherheit installieren. Das zwölfte Kapitel enthält weitere Informationen zur Installation und Aktivierung von Modulen. Nachdem das Modul installiert wurde, müssen Sie die Windows-Authentifizierung explizit aktivieren, damit diese verfügbar ist.

Tabelle 14.12 Parameter für die Konfiguration der Digestauthentifizierung


ConfigurationPath Der Konfigurationspfad, für den diese Konfiguration gesetzt werden soll. Wenn Sie diesen Parameter ange-ben, müssen Sie ebenfalls den Parameter /commit:apphost benutzen, um für den Fall, dass die Konfigura-tion auf die Website- oder URL-Ebene angewendet wird, Fehler aufgrund von Sperrungen zu vermeiden.

enabled Gibt an, ob die Digestauthentifizierung aktiviert oder deaktiviert werden soll

realm Der Digestauthentifizierungsbereich, der, wie in RFC 2617 angegeben, verwendet wird



Die Windows-Authentifizierung ist wie andere IIS-Authentifizierungsverfahren ein anfragebasiertes Authentifizierungsschema. Wenn eine Anforderung mit dem Statuscode 401 (nicht autorisiert) zurückgewiesen wird, übermittelt die Windows-Authentifizierung einen WWW-Authenticate-Anfrage-header, der einen der beiden folgenden Authentifizierungsschemanamen enthält:

� NTLM Gibt dem Client zu verstehen, dass er das NTLM-Authentifizierungsprotokoll für die Authentifizierung verwenden kann. Dies ist für ältere Clients gedacht, die den Negotiate-Wrapper nicht unterstützen.

� Negotiate Gibt dem Client zu verstehen, dass er das Kerberos- oder NTLM-Protokoll für die Authentifizierung verwenden kann. Negotiate wird verwendet, um abhängig davon, wozu der Client in der Lage ist, die Kerberos- oder NTLM-Authentifizierung zuzulassen.

Hinweis Sowohl die Kerberos- als auch die NTLM-Authentifizierung bedingen, dass der Client im Rahmen des Authentifizierungshandshakes mehrere an den Server gerichtete Anforderungen (in der Regel zwei oder drei) initiiert. Dies bedeutet, dass Ihre Module mit mehreren Anforderungen konfrontiert werden, die Teil des Authenti-fizierungsprozesses sind. Eine Authentifizierung erfolgt jedoch nur einmal pro Verbindung und nicht für alle Anforderungen, die über dieselbe Verbindung eingehen.

Der Client entscheidet sich dann entweder für Kerberos (sofern verfügbar) oder NTLM und initiiert eine Sequenz von Anforderungen, um die Authentifizierung mithilfe des ausgewählten Protokolls durchzuführen. Die Auswahl des Protokolls ist davon abhängig, ob der Client so konfiguriert ist, dass er in Zusammenarbeit mit dem Server über Kerberos authentifiziert werden kann. Dazu ist eine direkte Verbindung zum Schlüsselverteilungscenter (Key Distribution Center, KDC) des Domänencontrollers und ein direkter Zugriff auf Active Directory erforderlich. NTLM kann in einer Umgebung ohne Domäne für lokale Windows-Konten des Servers oder für den Fall verwendet werden, dass keine Verbindung zu den für Kerberos benötigten Domänendiensten verfügbar ist.

Hinweis Die Windows-Authentifizierung ist besonders für Intranetumgebungen geeignet.

Die Windows-Authentifizierung ist für auf Windows basierende Intranetumgebungen eine vernünftige Wahl. Soll sie für andere Umgebungen genutzt werden, sollten Sie die folgenden Einschränkungen berücksichtigen:

� Sie funktioniert nicht in Verbindung mit HTTP-Proxies. Der Grund hierfür besteht darin, dass Kerberos und NTLM verbindungsbasiert sind, und Proxies halten Verbindungen nicht immer geöffnet oder sorgen dafür, dass Verbindungen von den Anforderungen verschiedener Clients gemeinsam genutzt werden.

� Das Kerberos-Protokoll verlangt, dass sowohl der Client als auch der Server Mitglieder derselben Domäne oder von zwei Domänen mit einem Vertrauensverhältnis sind und direkt auf Active Directory und die KDC-Dienste des Domänencontrollers zugreifen können.

� Das Kerberos-Protokoll verlangt, dass alle Anwendungspools, die eine Kerberos-Authentifizierung durchführen, mit einem Dienstprinzipalnamen (Service Principal Name, SPN) bei Active Directory registriert werden.



Die Windows-Authentifizierung konfigurierenSie können die Windows-Authentifizierung mit dem IIS-Manager aktivieren oder deaktivieren. Markieren Sie im Hierarchielistenfeld den gewünschten Knoten, und führen Sie einen Doppelklick auf Authentifizierung aus. Markieren Sie in der Liste den Eintrag Windows-Authentifizierung, und benutzen Sie im Bereich Aktionen die Optionen Aktivieren, Deaktivieren oder Bearbeiten, um diese Art der Authentifizierung zu konfigurieren.

Sie können die Windows-Authentifizierungskonfiguration auch direkt bearbeiten. Benutzen Sie das Befehlszeilentool Appcmd.exe oder die Konfigurations-APIs, um den Abschnitt system.webServer/security/windowsAuthentication zu konfigurieren. Appcmd bietet dazu die folgende Syntax an.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/windowsAuthentication [/enabled:bool] [/authPersistSingleRequest:bool] [/authPersistNonNTLM:bool] [/useKernelMode:bool] [/useAppPoolCredentials:bool]


Darüber hinaus können Sie festlegen, ob der Server das NTLM- oder Negotiate-Protokoll verwenden soll. Dazu bearbeiten Sie die providers-Auflistung im Konfigurationsabschnitt system.webServer/security/windows-Authentication. Diese Auflistung enthält standardmäßig sowohl den NTLM- als auch den Negotiate-Proto-kollanbieter. Sie können den Server veranlassen, nur mit NTLM zu arbeiten, indem Sie den Negotiate-Protokollanbieter entfernen. Sie können mithilfe dieser Konfiguration jedoch nicht dafür sorgen, dass der Server nur Kerberos verwendet, da der Negotiate-Wrapper es dem Client ermöglicht, entweder NTLM oder Kerberos zu benutzen. Sie können dem Client nicht mitteilen, dass nur Kerberos unterstützt wird.

Tabelle 14.13 Parameter für die Konfiguration der Windows-Authentifizierung



enabled Gibt an, ob die Windows-Authentifizierung aktiviert oder deaktiviert werden soll

authPersistSingleRequest Gibt an, ob jede Anforderung erneut authentifiziert werden muss. Ist die Einstellung auf false gesetzt, führt der Client den Authentifizierungshandshake nur einmal pro Verbindung durch, und der Server speichert die authentifizierte Identität für alle nachfolgenden Anforderungen im Cache. Andernfalls sind für alle Anforderungen Authentifizierungshandshakes erforderlich. Der Standard ist false.

authPersistNonNTLM Gibt an, ob jede Anforderung erneut authentifiziert werden muss, wenn Kerberos verwendet wird. Ist die Einstellung auf false gesetzt, führt der Client den Authentifizierungshandshake nur einmal pro Verbindung durch, und der Server speichert die authentifizierte Identität für alle nachfolgenden Anforderungen im Cache. Andernfalls sind für alle Anforderungen Authentifizierungshandshakes erforderlich. Der Standard ist false.

useKernelMode Gibt an, ob die Windows-Authentifizierung im Kernel durchgeführt werden soll. Der Standard ist true.

useAppPoolCredentials Gibt an, ob anstelle von LocalSystem die Anwendungspoolidentität zur Durchführung der Windows-Authentifizierung im Kernel verwendet werden soll. Dies ist notwendig, wenn Sie ein Domänenkonto als Anwendungspoolidentität benutzen, um die Kerberos-Authentifizierung in einer Webfarm durch-zuführen. Der Standard ist false.



Sie können jedoch die NTLM-Authentifizierungsebene konfigurieren, indem Sie die Konsole Lokale Sicherheitsrichtlinie benutzen und die Option Sicherheitseinstellungen\Lokale Richtlinien\Sicherheits-optionen\Netzwerksicherheit: LAN-Manager-Authentifizierungsebene bearbeiten, wie in Abbildung 14.7 dargestellt. Die Standardeinstellung ist Nur NTLMv2-Antworten senden, die es dem Server ermög-licht, alle Ebenen zu akzeptieren. Sie können diese Einstellung auf Nur NTLMv2-Antworten senden. LM & NTLM verweigern setzen, um eine maximale Sicherheit zu erzielen. Clients, die nicht über die Möglichkeit verfügen, mit Kerberos zu arbeiten, können dann das NTLMv2-Schema verwenden.

Abbildung 14.7 Die NTLM-Authentifizierungsebene konfigurieren

Um bei IIS 6.0 das Kerberos-Authentifizierungsprotokoll verwenden zu können, müssen Sie mit dem Befehlszeilentool Setspn.exe arbeiten, das im Active Directory-System für alle Anwendungspoolkonten Dienstprinzipalnamen für die NetBIOS-Namen und die vollqualifizierten Domänennamen registriert. Darüber hinaus kann nur ein Anwendungspoolkonto pro Dienstprinzipalname registriert werden, wo-durch verhindert wird, dass mehrere Anwendungspools mit unterschiedlichen Identitäten die Kerberos-Authentifizierung nutzen.

Bei IIS 7.0 bietet die kernelbasierte Windows-Authentifizierung (die standardmäßig aktiviert ist) eine verbesserte Funktionalität. Da HTTP.sys den Authentifizierungsvorgang im Kernel durchführt, geschieht dies unter der LocalSystem-Identität, und zwar unabhängig von der Anwendungspooliden-tität. Dies führt zu den folgenden Verbesserungen:

� Es ist nicht mehr notwendig, separate Dienstprinzipalnamen zu konfigurieren, weil Kerberos den Standardeintrag für den NetBIOS-Dienstprinzipalnamen automatisch verwendet, wenn der Web-servercomputer mit der Domäne verbunden wird.



� Die Anwendungspoolidentität kann geändert werden, ohne den Dienstprinzipalnamen für das neue Konto erneut registrieren zu müssen. Das Anwendungspoolkonto muss nicht mehr ein Domänen-konto sein.

� Mehrere Anwendungspools können die Kerberos-Authentifizierung verwenden.

Diese Änderungen tragen dazu bei, dass die Bereitstellung und Verwendung des Kerberos-Protokolls mit IIS sehr einfach ist.

Hinweis Sie müssten die Anwendungspoolidentität verwenden und Dienstprinzipalnamen für die Kerberos-Authentifizierung registrieren, wenn Sie diese in einer Webfarm nutzen.

Wenn Sie jedoch in einer Webfarm mit IIS arbeiten und das Kerberos-Protokoll benötigen, müssen Sie die Verwendung der LocalSystem-Identität für die Kerberos-Authentifizierung deaktivieren, indem Sie im Konfigurationsabschnitt system.webServer/security/authentication/windowsAuthentication das useAppPoolCredentials- Attribut auf true setzen. Darüber hinaus müssen Sie ein Domänenkonto als Identität für den Anwendungs-pool benutzen. Sie müssen weiterhin mit Setspn.exe arbeiten, um den Websitehostnamen zu registrieren. Dazu verwenden Sie das Domänenkonto, für das die Anwendungspools konfiguriert sind, um im Active Directory-System ausgeführt zu werden. Weitere Informationen zur Registrierung von Dienstprinzipal-namen für Kerberos mit Setspn.exe finden Sie unter http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true.

Authentifizierung über ClientzertifikatzuordnungenDie Authentifizierung über Clientzertifikatzuordnungen ermöglicht die Authentifizierung von Clients, indem Clientzertifikate über SSL-Verbindungen (Secure Sockets Layer) präsentiert werden.

Hinweis Mithilfe der zertifikatbasierten Authentifizierung können Clients Clientzertifikate benutzen, um auf dem Webserver authentifiziert zu werden. Hierfür ist eine sichere Kommunikation zwischen Client und Server nicht notwendig.

Die Authentifizierung über Clientzertifikatzuordnungen greift innerhalb des Active Directory-Systems auf die Verzeichnisdienstzuordnung (Directory Services Mapper, DS Mapper) zurück, um die von den Benutzern zur Verfügung gestellten Clientzertifikate Domänenkonten zuzuordnen. IIS bietet außerdem ein benutzerdefiniertes Zertifikatzuordnungsfeature an (die Authentifizierung über IIS-Clientzertifikat-zuordnungen), die eine flexiblere Zuordnung von Clientzertifikaten zu Windows-Konten ermöglicht. Lesen Sie später in diesem Kapitel den Abschnitt »Authentifizierung über IIS-Clientzertifikatzuordnungen«, um weitere Informationen zu erhalten.

Hinweis Die Authentifizierung über Clientzertifikatzuordnungen ist kein Teil der IIS-Standardinstallation, und sie ist auch nicht standardmäßig aktiviert. Sie können sie unter Windows Vista mithilfe der Option Windows-Funktionen ein- oder ausschalten über die Kategorie Sicherheit manuell installieren. Und Sie können sie unter Windows Server 2008 mithilfe des Server-Managers über die Webserverrollenkategorie Sicherheit installieren. Das zwölfte Kapitel enthält weitere Informationen zur Installation und Aktivierung von Modulen. Nachdem das Modul installiert wurde, müssen Sie die Authentifizierung über Clientzertifikatzuordnungen explizit aktivieren, damit sie verfügbar ist.



Um mit der Authentifizierung über Clientzertifikatzuordnungen arbeiten zu können, müssen die folgenden Anforderungen erfüllt sein:

� Der Webserver muss Mitglied einer Windows-Domäne sein.

� Sie müssen mithilfe einer für den Webserver vertrauenswürdigen Zertifizierungsstelle Client-zertifikate an Ihre Benutzer ausgeben.

� Sie müssen innerhalb des Active Directory-Systems jedes Clientzertifikat einem gültigen Domänenkonto zuordnen.

Hinweis Sie müssen die Authentifizierung über Clientzertifikatzuordnungen nicht benutzen, damit die Clients ihre Clientzertifikate präsentieren. Sie können den Server auch so konfigurieren, dass immer Clientzertifikate für den Zugriff auf den Server verlangt werden, aber ein anderes Authentifizierungsschema verwendet wird, um die Clients zu authentifizieren. Lesen Sie dazu später in diesem Kapitel den Abschnitt »Clientzertifikate«.

Um auf dem Webserver die Authentifizierung über Clientzertifikatzuordnungen zu aktivieren, gehen Sie wie folgt vor (das Modul für die Authentifizierung über Zertifikatzuordnungen muss jedoch bereits installiert sein).

1. Aktivieren Sie die Authentifizierung über Clientzertifikatzuordnungen. Dies ist im IIS-Mana-ger möglich, indem Sie den Serverknoten markieren, einen Doppelklick auf Authentifizierung ausführen, Active Directory-Clientzertifikatauthentifizierung markieren und im Bereich Aktionen auf Aktivieren klicken. Beachten Sie, dass dies mit dem IIS-Manager nur auf der Serverebene mög-lich ist, obwohl Sie in der Konfiguration die Authentifizierung über Clientzertifikatzuordnungen für einen bestimmten URL aktivieren können.

2. Konfigurieren Sie SSL für jede Website, die dieses Authentifizierungsverfahren nutzen soll. Die Zertifikatauthentifizierung ist nur dann möglich, wenn über eine SSL-Verbindung auf die Web-site zugegriffen wird. Deshalb muss für die gewünschte Website eine SSL-Bindung konfiguriert werden. Lesen Sie später in diesem Kapitel den Abschnitt »SSL konfigurieren«, um weitere Infor-mationen zu erhalten.

3. Aktivieren Sie für jede Website, die eine SSL-Bindung verwendet, die Verzeichnisdienstzuord-nung. Der IIS-Manager sorgt automatisch hierfür, wenn die Authentifizierung über Clientzertifikat-zuordnungen aktiviert ist und Sie einer Website eine SSL-Bindung hinzufügen. Manuell ist dies eben-falls möglich. Benutzen Sie dazu den Befehl Netsh.exe mit der folgenden Syntax: netsh http add sslcert IP Address:Port dsmapperusage=enable, wobei IP Adress und Port die IP-Adresse und den Port der entspre-chenden Bindung angeben.

4. Konfigurieren Sie jede Website, die dieses Authentifizierungsverfahren verwenden soll so, dass sie Clientzertifikate akzeptiert (und möglicherweise auch verlangt). Dies gewährleistet, dass der Server Clientzertifikate akzeptiert, wenn diese vom Client zur Verfügung gestellt werden. Außerdem kann der Server so konfiguriert werden, dass er vom Client die Vorlage eines Zertifikats verlangt, damit die Verarbeitung fortgesetzt wird. Lesen Sie später in diesem Kapitel den Abschnitt »Clientzertifikate«, um weitere Informationen zu erhalten.

Sie können die Authentifizierung über Clientzertifikatzuordnungen auch direkt bearbeiten. Benutzen Sie das Befehlszeilentool Appcmd.exe oder die Konfigurations-APIs, um den Abschnitt system.webServer/security/authentication/clientCertificateMappingAuthentication zu konfigurieren. Sie können dieses Authentifi-zierungsverfahren mit der folgenden Appcmd-Syntax aktivieren.



%systemroot%\system32\inetsrv\Appcmd set config /section: system.webServer/security/authentication/ clientCertificateMappingAuthentication /enabled:true

Das Attribut enabled gibt an, ob die Authentifizierung über Clientzertifikatzuordnungen aktiviert ist. Sie können dieses Verfahren für einen bestimmten URL aktivieren. Beachten Sie jedoch, dass die Entscheidung, Zertifikate mithilfe der Verzeichnisdienstzuordnung Windows-Domänenkonten zuzuordnen, davon abhängig ist, dass jede Websitebindung so konfiguriert wurde, dass sie die Verzeichnisdienstzuordnungseinstellung in HTTP.sys verwendet.

Sie erfahren später in diesem Kapitel mehr über die SSL-Konfiguration und darüber, wie Sie den Server konfigurieren, damit dieser Clientzertifikate akzeptiert. Dies ist im Abschnitt »Clientzertifikate« beschrieben.

Authentifizierung über IIS-ClientzertifikatzuordnungenDie Authentifizierung über IIS-Clientzertifikatzuordnungen ermöglicht auf dem Webserver die Authentifizierung von Clients, indem Clientzertifikate über SSL-Verbindungen (Secure Sockets Layer) präsentiert werden.

Hinweis Mithilfe der zertifikatbasierten Authentifizierung können Clients Clientzertifikate benutzen, um auf dem Webserver authentifiziert zu werden. Hierfür ist eine sichere Kommunikation zwischen Client und Server nicht notwendig.

Die Authentifizierung über IIS-Clientzertifikatzuordnungen ist ein weitaus flexiblerer Mechanismus für die auf Clientzertifikaten basierende Authentifizierung, als die Authentifizierung über die auf Active Directory basierenden Clientzertifikate. Sie ist nicht auf die Verzeichnisdienstzuordnung (DS Mapper) angewiesen, um Clientzertifikate Windows-Konten zuzuordnen. Stattdessen verwendet sie die Konfi-guration, um diese Zuordnung durchzuführen. Demgemäß müssen die Benutzerkonten auch keine Domänenkonten sein, und Active Directory ist ebenfalls nicht erforderlich, um diese Art der Authentifizierung nutzen zu können.

Hinweis Die Authentifizierung über IIS-Clientzertifikatzuordnungen ist kein Teil der IIS-Standardinstallation, und sie ist auch nicht standardmäßig aktiviert. Sie können sie unter Windows Vista mithilfe der Option Windows-Funktionen ein- oder ausschalten über die Kategorie Sicherheit manuell installieren. Und Sie können sie unter Windows Server 2008 mithilfe des Server-Managers über die Webserverrollenkategorie Sicherheit installieren. Das zwölfte Kapitel enthält weitere Informationen zur Installation und Aktivierung von Modulen. Nachdem das Modul installiert wurde, müs-sen Sie die Authentifizierung über IIS-Clientzertifikatzuordnungen explizit aktivieren, damit sie verfügbar ist.

Das Feature Authentifizierung über IIS-Clientzertifikatzuordnung unterstützt die folgenden Zuordnungs-typen:

� 1:1-Zuordnung Ordnet einem bestimmten Windows-Konto ein einzelnes Clientzertifikat zu. Der Server verwendet eine exakte Kopie des Clientzertifikats, um nach Übereinstimmungen zu suchen. Deshalb muss er Kopien von allen Clientzertifikaten besitzen.

� n:1-Zuordnung Ordnet einem Windows-Konto Clientzertifikate zu, wenn sich Übereinstimmungen aufgrund von Platzhalterausdrücken ergeben, in denen bestimmte Felder angegeben werden, z.B. der Aussteller oder der Antragsteller. Eine Kopie des Zeritifkats ist hierfür nicht erforderlich.



Um mit der Authentifizierung über IIS-Clientzertifikatzuordnungen arbeiten zu können, müssen die folgenden Anforderungen erfüllt sein:

� Sie dürfen bei Sites, für die Sie die Authentifizierung über IIS-Clientzertifikatzuordnungen aktiviert haben, keine Authentifizierung über auf Active Directory basierende Clientzertifikate verwenden.

� Sie müssen die Kennwörter aller Windows-Konten kennen, denen Zertifikate zugeordnet werden sollen. Im Gegensatz zur Authentifizierung über Clientzertifikatzuordnungen, die auf Active Directory angewiesen ist, um Windows-Tokens für die Konten zu generieren, müssen Sie bei der Authentifizierung über IIS-Clientzertifikatzuordnungen sowohl den Benutzernamen als auch das Kennwort für jedes zuzuordnende Konto angeben, so dass IIS das Token generieren kann.

� Um mit der 1:1-Zuordnung arbeiten zu können, müssen Sie eine exakte Kopie des Clientzertifikats besitzen, das zugeordnet werden soll. Wenn Sie dafür verantwortlich sind, Benutzern Zertifikate auszustellen, besitzen Sie diese Kopien. Andernfalls müssen Sie die Benutzer bitten, Ihnen eine exportierte Kopie des Zertifikats zukommen zu lassen. Wenn Sie mit n:1-Zuordnungen arbeiten, benötigen Sie keine Zertifikatkopien.

Hinweis Sie müssen die Authentifizierung über IIS-Clientzertifikatzuordnungen nicht benutzen, damit die Clients ihre Clientzertifikate präsentieren. Sie können den Server auch so konfigurieren, dass immer Clientzertifikate für den Zugriff auf den Server verlangt werden, aber ein anderes Authentifizierungsschema verwendet wird, um die Clients zu authentifizieren. Lesen Sie dazu später in diesem Kapitel den Abschnitt »Clientzertifikate«.

Um die Authentifizierung über IIS-Clientzertifikatzuordnungen für eine bestimmte Website oder einen URL zu aktivieren, gehen Sie wie folgt vor (das Modul für die Authentifizierung über IIS-Zertifikat-zuordnungen muss bereits installiert sein).

1. Aktivieren Sie die Authentifizierung über IIS-Clientzertifikatzuordnungen. Dies ist mit dem IIS-Manager nicht möglich. Sie müssen hierzu den Abschnitt system.webServer/security/authentication/iisClientCertificateMappingAuthentication direkt bearbeiten. Alternativ dazu können Sie das Befehls-zeilentool Appcmd.exe oder die Konfigurations-APIs verwenden. Sie können die Authentifizierung über IIS-Clientzertifikatzuordnungen mit der folgenden Appcmd-Syntax aktivieren (genaue Infor-mationen zu dieser Konfiguration finden Sie später in diesem Abschnitt).%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/authentication/ iisClientCertificateMappingAuthentication /enabled:true /commit:apphost

2. Konfigurieren Sie SSL für jede Website, die dieses Authentifizierungsverfahren nutzen soll. Die Zertifikatauthentifizierung ist nur dann möglich, wenn über eine SSL-Verbindung auf die Web-site zugegriffen wird. Deshalb muss für die gewünschte Website eine SSL-Bindung konfiguriert werden. Lesen Sie später in diesem Kapitel den Abschnitt »SSL konfigurieren«, um weitere Infor-mationen zu erhalten.

3. Konfigurieren Sie jede Website, die dieses Authentifizierungsverfahren verwenden soll so, dass sie Clientzertifikate akzeptiert (und möglicherweise auch verlangt). Dies gewährleistet, dass der Server Clientzertifikate akzeptiert, wenn diese vom Client zur Verfügung gestellt werden. Außerdem kann der Server so konfiguriert werden, dass er vom Client die Vorlage eines Zertifikats verlangt, damit die Verarbeitung fortgesetzt wird. Lesen Sie später in diesem Kapitel den Abschnitt »Clientzertifikate«, um weitere Informationen zu erhalten.

4. Konfigurieren Sie die erforderlichen 1:1- oder n:1-Zuordnungen. Erstellen Sie die Zuordnungen, um Windows-Konten Zertifikate zuzuordnen.



Hinweis Obwohl Sie das Feature Authentifizierung über IIS-Clientzertifikatzuordnung für einen bestimmten URL aktivieren können, kann die Zuordnungskonfiguration nur auf der Server- oder Websiteebene festgelegt werden. Sie wird ignoriert, wenn sie auf einer niedrigeren Ebene konfiguriert wird.

Sie erfahren später in diesem Kapitel mehr über die SSL-Konfiguration und darüber, wie Sie den Server konfigurieren, damit dieser Clientzertifikate akzeptiert. Dies ist im Abschnitt »Clientzertifikate« beschrie-ben. Das Konfigurieren von Zertifikatzuordnungen für die Authentifizierung über IIS-Clientzertifikat-zuordnungen wird in den folgenden Abschnitten »1:1-Zertifikatzuordnung erstellen« und »n:1-Zertifikat-zuordnungen erstellen« erläutert.

1:1-Zertifikatzuordnung erstellenSie können 1:1-Zertifikatzuordnungen als Teil eines strengen Authentifizierungs- und Autorisierungs-schemas verwenden, um den Zugriff auf Anwendungsressourcen abhängig von der genauen Identität des Clients zu steuern. Dieses Schema kann anstelle eines auf dem Benutzernamen und Kennwort basierenden Authentifizierungsschemas verwendet werden, bei dem der Benutzer die Anmeldeinfor-mationen angeben müsste. Um mit 1:1-Zuordnungen arbeiten zu können, müssen Sie über exakte Kopien aller Zertifikate verfügen.

Der IIS-Manager unterstützt die Konfiguration von 1:1-Zuordnungen nicht. Sie können sie mit dem Befehlszeilentool Appcmd konfigurieren. Alternativ hierzu können Sie den Konfigurationsabschnitt system.webServer/security/authentication/iisClientCertificateMappingAuthentication direkt oder mithilfe von Konfigurations-APIs bearbeiten. Sie können eine 1:1-Zuordnung mit der folgenden Appcmd-Syntax hinzufügen.%systemroot%\system32\inetsrv\Appcmd set config [SiteName] /section:system.webServer/security/authentication/ iisClientCertificateMappingAuthentication /+oneToOneMappings [certificate='string',enabled='bool',username='string',password='string']

Sie können eine 1:1-Zuordnung mit der folgenden Appcmd-Syntax entfernen.%systemroot%\system32\inetsrv\Appcmd set config [SiteName] /section:system.webServer/security/authentication /iisClientCertificateMappingAuthentication /-oneToOneMappings [certificate='string']

Diese Befehle verwenden die in Tabelle 14.14 aufgeführten Parameter.

Tabelle 14.14 Parameter zur Erstellung von Zertifikatzuordnungen


SiteName Der Sitename der Website, für die diese Einstellungen gesetzt werden sollen. Erfolgt keine Angabe, werden die Einstellungen für den gesamten Webserver gesetzt. Wenn Sie einen Konfigurationspfad angeben, der sich unterhalb des Websitestamms findet, haben diese Einstellungen keine Auswirkungen.

certificate Der exakte Zertifikatstext (nicht das Zertifikathash)

enabled Gibt an, dass diese Zuordnung aktiviert ist

userName Der Benutzername des Kontos, dem das Zertifikat zugeordnet ist

password Das Kennwort des Kontos, dem das Zertifikat zugeordnet ist. Dieser Wert wird in verschlüsselter Form gespeichert.



Sie können den genauen Text des Zertifikats aus einer exportierten Zertifikatdatei (die unverschlüsselte Zertifikatinformationen enthält) abrufen oder indem Sie das Zertifikat aus dem lokalen Zertifikat-speicher bzw. dem Zertifikatspeicher der Domäne auslesen. Letzteres ist mit dem folgenden Befehl möglich.certuil –encode –f CertName cert.cer

CertName ist der Anzeigename des Zertifikats. Sie können den Zertifikatspeicher einsehen und die Anzeige-namen der installierten Zertifikate abrufen. Benutzen Sie dazu den folgenden Befehl.certuil –viewstore StoreName

StoreName ist der Name des Zertifikatsspeichers. Benutzen Sie den Namen MY für den persönlichen Zertifikatspeicher.

Hinweis Sie müssen für die 1:1-Zuordnung die exakten Base64-codierten Inhalte des Zertifikats angeben, wobei der abschließende Zeilenvorschub entfernt werden muss. Benutzen Sie nicht das Zertifikathash. Wenn Sie das Zertifikat nicht richtig angeben und auf die Website bezogene Anforderungen initiieren, erhalten Sie den Status-fehler 404.1. Dieser Fehler zeigt die Information 0x8009310b HRESULT an, die Aufschluss darüber gibt, dass IIS das zum Zuordnungseintrag gehörende Zertifikat nicht laden konnte.

n:1-Zertifikatzuordnungen erstellenIm Gegensatz zu 1:1-Zuordnungen werden n:1-Zuordnungen in der Regel nicht verwendet, um einen ein-zelnen Benutzer zu authentifizieren. Stattdessen können Sie sie benutzen, um eine Gruppe von Benutzern zu authentifizieren, indem in deren Zertifikaten nach Übereinstimmungen mit bestimmten Feldern gesucht wird. Die gesamte Gruppe wird dann nur einem Windows-Konto zugeordnet. Deshalb ist eine Autorisie-rung, die darauf basiert, dass der authentifizierte Benutzer von einer n:1-Zuordnung generiert wird, ver-gleichbar mit der rollen- oder gruppenbasierten Autorisierung, bei der der authentifizierte Benutzer eine Gruppe repräsentiert, der mehrere Benutzer angehören. Sie könnten beispielsweise nach allen Zertifikaten suchen, die von einer bestimmten Organisation ausgestellt wurden. Die Benutzer, die den gefundenen Zertifikaten entsprächen, würden dann einem entsprechenden Organisationskonto zugeordnet. Aus diesem Grund können n:1-Zuordnungen für die benutzerbasierte Anpassung oder Zugriffsteuerung weniger ge-eignet sein, als 1:1-Zuordnungen. Dies ist davon abhängig, für welche Autorisierungsstrategie Sie sich entscheiden.

Hinweis 1:1-Zuordnungen werden immer vor n:1-Zuordnungen verarbeitet.

Bei n:1-Zuordnungen ist es nicht erforderlich, dass der Server über exakte Kopien der Benutzer-zertifikate verfügt. Stattdessen konfigurieren Sie einfach Platzhalterregeln, die auf den Zertifikatfeldern basieren, so dass alle Zertifikate, die übereinstimmende Feldinhalte aufweisen, einem Windows-Konto zugeordnet werden.

Mit dem IIS-Manager ist es nicht möglich, n:1-Zuordnungen zu konfigurieren. Sie können sie mit dem Befehlszeilentool Appcmd konfigurieren. Sie können außerdem den Konfigurationsabschnitt system.webServer/security/authentication/iisClientCertificateMappingAuthentication direkt oder mit anderen Konfi-gurations-APIs bearbeiten. Eine n:1-Zuordnung kann mit der folgenden Appcmd-Syntax hinzugefügt werden.%systemroot%\system32\inetsrv\Appcmd set config [SiteName] /section:system.webServer/security/authentication/ iisClientCertificateMappingAuthentication /+manyToOneMappings [name='string',enabled='bool',permissionMode='enum', username='string',password='string',description='string']



Sie können anschließend der Zuordnung weitere Suchkriterien hinzufügen, indem Sie die folgende Appcmd-Syntax verwenden, wobei der Name der Zuordnung angegeben werden muss, die mit dem vorherigen Befehl erstellt wurde.%systemroot%\system32\inetsrv\Appcmd set config [SiteName] /section:system.webServer/security/authentication/ iisClientCertificateMappingAuthentication /+manyToOneMappings [name='string'].rules.[certificateField='enum', certificateSubField='string',matchCriteria='string', compareCaseSensitive='bool']

Sie können eine Zuordnung mit der folgenden Appcmd-Syntax entfernen.%systemroot%\system32\inetsrv\Appcmd set config [SiteName] /section:system.webServer/security/authentication/ iisClientCertificateMappingAuthentication /-manyToOneMappings [name='string']

Diese Befehle verwenden die in Tabelle 14.15 beschriebenen Parameter.

UNC-AuthentifizierungDer Webserverkern verwendet die UNC-Authentifizierung, um eine Identität für den Zugriff auf Remote-anwendungsinhalte einzurichten, die sich in virtuellen Verzeichnissen befinden, die wiederum über eine UNC-Freigabe erreichbar sind. Es handelt sich hierbei um kein Authentifizierungsverfahren im eigent-lichen Sinne, weil es selbst kein Authentifizierungsschema für das Einrichten der Clientidentität verwen-det. Es ist vielmehr ein Verfahren zur Nutzung des authentifizierten Benutzers, der über andere Authentifi-

Tabelle 14.15 Parameter für die Erstellung von Zertifikatzuordnungen


SiteName Der Sitename der Website, für die diese Einstellungen gesetzt werden sollen. Erfolgt keine Angabe, werden die Einstellungen für den gesamten Webserver gesetzt. Wenn Sie einen Konfigurationspfad angeben, der sich unterhalb des Websitestamms findet, haben diese Einstellungen keine Auswirkungen.

name Der Name der Zuordnung; kann ebenfalls verwendet werden, um Regeln hinzuzufügen oder zu löschen.

enabled Gibt an, dass diese Zuordnung aktiviert ist

permissionMode Gibt an, ob dem Benutzer zu dieser Zuordnung der Zugriff gewährt oder verweigert wird

userName Der Benutzername des Kontos, dem das Zertifikat zugeordnet ist

password Das Kennwort des Kontos, dem das Zertifikat zugeordnet ist. Dieser Wert wird in verschlüsselter Form gespeichert.

description Eine für Menschen lesbare Beschreibung der Zuordnung

certificateField Das Zertifikatfeld, das in der aktuellen Regel verwendet wird, um nach Übereinstimmungen zu suchen. Übliche Felder sind der Aussteller und der Antragsteller. Um weitere Informationen zu erhalten, rufen Sie von der Zertifizierungsstelle die Details zum Inhalt des Zertifikats ab.

certificateSubField Das Zertifikatunterfeld, das in der aktuellen Regel verwendet wird, um nach Übereinstimmungen zu suchen. Um weitere Informationen über Unterfelder zu erhalten, rufen Sie von der Zertifizierungsstelle die Details zum Inhalt des Zertifikats ab.

matchCriteria Die Suchkriterien. Diese können die Platzhalterzeichen * und ? enthalten.

compareCaseSensitive Gibt an, ob die Groß-/Kleinschreibung berücksichtigt werden soll



zierungsmechanismen eingesetzt wurde – und in einigen Fällen ist es eine in der Konfiguration angege-bene feste Identität. Dieser Benutzer wird verwendet, um zu ermitteln, über welche Identität auf die Remoteinhalte zugegriffen werden soll.

IIS verwendet die UNC-Authentifizierung immer dann, wenn eine Anforderung initiiert wird, die sich auf eine Ressource in einem virtuellen Verzeichnis bezieht, dessen physikalischer Pfad über eine UNC-Freigabe erreichbar ist (unabhängig davon, ob sich die UNC-Freigabe auf dem lokalen Computer befindet oder nicht). Während der UNC-Authentifizierung ermittelt der Webserver wie folgt die Identität, die für den Zugriff auf die Remoteinhalte verwendet werden soll:

1. Die festen Anmeldeinformationen des virtuellen Verzeichnisses werden verwendet. Bei IIS 7.0 kann jedes virtuelle Verzeichnis feste Anmeldeinformationen angeben, die IIS für alle Zugriffe auf diesen Speicherort verwendet. Dies ersetzt die IIS 6.0-Eigenschaften UNCUserName und UNCPassword, die nur dann genutzt wurden, wenn ein virtuelles Verzeichnis eine UNC-Freigabe referenzierte.

2. Andernfalls wird der authentifizierte Benutzer verwendet, sofern verfügbar. Wenn das virtu-elle Verzeichnis keine festen Anmeldeinformationen festlegt, verwenden Sie den authentifizierten Benutzer, sofern dieser bereits mithilfe eines Authentifizierungsverfahrens ermittelt wurde. Dies wird als Pass-Through-Authentifizierung bezeichnet. Ein Zugriff auf web.config-Dateien ist damit nicht möglich, weil dieser erfolgt, bevor IIS den authentifizierten Benutzer ermittelt.

3. Andernfalls wird die Prozessidentität verwendet. Wenn IIS den authentifizierten Benutzer noch nicht ermittelt hat, verwendet es die Identität des IIS-Arbeitsprozesses. Der Webserver nutzt diese Option, um auf die web.config-Dateien zuzugreifen (wenn Anmeldeinformationen für virtuelle Verzeichnisse nicht konfiguriert sind), weil die Konfiguration vor der Authentifizierungs-phase gelesen wird.

Hinweis IIS 7.0 kann die Pass-Through-Authentifizierung nicht nutzen, um über eine Remote-UNC-Freigabe auf web.config-Dateien zuzugreifen. Deshalb muss das entsprechende virtuelle Verzeichnis feste Anmeldeinformatio-nen angeben, oder die Anwendungspoolidentität muss Leserechte für die Remote-UNC-Freigabe besitzen.

IIS kann standardmäßig nicht auf Remote-UNC-Inhalte zugreifen. Der Grund hierfür besteht darin, dass der anonyme Standardbenutzer IUSR ein lokales integriertes Konto ist, das über keine Netzwerk-berechtigungen verfügt. Da außerdem IIS über die IIS-Arbeitsprozessidentität auf web.config zugreifen muss, entsteht ein ähnliches Problem, weil das Konto NETZWERKDIENST in der Regel nicht über das Recht verfügt, auf Remoteressourcen zuzugreifen. Ihnen stehen deshalb zwei Möglichkeiten zur Ver-fügung, um die UNC-Authentifizierung für den Zugriff auf Remoteinhalte richtig zu konfigurieren:

� Benutzen Sie die Pass-Through-Authentifizierung Die Pass-Through-Authentifizierung bedingt, dass sowohl die Anwendungspoolidentität als auch alle zugelassenen authentifizierten Benutzer-identitäten auf eine Remote-UNC-Freigabe zugreifen können. Darüber hinaus bedingt sie den Einsatz eines Authentifizierungsschemas, mit dem es möglich ist, die Benutzeridentität an einen Remote-computer zu delegieren oder die eingeschränkte Delegierung und/oder den Protokollübergang zu konfigurieren, damit eine solche Delegierung auch für andere Authentifizierungsschemata möglich ist.

� Benutzen Sie feste Anmeldeinformationen für virtuelle Verzeichnisse Dies ist die empfohlene Vorgehensweise, weil Sie in diesem Fall einer einzelnen Identität den Zugriff auf die Freigabe explizit gewähren müssen. Außerdem muss nicht sichergestellt werden, dass das Authentifizierungsschema seine Identitäten an die Remote-UNC-Freigabe delegieren kann, weil immer die feste Identität für den Zugriff auf die Inhalte verwendet wird. Wenn jedoch feste Anmeldeinformationen genutzt werden, ist



die NTFS-Autorisierung und Überwachung von authentifizierten Benutzern, die auf die jeweilige Freigabe zugreifen, nicht möglich, da der Zugriff immer mithilfe der angegebenen Anmeldeinforma-tionen und nicht unter der Identität des authentifizierten Benutzers erfolgt. Weitere Informationen zum Einrichten fester Anmeldeinformationen für virtuelle Verzeichnisse finden Sie im neunten Kapitel unter dem Abschnitt »Remoteinhalte verwalten«.

Hinweis Es wird empfohlen, dass Sie mit festen Anmeldeinformationen arbeiten, um den Zugriff auf Remote UNC-Freigaben zu konfigurieren. Folgen Sie immer dieser Empfehlung, sofern Sie nicht hinsichtlich Ihrer authentifizierten Benutzer auf eine auf NTFS-ACLs basierende Zugriffsteuerung oder auf die Überwachung der Remoteinhalte angewiesen sind.

Wenn Sie sich für den Einsatz der Pass-Through-Authentifizierung entscheiden, müssen Sie wie folgt vorgehen:

1. Verwenden Sie eine benutzerdefinierte Anwendungspoolidentität, die auf die UNC-Freigabe zugreifen darf.

2. Wenn Sie mit der anonymen Authentifizierung arbeiten, konfigurieren Sie den anonymen Benutzer so, dass er die Anwendungspoolidentität verwendet. Konfigurieren Sie alternativ hierzu einen benutzerdefinierten anonymen Benutzer, der auf die UNC-Freigabe zugreifen darf.

3. Wenn Sie andere Authentifizierungsverfahren verwenden, die Windows-Identitäten generieren, stellen Sie sicher, dass diese Verfahren Identitäten an die UNC-Freigabe delegieren können. Stellen Sie anschließend sicher, dass alle authentifizierten Benutzer auf die UNC-Freigabe zugreifen können.

Weitere Informationen darüber, wie Sie gewährleisten, dass Ihr Authentifizierungsschema das Dele-gieren von authentifizierten Benutzeridentitäten an Remoteressourcen unterstützt, finden Sie im folgenden Abschnitt »Die Authentifizierungsdelegierung verstehen«.

Die Authentifizierungsdelegierung verstehenViele IIS-Authentifizierungsverfahren produzieren Windows-Identitäten, die im Rahmen eines Identitäts-wechsels für den Zugriff auf Ressourcen verwendet werden können. Wenn sich die Ressourcen, auf die der Zugriff erfolgt, auf einem Remotecomputer befinden, muss die authentifizierte Benutzeridentität zum Remotecomputer übermittelt werden, damit der dortige Remotedienst eine Authentifizierung durchführen kann. Dieser Vorgang wird als Delegierung bezeichnet. Er findet statt, wenn IIS versucht, über Remote-UNC-Freigaben auf Dateien zuzugreifen, oder wenn die Anwendung die authentifizierte Benutzer-identität annimmt, um eine Verbindung zu einem Remoteserver wie z.B. SQL Server herzustellen.

Die meisten IIS-Authentifizierungsverfahren erzeugen keine authentifizierten Identitäten, die für die Delegierung geeignet sind. Wenn IIS für die Nutzung solcher Authentifizierungsverfahren konfiguriert ist, bedeutet dies, dass IIS und die Anwendungen auf diese Remoteressourcen nicht zugreifen können, sofern sie eine derartige authentifizierte Identität annehmen.

Hinweis Sie können sich merken, welche Authentifizierungsverfahren delegiert werden können, indem Sie über-legen, welche Authentifizierungsverfahren ihre Anmeldung lokal auf dem Webserver durchführen. Alle Authentifi-zierungsschemata, bei denen der Benutzername und das Kennwort auf dem Webserver verfügbar sind – z.B. die Standardauthentifizierung, die Authentifizierung über IIS-Clientzertifikatzuordnungen oder die anonyme Authenti-fizierung – benutzen den Webserver für die Anmeldung und können somit die authentifizierten Identitäten delegieren.



Um zu gewährleisten, dass Ihre Anwendung auf Ressourcen zugreifen kann, die auf einem Remote-server gesichert sind, verfügen Sie über drei Möglichkeiten:

� Verwenden Sie ein Authentifizierungsverfahren, das die Delegierung unterstützt (siehe Tabelle 14.16).� Benutzen Sie feste Anmeldeinformationen für virtuelle Verzeichnisse, um eine Authentifizierungs-

identität zu erzeugen, die delegiert und deren Identität anstelle der authentifizierten Benutzeriden-tität angenommen werden kann. Weitere Informationen hierzu finden Sie früher in diesem Kapitel im Abschnitt »UNC-Authentifizierung«.

� Konfigurieren Sie die eingeschränkte Delegierung und den Protokollübergang, um die authentifi-zierte Identität heraufzustufen, so dass daraus eine delegierbare authentifizierte Identität wird, die das Kerberos-Protokoll nutzen kann.

Tabelle 14.16 beschreibt die integrierten IIS-Authentifizierungsschemata und die Konfiguration, die notwendig ist, um eine Delegierung authentifizierter Identitäten zu ermöglichen.

Die meisten Authentifizierungsschemata, die die Anmeldung nicht lokal auf dem Computer durch-führen, müssen mit der eingeschränkten Delegierung und dem Protokollübergang arbeiten, um die authentifizierte Identität an einen Remotecomputer delegieren zu können. Mithilfe der eingeschränkten Delegierung kann ein Dienst eine über das Kerberos-Protokoll abgerufene Benutzeridentität verwen-den, um auf Remoteressourcen zuzugreifen. Der Protokollübergang wird zusammen mit der einge-schränkten Delegierung eingesetzt, damit andere Authentifizierungsschemata eine Kerberos-Identität abrufen können, die im Rahmen einer eingeschränkten Delegierung für den Zugriff auf Remote-ressourcen genutzt wird. Weitere Informationen zum Einrichten der eingeschränkten Delegierung und des Protokollübergangs finden Sie unter http://technet2.microsoft.com/WindowsServer/en/library/c312ba01-318f-46ca-990e-a597f3c294eb1033.mspx.

Sichern der Kommunikation mit SSL (Secure Sockets Layer)Die gesamte Kommunikation zwischen dem Webserver und dem Client erfolgt standardmäßig über eine Klartextverbindung, weshalb die in den Anforderungen und Antworten enthaltenen Informationen von einem Angreifer eingesehen werden könnten, würde dieser die Kommunikation in der Netzwerkschicht abhören. Dies ist möglich, wenn innerhalb eines lokalen Netzwerks ein Packet Sniffing erfolgt oder

Tabelle 14.16 Integrierte Schemata und die für die Delegierung authentifizierter Identitäten erforderliche Konfiguration

Authentifizierung Konfiguration

Anonym Die Delegierung erfolgt bei Verwendung eines benutzerdefinierten anonymen Benutzers oder wenn eine benutzerdefinierte Anwendungspoolidentität für den anonymen Benutzer verwendet wird (1 Hop)

Standard Wird standardmäßig delegiert (1 Hop)

Windows (Kerberos) Erfordert eine eingeschränkte Delegierung

Windows (NTLM) Erfordert eine eingeschränkte Delegierung und den Protokollübergang

Digest Erfordert eine eingeschränkte Delegierung und den Protokollübergang

Clientzertifikatzuordnung Erfordert eine eingeschränkte Delegierung und den Protokollübergang

IIS-Clientzertifikatzuordnung Wird standardmäßig delegiert (1 Hop)


Sichern der Kommunikation mit SSL (Secure Sockets Layer) 489

wenn ein Router oder ein Proxyserver, der sich zwischen dem Client und dem Webserver befindet, kompromittiert wird. Dies kann zu einer unbeabsichtigten Offenlegung der Antwortdaten führen, die sensible Informationen enthalten könnte, z.B. Clientanmeldeinformationen, die als Teil eines Authenti-fizierungsverfahrens übermittelt werden (z.B. Standardauthentifizierung oder Formularauthentifi-zierung), Cookies usw. Der Angreifer könnte dies in einigen Fällen nutzen, um sich als Client auszu-geben, indem er im Rahmen eines Replay-Angriffs mithilfe der abgefangenen Anmeldeinformationen auf den Webserver zugreifen würde.

Um dies zu verhindern, können Sie die neuen Protokolle SSL (Secure Sockets Layer) oder das neuere TLS (Transport Layer Security, TLS) benutzen, mit denen es möglich ist, die Kommunikation zwischen dem Client und dem Server zu sichern. TLS ist ein weit verbreiteter Standard, der von den meisten Browsern implementiert wird. Im verbleibenden Abschnitt sind aus Gründen der Einfachheit beide Protokolle gemeint, wenn von SSL die Rede ist.

Zusätzlich zum Sichern der Kommunikation zwischen Client und Webserver erfüllt SSL den Zweck, dass es dem Client die Identität des Webservers bestätigt. Dies wird heute im Internet umfassend genutzt, um sicherzustellen, dass der Client wirklich mit der Entität arbeitet, die die Website vorgibt, zu repräsentieren. IIS kann SSL ebenfalls verwenden, um die Identität des Clients einzurichten, wenn dieser über ein akzeptiertes Zertifikat verfügt. Zertifikate werden später in diesem Kapitel im Abschnitt »Clientzertifikate« behandelt.

SSL konfigurierenUm SSL zu konfigurieren, gehen Sie wie folgt vor:

1. Rufen Sie ein Serverzertifikat von einer vertrauenswürdigen Zertifizierungsstelle ab. Die Zer-tifizierungsstelle muss für alle Clients, die unter Verwendung des Zertifikats eine Verbindung zur Website herstellen, eine vertrauenswürdige Stammzertifizierungsstelle sein. Bei Intranetsites kann dies eine Domänenzertifizierungsstelle sein, die von den Active Directory-Zertifikatdiensten zur Verfügung gestellt wird. Bei Internet Sites ist dies in der Regel eine Zertifizierungsstelle, der die meisten Clientbrowser standardmäßig vertrauen. Sie können das Zertifikat abrufen, indem Sie im IIS-Manager mithilfe des Features Serverzertifikate eine Zertifikatanforderung initiieren. Alternativ hierzu können Sie ein selbstausgestelltes (oder selbstsigniertes) Zertifikat verwenden, wenn Sie sowohl den Webserver als auch die Clients kontrollieren und beabsichtigen, dieses Zertifikat nur für Testzwecke zu nutzen.

2. Erstellen Sie eine sichere Bindung, indem Sie das HTTPS-Protokoll und Port 443 (oder einen anderen Port) verwenden und für jede Website das Serverzertifikat angeben. Sie können dies tun, indem Sie die Bindung mit dem IIS-Manager erstellen oder programmgesteuert hinzufügen. Danach verwenden Sie den Befehl netsh http add sslcert ipport=IPAddress:443 certstorename=MY certhash=hash appid=GUID, um das Zertifikat mit der Bindung zu verknüpfen. Sie können das Zertifikathash mithilfe der Konsole Zertifikate abrufen, indem Sie die Zertifikatdetails anzeigen lassen und den Wert der Eigen-schaft Fingerabdruck kopieren.

Hinweis Im Gegensatz zu IIS 6.0, wo die Zertifikatverknüpfungsinformationen in der Metabasis gespeichert werden und der Webpublishingdienst (W3SVC) bei seinem Start dafür verantwortlich ist, die Sitebindungen mit den Zertifikaten zu verknüpfen, speichert IIS 7.0 die Zertifikatinformationen direkt in der HTTP.sys-Konfiguration. Sie können diese Verknüpfungen mithilfe des IIS-Managers oder des Befehls netsh http add sslcert bearbeiten.



Um von den Clients akzeptiert zu werden, muss das Serverzertifikat CN-Einträge (Common Name, CN; gemeinsamer Name) für alle Hostheader enthalten, die von der Website verwendet werden. Dies muss geschehen, wenn das Zertifikat angefordert wird.

Hinweis Es ist möglich, dass mehrere SSL-Websites eigene eindeutige Serverzertifikate besitzen, sofern jede Website eine separate IP-Adresse bzw. einen eigenen Port für seine HTTPS-Bindung verwendet. Unter IIS 7.0 ist es wie bei IIS 6.0 nicht möglich, mit mehreren, eigene Serverzertifikate besitzenden Websites zu arbeiten, wenn die HTTPS-Bindungen dieser Sites dieselbe IP-Adresse/denselben Port benutzen und sich nur durch ihre Hostheader voneinander unterscheiden. Der Grund hierfür besteht darin, dass die Hostheaderinformationen während der SSL-Aushandlung nicht verfügbar sind. Deshalb gibt es nur eine Möglichkeit, um mit mehreren Websites zu arbeiten, die dieselbe IP-Adresse nutzen und unterschiedliche Hostheader definieren. All diese Websites müssen so konfiguriert werden, dass sie dasselbe SSL-Zertifikat in Verbindung mit einem Platzhalter-CN verwenden. Weitere Informatio-nen finden Sie unter http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true.

Weitere Informationen zur Konfiguration von Siteeindungen finden Sie im neunten Kapitel. Sie können außerdem mehr über das Anfordern von Zertifikaten erfahren, wenn Sie die Onlinedokumentation zu IIS 7.0 lesen, deren Adresse http://technet2.microsoft.com/windowsserver2008/en/library/d780d806-e8a8-4bc5-8d7a-9f045d1f3e221033.mspx?mfr=true lautet.

SSL voraussetzenUm zu gewährleisten, dass die Kommunikation zwischen Ihrem Webserver und den Clients geschützt ist, können Sie verlangen, dass die Clients die Inhalte Ihrer Website über sichere Verbindungen anfordern. Dies ist eine effektive Möglichkeit, um die Authentifizierungsanmeldeinformationen von Clients oder sensible Cookies zu schützen, die andernfalls von der Website über unsichere Verbindungen übermittelt würden.

Vorsicht Wenn Ihre Website eine gemischte SSL-Verwendung ermöglicht, wenn also z.B. der Zugriff auf die Web-site sowohl über SSL- als auch über nicht sichere Verbindungen erfolgen kann oder wenn der Zugriff auf Teile der Website über nicht sichere Verbindungen möglich ist, sollten Sie sich bewusst sein, dass Anforderungen, die über diese Verbindungen eingehen, sensible Informationen offen legen können. Wenn Ihre Website beispielsweise auf die Formularauthentifizierung zurückgreift, um Benutzer zu authentifizieren, oder wenn sie mit einem cookiebasier-ten Sitzungszustand arbeitet bzw. sensible Benutzerinformationen in Cookies speichert, können Ihre Clients diese Cookies offen legen, sobald sie Anforderungen über nicht sichere Verbindungen einreichen. Schützen Sie deshalb Ihre gesamte Website mit SSL, indem Sie SSL für den gesamten URL-Namespace der Site verlangen. Konfigu-rieren Sie außerdem Ihre Cookies so, dass sie das Sicherheitsbit enthalten, wodurch sichergestellt wird, dass der Browser nicht versucht, die Cookies über unverschlüsselte Verbindungen zu übermitteln.

Sie können mit dem IIS-Manager die Verwendung von SSL für den Webserver, eine Website oder einen URL erzwingen, indem Sie im Hierarchielistenfeld den entsprechenden Knoten markieren. Führen Sie anschließend einen Doppelklick auf SSL-Einstellungen aus. Markieren Sie auf der Seite des Features das Kontrollkästchen SSL erforderlich, damit SSL verwendet werden muss, wie in Abbildung 14.8 dar-gestellt. Sie können ebenfalls das Kontrollkästchen 128-Bit-SSL erforderlich aktivieren.


Sichern der Kommunikation mit SSL (Secure Sockets Layer) 491

Abbildung 14.8 SSL-Einstellungen mit dem IIS-Manager konfigurieren

Alternativ hierzu können Sie die Nutzung von SSL erzwingen, indem Sie mit Appcmd oder einer anderen Konfigurations-API den Abschnitt system.webServer/security/access direkt bearbeiten. Sie können beispielsweise diese Konfiguration mit der folgenden Appcmd-Syntax festlegen.%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] /section:system.webServer/security/access /sslFlags:enum

Dieser Befehl arbeitet mit den in Tabelle 14.17 beschriebenen Parametern.

Tabelle 14.17 Parameter für die Konfiguration von SSL-Einstellungen



sslFlags Eine kommagetrennte Liste, die die folgenden Werte enthalten kann: None, Ssl, Ssl128, SslNegotiateCert, SslRequireCert. Setzen Sie die Einstellung auf Ssl, um die Nutzung von SSL zu erzwingen, oder auf Ssl,Ssl128, um 128-Bit-SSL zu verlangen. Eine Beschreibung der Werte SslNegotateCert und SslRequireCert erhalten Sie im folgenden Abschnitt »Clientzertifikate«.



ClientzertifikateObwohl SSL in der Regel verwendet wird, um dem Client die Identität des Webservers zu bestätigen, kann es ebenfalls dazu herangezogen werden, die Identität des Clients für den Webserver zu bestätigen, sofern der Client über Zertifikate verfügt, die von einer Zertifizierungsstelle ausgestellt wurden, der der Webserver vertraut. Clientzertifikate können als Teil eines strengen zweistufigen Authentifizierungs-schemas verwendet werden, das sowohl einen Benutzernamen/ein Kennwort als auch ein physika-lisches Authentifizierungsverfahren, z.B. Smartcard, für die Bereitstellung des Clientzertifikats erfordert. Es kann aber auch als Teil eines einzelnen Authentifizierungsverfahrens verwendet werden, womit die Authentifizierung über Clientzertifikatzuordnungen gemeint ist, die von IIS unterstützt wird.

Um mit Clientzertifikaten arbeiten zu können, müssen die folgenden Anforderungen erfüllt sein:

� Die Website muss für die Verwendung von SSL konfiguriert sein und über ein gültiges Server-zertifikat verfügen.

� Der Client muss über ein Clientzertifikat verfügen, das von einer Zertifizierungsstelle ausgestellt wurde, der der Webserver vertraut.

Wenn ein Client eine Verbindung unter Verwendung von SSL herstellt, handelt der Webserver die Clientzertifikate aus (wenn er hierfür konfiguriert ist), indem er die Liste der vertrauenswürdigen Zertifizierungsstellen bereitstellt, was den Client veranlasst, mit der Liste der Zertifikate zu antworten, die auf dem Client verfügbar sind und die von den vertrauenswürdigen Zertifizierungsstellen ausgestellt wurden. Der Server überprüft dann die Zertifikate, einschließlich deren Verfallsdaten, und stellt sicher, dass diese nicht auf dem Webserver in der Liste für Zertifikatswiderrufung (Certificate Revocation List, CRL) aufgeführt sind.

IIS unterstützt mehrere Ebenen der Clientzertifikatverwendung:

1. Zertifikate aushandeln. Der Client wird aufgefordert, ein Clientzertifikat zur Verfügung zu stellen, sobald eine Anforderung erfolgt. Das Zertifikat ist jedoch nicht zwingend erforderlich. Wenn der Client ein Zertifikat zur Verfügung stellt, überprüft es der Server, und es wird der jeweiligen Anwen-dung zur Verfügung gestellt. Setzen Sie dazu das sslFlags-Attribut des Abschnitts system.webServer/security/access so, dass es SslNegotiateCert enthält, wie früher in diesem Kapitel im Abschnitt »SSL vor-aussetzen« beschrieben.

2. Zertifikate verlangen. Der Client muss ein Clientzertifikat zur Verfügung stellen, sobald die Anforderung erfolgt. Wenn das Zertifikat nicht zur Verfügung gestellt wird, wird die Anforderung mit dem Fehler 403.7 (Clientzertifikat ist erforderlich) zurückgewiesen. Wenn das Zertifikat vom Server nicht erfolgreich validiert wurde, wird die Anforderung mit dem Fehler 403.16 (Client-zertifikat ist nicht vertrauenswürdig oder ungültig) zurückgewiesen. Es kann auch mit dem Fehler 403.17 (Clientzertifikat ist abgelaufen oder momentan nicht gültig) zurückgewiesen werden. Um Zertifikate zu verlangen, setzen Sie das sslFlags-Attribut des Abschnitts system.webServer/security/access so, dass es die Werte SslNegotiateCert,SslRequireCert enthält, wie früher in diesem Kapitel im Abschnitt »SSL voraussetzen« beschrieben. Sie können Zertifikate verlangen, um ein strenges zweistufiges Authentifizierungsschema zu implementieren. Alternativ hierzu können Sie das Verlangen von Zertifikaten zusammen mit der Authentifizierung über Clientzertifikatzuordnungen als primäres Authentifizierungsschema für Ihre Website nutzen. Weitere Informationen finden Sie früher in diesem Kapitel in den Abschnitten »Authentifizierung über Clientzertifikatzuordnungen« und »Authentifizierung über IIS-Clientzertifikatzuordnungen«.


Sichern der Konfiguration 493

3. Benutzer mit Clientzertifikaten authentifizieren. IIS kann auch so konfiguriert werden, dass Clients basierend auf Clientzertifikaten authentifiziert werden. Um mehr über die Clientzertifikat-authentifizierung zu erfahren, lesen Sie früher in diesem Kapitel die Abschnitte »Authentifizierung über Clientzertifikatzuordnungen« und »Authentifizierung über IIS-Clientzertifikatzuordnungen«.

Sichern der KonfigurationÄltere IIS-Versionen benutzen einen zentralisierten Konfigurationsspeicher namens Metabasis. IIS 7.0 ersetzt diese Metabasis durch ein neues Konfigurationssystem, das auf hierarchischen XML-Konfigura-tionsdateien basiert. Auf diese Weise wird die Bereitstellung vereinfacht, und die Verwaltung des Webservers wird flexibler gestaltet.

Hinweis Im vierten Kapitel, »Verstehen des Konfigurationssystems«, erfahren Sie mehr über das neue IIS 7.0-Konfigurationssystem.

In diesem Abschnitt werfen wir einen Blick auf die Dateien, aus denen die IIS 7.0-Konfigurations-hierarchie besteht. Sie erfahren außerdem, wie Sie auf diese Dateien zugreifen. Wir werden uns mit empfohlenen Sicherheitsmaßnahmen beschäftigen, die den Zugriff auf diese Dateien einschränken, um zu gewährleisten, dass die darin enthaltene Konfiguration vor einer nicht autorisierten Offenlegung von Informationen und Manipulationen geschützt ist. Darüber hinaus wird die neue Konfigurationsisolation zwischen Anwendungspools behandelt.

Da die Konfiguration in einfachen XML-Textdateien gespeichert wird, von denen einige während der Bereitstellung vom Server genommen oder anderweitig offen gelegt werden, ist es manchmal not-wendig, die darin gespeicherten Informationen vor einer unerwünschten Einsicht zu schützen. Das Konfigurationssystem bietet eine integrierte Verschlüsselung an, um die in den Konfigurationsdateien gespeicherten sensiblen Informationen auch dann vor einer derartigen Einsicht zu schützen, wenn ein Angreifer auf die Dateien zugreifen kann. Später in diesem Kapitel werfen wir einen Blick darauf, welche empfohlenen Maßnahmen es zum Speichern solcher sensiblen Informationen in Konfigurations-dateien gibt und wie die Verschlüsselung genutzt wird, um diese Informationen zu schützen.

Die Konfigurationsdateihierarchie geht weit über eine zentralisierte Konfiguration hinaus und ermög-licht einen Zugriff auf verteilte web.config-Konfigurationsdateien, der an den Site- oder Anwendungs-besitzer delegiert werden kann. Sites und Anwendungen können deshalb über benötigte Konfigura-tionen verfügen, die ein Teil der jeweiligen Inhalte sind, so dass eine Bereitstellung in nur einem Schritt möglich ist, für die auf dem Server keine administrativen Rechte erforderlich sind. Dies ermöglicht es den Site- und Anwendungsbesitzern außerdem, ihre Anwendungen ohne administrative Rechte remote zu verwalten. In diesem Abschnitt werden wir uns mit den empfohlenen Maßnahmen zur sicheren Konfiguration der Konfigurationsdelegierung beschäftigen.

Hinweis Weitere Informationen zur Aktivierung und Sicherung der delegierten Remoteverwaltung finden Sie im achten Kapitel.



Einschränken des Zugriffs auf die KonfigurationDie IIS 7.0-Konfiguration ist in einer Konfigurationsdateihierarchie gespeichert, die aus Konfigurations-dateien der Serverebene besteht, aber auch aus verteilten web.config-Dateien, die an Site- und Anwen-dungsbesitzer delegiert werden können. Da diese Dateien ihre Konfiguration im einfachen XML-Text-format speichern, kann jeder Benutzer mit entsprechenden Zugriffsrechten die Serverkonfiguration lesen und manipulieren. Zusätzliche Tools oder APIs sind hierfür nicht notwendig. Deshalb bestimmen die für diese Dateien festgelegten NTFS-Zugriffsberechtigungen, wer auf die Serverkonfiguration zugreifen darf und in welchem Umfang dies möglich ist.

Um Konfigurationsdateien richtig zu sichern, ist es wichtig, die Dateien zu kennen, welche die Hierarchie bilden. Sie sollten außerdem wissen, wie der Zugriff auf diese Dateien erfolgt. Dies kann Ihnen dabei helfen, die richtige Zugriffstrategie für Ihre Umgebung zu definieren und umzusetzen.

Hinweis Ausführliche Informationen zur Konfigurationsdateihierarchie, dem Speicherort jeder Datei und der Aufgabe der jeweiligen Datei bei der Konfiguration des Servers erhalten Sie im vierten Kapitel.

Die Dateien, die die IIS 7.0-Konfigurationshierarchie bilden, sind zusammen mit ihren Zugriffstandardberechtigungen in Tabelle 14.18 aufgeführt.

Hinweis Die in Tabelle 14.18 aufgeführten Standardberechtigungen schließen auch Berechtigungen mit ein, die NT-AUTORITÄT\SYSTEM und BUILTIN\Administratoren volle Rechte gewähren. Diese wurden aus Gründen der Übersichtlichkeit aus der Tabelle entfernt.

Tabelle 14.18 Zugriffstandardberechtigungen für Konfigurationsdateien

Datei Beschreibung Standardberechtigungen

machine.config-Datei des Frameworks .NET Framework-Konfiguration auf der Computerebene

BUILTIN\IIS_IUSRS:(RX)

BUILTIN\Users:(RX)

web.config-Datei des Frameworkstamms ASP.NET-Anwendungskonfiguration der Computerebene


BUILTIN\Users:(RX)

IIS-Konfiguration der Computerebene Die Version der applicationHost.config-Datei, die für jeden Anwendungspool automatisch generiert wird

NT SERVICE\WMSvc:(R)


<AppoolName>.config Die Version der applicationHost.config-Datei, die für jeden Anwendungspool automatisch generiert wird

IIS APPPOOL\<ApppoolName>:(R)

Verteilte web.config-Datei (wwwroot) Verteilte Konfigurationsdateien in der Ver-zeichnisstruktur der Website


BUILTIN\Users:(RX)

administration.config IIS-Manager-Konfigurationsdatei der Com-puterebene


redirection.config Konfigurationsdatei der Computerebene für die Konfiguration einer applicationHost.config-Datei, die sich an einem Remoteort befindet




Ein Blick auf die Standardberechtigungen zeigt, dass:

� nur das System und die Mitglieder der Gruppe Administratoren in die Konfigurationsdateien der Serverebene schreiben können. Dazu zählen die machine.config-Datei des Frameworks, die web.config-Datei des Frameworkstamms und die Dateien applicationHost.config, administra-tion.config und redirection.config.

� alle Mitglieder der Gruppe Benutzer und der IIS_IUSRS-Gruppe Framework die Datei machine.config und die web.config-Stammdateien lesen können. Jeder Benutzer eines Computers – sowie jede An-wendung, die innerhalb eines IIS-Arbeitsprozesses ausgeführt wird – kann die in diesen Dateien enthaltene Konfiguration lesen, was bei den IIS-Konfigurationsdateien der Serverebene nicht möglich ist. Der Grund hierfür besteht darin, dass diese Dateien verwendet werden, um das Verhalten der .NET Framework-Komponenten zu konfigurieren, die von den auf dem Computer ausgeführten .NET-Anwendungen genutzt werden.

� die IIS-Konfigurationsdateien der Serverebene, applicationHost.config, redirection.config und administration.config, nur vom System, von Mitgliedern der Gruppe Administratoren und dem Webverwaltungsdienst (NT Service\WMSvc) gelesen werden können. Im Gegensatz zu den .NET Framework-Konfigurationsdateien können sie nicht von nicht administrativen Benutzern und auch nicht von den IIS-Arbeitsprozessen gelesen werden. IIS-Arbeitsprozesse erhalten von den ApppoolName.config-Dateien, die automatisch für jeden Anwendungspool erzeugt werden, eine Untermenge der applicationHost.config-Konfiguration.

� der Windows-Prozessaktivierungsdienst (WAS) automatisch ApppoolName.config-Dateien für jeden Anwendungspool generiert. Diese Dateien können nur von den IIS-Arbeitsprozessen im jeweiligen Anwendungspool gelesen werden. Dies ist die Basis der später in diesem Kapitel im Abschnitt »Die Konfigurationsisolation verstehen« beschriebenen Konfigurationsisolation.

� die verteilten web.config-Dateien, die sich in der Verzeichnisstruktur einer Site befinden, standard-mäßig von den Mitgliedern der Gruppe Benutzer gelesen werden können. Diese Dateien müssen in der Regel auch der IIS_IUSRS-Gruppe Zugriffsrechte gewähren, damit dem jeweiligen IIS-Arbeits-prozess der Zugriff möglich ist (das IIS-Setup sorgt automatisch hierfür, indem es die entspre-chenden Berechtigungen für den Stamm der Standardwebsite unter %SystemDrive%\Inetpub\ Wwwroot setzt).

Die Berechtigungen von Konfigurationsdateien setzenFür die Konfigurationsdateien in der IIS-Hierarchie sind standardmäßig restriktive Berechtigungen konfi-guriert, die in der Regel nicht geändert werden sollten (außer für die verteilten web.config-Dateien, die Teil der Verzeichnisstruktur einer Site sind). Das Ändern der Berechtigungen dieser Dateien könnte dazu führen, dass sie anfälliger für nicht autorisierte Zugriffe sind. Um die Sicherheit dieser Dateien aufrecht-zuerhalten, sollten Sie Folgendes berücksichtigen:

� Gewähren Sie nicht administrativen Identitäten (mit Ausnahme von NT SERVICE\WMSvc) niemals den Zugriff auf applicationHost.config, redirection.config und administration.config (weder Lese- noch Schreibrechte). Zu diesen Identitäten zählen NETZWERKDIENST, IIS_IUSRS, IUSR und jede andere von den IIS-Anwendungspools verwendete benutzerdefinierte Identität. IIS-Arbeitsprozesse sind nicht dafür vorgesehen, direkt auf diese Dateien zuzugreifen. Lesen Sie den folgenden Abschnitt »Die Konfigurationsisolation verstehen«, um weitere Informationen darüber zu erhalten, wie IIS-Arbeitsprozesse die Konfiguration von applicationHost.config beziehen.



� Stellen Sie applicationHost.config, redirection.config und administration.config niemals zur gemein-samen Nutzung im Netzwerk zur Verfügung. Wenn Sie mit einer freigegebenen Konfiguration arbeiten, sollten Sie applicationHost.config an einen anderen Ort exportieren (lesen Sie dazu später in diesem Kapitel den Abschnitt »Berechtigungen für freigegebene Konfigurationen festlegen«).

� Denken Sie daran, dass alle Benutzer standardmäßig die machine.config-Datei des .NET Frame-works und die web.config-Stammdatei lesen können. Speichern Sie keine sensiblen Informationen in diesen Dateien, die nur für den Administrator bestimmt sind. Verschlüsseln Sie sensible Informa-tionen, die nur von den IIS-Arbeitsprozessen und nicht von anderen Benutzern des Computers gelesen werden sollen.

Die einzige Ausnahme dieser Regel bilden die verteilten web.config-Dateien, die Teil der Verzeichnis-struktur Ihrer Website sind. Es liegt an Ihnen, ACLs für diese Dateien bereitzustellen, um nicht autori-sierte Zugriffe auf deren Inhalte zu verhindern. Sie sollten die Standardrichtlinien zum Setzen von Berechtigungen für Webseiteinhalte befolgen, die früher in diesem Kapitel im Abschnitt »NTFS-Berechtigungen für den Mindestzugriff gewähren« beschrieben sind. Dazu zählen die Nutzung der Anwendungspoolisolation, um den Zugriff auf den Anwendungspool einzuschränken, dem die jewei-lige Anwendung zugeordnet ist, sowie das Setzen der Berechtigungen, die notwendig sind, um über den IIS-Manager eine delegierte Remoteverwaltung zu ermöglichen.

Die Konfigurationsisolation verstehenWie bereits erwähnt wurde, verfügen IIS-Arbeitsprozesse nicht über eine Leseberechtigung für applicationHost.config. Doch wie können sie dann die in dieser Datei enthaltene Konfiguration lesen?

Die Antwort liefert die von IIS 7.0 zur Verfügung gestellte Konfigurationsisolation, die standardmäßig immer aktiv ist. Anstatt den IIS-Arbeitsprozessen zu erlauben, applicationHost.config im Rahmen eines Abrufs von Informationen aus der Konfigurationsdateihierarchie direkt zu lesen, generiert IIS gefilterte Kopien dieser Datei und benutzt diese Kopien als Ersatz für applicationHost.config. Dies geschieht immer dann, wenn innerhalb eines IIS-Arbeitsprozesses eine Konfiguration gelesen wird.

Der Grund hierfür besteht darin, dass verhindert werden soll, dass IIS-Arbeitsprozesse aus Anwen-dungspool A applicationHost.config-Konfigurationsinformationen lesen können, die für Anwendungs-pool B bestimmt sind. Da applicationHost.config sensible Informationen enthalten kann, z.B. den Benutzernamen und das Kennwort einer benutzerdefinierten Anwendungspoolidentität oder eines virtuellen Verzeichnisses, wäre die Anwendungspoolisolation nicht mehr gegeben, wenn alle Anwen-dungspools auf applicationHost.config zugreifen könnten.

WAS ist dafür verantwortlich, temporäre Anwendungspoolkonfigurationsdateien zu generieren, die von jedem IIS-Arbeitsprozess als Ersatz für applicationHost.config verwendet werden können. Diese Dateien werden standardmäßig im Verzeichnis %SystemDrive%\Inetpub\Temp\Apppools abgelegt und nach dem Schema AppPoolName.config benannt. Wie bereits erwähnt wurde, sind diese Dateien so konfiguriert, dass nur die IIS-Arbeitsprozesse in den jeweiligen Anwendungspools darauf zugreifen können. Dazu wird die Anwendungspool-SID APPPOOL\AppPoolName verwendet.

Hinweis Dieser Vorgang erfolgt immer dann automatisch, wenn applicationHost.config geändert wird. Abgesehen von den normalen Konfigurationsvorgängen ist somit kein manuelles Eingreifen seitens des Administrators erforderlich.



Jede Anwendungspoolkonfigurationsdatei enthält die applicationHost.config-Konfiguration, wobei die folgenden Informationen entfernt werden:

� Alle Anwendungspooldefinitionen im Konfigurationsabschnitt system.applicationHost/applicationPools. Nur WAS muss diesen Konfigurationsabschnitt lesen.

� Alle Websitedefinitionen im Konfigurationsabschnitt system.applicationHost/sites, die sich auf Sites beziehen, für die im aktuellen Anwendungspool keine Anwendungen vorhanden sind.

� Alle location-Konfigurationstags von Websites, Anwendungen oder URLs, die sich nicht auf die Anwendungen im aktuellen Anwendungspool beziehen.

Vorsicht Alle Anwendungsdefinitionen (und die dazugehörigen Definitionen von virtuellen Verzeichnissen, die möglicherweise Anmeldeinformationen in Form von Benutzernamen und Kennwörtern enthalten) einer Site, die im aktuellen Anwendungspool über mindestens eine Anwendung verfügt, sind in der Anwendungspoolkonfigurations-datei aufgeführt. Um dies zu verhindern und nur die Anwendungsdefinitionen der im Anwendungspool enthaltenen Anwendungen einzubinden, setzen Sie den DWORD-Wert IsolationWholeSiteInclude, der sich im Schlüssel HKLM\System\CurrentControlSet\Services\WAS\Parameters befindet auf 0 und führen ein IISRESET durch. Dies kann bei Sites mit mehreren Anwendungen, die über mehrere Anwendungspools verteilt ausgeführt werden, zu Fehlern führen, wenn versucht wird, physikalische Pfade von URLs anderer Anwendungen zuzuordnen.

Denken Sie daran, dass die globalen Konfigurationseinstellungen in applicationHost.config (für die keine location-Tags definiert sind, um die Einstellungen auf bestimmte Websites, Anwendungen oder URLs anzuwenden) nicht gefiltert werden. Jede Anwendungspoolkonfigurationsdatei enthält all diese Einstellungen.

Die Konfigurationsisolation ist ein wichtiger Teil der IIS 7.0-Strategie für die Anwendungspoolisolation. Sie ist standardmäßig aktiviert, um eine Konfigurationsisolation für die applicationHost.config-Konfigu-ration der Serverebene zu erreichen. Strategien zum Erzielen der richtigen Anwendungspoolisolation sind früher in diesem Kapitel im Abschnitt »Anwendungen isolieren« beschrieben.

Vorsicht Die in der machine.config-Datei des .NET Frameworks und der web.config-Stammdatei gespeicherten Konfigurationen sind nicht isoliert. Nur die in applicationHost.config gespeicherte Konfiguration wird isoliert.

Berechtigungen für freigegebene Konfigurationen festlegenMit IIS 7.0 können mehrere Webserver einer Webfarm die in der Konfigurationsdatei applicationHost. config gespeicherte Serverkonfiguration gemeinsam nutzen. Um mit einer solchen freigegebenen Kon-figuration arbeiten zu können, muss die Konfiguration des Quellwebservers exportiert und an einem Ort platziert werden, der über eine Netzwerkfreigabe erreichbar ist. Danach muss die Freigabe so konfigu-riert werden, dass alle beteiligten Webserver darauf zugreifen können. Die dazu notwendige Vorgehens-weise ist im vierten Kapitel erklärt.

Um einen nicht autorisierten Zugriff auf die freigegebene Konfiguration zu verhindern, befolgen Sie die nachstehenden Richtlinien:

� Gewähren Sie der Identität, die vom Webserver für den Zugriff auf die freigegebene applicationHost. config-Datei verwendet wird, keine Schreibrechte. Diese Identität sollte ausschließlich über Lese-rechte verfügen.

� Benutzen Sie eine gesonderte Identität, um applicationHost.config am Ort der Freigabe zu veröffentlichen. Benutzen Sie diese Identität nicht, um auf den Webservern den Zugriff auf die freigegebene Konfiguration zu konfigurieren.



� Benutzen Sie ein starkes Kennwort, wenn Sie die Verschlüsselungsschlüssel exportieren, die für die freigegebene Konfiguration verwendet werden sollen.

� Lassen Sie nur einen eingeschränkten Zugriff auf die Freigabe zu, die die freigegebene Konfi-guration und die Verschlüsselungsschlüssel enthält. Wenn diese Freigabe kompromittiert wird, kann ein Angreifer jede beliebige IIS-Konfiguration für Ihre Webserver lesen und schreiben, Daten-verkehr von Ihrer Website zu böswilligen Quellen umleiten und in einigen Fällen die Kontrolle über alle Webserver erlangen, indem ein entsprechender Code in die IIS-Arbeitsprozesse geladen wird. Denken Sie darüber nach, die Freigabe mit Firewall Regeln und IPsec-Richtlinien zu schützen, damit nur die beteiligten Webserver eine Verbindung herstellen können.

Vorsicht Sorgen Sie für einen eingeschränkten Zugriff auf die Freigabe, die die freigegebene Konfiguration enthält. Ein böswilliger Zugriff auf diese Freigabe kann den Webserver vollständig kompromittieren.

Weitere Informationen zum Einrichten der freigegebenen Konfiguration finden Sie im vierten Kapitel.

Sensible Konfigurationen sichernDie Informationen in den Konfigurationsdateien der IIS 7.0-Konfigurationshierarchie sind durch eingeschränkte Berechtigungen geschützt, die von NTFS-ACLs für jede Datei angegeben werden. Diese Berechtigungen sollen verhindern, dass nicht autorisierte Benutzer auf diese Dateien zugreifen. Weitere Informationen zur Verwaltung von Sicherheitsberechtigungen für Konfigurationsdateien finden Sie früher in diesem Kapitel im Abschnitt »Einschränken des Zugriffs auf die Konfiguration«.

Dies allein bietet jedoch noch keinen ausreichenden Schutz besonders für sensible Informationen, die in Konfigurationsdateien gespeichert sind, z.B. Benutzernamen und Kennwörter von benutzerdefinierten Anwendungspoolidentitäten. Es ist wichtig, diese Informationen auch dann vor einer Offenlegung zu bewahren, wenn ein Angreifer es schafft, den lokalen Webserver zu kompromittieren und auf die Konfigurationsdatei zuzugreifen, die diese Informationen enthält. Wenn darüber hinaus jemand die Konfigurationsdatei vom Server entfernt, um sie zu archivieren oder zu kopieren, sollte ein Angreifer ebenfalls nicht in der Lage sein, die sensiblen Informationen innerhalb der Konfigurationsdatei zu lesen. Um dies zu gewährleisten, bietet IIS 7.0 die Möglichkeit, bestimmte in der Konfiguration gespeicherte Informationen zu verschlüsseln.

Sensible Konfigurationsinformationen mithilfe der Konfigurationsverschlüsselung speichernDie Konfigurationsverschlüsselung von IIS 7.0 verschlüsselt die Inhalte der Konfigurationsattribute, für die die Verschlüsselung vor dem Speichern der Werte in der Konfigurationsdatei aktiviert wurde. Deshalb ist es selbst bei einem erfolgreichen Zugriff auf die Datei nicht möglich, die Inhalte des Attributs ohne eine vorherige Entschlüsselung zu lesen.

Ob die Konfigurationsverschlüsselung für ein Attribut verwendet wird, bestimmt die Definition dieses Attributs im entsprechenden Konfigurationsabschnittsschema. Weitere Informationen zum Einrichten der Verschlüsselung in einem Konfigurationsabschnittsschema finden Sie im dreizehnten Kapitel, »Konfigurations- und Benutzeroberflächenerweiterungen verwalten« und dort im Abschnitt »Sensible Konfigurationsdaten schützen«. Das Schema dient außerdem als Verfahren zur Auswahl des Verschlüs-selungsanbieters, der zur Verschlüsselung der Attributdaten verwendet werden soll (weitere Informationen zu den verfügbaren Verschlüsselungsanbietern finden Sie im folgenden Abschnitt »Verschlüsselungsanbieter auswählen,«).



Wenn ein Konfigurationstool oder eine Konfigurations-API einen Wert für ein verschlüsseltes Attribut speichert, wird dieser Wert automatisch vom konfigurierten Verschlüsselungsanbieter verschlüsselt, bevor die Speicherung in der Konfigurationsdatei auf dem Datenträger erfolgt. Wenn Sie die resul-tierende Konfigurationsdatei untersuchen, finden Sie den verschlüsselten Wert ähnlich wie im folgen-den Codebeispiel vor. Dort wurde im Konfigurationsabschnitt system.applicationHost/applicationPools das password-Attribut der Anwendungspooldefinition verschlüsselt.<applicationPools> <add name="MyAppPool"> <processModel identityType="SpecificUser" userName="TestUser" password="[enc:IISWASOnlyAesProvider:N8mr4dLU6PnMW5xlmCWg6914cKePgeU0fTbxew ZppiwyTLmBQh0mZnFywQO78pQY:enc]" /> </add> </applicationPools>

Das Konfigurationssystem entschlüsselt automatisch das Attribut, sobald ein Zugriff darauf erfolgt. Dies geschieht jedoch nur dann, wenn der Aufrufer des Konfigurationssystems über das Recht verfügt, den Verschlüsselungsanbieter für die Durchführung der Entschlüsselung zu verwenden. Die Verschlüs-selung und Entschlüsselung erfolgt somit vom Administrator unbemerkt, aber gleichzeitig wird sicher-gestellt, dass die resultierende Konfiguration nicht als lesbarer Text gespeichert wird.

Verschlüsselungsanbieter auswählenIIS und das ASP.NET Framework bieten mehrere Verschlüsselungsanbieter an, die zur Verschlüsse-lung von Konfigurationen verwendet werden können. Jeweils ein Anbieter wird für jedes Konfigura-tionsattribut verwendet, das für die Verschlüsselung gekennzeichnet wurde. Die Anbieter sind in Tabelle 14.19 beschrieben.

Tabelle 14.19 Anbieter für die Konfigurationsverschlüsselung

Anbieter Verwendung Zugriff auf Verschlüsselungsschlüssel

RsaProtectedConfigurationProvider Verschlüsselung von .NET Framework-Konfigurationsabschnitten mithilfe der exportierbaren RSA-Verschlüsselung

RSA-Computerschlüssel: nur SYSTEM und Administratoren; Zugriffsgewährung unter Verwendung von Aspnet_regiis.exe -pa

DataProtectionConfigurationProvider Verschlüsselung von .NET Framework-Konfigurationsabschnitten mithilfe der lokalen Datenschutz-API-Verschlüsselung

Standardmäßig jeder auf dem Webserver; optional benutzerbasierter Schlüssel

IISWASOnlyRsaProvider Verschlüsselung der von WAS gelesenen IIS-Konfigurationsabschnitte mithilfe der exportierbaren RSA-Verschlüsselung

RSA-Computerschlüssel: nur SYSTEM und Administratoren

IISWASOnlyAesProvider Verschlüsselung der von WAS gelesenen IIS-Konfigurationsabschnitte mithilfe der AES-Verschlüsselung

Sitzungsschlüssel, der mit dem RSA-Com-puterschlüssel verschlüsselt wird: nur SYSTEM und Administratoren

AesProvider Verschlüsselung der von einem IIS-Arbeits-prozess gelesenen IIS-Konfigurationsab-schnitte mithilfe der AES-Verschlüsselung

Sitzungsschlüssel, der mit dem RSA-Computerschlüssel verschlüsselt wird:

IIS_IUSRS, NT Service\WMSvc



Das .NET Framework stellt die beiden Anbieter RsaProtectedConfigurationProvider und DataProtectionConfigura-tionProvider zur Verfügung. Diese Anbieter werden vorwiegend verwendet, um die .NET-Konfiguration von ASP.NET-Anwendungen mit dem Tool Aspnet_regiis.exe zu verschlüsseln. Weitere Informationen zur Verschlüsselung von .NET Framework-Konfigurationen finden Sie unter http://msdn2.microsoft.com/ en-us/library/53tyfkaw.aspx.

Hinweis Sie können .NET-Konfigurationsabschnitte nicht mit der IIS-Konfigurationsverschlüsselung verschlüsseln. Demgemäß können Sie IIS-Konfigurationsabschnitte nicht mit der .NET-Konfigurationsverschlüsselung und Aspnet_ regiis.exe verschlüsseln. Wenn Sie versuchen, die mit der .NET-Konfigurationsverschlüsselung verschlüsselten .NET-Konfigurationsabschnitte mithilfe von IIS-Konfigurations-APIs zu lesen, erhalten Sie eine Fehlermeldung, da IIS die im .NET Framework-Konfigurationssystem übliche Abschnittsebenenverschlüsselung nicht unterstützt.

Sie können die IIS-Verschlüsselungsanbieter – IISWASOnlyRsaProvider, IISWASOnlyAesProvider und AesProvider – benutzen, um IIS-Konfigurationsabschnitte zu verschlüsseln.

IISWASOnlyRsaProvider und IISWASOnlyAesProvider werden verwendet, um die von WAS gelesenen Konfigura-tionsabschnitte zu verschlüsseln, z.B. system.applicationHost/applicationPools, und sie lassen eine Ent-schlüsselung der Konfiguration durch IIS-Arbeitsprozesse nicht zu. Der Anbieter IISWASOnlyAesProvider bietet eine bessere Leistung, da er nicht die vollständige RSA-Verschlüsselung nutzt, sondern mit der AES-Verschlüsselung arbeitet, die einen mit RSA verschlüsselten Sitzungsschlüssel verwendet. Diese Verschlüsselung wird standardmäßig genutzt. Der Sitzungsschlüssel selbst wird unter Verwendung des RSA-Schlüsselcontainers verschlüsselt, der von IISWASOnlyAesProvider verwendet wird, so dass er die-selben Zugriffsanforderungen definiert. Konfigurationsattribute, die mithilfe dieser Anbieter verschlüs-selt werden, können nur von SYSTEM und Mitgliedern der Gruppe Administratoren entschlüsselt werden.

Der Anbieter AesProvider ist ein AES-Anbieter, der einen mithilfe des RSA-Schlüsselcontainers verschlüsselten Sitzungsschlüssel verwendet, der Berechtigungen für die Gruppe IIS_IUSRS besitzt, weshalb IIS-Arbeitsprozesse diesen Anbieter für die Verschlüsselung und Entschlüsselung von Konfi-gurationen nutzen dürfen. Dies ist der Anbieter, der standardmäßig von allen IIS-Konfigurations-abschnitten verwendet wird, die von IIS-Arbeitsprozessen gelesen werden. Es ist außerdem der Anbieter, über dessen Einsatz Sie nachdenken sollten, wenn Sie Ihre benutzerdefinierten Konfigura-tionsabschnitte schützen möchten. Die mit diesem Anbieter verschlüsselten Konfigurationsattribute können von allen IIS-Anwendungen entschlüsselt werden.

Hinweis Im Gegensatz zum .NET-Konfigurationssystem unterstützt das IIS-Konfigurationssystem keine plug-fähigen Verschlüsselungsanbieter. Sie können jedoch neue Instanzen der IIS-Konfigurationsanbietertypen konfi-gurieren, um verschiedene Schlüsselcontainer für die Verschlüsselung zu verwenden.

Sie können auch zusätzliche Instanzen der RSA- und AES-Anbieter erstellen, indem Sie dem Konfi-gurationsabschnitt configProtectedData neue Einträge hinzufügen und diese für die Verwendung neuer RSA-Schlüsselcontainer konfigurieren. Sie können neue RSA-Schlüsselcontainer erstellen, indem Sie den Befehl Aspnet_regiis.exe -pc wie unter http://msdn2.microsoft.com/en-us/library/2w117ede.aspx beschrieben ausführen lassen.

Sie können dann die Berechtigungen des RSA-Schlüssels bearbeiten. Auf diese Weise legen Sie fest, wer diesen Schlüssel verwenden darf, um Konfigurationen mithilfe der Befehle Aspnet_regiis.exe -pa und Aspnet_regiis -pr zu verschlüsseln und zu entschlüsseln.



Beachten Sie die folgenden Richtlinien, wenn Sie mit der Verschlüsselung arbeiten:

� Eine mit IISWASOnlyAesProvider verschlüsselte Konfiguration kann nur von den Mitgliedern der Gruppe Administratoren entschlüsselt werden. Dieser Anbieter wird ausschließlich zur Verschlüsselung von Konfigurationen verwendet, die nur von WAS gelesen werden.

� Eine mit AesProvider verschlüsselte Konfiguration kann von jeder IIS-Anwendung entschlüsselt werden. Sie kann genutzt werden, um eine Konfiguration davor zu schützen, außerhalb des Webservers offen gelegt zu werden. Sie bietet jedoch keinen Schutz vor Anwendungen, die auf dem Webserver ausge-führt werden. Sie schützt auch nicht eine von einem Anwendungspool verwendete Konfiguration vor einem anderen Anwendungspool (obwohl dieser Schutz mithilfe von NTFS-Berechtigungen, die für die Anwendungspoolisolation richtig konfiguriert wurden, erreicht werden kann).

� Wenn Sie als zusätzliche Isolationsmaßnahme die Konfiguration jedes Anwendungspools ver-schlüsseln möchten, sollten Sie separate RSA-Schlüssel für jede Anwendungspoolidentität gene-rieren, und Sie sollten für den jeweiligen Anwendungspool unter Verwendung der Anwendungs-pool-SID oder einer benutzerdefinierten Anwendungspoolidentität ACLs auf diese Schlüssel anwenden. Danach können Sie für jeden Anwendungspool einen Anbieter erstellen, die entspre-chenden RSA-Schlüssel benutzen und die Konfiguration für jeden Anwendungspool mithilfe des entsprechenden Anbieters verschlüsseln.

� Um eine Konfiguration in einer Webfarm freizugeben oder eine Anwendung mit einer verschlüsselten Konfiguration auf einem anderen Server bereitzustellen, müssen Sie dafür sorgen, dass sich der ursprüngliche Server, auf dem die Verschlüsselung durchgeführt wurde, und der Zielserver die Ver-schlüsselungsschlüssel und Anbieterdefinitionen teilen. Wenn Sie Verschlüsselungsschlüsselcontainer exportieren, sollten Sie ein starkes Kennwort benutzen und die Schlüssel vor einem Zugriff durch nicht autorisierte Benutzer schützen. Weitere Informationen zum Exportieren von Verschlüsselungs-schlüsseln erhalten Sie hier: http://msdn2.microsoft.com/en-us/library/2w117ede.aspx. Darüber hin-aus können Sie Verschlüsselungsschlüssel mit dem IIS-Manager exportieren, wenn Sie eine freigege-bene Konfiguration einrichten. Weitere Informationen hierzu finden Sie im vierten Kapitel.

Vorsicht Das Ändern der Berechtigungen eines RSA-Schlüsselcontainers kann zur Kompromittierung der Verschlüsselungsschlüssel führen, so dass es möglich ist, dass Ihre verschlüsselten Konfigurationen offen gelegt werden. Ändern Sie nicht die Standardberechtigungen des integrierten IIS-RSA-Schlüsselcontainers.

Grenzen des Speicherns von sensiblen Informationen in der KonfigurationWenn Sie in der Konfiguration sensible Informationen speichern, können diese sowohl durch die NTFS-Berechtigungen der Konfigurationsdatei (lesen Sie früher in diesem Kapitel den Abschnitt »Einschränken des Zugriffs auf die Konfiguration«) als auch durch die Konfigurationsverschlüsselung, sofern konfigu-riert, geschützt sein. Sie sollten jedoch die folgenden Einschränkungen kennen, die sich auf die Sicherheit Ihrer sensiblen Daten auswirken können:

� NTFS-Berechtigungen stellen einen grundlegenden Schutz für die in den Konfigurationsdateien gespeicherten sensiblen Informationen dar. Wenn jedoch Konfigurationsdateien archiviert, vom Computer herunterkopiert oder über ein Netzwerk übermittelt werden, geht dieser Schutz verloren. Benutzen Sie immer die Verschlüsselung, um in diesen Fällen einen Schutz für die sensiblen Infor-mationen zu bieten.



� Jeder Code innerhalb eines IIS-Arbeitsprozesses kann Konfigurationsdaten, auf die der IIS-Arbeits-prozess zugreifen darf, verschlüsseln und entschlüsseln. Jeder IIS-Arbeitsprozess kann standard-mäßig alle Konfigurationsdaten entschlüsseln, die mit dem IIS-Standardverschlüsselungsanbieter (AesProvider) verschlüsselt wurden.

� Eine Verschlüsselung ist immer nur so sicher wie der Schlüssel, der zur Durchführung der Ver-schlüsselung verwendet wurde. Stellen Sie deshalb sicher, dass nur die Benutzer, die zur Durch-führung der Verschlüsselung autorisiert sind, auf den für die Verschlüsselung benötigten Schlüssel-container zugreifen können, und stellen Sie weiterhin sicher, dass dieser Schlüsselcontainer nicht kompromittiert wird, wenn er im Rahmen eines Exports den Computer verlässt.

In teilweise vertrauenswürdigen Umgebungen einen von verwaltetem Code ausgehenden Zugriff auf die Konfiguration einschränkenWenn ein Zugriff auf die IIS-Konfiguration von einem systemeigenen (nativen) Code aus erfolgt, bilden die für die Konfigurationsdateien festgelegten Berechtigungen die Basis für die Entscheidung, ob der Zugriff auf die Konfiguration gewährt wird. Systemeigene Module und andere im IIS-Arbeitsprozess ausgeführte Codesegmente können somit jede Konfiguration in der Konfigurationsdateihierarchie lesen, die nicht aufgrund einer Anwendungspoolisolation versteckt oder mit Verschlüsselungs-schlüsseln verschlüsselt wurde, auf die der IIS-Arbeitsprozess nicht zugreifen kann.

Wenn jedoch verwaltete Codemodule mithilfe der API Microsoft.Web.Administration auf die Konfi-guration zugreifen, ist es möglich, das Lesen einiger Konfigurationsabschnitte über die für die Anwen-dung konfigurierte CAS-Richtlinie (Code Access Security) weiter einzuschränken. Dies ist vergleich-bar mit dem Einsatz von CAS, um zu verhindern, dass Anwendungen, die aus verwaltetem Code bestehen, bestimmte Aktionen initiieren, die der hostenden Prozess normalerweise ausführen dürfte, z.B. Datei-zugriffe oder das Öffnen von Netzwerkverbindungen.

Sie können dieses Verfahren nutzen, um zu verhindern, dass teilweise vertrauenswürdige ASP.NET-Anwendungen auf die Informationen bestimmter Konfigurationsabschnitte zugreifen dürfen. Dazu wird das requirePermission-Attribut der Abschnittsdeklaration auf true gesetzt. Wenn dies geschieht, können nur voll vertrauenswürdige ASP.NET-Anwendungen und verwaltete Module die Inhalte dieser Konfigurations-abschnitte lesen. Weitere Informationen zum Setzen des requirePermission-Attributs in der Abschnitts-deklaration erhalten Sie im dreizehnten Kapitel und dort im Abschnitt »Konfigurationsabschnitte deklarieren«

Hinweis Das requirePermission-Attribut verhindert, dass eine Anwendung die Konfigurations-APIs nutzt, um die betreffenden Konfigurationsabschnitte zu lesen. Dies geschieht jedoch nur dann, wenn mit der teilweisen Vertrau-enswürdigkeit gearbeitet wird. Die Anwendung kann auch weiterhin direkt auf die entsprechende Datei zugreifen, wenn die CAS-Richtlinie und die Dateiberechtigungen dies zulassen. requirePermission lohnt sich deshalb nur in solchen Fällen, in denen Anwendungen mit einer mittleren oder einer noch niedrigeren Vertrauenswürdigkeit davon abgehalten werden sollen, die Inhalte von Konfigurationsabschnitten zu lesen, die sich außerhalb der Verzeich-nisstruktur der Anwendung befinden, z.B. in applicationHost.config. Die Anwendung kann dann weiterhin die in ihrer Verzeichnisstruktur verteilten web.config-Dateien öffnen, indem sie die entsprechenden Eingabe-/Ausgabe-APIs direkt verwendet.

Die IIS-Konfigurationsabschnitte werden standardmäßig nicht mit dem auf true gesetzten requirePer-mission-Attribut deklariert, so dass die Inhalte dieser Abschnitte von teilweise vertrauenswürdigen Anwendungen gelesen werden können. Diese Technik ist deshalb mehr für die Deklaration neuer Konfigurationsabschnitte geeignet.



Weitere Informationen zur Verwendung von ASP.NET-Vertrauensebenen, um die Ausführung von verwalteten Modulen und ASP.NET-Anwendungen einzuschränken, erhalten Sie früher in diesem Kapitel im Abschnitt »Einschränken der Vertrauenswürdigkeit von ASP.NET-Anwendungen«.

Kontrollieren der KonfigurationsdelegierungEines der wichtigsten Verwaltungsszenarien des IIS 7.0-Konfigurationssystems ist die Konfigurations-delegierung. Mit Konfigurationsdelegierung ist die Möglichkeit einer Website oder eines Anwendungs-besitzers gemeint, die benötigte IIS-Konfiguration für eine Anwendung angeben zu können, ohne auf dem Webservercomputer über administrative Rechte verfügen zu müssen. Dazu können mithilfe der Konfigurationsdateihierarchie von IIS 7.0 Konfigurationen in verteilten web.config-Dateien angegeben werden, die sich innerhalb der Verzeichnisstruktur der Website befinden und die dazu fähig sind, die auf der Serverebene festgelegten Konfigurationen außer Kraft zu setzen. Websites und Anwendungen werden auf diese Weise portierbar, weil sich die benötigten Konfigurationsdateien dort befinden, wo auch die Inhalte gespeichert sind, so dass eine Bereitstellung durch bloßes Kopieren zum Webserver möglich ist.

Würde sich die Konfigurationsdelegierung nach dem Prinzip »Alles oder Nichts« richten, würde sie wahrscheinlich nicht funktionieren, weil die meisten Websiteadministratoren nicht damit einverstanden wären, dass eine Website oder Anwendung die gesamte Konfiguration der Serverebene außer Kraft setzen könnte. Dies gilt besonders für Konfigurationsabschnitte, die sich auf die Sicherheit, Stabilität und Leistung des Webservers auswirken. Das IIS 7.0-Konfigurationssystem bietet deshalb viele Kon-trollmechanismen an, mit denen die Administratoren festlegen können, welche Konfigurations-abschnitte und spezifischen Konfigurationsattribute auf der Website- oder Anwendungsebene außer Kraft gesetzt werden dürfen. Wenn Sie einen Webserver verwalten, der es Dritten erlaubt, Anwen-dungsinhalte zu veröffentlichen, werden Sie sich wahrscheinlich mit der zulässigen Konfigurations-delegierung auseinander setzen und in einigen Fällen bestimmte Konfigurationen für die Delegierung sperren oder entsperren müssen.

Weiterhin stellt IIS 7.0 auch die Infrastruktur zur Verfügung, die von Website- und Anwendungsadmi-nistratoren genutzt wird, um Konfigurationen mithilfe des IIS-Managers remote zu verwalten, ohne auf dem Webservercomputer über administrative Rechte verfügen zu müssen. Auch hier können Sie als Serveradministrator genau kontrollieren, wer die Websites und Anwendungen auf Ihren Computern remote verwalten darf und welche Verwaltungsfeatures hierfür eingesetzt werden dürfen. Weitere Informationen zur Konfiguration von Remoteverwaltungsberechtigungen finden Sie im achten Kapitel.

Die zu delegierende Konfiguration festlegenDer Konfigurationsabschnitt ist das grundlegende Element der Konfigurationsdelegierung. Wenn ein Konfigurationsabschnitt erstmals deklariert wird, erhält er eine Kennzeichnung, die Aufschluss darüber gibt, ob eine Delegierung zulässig ist oder nicht. Dazu wird innerhalb der Abschnittsdeklarationen das overrideModeDefault-Attribut angegeben (den Wert dieses Attributs legt in der Regel der Entwickler fest; er gründet seine Entscheidung auf der Überlegung, ob der Abschnitt sensible Einstellungen enthält und deshalb nur von Administratoren modifiziert werden darf). Wenn der Abschnitt nicht für die Dele-gierung gekennzeichnet ist, führt jeder Versuch, ihn auf einer niedrigeren Ebene der Konfigurations-hierarchie zu konfigurieren, im Falle eines Zugriffs auf den Abschnitt zu einem Konfigurationsfehler.

Hinweis Weitere Informationen zur Deklaration von Konfigurationsabschnitten und dem overrideModeDefault-Attribut erhalten Sie im dreizehnten Kapitel und dort im Abschnitt »Konfigurationsabschnitte deklarieren«.



Alle IIS-Konfigurationsabschnitte sind standardmäßig in applicationHost.config deklariert. Jede Abschnittsdeklarationen gibt an, ob der Abschnitt delegiert werden kann. Ausschlaggebend für diese Entscheidung sind die Kriterien des Microsoft-IIS-Teams, die festlegen, ob der jeweilige Konfigura-tionsabschnitt sensible Einstellungen enthält. Diese Kriterien basieren auf der Überlegung, ob ein Konfigurationsabschnitt verwendet werden kann, um die Sicherheit, Stabilität oder Leistung des Webservers insgesamt zu beeinträchtigen oder ob eine Website bzw. Anwendung mithilfe dieses Abschnitts auf Informationen außerhalb ihres Gültigkeitsbereichs zugreifen kann.

Hinweis Sie können auch die Delegierung von .NET-Konfigurationsabschnitten verwalten, indem Sie mit dem IIS-Verwaltungsstack arbeiten. Sowohl IIS- als auch .NET-Konfigurationen verwenden dieselben Mechanismen zum Kontrollieren der Delegierung, zu denen auch die Abschnittsperrung und die spezifischere Konfigurationssperrung zählen. Weitere Informationen hierzu erhalten Sie im vierten Kapitel.

Die Standarddelegierung von IIS-Konfigurationsabschnitten ist in Tabelle 14.20 zu sehen.

Tabelle 14.20 Standarddelegierung von IIS-Konfigurationsabschnitten

Abschnitt Standardzustand Grund

system.applicationHost

applicationPools keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

configHistory keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

customMetadata keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

listenerAdapters keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

log keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

sites keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

webLimits keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

system.webServer

asp Verweigern Enthält sensible Einstellungen für ASP-Anwendungen, die sich auf die Sicherheit, Leistung und Stabilität auswirken

caching Zulassen

cgi Verweigern Sicherheitsrelevant: createProcessAsUser

defaultDocument Zulassen

directoryBrowse Zulassen

fastCgi keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

globalModules keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

handlers Verweigert; wird zugelas-sen, wenn die .NET-Erwei-terbarkeit installiert wird

Dient der Kompatibilität mit IIS 6.0; der Abschnitt wird entsperrt, sobald die .NET-Erweiterbarkeit installiert wird; lesen Sie im zwölften Kapitel den Abschnitt »Einschränken der Erweiterbarkeit«

httpCompression keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden.

httpErrors Verweigern Sicherheitsrelevant: Fehlerseiten können außerhalb der Anwendung angegeben werden



httpLogging Verweigern Sicherheitsrelevant: das Ausschalten der Protokollierung kann den Nach-weis verhindern, dass ein Benutzer eine bestimmte Aktion initiiert hat

httpProtocol Zulassen

httpRedirect Zulassen

httpTracing Verweigern Leistungsrelevant: Liste der nachzuverfolgenden ETW-URLs

isapiFilters keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

modules Verweigert; wird zuge-lassen, wenn die .NET-Erweiterbarkeit installiert wird

Dient der Kompatibilität mit IIS 6.0; der Abschnitt wird entsperrt, sobald die .NET-Erweiterbarkeit installiert wird; lesen Sie im zwölften Kapitel den Abschnitt »Einschränken der Erweiterbarkeit«

odbcLogging Verweigern Sicherheitsrelevant: Konfiguration der Protokollierung in externer Datenbank

serverRuntime Verweigern Enthält sensible Einstellungen für die Kernwebserverengine, die sich auf die Sicherheit, Leistung und Stabilität auswirken

serverSideInclude Verweigern Sicherheitsrelevant: die Aktivierung von serverseitigen Includes kann dazu beitragen, dass die Anwendung auf Inhalte außerhalb ihres Gültigkeitsbereichs zugreifen kann

staticContent Zulassen

urlCompression Zulassen

validation Zulassen

system.webServer/security

access Verweigern Sicherheitsrelevant: Konfiguration von SSL-Anforderungen

applicationDependencies keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

authorization Zulassen

ipSecurity Verweigern Sicherheitsrelevant: Festlegen, wer auf die Anwendung zugreifen darf

isapiCgiRestriction keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

requestFiltering Zulassen Achtung: delegiert, aber Anwendungen können den auf der Server-ebene konfigurierten grundlegenden Schutz entfernen, wodurch die Sicherheit verringert wird

system.webServer/security/authentication

anonymousAuthentication Verweigern Sicherheitsrelevant: Aktivieren oder Deaktivieren von Authentifizierungs-verfahren

basicAuthentication Verweigern Sicherheitsrelevant: Aktivieren oder Deaktivieren von Authentifizierungs-verfahren

clientCertificateMapping Authentication

Verweigern Sicherheitsrelevant: Aktivieren oder Deaktivieren von Authentifizierungs-verfahren

Tabelle 14.20 Standarddelegierung von IIS-Konfigurationsabschnitten (Fortsetzung)




Die Standarddelegierung von IIS-Konfigurationsabschnitten ist lediglich ein Vorschlag, der nicht immer übernommen werden muss. Wenn Sie es Dritten gestatten, Website- oder Anwendungskonfigurationen auf Ihrem Server zu veröffentlichen, sollten Sie darüber nachdenken, welche Auswirkungen die Dele-gierung der einzelnen Abschnitte haben könnte. Sie müssen ein Gleichgewicht zwischen den auf die Delegierung bezogenen Anwendungsanforderungen und der Notwendigkeit herstellen, den Webserver vor versehentlichen oder böswilligen Konfigurationsänderungen zu schützen. Dann können Sie Konfi-gurationsabschnitte für die Delegierung sperren oder entsperren oder eine noch spezifischere Konfigura-tionssperrung nutzen, um zwar eine Abschnittsdelegierung generell zuzulassen, aber bestimmte Konfi-gurationsattribute, -elemente oder -auflistungseinträge zu sperren.

Hinweis Informationen zum Sperren und Entsperren von Abschnitten und zur spezifischen Konfigurations-sperrung finden Sie im vierten Kapitel und dort in den Abschnitten »Konfigurationsdelegierung« und »Spezifische Konfigurationssperrung«.

Wenn Sie festlegen, welche Konfiguration delegiert werden soll, sollten Sie die nachstehenden Richtlinien befolgen:

� Lassen Sie, wenn möglich, die Konfigurationsabschnitte auf der Serverebene gesperrt, und sorgen Sie dafür, dass die Anwendung bestimmte Abschnitte bei Bedarf entsperrt. Sie können auch bestimmte Abschnitte für bestimmte Websites oder Anwendungen entsperren und für andere Websites und Anwendungen gesperrt lassen. Auf diese Weise vermeiden Sie unerwartete Konfigurationsänderungen auf der Anwendungsebene, und zwar selbst dann, wenn Sie keine Konfiguration an andere Parteien delegieren.

� Wenn Sie einen bestimmten Abschnitt entsperren, können Sie dennoch bestimmte Teile dieses Abschnitts sperren, wenn diese eine sensible Konfiguration oder Einstellungen enthalten, die nicht geändert werden sollen.

digestAuthentication Verweigern Sicherheitsrelevant: Aktivieren oder Deaktivieren von Authentifizierungs-verfahren

iisClientCertificate MappingAuthentication

Verweigern Sicherheitsrelevant: Aktivieren oder Deaktivieren von Authentifizierungs-verfahren

windowsAuthentication Verweigern Sicherheitsrelevant: Aktivieren oder Deaktivieren von Authentifizierungs-verfahren

system.webServer/ tracing

traceFailedRequests Zulassen

traceProviderDefinitions keine Angabe Abschnitt kann nur in applicationHost.config angegeben werden

Tabelle 14.20 Standarddelegierung von IIS-Konfigurationsabschnitten (Fortsetzung)




ZusammenfassungIIS 7.0 weist wie seine Vorgänger bestimmte Sicherheitsstandards auf, die auf dem Webserver das Risiko der Ausnutzung von Sicherheitslücken verringern. Wenn Sie Ihre Anwendungen auf dem Webserver bereitstellen und Konfigurationen ändern, sollten Sie mit der Konfiguration und den Features vertraut sein, damit Sie den Webserver nicht gefährden. In diesem Kapitel haben Sie erfahren, welche Änderungen für IIS 7.0 an der Sicherheit vorgenommen wurden und welche neuen Sicherheits-features verfügbar sind, um die Sicherheit des Webservers aufrechtzuerhalten.

Unglücklicherweise hat die Erfahrung gezeigt, dass die meisten Sicherheitslücken durch die auf dem Webserver ausgeführten Anwendungen und nicht durch den Webserver selbst entstehen. Anwendungen werden, verglichen mit Webserverfeatures, oft nur unzureichend getestet. Sie werden in der Regel mit einem kaum vorhandenen Wissen um die Angriffswege entwickelt, die für Webanwendungen exis-tieren. Deshalb ist es wichtig, das Bedrohungspotenzial zu kennen und Sicherheitstests auf der Anwen-dungsebene durchzuführen, um Anwendungssicherheitslücken zu minimieren.

Darüber hinaus ist es wichtig, zusätzlich einen Sicherheitsansatz zu wählen, der nicht auf spezifischen Anwendungsangriffswegen basiert. IIS 7.0 macht es möglich, solch einen Ansatz zu nutzen, indem die Angriffsfläche des Webservers verkleinert und die Anwendungskomponenten mit den geringstmög-lichen Berechtigungen ausgeführt werden. Zusammen können diese beiden Techniken die Gefahr der Ausnutzung von bekannten und zukünftigen Sicherheitslücken und den dadurch möglich werdenden Schaden minimieren. Wenn Sie die in diesem Kapitel vorgestellten empfohlenen Maßnahmen befolgen, können Sie diese Techniken erfolgreich auf Ihre Anwendung anwenden und so das Risiko einer Sicherheitsverletzung auf Ihren Webserver verringern.

Schließlich sollten Sie immer daran denken, dass ein Webserver nicht innerhalb eines Vakuums arbeitet. Seine Sicherheit ist von verschiedenen Windows-Subsystemen und von der Sicherheit abhängig, die das Netzwerk und die damit verbundenen Dienste bieten. Berücksichtigen Sie diese Sicherheit des gesam-ten Netzwerkes und der damit verbundenen Dienste, wenn Sie eine Webfarm aufbauen.

Weitere Informationen� Das vierte Kapitel, »Verstehen des Konfigurationssystems«, enthält weitere Informationen zur

Konfiguration von IIS 7.0.

� Das elfte Kapitel, »Hosting von Anwendungsentwicklungsframeworks«, informiert über die Ausführungs-berechtigungen von Anwendungsframeworks.

� Das zwölfte Kapitel, »Verwalten von Webservermodulen«, verrät, wie Webservermodule verwaltet und gesichert werden.

� Verbesserung der Webanwendungssicherheit: Gefährdungen und Gegenmaßnahmen: http://msdn2.microsoft.com/en-us/library/ms994921.aspx.

� http://www.iis.net.

� Das regelmäßig aktualisierte Blog http://www.mvolo.com behandelt IIS 7.0 und die Sicherheit.


509

T E I L I V

Problembehandlung und Leistungsoptimierung

In diesem Teil:Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511Ablaufverfolgung und Problembehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537Optimieren der Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577


511

K A P I T E L 1 5

Protokollierung

Inhalt dieses Kapitels:� Was ist neu? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

� Protokolldateiformate, die sich nicht verändert haben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

� Zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

� Remoteprotokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

� Konfigurieren der IIS-Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

� Http.sys-Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

� Anwendungsprotokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

� Ordnerkomprimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

� Protokollanalyse mit Log Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535



Auf der Begleit-CD Auf der Begleit-CD finden Sie weitere Tools und Informationen.

Protokolldateien von Webservern sind zugegebenermaßen nicht das prickelndste Thema, aber sie sind außerordentlich wichtig. Sie sind ein zentrales Hilfsmittel, zum Beispiel als Basis für Auswertungen in den Bereichen Rechnungserstellung, Zuverlässigkeit, Leistung, Überwachung und Forensik. Dieses Kapitel beschreibt die Protokollierung und zugehörige Features in Microsoft IIS 7.0.

Was ist neu?Wie in IIS 6.0 werden Protokolldateien auch in IIS 7.0 vom Kernelmodusgerätetreiber Http.sys ver-waltet. In diesem Dienst wird kein Benutzercode ausgeführt, weil Http.sys im Kernelmodus läuft. Generell hat sich an der Protokollierung nicht besonders viel geändert, aber Sie sollten die wenigen Unterschiede sowie einige neue Möglichkeiten kennen. Sie werden feststellen, dass IIS 7.0 viele Ver-besserungen im Bereich der Protokollierung enthält, die erst in Windows Server 2003 Service Pack 1 (SP1) eingeführt wurden. Zum Beispiel können Sie zentrale W3C-Protokollierung (World Wide Web Consortium) und binäre Protokollierung nutzen; Standardprotokollformate wie W3C Extended, NCSA (National Center for Supercomputing Applications) und IIS; oder die benutzerdefinierte Protokollierung.

Unter den interessantesten Features von IIS 7.0 sind seine modulare Architektur und die integrierte Pipeline. Die integrierte Pipeline wird in Kapitel 2, »Grundlagen der IIS 7.0-Architektur«, ausführlich beschrieben. Die Protokollierung profitiert von der Flexibilität, die durch die Modularität von IIS 7.0


512 Kapitel 15: Protokollierung

ermöglicht wird, und der integrierten Pipeline, weil Sie eigene Protokollierungsmodule schreiben und in die Pipeline einklinken können. Ihr benutzerdefiniertes Modul kann dann genau die Informationen aufzeichnen, die Sie für Ihre Anwendung brauchen.

IIS 7.0 enthält einige Änderungen, die im Zusammenhang mit der Protokollierung wichtig sind:

� Einstellungen zur Protokollierung konfigurieren Sie im Internetinformationsdienste-Manager

� Das neue Konfigurationssystem arbeitet auf der Basis von XML

� Es stehen eine Reihe neuer Protokollierungskonfigurationsoptionen und ein neuer Satz von Status-codes zur Verfügung

� IIS 7.0 stellt Protokollierung für einen neuen Dienst zur Verfügung, der die Remoteverwaltung eines IIS 7.0-Servers ermöglicht

Der Internetinformationsdienste-ManagerIIS 7.0 führt eine völlig neue Benutzeroberfläche ein, den Internetinformationsdienste-Manager. Der Internetinformationsdienste-Manager macht es einfacher, IIS-Einstellungen anzuzeigen und zu ver-ändern. Zu diesen Einstellungen gehört auch die Konfiguration der Protokollierung. Falls Sie zum Beispiel in IIS 6.0 die zentrale Protokollierung implementieren wollten, mussten Sie ADSUtil.vbs verwenden. Jetzt steht im Internetinformationsdienste-Manager die Möglichkeit zur Verfügung, die zentrale Protokollierung zu aktivieren (Abbildung 15.1).

Abbildung 15.1 Konfigurieren der zentralen Protokollierung im Internetinformationsdienste-Manager

Kapitel 6, »Verwenden von IIS-Manager«, beschreibt den Internetinformationsdienste-Manager genauer.


Was ist neu? 513

Das XML-Konfigurationsschema für die ProtokollierungIIS 7.0 nutzt ein neues Konfigurationssystem, das auf XML basiert und dem Konfigurationssystem von ASP.NET stark ähnelt. Jeder Konfigurationsabschnitt ist in XML-Schemadateien definiert, die im Ordner %SystemRoot%\system32\inetsrv\config\schema abgelegt sind. Die Details der Konfigurations-abschnitte werden in Kapitel 4, »Verstehen des Konfigurationssystems«, beschrieben. Weil die Daten in XML-Dateien definiert sind, können Sie ganz einfach ermitteln, welche Attribute, Elemente und Enumerationen verwendet werden. Das Schema für IIS 7.0 enthält eine Liste aller konfigurierbaren Optionen, daher genügt ein kurzer Blick in die Schemadatei, um alle konfigurierbaren Einstellungen für ein beliebiges Feature herauszufinden, etwa die Protokollierung.

Das folgende Listing zeigt den Abschnitt system.applicationHost/log aus der Datei %SystemRoot%\system32\ inetsrv\config\schema\IIS_Schema.xml. (Einige lange Zeilen wurden umbrochen, weil sie nicht auf die Buchseite passen.) Wie Sie sehen, definiert der XML-Code eindeutig die Namen und Datentypen für jedes Element.<sectionSchema name="system.applicationHost/log"> <attribute name="logInUTF8" type="bool" defaultValue="true" /> <attribute name="centralLogFileMode" type="enum" defaultValue="Site" > <enum name="Site" value="0"/> <enum name="CentralBinary" value="1"/> <enum name="CentralW3C" value="2"/> </attribute> <element name="centralBinaryLogFile"> <attribute name="enabled" type="bool" defaultValue="false" /> <attribute name="directory" type="string" expanded="true" defaultValue="%SystemDrive%\inetpub\logs\LogFiles" /> <attribute name="period" type="enum" defaultValue="Daily"> <enum name="Hourly" value="4"/> <enum name="Daily" value="1"/> <enum name="Weekly" value="2"/> <enum name="Monthly" value="3"/> <enum name="MaxSize" value="0"/> </attribute> <attribute name="truncateSize" type="int64" defaultValue="20971520" validationType="integerRange" validationParameter="1048576,4294967295" /> <attribute name="localTimeRollover" type="bool" defaultValue="false"/> </element> <element name="centralW3CLogFile"> <attribute name="enabled" type="bool" defaultValue="true" /> <attribute name="directory" type="string" expanded="true" defaultValue="%SystemDrive%\inetpub\logs\LogFiles" validationType="nonEmptyString" /> <attribute name="period" type="enum" defaultValue="Daily"> <enum name="Hourly" value="4"/> <enum name="Daily" value="1"/> <enum name="Weekly" value="2"/> <enum name="Monthly" value="3"/> <enum name="MaxSize" value="0"/> </attribute> <attribute name="truncateSize" type="int64" defaultValue="20971520" validationType="integerRange" validationParameter="1048576,4294967295" />



<attribute name="localTimeRollover" type="bool" defaultValue="false"/> <attribute name="logExtFileFlags" type="flags" defaultValue="Date, Time, ClientIP, UserName, SiteName, ServerIP, Method, UriStem, UriQuery, HttpStatus, Win32Status, ServerPort, UserAgent, HttpSubStatus"> <flag name="Date" value="1"/> <flag name="Time" value="2"/> <flag name="ClientIP" value="4"/> <flag name="UserName" value="8"/> <flag name="SiteName" value="16"/> <flag name="ComputerName" value="32"/> <flag name="ServerIP" value="64"/> <flag name="Method" value="128"/> <flag name="UriStem" value="256"/> <flag name="UriQuery" value="512"/> <flag name="HttpStatus" value="1024"/> <flag name="Win32Status" value="2048"/> <flag name="BytesSent" value="4096"/> <flag name="BytesRecv" value="8192"/> <flag name="TimeTaken" value="16384"/> <flag name="ServerPort" value="32768"/> <flag name="UserAgent" value="65536"/> <flag name="Cookie" value="131072"/> <flag name="Referer" value="262144"/> <flag name="ProtocolVersion" value="524288"/> <flag name="Host" value="1048576"/> <flag name="HttpSubStatus" value="2097152"/> </attribute> </element> </sectionSchema>

Konfigurationsoptionen für zentrale ProtokollierungDer folgende Ausschnitt zeigt den Abschnitt der Datei applicationHost.config, der die Optionen für die zentrale Protokollierung steuert. Sie können diese Einstellungen so ändern, dass Ihre Dateien auf einem anderen Laufwerk oder Volume gespeichert werden, und die gewünschten Optionen aktivieren bezie-hungsweise deaktivieren.<log> <centralBinaryLogFile enabled="true" directory="%SystemDrive%\inetpub\logs\LogFiles" /> <centralW3CLogFile enabled="true" directory="%SystemDrive%\inetpub\logs\LogFiles" /> </log>

Standardkonfiguration für neue SitesDer siteDefaults-Abschnitt in der Datei applicationHost.config steuert, welche Protokollierungseinstel-lungen verwendet werden, wenn Sie neue Sites erstellen. Wie im folgenden Ausschnitt gezeigt, können Sie zwei Optionen konfigurieren: das Format der Protokolldatei und den Speicherort, in dem Ablaufver-folgungsdateien zu fehlgeschlagenen Anforderungen abgelegt werden.


Was ist neu? 515

<siteDefaults> <logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" /> <traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" /> </siteDefaults>

Konfigurationsoptionen zum Deaktivieren der HTTP-ProtokollierungIn manchen Fällen braucht der IIS-Administrator keine Protokolldateien. Falls Sie die HTTP-Proto-kollierung auf Serverebene ausschalten wollen, können Sie die Protokollierung im Internetinforma-tionsdienste-Manager deaktivieren. Sie können die Protokollierung auch auf Siteebene deaktivieren. Falls Sie sich fragen, wozu diese Optionen gut sein sollen: Sie können auf diese Weise die Protokol-lierung auf Ihren Test- oder Entwicklungscomputern deaktivieren und so den Platzverbrauch durch nicht benötigte Dateien verringern.

Bevor Sie die HTTP-Protokollierung deaktivieren, sollten Sie diesen Schritt mit dem Management oder der Rechtsabteilung abklären und prüfen, welche Anforderungen und Richtlinien in Ihrem Unterneh-men für die Protokollierung gelten. Der Standardwert für diese Einstellung ist false, wie im folgenden Ausschnitt zu sehen:<httpLogging dontLog="false" />

Hinweis Weitere Informationen über die Optionen in system.webServer/httpLogging finden Sie im Abschnitt »Gegenmaßnahmen« in Kapitel 17, »Optimieren der Leistung«.

Standardspeicherort der ProtokolldateienEine der deutlichsten Änderungen in IIS 7.0 ist, dass WWW-Protokolle jetzt im Ordner %SystemDrive%\ inetpub\logs\LogFiles gespeichert werden. Zum Beispiel liegen die Protokolle der Standardwebsite in C:\inetpub\logs\LogFiles\w3svc1. Das bedeutet, dass bei IIS 7.0 in der Standardeinstellung alle Proto-kolldateien im selben Ordner gespeichert werden. Beachten Sie aber, dass Protokolldateien für die eingebauten Legacy-FTP- (File Transfer Protocol) und SMTP-Dienste (Simple Mail Transfer Protocol) weiterhin in %windir%\System32\Logfiles liegen. Sie können diese Dateien im Internetinformations-dienste-Manager 6.0 verwalten; diese MMC-Konsole wird mitinstalliert, wenn Sie den Legacy-FTP-Dienst oder den SMTP-Dienst installieren.

Hinweis Der neue FTP-Publishingdienst für IIS 7.0 speichert seine Protokolldateien standardmäßig in %Sys-temDrive%\inetpub\logs\LogFiles. Sie müssen dieses Add-On gesondert herunterladen und installieren, da es nicht in IIS 7.0 enthalten ist. Die x86- und x64-Versionen stehen unter http://www.iis.net zur Verfügung. Klicken Sie auf Download und suchen Sie nach »Microsoft FTP Publishing Service for IIS 7.0«.

UTF-8-KodierungIn der Standardeinstellung speichert IIS 7.0 Protokolldateien in UTF-8-Kodierung. Dadurch wird die Konvention für Dateinamen geändert, sodass die Dateinamen mit »u_« beginnen (zum Beispiel u_exJJMMTT.log). Hier der Abschnitt der Datei IIS_Schema.xml, der die UTF-8-Kodierung einstellt. Die Standardeinstellung ist true.



<sectionSchema name="system.applicationHost/log"> <attribute name="logInUTF8" type="bool" defaultValue="true" /> ... </sectionSchema>

Bei der UTF-8-Kodierung kann der Text Zeichen umfassen, die aus einem einzigen Byte oder mehreren Bytes bestehen. Diese Kodierung ermöglicht Ihnen, Textprotokolle (zum Beispiel Protokolle in den Formaten W3C Extended, IIS und NCSA Common) in anderen Sprachen als Englisch zu lesen. Für den eingebauten FTP-Publishingdienst unterstützt IIS keine Protokolldateien im UTF-8-Format. Die UTF-8-Kodierung steht auch in IIS 6.0 zur Verfügung, ist dort aber nicht standardmäßig aktiviert. Falls Sie für Ihre Protokolle nicht die UTF-8-Kodierung verwenden wollen, können Sie ANSI als Format wählen.

Neue StatuscodesIn IIS 7.0 wurden neue Statuscodes für HTTP und FTP eingeführt. Diese zusätzlichen Fehlercodes liefern ausführlichere Details über Ereignisse und bessere Beschreibungen, wie Fehler beseitigt werden können, inklusive Vorschlägen, welche Einstellungen Sie prüfen und welche Schritte Sie durchführen sollten. Anhang A enthält eine vollständige Liste aller Statuscodes.

VerwaltungsdienstIIS 7.0 führt den Verwaltungsdienst (engl. management service) ein, der es Computer- und Domänen-administratoren ermöglicht, im Remotezugriff einen anderen Computer im Internetinformations-dienste-Manager zu verwalten. Der Verwaltungsdienst ermöglicht es auch Benutzern, die keine Administratoren sind, Sites und verschiedene Anwendungen mithilfe des Internetinformationsdienste-Managers von einer Arbeitsstation aus zu steuern.

Dieser Dienst hat seine eigenen Protokolle, die Informationen im Zusammenhang mit dem Verwal-tungsdienst aufzeichnen. Dieser Dienst wird nicht standardmäßig installiert. Falls Sie diesen Dienst installieren und aktivieren, werden die Protokolle in %SystemDrive%\inetpub\logs\WMSvc gespeichert.

Sie sollten sicherstellen, dass die Protokollierung für den Verwaltungsdienst aktiviert ist. Die Protokolle helfen Ihnen, Probleme zu überwachen und zu beseitigen, die auftreten, wenn Clients versuchen, eine Verbindung zu Ihrem Server aufzubauen. Der Verwaltungsdienst wird in Kapitel 8, »Remoteverwaltung«, ausführlich beschrieben.

Protokolldateiformate, die sich nicht verändert habenIIS 7.0 unterstützt alle verbreiteten Protokollformate, die in älteren IIS-Versionen zur Verfügung standen. An den folgenden Protokolldateiformaten gibt es in IIS 7.0 keine Änderungen:

� Microsoft IIS

� NCSA

� W3Svc Extended

Hinweis Beschreibungen, Erläuterungen und Beispiele zu diesen Protokollformaten erhalten Sie, wenn Sie auf http://msdn2.microsoft.com den Suchbegriff »IIS logging formats« eingeben.


Remoteprotokollierung 517

Zentrale ProtokollierungDie zentrale Protokollierung in IIS 7.0 funktioniert genauso wie in IIS 6.0. Sie können diese Option jetzt aber im Internetinformationsdienste-Manager konfigurieren. Wählen Sie dazu im Startmenü Verwaltung und dann Internetinformationsdienste-Manager. Klicken Sie auf den Computernamen und suchen Sie im Abschnitt IIS den Eintrag Protokollierung.

Auf diese Weise können Sie die Administrationskosten senken, weil es nur eine IIS-Protokolldatei gibt. Falls Sie Binärprotokollierung verwenden, kann das Protokoll in einer viel kleineren Datei gespeichert werden als bei Verwendung einer entsprechenden Textprotokolldatei.

W3C-Format für die zentrale ProtokollierungZentrale W3C-Protokollierung wurde in Windows Server 2003 SP1 eingeführt. Zentrale W3C-Proto-kollierung ist eine Einstellung auf Serverebene. Wenn Sie dieses Feature auf einem Server aktivieren, schreiben alle Websites auf diesem Server Protokolldaten in eine zentrale Protokolldatei. Die Daten werden im W3C Extended-Format in der Protokolldatei gespeichert. Sie können diese Einstellung im Internetinformationsdienste-Manager oder mit Appcmd aktivieren. Wenn Sie zentrale W3C-Protokol-lierung verwenden, können Sie sich die Protokolldatei mit einem Texteditor ansehen, zum Beispiel dem Windows-Editor.

Hinweis Die zentrale W3C-Protokollierung verwendet das W3C Extended-Protokollformat, das vier Felder enthält: HostHeader, Cookie, UserAgent und Referrer. Diese Felder stehen bei der zentralen Binärprotokollierung nicht zur Verfügung.

Binärformat für die zentrale ProtokollierungDie zentrale Binärprotokollierung ist im Wesentlichen dasselbe wie die zentrale W3C-Protokollierung, allerdings verwendet die Protokolldatei ein proprietäres Binärformat. Weil die gespeicherte Datei im Binärformat vorliegt, ist sie kleiner als eine entsprechende Textdatei. Sie können auf diese Weise also Festplattenplatz sparen. Sie können eine solche Datei nicht in einem Texteditor lesen, sondern müssen sie von einem Programm auswerten lassen, damit Sie sinnvolle Informationen erhalten. Das ist aber kein Problem, wenn Sie das Tool Log Parser verwenden, das zentrale Protokolle im Binärformat nativ liest. Das Tool Log Parser wird weiter unten in diesem Kapitel genauer beschrieben.

Wichtig Die integrierten FTP- und SMTP-Dienste bieten keine Unterstützung für die zentrale W3C-Protokollierung.

RemoteprotokollierungIIS 7.0 bietet die Möglichkeit, Protokolldateien in eine Netzwerkfreigabe zu schreiben. Auf diese Weise können Sie Ihre Protokolldateien in Echtzeit auf einem Remotecomputer speichern. Nehmen wir an, Sie haben eine Webfarm für die zentrale Protokollierung konfiguriert. Der Remotedateiserver ist ein Server, der DFS (Distributed File System, verteiltes Dateisystem) ausführt. DFS bietet mehrere Vorteile, darun-ter einen zentralen Speicherort zum Sammeln Ihrer Protokolldateien und automatische Replikation der Protokolle an mehrere Orte. Wenn Sie die Protokolle auf diese Weise an einem primären Speicherort sammeln, wird die Berichterstellung deutlich einfacher.



Wichtig Wenn Sie Ihre Remoteprotokollierungsumgebung einrichten, müssen Sie sicherstellen, dass die Host- (A) und Zeiger-DNS-Einträge (PTR) so konfiguriert sind, dass Authentifizierung und Auflösung richtig durchgeführt werden. So vermeiden Sie Probleme wie etwa Kerberos-Authentifizierungsfehler, wenn Http.sys versucht, Protokoll-dateien zu schreiben.

Sie richten die Remoteprotokollierung in Form eines UNC-Pfads (Universal Naming Convention) ein. Dafür können Sie entweder den Internetinformationsdienste-Manager oder Appcmd verwenden.

Einrichten der Remoteprotokollierung mit dem Internetinformationsdienste-ManagerGehen Sie folgendermaßen vor, um die Remoteprotokollierung mit dem Internetinformationsdienste-Manager zu aktivieren:

1. Erstellen Sie ein Verzeichnis namens IISLogs auf dem Remoteserver, in dem die Protokolldateien gespeichert werden. Dieser Computer liegt normalerweise in derselben Domäne wie die Webserver. Falls sich der Remoteserver nicht in derselben Domäne befindet oder ein eigenständiger Computer ist, können Sie der Anleitung im folgenden Textkasten folgen, um Ihre Dateien auf einem Remote-computer speichern zu lassen.

Verwenden einer NULL-Sitzung für RemoteprotokollierungFalls Ihr Remoteserver in einer anderen Domäne liegt, können Sie eine NULL-Sitzung einrichten, um die Remoteprotokollierung zu ermöglichen. Die folgende Anleitung beschreibt, wie Sie eine solche Umgebung einrichten. Falls Ihr Remoteserver nicht in einer anderen Domäne liegt, können Sie diese Schritte überspringen und gleich mit Schritt 2 der Anleitung zum Einrichten der Remote-protokollierung mit dem Internetinformationsdienste-Manager weitermachen.

Bevor Sie Ihre Umgebung einrichten, müssen Sie sicherstellen, dass beide Computer ihre Namen gegenseitig über DNS, WINS oder benutzerdefinierte Einträge in der lokalen HOSTS-Datei auflösen können. Diese Anleitung setzt voraus, dass beide Server unter Windows Server 2008 laufen.

1. Suchen Sie die zwei Computer aus, die Sie als Webserver und Dateiserver verwenden. Diese Rollen müssen auf physisch getrennten Computern laufen.

2. Legen Sie auf Ihrem Dateiserver einen Ordner namens IISLogs an, geben Sie ihn frei und stellen Sie die benötigte Ordnersicherheit ein.

a. Öffnen Sie auf dem Dateiserver eine Eingabeaufforderung und geben Sie den Befehl mkdir c:\IISLogs ein.

b. Geben Sie den Befehl net share IISLogs=c:\IISLogs /Grant:Jeder,FULL ein.

c. Geben Sie den Befehl cacls c:\IISLogs /G Administratoren:F SYSTEM:F Jeder:C ein.

d. Geben Sie j ein, wenn die Eingabeaufforderung »Sind Sie sicher (J/N)?« angezeigt wird.

e. Es wird die Meldung »Bearbeitetes Verzeichnis: c:\IISLogs« angezeigt.

3. Konfigurieren Sie die Protokollierung für Ihre Website, indem Sie den folgenden Befehl ausführen:appcmd set sites "Websitename" -logFile.directory:\\Dateiservername\IISLogs



2. Geben Sie den Ordner IISLogs frei, den Sie in Schritt 1 angelegt haben. Ändern Sie die Freigabe-berechtigungen, sodass zumindest die Gruppe Administratoren des Remotecomputers und das Konto, das die Protokolldateien schreibt, Vollzugriff erhalten. Ändern Sie die NTFS-Berechtigun-gen so, dass die Gruppe Administratoren des Remotecomputers und das Konto, das die Protokoll-dateien schreibt, die Berechtigung Ändern besitzen. Diese Anleitung geht davon aus, dass Sie für Ihren Anwendungspool das Konto NETZWERKDIENST verwenden und dass sich Remoteserver und Webserver in derselben Domäne befinden.

Hinweis Wenn das Konto NETZWERKDIENST auf eine Remoteressource zugreift, verwendet es das Computer-konto, das im Active Directory-Domänendienst gespeichert ist, um auf den Protokollordner zuzugreifen.

3. Öffnen Sie im Internetinformationsdienste-Manager den Knoten Ihrer Website und geben Sie den UNC-Pfad des Servers ein. Klicken Sie dazu im Startmenü auf Verwaltung und dann auf Internet-informationsdienste-Manager. Wählen Sie im linken Fensterabschnitt den Computernamen aus und klicken Sie im Abschnitt IIS doppelt auf das Symbol Protokollierung. Geben Sie im Textfeld Verzeich-nis den Pfad der Freigabe in der Form \\Servername\Freigabename ein, wie in Abbildung 15.2 gezeigt.

Hinweis Sie können auch die Syntax \\FQDN\Freigabename verwenden, um den Protokollpfad anzugeben. Allerdings können Probleme auftreten, falls Sie den Pfad in der Form \\IP-Adresse\Freigabename eingeben. In die-sem Fall kann ein Authentifizierungsproblem verhindern, dass die Protokolldateien erstellt werden. Das folgende Beispiel zeigt einen Fehler, der beim Versuch generiert wurde, die Remoteprotokollierung mithilfe einer IP-Adresse zu aktivieren:

Microsoft-Windows-HttpService, LogFileCreateFailed, 49, 0, 16, 2, 59, 9, 0x0000000000000800, 0x00000004, 0x000005AC, 0, , , {00000000-0000-0000-0000-000000000000}, , 128277049412643098, 220, 0, 0xC0000022, "ResponseLogging", "Site", "W3C", "\dosdevices\UNC\192.168.0.125\UncLogFiles\W3SVC1\u_ex070630.log", 0

4. Klicken Sie auf Übernehmen.

5. Rufen Sie im Webbrowser eine Webseite Ihrer Site auf.

4. Öffnen Sie auf dem Dateiserver die lokale Sicherheitsrichtlinie, indem Sie im Startmenü auf Verwaltung und dann Lokale Sicherheitsrichtlinie klicken und den Knoten Lokale Richtlinien/Sicherheitsoptionen öffnen:

a. Aktivieren Sie die Richtlinie Netzwerkzugriff: Die Verwendung von "Jeder"-Berechtigungen für anonyme Benutzer ermöglichen.

b. Fügen Sie die Freigabe IISLogs zur Richtlinie Netzwerkzugriff: Freigaben, auf die anonym zugegriffen werden kann hinzu.

5. Rufen Sie Ihre Website auf dem Webserver im Browser auf, indem Sie die Adresse http://local-host/ eingeben.

6. Öffnen Sie auf dem Webserver eine Eingabeaufforderung und geben Sie den folgenden Befehl ein:netsh http flush logbuffer

7. Prüfen Sie, ob die Anforderung in Ihren Protokolldateien eingetragen ist.



6. Öffnen Sie eine Eingabeaufforderung mit erhöhten Privilegien und geben Sie den Befehl netsh http flush logbuffer ein. Falls dies das erste Mal war, dass Einträge protokolliert wurden, erstellt Http.sys den Ordner und eine Protokolldatei. Öffnen Sie die Protokolldatei im Editor und prüfen Sie, ob Ein-träge für Ihren Testaufruf aufgezeichnet wurden.

Abbildung 15.2 Aktivieren der Remoteprotokollierung für die Standardwebsite

Einrichten der Remoteprotokollierung mit AppcmdSie können auch Appcmd verwenden, um den Speicherort der Protokolldateien für eine bestimmte Website festzulegen. Die Syntax zum Konfigurieren der Remoteprotokollierung mit UNC-Pfaden in Appcmd sieht folgendermaßen aus:// Einstellen des Protokollpfads für die Standardwebsite mit Appcmd appcmd set sites "Default Web Site" -logFile.directory:\\RemoteServerCMD.Contoso.com\LogFiles

Hinweis Sie können die Konfiguration der Remoteprotokollierung automatisieren, indem Sie diese Anweisung in ein Skript einfügen, dem Sie beim Aufruf die gewünschten Argumente übergeben.

Wenn Sie diesen Befehl ausführen, erhalten Sie die folgende Ausgabe:Das SITE-Objekt "Default Web Site" wurde geändert.

Remoteprotokollierung mit dem FTP-7.0-PublishingdienstDer FTP-7.0-Publishingdienst ist ein separat herunterladbares Add-On, das den eingebauten FTP-Dienst ersetzen soll. Der FTP-7.0-Publishingdienst bietet die Möglichkeit, Protokolle auf einem Remotecom-puter zu speichern. Das macht es Ihnen einfacher, Sicherheitsvorfälle zu analysieren. Nehmen wir an, ein bestimmter Computer wurde kompromittiert, aber Sie haben Ihre Protokolle auf einem Remotesystem gespeichert. Wenn der Angreifer versucht, seine Spuren zu verwischen, indem er die lokalen Protokoll-



dateien löscht, hat er keinen Zugriff auf die Protokolldateien des FTP-7.0-Publishingdienstes, weil sie in einer Remotefreigabe gespeichert sind. Falls Ihre Remotefreigabe mit DFS arbeitet, können die Protokoll-dateien sogar in mehrere Speicherorte repliziert werden. Remoteprotokollierung mit Replikation kann Ihnen bei der Forensik helfen. Damit die FTP-Protokolle auf einem Remoteserver gespeichert werden, brauchen Sie lediglich den Remoteserver, auf dem die Protokolldateien abgelegt werden, genauso zu konfigurieren wie einen Webserver. Abbildung 15.3 zeigt, wie der FTP-7.0-Publishingdienst so konfi-guriert wird, dass er Protokolle in einem Remotesystem speichert.

Abbildung 15.3 Konfigurieren des FTP-7.0-Publishingdienstes, sodass er Protokolldateien auf einem Remotecomputer speichert

Benutzerdefinierte ProtokollierungDank der modularen Architektur von IIS 7.0 können Sie eigene Protokollierungsmodule implemen-tieren oder vorhandene Protokollierungsfunktionen erweitern oder ersetzen. Ihr Modul kann direkt in der Anforderungspipeline implementiert werden. Es kann entweder ein natives Modul sein oder in verwaltetem Code geschrieben sein. Sie können jede beliebige .NET-Sprache verwenden, zum Beispiel C# oder Microsoft Visual Basic.NET.



Direkt von der Quelle: Implementieren eines SQL-ProtokollierungsmodulsDieses Beispiel stammt von Carlos Aguilar Mares und Andrew Lin. Es zeigt eine Technik, die Sie nur mit IIS 7.0 und der integrierten Pipeline nutzen können. Als Vorbereitung müssen Sie Ihr System folgendermaßen einrichten:

� Laden Sie Visual Studio Web Developer Express herunter und installieren Sie es.

� Laden Sie SQL Server Express herunter und installieren Sie es (als Komponente der vorherigen Installation).

� Laden Sie SQL Server Management Studio Express herunter und installieren Sie es.

Hinweis Eine ausführliche Anleitung zu diesem Beispiel finden Sie auf der Begleit-CD in der Datei Implement a SQL Logging module-details.doc. Sie können diese Datei auch unter der Adresse http://blogs.iis.net/bills/archive/2007/05/01/building-an-iis7-sql-logging-module-withnet.aspx herunterladen.

Sie müssen IIS 7.0 unter Windows Vista oder Windows Server 2008 ausführen, außerdem muss ASP.NET oder zumindest .NET-Erweiterbarkeit installiert sein.

Erstellen Sie erst einmal ein einfaches Modul mit einem fest einprogrammierten Verbindungsstring. Legen Sie die Datenbank mit SQL Server Management Studio an (ein Skript namens sqlLogging_ CreateDB.sql finden Sie auf der Begleit-CD). Warten Sie, bis die Datenbank erstellt wurde, und legen Sie dann ein Modul an, das eine Verbindung zu dieser Datenbank herstellt. Legen Sie in Ihrer Website/Anwendung das Verzeichnis App_Code an und speichern Sie darin sqlLoggingModule.cs als erste Codedatei (ebenfalls auf der Begleit-CD).

Bevor Sie das Modul nutzen können, müssen Sie es in IIS registrieren. Öffnen Sie die Seite Module der Site/Anwendung und klicken Sie auf Verwaltetes Modul hinzufügen. Rufen Sie eine Seite Ihrer Site auf. Daraufhin müsste die Anforderung in der Tabelle protokolliert werden, sofern alles ein-wandfrei funktioniert.

Jetzt können Sie die Konfigurationserweiterbarkeit implementieren. Erstellen Sie dazu eine neue Datei unter dem Namen sqlLogging_schema.xml (auf der Begleit-CD enthalten) und speichern Sie sie im Verzeichnis %SystemRoot%\system32\inetsrv\config\schema. Anschließend müssen Sie diese Datei in %SystemRoot%\system32\inetsrv\config\applicationHost.config registrieren. Fügen Sie dazu den folgenden Abschnitt unter sectionGroup name=system.webServer ein: <sectionGroup name="system.webServer"> <section name="sqlLogging" overrideModeDefault="Allow" />

An Ihrem Modul müssen Sie einige Änderungen vornehmen. Erstens müssen Sie den grässlichen fest einprogrammierten Verbindungsstring entfernen und in Ihre Web.config verlegen. Öffnen Sie Web.config im Editor und fügen Sie den Verbindungsstring folgendermaßen ein, wobei Sie billsiis7demo durch den Namen Ihres Computers ersetzen: <sqlLogging connectionString="server=billsiis7demo\sqlexpress;database=MIX;uid=sa;pwd=sa" />


Konfigurieren der IIS-Protokollierung 523

Konfigurieren der IIS-ProtokollierungIIS 7.0 stellt mehrere Wege zur Verfügung, um Ihre Webserver zu konfigurieren und zu verwalten. Dazu gehören auch Möglichkeiten, Ihre Protokollierungseinstellungen zu konfigurieren. Dieser Abschnitt beschreibt, wie Sie die Protokollierungseinstellungen mithilfe der grafischen Benutzeroberfläche (Graphical User Interface, GUI) und Befehlszeilentools konfigurieren. Sie lernen dabei die Bedienung des Internetinformationsdienste-Managers, des Tools Appcmd und der Windows PowerShell.

Internetinformationsdienste-ManagerDer Internetinformationsdienste-Manager ist ein von Grund auf neu geschriebenes Tool, mit dem Admi-nistratoren ihre Webserver verwalten können. Die intuitive Bedienoberfläche ermöglicht Ihnen, alle Einstellungen schnell anzusehen und zu verändern. Dazu gehören auch die Einstellungen für Protokoll-dateien. Gehen Sie folgendermaßen vor, um die Protokollierungseinstellungen im Internetinformations-dienste-Manager zu konfigurieren:

1. Klicken Sie im Startmenü auf Verwaltung und dann auf Internetinformationsdienste-Manager. Wählen Sie in der Strukturansicht den Servernamen aus. Abbildung 15.4 zeigt die Konsole, während das Symbol für die globalen Protokollierungseinstellungen ausgewählt ist.

Jetzt können Sie endlich Ihr Modul fertig stellen. Ersetzen Sie zuerst den fest einprogrammierten Verbindungsstring durch einen Aufruf der Methode GetConnectionString(httpContext). Das sieht folgen-dermaßen aus:private string GetConnectionString(HttpContext httpContext) { ConfigurationSection section = WebConfigurationManager.GetSection( "system.webServer/sqlLogging"); return (string)section["connectionString"]; }

Vergessen Sie nicht, am Anfang Ihrer .cs-Datei die Anweisung using Microsoft.Web.Administration einzufügen. (Unter Umständen müssen Sie erst einen Verweis auf %SystemRoot%\system32\inetsrv\ Microsoft.Web.Administration.dll hinzufügen.) Sie können nicht nur mithilfe von Microsoft.Web.Admi-nistration in Ihrem neuen Konfigurationsabschnitt lesen und schreiben (genau wie beim Aufruf von GetConnectionString(httpContext) im letzten Codeausschnitt), sondern auch Appcmd.exe (das Befehls-zeilentool) und VB/JScript über COM nutzen.

Und damit sind Sie auch schon fertig! Ein SQL-Protokollierungsmodul, geschrieben in .NET mit 66 Codezeilen und mit einem IIS 7.0-Konfigurationsabschnitt, der über Skripts, von Programmcode aus und in der Befehlszeile verwaltet werden kann.

Bill StaplesMicrosoft Product Unit Manager

Carlos Aguilar MaresMicrosoft Senior Development Lead



Abbildung 15.4 Im Internetinformationsdienste-Manager ist das Symbol für die globale Protokollierungskonfiguration ausgewählt

2. Klicken Sie doppelt auf das Symbol Protokollierung, um die Oberfläche anzuzeigen, in der Sie die Protokollierungseinstellungen für den Server konfigurieren.

Abbildung 15.5 zeigt die Standardeinstellungen. Weil in der Strukturansicht im linken Fensterab-schnitt der Knoten des Servers ausgewählt ist, werden diese Einstellungen an alle Websites vererbt, die auf dem Server eingerichtet werden.

3. Änderungen nehmen Sie vor, indem Sie die jeweilige Dropdownliste öffnen und die gewünschte Einstellung wählen. Zum Beispiel stellen Sie den Server von Protokollierung auf Siteebene (Erstel-len einer Protokolldatei pro Site) auf Protokollierung auf Serverebene (Erstellen einer Protokoll-datei pro Server) um, indem Sie in der Dropdownliste Eine Protokolldatei pro den Eintrag Server auswählen (Abbildung 15.6).

In IIS 6.0 müssen Sie ein Skript schreiben, um die Metabasiseigenschaft CentralW3CLoggingEnabled zu ändern. Das ist ein Beispiel, das beweist, dass der Internetinformationsdienste-Manager leistungs-fähiger und einfacher bedienbar ist als in der Vorgängerversion von IIS. (Weitere Informationen über diese Metabasiseigenschaft erhalten Sie, wenn Sie http://technet.microsoft.com aufrufen und nach »CentralW3CLoggingEnabled« suchen.)



Abbildung 15.5 Globale Standardeinstellungen

Abbildung 15.6 Ändern der Protokollierung von Siteebene auf Serverebene im Internetinformationsdienste-Manager



Hinweis Wenn Sie IIS 7.0 so konfigurieren, dass es mit Protokollierung auf Serverebene arbeitet, ist in der Stan-dardeinstellung das Format Binär ausgewählt. Wenn Sie Ihr Protokoll auf Serverebene im W3C Extended-Format schreiben wollen, brauchen Sie lediglich in der Dropdownliste Format den Eintrag W3C auszuwählen.

IIS 7.0 gibt Ihnen auch die Möglichkeit, jede einzelne Website individuell zu konfigurieren. Klicken Sie zum Beispiel auf die Schaltfläche Felder auswählen, um festzulegen, welche Details für die ausge-wählte Website protokolliert werden. In Abbildung 15.7 sind unter anderem die Einträge Gesendete Bytes (sc-bytes), Empfangene Bytes (cs-bytes), Zeitraum (time-taken) und Referenz (cs(Referer) akti-viert. Sie können außerdem das Verzeichnis für die Protokolldateien, Einstellungen für das Protokoll-dateirollover und die Verwendung der lokalen Zeit für Dateibenennung und Rollover konfigurieren.

Abbildung 15.7 Nach Anklicken der Schaltfläche Felder auswählen können Sie einstellen, welche Details zu einer bestimmten Website protokolliert werden

AppcmdDer Internetinformationsdienste-Manager eignet sich hervorragend, um einzelne Einstellungen zu ver-walten, die eine GUI zur Verfügung stellen. Appcmd ist ein Tool, mit dem sich alle administrativen Aufgaben über eine Befehlszeile ausführen lassen. Appcmd ersetzt eine Vielzahl von Skripts und Tools, die in älteren IIS-Versionen verwendet wurden.

Alle Protokollierungseinstellungen, die Sie unter Umständen anpassen müssen, liegen in drei Abschnitten der Datei applicationHost.config: system.applicationHost/log, system.applicationHost/sites und system.webServer/httpLogging.



Im Beispiel aus dem vorherigen Abschnitt haben Sie mit dem Internetinformationsdienste-Manager die Protokollierung auf Serverebene konfiguriert. Gehen Sie folgendermaßen vor, um dieselbe Aufgabe mit Appcmd durchzuführen:

1. Öffnen Sie eine Eingabeaufforderung und wechseln Sie in den Ordner %SystemRoot%\System32\ inetsrv, in dem Appcmd liegt.

Hinweis Wenn Sie diesen Pfad zu Ihrer globalen PATH-Umgebungsvariablen hinzufügen, können Sie Appcmd aus jedem beliebigen Ordner heraus ausführen.

2. Führen Sie in der Eingabeaufforderung den folgenden Befehl aus, um die aktuellen Einstellungen aufzulisten:appcmd list config -section:log

Die Standardeinstellungen sehen folgendermaßen aus:<system.applicationHost> <log> <centralBinaryLogFile enabled="true" directory="%SystemDrive%\inetpub\logs\LogFiles" /> <centralW3CLogFile enabled="true" directory="%SystemDrive%\inetpub\logs\LogFiles" /> </log> </system.applicationHost>

Dieser Befehl zeigt den Abschnitt aus applicationHost.config an, in dem die centralLogFileMode-Ein-stellungen gespeichert sind.

3. Führen Sie nun den folgenden Befehl aus, um die Protokollierung auf Serverebene zu aktivieren:appcmd set config -section:log -centralLogFileMode:CentralW3C

4. Führen Sie den folgenden Befehl aus, um die aktuellen Einstellungen aufzulisten, und prüfen Sie, ob die Einstellungen geändert wurden:appcmd list config -section:log

Das Ergebnis müsste zeigen, dass die Einstellung von centralLogFileMode auf den Wert CentralW3C geändert wurde:<system.applicationHost> <log centralLogFileMode="CentralW3C"> <centralBinaryLogFile enabled="true" directory="%SystemDrive%\inetpub\logs\LogFiles" /> <centralW3CLogFile enabled="true" directory="%SystemDrive%\inetpub\logs\LogFiles" /> </log> </system.applicationHost>

Beachten Sie die Einstellung log centralLogFileMode="CentralW3C". Bevor Sie den appcmd set config-Befehl ausgeführt haben, wurde dieser Wert nicht aufgelistet, weil im Schema definiert ist, dass die Site-Option die Standardeinstellung ist.

Der Abschnitt »Erweiterte Appcmd-Operationen« weiter unten in diesem Kapitel erklärt, wie Sie heraus-finden, welche Optionen Sie einstellen können.

Sehen wir uns ein anderes Beispiel an: Sie haben bereits das globale Server-Attribut eingestellt und wollen jetzt die globale localTimeRollover-Einstellung ändern. Führen Sie dazu den folgenden Befehl aus:appcmd set config -section:log -centralW3CLogFile.localTimeRollover:True

Das Ergebnis sollte folgendermaßen aussehen:Die Konfigurationsänderungen am Abschnitt "system.applicationHost/log" für "MACHINE/WEBROOT/APPHOST" im Commit-Pfad "MACHINE/WEBROOT/APPHOST" der Konfiguration wurden übernommen.



Ein anderes Beispiel: Sie wollen das siteDefaults-Protokollformat auf NCSA ändern, sodass alle neuen Sites diese Einstellung übernehmen, sofern sie bei einer Site nicht explizit anders konfiguriert ist. In diesem Fall legt der folgende Befehl die globale Formatoption fest:appcmd set config -section:sites -siteDefaults.logFile.logFormat:NCSA

Hier das Ergebnis:Die Konfigurationsänderungen am Abschnitt "system.applicationHost/sites" für "MACHINE/WEBROOT/APPHOST" im Commit-Pfad "MACHINE/WEBROOT/APPHOST" der Konfiguration wurden übernommen.

Mit Appcmd können Sie über die Befehlszeile schnell Änderungen an Ihren IIS-Protokolleinstellungen vornehmen. Sie können einen Satz von Skripts erstellen, die Appcmd aufrufen, und auf diese Weise häufig benötigte Änderungen schnell durchführen, die über die GUI des Internetinformationsdienste-Managers einigen Administrationsaufwand erfordern. Solche Skripts helfen Ihnen, Ihre Serverkonfi-guration und -bereitstellung zu optimieren und automatisieren.

Erweiterte Appcmd-OperationenMit Appcmd können Sie viele erweiterte Operationen durchführen. In diesem Abschnitt finden Sie einige Tipps, wie Sie mit Appcmd erweiterte Eigenschaften konfigurieren.

Wenn Sie das Attribut centralLogFileMode konfigurieren und sich ansehen wollen, welche Eigenschaften (Enumerationswerte) zur Verfügung stehen, müssen Sie die Datei IIS_Schema.xml öffnen. Das ist kein großer Aufwand, solange Sie ihren Inhalt nur gelegentlich lesen wollen. Aber es ist effizienter, die verfügbaren Eigenschaften von Appcmd auflisten zu lassen. Zum Beispiel listet der folgende Befehl alle Eigenschaften auf, die im Abschnitt system.applicationHost/log konfiguriert werden können://Listet alle Eigenschaften auf, die im Abschnitt // system.applicationHost/log zur Verfügung stehen appcmd set config –section:log -?

Die Ausgabe sieht so aus:ERROR ( message:-logInUTF8 -centralLogFileMode -centralBinaryLogFile.enabled -centralBinaryLogFile.directory -centralBinaryLogFile.period -centralBinaryLogFile.truncateSize -centralBinaryLogFile.localTimeRollover -centralW3CLogFile.enabled -centralW3CLogFile.directory -centralW3CLogFile.period -centralW3CLogFile.truncateSize -centralW3CLogFile.localTimeRollover -centralW3CLogFile.logExtFileFlags )

Appcmd ist in Windows Vista erforderlichIn der Standardeinstellung stellt Windows Vista keine GUI zum Verwalten der Protokolldateien zur Verfügung. Anpassungen an den Protokolldateieinstellungen müssen Sie daher mit Appcmd durchführen. Ein Add-On für IIS 7.0 auf Windows Vista hat Microsoft inzwischen auch als Download zur Verfügung gestellt. Sie können sich dieses Vista-Protokollierungs-UI-Add-On unter http://www.iis.net/go/1328 herunterladen.



Mit der folgenden Syntax verändern Sie den Wert einer Eigenschaft. (Mehrere Eigenschaften gleich-zeitig passen Sie an, indem Sie ein Leerzeichen zwischen die Werte einfügen.)appcmd set config –section:log –Eigenschaft1:Wert –Eigenschaft2:Wert

Falls Sie nicht sicher sind, welche Werte für eine bestimmte Eigenschaft zur Verfügung stehen, können Sie die möglichen Werte mit dem folgenden Befehl ermitteln. Dieses Beispiel zeigt, wie Sie alle Werte auflisten, die für die Eigenschaft centralLogFileMode zur Verfügung stehen://Ermitteln, welche Werte zugewiesen werden können appcmd set config –section:log –centralLogFileMode -?

Die Fehlermeldung listet die gültigen Werte auf, in diesem Fall Site, CentralBinary und CentralW3C:ERROR ( message:Unbekanntes Attribut "centralLogFileMode".. Grund: Enumeration muss einen der Werte von Site, CentralBinary, CentralW3C aufweisen. )

Nehmen wir an, Sie wollen die Protokollierungseinstellungen der Site ändern. Geben Sie den folgenden Befehl ein, um alle verfügbaren Eigenschaften zusammen mit ihrer Syntax aufzulisten://Auflisten aller Eigenschaften, die im sites-Abschnitt zur Verfügung stehen appcmd set config -section:sites -?

Die Ausgabe zeigt alle Eigenschaften für den sites-Abschnitt. Mit den Optionen ab dem Eintrag -siteDefaults.logFile (in der folgenden Ausgabe fett hervorgehoben) können Sie die Standardeinstel-lungen ändern, die an neue Sites vererbt werden. (Einige Zeilen wurden in der Ausgabe umbrochen.)appcmd set config -section:sites -?

ERROR ( message:-siteDefaults.name -siteDefaults.id -siteDefaults.serverAutoStart -siteDefaults.bindings. [protocol='string',bindingInformation='string'].protocol -siteDefaults.bindings. [protocol='string',bindingInformation='string'].bindingInformation -siteDefaults.limits.maxBandwidth -siteDefaults.limits.maxConnections -siteDefaults.limits.connectionTimeout -siteDefaults.logFile.logExtFileFlags -siteDefaults.logFile.customLogPluginClsid -siteDefaults.logFile.logFormat -siteDefaults.logFile.directory -siteDefaults.logFile.period -siteDefaults.logFile.truncateSize -siteDefaults.logFile.localTimeRollover -siteDefaults.logFile.enabled -siteDefaults.traceFailedRequestsLogging.enabled -siteDefaults.traceFailedRequestsLogging.directory -siteDefaults.traceFailedRequestsLogging.maxLogFiles -siteDefaults.traceFailedRequestsLogging.maxLogFileSizeKB -siteDefaults.traceFailedRequestsLogging.customActionsEnabled -applicationDefaults.path -applicationDefaults.applicationPool -applicationDefaults.enabledProtocols -virtualDirectoryDefaults.path -virtualDirectoryDefaults.physicalPath -virtualDirectoryDefaults.userName -virtualDirectoryDefaults.password -virtualDirectoryDefaults.logonMethod -virtualDirectoryDefaults.allowSubDirConfig



-[name='string',id='unknown'].name -[name='string',id='unknown'].id -[name='string',id='unknown'].serverAutoStart -[name='string',id='unknown'].bindings. [protocol='string',bindingInformation='string'].protocol -[name='string',id='unknown'].bindings. [protocol='string',bindingInformation='string'].bindingInformation -[name='string',id='unknown'].limits.maxBandwidth -[name='string',id='unknown'].limits.maxConnections -[name='string',id='unknown'].limits.connectionTimeout -[name='string',id='unknown'].logFile.logExtFileFlags -[name='string',id='unknown'].logFile.customLogPluginClsid -[name='string',id='unknown'].logFile.logFormat -[name='string',id='unknown'].logFile.directory -[name='string',id='unknown'].logFile.period -[name='string',id='unknown'].logFile.truncateSize -[name='string',id='unknown'].logFile.localTimeRollover -[name='string',id='unknown'].logFile.enabled -[name='string',id='unknown'].traceFailedRequestsLogging.enabled -[name='string',id='unknown'].traceFailedRequestsLogging.directory -[name='string',id='unknown'].traceFailedRequestsLogging.maxLogFiles -[name='string',id='unknown'].traceFailedRequestsLogging.maxLogFileSizeKB -[name='string',id='unknown']. traceFailedRequestsLogging.customActionsEnabled -[name='string',id='unknown'].applicationDefaults.path -[name='string',id='unknown'].applicationDefaults.applicationPool -[name='string',id='unknown'].applicationDefaults.enabledProtocols -[name='string',id='unknown'].virtualDirectoryDefaults.path -[name='string',id='unknown'].virtualDirectoryDefaults.physicalPath -[name='string',id='unknown'].virtualDirectoryDefaults.userName -[name='string',id='unknown'].virtualDirectoryDefaults.password -[name='string',id='unknown'].virtualDirectoryDefaults.logonMethod -[name='string',id='unknown'].virtualDirectoryDefaults.allowSubDirConfig -[name='string',id='unknown'].[path='string'].path -[name='string',id='unknown'].[path='string'].applicationPool -[name='string',id='unknown'].[path='string'].enabledProtocols -[name='string',id='unknown'].[path='string'].virtualDirectoryDefaults.path -[name='string',id='unknown'].[path='string']. virtualDirectoryDefaults.physicalPath -[name='string',id='unknown'].[path='string']. virtualDirectoryDefaults.userName -[name='string',id='unknown'].[path='string']. virtualDirectoryDefaults.password -[name='string',id='unknown'].[path='string']. virtualDirectoryDefaults.logonMethod -[name='string',id='unknown'].[path='string']. virtualDirectoryDefaults.allowSubDirConfig -[name='string',id='unknown'].[path='string'].[path='string'].path -[name='string',id='unknown'].[path='string'].[path='string'].physicalPath -[name='string',id='unknown'].[path='string'].[path='string'].userName -[name='string',id='unknown'].[path='string'].[path='string'].password -[name='string',id='unknown'].[path='string'].[path='string'].logonMethod -[name='string',id='unknown'].[path='string'].[path='string'].allowSubDirConfig )



Einstellungen für einzelne Websites können Sie mit den Eigenschaften ab dem Eintrag -[name=‘string’, id=‘unknown’].logFile festlegen. Sie brauchen lediglich das 'unknown’ durch den Namen der Website zu ersetzen. Das folgende Beispiel zeigt, wie Sie Einstellungen für eine bestimmte Site ändern. Beachten Sie, dass in diesem Beispiel der Name der Standardwebsite (Default Web Site) von doppelten Anführungszeichen umschlossen wird. Das ist nötig, weil der Websitename Leerzeichen enthält. Vergessen Sie nicht, den Namen und die ID zu ändern, wenn Sie dieses Beispiel abtippen.//Festlegen der Eigenschaft logFile.directory, wenn der Sitename Leerzeichen enthält appcmd set config -section:sites /[name='"Default Web Site"',id='1'].logFile.directory:c:\wwwlogs //Ändern der Eigenschaft logFile.directory, wenn der Sitename keine Leerzeichen enthält appcmd set config -section:sites /[name='Contoso.com',id='2'].logFile.directory:c:\wwwlogs

Windows PowerShellSie können Ihren IIS 7.0-Server auch mithilfe der Windows PowerShell verwalten. Dieser Abschnitt zeigt einige Beispiele, wie Sie das Verzeichnis für die Protokolldateien ändern. Im folgenden Bei-spielskript laden Sie erst Microsoft.Web.Administration.dll in Ihre Windows PowerShell-Sitzung. Anschließend weisen Sie der Variablen $sm eine Instanz des ServerManager-Objekts zu, damit Sie die Logfile-Werte ermitteln und ändern können. (Im folgenden Listing wurden einige Zeilen umbrochen.)//DLL in die Power Shell-Sitzung laden [System.Reflection.Assembly]::LoadFrom ( "C:\windows\system32\inetsrv\Microsoft.Web.Administration.dll" ) //Eine Instanz des ServerManager-Objekts in die Variable $sm laden $sm = new-object Microsoft.Web.Administration.ServerManager //Abrufen der Eigenschaft LogFile.Directory für die Standardwebsite $sm.Sites["Default Web Site"].LogFile.Directory //Abrufen der Eigenschaft LogFile.Directory für SiteDefaults $sm.SiteDefaults.LogFile.Directory //Ändern der Eigenschaft LogFile.Directory für die Standardwebsite $sm.Sites["Default Web Site"].LogFile.Directory = "\\RemoteServer.Contoso.com\Logfiles" $sm.CommitChanges() //Ändern der Eigenschaft LogFile.Directory für SiteDefaults $sm.SiteDefaults.Logfile.Directory = "\\RemoteServer.Contoso.com\Logfiles" $sm.CommitChanges()

Wie Sie IIS 7.0 mit der Windows PowerShell verwalten, ist in Kapitel 7, »Verwenden von Befehlszeilentools«, ausführlich beschrieben. Informationen, wie Sie ein Cmdlet erstellen, mit dem Sie viele wichtige Funktionen in IIS 7.0 verwalten können, finden Sie auf der Website http://www.iis.net/go/1211.

In Windows Server 2008 gibt es die neue Möglichkeit, zwischengespeicherte Protokolleinträge sofort auf den Datenträger zu schreiben. Der Dienst Http.sys speichert Anforderungen und schreibt sie nur in regelmäßigen Abständen auf den Datenträger. Wenn Sie ein konkretes Problem untersuchen, können Sie den folgenden netsh-Befehl aufrufen, der besonders bei der Problembehandlung von Fehlern im Zusammenhang mit Http.sys nützlich ist:



//Protokolleinträge sofort auf Datenträger schreiben netsh http flush logbuffer

Http.sys-ProtokollierungIn IIS 6.0 wurde der Prozess Http.sys eingeführt und übernahm die Protokollierungsaufgaben, die vorher von Inetinfo.exe erledigt wurden. Http.sys führte ein weiteres Protokoll namens HTTPERR ein. Die HTTPERR-Protokolle liegen in Windows Server 2008 im selben Speicherort wie unter Windows Server 2003, nämlich im Pfad %SystemRoot%\System32\LogFiles\HTTPERR. Dieses Protokoll zeichnet alle Fehler auf, die nicht an einen gültigen Arbeitsprozess weitergeleitet werden, also nor-malerweise Antworten an Clients, Verbindungszeitüberschreitungen und verwaiste Anforderungen. Diese zusätzlichen Informationen helfen Ihnen bei der Problembehandlung von HTTP-Fehlern, die aufgezeichnet werden, bevor die Anforderung IIS erreicht.

Windows Vista und Windows Server 2008 führen einige Verbesserungen am Http.sys-Protokollierungs-prozess ein. Mithilfe von ETW (Event Tracing for Windows) können Sie die erweiterten Informationen abrufen. Gehen Sie folgendermaßen vor, um eine ETW-Ablaufverfolgungssitzung zu starten, die Informationen aufzuzeichnen und anzuzeigen:

1. Öffnen Sie eine Eingabeaufforderung, indem Sie im Suchfeld des Startmenüs cmd.exe eingeben.

2. Starten Sie die ETW-Ablaufverfolgungssitzung für Http.sys, indem Sie den folgenden Befehl ausführen:logman.exe start httptrace -p Microsoft-Windows-HttpService 0xFFFF -o httptrace.etl –ets

3. Führen Sie die Schritte oder Tests durch, die Sie analysieren wollen.

4. Beenden Sie die ETW-Ablaufverfolgungssitzung für Http.sys, indem Sie den folgenden Befehl ausführen:logman stop httptrace –ets

5. Konvertieren Sie die ETL-Datei mit dem folgenden Befehl in eine kommagetrennte Datei (CSV-Format):tracerpt httptrace.etl -of csv -o httptrace.csv /y

Die CSV-Dateien können Sie in einem Texteditor oder einer Tabellenkalkulation öffnen. Eine ausführ-liche Version dieser Anleitung finden Sie in einem White Paper auf http://technet.microsoft.com; suchen Sie nach dem Titel »HTTP.sys Manageability in Windows Vista and Longhorn Server«.

Hinweis Die Site http://technet.microsoft.com/en-us/library/bb726965.aspx beschreibt die neuen Netzwerkfeatures in Windows Vista und Windows Server 2008.

AnwendungsprotokollierungNeben den Standard-IIS-Protokollen können auch andere Elemente aufgezeichnet werden. Viele dieser Optionen stellen Sie im Internetinformationsdienste-Manager oder mithilfe von Appcmd ein.

Protokollierung der ProzesswiederverwendungIn IIS 7.0 werden Ereignisse in das Windows-Ereignisprotokoll eingetragen, wenn ein Anwendungs-pool Prozesse wiederverwendet (recycelt). Mit den Optionen, die in Tabelle 15.1 aufgeführt sind, steuern Sie 8 Konfigurationseinstellungen.


Anwendungsprotokollierung 533

ASPDas klassische ASP (Active Server Pages) erfreut sich in IIS 7.0 bester Gesundheit, und Sie können Optionen für die Protokollierung von ASP-Fehlern im Abschnitt ASP des Internetinformationsdienste-Managers konfigurieren. Die folgenden Optionen sind nützlich, wenn Sie Probleme bei der Migration Ihrer alten ASP-Anwendungen auf IIS 7.0 untersuchen:

� Fehlerprotokollanforderungen aktivieren Steuert, ob der Webserver ASP-Fehler in das Anwendungsereignisprotokoll schreibt

� Fehler in NT-Protokoll protokollieren Legt fest, ob ASP-Fehler im Windows-Ereignisprotokoll aufgezeichnet werden

Diese Optionen stehen auch in IIS 6.0 zur Verfügung, aber Sie müssen sie mithilfe von ADSUtil.vbs in der Metabasis aktivieren. In IIS 7.0 können Sie diese Optionen direkt im Internetinformationsdienste-Manager aktivieren.

ASP.NETAlle unbehandelten ASP.NET 2.0-Ausnahmen werden in das Anwendungsereignisprotokoll geschrieben. Neben den Wiederverwendungsereignissen des Anwendungspools und anderen Fehlern in den Ereignis-protokollen sind auch diese Ereignisse sehr nützlich bei der Problembehandlung von Anwendungs-fehlern. Wie Sie die ASP.NET-Protokollierung ausschalten, ist im Knowledge Base-Artikel http://support.microsoft.com/kb/911816 beschrieben.

Tabelle 15.1 Wiederverwendungsoptionen unter dem Eintrag Protokolleintrag für Wieder- verwendungsereignis generieren

Option Beschreibung Standardeinstellung

Geänderte Anwendungspool-konfiguration

Es wird ein Ereignis aufgezeichnet, wenn der Anwendungspool wegen einer Konfigurationsänderung wiederverwendet wird

False

ISAPI-Fehlermeldung Es wird ein Ereignis aufgezeichnet, wenn eine ISAPI-Erweiterung einen Fehler meldet

False

Manuelle Wiederverwendung Es wird ein Ereignis aufgezeichnet, wenn der Anwendungspool von Hand wiederverwendet wurde

False

Überschrittenes Limit für den privaten Speicher

Es wird ein Ereignis aufgezeichnet, wenn der Anwendungspool wiederverwendet wird, nachdem sein Limit für den privaten Speicher überschritten wurde

True

Regelmäßiges Zeitintervall Es wird ein Ereignis aufgezeichnet, wenn der Anwendungspool nach Ablauf des eingestellten Intervalls wiederverwendet wird

True

Anforderungslimit überschritten Es wird ein Ereignis aufgezeichnet, wenn der Anwendungspool wiederverwendet wird, nachdem sein Anforderungslimit überschritten wurde

False

Bestimmte Zeit Es wird ein Ereignis aufgezeichnet, wenn der Anwendungspool zum geplanten Zeitpunkt wiederverwendet wird

False

Limit für den virtuellen Speicher überschritten

Es wird ein Ereignis aufgezeichnet, wenn der Anwendungspool wiederverwendet wird, nachdem sein Limit für den virtuellen Speicher überschritten ist

True



IIS-EreignisseAuch andere Prozesse, die mit IIS zusammenarbeiten, schreiben Einträge in das Windows-Ereignis-protokoll. Das sind unter anderem HTTP-, IISAdmin-, FTP-Publishingdienst sowie die W3SVC-Dienste. Eine vollständige Liste der Ereignisse finden Sie unter http://technet.microsoft.com; suchen Sie dort nach »IIS events reference«.

OrdnerkomprimierungProtokolldateien sind nötig, um Websitestatistiken und -trends verfolgen zu können. Webentwickler und Manager brauchen sie, um sicherzustellen, dass die Beliebtheit ihrer Websites weiter steigt. Für Administratoren ist die Aufbewahrung und Verwaltung der Protokolldateien eine der größten Heraus-forderungen. In der Standardeinstellung überschreibt IIS die Protokolldateien nach einem Tag (das so genannte Rollover). Ihre Protokolldateien können aber ziemlich groß werden, selbst wenn Sie diese Standardeinstellung für das Protokolldateirollover verwenden.

Windows Server 2008 stellt Ordnerkomprimierung zur Verfügung, mit der Sie Platz sparen können. Sie aktivieren diese Option im Windows-Explorer. Abbildung 15.8 zeigt einen Ordner, bei dem die Komprimierung aktiviert ist. In diesem Beispiel beträgt die Größe des Ordners 166 MByte, aber in Wirklichkeit belegt der Ordner nur 43,1 MByte auf dem Datenträger. Wenn Ihre unkomprimierten Protokolldateien mehrere GByte belegen, können Sie mithilfe der Ordnerkomprimierung eine Menge Festplattenplatz sparen.

Abbildung 15.8 Aktivieren der Ordnerkomprimierung für den Ordner WWWLogs

Weil Http.sys die Informationen puffert, bevor sie in die IIS-Protokolldateien geschrieben werden, beeinträchtigt es nicht die Leistung, falls Ihre Protokolldateien in einem Ordner liegen, bei dem die Komprimierung aktiviert ist. Manche Administratoren setzen Protokollkomprimierungsprodukte von


Protokollanalyse mit Log Parser 535

Fremdherstellern oder kostenlose Tools wie Gzip in Kombination mit Skripts ein, um ihre Protokoll-dateien zu komprimieren. Sofern Sie kein Tool haben, das den Inhalt von Zip-Dateien durchsuchen kann, ist diese Lösung nur sinnvoll, wenn Sie Ihre archivierten Protokolldateien nur ganz selten ent-packen und durchsuchen müssen. Wenn Sie die Komprimierung aktivieren, können Sie Ihre Dateien dagegen im Original behalten und sie problemlos durchsuchen. Sie müssen höchstens irgendein Archivierungs- und Aufräumskript implementieren; dafür können Sie Ihr bevorzugtes Skriptsystem oder das Programm eines Fremdherstellers verwenden.

Indem Sie das eingebaute Komprimierungsfeature von Windows Server 2008 nutzen, können Sie Festplattenplatz sparen und die Aufbewahrung Ihrer Protokolldateien vereinfachen. Weitere Infor-mationen über das Verwalten von Protokolldateien finden Sie in Kapitel 6, »Managing Log Files«, des Buchs Microsoft Log Parser Toolkit von Gabriele Giuseppini und Mark Burnett (Syngress Publishing, Inc., 2006; http://www.syngress.com/catalog/?pid=3110). Dort werden Konvertierungs-, Archivie-rungs- und Löschstrategien beschrieben.

Protokollanalyse mit Log ParserEin Kapitel über Protokollierung wäre unvollständig, wenn es das Tool Log Parser nicht zumindest erwähnt. Log Parser ist eines der nützlichsten Tools zum Durchsuchen Ihrer Protokolle. Eine Einfüh-rung in die Arbeit mit Log Parser würde den Rahmen dieses Buchs sprengen, aber wir führen einige Beispiele vor, die Sie in Ihrer eigenen Umgebung nutzen können. Der Log Parser steht als Download unter http://ww.iis.net/go/1287 zur Verfügung.

Hinweis Die Mitarbeiter des Microsoft.com-Teams sind große Fans von Log Parser. Unter http://blogs.tech-net.com/mscom/archive/2005/10/19/412745.aspx finden Sie einen Artikel, der den Einsatz von Log Parser beschreibt.

Hier sind drei Beispiele, wie Sie mit dem Log Parser wichtige Informationen aus Ihren IIS-Protokollen extrahieren:

1. Auflisten der Top-25-Webanforderungen (häufigste Anforderungen):LogParser -i:iisw3c "SELECT TOP 25 cs-uri-stem, COUNT(*) AS HitCount INTO Results.csv FROM LOGFILENAME.LOG GROUP BY cs-uri-stem ORDER BY HitCount DESC" -o:csv

2. Anzeigen der 25 Anforderungen, deren Ausführung am längsten gedauert hat://Ändern Sie bei Bedarf den Datumswert SELECT TOP 25 CS-URI-STEM, TIME-TAKEN FROM LOGFILENAME.LOG WHERE DATE > '2007-03-26' ORDER BY TIME-TAKEN DESC

3. Auslesen der Informationen aus dem angegebenen Zeitraum und Schreiben der Ergebnisse in eine Textdatei namens Output.txt:SELECT DATE, TIME, CS-URI-STEM,



SC-STATUS, COUNT(*) AS MaxTime INTO Output.txt FROM LOGFILENAME.LOG WHERE TO_TIME(time) BETWEEN TIMESTAMP('01/01 13:50:00', 'MM/dd hh:mm:ss') AND TIMESTAMP('01/01 18:30:00', 'MM/dd hh:mm:ss') AND SC-STATUS = 500 GROUP BY CS-URI-STEM, DATE, TIME, SC-STATUS ORDER BY MaxTime DESC

Falls Sie für die Verwaltung einer IIS-Umgebung verantwortlich sind, sollten Sie sich den Log Parser genauer ansehen. Es ist ein hervorragendes Tool für die Analyse aller Arten von Problemen. Weitere Informationen über Log Parser finden Sie in den Community-Foren unter http://forums.iis.net/default.aspx?GroupID=51.

ZusammenfassungIIS 7.0 übernimmt die besten Features, die in Windows Server 2003 neu eingeführt wurden, und erweitert sie. Die modulare Architektur und die integrierte Pipeline bieten zahlreiche Möglichkeiten, die Anwendungsprotokollierung optimal anzupassen. Der Internetinformationsdienste-Manager vereinfacht die Verwaltung Ihrer Protokollierungseinstellungen. Sie können die Standardprotokol-lierungseinstellungen auf Site- oder Serverebene konfigurieren.

IIS 7.0 bringt auch viele neue Tools mit, die es Ihnen ermöglichen, die Konfiguration der Protokoll-dateien zu automatisieren. Mit Appcmd oder Windows PowerShell und dem Namespace Microsoft.Web. Administration können Sie die Protokollierung konfigurieren oder nach Informationen suchen. Die neue UTF-8-Kodierung hilft bei der Standardisierung Ihrer Protokolle.

IIS 7.0 protokolliert mehr Daten als ältere IIS-Versionen. Mit den neuen Tools, die IIS 7.0 und Windows Server 2008 zur Verfügung stellen, können Sie die zusätzlichen Informationen auswerten, wenn Sie Probleme in Ihrer Umgebung analysieren und beseitigen.

Weitere InformationenDie folgenden Quellen liefern weitere Informationen und Tools zu den Themen dieses Kapitels:

� Informationen zu IIS unter http://www.iis.net

� Links zu allen Tools, die in diesem Kapitel erwähnt werden, darunter Log Parser und FTP-Publishingdienst, enthält der Downloads-Abschnitt unter http://www.iis.net.

� Wichtige Tools von Fremdherstellern, die Zusatzprodukte zu IIS entwickeln und anbieten, sind unter http://www.iis.net aufgeführt. Zum Beispiel steht IISLogs, das zwei Tools zum Verwalten von Protokolldateien zur Verfügung stellt, als Download im Abschnitt Administration bereit.

Auf der Begleit-CD Weitere Informationen über Log Parser und IISLogs finden Sie auf Begleit-CD.

� Blogs, Foren und das TechCenter unter http://www.iis.net


537

K A P I T E L 1 6

Ablaufverfolgung und Problembehandlung

Inhalt dieses Kapitels:� Problembehandlung mithilfe von Ablaufverfolgung und Diagnose . . . . . . . . . . . . . . . . . . . . . . . . . 538

� Problembehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

� Beseitigen häufig auftauchender Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574




Die üblichen Methoden zum Debuggen einer Anwendung lassen sich bei den meisten Internet-Client-Serveranwendungen nicht einsetzen. Normalerweise haben Sie wenig oder gar keine Kontrolle über die Webbrowser, die die von Ihrem Webserver gehosteten Umgebungen aufrufen. Gerade wegen der Charakteristik von Internetanwendungen kann es sogar oft schwierig sein, überhaupt zu erkennen, dass ein Problem besteht.

Glücklicherweise stehen Ihnen mehrere Tools zur Verfügung, mit denen Sie Probleme analysieren und beseitigen können. Microsoft IIS 7.0 (Internet Information Services, Internetinformationsdienste) erweitert das Arsenal durch die Ablaufverfolgung für Anforderungsfehler (Failed Request Tracing, FRT). Indem Sie die FRT mit den leistungsfähigen Protokollierungsfähigkeiten von IIS 7.0 und einer Vielzahl anderer Tools kombinieren, die in Microsoft Windows Server 2008 zur Verfügung stehen, sind Sie in der Lage, eventuell auftretende Probleme zu verstehen und zu korrigieren.

Im ersten Teil dieses Kapitels sehen wir uns an, wie Sie Ihr System überwachen, wenn Sie ein Problem vermuten, und wie Sie dafür sorgen, dass Sie automatisch gewarnt werden und Protokolle erstellt werden, sobald Fehler auftreten. Sie werden feststellen, dass die FRT eine große Verbesserung gegenüber dem Debugging mithilfe der Ereignisablaufverfolgung für Windows (Event Tracing for Windows, ETW) ist, weil die ETW oft umständlich zu installieren und konfigurieren sowie schwierig zu benutzen ist. Ein FRT-Protokoll liegt im XML-Format vor, sodass Sie es mit einem passenden Tool schnell durchsuchen können. Die FRT stellt einen vordefinierten Stylesheet zur Verfügung, der die Ausgabe einfach verständlich macht. Mithilfe der FRT kann ein Administrator Informationen über Fehler sammeln, die bei ausgewählten oder allen Clients auftreten. Sie brauchen nicht am Client anwesend zu sein, während der Fehler auftritt, um die vom Server generierten Fehlerinformationen zu lesen. Fehler, die schwierig zu reproduzieren sind, aber immer wieder in Erscheinung treten, können durch die FRT dingfest gemacht werden.

Der zweite Teil dieses Kapitels beschreibt, mit welchen Tools und Methoden Sie Probleme analysieren und beseitigen. Für die Problembehandlung in einer IIS 7.0-Installation stehen beispielsweise Ping, Wfetch und Process Monitor zur Verfügung; eine Vielzahl von Tools, die von simplen Befehlszeilen-programmen bis zu komplexen Anwendungen mit grafischer Benutzeroberfläche (Graphical User Inter-


538 Kapitel 16: Ablaufverfolgung und Problembehandlung

face, GUI) reichen. Aber jedes dieser Tools liefert wichtige Informationen, die Sie brauchen, wenn Sie das Problem nach einem grundlegenden Schema analysieren, das Problem isolieren und die eigentliche Ursache herausfinden.

Der letzte Abschnitt in diesem Kapitel stellt einige Szenarien vor, mit denen es Administratoren oft bei der Problembehandlung zu tun haben. Außerdem werden dort häufige Probleme beschrieben, mit denen Sie vermutlich öfters konfrontiert werden, und mögliche Lösungen zu deren Beseitigung vorgestellt.

Problembehandlung mithilfe von Ablaufverfolgung und DiagnoseDie FRT ist ein leistungsfähiges Diagnosetool, um Fehler in Ihrer Webserverumgebung zu untersuchen. Was ist eigentlich ein Fehler einer Internetanwendung? Das ist durchaus keine rhetorische Frage, weil die FRT Ihnen die Fähigkeit gibt, selbst anhand von Parametern zu definieren, wann eine Anforderung als fehlgeschlagen eingestuft wird. Sie können einen Anforderungsfehler anhand verschiedener Faktoren definieren: ein bestimmter HTTP-Fehlerstatuscode; ein Bereich von Statuscodes; wie lange der Server braucht, um die Anforderung zu beantworten; der Schweregrad eines Ereignisses; oder anhand einer beliebigen Kombination dieser Bedingungen. Sie können ganz präzise eingrenzen, welchen Inhalt Sie mit einer bestimmten FRT-Regel verfolgen, und Sie können die gelieferte Ausgabe ganz einfach detailliert analysieren. Das Ergebnis ist oft, dass Sie die Komponenten in Ihrer Anwendung aufspüren können, die Probleme verursachen, und zwar bis hinein in einzelne Module.

Wenn Sie die FRT nutzen wollen, müssen Sie sie erst einmal installieren und konfigurieren. Dafür stehen unterschiedliche Methoden zur Verfügung. Sie können GUI-Tools, Befehlszeilentools oder Skripts verwenden oder die Konfigurationsdateien direkt bearbeiten.

Installieren des FRT-ModulsDie Ablaufverfolgung für Anforderungsfehler ist eine optionale Komponente in der modularen Architektur von IIS 7.0. Wenn Sie IIS 7.0 installieren, sollten Sie den Rollendienst Nachverfolgung aus der Kategorie Integrität und Diagnose mitinstallieren (Abbildung 16.1). In Kapitel 5, »Installieren von IIS 7.0«, finden Sie weitere Informationen zur Installation von IIS 7.0. Damit Sie Probleme effizient beseitigen können, sollten Sie auch die passenden Protokollierungsmodule installieren. Informationen zu HTTP-Protokollierung (Hypertext Transfer Protocol), benutzerdefinierter Protokollierung und anderen Protokollierungstools finden Sie in Kapitel 15, »Protokollierung«.

Ob Sie das Ablaufverfolgungsmodul installiert haben, können Sie feststellen, indem Sie im Internet-informationsdienste-Manager in der Strukturansicht den Server auswählen und doppelt auf Module klicken. In der Liste muss der Eintrag FailedRequestsTracingModule aufgeführt sein.

Hinweis Den Internetinformationsdienste-Manager starten Sie über die Programmgruppe Verwaltung oder indem Sie im Dialogfeld Ausführen den Befehl inetmgr eingeben.

Stattdessen können Sie auch prüfen, ob das Ablaufverfolgungsmodul installiert ist, indem Sie nach-sehen, ob im Abschnitt <modules> der Datei applicationHost.config die folgende Zeile vorhanden ist.<add name="FailedRequestsTracingModule" />


Problembehandlung mithilfe von Ablaufverfolgung und Diagnose 539

Abbildung 16.1 Installieren des Rollendienstes Nachverfolgung beim Hinzufügen der Rolle Webserver (IIS)

Aktivieren und Konfigurieren der FRTUm die Ablaufverfolgung mit der FRT einzuschalten, müssen Sie die FRT für jede Website aktivieren, die Sie überwachen wollen, und anschließend FRT-Regeln für die Website oder die konkrete URL konfigu-rieren, die Sie analysieren wollen. (Beachten Sie, dass Sie die FRT zwar auf Siteebene aktivieren/deakti-vieren müssen, aber die Fehlerdefinitionen für jede beliebige URL innerhalb dieser Site konfigurieren können. Und auch wenn Sie die FRT für eine Site nicht aktiviert haben, können Sie trotzdem Fehler-definitionen erstellen; sie werden allerdings erst ausgewertet, wenn Sie die FRT auf Siteebene einschal-ten.) Sie aktivieren die FRT für eine Website, indem Sie in der Strukturansicht des Internetinformations-dienste-Managers die Site auswählen, die Sie überwachen wollen. Klicken Sie im Fensterabschnitt Aktionen rechts im Internetinformationsdienste-Manager auf Ablaufverfolgung für Anforderungsfehler. Aktivieren Sie im Dialogfeld Ablaufverfolgungeinstellungen für Anforderungsfehler für die Website bearbeiten das Kontrollkästchen Aktivieren (Abbildung 16.2). Sie können für jede Website einen anderen Speicherort für die FRT-Protokolldateien der Site einstellen. (In der Standardeinstellung werden die Protokolldateien im Ordner %SystemDrive%\Inetpub\logs\FailedReqLogFiles gesammelt. Sie sollten nach Möglichkeit einen Speicherort außerhalb des Systemlaufwerks verwenden.) Sie können auch einstellen, wie viele Protokolldateien maximal aufbewahrt werden. Diese Einstellung ist wichtig, weil die FRT für jeden Fehler eine Protokolldatei anlegt. Für den Fall, dass eine Menge Fehler auftreten, begrenzt das Feld Maximale Zahl der Ablaufverfolgungsdateien die Zahl von Fehlerprotokollen, die im Dateisystem gespeichert werden.



Abbildung 16.2 Aktivieren der FRT für eine Website

Sie können FRT-Einstellungen delegieren, damit Anwendungsentwickler, die keine Serveradministratoren sind, die FRT innerhalb ihrer eigenen Anwendungen nutzen können. Im Abschnitt »Problembehandlung für UNC-Zugriffsfehler« weiter unten in diesem Kapitel finden Sie weitere Informationen über das Delegieren von FRT-Einstellungen. (Sie können FRT-Einstellungen unabhängig davon delegieren, ob die untersuchten Inhalte lokal oder auf einem anderen Computer abgelegt sind.)

Ablaufverfolgung für einen bestimmten FehlercodeSehen wir uns ein Beispiel an: Sie müssen Probleme untersuchen, die beim Zugriff auf eine Website aufgrund von Sicherheitseinstellungen auftreten. Gehen Sie folgendermaßen vor, um die FRT so zu konfigurieren, dass Sie alle Systemantworten untersuchen können, wenn ein Client den Fehlercode 401.3 (Nicht autorisiert: Zugriff verweigert) erhält:

1. Wählen Sie in der Strukturansicht des Internetinformationsdienste-Managers die Website aus, deren Ablaufverfolgung Sie konfigurieren wollen.

2. Klicken Sie doppelt auf Ablaufverfolgungsregeln für Anforderungsfehler.

Hinweis Stellen Sie sicher, dass unten im mittleren Fensterabschnitt die Option Ansicht "Features" ausgewählt ist.

3. Klicken Sie im Fensterabschnitt Aktionen auf den Link Hinzufügen, wie in der folgenden Abbildung gezeigt.



4. Auf der Seite Inhalt für Ablaufverfolgung angeben im Assistenten Ablaufverfolgungsregel für Anforderungsfehler hinzufügen legen Sie fest, welche Inhaltstypen Sie verfolgen wollen. Wählen Sie in diesem Beispiel die Option Gesamter Inhalt aus und klicken Sie auf Weiter.

5. Auf der Seite Ablaufverfolgungsbedingungen definieren legen Sie fest, was ein Anforderungsfehler ist. Sie können einen Anforderungsfehler als beliebige Kombination aus zurückgegebenen Status-codes, Antwortzeiten oder Ereignisschweregraden definieren. Falls Sie mehrere Bedingungen ange-ben, wird das Protokoll geschrieben, sobald die erste erfüllt ist. (Im Textkasten »Direkt von der Quelle: Details zu FRT-Auslösungsbedingungen« weiter unten in diesem Kapitel wird genauer beschrieben, wie Sie Fehlerbedingungen kombinieren können.) Geben Sie im Textfeld Statuscode(s) den Wert »401.3« ein, um eine Anforderung, die einen »Zugriff verweigert«-Fehlercode zurückgibt, als Anfor-derungsfehler zu definieren. Klicken Sie anschließend auf Weiter. (Sofern Sie nicht genau wissen, welcher Fehler auftritt, geben Sie normalerweise aber nicht den Unterstatuscode ein.)



6. Auf der Seite Ablaufverfolgungsanbieter auswählen geben Sie an, was IIS 7.0 aufzeichnen soll, wenn eine Anforderung fehlschlägt, und wie ausführlich die aufgezeichneten Daten sein sollen. Deakti-vieren Sie, wie in der folgenden Abbildung, in der Liste Anbieter alle Kontrollkästchen außer WWW Server, wählen Sie in der Dropdownliste Ausführlichkeitsgrad den Eintrag Ausführlich und deaktivie-ren Sie in der Liste Bereiche alle Kontrollkästchen außer Authentication, Security, RequestNotifica-tions und Module. (Sie müssen im Listenfeld nach unten blättern, damit das Kontrollkästchen Module sichtbar wird.) Tabelle 16.1 beschreibt die Bereiche, die Sie für den Anbieter WWW Server auswählen können. Klicken Sie auf Fertig, um die Regel für die Website hinzuzufügen.

Sie können Ihre FRT-Einstellungen testen und ein FRT-Protokoll für das gerade konfigurierte Beispiel generieren, indem Sie die Sicherheitsberechtigungen für eine Ressource in der Website einschränken und dann versuchen, diese Ressource im Microsoft Internet Explorer aufzurufen. Der Browser meldet einen 401.3-Fehler (Abbildung 16.3) und die FRT generiert ein Ablaufverfolgungsprotokoll.

Tabelle 16.1 Ablaufverfolgungsbereiche für den Anbieter WWW Server

Bereich Beschreibung

Authentication Zeichnet Ereignisse im Zusammenhang mit der Authentifizierung auf

Security Zeichnet Sicherheitsereignisse auf, zum Beispiel Autorisierung und Zugriffssteuerungslisten-prüfungen, die IIS für Dateien und andere Ressourcen durchführt

Filter Zeichnet Filterereignisse auf, während eine Anforderung die verschiedenen ISAPI-Filter (Internet Server Application Programming Interface) durchläuft, die für die überwachte URL konfiguriert sind

StaticFile Zeichnet Ereignisse zu statischen Dateien auf, zum Beispiel ob die Datei aus dem Cache abgerufen wurde oder nicht

CGI Zeichnet Ereignisse auf, die vom CGI-Modul (Common Gateway Interface) generiert wurden, zum Beispiel FastCGI-Anforderungen

Compression Zeichnet Ereignisse auf, die durch das Komprimieren von Antworten und Ausliefern komprimierter Antworten ausgelöst werden



Abbildung 16.3 Ein 401.3-Fehler im Internet Explorer

Cache Zeichnet Cacheoperationen für eine Anforderung auf

RequestNotifications Zeichnet alle Anforderungspipelinebenachrichtigungen auf, die an Module gesendet werden

Module Zeichnet Ereignisse auf, die jedes Mal ausgelöst werden, wenn ein bestimmtes Modul die Verarbeitung einer Anforderungsbenachrichtigung beginnt oder beendet

Direkt von der Quelle: Details zu FRT-AuslösungsbedingungenDie Ablaufverfolgung für Anforderungsfehler in IIS 7.0 kann Fehler aufgrund von drei Bedingungen auslösen: Status-/Unterstatuscodes, abgelaufene Zeit und Ausführlichkeitsgrad des Ereignisses (in der Benutzeroberfläche auch als Ereignisschweregrad bezeichnet). Dabei ist wichtig, dass der Auslöser immer eine logische ODER-Verknüpfung aller Fehlerbedingungen ist. Falls Sie alle drei Bedingungen definieren, zum Beispiel statusCodes="400-599", timeTaken="00:00:10" und verbosity="Errors", schreibt der Arbeitsprozess das Ablaufverfolgungsprotokoll für den Anforderungsfehler, sobald die erste dieser Bedingungen erfüllt ist. Falls Ihre Anforderung letztlich mit dem HTTP-Statuscode 500 abgebrochen wird, das aber erst nach 30 Sekunden passiert, ist der eigentliche Auslöser der timeTaken-Wert. Das Attribut <failedRequest failureReason="<Grund>"> im Ablaufverfolgungsprotokoll verrät Ihnen genau, welche Fehlerbedingung das Schreiben des Protokolls ausgelöst hat.

Tabelle 16.1 Ablaufverfolgungsbereiche für den Anbieter WWW Server (Fortsetzung)

Bereich Beschreibung



Konfigurieren der FRT mit AppcmdSie können FRT-Regeln auch mit Befehlszeilenprogrammen wie Appcmd, Windows PowerShell und WMI (Windows Management Instrumentation) definieren. Die Syntax für Appcmd lautet folgender-maßen:%systemroot%\system32\inetsrv\appcmd configure trace "URL" /enable [/path:Pfad] [/statuscodes:Statuscode] [/timeTaken:Zeitlimit] [/areas:Bereiche] [/verbosity:Grad]Mit der folgenden Appcmd-Syntax können Sie eine FRT-Regel löschen:%systemroot%\system32\inetsrv\appcmd configure trace "URL" /disable [/path:Pfad]

Denken Sie daran, dass die Regeln nur wirksam werden, wenn Sie die FRT für die Website aktiviert haben. Das können Sie im Internetinformationsdienste-Manager erledigen, wie weiter oben in diesem Kapitel beschrieben, oder mit dem folgenden Aufruf von Appcmd, wobei Websitename der Name der Website ist. Mit /disablesite können Sie die FRT für eine Website wieder deaktivieren.%systemroot%\system32\inetsrv\appcmd configure trace "Websitename" /enablesite

Tabelle 16.2 beschreibt die Parameter dieser Befehle.

Es werden die Ereignisse ins Ablaufverfolgungsprotokoll geschrieben, die bis zu dem Zeitpunkt, an dem der Fehler auftritt, ausgelöst wurden. Das heißt, dass nur Fehlerbedingungen, die einen Status-/Unterstatuscode angeben (failureReason="STATUS_CODE"), die gesamte Anforderung von Anfang bis Ende aufzeichnen. Bei timeTaken-Auslösern erhalten Sie alle Ereignisse, die bis zur Überschreitung des Zeitlimits aufgetreten sind. Im Beispiel aus dem letzten Absatz bewirkt die Fehlerbedingung, die ein Limit von 10 Sekunden definiert, dass IIS nur die Ereignisse aufzeichnet, die bis zum Ablauf dieser 10-Sekunden-Frist aufgetreten sind; Ereignisse, die danach kommen, werden nicht mehr ins Protokoll geschrieben. Dasselbe gilt für Auslöser, die einen Ausführlichkeitsgrad definieren: Sobald das erste Ereignis auftritt, dessen Ausführlichkeitsgrad gleich oder höher als die Auslösungsbedingung ist, werden alle Ereignisse protokolliert, die bis zu diesem Zeitpunkt aufgetreten sind (inklusive des Auslöserereignisses).

Nehmen wir an, Ihre Auslösungsbedingung legt fest, dass für Foobar.aspx ein Protokoll geschrieben wird, wenn der Ausführlichkeitsgrad den Wert WARNING hat. Weil Ausführlichkeitsgrade mit höherem Schweregrad ebenfalls entsprechend interpretiert werden, generiert IIS das Protokoll für Foobar.aspx, sobald das erste Ablaufverfolgungsereignis zu einer Anforderung dieser URL eintrifft, bei dem der Ausführlichkeitsgrad WARNING, ERROR oder CRITICAL ERROR ist. Falls der Ausführlichkeitsgrad der Fehler-bedingung auf den Wert ERROR eingestellt ist, generiert IIS das Protokoll, sobald das erste Ablauf-verfolgungsereignis vom Typ ERROR oder CRITICAL ERROR auftritt.

Dieser Mechanismus soll Ihnen flexible Möglichkeiten geben, Fehlerbedingungen festzulegen und ein Protokoll zu generieren, sobald eine bestimmte Bedingung eintritt. Momentan werden vor allem die Bedingungen zu Statuscode und Zeitablauf verwendet. Aber auch der Ausführlichkeitsgrad ist nützlich, wenn Sie Anwendungsfehler analysieren, die benutzerdefinierte 200-»OK«-Meldungen an den Client liefern und Beschreibungen wie »Leider kann keine Verbindung zur Produktdatenbank hergestellt werden« enthalten. Lösen Sie einfach ein Ablaufverfolgungsereignis in Ihrem Code aus und konfigurieren Sie die Ausführlichkeitsgrad-Fehlerbedingung so, dass entsprechende Protokolle generiert werden. Dann werden Sie solche Fehler schnell aufspüren!

Eric DeilySenior Program Manager Lead



Lesen der FRT-ProtokolleDie von der FRT generierten Protokolle können Sie sich im Windows-Explorer ansehen, indem Sie in den Ordner mit den FRT-Protokolldateien wechseln und den Unterordner W3SVC<n> öffnen, wobei <n> für die Site-ID steht. Jedes Ereignis wird in einer eigenen XML-Datei protokolliert. Die XML-Dateien verwenden einen Stylesheet namens Freb.xsl, der die XML-Protokolldatei formatiert, sodass sie einfacher zu lesen und auszuwerten ist. Klicken Sie doppelt auf die Datei Fr<xxxxxx>.xml, die Sie sich ansehen möchten. Daraufhin öffnet sich eine Zusammenfassungsseite, die ähnlich wie in Abbil-dung 16.4 aussieht.

Vorsicht In der Standardeinstellung können Sie sich die FRT-Protokolldateien auf Windows Server 2008 nicht anse-hen, weil die erweiterte Sicherheitskonfiguration (Enhanced Security Configuration, ESC) des Internet Explorers aktiv ist. Unter Umständen werden Sie aufgefordert, about:internet zur Liste der vertrauenswürdigen Sites hinzuzufügen. Falls Sie auch danach nicht in der Lage sind, die Protokolldatei unter Windows Server 2008 anzuzeigen, müssen Sie ESC im Server-Manager deaktivieren. Das schwächt die Serversicherheit, was das Anzeigen von Webinhalten betrifft. Daher ist es besser, wenn Sie sich die FRT-Protokolldateien auf einem Clientcomputer ansehen. Auf jeden Fall sollten Sie ESC sofort wieder aktivieren, nachdem Sie sich die Protokolldateien angesehen haben.

Tabelle 16.2 Parameter beim Aufruf von Appcmd zum Konfigurieren der FRT


URL Die URL, die Sie überwachen wollen

Pfad Die Inhaltstypen, die Sie überwachen wollen. Muss *, *.aspx, *.asp oder benutzerdefiniert sein. Falls Sie dieses Argument weglassen, wird "*" als Standardeinstellung verwendet.

Statuscodes Der Statuscode, den Sie überwachen wollen. Wird dieses Argument weggelassen, lautet die Standardeinstellung "500,400,401,403".

Zeitlimit Nach wie vielen Sekunden eine Anforderung als fehlgeschlagen interpretiert wird. Wird dieses Argument weg-gelassen, ist die Standardeinstellung 1 Minute.

Bereiche Die Liste der Anbieter und Teilbereiche, die Sie für die Ablaufverfolgungsregel aktivieren. Hier stehen die Anbieter zur Auswahl, die in der Konfiguration registriert sind. Standardmäßig sind dies die Anbieter ASP, ASPNET, ISAPI oder WWW Server. Falls ASP.NET installiert ist, können Sie zusätzlich Infrastructure, Module, Page oder AppServices angeben. Für den Anbieter WWW Server können Sie Authentication, Security, Filter, StaticFile, CGI, Com-pression, Cache, RequestNotifications, IISGeneral oder All angeben. Lassen Sie dieses Argument weg, werden alle registrierten Anbieter und alle ihre Teilbereiche aufgezeichnet.

Grad Der Ausführlichkeitsgrad, den IIS 7.0 aufzeichnen soll. Zur Auswahl stehen General, Critical Errors, Errors, Warnings, Information und Verbose. Wird dieses Argument weggelassen, lautet die Standardeinstellung Verbose.



Abbildung 16.4 Die Zusammenfassungsseite einer FRT-Protokolldatei

Direkt von der Quelle: Wo sind meine FRT-Protokolldateien?Sie haben also die FRT konfiguriert, aber jetzt können Sie Ihre Protokolldateien nicht finden? Eine Problembehandlung für das Problembehandlungsfeature ist fällig. Fangen wir ganz vorne an:

1. Stellen Sie sicher, dass Sie die FRT auf Siteebene aktiviert haben. Wenn Sie eine Site verwalten, aber nicht den IIS-Server administrieren, können Sie zwar in Ihren Web.config-Dateien Fehler-bedingungen definieren und festlegen, was aufgezeichnet wird, aber Sie müssen den IIS-Admi-nistrator bitten, die FRT für Ihre Site zu aktivieren. Wählen Sie im Internetinformationsdienste-Manager die Website aus und klicken Sie im Fensterabschnitt Aktionen unter Konfigurieren auf Ablaufverfolgung für Anforderungsfehler. Daraufhin öffnet sich ein Dialogfeld, in dem Sie die FRT aktivieren und einstellen, in welchem Verzeichnis die Protokolle gespeichert werden und wie viele Dateien maximal angelegt werden.

2. Stellen Sie sicher, dass die Identität des Arbeitsprozesses Vollzugriff auf das Protokollverzeich-nis hat. Der Arbeitsprozess benutzt nämlich seine eigene Identität, um die Protokolldateien zu schreiben, das W3SVC<n>-Verzeichnis anzulegen (wobei <n> Ihre Site-ID ist) und alte Dateien zu löschen.



Wenn Sie die Registerkarte Request Details oben auf der Seite anklicken, stehen mehrere Formate zum Anzeigen der Details zur Verfügung:

� Complete Request Trace Zeigt jeden einzelnen Schritt in der Ablaufverfolgung an, ein Ereignis nach dem anderen

� Filter Notifications Zeigt alle Ereignisse in der Ablaufverfolgung an, die von Filtern generiert wurden. So können Sie sehen, welche ISAPI-Filter Ihre Anforderung durchlaufen hat, wie lange sie in jedem Filter verarbeitet wurde und welche Änderungen an Anforderung oder Antwort (zum Beispiel Hinzufügen oder Entfernen von Headern) ein Filter vorgenommen hat.

� Module Notifications Zeigt alle Module an, durch die Ihre Anforderung geleitet wurde (in der Reihenfolge, in der die Module durchlaufen wurden). Dabei werden auch die Benachrichtigungen aufgeführt, die die Verarbeitung der Anforderung im jeweiligen Modul ausgelöst haben, und es wird angegeben, wie lange die Anforderung im Modul verarbeitet wurde.

� Performance View Zeigt an, wie viel Zeit für Teiloperationen (zum Beispiel Authentifizierung oder Durchlaufen der ISAPI-Filter) verbraucht wurde. Anhand dieser Angaben können Sie heraus-finden, wo Ihre Anforderung am meisten Zeit verbracht hat.

� Authentication Authorization Zeigt Ereignisse der Ablaufverfolgung an, die mit Authentifi-zierung und Autorisierung zu tun haben

� ASP.NET Page Traces Zeigt die Ereignisse in der Ablaufverfolgung an, die durch Aufrufe von Trace.Write() und Trace.Warn() ausgelöst wurden. Wenn die Seitenablaufverfolgung auf Ihrer ASPX-Seite aktiviert ist, werden auch die intern ausgelösten Ereignisse für jedes ASP.NET-Seitenereignis aufgezeichnet.

� Custom Module Traces Zeigt Ereignisse an, die von verwalteten Modulen mit der System.Diag-nostics-API generiert wurden (über Aufrufe von System.Diagnostics.TraceSource)

3. Suchen Sie im Ereignisprotokoll Ereignisanzeige\Windows-Protokolle\Anwendungen nach Ereignissen von der Quelle Microsoft-Windows-IIS-W3SVC-WP. Am häufigsten werden Fehler durch Probleme mit Berechtigungen verursacht. Andere mögliche Fehler sind:

� Falsche Konfiguration Das Ereignis gibt an, welches Element der Konfiguration falsch ist. Sie müssen die Konfiguration korrigieren, damit eine Fehlerbedingung ausgelöst werden kann.

� Dateisystem ist voll Es werden Protokolldateien geschrieben, und zwar im XML-Format. Stellen Sie sicher, dass auf dem Volume genug Platz für die Protokolle ist. Falls dieser Fehler auf dem Systemlaufwerk auftritt, dürften Probleme mit der FRT die kleinste Ihrer Sorgen sein!

Anhand dieser Schritte sollten Sie herausfinden können, warum Sie keine FRT-Protokolldateien erhalten.




Wenn Sie das Pluszeichen (+) neben einem Ereignis anklicken, werden die Details zu diesem Ereignis angezeigt. Abbildung 16.5 zeigt einen Abschnitt der Ansicht Complete Request Trace, der beweist, dass der Benutzer erfolgreich authentifiziert wurde, bevor IIS den Fehlerstatus gesetzt hat. Das bedeutet, dass die Ursache bei den Berechtigungen liegt, nicht bei der Authentifizierung. Genau diesen Fall haben wir im Beispiel weiter oben simuliert (siehe Abbildung 16.3 weiter oben in diesem Kapitel). Wie Sie sehen, sind die Ereignisse verschachtelt und die Ablaufverfolgung gibt die Dauer jedes Schritts in der Einheit Millisekunden an.

Abbildung 16.5 Ausschnitt einer FRT-Protokolldatei in der Ansicht Request Details

Wenn Sie oben auf der Seite die Registerkarte Compact View auswählen, können Sie sich eine Liste mit den vollständigen Details aller Ereignisse ansehen (Abbildung 16.6).

Mithilfe von FRT-Protokollen können Sie die Ursache eines Problems aufspüren. Falls zum Beispiel die Beantwortung einer Anforderung sehr lange dauert, können Sie auf der Registerkarte Request Details die Ansicht Performance View auswählen und schnell herausfinden, welche Module oder ISAPI-Filter in der Anforderungspipeline vermutlich für die Verzögerung verantwortlich sind.



Abbildung 16.6 Eine FRT-Protokolldatei in der Ansicht Compact View

Direkt von der Quelle: Die FRT liefert Daten für die Suche nach den Ursachen eines ProblemsEines meiner Lieblingsfeatures in IIS 7.0 wurde ursprünglich FREB getauft, was für »Failed Request Event Buffering« steht. Es hat jetzt die seriösere Bezeichnung Ablaufverfolgung für Anforderungs-fehler (Failed Request Tracing, FRT), aber hier bei uns verwenden wir gelegentlich noch den Kose-namen FREB. Mithilfe der FRT können Sie IIS so konfigurieren, dass es nach bestimmten Fehler-bedingungen »Ausschau hält« und Ihnen detaillierte Ablaufverfolgungsinformationen über eine Anforderung liefert. Daher ist es viel einfacher als in älteren Versionen von IIS, Fehler zu diagnosti-zieren, insbesondere diese schwer reproduzierbaren Probleme, die natürlich immer nur um 3 Uhr nachts auftreten, wenn Sie im Bett liegen sollten. IIS protokolliert nicht nur alle IIS-Ablaufverfolgungsereig-nisse, die wir in unserem Code verteilt haben, sondern auch ASP.NET-Ablaufverfolgungsereignisse und sogar Ihre eigenen Seitenablaufverfolgungsereignisse! Es ist ein sehr leistungsfähiges Feature.

Stellen Sie fest, dass Anforderungen allmählich immer langsamer oder überhaupt nicht abgeschlossen werden? Konfigurieren Sie einfach die FRT, um Anforderungen zu überwachen, die ein bestimmtes Zeitlimit überschreiten. Dann erhalten Sie detaillierte Informationen zu allen Vorgängen, die während der Verarbeitung solcher langsamer Anforderungen durchgeführt wurden, bis das Zeitlimit über-schritten ist. Anhand dieser Informationen sollten Sie in der Lage sein, die Stelle ausfindig zu machen, an der die Verzögerung auftritt.



Integrieren von Ablaufverfolgung und ASP.NETIn IIS 7.0 können Sie mithilfe der FRT Ablaufverfolgungsausgaben von ASP.NET-Anwendungen sammeln.

Aufzeichnen von ASP.NET-Ablaufverfolgungsausgaben mit der FRTWenn Sie die FRT mit ASP.NET-Ablaufverfolgungsausgaben kombinieren, erhalten Sie gegenüber herkömmlichen Methoden zum Sammeln und Analysieren von ASP.NET-Ablaufverfolgungsausgaben deutliche Vorteile. Mit dem FRT-Framework können Sie Daten zu erfolgreichen Anforderungen aus-filtern und sich die Ablaufverfolgungsdaten im Kontext der Ablaufverfolgungsinformationen anderer Systemkomponenten ansehen. Natürlich lässt sich die FRT ergänzend zu herkömmlichen Methoden einsetzen, sodass Sie sich auch weiterhin die ASP.NET-Ablaufverfolgungsausgaben ansehen können, wenn Sie die Anwendung lokal auf dem Server abrufen oder die Anwendungsablaufverfolgung aktivieren.

Vorbereiten von ASP.NET-Anwendungen für die AblaufverfolgungWenn ein Entwickler zum Debuggen einer ASP.NET-Anwendung Ablaufverfolgungsausgaben gene-rieren will, braucht er lediglich Trace.Warn() und Trace.Write() in eine ASP.NET-Seite einzufügen und die Daten auszugeben, die Sie überwachen wollen. (Sie müssen außerdem die Ablaufverfolgung auf Seitenebene aktivieren, indem Sie am Anfang der Seite die Direktive <%@ Page Trace="true"%> einfügen.)

Um die ASP.NET-Ablaufverfolgungsausgaben dann mithilfe der FRT aufzuzeichnen, erstellen Sie zum Beispiel eine FRT-Regel mit den Einstellungen aus Tabelle 16.3. Bei Verwendung dieser Einstellungen werden nur die ASP.NET-Ablaufverfolgungsausgaben aufgezeichnet. Wenn Sie sich die ASP.NET-Ablaufverfolgungsausgaben im Kontext anderer Ereignisse ansehen wollen, können Sie weitere Anbieter oder Bereiche zur Regel hinzufügen.

Bekommen Sie sporadisch 401-, 404- oder Server-500-Fehler? IIS ist berüchtigt dafür, dass es diese Standardfehlermeldungen aus einer Vielzahl ganz unterschiedlicher Gründe zurückgibt. Bei IIS 7.0 liefern Ihnen detaillierte Fehler viel mehr Informationen, falls Sie auf dem lokalen Computer arbeiten. Aber wenn Sie wissen wollen, welche Komponente den Fehler zurückgegeben hat oder was vor dem Fehler passiert ist, müssen Sie die FRT nutzen.

Wenn Sie sich ein FRT-Protokoll ansehen, bekommen Sie standardmäßig die Registerkarte Request Summary angezeigt, die zusammenfassende Informationen über die Anforderung sowie alle Fehler- und Warnungsereignisse enthält, die im Ablaufverfolgungsprotokoll gefunden wurden. Das ist eine hervorragende Möglichkeit, das Ereignis aufzuspüren, das Ihre Fehler wahrscheinlich auslöst. Wenn Sie auf View Trace klicken, können Sie sich die gesamte Hierarchie der Ereignisse, die während der Anforderung aufgetreten sind, in der ursprünglichen Reihenfolge ansehen. Das Ereignis, das Sie angeklickt haben, ist hervorgehoben, sodass Sie sofort sehen, an welcher Stelle im Ablauf es aufge-treten ist.

Bill StaplesIIS Product Unit Manager



Wenn Ihre ASP.NET-Seite das nächste Mal angefordert wird und die ASP.NET-Ablaufverfolgung für diese Seite aktiviert ist, wird ein FRT-Protokoll generiert. In den FRT-Ausgaben finden Sie AspNetPage-TraceWriteEvent- oder AspNetPageTraceWarnEvent-Einträge, die Sie analysieren können.

LeistungsaspekteDie FRT ist für die Untersuchung bekannter Probleme sowie die Überwachung und regelmäßige Analyse der Systemintegrität gedacht. Sie setzt auf der Infrastruktur der IIS-Ablaufverfolgung auf, die relativ effizient ist, sofern sie vernünftig genutzt wird. Sie können Ihr System mithilfe der FRT dauerhaft über-wachen, aber denken Sie daran, dass die FRT einigen Aufwand verursacht. Die FRT generiert zwar nur eine Protokolldatei, wenn eine Anforderung fehlschlägt, aber sie muss alle Daten, die für ein Protokoll benötigt werden, für jede Anforderung puffern, weil diese Daten eventuell benötigt werden, wenn ein Anforderungsfehler auftritt. Falls Sie also die FRT für einen bestimmten Anforderungstyp aktiviert haben, wird jedes Mal, wenn eine entsprechende Anforderung eingeht, ein gewisser Aufwand fällig (in erster Linie wird Arbeitsspeicher belegt), ganz unabhängig davon, ob die Anforderung letztlich erfolgreich ist oder einen Fehler verursacht.

Die FRT ist so entworfen, dass sie auf einem Produktivcomputer im Hintergrund ausgeführt wird, um Fehler zu analysieren, die sich nur schwer reproduzieren lassen. Je nachdem, welche Zielsetzungen Sie für die Leistung Ihrer Anwendung definiert haben, kann es sinnvoll sein, die FRT dauerhaft im Hintergrund laufen zu lassen (mit effizienten Einstellungen, wie im nächsten Absatz beschrieben). Das ist oft nützlich, weil es die Diagnose seltener oder schwer reproduzierbarer Fehlerbedingungen erleichtert. Falls Sie die FRT auf diese Weise einsetzen wollen, sollten Sie Leistungstests durchführen, um sicherzustellen, dass Ihre FRT-Einstellungen die Leistung der Anwendung nicht zu stark bremsen.

Falls Sie die FRT in einer Produktivumgebung aktivieren, können Sie die Auswirkungen auf das System dadurch minimieren, dass Sie die Ablaufverfolgungsregel so eng wie möglich auf den Aspekt konzen-trieren, den Sie untersuchen wollen. Das Ziel besteht darin, nur genau die Ablaufverfolgungsdaten aufzuzeichnen, die Sie wirklich brauchen. Geben Sie als Einstellung für den protokollierten Inhalt nur die URLs an, die Sie überwachen wollen. Sie können die Auswirkung auf Ihr Produktivsystem noch weiter verringern, indem Sie Ihre Ablaufverfolgungsregeln so gestalten, dass nur gerade die Nachrichten aufgezeichnet werden, die Sie für die Analyse des Problems vermutlich brauchen. Wenn Sie zum Beispiel eine ASP.NET-Anwendung debuggen, reicht es oft aus, wenn Ihre FRT-Regel nur den Anbieter ASPNET und den Bereich Page definiert. Grenzen Sie die Regel so weit wie möglich auf einen bestimmten Anbie-ter, Bereich, Ausführlichkeitsgrad, eine URL oder eine Anforderung ein, sodass Sie nur Daten für die Fehlerdefinitionen aufzeichnen, an denen Sie interessiert sind.

Tabelle 16.3 Minimale FRT-Regeleinstellungen zum Aufzeichnen der ASP.NET-Ablaufverfolgungsausgaben

Einstellung Wert

Objekt der Ablaufverfolgung ASP.NET (*.aspx)

Statuscodes 200

Anbieter ASPNET

Ausführlichkeitsgrad Ausführlich

Bereiche Page



ProblembehandlungIn den restlichen Abschnitten dieses Kapitels erhalten Sie einen Überblick über die üblichen Verfahren der Problembehandlung bei einer IIS 7.0-Anwendung. Außerdem lernen Sie einige Tools für die Prob-lembehandlung und Lösungen für einige häufig auftretende Probleme kennen.

Anwenden eines VerfahrensWenn Sie eine Anwendung debuggen wollen, sind Intuition und Experimente oft eher gefordert als streng wissenschaftliche Prinzipien. Trotzdem liefert Ihre Intuition bessere Ergebnisse, wenn Sie im Rahmen eines bestimmten methodischen Verfahrens arbeiten, einer Methodologie. Wenn Sie IIS-Anwendungen debuggen, sollten Sie erst einmal den Fehler identifizieren. Das kann dadurch erschwert werden, dass die Fehlermeldung zwischen Browser und Server mehrere Schritte durchläuft. Nachdem Sie sich Details über den Fehler verschafft und offensichtliche Ursachen ausgeschlossen haben, sollten Sie sich fragen, wodurch die unerwartete Antwort ausgelöst wurde. Machen Sie anhand der Fehler-details und der Informationen aus Protokollen der Ablaufverfolgung das Modul ausfindig, das die unerwartete Antwort generiert hat, weil es einen Fehler verursacht oder viele Systemressourcen verbraucht.

Weiterführende Informationen Eine ausführliche Beschreibung der Schritte, mit denen Sie Fehlerdetails identifi-zieren und die erste Analyse durchführen, finden Sie unter http://mvolo.com/blogs/serverside/archive/2007/07/26/Troubleshoot-IIS7-errors-like-a-pro.aspx.

Erweiterbarkeit der AblaufverfolgungWie alle Komponenten in IIS 7.0 ist auch die Ablaufverfolgung als Modul implementiert, das erweitert oder sogar durch benutzerdefinierten Code ersetzt werden kann. Verwaltete Codemodule können mithilfe der System.Diagnostics-API (Application Programming Interface) Code implementieren, der Ablaufverfolgungsausgaben an die IIS-Ablaufverfolgungsinfrastruktur übergibt. Auf diese Weise können Sie für die Problembehandlung von Webserver und Anwendungen die Diagnoseinformationen von Fremdherstellerkomponenten nutzen. Wie Sie IIS 7.0 so konfigurieren, dass es Ablaufverfolgungs-informationen sammelt, die von verwalteten Modulen und ASP.NET-Anwendungen generiert werden, ist auf http://www.iis.net beschrieben; suchen Sie dort nach »How to Add Tracing to IIS7 Managed Modules«.

Das in IIS 7.0 eingebaute FRT-Modul generiert Ablaufverfolgungsdaten im XML-Format, das problemlos von beliebigen Anwendungen weiterverarbeitet werden kann. Falls Sie also nur nach einer anderen Möglichkeit suchen, Ablaufverfolgungsinformationen zu verarbeiten, nachdem diese Daten generiert wurden, können Sie einfach die vorhandenen Protokolle der Ablaufverfolgung auswerten. Dank der nativen APIs für die Webservererweiterbarkeit ist es aber auch möglich, eigene Module zu entwickeln, die Ablaufverfolgungsinformationen direkt zu verarbeiten und selbst zu entscheiden, welche Ablaufverfolgungsinformationen wann ausgewertet werden und in welcher Form sie berichtet werden.


Problembehandlung 553

Das Ziel Ihrer Problembehandlung sollte darin bestehen, das Problem innerhalb der oft unübersicht-lichen Masse von Komponenten zu isolieren, die eine Anforderung bearbeiten. Dabei reicht es nicht, lediglich die IIS-Anforderungsverarbeitungspipeline zu betrachten. Sie müssen zusätzlich einige oder alle der folgenden Komponenten untersuchen:

� Browsereinstellungen

� Wie geht der Browser bei der Fehlerberichterstattung vor?

� Ist der Browser richtig konfiguriert?

� Clientcomputereinstellungen

� Sind die Firewalleinstellungen richtig konfiguriert?

� Netzwerkinfrastruktur

� Funktioniert das Netzwerk?

� Netzwerkkonfiguration

� Ist die Netzwerkumgebung des Browsers richtig konfiguriert?

� Ist die Netzwerkumgebung des Servers richtig konfiguriert?

� Können Browser und Server miteinander kommunizieren?

� Authentifizierung/Autorisierung

� Übergibt der Benutzer gültige Anmeldeinformationen?

� Wird der Benutzer erfolgreich vom Server authentifiziert?

� Erlauben die Anmeldeinformationen des Benutzers Zugriff auf die angeforderten Ressourcen?

� IIS-Ausführung

� Welche anderen Anforderungen werden ausgeführt, während der Fehler auftritt?

� IIS-Konfiguration und -Einstellungen

� Sind die richtigen Module installiert?

� Website-/Anwendungskonfiguration und -einstellungen

� Wurde die Website gestartet?

� Sind virtuelle Verzeichnisse richtig konfiguriert?

� Arbeitet die Umleitung richtig?

� Funktion einzelner Module

� Welche Module verbrauchen den Großteil der Verarbeitungszeit?

� Funktion und Reaktion von .NET-Anwendungen

� Laufen benutzerdefinierte Anwendungen wie erwartet?

� Aktueller Serverstatus

� Welchen Status haben die aktuellen Anwendungspools?

� Welchen Status haben die aktuellen Arbeitsprozesse?

� Welchen Status haben gehostete Sites?

� Welchen Status hat die Anwendungsdomäne?

� Welchen Status haben die momentan ausgeführten Anforderungen?



� Websiteinhalt

� Was genau wird angefordert?

� Serverleistung

� Funktioniert der Server einwandfrei?

Wenn eine Anforderung fehlschlägt, sollten Sie erst detaillierte Informationen über das Problem zusam-menstellen und dann systematisch die Komponenten untersuchen, die die Anforderung verarbeiten. Auf diese Weise verschwenden Sie keine Zeit damit, im Rateverfahren Lösungen für eine unbestätigte Diagnose zu suchen.

Arbeiten mit Tools und DienstprogrammenDieser Abschnitt stellt kurz einige unverzichtbare Problembehandlungstools und -dienstprogramme vor. Mit diesen Tools können Sie systematisch die vielen Komponenten untersuchen, die dafür ver-antwortlich sein könnten, wenn eine Website oder Anwendung nicht wie erwartet antwortet.

Machen Sie sich genau mit diesen Dienstprogrammen vertraut. Wenn Sie ein schwieriges Problem beseitigen müssen, hilft Ihre Erfahrung Ihnen nicht nur, das Problem effizient aufzuspüren, sondern ermöglicht es Ihnen auch, die volle Bandbreite möglicher Ursachen zu erkennen, die Sie untersuchen sollten.

Hinweis Das IIS 6 Diagnostics Toolkit (das AuthDiag, DebugDiag und SSL Diag umfasst) funktioniert nicht unter IIS 7.0, aber prüfen Sie auf http://www.iis.net, ob Updates für dieses nützliche Problembehandlungstool verfügbar werden.

Tabelle 16.4 listet die Tools und Dienstprogramme auf, die weiter unten in diesem Kapitel genauer beschrieben werden. Die Tabelle beschreibt kurz, wann und wie Sie diese Tools einsetzen sollten.

Tabelle 16.4 Problembehandlungstools

Tool oder Dienstprogramm Einsatzbereiche Sicherheits- oder Leistungsaspekte für Produktivsysteme

net start Prüfen, ob ein Dienst läuft, und Starten eines beendeten Dienstes

Keine

sc query Prüfen, ob ein Dienst läuft Keine

Ping Prüfen, ob grundlegende Netzwerkkonnektivität vor-handen ist

Keine

PortCheck Prüfen der Konnektivität über einen bestimmten Port auf dem Server

Keine

Tasklist Ermitteln der PID für einen Dienst. Mithilfe der PID können Sie den Status mit Netstat prüfen.

Keine

Netstat Auflisten aller überwachten Ports mit dem jeweiligen Protokoll, lokaler und Remoteadresse, Status und PID (suchen Sie nach der PID, die Sie mit Tasklist gefunden haben)

Keine



Arbeiten mit net start und sc query

Hinweis Arbeiten Sie die Abschnitte zu net start, Ping und PortCheck in diesem Kapitel durch, wenn Sie den Fehlercode 503 oder die Meldung »Seite kann nicht angezeigt werden« erhalten.

Sie können schnell prüfen, welche Dienste auf einem Computer laufen, indem Sie an einer Eingabeauf-forderung den folgenden Befehl eingeben:net start

Daraufhin werden alle aktiven Dienste aufgelistet. Damit Anforderungen bearbeitet werden, muss der Server auf jeden Fall den Windows-Prozessaktivierungsdienst (Process Activation Service, WAS) und den WWW-Publishingdienst (World Wide Web Publishing Service, W3SVC) ausführen. Mit dem folgenden Befehl stellen Sie schnell fest, ob der W3SVC-Dienst läuft, und starten ihn bei Bedarf:net start W3SVC

WFetch 1.4 Senden und Empfangen von Headern und Anforderun-gen ohne Beeinträchtigungen durch einen benutzer-freundlichen Browser; Anzeigen der unveränderten Anforderung und Antwort

Stellt ein Sicherheitsrisiko dar, weil Kennwörter gespeichert und Testzertifi-kate verwendet werden

Appcmd Auflisten und Starten von Sites und Anwendungspools; prüfen, ob die richtigen Netzwerkbindungen definiert sind

Keine

Process Monitor Überwachen von Aktivitäten in Dateisystem, Regist-rierung, Prozessen, Threads und DLLs (Dynamic-Link Library); Überwachen von Arbeitsprozessen

Ausschalten, wenn es nicht benutzt wird

Internetinformationsdienste-Manager

Untersuchen der momentan ausgeführten Arbeits-prozesse und Anforderungen

Keine

Ereignisanzeige Prüfen, ob Fehlerereignisse in Anwendungs- und Systemprotokolle eingetragen wurden

Keine

Ablaufverfolgung für Anforder-ungsfehler (Failed Request Tracing, FRT)

Generieren von Ablaufverfolgungsprotokollen, ins-besondere für Fehler, die nur sporadisch auftreten oder schwierig zu reproduzieren sind

Minimieren Sie die möglichen Leistungs-beeinträchtigungen, indem Sie den Bereich der überwachten Anforderungen stark eingrenzen

Zuverlässigkeits- und Leistungs-überwachung

Prüfen der Systemleistung; Identifizieren verdächtiger Prozesse, wenn der Server hängen zu bleiben scheint


Network Monitor Aufzeichnen von Netzwerkpaketen und Diagnostizieren von TCP-Sitzungsdaten (Transmission Control Protocol)


Tabelle 16.4 Problembehandlungstools (Fortsetzung)

Tool oder Dienstprogramm Einsatzbereiche Sicherheits- oder Leistungsaspekte für Produktivsysteme



Falls der Dienst noch nicht läuft, wird er gestartet. Andernfalls zeigt eine Meldung an, dass der Dienst bereits ausgeführt wird. W3SVC hängt von WAS ab. Falls Sie WAS beenden wollen, während W3SVC läuft, müssen Sie bestätigen, dass Sie beide Dienste beenden wollen. Und falls Sie W3SVC starten wollen, während WAS nicht läuft, startet der Befehl automatisch (allerdings ohne eine Meldung auszugeben) auch WAS.

Wenn Sie den Status eines Dienstes prüfen, ihn aber nicht starten wollen, falls er nicht läuft, können Sie stattdessen den folgenden Befehl eingeben, wobei Dienstname der Name des Dienstes ist, den Sie überprüfen wollen:sc query Dienstname

Zum Beispiel sieht die Ausgabe des Befehls sc query W3SVC folgendermaßen aus:SERVICE_NAME: w3svc TYPE : 20 WIN32_SHARE_PROCESS STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0

Arbeiten mit Ping

Hinweis Arbeiten Sie diesen Abschnitt durch, wenn Sie den Fehlercode 503 oder die Meldung »Seite kann nicht angezeigt werden« erhalten.

Grundlegende Netzwerkprobleme schließen Sie als Ursache aus, indem Sie vom Client aus den Server mit Ping überprüfen. Versuchen Sie erst ein Ping an den Hostnamen der URL, um sicherzustellen, dass er richtig in eine IP-Adresse aufgelöst wird. Dazu rufen Sie das Befehlszeilentool Ping in einer Eingabe-aufforderung auf, wie im folgenden Beispiel:ping www.contoso.com

Die Ausgabe müsste die entsprechende IP-Adresse zeigen. Ist das nicht der Fall, müssen Sie sicher-stellen, dass der DNS-Server (Domain Name System) des Clients richtig arbeitet. Prüfen Sie auch, ob der Client eine Hosts-Datei enthält, die möglicherweise die richtige IP-Adressenauflösung verhindert. Sofern das Problem nicht bei der IP-Adressenauflösung liegt, der Ping-Test auf die IP-Adresse des Servers aber nicht erfolgreich verläuft, liegt möglicherweise ein Problem mit der Netzwerkverbindung vor, entweder auf Client- oder Serverseite. Prüfen Sie aber auf jeden Fall, ob die Firewalleinstellungen auf dem Client eine Verbindung verhindern. Informationen über die Problembehandlung für Netzwerk-konnektivität finden Sie im Abschnitt »Arbeiten mit dem Network Monitor« weiter unten in diesem Kapitel.

Arbeiten mit PortCheckFalls ein Server nicht auf den Ping-Test antwortet, liegt das unter Umständen daran, dass die Firewall des Servers die Verbindung abweist oder der Dienst nicht den verwendeten Port überwacht. Das Tool PortCheck kann die TCP-Konnektivität (Transmision Control Protocol) für einen bestimmten Port unter der angegebenen IP-Adresse überprüfen. Das Tool liefert eine ausführliche Auflistung der unterschied-lichen Konnektivitätsprobleme, die möglicherweise für das Problem verantwortlich sind.



Hinweis Das Tool PortCheck ist auf der Begleit-CD enthalten, Sie können es aber auch von der Website http://mvolo.com/blogs/serverside/pages/Check-network-service-connectivity-with-PortChecker-tool.aspx herunterladen.

Rufen Sie das Tool PortCheck folgendermaßen in der Befehlszeile auf, um die Konnektivität durch einen bestimmten Port einer URL zu prüfen:portcheck www.contoso.com 80

Stattdessen können Sie auch die IP-Adresse angeben:portcheck 192.168.1.101 80

Arbeiten mit Tasklist und NetstatFalls Sie Probleme mit einem Dienst oder Prozess vermuten, der einen Port überwacht, können Sie alle Dienste und ihre Prozess-IDs (PID) auflisten, indem Sie in der Eingabeaufforderung den folgenden Befehl eingeben:tasklist /svc

Die Ausgabe sieht wie im folgenden Beispiel aus, wo die PID 564 für die Dienste W3SVC und WAS angezeigt wird:Abbildname PID Dienste ========================= ======== ============ System Idle Process 0 Nicht zutreffend System 4 Nicht zutreffend smss.exe 360 Nicht zutreffend ... svchost.exe 564 W3SVC, WAS

Suchen Sie in der Ausgabe von Tasklist nach der PID des Dienstes, bei dem ein Problem aufgetreten ist. Listen Sie anschließend alle überwachten Ports mit Protokoll, lokaler und Remoteadresse, Status und PID auf, indem Sie in der Eingabeaufforderung den folgenden Befehl eingeben:netstat -ano

Suchen Sie in der Ausgabe nach der PID, die Sie mit Tasklist ermittelt haben, und prüfen Sie die Adresse und den Status. Sie können auch nach Prozessen suchen, die einen Port überwachen, an dem Sie interes-siert sind. Die folgende Beispielausgabe zeigt, dass PID 4 den Port 80 überwacht:Aktive Verbindungen Proto Lokale Adresse Remoteadresse Status PID TCP 0.0.0.0:80 0.0.0.0:0 ABHÖREN 4 TCP 0.0.0.0:88 0.0.0.0:0 ABHÖREN 560 TCP 0.0.0.0:135 0.0.0.0:0 ABHÖREN 844 TCP 0.0.0.0:389 0.0.0.0:0 ABHÖREN 560 ...

Arbeiten mit WFetch 1.4

Hinweis WFetch 1.4 ist im IIS 6 Diagnostics Toolkit enthalten. Sie können WFetch 1.4 auch einzeln von der Adresse http://www.iis.net/go/1307 herunterladen.

Manchmal ist der vom Browser gemeldete Fehlertext so vage, dass die Ursache des Problems nicht mehr zu erkennen ist. Diese benutzerfreundliche Bevormundung der üblichen Browser umgehen Sie mit WFetch, das im Grunde ein simpler Browser ohne irgendwelche Erweiterungen ist. Mit WFetch



können Sie sich die unveränderten Daten ansehen, die zwischen Browser und Server ausgetauscht werden. Es ist daher ein ideales Werkzeug, um Authentifizierungsprobleme zu überprüfen oder sich benutzerdefinierte Header in den Anforderungs- und Antwortpaketen anzusehen.

Vorsicht Weil Sie mit WFetch Kennwörter speichern und Testsicherheitszertifikate manipulieren können, gefähr-det es unter Umständen die Sicherheit Ihrer Site. Daher empfiehlt Microsoft, dieses Tool nur für Tests einzusetzen, nicht in einer Produktivumgebung.

Sie starten WFetch 1.4 (in diesem Beispiel die Version für ein x86-System) aus der Programmgruppe IIS Diagnostics (32bit)\WFetch 1.4. Abbildung 16.7 zeigt, wie die Benutzeroberfläche von WFetch 1.4 gerade ein Protokoll ausgibt, nachdem die Standardwebseite auf dem lokalen Computer angefordert wurde. Sie können in der Oberfläche ein HTTP-Verb (GET, HEAD, PUT, DELETE, TRACE, POST, OPTIONS), den Host, den Port, die HTTP-Version sowie den Pfad angeben und Authentifizierungs- und Verbindungstypen auswählen. In komplizierten Fällen können Sie im Abschnitt Advanced Request von Hand Elemente zu einer Anforderung hinzufügen oder WFetch Teile der Anforderung aus einer Datei lesen lassen.

Abbildung 16.7 Die Benutzeroberfläche von WFetch 1.4



Hinweis Das Dateiformat der Hilfedateien, die in der aktuellen Version des IIS 6 Diagnostics Toolkit enthalten sind, wird in Microsoft Windows Vista und Windows Server 2008 nicht unterstützt. Verwenden Sie stattdessen die Online-Hilfe oder installieren Sie WinHlp32.exe, um die Hilfedateien lesen zu können. Der folgende Knowledge Base-Artikel enthält weitere Informationen und einen Link zur Downloadadresse von WinHlp32.exe: http://support.microsoft. com/kb/917607.

Arbeiten mit AppcmdFalls eine Site nicht läuft oder die Netzwerkbindungen für die Site aufgrund von Fehlern in Ihrer IIS-Konfiguration oder der Sitedefinition falsch konfiguriert sind, kann der IIS-Server keine Anforderungen für diese Site entgegennehmen. Mit Appcmd können Sie schnell prüfen, ob eine Site läuft und ihre Netzwerkbindungen richtig konfiguriert sind. Geben Sie in der Eingabeaufforderung den folgenden Befehl ein:appcmd list sites

Falls die IIS-Konfiguration in Ordnung ist, werden die Bindungen der Sitedefinition mit ihrem aktu-ellen Status aufgelistet (Started, Stopped oder Unknown). Überprüfen Sie, ob die Bindungen richtig sind. Falls die Site nicht gestartet wurde, verhindert unter Umständen ein Konfigurationsfehler, dass IIS die Site oder den Anwendungspool startet. Sie starten eine Site folgendermaßen mithilfe von Appcmd:appcmd start site Sitename

Auf ähnliche Weise können Sie mit diesem Befehl prüfen, ob ein Anwendungspool läuft:appcmd list apppools

Bei Bedarf können Sie den Anwendungspool mit dem folgenden Befehl starten:appcmd start apppool Poolname

Weiterführende Informationen Weitere Informationen über Appcmd finden Sie in Kapitel 7, »Verwenden von Befehlszeilentools«.

Arbeiten mit Process MonitorMit dem Tool Process Monitor können Sie das Dateisystem, die Registrierung, Prozesse, Threads und DLLs überwachen. Es ersetzt und erweitert zwei Tools aus älteren IIS-Versionen: Filemon und Regmon. Process Monitor ist ein leistungsfähiges Tool, das detaillierte Systeminformationen liefert und Such-, Filter- und Dateiprotokollierungsmöglichkeiten bietet, die Ihnen helfen, sich in der Vielzahl von Daten zurechtzufinden. Sie können die Prozessdaten in Echtzeit beobachten oder sie aufzeichnen und später auswerten.

Sie starten Process Monitor, indem Sie Procmon.exe aus dem Installationspfad heraus starten. Abbil-dung 16.8 zeigt das Fenster von Process Monitor, das einen kleinen Teil der Operationen auflistet, die ausgeführt werden, wenn ein Benutzer eine Site im Browser aufruft. Sie können sich Operationen zu Registrierungs-, Dateisystem- und Prozess/-Threadaktivitäten anzeigen lassen. Sie können die Opera-tionen anhand einer umfangreichen Liste von Kategorien und Werten filtern. Außerdem können Sie in Process Monitor die Liste durchsuchen und direkt zu einem Objekt springen, das an einer Operation beteiligt ist, zum Beispiel eine Temporärdatei oder ein Registrierungsschlüssel.



Abbildung 16.8 Das Fenster von Process Monitor, nachdem der Client eine Site im Internet Explorer aufgerufen hat

Wenn Sie doppelt auf eine Operation klicken, werden die Eigenschaften dieser Operation anzeigt. Hier erhalten Sie Informationen über das Ereignis, den Prozess (Abbildung 16.9) oder den Stack.

Abbildung 16.9 Die Registerkarte Process in den Ereigniseigenschaften einer Operation



Sie können sich auch zusammenfassende Berichte sowie eine Strukturansicht der Prozesse ansehen (Abbildung 16.10).

Abbildung 16.10 Die Strukturansicht für Prozesse im Process Monitor

Sie können im Process Monitor Ihre Arbeitsprozesse überwachen (filtern Sie nach »Process Name is w3wp.exe«). Wenn Sie prüfen wollen, welchem Anwendungspool die Arbeitsprozesse zugeordnet sind, können Sie im Internetinformationsdienste-Manager die Listen der Arbeitsprozesse und der aktiven Anforderungen anzeigen lassen (mehr dazu im nächsten Abschnitt). Auf diese Weise können Sie die Interna des Arbeitsprozesses untersuchen und feststellen, welche Anforderungen er ausführt, in welcher Phase diese Anforderungen sind und welche Anwendungsdomänen in diesen Prozess geladen sind.

Sie können mit dem Process Monitor auch systemweite Details zu einer Reihe von Ereignissen unter-suchen, wenn es im Rahmen Ihrer Problembehandlung nötig wird, den Bereich der Informationen zu verlassen, die IIS-spezifische Tools wie die FRT aufgezeichnet haben.

Hinweis Der Process Monitor ist nicht in der Standardinstallation von Windows Vista oder Windows Server 2008 enthalten. Sie müssen ihn als Element einer benutzerdefinierten Installation auswählen. Bei Bedarf können Sie Process Monitor von der Adresse http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx herunterladen.

Arbeiten mit dem Internetinformationsdienste-ManagerDer Internetinformationsdienste-Manager greift auf die RSCA (Runtime State und Control API) zurück, um Daten zu den momentan laufenden Arbeitsprozessen und allen Anforderungen zu liefern, die unter diesen Prozessen abgearbeitet werden. Wählen Sie in der Strukturansicht des Internetinforma-tionsdienste-Managers den Server aus, blättern Sie im mittleren Fensterabschnitt nach unten und klicken Sie im Feld IIS doppelt auf Arbeitsprozesse. Der Internetinformationsdienste-Manager zeigt daraufhin die momentan ausgeführten Arbeitsprozesse an (Abbildung 16.11).



Abbildung 16.11 Anzeigen der momentan laufenden Arbeitsprozesse im Internetinformationsdienste-Manager

Wählen Sie den Arbeitsprozess aus, den Sie untersuchen wollen, und klicken Sie im Fensterabschnitt Aktionen auf Aktuelle Anforderungen anzeigen, um eine Liste der aktuellen Anforderungen für diesen Arbeitsprozess anzeigen zu lassen (Abbildung 16.12).

Abbildung 16.12 Anzeigen der momentan bearbeiteten Anforderungen im Internetinformationsdienste-Manager



Wenn Sie wissen, welche Arbeitsprozesse und Anforderungen momentan ausgeführt werden, ist es ein-facher, langsam beantwortete Antworten zu analysieren, deren Probleme dadurch verursacht werden, dass eine ganz andere Anforderung gerade sehr viele Systemressourcen verbraucht. Sie stellen unter Umständen auch fest, dass eine Anwendung Auswirkungen auf andere Anwendungen im selben Anwendungspool hat. Bei Bedarf können Sie die Anwendung dann in ihren eigenen Anwendungspool auslagern. Oder Sie erstellen eine FRT-Regel für die momentan ausgeführten Anforderungen und sehen sich an, an welcher Stelle sie blockieren und was mit diesen Anforderungen passiert, bevor das Problem auftritt.

Hinweis Sie können vom Programmcode aus über den WMI-Anbieter auf die RSCA zugreifen, oder in verwaltetem Code über den Namespace Microsoft.Web.Administration. Dort stellt die Klasse WorkerProcess folgende Informatio-nen über eine Anforderung zur Verfügung (GUID ist die eindeutige Anforderungskennung, die auch verwendet wird, wenn die Ablaufverfolgung für die Anforderung aktiviert ist):

Hinweis Beispiele, wie Sie im Code auf die RSCA zugreifen, finden Sie unter http://www.iis.net; suchen Sie nach »How to Access IIS7 RSCA Data« und klicken Sie auf den Artikel mit diesem Titel.

Sie können auf die RSCA auch mithilfe von Appcmd zugreifen, ohne irgendwelchen Code schreiben zu müssen! Beispiele, wie Sie Arbeitsprozessdaten mithilfe von Appcmd abfragen, finden Sie in Kapitel 10, »Verwalten von Anwendungen und Anwendungspools«.

Arbeiten mit der EreignisanzeigeIn der Ereignisanzeige können Sie überprüfen, warum ein Anwendungspool beendet wurde oder nicht gestartet werden kann. Sie starten die Ereignisanzeige mit dem Eintrag Ereignisanzeige in der Pro-grammgruppe Verwaltung oder indem Sie im Dialogfeld Ausführen den Befehl eventvwr eingeben. Erweitern Sie in der Strukturansicht den Knoten Windows-Protokolle und wählen Sie Anwendung aus. Sie können die Liste der Ereignisse anhand der Ereignisquelle filtern.

Wichtig In der folgenden Onlinedokumentation, die als »IIS 7.0 Health Model« bezeichnet wird (also Diagnose- und Fehlerbedingungen, die in der Software auftreten können), finden Sie eine Liste der Ereignis-IDs zu IIS 7.0. Erweitern Sie in der linken Strukturansicht den Dokumentationsknoten oder klicken Sie die Links in der Dokumen-tation an, um sich eine Liste der Ereignisse anzeigen zu lassen, die mit bestimmten verwalteten Entitäten oder Aspekten verwalteter Entitäten verknüpft sind: http://technet2.microsoft.com/windowsserver2008/en/library/b19873a2-9f72-40c8-b73d-89f39cda62781033.mspx?mfr=true.

Fehler, die von der Quelle IIS-W3SVC-WP generiert werden (Abbildung 16.13), geben an, dass der Arbeitsprozess gestartet wurde, aber während der Initialisierung ein Fehler aufgetreten ist. Das kann zum Beispiel passieren, wenn der Konfigurationsabschnitt ungültig ist oder ein Modul nicht geladen oder nicht initialisiert werden kann. Klicken Sie doppelt auf ein Ereignis, um sich Details darüber anzeigen zu lassen.

GUID Site ClientIPAddress CurrentModule

ConnectionID LocalIPAddress TimeElapsed TimeInModule

Verb LocalPort PipelineState

URL HostName TimeInState



Abbildung 16.13 Ein Fehler im Anwendungsprotokoll der Ereignisanzeige weist auf ein Problem hin, das beim Initialisieren eines Arbeitsprozesses aufgetreten ist

Wählen Sie auch den Knoten System unter Windows-Protokolle aus. Fehler, die von den Quellen IIS-W3SVC-WP oder WAS in das Systemprotokoll geschrieben werden, weisen darauf hin, dass WAS den Arbeitsprozess nicht starten konnte. Die Ursache ist unter Umständen ein Problem in der Konfiguration, bei den Anmeldeinformationen der Anwendungspoolidentität, eine Überschreitung der Zahl erlaubter Arbeitsprozesse oder eine andere fehlende Ressource.

Ein Fehler im Systemprotokoll kann auch durch einen Bug in benutzerdefiniertem Anwendungscode verursacht werden. WAS deaktiviert einen Anwendungspool, falls eine Anwendung im Pool die RFP (Rapid Fail Protection) auslöst. RFP ist ein Mechanismus, mit dem IIS verhindert, dass sich ständig wiederholende Fehler in einer Anwendung das System lahmlegen. Wenn IIS wiederholt auftretende Abstürze in einem Arbeitsprozess oder eine hängengebliebene Anwendung erkennt, hält RFP den gesamten Anwendungspool an, in dem diese Anwendung enthalten ist.

Arbeiten mit der FRTMit der FRT generieren Sie Ablaufverfolgungsprotokolle für IIS-Antworten, die bestimmte Bedingungen verletzen. Welche Bedingungen dies sind, legen Sie im Internetinformationsdienste-Manager unter Ablaufverfolgungsregeln für Anforderungsfehler fest. Im Abschnitt »Problembehandlung mithilfe von Ablaufverfolgung und Diagnose« weiter oben in diesem Kapitel ist genauer beschrieben, wie Sie die FRT nutzen. Damit die FRT Ihre Problembehandlung möglichst effizient macht, sollten Sie die FRT-Regeln stark eingrenzen, sodass Sie nur genau die URLs untersuchen, bei denen Probleme auftreten.



Arbeiten mit der Zuverlässigkeits- und LeistungsüberwachungIn der Zuverlässigkeits- und Leistungsüberwachung untersuchen Sie den Gesamtzustand Ihres Servers. Sie starten die Konsole Zuverlässigkeits- und Leistungsüberwachung in der Programmgruppe Verwal-tung. Erweitern Sie in der Strukturansicht den Knoten Überwachungstools und wählen Sie System-monitor aus. Sie können Leistungsindikatoren für alle Aspekte der Serverleistung hinzufügen und konfigurieren (Abbildung 16.14).

Die Leistungsindikatoren zu Prozessen und Threads sollten Sie regelmäßig überwachen, zum Beispiel Prozessorzeit (%). Bei der Problembehandlung für eine ASP- oder ASP.NET-Anwendung sollten Sie sich die Active Server Pages-Leistungsindikatoren, die verschiedenen .NET-CLR-Leistungsindikatoren und die ASP.NET- sowie ASP.NET-Anwendungsindikatoren ansehen. Daneben bringt IIS 7.0 viele neue Leistungsindikatoren mit, die unter den Abschnitten W3SVC_W3WP und WAS_W3WP aufgeführt sind.

Direkt von der Quelle: Welche Bedingungen erkennt die FRT nicht?Die FRT ist ein leistungsfähiges Feature, das bei der Diagnose von Problemen in Webanwendungen eine große Hilfe ist. Leider gibt es einige wenige Bedingungen, bei denen Ihnen die FRT nicht helfen kann. Das sind unter anderem:

� Abstürzender Arbeitsprozess Sie dürfen nicht vergessen, dass die FRT die Ablaufverfolgungs-ereignisse zu den Anforderungen, die sie überwachen soll, im Prozessarbeitsspeicher puffert. Falls in diesem Prozess daher ein Fehler auftritt, der dazu führt, dass der Prozess unerwartet abgebrochen wird, gehen alle Ereignisse verloren, die in diesem Prozess gepuffert wurden.

� Fehler, die auftreten, bevor die Verarbeitung der Anforderung beginnt Die FRT liest die Konfiguration und beginnt, Ablaufverfolgungsereignisse zu den Anforderungen anzunehmen, sobald die Begin-Request-Benachrichtigung eintrifft. Einige Arbeiten werden aber durchgeführt, nachdem die Anforderung im Arbeitsprozess eintrifft, aber noch bevor diese Benachrichtigung empfangen wird. Unter anderem können folgende Probleme dazu führen, dass ein Anforderungsfehler auftritt, bevor die Begin-Request-Benachrichtigung empfangen wird:

� W3WP kann die Konfiguration für die Anforderung nicht laden

� Fehler beim URL-Rewriting

Falls Fehler in dieser Phase auftreten, bekommen Sie kein FRT-Protokoll. Am besten verwenden Sie in einem solchen Fall die ETW-Ablaufverfolgung oder prüfen das Anwendungsereignisprotokoll.




Abbildung 16.14 Anzeigen von Leistungsindikatoren im Systemmonitor

Die Zuverlässigkeits- und Leistungsüberwachung ist vor allem dann nützlich, wenn Sie einen Server untersuchen, der hängen zu bleiben scheint. Sie können ein Leistungsprotokoll speichern, indem Sie einen Sammlungssatz aufzeichnen. Erweitern Sie dazu in der Strukturansicht den Knoten Sammlungs-sätze, klicken Sie mit der rechten Maustaste auf den Knoten Benutzerdefiniert und wählen Sie im Kontextmenü den Befehl Neu\Sammlungssatz. Um das Problem zu isolieren, sollten Sie das Leistungs-protokoll in Kombination mit einem Speicherabbild des Prozesses analysieren, der auf dem Server läuft. Sie müssen das Speicherabbild zu einem Zeitpunkt anfertigen, an dem der Server hängenzu-bleiben scheint und gerade ein Leistungsprotokoll Daten aufzeichnet.

Arbeiten mit dem Network MonitorWenn Sie Konnektivitätsprobleme untersuchen, können Sie mit dem Network Monitor Netzwerkpakete aufzeichnen und TCP-Sitzungsdaten diagnostizieren. Sie starten den Network Monitor 3.1 aus der Programmgruppe Microsoft Network Monitor 3.1. Nachdem Sie eine Sequenz von Netzwerkpaketen aufgezeichnet haben, klicken Sie doppelt auf einen Frame in der Sequenz, um sich die Details (mit dem Inhalt im Hexadezimalformat) dieses Frames anzeigen zu lassen (Abbildung 16.15).



Abbildung 16.15 Anzeigen von Netzwerkpaketen im Network Monitor

Hinweis Der Network Monitor 3.1 ist nicht Teil einer Standardinstallation von Windows Vista oder Windows Server 2008. Sie können den Network Monitor 3.1 von http://www.microsoft.com/downloads herunterladen; suchen Sie nach »Microsoft Network Monitor 3.1«.

Problembehandlung für HTTPWenn Sie HTTP-Probleme untersuchen, sollten Sie zuerst sicherstellen, dass Ihr Browser die genauen Fehlerinformationen anzeigt. Dann prüfen Sie die verschiedenen Protokolle und zeichnen Ablaufverfol-gungen auf, um die Ursache der Fehler zu finden.

Kurze Fehler, benutzerdefinierte Fehler und ausführliche FehlerBei der Analyse von HTTP-Problemen müssen Sie erst einmal sicherstellen, dass die Fehler in Ihrem Browser auch unverändert gemeldet werden. Browser übersetzen bestimmte Fehlerantworten oft in benutzerfreundliche, kurze Textmeldungen, die nicht immer die eigentliche Ursache wiedergeben. In Microsoft Internet Explorer 7.0 deaktivieren Sie die benutzerfreundlichen Fehlermeldungen, indem Sie im Menü Extras den Befehl Internetoptionen wählen und auf der Registerkarte Erweitert das Kontroll-kästchen Kurze HTTP-Fehlermeldungen anzeigen deaktivieren. Anschließend müssen Sie den Internet Explorer beenden und neu starten.

Auf der Serverseite gibt IIS 7.0 in der Standardeinstellung nur allgemeine Fehlerinformationen an den Browser zurück. IIS 7.0 wurde aus Sicherheitsgründen so entworfen: Es soll vermieden werden, detail-lierte Fehlermeldungen an beliebige Besucher zu senden, weil darin unter Umständen Informationen über Ihre Umgebung enthalten sind, die Ihre Sicherheit gefährden. Außerdem kann IIS so konfiguriert



werden, dass es benutzerdefinierte Fehlerseiten zurückgibt, wenn ein bestimmter Fehlercode auftritt. Um sicherzustellen, dass Sie die vollständigen und unveränderten Details zu einem Fehler angezeigt bekommen, müssen Sie benutzerdefinierte Fehlerantworten abschalten und die Ausgabe von detail-lierten Fehlern aktivieren.

Sie konfigurieren IIS so, dass es detaillierte Fehlermeldungen an den Client sendet, indem Sie im Internetinformationsdienste-Manager die Site oder Anwendung auswählen, die Sie konfigurieren wollen, und doppelt auf Fehlerseiten klicken. Wählen Sie einen Statuscode aus, klicken Sie im Fenster-abschnitt Aktionen auf den Link Featureeinstellungen bearbeiten und wählen Sie die Option Detail-lierte Fehler aus. Vergessen Sie nicht, nach dem Debuggen wieder die Option Detaillierte Fehler für lokale Anforderungen und benutzerdefinierte Fehlerseiten für Remoteanforderungen auszuwählen.

Geben Sie in der Eingabeaufforderung den folgenden Appcmd-Befehl ein, um IIS so zu konfigurieren, dass es detaillierte Fehlermeldungen an den Client sendet:%systemroot%\system32\inetsrv\appcmd set config "Site/Anwendung" /section:httpErrors /errorMode:Detailed

Hinweis Im httpErrors-Konfigurationsabschnitt müssen Sie overrideMode auf den Wert Allow setzen.

Wenn Sie mit dem Debuggen fertig sind, sollten Sie verhindern, dass der Server weiterhin ausführliche Fehler sendet. Führen Sie dazu den folgenden Befehl aus:%systemroot%\system32\inetsrv\appcmd set config "Site/Anwendung" /section:httpErrors /errorMode:DetailedLocalOnly

In Anhang B, »IIS 7.0-Fehlermeldungen«, finden Sie weitere Informationen über Fehlermeldungs-einstellungen, etwa über benutzerdefinierte Fehler und die Möglichkeit der Umleitung. Sie sollten im Allgemeinen keine ausführlichen Fehlerinformationen zurückgeben, weil solche Details sich unter Umständen missbrauchen lassen, um Informationen über Ihr System zu sammeln. Ausführliche Fehler listen die folgenden Informationen auf:

� Status- und Unterstatuscode

� Beschreibung des Fehlers

� Modul

� Benachrichtigung

� Handler (statisch oder dynamisch)

� Fehlercode

� Angeforderte URL

� Physischer Pfad

� Anmeldemethode

� Angemeldeter Benutzer

� FRT-Protokollverzeichnis

� Wahrscheinliche Ursachen

� Mögliche Lösungen

� Links zu weiteren Informationen



Sehen Sie sich insbesondere die Daten zu Modul, Benachrichtigung und Handler an. Anhand dieser Informationen können Sie zumindest eingrenzen, welches Modul das Problem meldet. Das verrät Ihnen wiederum oft, welches Modul das Problem verursacht.

Hinweis Lesen Sie die Informationen in diesem Abschnitt, wenn Sie einen 404-Fehlercode erhalten.

Wenn Sie sich die angeforderte URL und den physischen Pfad ansehen, in den die URL aufgelöst wurde, können Sie schnell Konfigurationsprobleme bei einem virtuellen Verzeichnis identifizieren.

Prüfen der ProtokolleWenn Sie HTTP-Probleme untersuchen, sind vier Protokolle relevant: das Ereignisprotokoll, das Firewall-protokoll, das Websiteprotokoll und das Httperr-Protokoll. Das Ereignisprotokoll sehen Sie sich in der Ereignisanzeige an. (Weitere Informationen enthält der Abschnitt »Arbeiten mit der Ereignisanzeige« weiter oben in diesem Kapitel.) Von Interesse sind die folgenden Ereignisquellen:

� IIS-APPHOSTSVC

� IIS-W3SVC

� IIS-W3SVC-WP

� IIS-WMSVC

� WAS

� WAS-ListenerAdapter

� HttpService

Die folgende XML-Abfragedatei filtert das Ereignisprotokoll, sodass es einfacher auszuwerten ist. Diese Datei finden Sie auf der Begleit-CD unter dem Namen IIS-event-filter.xml.<QueryList> <Query Id="0" Path="Application"> <Select Path="Application">*[System[Provider[@Name='Microsoft-Windows-HttpService' or @Name='Microsoft-Windows-IIS-APPHOSTSVC' or @Name='Microsoft-Windows-IIS-W3SVC' or @Name='Microsoft-Windows-IIS-W3SVC-WP' or @Name='Microsoft-Windows-IIS-WMSVC' or @Name='Microsoft-Windows-WAS' or @Name='Microsoft-Windows-WAS-ListenerAdapter'] and (Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]</Select> <Select Path="Microsoft-Windows-HttpService/Trace">* [System[Provider[@Name='Microsoft-Windows-HttpService' or

Details zu ASP-SkriptfehlernIn IIS 7.0 sind Details zu ASP-Skriptfehlern standardmäßig versteckt und werden durch einen allgemeinen Fehler ersetzt. Damit der Server die Details zu ASP-Skriptfehlern an einen Browser sendet, müssen Sie in der Strukturansicht des Internetinformationsdienste-Managers die Website oder Anwendung auswählen und doppelt auf ASP klicken. Erweitern Sie im Abschnitt Kompilierung der angezeigten Liste den Knoten Debugeigenschaften und setzen Sie den Wert des Eintrags Fehler an Browser senden auf True. Sie können diese Einstellung auch mit Appcmd ändern, indem Sie in der Eingabeaufforderung den folgenden Befehl eingeben:

%systemroot%\system32\inetsrv\appcmd set config -section:asp -scriptErrorSentToBrowser:true

Vergessen Sie nicht, die Skriptfehlerdetails wieder zu verstecken, sobald Sie die Problembehandlung abgeschlossen haben.



@Name='Microsoft-Windows-IIS-APPHOSTSVC' or @Name='Microsoft-Windows-IIS-W3SVC' or @Name='Microsoft-Windows-IIS-W3SVC-WP' or @Name='Microsoft-Windows-IIS-WMSVC' or @Name='Microsoft-Windows-WAS' or @Name='Microsoft-Windows-WAS-ListenerAdapter'] and (Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]</Select> <Select Path="System">*[System[Provider[@Name='Microsoft-Windows-HttpService' or @Name='Microsoft-Windows-IIS-APPHOSTSVC' or @Name='Microsoft-Windows-IIS-W3SVC' or @Name='Microsoft-Windows-IIS-W3SVC-WP' or @Name='Microsoft-Windows-IIS-WMSVC' or @Name='Microsoft-Windows-WAS' or @Name='Microsoft-Windows-WAS-ListenerAdapter'] and (Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]</Select> </Query> </QueryList>

Das Firewallprotokoll und das Httperr-Protokoll sind in den Ordnern %SystemRoot%\System32\ LogFiles\Firewall beziehungsweise %SystemRoot%\System32\LogFiles\HTTPERR gespeichert. Das Websiteprotokoll wird in der Standardeinstellung täglich im Ordner %SystemDrive%\Inetpub\logs\ LogFiles\W3SVC<n> gespeichert, wobei <n> die Site-ID ist.

Suchen Sie in den Protokollen nach allen Fehlerbedingungen, die mit dem vorliegenden Problem zu tun haben könnten. (Falls die Protokolle im Standardformat gespeichert werden, können Sie sie im Windows-Editor öffnen oder ein Dienstprogramm wie Log Parser verwenden.) Kapitel 15 enthält weitere Informationen über Protokolldateien in IIS 7.0.

Hinweis Log Parser ist ein Tool, das Abfragen für Protokolldateien im Textformat, XML-Dateien und CSV-Dateien (kommagetrennte Werte) ermöglicht. Sie können Log Parser von http://www.microsoft.com/downloads herunter-laden; suchen Sie dort nach »Log Parser«. Abfragen müssen innerhalb des Kontextes der Log Parser-Eingabe-aufforderung ausgeführt werden. Sie öffnen die Eingabeaufforderung, indem Sie Log Parser aus der Programm-gruppe Log Parser starten. Weitere Informationen über Log Parser finden Sie in Kapitel 15.

Problembehandlung für häufig auftretende HTTP-SzenarienBei etlichen HTTP-Standardproblemen können Sie einen Standardansatz nutzen, um Fehler schnell zu diagnostizieren und zu beseitigen. Die folgenden Abschnitte beschreiben Problembehandlungs-verfahren für einige der häufigsten Szenarien, bei denen HTTP-Fehler auftreten.

Problembehandlung für statische und dynamische Inhalte

Hinweis Lesen Sie die Informationen in diesem Abschnitt, wenn Sie einen 404.3-Fehler erhalten. Viele 404-Fehler haben gar nichts mit MIME-Zuordnungen zu tun (falsche URL, falsche Struktur des virtuellen Verzeichnisses, URL-Rewriting, geänderte URL, fehlende physische Dateien und so weiter).

Die häufigste Ursachen, wenn ein »Nicht gefunden«-Fehler zurückgegeben wird, sind fehlende Handler-zuordnungen oder dass ein Anwendungsframework nicht installiert ist. Diese Fehler werden in Kapitel 11, »Hosting von Anwendungsentwicklungsframeworks«, ausführlich beschrieben. IIS fordert, dass bekannte MIME-Typen registriert werden, damit es genau kontrollieren kann, welche Dateitypen (identifiziert anhand ihrer Erweiterungen) direkt (als statischer Inhalt) ausgeliefert werden. MIME-Typen werden vererbt und können auf Site-, Anwendungs- oder Verzeichnisebene definiert oder



blockiert werden. Falls Sie einen MIME-Typ als statische Ressource registriert haben, liefert IIS 7.0 den

Inhalt einfach aus. Ist ein MIME-Typ dagegen nicht als statischer Inhalt registriert, kann er nur dann dynamisch ausgeliefert werden, wenn die Dateierweiterung einem Anwendungsframework zugeordnet ist, zum Beispiel ASP oder ASP.NET. Dafür wird ein Zuordnungshandler benötigt.

Wenn Sie ein Problem bei einem Zuordnungshandler untersuchen, sollten Sie prüfen, ob die dynamischen Zuordnungshandler konfiguriert werden, bevor der Handler für statische Dateien mit path="*" verb="*" deklariert wird. Kapitel 11 und Kapitel 12, »Verwalten von Webservermodulen« enthalten weitere Informa-tionen über Zuordnungshandler und dynamische Inhalte.

Problembehandlung für UNC-Zugriffsfehler

Hinweis Lesen Sie die Informationen in diesem Abschnitt, wenn Sie einen 500.16-Fehler erhalten.

Inhalte, die auf verteilten Computern gehostet werden, machen die Problembehandlung unter Umständen schwieriger. Fehler, die UNC-Inhalte (Universal Naming Convention) betreffen, werden als UNC-Zugriffs-fehler gemeldet. Sie können eine Reihe von Einstellungen überprüfen, um sicherzustellen, dass Ihr UNC-Inhalt richtig konfiguriert ist. (In Kapitel 9, »Verwalten von Websites«, finden Sie weitere Informationen über die Konfiguration von UNC.) UNC-Inhalt wird außerdem oft von einem Entwickler oder Anwendungs-besitzer verwaltet, der unter Umständen keine administrativen Privilegien auf dem IIS-Server hat. Sie können die Verwaltung der Inhalte inklusive der FRT-Einstellungen delegieren. Dabei stellen Sie normaler-weise die FRT-Regeln so ein, dass die Ablaufverfolgungsprotokolle in der UNC-Freigabe gespeichert werden. Das setzt wiederum voraus, dass Sie für die zugehörige Arbeitsprozess-ID geeigneten Zugriff auf den Speicherort der Protokolldatei konfigurieren.

Damit die FRT Ablaufverfolgungsprotokolle in eine UNC-Freigabe schreiben kann, müssen Sie der Arbeitsprozess-ID Vollzugriff auf die Netzwerkfreigabe und den entsprechenden Pfad auf dem Remote-computer geben. Anschließend müssen Sie auf dem IIS-Server die FRT für die Website aktivieren und als Zielverzeichnis für das FRT-Protokoll den UNC-Speicherort eintragen. (Diese Einstellungen nehmen Sie im Internetinformationsdienste-Manager vor, indem Sie in der Strukturansicht die Website auswählen und im Fensterabschnitt Aktionen auf Ablaufverfolgung für Anforderungsfehler klicken.)

Weiterführende Informationen Ausführliche Informationen, wie Sie die FRT mit verteilten Inhalten nutzen, finden Sie auf http://www.iis.net; suchen Sie nach »How to Enable Failed Request Tracing for UNC Hosting« und klicken Sie auf den Artikel mit diesem Titel.

In der Standardeinstellung ist bereits die Delegierung für die Administration der FRT-Einstellungen eingerichtet, sodass ein Administrator FRT-Regeln in die Web.config-Datei einer bestimmten Website eintragen kann. Sie können diese Einstellung im Internetinformationsdienste-Manager überprüfen, indem Sie in der Strukturansicht den Server auswählen und im Feld Verwaltung doppelt auf Delegierung von Features klicken. Prüfen Sie in der angezeigten Liste, ob beim Eintrag Ablaufverfolgungsregeln für Anforderungsfehler in der Spalte Delegierung der Wert Lesen/Schreiben eingetragen ist. Ändern Sie die Einstellung bei Bedarf, indem Sie im Fensterabschnitt Aktionen auf Lesen/Schreiben klicken.



Auf dem Remotecomputer können Sie FRT-Regeln direkt in die Web.config-Datei einfügen. Nehmen wir als Beispiel die FRT-Regel zum Verfolgen eines 401.3-Fehlercodes, die im Abschnitt »Ablaufverfolgung für einen bestimmten Fehlercode« weiter oben in diesem Kapitel beschrieben wurde. Um diese Regel hinzuzufügen, trägt der Anwendungsbesitzer das folgende <tracing>-Element in den <system.webServer>-Abschnitt der Web.config-Datei seiner Anwendung ein:<tracing> <traceFailedRequests> <clear /> <add path="*" customActionTriggerLimit="1"> <traceAreas> <add provider="WWW Server" areas="Authentication,Security,RequestNotifications,Module" verbosity="Verbose" /> </traceAreas> <failureDefinitions timeTaken="00:00:00" statusCodes="401.3" verbosity="Ignore" /> </add> </traceFailedRequests> </tracing>

Problembehandlung für 503-»Dienst nicht verfügbar«-FehlerFalls der WAS-Dienst den IIS-Arbeitsprozess, der eine bestimmte HTTP-Anforderung bearbeiten soll, nicht erstellen kann, bekommen solche Anforderungen eine 503-Antwort mit der Meldung »Dienst nicht verfügbar« zurück. Prüfen Sie in diesem Fall mit dem Befehl appcmd list apppools in der Eingabe-aufforderung, ob der Anwendungspool läuft oder nicht. Falls ein Anwendungspool beendet wurde, kann der RFP-Mechanismus (Rapid Fail Protection) von IIS 7.0 die Ursache sein. Durchsuchen Sie in der Ereignisanzeige das Systemprotokoll und prüfen Sie, ob WAS ein Ereignis mit der ID 5002 eingetragen hat: »Der Anwendungspool xxx wird aufgrund einer Serie von Fehlern bei den Prozessen für diesen Anwendungspool automatisch angehalten.« Suchen Sie im Systemprotokoll und im Anwen-dungsprotokoll nach weiteren Ereignissen, die angeben, dass der Anwendungspool angehalten oder überhaupt nie gestartet wurde.

Weiterführende Informationen Weitere Informationen zur Problembehandlung für einen 503-»Dienst nicht verfügbar«-Fehler finden Sie unter http://mvolo.com/blogs/serverside/archive/2006/10/19/Where-did-my-IIS7-servergo_3F00_-Troubleshooting-_2200_service-unavailable_2200_-errors.aspx.

Problembehandlung für FirewallproblemeFirewallprobleme können Sie ausschließen, wenn Sie die Website erfolgreich mit Ping oder dem Tool PortCheck überprüft haben. So können Sie sicherstellen, dass der Server die URL am richtigen Port entgegennimmt.

Falls Sie ein Firewallproblem vermuten, sollten Sie im Firewallprotokoll nach Fehlern suchen. Stellen Sie sicher, dass die Firewall im Netzwerk Ihres Servers richtig konfiguriert ist. Die Einstellungen der Windows-Firewall prüfen Sie, indem Sie zum Beispiel im Startmenü mit der rechten Maustaste auf Netzwerk klicken und den Befehl Eigenschaften wählen. Klicken Sie in der linken unteren Ecke des Fensters auf Windows-Firewall. Klicken Sie im Fenster Windows-Firewall auf Einstellungen ändern. Stellen Sie auf der Registerkarte Ausnahmen des Dialogfelds Windows-Firewalleinstellungen sicher,



dass die Ausnahmen Webverwaltungsdienst (HTTP) und WWW-Dienste (HTTP) aktiviert sind. Falls Sie in Ihrer Umgebung HTTPS benutzen, muss auch die Ausnahme Sichere WWW-Dienste (HTTPS) aktiviert sein.

Klicken Sie anschließend in der Programmgruppe Verwaltung auf Windows-Firewall mit erweiterter Sicherheit. Falls Sie wissen, dass Verkehr verworfen und nicht lediglich blockiert wird, können Sie das Problem genauer einkreisen. Prüfen Sie folgende Punkte:

� Es muss eine aktive Zulassen-Regel für das aktive Profil geben.

� Stellen Sie sicher, dass keine Blocken-Regeln die Zulassen-Regel überschreiben.

� Prüfen Sie, ob Gruppenrichtlinien verhindern, dass lokale Regeln angewendet werden.

� Prüfen Sie, ob die aktive Zulassen-Regel nur sichere Verbindungen erlaubt. Ist dies der Fall (und sofern das in Ihrer Umgebung vorgesehen ist), sollten Sie prüfen, ob entsprechende Sicherheitsregeln definiert sind.

� Stellen Sie sicher, dass die ausgehende Verbindung nicht explizit blockiert wird und Verbindungen erlaubt sind, sofern sie nicht explizit blockiert werden.

� Prüfen Sie, ob Konflikte zwischen Firewall und IPsec-Sicherheitsrichtlinien (Internet Protocol Security) bestehen.

Weiterführende Informationen Ausführliche Informationen über die Problembehandlung für die Windows-Fire-wall mit erweiterter Sicherheit und eine Erklärung der Firewallprotokolldateien finden Sie im Artikel »Windows Fire-wall with Advanced Security: Diagnostics and Troubleshooting« unter der Adresse http://go.microsoft.com/fwlink/?LinkId=64382.

Prüfen Sie, ob alle benötigten Dienste laufen: Basisfiltermodul, Gruppenrichtlinienclient, IKE- und AuthIP IPsec-Schlüsselerstellungsmodule, IP-Hilfsdienst, IPsec-Richtlinien-Agent, NLA (Network Location Awareness), Netzwerklistendienst und Windows-Firewall. Sie können die Firewall kurzzeitig deaktivieren oder Ihre Firewalleinstellungen speichern (exportieren) und die Standardeinstellungen wiederherstellen. Falls das Problem verschwindet, haben Sie eine genauere Vorstellung, wo die Ursache des Problems liegt. Aktivieren Sie die Firewall wieder oder stellen Sie die exportierten Einstellungen wieder her, sobald Sie die Problembehandlung abgeschlossen haben.

Probleme mit übergeordneten PfadenDamit ein Client nicht in das Dateisystem des Servers eindringen kann, verbietet IIS 7.0 in ASP-Skripts standardmäßig die Verwendung der Notation »..\«, die für den übergeordneten Pfad steht. Damit ASP-Skripts diese Notation nutzen können, müssen Sie in der Strukturansicht des Internetinformations-dienste-Managers die Website oder Anwendung auswählen und doppelt auf ASP klicken. Ändern Sie im Abschnitt Verhalten der angezeigten Liste die Einstellung Übergeordnete Pfade aktivieren auf den Wert True. Auch mit Appcmd können Sie diese Einstellung konfigurieren, indem Sie in der Eingabe-aufforderung den folgenden Befehl eingeben:%systemroot%\system32\inetsrv\appcmd set config section:asp -enableParentPaths:true

Problembehandlung für bestimmte StatuscodesAnhang A, »HTTP-Fehlercodes in IIS 7.0«, enthält eine Liste der Status- und Unterstatuscodes. Diese Informationen sind nützlich, wenn Sie den Statuscode wissen und mehr Details zu den Status-/Unter-statuscodes brauchen.



Wichtig Unter http://support.microsoft.com/kb/943891 finden Sie eine Erklärung der Fehlercodekategorien. Der Artikel führt häufig vorkommende Fehlercodes auf, beschreibt mögliche Ursachen und verweist auf detaillierte Anleitungen, wie Sie die Fehler beseitigen können.

Beseitigen häufig auftauchender ProblemeDie Probleme, die am häufigsten in einer IIS 7.0-Installation auftauchen, lassen sich oft ganz einfach beseitigen. Zumindest gibt es oft einfache Verfahren, um die Probleme zu identifizieren und zu lösen. Die restlichen Abschnitte dieses Kapitels beschreiben einige häufig auftretende Probleme und enthalten Leitfäden, wie sie sich beseitigen lassen.

IIS 6.0-Verwaltungsprogramme sind nicht installiertDamit Sie die IIS 6.0-Verwaltungsprogramme verwenden können (falls Sie zum Beispiel Ihren IIS 7.0-Server mit vorhandenen IIS 6.0-ADSI- oder WMI-Skripts verwalten oder IIS 6.0-Server von Ihrem IIS 7.0-Server aus administrieren), müssen Sie die entsprechenden Rollendienste unter IIS 6-Verwaltungs-kompatibilität aus der Kategorie Verwaltungsprogramme installieren. Kapitel 5 enthält weitere Infor-mationen über die Installation von IIS 7.0-Modulen. Beachten Sie, dass IIS 7.0 einen neuen WMI-Anbieter enthält, der nicht abwärtskompatibel zum alten WMI-Anbieter ist (sie verwenden unter-schiedliche Namespaces).

SSl ist nicht aktiviertSSI-Direktiven (Server-Side Include) bewirken, dass IIS den angegebenen Inhalt in die Anforderungs-antwort einfügt. Eine Datei, die eine SSI-Direktive enthält, sollte eine bekannte SSI-Dateinamen-erweiterung haben. In der Standardeinstellung sind das .asp (für #include-Direktiven), .stm, .shtm und .shtml. Die Datei sollte in einem Verzeichnis liegen, das Skript- oder Ausführen-Zugriffsberechti-gungen hat. Stellen Sie schließlich sicher, dass Ihre IIS-Installation den Rollendienst Serverseitige Includes (in der Kategorie Anwendungsentwicklung) enthält.

Unerwartete WiederverwendungWenn ein Anwendungspool wiederverwendet wird, gehen mit dem Arbeitsprozess alle Daten zum Sitzungszustand verloren, die in diesem Arbeitsprozess gespeichert waren. Falls Ihre Anwendung voraussetzt, dass ihr Sitzungszustand gespeichert wird, müssen Sie die Anwendung so anpassen, dass sie die Zustandsinformationen außerhalb des Arbeitsprozesses speichert (verwenden Sie bei ASP.NET-Anwendungen den Out-of-Process-Sitzungszustand), damit die Leistung der Anwendung nicht durch die Anwendungswiederverwendung beeinträchtigt wird.

Weiterführende Informationen Weitere Informationen über den Sitzungszustand und die Wiederverwendung des Anwendungspools finden Sie auf der Site http://blogs.msdn.com/david.wang/archive/2005/09/19/Why_do_I_ lose_ASP_Session_State_on_IIS6.aspx.


Zusammenfassung 575

AbstürzeFalls eine Anwendung in Ihrer Website abstürzt, können Sie ein Speicherabbild erstellen. Wenn Sie den Arbeitsprozess debuggen wollen (wahrscheinlich finden Sie eine unbehandelte Ausnahme oder eine Speicherzugriffsverletzung), müssen Sie einen Debugger mit dem Arbeitsprozess der Anwendung verknüpfen.

Weiterführende Informationen Weitere Informationen finden Sie im Artikel »Troubleshooting IIS7 503 ‘Service Unavailable’ Errors with Startup Debugging« unter http://mvolo.com/blogs/serverside/archive/2007/05/19/Troubles-hooting-IIS7-503-_2200_Service-unavailable_2200_-errors-withstartup-debugging.aspx.

Website nicht erreichbarWenn ein Client eine Website nicht erreichen kann, sollten Sie erst einmal mit Ping und dem Tool PortCheck prüfen, ob der Client eine Verbindung zum Server aufbauen kann. Prüfen Sie dann mit dem Befehl net start, ob IIS läuft. Stellen Sie zuletzt mit Appcmd und unter Umständen dem Befehl Netstat sicher, dass die Site läuft und Anforderungen entgegennimmt.

AuthentifizierungsfehlerWenn eine Anforderung wegen fehlgeschlagener Authentifizierung abgewiesen wird, sollten Sie die FRT einschalten. Zeigen Sie in der FRT-Protokolldatei die Registerkarte Request Details an und wählen Sie die Ansicht Authentication Authorization, damit alle Ablaufverfolgungsereignisse aufgelistet werden, die mit der Authentifizierung zu tun haben. Senden Sie anschließend mit WFetch eine Anforderung und suchen Sie in den Headern, die bei der Transaktion ausgetauscht wurden, nach möglichen Problemen mit den Anmeldeinformationen des Benutzers. Prüfen Sie schließlich die Authentifizierungs-/Autorisierungseinstellungen für die betroffene Website.

Langsame Reaktion oder hängender ServerWenn eine Anwendung verzögert antwortet oder der Server zu hängen scheint, sollten Sie erst einmal die FRT einschalten. Zeigen Sie in der FRT-Protokolldatei die Registerkarte Request Details an und wählen Sie die Ansicht Performance View, damit die Ablaufverfolgungsereignisse nach ihrer Dauer sortiert werden. Auf diese Weise finden Sie heraus, ob ein bestimmtes Modul den größten Teil der Verarbeitungszeit bean-sprucht. Sehen Sie sich anschließend im Internetinformationsdienste-Manager die momentan ausge-führten Arbeitsprozesse und Anforderungen an, um festzustellen, ob die langsame Reaktion durch eine ganz andere Anforderung verursacht wird. Untersuchen Sie schließlich in der Zuverlässigkeits- und Leistungsüberwachung die generelle Leistung des Servers. Falls der Server hängen zu bleiben scheint, können Sie auch ein Benutzerspeicherabbild anfertigen, sobald sich die Symptome zeigen.

ZusammenfassungWenn in Ihrer IIS 7.0-Umgebung Probleme auftreten oder Sie vermuten, dass ein Problem besteht, können Sie mithilfe der Tools, die in IIS 7.0 enthalten sind, die Symptome aufzeichnen und diagnostizieren. Die FRT ist Ihre erste Anlaufstelle, um ein Problem zu analysieren und die Ursache aufzuspüren. Allerdings brauchen Sie ein Bündel von Tools, um Fehler zu beseitigen, die ganz unterschiedliche Ursachen haben: beendete Dienste, Netzwerkprobleme, falsche Serverkonfiguration, Authentifizierungs- und Autorisie-rungsfehler, Probleme mit Firewalleinstellungen, fehlerhafter Anwendungscode oder sogar Fehler in benutzerdefinierten Modulen.



Indem Sie mit wenigen simplen Schritten das Problem diagnostizieren, können Sie die Probleme, die am häufigsten in einer IIS 7.0-Umgebung auftauchen, schnell beseitigen. Debuggen wird oft als Kunst bezeichnet. Je vertrauter Sie mit den Werkzeugen werden, die Ihnen zur Verfügung stehen, desto effizienter und eleganter werden Ihre Lösungen.

Weitere InformationenDie folgenden Quellen liefern weitere Informationen und Tools zu den Themen dieses Kapitels:

� IIS 7.0-Integritätsmodell: http://technet2.microsoft.com/windowsserver2008/en/library/b19873a2-9f72-40c8-b73d-89f39cda62781033.mspx?mfr=true

� Liste häufiger Fehlercodes und Erklärungen möglicher Ursachen mit Verweisen auf detaillierte Anleitungen, wie sich die Probleme beseitigen lassen: http://support.microsoft.com/kb/943891

� Die neuesten Debugtools: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

� Das Tool PortCheck: http://mvolo.com/blogs/serverside/pages/Check-network-service-connec-tivity-with-PortChecker-tool.aspx

� Debugtools und -symbole (Links zu Trainings- und Supportinformationen): http://www.microsoft.com/whdc/devtools/debugging/resources.mspx

� Wfetch 1.4 (auch im IIS 6 Diagnostics Toolkit enthalten): http://www.iis.net/go/1307

� Details über das Arbeiten mit Wfetch: http://support.microsoft.com/kb/284285

� Microsoft Windows Sysinternals (Informationen über Process Monitor): http://www.microsoft.com/technet/sysinternals/default.mspx

� Process Monitor (Details und Download): http://www.microsoft.com/technet/sysinternals/SystemInformation/processmonitor.mspx

� Performance Monitor Wizard (vereinfacht das Erstellen und Verwalten von Leistungsüber-wachungsprotokollen): Suchen Sie auf http://www.microsoft.com nach »Performance Monitor Wizard«.

� Microsoft Network Monitor 3.1, ein Netzwerkprotokoll-Analyzer (ermöglicht das Aufzeichnen und Analysieren von Netzwerkverkehr): Suchen Sie auf http://www.microsoft.com/downloads nach »Microsoft Network Monitor 3.1«.

� Informationen zum Verknüpfen eines Debuggers mit einem IIS 7.0-Arbeitsprozess oder einer Web-anwendung in Visual Studio: Suchen Sie auf http://www.iis.net nach »Debugging IIS 7 with Visual Studio 2005 on Windows Vista« und klicken Sie auf den Artikel mit diesem Titel.

� Tipps für Entwickler, die in IIS 7.0 mit klassischem ASP arbeiten: http://blogs.iis.net/bills/archive/2007/05/21/tips-for-classic-asp-developers-on-iis7.aspx.


577

K A P I T E L 1 7

Optimieren der Leistung

Inhalt dieses Kapitels:� Einen Kompromiss zwischen Sicherheit und Leistung finden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

� 64-Bit-Modus und 32-Bit-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600

� Optimieren der Konfiguration unter Leistungsaspekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601

� Systemüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615

� Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617




Dieses Kapitel beschäftigt sich mit Leistung und Optimierung Ihrer Microsoft Windows Server 2008-Webserver. Windows Server 2008 und Internetinformationsdienste (Internet Information Services, IIS) 7.0 stellen viele Möglichkeiten zur Verfügung, damit Sie Ihr System optimieren und einen sinnvollen Kompromiss zwischen bestmöglicher Leistung und den Anforderungen Ihrer Anwendungen finden können. Sie müssten in der Lage sein, mithilfe der neuen Features in IIS 7.0 ein System zu entwerfen, das die aufgewendeten Investitionen optimal durch die Erfüllung Ihrer Geschäftsanforderungen amortisiert.

Das Optimieren der Leistung eines Servers ist sowohl eine Kunst als auch eine Wissenschaft. Ein Beispiel ist die Balance zwischen Anwendungspoolisolierung und Leistung. Gerade in bestimmten Hostingszenarien kann es ein großes Problem sein, Anwendungspools zu isolieren. Der Einsatz von Anwendungspools, um Websites zu isolieren, kann den Server zwar sicherer machen, es werden dann aber auch mehr Serverressourcen verbraucht (auf jeden Fall mehr Arbeitsspeicher). Auch URL-Filte-rung kann die Leistung beeinträchtigen. Jede Option, die Sie implementieren, kann sich sowohl auf die Leistung als auch die Sicherheit auswirken.

Einen Kompromiss zwischen Sicherheit und Leistung findenWie Sie aus dem Physikunterricht wissen, gibt es zu jeder Aktion eine gleich große Reaktion in der ent-gegengesetzten Richtung. Dieses Prinzip gilt auch für den Kompromiss zwischen Leistung und Sicherheit. Viele Faktoren wirken sich auf die Leistung Ihres Servers aus. Einer der wichtigsten Faktoren für die Leistung Ihres Servers ist die Ausnutzung des Arbeitsspeichers (Random Access Memory, RAM). Da 64-Bit-Betriebssysteme inzwischen viele GByte RAM verwalten, sollte man denken, dass die Beschrän-kung des verfügbaren Speichers der Vergangenheit angehört. Leider ist es nicht ganz so einfach.


578 Kapitel 17: Optimieren der Leistung

Eines der wichtigsten Features von IIS 7.0 ist die Fähigkeit, nur genau die Module zu laden, die gebraucht werden, um eine bestimmte Anwendung zu unterstützen. Das kann helfen, die Belastung des Servers so gering wie möglich zu halten.

Messen der BelastungWarum sollten Sie die Belastung Ihres Servers messen? Sie können das mit dem Ermitteln der Belastung in einem beliebigen Unternehmen vergleichen: Jedes Unternehmen muss monatlich Miete, Nebenkosten und Löhne zahlen. Diese Fixkosten sind Belastungen. Diese Analogie macht deutlich, dass jeder Server bestimmte Basisressourcen hat, die Belastungen für das System verursachen.

Sicherheit kann Belastungen zu jeder Anwendung und jedem Server hinzufügen. Je nachdem, wie Ihre Anforderungen aussehen, verursacht sie unter Umständen eine Verzögerung und wirkt sich auf die Anwendungsleistung aus. Sicherheit drückt auch die Leistung. Abhängig von Ihrer Architektur müssen Sie zum Beispiel damit rechnen, dass SSL-Verarbeitung (Secure Sockets Layer) die Gesamtleistung sowohl auf Server- als auch Anwendungsebene beeinträchtigt.

Das folgende Beispiel zeigt, wie Sie Referenzwerte (engl. baseline) für Ihren Server und die Arbeits-prozessgröße (w3wp.exe) ermitteln, bevor Sie irgendwelche Anwendungen und Module aktivieren und das System belasten. Das Beispiel verwendet einen Server, der unter Windows Server 2008 Enterprise Edition mit einer IIS 7.0-Standardinstallation läuft:

1. Installieren Sie die IIS-Standardkonfiguration, bei der statischer Inhalt mit anonymem Zugriff aus-geliefert wird.

Hinweis Kapitel 5, »Installieren von IIS 7.0«, enthält weitere Informationen, wie Sie einen IIS 7.0-Server in der Standardkonfiguration einrichten. Diese Konfiguration verwendet einfach die Standardoptionen, die beim Installieren von IIS 7.0 ausgewählt sind.

2. Öffnen Sie den Internet Explorer und geben Sie die Adresse http://localhost ein.

3. Nachdem Sie http://localhost aufgerufen haben, müsste ein w3wp.exe-Prozess im Windows Task-Manager auftauchen. Klicken Sie auf die Registerkarte Prozesse und stellen Sie fest, wie viel Arbeitsspeicher der Prozess belegt (in diesem Beispiel sind es etwa 3,1 MByte).

4. Sie können sich ansehen, welche DLLs (Dynamic-Link Library) in den Arbeitsprozess w3wp.exe geladen sind, indem Sie eine Eingabeaufforderung öffnen und den Befehl tasklist /M /FI "Imagename eq w3wp.exe" eingeben. Die Ausgabe sieht zum Beispiel so aus:Abbildname PID Module ===================== ======== ============================================ w3wp.exe 3572 ntdll.dll, kernel32.dll, ADVAPI32.dll, RPCRT4.dll, msvcrt.dll, USER32.dll, GDI32.dll, ole32.dll, IISUTIL.dll, CRYPT32.dll, MSASN1.dll, USERENV.dll, Secur32.dll, WS2_32.dll, NSI.dll, IMM32.DLL, MSCTF.dll, LPK.DLL,USP10.dll, NTMARTA.DLL, WLDAP32.dll, PSAPI.DLL, SAMLIB.dll, w3wphost.dll, OLEAUT32.dll, nativerd.dll, XmlLite.dll, IISRES.DLL, rsaenh.dll, mscoree.dll, SHLWAPI.dll, comctl32.dll, mscorwks.dll, MSVCR80.dll, CLBCatQ.DLL, mlang.dll, iiscore.dll, W3TP.dll, w3dt.dll, HTTPAPI.dll,slc.dll,


Einen Kompromiss zwischen Sicherheit und Leistung finden 579

faultrep.dll, VERSION.dll, NLAapi.dll, IPHLPAPI.DLL, dhcpcsvc.DLL, DNSAPI.dll, WINNSI.DLL, dhcpcsvc6.DLL, mswsock.dll, winrnr.dll, napinsp.dll, wshtcpip.dll, wship6.dll, rasadhlp.dll, cachuri.dll, cachfile.dll, cachtokn.dll,cachhttp.dll, compstat.dll, defdoc.dll, dirlist.dll, protsup.dll, static.dll, authanon.dll, modrqflt.dll, custerr.dll, loghttp.dll, iisreqs.dll, WSOCK32.dll, authbas.dll, authsspi.dll, NETAPI32.dll

Hinweis Diese Liste der DLLs scheint zwar viele Einträge zu enthalten, aber die meisten DLLs werden vom IIS-Kernmodul benötigt. Einige Module, zum Beispiel für Standarddokumente (defdoc.dll), sind optional und können entfernt werden. Dieses Beispiel verwendet die Standardinstallation von IIS. Bei Bedarf können Sie nicht benötigte Rollendienste entfernen, wodurch sich die Zahl der geladenen DLLs verringert. Ob Sie die Zahl der optionalen Rollendienste tatsächlich verringern können, können Sie nur feststellen, indem Sie einen Server in einer isolierten Umgebung einrichten und Ihre Konfiguration testen.

Hier ein Beispiel auf einem Server, der unter Windows Server 2008 Server Core läuft. Der Prozess w3wp.exe belegt hier etwa 2,5 MByte:Abbildname PID Module ===================== ======== ============================================ w3wp.exe 804 ntdll.dll, kernel32.dll, ADVAPI32.dll, RPCRT4.dll, msvcrt.dll, USER32.dll, GDI32.dll, ole32.dll, IISUTIL.dll, CRYPT32.dll, MSASN1.dll, USERENV.dll, Secur32.dll, WS2_32.dll, NSI.dll, IMM32.DLL, MSCTF.dll, LPK.DLL,USP10.dll, NTMARTA.DLL, WLDAP32.dll, PSAPI.DLL, SAMLIB.dll, w3wphost.dll, OLEAUT32.dll, nativerd.dll, XmlLite.dll, IISRES.DLL, rsaenh.dll, CLBCatQ.DLL, mlang.dll, comctl32.dll, SHLWAPI.dll, iiscore.dll, W3TP.dll, w3dt.dll, HTTPAPI.dll,slc.dll, faultrep.dll, VERSION.dll, mswsock.dll, DNSAPI.dll, NLAapi.dll, IPHLPAPI.DLL, dhcpcsvc.DLL, WINNSI.DLL, dhcpcsvc6.DLL, wshtcpip.dll, wship6.dll, cachuri.dll, cachfile.dll, cachtokn.dll,cachhttp.dll, compstat.dll, defdoc.dll, dirlist.dll, protsup.dll, static.dll, authanon.dll, modrqflt.dll, custerr.dll, loghttp.dll, iisreqs.dll, WSOCK32.dll, gzip.dll

Bei dieser Referenzmessung ermitteln Sie, wie groß Ihr w3wp-Prozess ist und welche DLLs geladen werden. Wenn Sie Module hinzufügen, können Sie die Messung wiederholen und prüfen, wie stark sich die Auslastung Ihres Arbeitsspeichers geändert hat.

Tabelle 17.1 listet die neuen WAS_W3WP-Leistungsindikatoren der Zuverlässigkeits- und Leistungs-überwachung (perfmon) in IIS 7.0 auf.



Die neuen W3SVC_W3WP-Leistungsindikatoren der Zuverlässigkeits- und Leistungsüberwachung (perfmon) in IIS 7.0 sind in Tabelle 17.2 aufgeführt.

Tabelle 17.1 WAS_W3WP-Leistungsindikatoren

Name des Leistungsindikators Beschreibung

Gesamtanzahl der Statuspings Zahl der insgesamt vom Prozess empfangenen Statuspings

Gesamtanzahl der Laufzeit-statusabfragen

Zahl der insgesamt vom Prozess empfangenen Laufzeitstatusabfragen

Antwortzeit von Statuspings Wie lange der Arbeitsprozess gebraucht hat, um den letzten Statusping zu beantworten (Wert in 100-Nanosekunden-Intervallen)

Aktive Listenerkanäle Zahl der momentan im Arbeitsprozess aktiven Listenerkanäle

Aktive Protokollhandler Zahl der momentan im Arbeitsprozess aktiven Protokollhandler

Empfangene WAS-Meldungen Zahl der Nachrichten, die der Arbeitsprozess insgesamt vom Webverwaltungsdienst empfangen hat

Gesamtanzahl der an WAS gesendeten Meldungen

Zahl der Nachrichten, die insgesamt an WAS gesendet wurden

Gesamtanzahl übermittelter Anforderungen

Zahl der Anforderungen, die vom Arbeitsprozess insgesamt verarbeitet wurden. Dieser Leis-tungsindikator ist nur nützlich, wenn für den Anwendungspool die anforderungsgesteuerte Wiederverwendung aktiviert ist.

Gesamtanzahl der an WAS gesendeten Meldungen

Zahl der Nachrichten, die der Arbeitsprozess insgesamt an den Webverwaltungsdienst gesendet hat

Tabelle 17.2 W3SVC_W3WP-Leistungsindikatoren in IIS 7.0


Gesamtzahl übermittelter HTTP-Anforderungen

Zahl der HTTP-Anforderungen, die der Arbeitsprozess insgesamt verarbeitet hat

Anforderungen/s Zahl der HTTP-Anforderungen, die der Arbeitsprozess pro Sekunde verarbeitet

Aktive Anforderungen Zahl der Anforderungen, die der Arbeitsprozess momentan verarbeitet

Gesamtanzahl der Threads Zahl der Threads, die im Arbeitsprozess insgesamt zum Verarbeiten von Anforderungen zur Verfügung stehen

Anzahl aktiver Threads Zahl der Threads, die im Arbeitsprozess aktiv Anforderungen verarbeiten

Maximalanzahl von Threads Maximalzahl der Threads, die der Threadpool bei Bedarf anlegen kann

Verwendeter Speicher für Datei-cache

Aktuelle Größe des Benutzermodusdateicaches in Byte

Maximal verwendeter Speicher für Dateicache

Maximale Größe des Benutzermodusdateicaches in Byte

Aktuelle Speicherauslastung des Ausgabecaches

Aktuelle Größe des Ausgabecaches in Byte

Anzahl zwischengespeicherter Dateien

Zahl der Dateien, deren Inhalt momentan im Benutzermoduscache gespeichert ist



Zwischengespeicherte Dateien insgesamt

Zahl der Dateien, deren Inhalt irgendwann (seit dem Start des Dienstes) zum Benutzermodus-cache hinzugefügt wurde

Dateicachetreffer Gesamtzahl der erfolgreich im Benutzermodusdateicache gefundenen Dateien (seit dem Start des Dienstes)

Dateicachefehler Gesamtzahl der erfolglos im Benutzermodusdateicache gesuchten Dateien (seit dem Start des Dienstes)

Dateicacheleerungen Gesamtzahl der Dateien, die aus dem Benutzermoduscache gelöscht wurden (seit dem Start des Dienstes)

Aktive entfernte Einträge Zahl der im Benutzermodus zwischengespeicherten Dateihandles, die geschlossen werden, sobald alle aktuellen Übertragungen abgeschlossen sind

Entfernte Dateien insgesamt Gesamtzahl der Dateihandles, die aus dem Benutzermoduscache gelöscht wurden (seit dem Start des Dienstes)

Aktuell zwischengespeicherte URIs Zahl der momentan im Benutzermoduscache gespeicherten URI-Informationsblöcke

Zwischengespeicherte URIs insgesamt

Gesamtzahl der URI-Informationsblöcke, die zum Benutzermoduscache hinzugefügt wurden (seit dem Start des Dienstes)

URI-Cachetreffer Gesamtzahl der erfolgreichen Suchoperationen im Benutzermodus-URI-Cache (seit dem Start des Dienstes)

URI-Cachefehler Gesamtzahl der erfolglosen Suchoperationen im Benutzermodus-URI-Cache (seit dem Start des Dienstes)

URI-Cacheleerungen Gesamtzahl der Löschungen des URI-Caches (seit dem Start des Dienstes)

Entfernte URIs insgesamt Zahl der URI-Informationsblöcke, die aus dem Benutzermoduscache gelöscht wurden (seit dem Start des Dienstes)

Aktuelle Metadaten im Cache Zahl der Metadateninformationsblöcke, die momentan im Benutzermoduscache gespeichert sind

Gesamte Metadaten im Cache Zahl der Metadateninformationsblöcke, die insgesamt zum Benutzermoduscache hinzugefügt wurden (seit dem Start des Dienstes)

Metadatencache-Treffer Gesamtzahl der erfolgreichen Suchoperationen im Benutzermodus-Metadatencache (seit dem Start des Dienstes)

Metadatencache-Fehler Gesamtzahl der erfolglosen Suchoperationen im Benutzermodus-Metadatencache (seit dem Start des Dienstes)

Metadatencache-Leerungen Gesamtzahl der Löschungen des Benutzermodus-Metadatencaches (seit dem Start des Dienstes)

Entfernte Metadaten insgesamt Zahl der Metadateninformationsblöcke, die insgesamt aus dem Benutzermoduscache gelöscht wurden (seit dem Start des Dienstes)

Aktuelle Objekte im Ausgabecache Zahl der Elemente, die momentan im Ausgabecache gespeichert sind

Ausgabecachetreffer insgesamt Gesamtzahl der erfolgreichen Suchoperationen im Ausgabecache (seit dem Start des Dienstes)

Ausgabecachefehler insgesamt Gesamtzahl der erfolglosen Suchoperationen im Ausgabecache (seit dem Start des Dienstes)

Ausgabecacheleerungen insgesamt Gesamtzahl der Löschungen des Ausgabecaches (seit dem Start des Dienstes)

Tabelle 17.2 W3SVC_W3WP-Leistungsindikatoren in IIS 7.0 (Fortsetzung)




AuthentifizierungDer Internetinformationsdienste-Manager listet sieben unterschiedliche Authentifizierungsmodule auf. Das Modul für Anonyme Authentifizierung wird standardmäßig installiert, die anderen können Sie nach Bedarf einzeln installieren:

� Active Directory-Clientzertifikatzuordnung

� Anonyme Authentifizierung

� ASP.NET-Identitätswechsel

� Standardauthentifizierung

� Digestauthentifizierung

� Formularauthentifizierung

� Windows-Authentifizierung

Um Ihren Server sicher zu machen und optimale Leistung zu gewährleisten, sollten Sie nur die Module installieren, die Sie wirklich brauchen. Weitere Informationen zur Konfiguration finden Sie in Kapitel 5.

Aus dem Ausgabecache entfernte Objekte insgesamt

Zahl der Elemente, die insgesamt aus dem Ausgabecache gelöscht wurden (seit dem Start des Dienstes)

Dateicachetreffer/s Durchschnitt der erfolgreichen Suchoperationen im Dateicache während des letzten Mess-intervalls

Metadatencache-Treffer/s Durchschnitt der erfolgreichen Suchoperationen im Metadatencache während des letzten Messintervalls

Ausgabecachetreffer/s Durchschnitt der erfolgreichen Suchoperationen im Ausgabecache während des letzten Messintervalls

URI-Cachetreffer/s Durchschnitt der erfolgreichen Suchoperationen im URI-Cache während des letzten Mess-intervalls

Dateicachefehler/s Durchschnitt der erfolglosen Suchoperationen im Dateicache während des letzten Mess-intervalls

Metadatencache-Fehler/s Durchschnitt der erfolglosen Suchoperationen im Metadatencache während des letzten Messintervalls

Ausgabecachefehler/s Durchschnitt der erfolglosen Suchoperationen im Ausgabecache während des letzten Mess-intervalls

URI-Cachefehler/s Durchschnitt der erfolglosen Suchoperationen im URI-Cache während des letzten Messintervalls

Tabelle 17.2 W3SVC_W3WP-Leistungsindikatoren in IIS 7.0 (Fortsetzung)




SSLDie SSL-Implementierung wurde in IIS 7.0 geändert. Windows Server 2003 speichert die gesamten SSL-Konfigurationen in der IIS-Metabasis, und die Ver- und Entschlüsselung wird im Benutzermodus durchgeführt. Das verursacht eine Menge Datenaustausch zwischen Kernel- und Benutzermodus. In Windows Server 2008 übernimmt Http.sys die SSL-Ver- und Entschlüsselung im Kernelmodus. Sichere Verbindungen sollten bis zu 20 Prozent mehr Leistung bieten als in IIS 6.0. Die Leistungssteigerung beim Entschlüsseln von Daten ist offensichtlich, weil deutlich seltener zwischen Kernelmodus und Benutzermodus hin- und hergeschaltet werden muss.

Um SSL in den Kernelmodus verlegen zu können, erfordert IIS 7.0, dass SSL-Bindungsinformationen an zwei Stellen gespeichert sind. In %windir%\system32\inetsrv\applicationHost.config sind die Bindungsinformationen für alle Sites gespeichert. Wenn die Site startet, sendet IIS die Bindung an Http.sys, und Http.sys nimmt Anforderungen auf der angegebenen Kombination von IP-Adresse und Port entgegen. Der zweite Teil der SSL-Konfiguration ist in der Http.sys-Konfiguration gespeichert. Die SSL-Bindungskonfiguration, die in Http.sys gespeichert ist, können Sie sich mit Netsh anzeigen lassen.

Hinweis Netsh ist ein Befehlszeilenprogramm, mit dem Sie lokal oder im Remotezugriff die Netzwerkkonfiguration eines momentan laufenden Computers anzeigen oder ändern können. Netsh stellt auch Skriptingfeatures zur Verfügung, sodass Sie eine Gruppe von Befehlen im Batchmodus für einen angegebenen Zielcomputer ausführen können. Netsh kann ein Konfigurationsskript in einer Textdatei speichern, wenn Sie die Operationen archivieren oder damit andere Server konfigurieren wollen. Weitere Informationen über Netsh finden Sie auf http://technet. microsoft.com; suchen Sie dort nach »Netsh overview«.

Hier ein Beispiel für eine Bindung an 192.168.0.10. Dieselbe IP-Adresse wird in den Websitebindungen aufgelistet:netsh http show sslcert SSL-Zertifikatbindungen: ------------------------- IP:Port : 192.168.0.10:443 Zertifikathash : 63ca21f32543806959aed570a081fb3f311f958a Anwendungskennung : {4dc3e181-e14b-4a21-b022-59fc669b0914} Zertifikatspeichername : MY Clientzertifikatsperre überprüfen : Aktiviert Sperre nur mithilfe des zwischengespeicherten Zertifikats prüfen : Deaktiviert Verwendungsprüfung : Aktiviert Sperraktualisierungszeit : 0 URL-Abrufzeitlimit : 0 Steuerelement-ID : (null) Steuerelement-Speichername : (null) DS-Zuordnungsverwendung : Deaktiviert Clientzertifikat aushandeln : Deaktiviert

Wenn ein Client eine SSL-Aushandlung beginnt, sucht Http.sys in seiner SSL-Konfiguration nach der Kombination aus IP und Port, zu der der Client eine Verbindung hergestellt hat. Die SSL-Anforderung ist nur erfolgreich, wenn die SSL-Konfiguration von Http.sys ein Zertifikathash und den Namen des Zertifikatspeichers enthält.



SSL-Beschleuniger gibt es in zwei Formen: externe Geräte und interne Karten. Ein externes Gerät ist nützlich, wenn Sie die Kapazität bei Bedarf erhöhen oder sich Erweiterungsmöglichkeiten offen halten wollen. Wenn Ihre SSL-Anforderungen wachsen, können Sie Geräte hinzufügen, die die zusätzliche Last übernehmen. Eine interne Karte, normalerweise eine PCI-Karte, nimmt dem Webserver Last ab, indem sie Ver- und Entschlüsselung erledigt. Da Computer ständig schneller werden und die CPUs immer mehr Kerne erhalten, werden externe Geräte in Zukunft möglicherweise nicht mehr benötigt.

Welche Lösung Sie für SSL wählen, hängt davon ab, welche Anforderungen Ihre Anwendung stellt. IIS 7.0 bietet gegenüber IIS 6.0 mehr Leistung bei der Verarbeitung von SSL. Erst wenn Sie einen Belastungstest für Ihre Anwendung durchgeführt haben, sollten Sie entscheiden, ob Sie ein externes Gerät brauchen.

Unabhängig davon, welche Möglichkeit Sie wählen, sollten Sie Ihre Anwendung generell in einer genau kontrollierten Umgebung einrichten und einen Belastungstest durchführen. Falls Sie feststellen, dass Ihre Server unter Last alle Operationen schaffen, hilft Ihnen das bei der Einschätzung, wie die Anwendung in Ihrer Produktivumgebung funktioniert. Tests helfen Ihnen, eine sinnvolle Entscheidung bezüglich der SSL-Leistung zu treffen.

Auswirkungen knapper LeistungsressourcenJeder Administrator steht vor dem Problem, dass ein Server nur begrenzte Ressourcen hat. Windows Server 2008 und IIS 7.0 stellen die Zuverlässigkeits- und Leistungsüberwachung zur Verfügung, ein neues und erweitertes Leistungstool. Mit seiner Hilfe können Sie feststellen, wo Probleme aufgrund knapper Ressourcen auftreten.

ProzessorDas erste Ressourcenproblem, das einem Administrator auffällt, ist meist eine hohe CPU-Auslastung (Central Processing Unit). Wenn Benutzer über mangelnde Leistung klagen, starten die meisten Admi-nistratoren erst einmal den Windows Task-Manager und sehen sich die Prozessorauslastung an. Dieses Problem ist normalerweise ein Symptom für etwas anderes, das im Computer oder einer Anwendung vor sich geht. Ein heftiger Ausschlag der CPU-Auslastung kann jederzeit auftreten, schon eine Endlosschleife im Code reicht dafür aus.

Was verursacht hohe CPU-Last?Gäbe es eine simple Antwort auf die Frage, wodurch hohe CPU-Last verursacht wird, wäre die Arbeit des Administrators wesentlich einfacher. Sehen wir uns an, welche Elemente häufig hohe Last verur-sachen:

� Schlecht geschriebene Anwendungen

� Speicherintensive Dienste

� Server, die für die Unterstützung der Anwendungen nicht ausreichend dimensioniert sind

� Zu viele Prozesse auf dem Server

� Server mit zu wenig RAM

Wie Sie sehen, kann eine Vielzahl von Ursachen hohe CPU-Last auslösen.



DrosselungDrosselung (engl. throttling) einer Anwendung oder eines Prozesses ist eine Möglichkeit, Server-ressourcen verfügbar zu halten und zu verhindern, dass der Server Anforderungen nur noch träge bedient. Der Begriff Drosselung (auch als Einschränkung oder Beschränkung bezeichnet) bedeutet, dass die Menge der Serverressourcen, die einem bestimmten Prozess oder einer Ressource zur Verfü-gung stehen, eingeschränkt wird. Zum Beispiel bietet IIS 7.0 mehrere Wege, Ressourcen zu drosseln: von Bandbreiten- bis zu Verbindungszeitüberschreitungen und -limits. Falls Ihr Server mehrere Web-sites hostet, können Sie die Zahl der Verbindungen beschränken, die eine Website annimmt. Auf diese Weise benutzt sie nicht zu viele Verbindungen oder Serverressourcen, außerdem verhindern Sie, dass Auswirkungen auf andere auf dem Server gehostete Websites auftreten. Abbildung 17.1 zeigt die Optionen, die Sie in IIS 7.0 drosseln können. Diesen Einstellungen können Sie für jede Website individuell festlegen.

Abbildung 17.1 Websitespezifische Limits in IIS 7.0

IIS 7.0 stellt mehrere Möglichkeiten zur Verfügung, um Ressourcen mithilfe von Anwendungspool-limits zu drosseln. Sie können Limits für Arbeitsprozess-CPU-Einstellungen, RFP (Rapid Fail Protec-tion), Wiederverwendung und diverse Einstellungen im Abschnitt Prozessmodell der erweiterten Anwendungspooleinstellungen konfigurieren. Über die Anwendungspooleinstellungen erfahren Sie mehr in Kapitel 10, »Verwalten von Anwendungen und Anwendungspools«.

Zwischenspeicherung ist eine der besten Möglichkeiten, die Leistung einer Anwendung zu steigern. Sie können dabei auch einschränken, wie viele Ressourcen des Servers benutzt werden. Wenn Sie ein Limit setzen, wie viel RAM für die Zwischenspeicherung verwendet werden darf, kann sich das auf den Leistungsgewinn Ihrer Anwendung auswirken.

Mithilfe von Anwendungspooloptionen können Sie die CPU-Last senken, sodass Ressourcen für Ihre am stärksten frequentierten Sites zur Verfügung stehen. Das ist ein Beispiel, wie Sie die Ressourcen-nutzung auf Ihrem Server steuern und die Anwendungsleistung maximieren können.



Nützliche CPU-LeistungsindikatorenTabelle 17.3 führt wichtige Leistungsindikatoren auf, mit denen Sie feststellen können, welche Pro-zesse wie viele Serverressourcen belegen. Prüfen Sie diese Leistungsindikatoren, wenn bei Ihrem IIS 7.0-Server hohe CPU-Last auftritt.

Tabelle 17.3 CPU-Leistungsindikatoren, die Sie überwachen sollten

Name des Leistungs-indikators

Beschreibung

Prozessor(_Total) \ Interruptzeit (%)

Gibt an, wie viel Zeit der Prozessor während des Messintervalls damit verbracht hat, Hardwareinterrupts anzunehmen und zu verarbeiten. Dieser Wert ist ein indirekter Indikator für die Aktivitäten der Geräte, die Interrupts generieren, zum Beispiel Systemuhr, Maus, Datenträgertreiber, Datenkommunikationsleitungen, Netzwerkschnittstellenkarten und andere Peripheriegeräte. Diese Geräte unterbrechen normalerweise den Prozessor, wenn sie eine Aufgabe abgeschlossen haben oder etwas benötigen. Während ein Interrupt abgearbeitet wird, wird die normale Threadausführung angehalten. Die meisten Systemuhren unterbrechen den Prozessor alle 10 Millisekunden, sodass ständig Interruptaktivitäten anfallen. Dieser Leistungsindikator gibt an, wie lange der Prozessor während des Messintervalls durchschnittlich mit Interrupts beschäftigt war, angezeigt als Prozentsatz.

Prozessor(_Total) \ Privilegierte Zeit (%)

Gibt an, wie viel Prozent des Messintervalls für Prozessthreads verbraucht wurden, die im privilegierten Modus ausgeführt werden. Wenn ein Windows-Systemdienst aufgerufen wird, wird er oft im privilegierten Modus ausgeführt, um Zugriff auf Systemdaten zu erhalten. Solche Daten sind vor dem Zugriff durch Threads geschützt, die im Benutzermodus ausgeführt werden. Systemaufrufe können explizit oder implizit sein, beispielsweise wenn ein Seitenfehler oder ein Interrupt auftritt. Einige Arbeiten, die im Auftrag einer Anwendung durchgeführt werden, werden eventuell in anderen Teilsystemprozessen aufgeführt, zusätzlich zur privilegierten Zeit des Prozesses.

Prozessor(_Total) \ Prozessorzeit (%)

Gibt an, wie viel Prozent des Messintervalls der Prozessor mit der Ausführung von anderen Threads als dem Leerlaufthread verbringt. Dazu wird gemessen, wie viel Prozent der Zeit mit der Ausführung des Leer-laufthreads verbracht wird, und dieser Wert wird von 100% subtrahiert. (Jeder Prozessor hat einen Leer-laufthread, der die Zyklen bekommt, in denen keine anderen Threads auf ihre Ausführung warten.) Dieser Leistungsindikator ist der wichtigste Wert für die Prozessoraktivität. Er zeigt an, wie lange die CPU während des Messintervalls durchschnittlich belastet war. Beachten Sie, dass nur mit der Auflösung der Systemuhr (10 ms) ermittelt wird, ob der Prozessor sich im Leelauf befindet oder nicht. Bei der hohen Geschwindigkeit moderner Prozessoren kann Prozessorzeit (%) daher einen zu niedrigen Wert für die Prozessorauslastung liefern, da der Prozessor zwischen den Messzeitpunkten möglicherweise eine Menge Zeit mit der Aus-führung von Threads verbringt. Zum Beispiel liefern lastabhängige Timeranwendungen oft ungenaue Ergebnisse, da der Timer ausgelöst wird, unmittelbar nachdem die Messung vorgenommen wurde.

Prozessor(_Total) \ Benutzerzeit (%)

Gibt an, wie viel Prozent der Zeit der Prozessor im Benutzermodus verbringt. Der Benutzermodus ist ein eingeschränkter Verarbeitungsmodus, der für Anwendungen, Umgebungssubsysteme und integrale Sub-systeme gedacht ist. Der privilegierte Modus (Kernel) dagegen ist für Betriebssystemkomponenten vorge-sehen und erlaubt direkten Zugriff auf Hardware und den gesamten Arbeitsspeicher. Das Betriebssystem schaltet Anwendungsthreads in den privilegierten Modus, um auf Betriebssystemdienste zuzugreifen. Dieser Leistungsindikator gibt als Prozentwert an, wie lange der Prozessor durchschnittlich belastet war.



Mithilfe der Leistungsindikatoren der Zuverlässigkeits- und Leistungsüberwachung können Sie einen Referenzwert für Ihren Server ermitteln, sodass Sie wissen, welche Menge an Ressourcen während Zeiten normaler und hoher Last verbraucht werden. Wenn ein Problem auftritt, können Sie diese Refe-renzdaten mit den aktuell vorgenommenen Messungen vergleichen, um die Ursache des Problems zu identifizieren.

Die Leistungsindikatoren der Zuverlässigkeits- und Leistungsüberwachung liefern eine Vielzahl von Daten. Wenn Sie die Leistungsindikatoren sinnvoll nutzen, werden Sie Leistungsprobleme schnell isolieren und beseitigen.

Auswirkung von EinschränkungenWenn Sie die CPU-Ressourcen auf einem Server einschränken, hat das möglicherweise Auswirkungen auf die Leistung Ihrer Anwendung. Das gilt nur, wenn Sie Einschränkungen für Ihre Anwendung fest-legen. In diesem Fall gibt es Auswirkungen auf die Leistung; eine Anwendung macht Ressourcen frei, die eine andere Anwendung nutzen kann.

GegenmaßnahmenWie IIS 7.0 hohe CPU-Last verhindern kann, lässt sich am Beispiel von Webgärten zeigen. Ein Web-garten ist ein Feature für Arbeitsprozesse, das hilft, die Last zwischen mehreren Prozessen zu verteilen (Abbildung 17.2).

Denken Sie aber daran, dass Sie einen Webgarten nicht bei Anwendungen nutzen können, die mit statusbehafteten Sitzungen arbeiten. Was bedeutet das? Wenn Sie eine Anwendung haben, die einen Cache verwendet, werden die Variablen in jedem Anwendungspoolprozess zwischengespeichert und nicht mit anderen Prozessen geteilt. Damit wird erreicht, dass jeder Prozess eine eigene Version des Anwendungszustands hat, dessen Werte unabhängig von denen anderer Arbeitsprozesse sind und nicht mit anderen Prozessen im Webgarten übereinstimmen.

System \ Kontext-wechsel/s

Gibt an, wie oft alle Prozessoren auf dem Computer insgesamt von einem Thread zu einem anderen umge-schaltet haben. Kontextwechsel treten auf, wenn ein laufender Thread freiwillig den Prozessor freigibt, durch einen anstehenden Thread höherer Priorität verdrängt wird oder zwischen Benutzermodus und privilegier-tem Modus (Kernel) umgeschaltet wird, um eine Exekutive oder einen Subsystemdienst zu benutzen. Dies ist die Summe der Werte für Thread\Kontextwechsel/s für alle Threads, die auf allen Prozessoren im Com-puter laufen. Der Wert gibt die Zahl der Kontextwechsel an. Es gibt Kontextumschaltungsindikatoren für System- und Threadobjekte. Dieser Leistungsindikator enthält die Differenz zwischen den Werten aus den beiden letzten Messintervallen, geteilt durch die Länge des Messintervalls.

System \ System- aufrufe/s

Gibt an, wie oft die Betriebssystemdienstroutinen von allen Prozessen, die auf dem Computer laufen, auf-gerufen wurden. Diese Routinen führen alle grundlegenden Zeitsteuerungs- und Synchronisierungsaktivi-täten auf dem Computer durch und bieten Zugriff auf Nicht-Grafik-Geräte, Arbeitsspeicherverwaltung und Namespaceverwaltung. Dieser Leistungsindikator enthält die Differenz zwischen den Werten aus den beiden letzten Messintervallen, geteilt durch die Länge des Messintervalls.

Tabelle 17.3 CPU-Leistungsindikatoren, die Sie überwachen sollten (Fortsetzung)


Beschreibung



Abbildung 17.2 Einstellen der maximal zugelassenen Arbeitsprozesse in IIS 7.0

Sehen wir uns ein Beispiel an, wann Sie einen Webgarten einsetzen sollten: Steve verwaltet bei der Firma Contoso eine Anwendung, die das 2-GByte-Limit für x86-Prozesse erreicht und abstürzt. Die Anwendung verwendet den Sitzungszustand nicht, daher ist es möglich, einen Webgarten zu aktivieren. Wenn Steve die Webgärten aktiviert hat, kann er die Anwendungslast über mehrere Arbeitsprozesse verteilen, sodass die Anwendung nicht mehr abstürzt.

Sehen wir uns ein weiteres Beispiel an, bei dem wieder Steve von Contoso zum Einsatz kommt: Er hat außerdem einen Datenbankprozess, der sehr langsam wird. Von Zeit zu Zeit führt das dazu, dass der Anwendungspool abstürzt. Um die Leistung der Anwendung zu verbessern, fügt Steve Prozesse hinzu, damit die Anwendung mit mehreren Prozessen auf die Ressource zugreift (in diesem Fall eine Datenbank).

ArbeitsspeicherSpeicher – genauer gesagt Speichermangel – ist wahrscheinlich der häufigste Engpass in einem System. Ist nicht genug Speicher vorhanden, bemerken auch Benutzer den Leistungseinbruch. Diesen Punkt sollten Sie als ersten überprüfen, wenn Probleme mit einem Server auftauchen. Seit der Einführung von 64-Bit-Systemen stehen Server zur Verfügung, die gleich mehrere Terabyte RAM unterstützen. Falls Ihre Anwendung tatsächlich so viel RAM benötigt, auf den Benutzer zugreifen müssen, gibt es aber sicherlich Ansatzpunkte, wie Sie die Leistung dieser Anwendung verbessern können. Dennoch können 64-Bit-Systeme Anwendungen, die viel Arbeitsspeicher benötigen, besser skalierbar machen als 32-Bit-Plattformen.



Wodurch wird Speichermangel ausgelöst?Oft sind Webanwendungen, die aufgrund ihrer Architektur oder schlechter Codeimplementierung viel Arbeitsspeicher belegen, für Engpässe verantwortlich. Viele Arbeitsspeicherengpässe finden Sie beim Testen oder während einer Pilotbereitstellung Ihrer Anwendung. Indem Sie den empfohlenen Entwick-lungsverfahren folgen und bereits in frühen Phasen Stresstests ausführen, können Sie Probleme auf-grund von Speichermangel gering halten.

Wenn die Liste der Features und Situationen, die eine Anwendung bewältigen muss, immer länger wird, sollten Sie vor allem darauf verzichten, noch mehr Daten oder Informationen an den Client zu über-geben. In einer verteilten Umgebung können typische Webanwendungen versuchen, 10.000 Datensätze auszuwählen und zwischenzuspeichern. Stellen Sie sich vor, dass Hunderte von Leuten gleichzeitig Ihre Website aufrufen. Falls Ihre Informationen auf dem Server zwischengespeichert wurden, kann die Leis-tung Ihrer Anwendung einbrechen, weil kein Arbeitsspeicher mehr auf dem Server frei ist.

Nützliche Leistungsindikatoren für den ArbeitsspeicherTabelle 17.4 führt wichtige Leistungsindikatoren zum Arbeitsspeicher auf, mit denen Sie feststellen können, welche Prozesse wie viele Serverressourcen belegen. Prüfen Sie diese Leistungsindikatoren, wenn bei Ihrem IIS 7.0-Server der Speicher stark ausgelastet ist.

Tabelle 17.4 Arbeitsspeicher-Leistungsindikatoren, die Sie überwachen sollten

Name des Leistungs- indikators

Beschreibung

Speicher \ Verfügbare MB Die Menge des physischen Arbeitsspeichers (in der Einheit MByte), die unmittelbar für die Verwen-dung durch einen Prozess oder das System zur Verfügung steht. Dies ist die Summe des Speichers, der den Listen der Standby- (Cache), freien und Nullseiten zugewiesen ist.

Speicher \ Cachefehler/s Gibt an, wie viele Fehler auftreten, weil eine im Dateisystemcache gesuchte Seite nicht gefunden wird und aus einer anderen Arbeitsspeicherposition (»weicher Fehler«) oder von Festplatte (»harter Feh-ler«) gelesen werden muss. Der Dateisystemcache ist ein Bereich des physischen Arbeitsspeichers, der die zuletzt benutzten Datenseiten für Anwendungen speichert. Cacheaktivitäten sind zuverlässige Indikatoren für die meisten Anwendungs-E/A-Operationen. Dieser Leistungsindikator gibt die Zahl der Fehler an, ohne zu beachten, wie viele Seiten bei einem solchen Fehler nicht gefunden wurden.

Speicher \ Nullforderungs- fehler/s

Gibt an, wie oft eine Nullseite (eine Seite, die mit Nullen gefüllt ist) gebraucht wurde, um den Fehler zu beheben. In Nullseiten werden die vorher gespeicherten Daten durch Nullen überschrieben und so gelöscht. Sie sind ein Sicherheitsfeature, mit dem Windows verhindert, dass Prozesse Daten lesen, die von anderen Prozessen gespeichert wurden, als sie die Speicherseite vorher benutzt haben. Windows verwaltet eine Liste der Nullseiten, um diesen Vorgang zu beschleunigen. Dieser Leistungsindikator gibt die Zahl der Fehler an, ohne zu beachten, wie viele Seiten bei einem solchen Fehler benötigt wurden. Dieser Leistungsindikator enthält die Differenz zwischen den Werten aus den beiden letzten Messintervallen, geteilt durch die Länge des Messintervalls.

Speicher \ Seiten/s Gibt an, wie viele Seiten auf Festplatte gelesen oder geschrieben werden, um harte Seitenfehler zu beheben. Dieser Leistungsindikator liefert wichtige Hinweise zu Fehlern, die systemweite Verzöge-rungen verursachen. Sein Wert ist die Summe von Speicher\Seiteneingabe/s und Speicher\Geän-derte Seiten/s. Der Wert ist die Zahl der Seiten, daher können Sie ihn direkt mit den Werten für andere Seiten vergleichen, zum Beispiel Speicher\Seitenfehler/s. Er umfasst Seiten, die abgerufen werden, um Fehler im Dateisystemcache zu beheben (normalerweise von Anwendungen angefor-dert) und nicht zwischengespeicherte Speicherbilddateien nachzuladen.



Auswirkung von EinschränkungenWenn in einem Server der RAM knapp ist, benutzt der Computer die Auslagerungsdatei. Das bedeutet, dass der Arbeitsprozess Daten von der Festplatte holen muss, was die Leistung verschlechtert. Das kann eine Kettenreaktion auslösen, weil die Anwendung damit einen weiteren potentiellen Engpass einführt: Datenträger-E/A (Eingabe/Ausgabe). Wenn eine Anwendung gezwungen ist, einen Teil der Daten in die Auslagerungsdatei zu verlegen, vergrößert sich die Latenz und der Server verbraucht mehr Ressourcen.

Speicher \ Wechselfehler/s Gibt an, wie viele Seitenfehler durch die Wiederherstellung von Seiten beseitigt wurden, die gemein-sam mit anderen Prozessen benutzt werden, die auf der Liste geänderter Seiten oder der Standby-liste eingetragen sind oder die zum Zeitpunkt des Seitenfehlers auf die Festplatte geschrieben wurden. Diese Seiten wurden ohne zusätzliche Festplattenoperationen wiederhergestellt. Wechsel-fehler werden als Zahl der Fehler angegeben. Weil bei jeder Operation nur genau eine Seite einen Fehler verursacht, ist dieser Wert gleich der Zahl der Seitenfehler.

Prozess(inetinfo) \ Prozessor- zeit (%)

Gibt an, wie viel Prozent der Zeit alle Prozessthreads auf dem Prozessor Anweisungen ausgeführt haben. Eine Anweisung ist die Basiseinheit für die Ausführung in einem Computer. Ein Thread ist das Objekt, das Anweisungen ausführt. Und ein Prozess ist das Objekt, das erstellt wird, wenn ein Pro-gramm ausgeführt wird. Code, der ausgeführt wird, um Hardwareinterrupts und Trapbedingungen zu bearbeiten, ist ebenfalls in diesem Wert enthalten.

Prozess(w3wp) \ Prozessor- zeit (%)

siehe vorherigen Eintrag

Prozess(w3wp) \ Handle- anzahl

Die Gesamtzahl der Handles, die dieser Prozess momentan geöffnet hat. Dieser Wert ist die Summe der Handles, die jeder Thread im Prozess momentan geöffnet hat.

Prozess(w3wp) \ Prozess-kennung

Die eindeutige ID dieses Prozesses. Prozess-IDs werden wiederverwendet, daher identifizieren sie einen Prozess nur während der Lebensdauer dieses Prozesses.

Prozess(w3wp) \ Private Bytes

Die aktuelle Größe des Arbeitsspeichers (in der Einheit Byte), der diesem Prozess zugewiesen wurde und der nicht von anderen Prozessen gemeinsam benutzt werden kann.

Prozess(w3wp) \ Thread- anzahl

Die Zahl der Threads, die in diesem Prozess momentan aktiv sind. Eine Anweisung ist die Basis-einheit für die Ausführung in einem Prozessor, und ein Thread ist das Objekt, das Anweisungen aus-führt. Jeder laufende Prozess hat mindestens einen Thread.

Prozess(w3wp) \ Virtuelle Bytes (max.)

Die aktuelle Größe des virtuellen Adressraums, den dieser Prozess benutzt (in der Einheit Byte). Die Nutzung des virtuellen Adressraums bedeutet nicht unbedingt, dass entsprechend viele Festplatten- oder Arbeitsspeicherseiten gebraucht werden. Virtueller Speicher ist begrenzt, und der Prozess kann seine Fähigkeit einschränken, Bibliotheken zu laden.

Prozess(w3wp) \ Arbeitsseiten Die aktuelle Größe der Arbeitsseiten dieses Prozesses (in der Einheit Byte). Die Arbeitsseiten sind der Satz der Arbeitsspeicherseiten, die vor kurzem von den Threads im Prozess benutzt wurden. Falls mehr Arbeitsspeicher im Computer frei ist, als ein Schwellenwert definiert, werden Seiten auch dann in den Arbeitsseiten eines Prozesses belassen, wenn sie nicht benutzt werden. Wenn der freie Arbeitsspeicher unter einen Schwellenwert fällt, werden Seiten aus den Arbeitsseiten entfernt. Werden sie wieder gebraucht, werden sie über einen weichen Fehler in die Arbeitsseiten zurück-geladen, bevor sie aus dem Arbeitsspeicher gelöscht werden.

Tabelle 17.4 Arbeitsspeicher-Leistungsindikatoren, die Sie überwachen sollten (Fortsetzung)

Name des Leistungs- indikators

Beschreibung



Bei 32-Bit-Betriebssystemen wird im Allgemeinen empfohlen, die Auslagerungsdatei 1,5 Mal so groß zu machen wie das vorhandene RAM. In einer 64-Bit-Umgebung können Sie es dem Betriebssystem überlassen, die Größe der Auslagerungsdatei automatisch zu bestimmen.

GegenmaßnahmenEine Maßnahme gegen hohe Arbeitsspeicherauslastung besteht darin, sicherzustellen, dass die Auslage-rungsdatei Ihres Webservers richtig konfiguriert ist und auf einem getrennten Satz von Festplatten liegt. Wenn Sie eine Auslagerungsdatei über mehrere physische Festplatten verteilen, steigern Sie die Leistung der Auslage-rungsdatei, weil die Laufwerke nicht die Inhalte oder Protokolldateien Ihrer Site speichern. Dies sind zwar elementare Schritte, sie können die Leistung Ihrer Anwendung aber stark verbessern. Außerdem sparen Sie Ihrem Unternehmen Kosten, weil Sie das Optimum aus Ihren Servern herausholen.

Es ist wichtig zu wissen, wie viele Ressourcen eine typische Transaktion verbraucht. Dieser Wert ist nützlich, wenn Sie berechnen, wo das Limit für Ihre Produktivumgebung liegt und wo Sie Schwellen-werte ansetzen sollten. Falls Ihre Datenbank große Mengen an Detaildaten speichert, können Sie aus-rechnen, wie stark die Daten im Lauf einiger Monate oder Jahre anwachsen und wie sich das auf Ihre Anwendung auswirkt. Anfangs läuft sie möglicherweise noch einwandfrei, aber nachdem die Menge der Daten angewachsen ist, wird Ihre Anwendung langsamer und die Serverleistung sinkt.

FestplattenDa ständig schnellere Festplatten entwickelt werden, sinkt die Wahrscheinlichkeit, dass die Datenträger ein Problem verursachen. RAID (Redundant Array of Inexpensive Disk) und Stripingtechnologien sind genau genommen keine IIS-Leistungstricks, aber sie können die Gesamtleistung Ihres Servers verbes-sern. Die tatsächliche Auswirkung der Festplatten hängt davon ab, wie viel RAM Ihr Computer hat.

Wodurch wird hohe Festplattenauslastung verursacht?Hohe Last wird üblicherweise dadurch verursacht, dass viele Daten auf Festplatte gelesen oder geschrieben werden. Ein Webserver führt viele Lese-, aber wenig Schreiboperationen aus, daher bietet er oft gute Leis-tung. Die Zuverlässigkeits- und Leistungsüberwachung ist ein hervorragendes Werkzeug, um zu analy-sieren, wie viele Lese- und Schreibvorgänge ein Webserver insgesamt generiert. Falls Ihre Anwendung viele Daten schreibt, sollten Sie schnelle Festplatten verwenden und eine RAID-Implementierung einrich-ten. Engpässe im Bereich der Festplatte lassen sich mithilfe des Kernelmoduscaches verringern, weil er die Zahl der direkten Leseoperationen von der Festplatte stark verringert.

Nützliche Leistungsindikatoren für FestplattenTabelle 17.5 führt wichtige Leistungsindikatoren zu Festplatten auf, mit denen Sie feststellen können, welche Prozesse wie viele Serverressourcen belegen. Prüfen Sie diese Leistungsindikatoren, wenn bei Ihrem IIS 7.0-Server die Festplatten stark ausgelastet sind.

Tabelle 17.5 Festplatten-Leistungsindikatoren, die Sie überwachen sollten


Beschreibung

Physikalischer Daten-träger(_Total) \ Zeit (%)

Der Prozentsatz des Messzeitraums, in dem das ausgewählte Festplattenlaufwerk mit Lese- oder Schreibanforderungen beschäftigt war

Physikalischer Daten-träger(_Total) \ Lesezeit (%)

Der Prozentsatz des Messzeitraums, in dem das ausgewählte Festplattenlaufwerk mit Leseanforde-rungen beschäftigt war



Auswirkung von EinschränkungenFalls Ihr IIS 7.0-Server nicht über genug RAM verfügt, hat das Auswirkungen auf Leistung und Durch-satz Ihrer Anwendung. Wenn ein Server Daten auf Festplatte schreiben und lesen muss, wird Ihre Anwen-dung langsamer. Speicherauslagerung auf Festplatte kann eine aufwendige Operation sein, und mithilfe der Datenträger-Leistungsindikatoren können Sie die Leistung Ihres Servers messen.

GegenmaßnahmenEs gibt einige Maßnahmen, um zu verhindern, dass Festplattenlatenz auftritt. Beachten Sie vor allem die folgenden Punkte:

� Wählen Sie das richtige RAID für Ihre Server aus.

� Verwenden Sie einen Hardwarecontroller, wenn Sie RAID nutzen, keine Software-RAID-Lösung. Die Investition lohnt sich.

� Sie können Ihre Auslagerungsdatei über mehrere Datenträger verteilen.

� Multispindle-Geräte bieten mehr Leistung. Mehrere kleine Festplatten sind schneller als ein großes Laufwerk.

� Geschwindigkeit ist sehr wichtig. Schnellere Festplatten verbessern die Leistung, und langfristig amortisieren sich die geringfügig höheren Kosten.

� Überwachen Sie auf jeden Fall die Leistung mithilfe der Leistungsindikatoren, die in diesem Abschnitt beschrieben wurden.

Physikalischer Daten-träger(_Total) \ Schreibzeit (%)

Der Prozentsatz des Messzeitraums, in dem das ausgewählte Festplattenlaufwerk mit Schreib-anforderungen beschäftigt war

Physikalischer Daten-träger(_Total) \ Aktuelle Warteschlangenlänge

Die Zahl der noch beim Datenträger anstehenden Anforderungen zu dem Zeitpunkt, als die Leis-tungsdaten gemessen wurden. Dies umfasst auch Anforderungen, die zum Zeitpunkt der Messung gerade bearbeitet wurden. Dies ist ein Augenblickswert, kein Durchschnitt über einen bestimmten Zeitraum. Multispindle-Festplatten können mehrere Anforderungen gleichzeitig aktiv haben, während andere Anforderungen auf ihre Ausführung warten. Dieser Leistungsindikator kann kurzzeitig eine sehr lange oder kurze Warteschlange aufzeichnen, aber wenn das Festplattenlaufwerk stark ausge-lastet ist, dürfte dieser Wert konsistent hoch sein. Die Wartezeit für Anforderungen ist proportional zur Länge dieser Warteschlange minus der Zahl der Spindles in der Festplatte. Um gute Leistung zu gewährleisten, sollte diese Differenz durchschnittlich kleiner als 2 sein.

Physikalischer Daten- träger \ Lesevorgänge/s

Die Zahl der Leseoperationen auf der Festplatte

Physikalischer Datenträger \ Schreibvorgänge/s

Die Zahl der Schreiboperationen auf der Festplatte

Physikalischer Datenträger \ Mittlere Bytes/Lesevorgang

Gibt an, wie viele Bytes bei Leseoperationen durchschnittlich von der Festplatte übertragen werden

Physikalischer Datenträger \ Mittlere Bytes/Schreibvorgang

Gibt an, wie viele Bytes bei Schreiboperationen durchschnittlich zur Festplatte übertragen werden

Tabelle 17.5 Festplatten-Leistungsindikatoren, die Sie überwachen sollten (Fortsetzung)


Beschreibung



� Verhindern Sie, dass Ihre Datenträger fragmentiert werden.

� Speichern Sie bei einem Webserver Protokolle und Inhalte auf anderen Festplatten als das Betriebs-system. Die Protokollierung kann eine aufwendige Operation sein, daher sollten Sie Protokolle nach Möglichkeit auf eigene Festplatten schreiben. Stattdessen können Sie die Protokolle auch an einen Remoteserver weiterleiten.

Hinweis Eine wichtige Hilfe bei der Protokollierung ist die Option httpLogging. Sie legt fest, wie viele Daten in Ihren IIS-Protokolldateien gespeichert werden. Mit dem Attribut selectiveLogging der Option httpLogging stellen Sie ein, welche Statuscodes in den IIS-Protokollen aufgezeichnet werden. In der Standardeinstellung hat selectiveLogging den Wert LogAll, das bedeutet, dass alle Statuscodes protokolliert werden. Sie können den Wert auf LogSuccessful setzen, dann werden alle HTTP-Statuscodes von 100 bis 399 aufgezeichnet. Bei LogError werden die HTTP-Status-codes von 400 bis 999 protokolliert. Das folgende Beispiel zeigt, wie Sie selectLogging mithilfe von Appcmd ein-stellen. Sie können httpLogging auch auf dontLog setzen, dann werden überhaupt keine Protokolle generiert. Die Protokollierung wird in Kapitel 15, »Protokollierung«, genauer beschrieben.

//Dieses Codebeispiel stellt das Attribut selectiveLogging mit Appcmd ein. //LogAll ist der Standardwert, LogSuccessful und LogError sind weitere Optionen. appcmd set config -section:httpLogging -selectiveLogging:LogSuccessful

//Der folgende Ausschnitt des Schemas steuert // das Attribut system.webServer/httpLogging/selectiveLogging <attribute name="selectiveLogging" type="enum" defaultValue="LogAll"> <enum name="LogAll" value="0" /> <enum name="LogSuccessful" value="1" /> <enum name="LogError" value="2" /> </attribute>

Schalten Sie nicht benötigte Dienste wie den Indexdienst oder andere Suchfunktionen aus, die die Fest-platten stark belasten. Solche Dienste versuchen ständig, den Inhalt zu indizieren, und verbrauchen wertvolle Festplattenleistung.

Um das Optimieren des Festplattensubsystems brauchen Sie sich wahrscheinlich nicht zu kümmern, wenn Sie Ihr System optimieren. Indem Sie Ihren Server mit ausreichend RAM ausstatten, stellen Sie weitgehend sicher, dass Probleme nicht durch die Festplatte verursacht werden.

NetzwerkEine der besten Leistungsoptimierungen in Microsoft Windows Server 2008 ist der vollständige Neuent-wurf des TCP/IP-Stacks (Transmission Control Protocol/Internet Protocol), der als Next-Generation-TCP/IP-Stack bezeichnet wird. Der TCP/IP-Stack wurde mit dem Ziel entworfen, Multi-Gigabit/s-Hochge-schwindigkeitsübertragungen zu ermöglichen, ohne die gesamte CPU-Leistung und andere Ressourcen auf dem Server mit Beschlag zu belegen. Er integriert Sicherheitsprodukte in die Windows-Plattform und macht ihre Verwaltung einfacher. Außerdem wurden bei der Neuentwicklung des TCP/IP-Stacks die Ziele verfolgt, ihn einfacher wartbar zu machen, Fähigkeiten hinzuzufügen und ihn durch Features von Fremd-herstellern erweitern zu lassen (insbesondere Firewalls und Antivirenlösungen).

Wodurch wird hohe Netzwerkbelastung verursacht?Im Idealfall würden Bandbreiteneinschränkungen keine Probleme verursachen. Mit Switches ausge-stattete Netzwerke und Geschwindigkeiten von 1 GBit/s und mehr sind eine Erleichterung, aber die Netzwerkauslastung kann nach wie vor einen Engpass bilden. Ob Ihre Anwendungen erfolgreich sind



oder nicht, entscheidet sich unter Umständen dadurch, wie Sie mit der begrenzten Bandbreite umgehen. Die zunehmende Verfügbarkeit von Hochgeschwindigkeitsnetzwerken und Breitbandverbindungen allein garantiert nicht, dass keine Verzögerungen auftreten.

Stark nachgefragte Inhalte wie Videostreaming oder Audiodateien können das Netzwerk auslasten. Das Internet ist ein großes WAN (Wide Area Network), und eine einzige langsame Verbindung reicht aus, dass es überlastet wird und Paketverluste auftreten. Wenn Pakete verloren gehen, können hohe Latenz und langsame Reaktion bei Anwendungen die Folge sein. In einem LAN (Local Area Network) ist es unwahrscheinlicher, dass hohe Latenz und langsame Reaktion von Anwendungen auftreten. Aber das Netzwerk ist immer nur so stark wie sein schwächstes Glied.

Nützliche NetzwerkleistungsindikatorenTabelle 17.6 führt wichtige Leistungsindikatoren für das Netzwerk auf, mit denen Sie Netzwerkprobleme auf Ihrem IIS 7.0-Server erkennen können.

Auswirkung von EinschränkungenWenn Router langsam oder Switches überlastet sind, hat das Auswirkungen auf die Verfügbarkeit von Diensten und die Funktion des Netzwerks. Indem Sie QoS (Quality of Service) einsetzen und netzwerk-intensive Operationen in weniger frequentierte Zeiten verlegen, können Sie die Auswirkungen auf Ihr Netzwerk verringern.

Wenn Sie Tools zur Verfügung haben, um Ihr Netzwerk zu überwachen, können Sie Trends erkennen und sehen, ob Ihr Netzwerk effizient arbeitet. Der Next-Generation-TCP/IP-Stack unterstützt die IETF-Draft-RFC 4898, »TCP Extended Statistics MIB«, in der erweiterte Leistungsstatistiken für TCP definiert sind. Indem Sie die erweiterten Statistiken (ESTATS) einer Verbindung analysieren, können Sie feststellen, ob die Leistung einer Verbindung durch die sendende Anwendung, die empfangende Anwendung oder das Netzwerk begrenzt wird. ESTATS ist standardmäßig deaktiviert, bei Bedarf können Sie es für jede Verbindung individuell aktivieren. Mit ESTATS können Fremdhersteller leistungsfähige Anwendungen für die Analyse und Diagnose des Netzwerkdurchsatzes entwickeln. Tcpanalyzer.exe, das Sie im Windows Vista SDK finden, ist ein Diagnosetool, das auf ESTATS aufbaut.

Das ECN-Feature (Explicit Congestion Notification) verbessert ebenfalls die Leistung. Wenn ein TCP-Segment verloren geht, nimmt TCP an, dass dieses Segment aufgrund der Überlastung eines Routers verloren ging, und aktiviert eine Überlastungssteuerung, wodurch sich die Übertragungsrate des TCP-Absenders deutlich senkt. Wenn beide TCP-Kommunikationspartner und die Routinginfrastruktur ECN unterstützen, markiert ein überlasteter Router die weitergeleiteten Pakete. Wenn TCP-Kommunika-tionspartner solche markierten Pakete erhalten, verringern sie ihre Übertragungsrate, um die Last zu

Tabelle 17.6 Netzwerkleistungsindikatoren, die Sie überwachen sollten


Netzwerkschnittstelle(Schnittstelle) \ Gesamtanzahl Bytes/s

Gibt an, wie viele Bytes über jede Netzwerkkarte gesendet und empfangen werden, inklu-sive der in den Frames enthaltenen Daten. Netzwerkschnittstelle\Gesamtanzahl Bytes/s ist die Summe aus Netzwerkschnittstelle\Empfangene Bytes/s und Netzwerkschnittstelle\ Bytes gesendet/s.

Netzwerkschnittstelle(Schnittstelle) \ Aktuelle Bandbreite

Eine Schätzung der aktuellen Bandbreite der Netzwerkschnittstelle in der Einheit Bit/s. Bei Schnittstellen, deren Bandbreite sich nicht ändert, oder bei denen keine sinnvolle Schätzung möglich ist, gibt dieser Wert die nominale Bandbreite an.



verringern und Segmentverluste zu verhindern. Indem eine Überlastung erkannt wird, bevor Paket-verluste auftreten, verbessert sich der Gesamtdurchsatz zwischen den TCP-Kommunikationspartnern. ECN ist in der Standardeinstellung nicht aktiviert. Sie können es aktivieren, indem Sie den Befehl netsh interface tcp set global ecncapability=enabled ausführen.

GegenmaßnahmenWie ermitteln Sie, wie hoch Ihre Netzwerkauslastung ist? Klicken Sie mit der rechten Maustaste in die Taskleiste, wählen Sie im Kontextmenü den Befehl Task-Manager und aktivieren Sie die Registerkarte Netzwerk. Wählen Sie die Netzwerkschnittstelle aus, die Sie untersuchen wollen, und prüfen Sie ihre Netzwerkauslastungsstatistiken. Falls Ihre primäre Netzwerkkarte an die 100 Prozent anzeigt, bildet diese Karte wahrscheinlich einen Engpass für die Leistung Ihrer Anwendung. Im Allgemeinen sollten Sie Maßnahmen ergreifen, wenn die Netzwerkauslastung etwa 50 Prozent erreicht. Abbildung 17.3 zeigt, wie der Task-Manager Netzwerkauslastungsstatistiken ausgibt.

Abbildung 17.3 Die Netzwerkauslastung im Windows Task-Manager

Der Next-Generation-TCP/IP-Stack ist eine vollständige Neuentwicklung der TCP/IP-Funktionalität für IPv4 und IPv6, die die Konnektivitäts- und Leistungsanforderungen der modernen heterogenen Netzwerkumgebungen und -technologien erfüllt. Folgende Features sind neu oder wurden verbessert:

� Automatische Optimierung des Empfangsfensters

� Compound TCP

� Verbesserungen für Umgebungen mit hohen Verlustraten

� Erkennung der Nachbarnichterreichbarkeit (Neighbor Unreachability Detection) für IPv4

� Erkennung deaktivierter Gateways

� Black-Hole-Router-Erkennung mit PMTU (Path Maximum Transmission Unit)

� Routingdepots (engl. routing compartments)



� Netzwerkdiagnose-Framework

� Windows-Filterplattform

� ECN (Explicit Congestion Notification)

Mit seinen vielen neuen Features und Verbesserungen sollte Windows Server 2008 dazu beitragen, die Netzwerkauslastung so gering wie möglich zu halten. Weitere Informationen finden Sie im TechNet-Artikel »New Networking Features in Windows Server 2008 and Windows Vista« unter http://technet.microsoft.com/en-us/library/bb726965.aspx.

Leistungsindikatoren für die AnwendungsebeneMicrosoft stellt etliche Leistungsindikatoren für die Anwendungsebene zur Verfügung, die bei der Problembehandlung Ihrer Anwendung nützlich sind. Tabelle 17.7 führt die wichtigsten Leistungs-indikatoren auf, die Ihnen bei der Analyse von ASP.NET- und Webproblemen helfen.

Tabelle 17.7 Anwendungsleistungsindikatoren


.NET CLR-Ausnahmen(w3wp) \ Anzahl der ausgelösten Ausnahmen/s

Die Zahl der pro Sekunde ausgelösten Ausnahmen. Dies sind sowohl .NET-Ausnahmen als auch unverwaltete Ausnahmen, die in .NET-Ausnahmen konvertiert werden (zum Beispiel wird eine Nullzeigerverweisausnahme aus unverwaltetem Code im verwalteten Code als .NET-Ausnahme vom Typ System.NullReferenceException erneut ausgelöst). Dieser Leis-tungsindikator zählt sowohl behandelte als auch unbehandelte Ausnahmen. Ausnahmen soll-ten nur in seltenen Fällen auftreten, nicht im normalen Programmablauf. Dieser Leistungs-indikator soll auf potentielle Leistungsprobleme aufgrund einer hohen Zahl (Hunderter) von ausgelösten Ausnahmen aufmerksam machen. Dieser Leistungsindikator gibt keinen Durch-schnittswert über einen längeren Messzeitraum an; sein Wert ist die Differenz zwischen den Ergebnissen der beiden letzten Messungen, geteilt durch die Länge des Messzeitraums.

.NET CLR-Jit(w3wp) \ JIT-Zeitdauer in Prozent

Gibt an, wie viel Prozent der Zeit seit der letzten JIT-Kompilierungsphase mit der JIT-Kompi-lierung verbracht wurde. Dieser Leistungsindikator wird am Ende jeder JIT-Kompilierungs-phase aktualisiert. In einer JIT-Kompilierungsphase werden eine Methode und ihre Abhängig-keiten kompiliert.

.NET CLR-Jit(w3wp) \ Mit JIT kompilierte IL-Bytes/s

Die Gesamtzahl der IL-Bytes, die seit dem Start der Anwendung mit JIT kompiliert wurden. Dieser Leistungsindikator entspricht genau dem Leistungsindikator Gesamtanzahl der mit JIT kompilierten IL-Bytes.

.NET CLR-Ladevorgang(w3wp) \ Aktuelle Anwendungsdomänen

Die Zahl der Anwendungsdomänen, die momentan in diese Anwendung geladen sind. Anwendungsdomänen (AppDomain) stellen eine sichere und flexible Verarbeitungseinheit zur Verfügung, mit der die CLR Isolierung zwischen Anwendungen sicherstellen kann, die im selben Prozess laufen.

.NET CLR-Ladevorgang(w3wp) \ Aktuelle Assemblys

Die Zahl der Assemblys, die momentan in allen Anwendungsdomänen dieser Anwendung geladen sind. Falls die Assembly domänenneutral von mehreren Anwendungsdomänen geladen wird, erhöht sich dieser Leistungsindikator nur um den Wert 1. Assemblys können domänenneutral geladen werden, wenn ihr Code von allen Anwendungsdomänen benutzt wird. Wenn ihr Code dagegen nur innerhalb der Anwendungsdomäne zur Verfügung stehen soll, kann sie domänenspezifisch geladen werden.



.NET CLR-Sperren und Threads(w3wp) \ Warteschlangen-länge/Sek.

Gibt an, wie oft pro Sekunde Threads auf eine Sperre der Anwendung warten. Dieser Leis-tungsindikator gibt keinen Durchschnittswert über einen längeren Messzeitraum an; sein Wert ist die Differenz zwischen den Ergebnissen der beiden letzten Messungen, geteilt durch die Länge des Messzeitraums.

.NET CLR-Sperren und Threads(w3wp) \ Gesamtanzahl der Konflikte

Gibt an, wie oft Threads in der CLR vergeblich versucht haben, eine verwaltete Sperre zu erhalten. Verwaltete Sperren können auf viele Arten angefordert werden, mit der lock-Anwei-sung in C#, durch Aufruf von System.Monitor.Enter oder mithilfe des benutzerdefinierten Attributs MethodImplOptions.Synchronized.

.NET CLR-Speicher(w3wp) \ GC-Zeitdauer in Prozent

Gibt an, wie viel Prozent der Zeit seit der letzten Garbage Collection (GC) mit dem Durchfüh-ren von Garbage Collections verbracht wurde. Dieser Leistungsindikator gibt normalerweise Auskunft, welche Arbeiten der Garbage Collector für die Anwendung erledigt, um Arbeits-speicher freizugeben und zu komprimieren. Dieser Leistungsindikator wird am Ende jeder Garbage Collection aktualisiert. Sein Wert ist der letzte Messwert, kein Durchschnittswert.

.NET CLR Speicher(w3wp)\ Gesamtanzahl der reservierten Bytes

Die Menge an virtuellem Arbeitsspeicher (in Byte), der momentan für den Garbage Collector reserviert ist. Reservierter Arbeitsspeicher ist der physische Arbeitsspeicher, für den Platz in der Auslagerungsdatei der Festplatte reserviert ist.

.NET CLR-Speicher(w3wp) \ Anzahl der Bytes in den Heaps

Die Summe der vier Indikatoren Heapgröße der Generation 0, Heapgröße der Generation 1, Heapgröße der Generation 2 und Objektheapgröße. Dieser Leistungsindikator gibt an, wie viel Arbeitsspeicher (in der Einheit Byte) momentan den GC-Heaps zugewiesen ist.

.NET CLR-Speicher(w3wp) \ Auflistungsanzahl der Generation 0

Gibt an, wie oft Objekte der Generation 0 (die neuesten, zuletzt zugewiesenen) seit dem Start der Anwendung vom Garbage Collector freigegeben wurden. Eine Garbage Collection der Generation 0 findet statt, wenn der verfügbare Arbeitsspeicher in Generation 0 nicht aus-reicht, um eine Reservierungsanforderung zu bedienen. Dieser Leistungsindikator wird jeweils am Ende einer Garbage Collection der Generation 0 hochgezählt. Garbage Collec-tions höherer Generationen umfassen auch Garbage Collections aller niedrigeren Genera-tionen. Dieser Leistungsindikator wird explizit inkrementiert, wenn eine Garbage Collection einer höheren Generation (Generation 1 oder 2) durchgeführt wird. Der Wert der Instanz _Global_ ist nicht zuverlässig und sollte ignoriert werden. Dieser Leistungsindikator gibt den letzten gemessenen Wert an.

.NET CLR-Speicher(w3wp) \ Auflistungsanzahl der Generation 1

Gibt an, wie oft Objekte der Generation 1 seit dem Start der Anwendung vom Garbage Collector freigegeben wurden. Dieser Leistungsindikator wird jeweils am Ende einer Garbage Collection der Generation 1 hochgezählt. Garbage Collections höherer Generationen umfas-sen auch Garbage Collections aller niedrigeren Generationen. Dieser Leistungsindikator wird explizit inkrementiert, wenn eine Garbage Collection einer höheren Generation (Generation 2) durchgeführt wird. Der Wert der Instanz _Global_ ist nicht zuverlässig und sollte ignoriert werden. Dieser Leistungsindikator gibt den letzten gemessenen Wert an.

.NET CLR-Speicher(w3wp) \ Auflis-tungsanzahl der Generation 2

Gibt an, wie oft Objekte der Generation 2 seit dem Start der Anwendung vom Garbage Collector freigegeben wurden. Dieser Leistungsindikator wird jeweils am Ende einer Garbage Collection der Generation 2 hochgezählt (auch als vollständige Garbage Collection bezeich-net). Der Wert der Instanz _Global_ ist nicht zuverlässig und sollte ignoriert werden. Dieser Leistungsindikator gibt den letzten gemessenen Wert an.

Tabelle 17.7 Anwendungsleistungsindikatoren (Fortsetzung)




.NET CLR-Speicher(w3wp) \ Anzahl der ausgelösten GC

Gibt an, wie oft Garbage Collections durchgeführt wurden, weil GC.Collect explizit aufgerufen wurde. Es wird empfohlen, den Garbage Collector selbst entscheiden zu lassen, wie oft er Collections ausführt.

.NET CLR-Speicher(w3wp) \ Zugeordnete Bytes/Sek.

Gibt an, wie viele Bytes pro Sekunde auf dem GC-Heap zugewiesen wurden. Dieser Leis-tungsindikator wird am Ende jeder Garbage Collection aktualisiert, nicht bei jeder Zuweisung. Dieser Leistungsindikator gibt keinen Durchschnittswert über einen längeren Messzeitraum an; sein Wert ist die Differenz zwischen den Ergebnissen der beiden letzten Messungen, geteilt durch die Länge des Messzeitraums.

.NET CLR-Speicher(w3wp)\ Aufgrund ausstehender Objekt-festlegung beibehaltene Objekte

Die Zahl der vom Garbage Collector freigegebenen Objekte, die eine Garbage Collection über-stehen, weil sie auf ihre Finalisierung warten. Falls diese Objekte Verweise auf andere Objekte enthalten, bleiben auch diese Objekte erhalten, werden aber nicht von diesem Leistungsindika-tor erfasst. Die Leistungsindikatoren Von Gen 0 heraufgestufter Finalization-Speicher und Von Gen 1 heraufgestufter Finalization-Speicher geben an, wie viel Arbeitsspeicher insgesamt nach der Finalisierung beibehalten wurde. Dieser Leistungsindikator ist nicht kumulativ. Er wird am Ende jeder Garbage Collection mit der Zahl der Objekte aktualisiert, die während genau dieser Garbage Collection beibehalten wurden. Dieser Leistungsindikator soll zeigen, welcher Zusatzaufwand für die Anwendung aufgrund der Finalisierung verursacht wird.

.NET CLR-Speicher(w3wp) \ Heapgröße der Generation 0

Gibt an, wie viele Bytes in Generation 0 maximal zugewiesen werden können. Dies ist nicht die Größe des Speichers, der in Generation 0 tatsächlich zugewiesen ist. Es wird eine Garbage Collection der Generation 0 ausgelöst, wenn die Anforderungen seit der letzten Garbage -Collection diese Größe überschreiten. Die Generation-0-Größe wird vom Garbage Collector optimiert und kann sich während der Ausführung einer Anwendung ändern. Am Ende einer Garbage Collection der Generation 0 beträgt die Größe des Generation-0-Heaps 0 Byte; dieser Leistungsindikator gibt die Größe der Zuweisungen (in Byte) an, die die nächste Garbage Collection der Generation 0 auslösen. Dieser Leistungsindikator wird am Ende einer Garbage Collection aktualisiert, nicht bei jeder Zuweisung.


Die aktuelle Zahl der Bytes in Generation 1. Dieser Leistungsindikator gibt nicht die maximale Größe für Generation 1 an. Objekte werden dieser Generation nicht direkt zugeordnet, sondern aus einer vorherigen Garbage Collection der Generation 0 hochgestuft. Dieser Leistungsindika-tor wird am Ende einer Garbage Collection aktualisiert, nicht nach jeder Zuweisung.


Die aktuelle Zahl der Bytes in Generation 2. Objekte werden dieser Generation nicht direkt zugeordnet, sondern aus einer vorherigen Garbage Collection der Generation 1 hochgestuft. Dieser Leistungsindikator wird am Ende einer Garbage Collection aktualisiert, nicht nach jeder Zuweisung.

.NET CLR-Speicher(w3wp) \ Objektheapgröße

Die aktuelle Größe des Heaps für große Objekte (in der Einheit Byte). Objekte, die größer als 20 KByte sind, werden vom Garbage Collector als große Objekte eingestuft und direkt in einem speziellen Heap angelegt. Sie werden nicht durch Generationen hochgestuft. Dieser Leistungsindikator wird am Ende einer Garbage Collection aktualisiert, nicht nach jeder Zuweisung.

.NET CLR-Speicher(w3wp) \ Prozess-ID

Die Prozess-ID der überwachten CLR-Prozessinstanz.





.NET CLR-Sicherheit(w3wp) \ Zeit für die RT-Überprüfungen in Prozent

Gibt an, wie viel Prozent der Zeit seit der letzten Prüfung mit dem Durchführen von Laufzeit-Codezugriffssicherheitprüfungen (Code Access Security, CAS) verbracht wurden. CAS ermög-licht es, Code in verschiedene Ebenen der Vertrauenswürdigkeit einzuordnen. Es erzwingt diese Vertrauenswürdigkeitsebenen abhängig von der Codeidentität. Dieser Leistungsindikator wird am Ende einer Laufzeitsicherheitsprüfung aktualisiert. Er gibt den letzten gemessenen Wert an, nicht den Durchschnittswert.

ASP.NET-Anwendungen(__Total__) \ Cachetrimmungen gesamt

Gesamtzahl der Einträge, die wegen Speicherknappheit zwangsweise aus dem Cache gelöscht wurden

ASP.NET-Anwendungen(__Total__) \ Cacheeinträge gesamt

Gesamtzahl der Einträge im Cache (sowohl intern als auch vom Benutzer hinzugefügt)

ASP.NET-Anwendungen(__Total__) \ Cache-Trefferrate gesamt

Trefferrate aller Cacheaufrufe

ASP.NET-Anwendungen(__Total__) \ Gesamte Cacheturnoverrate

Gibt an, wie oft pro Sekunde Objekte zum Cache hinzugefügt oder daraus gelöscht wurden

ASP.NET-Anwendungen(__Total__) \ Ausgabecacheeinträge

Aktuelle Zahl der Einträge im Ausgabecache

ASP.NET-Anwendungen(__Total__) \ Ausgabecachetreffer

Gesamtzahl der Anforderungen, die aus dem Ausgabecache bedient wurden

ASP.NET-Anwendungen(__Total__) \ Ausgabecache-Trefferrate

Trefferrate der Anforderungen, die aus dem Ausgabecache bedient werden konnten

ASP.NET-Anwendungen(__Total__) \ Turnoverrate für den Ausgabecache

Gibt an, wie oft pro Sekunde Objekte zum Ausgabecache hinzugefügt oder daraus gelöscht wurden

ASP.NET-Anwendungen(__Total__) \ Kompilierungen insgesamt

Zahl der dynamisch kompilierten .asax-, .ascx-, .ashx-, .asmx- oder .aspx-Quelldateien

ASP.NET-Anwendungen(__Total__) \ Fehler gesamt/s

Rate der aufgetretenen Fehler

ASP.NET-Anwendungen(__Total__) \ Pipeline-Instanzenzahl

Zahl der aktiven Pipelineinstanzen

ASP.NET-Anwendungen(__Total__) \ Ausgeführte Anforderungen

Die Zahl der Anforderungen, die momentan ausgeführt werden

ASP.NET-Anwendungen(__Total__) \ Anfragen in Anwendungswarte-schlange

Die Zahl der Anforderungen in der Anforderungswarteschlange der Anwendung

ASP.NET-Anwendungen(__Total__) \ Anforderungen/s

Die Zahl der pro Sekunde ausgeführten Anforderungen

ASP.NET \ Anwendungsneustarts Gibt an, wie oft die Anwendung während der Lebensdauer des Webservers neu gestartet wurde

ASP.NET \ Wartezeit der Anforderung Gibt an, wie viele Millisekunden die neueste Anforderung bereits in der Warteschlange liegt





64-Bit-Modus und 32-Bit-ModusDie 64-Bit-Architektur hat die Ressourcenlimits gegenüber 32-Bit-Systemen deutlich erweitert. Auf den ersten Blick sehen die Limits im Vergleich zu 32-Bit-Systemen (x86) sehr groß aus. Windows Server 2008 steht in zwei 64-Bit-Versionen zur Verfügung. Die x64-Plattform bietet die Fähigkeit, 32-Bit- und 64-Bit-Anwendungen auf demselben Computer auszuführen. Diese Lösung ist die beste Wahl für die meisten Serveranwendungsbereitstellungen, unabhängig von ihrer Größe.

Die andere 64-Bit-Version ist ein Itanium-System. IA64-Systeme eignen sich am besten für sehr große Datenbank- und benutzerdefinierte Anwendungslösungen. Im Rest dieses Abschnitts konzentrieren wir uns auf x64.Einer der Hauptunterschiede zwischen IIS 6.0 und IIS 7.0 ist, dass Sie mit IIS 6.0 eine 32-Bit-Anwen-dung auf einem 64-Bit-Computer ausführen können, dann aber der gesamte IIS 6.0-Server im 32-Bit-Modus läuft. In IIS 7.0 können Sie für jede Anwendung individuell festlegen, welche .NET-Version verwendet wird. Tabelle 17.8 zeigt, welche Anwendungspools Sie auf einem einzigen x64-Computer ausführen können.

ASP.NET \ Aktuelle Anforderungen Die aktuelle Zahl der Anforderungen, inklusive der Anforderungen, die sich in der Warte-schlange befinden, momentan ausgeführt werden oder darauf warten, an den Client ausge-geben zu werden. Wenn der Wert dieses Leistungsindikators den Wert requestQueueLimit aus dem Konfigurationsabschnitt processModel überschreitet, weist ASP.NET weitere Anfor-derungen zurück.

ASP.NET \ Anforderungen in Warteschlange

Die Zahl der Anforderungen, die auf ihre Verarbeitung warten

ASP.NET \ Zurückgewiesene Anforderungen

Die Zahl der Anforderungen, die zurückgewiesen wurden, weil die Anforderungswarte-schlange voll war

Webdienst(_Total) \ Abruf- anforderungen/s

Gibt an, wie oft HTTP-Anforderungen mit der GET-Methode gesendet werden. GET-Anforderungen sind die häufigsten HTTP-Anforderungen.

Webdienst(_Total) \ Bereit- stellungsanforderungen/s

Gibt an, wie oft HTTP-Anforderungen mit der POST-Methode gesendet werden

Webdienst(_Total) \ Verbindungs-versuche/s

Gibt an, wie oft versucht wird, eine Verbindung zum Webdienst herzustellen

Webdienst(_Total) \ Aktuelle Verbindungen

Die aktuelle Zahl der Verbindungen, die mit dem Webdienst bestehen

Webdienst(_Total) \ ISAPI- Erweiterungsanforderungen/s

Gibt an, wie oft der Webdienst Anforderungen nach ISAPI-Erweiterungen empfängt

Webdienst(_Total) \ Betriebszeit des Dienstes

Gibt an, wie lange der Webdienst bereits läuft

Webdienst(_Total) \ Anforderungen aller Methoden insgesamt

Die Zahl aller HTTP-Anforderungen seit dem Start des Dienstes

Cache für Webdienst \ URI-Cache-treffer %

Das Verhältnis von Benutzermodus-URI-Cachetreffern zur Gesamtzahl der Cacheanforde-rungen (seit dem Start des Dienstes)




Optimieren der Konfiguration unter Leistungsaspekten 601

Alle Handler für verschiedene ASP.NET-Versionen und Pipelinemodi werden global vom IIS 7.0-Kernserver registriert. So können Sie eine ASP.NET 2.0-Anwendung auf demselben Computer im 32-Bit- und im 64-Bit-Modus ausführen. Die Vorbedingungen und Einstellungen des Anwendungs-pools legen automatisch fest, welche Handler für diesen Anwendungspool benutzt werden müssen. Die Vorbedingungen gelten auch für ISAPI-Filter (Internet Server Application Programming Interface).

Wenn Sie 32-Bit-Anwendungen auf einem 64-Bit-Computer ausführen, besteht ein weiterer Vorteil darin, dass 32-Bit-Prozesse, die unter Windows-on-Windows 64-Bit (WoW64) laufen, 4 GByte adres-sierbaren virtuellen Arbeitsspeicher erhalten. Es wird kein Kernelspeicher geopfert, um mehr virtuellen Speicher für Benutzermodusprozesse bereitzustellen. Selbst mit 32-Bit-IIS-Arbeitsprozessen läuft der Kernel nativ im 64-Bit-Modus.

Tabelle 17.9 zeigt die Unterschiede zwischen den 32-Bit- und 64-Bit-Versionen von Windows Server 2008 bezüglich der CPU- und Arbeitsspeicherlimits für jede Betriebssystemversion.

IIS 7.0 ist ein wichtiges Argument, warum Sie Ihre Systeme auf eine x64-Bit-Edition von Windows Server 2008 aufrüsten sollten. Indem Sie für jeden Anwendungspool separat festlegen, ob er mit .NET 1.1, .NET 2.0 oder anderen Frameworks läuft, können Sie die Vorteile der 64-Bit-Architektur nutzen, ohne irgendetwas am Code ändern zu müssen.

Optimieren der Konfiguration unter LeistungsaspektenUm die Konfiguration Ihrer Umgebung unter Leistungsaspekten optimieren zu können, müssen Sie Ihre Anwendungen genau kennen und wissen, wie Ihre Benutzer auf diese Anwendungen zugreifen. Wie oft haben Sie schon von Administratoren gehört, dass eine Anwendung im Labor einwandfrei funktioniert hat, aber abgestürzt ist, sobald sie in der Produktivumgebung bereitgestellt wurde? Klingt das vertraut? Hoffentlich nicht! Ausreichende Tests im Vorfeld sollten zwingend sein, bevor Sie Produktivhardware kaufen.

Tabelle 17.8 Mögliche Versionen des Anwendungspools

Anwendungsversion .NET Framework-Version

32-Bit-Anwendungspool ASP.NET 1.1



Tabelle 17.9 CPU-/Speicherlimits für Windows Server 2008

Technologie Web Edition Standard Edition Enterprise Datacenter IA-Systeme

CPUs, x86 4 4 8 32 -

CPUs, x64 4 4 8 64 -

CPUs, IA64 - - - - 64

RAM, 32-Bit 4 GByte 4 GByte 64 GByte 64 GByte -

RAM, 64-Bit 32 GByte 32 GByte 2 TByte 2 TByte -

RAM, IA64 - - - - 2 TByte



Sie sollten einige Szenarien durchspielen, wenn Sie Ihre Server konfigurieren. Zuerst brauchen Sie einige grundlegende Informationen, zum Beispiel folgende:

� Wie viele Benutzer werden wahrscheinlich auf Ihre Anwendung zugreifen?

� Wie viele gleichzeitige Benutzer erwarten Sie maximal?

� Wo befinden sich Ihre Benutzer? Arbeiten Sie in schnellen Netzwerken wie einem LAN oder sind sie über das Internet verbunden?

� Wie lange dauert eine typische Sitzung?

� Benötigt Ihre Anwendung einen Sitzungszustand?

� Greift Ihre Anwendung auf eine Datenbank zu?

� Wie viel RAM belegt eine typische Sitzung?

� Greift Ihre Anwendung oft auf die Festplatten zu?

Diese Fragen sind wichtig, wenn Sie Ihre Umgebung sinnvoll konfigurieren wollen. Ihre Antworten können sich auf die Entscheidung auswirken, ob Sie alles auf einem Server ausführen oder eine Gruppe von Servern einrichten. Eine Servergruppe könnte aus einem Webfarm-Frontend mit einem separaten Datenbankserver bestehen.

Falls Ihre aktuelle Anwendung im Produktivbetrieb arbeitet, können Sie mithilfe der Zuverlässigkeits- und Leistungsüberwachung Referenzmessungen durchführen, die für Belastungstests Ihrer Umgebung nützlich sind. Falls Ihre Anwendung brandneu ist, müssen Sie Nutzungszahlen berechnen und schätzen, wie viel Verkehr Sie erwarten.

Dieser Abschnitt des Kapitels soll keine tiefgehende Behandlung der Anwendungsarchitektur bieten. Trotzdem sollten Sie bedenken, dass Entwicklungsverfahren und -methodologien großen Einfluss darauf haben, wie Sie Ihre Umgebung einrichten und skalieren. Das Ziel besteht letztlich darin, optimierte Anwendungen zu betreiben, die den Kunden maximalen Nutzen bringen. Sorgfältige Planung im Vorfeld bringt große Vorteile, wenn Sie später ins Labor gehen und Ihre Anwendungen testen.

ServerebeneAuf Serverebene können Sie viele Einstellungen konfigurieren, um die Leistung Ihrer Umgebung zu optimieren. Bevor Sie aber irgendwelche Änderungen auf Serverebene vornehmen, sollten Sie die Anwendung, die Sie unterstützen wollen, genau kennen. Nur dann sind Sie in der Lage, eine perfekt funktionierende Umgebung einzurichten. Folgende Punkte sollten Sie durchgehen, damit Ihre Server akzeptable Leistung bieten:

� Verwenden Sie nach Möglichkeit die 64-Bit-Version von Windows Server 2008.

� Konfigurieren Sie Ihre Anwendungspools so, dass sie im 32-Bit-Modus laufen.

� Stellen Sie sicher, dass Ihr Server genug RAM hat.

� Stellen Sie sicher, dass Firmware und BIOS (Basic Input/Output System) Ihres Servers auf dem neuesten Stand sind.

� Falls Sie eine Webfarm betreiben, sollten Sie Ihre Server nach Möglichkeit identisch konfigurieren.

� Konfigurieren Sie Ihr System so, dass es RAID verwendet.

� Installieren Sie nur Software, die wirklich gebraucht wird, zum Beispiel Überwachungsagenten, Antivirensoftware und so weiter.



IISIIS ist schon immer ein Dienst, der sich recht gut selbst optimiert. Es gibt hier und da einige Registrierungs-tricks und Metabasisanpassungen, aber insgesamt hat IIS einen guten Ruf, was die automatische Anpas-sung an eine Vielzahl von Belastungssituationen angeht. IIS 7.0 setzt diese Tugenden fort. Bevor wir behaupten, dass sich IIS 7.0 auf beliebiger Hardware optimal skaliert, sollten Sie aber überlegen, welche Anwendungstypen Sie bereitstellen. Dies kann große Auswirkungen auf die IIS-Leistung haben, die Anwendungstypen haben aber wenig mit IIS 7.0 selbst zu tun. Von der Hardwareausrüstung über die RAM-Größe bis zur Geschwindigkeit der Festplatten haben viele Faktoren Auswirkungen auf die Webserverleistung.

Optimieren der Konfiguration für den BelastungstypWie Sie Ihre Umgebung am besten optimieren, hängt letztlich von Ihren Anforderungen ab. Müssen Sie zum Beispiel viele gleichzeitige Verbindungen von Benutzern unterstützen oder ist es wichtig, große Mengen von Transaktionen auszuführen? Die folgenden Abschnitte beschreiben eine Reihe von Bei-spielen, die demonstrieren, welche Faktoren Sie beim Optimieren Ihrer Umgebung beachten müssen.

LastDie Last ist eine der ersten Leistungsanforderungen, die in den Planungsphasen Ihrer Anwendung definiert werden muss. Falls Ihre Anwendung Lastspitzen hat, müssen Sie das in Ihrem Entwurf berücksichtigen. Eine Anwendung, deren Belastung stark schwankt, ist oft schwieriger zu entwerfen. Wahrscheinlich müssen Sie Lastspitzen einplanen, ganz unabhängig davon, wie groß die absolute Belastung ist.

Sehen wir uns ein Beispiel an: Sie sind Leiter der IT-Abteilung bei Contoso. Sie wissen, dass der Verkehr zur Website contoso.com jedes Jahr am 31. Dezember um das Tausendfache gegenüber dem Durchschnitt steigt. Die Besucher reichen dann nämlich Spesenanträge für das vergangene Jahr ein, damit sie ihre Aufwendungen erstattet bekommen. Bedeutet das nun, dass Sie Ihre Umgebung so skalieren müssen, dass sie die Last am 31. Dezember bewältigt, aber das übrige Jahr eine Menge Kapazität brachliegt? Wahrscheinlich nicht, aber es lässt sich wohl nicht vermeiden, Pläne für den Fall zu entwerfen, dass so viele Besucher gleichzeitig auf die Site zugreifen und zusätzliche Last verur-sachen. Es könnte sinnvoll sein, mithilfe gestaffelter Termine oder anderer Maßnahmen zu verhindern, dass alle Benutzer gleichzeitig auf das System zugreifen. Das Beispiel mag unrealistisch klingen, aber es zeigt, was Sie als Last definieren sollten und welche Faktoren Sie bei Tests in Ihre Überlegungen einbeziehen müssen. Wenn in diesem Beispiel ein Benutzer seinen Spesenantrag eingegeben hat und auf Absenden klickt, erwartet er, dass die Transaktion funktioniert. Auf keinen Fall will er die Daten noch einmal eingeben – und natürlich will er die Erstattung möglichst bald überwiesen bekommen.

Ein anderes Beispiel: Stellen Sie sich vor, Sie müssen Ihre Anwendung so skalieren, dass sie eine große Zahl gleichzeitiger Verbindungen verarbeitet. In einem solchen Fall sollten Sie prüfen, ob Sie eine Webfarm mit mehreren Servern einrichten können. Auf diese Weise ist nicht nur sichergestellt, dass die Last bewältigt wird, sondern die Site auch immer verfügbar ist.

Anforderungen an die VerfügbarkeitNormalerweise legen Sie gemeinsam mit Ihren Geschäftspartnern fest, wie hoch die Verfügbarkeit der Anwendung sein muss. Da das Internet allgegenwärtig ist, müssen Anwendungen 24 Stunden am Tag und 7 Tage die Woche zur Verfügung stehen. Das Durchführen der Routinewartung oder Einspielen von Sicherheitspatches kann zum Problem werden. Eine Empfehlung besteht darin, ein



Standardwartungsfenster einzuplanen. Das ist oft schwierig, weil von überall her auf Internetanwen-dungen zugegriffen wird. Das Standardfenster hilft immerhin, eine gewisse Verlässlichkeit zu etab-lieren, sodass die Benutzer wissen, wann Änderungen durchgeführt werden.

LeistungsanforderungenWenn Sie ein SLA (Service Level Agreement) ausarbeiten, werden die Leistungsanforderungen klarer. Häufig benötigte und unverzichtbare Funktionen müssen identifiziert und getestet werden, um sicher-zustellen, dass sie einwandfrei funktionieren. Häufig benutzte Transaktionen, anspruchsvolle Opera-tionen und unternehmenskritische Operationen müssen auch unter hoher Last abgearbeitet werden und den Benutzern zur Verfügung stehen.

Beim Testen Ihrer Anwendung ist wichtig, dass Sie Daten verwenden, die den realen Daten und Benutzermustern so nah wie möglich kommen. Nur so stellen Sie sicher, dass Ihr System optimal funk-tioniert. Das Erstellen von Referenzdaten für die Anwendung im Praxisbetrieb ist für diese Aufgabe unverzichtbar.

InhaltstypenWelche Art von Inhalt Ihre Anwendung verarbeitet, hat starke Auswirkungen auf die Leistung und den Entwurf Ihrer Webserverumgebung. Sehen Sie sich zuerst an, wie das Verhältnis von statischem Inhalt und dynamischem Inhalt in Ihrer Website aussieht. Der Server sollte so eingerichtet sein, dass er für den Inhaltstyp optimiert ist, der am häufigsten auf dem Server benutzt wird. Ein Server, der vorwiegend statischen Inhalt verarbeitet, kann zum Beispiel den Kernelmoduscache und den Ausgabecache nutzen.

Der Ausgabecache von IIS 7.0 kann auch Inhalte verarbeiten, die teilweise dynamisch sind, zum Beispiel eine ASP.NET-Anwendung, die Daten aus einer Datenbank abruft, deren Inhalt relativ konstant bleibt. Eine empfohlene Technik bei der Verwendung des Ausgabecaches besteht darin, dass Sie Ihren Inhalt lediglich für wenige Sekunden zwischenspeichern; der Leistungsgewinn kann trotzdem beträchtlich sein.

Serverseitige ToolsIIS 7.0 versucht an vielen Stellen, Inhalte zwischenzuspeichern. Alle in diesem Abschnitt vorgestellten Features speichern nicht nur Inhalt in einem Cache, sondern analysieren auch, welcher Inhaltstyp zwischengespeichert wird. Jede dieser Techniken hat ihre Vor- und Nachteile, aber alle können die Gesamtleistung des Servers verbessern.

Http.sys-CacheMicrosoft hat den Kernelmoduscache in IIS 6.0 eingeführt. Dieses Feature macht es in vielen Fällen überflüssig, auf den Benutzermoduscache zuzugreifen. Der Http.sys-Cache verbessert die Server-leistung und verringert die Festplattenbelastung. Der Inhalt muss einige Male angefordert werden, bevor IIS 7.0 eine URL für die Zwischenspeicherung in Betracht zieht. Sie können im serverRuntime-Abschnitt von applicationHost.config die Schwellenwerte frequentHitTimePeriod und frequentHitThreshold konfigurieren. Die Standardeinstellungen für serverRuntime sind in %windir%\system32\inetsrv\config\ Schema\IIS_Schema.xml definiert; sie werden standardmäßig vererbt:<sectionSchema name="system.webServer/serverRuntime"> <attribute name="enabled" type="bool" defaultValue="true" /> <attribute name="appConcurrentRequestLimit" type="uint" defaultValue="5000" /> <attribute name="maxRequestEntityAllowed" type="uint" defaultValue="4294967295" /> <attribute name="uploadReadAheadSize" type="uint" defaultValue="49152" validationType="integerRange" validationParameter="0,2147483647" />



<attribute name="alternateHostName" type="string" /> <attribute name="enableNagling" type="bool" defaultValue="false" /> <attribute name="frequentHitThreshold" type="uint" defaultValue="2" validationType="integerRange" validationParameter="1,2147483647" /> <attribute name="frequentHitTimePeriod" type="timeSpan" defaultValue="00:00:10" /> </sectionSchema>

Eine Anforderung wird zwischengespeichert, falls innerhalb des in frequentHitTimePeriod festgelegten Intervalls mehr als frequentHitThreshold Anforderungen nach einer zwischenspeicherfähigen URL eingehen. Das folgende Beispiel zeigt, welche Vorteile Sie erhalten, wenn Sie statt des Benutzermodus-caches oder gar keiner Zwischenspeicherung den Kernelmoduscache verwenden.

Das Beispiel zeigt, wie Sie WCAT (Web Capacity Analysis Tool) einrichten, den WCAT-Controller und den WCAT-Client ausführen und Richtlinien für den Ausgabecache im Internetinformationsdienste-Manager konfigurieren. Es werden drei Tests mit unterschiedlichen Ausgabecacherichtlinien durch-geführt.

Zuerst müssen Sie WCAT konfigurieren, damit Sie dieses Beispiel in Ihrer Umgebung durcharbeiten können:

1. Laden Sie die IIS6 Resource Kit-Tools herunter (von http://www.iis.net/go/1352), führen Sie eine benutzerdefinierte Installation durch und installieren Sie nur WCAT. Sie brauchen drei Dateien, um WCAT zu konfigurieren:

� Eine Skriptdatei, die WCAT anweist, welche URLs es anfordern soll. Jede URL erhält eine eindeutige ClassID.

� Eine Verteilungsdatei, die WCAT mitteilt, wie die Anforderungen über die in der Skriptdatei angegebenen URLs verteilt werden sollen.

� Eine Konfigurationsdatei, die die Parameter eines bestimmten Durchlaufs festlegt, zum Beispiel die Dauer der Tests, wie viele HTTP-Clients simuliert werden und so weiter.

2. Legen Sie einen Ordner namens C:\LoadTest an, in dem die Konfigurationsdateien gespeichert werden.

3. Erstellen Sie im Ordner C:\LoadTest eine Datei namens Default.aspx. Geben Sie den Text <% = Datetime.Now() %> ein und speichern Sie Default.aspx. Diese Datei wird für die Belastungstests ver-wendet.

4. Erstellen Sie im Ordner C:\LoadTest eine neue Datei namens Skript.cfg und geben Sie darin den folgenden Text ein:NEW TRANSACTION classId = 1 NEW REQUEST HTTP Verb = "GET" URL = "http://localhost/Default.aspx"

5. Erstellen Sie eine Datei namens Distribution.cfg und geben Sie darin den folgenden Text ein:1 100

6. Erstellen Sie eine Datei namens Config.cfg und geben Sie darin den folgenden Text ein:Warmuptime 5s Duration 30s CooldownTime 5s NumClientMachines 1 NumClientThreads 20



Sie haben nun den Ordner LoadTest und die benötigten WCAT-Dateien konfiguriert. Jetzt können Sie den WCAT-Controller aktivieren. Das ist nötig, um die Tests durchzuführen. Öffnen Sie eine Eingabe-aufforderung und geben Sie die folgenden Befehle ein:Cd \LoadTest "%programfiles%\IIS Resources\WCAT Controller\wcctl" -c config.cfg -s script.cfg -d distribution.cfg -a localhost

Sobald Sie den WCAT-Controller aktiviert haben, können Sie den WCAT-Client starten, um Ihre Leistungstests durchzuführen. Sie müssen ein weiteres Eingabeaufforderungsfenster öffnen, um den WCAT-Client zu starten:"%programfiles%\IIS Resources\WCAT Client\wcclient.exe" localhost

Beim ersten Test ist keine Ausgabecacherichtlinie aktiviert. Sie stellen die Ausgabecacherichtlinie im Internetinformationsdienste-Manager ein. Abbildung 17.4 zeigt, wie die Oberfläche aussieht, wenn keine Ausgabecacherichtlinie aktiviert ist.

Wie aus Tabelle 17.10 hervorgeht, werden beim Ausführen eines Tests 575 Anforderungen pro Sekunde verarbeitet. Das ist ein akzeptabler Wert. Sehen wir uns nun an, wie stark die Zwischenspeicherung die Leistung steigert.

Beim zweiten Test wird nur die Richtlinie für den Benutzermoduscache aktiviert. Bei diesem Test wird vorausgesetzt, dass Sie die Dateiüberwachungsoption verwenden, die in Abbildung 17.5 gezeigt ist. In Abbildung 17.5 sehen Sie auch, wie Sie eine Benutzermoduscacherichtlinie aktivieren.

Abbildung 17.4 Es ist keine Ausgabecacherichtlinie aktiviert

Wie Tabelle 17.10 zeigt, werden 656 Anforderungen pro Sekunde verarbeitet, wenn Sie für den Test den Benutzermoduscache aktivieren. Das ist eine Verbesserung von 13 Prozent gegenüber dem Test ohne Cacherichtlinie.



Abbildung 17.5 Richtlinie für den Benutzermoduscache

Deaktivieren Sie für den dritten Test die Richtlinie für den Benutzermoduscache und aktivieren Sie den Kernelmoduscache. Stellen Sie für diesen Test die Dateiüberwachungsoptionen aus Abbildung 17.6 ein. In Abbildung 17.6 sehen Sie auch, wie Sie eine Kernelmoduscacherichtlinie konfigurieren.

Abbildung 17.6 Richtlinie für den Kernelmoduscache



Wenn Sie den Test mit aktiviertem Kernelmoduscache ausführen, ist das Ergebnis 946 Anforderungen pro Sekunde. Das sind 60 Prozent mehr als bei ausgeschaltetem Cache. Tabelle 17.10 zeigt die Ergebnisse der drei Leistungstests. Die Ergebnisse hängen natürlich davon ab, welche Hardware Sie verwenden.

Machen Sie sich damit vertraut, welche Einschränkungen bestehen, wenn Sie den Kernelmoduscache einsetzen. Der Kernelmoduscache unterstützt keine Module und Features, die im Benutzermodus laufen, wenn Ihre Anwendung zum Beispiel Standardauthentifizierung oder Windows-Authentifizierung oder -autorisierung verwendet. Solcher Inhalt wird ausgeliefert, aber nicht zwischengespeichert. Der Kernel-moduscache unterstützt das Attribut varyByHeaders, aber nicht varyByQuerystring. Ob eine Anforderung im Kernelmoduscache zwischengespeichert wird, können Sie mit dem Befehl netsh http show cachestate feststellen.

Hinweis Weitere Informationen zu den Änderungen in Http.sys unter Vista und Windows Server 2008 finden Sie unter http://technet.microsoft.com/en-us/library/bb726965.aspx; suchen Sie innerhalb des angezeigten Artikels nach »Http.sys«.

BenutzermoduscacheEine wichtige Änderung am Benutzermoduscache ist, dass beliebige Inhaltstypen zwischengespeichert werden, nicht nur klassisches ASP oder ASP.NET.

Tabelle 17.10 Ergebnisse für unterschiedliche Ausgabecaches

Anforderungen pro Sekunde Cachetyp

575 Kein Cache aktiviert

656 Nur Benutzermoduscache

946 Nur Kernelmoduscache

Direkt von der Quelle: Änderungen am nativen Ausgabecache in IIS 7.0Der native Ausgabecache ist der neue Benutzermodus-Antwortcache in IIS 7.0. Dieses Modul stellt ähnliche Funktionalität zur Verfügung wie das verwaltete Ausgabecachemodul in ASP.NET. Sie steuern die Funktionalität dieses Moduls, indem Sie den Abschnitt system.webServer/caching in applica-tionHost.config bearbeiten oder auf IHttpCachePolicy zugreifen. Die Schnittstelle IHttpCachePolicy dient dazu, Kernelantwortcache- oder Benutzermodus-Ausgabecacherichtlinien vom Code aus zu lesen oder zu ändern. Sie können im Abschnitt system.webServer/caching folgende Eigenschaften einstellen:

� enabled Diese Eigenschaft legt fest, ob der Ausgabecache für die URL aktiviert ist. Falls der Cache deaktiviert ist, führt das Ausgabecachemodul in den ResolveRequestCache- und UpdateRequestCache-Phasen keine Aktivitäten aus.

Beachten Sie, dass die Antwortzwischenspeicherung nicht unbedingt eingeschaltet wird, nur weil Sie die Eigenschaft enabled auf den Wert true setzen. Module müssen auch noch Benutzer-cacherichtlinien einstellen.



� enableKernelCache Steuert, ob der Kernelcache für diese URL aktiviert ist. Das Ausgabe-cachemodul ruft IHttpResponse::DisableKernelCache auf, falls diese Eigenschaft den Wert false hat. Das Ausgabecachemodul erledigt die Arbeiten für den Kernelcache in der SendResponse-Phase, sofern in der Pipeline nicht DisableKernelCache aufgerufen wird. Beachten Sie, dass der Kernelcache die Antworten nicht unbedingt zwischenspeichert, nur weil Sie die Eigenschaft enableKernelCache auf den Wert true setzen. Die Module müssen auch Kernelcacherichtlinien einstellen.

� maxCacheSize Die Maximalgröße des Ausgabecaches in der Einheit MByte. Der Wert 0 bedeutet, dass die maximale Cachegröße automatisch von IIS 7.0 bestimmt wird. IIS 7.0 verwendet die Hälfte des freien physischen Arbeitsspeichers oder des virtuellen Arbeitsspeichers, je nachdem, welcher Wert kleiner ist.

� maxResponseSize Gibt an, wie groß eine Antwort maximal sein darf (in der Einheit Byte), damit sie im Ausgabecache gespeichert wird. Der Wert 0 bedeutet, dass kein Limit festgelegt wird.

Sie können zwar maxCacheSize und maxResponseSize für eine URL festlegen, aber das Ausgabecachemodul verwendet immer die Werte, die auf der Stammebene eingestellt sind.

In Zukunft werden sich Eigenschaften für jeden Anwendungspool individuell konfigurieren lassen. Falls der Ausgabecache aktiviert ist, können Sie sein Verhalten für unterschiedliche Dateitypen steuern, indem Sie Profile für unterschiedliche Dateierweiterungen hinzufügen. Diese Profile sorgen dafür, dass das Ausgabecachemodul die interne IHttpCachePolicy mit den entsprechenden Werten füllt, sodass die Antworten im Benutzer-/Kernelcache zwischengespeichert werden. In einem Profil können Sie ähnliche Eigenschaften einstellen wie in system.web/caching/outputCacheSettings. Folgende Eigenschaften sind in system.webServer/caching-Profilen zulässig:

� extension Zum Beispiel ".asp, .htm". Das Zeichen * wird als Platzhalter verwendet. Falls das Profil für eine bestimmte Erweiterung nicht gefunden wird, wird das Profil für die Erweiterung * benutzt, sofern es vorhanden ist.

� policy Mögliche Werte sind DontCache, CacheUntilChange, CacheForTimePeriod oder DisableCache (nur im Server). Das Ausgabecachemodul ändert die interne IHttpCachePolicy abhängig vom Wert dieser Eigenschaft.

DontCache bedeutet, dass die interne IHttpCachePolicy nicht gesetzt wird; es wird aber nicht verhindert, dass andere Module sie ändern und den Cache aktivieren. Im Server haben wir die Option DisableCache hinzugefügt. Sie stellt sicher, dass die Antwort nicht zwischengespeichert wird, sogar wenn ein ande-res Modul die Richtlinie setzt und das Ausgabecachemodul damit anweist, die Antwort zwischen-zuspeichern.

� kernelCachePolicy Mögliche Werte sind DontCache, CacheUntilChange, CacheForTimePeriod oder DisableCache (nur im Server). Wie bereits erwähnt, verhindert DontCache nicht, dass andere Module die Kernelcacherichtlinie einstellen. Bei statischen Dateien legt der entsprechende Handler die Kernelcacherichtlinie fest, sodass der Kernelcache für die Antwort aktiviert wird. Im Server bewirkt die Option DisableCache, dass die Antwort nicht im Kernelcache zwischengespeichert wird.

� duration Diese Eigenschaft wird nur benutzt, wenn policy oder kernelCachePolicy den Wert CacheForTimePeriod hat.



� location Konfiguriert den cache-control-Antwortheader für den Clientcache. Der cache-control-Antwortheader wird abhängig vom Wert dieser Eigenschaft eingestellt, folgende Werte sind möglich:Any | Downstream: public ServerAndClient | Client: private None | Server: no-cache

� varyByHeaders Eine kommagetrennte Liste der Anforderungsheader. Wenn mehrere Antworten auf Anforderungen unterschiedliche Werte in diesen Headern haben, werden sie getrennt vonein-ander im Cache gespeichert. Zum Beispiel werden oft unterschiedliche Antworten aufgrund von Unterschieden in Accept-Language-, User-Agent- oder Accept-Encoding-Headern zurückgegeben. Alle solche Antworten werden zwischengespeichert.

� varyByQueryString Kommagetrennte Abfragestringvariablen. Es werden mehrere Ant-worten zwischengespeichert, wenn sich die Werte von Abfragestringvariablen in mehreren Anforderungen voneinander unterscheiden. Im Server können Sie varyByQueryString auf den Wert * setzen, dann speichert das Ausgabecachemodul jeweils eine separate Antwort, wenn sich irgendein Wert in den Abfragestringvariablen unterscheidet.

Nur der Benutzermoduscache arbeitet mit location-Headern und varyBy. Diese Eigenschaften haben keine Auswirkungen auf den Kernelcache. Falls die Richtlinie also DontCache einstellt, werden diese Eigenschaften ignoriert. Nehmen wir an, das Ausgabecachemodul soll mehrere Antworten einer ASP-Seite, die sich abhängig vom Wert der Abfragestringvariablen action und dem User-Agent-Anforderungsheader unterscheiden, 30 Minuten lang zwischenspeichern. In diesem Fall sieht der <caching>-Abschnitt der Datei applicationHost.config folgendermaßen aus:<caching> <profiles enabled="true"> <add extension=".asp" policy="CacheForTimePeriod" duration="00:30:00" varyByQueryString="action" varyByHeaders="User-Agent"/> </profiles> </caching>

Das Ausgabecachemodul füllt die interne IHttpCachePolicy während der BeginRequest-Phase, sofern ein passendes Profil gefunden wird. Andere Module können weiterhin Änderungen an der Cachericht-linie für die aktuelle Anforderung vornehmen, wodurch sich unter Umständen das Verhalten von Benutzermodus- oder Kernelmoduscache ändert. Der Ausgabecache speichert nur 200 Antworten auf GET-Anforderungen. Falls ein Modul bereits die Antwort gelöscht hat, wenn die Anforderung die UpdateRequestCache-Phase erreicht, oder falls Header unterdrückt werden, wird die Antwort nicht vom Ausgabecachemodul zwischengespeichert.

Das Ausgabecachemodul speichert die Antwort nur, falls noch kein anderes Modul sie zwischen-gespeichert hat. Das wird über IHttpCachePolicy::SetIsCached festgelegt. Außerdem wird die Zwischen-speicherung nur für häufig abgerufene Inhalte durchgeführt. Die Definition, wann Inhalt als häufig abgerufen gilt, wird von den Eigenschaften frequentHitThreshold und frequentHitTimePeriod gesteuert, die im Abschnitt system.webServer/serverRuntime von applicationHost.config liegen. Die Standardwerte legen fest, dass Inhalt als häufig abgerufen gilt, wenn er zweimal innerhalb eines beliebigen 10-Sekunden-Intervalls angefordert wird.

Kanwaljeet SinglaIIS Team Microsoft



KomprimierungIIS 7.0 stellt Fähigkeiten für statische und dynamische Komprimierung zur Verfügung. Die meisten Eigenschaften werden unter system.webServer\httpCompression in der Datei applicationHost.config verwaltet.

Direkt von der Quelle: Änderungen an den Komprimierungsmodulen in IIS 7.0Statische Komprimierung ist in IIS 7.0 standardmäßig eingeschaltet. Dynamische Komprimierung ist in der Standardeinstellung weiterhin ausgeschaltet. Sie können sie für den gesamten Inhalt mit dem folgenden Befehl aktivieren:appcmd set config -section:urlCompression /doDynamicCompression:true

In IIS 6.0 wird die statische Komprimierung in einem separaten Thread durchgeführt. Wenn eine Anforderung eintrifft, ist die Antwort also erst einmal unkomprimiert und IIS 6.0 startet einen separaten Thread, um die Datei zu komprimieren. Diese Version wird im Cache für komprimierte Dateien zwischengespeichert. Anforderungen nach komprimierten Inhalten, die IIS 6.0 erhält, nachdem die Komprimierung abgeschlossen ist, werden mit einer komprimierten Antwort bedient.

In IIS 7.0 wird die Komprimierung im Haupt-Thread erledigt. Damit aber keine Leistung dadurch verschwendet wird, alle Anforderungen zu komprimieren, wird die Komprimierung nur für häufig angeforderten Inhalt durchgeführt. Wann Inhalt als häufig angefordert eingestuft wird, ist in den Eigenschaften frequentHitThreshold und frequentHitTimePeriod des Abschnitts system.webServer/serverRuntime definiert. Falls IIS 7.0 innerhalb des Zeitraums frequentlyHitTimePeriod mehr als die in frequentHitThreshold festgelegte Zahl von Anforderungen für dieselbe URL empfängt, komprimiert IIS 7.0 die Datei, sodass eine komprimierte Antwort zurückgegeben werden kann, falls dieselbe Anforderung erneut eintrifft.

Diese komprimierte Antwort wird im Cache für komprimierte Dateien zwischengespeichert, genau wie in IIS 6.0. Falls die komprimierte Antwort bereits im Cache vorhanden war, wird die frequentHitThreshold-Logik nicht angewendet, weil komprimierter Inhalt aus dem Cache abgerufen wird. Somit entsteht kein zusätzlicher Aufwand, um den Inhalt zu komprimieren. Die Trefferzahl wird pro URL gezählt. Wenn also die erste Anforderung mit dem Accept-Encoding-Header gzip und die zweite mit deflate eintrifft, gilt die Anforderung als häufig abgerufener Inhalt und IIS komprimiert die Antwort. Voraussetzung ist, dass cachuri.dll im globalModules-Abschnitt eingetragen ist, weil dieses Modul die URL-Trefferzahl verwaltet.

Der Ordner für komprimierte Dateien hat in IIS 7.0 eine verschachtelte Verzeichnisstruktur, in IIS 6.0 beschränkte er sich auf eine Ebene. IIS 7.0 legt für jeden Anwendungspool einen Ordner für die komprimierten Dateien an, und darunter dann separate Ordner für unterschiedliche Schemas. Unter-halb der Schemaordner erstellt IIS 7.0 wiederum eine Ordnerstruktur, die dem Ordner ähnelt, aus dem der ursprüngliche Inhalt stammt. Falls also iisstart.htm aus D:\inetpub\wwwroot mit gzip komprimiert wurde, wird ein Cacheeintrag im Ordner D:\inetpub\temp\IIS Temporary Compressed Files\DefaultAppPool\$^_gzip_D^\INETPUB\WWWROOT erstellt.

IIS 7.0 weist dem Anwendungspoolordner eine ACL (Access Control List, Zugriffssteuerungsliste) für die Arbeitsprozessidentität zu, um den Inhalt vor Arbeitsprozessen zu schützen, die in anderen Anwendungspools arbeiten. Sie können das Verzeichnis weiterhin in der Konfigurationsdatei fest-legen, aber die Standardeinstellung wurde von %windir%\iis temporary compressed files auf %SystemDrive%\inetpub\temp\iis temporary compressed files geändert.



Eine andere Konsequenz der Änderungen ist, dass der Schellenwert maxDiskSpaceUsage pro Anwen-dungspool angewendet wird. Falls Sie also in IIS 6.0 für HcMaxDiskSpaceUsage den Wert 100 MByte eingestellt haben, wird dieses Limit auf den gesamten komprimierten Inhalt im Cache für kompri-mierte Dateien angewendet. In IIS 7.0 gilt dieses Limit für die komprimierten Dateien eines Anwen-dungspools. Falls Sie 10 Anwendungspools haben und maxDiskSpaceUsage auf 100 MByte einstellen, wird bis zu 1 GByte durch den Cache für komprimierte Dateien belegt.

Weil statische Komprimierung standardmäßig aktiviert ist und die Komprimierung im Haupt-Thread durchgeführt wird, wird die On-the-fly-Komprimierung abhängig von der CPU-Belastung ausge-schaltet oder wieder eingeschaltet. Vier neue Eigenschaften im Abschnitt system.webServer/httpCom-pression steuern dieses Verhalten:

� staticCompressionDisableCpuUsage Die Komprimierung wird deaktiviert, wenn die durchschnittliche CPU-Auslastung über den angegebenen Zeitraum diesen Wert überschreitet.

� staticCompressionEnableCpuUsage Die Komprimierung wird aktiviert, wenn die durch-schnittliche CPU-Auslastung über den angegebenen Zeitraum diesen Wert unterschreitet.

� dynamicCompressionDisableCpuUsage und dynamicCompressionEnableCpuUsage Die dynamische Komprimierung wird abhängig von der CPU-Auslastung aktiviert oder deaktiviert. IIS 7.0 berechnet die durchschnittliche CPU-Auslastung alle 30 Sekunden.

In IIS 7.0 können Sie die Komprimierung abhängig vom Inhaltstyp der Antwort aktivieren und deak-tivieren. In IIS 6.0 ist dies nur über Erweiterungen möglich. In IIS 7.0 können Sie mit einem einzigen Eintrag in der Konfiguration die statische oder dynamische Komprimierung für Text/HTML-Ant-worten aktivieren. Sie brauchen nicht mehr alle Erweiterungen herauszusuchen, die Text/HTML-Antworten zurückgeben. Wenn Sie diese MIME-Typen im Abschnitt httpCompression konfigurieren, können Sie das Zeichen * als Platzhalter eintragen. Falls der Antworttyp Text/HTML ist, sollten Sie nach einem gleichnamigen Eintrag suchen. Ist einer vorhanden, können Sie den zugehörigen enabled-Wert ändern. Falls kein Eintrag namens text/html vorhanden ist, sollten Sie nach text/* oder */html suchen. Falls beide vorhanden sind, können Sie den nehmen, der weiter oben steht, und seinen enabled-Wert anpassen. Falls Sie auch diese beiden Einträge nicht finden, müssen Sie nach */* suchen und den zugehörigen enabled-Wert ändern. Sie können die Komprimierung für alle Inhaltstypen aktivieren, indem Sie den folgenden Eintrag in den httpCompression-Abschnitt von applicationHost.config einfügen:<staticTypes> <add mimeType="*/*" enabled="true" /> </staticTypes>

Der Wert von maxDiskSpaceUsage wird in IIS 7.0 in der Einheit MByte konfiguriert, nicht Byte. Uns war klar, dass die Administratoren das Limit nicht auf das Byte genau konfigurieren wollen, aber in erster Linie haben wir diese Entscheidung getroffen, weil der Limitwert vom Typ UINT ist und wir verhin-dern wollten, dass Benutzer einen Wert eintragen, der nicht in ein UINT passt. Angesichts der Größe moderner Festplatten ist es nicht ungewöhnlich, wenn dieser Wert sehr groß ist.

Da die statische Komprimierung standardmäßig aktiviert ist, legt IIS 7.0 nur komprimierte Antworten im Kernelcache (Http.sys) ab. Falls also die Komprimierung für eine Datei aktiviert ist, aber die aktuelle Anforderung keinen Accept-Encoding-Header enthält (oder die Komprimierung nicht durchgeführt wurde, weil dies die erste Anforderung ist), weist IIS 7.0 Http.sys nicht an, die Datei zwischenzuspeichern. Nur Antworten, bei denen die Komprimierung aktiviert ist, werden im Kernelcache zwischengespeichert. Dynamisch komprimierte Antworten werden in keinem der Caches zwischengespeichert (nicht einmal komprimierte Dateien wie in IIS 6.0).



AnwendungspoolsIIS 7.0 stellt ein neues Verhalten zur Verfügung, das Ihnen erlaubt, für jede Website einen eigenen Anwendungspool zu erstellen. Das ist eine deutliche Änderung gegenüber IIS 6.0, wo Sie einen bereits vorhandenen Anwendungspool benutzen müssen. Diese Änderung kann für Webhoster starke Aus-wirkungen haben, weil sie oft Sites mit gemeinsam genutzten Anwendungspools konfigurieren.

Microsoft empfiehlt, dass Sie jede Site in ihrem eigenen Anwendungspool isolieren. Falls dies nicht ohne weiteres möglich ist, können Sie den Anwendungspool so einstellen, dass er aufgrund einer Reihe von Faktoren wiederverwendet wird.

NetzwerklastenausgleichBeim Netzwerklastenausgleich (Network Load Balancing, NLB) übernehmen zwei oder mehr Server die Ausführung Ihrer Website. Um die Last auf mehrere Computer zu verteilen, brauchen Sie den Lasten-ausgleich. Sie können die eingebaute Netzwerklastenausgleichanwendung aus Windows Server 2008 verwenden oder das Hardwaregerät eines Fremdherstellers einsetzen. Wenn Sie NLB implementieren, kann das die Leistung Ihrer Anwendung und Website stark verbessern. Auf NLB gehen wir im Abschnitt »Systemüberwachung« weiter unten in diesem Kapitel genauer ein.

AnwendungDie Optimierung Ihrer Anwendung unter Leistungsaspekten beginnt in dem Moment, an dem Sie erstmals besprechen, welche Anforderungen an die Anwendung gestellt werden. Bestimmte Architektur- und Entwurfsüberlegungen haben die größte Auswirkung darauf, welche Leistung Ihre Anwendung langfristig bringt. Wie sollten Sie Ihre Datenbank entwerfen? Wie viele Daten speichern Sie? Woher bekommen Sie Ihre Daten? Muss in Echtzeit auf die Daten zugegriffen werden oder können sie zwischengespeichert werden? Wie viele Daten werden zwischengespeichert? Verwendet Ihre Anwendung den Sitzungszustand oder ist sie zustandslos? Wie authentifizieren Sie Ihre Besucher? Welches Sicherheitsmodell verwendet Ihre Anwendung?

Auch welche Art von Daten Sie verarbeiten, hat Auswirkungen auf Ihre Anwendung. Diesen Punkt müssen Sie auch analysieren, wenn Sie Ihre Anwendung später konfigurieren. Faktoren wie die Einschränkung der Speichernutzung und der Datenbankaufrufe wirken sich auf die Leistung aus.

Die Eigenschaft deflate wurde aus der Standardkonfiguration entfernt, die Funktionalität ist aber nach wie vor in gzip.dll vorhanden. Sie können das deflate-Schema wieder aktivieren, indem Sie den folgenden Eintrag in den httpCompression-Abschnitt einfügen.<scheme name="deflate" dll="%Windir%\system32\inetsrv\gzip.dll" />

Auch der folgende Appcmd-Befehl erledigt diese Aufgabe:appcmd set config /section:httpCompression /+[name='deflate',dll='%Windir%\system32\inetsrv\gzip.dll']

Weil die statische Komprimierung standardmäßig aktiviert ist, wurde der Standardwert für staticCom-pressionLevel von 10 in IIS 6.0 auf 7 in IIS 7.0 geändert.

Kanwaljeet SinglaIIS Team Microsoft



Identifizieren und Isolieren von EngpässenIIS 7.0 stellt Ihnen leistungsfähige Möglichkeiten zur Verfügung, um Engpässe in Ihren Webanwen-dungen zu isolieren und identifizieren. Dazu ermöglicht IIS 7.0 eine flexible Instrumentierung durch die gesamte Anforderungspipeline. Der Internetinformationsdienste-Manager verschafft den Administra-toren unmittelbar Zugriff auf Webanforderungsdaten. Diese Daten wurden erstmals in Windows Server 2003 SP1 verfügbar gemacht, aber in IIS 7.0 ist das Verfahren viel benutzerfreundlicher. Nehmen wir etwa an, bei einem Ihrer Anwendungspools tritt ein Problem auf. Mit IIS 7.0 können Sie schnell identifizieren, welche Webseiten während der Laufzeit ausgeführt werden.

Die Ablaufverfolgung für Anforderungsfehler (Failed Request Tracing, FRT) lässt sich für alle Inhalts-typen einsetzen, nicht nur für ASP oder ASP.NET. Mithilfe der verfügbaren Daten können Sie die Leistung Ihrer Anwendung verbessern. Hier ein Beispiel: Ihre Anwendung führt einen LDAP-Aufruf (Lightweight Directory Application Protocol) an einen Verzeichnisdienst wie den Microsoft Active Directory-Verzeichnisdienst durch, um bestimmte Informationen zu einer Gruppenmitgliedschaft abzu-rufen. Dies ist einer der ersten Vorgänge nach dem Start der Anwendung. Dieser Schritt entscheidet, ob die Anwendung erfolgreich ist oder nicht, weil der Benutzer auf das Ergebnis warten muss. Mithilfe der neuen Ablaufverfolgungstools ermöglicht IIS 7.0 es Ihnen, die Abläufe durch die gesamte Anforde-rungspipeline zu verfolgen und festzustellen, wie lange der beschriebene Schritt dauert. Falls er binnen weniger Millisekunden abgeschlossen ist, dürfte er kein Problem darstellen (anders sieht es aus, wenn er mehr als fünf Sekunden braucht).

Vor IIS 7.0 mussten Entwickler und Administratoren im Rahmen einer aufwendigen Problembehand-lung herausfinden, wo der Engpass auftritt. Der Entwickler schiebt die Schuld auf den Administrator und sagt: »Meine Anwendung läuft einwandfrei, sobald sie die Daten zur Gruppenmitgliedschaft hat.« Der Administrator widerspricht: »Mein Active Directory ist redundant ausgelegt, läuft auf schnellen Servern und über ein Hochgeschwindigkeitsnetzwerk. Was tun Sie denn bloß in Ihrer Anwendung?«

Der Administrator hat recht, falls die Anwendung mehrere Male Daten hin- und herschickt. Falls Sie die Anmeldeinformationen des Benutzers schon im Vorfeld zur Verfügung haben, sollten Sie sich auf einen Aufruf in den Verzeichnisdienst beschränken, um die Informationen zur Gruppenmitgliedschaft abzurufen. Das kann die Latenz verringern und die Benutzerzufriedenheit steigern. Dieses Beispiel zeigt, wie sich die Anwendungsleistung durch die Zusammenarbeit von Administratoren und Ent-wicklern optimieren lässt.

Empfohlene VorgehensweiseWichtige Konzepte beim Optimieren Ihrer Anwendungen sind TTFB (Time To First Byte, Zeit bis zum ersten Byte) und TTLB (Time To Last Byte, Zeit bis zum letzten Byte). Wie viele Sekunden dauert es, bis die TTFB erreicht ist, und wie viele Sekunden liegen zwischen TTFB und TTLB? Wie hoch ist die Latenz? Wird die Seite schnell geladen, muss die Anwendung dann aber viele Daten von Webdiensten und anderen Datenquellen abrufen?

Ihre Hardware kann entscheiden, ob eine Anwendung akzeptabel läuft oder nicht. Aber Architektur, Entwurf und Tests einer Anwendung tragen viel dazu bei, dass eine Anwendung im Produktivbetrieb erfolgreich wird.


Systemüberwachung 615

SystemüberwachungÜberwachung ist ein unverzichtbares Element beim Betreiben jeder Anwendung und jedes Systems. Architektur, Entwurf und Tests einer Anwendung oder eines Systems wird üblicherweise die meiste Aufmerksamkeit geschenkt. Aber welches ist der wichtigste und kritischste Teil des Systems, nachdem Planung, Tests und Optimierung abgeschlossen sind? Das Rollout – Sie haben richtig gelesen, das Rollout ist der wichtigste Schritt in diesem Prozess. Und es ist oft der furchteinflößendste und aufregendste Teil bei einem Projekt.

Die Überwachung muss mit dem Rollout kombiniert werden. Wenn eine Anwendung oder ein System nicht überwacht werden kann, überlebt es im Produktivbetrieb vermutlich nicht allzu lang, sofern es nicht eine ganz unkritische Komponente ist. Zeit und Ressourcen (bei Hardware und Menschen) sind knapp.

Microsoft hat Verbesserungen an der Leistungsüberwachung vorgenommen. Dieser Abschnitt soll Ihnen nicht in allen Einzelheiten beibringen, wie Sie die verschiedenen Tools und Features bedienen. Sie erhalten aber einen Überblick und bekommen Hinweise, wie und wann Sie die geeigneten Werk-zeuge einsetzen.

Die Überwachung eines Systems ist nur so gut wie die verfügbaren Tools. Verschiedene Tools helfen Ihnen dabei, Ihre Anwendung oder Ihr System zu überwachen, testen und optimieren. Folgende Tools stehen für die Überwachung zur Verfügung, sie werden in den nächsten Abschnitten genauer beschrieben:

� Web Capacity Analysis Tool (WCAT)

� Zuverlässigkeits- und Leistungsüberwachung

� Ablaufverfolgung für Anforderungsfehler (FRT), auch als FREB bezeichnet

� Ereignisanzeige

� System Center Operations Manager

WCATDas Web Capacity Analysis Tool (WCAT) ist ein wichtiges Tool zum Testen Ihrer Anwendungen und Systeme. Es wurde dafür entworfen, Belastungsszenarien zu simulieren. Mit WCAT ermitteln Sie die beste Konfiguration für Ihre Anwendung und Ihr System. Das IIS-Team und das NT-Leistungsteam setzen dieses Tool für interne Leistungs- und Skalierbarkeitstests von IIS und ASP.NET ein. Sie können WCAT von http://iis.net/downloads herunterladen.

Zuverlässigkeits- und LeistungsüberwachungWindows Server 2008 führt einen erweiterten Systemmonitor mit dem Namen Zuverlässigkeits- und Leistungsüberwachung ein. Es ist eine Sammlung von Dienstprogrammen für Administratoren, die Leistungsdaten für verschiedenste Komponenten messen wollen. Windows Server 2008 und IIS 7.0 nutzen dieses neue Tool. Abbildung 17.7 zeigt, wie die Zuverlässigkeits- und Leistungsüberwachung die vier wichtigsten Leistungsindikatorkategorien anzeigt: CPU, Datenträger, Speicher und Netzwerk.



Abbildung 17.7 Zuverlässigkeits- und Leistungsüberwachung in Windows Server 2008

FRTEines der zentralen Features von IIS 7.0 ist die Diagnose. Die Ablaufverfolgung für Anforderungsfehler (Failed Request Tracing, FRT) ist neu in IIS 7.0 (in Betaversionen wurde sie noch als FREB bezeichnet). Sie ist Ihr Hauptwerkzeug, um Probleme aufzudecken und zu diagnostizieren. Die Ablaufverfolgung für Anforderungsfehler wird in Kapitel 16, »Ablaufverfolgung und Problembehandlung«, ausführlich beschrieben.

EreignisanzeigeSie fragen sich vielleicht, warum hier die Ereignisanzeige erwähnt wird, aber die Ereignisanzeige liefert wertvolle Informationen, darunter Daten zu allen aufgetretenen Fehlern. Wie ausführlich die in der Ereignisanzeige sichtbaren Informationen sind, hängt von Ihren Überwachungseinstellungen ab, aber sie ist immer eine gute erste Anlaufstelle, wenn Sie eine Problembehandlung durchführen.

System Center Operations Manager 2007System Center Operations Manager 2007 wird normalerweise in Unternehmensumgebungen bereit-gestellt. Es ist ein Element einer Toolfamilie für Überwachung und Systemverwaltung. Microsoft stellt Verwaltungspakete zur Verfügung, die sich in Operations Manager 2007 einbinden. Weitere Informa-tionen über dieses Tool finden Sie unter http://www.microsoft.com/systemcenter/opsmgr/default.mspx.


Skalierbarkeit 617

SkalierbarkeitDie Skalierbarkeit hängt von vielen Faktoren ab, darunter die verwendete Hardware, die bereitgestellten Inhaltstypen und Anwendungen sowie die Menge des verfügbaren RAMs. Dieser Abschnitt beschreibt, inwiefern Windows Server 2008 und IIS 7.0 Ihre Anwendungen in diesem Bereich verbessern.

IIS 7.0 stellt viele Features zur Verfügung, die sich positiv auf die Skalierbarkeit auswirken. Kernel-moduscache, dynamische Komprimierung und integrierte Pipeline sind einige dieser Features.

EntwurfsphaseDie Entwurfsphase hat wahrscheinlich die größte Auswirkung auf die Skalierbarkeit einer Anwendung. Sie können während der Entwurfsphase ein Testmuster bereitstellen und es in einer kontrollierten Umgebung austesten.

Charakteristik einer AnwendungWenn Sie Ihre Anwendung genau verstehen, kann das die Skalierbarkeit verbessern. Ist der Großteil der Daten dynamisch oder statisch? Falls die Anwendung statische Elemente hat, können Sie unter Umständen Teile davon zwischenspeichern. Enthalten die am häufigsten abgerufenen Seiten statische oder teilweise statische Informationen? Dieser Punkt wird darüber entscheiden, ob Sie die Zwischenspeicherungsfeatures von IIS 7.0 nutzen.

Auch andere Faktoren können die Skalierbarkeit verbessern, zum Beispiel ob Ihre Anwendung Informationen in Text- oder XML-Dateien speichert und ob der Großteil der Informationen in einer Datenbank gespeichert ist.

BenutzerbasisEine weitere kritische Anforderung, die Sie analysieren müssen, ist Ihre Benutzerbasis. Manchmal übersehen wir, wer eigentlich auf unsere Anwendungen zugreift. Kommen die meisten oder sogar alle Ihre Benutzer aus Ihrem eigenen Unternehmen oder aus dem Internet?

Wenn Sie Ihre Benutzerbasis während aller Phasen der Anwendungsentwicklung, -tests und -rollouts kennen, können Sie realistischere Erwartungen über den Zeitpunkt formen, an dem tatsächlich die ersten Benutzer auf Ihre Anwendung zugreifen. Wenn Sie Ihre Anwendung unter Berücksichtigung der erwarteten Benutzerbasis testen, sollten Sie versuchen, unterschiedliche Szenarien unter unterschied-lichen Lastsituationen durchzuspielen.

Um eine zuverlässige, skalierbare Anwendung zu erhalten, ist es unverzichtbar, dass Sie wissen, wie Ihre Benutzerbasis auf Ihre Anwendung zugreift und wie sich die Anwendung in unterschiedlichen Situationen verhält.

Mehr Computer oder leistungsfähigere Computer?Die uralte Frage der IT: Sollten Sie lieber wenige leistungsfähige Computer einsetzen oder viele schwächere? Simple Antwort: Kommt drauf an.

WebfarmenEine Webfarm ist eine Gruppe aus zwei oder mehr Servern, die eine Website hosten. Webfarmen erhöhen die Kapazität einer Website und verbessern die Verfügbarkeit, weil redundante Server zur Verfügung stehen. Webfarmen werden üblicherweise für stark frequentierte und unternehmenskritische



Websites eingesetzt. Folgende Faktoren sollten Sie beachten, wenn Sie vorhaben, eine einzige Website auf mehreren Servern auszuführen:

� Speicherort der Inhalte

� Sitzungsverwaltung

� Netzwerklastenausgleich

Der Speicherort der Inhalte ist oft die zentrale Frage für Architektur und Skalierbarkeit. Sie können die Dateien entweder lokal auf den Webservern ablegen oder in einen Remotedateiserver auslagern. Bei Bereitstellungen, die nur einen einzigen Server umfassen, bringt es Leistungsvorteile, wenn Sie den Inhalt lokal auf dem Server halten. Außerdem sind Verwaltung und Wartung einfacher. In Webfarmen können Sie den Inhalt ebenfalls lokal auf dem Server ablegen. Aber Sie müssen dann irgendeine Form der Dateireplikation implementieren, damit die Dateien auf allen Computern synchron bleiben. Falls Ihre Website oft Änderungen durchführt oder Tausende von Dateien verwaltet, kann es schwierig sein, sie alle synchron zu halten.

Die andere Möglichkeit zum Speichern der Inhalte besteht darin, sie auf einen Remotedateiserver zu verlagern. Ihre IIS-Server bilden das Frontend für den Remoteinhalt. Es hat viele Vorteile, den Inhalt auf einem Remotedateiserver abzulegen: eine einzige Version des Inhalts; höhere Effizienz beim Durchführen von Updates; einfachere Rücknahme von Änderungen als bei der Speicherung der Inhalte auf sämtlichen Knoten der Webfarm; und als Remotedateiserver kann ein SAN (Storage Area Network) eingesetzt werden, dessen Festplatten schneller sind als lokale Serverfestplatten.

Wenn Sie über UNC-Pfade (Universal Naming Convention) auf die Inhalte zugreifen, müssen Sie einige Änderungen in der Registrierung vornehmen. Beim Webserver fügen Sie einen Registrierungs-eintrag hinzu, beim Remotedateiserver zwei Registrierungseinträge. Die folgende Anleitung beschreibt, wie Sie diese Änderungen vornehmen.

Gehen Sie folgendermaßen vor, um die Registrierungsschlüssel auf dem Dateiserver zu konfigurieren:

1. Geben Sie in einer Eingabeaufforderung den Befehl regedt32 ein, um den Registrierungs-Editor zu öffnen.

2. Öffnen Sie den Zweig HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanman-server\Parameters.

3. Erstellen Sie einen DWORD-Registrierungseintrag mit dem Namen MaxMpxCt, sofern er noch nicht vorhanden ist, und setzen Sie ihn auf den Wert 800 hexadezimal (das entspricht dezimal 2048).

4. Erstellen Sie einen DWORD-Registrierungseintrag mit dem Namen MaxWorkItems, sofern er noch nicht vorhanden ist, und setzen Sie ihn auf den Wert 2000 hexadezimal (das entspricht dezimal 8192, also das Vierfache von MaxMpxCt).

Gehen Sie folgendermaßen vor, um den Registrierungsschlüssel auf dem Webserver zu konfigurieren:

1. Geben Sie in einer Eingabeaufforderung den Befehl regedt32 ein, um den Registrierungs-Editor zu öffnen.

2. Öffnen Sie den Zweig HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanman-workstation\Parameters.

3. Erstellen Sie einen DWORD-Registrierungseintrag mit dem Namen MaxCmds, sofern er noch nicht vorhanden ist, und setzen Sie ihn auf den Wert 800 hexadezimal (das entspricht dezimal 2048).

Weiterführende Informationen Weitere Informationen finden Sie im Artikel »IIS Runs Out of Work Items and Causes RPC Failures When Connecting to a Remote UNC Path« unter http://support.microsoft.com/kb/221790/.


Skalierbarkeit 619

Die Sitzungsverwaltung in einer Webfarm kann recht problematisch sein. Abhängig von der Anwendung gibt es verschiedene Möglichkeiten, den Sitzungszustand in einer Webfarm zu unterstützen. Bei klassischen ASP-Anwendungen haben Sie normalerweise eine so genannte Sticky-State-Verwaltung auf dem Load-Balancer implementiert, die den Client an den Server weiterleitet, der ursprünglich die Sitzung begonnen hat. Alle Anforderungen werden über die gesamte Sitzung hinweg an diesen Server geleitet. Abhängig vom Verkehr kann dieses Verhalten Auswirkungen auf die Belastung anderer Server haben.

Falls Sie das eingebaute NLB-Feature von Windows Server 2008 einsetzen, sorgt die so genannte Affinität dafür, dass die Sitzung immer an denselben Server weitergeleitet wird. ASP.NET-Anwendungen unter-stützen verschiedene Modi für den Sitzungszustand. In einer Webfarmbereitstellung brauchen Sie ent-weder einen Remote-ASP.NET-Sitzungszustandsserver oder einen SQL Server-Sitzungszustandsserver. Die SQL Server-Lösung lässt sich auf einen Cluster mehrerer Computer verteilen, sodass Failoverfähig-keiten zur Verfügung stehen. Microsoft selbst stellt ASP.NET-Zustandsserver und SQL Server-Sitzungen als Optionen zur Verfügung. Sie bieten gute Skalierbarkeit für Anwendungen, die eine Zustandsverwal-tung benötigen. Lösungen anderer Hersteller bieten Unterstützung für InProc und die Replikation von Sitzungs- und Cacheobjekten auf andere Computer. Am besten entwerfen Sie Ihre Anwendungen gleich so, dass sie zustandslos arbeiten und keine Sitzungsverwaltung benötigen. Eine zustandslose Anwendung ist flexibler und lässt sich in einer Webfarmbereitstellung besser skalieren.

Webfarmen können für die Skalierung Ihrer Anwendung sehr wichtig sein. Bevor Sie die Skalierung in Angriff nehmen, sollten Sie wissen, dass eine Webfarm wahrscheinlich die kostengünstigste Möglich-keit ist und sich schnell amortisiert.

WebgärtenWeiter oben in diesem Kapitel haben wir Webgärten behandelt und erklärt, wie sie die Skalierbarkeit verbessern. Wenn Sie Webgärten einsetzen, können Sie die Skalierung unter Beibehaltung der Hard-ware durchführen. Systeme, die mehrere Prozessorkerne haben, bieten automatisch Unterstützung für Webgärten. Wenn Sie die Skalierbarkeit verbessern wollen, bieten Webgärten eine Möglichkeit, sofern Ihre Systeme mehrere CPU-Kerne haben.

HardwareaufrüstungDie Möglichkeit, Ihre vorhandene Hardware aufzurüsten, wird manchmal übersehen, wenn Anwen-dungsprobleme auftauchen. Im Allgemeinen vergleicht der Administrator stärkere und schnellere Hardware mit den vorhandenen Geräten. Bevor Sie das Budget für den Kauf neuer Hardware bean-tragen, sollten Sie erst einmal analysieren, was wirklich in Ihrem Server vor sich geht. Falls Sie fest-stellen, dass die CPU des Computers überlastet ist, können Sie möglicherweise weitere Prozessoren hinzufügen. Eine typische CPU kostet weniger als ein neuer Computer. Falls Sie feststellen, dass RAM den Engpass bildet, sollten Sie prüfen, ob er sich im vorhandenen Computer aufrüsten lässt. Mehr RAM kann die Serverleistung deutlich steigern. Falls die Festplatten den Engpass bilden, sollten Sie prüfen, ob Sie den Inhalt in ein SAN verlegen können, sofern eines in Ihrer Umgebung verfügbar ist. Das ver-längert die Lebensdauer des Servers und verbessert die Anwendungsleistung.

Sehen wir uns ein Beispiel an: Sie haben eine Webfarm mit zwei Knoten. Die CPU eines Servers ist durchschnittlich mit 30 bis 40 Prozent ausgelastet, Spitzenwerte liegen bei 60 Prozent, manchmal auch darüber. Der Verkehr hat sich so stark erhöht, dass die Leistung inzwischen ein Problem ist. Mithilfe der Zuverlässigkeits- und Leistungsüberwachung stellen Sie fest, dass in der CPU-Auslastung immer wieder Spitzen auftreten. Die Server haben jeweils einen Prozessor installiert (mit Hyperthreading, sodass zwei Kerne angezeigt werden). Wenn Sie einen weiteren Prozessor zu einem Server hinzufügen, der zwei CPU-Sockel hat, sinkt die CPU-Auslastung von 30 bis 40 Prozent auf 10 bis 15 Prozent. Der



Prozessor kostet 200 Euro pro Computer. Die Gesamtkosten betragen also 400 Euro (200 Euro pro Computer, von denen die Webfarm 2 enthält). Dagegen würde es eine vierstellige Summe kosten, einen weiteren Computer anzuschaffen. Dies ist ein Beispiel, wie Sie die Lebensdauer Ihrer aktuellen Hard-ware verlängern können, statt eine Webfarm durch weitere Computer zu erweitern oder Server durch schnellere Modelle zu ersetzen.

NetzwerklastenausgleichNetzwerklastenausgleich (Network Load Balancing, NLB) leitet Anforderungen an mehrere Server, die Ihre Website zur Verfügung stellen. Es gibt mehrere Möglichkeiten, wie der Verkehr an Ihre Webfarm weitergeleitet wird. Beim Round-Robin werden Anforderungen gleichmäßig auf alle Computer verteilt. Beim Least-Active-Verfahren werden Anforderungen an den Webserver gesendet, der am meisten Ressourcen frei hat. Beim Sticky-State- oder Affinitäts-Verfahren werden Anforderungen erneut an den Server weitergeleitet, der die Sitzung ursprünglich begonnen hat. Beim Fastest-Reply-Verfahren werden Anforderungen an den Server gesendet, der am schnellsten antwortet. Windows Server 2008 stellt ein eingebautes NLB-Feature zur Verfügung, das mehrere dedizierte IP-Adressen unterstützt. Viele Hersteller bieten Multilayer-Load-Balancer an. Für Sites mit hohem Verkehrsaufkommen wird empfohlen, Microsoft NLB und Load-Balancer anderer Hersteller zu analysieren, bevor entschieden wird, welche Lösung eingesetzt werden soll. Der Einsatz von Load-Balancer-Technologie kann hohe Verfügbarkeit und Redundanz sicherstellen und die Skalierbarkeit Ihrer Anwendung verbessern.

ZusammenfassungIIS 7.0 baut auf Verbesserungen auf, die erstmals in Windows Server 2003 SP1 und IIS 6.0 eingeführt wurden. Die Zwischenspeicherung wurde erweitert, sodass alle Arten von Anwendungen mehr Leistung bieten. Der Ausgabecache kann für Microsoft-Technologien wie ASP und ASP.NET, aber auch für Nicht-Microsoft-Sprachen wie PHP genutzt werden. Eine andere Verbesserung ist zum Beispiel, dass die SSL-Verarbeitung in den Kernelmodus verlagert wurde, wodurch sie schneller wird.

Die 64-Bit-Editionen von Windows Server 2008 bieten die Fähigkeit, 32-Bit- und 64-Bit-Anwendungs-pools auf demselben Server auszuführen. IIS 7.0 bietet stichhaltige Gründe, auf die 64-Bit-Version umzusteigen; es sind keinerlei Codeänderungen nötig, aber Sie profitieren trotzdem von den Vorteilen der 64-Bit-Architektur.

Verbesserte Diagnosemöglichkeiten helfen, Probleme schnell zu identifizieren und beseitigen. Windows Server 2008 führt eine erweiterte Zuverlässigkeits- und Leistungsüberwachung ein. Sie können mithilfe vieler Indikatoren die relevanten Daten messen und Ihre Anwendungen schnell analysieren und Probleme beseitigen. Der TCP/IP-Stack ist zwar eher eine Verbesserung am Betriebssystem, aber die Leistungs-gewinne sind auch in Ihren Webanwendungen spürbar. Außerdem stehen neue Informationen zur Ver-fügung, mit denen Sie Ihre Anwendungen besser überwachen können.

IIS 7.0 stellt also viele Verbesserungen zur Verfügung, die zahlreiche Möglichkeiten bieten, die Leis-tung Ihrer Webanwendungsumgebung zu steigern.



Weitere InformationenDas IIS-Team bei Microsoft hat große Anstrengungen unternommen, um Artikel für alle möglichen Zielgruppen auf http://www.iis.net zu veröffentlichen, der zentralen IIS-Community-Site. Weitere Informationen über Leistung und Optimierung finden Sie im TechCENTER auf http://www.iis.net. Die folgenden Quellen liefern weitere Informationen und Tools zu den Themen Leistung und Optimierung:

� Informationen zu 64-Bit-Systemen finden Sie unter http://www.microsoft.com/servers/64bit/overview.mspx.

� Der Artikel »IIS7 Output Caching for Dynamic Content: Speed Up Your ASP and PHP Applications« unter http://blogs.iis.net/bills/archive/2007/5/2/1690364.aspx

� Weitere Informationen über den Ausgabecache in IIS 7.0 finden Sie im Artikel »IIS 7.0 Output Caching« unter http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Optimizing-Performance/ Using-Output-Cache/IIS7-Output-Caching.

� Der Artikel »IIS 7 C++ Module API Sample: Controlling HTTP.sys Caching« unter http://blogs.iis.net/rickjames/archive/2007/11/20/iis-7-c-module-api-sample-controlling-http-sys-caching.aspx

� Weitere Informationen über SSL-Verarbeitung in IIS 7.0 finden Sie in »How to Setup SSL on IIS7« unter http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Configuring-Security/Using-SSL/How-to-Setup-SSL-on-IIS7.

� Der Artikel »Web and Application Server Infrastructure: Performance and Scalability« unter http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx#ESXAE

� Anleitungen zur ASP.NET-Leistungsüberwachung finden Sie in »ASP.NET Performance Monitoring and When to Alert Administrators« unter http://msdn2.microsoft.com/en-us/library/ms972959.aspx#monitor_perf_topic12.

� Das Whitepaper »Shared Hosting on IIS 7.0« unter http://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Deployment-for-Web-Hosters/Shared-Hosting-on-IIS7


623

T E I L V

Anhänge

In diesem Teil:HTTP-Fehlercodes in IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625IIS 7.0-Fehlermeldungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631Liste der IIS 7.0-Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639Reihenfolge der Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651IIS 7.0-Standardeinstellungen und Zeitlimits/Schwellenwerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655IIS 7.0 und 64-Bit-Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685Zuordnung von Internetinformationsdienste-Manager-Features und Konfigurationsabschnitten . . . . 689Zuordnung zwischen IIS 6.0-Metabasis und IIS 7.0-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 693Shared Hosting mit IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707Durchführen von Administrationsaufgaben im Internetinformationsdienste-Manager . . . . . . . . . . . . . 713


625

A N H A N G A

HTTP-Fehlercodes in IIS 7.0

Tabelle A.1 führt die benutzerdefinierten HTTP-Codes auf, die IIS 7.0 (Internet Information Services, Internetinformationsdienste) verwendet, wenn es einen Fehler anzeigt. Benutzerdefinierte Fehler-dateien sind in %SystemDrive%\inetpub\custerr\<Region> gespeichert (bei der deutschen Version also in %SystemDrive%\inetpub\custerr\de-DE). Nicht zu allen Statuscodes gibt es benutzerdefinierte Fehlerseiten auf dem Datenträger. Wenn das Modul für benutzerdefinierte Fehler einen Fehler feststellt, führt es eine von sechs möglichen Aktionen aus:

1. Die Antwort bleibt unverändert.

2. Es wird eine einzeilige Fehlermeldung ausgegeben.

3. Es wird eine statische Datei vom Datenträger ausgegeben (c:\inetpub\custerr\de-DE\404.htm).

4. Eine URL wird ausgeführt.

5. Umleitung

6. Es wird ein ausführlicher Fehler generiert (für localhost-Anforderungen das Standardverhalten).

Die folgenden Artikel enthalten weitere Informationen zu HTTP-Statuscodes und häufigen Fehlerursachen sowie Verweise auf weitere Artikel zur Problembehandlung:

� »Troubleshooting Failed Requests using Tracing in IIS7« unter http://support.microsoft.com/kb/943891

� Der folgende Link wird unter Weitere Informationen unten in einem detaillierten Fehler angezeigt: http://go.microsoft.com/fwlink/?LinkID=66439. Wenn der Link aufgerufen wird, werden folgende Daten in den Link eingebaut: Status, Unterstatus, Hresult, Buildnummer. Der fertige Link sieht dann zum Beispiel so aus http://go.microsoft.com/fwlink/?LinkID=62293&IIS70Error= 404,0,0x80070002,6001.

� »The HTTP Status Codes in IIS 7.0« unter http://go.microsoft.com/fwlink/?LinkID=62293

� Weitere Informationen über RFC-Fehlercodes finden Sie unter http://www.ietf.org/rfc/rfc2616.txt.Module von Fremdherstellern können beliebige Werte für Status, Unterstatus oder Hresult eintragen, auch ungültige.

Tabelle A.1 Benutzerdefinierte HTTP-Fehlercodes in IIS

Statuscode Unterstatuscode Hresult Beschreibung

100 Fortsetzen

101 Protokolle werden gewechselt

200 OK. Die Clientanforderung war erfolgreich.

201 Erstellt

202 Akzeptiert

203 Nicht autorisierende Informationen

204 Kein Inhalt


microsoft internetinformationsdienste (iis) 7.0 – die technische...

Documents