Grundlegendes zur IIS 7.0-Konfigurationsdelegierung

von Saad Ladki

Einführung

IIS führt in seiner siebten Produktfreigabe ein brandneues dateibasiertes Konfigurationssystem ein. Dieses neue System hebt ein datengesteuertes System hervor, das für eine gesamte Webplattform geeignet ist, bei der Technologien wie ASP.NET, Indigo und sogar Komponenten von Drittanbietern diesen Konfigurationsspeicher sowohl verwenden als auch erweitern können, um jede Website- oder Anwendungseigenschaft zu speichern.

Das System basiert auf XML-Dateien, die in einem einfachen und klaren Format mit einer ähnlichen Syntax wie ASP.NET web.config-Dateien definiert sind. Diese Konfigurationsdateien enthalten Einstellungen in logischen Gruppierungen, und alle Änderungen an den Dateien werden sofort auf der Website oder Anwendung wiedergegeben, deren Eigenschaften geändert werden.

Dieses neue System bietet auch eine delegierte Verwaltung, bei der Administratoren den Besitzern von Websites und Anwendungen erlauben können, bestimmte Einstellungen zu ändern. Die Auswirkungen dieser Änderungen sind auf die betreffende Website oder Anwendung beschränkt. In diesem Modell wird das Konzept eigenständiger Anwendungen eingeführt, bei denen sowohl Inhalte als auch Konfigurationseinstellungen im Website- oder Anwendungsverzeichnis gespeichert sind und per X-Kopie von einem Computer auf einen anderen bereitgestellt bzw. übertragen werden können.

Konfigurationsdateien und Konfigurationsschema

IIS 7.0 und höher verfügt über eine zentrale Konfigurationsdatei namens applicationHost.config in %WINDIR%\System32\InetSrv\Config\. Diese Datei ersetzt die metabase.xml Datei, die IIS 6.0 für den Konfigurationsspeicher verwendet hat. Dieses neue Konfigurationssystem ist sehr einfach, dateibasiert und dennoch sehr leistungsfähig. Es gibt keinen Konfigurationsdienst, da IISADMIN nicht erforderlich ist. Jeder Arbeitsprozess verfügt über eine Instanz einer Konfigurationsleseprogrammkomponente und ruft die Konfiguration direkt aus den Dateien ab.

Außerdem gibt es keine speicherinterne Darstellung der Konfiguration. Sobald eine Änderung an einer Datei ausgestellt wurde, wird sie sofort vom Arbeitsprozess abgerufen und auf der angegebenen Website, Anwendung oder im virtuellen Verzeichnis widergespiegelt.

Die Datei „applicationHost.config“ enthält globale Einstellungen für die verschiedenen Funktionen und Komponenten von IIS und anderen Webtechnologien. Alle in dieser Datei festgelegten Eigenschaften gelten für alle Websites, Anwendungen und virtuellen Verzeichnisse auf dem Computer.

Der von IIS verwendete Konfigurationsleser versteht das Format, die Syntax und die korrekte Benennung der einzelnen Konfigurationsabschnitte, Elemente und Attribute, da sie in einer Schemadatei definiert sind. Das Schema für die Konfiguration wird in Dateien definiert, die sich im %WINDIR%\System32\InetSrv\Config\Schema\-Verzeichnis befinden. Bei der Instanziierung des Konfigurationssystems liest der Arbeitsprozess das Schema in den Speicher ein. Dies hilft dem System, die Eigenschaften, die eingestellt werden können, und ihr Format zu verstehen. Mindestens befinden sich IIS_schema.xml-, ASPNET_schema.xml- und FX_schema.xml-Dateien in diesem Verzeichnis und definieren die Konfigurationsstruktur für Abschnitte, die für IIS, ASP.NET und die .NET Framework-Funktionen gelten.

Das Schema definiert verschiedene Aspekte der Konfiguration und ihrer Abschnitte, wie z. B. die Benennung von Abschnitten und Eigenschaften, die erwarteten Typen für Werte, den Bereich dieser Werte oder ob einige von ihnen eindeutig oder erforderlich sind. Außerdem definiert es den Standardwert, den ein bestimmtes Attribut annimmt. Wenn eine Eigenschaft nicht in applicationHost.config definiert ist, wird ihr Wert aus der Standardeinstellung übernommen, die in der Schemadatei angegeben wurde.

Zusätzlich zu dieser zentralen Datei, applicationHost.config, können auf jeder Ebene der URL-Hierarchie mehrere web.config-Dateien erscheinen. Diese Dateien können auf der Ebene der Site, der Anwendung, des virtuellen Verzeichnisses oder sogar des physischen Pfads erscheinen. Diese Dateien definieren Eigenschaften, deren Werte die globalen Einstellungen außer Kraft setzen, die in applicationHost.config definiert sind. Diese Änderungen gelten jedoch nur für den Bereich, in dem die Datei erscheint, d. h. für die angegebene Site, Anwendung, das virtuelle Verzeichnis oder den physischen Pfad, in dem sich die Datei „web.config“ befindet.

Konfigurationshierarchie und effektive Konfiguration

Neben applicationHost.config verwendet IIS ASP.NET, die sowohl auf den machine.config-Dateien als auch auf den Stammdateien „web.config“ basiert. Die Datei „machine.config“ definiert die Eigenschaften, die für alle Framework-Funktionen erforderlich sind. Die Stammdatei „web.config“ definiert die globalen Einstellungen für Eigenschaften, die für alle ASP.NET Webanwendungen definiert sind. Diese beiden Dateien sind analog zu applicationHost.config von IIS. Die drei Dateien sind vorhanden, da .NET Framework und IIS-Version separat vorhanden sind. Es können mehrere Versionen des Frameworks in einem bestimmten Windows Server-System installiert werden, das über eine einzelne Version von IIS verfügt.

Daher wird eine Konfigurationshierarchie für die Konfigurationseinstellungen des Systems definiert und berechnet. Die Hierarchie beginnt bei „machine.config“ und wird dann zur Stammdatei „web.config“ gefolgt von „applicationHost.config“ ausgeführt. Von da an wird jede optionale web.config-Datei, die sich auf der Ebene der Site, der Anwendung oder des virtuellen Verzeichnisses befindet, hinzugefügt und auf die Hierarchie angewendet. Am Ende vererben sich die Eigenschaften von der übergeordneten Datei auf die untergeordnete Datei, von der machine.config bis hin zur letzten web.config-Datei (falls vorhanden), und die effektive Konfiguration wird für einen bestimmten Pfad berechnet.

Das Vererbungsverhalten erfolgt standardmäßig. Jede Einstellung auf einer niedrigeren Ebene in der Hierarchie hat Vorrang vor einer übergeordneten Einstellung, die in einer Datei über der aktuellen Ebene definiert ist. Je weiter Sie jedoch in der Hierarchie nach unten gehen, desto eingeschränkter ist der Umfang der Konfiguration. Wenn die Einstellungen der Dateien „machine.config“, „root web.config“ und „applicationHost.config“ auf alle Elemente im System angewendet werden, gelten die Einstellungen der optionalen Web.config-Dateien nur für den aktuellen Speicherort und unten (unabhängig davon, ob es sich um eine Site, eine Anwendung oder ein virtuelles Verzeichnis handelt).

Konfigurationsabschnitte

Innerhalb einer Konfigurationsdatei gibt es mögliche Einstellungen, die gelesen und festgelegt werden können. Die Einstellungen sind in einer strukturierten Weise gruppiert. Mehrere Einstellungen, die ähnlich sind oder sich auf eine bestimmte Funktion beziehen (d. h. ASP, Authentifizierung, ISAPI usw.), werden in logische Einheitsblöcke gruppiert, die als Konfigurationsabschnitte bezeichnet werden. Jeder Konfigurationsabschnitt kann andere Konfigurationsabschnitte enthalten, definiert aber in der Regel Elemente, Sammlungen oder Attribute.

Ein Konfigurationselement ist ein XML-Element, das mehrere Konfigurationsattribute definiert. Eine Konfigurationssammlung ist ein Spezialfall eines Konfigurationselements, das eine Liste von Elementen enthält, die mit den Konfigurationsanweisungen hinzufügen/entfernen/löschen definiert wurden. Schließlich sind Konfigurationsattribute Blattkonfigurationseinstellungen, die XML-Attribute darstellen.

Das folgende Codeschnipsel zeigt die Einstellungen für den <defaultDocument>-Abschnitt. Das aktivierte Wort ist ein Attribut, bei dem das Wort Dateien ein Element ist, das eine Auflistung anderer Elemente enthält, welche durch die Anweisung Hinzufügen und eine Reihe von Attributen definiert sind.

<defaultDocument enabled="true"> 
    <files> 
        <add value="Default.htm" /> 
        <add value="Default.asp" /> 
        <add value="index.htm" /> 
        <add value="index.html" /> 
        <add value="iisstart.htm" /> 
        <add value="default.aspx" /> 
    </files> 
</defaultDocument>

Dieser Konfigurationsabschnitt verfügt über ein zugeordnetes Schema. Das folgende Codeschnipsel zeigt das Schema für den Abschnitt <defaultDocument> in der Datei „IIS_schema.xml“. Das Schema definiert den Namen des Abschnitts und den Namespace, in dem er angezeigt wird (in diesem Fall system.webServer). Außerdem beschreibt das Schema die Attribute und Elemente sowie für jeden Namen, Typ, Standardwerte und andere interessante Daten.

<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>

Ein spezieller Abschnitt: <configSections>

Der <configSections>-Konfigurationsabschnitt ist ein spezieller Abschnitt, der in applicationHost.config definiert ist. Er wird als Registrierungspunkt für die Konfigurationsabschnitte des IIS-Servers verwendet. In diesem Abschnitt werden die aktuellen Konfigurationsabschnitte registriert, die im System verfügbar sind. In dem Fall, dass das Konfigurationssystem erweitert wird und ein benutzerdefinierter Abschnitt zum Server hinzugefügt wird, muss dieser durch Hinzufügen eines Elementeintrags zu diesem Abschnitt registriert werden.

Das folgende Codeschnipsel zeigt den <configSections>-Eintrag für den <defaultDocument>-Abschnitt. Andere Einträge wurden aus Gründen der Klarheit weggelassen. Der interessante Teil des <configSections>-Abschnittsgruppeneintrags ist der Abschnittsgruppeneintrag, der den Namespace der einzelnen Abschnitte definiert – in diesem Fall system.webServer und den Wert des overrideModeDefault-Attributs, das für diesen Abschnitt „Zulassen“ lautet. Da „allowDefinition“ nicht deklariert ist, wird es aus dem Schema übernommen und der Standardwert ist „Überall“.

<configSections> 
    <sectionGroup name="system.webServer"> 
        <section name="defaultDocument" overrideModeDefault="Allow" />
    </sectionGroup>
</configSections>

Neben dem Definieren eines Abschnitts und seiner Abschnittsgruppe gibt es zwei Schlüsselattribute, die definiert sind: overrideModeDefault und allowDefinition.

Das Attribut „overrideModeDefault“ ist ein optionales Attribut, das den gesperrten Zustand eines Abschnitts definiert. Die verfügbaren Werte sind Zulassen oder Verweigern. Der Standardwert ist „Zulassen“. Alle IIS-Abschnitte, die mit allen Leistungs-, Sicherheits- oder kritischen Aspekten des Servers zusammenhängen, werden gesperrt, wobei dieses Attribut auf „Verweigern“ festgelegt ist. Wenn das overrideModeDefault-Attribut auf „Verweigern“ festgelegt ist, können alle Konfigurationsdateien auf einer niedrigeren Ebene (d. h. Web.config-Dateien), die einen Wert für eine Eigenschaft für den spezifischen Konfigurationsabschnitt festlegen, nicht wirksam werden und die globalen Werte überschreiben. Dies führt zu einem Verstoß gegen die Sperre und ein Fehler tritt auf.

Das allowDefinition-Attribut ist ein weiteres optionales Attribut, das die Ebene der Hierarchie definiert, in welcher der Abschnitt definiert werden kann und Eigenschaften festgelegt werden können. Wenn der Wert MachineOnly lautet, kann der Abschnitt nur in applicationHost.config oder machine.config festgelegt werden. Wenn der Wert MachineToRootWeb lautet, kann der Abschnitt entweder in den MachineOnly-Dateien oder auch in der Stammdatei web.config festgelegt werden. Wenn der Wert MachineToApplication lautet, kann der Abschnitt entweder in allen vorherigen drei Dateien oder auch in Web.config-Dateien im Anwendungsstammordner festgelegt werden. Und schließlich kann der Wert Überall (welcher die Standardeinstellung ist) in einer beliebigen Konfigurationsdatei festgelegt werden, unabhängig davon, ob die Dateien, die sich auf die Konfiguration global oder in Web.config-Dateien auswirken, die für eine bestimmte Site, eine Anwendung oder ein virtuelles Verzeichnis gelten.

Das Konzept des Standorts

Jede Einstellung, die in einer bestimmten Datei der Konfigurationshierarchie angegeben wird, gilt für diese Ebene und darunter, wobei die Möglichkeit besteht, dass sie von untergeordneten Dateien überschrieben wird. Es gibt jedoch die Option, Konfigurationseinstellungen für bestimmte Pfade unter der aktuellen Konfigurationsdatei mithilfe des Speicherort-Tags mit einem Pfadattribut anzugeben und anzuwenden. Wenn die Konfigurationsdatei „applicationHost.config“ lautet, können Speicherort-Tags einen Pfad enthalten, der von allen Sites, Anwendungen und virtuellen Verzeichnissen im System zu einer bestimmten Site, Anwendung, virtuellen Verzeichnis oder Datei reicht. Das Speicherort-Tag kann auch in Web.config-Dateien angegeben werden und kann einen beliebigen relativen Pfad für Pfade unterhalb der aktuellen Website, Anwendung oder des virtuellen Verzeichnisses enthalten.

Das folgende Codeschnipsel zeigt, wie Sie eine Konfigurationseigenschaft angeben, die nur für die Entwickler-Site gilt. Dies kann auch über eine web.config-Datei im Inhalt der Site erreicht werden. Die effektive Konfiguration für die Entwickler-Site besteht aus der Liste der Einträge für die Dateisammlung in der Datei applicationHost.config sowie dem Speicherortpfad und einer web.config-Datei für die Site.

<location path="Developer Site" overrideMode="Allow"> 
    <defaultDocument enabled="true"> 
        <files> 
            <add value="Developer.htm" /> 
        </files> 
    </defaultDocument> 
</location>

Wenn kein Pfad angegeben wird, was der Angabe eines Punkts (.) entspricht, wird der Pfad von dieser Ebene und darunter zu allen untergeordneten Pfaden verstanden. Wenn Sie dies in applicationHost.config tun, geben Sie auch die Konfiguration für die globale Ebene an.

Ein Attribut, das in einem Location-Tag definiert werden kann, ist der overrideMode. Wie overrideModeDefault gibt dies an, ob der angegebene Konfigurationsabschnitt, auf den im aktuellen Speicherort-Tag verwiesen wird, und die darin festgelegten Eigenschaften auf niedrigeren Ebenen der Hierarchie bearbeitet und überschrieben werden können.

Sperren und Entsperren eines Abschnitts

Das anfängliche Konzept der Sperrung eines Abschnitts über das overrideModeDefault-Tag im <configSections>-Abschnitt kann übernommen und erweitert werden, um feinkörniger zu sein. Indem ein Abschnitt auf der <configSections>-Ebene außer Kraft gesetzt werden kann, wird der Abschnitt geöffnet, und seine Werte können von jedem im System über Web.config-Dateien auf jeder Ebene des URL-Namespace außer Kraft gesetzt werden. Dies kann jedoch ein ernstes Sicherheitsrisiko darstellen und negative Auswirkungen auf die Verfügbarkeit oder Leistung des Systems verursachen. Über Positions-Tags kann man das overrideMode-Attribut verwenden und den Sperrzustand eines Abschnitts angeben und ihn für einen bestimmten Pfad einschränken.

Das folgende Codeschnipsel zeigt, wie Sie den <windowsAuthentication>-Abschnitt für alle Sites, Anwendungen und virtuellen Verzeichnisse im System entsperren. Dies geschieht durch Festlegen von „Zulassen“ im overrideModeDefault-Attribut. Der Nachteil dieses Ansatzes ist, dass er einen Bereich für jedermann freischaltet und jeder in der Lage ist, die Einstellungen auf Site- oder Anwendungsebene über web.config-Dateien außer Kraft zu setzen.

<section name="windowsAuthentication" overrideModeDefault="Allow" />

Das folgende Codeschnipsel zeigt, wie Sie dasselbe erreichen, indem Sie den <windowsAuthentication>-Abschnitt freischalten, allerdings nur für die AdministratorSite, sodass die Eigenschaften für diesen Abschnitt über web.config-Dateien auf der Ebene der AdministratorSite geändert werden können. Die anderen Sites im System weisen das Standardverhalten eines gesperrten <windowsAuthentication>-Abschnitts auf. Dies erfolgt über das overrideMode-Attribut.

<location path="AdministratorSite" overrideMode="Allow"> 
   <security> 
        <authentication> 
            <windowsAuthentication enabled="false"> 
                <providers> 
                    <add value="Negotiate" /> 
                    <add value="NTLM" /> 
                </providers> 
            </windowsAuthentication> 
        </authentication> 
   </security> 
</location> 
 
The location tag path can be specified here a site, application or even a virtual directory to which the administrator wants to unlock configuration and/or apply configuration at that level.

Das gegenteilige Verhalten kann erreicht werden, wodurch ein Abschnitt für eine bestimmte Site gesperrt wird, während der Rest des Systems ihn bearbeiten kann. <defaultDocument > ist beispielsweise ein Abschnitt, in dem das Attribut „overrideModeDefault“ im <configSections>- Abschnitt auf „Zulassen“ festgelegt ist, aber über ein Speicherort-Tag können wir diesen Abschnitt für die Standard-Site sperren. Die folgenden Codeschnipsel zeigen, wie Sie dies erreichen und gleichzeitig einstellen, dass der einzige Wert, der vom System als Standardseite für den Server akzeptiert wird, der Titel basic.htm ist. Die Anweisung „Löschen“ löscht alle geerbten Werte von höheren Ebenen in der Konfigurationshierarchie, die in diesem Fall die globale Auflistung der Dateien aus applicationHost.config ist.

<location path="Basic Site" overrideMode="Deny"> 
    <defaultDocument enabled="true"> 
        <files> 
       </clear> 
            <add value="basic.htm" /> 
        </files> 
    </defaultDocument> 
</location>

Granuläre Sperrung

Das Öffnen eines Abschnitts über ein Speicherort-Tag ist ein effektiver Weg, um einen Abschnitt und alle seine Eigenschaften für den Eigentümer der Site oder der Anwendung des angegebenen Pfads freizuschalten. Dies ist ein Alles-oder-Nichts-Ansatz, bei dem die Besitzer von Sites und Anwendungen unbegrenzten Zugriff auf einen Bereich haben. Manchmal möchten Administratoren jedoch eine spezifische Kontrolle über bestimmte Eigenschaften in einem Bereich und wünschen die Kontrolle über bestimmte Werte. Andere können delegiert werden. Hier kommt die granuläre Sperrung ins Spiel.

Die granuläre Sperrung ist eine Gruppierung bestimmter Attribute, die für Elemente oder andere Attribute festgelegt werden können. Die differenzierte Sperrung kann deklarieren, ob Pfade unterhalb des aktuellen Pfads die Konfigurationswerte ändern können. Werte können gelesen werden, aber wenn Sperrungen festgelegt sind, können sie nicht bearbeitet oder gar deklariert werden. Bearbeiten Sie keine Werte, bei denen Sperrungen gesetzt sind, da dies zu Fehlern bei Verstößen gegen Konfigurationssperren führt.

Das erste Attribut in der granulären Sperrgruppierung ist lockAttributes. Die lockAttributes definieren eine durch Trennzeichen getrennte Liste von Attributen, die für Pfade unter der aktuellen Konfigurationsebene gesperrt sind. Es akzeptiert auch ein Sternchen (*) als Wert, was bedeutet, dass alle Attribute gesperrt sind. An diesem Punkt kann der Konfigurationsabschnitt in Pfaden auf untergeordneter Ebene und sogar in den gesperrten Attributen gelesen werden, aber die Bearbeitung geschützter Attribute führt zu Fehlern.

Das folgende Codeschnipsel zeigt, wie der aktivierte Status des <defaultDocument>-Abschnitts für die Entwickler-Site gesperrt wird. Wenn der Besitzer der Entwickler-Site die Standarddokumentfunktion deaktiviert oder sogar die Eigenschaft mit demselben Wert deklariert, der im Speicherort-Tag angegeben ist, tritt ein Sperrverstoß auf.

<location path="Developer Site" > 
    <defaultDocument enabled="true" lockAttributes="enabled" /> 
</location>

Das zweite Attribut in der granulären Sperrgruppierung ist lockElements. Die lockElements definieren eine durch Trennzeichen getrennte Liste von Elementen, die für Pfade unter der aktuellen Konfigurationsstufe gesperrt sind. Wie lockAttributes akzeptiert es auch ein Sternchen (*) als Wert, was bedeutet, dass alle Elemente gesperrt sind. Dies ist sehr nützlich für Konfigurationsabschnitte mit mehreren Elementen oder Sammlungen und muss für Pfade auf untergeordneter Ebene geschützt werden. Auch hier führt die Bearbeitung eines der gesperrten Werte zu Fehlern.

Das folgende Codeschnipsel zeigt, wie sie die Dateisammlung für die Entwickler-Site sperren. Dies überlässt es dem Besitzer der Site, zu entscheiden, ob die Funktion für Standarddokumente aktiviert ist oder nicht. Wenn sie jedoch aktiviert ist, kann sie die globalen Werte nicht ändern und erbt das, was der Administrator des Computers in applicationHost.config angegeben hat.

<location path="Developer Site"> 
    <defaultDocument enabled="true" lockElements="files" > 
        <files> 
            <add value="Developer.htm" /> 
        </files> 
    </defaultDocument> 
</location>

Das Beispiel „lockElement“ ist auch in Sammlungen hilfreich, um die Anweisungen dieser Auflistung zu sperren. Die Anweisungen sind die Schlüsselwörter wie Hinzufügen, Entfernen, Löschen einer Sammlung. Durch das Sperren der Anweisungen kann ein Administrator genau festlegen, ob eine Sammlungsliste für das Hinzufügen oder Entfernen bestimmter oder aller Elemente verfügbar ist.

Das folgende Codeschnipsel zeigt, wie das Entfernen und Löschen von aktuellen Einträgen in der Dateisammlung gesperrt wird. Der Besitzer der Site kann der Dateisammlung bei Bedarf neue Einträge hinzufügen. Wenn der Besitzer der Site ein „Löschen“-Tag angibt oder versucht, einen Eintrag zu entfernen, tritt ein Sperrverstoß auf.

<location path="Developer Site"> 
    <defaultDocument enabled="true" > 
        <files lockElements="clear,remove"> 
            <add value="Developer.htm" /> 
        </files> 
    </defaultDocument> 
</location> 
 
Besides lockAttribute and lockElement, there are negative counterparts: lockAllAttributesExcept, and lockAllElementsExcept. These attributes achieve  the inverse action of the previous ones in which the comma-separated list declares the attributes and elements to be unlocked while the rest are not  available to be edited in child paths.

Es gibt auch ein lockItem-Attribut. Dies sperrt ein Attribut und funktioniert auf der Ebene der XML-Attribute. Das folgende Codeschnipsel zeigt, wie der Site-Administrator alles tun kann, was er tun möchte, z. B. Hinzufügen oder Entfernen von Einträgen in der Auflistung, mit Ausnahme der Änderung des basic.htm-Eintrags in der Dateisammlung.

<location path="Developer Site"> 
    <defaultDocument enabled="true" > 
        <files> 
            <add value="basic.htm" lockItem="true"/> 
        </files> 
    </defaultDocument> 
</location>

Zusammenfassung

In diesem Dokument wurde eine grundlegende Übersicht über das Konfigurationssystem, seine Dateien, Schema- und Delegierungsfunktionen beschrieben. Außerdem wurde die Konfigurationshierarchie und die effektive Konfiguration erörtert. Im Artikel wurde auch eine Einführung in Konfigurationsabschnitte und deren Struktur von Elementen und Attributen vorgestellt. Es veranschaulicht das Konzept von Speicherort, Sperren und granulärem Sperren.

Insgesamt führt der IIS ein neues dateibasiertes Konfigurationssystem ein, das die Möglichkeit bietet, die gesamte Konfiguration in einer zentralen Konfigurationsdatei zu speichern oder über web.config-Dateien zu verteilen, in denen Site- und Anwendungsadministratoren die für ihre Anwendungen und Inhalte geltenden Eigenschaften ändern können. Mit dem verteilten Konfigurationsmodell ist das Konzept eigenständiger Anwendungen, bei denen sowohl Inhalte als auch Konfigurationseinstellungen im Standort- oder Anwendungsverzeichnis gespeichert sind und X-Kopie von einem Computer auf einen anderen bereitgestellt werden kann, aktiviert.