Metabase-Kompatibilität mit IIS 7 und höher

von Saad Ladki

Einführung

Das Konfigurationssystem in IIS 7 und höher ist mit Legacy-Konfigurationsschnittstellen auf API-Ebene kompatibel. Es unterstützt die ABO (Admin Base Objects)-Schnittstelle, auch IMSAdminBase genannt, wie auch die ADSI- und WMI-Anbieter, die auf ABO in IIS 6.0 aufgebaut wurden. Vorhandene Anwendungen und Skripts können diese befehlsorientierte Benutzerschnittstelle in IIS 7.0 und höher weiterhin aufrufen und weiterhin funktionieren, solange die Metabase-Kompatibilitätskomponente von IIS installiert ist

Installieren der Metabase-Kompatibilitätsunterstützung

Sie finden diese Komponente im Setup unter Internetinformationsdienste -> Webverwaltungstools -> IIS 6.0-Verwaltungsfunktionsfeature.

Diese Komponente ist nicht standardmäßig installiert, da IIS anfangs nicht für dessen Verwendung eingerichtet ist. Die Legacy-Schnittstellen weisen einige Einschränkungen auf und eignen sich nicht ideal für die Arbeit mit verteilten Konfigurationsdateien (siehe Abschnitt „Einschränkungen“ unten). Daher wird empfohlen, dass Kunden im Laufe der Zeit und insbesondere beim Öffnen des Konfigurationssystems für immer mehr Delegierung (d. h. immer mehr web.config-Dateien mit darin enthaltenen IIS-Einstellungen) erwägen, Legacy-Skripts und Anwendungen auf das neue System und seine Schnittstellen zu portieren.

Es wird auch empfohlen, dass neue Skripts und Anwendungen mithilfe der neuen Schnittstellen entwickelt werden, sodass sie ideal mit dem neuen System funktionieren und Zugriff auf die neuen Eigenschaften, Konzepte und Struktur des Konfigurationssystems haben können.

Wenn alle Legacy-Skripts und Anwendungen zu den neuen Schnittstellen portiert werden, empfiehlt es sich, das Metabase-Kompatibilitätsfeature zu deinstallieren.

Funktionsweise der Metabase-Kompatibilität

Das Metabase-Kompatibilitätsfeature wird innerhalb des Metabase-Diensts (IISADMIN) ausgeführt. Es fängt alle Methodenaufrufe an ABO ab. Wenn sich die Informationen im Methodenaufruf auf die Webserverkonfiguration beziehen, werden sie auf das neue System zugeordnet. Wenn sie sich auf die FTP-, SMTP- oder NNTP-Konfiguration beziehen, folgt sie der regulären Logik des Metabase-Systems und endet in der Metabase-Datei.

Beachten Sie, dass auch benutzerdefinierte Eigenschaften, die sich unter der Webserverkonfiguration befinden, dem neuen System zugeordnet (und beibehalten) werden.

Die Zuordnungsentscheidung basiert auf dem entsprechenden Metabase-Knoten. Die Webserverkonfiguration befindet sich in der Regel unter LM/W3SVC, einschließlich benutzerdefinierter Eigenschaften, mit einigen wenigen Ergänzungen wie Mime Maps.

Die Zuordnung erfolgt, um zwischen der ABO-Ansicht und der neuen Systemansicht hin und her zu übersetzen. Beispielsweise verfügt das neue System über ein Konzept von Anwendungen, unter jeder Site und über allen virtuellen Verzeichnissen. Das Legacy-System behandelt Anwendungen anders: Sie sind einfach virtuelle Verzeichnisse mit einer speziellen Eigenschaft, um sie als Anwendungen (AppIsolated oder AppRoot) zu kennzeichnen.

Beim Aufrufen von ABO zum Schreiben der Webserverkonfiguration speichert die Metabase-Kompatibilitätskomponente die Daten in applicationHost.config. Dies wird als „write-through“ (durchgehendes Schreiben) bezeichnet, da die Informationen nicht im Arbeitsspeicher gehalten werden. Beim Aufrufen von ABO zum Lesen der Webserverkonfiguration liest die Metabase-Kompatibilitätskomponente sie aus applicationHost.config. Dies wird als „read-through“ (durchgehendes Lesen) bezeichnet, da die Informationen wieder nicht aus dem Speicher abgerufen werden.

Unvollständige Daten, die nicht für die Verwendung durch die Serverruntime bereit sind, werden in einem speziellen Abschnitt in applicationHost.config, der als customMetadata bezeichnet wird, beibehalten. Dieser Abschnitt wird als beständiger Speicher für das Metabase-Kompatibilitätsfeature verwendet, und Kunden sollten dessen Inhalt niemals ändern. Ein Beispiel für unvollständige Daten ist, wenn das Legacy-Skript die Site-ID, aber nicht die Sitebindungen festgelegt hat. In IIS 6.0 hätte ein solcher Aufruf ein ungültiges Siteobjekt in der Konfiguration erstellt. In IIS 7.0 und höher wird es im Abschnitt beibehalten, der nicht vom Server genutzt wird. Wenn ein nachfolgender Aufruf zum Festlegen der Sitebindungen erfolgt, wird das Siteobjekt als abgeschlossen betrachtet und in seiner Gesamtheit im Abschnitt beibehalten, wo es von der Serverruntime abgeholt wird. Temporäre Daten werden zu diesem Zeitpunkt entfernt, sodass der Benutzer keine Reste aus dem System bereinigen muss. Wenn ein solcher nachfolgenden Aufruf nicht erfolgt, wird die Serverruntime diese ungültige Site nie sehen, aber Legacy-Skripts werden sie in der ABO-Ansicht haben, genau wie in IIS 6.0. Aus Sicht des Legacy-Skripts ist das System hier vollständig mit IIS 6.0 kompatibel.

Benutzerdefinierte Webservereigenschaften, die über Legacy-Skripts und Anwendungen festgelegt werden, werden immer im Abschnitt beibehalten. Sie können wie in IIS 6.0 über die Legacy-Schnittstelle abgerufen werden, sodass das System vollständig kompatibel ist. Dies unterscheidet sich natürlich sehr von der empfohlenen Art und Weise, das IIS-Konfigurationssystem zu erweitern und ist daher ein weiterer Grund, solche Anwendungen im Laufe der Zeit zu portieren, um neue Schnittstellen und neue Features zu verwenden, die vom Konfigurationssystem in IIS 7.0 und höher angeboten werden.

Andere Metabase-Konfigurationsdaten

Beachten Sie, dass die FTP-, SMTP- und NNTP-Konfiguration weiterhin im Metabase-System beibehalten und nicht zu den neuen IIS-Konfigurationssystemen portiert wurde. Die Konfigurationseinstellungen für diese können weiterhin über befehlsorientierte Legacy-Benutzerschnittstellen verwaltet und direkt in der Datei metabase.xml bearbeitet werden.

Übersicht

Die meisten Vorgänge auf Metabase-Schlüsseln und -Eigenschaften funktionieren nahtlos, und dem Benutzer werden diesen Legacy-Konzepte und -Namen angezeigt und nicht den neuen IIS-Konzepte wie Konfigurationsabschnitte und benannte Eigenschafte (ABO arbeitet weiterhin mit Eigenschaften-IDs; ADSI arbeitet weiterhin mit den Legacy-Eigenschaftennamen).

Legacy-Benutzer können weiterhin das ADSI-Schema verwenden und es sogar wie bei IIS 6.0 erweitern.

XML-Dateikompatibilität

Die Webserverkonfiguration, einschließlich der benutzerdefinierten Konfiguration, die den Webserver erweitert, wird in system32\inetsrv\applicationHost.config beibehalten und nicht in metabase.xml. Daher befindet sich der Legacy-Support auf API-Ebene und nicht auf der Dateiformatebene (und deshalb werden einige Legacy-Features nicht unterstützt). Der Legacy-Schnittstellenaufrufer erhält die „ABO-Ansicht“ der Konfiguration genau wie bei IIS 6.0 und nicht das neue Dateiformat oder die Namensgebung oder die Konzepte.

Eine Folge davon ist, dass Konzepte wie Metabase-ACLs nicht unterstützt werden. Dies liegt daran, dass sie eng mit dem Metabase-Dateiformat verbunden sind. Das IIS-Konfigurationssystem nutzt Standarddatei-ACLs für die Konfigurationsdateien. Das System stellt keine Zuordnung zwischen Metabase-ACLs und Standarddatei-ACLs bereit.

Features wie Verlaufsdateien, Sicherung/Wiederherstellung und Import/Export funktionieren anders, da sie auf dem neuen Konfigurationssystem basieren. ABO-Aufrufe an die Sicherungskonfiguration werden daher ignoriert.

Legacy-Metabase-Features

Die Konfigurationsüberwachung wurde IIS 6.0 in Windows Server® 2003 Service Pack 1 hinzugefügt. Sie wird derzeit von IIS 7.0 oder höher nicht unterstützt, da das neue Konfigurationssystem eine sehr unterschiedliche Architektur aufweise (z. B. verwendet IIS 7.0 und höher ein prozessinternes Konfigurationssystem, IIS 6.0 verwendet einen dedizierten NT-Dienst, der aus Benutzercode in anderen Prozessen gekapselt wird).

Legacy-Metabase-Eigenschaften

Es werden nur Legacy-Eigenschaften unterstützt. Konfigurationseigenschaften von IIS 7.0 und höher werden nicht an den Legacy-Benutzer zurückgegeben, und auch keine .NET Framework-Konfigurationseigenschaften.

Zuordnungseinschränkungen

Der Zuordnungsalgorithmus muss die Unterschiede der Konfigurationssysteme zwischen IIS 6.0 und IIS 7.0 und berücksichtigen. IIS 6.0 erforderte beispielsweise keine Namen („Serverkommentare“) für Sites. Wenn ihnen Namen gegeben wurden, war es nicht erforderlich, dass diese Namen eindeutig waren. In IIS 7.0 und höher muss jede Site einen eindeutigen Namen haben. Das Zuordnen der alten ServerComment-Eigenschaft zur neuen Name-Eigenschaft ist daher nicht trivial. Der Zuordnungsalgorithmus erzwingt, dass Namen pro Site eindeutig sind, da dies eine Anforderung des Konfigurationssystems von IIS 7.0 und höher ist. Dies geschieht durch Hinzufügen von Zahlen zu den Serverkommentaren, um die Eindeutigkeit zu gewährleisten. Das Endergebnis ist, dass der Wert, der tatsächlich für den Serverkommentar festgelegt ist, sich von dem vom Skript angegebenen unterscheidet.

Verteilte Konfiguration

Nur applicationHost.config wird vom Metabase-Kompatibilitätsfeature unterstützt. Die Konfiguration in web.config-Dateien wird nicht an den Legacy-Benutzer zurückgegeben. Tags für Speicherorte werden in applicationHost.config verwendet, um die Konfiguration pro URL zu unterstützen.