Microsoft SharePoint Foundation als ASP.NET-Anwendung

Letzte Änderung: Freitag, 28. Januar 2011

Gilt für: SharePoint Foundation 2010

Inhalt dieses Artikels
Konfiguration von IIS und ASP.NET
Die Anforderungspipeline
Warum die Pipeline durch SharePoint verändert wird
Wie die Pipeline durch SharePoint verändert wird

In diesem Thema wird erklärt, inwiefern Microsoft SharePoint Foundation auf einem Satz von Modifikationen der integrierten Anforderungspipeline (Integrated Request Pipeline) von Internetinformationsdienste (Internet Information Services, IIS) und Microsoft ASP.NET aufbaut.

Hinweis
Das Zusammenspiel zwischen IIS und ASP.NET im integrierten Modus wird erklärt. Diese beiden Anwendungen können auch im klassischen Modus betrieben werden. Da sich SharePoint Foundation-Webanwendungen aber in Anwendungspools befinden müssen, für die der integrierte Modus verwendet wird, wird der klassische Modus in diesem Thema nicht weiter behandelt.

Hinweis
In diesem Thema werden zwar web.config-Dateien und zugehörige Dateien erläutert, die Anpassung dieser Dateien ist aber nicht Inhalt dieser Ausführungen. Informationen zum Anpassen der SharePoint Foundation-Konfiguration finden Sie unter Arbeiten mit Web.config-Dateien.

Konfiguration von IIS und ASP.NET

Konfigurationseinstellungen für IIS, ASP.NET und die darauf aufbauenden Websites, Anwendungen und Dienste werden in einer Hierarchie von Konfigurationsdateien gespeichert. Das dahinter stehende Prinzip ist, dass jede Datei in der Hierarchie einen engeren Bereich hat als die in der Hierarchie darüber befindlichen Dateien und innerhalb ihres Bereichs Einstellungen in Dateien außer Kraft setzen kann, die sich in der Hierarchie weiter oben befinden. Außerdem können einige der Einstellungen der Datei in einer dieser Konfigurationsdateien gesperrt werden. Dadurch wird verhindert, dass diese gesperrten Einstellungen durch Dateien, die in der Hierarchie weiter unten stehen, außer Kraft gesetzt werden.

• Ganz oben in der Hierarchie befindet sich die machine.config-Datei, und zwar im Verzeichnis %WinDir%\Microsoft.NET\Framework64\v2.0.50727\CONFIG\. Diese Datei enthält serverweite Einstellungen.

• Eine zweite serverweit geltende Konfigurationsdatei ist die globale web.config-Datei, die sich im gleichen Verzeichnis befindet.

  Hinweis

  SharePoint Foundation 2010 verwendet Microsoft ASP.NET 3.5, selbst wenn auch eine neuere Version von ASP.NET auf dem Front-End-Webserver installiert ist. Die Standard-machine.config-Datei oder die globale web.config-Datei wurde jedoch von Version 3.5 nicht geändert. Die jüngste Vorgängerversion der Anwendung, die diese Dateien änderte, ist Microsoft ASP.NET 2.0. Aus diesem Grund befinden sich die Dateien unter dem Zweig für Version 2.0 des Ordners %WinDir%\Microsoft.NET\Framework64\.

• Eine dritte serverweit geltende Konfigurationsdatei ist der IIS-Konfigurationsspeicher, der sich in der applicationhost.config-Datei befindet. Diese Datei ist im Verzeichnis %WinDir%\System32\inetsrv\config\ gespeichert und enthält Registrierungen der IIS-Websites und -Anwendungspools auf dem Server sowie bestimmte Einstellungen, die für alle Webanwendungen auf dem Webserver gelten. Die Einstellungen in applicationhost.config sind primär für die Teile der Pipeline vorgesehen, die von IIS eingebracht werden, während die machine.config-Datei und die globalen web.config-Dateien Einstellungen enthalten, die vor allem für die von ASP.NET eingebrachten Teile der integrierten Anforderungspipeline gelten.

• Jede IIS-Website kann eine eigene web.config-Datei in ihrem Stammverzeichnis haben, die websitespezifische Überschreibungen der Einstellungen enthält, die aus Konfigurationsdateien weiter oben in der Hierarchie geerbt werden, und die das Hinzufügen von neuen Einstellungen ermöglicht.

• Bestimmte physische oder virtuelle Verzeichnisse in einer IIS-Website können ebenfalls eine eigene web.config-Datei haben, mit der neue Einstellungen hinzugefügt oder geerbte Einstellungen überschrieben werden können. Die neuen Einstellungen und Überschreibungen gelten natürlich nur für HTTP-Anforderungen für Ressourcen, die sich in dem betreffenden Verzeichnis und dessen Unterverzeichnissen befinden.

Hinweis

Eine "Webanwendung" in der SharePoint Foundation-Terminologie hängt eng mit dem in der IIS-Terminologie als "Website" bezeichneten Objekt zusammen. Jede SharePoint Foundation-Webanwendung wird auf einer IIS-Website mit dem gleichen Namen gehostet, in der Regel nur auf einer einzigen IIS-Website. (Allerdings besteht die Möglichkeit, eine SharePoint Foundation-Webanwendung auf einen zusätzlichen Port zu erweitern. In diesem Fall wird die Webanwendung auf einer zusätzlichen IIS-Website gehostet). Aus diesem Grund finden Sie in der SharePoint Foundation-Dokumentation u. U. Verweise auf die web.config-Datei im Stammverzeichnis einer Webanwendung oder auf eine web.config-Datei in einem Verzeichnis einer Webanwendung. Das, worauf wirklich verwiesen wird, sind streng genommen die Stammverzeichnisse und Verzeichnisse der zugehörigen IIS-Website.

Das von diesen Konfigurationsdateien verwendete XML-Schema wird unter IIS 7.0: Settings Schema beschrieben. Weitere Informationen finden Sie unter ASP.NET Configuration Overview und Das Konfigurationssystem in IIS 7.0.

Die Anforderungspipeline

Wenn ein Front-End-Webserver eine Anforderung von einem Client erhält, wird die Anforderung durch eine Pipeline von Einheiten geleitet, die die Anforderung verarbeiten. Diese Verarbeitung umfasst die Authentifizierung des Benutzers, das Überprüfen der Autorisierung des Benutzers, das Erstellen und Senden der Antwort und schließlich das Protokollieren der Anforderung. Von der Versionshistorie her gesehen stammen einige dieser Einheiten ursprünglich aus früheren Versionen von IIS und andere aus ASP.NET, diese Unterscheidung ist jedoch für SharePoint Foundation von geringer Bedeutung.

HTTP-Handler

Die Antwort auf eine beliebige Anforderung wird durch ein HTTP-Handlerobjekt erzeugt. Anforderungen werden durch die *.config-Dateien dem einen oder anderen HTTP-Handlerobjekt zugewiesen (oder einer Handlerfactoryklasse, die HTTP-Handlerobjekte erstellt), je nach der angeforderten Ressource und dem HTTP-Verb in der Anforderung. Ein Beispiel: In einer unveränderten ASP.NET-Installation wird eine Anforderung einer ASPX-Datei, d. h. einer ASP.NET-Seite, mit dem Verb "GET" an ein PageHandlerFactory-Objekt gesendet, das ein Page-Objekt für die Verarbeitung der Anforderung erstellt. Nur Klassen, die – wie die Page-Klasse – die IHttpHandler-Klasse implementieren, können HTTP-Handler mit verwaltetem Code sein. Die Zuordnung eines Ressourcen-Verb-Paars zu einem Handler (oder einer Handlerfactory) wird im untergeordneten handlers-Element des system.webServer-Elements angegeben. Im Folgenden ein Beispiel für das handlers-Element, wobei die meisten untergeordneten Elemente der Kürze halber weggelassen wurden.

<location path="" overrideMode="Allow">
  <system.webServer>
    <handlers accessPolicy="Read, Script">
       ...
      <add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG"
           type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" />
      <add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG"
           type="System.Web.UI.SimpleHandlerFactory" preCondition="integratedMode" />
      <add name="WebServiceHandlerFactory-Integrated" path="*.asmx" verb="GET,HEAD,POST,DEBUG"
           type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, 
           Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
           preCondition="integratedMode,runtimeVersionv2.0" />
       ...
    </handlers>
       ...
  </system.webServer>
</location>

Das overrideMode-Attribut des location-Elements ist auf "Allow" festgelegt, sodass *.config-Dateien weiter unten in der Hierarchie eigene handler-Elemente haben können, die die Einstellungen hier überschreiben. Das path-Attribut ist auf die leere Zeichenfolge festgelegt, sodass diese Einstellungen dann für alle IIS-Websites gelten, es sei denn, sie werden in einer *.config-Datei überschrieben.

HTTP-Module

Die Anforderungspipeline enthält auch HTTP-Module. Module sind Assemblys, die typischerweise einen oder mehrere Ereignishandler enthalten oder neue Ereignisse definieren, die von anderen Modulen verarbeitet werden können. HTTP-Module können im Lebenszyklus der Anforderung für ein oder mehrere Ereignisse registriert werden. Sie werden häufig für die Vor- oder Nachverarbeitung von Anforderungen verwendet. Die Standardmodule sind in einem untergeordneten modules-Element des system.webServer-Elements registriert. Im Folgenden das Standard-modules-Element, wobei die meisten der untergeordneten Elemente der Kürze halber weggelassen wurden.

<location path="" overrideMode="Allow">
  <system.webServer>
        ...
    <modules>
       ...
      <add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" 
           preCondition="managedHandler" />
      <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
           preCondition="managedHandler" />
       ...
      <add name="RoleManager" type="System.Web.Security.RoleManagerModule" 
           preCondition="managedHandler" />
      <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" 
           preCondition="managedHandler" />
       ...
      <add name="UrlMappingsModule" type="System.Web.UrlMappingsModule" 
           preCondition="managedHandler" />
       ...
    </modules>
  </system.webServer>
</location>

Das preCondition-Attribut gibt eine Bedingung an, die eine Anforderung erfüllen muss, bevor das Modul auf sie angewendet wird. Hat das Attribut den Wert "managedHandler", dann wird das Modul auf Anforderungen für verwaltete Ressourcen angewendet (dies sind überwiegend ASP.NET-Ressourcen, z. B. ASPX-Dateien). Im Abschnitt Wie die Pipeline durch SharePoint verändert wird weiter unten wird beschrieben, wie SharePoint Foundation dieses Verhalten außer Kraft setzt, sodass diese Module auf alle Anforderungen angewendet werden, auch auf Nicht-ASP.NET-Ressourcen wie etwa statische HTML-Dateien. Weitere Informationen zu HTTP-Modulen finden Sie unter Einführung in die IIS 7.0-Architektur.

Warum die Pipeline durch SharePoint verändert wird

Im Folgenden finden Sie eine Liste der Gründe, warum die Standardkonfiguration der Pipeline durch SharePoint Foundation verändert werden muss:

1. Mit SharePoint Foundation wird eine neue, abstrakte "Webwelt" erstellt, in der nicht Seiten, sondern Listen und Listenelemente die Haupteinheiten der "Bevölkerung" sind. Natürlich ist es für die Anzeige und die Interaktion mit dieser Bevölkerung (zumindest, wenn diese über einen Browser erfolgt) erforderlich, dass die Daten aufbauend auf der vertrauten Webwelt aus in Browsern gerenderten Seiten implementiert werden. Doch die Listen bestehen unabhängig von einer bestimmten Seite, und eine bestimmte Liste kann auf mehreren Seiten angezeigt werden. Aus diesem Grund ist die Seitenstruktur einer Website in SharePoint Foundation für viele Zwecke von geringer Bedeutung.

   Betrachten wir einmal, wie es sich auswirkt, dass Websites auf Listen und nicht auf Seiten aufbauen. Eine Siteübersicht, die den Aufbau von Seiten zeigt, ist weit weniger interessant als eine Siteübersicht, in der die Listen zugeordnet sind. Daher ist eine Siteübersicht mit dem Listeninhalt wesentlich nützlicher als eine Übersicht über die Seiten der Website.

2. In ASP.NET-Anforderungshandlern wird generell davon ausgegangen, dass die URL einer angeforderten Ressource direkt dem Dateisystem des Front-End-Webservers zugeordnet wird. SharePoint Foundation speichert jedoch viele Ressourcen, z. B. angepasste Seiten, in einer Datenbank. Außerdem werden in SharePoint Foundation virtuelle Verzeichnisse intensiv genutzt, auch, wenn sich eine Datei im Dateisystem des Front-End-Webservers befindet. Dies geht über die einfache Standard-IIS-Zuordnung des virtuellen Stammverzeichnisses "\" des Servers zum physischen Verzeichnis "inetpub\wwwroot\" hinaus. Diese Technik wird u. a. dazu benötigt, dass SharePoint Foundation-Anwendungsseiten als Teil jeder Website innerhalb einer SharePoint Foundation-Webanwendung eingebunden werden können.

3. Standardmäßig verarbeiten die Module in der Pipeline, die von ASP.NET eingebracht werden, z. B. das FormsAuthentication-Modul, nur ASP.NET-spezifische Ressourcentypen, z. B. ASPX-Dateien. Für die Typen von Dateien, die in einer SharePoint Foundation-Dokumentbibliothek gespeichert werden können, gibt es jedoch keinerlei Beschränkung. In SharePoint Foundation müssen alle Anforderungen unabhängig vom Ressourcentyp durch diese Module verarbeitet werden. Wenn ein Benutzer beispielsweise eine E-Mail-Nachricht mit einem Link zu einer DOCX-Datei in einer SharePoint Foundation-Dokumentbibliothek erhält, muss dieser Benutzer authentifiziert werden, bevor er auf die Datei zugreifen kann.

4. Standardmäßig wird jede ASPX-Seite von ASP.NET bei der ersten Anforderung in eine Assembly kompiliert, die im Arbeitsspeicher geladen ist. SharePoint Foundation-Bereitstellungen enthalten in der Regel zu viele ASPX-Seiten, als dass dies praktikabel wäre. Der Arbeitsspeicher der Front-End-Webserver wäre überlastet, und es besteht keine Möglichkeit, diese Assemblys dynamisch aus dem Arbeitsspeicher zu entladen. Daher muss SharePoint Foundation die meisten ASPX-Seiten im unkompilierten Modus zur Verfügung stellen.

5. SharePoint Foundation ermöglicht die Delegierung der Verwaltung. Server und Farmen werden zwar weiterhin von IT-Spezialisten verwaltet, doch werden zahlreiche Aufgaben, die traditionell im Verantwortungsbereich von IT-Spezialisten oder Websitesdesignern lagen, z. B. die Erstellung von neuen Websites und Websiteseiten in SharePoint Foundation von Benutzern ausgeführt, die aus der Sicht des IT-Profis eher Amateure wären. Werden solche Befugnisse an Nicht-Profis delegiert, erfordert dies ein komplexeres Schema zur Steuerung von Vertrauensebenen und Berechtigungen.

6. Beim ASP.NET-Design wird generell davon ausgegangen, dass nur Personen, die über eine Administratorberechtigung zum Hinzufügen von Seiten verfügen, einer Website neue ASPX-Seiten hinzufügen. Daher vertraut die Anwendung jedem Steuerelement auf einer solchen Seite. In SharePoint Foundation haben dagegen weitaus mehr verschiedene Endbenutzer die Möglichkeit, ASPX-Seiten hinzuzufügen: jeder Benutzer, der über die Berechtigung Seiten hinzufügen und anpassen verfügt, kann Seiten hinzufügen. Dafür benötigt SharePoint Foundation ein System, nach dem Administratoren die auf einer Seite zulässigen Steuerelemente beschränken können. Und da diese von Benutzern erstellten Seiten Webparts enthalten können, brauchen Administratoren zudem eine Möglichkeit, die schiere Anzahl der Webparts und Steuerelemente zu begrenzen. Es ist auch notwendig, von Benutzern hinzugefügte Steuerelemente und Webparts im Hinblick auf den Typ von Code, der von ihnen ausgeführt werden kann, zu beschränken, um zu verhindern, dass fehlerhafter Code den Absturz des Webservers zur Folge hat. Dies wird in SharePoint erzwungen, indem diese Steuerelemente in einem eingeschränkten Ausführungsmodus ausgeführt werden müssen, der als abgesicherter Modus bezeichnet wird.

7. SharePoint Foundation macht ein Clientobjektmodell in einer Assembly verfügbar, die auf Clientcomputern installiert ist. Diese Assembly ermöglicht es, dass Code an den Server gesendet und im Batchmodus ausgeführt werden kann. Dazu muss ein Host auf dem Server die Batches verarbeiten. Ein solches Element ist in ASP.NET nicht integriert, da ASP.NET keine clientseitigen Assemblys enthält.

8. SharePoint Foundation unterstützt Workflows und ist eng in Windows Workflow Foundation integriert.

9. SharePoint Foundation enthält ein umfassendes System aus globalisierten Ressourcen, die in seinen ASPX- und ASCX-Dateien referenziert werden. Für diese werden spezialisierte Ausdrucks-Generatoren benötigt.

10. Die ASP.NET-Unterstützung für AJAX wurde für Microsoft ASP.NET 3.5 teilweise neu entworfen, und SharePoint Foundation unterstützt dieses neue Design mit benutzerdefinierten Handlern.

11. SharePoint Foundation enthält ein umfassend konfigurierbares System zur Anforderungseinschränkung, das das selektive Blockieren von HTTP-Anforderungen erlaubt, wenn ein Server ausgelastet ist. Die Blockierung basiert auf den Merkmalen der Anforderungen, z. B. der Identität des Benutzer-Agenten, dem Typ der angeforderten Ressourcen und den Informationen im Header.

12. SharePoint Foundation ermöglicht den Zugriff auf seine Websites von mobilen Geräten aus. Dies wird durch die automatische Umleitung von Anforderungen von mobilen Geräten auf spezielle für den mobilen Betrieb optimierte Versionen der Webseiten erreicht.

Wie die Pipeline durch SharePoint verändert wird

In diesem Abschnitt wird beschrieben, wie und wo SharePoint Foundation bei der Installation Änderungen an der integrierten Anforderungspipeline vornimmt. Dabei werden nur die wichtigsten Änderungen behandelt. Die fett dargestellten Zahlen in eckigen Klammern nach den jeweiligen Aufzählungspunkten für Änderungen in den folgenden Unterabschnitten geben an, dass die entsprechende Bedingung gemäß der Liste unter Warum die Pipeline durch SharePoint verändert wird die Änderung unterstützt.

Hinweis

SharePoint Foundation verändert jedoch nicht nur die Pipeline, sondern führt bei der Installation auch andere Konfigurationsänderungen auf den Front-End-Webservern aus. Beispielsweise werden IIS-Websites und Anwendungspools für eine erste SharePoint Foundation-Webanwendung, für die Zentraladministrationsanwendung von SharePoint Foundation und für die SharePoint Services-Plattform. (Die letzte dieser Websites und der letzte dieser Anwendungspools ersetzen eine UDDI-Website und einen UDDI-Anwendungspool, die bzw. der durch die Installation von SharePoint Foundation gelöscht wurde.) Außerdem werden Anwendungspools zur Unterstützung des Business Data Connectivity-Dienst (BDC), der Sicherheitstoken und der anspruchsbasierten Sicherheit erstellt. Diese weiteren Änderungen werden auch in der Hierarchie der Konfigurationsdateien beibehalten, in diesem Thema jedoch nicht behandelt.

Pipelineänderungen auf der Ebene von ASP.NET Framework

Keine. SharePoint Foundation nimmt keine Änderungen an der machine.config-Datei oder an der globalen web.config-Datei vor.

Pipelineänderungen auf der Ebene der IIS-Konfiguration

SharePoint Foundation ändert den IIS-Konfigurationsspeicher (applicationhost.config). Die wichtigsten Änderungen sind folgende:

• In SharePoint Foundation wird owssvr.dll als globales Modul namens SharePoint14Module registriert. Diese nicht verwaltete Assembly ist eine primäre Methode zum Übertragen von Anforderungen von Daten von den Front-End-Webservern in die SharePoint Foundation-Datenbanken. Sie verarbeitet Anforderungen an eine SharePoint Foundation-Webanwendung für nicht verwaltete Ressourcen. (ASP.NET-Ressourcen, z. B. AS?X-Dateien, sind verwaltete Ressourcen.) Durch die Registrierung wird die nicht verwaltete Assembly bestimmten IIS-Websites (und damit SharePoint Foundation-Webanwendungen) zur eigenen Verwendung zur Verfügung gestellt. (Verwaltete Module müssen nicht global registriert werden.) Weitere Informationen zu owssvr.dll finden Sie unter Remoteprozeduraufruf-Protokoll und den untergeordneten Themen. Im Folgenden wird die Registrierung gezeigt. (Zeilenumbrüche im Pfad sind im Original nicht vorhanden.) [2 und 3]

  Hinweis
  Alle Auszüge aus SharePoint Foundation-Konfigurationsdateien in diesem Thema wurden einer Vorabversion von SharePoint Foundation entnommen. Sie werden hier zur Veranschaulichung wiedergegeben und spiegeln nicht notwendigerweise den Inhalt der Dateien im veröffentlichten Produkt wider.

  <system.webServer>
     ...
    <globalModules>
        ...
        <!-- Other Unmanaged Modules -->
        ...
      <add name="SharePoint14Module" 
           image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
                  \14\isapi\owssvr.dll" />
    </globalModules>
  </system.webServer>
  

• Manche IT-Abteilungen möchten die ISAPI-Erweiterungen, die auf ihren Servern ausgeführt werden können, auf diejenigen beschränken, die in einem <isapiCgiRestriction>-Abschnitt der applicationhost.config-Datei explizit aufgelistet sind. Damit eine solche Vorgehensweise möglich ist, fügt SharePoint Foundation diesem Abschnitt owssvr.dll und drei eng damit zusammenhängende Assemblys hinzu. Im Folgenden wird die Registrierung gezeigt. (Zeilenumbrüche im Pfad sind im Original nicht vorhanden.) [2]

  <system.webServer>
     ...
    <security>
         ...
      <isapiCgiRestriction notListedIsapisAllowed="false" notListedCgisAllowed="false">
         ...
        <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
                   \14\isapi\_vti_aut\author.dll" allowed="true" 
             groupId="Windows SharePoint Services V4" 
             description="Windows SharePoint Services V4" />
        <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
                   \14\isapi\_vti_adm\admin.dll" allowed="true" 
             groupId="Windows SharePoint Services V4" 
             description="Windows SharePoint Services V4" />
        <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
                   \14\isapi\shtml.dll" allowed="true" 
             groupId="Windows SharePoint Services V4" 
             description="Windows SharePoint Services V4" />
        <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
                   \14\isapi\owssvr.dll" allowed="true" 
             groupId="Windows SharePoint Services V4" 
             description="Windows SharePoint Services V4" />
      </isapiCgiRestriction>
       ...
    </security>
     ...
  </system.webServer>
  

• Ein Abschnitt <site> wird in applicationhost.config immer dann erstellt, wenn SharePoint Foundation eine IIS-Website und einen Anwendungspool für eine SharePoint Foundation-Webanwendung erstellt. Der Hauptzweck dieses Abschnitts besteht darin, virtuelle Verzeichnisse physischen Verzeichnissen mit virtualDirectory-Elementen zuzuordnen. Im Folgenden wird ein Auszug aus einem <site>-Abschnitt gezeigt. (Zeilenumbrüche im Pfad sind im Original nicht vorhanden.) [2]

  <site name="SharePoint - 80" id="2055865624" serverAutoStart="true">
      <application path="/" applicationPool="SharePoint - 80">
          <virtualDirectory path="/" 
                            physicalPath="C:\inetpub\wwwroot\wss\VirtualDirectories\80" />
          <virtualDirectory path="/_vti_bin" 
                            physicalPath="C:\Program Files\Common Files\Microsoft Shared
                                          \Web Server Extensions\14\isapi" />
          <virtualDirectory path="/_layouts" 
                            physicalPath="C:\Program Files\Common Files\Microsoft Shared
                                          \Web Server Extensions\14\template\layouts" />
          <virtualDirectory path="/_controltemplates" 
                            physicalPath="C:\Program Files\Common Files\Microsoft Shared
                                          \Web Server Extensions\14\template\controltemplates" />
            ...
      </application>
       ...
  </site>
  

Pipelineänderungen auf der Ebene der SharePoint-Webanwendung

Wenn eine SharePoint Foundation-Webanwendung (und eine zugehörige IIS-Website) erstellt wird, wird deren Stammverzeichnis eine web.config-Datei hinzugefügt. Diese Datei enthält die folgenden Konfigurationseinstellungen, die die auf Ebenen weiter oben in der Konfigurationshierarchie festgelegten Einstellungen entweder ergänzen oder außer Kraft setzen. Weitere Informationen zu dieser Datei und deren Modifikation in SharePoint Foundation-Entwicklungsprojekten finden Sie unter Arbeiten mit Web.config-Dateien.

• Ein <SafeMode>-Abschnitt konfiguriert das Verarbeitungssystem im abgesicherten Modus. Es folgt das SharePoint Foundation-Standardelement SafeMode unmittelbar nach der Installation. Beachten Sie, dass das CallStack-Attribut auf false festgelegt wird. Dadurch werden die meisten Systemausnahmeinformationen blockiert, die andernfalls von ASP.NET gemeldet würden. Dies geschieht, um die Weitergabe von Informationen zu verhindern. [5 und 6]

  SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
  ...
  </SafeMode>
  

• Ein <SafeControls>-Abschnitt gibt die Steuerelemente an, deren Ausführung im abgesicherten Modus zulässig ist. Benutzerdefinierte Websiteseiten werden im abgesicherten Modus ausgeführt, Anwendungsseiten nicht. Dadurch wird sichergestellt, dass Benutzer keine Websiteseiten hinzufügen können, die ein Steuerelement enthalten, das nicht von einem Administrator zur Ausführung auf einer Websiteseite freigegeben wurde. (Benutzer sind nicht berechtigt, Anwendungsseiten hinzuzufügen.) Jedes SafeControl-Element im Abschnitt kann eine bestimmte Steuerelementklasse – oder mehrere Klassen mithilfe von Platzhaltern – in einer Assembly als sicher registrieren. (Sie können der Datei zusätzliche SafeControl-Elemente als Teil der Bereitstellung Ihres Entwicklungsprojekts hinzufügen. Weitere Informationen zur entsprechenden Vorgehensweise finden Sie unter Gewusst wie: Erstellen einer ergänzenden .config-Datei und SafeControl-Element (Lösung).) Im Folgenden wird ein Auszug aus dem <SafeControls>-Abschnitt gezeigt. [5 und 6]

  <SharePoint>
     ...
    <SafeControls>
      <SafeControl Assembly="System.Web, Version=1.0.5000.0, Culture=neutral, 
                   PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" 
                   TypeName="*" Safe="True" AllowRemoteDesigner="True" />
       ...
       <!-- Other ASP.NET classes -->
       ...
      <SafeControl Assembly="System.Web, Version=2.0.0.0, Culture=neutral, 
                   PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" 
                   TypeName="SqlDataSource" Safe="False" AllowRemoteDesigner="False" />
       ...
       <!-- SharePoint classes from earlier versions of the SharePoint assemblies  -->
       ...
      <SafeControl Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint" 
                   TypeName="*" Safe="True" AllowRemoteDesigner="True" />
       ...
       <!-- Other SharePoint classes from the current version of the SharePoint assemblies  -->
       ...
      <SafeControl Src="~/_controltemplates/*" IncludeSubFolders="True" Safe="True" 
                   AllowRemoteDesigner="True" />
       ...    
    </SafeControls>
     ...
  </SharePoint>
  

  Wie Sie sehen, registriert das letzte SafeControl-Element in dem Auszug die unkompilierten ASCX-Steuerelemente im virtuellen Verzeichnis _controltemplates, das dem Verzeichnis %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\CONTROLTEMPLATES zugeordnet ist, als sicher.

• Ein <pages>-Abschnitt wird hinzugefügt. Dieser gibt den benutzerdefinierten SharePoint Foundation-Seitenparserfilter (abgeleitet von PageParserFilter) an, der nach unsicheren Steuerelementen sucht. Der Filter stellt außerdem fest, ob die Seite kompiliert oder im unkompilierten Modus bereitgestellt werden soll. Im Folgenden wird die Registrierung gezeigt. [4, 5 und 6]

  <pages enableSessionState="false" enableViewState="true" 
              enableViewStateMac="true" validateRequest="false" 
              pageParserFilterType="Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter, 
               Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
               PublicKeyToken=71e9bce111e9429c" asyncTimeout="7">
   ...
  </pages>
  

• Ein <modules>-Abschnitt überschreibt die geerbte Konfiguration auf folgende Weise:

  • Das runAllManagedModulesForAllRequests-Attribut wird auf true festgelegt. Dies bewirkt, dass die "managedHandler"-Vorbedingungen im IIS-Konfigurationsspeicher überschrieben werden. Dadurch gelten die verwalteten Codeteile in der Pipeline (einschließlich derer, die durch ASP.NET eingebracht werden, z. B. für die Benutzerauthentifizierung) für alle Anforderungen, unabhängig davon, ob die angeforderte Ressource ein verwalteter Typ ist oder ASP.NET in irgendeiner bestimmten Weise zugeordnet ist. [3]

  • Bestimmte von SharePoint Foundation nicht verwendete Module werden entfernt, andere werden hinzugefügt, darunter SharePoint14Module (dies ist ein anderer Name für die owssvr.dll-Datei). (Dieses nicht verwaltete Modul wird im IIS-Konfigurationsspeicher als globales Modul registriert. Es muss auch hier für die Verwendung durch diese Webanwendung aktiviert werden.) [2]

    Auch SPRequestModule wird hinzugefügt. Folgende Aufgaben werden durch dieses Modul ausgeführt:

    • Es registriert den SharePoint Foundation-Anbieter von virtuellen Pfaden, ein Objekt einer internen Klasse, das VirtualPathProvider implementiert. Der Pfadanbieter dient als URL-Interpreter. Wenn beispielsweise eine Anforderung für eine Websiteseite empfangen wird, die der Websitebesitzer angepasst hat, zeigt die URL scheinbar auf einen Speicherort im physischen Dateisystem, tatsächlich aber übersetzt der SharePoint Foundation-Pfadanbieter die URL in einen Speicherort in der Inhaltsdatenbank. Dank des Pfadanbieters kann SharePoint Foundation außerdem zwei verschiedene URL-Typen unterstützen: serverrelative und websiterelative. Der Pfadanbieter löst die "~"-Token auf, die in bestimmten Dateipfaden enthalten sind, z. B. in Pfaden für Gestaltungsvorlagendateien. Er überprüft, ob eine angeforderte Datei in einer Dokumentbibliothek ausgecheckt ist. Und schließlich interpretiert der Pfadanbieter URLs, die virtuelle Ordner enthalten, und löst sie in die tatsächlichen physischen URLs auf. Hat der Pfadanbieter eine ASPX-Seite abgerufen, übergibt er sie an den Seitenparserfilter, der ermittelt, ob die Seite unsicheren Code enthält. Ist dies nicht der Fall, wird die Datei an den ASP.NET-Seitenparser übergeben. [2]

    • Das Modul stellt fest, ob eine Anforderung an owssvr.dll weitergeleitet werden soll. Falls ja, verarbeitet es die HTTP-Header in der Anforderung für owssvr.dll. [2 und 3]

    • Es steuert die Leistungsüberwachung und das System zur Anforderungseinschränkung. Es kann Anforderungen selektiv blockieren, wenn der Server zu stark ausgelastet ist, um alle empfangenen Anforderungen zu verarbeiten. [11]

    • Es stellt fest, ob die Anforderung von einem mobilen Gerät stammt. Ist dies der Fall, wird die Anforderung an die entsprechende mobile Seite weitergeleitet. [12]

    Im Folgenden wird der <modules>-Abschnitt gezeigt.

    <system.webServer>
       ...
      <modules runAllManagedModulesForAllRequests="true">
        <remove name="AnonymousIdentification" />
        <remove name="FileAuthorization" />
        <remove name="Profile" />
        <remove name="WebDAVModule" />
        <add name="SPRequestModule" preCondition="integratedMode" 
             type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, 
                   Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
        <add name="ScriptModule" preCondition="integratedMode" 
             type="System.Web.Handlers.ScriptModule, System.Web.Extensions, 
                   Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        <add name="SharePoint14Module" preCondition="integratedMode" />
      </modules>
       ...
    </system.webServer>
    

• Ein <handlers>-Abschnitt überschreibt die geerbte Konfiguration, im Wesentlichen durch Entfernen einiger HTTP-Handlers, die in SharePoint Foundation nicht verwendet werden, und durch Hinzufügen von Handlern, die AJAX unterstützen. Außerdem wird owssvr.dll unter dem Namen OwssvrHandler als HTTP-Handler registriert. Das ist erforderlich, damit Anforderungen während des MapRequestHandler-Ereignisses dorthin weitergeleitet werden können. (Anforderungen für nicht verwaltete Ressourcen werden von OwssvrHandler verarbeitet.) Weitere Informationen zu den Ereignissen im Lebenszyklus von Anforderungen finden Sie unter ASP.NET Application Life Cycle Overview for IIS 7.0. Im Folgenden wird der <handlers>-Abschnitt gezeigt. (Zeilenumbrüche in den Pfaden sind im Original nicht vorhanden.) [3 und 10]

  <system.webServer>
     ...
    <handlers>
      <remove name="OPTIONSVerbHandler" />
      <remove name="WebServiceHandlerFactory-Integrated" />
      <remove name="svc-Integrated" />
      <remove name="WebDAV" />
      <add name="svc-Integrated" path="*.svc" verb="*" 
           type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, 
           Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode" />
      <add name="OwssvrHandler" 
           scriptProcessor="C:\Program Files\Common Files\Microsoft Shared
                            \Web Server Extensions\14\isapi\owssvr.dll"
           path="/_vti_bin/owssvr.dll" verb="*" modules="IsapiModule" preCondition="integratedMode" />
      <add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode"
           type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, 
                 Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" 
           preCondition="integratedMode" 
           type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, 
                 Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" 
           path="ScriptResource.axd" 
           type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, 
                 Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </handlers>
  </system.webServer>
  

• Ein <microsoft.sharepoint.client>-Abschnitt wird hinzugefügt, um das Clientobjektmodell von SharePoint Foundation und die clientseitige Programmierung zu unterstützen. (Weitere Informationen zu diesem Objektmodell finden Sie unter Verwenden der Client-APIs.) Das folgende Markup zeigt diesen Abschnitt. [7]

  <microsoft.sharepoint.client>
    <serverRuntime>
      <hostTypes>
        <add type="Microsoft.SharePoint.Client.SPClientServiceHost, Microsoft.SharePoint, 
                   Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      </hostTypes>
    </serverRuntime>
  </microsoft.sharepoint.client>
  

• Des Weiteren werden mehrere Abschnitte zur Unterstützung von Limits für Webparts und die Anzahl der Steuerelemente hinzugefügt. [5 und 6]

  <WebPartLimits MaxZoneParts="50" PropertySize="1048576" />
  <WebPartCache Storage="CacheObject" />
  <WebPartControls DatasheetControlGuid="65BCBEE4-7728-41a0-97BE-14E1CAE36AAE" />
  

• Ein <WorkflowServices>-Abschnitt und ein <System.Workflow.ComponentModel.WorkflowCompiler>-Abschnitt werden zur Unterstützung von Workflows in SharePoint Foundation hinzugefügt. Das folgende Markup zeigt den <WorkflowServices>-Abschnitt und darunter einen Auszug aus dem <System.Workflow.ComponentModel.WorkflowCompiler>-Abschnitt.[8]

  <SharePoint>
    ...
    <WorkflowServices>
      <WorkflowService Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                                 PublicKeyToken=71e9bce111e9429c" 
                                 Class="Microsoft.SharePoint.Workflow.SPWinOEWSSService">
      </WorkflowService>
      <WorkflowService Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                                 PublicKeyToken=71e9bce111e9429c" 
                                 Class="Microsoft.SharePoint.Workflow.SPWinOETaskService">
      </WorkflowService>
     </WorkflowServices>
  </SharePoint>
  ...
   <System.Workflow.ComponentModel.WorkflowCompiler>
    <authorizedTypes>
        <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, 
                                  PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" 
                                  TypeName="*" Authorized="True" />
        <authorizedType Assembly="System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral,
                                  PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" 
                                  TypeName="*" Authorized="True" />
        <authorizedType Assembly="System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, 
                                  PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Runtime"
                                  TypeName="CorrelationToken" Authorized="True" />
        <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, 
                                  PublicKeyToken=b77a5c561934e089" Namespace="System" 
                                  TypeName="Guid" Authorized="True" />
       ...
       <-- Other mscorlib classes -->
       ...
        <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                                  PublicKeyToken=71e9bce111e9429c" 
                                  Namespace="Microsoft.SharePoint.Workflow" 
                                  TypeName="SPWorkflowActivationProperties" Authorized="True" />
        <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                                  PublicKeyToken=71e9bce111e9429c" 
                                  Namespace="Microsoft.SharePoint.Workflow" 
                                  TypeName="SPWorkflowTaskProperties" Authorized="True" />
        <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                                  PublicKeyToken=71e9bce111e9429c" 
                                  Namespace="Microsoft.SharePoint.Workflow" 
                                  TypeName="SPWorkflowHistoryEventType" Authorized="True" />
        <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                                  PublicKeyToken=71e9bce111e9429c" 
                                  Namespace="Microsoft.SharePoint.Workflow" 
                                  TypeName="SPItemKey" Authorized="True" />
        <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                                  PublicKeyToken=71e9bce111e9429c" 
                                  Namespace="Microsoft.SharePoint.Workflow" 
                                  TypeName="SPWorkflowUserContext" Authorized="True" />
        <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=14.0.0.0, 
                                  Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
                                  Namespace="Microsoft.SharePoint.WorkflowActions" 
                                  TypeName="*" Authorized="True" />
    </authorizedTypes>
  </System.Workflow.ComponentModel.WorkflowCompiler>
  

• Mithilfe eines <securityPolicy>-Abschnitts werden zwei zusätzliche Vertrauensebenen hinzugefügt, WSS_Minimal und WSS_Medium. Diese Vertrauensebenen sind in Dateien definiert, die sich im Verzeichnis %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG befinden. Das folgende Markup zeigt den <securityPolicy>-Abschnitt. (Zeilenumbrüche in den Pfaden sind im Original nicht vorhanden.) [5]

  <system.web>
    <securityPolicy>
      <trustLevel name="WSS_Medium" 
       policyFile="C:\Program Files\Common Files\Microsoft Shared
                   \Web Server Extensions\14\config\wss_mediumtrust.config" />
      <trustLevel name="WSS_Minimal" 
       policyFile="C:\Program Files\Common Files\Microsoft Shared
                   \Web Server Extensions\14\config\wss_minimaltrust.config" />
    </securityPolicy>
   ...
  </system.web>
  

• Ein <compiliation>-Abschnitt informiert den Seitenparser über vier zusätzliche Assemblys, die er zum Kompilieren von SharePoint Foundation-AS?X-Dateien verwenden kann. Er gibt außerdem vier spezielle Ausdrucks-Generatoren an, mit denen der Seitenparser ASP.NET-Seiten und andere AS?X-Steuerelemente in einer SharePoint Foundation-Webanwendung verarbeiten kann. Das folgende Markup zeigt den <compiliation>-Abschnitt. [9]

  <system.web>
     ...
    <compilation batch="false" debug="false">
      <assemblies>
        <add assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                       PublicKeyToken=71e9bce111e9429c" />
        <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
                       PublicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, 
                       PublicKeyToken=71e9bce111e9429c" />
        <add assembly="Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, 
                       PublicKeyToken=71e9bce111e9429c" />
      </assemblies>
      <expressionBuilders>
        <remove expressionPrefix="Resources" />
        <add expressionPrefix="Resources" 
             type="Microsoft.SharePoint.SPResourceExpressionBuilder, 
                   Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" />
        <add expressionPrefix="SPHtmlEncodedResources" 
             type="Microsoft.SharePoint.SPHtmlEncodedResourceExpressionBuilder, 
                   Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" />
        <add expressionPrefix="SPSimpleFormattingEncodedResources" 
             type="Microsoft.SharePoint.SPSimpleFormattingEncodedResourceExpressionBuilder, 
                   Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" />
        <add expressionPrefix="SatelliteResources" 
             type="Microsoft.SharePoint.Search.SPSatelliteResourceExpressionBuilder, 
                   Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" />
      </expressionBuilders>
    </compilation>
  ...
  </system.web>
  

• Ein <sitemap>-Abschnitt gibt vier spezielle SharePoint Foundation-Siteübersichtsanbieter an. Das folgende Markup zeigt den <sitemap>-Abschnitt. [1]

  <system.Web>
     ...
    <siteMap defaultProvider="SPSiteMapProvider" enabled="true">
      <providers>
        <add name="SPNavigationProvider" 
             type="Microsoft.SharePoint.Navigation.SPNavigationProvider, 
                   Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" />
        <add name="SPSiteMapProvider" 
             type="Microsoft.SharePoint.Navigation.SPSiteMapProvider, 
                   Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" />
        <add name="SPContentMapProvider" 
             type="Microsoft.SharePoint.Navigation.SPContentMapProvider, 
                   Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" />
        <add name="SPXmlContentMapProvider" siteMapFile="_app_bin/layouts.sitemap"
             type="Microsoft.SharePoint.Navigation.SPXmlContentMapProvider, 
                   Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, 
                   PublicKeyToken=71e9bce111e9429c" />
      </providers>
    </siteMap>
     ...
  </system.Web>
  

Hinweis

Die Anwendung für die Zentraladministration von SharePoint Foundation wird als eine SharePoint Foundation-Webanwendung implementiert und somit als eine IIS-Website. Sie enthält ebenfalls eine web.config-Datei im Stammverzeichnis, die der oben beschriebenen web.config-Datei sehr ähnlich ist. Die Hauptunterschiede bestehen darin, dass die Anwendung für die Zentraladministration Sitzungszustände unterstützt und zusätzliche Siteübersichtsanbieter und einige zusätzliche Steuerelemente als sicher registriert. Auch die IIS-Website, die die SharePoint Services-Plattform hostet, enthält eine sehr kleine web.config-Datei im Stammverzeichnis. Diese wird auch zum Registrieren von Anbietern verwendet, die anspruchsbasierte Sicherheit unterstützen.

Pipelineänderungen auf Verzeichnisebene

In SharePoint Foundation wird die Anforderungspipeline durch web.config-Dateien, die nur für Anforderungen für Ressourcen in bestimmten physischen oder virtuellen Verzeichnissen gelten, weiter differenziert. An dieser Stelle sei nur ein Beispiel gegeben: SharePoint Foundation stellt Versionen seiner Anwendungsseiten und Formulare bereit, die für die Anzeige auf mobilen Geräten vorgesehen sind. Diese Versionen befinden sich im virtuellen Verzeichnis _layouts\mobile (das dem physischen Verzeichnis %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\ zugeordnet ist). Dieses Verzeichnis enthält eine web.config-Datei, die Grenzwerte für die auf der Seite angezeigte Datenmenge festlegt. Sie registriert außerdem eine Reihe von Filtern, die das Rendering der Seite basierend auf den Funktionen des mobilen Geräts steuern, auf dem sich die angeforderte Seite befindet.

Siehe auch

Weitere Ressourcen

ASP.NET Application Life Cycle Overview for IIS 7.0

ASP.NET Configuration Overview

IIS 7.0: Settings Schema

Einführung in die IIS 7.0-Architektur

Das Konfigurationssystem in IIS 7.0