Microsoft Internetinformationsdienste (IIS) 7.0 – Die

Transcrição

Mike Volodarsky
Olga Londer
Brett Hill
Bernard Cheah
Steve Schofield
Carlos Aguilar Mares
Kurt Meyer
Microsoft IIS Team
Microsoft
Internetinformationsdienste (IIS) 7.0 –
Die technische
Referenz
Microsoft Internetinformationsdienste (IIS) 7.0 – Die technische Referenz, © 2008 Microsoft Press Deutschland, ISBN 978-3-86645-924-3
Dieses Buch ist die deutsche Übersetzung von: Internet Information Services 7.0 Resource Kit
Microsoft Press, Redmond, Washington 98052-6399
Copyright 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 sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programmmaterials oder Teilen davon entsteht.
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ältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Die in den Beispielen verwendeten Namen von Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereignissen 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 1
10 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ßheim
Alle Rechte vorbehalten
Übertragung ins Deutsche: Detlef Johannis, Uwe Thiemann
Korrektorat: Karin Baeyens, Dorothee Klein, Siegen
Satz: 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)
III
Inhaltsverzeichnis
Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XV
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XVII
Welche Neuerungen bietet IIS 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Übersicht über das Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Besondere Kennzeichnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lesehilfen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einschübe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Befehlszeilenbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inhalt der Begleit-CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Weitere Inhalte online finden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supportrichtlinie für die technische Referenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XVII
XIX
XIX
XIX
XX
XX
XX
XXI
XXI
Teil I Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
Kapitel 1 Einführung in IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Übersicht über IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Welche Neuerungen bietet IIS 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Der Webserverkern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltungstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows-Prozessaktivierungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungskompatibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grundlegende Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Websites erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungen erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtuelle Verzeichnisse erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungspools erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einem Anwendungspool eine Anwendung zuweisen . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS 7.0 Features unter Windows Server 2008 und Windows Vista . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
5
5
8
10
13
14
15
15
15
17
19
20
21
22
26
27
Kapitel 2 Grundlagen der IIS 7.0-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Übersicht über die IIS 7.0-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS 7.0-Kernkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTP.sys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WWW-Publishingdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows-Prozessaktivierungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
33
33
35
37
IV Inhaltsverzeichnis
Konfigurationsspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeitsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anforderungsverarbeitung im Anwendungspool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Klassischer Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Der integrierte .NET-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gültigkeitsbereiche von Modulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modulreihenfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verarbeitung von Nicht-HTTP-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
40
42
43
45
50
51
52
54
55
Kapitel 3 Verstehen der modularen Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Ideen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modultypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Module und Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hauptvorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integrierte Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
58
58
59
61
61
63
63
64
65
65
Kapitel 4 Verstehen des Konfigurationssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Übersicht über das Konfigurationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsdateihierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsdateisyntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Das IIS 7.0-Konfigurationssystem und die IIS 6.0-Metabasis . . . . . . . . . . . . . . . . . . . .
IIS 7.0 und die .NET-Konfigurationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsbearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auswahl des Konfigurationsorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationen festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsfehler verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sichern der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeiten mit dem Konfigurationsverlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exportieren und Importieren von Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsdelegierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eine Konfiguration für mehrere Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
69
73
80
83
84
85
86
90
93
93
94
95
96
106
111
112
Inhaltsverzeichnis
Teil II Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V
113
Kapitel 5 Installieren von IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
115
Planen der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installationsszenarien für IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Möglichkeiten der Installation von IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mit dem Server-Manager arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Den Paketmanager verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ServerManagerCMD verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Antwortdateien für unbeaufsichtigte Installationen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sysprep/Neues Setupsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automatische Installationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows Server 2008-Setup für optionale Features . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nach der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ordner und Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Überprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behandlung von Installationsproblemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ereignisprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS 7.0-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Andere Protokollierungsoptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS 7.0 entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Benutzeroberfläche unter Windows Server 2008 und Windows Vista . . . . . . . . . .
Die Befehlszeilenmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
115
117
129
129
130
131
133
135
136
136
137
138
139
139
139
140
140
141
141
142
142
144
145
146
Teil III Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
147
Kapitel 6 Verwenden von IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
149
Übersicht über den IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Den IIS-Manager starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Benutzeroberfläche des IIS-Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Navigationsleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Der Bereich Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeitsbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Der Bereich Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Features verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Zuordnung von Features zu Modulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Speicherort der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gültigkeitsbereich der Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anpassung und Erweiterbarkeit des IIS 7.0-Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remoteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
149
152
153
155
155
158
171
171
172
174
176
177
180
181
182
VI Inhaltsverzeichnis
Kapitel 7 Verwenden von Befehlszeilentools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
183
Befehlszeilentools für die Verwaltung benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appcmd.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erste Schritte mit Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Syntax von Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unterstützte Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Hilfe nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Ausgabe von Appcmd verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allgemeine Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bereichsoperatoren verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Häufige Fehler bei der Arbeit mit Appcmd vermeiden . . . . . . . . . . . . . . . . . . . . . . . . .
Die Grundverben verwenden: List, Add, Set und Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objekte mit dem List-Befehl auflisten und auffinden . . . . . . . . . . . . . . . . . . . . . . . . . .
Objekte mit dem Add-Verb erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bereits vorhandene Objekte mit dem Set-Verb ändern . . . . . . . . . . . . . . . . . . . . . . . . .
Objekte mit dem Delete-Verb entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeiten mit der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationen mit dem Befehl List Config betrachten . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationen mit dem Befehl Set Config festlegen . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Konfigurationsdelegierung verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationssicherungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mit Anwendungen, virtuellen Verzeichnissen und Anwendungspools arbeiten . . . . . . . . . .
Mit Webservermodulen arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ausgeführte Arbeitsprozesse und Anforderungen untersuchen . . . . . . . . . . . . . . . . . . . . . . .
Ausgeführte IIS-Arbeitsprozesse auflisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gegenwärtig ausgeführte Anforderungen auflisten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mit der Ablaufverfolgung für Anforderungsfehler arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Ablaufverfolgung für Anforderungsfehler aktivieren . . . . . . . . . . . . . . . . . . . . . . .
Ablaufverfolgungsregeln für Anforderungsfehler aufstellen . . . . . . . . . . . . . . . . . . . . .
Ablaufverfolgungsprotokolle für Anforderungsfehler durchsuchen . . . . . . . . . . . . . . .
Microsoft.Web.Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sites mit MWA erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungspools mit MWA erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Konfiguration festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows PowerShell und IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WMI-Anbieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
COM-Objekte für die IIS 7.0-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
183
185
186
187
188
189
191
194
195
196
196
196
198
198
199
200
201
202
206
206
207
208
208
208
209
210
210
211
213
215
215
216
217
218
219
219
220
220
Kapitel 8 Remoteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
221
Der IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Webverwaltungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WMSvc-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
222
222
223
224
Inhaltsverzeichnis
VII
Die Remoteverwaltung verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mit der Remoteverwaltung arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problembehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
232
240
243
245
248
248
Kapitel 9 Verwalten von Websites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
249
Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools . . . . . . . . . . . . . .
Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtuelle Verzeichnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungspools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eine neue Website hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Bindungen einer Website konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Websiteverwendung einschränken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Websiteprotokollierung und Ablaufverfolgung für Anforderungsfehler konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Websites starten und beenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtuelle Verzeichnisse verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ein neues virtuelles Verzeichnis hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtuelle Verzeichnisse konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nach virtuellen Verzeichnissen suchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remoteinhalte verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungen für die Arbeit mit Remoteinhalten konfigurieren . . . . . . . . . . . . . . . . . .
Das Sicherheitsmodell für den Zugriff auf Remoteinhalte auswählen . . . . . . . . . . . . . .
Feste Anmeldeinformationen für den Zugriff auf Remoteinhalte konfigurieren . . . . . .
Den Zugriff auf Remoteinhalte gewähren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
249
250
252
254
254
256
256
259
262
264
265
266
266
268
271
272
273
274
276
276
277
278
Kapitel 10 Verwalten von Anwendungen und Anwendungspools . . . . . . . . . . . . . . . . . . . .
279
Webanwendungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Webanwendungen erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Webanwendungen auflisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungspools verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Überlegungen zu Anwendungspools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einen neuen Anwendungspool hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungspoolidentitäten verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erweiterte Anwendungspoolkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeitsprozesse und Anforderungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeitsprozesse und Anforderungen überwachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
279
280
285
287
288
290
292
296
302
302
306
307
VIII Inhaltsverzeichnis
Kapitel 11 Hosting von Anwendungsentwicklungsframeworks . . . . . . . . . . . . . . . . . . . . .
309
IIS als Anwendungsentwicklungsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsframeworks unterstützen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unterstützte Anwendungsframeworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP.NET-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Den integrierten und den klassischen ASP.NET-Modus verstehen . . . . . . . . . . . . . . . .
Mehrere ASP.NET-Versionen gleichzeitig ausführen . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP.NET installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP.NET-Anwendungen bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zusätzliche Überlegungen zur Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP-Anwendungen bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PHP-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PHP-Anwendungen bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsframeworks ermöglichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Verarbeitung von neuen statischen Dateien konfigurieren . . . . . . . . . . . . . . . . . . .
Frameworks basierend auf systemeigenen IIS 7.0-Modulen bereitstellen . . . . . . . . . . .
Frameworks basierend auf ASP.NET-Handlern bereitstellen . . . . . . . . . . . . . . . . . . . .
Frameworks basierend auf ISAPI-Erweiterungen bereitstellen . . . . . . . . . . . . . . . . . . .
Mit FastCGI arbeitende Frameworks bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mit CGI arbeitende Frameworks bereitstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
309
310
312
313
314
316
318
320
325
327
327
328
329
330
331
335
337
338
340
341
342
342
346
348
348
Kapitel 12 Verwalten von Webservermodulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
349
IIS 7.0-Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die IIS 7.0-Erweiterbarkeitsarchitektur auf einen Blick . . . . . . . . . . . . . . . . . . . . . . . .
Die Erweiterbarkeit verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Webservererweiterbarkeit zur Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Was ist ein Modul? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Module installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allgemeine Modulverwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltete Module mit dem IIS-Manager installieren und verwalten . . . . . . . . . . . . . .
Handlerzuordnungen mit dem IIS-Manager erstellen und verwalten . . . . . . . . . . . . . .
Verwaltete Module mit Appcmd installieren und verwalten . . . . . . . . . . . . . . . . . . . . .
Handlerzuordnungen erstellen und verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Webservermodule sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
349
350
352
353
353
359
370
377
380
384
388
390
399
400
Inhaltsverzeichnis
IX
Kapitel 13 Konfigurations- und Benutzeroberflächenerweiterungen verwalten . . . . . . . .
401
Übersicht über den Verwaltungsstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationserweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsabschnittsschemata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsabschnitte deklarieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Neue Konfigurationsabschnitte installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsabschnitte sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltungserweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wie Verwaltungserweiterungen funktionieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltungserweiterungen installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltungserweiterungen sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS-Manager-Erweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Funktionsweise von IIS-Manager-Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS-Manager-Erweiterungen installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS-Manager-Erweiterungen sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
401
403
405
407
410
411
415
417
418
418
419
420
422
422
425
425
Kapitel 14 Implementieren von Sicherheitsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
427
Sicherheitsänderungen unter IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verkleinern der Angriffsfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Angriffsfläche der Anwendung verkleinern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungen für die Nutzung von geringstmöglichen Berechtigungen konfigurieren . . . .
Eine über wenige Berechtigungen verfügende Anwendungspoolidentität verwenden . . .
NTFS-Berechtigungen für den Mindestzugriff gewähren . . . . . . . . . . . . . . . . . . . . . . .
Einschränken der Vertrauenswürdigkeit von ASP.NET-Anwendungen . . . . . . . . . . . .
Anwendungen isolieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Zugriffssteuerung implementieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP- und Domäneneinschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anforderungsfilterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auf NTFS-ACLs basierende Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
URL-Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anonyme Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standardauthentifzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Digestauthentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentifizierung über Clientzertifikatzuordnungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentifizierung über IIS-Clientzertifikatzuordnungen . . . . . . . . . . . . . . . . . . . . . . . .
UNC-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Authentifizierungsdelegierung verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sichern der Kommunikation mit SSL (Secure Sockets Layer) . . . . . . . . . . . . . . . . . . . . . . .
SSL konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSL voraussetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clientzertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
428
430
440
445
446
448
450
451
453
455
457
461
462
464
468
470
472
474
475
479
481
485
487
488
489
490
492
X Inhaltsverzeichnis
Sichern der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einschränken des Zugriffs auf die Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sensible Konfigurationen sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kontrollieren der Konfigurationsdelegierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die zu delegierende Konfiguration festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
493
494
498
503
503
507
507
Teil IV Problembehandlung und Leistungsoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
509
Kapitel 15 Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
511
Was ist neu? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Der Internetinformationsdienste-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Das XML-Konfigurationsschema für die Protokollierung . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsoptionen für zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . .
Standardkonfiguration für neue Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsoptionen zum Deaktivieren der HTTP-Protokollierung . . . . . . . . . . . . .
Standardspeicherort der Protokolldateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UTF-8-Kodierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Neue Statuscodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protokolldateiformate, die sich nicht verändert haben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
W3C-Format für die zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Binärformat für die zentrale Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remoteprotokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einrichten der Remoteprotokollierung mit dem Internetinformationsdienste-Manager . . .
Einrichten der Remoteprotokollierung mit Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remoteprotokollierung mit dem FTP-7.0-Publishingdienst . . . . . . . . . . . . . . . . . . . . .
Benutzerdefinierte Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurieren der IIS-Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internetinformationsdienste-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erweiterte Appcmd-Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows PowerShell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Http.sys-Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsprotokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protokollierung der Prozesswiederverwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS-Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ordnerkomprimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protokollanalyse mit Log Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
511
512
513
514
514
515
515
515
516
516
516
517
517
517
517
518
520
520
521
523
523
526
528
531
532
532
532
533
533
534
534
535
536
536
Inhaltsverzeichnis
XI
Kapitel 16 Ablaufverfolgung und Problembehandlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
537
Problembehandlung mithilfe von Ablaufverfolgung und Diagnose . . . . . . . . . . . . . . . . . . . .
Installieren des FRT-Moduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aktivieren und Konfigurieren der FRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lesen der FRT-Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integrieren von Ablaufverfolgung und ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Leistungsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problembehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwenden eines Verfahrens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeiten mit Tools und Dienstprogrammen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problembehandlung für HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beseitigen häufig auftauchender Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS 6.0-Verwaltungsprogramme sind nicht installiert . . . . . . . . . . . . . . . . . . . . . . . . . .
SSl ist nicht aktiviert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unerwartete Wiederverwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abstürze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Website nicht erreichbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentifizierungsfehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Langsame Reaktion oder hängender Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
538
538
539
545
550
551
552
552
554
567
574
574
574
574
575
575
575
575
575
576
Kapitel 17 Optimieren der Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
577
Einen Kompromiss zwischen Sicherheit und Leistung finden . . . . . . . . . . . . . . . . . . . . . . . .
Messen der Belastung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prozessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeitsspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Festplatten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Leistungsindikatoren für die Anwendungsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64-Bit-Modus und 32-Bit-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimieren der Konfiguration unter Leistungsaspekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Serverebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimieren der Konfiguration für den Belastungstyp . . . . . . . . . . . . . . . . . . . . . . . . . .
Serverseitige Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Systemüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WCAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zuverlässigkeits- und Leistungsüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ereignisanzeige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Center Operations Manager 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
577
578
582
583
584
588
591
593
596
600
601
602
603
603
604
613
615
615
615
616
616
616
XII Inhaltsverzeichnis
Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entwurfsphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mehr Computer oder leistungsfähigere Computer? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
617
617
617
620
621
Teil V Anhänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
623
Anhang A HTTP-Fehlercodes in IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
625
Anhang B IIS 7.0-Fehlermeldungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
631
HTTP-Fehler in IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurieren von <httpErrors> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unterstatuscodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel für einen Unterstatuscode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Benutzerdefinierte Fehler in unterschiedlichen Sprachen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optionen für benutzerdefinierte Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ausführen einer URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Umleiten der Anforderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
632
634
634
635
635
636
636
637
Anhang C Liste der IIS 7.0-Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
639
Native Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltete Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
639
647
Anhang D Reihenfolge der Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
651
Anhang E IIS 7.0-Standardeinstellungen und Zeitlimits/Schwellenwerte . . . . . . . . . . . . . .
655
ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standardeinstellungen für Anwendungspools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
655
661
680
682
Anhang F IIS 7.0 und 64-Bit-Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
685
Windows Server 2008 x64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurieren einer 32-Bit-Anwendung unter einer 64-Bit-Version von
Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
685
686
Anhang G Zuordnung von Internetinformationsdienste-Manager-Features
und Konfigurationsabschnitten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
689
ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
689
690
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
707
Implementieren von Process Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeiten mit der Befehlszeile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsänderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aktivieren des Schwellenwerts für das dynamische Leerlaufzeitlimit . . . . . . . . . . . . . . . . . .
Arbeiten mit der Befehlszeile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsänderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
707
708
709
709
711
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-Produktteam 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 Teammitglieder 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 durchzufü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-Operations-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 Professionalismus, 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? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Übersicht über das Buch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Besondere Kennzeichnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inhalt der Begleit-CD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Weitere Inhalte online finden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XVII
XIX
XIX
XX
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 (Internetinformationsdienste), 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 enthalten schließlich zusätzliche Tools und Dokumentationen, die Sie nutzen können, um IIS 7.0-Webserver 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 konfigurieren. Sie können die benötigten IIS-Features auswählen und sie mit neuen Webserverfeatures, welche die neuen funktionsreichen Erweiterbarkeits-APIs (Application Programming Interface) nutzen,
ergänzen oder durch diese ersetzen. Der Webserver bietet außerdem ein neues verteiltes Konfigurationssystem und Verwaltungstools an, die seine Bereitstellung und Verwaltung erleichtern. Die Kernfeatures 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 Administrator kann diese Komponenten einzeln installieren, um leichte Webserver mit einer auf das Wesentliche 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 Anwendungstechnologien 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 Interface) nicht vermeiden ließ.
Erweiterte Unterstützung von Anwendungsframeworks Zusätzlich zur Erweiterung des Webservers durch eine verbesserte ASP.NET-Integration bietet IIS 7.0 weitere Optionen zur Unterstützung 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 Anwendungen, eigene Konfigurationen festzulegen. Mit dem neuen Konfigurationssystem ist eine vereinfachte 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 flexibler 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 Ablaufverfolgung fehlgeschlagener Anforderungen Probleme zu lösen, deren Ursachen schwer nachvollziehbar sind. Die Ablaufverfolgungsfeatures sind in ASP.NET-Anwendungen integriert, damit eine vollständige Webanwendungsdiagnose von Endpunkt zu Endpunkt durchgeführt werden kann.
Einführung
XIX
Übersicht über das Buch
Die 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 Installations-Architektur und hält Anleitungen zur Installation von IIS 7.0 für verschiedene übliche Webserverauslastungsszenarien 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 Ablaufverfolgungs-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 verbessert wird.
Das Buch enthält außerdem mehrere Anhänge zu verschiedenen Themen sowie ein Glossar zum
Nachschlagen.
Besondere Kennzeichnungen
In diesem Buch werden die folgenden Kennzeichnungen verwendet, um bestimmte Besonderheiten
hervorzuheben.
Lesehilfen
Die 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übe
Im 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.
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 Problembehandlung geben
So funktioniert es
Vermittelt einen Eindruck von den IIS 7.0-Features und deren Arbeitsweise
Befehlszeilenbeispiele
In diesem Buch werden die folgenden Gestaltungsmerkmale für die Darstellung von Befehlszeilenbeispielen verwendet.
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
Inhalt der Begleit-CD
Die Begleit-CD ist eine nützliche Ergänzung zu diesem Buch und weist den folgenden Inhalt (in englischer Sprache) auf:
Elektronisches Buch Der gesamte Text des gedruckten Buches in einem durchsuchbaren PDFeBook
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 zeigen, wie die Features von IIS, Windows Server 2008 und anderen Produkten richtig eingesetzt und
Probleme behoben werden
Einführung
XXI
Weitere Inhalte online finden
Wenn 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 Referenz
Es 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Grundlagen der IIS 7.0-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Verstehen der modularen Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Verstehen des Konfigurationssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3
K A P I T E L
1
Einführung in IIS 7.0
Übersicht über IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Welche Neuerungen bietet IIS 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grundlegende Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS 7.0 Features unter Windows Server 2008 und Windows Vista . . . . . . . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
5
15
22
26
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 erweiterbaren Architektur sorgt IIS 7.0 dafür, dass die Entwicklung, Bereitstellung, Konfiguration und Verwaltung 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 Administratoren die volle Kontrolle über die Funktionalität ihrer Webserver. Dieses Design umfasst eine
erweiterbare Architektur, die es Administratoren und Entwicklern ermöglicht, angepasste und spezialisierte Webserver einzurichten. Die neuen Verwaltungsmöglichkeiten und das verteilte, auf XML
basierende Konfigurationssystem sorgen dafür, dass die Bereitstellung und Verwaltung von Webanwendungen 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.0
Mit 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 verlä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 automatisch isoliert. Möglich wird dies durch eine abgeschirmte Konfiguration und eindeutige Prozesskennungen.
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 Befehlszeilenhilfsmittel 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 administrativen 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 Erweiterbarkeits-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-Einstellungen zusammen mit ASP.NET-Einstellungen in web.config-Dateien zu speichern. Dieses vereinheitlichte 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 Betriebssicherheit opfern zu müssen.
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 Publishingmöglichkeiten, z.B. FTP über SSL (Secure Sockets Layer), und einer mitgliederbasierten Authentifizierung anbieten können.
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 vorherigen IIS-Versionen werfen.
Der Webserverkern
Der 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 Erweiterungen sind Modularität und Erweiterbarkeit.
Modularität
Bei 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 Webserverfeatures 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 Anforderungsverarbeitungspipeline entsteht. Sowohl systemeigener als auch verwalteter Code werden über
diese einzelne Anforderungspipeline verarbeitet. Alle Benachrichtigungsereignisse in der Anforderungspipeline 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 Anforderungsverarbeitungspipeline. In der Anforderungsauthentifizierungsphase zeigt Abbildung 1.1
Authentifizierungsmodule, die für alle Anforderungen zur Verfügung stehen. Die Standardauthentifizierung, 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
7
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 Arbeitsspeichers verringert. Darüber hinaus wird die Menge des Codes, der für jede Anforderung ausgefü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 Lastenausgleich, optimiert sind.
Hinweis Weitere Informationen zur Modularität des Servers finden Sie im dritten Kapitel, »Verstehen der modularen Basis«.
Erweiterbarkeit
Die 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 Webanwendungen 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 Servercode 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 benutzerdefiniertem 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 uneingeschrä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«.
Konfiguration
Die frühen IIS-Versionen verfügten über nur wenige Konfigurationseinstellungen, die in der WindowsRegistrierung gespeichert wurden. IIS 5.0 führte einen binären Speicher zur Verwaltung der URLbasierten Konfiguration ein, der als Metabasis bezeichnet wurde. Bei IIS 6.0 wurde die binäre Metabasis 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 Konfigurationseinstellungen 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 Konfigurationsspeicher 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äuchliche Format trägt dazu bei, dass IIS-Konfigurationseinstellungen zusammen mit der ASP.NETKonfiguration 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 FrameworkKonfigurationsdateien, machine.config und die web.config-Stammdatei, die globale IIS-Konfigurationsdatei 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.configDatei 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>.
9
Abbildung 1.2 Dateibasierter verteilter Konfigurationsspeicher
Der Abschnitt <system.applicationHost> enthält Einstellungen für Sites, Anwendungen, virtuelle Verzeichnisse 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 Inhaltsverzeichnisse 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 Konfigurationseinstellungen ist standardmäßig ausschließlich auf den Serveradministrator beschränkt. Der
Serveradministrator kann die Verwaltung bestimmter Konfigurationseinstellungen an Benutzer delegieren, 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 FrontEnd-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 aufnimmt. 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«.
Verwaltungstools
Die IIS 7.0-Verwaltungstools wurden vollständig neu entwickelt. Sie bieten unterschiedliche Schnittstellen 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-Stammdatei 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.
11
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 Remoteverwaltung 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-ManagerFensters 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 IISManager-Fensters. Der Arbeitsbereich besteht aus zwei Ansichten: Features und Inhalt.
In der Ansicht Features können Sie die Features des gegenwärtig ausgewählten Konfigurationspfades betrachten und konfigurieren. Jedes IIS-Manager-Feature ist in der Regel einem Konfigurationsabschnitt zugeordnet, der das entsprechende Webserverfeature kontrolliert.
Die Ansicht Inhalt stellt die Inhalte, die sich auf den gegenwärtig ausgewählten Konfigurationspfad 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ähigkeiten 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 WindowsAnmeldeinformationen, aber auch andere Anmeldeinformationsspeicher verwenden. IIS-ManagerAnmeldeinformationen 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 Remoteverwaltung ü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 IISManagers ist in Abbildung 1.5 dargestellt.
13
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 hinzuzufü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.
Diagnose
IIS 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 Ausfallzeiten von Websites auf ein Mindestmaß reduzieren, wenn Sie die neuen leistungsfähigen Diagnosemö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 Laufzeitinformationen
IIS 7.0 enthält eine neue API namens RSCA (Runtime State and Control API), die Echtzeitstatusinformationen ü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 Anforderungsfehler
IIS 7.0 produziert für den gesamten Anforderungs- und Antwortpfad detaillierte Ablaufverfolgungsereignisse, so dass Sie eine Anforderung auf ihrem Weg zu IIS, durch die IIS-Anforderungsverarbeitungspipeline, 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 nachzugehen.
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 Anforderungsfehler hilfreich sein. Sie wurde entwickelt, um die auf eine Anforderung bezogenen Ablaufverfolgungsereignisse zu puffern und im Falle eines Fehlers auf dem Datenträger in einem Ablaufverfolgungsprotokoll 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 Antwortfehlercodes, für jede betroffene Anforderung vollständige Ablaufverfolgungsprotokolle im XMLFormat generiert werden.
Die Diagnosemöglichkeiten von IIS 7.0 können erweitert werden, indem beispielsweise neue Ablaufverfolgungsereignisse in benutzerdefinierten Modulen definiert werden.
Hinweis Weitere Informationen zur Diagnose und Problembehandlung erhalten Sie im sechzehnten Kapitel,
»Ablaufverfolgung und Problembehandlung«.
Windows-Prozessaktivierungsdienst
IIS 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 ProtokollListenern während des Betriebs. WAS ist nicht nur protokollunabhängig, sondern versorgt auch alle
nachrichtenaktivierten Anwendungen mit einer intelligenten Ressourcenverwaltung, bedarfsorientierten Prozessaktivierung, Zustandsüberwachung und automatischen Fehlererkennung und Wiederherstellung. 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ät
IIS 7.0 ist kompatibel mit älteren IIS-Versionen. Die meisten bereits vorhandenen ASP-, ASP.NET 1.1und 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«.
Damit ein Webserver beginnen kann, Inhalte bereitzustellen, muss er über eine Grundkonfiguration verfü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 Internetinformationsdienste-Manager auf.
Websites erstellen
Eine 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 Bindungsinformationen. 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 Auswählen. Wählen Sie anschließend im Dialogfeld Anwendungspool auswählen und dort im Dropdown-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 verweist, 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 Dialogfeld 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.
17
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 Hostname 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 erstellen
Eine 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 Anwendungspools 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 Dialogfeld 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 Auswählen. Wählen Sie anschließend im Dialogfeld Anwendungspool auswählen und dort im Dropdown-Listenfeld Anwendungspool den gewünschten Anwendungspool und klicken Sie auf OK.
überprüfen.
6. Klicken Sie auf OK. Die neue Anwendung wird erstellt und erscheint im Bereich Verbindungen.
19
Virtuelle Verzeichnisse erstellen
Ein virtuelles Verzeichnis ist ein Verzeichnisname (der auch als Pfad bezeichnet wird). Dieses Verzeichnis 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 Anforderung, 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 virtuelles 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. Download. Dieser Wert wird benutzt, um über einen URL auf das virtuelle Verzeichnis zuzugreifen.
überprüfen.
5. Klicken Sie auf OK. Das neue virtuelle Verzeichnis wird erstellt und erscheint im Bereich Verbindungen.
Anwendungspools erstellen
Ein 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 verwendet 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 entsprechende 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 Maustaste auf den Knoten Anwendungspools. Wählen Sie anschließend Anwendungspool hinzufügen
aus. Das gleichnamige Dialogfeld erscheint.
21
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 Anwendungen, 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 auswählen:
Integriert
Wählen Sie diese Option, wenn Sie die integrierte IIS- und ASP.NET-Anforderungsverarbeitungspipeline verwenden möchten. Dies ist der Standardmodus.
Klassisch
Wählen Sie diese Option, wenn Sie die IIS- und ASP.NET-Anforderungsverarbeitungsmodi 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 Anwendungspoolliste.
Einem Anwendungspool eine Anwendung zuweisen
Sie 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 Anwendungspool 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 Vista
IIS 7.0 ist ein Bestandteil von Windows Server 2008 und Windows Vista. Die Verfügbarkeit der IIS 7.0Features 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-Funktionalitä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 -Anwendungen 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 Prozessaktivierung und stellt WCF-Anwendungen (Microsoft Windows Communication Foundation) eine
Verwaltungsinfrastruktur zur Verfügung. Diese Infrastruktur wird vom Windows-Prozessaktivierungsdienst 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
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
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
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
Anwendungsentwicklungsfeatures
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
Tabelle 1.1 IIS 7.0 Features unter Windows Server 2008 und Windows Vista (Fortsetzung)
Featurename
Windows Server
2008-Editionen
Ultimate, Business
und Enterprise
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 Clientzertifikatzuordnung
Verfügbar
Verfügbar
Nicht verfügbar
Nicht verfügbar
Authentifizierung über IIS-Clientzertifikatzuordnung
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
Komprimierung statischer Inhalte
Standard
Standard
Standard
Standard
Komprimierung dynamischer Inhalte
Verfügbar
Verfügbar
Verfügbar
Verfügbar
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
Performance Features
Verwaltungstools
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)
Featurename
Windows Server
2008-Editionen
Ultimate, Business
und Enterprise
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
10
3
3
Maximale Anzahl gleichzeitiger Verbindungen
Maximale Anzahl gleichzeitiger
Verbindungen
Unbegrenzt
Zusammenfassung
IIS 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 Verwaltung 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 potentielle 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 Konfigurationsdateihierarchie, 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 Webinfrastruktur 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 Befehlszeilentool, Appcmd.exe, einen neuen WMI-Anbieter für die Automatisierung von Verwaltungsaufgaben
Weitere Informationen
27
und eine neue verwaltete API. All diese Tools unterstützen die einheitliche und gemeinsame Verwaltung 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 verringern, 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.
Diese 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ächenerweiterungen 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 Verwendung 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
Übersicht über die IIS 7.0-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS 7.0-Kernkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anforderungsverarbeitung im Anwendungspool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verarbeitung von Nicht-HTTP-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
33
42
52
54
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 nachfolgend 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 Konfigurationseinstellungen 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 WMIAnbieter 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-HTTPAnwendungen 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 Anforderungsverarbeitungsarchitektur 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 Anforderungsverarbeitungspipeline 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-Architektur
IIS 7.0 besteht aus mehreren Kernkomponenten, die zusammenarbeiten, um HTTP-Clientanforderungen 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.0Architektur und -Kernkomponenten.
Die in Abbildung 2.1 dargestellten Kernkomponenten sind nachfolgend beschrieben:
HTTP-Protokollstapel (HTTP.sys) HTTP.sys ist der im Kernelmodus arbeitende Protokolllistener, der darauf achtet, ob HTTP- und HTTPS-Anforderungen eingehen.
W3SVC (World Wide Web Service Publishing Service) W3SVC ist ein HTTP-ListenerAdapter. 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 Anwendungspools und sorgt für deren Wiederverwendung. Darüber hinaus überwacht er zur Laufzeit den
Zustand von Arbeitsprozessen. Außerdem ruft er Konfigurationsinformationen aus dem Konfigurationsspeicher 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 Arbeitsprozessen 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-Anforderungen. 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 Arbeitsprozess 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 Anwendungspool 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 Arbeitsprozess gestartet, und die Serverfunktionalität wird in den Prozess geladen. Danach wird die Anforderung 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 applicationHost.config ab.
4. WAS prüft innerhalb des Anwendungspools, an den sich die Anforderung richtet, ob der Arbeitsprozess vorhanden ist. Ist der Arbeitsprozess nicht vorhanden, startet WAS diesen für den Anwendungspool.
5. WAS übergibt die Konfiguration, die in Form von Anwendungspool- und Anwendungskonfigurationseinstellungen 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 Anforderungsverarbeitungspipeline später in diesem Kapitel im Abschnitt »Anforderungsverarbeitung im Anwendungspool« erörtern.
9. HTTP.sys sendet eine Antwort zum Client.
In diesem Abschnitt untersuchen wir die IIS 7.0-Kernkomponenten und deren Aufgaben bei der
Prozessaktivierung und Anforderungsverarbeitung.
HTTP.sys
HTTP.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 HTTPAnforderungen. 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 Benutzermodus arbeitende Komponente, die von älteren IIS-Versionen verwendet wurde, um HTTP-Anforderungen 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 Routingtabelle wird ermittelt, welcher Anwendungspool auf Anforderungen aus welchen Teilen des Namespace 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 Anforderungen 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,
35
bemerkt der Benutzer den Fehler nicht, da die TCP/IP-Verbindungen aufrecht erhalten und Anforderungen 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-Publishingdienst
Verglichen 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-Konfigurationsspeicher, der Metabasis.
Bei IIS 7.0 liest W3SVC die Konfigurationsinformationen nicht mehr aus dem Konfigurationsspeicher. Stattdessen liest WAS die Konfigurationsinformationen aus dem IIS 7.0-Konfigurationsspeicher, 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 Arbeitsprozesse 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.
37
Das 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 beispielsweise die Kommunikation mit HTTP.sys und teilt dem WAS-Dienst über die Listeneradapterschnittstelle 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 Verwaltungsaufgaben 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 Arbeitsprozess. 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 Konfigurations- 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.
Konfigurationsspeicher
Bei 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.NETEinstellungen kombiniert.
Die verteilte Konfigurationshierarchie enthält die globalen, computerweit gültigen .NET FrameworkKonfigurationsdateien, machine.config und die web.config-Stammdatei, die globale IIS-Konfigurationsdatei 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
39
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 Anwendungsverwaltung 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 innerhalb des Konfigurationssystems von IIS 7.0 Konfigurationen lesen und schreiben. Die Konfigurationsdateien 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 featureorientierten 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 COMAPI, mit der die Konfiguration von einem C++-Programm aus verwaltet werden kann, und eine .NETAPI (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-Verwaltungsdienst), 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.
Arbeitsprozesse
Die Aufgabe eines Arbeitsprozesses besteht darin, Anforderungen zu verarbeiten. Ein Arbeitsprozess
ist ein in sich geschlossener, dauerhaft ausgeführter Benutzermodusprozess, der in Form einer ausfü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 Anwendungsgruppen 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.
41
Innerhalb eines Arbeitsprozesses stellen Anwendungsdomänen Anwendungsgrenzen für .NETAnwendungen 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.
Direkt von der Quelle: Anwendungspoolisolierung bei IIS 7.0
Das mit IIS 6.0 eingeführte Anwendungspooldesign bildete die Grundlage für eine höhere Sicherheit, 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 beibehalten, 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 Anwendungspoolisolation ü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 Anwendungspool 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 Leistungsverbesserungen, 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 Fehlerisolation 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
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 Anwendungspool konfigurieren, um festzulegen, in welchem der beiden Modi ASP.NET-Anforderungen ausgeführt
werden sollen. Im nächsten Abschnitt konzentrieren wir uns auf die Anforderungsverarbeitungsarchitektur innerhalb der Arbeitsprozesse, die die Anwendungspools bedienen.
Anforderungsverarbeitung im Anwendungspool
Bei 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, verarbeitete IIS 7.0 die ASP.NET-Anforderungen unter Verwendung der integrierten IIS- und ASP.NETAnforderungsverarbeitungspipeline. 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 verschiedene 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 konfigurieren, 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.
43
4. Wählen Sie im Dialogfeld Anwendungspool bearbeiten und dort im Dropdown-Listenfeld Verwalteter Pipelinemodus den gewünschten Modus (Integriert oder Klassisch) und klicken Sie auf OK.
Klassischer Modus
Der klassische Modus dient bei IIS 7.0 der Abwärtskompatibilität mit IIS 6.0. Wenn Sie einen Anwendungspool 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 Anforderungen bietet es leistungsfähige Features an, wie z.B. die Formularauthentifizierung und die Ausgabezwischenspeicherung 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 Serverpipelines, eine für native ISAPI-Filter- und -Erweiterungskomponenten und eine weitere für verwaltete
Anwendungskomponenten. ASP.NET-Komponenten werden vollständig innerhalb der ASP.NETISAPI-Erweiterung und ausschließlich für solche Anforderungen ausgeführt, die in der IIS-Skriptzuordnungskonfiguration ASP.NET zugeordnet sind. Anforderungen, die sich auf Nicht-ASP.NETInhalte beziehen, wie z.B. ASP-Seiten oder statische Dateien, werden von IIS oder anderen ISAPIErweiterungen 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
45
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.NETAnforderungen 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 Ablaufverfolgung und die Ausgabezwischenspeicherung.
ASP.NET-Anwendungen haben keinen Einfluss auf bestimmte Abschnitte der IIS-Anforderungsverarbeitung, 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 Anwendungspool 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-Modus
Wenn 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-Anforderungspipelines sind kombiniert, wodurch eine vereinheitlichte (also integrierte) Anforderungsverarbeitungspipeline 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 implementiert. 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 implementiert. Es gibt über vierzig separate systemeigene und verwaltete Module. Jedes Modul implementiert 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
47
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 Anforderungszustand 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 Formularauthentifizierung 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 Verfü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-Pipeline, um authentifiziert zu werden. Weitere vereinheitlichte IIS- und ASP.NET-Funktionen sind die
URL-Autorisierung, die Ablaufverfolgung, benutzerdefinierte Fehler und die Ausgabezwischenspeicherung.
49
Alle Module werden an einem Ort verwaltet, wodurch auf dem Server die Site- und Anwendungsverwaltung 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 Serverpipeline 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, »Verwalten von Webservermodulen«.
Implementierung der ASP.NET-Integration
Obwohl 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 IntegrationsWrapper 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 Ereignisbenachrichtigungen 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 funktionieren 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 Modulen
Module 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 Verfü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 Anwendungsebene 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 ModuleFeatures verwalten.
Hinweis Weitere Informationen zur Verwaltung von Modulen finden Sie im zwölften Kapitel.
51
Modulreihenfolge
Das 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 Anforderungsauthentifizierungsphase 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 Authentifizierungsmodule, die in der Anforderungsauthentifizierungsphase ausgeführt werden, sollten beispielsweise 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 Modulreihenfolge 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, »Reihenfolge der Module«.
Verarbeitung von Nicht-HTTP-Anforderungen
Bei IIS 7.0 unterstützt WAS Nicht-HTTP-Protokolle, so dass Sie IIS verwenden können, um Anwendungen 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 Aktivierung unterstützt und die Möglichkeit bietet, auf nur einem Computer eine große Anzahl von Anwendungen zu hosten. WCF (Windows Communication Foundation) wird mit Protokolladaptern ausgeliefert, 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 Funktionalität eines Protokolllisteners auf. Abbildung 2.14 zeigt WAS bei Listeneradaptern für Nicht-HTTPProtokolle.
Abbildung 2.14 Unterstützung von Nicht-HTTP-Protokollen bei WAS
Listeneradapter sind Windows-Dienste, die über bestimmte Netzwerkprotokolle Nachrichten empfangen und mit WAS kommunizieren, um eingehende Anforderungen an den richtigen Arbeitsprozess weiterzuleiten. Die Listeneradapterschnittstelle wird verwendet, um den Eingang von Aktivierungsanforderungen 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 NichtHTTP-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 Abbildung 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 Fehlererkennung 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.
Zusammenfassung
In 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 HTTPAnforderungen 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 HTTPAnforderungen ausführt und Antworten generiert
55
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 Anwendungsverwaltung 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-HTTPAnwendungen 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 Webservermodulen 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
Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hauptvorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integrierte Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
61
64
65
65
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 Komponentendesign 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.
Konzepte
Die komponentenbasierte Architektur ist eine der wichtigsten Änderungen, die an IIS 7.0 vorgenommen 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 Ideen
Ein 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 zusammengesetzt 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 Funktionalitäten, so dass Sie einen Webserver aufbauen können, der an die speziellen Bedürfnisse Ihres Unternehmens angepasst ist. Dieses neue und offene Design ist revolutionär für Microsoft und öffnet der
Webplattform ganz neue Türen.
So funktioniert es: Das modulare Design
IIS 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-Anforderungsverarbeitungspipeline 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 Ereignisbenachrichtigungen 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 Anforderungspipeline hinzufügen, in dieser ersetzen oder aus dieser entfernen können, wodurch die uneingeschränkte Erweiterbarkeit des IIS 7.0-Webservers gewährleistet ist.
Modultypen
IIS 7.0 wird mit ca. vierzig Modulen ausgeliefert, zu denen auch sicherheitsrelevante Authentifizierungsmodule 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
Konzepte
59
beispielsweise die Bereitstellung von statischen Dateien, ASP.NET-Seiten usw. Ungeachtet ihrer Aufgabenbereiche sind Module die wichtigsten Zutaten für IIS 7.0. Entwickler können zwei Arten von IISModulen 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 Anforderungen 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 Interface) 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 Anwendung zur Verfügung gestellt werden. Weitere Informationen zur Bereitstellung von Modulen erhalten
Sie im zwölften Kapitel.
Module und Konfiguration
Damit 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 Anwendungen 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 beispielsweise 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>
Hauptvorteile
Die 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.
Sicherheit
Fü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-Standardinstallation 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 Betriebssystems 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ärdateien, 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 Sicherheitsupdates 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 Angriffspunkte 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 Bearbeitung 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 installiert 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 Komponenten 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ärdateien 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 einheitliche 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 konfigurieren. 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 Welt
Als 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ückgegeben 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
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 geringstmöglichen Angriffsfläche entsteht.
Mike Volodarsky
Leistung
Aufgrund der aus Komponenten bestehenden Architektur können Sie mit IIS 7.0 den Speicherverbrauch 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-, Digestauthentifizierung usw.) in den Arbeitsprozess geladen. Bei IIS 7.0 werden nur die benötigten Authentifizierungsmodule geladen und in die Anforderungsverarbeitung eingebunden. Weitere Informationen zum
Entfernen von nicht benötigten Modulen finden Sie im zwölften Kapitel.
Erweiterbarkeit
Bei ä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-Standardauthentifizierungsfeatures 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 Lastenausgleichsalgorithmus 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.
Integrierte Module
Module, 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 Definitionen 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, Laufzeitinformationen abzufragen. Dazu zählen beispielsweise die gegenwärtig ausgeführten Anforderungen, 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 TRACEund 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 Authentifizierungschemata (anonyme Authentifizierung, Standardauthentifizierung und IIS-Clientzertifikatauthentifizierung)
System.Web.Caching.OutputCacheModule (ManagedEngine)
Definiert die Ausgabezwischenspeicherungsrichtlinien einer ASP.NET-Seite oder eines Benutzersteuerelements, 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 leistungsfähiger Satz Sicherheitsregeln implementiert, um verdächtige Anforderungen in einer sehr
frühen Phase abzuweisen.
65
Tabelle 3.1 Modulkategorien (Fortsetzung)
Kategorie
Modul
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
Weitere Informationen zum Modulkonfigurationsspeicher sowie zu Modulabhängigkeiten und potentiellen Problemen beim Entfernen eines Moduls finden Sie in Anhang C.
Zusammenfassung
Die wichtigsten von IIS 7.0 angebotenen Features stammen aus seinem modularen Design. Webadministratoren haben zum ersten Mal die volle Kontrolle über den IIS-Server. Es ist außerdem die erste IISVersion, die vollständig erweiterbar ist. Sie definiert ein vereinheitlichtes Anforderungsverarbeitungsmodell, 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 Speicherverbrauch 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 Funktionsweise. 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.
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
Übersicht über das Konfigurationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
Konfigurationsbearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
Konfigurationsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Weitere Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Auf der Begleit-CD
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 Konfiguration, die ASP.NET-Integration, die xcopy-Bereitstellung der Konfiguration und viele andere Leistungsmerkmale.
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-Konfigurationssystem 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 zusammengesetzt, 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 Konfigurationssystem
Das IIS 7.0-Konfigurationssystem weist in vielerlei Hinsicht große Unterschiede zum Konfigurationsmodell älterer IIS-Versionen – die Metabasis – auf. Die neue Architektur berücksichtigt die Anforderungen, 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-Konfigurationssystem 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
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.
Konfigurationsdateihierarchie
Die 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 Konfiguration 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-Konfigurationsdateihierarchie 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 zugeordnet 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 URLNamespace 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 physikalischen 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 verwechselt werden, die im Stammverzeichnis einer Website angeordnet ist und oft als Webstamm bezeichnet wird. Im ersten Fall ist die web.config-Datei gemeint, die von .NET verwendet wird und der Parent oder Stamm der web.configDateien 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 applicationHost.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 Abschnitte, 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 Anwendung 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
71
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-Stammdatei
Obwohl 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-Konfiguration 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 Framework-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 Computeradministratoren 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 Konfigurationsdateien 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.
Die IIS-Hauptkonfigurationsdatei ist applicationHost.config, die sich im Verzeichnis %windir%\system32\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 Anwendungspooldefinitionen. 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-Konfigurationsabschnitte, 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"
<section name="webLimits" allowDefinition="AppHostOnly"
…
</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 untergeordneten Ebenen (Childebenen) wird wie im vorherigen Beispiel gezeigt mit dem overrideModeDefaultAttribut 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-Dateien
Die IIS 7.0-Konfigurationshierarchie trägt dazu bei, dass die Siteverzeichnisstruktur web.configKonfigurationsdateien 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 IISals auch ASP.NET-Konfigurationseinstellungen enthalten.
redirection.config
Sie 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«.
73
administration.config
Nur der IIS-Manager nutzt administration.config (ebenfalls nicht Bestandteil der IIS 7.0-Konfigurationshierarchie), 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 IISManager-Erweiterungen. Diese Erweiterungen stellen die Features zur Verfügung, die Sie im IISManager 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 Anwendungspools
Eines 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 jeweiligen 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«.
Konfigurationsdateisyntax
Jede Konfigurationsdatei verwendet spezielle XML-Elemente, um Konfigurationsinformationen
anzugeben. Diese Elemente werden als Konfigurationsabschnitte bezeichnet. Ein Konfigurationsabschnitt 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 Konfigurationsabschnitte angibt:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<asp>
<cache diskTemplateCacheDirectory="%SystemDrive%\inetpub\temp\
ASP Compiled Templates" />
</asp>
<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-Konfigurationssystem, das Code benutzt, um die Struktur seiner Konfiguration zu definieren, basiert das IIS 7.0Konfigurationssystem 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 Konfigurationsdateien 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 umgehen
Das 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.configDateien 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 WindowsRegistrierung einen Schlüssel hinzufügen. Erzeugen Sie den folgenden Schlüssel:
HKLM\Software\Microsoft\InetStp\Configuration
75
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.
Abschnittsdeklarationen
Jeder 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-Konfigurationsdatei aufgeführt, der alle IIS-Konfigurationsabschnitte deklariert:
<configSections>
<sectionGroup name="system.applicationHost">
<section name="applicationPools" allowDefinition="AppHostOnly"
<section name="sites" allowDefinition="AppHostOnly"
</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 Webserverfeatures, 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 applicationHost.config deklariert und somit in jeder web.config-Konfigurationsdatei einer Website verfügbar.
Die Attribute allowDefinition und overrideModeDefault kontrollieren die Möglichkeit, diese Konfigurationsabschnitte auf den unteren Ebenen zu verwenden.
Abschnittsgruppen
Sie 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 Abschnittsgruppen 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 Abschnittsgruppenelementen 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-Konfigurationssystem 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, einschließlich <sites>, <applicationPools>, <listenerAdapters> usw.
system.webServer
Enthält alle Konfigurationen für die IIS-Webserverengine und
-features, einschließlich <modules>, <handlers>, <serverRuntime>, <asp>, <defaultDocument> und viele weitere; enthält
außerdem mehrere untergeordnete (Child) Abschnittsgruppen
system.webServer /security
Enthält sicherheitsbezogene Webserverkonfigurationen, einapplicationHost.config
schließlich <authorization>, <isapiCgiRestriction>, <requestFiltering> und weitere
system.webServer /security /
authentication
Enthält Konfigurationen für alle Webserverfeatures, die sich
auf die Authentifizierung beziehen, einschließlich <anonymousAuthentication>, <windowsAuthentication> und weitere
77
Tabelle 4.2 Abschnittsgruppen (Fortsetzung)
Abschnittsgruppen
Beschreibung
Deklariert in
system.webServer /tracing
Enthält Konfigurationen für Webserverfeatures, die sich auf
die Ablaufverfolgung beziehen, einschließlich <traceFailedRequests> und <traceProviderDefinitions>
system.web
Enthält alle ASP.NET-Konfigurationen
Framework machine.config
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 FrameworkVerhaltens. Zu ihnen zählen system.net, system.xml.serialization usw.
Abschnitte
Der Abschnitt configuration ist der Mittelpunkt des IIS 7.0-Konfigurationssystems, da er die grundlegende 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.
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 Auflistungselemente hinzugefügt werden, wenn die Auflistungen verschiedener Konfigurationsdateien miteinander verbunden werden usw.
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
Instanzen dieses Abschnitts zusammenfügt, wenn es diesen Abschnitt für einen bestimmten Konfigurationspfad abruft. Das Zusammenfügen von Attributen führt dazu, dass die in den höheren Konfigurationsebenen 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 Stammverzeichnis 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>
<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.
Konfigurationsabschnittsschema
Alle 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>
79
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-Schemadateien zu modifizieren. Wenn Sie aber neue IIS-Features entwickeln, können Sie benutzerdefinierte Konfigurationsschemadateien 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-Tags
Eine 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 Konfiguration, 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 URLNamespace 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 verwenden, ohne diese Konfiguration in der web.config-Datei der Site zu definieren. Dies ist beispielsweise das Verfahren, das üblicherweise von Shared-Hostingsservern genutzt wird, um sitespezifische Konfigurationen festzulegen, über die der Siteadministrator keine Kontrolle haben soll. Wenn
im IIS-Manager oder mit einer der programmgesteuerten Schnittstellen Änderungen an der Konfiguration 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 Konfigurationspfad. 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 diesen Konfigurationsabschnitt für diesen Pfad zu sperren oder wieder freizugeben. Dies ist beispielsweise 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 Verzeichnis 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 Anwendung 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-Metabasis
Bisher 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-Metabasis
Der 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.
81
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 Administrator kontrollierte Konfiguration
in applicationHost.config als auch
die delegierte Konfiguration in
web.config-Dateien sind möglich
Administratoren können Konfigurationsaufgaben an Anwendungsbesitzer 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 Verwendung kürzerer Elementnamen,
da alle Einträge in Abschnitten
logisch gruppiert sind und nicht
einfach nur aufgelistet werden
Vereinfachte Beschreibung Verwendet Multi-SZSchlüsseltypen und Bitvon Eigenschaften mit
masken, um mit mehreren
mehreren Werten
Elementwerten, wie z.B.
AuthenticationProviders
(NT) umgehen zu können
Verwendet Auflistungen mit einer
einfachen add/remove/clear-Syntax, die auf der .NET FrameworkKonfigurationssyntax und -verwendung 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; Synchronisierungsprobleme können auftreten
Die Konfiguration ist dateibasiert; Die IIS-Konfiguration ist immer vollKonfigurationsänderungen werden ständig in .config-Dateien abgebildet
direkt in die Konfigurationsdateien
übernommen
Schemaerweiterbarkeit
Für benutzerdefinierte
Anwendungen schwierig
zu erweitern; verhindert
Innovationen von Seiten
der Community
Basiert auf IIS_Schema.xml;
Anwendungsentwickler können
das Schema kann einfach mithilfe Anwendungseinstellungen einfacher
von XML erweitert werden
in IIS 7.0 integrieren
Kompatibilität mit der IIS 6.0-Metabasis
Trotz der umfassenden Überarbeitung des Konfigurationssystems ist IIS 7.0 auch weiterhin abwärtskompatibel 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 ABOSchnittstellen (Active Base Objects) offen gelegten Metabasis-APIs ermöglicht, auf denen alle anderen
Metabasistools und -Scripting-APIs basieren. Die Metabasisemulationsschicht, die auch als ABOMapper 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.
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 entsprechenden IIS 7.0-Konfigurationseigenschaften zuzuordnen. Letztendlich können fast alle Metabasiseigenschaften 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-Metabasiseigenschaften 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 WindowsFunktionen ein- oder ausschalten aus. Dort befindet sie sich in der Kategorie IIS/Metabasiskompatibilitä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-Metabasiskompatibilitä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.
83
IIS 7.0 und die .NET-Konfigurationssysteme
Die .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 .NETKonfigurationssystem gar nicht, dass es unter IIS 7.0 ausgeführt wird, und es liest auch keine der IIS 7.0Konfigurationseinstellungen. IIS 7.0 hingegen ist sich der Anwesenheit von .NET bewusst. Die IIS 7.0Konfigurationshierarchie 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 gespeichert 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 .NETKlassen genauso auf die .NET-Konfiguration zugreifen, wie sie dies mit den IIS 7.0-Konfigurationsabschnitten 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 .NETKonfigurationsabschnitte 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 IISManager«, 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 Konfigurationsabschnitten arbeiten. Die Tatsache, dass das ASP.NET-Konfigurationssystem keine IIS 7.0-Konfigurationsabschnitte 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üsselungsverfahren 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-Konfigurationsschemadateien, 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 Konfiguration 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öglicherweise 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-Konfigurationsabschnitte bewusst ist, die sich in der Abschnittsgruppe <system.webServer> befinden (oder in benutzerdefinierten 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.
Konfigurationsbearbeitung
Das IIS 7.0-Konfigurationssystem ist sehr flexibel, wenn es um die Bearbeitung der Serverkonfiguration 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 Verzeichnisstruktur einer Site befinden.
Zusätzlich zur manuellen Konfigurationsbearbeitung bietet IIS 7.0 einen vollständigen Verwaltungsstack an, der Tools und APIs für die Bearbeitung von Konfigurationen bereithält. Dazu zählt der IISManager, ein gänzlich überarbeitetes, aufgabenbasiertes Programm mit einer grafischen Benutzeroberflä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 Anwendungshostverwaltungsobjekte oder AHADMIN [Application Host Administration] bezeichnet), Windows-Skripts, eines
WMI-Anbieters und neuer APIs für die von .NET-Programmen ausgehende Verwaltung der
Konfiguration.
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.0Features 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 Konfigurationsfunktionalität nicht anbietet, Appcmd zur Konfigurationsbearbeitung. Appcmd beherrscht die meisten Konfigurationsaufgaben, 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 anderen 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 Konfigurationsorts
In diesem Kapitel wurde bereits die IIS 7.0-Konfigurationshierarchie beschrieben. Diese Hierarchie
besteht aus mehreren Konfigurationsdateien, zu denen die .NET-Konfigurationsdateien, applicationHost.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 Konfiguration für eine bestimmte Website oder einen bestimmten URL liest, fügt er alle Konfigurationsdateien 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.
Tabelle 4.5 Ablageorte für Konfigurationen
Konfiguration für
Ablegen in
den gesamten Server
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
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 verwahren, 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 Konfigurationspfades 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 standardmäß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 Konfiguration 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 festlegen
Um 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
87
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 Konfigurationsdatei sein. Beachten Sie ebenfalls das Element <system.webServer> – dies ist das Abschnittsgruppenelement
des hier konfigurierten <defaultDocument>-Abschnitts (und aller anderen IIS 7.0-Konfigurationseinstellungen).
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 Standarddokumentfeature ein oder aus und geben die Liste der Standarddokumente mithilfe der Attribute oder
Auflistungselemente an, die dem Abschnitt zugeordnet sind.
Abschnittsattribute festlegen
Die 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 Konfigurationsauflistungen
Zusätzlich zu Attributen können Konfigurationsabschnitte ebenfalls Auflistungen enthalten. Auflistungen 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:
<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.0Konfigurationsschemas. 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 Verzeichnisses spezifische Standarddokumente hinzuzufügen.
89
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 IISAbschnitt <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 hinzugefü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 identifiziert. 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 Auflistungselemente 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 Auflistungselemente, 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 übergeordneten 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 verstehen
Im 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 abgefangen, 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 Konfigurationssicherung.
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 Konfigurationssystem 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-Arbeitsprozessverwaltung (der Windows-Prozessaktivierungsdienst) gelesen wird, wird der gesamte Server in den
Offline-Zustand versetzt. In diesem Fall erhalten Sie keine detaillierte Anforderungsfehlermeldung, die
91
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.
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.configStammdatei 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.configStammdatei 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.applicationHost-Konfigurationsabschnitte befindet, kann der Server in den OfflineZustand 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 unzulä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 übergeordneten Ebene gesperrt ist
Wie oben
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 protokolliert werden. Wenn sich der Fehler in einem der bei jeder Anforderung gelesenen IIS-Kernkonfigurationsabschnitte befindet, z.B. <serverRuntime>, <modules> und <handlers>, geben alle Anforderungen, die sich
auf den der unzulässigen Konfiguration entsprechenden URL-Namespace beziehen, Konfigurations-
fehler zurück. Diese Fehler geben exakt Aufschluss über den Grund für den fehlgeschlagenen Konfigurationszugriff. 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 Informationen 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
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.
Je länger Sie mit der IIS-Konfiguration arbeiten, desto wahrscheinlicher ist es, dass Sie viele verschiedene 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 XMLKonfigurationsdateien 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ücklicherweise sorgt IIS dafür, dass dies sehr einfach ist.
In diesem Abschnitt untersuchen wir die Verwaltungsaufgaben, die sich auf das Sichern und Wiederherstellen 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 Konfiguration
Bevor 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 Befehlszeilenhilfsmittel 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 auflisten.
%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 Sicherungsverzeichnis befinden. Es ist nicht sicher, sie ohne zusätzlichen Schutz an einem anderen Ort
abzulegen.
Arbeiten mit dem Konfigurationsverlauf
IIS 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 Konfigurationsabschnitt <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
95
Tabelle 4.7 <configHistory>-Attribute (Fortsetzung)
Attribut
Standardeinstellung
Definition
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
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 Benutzeroberflä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 Konfigurationen
Die 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 Zielserver ü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.
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üsselungsschlüsseln.
Wenn Ihre Konfigurationsdateien verschlüsselte Informationen enthalten, zum Beispiel AnwendungspoolIDs, sind sie an den Server gebunden, auf dem die Verschlüsselung generiert wurde. Sie können die Konfigurationsschlü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 Konfigurationen 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.
Konfigurationsdelegierung
Das 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öglichkeit, 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 Serveradministrator 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 festgelegt 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.
97
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 Verfügung, die notwendig sind, um die Remoteverwaltung nahtlos in dieses Tool zu integrieren. Die Verwaltung der Featuredelegierung mithilfe des IIS-Managers hat den Vorteil, dass die korrekte Konfiguration der Delegierung immer gewährleistet ist. Der IIS-Manager berücksichtigt die Delegierungseinstellungen, 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.NETEinstellungen 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 hochgeladen 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 Siteoder 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 applicationHost.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-Manager
Lassen Sie uns die verschiedenen Einstellungen im IIS-Manager untersuchen, die sich auf die Delegierung beziehen. Abbildung 4.5 zeigt, was Sie sehen, wenn Sie im Hierarchielistenfeld den Serverknoten 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 Hierarchielistenfeld das Serversymbol markiert ist) an dem Feature vornehmen, in applicationHost.config
gespeichert. Änderungen auf der Site- oder Anwendungsebene können nur vom Serveradministrator 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 entsprechende 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 Anwendungsebene vornehmen, werden in der entsprechenden web.config-Datei gespeichert. (Eine Referenzierung 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 Delegierungswerte 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 Konfiguration
Wie bereits erwähnt wurde, werden bei IIS 7.0 einige Einstellungen standardmäßig delegiert, wohingegen 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 Standardeinstellungen vielleicht zu anderen Entscheidungen als das IIS-Team gelangen. Die globalen Einstellungen sind jedoch gut durchdacht, weshalb Sie daran keine Änderungen vornehmen sollten, sofern Sie
nicht einen guten Grund hierfür haben.
99
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.NETKompilierung fest, wie z.B. das temporäre Kompilierungsverzeichnis
Verhindert, dass Benutzer das temporäre Kompilierungsverzeichnis
manuell festlegen
.NET-Globalisierung
Lesen/Schreiben
Legt Einstellungen für die Standardkultur und Globalisierungseigenschaften 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-Benutzern und der Formularauthentifizierung verwendet werden
.NET-Vertrauensebenen
Schreibgeschützt
(wurde geändert,
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 Sicherheitskontext 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
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
Tabelle 4.8 Feature- und Delegierungseinstellungen (Fortsetzung)
Feature
Delegierte Einstellung
Grund
Standarddokument
Lesen/Schreiben
Legt die Standarddokumente einer Website fest
Wenn 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
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 Anforderungen fest. Ermöglicht es den Benutzern, Regeln für die Ablaufverfolgung 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,
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 hinzugefü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 Anwendungsdienste fest, wie z.B. für den Anzeigezustand, die Formularauthentifizierung 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 Formularauthentifizierungscookies 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
101
Direkte Konfiguration der Delegierung
Mit 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-ManagerDelegierungsstatus auswählen, werden ebenfalls die erforderlichen Konfigurationsdelegierungseinstellungen generiert, die kontrollieren, ob die entsprechenden Konfigurationsabschnitte auf der Siteoder 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 IISManager-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-Konfigurationsabschnitte, 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 durchdacht. 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 Konfigurationsabschnitts 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 applicationHost.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 Remoteverwaltung
Damit 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 Konfigurationssperrung
Bisher 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 Featuredelegierung 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.
103
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.
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
lockAttributes, lockAllAttributesExcept
Die 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="index.htm" />
<add value="iisstart.htm" />
</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.
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, lockAllElementsExcept
Die 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>-Auflistung des <defaultDocument>-Abschnitts angegeben wird. Auf diese Weise wird vermieden, dass
niedrigere Konfigurationsebenen den Inhalt der Standarddokumentliste ändern.
<defaultDocument enabled="true" lockElements="files" >
<files>
</files>
</defaultDocument>
105
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.
lockItem
Die 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 Standardseitenliste 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.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.configDatei 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 Server
Ein ganz neues Feature von IIS 7.0 ist die Möglichkeit, dass mehrere Webserver eine einzelne Konfigurationsdatei gemeinsam nutzen. Dieses Feature wurde mit Blick auf Webfarmen für den Lastenausgleich 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 Notwendigkeit, Anwendungsinhalte und lokale Komponenten – wie SSL-Zertifikate oder im globalen Assemblycache registrierte .NET-Assemblys – zu synchronisieren, nicht entfällt.
Die freigegebene Konfiguration aktivieren
Sie 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
107
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 entscheiden würden.
Funktionsweise der freigegebenen Konfiguration
Die 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 Konfiguration
Der 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 ausgestattet 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 freigegebenen 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änenbenutzer, 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 Freigabeberechtigungen. 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 Konfiguration 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 exportieren
1. Markieren Sie im IIS-Manager den Serverknoten und führen Sie einen Doppelklick auf dem Symbol 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 Anmeldeinformationen 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.
109
5. Geben Sie unter Verschlüsselungsschlüssel ein Kennwort ein, das für den Schutz exportierter Verschlüsselungsschlüssel verwendet wird, wenn diese den Server verlassen. Sie müssen dieses Kennwort 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 Konfigurationsdateien 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 aktivieren
Sie 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 automatisch zu beginnen. Es ist sogar so, dass, wenn Sie an diesem Punkt Änderungen an der IIS 7.0Konfiguration 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 Konfiguration 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 Kennwort 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 entschlüsselt werden.
4. Klicken Sie auf OK, um das Meldungsdialogfeld zu schließen. Daraufhin wird eine weitere Meldung 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 Konfigurationsdateien 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 Konfiguration
Die freigegebene Konfiguration hilft, den administrativen Aufwand zu verringern, der mit dem Replizieren 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 SSLZertifikaten, zur Wiederverwendung von Diensten, zu Betriebssystemupdates, zur Registrieren von
COM-Objekten, zum Platzieren neuer Inhalte im globalen .NET-Assemblycache, zur Netzwerkkonfiguration 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 Anwendungspools 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.
Zusammenfassung
Das IIS 7.0-Konfigurationssystem ist die Basis für viele wichtige Bereitstellungs- und Verwaltungsfunktionen des Servers. Es ermöglicht zum ersten Mal Szenarien wie die delegierte Konfigurationsverwaltung, 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 Webfarm.
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-Konfigurationssystem 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.0Konfigurationsschema 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-IIS7Configuration-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
Planen der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nach der Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behandlung von Installationsproblemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IIS 7.0 entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auf der Begleit-CD
115
137
140
142
145
146
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 ServerManager 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 Installation
IIS 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 Standardinstallation 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 Verwendung 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. ServerManagerCMD ist als globales Tool vorgesehen, das auf der Serverebene verwendet wird. ServerManagerCMD 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 ServerManager müssen Sie bei der Arbeit mit dem Paketmanager jedoch die Module und deren Abhängigkeiten 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 Installationsvorgang 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 ServerManagerCMD 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 CoreComputern 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 ServerManagerCMD 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«.
117
Installationsszenarien für IIS 7.0
Ein bei Windows Server 2008 neues Konzept sind Setups, die sich nach dem späteren Arbeitsschwerpunkt 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 Setupoptionen 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 HTMLDateien, 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 Durchführung von Paketmanager-Installationen verwendet werden.
Tabelle 5.1 Installationskomponenten für den Standardserver
Server-Manager
Updatename
Statischer Inhalt
IIS-StaticContent
Standarddokument
IIS-DefaultDocument
IIS-DirectoryBrowsing
HTTP-Fehler
IIS-HttpErrors
IIS-HttpLogging
IIS-LoggingLibraries
IIS-RequestMonitor
IIS-RequestFiltering
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 ausschließlich statische Inhalte bereitstellen soll, benutzen Sie im Fenster der Eingabeaufforderung den
folgenden Befehl:
ServerManagerCMD.exe –install Web-Server
ASP.NET
Der Microsoft ASP.NET-Webserver ist wahrscheinlich der am meisten verwendete Arbeitsschwerpunktserver. 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.NETSchwerpunktserver konfigurieren. Die Tabelle enthält auch die entsprechenden Updatenamen.
Tabelle 5.2 Installationsoptionen für den ASP.NET-Schwerpunktserver
Server-Manager
Updatename
Statischer Inhalt
IIS-StaticContent
Standarddokument
IIS-DefaultDocument
HTTP-Fehler
IIS-HttpErrors
IIS-HttpLogging
IIS-RequestMonitor
ASP.NET
IIS-ASPNET
IIS-NetFxExtensibility
ISAPI
IIS-ISAPIFilter
ISAPI-Erweiterungen
IIS-ISAPIExtensions
119
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;
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
-install
-install
-install
-install
-install
Web-Server
Web-ASP-NET
Web-NET-Ext
Web-Filtering
Web-ISAPI-Filter
Web-ISAPI-Ext
Klassisches ASP
Bevor Microsoft ASP.NET veröffentlichte, war klassisches ASP die Programmiersprache, die hauptsä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-Schwerpunktserver.
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
Server-Manager
Updatename
Statischer Inhalt
IIS-StaticContent
Standarddokument
IIS-DefaultDocument
HTTP-Fehler
IIS-HttpErrors
IIS-HttpLogging
IIS-RequestMonitor
Tabelle 5.3 Installationsoptionen für den klassischen ASP-Schwerpunktserver (Fortsetzung)
Server-Manager
Updatename
ASP
IIS-ASP
ISAPI-Erweiterungen
IIS-ISAPI-Extensions
Um mithilfe des Paketmanagers die IIS-Features für den klassischen ASP-Schwerpunktwebserver zu
IIS-ASP;IIS-ISAPIExtensions;IIS-HealthAndDiagnostics;
IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;
IIS-Security;IIS-RequestFiltering;IIS-HttpCompressionStatic;
Um mithilfe von ServerManagerCMD die IIS-Features für den klassischen ASP-Schwerpunktwebserver zu installieren, benutzen Sie im Fenster der Eingabeaufforderung den folgenden Befehl:
-install
-install
-install
-install
Web-Server
Web-ASP
Web-Filtering
Web-ISAPI-Ext
FastCGI-Schwerpunktserver
FastCGI 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 Webserverplattform 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 FastCGISchwerpunktserver konfigurieren. Die Tabelle enthält auch die entsprechenden Updatenamen.
Tabelle 5.4 Installationsoptionen für einen FastCGI-Schwerpunktserver
Server-Manager
Updatename
Statischer Inhalt
IIS-StaticContent
Standarddokument
IIS-DefaultDocument
121
Tabelle 5.4 Installationsoptionen für einen FastCGI-Schwerpunktserver (Fortsetzung)
Server-Manager
Updatename
HTTP-Fehler
IIS-HttpErrors
IIS-HttpLogging
IIS-RequestMonitor
CGI
IIS-CGI
Um mithilfe des Paketmanagers die IIS-Features für einen FastCGI-Schwerpunktserver zu installieren,
IIS-CGI;IIS-HealthAndDiagnostics;IIS-HttpLogging;
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-Erweiterbarkeit
Es 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 Schwerpunktserver für verwaltete IIS-Module und die .NET-Erweiterbarkeit konfigurieren. Die Tabelle enthält auch
die entsprechenden Updatenamen.
Tabelle 5.5 Installationsoptionen für Server, die verwaltete IIS-Module und die .NET-Erweiterbarkeit nutzen
Server-Manager
Updatename
Statischer Inhalt
IIS-StaticContent
Standarddokument
IIS-DefaultDocument
HTTP-Fehler
IIS-HttpErrors
IIS-HttpLogging
IIS-RequestMonitor
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:
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 Eingabeaufforderung den folgenden Befehl:
ServerManagerCmd.exe -install Web-Server
ServerManagerCmd.exe -install Web-Net-Ext
Vollständige IIS-Installation
Wenn 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 Entwicklungsumgebung 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 Produktionsservers nicht zu groß wird, was wiederum eine größere Sicherheit zur Folge hat. Je weniger Module Sie
123
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
Server-Manager
Updatename
Internet Information Services
IIS-WebServerRole
World Wide Web Services
IIS-WebServer
IIS-CommonHttpFeatures
Statischer Inhalt
IIS-StaticContent
Standarddokument
IIS-DefaultDocument
HTTP-Fehler
IIS-HttpErrors
HTTP-Umleitung
IIS-HttpRedirect
IIS-ApplicationDevelopment
ASP.NET
IIS-ASPNET
ASP
IIS-ASP
CGI
IIS-CGI
ISAPI-Erweiterungen
IIS-ISAPIExtensions
ISAPI-Filter
IIS-ISAPIFilter
IIS-ServerSideInclude
IIS-HealthAndDiagnostics
IIS-HTTPLogging
IIS-RequestMonitor
Ablaufverfolgung
IIS-HttpTracing
IIS-CustomLogging
IIS-ODBCLogging
Sicherheit
IIS-Security
IIS-BasicAuthentication
IIS-WindowsAuthentication
Digestauthentifizierung.
IIS-DigestAuthentication
IIS-ClientCertificateMappingAuthentication
Tabelle 5.6 Komponenten für eine vollständige Serverinstallation (Fortsetzung)
Server-Manager
Updatename
IIS-IISCertificateMappingAuthentication
URL-Autorisierung
IIS-URLAuthorization
IIS-IPSecurity
Leistung
IIS-Performance
IIS-HttpCompressionDynamic
Verwaltungstools
IIS-WebServerManagementTools
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
IIS-FTPManagement
WAS-WindowsActivationService
Prozessmodell
WAS-ProcessModel
.NET-Umgebung
WAS-NetFxEnvironment
Konfigurations-APIs
WAS-ConfigurationAPI
Um mithilfe des Paketmanagers die IIS-Features für eine vollständige Serverinstallation zu installieren,
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;
125
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;
Um mithilfe von ServerManagerCMD die IIS-Features für eine vollständige Serverinstallation zu
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
Server-Manager
Updatename
Web-Common-Http
Statischer Inhalt
Web-Static-Content
Standarddokument
Web-Default-Doc
Web-Dir-Browsing
HTTP-Fehler
Web-Http-Errors
HTTP-Umleitung
Web-Http-Redirect
Web-App-Dev
ASP.NET
Web-Asp-Net
Web-Net-Ext
ASP
Web-ASP
CGI
Web-CGI
ISAPI-Erweiterungen
Web-ISAPI-Ext
ISAPI-Filter
Web-ISAPI-Filter
Web-Includes
Web-Health
Web-Http-Logging
Web-Log-Libraries
Web-Request-Monitor
Ablaufverfolgung
Web-Http-Tracing
Web-Custom-Logging
Web-ODBC-Logging
Sicherheit
Web-Security
Tabelle 5.7 Vollständige Liste der ServerManagerCMD-Updatenamen (Fortsetzung)
Server-Manager
Updatename
Web-Basic-Auth
Web-Windows-Auth
Digestauthentifizierung
Web-Digest-Auth
Web-Client-Auth
Web-Cert-Auth
URL-Autorisierung
Web-Url-Auth
Web-Filtering
Web-IP-Security
Leistung
Web-Performance
Web-Stat-Compression
Web-Dyn-Compression
Verwaltungstools
Web-Mgmt-Tools
Web-Mgmt-Console
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
Web-Ftp-Mgmt-Console
WAS
Prozessmodell
WAS-Process-Model
.NET-Umgebung
WAS-NET-Environment
Konfigurations-APIs
WAS-Config-APIs
Server Core Web Edition-Schwerpunktserver
Mit Windows Server 2008 wurde Server Core eingeführt, ein vollständiges Befehlszeilen-ShellBetriebssystem.
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.
127
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.0Hosting 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 AnonymousAuthenticationModule. Das folgende Beispiel zeigt die Leistungsfähigkeit und Flexibilität der modularen IIS 7.0Architektur.
Installieren von IIS 7.0 unter Server Core Web Edition
Um 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 konfigurieren. 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 Eingabeaufforderung 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\ApplicationHost.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://<IPAdresseVonServerCore>/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 IISStandardprotokollen 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 Wiederherstellungsbefehl nur dann geben, wenn Probleme auftreten oder Sie wie in diesem Beispiel den Server in den
ursprünglichen Zustand zurückversetzen möchten.
129
Durch die modulare Architektur von Windows Server 2008 ist es möglich, das Server-Setup anzupassen. 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/administeringiis7-on-server-core-installations-of-windows-server-2008.aspx.
Möglichkeiten der Installation von IIS 7.0
Server-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 Unternehmen einrichten, sollten Sie außerdem einige Alternativen kennen. Die folgenden Abschnitte enthalten wesentliche Hinweise und Tipps, die Sie berücksichtigen sollten, wenn Sie mit den verschiedenen Tools und Optionen für die IIS 7.0-Installation arbeiten.
Mit dem Server-Manager arbeiten
Bevor 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 Benutzerkontensteuerung 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 Benutzer
Stellen 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 installieren
Der 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 IISFeatures, 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 verwenden
Optionale 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 vollstä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 deinstallierende Updates festlegen, indem Sie diese durch Semikola voneinander trennen. Es muss mindestens ein Update-Name angegeben werden.
/n:{unattend XML} Gibt eine XML-Datei an, die Informationen zu einer unbeaufsichtigten Installation enthält. (Weitere Informationen zur Durchführung einer unbeaufsichtigten Installation erhalten Sie später in diesem Kapitel im Abschnitt »Antwortdateien für unbeaufsichtigte Installationen«.)
131
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 verwenden
Sie können ServerManagerCMD in Verbindung mit der Benutzeroberflächenversion des ServerManagers 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 verwenden:
ServerManagerCmd -install Web-Server
Sie können die Installationsaktionen außerdem in einem XML-Dokument wie dem folgenden vermerken (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 Komponenten 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>
<log.txt>]
-inputPath <answer.xml>
<log.txt>]
-help | -?
-version
133
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 Installationen
Die unter Windows Server 2008 und IIS 7.0 verwendeten Antwortdateien für unbeaufsichtigte Installationen liegen nun im Gegensatz zu früheren Windows-Versionen im XML-Format vor. Eine Antwortdatei 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 experimentieren, 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
135
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 PaketmanagerSyntax. 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-Zeichenfolge 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 Setupsystem
Sysprep wird seit Jahren verwendet, um Standardabbilddateien als Teil der Serverbereitstellung vorzubereiten. 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 unbeaufsichtigten 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 Automated 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 Computerschlü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 Umgebung bereitzustellen.
Automatische Installationen
Microsoft 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 Features
Die 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 Installationsarchitektur.
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
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 (ServerManager, 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 Mindestsatz 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 verschiedenen 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 Funktionalität zum Server sehr einfach ist.
Brett Hill
Sobald die Installation abgeschlossen ist, besteht eine Ihrer ersten Aufgaben darin, die Dateien applicationHost.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.
Ordner und Inhalte
Benutzen 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.0Features 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 FTPPublishingdienst
%SystemDrive%\inetpub\logs\failedreqlogfiles Speicherort für alle Ereignisablaufverfolgungen 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 ASPVorlagen 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 Kernkonfigurationsdatei. Dies ist die Hauptdatei, die die Metabasis von früheren IIS-Versionen ersetzt.
139
Registrierung
Die 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üsselwert aufführt, finden Sie unter http://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Discover-Installed-Components.
Dienste
Tabelle 5.8 ist eine Liste der Systemdienste, die während der Installation einer Webserverrolle installiert
werden, wenn alle Rollendienst ausgewählt 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 dieser Dienst beendet wird, werden keine Out-of-Process-Anforderungen verarbeitet.
IIS-Verwaltungsdienst
Ermöglicht diesem Server die Verwaltung von FTP-Metabasisdiensten. Wenn dieser Dienst beendet wird, kann der Server weder die Metabasis- noch FTP-Sites
ausführen.
Webverwaltungsdienst
Bietet Remote- und delegierte Verwaltungsfunktionen für Administratoren zur Verwaltung des Webservers, der Websites und der Anwendungen auf dem Computer
Windows-Prozessaktivierungsdienst (WAS)
Bietet Dienste zur Prozessaktivierung, Ressourcenverwaltung und Zustandsverwaltung 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
Überprüfung
Um 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 enthaltenen 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.
Webbenutzeroberfläche
IIS 7.0 verwendet einen vollständig neuen IIS-Manager. Diese Anwendung nutzt nur eine Benutzeroberflä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 IISManager«, hält weiterführende Informationen zur Arbeit mit dem IIS-Manager bereit.
Benutzer und Gruppen unter Windows Server 2008
Fü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 ACLInformationen (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 WindowsInstallation 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 Installationsproblemen
Der neue deklarative XML-Installationsprozess stellt umfassende und detaillierte Protokollinformationen 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«).
Ereignisprotokolle
Sie 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-Protokoll
Die neue auf verschiedenen Komponenten basierende Installation bietet eine umfassende und detaillierte 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 beschreibende 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 Protokollierungsoptionen
ServerManagerCMD 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;IISommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IISirectoryBrowsing;IIS-HttpErrors;IIS-HealthAndDiagnostics;IISttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security;IISequestFiltering;IIS-HttpCompressionStatic;IIS-WebServerManagementTools;
IS-ManagementConsole;WAS-WindowsActivationService;WAS-ProcessModel;WASetFxEnvironment;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 entfernen
Der 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 Vista
Um 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 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 deinstallierten 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 Befehlszeilenmethode
Sie können entweder den Paketmanager oder ServerManagerCMD benutzen, um die Webserverrolle zu
deinstallieren.
Den Paketmanager verwenden
Dieser 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 angegeben werden.
Zusammenfassung
145
Der folgende Paketmanagerbefehl deinstalliert alle Komponenten, die sich auf die Serverrolle Webserver (IIS) beziehen:
start /w pkgmgr.exe /uu:IIS-WebServerRole;IIS-WebServer;
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-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 verwenden
Sie können ebenfalls ServerManagerCMD benutzen, um die Webserverrolle zu deinstallieren. Verwenden 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
Zusammenfassung
Wir 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 Informationen 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/administeringiis7-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-onLonghorn-Server?Page=2.
147
T E I L
I I I
Verwaltung
In diesem Teil:
Verwenden von IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwenden von Befehlszeilentools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remoteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwalten von Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwalten von Anwendungen und Anwendungspools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hosting von Anwendungsentwicklungsframeworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwalten von Webservermodulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurations- und Benutzeroberflächenerweiterungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementieren von Sicherheitsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
149
183
221
249
279
309
349
401
427
149
K A P I T E L
6
Verwenden von IIS-Manager
Übersicht über den IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Den IIS-Manager starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Benutzeroberfläche des IIS-Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Features verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anpassung und Erweiterbarkeit des IIS 7.0-Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remoteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
149
152
153
171
177
180
181
182
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 aufgabenorientierte 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 IISManager 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-Manager
Der IIS-Manager ist ein Serververwaltungstool, das es Ihnen ermöglicht, mit nur einer Benutzeroberfläche IIS 7.0- und ASP.NET-Features zu konfigurieren. Sie können Systemzustands- und Diagnoseinformationen 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 aufgabenorientierten, sich intuitiv erschließenden Benutzeroberfläche zielt das Tool darauf ab, Verwaltungsaufgaben 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 Konfigurationseinstellungen. 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.0Verwaltungskonsole ist kein MMC-Snap-In, sondern eine benutzerfreundliche Windows FormsAnwendung, 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%\System32\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 delegierten Verwaltung bietet der IIS-Manager den Anwendungsbesitzern die Möglichkeit, ihre Anwendungen 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 verwalten, der diese Sites und Anwendungen hostet. Eine sichere Delegierung administrativer Verantwortlichkeiten kann dazu beitragen, dass ein Serveradministrator viel Zeit spart und dass Webverwaltungsengpä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. IISManager-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 Protokoll 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 IPAdressen 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 Konfigurationseinstellung 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 IISManager-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, administration.config, die das Hinzufügen von benutzerdefinierter Funktionalität ermöglicht. Alle hinzugefü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 starten
Sie 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 ausfü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
Der 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 IISManagers, 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-ManagerFensters 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 Konfigurationspfades betrachten und konfigurieren. Jedes IIS-Manager-Feature ist in der Regel einem Konfigurationsabschnitt zugeordnet, der das entsprechende Webserverfeature kontrolliert.
Die Ansicht Inhalt stellt die Inhalte, die sich auf den gegenwärtig ausgewählten Konfigurationspfad beziehen, schreibgeschützt dar. Wenn Sie die Ansicht Inhalt aktiviert haben und in der hierarchischen 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 Erscheinungsbild 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 Benutzeroberflä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 überzeugt gewesen waren, nicht so nützlich seien. Andere Features wiederum, die wir als nicht erforderlich 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.
155
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 entsprechenden 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 Ergebnisse der Untersuchungen zur Benutzerfreundlichkeit verbesserten sich umgehend, und den Benutzern 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 Designentscheidungen wieder und wieder zu überprüfen.
Senior Development Lead, IIS
Navigationsleiste
Die obere Leiste des IIS-Managers ist die Navigationsleiste, mit deren Hilfe Sie durch die Benutzeroberflä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 Benutzeroberflä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 innerhalb der Benutzeroberfläche ausgewählt ist.
Die Schaltfläche Beenden unterbricht die gegenwärtig innerhalb der Benutzeroberfläche ausgefü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 Verbindungen
Oben 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.
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 Anwendungsverbindung 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, markieren 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 erstellen
Um 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 vorangestellten 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 Benutzeranmeldeinformationen. 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.
157
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 erforderlichen 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. Serveradministratoren, Administratoren der Site, die der Anwendung übergordnet ist, und designierte Anwendungsadministratoren 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
Arbeitsbereich
Der 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 Abbildung 6.7 dargestellt.
Abbildung 6.7 Die Schaltflächen der Ansichten Features und Inhalt
159
Die Ansicht Features
Wenn 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.
Startseite
Wenn 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
Server, Site, Anwendung, virtuelles Verzeichnis, Ordner, Datei
.NET-Globalisierung
Konfiguriert Globalisierungseigenschaften für verwalteten Code
ASP.NET
.NET-Profil
Konfiguriert Optionen für das Feature ASP.NET
ASP.NET-Profil, das innerhalb von
ASP.NET-Anwendungen Benutzerinformationen überwacht
Site, Anwendung, virtual directory, Ordner, Datei
.NET-Rollen
Konfiguriert Rollen für das Feature
ASP.NET
ASP.NET-Rollen. Diese Rollen
können für .NET-Benutzer und die
Formularauthentifizierung verwendet
werden.
Sicherheit
Site, Anwendung, virtual directory, Ordner, Datei
Konfiguriert Vertrauensebenen für
verwaltete Module, Handler und
Anwendungen
ASP.NET
Sicherheit
.NET-Benutzer
Verwaltet Benutzer für das Feature
ASP.NET-Mitgliedschaft
ASP.NET
Sicherheit
Site, Anwendung, virtuelles
Verzeichnis, Ordner, Datei
Konfiguriert Name/Wert-Paare, die
zur Laufzeit von aus verwaltetem
Code bestehenden Anwendungen
verwendet werden können
ASP.NET
Authentifizierung
Konfiguriert Authentifizierungseinstellungen für Sites und Anwendungen
IIS
Sicherheit
Hinweis: Einige Optionen innerhalb des Authentifizierungsfeatures sind ausschließlich auf
der Serverebene verfügbar
Komprimierung
Konfiguriert Einstellungen für die
Komprimierung von Antworten
IIS
Leistung
Konfiguriert Zeichenfolgen, die von
ASP.NET
ASP.NET-Anwendungen verwendet
werden können, um Verbindungen zu
Datenquellen herzustellen
Server, Site, Anwendung,
virtuelles Verzeichnis, Ordner,
Datei
HTTP-Features
Server, Site, Anwendung,
virtuelles Verzeichnis, Ordner,
Datei
Standarddokument Konfiguriert Standarddateien, die
IIS
zurückgegeben werden, wenn Clients
den Verzeichnisstamm anfordern
161
Tabelle 6.1 Features des IIS-Managers (Fortsetzung)
Feature
Beschreibung
Verzeichnis
durchsuchen
Bereich
Kategorie
Gültigkeitsbereich
Legt fest, ob IIS eine Verzeichnisliste IIS
anzeigt, wenn Clients einen Verzeichnisstamm anfordern
HTTP-Features
Fehlerseiten
Konfiguriert Seiten, die beim Auftreten IIS
von HTTP-Fehlern zurückgegeben
werden
HTTP-Features
Ablaufverfolgung
für Anforderungsfehler
Konfiguriert die Protokollierung der
Ablaufverfolgung für Anforderungsfehler
Systemzustand
und Diagnose
Delegierung von
Features
Konfiguriert den StandarddelegieVerwaltung
rungsstatus für Features, die sich im
IIS-Manager auf niedrigeren Ebenen
befinden
Sicherheit
Stammknoten der Verbindung
(Server, Site, Anwendung)
Handlerzuordnungen
Legt Handler fest, die für Antworten
auf bestimmte Anforderungstypen
zuständig sind
Serverkomponenten
HTTP-Umleitung
IIS
Legt Regeln für das Umleiten von
eingehenden Anforderungen zu einer
anderen Datei oder einem anderen
URL fest
HTTP-Features
HTTP-Antwortheader
Konfiguriert HTTP-Header, die den
Antworten vom Webserver hinzugefügt werden
HTTP-Features
IIS-ManagerBerechtigungen
Konfiguriert Benutzer, die in Sites
Verwaltung
oder Anwendungen, für die sie die
entsprechenden Berechtigungen
besitzen, delegierte Features einrichten können
Sicherheit
Server
IIS-ManagerBenutzer
Verwaltet IIS-Manager-Benutzer
Sicherheit
Server
ISAPI- und CGIEinschränkungen
Schränkt bestimmte ISAPI-Erweite- IIS
rungen (Internet Server Application
Programming Interface) und CGIProgramme (Common Gateway Interface) auf dem Webserver ein oder
aktiviert diese
Sicherheit
Server
ISAPI-Filter
Legt ISAPI-Filter fest, die die IISFunktionalität modifizieren
Serverkomponenten
Server, Site
Protokollierung
Konfiguriert, wie IIS auf dem Webser- IIS
ver Anforderungen protokolliert
Systemzustand
und Diagnose
IIS
IIS
IIS
Verwaltung
IIS
Tabelle 6.1 Features des IIS-Managers (Fortsetzung)
Feature
Beschreibung
Kategorie
Gültigkeitsbereich
Computerschlüssel Konfiguriert Hashing- und Verschlüs- ASP.NET
selungseinstellungen für ASP.NETAnwendungsdienste, z. B. Anzeigezustand, Formularauthentifizierung,
Mitgliedschaft und Rollen und anonyme Authentifizierung
MIME-Typen
Konfiguriert DateinamenserweiteIIS
rungen und die damit verbundenen
Inhaltstypen, die als statische Dateien
bereitgestellt werden
HTTP-Features
Module
Konfiguiert Module für systemeigenen IIS
und verwalteten Code, die auf dem
Webserver Anforderungen verarbeiten
Serverkomponenten
Leistung
Ausgabezwischen- Legt Regeln für die Zwischenspeicherung
speicherung von Antwortinhalten im
Ausgabecache fest
Bereich
IIS
Seiten und
Steuerelemente
Konfiguriert Einstellungen für
ASP.NET
ASP.NET-Seiten und -Steuerelemente
Anbieter
Konfiguriert Anbieter für anbieterabhängige Anwendungsdienste
ASP.NET
Serverzertifikate
Anfordern und Verwalten von Zertifikaten für Websites, die SSL (Secure
Sockets Layer) verwenden
IIS
Sicherheit
Server
Sitzungszustand
Konfiguriert Sitzungszustandseinstellungen und Einstellungen für
Formularauthentifizierungscookies
ASP.NET
Server, Site, Anwendung, virtuelles 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 Webanwendungen heraus
ASP.NET
SSL-Einstellungen
Legt Anforderungen für SSL und
Clientzertifikate fest
IIS
Sicherheit
Site, Anwendung, virtuelles
Verzeichnis, Ordner, Datei
Arbeitsprozesse
Zeigt Informationen über ArbeitsIIS
prozesse und die darin ausgeführten
Anforderungen an
Systemzustand
und Diagnose
Server
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:
163
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 Hinzufü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):
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 beispielsweise die Ansicht Details für die Startseite einer Site, wobei sowohl ASP.NET- als auch IISGruppen nach Featurename sortiert sind.
165
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 IISManagers 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
Seitenlayouts
Die 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ügbaren Spaltenfiltern.
167
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 Eigenschaftenraster 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 Konfigurationsnamen 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
169
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 Inhalt
Wenn 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 Aktionen
Der Bereich Aktionen wird verwendet, um IIS-, ASP.NET- und IIS-Manager-Einstellungen zu konfigurieren. 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 verstehen
Die Features des IIS-Managers arbeiten mit den entsprechenden Konfigurationsabschnitten in der
.config-Dateihierarchie, um Daten daraus zu lesen oder darin zu schreiben. Das Feature Anwendungseinstellungen entspricht beispielsweise dem <appSettings>-Abschnitt in den web.config-Dateien, wohingegen 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 Modulen
Die Features des IIS-Managers und die entsprechenden Konfigurationsabschnitte in den .configDateien 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 Konfigurationsabschnitt 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 konfigurierte standardmäßige Rollenanbieter
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
basicAuthentication
BasicAuthenticationModule (authbas.dll)
[Authentifizierung] Digest
digestAuthentication
DigestAuthenticationModule (authmd5.dll)
[Authentifizierung] Formular
system.web/authentication
FormsAuthentication (System.Web.Security.
FormsAuthenticationModule)
[Athentifizierung] Windows
windowsAuthentication
WindowsAuthenticationModule (authsspi.dll)
appSettings
[ASP.NET-Anwendungscode]
ASP
system.webServer/asp (indirect)
IsapiModule (isapi.dll)
Autorisierungsregeln
authorization
UrlAuthorizationModule (urlauthz.dll)
CGI
system.webServer/cgi
CgiModule (cgi.dll)
Komprimierung
system.webServer/httpCompression
system.webServer/urlCompression
DynamicCompressionModule (compdyn.dll)
StaticCompressionModule (compstat.dll)
connectionStrings
[ASP.NET-Features und -Anwendungscode]
Features verstehen
173
Tabelle 6.2 Zuordnung von IIS-Manager-Features zur Konfiguration und zu Modulen (Fortsetzung)
Featurename
Verwendet von
Standarddokument
system.webServer/
defaultDocument
DefaultDocumentModule (defdoc.dll)
system.webServer/directoryBrowse
DirectoryListingModule (dirlist.dll)
Fehlerseiten
system.webServer/httpErrors
CustomErrorModule (custerr.dll)
Ablaufverfolgung für
Anforderungsfehler
system.webServer/tracing/
traceFailedRequests
system.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
isapiCgiRestriction
CgiModule (cgi.dll)
IsapiModule (isapi.dll)
ISAPI-Filter
system.webServer/isapiFilters
IsapiFilterModule (filter.dll)
Protokollierung
system.applicationHost/log
system.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/globalModules
system.webServer/modules
[IIS-Serverkern]
Ausgabezwischenspeicherung
system.webServer/caching
HttpCacheModule (cachhttp.dll)
Seiten und Steuerelemente
system.web/pages
[ASP.NET]
Anbieter
system.web/membership
system.web/roleManager
system.web/profile
[Features für ASP.NET-Rollen, -Mitgliedschaft
und -Profile]
Serverzertifikate
[Local Machine Certificate Store]
[Betriebssystem, HTTP.SYS, WindowsAnwendungen]
Tabelle 6.2 Zuordnung von IIS-Manager-Features zur Konfiguration und zu Modulen (Fortsetzung)
Featurename
Verwendet von
system.webServer/
serverSideInclude
ServerSideIncludeModule (iis_ssi.dll)
Sitzungszustand
system.web/sessionState
system.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}
Speicherort der Konfiguration
Wenn 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-Featureeinstellungen 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 Konfigurationsabschnitt 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 Stammordner der Anwendung oder auf den Ebenen darunter befinden. Serveradministratoren, Administratoren 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.
Features verstehen
175
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 Authentifizierungsfeature 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.config 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 IISManager 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 jeweiligen Verbindung erreicht. Wenn der Abschnitt auch dort gesperrt ist, wird die Konfiguration als schreibgeschützt erachtet.
Wenn Sie Featurekonfigurationseinstellungen bearbeiten, zeigt der IIS-Manager Ihnen den Verwahrungsort der Datei an, in der diese Einstellungen gespeichert werden. Der Speicherort der Konfigurationsdatei 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.configStammdatei. 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 Statusleiste 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 Konfigurationsabschnitt, 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 Features
Die Startseiten der Knoten auf den verschiedenen Ebenen des Hierarchielistenfelds können unterschiedliche 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 ausschließ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-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 Serverebene 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 IISManager angezeigt wird oder nicht. Ausführliche Informationen zur Featuredelegierung finden Sie im
achten Kapitel.
Der 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.
Direkt von der Quelle: IIS-Manager – gegründet auf der öffentlichen Erweiterbarkeits-API
Wä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 sicherzustellen, 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ährleisteten wir, dass alles, was wir entwickelten, von anderen erweitert oder durch eigene Implementierungen 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 IISFeatures, wie z.B. FTP, WebDAV usw., einen Platz im IIS-Manager finden können.
Senior Development Lead, IIS
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 benutzerdefinierte Einstellungen und Anwendungen zu verwalten. Diese API bietet beispielsweise im Rahmen der
Erweiterbarkeit die Möglichkeit, Benutzeroberflächenfeatures zu entwickeln, die in Form von Listenseiten, 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.
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 IISManagers trennt die Logik, die die Servereinstellungen modifiziert, von dem Code, der diese Einstellungen für jedes Benutzeroberflächenfeature in einer benutzerfreundlichen Weise darstellt.
Die IIS 7.0-Verwaltungs- und Administrations-API
Die 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 IISManager 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 Webserverkonfigurationen und die Verwaltungsinformationen zuzugreifen und diese zu aktualisieren. Sie unterstü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.
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 Serverkomponenten 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 IISManager registriert werden. Der IIS-Manager gründet auf einer Erweiterbarkeit des Konfigurationssystems, die das einfache Hinzufügen von benutzerdefinierter Funktionalität ermöglicht.
Der IIS-Manager benutzt eine spezielle Datei namens administration.config, die die IIS-ManagerKonfiguration 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 Webverwaltungsdienst 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.
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 Erweiterung 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 IISManager 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«.
Remoteverwaltung
Remoteverbindungen 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 entsprechend 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 aktivieren. 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 Serveradministrator, 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 dwordWert namens EnableRemoteManagement gespeichert. Dies geschieht unter dem Registrierungsschlüssel HKLM\SOFTWARE\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. Konfigurieren Sie andere Einstellungen, sofern dies erforderlich ist, z.B. Verbindungs- und Protokollierungsoptionen 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 Webverwaltungsdiensteinstellungen befasst, erhalten Sie im achten Kapitel.
Zusammenfassung
Der 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.
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, »Konfigurationsund 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 InternetinformationsdiensteManager«.
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/GettingStarted-with-IIS-Manager.
183
K A P I T E L
7
Verwenden von Befehlszeilentools
Befehlszeilentools für die Verwaltung benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appcmd.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erste Schritte mit Appcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Grundverben verwenden: List, Add, Set und Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeiten mit der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mit Anwendungen, virtuellen Verzeichnissen und Anwendungspools arbeiten . . . . . . . . . . . . . . .
Mit Webservermodulen arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ausgeführte Arbeitsprozesse und Anforderungen untersuchen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mit der Ablaufverfolgung für Anforderungsfehler arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft.Web.Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows PowerShell und IIS 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WMI-Anbieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
COM-Objekte für die IIS 7.0-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auf der Begleit-CD
183
185
186
196
200
207
208
208
210
215
218
219
219
220
220
Befehlszeilentools für die Verwaltung benutzen
Es 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 Automatisierungsvorgä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 Verwaltungsaufgaben 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-Objektmodell nutzen.
COM-Objekte für die IIS 7.0-Konfiguration Sie können die COM-Objekte für die IIS 7.0Konfiguration (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.0Verwaltung wählen, ist Ihre Entscheidung oft von Ihren Präferenzen hinsichtlich des Programmiermodells 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
Appcmd
Microsoft.Web.Administration
COM-Konfigurationsobjekte
Nachteile
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
Beste Option für .NET Framework-Programme
Unterstützt die Remoteverwaltung
Beste Option für native C++-Programme
und Skripts
Funktioniert bei vollständigen Windows- und
bei Server Core-Installationen
Bietet die beste Leistung
Keine Unterstützung der Remoteverwaltung
Erfordert administrative Rechte
Die Befehlszeile kann bei komplexen Verwaltungsvorgängen Einschränkungen unterliegen
Code ist erforderlich
Ist für Server Core nicht verfügbar, kann aber
für die Remoteverwaltung von Server CoreServern verwendet werden
Appcmd.exe
185
Tabelle 7.1 Vorzüge und Einschränkungen der Optionen zur Verwaltung über die Befehlszeile (Fortsetzung)
Option
Vorteile
Nachteile
WMI
Funktioniert bei vollständigen Windowsund bei Server Core-Installationen
Ermöglicht eine Remoteverwaltung, die von
anderen Windows-Betriebssystemen aus
erfolgen kann
Bietet die Flexibilität der Windows
PowerShell-Befehlszeilenumgebung
PowerShell
Führt zu einem WMI-Overhead
Erfordert administrative Rechte
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 CoreServern verwendet werden
Erfordert die Entwicklung benutzerdefinierter
Cmdlets
Appcmd.exe
Appcmd.exe ist ein neues in IIS 7.0 enthaltenes Befehlszeilentool. Es ermöglicht die meisten Webserververwaltungsvorgä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öglichkeiten:
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«.
Erste Schritte mit Appcmd
Appcmd.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 InetsrvVerzeichnis 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 Umgebungsvariablen 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 Administratoren 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 Eingabeaufforderung, 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 beispielsweise 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 Befehlsausfü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,
Liste führt außerdem einige wichtige Attribute des Objekts auf (id, bindings, state).
TestSite).
Die
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 Appcmd
Appcmd 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 unterstü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, eindeutig 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 unterscheiden, 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 spezifischen 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 Konfigurationsattribute 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 Objekte
Appcmd 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 Arbeitsprozesse auf
List
Request (Requests)
Listet die gegenwärtig ausgeführten HTTPAnforderungen 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
189
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) verwenden, 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 nutzen
Da Appcmd solch eine Vielfalt an Objekten und Verben bietet und jedes Verb über verschiedene Parameter 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 allgemeinen 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 werden. 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 unterstü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
APP
VDIR
...
Verwaltung von virtuellen Sites
Verwaltung von Anwendungen
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>
/xml
Ausgabe im Textformat generieren (Standard)
/text:* Alle Objekteigenschaften in der Detailansicht anzeigen
/text:<Attribut> Wert des angegebenen Attributs
für jedes Objekt anzeigen
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 Ausfü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 beispielsweise 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
set
add
delete
start
stop
Virtuelle Sites auflisten
Virtuelle Site konfigurieren
Neue virtuelle Site hinzufügen
Virtuelle Site löschen
Virtuelle Site starten
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
191
/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 Bezeichner 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, dynamische 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 verstehen
Die Ausgabe von Appcmd enthält in der Regel eine Liste mit Elementen. Bei Befehlen, die Objektinstanzen 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 "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.
193
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 />
<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 AppcmdBefehls 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 Parameter
Zusä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.
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 Appcmd 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 Parameter, 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 Konfiguration 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.
Wenn Sie einem Befehl einen Parameter übergeben, der denselben Namen wie ein allgemeiner Parameter hat, können Sie dem Parameter zur besonderen Kennzeichnung ein Ausrufezeichen (!) voranstellen. Müssten Sie beispielsweise das commit-Konfigurationsattribut für den fiktiven Konfigurationsabschnitt mysection setzen, könnten Sie die folgende Syntax benutzen:
appcmd set config /section:mysection /!commit:somevalue
195
Bereichsoperatoren verwenden
Wenn 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 Einschrä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 vermeiden
Wenn 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 Befehlszeilenshell 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 Zeichencodes besitzen und deshalb von der Befehlszeilenshell oder von Appcmd möglicherweise nicht richtig 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 Delete
Die 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 auffinden
Das 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
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 Zeichenfolgenwerte. 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 entsprechende Website zu erhalten. Dies funktioniert auch beim Auflisten der Objekte App und Vdir. Um beispielsweise 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 erstellen
Viele 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 AddVerb 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 neunten 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 generiert 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 ändern
Zusätzlich zur Erstellung neuer Objekte mit dem Add-Verb können Sie ebenfalls die Konfigurationsattribute 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.
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 Verbindung mit der detaillierten Textansicht oder das Verb Set mit dem Parameter /?. Möchten Sie beispielsweise 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 entfernen
Kein 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 Objektinstanz 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 Konfiguration
Eine der wichtigsten Aufgaben, für die Appcmd verwendet wird, ist die Bearbeitung der IIS 7.0Konfiguration. 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 Automatisierung 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.0Onlinehilfe 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 AppcmdObjekte 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ückzusetzen; 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
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 Konfigurationsabschnitten 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 referenziert 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 betrachten
Um eine Konfiguration zu betrachten, können Sie den Befehl List
die folgende Syntax auf:
Config
benutzen. Dieser Befehl weist
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
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 Konfigurationsabschnitte 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:
MACHINE/WEBROOT/APPHOST,
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 beispielsweise 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 festlegen
Der Befehl Set Config ist sehr vielseitig und ermöglicht es Ihnen, Konfigurationseigenschaften festzulegen oder zu bearbeiten. Dieser Befehl verwendet die folgende Syntax.
appcmd list config Konfigurationspfad [/section:Abschnittsname] [/Attribut:Wert]
[/+Attribut] [/-Attribut]
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 anzuwenden. 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 Konfigurationshierarchie 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.
Konfigurationspfad
Direkt von der Quelle: Wo die Konfiguration gespeichert wird
Es ist wichtig, dass Sie verstehen, dass es einen Unterschied gibt, und zwar zwischen dem Konfigurationspfad, 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 Konfigurationsabschnitte 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.
203
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
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, »Konfigurationsattribute setzen« und später in diesem Kapitel im Abschnitt »Konfigurationsauflistungen verwalten«
beschrieben.
Konfigurationsattribute setzen
Um 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:
/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 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 Konfigurationsabschnitt 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:
/-allowDoubleEscaping
Direkt von der Quelle: Berücksichtigung der Groß- und Kleinschreibung in Appcmd
Bei Parameternamen unterscheidet Appcmd nicht zwischen Groß- und Kleinschreibung. Das bedeutet,
dass Sie sich keine Gedanken darum machen müssen, ob die von Ihnen gesetzten Konfigurationsattribute groß oder klein geschrieben werden. Das zugrunde liegende Konfigurationssystem berücksichtigt jedoch bei Attributnamen die Groß- und Kleinschreibung. Tritt somit der recht unwahrscheinliche Fall ein, dass ein Konfigurationselement zwei Attribute besitzt, die sich ausschließlich hinsichtlich 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 verwenden, 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 unterscheiden.
Letztendlich erleichtert die fehlende Berücksichtigung der Groß- und Kleinschreibung bei Attributund 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
Konfigurationsauflistungen verwalten
Sie 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
205
Sie können optional andere vom Auflistungselement unterstützte Attribute festlegen. Um beispielsweise der Auflistung im fileExtensions-Element des Abschnitts system.webServer/security/requestFiltering
einen neuen Eintrag hinzuzufügen, können Sie den folgenden Befehl benutzen:
/+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 Elementpfad 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 hinzugefügt haben, am Anfang der Auflistung anzuordnen, können Sie die folgende Syntax verwenden:
/+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:
/-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:
/-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:
/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 eindeutigen 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 verwalten
Sie 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 verwalten
Appcmd 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 applicationHost.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 arbeiten
Appcmd ist ein effektives Hilfsmittel für die Erstellung und Konfiguration vieler Webserver-Schlüsselobjekte, 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 ConfigObjekts 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 Stammanwendung 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 Anwendungen 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 Anwendungspools ä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 arbeiten
Das 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 Konfigurationsdateien 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
untersuchen
Das 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 auflisten
Sie können den Befehl List Wp benutzen, um alle gegenwärtig ausgeführten IIS-Arbeitsprozesse aufzulisten. 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
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 auflisten
Sie 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-Arbeitsprozessen 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 wird
Sie 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 Informationen 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
Parameter
Beschreibung
identifier
Der Anforderungsbezeichner, mit dem eine bestimmte Anforderung mehrmals abgefragt werden kann. Der Anforderungsbezeichner 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.
Tabelle 7.6 Parameter für den Befehl List Requests (Fortsetzung)
Parameter
Beschreibung
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 abgefragt 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 IPv6Format 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 Anforderungsverarbeitungspipeline«.
module
Der Name des Moduls. Benutzen Sie diesen Parameter, um nur solche Anforderungen anzeigen zu lassen, die vom
angegebenen Modul verarbeitet werden.
Mit der Ablaufverfolgung für Anforderungsfehler arbeiten
Das 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 sechzehnten 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 aktivieren
Um 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
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 deaktivieren, 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 aufstellen
Um 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
Parameter
Beschreibung
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 Ablaufverfolgungsprotokolle 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 Fehlerbedingung erfüllt und das Ablaufverfolgungsprotokoll generiert wird. Sie können diesen Parameter benutzen, um Ablaufverfolgungsprotokolle 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 Ablaufverfolgungsprotokoll 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 Anforderungen 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 Fehlerdefinitions-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 Anforderungsfehler 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
213
Ablaufverfolgungsprotokolle für Anforderungsfehler durchsuchen
Appcmd 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.
Tabelle 7.8 Parameter des Befehls List Trace
Parameter
Beschreibung
identifier
Der eindeutige Bezeichner eines Ablaufverfolgungsprotokolls, der im Format SiteName/logfilename.xml angegeben 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 Parameters 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
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 Ablaufverfolgungsprotokolle 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 Arbeitsprozess:
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)
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ührliche 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
Parameter
Beschreibung
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
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 auflisten 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-easilywith-AppCmd-command-piping.aspx, um weitere Informationen zu erhalten.
Eine 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 MWAAssembly 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 erstellen
Das 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 SitesEigenschaft 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.
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 applicationHost.config-Datei sehen können. Ihre Konfiguration sollte einen ähnlichen Abschnitt wie den folgenden enthalten:
<site name="Fabrikam" id="1000" serverAutoStart="true">
<virtualDirectory path="/"
physicalPath="c:\inetpub\wwwroot\fabrikam" />
</application>
<bindings>
<binding protocol="http" bindingInformation=":8080:" />
</bindings>
</site>
Anwendungspools mit MWA erstellen
Sie 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;
namespace Example {
class Program {
ApplicationPool pool =
mgr.ApplicationPools.Add("FabrikamPool");
pool.ManagedPipelineMode
= ManagedPipelineMode.Classic;
217
Site = mgr.Sites["Fabrikam"];
site.Applications[0].ApplicationPoolName =
@"FabrikamPool";
}
}
}
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 Eigenschaft 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:
Die Konfiguration festlegen
Der folgende Code demonstriert, wie die Microsoft.Web.Administration-APIs verwendet werden, um das
Standarddokument von Default Web Site zu aktivieren:
using System;
namespace Example {
class Program
{
Configuration config =
mgr.GetWebConfiguration(
"Default Web Site");
ConfigurationSection section =
config.GetSection(
"system.webServer/defaultDocument");
ConfigurationAttribute enabled =
section.GetAttribute("enabled");
enabled.Value = true;
}
}
}
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 GetWebConfigurationMethode des Server-Managers auf die Webkonfigurationsstammdatei zugreifen:
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;
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.0
Windows 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:
NewErzeugt eine neue Instanz eines Elements oder Objekts
Remove- Entfernt eine Instanz eines Elements oder Objekts
SetModifiziert bestimmte Einstellungen eines Objekts
GetRuft ein bestimmtes Objekt oder eine Untermenge eines Objekts ab
Das Cmdlet Get-Credential ruft beispielsweise basierend auf einem Kennwort ein Anmeldeinformationsobjekt 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-Anbieter
IIS 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 6Metabasiskompatibilitä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.0Metabasiskompatibilitä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 Konfigurationssystem 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 Konfigurationssystem 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-Verwaltungsskripts 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 Onlinedokumentation, die unter http://msdn2.microsoft.com/en-us/library/aa347459.aspx verfügbar ist.
COM-Objekte für die IIS 7.0-Konfiguration
Sie 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 COMObjekte 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 Frameworks.
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.ApplicationHost.AdminManager.
Zusammenfassung
In diesem Kapitel haben Sie die verfügbaren Optionen für die Verwaltung von IIS 7.0 über die Befehlszeile 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 Programm Webserverkonfigurationen generisch bearbeiten und alle erforderlichen Konfigurationsaufgaben 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 Ablaufverfolgung für Anforderungsfehler und die Sicherung und Wiederherstellung von Konfigurationen.
Der Vorteil von Appcmd besteht darin, dass zur effektiven Verwaltung des Webservers keine Programmierung erforderlich ist. Wenn Sie jedoch Verwaltungsaufgaben aus einer Programmierumgebung
heraus lösen müssen, stehen Ihnen mehrere Optionen zur Entwicklung einer umfassenden Verwaltungsautomatisierung 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.
Auf der Begleit-CD
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
Der IIS-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Webverwaltungsdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auf der Begleit-CD
222
222
248
248
Auf der CD finden Sie weitere Tools und Ressourcen .
Die Möglichkeit, einen Server remote zu verwalten, stellt für Administratoren eine wichtige Voraussetzung 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 Standardprotokollierungsregeln. 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 Umgebung 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 Konfigurationstools, 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-Manager
Der 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 Webplattformeinstellungen vereinheitlicht. Teil dieses Plattformentwurfs ist eine Remotinginfrastruktur für
integrierte Features, aber auch für die Features von Drittanbietern. Weitere Informationen zum IISManager 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.
Der 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-Anforderungen ü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 Remotecomputer 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 Webverwaltungsdienst für eine solche Konfiguration nicht installiert werden kann.
223
Installation
Der 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«.
Webverwaltungsdienst-Setup
Die 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) generiert. 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\WebManagement\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
WMSvc-Konfiguration
Nachdem der Webverwaltungsdienst installiert wurde, müssen Sie einige Konfigurationsänderungen
vornehmen, um den Dienst an Ihre Umgebung anzupassen. Besonders wichtige Konfigurationsaufgaben 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 konfigurieren
Nach 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.
225
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-Konfiguration
Der Webverwaltungsdienst ist standardmäßig so konfiguriert, dass zur Durchführung von Verwaltungsaufgaben nur lokale Verbindungen zum Dienst hergestellt werden können. Auf diese Weise können
delegierte Benutzer (Nichtadministratoren) am lokalen Computer eine Verbindung zum Server herstellen, 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 herzustellen. 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 Zertifizierungsstelle oder bei einer bekannten externen Zertifizierungsstelle ein gültiges Zertifikat für die Serverauthentifizierung 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 Verwaltungsdienst 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 Dropdown-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.
227
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üssen 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. MyServerMachine: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.
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öglichen 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.
RemoteRestrictions
Stellt eine serialisierte Version der Liste zur Verfügung, die die konfigurierten IP-Adressbeschrä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 WindowsAnmeldeinformationen erlaubt sind. Setzen Sie ihn auf 0, damit beide Arten von Anmeldeinformationen 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
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-Registrierung 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änkungen
Wenn der Webverwaltungsdienst ausgeführt wird und Remoteverbindungen aktiviert sind, ist es möglich, ü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-
229
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 DropdownListenfeld 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 DropdownListenfeld 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 unabhä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
Verbindungsauthentifizierungsoptionen
Eines 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.configDateien 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 IISManagers 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 Verwaltung von Benutzern und Gruppen und zum Aufstellen von Richtlinien, wie z.B. Kontokennwortrichtlinien, 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 Sicherheitsmechanismen von Windows nutzen können, wie z.B. ACLs (Access Control List, Zugriffssteuerungsliste), 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 WindowsPrinzipalen. 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 Dienstisolationsfeatures 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 Verbindung 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 IISManagers 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.
231
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 Benutzerspeichers durchzuführen. Dabei kann es sich um eine bereits vorhandene Datenbank, einen LDAPAnbieter 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 KonfigurationsAPIs, 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 Jede Aktion des Servers wird unter der
zum Server und zu jeder beliebigen Site und Anwendung Identität des aufrufenden Windowsdes Computers herstellen
Administrators ausgeführt
Windows-Benutzer
Windows-Benutzer dürfen lediglich Verbindungen zu
Jede Aktion des Servers wird unter der
Sites und Anwendungen herstellen, sofern ihnen über
Identität des aufrufenden Windowsdas Feature IIS-Manager-Berechtigungen die entspreBenutzers ausgeführt
chenden Zugriffsrechte gewährt wurden. Gewöhnliche
Windows-Benutzer können somit niemals eine Verbindung herstellen, um den gesamten Server zu verwalten.
Sie können lediglich für Sites oder Anwendungen
zuständig sein.
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 Feature 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 Anwendungen 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 verwalten
Der 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 verwalten
Die Vorgehensweise zum Verwalten von Benutzern und Berechtigungen kann abhängig davon variieren, 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 IISManager-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.
233
Abbildung 8.7 zeigt das Dialogfeld Benutzer zulassen. Beachten Sie, dass, wenn auf der Verwaltungsdienstseite nur Windows-Anmeldeinformationen aktiviert sind, im oberen Teil des Bereichs Aktionen
eine entsprechende Meldung angezeigt wird und im Dialogfeld Benutzer zulassen die Option IISManager 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 IISManager 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 administration.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 verwaltetem 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.
2. Markieren Sie im Bereich Verbindungen den Knoten des IIS-Computers und führen Sie einen Doppelklick 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-ManagerBerechtigungen 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:
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-ManagerBenutzer zu gewähren, müssen Sie sicherstellen, dass der Verwaltungsdienst so konfiguriert wurde, dass WindowsAnmeldeinformationen 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
235
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 PowerShellKonsole 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 administration.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 Features
Der 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 Anwendungen 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 konfigurieren. An dieser Stelle kommt die Featuredelegierung ins Spiel.
Abbildung 8.10 Die Seite Delegierung von Features
237
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 Features 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ände
Auf 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.
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.config-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 gekennzeichnet wird, werden alle Einstellungen für die entsprechenden Sites und Anwendungen unter Verwendung 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 Einstellungen 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.
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 implementiert sein.
239
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 Konfigurationseinstellungen 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 Delegierungsebene 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 Delegierungseinstellungen 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 automatisch 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 arbeiten
Mö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 Unterschiede 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
241
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 vollstä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 modifizieren, 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 Anwendungsadministratoren (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 Anmeldeinformationen 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 Verbindung 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
243
Hinweis Wenn Sie einen anderen Port als 8172 verwenden, müssen Sie diesen bei der Verbindungsherstellung im
Textfeld Servername eingeben, z.B. MyMachine:8173.
Administration.config und die Featuredelegierung
Administration.config ist die Datei, die alle Einstellungen für den IIS-Manager und die Remoteverwaltung 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 hinzufü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.configDatei gespeichert wird, die sich im übergeordneten physikalischen Pfad der Site befindet.
Problembehandlung
Die 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 werden
Wenn 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 Remoteanforderungen 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.
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:
Benutzer:
Abhören:
Delegieren:
SDDL:
https://*:8172/
NT SERVICE\WMSvc
Yes
No
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 autorisiert
Sie 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:
Kontoname:
Kontodomäne:
Anmelde-ID:
LOCAL SERVICE
LOKALER DIENST
NT AUTHORITY
0x3e5
Anmeldetyp:
245
8
Konto, für das die Anmeldung fehlgeschlagen ist:
Kontoname:
Administrator
Kontodomäne:
CARLOSAG1-IIS
Fehlerinformationen:
Fehlerursache:
Status:
Unterstatus:
Unbekannter Benutzername oder ungültiges Kennwort.
0xc000006d
0xc0000064
Prozessinformationen:
Aufrufprozess-ID:
Aufrufprozessname:
0x8d8
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 EreignisID 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 herstellen. Wenn ein delegierter Benutzer versucht, sich mit einem Server zu verbinden, wird ihm dies verweigert. 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
Protokollierung
Es ist hilfreich, die Protokollierungsvorgänge des Webverwaltungsdienstes zu verstehen. Die Protokolldateien 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 W3CProtokolldateiformat (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 Informationen 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.
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 Anwendungspfad
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
Sie untersuchen die Protokolldatei am besten mit einem Tool namens Log Parser, das es Ihnen ermöglicht, 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öglicht. 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 Eingabeaufforderung zu öffnen, starten Sie Log Parser aus der gleichnamigen Programmgruppe heraus.
Remoteverwaltungsprotokolle mit Log Parser untersuchen
Log 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.
247
Ü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 Anforderungen, die von jedem Benutzer initiiert wurden:
SELECT TOP 25
cs-username As User,
COUNT(*) as Hits
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 Anwendungsverbindungen. Diese werden nach Site gruppiert aufgelistet.
SELECT TOP 25
TO_LOWERCASE(EXTRACT_VALUE(cs-uri-query,'Site')) as Site,
COUNT(*) As Hits
WHERE Site IS NOT NULL
GROUP BY Site ORDER By Hits DESC
Site
Hits
-------------------- ---default%20web%20site 305
delegateduser1site 8
Zusammenfassung
IIS 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-ManagerBenutzer 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
Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools . . . . . . . . . . . . . . . . . . .
Verwaltungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtuelle Verzeichnisse verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remoteinhalte verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
249
256
266
272
277
278
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-Versionen 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-Konfigurationsdateien beschrieben ist.
Websites, Anwendungen, virtuelle Verzeichnisse
und Anwendungspools
Wie 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 Objekten, 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 enthalten können. Bei dieser Struktur wird eine Anwendung zu einem übergeordneten Container für Laufzeitfunktionalität und dient als isolierte logische Objekteinheit, die mit einem spezifischen Anwendungspool verknüpft ist. Das virtuelle Verzeichnis wird dabei einfach zu einem Mechanismus, der bestimmte
Teile des Anwendungs-URL-Namespace (Uniform Resource Locator) einem bestimmten physikalischen 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.
Websites
Eine Website ist ein übergeordneter Container für IIS-Inhalte und -Funktionalität. Er enthält Anwendungen, 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 Verbindungsendpunkt 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 Bindungskonfiguration fest (z.B. die HTTP-Bindungskonfiguration von IP-Adressen, der Port und Hostheaderdetails).
Es sind mehrere Bindungen zulässig, so dass der Zugriff auf eine Website von verschiedenen Endpunkten aus erfolgen kann, und zwar entweder mit demselben Protokoll oder mit mehreren verschiedenen 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 Hostheaderkonfigurationen 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 Communication 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 Anwendungsserver
IIS 6.0 stellt Webanwendungen eine Arbeitsprozessarchitektur für die zuverlässige und sichere Verarbeitung von Anforderungen zur Verfügung. Die W3SVC-Architektur (World Wide Web Publishing
Service) von IIS trennt die vom Kernelmodustreiber HTTP.sys durchgeführte Überwachung eingehender 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-Arbeitsprozesse verantwortlich und erzeugt diese bei Bedarf, damit die von HTTP.sys eingehenden Anforderungen verarbeitet werden. Er verwaltet außerdem den Zustand und die Lebensdauer der Arbeitsprozesse, 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 Anwendungsabstürzen bestehen bleibt.
Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools
251
Bei IIS 7.0 nutzt auch der neue Arbeitsprozessaktivierungsdienst diese Architektur, um ein zuverlä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 Anwendungen unabhängig vom Protokoll zu aktivieren und zu hosten. Der ehemalige Webaktivierungsdienst 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 IISWebsites 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,
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.fabrikam.com.
<sites>
<site name="Contoso Corp" id="1">
<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">
<virtualDirectory path="/" physicalPath="d:\fabrikam" />
</application>
<bindings>
bindingInformation="*:80:www.fabrikam.com" />
</bindings>
...
</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 Beispielkonfiguration 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.
IPv6
Windows 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 Anwendungen. 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 diejenigen, die die vielen neuen Features von IPv6 nutzen möchten.
Unter http://technet.microsoft.com/en-us/network/bb530961.aspx erhalten Sie weitere
Informationen.
Anwendungen
Eine 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 IISVersionen 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.
253
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 Anwendung 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 Anwendung 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 Ausführungsumgebung (in einem spezifischen IIS-Arbeitsprozess und vielleicht in einem spezifischen
Anwendungsframeworkkontext wie ASP oder ASP .NET) ausgeführt werden. Ein virtuelles Verzeichnis 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>
<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 erzeugt 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 Anwendungspools.
Virtuelle Verzeichnisse
Ein 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 zuzuordnen, 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 virtuelles Stammverzeichnis enthalten. Dies bedeutet, dass jede Website über ein virtuelles Stammverzeichnis 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öglich. 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.
Anwendungspools
Das 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 Anwendungslaufzeitumgebungen in einem separaten IIS-Arbeitsprozess gehostet werden. Dabei kümmert sich der Arbeits-
255
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 Anwendungen in IIS-Arbeitsprozessen ausgeführt werden können, die unter verschiedenen Anwendungspoolidentitä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 Anwendungspool zur Laufzeit in separaten Speicherbereichen isoliert und die entsprechenden Anwendungsressourcen 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, »Implementieren 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 Anwendungspool explizit zuweisen (andernfalls wird der als Standard konfigurierte Anwendungspool verwendet). Sie
können einen Anwendungspool ebenfalls manuell erstellen, sofern Sie möchten, dass bestimmte Anwendungen 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.NETAnwendungen im Anwendungspool verwendet wird.
Der ASP.NET-Integrationsmodus (Integriert [Standard] oder Klassisch). Wirkt sich auf die Arbeitsweise 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-Komponenten 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.
Verwaltungsaufgaben
Bei 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 Webanwendung 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 angebotenen 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, IISWEB.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 Verwaltung 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ügen
Sie können mit IIS 7.0 neue Webistes erstellen, um Ihre Webanwendungen und -dienste zu veröffentlichen. 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 Verzeichnisse. 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 festlegen, 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.
Tabelle 9.1 Appcmd-Syntax zum Hinzufügen einer Website
Parameter
Beschreibung
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-Bindungsinformationen 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 Hostheadername 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 entsprechenden 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.
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"
Hinweis Lange Befehle werden bisweilen in mehrere Zeilen umbrochen, damit sie auf die gedruckte Seite passen.
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 Stammanwendung 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
Verwaltungsaufgaben
259
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 Verzeichnis 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">
<virtualDirectory path="/" physicalPath="d:\fabrikamHR" />
</application>
<bindings>
bindingInformation="*:80:hr.fabrikam.com" />
</bindings>
</site>
...
</sites>
Die Bindungen einer Website konfigurieren
Websitebindungen legen protokollspezifische Endpunkte fest, an denen die auf die jeweilige Website
bezogenen Anforderungen empfangen werden. Jede Bindung definiert das Protokoll und die protokollspezifischen 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-Sitebindung 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öglichkeiten 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 Bindungen im Bereich Aktionen zu konfigurieren. Mit IIS 7.0 können Sie für eine Website andere Protokollbindungen 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 hinzufügen auf die Schaltfläche Anzeigen klicken. Weitere Informationen zur Konfiguration von SSL unter IIS 7.0 finden
Sie im vierzehnten Kapitel.
Verwaltungsaufgaben
261
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
Tabelle 9.2 Appcmd-Syntax zum Festlegen von Bindungen
Parameter
Beschreibung
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-Bindungsinformationen 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.
Hinweis Weitere Informationen zur Verwendung von Appcmd, um Bindungen und das Bindungsformat festzulegen, 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']
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 Bindungsinformationen ändern möchten, so dass aus myhr.fabrikam.com askhr.fabrikam.com wird, können Sie die
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>
...
</application>
<bindings>
bindingInformation="*:80:askhr.fabrikam.com" />
</bindings>
</site>
...
</sites>
Die Websiteverwendung einschränken
Sie können wie bei früheren IIS-Versionen Websiteeinschränkungen konfigurieren, wie z.B. die maximal verfügbare Bandbreite, die maximale Anzahl gleichzeitiger Verbindungen und den Verbindungstimeout. 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 Verbindungen und/oder eine größere Bandbreite als andere Sites nutzen können. Sie können drei Einschränkungen 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 Bandbreitendrosselung. 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.
Verwaltungsaufgaben
263
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änken, 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 Verbindungen 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 standardmäß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
Tabelle 9.3 Appcmd-Syntax zum Festlegen des Verbindungsgrenzwertes und der Bandbreitendrosselung
Parameter
Beschreibung
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.
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>
...
</application>
<bindings>
bindingInformation="*:80:askhr.fabrikam.com" />
</bindings>
<limits maxBandwidth="10485760" maxConnections="500" />
</site>
...
</sites>
Die Websiteprotokollierung und Ablaufverfolgung
für Anforderungsfehler konfigurieren
Nachdem 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
Verwaltungsaufgaben
265
markieren und im Featurehauptbereich einen Doppelklick auf dem Symbol des Features Protokollierung 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 Ablaufverfolgung 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 Ablaufverfolgungsdateien 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 beenden
Wenn 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 entgegennimmt. 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-Arbeitsprozessen 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.
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 IISKerndienstes 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.
Sie 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ügen
Sie können ein virtuelles Verzeichnis erstellen, um eine virtuelle Pfadzuordnung für Ressourcen festzulegen, 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 physikalischen 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 Verbindungen 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
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 URLNamespace des virtuellen Verzeichnisses zugeordnet werden soll.
Anmeldeinformationen für den Zugriff auf das virtuelle Verzeichnis konfigurieren
Der 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-Authentifizierungsmechanismus, 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 Anmeldeinformationen 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 freigegebenen 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 erstellen
Sie 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.
Tabelle 9.4 Appcmd-Syntax zum Hinzufügen eines virtuellen Verzeichnisses
Parameter
Beschreibung
app.name
Der Pfad der übergeordneten Anwendung, der das virtuelle Verzeichnis hinzugefügt wird. Dieser Parameter muss angegeben werden.
path
Der virtuelle Pfad des virtuellen Verzeichnisses. Er ist, ausgehend vom virtuellen Pfad der übergeordneten 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 PassThrough-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 virtuellen 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 Verzeichnisses 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.
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 konfigurieren
Wenn Sie ein virtuelles Verzeichnis hinzufügen oder ändern, sollten Sie dessen Beziehung zur Webanwendung 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.
269
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 PassThrough-Authentifizierung verwendet.
password
Das Kennwort, das zusammen mit dem Benutzernamen verwendet werden soll, um auf die Inhalte des
virtuellen Verzeichnisses zuzugreifen
Tabelle 9.5 Appcmd-Syntax zum Konfigurieren eines virtuellen Verzeichnisses (Fortsetzung)
Parameter
Description
logonMethod
Die Anmeldemethode, die zur Erstellung des Anmeldetokens für die Anmeldeinformationen des virtuellen 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 Verzeichnisses 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.
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 benutzerdefiniertes 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:
<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 Stammanwendung zugeordnet ist.
271
Nach virtuellen Verzeichnissen suchen
Wenn 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 Anforderungsidentitä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.
Tabelle 9.6 Appcmd-Syntax für die Suche nach virtuellen Verzeichnissen
Parameter
Beschreibung
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.
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
VDIR
VDIR
VDIR
"Contoso Corp/" (physicalPath:d:\contoso)
"Contoso Corp/images" (physicalPath:\\ContosoLegal\pub\images)
"Contoso Corp/payment" (physicalPath:d:\KDbank)
"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 Verzeichnissen 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 verwalten
Die Dateien, aus denen eine Webanwendung besteht, werden in der Regel im lokalen Dateisystem des IISServers 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 Anwendungsinhalte lokal zu hosten.
Für einige Szenarien benötigen Sie möglicherweise mehr als nur einen Webserver, um eine Webanwendung 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
273
Inhalte auf allen Servern synchronisiert werden. Darüber hinaus könnten durch die Replikation Probleme verursacht werden, die sich möglicherweise auf die Verfügbarkeit der Anwendung und die Intaktheit der Inhalte auswirken würden. Noch wichtiger ist, dass die Verwaltung von Inhalten über verschiedene 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 Leistungssteigerung 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 Einrichten vom Remoteinhalten erforderlichen Schritte, Sicherheitsüberlegungen zum Zugriff auf Remoteinhalte 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 konfigurieren
Wenn Sie virtuelle Verzeichnisse verwenden, um eine Zuordnung zu Remoteinhalten zu erhalten,
werden diese, in einem Remotenetzwerkpfad befindlichen Inhalte zu einem Teil des AnwendungsURL-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 Webanwendung 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 innerhalb 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-Authentifizierung 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ähren Sie dieser Dateifreigabe die erforderlichen Rechte.
Das Sicherheitsmodell für den Zugriff auf Remoteinhalte auswählen
Um 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 Verzeichnis feste Anmeldeinformationen festgelegt wurden, werden diese genutzt. Andernfalls wird
die Identität des gegenwärtig authentifizierten Benutzers verwendet, um auf diese Dateien zuzugreifen. 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 Anwendungsframeworks 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ührungsidentitä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.configDateien zugreifen zu müssen, erschwert jedoch die Konfiguration des Remoteinhaltszugriffs unter Verwendung der Pass-Through-Authentifizierung, da der authentifizierte Benutzer nicht verfügbar ist,
275
wenn der Webserver web.config-Dateien lesen muss. Deshalb ist es notwendig, dass die IIS-Arbeitsprozessidentität auf die Remoteinhaltsfreigabe zugreifen kann. Andernfalls müssen feste Anmeldeinformationen 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öglich. Die Pass-Through-Authentifizierung kann jedoch in diesem Fall genutzt werden. Weitere Informationen erhalten 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 Authentifizierungsmechanismus 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 Konfiguration der Delegierung und des Protokollübergangs, was bei vielen IIS 7.0-Authentifizierungsmechanismen notwendig ist, wenn die authentifizierte Identität für den Zugriff auf die Remotenetzwerkfreigabe 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 URLAutorisierungsfeature 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, benutzerdefinierte 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-Überwachungsmodul 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 Benutzers auf die Remoteinhalte zugreifen müssen, und Sie das URL-Autorisierungsfeature von IIS und
die benutzerdefinierte Autorisierung bzw. die protokollbasierte oder benutzerdefinierte Überwachung ü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-Authentifizierung) an die Remotenetzwerkfreigabe ermöglicht, oder wenn Sie eine eingeschränkte Delegierung und den Protokollübergang konfiguriert haben, um die Delegierung für andere Authentifizierungsmechanismen zu ermöglichen.
Sie keine anonyme Authentifizierung nutzen oder diese so konfiguriert haben, dass sie eine benutzerdefinierte 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 konfigurieren
Um 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 Verzeichnis 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 Speicherort 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ähren
Nachdem Sie das Sicherheitsmodell für den Zugriff auf die Remoteinhalte ausgewählt und den Webserver so konfiguriert haben, dass er mit diesem Modell arbeitet, müssen Sie den Zugriff auf die Netzwerkfreigabe 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 Verbindung 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 Remoteinhaltsverzeichnis. Gehen Sie dazu genauso wie für die Netzwerkfreigabe vor. Behalten Sie die vorhandenen 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 Remotenetzwerkserver ü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 festlegen 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-Authentifizierung verwendet wird, um einer großen Anzahl von authentifizierten Benutzern den Zugriff zu
gewähren.
Zusammenfassung
In 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 Remotefreigabe verwendet. Weitere Informationen zum Sichern von Websiteinhalten und zu fortgeschritteneren 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 Anwendungsframeworks 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 IISManagers unter IIS 7.0 bereit.
Das siebte Kapitel, »Verwenden von Befehlszeilentools«, beschreibt die Arbeit mit dem Befehlszeilenhilfsmittel 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 Protokollierungsverfahren, 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 Problembehandlungsmö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
Webanwendungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungspools verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeitsprozesse und Anforderungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auf der Begleit-CD
279
287
302
306
307
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 Erstellung 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 verwalten
Eine 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ührung 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 Stammpfades 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 physikalischen Stammverzeichnis der Anwendung zuordnet. Andererseits sind nicht alle virtuelle Verzeichnisse
als Anwendungsstamm definiert, weil sie einfach keine Anwendungsstartpunkte, sondern anderen
Anwendungen zugeordnet sind.
Webanwendungen erstellen
Bevor 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 Anwendung 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 Einkaufswagenfunktionalitä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 gesonderten Anwendungspool gehostet wird. Die Anwendungsisolation hilft Ihnen, eine bessere Verfügbarkeit
zu erzielen, da eine in einem eigenen Anwendungspool gehostete Anwendung von verschiedenen Arbeitsprozessen 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 Webanwendung erzeugen, indem Sie entweder eine neue Anwendung direkt hinzufügen oder ein bereits vorhandenes 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 Verzeichnis 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 Webanwendung zu finden ist.
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 konvertieren, 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 vorhandenes 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
Parameter
Beschreibung
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.
283
Dieser Befehl kann nicht verwendet werden, um zusätzliche Einstellungen zu dem virtuellen Stammverzeichnis 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 Stammverzeichnis 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
Tabelle 10.2 Appcmd-Syntax zum Ändern einer Webanwendung
Parameter
Beschreibung
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.
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 generieren. 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 informiert, 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.
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 Websitestamm 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 Stammanwendung 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 Dateisysteminhalte des zugeordneten Pfades. Es löscht lediglich die Zuordnungsbeziehung zwischen dem Anwendungs-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 Anwendung 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>
...
<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>
285
Webanwendungen auflisten
IIS 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 Webanwendungen 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 anzeigen, 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 Webanwendungen zurückgibt:
appcmd list app AppPath /site.name:string /apppool.name:string
Tabelle 10.3 beschreibt die Parameter dieser Syntax.
Tabelle 10.3 Appcmd-Syntax zum Abfragen einer Webanwendungsliste
Parameter
Beschreibung
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.
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
APP
APP
APP
"Contoso Corp/"" (applicationPool:DefaultAppPool)
"Contoso Corp/payment" (applicationPool:MyAppPool)
"Fabrikam HR/" (applicationPool:DefaultAppPool)
"Fabrikam HR/Stock" (applicationPool:Fabrikam Stock)
Um alle mit Fabrikam HR verknüpften Anwendungen anzeigen zu lassen, verwenden Sie den folgenden Befehl:
appcmd list app /site.name:"Fabrikam HR"
Dieses Beispiel fragt das Konfigurationssystem ab und zeigt alle Anwendungsobjekte an, die zur Website 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)
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
287
Websites sind. Sie können zum Filtern der Ausgabe auch jeden anderen Parameter des Anwendungsobjekts benutzen. Um weitere Informationen zur Suche nach Objekten zu erhalten, lesen Sie bitte das
siebte Kapitel, »Verwenden von Befehlszeilentools«.
Anwendungspools 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 Arbeitsprozesses 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 Anwendungspool 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ärten
Ein Anwendungspool mit mehr als einem Arbeitsprozess wird als Webgarten bezeichnet. Viele
Arbeitsprozesse, die dieselbe Anwendung bedienen, können bisweilen zu einer besseren Durchsatzleistung und Anwendungsreaktionszeit führen. Beachten Sie, dass jeder Arbeitsprozess eines Webgartens eigene Prozessthreads und einen eigenen Arbeitsspeicherbereich besitzt. Wenn die Anwendung 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 ausgefü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 Anwendungspools
Wenn 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 .NETAnwendungspool (Classic .NET AppPool), damit ASP.NET-Anwendungen im klassischen ASP.NETIntegrationsmodus 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.
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
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 Informationen darüber, wie diese Anwendungspools verwendet werden, um die ASP.NET-Versionen von ASP.NETAnwendungen zu verwalten, finden Sie im elften Kapitel, »Hosting von Anwendungsentwicklungsframeworks«.
Bevor Sie einen neuen Anwendungspool erstellen, sollten Sie – aus verschiedenen Blickwinkeln betrachtet – 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 Anwendungspools 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 Anwendungspoolidentitä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 Anwendungspoolisolation 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 Isolation, bei der jede Site einen eigenen Pool erhält, weil IIS 7.0 in diesem Fall eine bessere Sitedichte
bietet.
289
Kapazitätsanalyse für eine große Anzahl von Anwendungspools
Es 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 Kapazitä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 Auswirkungen 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 Webserver 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.
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 Anwendungen 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 Testanwendungen 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 Framework-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 Framework-Versionen arbeiten, sollten Sie wissen, dass verschiedene .NET Framework-Anwendungen auch verschiedene Anwendungspools erfordern, da jeder Anwendungspools immer nur einer .NET Framework-Laufzeitversion
zugeordnet ist.
Einen neuen Anwendungspool hinzufügen
Um mit dem IIS-Manager einen neuen Anwendungspool zu erstellen, erweitern Sie im Bereich Verbindungen 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 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 IISManager. Erweitern Sie im Hierarchielistenfeld des Bereichs Verbindungen den Knoten des IIS-Computers und dann den Knoten Sites. Erweitern Sie auch den Knoten der Website, die die gewünschte Anwendung enthält. Markieren Sie diese Anwendung und klicken Sie im Bereich Aktionen auf Grundeinstellungen. 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
291
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 Arbeitsprozess 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.
Tabelle 10.5 Appcmd-Syntax zum Konfigurieren von Anwendungspooleigenschaften
Parameter
Beschreibung
name
Der Name des neuen Anwendungspools. Muss zum Hinzufügen eines Anwendungspools angegeben 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.
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.
Sobald der neue Anwendungspool bereit ist, können Sie entweder eine neue Anwendung darin ausfü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 <applicationPools>-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 verwalten
Sie 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 Arbeitsprozessidentitä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.
293
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 Zugriffsrechte 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 verlangt, 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 Standardkonto, das von IIS-Anwendungspools verwendet wird, und es kann eingeschränkt auf Ressourcen zugreifen,
die sich auf dem lokalen Computer und auf Remotecomputern befinden.
Sicherheitskontenänderungen bei IIS 7.0
Bei IIS 7.0 wurde sowohl das anonyme Benutzerkonto (IUSR_computername) als auch die Benutzergruppe IIS_WPG entfernt und durch integrierte Systemkonten anstelle normaler Benutzer- und Gruppenkonten 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 Benutzeranmeldeinformationen 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_computername
IIS_IUSRS Neue integrierte Benutzergruppe; ersetzt die Gruppe IIS_WPG
Hinweis IUSR_computername wird erzeugt, wenn unter Windows Server 2008 der Rollendienst FTP-Publishingdienst (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 Anwendungspoolidentität fest. (Setzen Sie einfach im Konfigurationsabschnitt anonymousAuthentication das userNameAttribut auf einen leeren Wert. Um dieses neue Feature kennen zu lernen, lesen Sie bitte das vierzehnte Kapitel.) Der Hauptvorteile der Konfiguration des anonymen Benutzers als Anwendungspoolidentitä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 Anwendungspoolidentitä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 Anwendungspoolidentität wird aber nicht der Gruppe IIS_IUSRS hinzugefügt. Die Gruppen-SID wird zur
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änengruppenmitgliedschaft 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
Direkt von der Quelle: Anwendungspools für Sandbox-Anwendungen verwenden
Der 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ätswechsel 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 Ressourcen des Anwendungspools mithilfe von ACLs verwendet werden. Der Windows-Prozessaktivierungsdienst (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 Anwendungspool gefilterte Kopien der Konfigurationsdatei applicationHost.config generiert, die nur die Konfigurationen enthalten, die den jeweiligen Anwendungspool betreffen. Konfigurationen für andere Anwendungspools, 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
Die Anwendungspoolidentität konfigurieren
NetworkService ist ein Konto mit reduzierten Zugriffsrechten. Vielleicht möchten Sie deshalb die Arbeitsprozessidentität gemäß Ihren geschäftlichen Anforderungen ändern. Eine Sicherheitsanwendung könnte
beispielsweise den Zugriff auf Systemressourcen erfordern, für die NetworkService nicht die notwendigen Rechte besitzt. In diesem Fall könnten Sie den Arbeitsprozess unter der Identität eines benutzerdefinierten 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.
295
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 Sitzungsdaten 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
Tabelle 10.7 Appcmd-Syntax zum Konfigurieren der Anwendungspoolidentität
Parameter
Beschreibung
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 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:
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 Eigenschaften 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-Anwendungspoolidentitä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 Standardeinstellungen 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 Anwendungspoolkonfiguration
Obwohl die Anwendungspoolkonfiguration von IIS 7.0 der von IIS 6.0 gleicht, wurde die Konfigurationsoberflä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öglichen
Die 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-Anwendung arbeitet mit einer Microsoft Access-Datenbank. Bei IIS 6.0 gewährt das Betriebssystem standardmäß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.
297
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 verschiedenen temporären Ordnern für jede Prozessidentität. Doch nur das Prozesskonto kann standardmäß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 TempVerzeichnis 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 Verbindungen den Knoten des IIS-Computers und markieren den Knoten Anwendungspools. Markieren
Sie auf der Seite Anwendungspools den Anwendungspool, dessen Einstellung zum Laden eines Benutzerprofils 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 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 standardmäßig nur die Prozessidentität auf die Profilverzeichnisse zugreifen kann. Der integrierte Kontoprofilordner 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 Zugriffsberechtigungen 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
Tabelle 10.8 Appcmd-Syntax zum Aktivieren des Ladens von Benutzerprofilen
Parameter
Beschreibung
apppool name
Die Zeichenfolge repräsentiert den Anwendungspoolnamen
processModel.loadUserProfile
Gibt an, ob der Arbeitsprozess das Benutzerprofil während des Starts laden soll
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 processModelElement 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>
...
</applicationPools>
Die Wiederverwendung von Anwendungspools überwachen
Die 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 Anwenungsverfügbarkeit zu beheben. Bei IIS 6.0 können ähnliche Ereignisprotokollierungen ausschließlich
299
über ein Befehlszeilentool konfiguriert werden und nicht alle Anwendungspoolereignisse werden
erfasst. Beispielsweise wird das Herunterfahren eines Anwendungspools nach einer bestimmten Leerlaufzeit nicht registriert. Weitere Informationen zu IIS 6.0-Anwendungspoolwiederverwendungsereignissen 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 IISManager konfiguriert werden. Das schließt auch die auf Anwendungspools bezogenen Wiederverwendungsereignisse mit ein. Tabelle 10.9 zeigt die Ereignisprotokoll-ID und Detailinformationen zu jedem
Wiederverwendungsereignis.
Tabelle 10.9 Wiederverwendungsereignisse für Anwendungspools
Ereignis/Attributwert
Beschreibung
Ereignis-ID
Geänderte Anwendungspoolkonfiguration (ConfigChange)
Die Arbeitsprozesse für Anwendungspool '%1' werden aufgrund mindes- System
tens einer Konfigurationsänderung in den Anwendungspooleigenschaften, 5080
die zum Starten der Prozesse erforderlich sind, wieder verwendet
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 Fehlerursache angegeben.
Modul-Fehlermeldung
(ReportUnhealthy)
Eine Anwendung hat gemeldet, dass sie fehlerhaft ist. Der Arbeitsprozess Anwendung
fordert eine Wiederverwendung an. Grund: %1. Fehler in den Daten.
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)
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' System
hat die Wiederverwendung angefordert, da das zulässige Anforderungslimit 5075
erreicht wurde
Bestimmte Zeit (Schedule)
hat die Wiederverwendung angefordert, da die geplante Wiederverwendungszeit erreicht wurde
System
5076
Limit für den virtuellen Speicher
überschritten (Memory)
hat die Wiederverwendung angefordert, da das Limit für den virtuellen
Speicher erreicht wurde
System
5077
Anwendung
2262
Anwendung
2263
Wird ein Arbeitsprozess herutergefahren, weil die Leerlaufzeit (die Vorgabe ist 20 Minuten) überschritten 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.
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 Anwendungspools zu aktivieren, 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 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 Ereignisprotokolleintrag 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 protokolliert 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
301
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
Tabelle 10.10 Appcmd-Syntax zum Konfigurieren der Protokollierung von Wiederverwendungsereignissen
Parameter
Beschreibung
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.
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 wiederverwendet werden. Die folgende Syntax setzt das Anforderungslimit auf 500 und aktiviert für den Anwendungspool 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 Anwendungspools werden unter diesem Element konfiguriert. Es enthält die folgenden Knoten zum Festlegen 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 Ereignisprotokolleintrags wird im <recycling>-Element deklariert und die Limits oder Einschränkungen zu jeder Einstellung werden im Unterelement <periodicRestart> definiert. Nachfolgend ist die <applicationPools>-Konfiguration aufgeführt, die sich aus dem vorherigen Beispiel ergibt:
<applicationPools>
<add name="DefaultAppPool">
<recycling logEventOnRecycle="Requests">
<periodicRestart request="500" />
</recycling>
</add>
</applicationPools>
Arbeitsprozesse und Anforderungen verwalten
Der 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 Anforderungen 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 überwachen
Durch die Überwachung von Arbeitsprozessen erhalten Sie eine Übersicht über den Verbrauch der
Webserverressourcen. Sie können diese Informationen ebenfalls nutzen, um einen fehlerhaften Arbeitsprozess 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 Anforderungsstatus 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 Arbeitsprozesse ist in Abbildung 10.9 dargestellt.
Um eine Liste der gegenwärtig ausgeführten Anforderungen zu erhalten, markieren Sie einen Arbeitsprozess 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.
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.
Tabelle 10.11 Appcmd-Syntax zum Auflisten von Arbeitsprozessen
Parameter
Beschreibung
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
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.
Tabelle 10.12 Appcmd-Syntax zum Auflisten ausgeführter Anforderungen
Parameter
Beschreibung
RequestId
Der eindeutige Bezeichner der Anforderung, sofern bekannt. Erfolgt keine Angabe, werden alle Anforderungen 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.
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 Anwendungspools 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 "3918" (applicationPool:MyAppPool)
WP "3320" (applicationPool:Fabrikam Stock)
Hinweis Die RSCA-Objekte (Runtime State and Control API) innerhalb der IIS-Webserverkernengine stellen Laufzeitinformationen 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"
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 Anwendungspool DefaultAppPool bedienen:
Um alle Arbeitsprozesse aufzulisten, die zu einer Website gehören, listen Sie zunächst alle Anwendungen 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 "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)
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 ASPAnforderungen 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,
REQUEST "f800000080000010" (url:GET /account.asp, time:200 msec,
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 verarbeiteten 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 Anforderungsverarbeitung 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 versorgt, erhalten Sie nicht alle Informationen zu den Ereignissen, die im Rahmen der Anforderungsverarbeitung 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«.
Zusammenfassung
Das Webanwendungskonzept ist ein sehr wichtiges IIS 7.0-Konzept, das einen Container für die Funktionalitä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 Anwendungsausführung verwendet.
In diesem Kapitel haben Sie sich mit der grundlegenden Erstellung und Verwaltung von IIS-Anwendungen 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 Informationen zum Konfigurieren von Anwendungsframeworks für Ihre Anwendungen finden Sie im elften
Kapitel.
307
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 Nachverfolgungsprotokolldatei 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 herunterzuladen, 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-Anwendungspoolwiederverwendungsereignissen 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 Anwendungsentwicklungsframeworks
IIS als Anwendungsentwicklungsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP.NET-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PHP-Anwendungen hosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsframeworks ermöglichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auf der Begleit-CD
309
313
327
330
337
348
348
IIS als Anwendungsentwicklungsplattform
Wie 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-Dokumenten und Bildern. Dazu wurde das HTTP-Protokoll verwendet. Neue Anforderungen an Webseiteanwendungen 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 Anwendungsumgebungen 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 Webanwendungen 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 Anwendungsentwicklungsframework-Technologien entwickelt. IIS 3.0 hat die ASP-Skriptumgebung eingeführt, die für die Erstellung von Windows-basierten, dynamischen Serveranwendungen oft genutzt wurde (die letzte ASPVersion 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ßerdem 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 Anwendungsinhalte 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 leistungsfä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 Umgebungen 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 Anwendungsframeworktechnologie 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 IISTeam 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 PHPInitiative werden in nächster Zukunft sicherlich noch mehr Anwendungsframeworks von Drittanbietern
erstmals von der IIS-Plattform unterstützt.
Anwendungsframeworks unterstützen
Die 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 kennzeichnet, 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 dargestellt. (Wenn Sie die Datei remote anfordern, erhalten Sie aus Sicherheitsgründen – die benutzerdefinierte 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 Offenlegung 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 Anwendungsframework dynamisch verarbeitet werden muss, müssen Sie dieses Anwendungsframework
installieren und eine Handlerzuordnung konfigurieren, um das Anwendungsframework den gewünschten 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 Anwendungsframeworks
Durch die Beibehaltung der Unterstützung alter ISAPI-Erweiterungen und CGI-Programme ermöglicht 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).
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 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-Webserver mithilfe von verwaltetem Code zu erweitern. Auf diese Weise wird ASP.NET zum .NETErweiterbarkeitsmodell 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 Anwendungsframeworks vieler Drittanbieter unterstützt. Dies geschieht mithilfe des alten ISAPI-Erweiterungsmechanismus. 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
ASP.NET-Anwendungen hosten
313
offiziell getestet hatte. Viele dieser Anwendungsframeworks arbeiten problemlos mit IIS 7.0 zusammen, 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 entsprechenden 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 ist die Anwendungsframeworkplattform, die für die Entwicklung funktionsreicher Webanwendungen, 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 Anforderungsverarbeitungspipeline 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 Webserverkerns.
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 umfassenden 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. Serveradministratoren können somit beispielsweise nur jeweils eine Logik für die Authentifizierung, den Sitzungszustand 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-Anwendungen
Um 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 Arbeitsweise 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 vorhandenen ASP.NET-Anwendungen auswirken.
Wir wollten jedoch sicherstellen, dass bereits vorhandene ASP.NET-Anwendungen im neuen ASP.NETIntegrationsmodus auch weiterhin richtig arbeiten würden. Die Gewährleistung der Abwärtskompatibilität war ein wichtiges Design- und Implementierungsziel für die integrierte ASP.NET-Pipeline. Während der Entwicklung des Projekts erwies sich dies als große Herausforderung.
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 Workarounds, 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
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 verstehen
IIS 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 Webserverfeatures 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 Konfiguration 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.NETAnwendungen gedacht, auf die sich die mit dem integrierten Modus verbundenen Änderungen auswirken.
Hinweis Verwechseln Sie die Integrationsmodi von ASP.NET (Integriert und Klassisch) nicht mit dem IIS-Arbeitsprozessisolationsmodus. 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 zugeordneten Anforderungen verarbeitet. Diese Erweiterung richtet eine zweite Anforderungsverarbeitungspipeline für ASP.NET-Anforderungen ein. Im integrierten Modus werden die von den ASP.NET-
315
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 notwendig 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 denselben web.config-Dateien zu speichern. Er ist ebenfalls nicht erforderlich, um neue IIS 7.0-Features wie die URLAutorisierung 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 auszuführen, die verschiedene Modi verwenden (Integriert bzw. Klassisch). Der ASP.NET-Integrationsmodus 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 Anwendungen, 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 Anwendung darauf vorbereitet ist, heute und in Zukunft verfügbare spezifische Webserverfeatures des integrierten 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ängigkeiten 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ühren
IIS 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 Frameworks arbeiteten. Dies wurde durch die Zuordnung der im entsprechenden .NET Framework-Versionsverzeichnis enthaltenen ISAPI-Erweiterung Aspnet_isapi.dll zu den ASP.NET-Inhaltstypen der jeweiligen 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.
317
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 Versionsauswahl 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 Versionsverwaltung 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 Anwendungspool 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 installieren
Bevor 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-Redistributable 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.0Anwendungen 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.NETAnwendung 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 installieren
ASP.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-Erweiterbarkeitskomponente 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.NETAnwendungsframework selbst nicht benötigen.
Hinweis Wenn Sie anstelle von ASP.NET die .NET-Erweiterbarkeitskomponente installieren, können Anwendungen, die im integrierten Modus arbeiten, ASP.NET-Handler und -Module nutzen. Das ASP.NET-Anwendungsframework 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.
319
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 installieren
Im 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-Anwendungen 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 ServerManager 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 Anwendungskompatibilitä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 Vorbedingungen 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 Ausführung im 32-Bit-Modus und die Nutzung des klassischen ASP.NET-Integrationsmodus konfiguriert.
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 bereitstellen
Nachdem 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 erforderlich, die im integrierten Modus ausgeführt werden und migriert werden müssen).
Eine IIS-Anwendung erstellen
Obwohl Sie ASP.NET-Seiten für jede Anwendung, jedes virtuelle Verzeichnis und jedes Unterverzeichnis 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_CodeVerzeichnis 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 IISVersionen. 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 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 entsprechenden 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«.
321
Den richtigen Anwendungspool für die benötigte ASP.NET-Version und den entsprechenden
Integrationsmodus auswählen
Nachdem Sie die Anwendung erstellt haben, müssen Sie sie so konfigurieren, dass sie einen Anwendungspool 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 sicherzustellen, dass Ihre Anwendung im richtigen Anwendungspool platziert wird. Tabelle 11.2 beschreibt diese
Einstellungen.
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
managedPipelineMode: Integrated
Kann den Standardanwendungspool DefaultAppPool verwenden
Klassischer ASP.NET 2.0-Modus
managedPipelineMode: Classic
Kann den Anwendungspool Classic .NET AppPool verwenden
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 Informationen zur Erstellung und Verwaltung von Anwendungspools finden Sie im zehnten Kapitel.
ASP.NET 2.0-Anwendungen für die Verwendung des integrierten Modus migrieren
Nachdem 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 erforderlich, 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.
323
Tabelle 11.3 ASP.NET-Konfiguration, die für den integrierten Modus migriert werden muss
Situation
Empfohlene Aktion
Die Anwendung definiert im Konfigurationsabschnitt system.web/httpModules benutzerdefinierte 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 Konfigurationsabschnitt system.web/httpHandlers benutzerdefinierte Handlerzuordnungen
Entfernen Sie die Handlereinträge aus dem Abschnitt system.web/httpHandlers
und ordnen Sie sie im IIS-Abschnitt system.webServer/handlers an. Das Migrationstool kann dies automatisch tun.
Die Anwendung ermöglicht im Konfigurationsabschnitt system.web/identity den Anforderungsidentitätswechsel
Konfigurieren Sie die Anwendung für den klassischen Modus oder so, dass sie
diesen Fehler ignoriert
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"
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-Konfiguration, 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 klassischem 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:
ApplicationPath
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
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 Konfigurationsabschnitten sowohl für den klassischen als auch für den integrierten Modus gespeichert werden.
Die Vorzüge des integrierten ASP.NET-Modus nutzen
Wenn Sie Ihre Anwendung im integrierten Modus bereitstellen, können Sie die Vorzüge der ASP.NETIntegration 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 anwendungsspezifischen 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-Webserver-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-Anmeldesteuerelemente 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/GettingStarted/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 Anwendungen 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.NETInhaltstypen 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 Konfigurationsabschnitts 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 ausfü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.
325
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-Rollendienst 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.
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ührung von ASP.NET-Modulen für alle Anforderungen finden Sie im zwölften Kapitel, »Verwalten von
Webservermodulen«.
Zusätzliche Überlegungen zur Bereitstellung
Dieser Abschnitt beschreibt einige zusätzliche Überlegungen zur Bereitstellung von ASP.NET-Anwendungen, die unter IIS 7.0 ausgeführt werden.
Grundlegende Veränderungen im integrierten ASP.NET 2.0-Modus
Die meisten ASP.NET 2.0-Anwendungen arbeiten korrekt, wenn sie nach der notwendigen Konfigurationsmigration 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«.
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-Integratedmode.aspx beschrieben.
ASP.NET-Anwendungen über Remote-UNC-Freigaben hosten
ASP.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 Anwendung, 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.NETAnwendung 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 Verwendung eines Domänenkontos konfigurieren und dieses Domänenkonto einsetzen, um die Anwendung 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 Anwendungspoolidentität über die notwendigen Berechtigungen zur Ausführung von ASP.NET verfügt.
Aspnet_regiis.exe -ga Domain\UserName
ist die Domäne und UserName ist der Benutzername des benutzerdefinierten Kontos. Dies gewährleistet, 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 RemoteUNC-Freigaben und lokale Verzeichnisse. Das virtuelle Stammverzeichnis muss sich in einer
UNC-Freigabe befinden, damit diese untergeordnete virtuelle Verzeichnisse besitzen kann.
Domain
ASP-Anwendungen hosten
327
Wenn die ASP.NET-Anwendung im Konfigurationsabschnitt system.webServer/identity eine benutzerdefinierte 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-Codezugriffsicherheitsrichtlinie für den freigegebenen Netzwerkpfad bearbeiten. Dazu können Sie wie folgt das Befehlszeilenhilfsmittel 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 Zugriffskonfiguration finden Sie im vierzehnten Kapitel, »Implementieren von Sicherheitsstrategien«.
IIS 7.0 unterstützt auch weiterhin ASP-Anwendungen, verbessert oder verändert die ASP-Unterstü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 installieren
Aufgrund 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 Informationen 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-Erweiterung 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 bereitstellen
Die 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 Verzeichnisse 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 Anwendungen 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 ASPAnwendung 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-Anwendungen 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 Anwendungen 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.
329
Dieser Abschnitt beschreibt zusätzliche Überlegungen zur Bereitstellung von ASP-Anwendungen, so
dass diese unter IIS 7.0 gehostet werden können.
Skriptfehler anzeigen lassen
Aus 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 Pfaden
Seit 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 'Dateiname' 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 hosten
ASP-Anwendungen nehmen wie alle ISAPI-Erweiterungen standardmäßig die Identität des authentifizierten 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 Anwendungspoolidentitä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 (Netzwerkdienst) 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 hosten
IIS 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 Verarbeitung von Anforderungen wiederverwendet werden. Dadurch, dass gewährleistet ist, dass gleichzeitig
nur eine Anforderung pro FastCGI-Prozess verarbeitet wird, bleibt die notwendige Single-ThreadedUmgebung erhalten, die von nicht-threadsicheren Anwendungsframeworks benötigt wird.
Direkt von der Quelle: Die Geschichte der PHP-Unterstützung in IIS
IIS 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 ISAPIErweiterung. 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 Anforderung 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 Threadsicherheit 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.
331
Bei IIS 7.0 dachten wir lange darüber nach, was notwendig ist, damit IIS zu einer optimalen Anwendungsplattform wird. Wir kamen überein, dass hierzu die Unterstützung einer breiten Palette von
Anwendungsframeworks notwendig sei und dass sichergestellt werden müsse, dass diese Frameworks 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 PHPAnwendungen in Produktionsumgebungen. Wir arbeiten auch mit anderen AnwendungsframeworkCommunities 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
Im Rest dieses Abschnitts werfen wir einen Blick auf die Schritte, die notwendig sind, damit PHPAnwendungen unter IIS 7.0 ausgeführt werden können.
PHP-Anwendungen bereitstellen
Um 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 installieren
Bevor 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.
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 FastCGIProgramme ausführen lassen können. Sie müssen die ausführbare PHP-FastCGI-Datei zunächst manuell aktivieren, damit eine entsprechende Ausführung möglich ist.
PHP installieren
Sie 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 ISAPIUmgebung einzusetzen. Dies kann jedoch zu Instabilitäten führen und wird nicht empfohlen, da nicht alle PHPErweiterungen 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«.
333
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 Netzwerkdienst 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 entsprechende Verzeichnis zugreifen kann oder Sie eine benutzerdefinierte Anwendungspoolidentität verwenden, 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 bereitstellen
Damit 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 PHPDatei verarbeitet werden, die mit FastCGI kompatibel ist.
Da der IIS-Manager den ersten Schritt automatisch ausführt, wenn Sie die entsprechende Handlerzuordnung erstellen, werden wir lediglich das Generieren dieser Zuordnung erörtern.
FastCGI-Handlerzuordnungen für PHP erstellen
Wenn 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 Anforderungen 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ültigkeitsbereich 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-Handlerzuordnungen 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-Anwendungskonfiguration 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 angegeben 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-Handlerzuordnungen, 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 FastCGIAnwendungseintrag 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.
335
Wenn 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 PHPProzesse 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 PHPAusführungsidentität« zuwenden.
Konfigurieren der PHP-Ausführungsidentität
PHP-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 Anwendungspools 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 Verwendung 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 authentifizierten Benutzers auszuführen. Dies wird oft als Möglichkeit genutzt, um mithilfe des von IIS authentifizierten 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 betrachtet war dieser Identitätswechsel sehr wichtig, um die Ausführungsberechtigungen von PHP-Skripts einzuschrä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 eingeschränkten Berechtigungen des Kontos Netzwerkdienst ausgeführt werden.
Sollen PHP-Skripts in der FastCGI-Umgebung unter der Identität des authentifizierten Benutzers ausgefü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 PHPSkripts 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.0Authentifizierung bereit.
Hinweis FastCGI unter IIS 7.0 unterstützt die Annahme der Identität des authentifizierten Benutzers. Zur Drucklegung 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 hosten
Wenn 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. Aufgrund 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 sicherstellen
Der 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 PHPAnwendungen 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-Anwendungskonfiguration die Umgebungsvariable PHP_FCGI_MAX_REQUESTS setzen (Lesen Sie den Abschnitt »FastCGIAnwendungseinstellungen 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.
IIS 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 Anforderungen 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 Verfü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 Anforderungsverarbeitungsdienste zur Verfügung zu stellen. Dazu zählen auch die von IIS angebotenen Authentifizierungsmechanismen, 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 Anforderungen 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 Anwendungsframeworks. Dazu zählt auch der Einsatz des neuen FastCGI-Moduls zum Hosten von Anwendungsframeworks, 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 konfigurieren
Die Standardinstallation von IIS 7.0 bietet eine grundlegende Dateiserverfunktionalität, die von StaticFileVerfü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 Dateinamenserweiterungen hierfür konfiguriert sind. Dies ist sehr wichtig, da andernfalls alle unbekannten
Ressourcen im bedienbaren Namespace der Anwendung, einschließlich aller Datendateien und Anwendungsskripts, 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 konfigurieren 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.
Module zur
339
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:
/section:system.WebServer/staticContent "ConfigurationPath"
"/-[fileExtension=’string’]"
Die Parameter dieser Befehle sind in Tabelle 11.6 beschrieben.
Tabelle 11.6 Parameter zum Hinzufügen von MIME-Typen
Parameter
Beschreibung
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 (contenttype) versendet, wenn die Inhalte der verknüpften Ressourcen zum Client übermittelt werden.
Die MIME-Typkonfiguration wird nur dann verwendet, wenn in der IIS 7.0-Handlerzuordnungskonfiguration die Dateinamenserweiterung nicht bereits einem anderen Handler zugeordnet ist.
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 bereitstellen
Das systemeigene IIS 7.0-Modul stellt die bevorzugte Vorgehensweise zur Integration von Anwendungsframeworks 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 einfacher, 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 Anwendungsframeworks, 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 werden 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ächenerweiterungen für die Konfiguration Ihres Moduls. Legen Sie anschließend die spezifische Modulkonfiguration fest. Die dazu notwendige Vorgehensweise ist im dreizehnten Kapitel, »Konfigurations- 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 Anwendungsframework 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.
341
Frameworks basierend auf ASP.NET-Handlern bereitstellen
Der 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 Anwendungsframeworkoptionen 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 Verzeichnissen /BIN oder /App_Code). Die letzte Option ist besonders dann geeignet, wenn Sie Anwendungsframeworks 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ächenerweiterungen 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 Zielanwendung 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.NETHandler jedoch innerhalb einer ASP.NET-Anwendung geladen und ausgeführt. Die ASP.NET-Anwendung kann zusätzlich die Inhalte und die Anforderungsausführung mithilfe der teilweisen Vertrauenswü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 konfiguriert 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 zugreifen 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 vierzehnten Kapitel erfahren Sie mehr über die Anwendungsisolation aus Sicherheitsgründen.
Frameworks basierend auf ISAPI-Erweiterungen bereitstellen
ISAPI-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 Multithreadingumgebung, 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 stattdessen 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 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.
Mit FastCGI arbeitende Frameworks bereitstellen
FastCGI 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 IISErweiterungsmechanismen – benutzt FastCGI das FastCGI-Protokoll, um eine Schnittstelle zu den
Anwendungsframeworks zur Verfügung zu stellen. Auf diese Weise können verschiedene bereits vorhandene Anwendungsframeworks, die schon auf anderen Webserverplattformen FastCGI unterstützen,
mit IIS zusammenarbeiten. Das FastCGI-Protokoll weist gegenüber CGI, das schon lange von IIS unterstützt wird, eine wesentlich bessere Leistung auf. Dabei hält es sich an die Bedingung, die eine Anforderung pro Prozess verlangt. Diese Bedingung existiert aufgrund der fehlenden Threadsicherheit im jeweiligen Anwendungsframework oder in der Anwendung, die das Framework verwendet.
343
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-Anwendungsdatei 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 Antwort 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 Anforderungen 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 entsprechenden Bestätigung automatisch erzeugt, sofern Sie als Serveradministrator verbunden sind. Sie müssen 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 FastCGIArbeitsprozesse langlebig und werden immer unter derselben Identität wie der übergeordnete Anwendungspool ausgeführt. Dies bedeutet, das die ausführbaren Dateien des FastCGI-Anwendungsframeworks und deren Skripts mithilfe der Identität des Anwendungspools ausgeführt werden, dem die IISAnwendung zugeordnet ist, die die Skripts 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 auf Ressourcen einheitlich zu
verwalten. Es ermöglicht Ihnen außerdem, FastCGI-Anwendungen unter Verwendung 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.
FastCGI-Anwendungseinstellungen modifizieren
Wenn 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.
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 Vorgabewert 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 FastCGIProzess gewartet werden soll. Danach wird ein Deadlock vorausgesetzt und der Prozess wird zwangsweise 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 herzustellen. 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 FastCGI-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 FastCGIProzess 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 FastCGIAnwendungsprozess. Jedes environmentVariable-Elemente innerhalb der Auflistung kann den Namen
der Umgebungsvariablen und deren Wert angeben.
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']"
345
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 Anwendungseintrags 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 sicherstellen
Das Verhalten Ihres Anwendungsframeworks, die jeweilige Anwendung und die gesamte Webserverkonfigurationen 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 beitragen, 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 FastCGIAnwendung 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 FastCGIDatei 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 FastCGIAnwendungseintrag 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 Anwendung, 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 bereitstellen
IIS 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 Anwendungsframeworks, 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 Argumenten 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.
347
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.webServer/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.webServer/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:
/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.
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.
Timeout
Das Anforderungstimeout in Sekunden, nach dessen Ablauf der CGI-Prozess beendet wird. Der
Standard ist 15 Minuten.
Hinweis Wenn Sie für den Anwendungspool ein benutzerdefiniertes Konto verwenden, müssen Sie dem benutzerdefinierten 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 Sicherheitsrichtlinie tun.
Darüber hinaus können Sie ein CGI-Prozesslimit konfigurieren, das für alle IIS-Arbeitsprozesse gleichzeitig aktiv sein kann. Wird die Zahl überschritten, werden alle folgenden eingehenden CGI-Anforderungen, 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 WindowsRegistrierung 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.
Zusammenfassung
IIS 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 Anwendungsframeworkschnittstellen, 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 Leistungsfä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 bereitgestellt 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
IIS 7.0-Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Webservererweiterbarkeit zur Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
349
353
399
400
IIS 7.0-Erweiterbarkeit
Innerhalb des IIS 7.0-Teams (Internet Information Services) gibt es den Running Gag, dass jede IISVersion 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 Webanwendungsplattform der nächsten Generation zu transformieren. Um dies zu erreichen, unternimmt die IIS 7.0Version 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 Webserverlaufzeitfeatures 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üsselkonzept, 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 Drittanbietern 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. Beispiel 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 Webserver 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 verbrauchen 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 Blick
Die 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 Verwaltungstools und APIs, mit deren Hilfe der Benutzer auf die Konfiguration- und Verwaltungsfunktionalität zugreifen 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 integrierte ASP.NET-Erweiterbarkeitsmodell –, die beide die Flexibilität bieten, die integrierte IIS 7.0Funktionalitä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 Anforderungen. 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 Konfigurationserweiterbarkeit 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-Konfigurationsobjektmodell 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 Siteoder 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 Remoteverwaltungsmöglichkeiten nutzen.
352 Kapitel 12: Verwalten von Webservermodulen
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 benutzerdefinierte Konfiguration und Verwaltungsfunktionalität aufweisen und gleichzeitig die Möglichkeiten
nutzen können, die von der Benutzeroberfläche des IIS-Managers geboten werden.
Direkt von der Quelle
IIS 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 Webserverfeatures, 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
Die Erweiterbarkeit verwalten
Die 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. Diesbezü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 WindowsSetup 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-
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 Verwaltungsaufgaben für jeden

Microsoft Internetinformationsdienste (IIS) 7.0 – Die

Transcrição

Documentos relacionados

Sachmittelplanung - Hellweg Berufskolleg Unna

Windows Server absichern - ECS

Profil - cobasoft

IT-Sicherheitsaspekte beim Arbeiten mit webbasierten Lösungen

TSO-DATA

Microsoft VBA Grundlagen

AutoSketch 9

bürgerlicher lebenslauf

Anwenderbericht Altenheim Emmaus

Neuheiten der vorliegenden Version 2005.5: Softwarekomponenten