17.11 Administration

Ist der IIS nebst der benötigten Anwendungen installiert, verlässt das System die Projektphase und tritt in die Betriebsphase ein. Es gibt natürlich die üblichen wiederkehrenden Aufgaben, also beispielsweise:

• Kontrollieren Sie das System auf Ereignisprotokolleinträge.
• Überwachen Sie die Performance des Servers (System-Monitor).
• Spielen Sie regelmäßig alle verfügbaren Patches ein.
• Ändern Sie nichts, ohne den definierten Change-Prozess einzuhalten.

Die üblichen Aufgaben eben.

Bei einer größeren Menge von Servern machen Sie sich das Leben übrigens deutlich einfacher, wenn Sie ein intelligentes System wie den System Center Operations Manager (SCOM) 2012 einsetzen. Dieser erledigt automatisiert die Überwachung der vorhandenen Systeme und der darauf laufenden Applikationen, ohne dass die Operatoren sofort IIS-Spezialisten sein müssen.

In diesem Kapitel soll es aber insbesondere um drei Aspekte der Administrationstätigkeit mit dem IIS gehen:

• Remote-Administration
• Delegierung von Administrationsberechtigungen
• Protokollierung

Das hört sich alles nicht wirklich spannend an? Stimmt, es ist aber trotzdem wichtig, insbesondere deshalb, weil einige Aspekte im IIS7/8 nicht so klar und deutlich auf der Hand liegen.

17.11.1 Remote-Administration

Der Internetinformationsdienste-Manager ist in der Tat eine recht hübsche Applikation, um den IIS zu konfigurieren. Er deckt zwar nicht jede exotische Konfigurationsmöglichkeit ab, in der Administrationspraxis ist das aber nicht wirklich ein Problem.

Wenn Sie mehr als einen IIS7/8 einsetzen, werden Sie vermutlich den Wunsch haben, dass Sie alle IIS-Installationen mit einer Konsole administrieren können und sich nicht ständig auf den diversen Servern anmelden müssen. Der Internetinformationsdienste-Manager verfügt auch in der Tat über die Möglichkeit, eine Verbindung mit einem Server, einer Site oder einer Anwendung aufzubauen (Abbildung 17.126).

Abbildung 17.126 Man kann sich mit einem entfernten Server bzw. einer entfernten Site oder Anwendung verbinden, ...

Wenn Sie in dieser Richtung bisher nichts konfiguriert haben, werden Sie beim Versuch, die Verbindung herzustellen, allerdings keinen Erfolg haben. Der Internetinformationsdienste-Manager wird Sie mit der wenig detaillierten Information abspeisen, dass die Verbindung mit dem Remoteserver nicht hergestellt werden konnte (Abbildung 17.127) – und dabei hätte alles so schön sein können!

Der zuvor geschilderte Versuch kann nicht erfolgreich sein, weil der IIS standardmäßig nicht aus der Ferne administriert werden kann; der Grund ist der modulare Aufbau des Webservers. Für die Remoteadministration ist die Installation des Rollendiensts Verwaltungsdienst notwendig, nebst einigen kleinen Konfigurationsschritten übrigens. Da der Verwaltungsdienst standardmäßig nicht installiert ist, steht auch die Remoteadministrationsmöglichkeit nicht zur Verfügung – so weit einleuchtend. Sie werden es bestimmt schon ahnen, dass zur Installation des Verwaltungsdiensts ein Rollendienst hinzugefügt werden muss. Wie das gemacht wird, sehen Sie in Abbildung 17.128.

Abbildung 17.127 ... aber manchmal funktioniert es eben nicht.

Abbildung 17.128 Der »Verwaltungsdienst« wird als Rollendienst installiert.

Der Webverwaltungsdienst (WMSvc) läuft nach der Installation zunächst nicht. Sie müssen mit dem Snap-In Dienste den Webverwaltungsdienst erstens starten und zweitens den Starttyp auf Automatisch festlegen (Abbildung 17.129).

Abbildung 17.129 Der Webverwaltungsdienst muss manuell gestartet werden.

Ganz fertig sind Sie allerdings noch immer nicht, denn der Verwaltungsdienst muss noch ein wenig konfiguriert werden. In den Konfigurationsmenüpunkten auf Serverebene findet sich das Symbol Verwaltungsdienst – allerdings natürlich nur, wenn der entsprechende Rollendienst installiert ist (Abbildung 17.130). Es gibt folgende Aspekte, die Sie konfigurieren müssen (Abbildung 17.131):

• Der Hauptschalter ist die Checkbox Remoteverbindungen aktivieren – mehr ist dazu nicht zu sagen.
• Im nächsten Abschnitt können Sie festlegen, ob »nur« Windows-Anmeldeinformationen akzeptiert werden sollen oder ob auch Anmeldungen mit IIS-Manager-Anmeldeinformationen möglich sein sollen. Die zweite Option wird dann verwendet, wenn Verwaltungsarbeiten durch Benutzer erfolgen sollen, die nicht über ein Active Directory-Konto verfügen. Das dürfte insbesondere in Internet-Hosting-Szenarien der Fall sein.
• Im Abschnitt Verbindungen legen Sie zunächst fest, auf welche IP-Adresse und Portnummer der Webverwaltungsdienst reagieren soll. Da eine SSL-Verbindung Pflicht ist, wird eines der vorhandenen Zertifikate ausgewählt. Das Zertifikat, dessen Name mit WMSvc beginnt, ist ein selbstsigniertes Zertifikat, das automatisch bei der Installation des Rollendiensts erzeugt wird.
• Im Bereich Einschränkungen für IP-Adressen können Sie optional die zugriffsberechtigten Clients angeben.

Abbildung 17.130 Ist der Rollendienst installiert, finden Sie dieses Symbol.

Abbildung 17.131 Der Verwaltungsdienst muss konfiguriert werden.

Wenn Sie nach Abschluss der Installations- und Konfigurationsarbeiten nochmals versuchen, einen IIS remote zu administrieren (siehe Abbildung 17.126), werden Sie nach ein paar Augenblicken die Erfolgsmeldung sehen, dass eine neue Verbindung erstellt wurde (Abbildung 17.132).

Abbildung 17.132 So sieht es aus, wenn die Verbindung zu einem entfernten IIS hergestellt wurde.

17.11.2 Remote-Administration für Nicht-Server-Administratoren und IIS-Benutzer

Vielleicht haben Sie sich gefragt, welche Benutzer überhaupt administrativen Zugriff auf den Webserver haben. Die Antwort ist ganz einfach: diejenigen mit administrativen Berechtigungen auf dem Server. Das entspricht zwar der üblichen Vorgehensweise, ist aber teilweise nicht ganz optimal, denn es könnte Situationen geben, in denen eine Website oder Webanwendung von einem Benutzer administriert werden soll, der eben nicht Administrator des Servers ist oder vielleicht sogar gar nicht im Active Directory angelegt ist.

IIS-Manager-Berechtigungen

Damit »normale« Benutzer, also Nicht-Administratoren, auf den Webserver, die Website oder eine Webanwendung zugreifen können, müssen für sie IIS-Manager-Berechtigungen eingetragen werden. Ist der Verwaltungsdienst installiert, ist das Symbol IIS-Manager-Berechtigungen sichtbar (Abbildung 17.133). In der Konfigurationsseite, die Sie mit diesem Icon aufrufen, können Sie die gewünschten Benutzerkonten eintragen (Abbildung 17.134). Wie Sie sehen, gibt es keine weitere Differenzierung der Berechtigungen, d. h., Sie können beispielsweise keine Benutzer mit Leserechten oder dergleichen eintragen.

Der Benutzer kann sich mit dem Internetinformationsdienste-Manager wie in Abbildung 17.126 gezeigt verbinden. Sofern er sich mit einer Website oder einer Webanwendung verbindet, fragt der Assistent, der ihn durch den Verbindungsaufbau führt, diese zusätzlichen Parameter ab (Abbildung 17.135).

Abbildung 17.133 Ist der Verwaltungsdienst installiert, gibt es auf der Ebene von Webserver, Website und Webanwendung die Möglichkeit, IIS-Manager-Berechtigungen einzutragen.

Abbildung 17.134 So werden zusätzliche Benutzer für die Administration zugelassen.

Abbildung 17.135 Beim Verbinden mit einer Website wird zusätzlich zum Server der Name der Site abgefragt.

IIS-Manager-Benutzer

Es sind durchaus Szenarien denkbar, in denen Benutzer, die über kein Active Directory-Konto verfügen, einen IIS administrieren sollen. Auch diese Aufgabe ist einfach zu lösen, da der IIS »eigene« Benutzer kennt. Damit solche Benutzer den Verwaltungsdienst nutzen können, muss dieser zunächst für die Verwendung von IIS-Manager-Anmeldeinformationen konfiguriert werden. Abbildung 17.136 zeigt die entscheidende Stelle im Dialog, den Sie auf der Serverebene finden.

Abbildung 17.136 Wenn IIS-Manager-Benutzer akzeptiert werden sollen, müssen Sie dies zunächst auf Serverebene im Verwaltungsdienst konfigurieren.

Ebenfalls auf Serverebene findet sich die Möglichkeit, IIS-Manager-Benutzer einzutragen (Abbildung 17.137). Hierzu gibt es wirklich nur wenig zu sagen, denn beim Anlegen werden nur ein Benutzername und ein Kennwort benötigt. Für angelegte Benutzer gibt es minimale Administrationsmöglichkeiten, die sich allerdings auf das Zurücksetzen des Kennworts, das Deaktivieren/Aktivieren und das Löschen beschränken.

Abbildung 17.137 So simpel ist das Hinzufügen von IIS-Manager-Benutzern.

Beim Eintragen der IIS-Manager-Berechtigungen, was auf Server-, Website- und Webanwendungsebene geschehen kann, können Sie, anstatt eine Active Directory-Anmeldung anzugeben, auch einen IIS-Manager-Benutzer wählen. Abbildung 17.138 zeigt die Vorgehensweise – es ist also absolut simpel.

Abbildung 17.138 Die IIS-Manager-Benutzer werden den IIS-Manager-Berechtigungen hinzugefügt.

Wenn ein solcher Benutzer sich verbinden möchte, ruft er »ganz normal« den Internetinformationsdienste-Manager auf, wählt wie in Abbildung 17.126 gezeigt Server, Site oder Anwendung aus und gibt seinen IIS-Manager-Anmeldenamen an. Irgendwelche »Besonderheiten« sind nicht zu beachten.

17.11.3 Delegierung von Features

Wie Sie zuvor erfahren haben, können zwar beliebige Benutzer zur Administration einer Website oder Webanwendung berechtigt werden, allerdings können Sie die erteilten Berechtigungen nicht differenzieren – ist ein Benutzer berechtigt, kann er loslegen.

Sie haben aber die Möglichkeit, die Konfigurierbarkeit der Features auf Ebene der Website oder Webanwendung einzuschränken. Dies geschieht auf der Dialogseite Delegierung von Features, die Sie auf Serverebene finden (Abbildung 17.139). Etwas anders formuliert bedeutet es, dass Sie bei Konfigurationsmöglichkeiten, die auf allen Ebenen (Webserver, Website, Webanwendung) existieren, verhindern können, dass diese auf unteren Ebenen modifiziert werden.

Abbildung 17.139 Der Dialog »Delegierung von Features«

In Abbildung 17.140 können Sie sehen, dass unterschiedliche Delegierungen auf Serverebene zu verschiedenen Konfigurationsmöglichkeiten auf der Ebene von Website und Webanwendung führen:

• Links ist die Delegierung der Protokollierung auf Schreibgeschützt gestellt.
• Rechts ist sie auf Lesen/Schreiben konfiguriert.

Bekanntlich liegen die Konfigurationsdaten in den diversen *.config-Dateien auf den verschiedenen Ebenen der Installation. Man könnte nun auf die Idee kommen, die »Sperre« (siehe Abbildung 17.140) des Internetinformationsdienste-Managers zu umgehen und die Konfiguration direkt in den web.config-Dateien der Website oder Webanwendung zu ändern. Auch das ermöglicht aber nicht, diese Vorgaben zu umgehen: In diesem Fall wird es beim Bearbeiten im Internetinformationsdienste-Manager eine Fehlermeldung geben (siehe Abbildung 17.87), und beim Aufruf der Webanwendung mit dem Browser wird ein interner Serverfehler gemeldet werden (Fehlercode 500).

Die »Überschreibbarkeit« von Einstellungen lässt sich übrigens direkt in der applicationHost.config-Datei noch genauer einstellen als mit dem Internetinformationsdienste-Manager. Ich möchte das Thema jetzt nicht zu breit auswalzen und möchte exemplarisch auf Abbildung 17.88 verweisen, in der zu sehen ist, wie man einen Konfigurationsabschnitt entsperrt.

Abbildung 17.140 Unterschiedliche Delegierungen auf Serverebene führen zu verschiedenen Konfigurationsmöglichkeiten auf der Ebene von Website und Webanwendung.

17.11.4 Protokollierung

Die Protokollierung und Diagnose ist ein Themenbereich, mit dem man recht problemlos die nächsten hundert Seiten dieses Buchs füllen könnte. Immerhin gibt es sechs Rollendienste, die sich »nur« mit diesem Themenbereich befassen.

Meiner Erfahrung nach befassen sich die meisten Administratoren mit der Protokollierung oder Nachverfolgung nur recht rudimentär und überlassen die Detailanalyse und Diagnostik eher den Webanwendungsspezialisten. Ich möchte diesen »Zustand« nun keinesfalls für alle Zeiten festzurren und behaupten, dass die Admins sich »nur« mit den Basisthemen befassen müssten, möchte aber auch nicht zig Seiten für Themen verbrauchen, die die meisten Leser nicht als »ihre Themen« ansehen.

Ich möchte daher neben der eigentlichen Protokollierung speziell auf die Nachverfolgung verweisen, die es ermöglicht, »kniffligen« Problemen auf die Spur zu kommen, die sich aus den normalen Logdateien nicht erschließen. Erfahrungsgemäß werden diese Möglichkeiten aber schwerpunktmäßig von dedizierten IIS-Spezialisten und Anwendungsentwicklern genutzt, weshalb ich es in diesem Buch bei der Erwähnung belassen möchte.

Abbildung 17.141 Immerhin sechs Rollendienste befassen sich mit Protokollierung und Diagnose.

Abbildung 17.142 zeigt den Dialog, mit dem die grundlegenden Protokollierungsoptionen konfiguriert werden:

• Im ersten Konfigurationsabschnitt (Eine Protokolldatei pro) können Sie festlegen, ob die Protokolle des Servers in eine einzige Datei geschrieben werden sollen oder ob eine separate Datei für jede Website geschrieben werden soll.
• Der Konfigurationsabschnitt Protokolldatei ermöglicht die Konfiguration des Formats und des Speicherorts. Die Formatoptionen sind:
  • Binär: Dieses Format steht nur zur Verfügung, wenn ein Protokoll pro Server (und eben nicht pro Site) erstellt wird. Durch die Protokollierung im binären Format wird zwar gegenüber den textbasierten Formaten Plattenplatz gespart, allerdings können Sie die Daten nicht mehr einfach mit dem Texteditor einsehen. Zum Lesen dieses Formats können Sie beispielsweise den Log Parser verwenden, den Sie im Microsoft Download Center herunterladen können.
  • Microsoft IIS: Dieses Format wird durch HTTP.sys verwaltet und liegt in einem festen textbasierten ASCII-Format vor. Das heißt, dass Sie die zu protokollierenden Felder nicht festlegen können. Die Felder sind durch Kommas getrennt, und die Zeit wird als lokale Zeit aufgezeichnet.

    

    Abbildung 17.142 Konfiguration der Protokollierung

  • NCSA allgemein: Dieses Format wird durch HTTP.sys verwaltet und liegt in einem festen textbasierten ASCII-Format vor. Das heißt, dass Sie die zu protokollierenden Felder nicht festlegen können. Die Felder werden durch Leerzeichen getrennt, und die Zeit wird als lokale Zeit mit UTC (Coordinated Universal Time) als Offset aufgezeichnet.
  • W3C: Dieses Format wird von HTTP.sys verwaltet und liegt in einem benutzerdefinierbaren textbasierten ASCII-Format vor. Das heißt, dass Sie die zu protokollierenden Felder festlegen können. Geben Sie im Dialogfeld W3C-Protokollfelder die Felder an, die protokolliert werden sollen. Die Felder werden durch Leerzeichen getrennt, und die Zeit wird in UTC (Coordinated Universal Time) aufgezeichnet.
  • Weiterhin können Sie ein benutzerdefiniertes Format auswählen. Bei Auswahl dieser Option wird die Seite Protokollierung deaktiviert, da in IIS-Manager keine benutzerdefinierte Protokollierung konfiguriert werden kann.
• Im letzten Konfigurationsabschnitt (Protokolldateirollover) legen Sie fest, ob und wann eine neue Protokolldatei begonnen werden soll.

Da die Protokolle recht umfangreich werden können, macht es unter Umständen Sinn, diese nicht auf dem Systemvolume abzulegen. Die Protokollierung auf einem Netzlaufwerk ist ebenfalls möglich. Alternativ kann mittels des installierbaren Rollendiensts ODBC-Protokollierung auch in eine Datenbank protokolliert werden.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.