Entwurfsbeispiel: Bereitstellung im Unternehmen (SharePoint Server 2010)

 

Gilt für: SharePoint Foundation 2010, SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2017-01-18

In diesem Artikel wird die praktische Implementierung logischer Architekturkomponenten zur Erstellung eines funktionsfähigen Entwurfs beschrieben. Dieser Artikel ist für die Verwendung mit den folgenden Entwurfsbeispielen vorgesehen:

• Entwurfsbeispiel: Unternehmensportal mit klassischer Authentifizierung

• Entwurfsbeispiel: Unternehmensportal mit anspruchsbasierter Authentifizierung

Auf folgender Website können diese beiden Entwurfsbeispiele heruntergeladen werden: SharePoint Server 2010-Entwurfsbeispiele: Unternehmensportal mit klassischer oder anspruchsbasierter Authentifizierung (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x407).

Inhalt dieses Artikels

• Informationen zu den Entwurfsbeispielen

• Allgemeine Entwurfsziele

• Serverfarmen

• Benutzer, Zonen und Authentifizierung

• Dienste

• Erstellungs- und Veröffentlichungsalternativen

• Administrationswebsites

• Anwendungspools

• Webanwendungen

• Websitesammlungen

• Inhaltsdatenbanken

• Zonen und URLs

• Zonenrichtlinien

Die Entwurfsbeispiele veranschaulichen eine allgemeine unternehmensweite Bereitstellung von Microsoft SharePoint Server 2010. Die Entwurfsbeispiele enthalten nahezu alle logischen Architekturkomponenten und verdeutlichen deren Integration in den Gesamtentwurf. Die beiden Beispiele veranschaulichen dieselben Dienste und Websites, basieren aber auf unterschiedlichen Authentifizierungsmethoden:

• Klassische Authentifizierung: Dieses Entwurfsbeispiel stellt eine Möglichkeit des Upgrades von Websites von Microsoft Office SharePoint Server 2007 auf Microsoft SharePoint Server 2010 dar. Dieser Entwurf arbeitet mit der klassischen Authentifizierung, bei der für den Zugriff auf Websites Windows-Authentifizierungsmethoden genutzt werden. Für jede Authentifizierungsmethode wird eine andere Zone verwendet. Während die Windows-Authentifizierung für SharePoint-Websites verwendet wird, kann ein Firewall- oder Gatewayprodukt für die Formularauthentifizierung konfiguriert werden, um Windows-Anmeldeinformationen zu erfassen, die an SharePoint Server 2010 weitergeleitet werden. Die Konten der Mitarbeiter von Partnern werden dem Unternehmensverzeichnis hinzugefügt.

• Anspruchsbasierte Authentifizierung: Dieses Entwurfsbeispiel arbeitet mit dem neuen anspruchsbasierten Authentifizierungsmodell. Mehrere Authentifizierungsanbieter und -typen werden in einer einzelnen Zone implementiert. Die anspruchsbasierte Authentifizierung unterstützt die formularbasierte Authentifizierung, die auf SAML-Token basierende Authentifizierung und die Windows-Authentifizierung. Bei diesem Entwurfsbeispiel werden Partnerunternehmen unter Verwendung der auf SAML-Token basierenden Authentifizierung hinzugefügt, damit eine direkte Authentifizierung im Abgleich mit Partnerverzeichnissen erfolgen kann. Für die Konten der Mitarbeiter von Partnern gibt es mehrere Anbieteroptionen.

Wählen Sie das Entwurfsbeispiel, das Ihren Authentifizierungsanforderungen am ehesten entspricht.

In diesem Artikel werden die Entwurfsziele der Beispiele beschrieben, und es wird erläutert, wie diese Ziele mithilfe der in den Beispielen veranschaulichten Komponenten der logischen Architektur erreicht werden.

Informationen zu den Entwurfsbeispielen

Die Entwurfsbeispiele veranschaulichen eine Unternehmensbereitstellung für ein fiktives Unternehmen namens Fabrikam, Inc. Die Bereitstellung umfasst zwei Serverfarmen. Eine Serverfarm hostet das Firmenintranet und die Partnerwebsite. Die zweite Farm hostet die Unternehmenswebsite (www.fabrikam.com). Im Rest dieses Abschnitts werden diese Websites auf oberster Ebene beschrieben.

Intranet

Das Unternehmensintranet umfasst die folgenden Websites:

• Veröffentlichter Intranetinhalt (z. B. HRweb)

• Teamwebsites für die Zusammenarbeit

• Meine Websites

Diese Komponenten bilden gemeinsam die inhalts- und zusammenarbeitsorientierten Websites, die die Mitarbeiter täglich verwenden. Einzeln betrachtet stellt jede dieser Anwendungen einen unterschiedlichen Inhaltstyp dar. Jeder Inhaltstyp:

• Hebt die unterschiedlichen Features von SharePoint Server 2010 hervor.

• Hostet Daten mit verschiedenen Datenmerkmalen.

• Unterliegt einem anderen Verwendungsprofil.

• Erfordert eine andere Strategie für die Berechtigungsverwaltung.

Folglich sollen durch die Entwurfsentscheidungen für jede dieser Anwendungen die Leistung und Sicherheit der jeweiligen Anwendung optimieren werden.

In diesem Dienstanwendungsentwurf werden diese drei Anwendungen zusammengeführt, um Folgendes zu ermöglichen:

• Die Navigation zwischen den Anwendungen

• Suchen im Unternehmen

• Gemeinsam genutzte Profildaten und Unternehmensmetadaten

In der folgenden Abbildung werden die drei Anwendungen gezeigt, die das Unternehmensintranet bilden.

Die URLs in dieser Abbildung stammen aus dem Entwurfsbeispiel mit klassischer Authentifizierung.

Partnerwebanwendung

Die Partnerwebanwendung hostet extern verfügbare Websites für eine sichere Zusammenarbeit mit den Mitarbeitern von Partnerunternehmen und einzelnen Partnern. Diese Anwendung ist dafür vorgesehen, dass Mitarbeiter Websites für eine sichere Zusammenarbeit problemlos erstellen können. Partner sind nicht berechtigt, auf andere Inhaltstypen zuzugreifen, die in der Serverfarm gehostet werden. Der Entwurf für Zonen und Dienstanwendungen unterstreicht dieses Ziel.

Im Entwurfsbeispiel wird die Partnerwebanwendung von der gleichen Farm gehostet wie der Intranetinhalt.

Internetwebsite des Unternehmens

Die Internetwebsite des Unternehmens stellt die Internetpräsenz des Unternehmens dar. Der Inhalt wird den Kunden über eine Konfiguration mit anonymem Zugriff und Leseberechtigung zur Verfügung gestellt. Es folgen die Hauptfaktoren der Entscheidung für diese Anwendung:

• Inhaltliche Trennung: Kunden können nicht auf andere Inhaltstypen zugreifen, die auf der Serverfarm gehostet werden.

• Gezielte Verwaltung: Ein authentifizierter Zugriff wird nur Mitarbeitern gewährt, die die Website verwalten bzw. Verwaltungs- und Dokumenterstellungsaufgaben erfüllen.

• Sichere Inhalterstellung und Veröffentlichung: Eine gesonderte Websitesammlung wird in Farm A in der Partnerwebanwendung für die Dokumenterstellung gehostet. Dies ermöglicht eine sichere Zusammenarbeit und Entwicklung von Inhalten sowohl mit internen als auch mit Remotemitarbeitern sowie mit redaktionellen Partnern, die auf die Websiteentwicklung oder Inhaltserstellung spezialisiert sind. Die Inhaltsveröffentlichung ist so konfiguriert, dass Inhalte aus der Websitesammlung für die Dokumenterstellung in der ersten Farm automatisch in der Websitesammlung für die Produktion in der zweiten Farm veröffentlicht werden. Die folgende Abbildung veranschaulicht den Veröffentlichungsprozess.

Allgemeine Entwurfsziele

Die Entwurfsbeispiele veranschaulichen eine praktische Implementierung von SharePoint Server 2010-Features in mehreren häufig verwendeten Anwendungstypen. Die Entwurfsimplementierungen der einzelnen Anwendungen werden in diesem Artikel beschrieben. Es folgen die wichtigsten Ziele der Entwurfsbeispiele:

• Verwendung möglichst weniger Serverfarmen zum Hosten der am häufigsten verwendeten Websitetypen, die normalerweise von einem Unternehmen benötigt werden: Intranet-, Extranet- und Internetwebsites.

• Erstellung eines Frameworks für das Entwerfen einer Umgebung, die auf Wachstum ausgelegt ist. Die Entwurfsentscheidungen für einzelne Anwendungen verhindern nicht das Hinzufügen anderer Anwendungen. Beispielsweise kann eine Erstbereitstellung nur Teamwebsites für die Zusammenarbeit oder nur die drei Anwendungen enthalten, die zusammen das Intranet bilden (Teamwebsites, "Meine Websites" und veröffentlichter Intranetinhalt). Mithilfe eines ähnlichen logischen Architekturentwurfs können Sie der Lösung Anwendungen ohne Auswirkungen auf den Entwurf der anfänglich vorhandenen Anwendungen hinzufügen. Mit anderen Worten weist der Entwurf keine Entwurfsentscheidungen auf, die die Nutzung der Umgebung beschränken.

• Zugriff für verschiedene Gruppe von Benutzern, ohne die Sicherheit des Inhalts der unterschiedlichen Websitetypen zu gefährden. Benutzer aus anderen Netzwerkzonen (sowohl intern als auch extern) mit anderen Authentifizierungsanbietern können an der Zusammenarbeit teilnehmen. Zudem dürfen die Benutzer auch nur auf Inhalte zugreifen, auf die sie zugreifen können sollen. Durch Verwendung eines ähnlichen logischen Architekturentwurfs schaffen Sie die Möglichkeit, Benutzern an verschiedenen Standorten und mit verschiedenen Zielen den Zugriff zu ermöglichen. Beispielsweise kann Ihr anfänglicher Entwurf nur für den Zugriff durch interne Mitarbeiter gedacht gewesen sein. Durch Verwendung eines ähnlichen Entwurfs ermöglichen Sie nun jedoch auch Remotemitarbeitern, Partnermitarbeitern, Partnerunternehmen und Kunden den Zugriff.

• Sicherstellung, dass der Entwurf in einer Extranetumgebung verwendet werden kann. Es werden Entwurfsentscheidungen getroffen, die gewährleisten sollen, dass die Serverfarmen in einem Umkreisnetzwerk sicher bereitgestellt werden können.

Im Rest dieses Artikels werden alle logischen Komponenten erläutert, die im Entwurfsbeispiel vorkommen (von oben nach unten). Außerdem werden die Entwurfsentscheidungen besprochen, die für das Entwurfsbeispiel gelten sollen. Der Zweck dieses Ansatzes besteht darin, die verschiedenen Methoden aufzuzeigen, mit denen logische Architekturkomponenten basierend auf der Anwendung konfiguriert werden können.

Serverfarmen

Das Entwurfsbeispiel umfasst zwei Serverfarmen. In diesem Abschnitt werden die Lizenzanforderungen beschrieben, die die Anzahl der Serverfarmen beeinflussen, die in einer Unternehmensumgebung erforderlich sind, und die Topologien der Serverfarmen aufgezeigt, die in dem Entwurfsbeispiel dargestellt werden.

Lizenzanforderungen

Für das Hosten von Intranetinhalten und Internetwebsites sind mindestens zwei Server erforderlich, um die Lizenzanforderungen zu erfüllen.

Die beiden folgenden Serverlizenzen stehen für SharePoint Server 2010 zur Verfügung:

• Microsoft Office SharePoint Server 2010, Serverlizenz: Dies ist die geeignete Lizenz für zusammenarbeitsorientierte Intranetinhalte. Diese Lizenz erfordert die Verwendung von Clientzugriffslizenzen (Client Access Licenses, CALs). Wenn Sie Websites für die Partnerzusammenarbeit erstellen, müssen Sie sicherstellen, dass Sie die erforderliche Anzahl von CALs für die Partnermitarbeiter erwerben.

• Microsoft Office SharePoint Server 2010 für Internetwebsites: Diese Lizenz ist ausschließlich für mit dem Internet verbundene Websites gedacht. Diese Lizenz erfordert keine CALs. Wenn Sie Websites für die Partnerzusammenarbeit erstellen, müssen Sie keine zusätzlichen CALs erwerben. Sie können jedoch keine Websites erstellen, die ausschließlich für die Nutzung durch Ihre Mitarbeiter vorgesehen sind.

Angesichts der Lizenzierungsoptionen besteht die wichtigste Entwurfsentscheidung darin, welche Farm die Partnerwebanwendung hosten soll. Im Entwurfsbeispiel hostet die erste Serverfarm den Intranetinhalt und die zweite Serverfarm die Internetwebsite des Unternehmens. Gemäß den Lizenzierungsbedingungen kann jede der beiden Farmen die Partnerwebanwendung hosten.

Da zwei Farmen zur Auswahl stehen, kann die Entwurfsentscheidung, welche Webfarm eine Partnerwebanwendung hosten soll, anhand der folgenden allgemeinen Überlegungen getroffen werden:

• Art der Zusammenarbeit: Wenn der Hauptzweck einer Extranetwebsite für Partner in der sicheren Kommunikation mit zahlreichen Partnern besteht, ist eine Internetserverfarm sicher die günstigste Lösung. Wenn andererseits der Hauptzweck die Zusammenarbeit mit einer kleinen Anzahl von Partnermitarbeitern darstellt, ist ggf. eine Intranetserverfarm die bessere Lösung. Wählen Sie die Option aus, die es Ihnen ermöglicht, die Farm für ihren geplanten Zweck zu optimieren.

• Anzahl der Partnermitarbeiter Wenn Sie mit vielen Partnermitarbeitern zusammenarbeiten und die Minimierung der Kosten wichtig ist, können Sie sowohl zusammenarbeitsorientierte als auch anonyme Inhalte in einer internetorientierten Serverfarm mit Internetwebsitelizenz sicher hosten.

Im Entwurfsbeispiel ist die Partnerwebanwendung auf eine intensive Zusammenarbeit mit Partnerfirmen, einschließlich Entwicklung und Staging der Internetwebsite des Unternehmens, ausgerichtet. Durch Zuordnen der Partnerwebanwendung zur ersten Farm kann das Unternehmen jede der beiden Serverfarmen für ihre beabsichtigte Verwendung optimieren (zusammenarbeitsorientierte oder schreibgeschützte Inhalte). Jede der beiden Farmen kann jedoch die Partnerwebanwendung hosten.

Das Entwurfsbeispiel enthält Microsoft Office Web Apps. Office Web Apps erfordert eine Microsoft Office 2010-Clientlizenz. Wenn Sie Partnern Office Web Apps zur Verfügung stellen möchten, müssen Sie Office 2010-Clientlizenzen für sie erwerben.

Topologie der Serverfarmen

Jede Serverfarm im Entwurfsbeispiel besteht aus fünf Servern mit folgender Topologie:

• Zwei Front-End-Webserver

• Ein Anwendungsserver

• Zwei Datenbankserver (entweder gruppiert oder gespiegelt)

Das Entwurfsbeispiel veranschaulicht die logische Architektur von SharePoint Server 2010 wie folgt:

• Alle Websites werden über Front-End-Webserver gespiegelt.

• Die Website für die Zentraladministration ist auf einem Anwendungsserver installiert, um sie vor direktem Benutzerzugriff zu schützen.

Im Grunde ist die Anzahl der Servercomputer und die Topologie der Serverfarm für die logische Architektur nicht wichtig, außer um bei Bedarf die Kapazität und Leistung zu erhöhen. Die logische Architektur kann unabhängig von der Serverfarmtopologie entworfen werden. Die Leistungs- und Kapazitätsplanung hilft Ihnen dabei, die Größe die Serverfarm anzupassen, um die Leistungs- und Kapazitätsziele zu erfüllen. Weitere Informationen finden Sie unter Leistungs- und Kapazitätsverwaltung (SharePoint Server 2010).

Skalierung mit mehr als zwei Farmen

Ihr Unternehmen benötigt ggf. mehr als die beiden dargestellten Farmen. Es folgen Websites, die sich gut für eine dedizierte Farm eignen:

• Meine Websites: Viele Organisationen mit sehr vielen Mitarbeitern oder Studenten entscheiden sich für das Hosten von "Meine Websites" in einer dedizierten Serverfarm.

• Erstellungs- und Stagingwebsites: Wenn veröffentlichte Inhalte komplex bzw. umfangreich sind, können Dokumenterstellung und Staging optimiert werden, indem diese Website unter Verwendung von Lizenzen vom Typ "Microsoft Office SharePoint Server 2010 für Internetwebsites" in einer dedizierten Farm mit einem Server gehostet werden. Das Veröffentlichen von Inhalten mit kategorisierten Metadaten erhöht die Komplexität des Dienstentwurfsbeispiels für sowohl die Erstellungsfarm als auch der veröffentlichten Farm, einschließlich der farmübergreifenden Freigabe des Diensts und dem Treffen von Entscheidungen dazu, wie der Dienst für andere Typen von Webanwendungen in einer Mehrzweckfarm freigegeben werden soll.

• Partnerwebsites: Zur Erfüllung von Sicherheits- und Trennanforderungen kann für die Partnerzusammenarbeit eine dedizierte Farm erforderlich sein. Dies sorgt für eine physische Trennung zwischen ausschließlich internen Inhalten und Inhalten, die in Zusammenarbeit mit externen Partnern entwickelt wurden.

Benutzer, Zonen und Authentifizierung

Beim Erstellen einer Webanwendung in SharePoint Server 2010 müssen Sie sich zwischen der anspruchsbasierten oder klassischen Authentifizierung entscheiden. Der Authentifizierungsmodus bestimmt, wie Konten von SharePoint Server 2010 intern verwendet werden. In der folgenden Tabelle werden die beiden Methoden vorgestellt.

Authentifizierungsmethode	Beschreibung	Empfehlungen
Klassischer Authentifizierungsmodus	Benutzerkonten werden von SharePoint Server 2010 als herkömmliche Windows Active Directory-Konten behandelt. Die folgenden Authentifizierungsprotokolle werden unterstützt: Kerberos, NTLM, Standard, Digest und anonym. Die formularbasierte Authentifizierung wird nicht unterstützt. Für eine Zone kann nur eine Authentifizierungsmethode konfiguriert werden.	Der klassische Modus wird für ein Upgrade von Umgebungen von Microsoft Office SharePoint Server 2007 empfohlen, in denen die formularbasierte Authentifizierung nicht erforderlich ist. Sie müssen die Benutzermigration nicht ausführen, wenn Sie ein Upgrade durchführen und den klassischen Authentifizierungsmodus wählen.
Anspruchsbasierte Authentifizierung	Benutzerkonten werden von SharePoint Server 2010 als Anspruchsidentitäten behandelt. Windows-Konten werden automatisch in Anspruchsidentitäten umgewandelt. Dieser Modus unterstützt zusätzlich die formularbasierte Authentifizierung und die Authentifizierung im Abgleich mit einem vertrauenswürdigen Identitätsanbieter. Für eine einzelne Zone können mehrere Authentifizierungsmethoden konfiguriert werden.	Die anspruchsbasierte Authentifizierung wird für neue SharePoint Server 2010-Bereitstellungen empfohlen und ist für Office SharePoint Server 2007-Lösungen erforderlich, die die formularbasierte Authentifizierung benötigen.

Von den beiden in diesem Artikel behandelten Entwurfsbeispielen werden diese beiden Optionen dargestellt. In den folgenden Abschnitten wird insbesondere erläutert, wie die Authentifizierung in die beiden Entwurfsbeispiele integriert wird.

Entwurfsbeispiel für den klassischen Authentifizierungsmodus

Das Entwurfsbeispiel, das mit dem klassischen Authentifizierungsmodus arbeitet, setzt auf dem herkömmlichen Ansatz von einer Zone pro Authentifizierungsmethode auf, der in der vorherigen Version eingeführt wurde. Aus diesem Grund bietet dieses Beispiel eine Möglichkeit des Upgrades von Office SharePoint Server 2007 zu SharePoint Server 2010.

Die einzige Einschränkung ist, dass die formularbasierte Authentifizierung im klassischen Modus nicht unterstützt wird. Bei Verwenden der klassischen Authentifizierung müssen sich alle authentifizierten Konten in Active Directory-Domänendienste (Active Directory Domain Services, AD DS) befinden. Die Empfehlung für Benutzer, die remote auf Websites zugreifen, ist das Verwenden der formularbasierten Authentifizierung für das Firewall- oder Gatewayprodukt zum Erfassen von Windows-Anmeldeinformationen, die an die SharePoint-Farm weitergeleitet werden.

Das Beispiel für den klassischen Modus veranschaulicht vier verschiedene Klassen von Benutzern, die jeweils einer anderen Zone zugewiesen sind. Innerhalb jeder Webanwendung können Sie bis zu fünf Zonen mit einem der verfügbaren Zonennamen erstellen: Standard, Intranet, Internet, Benutzerdefiniert oder Extranet.

Die folgende Tabelle enthält die Zonen, Benutzer und Authentifizierungstypen im Entwurfsbeispiel für den klassischen Modus.

Das Konto für die Durchforstung von Inhalten benötigt unter Verwendung der NTLM-Authentifizierung Zugriff auf mindestens eine Zone. Wenn keine der Zonen für Benutzer für die Verwendung von NTLM konfiguriert ist, konfigurieren Sie die benutzerdefinierte Zone für die NTLM-Authentifizierung.

Entwurfsbeispiel für die anspruchsbasierte Authentifizierung

Die anspruchsbasierte Authentifizierung wird für alle neuen SharePoint Server 2010-Bereitstellungen empfohlen und ist für Office SharePoint Server 2007-Lösungen erforderlich, die die formularbasierte Authentifizierung benötigen. Zusätzlich zur Bereitstellung der standardmäßigen Windows-Authentifizierungsmethoden ermöglicht die anspruchsbasierte Authentifizierung eine Authentifizierung im Abgleich mit anderen Verzeichnissen, z. B. Windows Live ID, Active Directory-Verbunddienste 2.0 oder einem anderen Identitätsanbieter, der SAML-Token und das WS-Verbund-Protokoll unterstützt.

Beim Entwurfsbeispiel für die anspruchsbasierte Authentifizierung wird diese Authentifizierungsmethode für die zusammenarbeitsorientierte Farm verwendet. Die anspruchsbasierte Authentifizierung erlaubt das Verwenden mehrerer Authentifizierungsmethoden in derselben Zone. Im Entwurfsbeispiel wird die Zone Standard für alle Authentifizierungsmethoden verwendet. Die folgende Tabelle zeigt die Zonen, Benutzer und Authentifizierungsmethoden, die vom Beispiel für die zusammenarbeitsorientierte Farm vorgeschrieben werden.

Im Entwurfsbeispiel können nur Mitarbeiter (ob inner- oder außerhalb des Netzwerks) auf die Website für veröffentliche Intranetinhalte, Teamwebsites und "Meine Websites" zugreifen. Im Entwurfsbeispiel wird nur eine URL (mithilfe von SSL) implementiert, die intern und extern verwendet werden kann. Es werden Active Directory-Konten verwendet. Bei Bedarf kann LDAP mit entweder der formularbasierten Authentifizierung oder SAML genutzt werden, wozu eine zusätzliche Konfiguration erforderlich ist.

Im Entwurfsbeispiel stellt die Partnerwebanwendung eine Extranetwebsite dar, auf die Partnermitarbeiter und Partnerunternehmen zugreifen können. Das Verwenden der anspruchsbasierten Authentifizierung in diesem Szenario erfordert, dass ein Vertrauensverhältnis mit mindestens einem externen Sicherheitstokendienst (Secure Token Service, STS) konfiguriert wird, was auf eine der folgenden Weisen erfolgen kann:

• Die SharePoint-Farm kann so konfiguriert werden, dass einem externen STS vertraut wird, z. B. dem Windows Live zugeordneten STS (für die Authentifizierung einzelner Partner) oder dem STS, der sich in einem Partnerunternehmen befindet (für die direkte Authentifizierung im Abgleich mit dem Partnerverzeichnis).

• Der STS in der Unternehmensumgebung kann so konfiguriert werden, dass einem externen STS vertraut wird. Diese Beziehung muss von Administratoren in beiden Organisationen explizit eingerichtet werden. In diesem Szenario wird die SharePoint-Farm so konfiguriert, dass sie nur dem STS vertraut, der sich in der eigenen Unternehmensumgebung befindet. Der interne STS überprüft das vom externen STS empfangene Token und stellt anschließend ein Token aus, das dem Partnerbenutzer den Zugriff auf die SharePoint-Farm erlaubt.

Eine Alternative zur Implementierung einer anspruchsbasierten Umgebung zum Authentifizieren von Partnern ist das Verwenden der formularbasierten Authentifizierung und das Verwalten dieser Konten mithilfe eines gesonderten Datenspeichers, z. B. einer Datenbank.

Weitere Informationen zur Implementierung einer anspruchsbasierten Authentifizierungsumgebung finden Sie im folgenden englischsprachigen Whitepaper: Claims-based Identity for Windows: An Introduction to Active Directory Federation Services 2.0, Windows CardSpace 2.0, and Windows Identity Foundation (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x407).

Beim Entwurfsbeispiel der anspruchsbasierten Authentifizierung ist die veröffentlichte Farm für die Verwendung des klassischen Authentifizierungsmodus eingerichtet. Eine Alternative ist das Verwenden der anspruchsbasierten Authentifizierung für die veröffentlichte Farm und die Implementierung einer gesonderten Zone für anonyme Benutzer. Das wichtige Element des Entwurfs ist die Nutzung einer gesonderten Zone für anonyme Benutzer zum Trennen der schreibgeschützten Umgebung von der Umgebung mit Lese-/Schreibzugriff ungeachtet des implementierten Authentifizierungsmodus. Die folgende Tabelle enthält die Zonen, Benutzer und Authentifizierungsmethoden, die für die veröffentlichte Farm abgebildet sind.

Wiederum benötigt das Konto für die Durchforstung von Inhalten unter Verwendung der NTLM-Authentifizierung Zugriff auf mindestens eine Zone. Bei Bedarf kann die NTLM-Authentifizierung einer Zone mit anspruchsbasierter Authentifizierung hinzugefügt werden. Wenn im klassischen Modus keine der Zonen für Benutzer für die Verwendung von NTLM konfiguriert ist, konfigurieren Sie die benutzerdefinierte Zone für die NTLM-Authentifizierung.

Zonen

Beim Entwerfen von Zonen sind mehrere Entscheidungen für den Erfolg der Bereitstellung von Bedeutung. Diese Entscheidungen betreffen u. a. den Entwurf und die Konfiguration der folgenden Zonen:

• Standardzone

• Zonen für externen Zugriff

In den folgenden Abschnitten werden die Entscheidungen beschrieben, die für das Entwurfsbeispiel übernommen wurden.

Konfigurationsanforderungen der Standardzone

Die Zone, die die meisten Überlegungen betreffen, ist die Standardzone. In SharePoint Server 2010 werden die folgenden Anforderungen an die Konfiguration der Standardzone gestellt:

• Wenn eine Benutzeranforderung keiner Zone zugeordnet werden kann, werden gelten die Authentifizierung und Richtlinien der Zone Standard. Aus diesem Grund muss die Zone Standard die sicherste Zone sein.

• Administrative E-Mails werden mit Links aus der Zone Standard gesendet. Hierzu gehören E-Mails an Besitzer von Websites, die sich ihren Kontingentgrenzen nähern. Benutzer, die diese Art von E-Mails und Benachrichtigungen erhalten, müssen folglich über die Zone Standard auf die Links zugreifen können. Dies ist besonders wichtig für Websitebesitzer.

• Websitesammlungen mit Hostnamen sind nur über die Zone Standard verfügbar. Benutzer, die auf Websitesammlungen mit Hostnamen zugreifen müssen, benötigen daher Zugriff über die Zone Standard.

Konfigurieren von Zonen für eine Extranetumgebung

In einer Extranetumgebung ist der Entwurf der Zonen aus den folgenden beiden Gründen von entscheidender Bedeutung:

• Benutzeranforderungen können in mehreren Netzwerken ausgelöst werden. Im Entwurfsbeispiel lösen Benutzer Anforderungen im internen Netzwerk, dem Internet und den Partnerunternehmen aus.

• Benutzer nutzen Inhalte verschiedener Webanwendungen. Im Entwurfsbeispiel besteht das Intranet aus drei Webanwendungen. Darüber hinaus können interne und Remotemitarbeiter potenziell Inhalte beitragen und Inhalte alle drei Webanwendungen übergreifend verwalten: Intranet, Partnerweb und Internetwebsite des Unternehmens.

Folgende Entwurfsprinzipien müssen in einer Extranetumgebung beachtet werden:

• Konfigurieren Sie Zonen über mehrere Webanwendungen hinweg, sodass sie sich gegenseitig spiegeln. Die Konfiguration der Authentifizierung und die vorgesehenen Benutzer sollten identisch sein. Die Richtlinien, die den Zonen zugeordnet sind, können sich über die Webanwendungen hinweg unterscheiden. Stellen Sie beispielsweise sicher, dass die Zone "Intranet" alle Webanwendungen übergreifend für dieselben Mitarbeiter verwendet wird. Mit anderen Worten: Konfigurieren Sie die Zone "Intranet" nicht in einer Webanwendung für interne Mitarbeiter und in einer anderen für Remotemitarbeiter.

• Konfigurieren Sie alternative Zugriffszuordnungen ordnungsgemäß und entsprechend der jeweiligen Zone und Ressource. Alternative Zugriffszuordnungen werden beim Erstellen der Zone automatisch erstellt. SharePoint Server 2010 kann so konfiguriert werden, dass Inhalte in externen Ressourcen durchforstet werden, z. B. einer Dateifreigabe. Links zu diesen externen Ressourcen müssen für jede Zone mithilfe alternativer Zugriffszuordnungen manuell erstellt werden.

Wenn webanwendungsübergreifende Zonen sich nicht gegenseitig spiegeln und Links zu externen Ressourcen nicht ordnungsgemäß sind, bestehen die folgenden Risiken:

• Servernamen, DNS-Namen (Domain Name System) und IP-Adressen können außerhalb des internen Netzwerks potenziell verfügbar gemacht werden.

• Benutzer können möglicherweise nicht auf Websites und andere Ressourcen zugreifen.

Dienste

Die gezeigte Dienstarchitektur veranschaulicht die komplexeste Option für die Bereitstellung von Diensten über die drei Websitetypen hinweg: Intranet, Partnerwebsite und Internetwebsite des Unternehmens. Dedizierte und partitionierte Dienste werden für die Partnerwebsite bereitgestellt. Eine gesonderte Instanz der Dienstanwendung für verwaltete Metadaten wird für die ausschließliche Verwendung durch die Erstellungswebsitesammlung und veröffentlichte Internetwebsite bereitgestellt.

Eine wesentlich einfachere Alternative ist das Bereitstellen einer Gruppe von Dienstanwendungen und die websiteübergreifende Freigabe der einzelnen Dienste den Anforderungen entsprechend. Diese Architektur basiert auf der Einschränkung aus Sicherheitsgründen, um nur Inhalte anzuzeigen, auf die Benutzer Zugriff haben. Die folgende Abbildung veranschaulicht diesen einfacheren Ansatz.

Die wesentliche Entwurfsentscheidung bei der Bereitstellung von Dienstanwendungen bezieht sich auf den Grad der Ausdehnung der Organisationstaxonomie. Dienstarchitekturen können vereinfacht werden, indem verwaltete Metadaten, Benutzerprofile und alle Web App-übergreifenden Suchen freigegeben werden und die Einschränkung aus Sicherheitsgründen aktiviert wird, um den Zugriff auf Inhalte zu steuern. In der in diesem Artikel beschriebenen vereinfachten Architektur wird eine Instanz des Diensts für verwaltete Metadaten für alle Websites freigegeben. Bei dieser Konfiguration haben jedoch alle Benutzer Zugriff auf die Organisationstaxonomie. Lösungsentwickler müssen festlegen, ob mehrere Instanzen des Diensts für verwaltete Metadaten implementiert werden sollen. Ferner muss bestimmt werden, wie umfassend Benutzerprofildaten freigegeben werden sollen.

Partnerwebsite

Für die Partnerwebsite (benutzerdefinierte Gruppe in Farm 1) heißen die vom Entwurfsbeispiel zumindest vorgeschriebenen Dienste Suche und Verwaltete Metadaten. Wenn Sie der von der Partnerwebsite verwendeten Gruppe der Dienste Office Web Apps hinzufügen, stellen Sie sicher, dass Sie über die entsprechenden Lizenzen für alle Benutzer dieser Website einschließlich Partner verfügen. Die Benutzerprofildienst-Anwendung ist im Entwurfsbeispiel nicht enthalten, um Partnerbenutzer an der Durchsuchung personenbezogener Daten in der Organisation zu hindern.

In der vereinfachten Architektur haben Partner Zugriff auf die gesamte Unternehmenstaxonomie und können personenbezogene Daten in der Organisation durchsuchen. Suchergebnisse sind jedoch auf Websites und Inhalte beschränkt, auf die Partner Zugriff haben.

Wenn Ihre Partnerwebsites eine Trennung von Inhalten zwischen Projekten erfordern, ist das Bereitstellen dedizierter und partitionierter Dienstanwendungen (wie im Entwurfsbeispiel veranschaulicht) eine gute Wahl. Dadurch wird die Komplexität der Architektur der Dienste erhöht, aber sichergestellt, dass Partner keinen Zugriff auf Metadaten haben, die dem Intranetinhalt oder gar anderen Projekten in der Partnerwebsite zugeordnet sind.

Internetwebsite des Unternehmens

In der vereinfachten Entwurfsarchitektur wird auch die Unternehmensdienstanwendung für verwaltete Metadaten mit der veröffentlichten Internetwebsite freigegeben. Eine Instanz der Dienstanwendung für verwaltete Metadaten wird in der zusammenarbeitsorientierten Farm für die ausschließliche Verwendung durch die Erstellungswebsitesammlung und veröffentlichte Farm bereitgestellt.

Wenn die veröffentlichte Farm anonym und schreibgeschützt ist, besteht nicht das Risiko, dass verwaltete Metadaten verfügbar gemacht werden, die nicht dem veröffentlichten Inhalten zugeordnet sind. Anonyme Benutzer haben nur Zugriff auf Inhalte, die veröffentlicht wurden, und können keine Bewertungen vornehmen oder andere Typen von Metadaten erstellen.

Das Freigeben der Dienstanwendung für verwaltete Metadaten in der gesamten Organisation (siehe die Abbildung der vereinfachten Architektur in diesem Artikel) ermöglicht Autoren die Nutzung der Unternehmenstaxonomie. Im Gegensatz dazu stellt das Bereitstellen einer dedizierten Instanz des Erstellungs- und Veröffentlichungsdiensts (wie im Entwurfsbeispiel veranschaulicht) sicher, dass verwaltete Metadaten isoliert werden.

Eine dedizierte Instanz der Suchdienstanwendung wird für die Farm bereitgestellt, die die Internetwebsite des Unternehmens hostet. Dies ist die empfohlene Konfiguration für eine veröffentlichte im Internet bereitgestellte Website.

Erstellungs- und Veröffentlichungsalternativen

Für die Internetwebsite des Unternehmens veranschaulicht das Entwurfsbeispiel einen Veröffentlichungsprozess, bei dem mithilfe der Inhaltsbereitstellungsfunktion Inhalte aus einer Erstellungswebsitesammlung in die Veröffentlichungsfarm verschoben werden. Eine einfachere Alternative zu diesem Ansatz ist die direkte Erstellung von Inhalten in der Veröffentlichungsfarm. Dies wird gemeinhin als Erstellung in der Produktionsumgebung bezeichnet.

Die Erstellung in der Produktionsumgebung vereinfacht die Lösung im Wesentlichen dadurch, dass Dienste für eine Farm konsolidiert werden und die Notwendigkeit der Inhaltsbereitstellung aufgehoben wird. Das Entwurfsbeispiel enthält die zusätzlichen Zonen, die von Autoren genutzt werden können, um sicher zu arbeiten, ohne anonyme Benutzer zu beeinträchtigen. Sorgen Sie dafür, dass eingehende anonyme Zugriffe an dem Port blockiert werden, der Zonen zugeordnet ist, die von Autoren verwendet werden. Wenn Ihre Website weniger als 500 Schreibvorgänge pro Stunde für Inhaltserstellungsaktivitäten aufweist, ist es unwahrscheinlich, dass die Leistung der veröffentlichten Website durch die Inhaltserstellung in der Produktionsumgebung beeinträchtigt wird.

SharePoint Server 2010 bietet Veröffentlichungsfunktionen, die in diesem Szenario verwendet werden können, um sicherzustellen, dass Inhalte erst dann anonymen Benutzern zur Verfügung gestellt werden, wenn sie dazu bereit sind. Weitere Informationen finden Sie in den folgenden Artikeln:

• Planen des Anfangs- und Enddatums für eine veröffentlichte Seite (https://go.microsoft.com/fwlink/?linkid=196777&clcid=0x407)

• Genehmigen oder Ablehnen einer ausstehenden Übermittlung (https://go.microsoft.com/fwlink/?linkid=196778&clcid=0x407)

• Festlegen von Berechtigungen für die Veröffentlichung (https://go.microsoft.com/fwlink/?linkid=196779&clcid=0x407)

Administrationswebsites

Im Entwurfsbeispiel wird die Zentraladministrationswebsite für jede Serverfarm auf einem Anwendungsserver gehostet. Dies schützt die Website vor direktem Benutzerkontakt. Wenn ein Leistungsengpass oder Sicherheitsproblem die Verfügbarkeit der Front-End-Webserver beeinträchtigt, bleibt die Zentraladministrationswebsite dennoch verfügbar.

Die Lastenausgleich-URLs für Administrationswebsites kommen im Entwurfsbeispiel oder in diesem Artikel nicht vor. Es gelten die folgenden Empfehlungen:

• Wenn in administrativen URLs Portnummern verwendet werden, sollten keine Standardports gewählt werden. Portnummern sind in URLs standardmäßig enthalten. Portnummern werden normalerweise nicht in URLs für Kunden verwendet. Allerdings kann durch Verwendung von Portnummern die Sicherheit von Administrationswebsites erhöht werden, indem der Zugriff auf diese Websites auf nicht standardmäßige Ports beschränkt wird.

• Erstellen Sie separate DNS-Einträge für Administrationswebsites.

Neben diesen Empfehlungen können Sie für die Zentraladministrationswebsite für einen Lastenausgleich auf mehreren Anwendungsservern sorgen, um Redundanz zu erzielen.

Anwendungspools

Separate IIS-Anwendungspools (Internet Information Services, Internetinformationsdienste) werden normalerweise implementiert, um eine Prozesstrennung zwischen Inhalten zu erreichen. Anwendungspools bieten für mehrere Websites eine Möglichkeit, auf dem gleichen Servercomputer ausgeführt zu werden und dennoch die eigenen Arbeitsprozesse und Identitäten zu behalten. Auf diese Weise wird eine Sicherheitslücke geschlossen, die einem Angreifer Gelegenheit zum Einfügen von Code auf dem Server für Angriffe auf andere Websites bieten könnte.

Sie sollten daher in Erwägung ziehen, für jedes der folgenden Szenarien einen dedizierten Anwendungspool zu verwenden:

• Trennen authentifizierter Inhalte von anonymen Inhalten

• Isolieren von Anwendungen, in denen Kennwörter für externe Geschäftsanwendungen gespeichert werden, mit denen sie interagieren (wenngleich der Secure Store Service für diesen Zweck verwendet werden kann)

• Trennen von Anwendungen, in denen Benutzer über umfangreiche Berechtigungen zum Erstellen und Verwalten von Websites sowie für die Zusammenarbeit an Inhalten verfügen

Im Entwurfsbeispiel werden Anwendungspools auf folgende Weise verwendet:

• Jede Administrationswebsite wird in einem dedizierten Anwendungspool gehostet. Dies ist eine Anforderung von SharePoint 2010-Produkte.

• Intranetinhalte werden in zwei verschiedene Anwendungspools unterteilt. Gemeinsame Inhalte ("Meine Websites" und Teamwebsites) werden in einem Anwendungspool gehostet. Veröffentlichte Intranetinhalte werden in einem gesonderten Anwendungspool gehostet. Diese Konfiguration bietet Prozessisolierung für veröffentlichte Intranetinhalte, für die Geschäftsdatenverbindungen häufiger verwendet werden.

• Die Partnerwebanwendung wird in einem dedizierten Anwendungspool gehostet.

• Die Internetwebsite des Unternehmens wird in einem dedizierten Anwendungspool für die zweite Farm gehostet Wenn diese Farm auch Inhalte für die Partnerzusammenarbeit hosten würde, würden diese beiden Inhaltstypen (Internet und Partner) in zwei verschiedenen Anwendungspools gehostet.

Webanwendungen

Eine Webanwendung ist eine IIS-Website, die von SharePoint 2010-Produkte erstellt und verwendet wird. Jede Webanwendung wird durch eine andere Website in IIS dargestellt.

Dedizierte Webanwendungen werden im Allgemeinen für folgende Zwecke verwendet:

• Trennen anonymer Inhalte von authentifizierten Inhalten. Im Entwurfsbeispiel wird die Internetwebsite des Unternehmens in einer dedizierten Webanwendung und einem Anwendungspool gehostet.

• Isolieren von Benutzern. Im Entwurfsbeispiel wird die Partnerwebanwendung in einer dedizierten Webanwendung und in einem Anwendungspool gehostet, um sicherzustellen, dass die Partner keinen Zugriff auf Intranetinhalte haben.

• Erzwingen von Berechtigungen. Eine dedizierte Webanwendung bietet die Möglichkeit zum Erzwingen von Berechtigungen durch Richtlinien mithilfe der Seite Richtlinie für Webanwendung in der Zentraladministration. Beispielsweise können Sie eine Richtlinie auf der Internetwebsite des Unternehmens erstellen und dadurch einer oder mehreren Gruppen von Benutzern den Schreibzugriff explizit verweigern. Richtlinien für eine Webanwendung werden unabhängig von Berechtigungen für einzelne Websites oder Dokumente in der Webanwendung erzwungen.

• Optimieren der Leistung. Anwendungen erzielen eine bessere Leistung, wenn sie zusammen mit anderen Anwendungen mit ähnlichen Datenmerkmalen in Webanwendungen platziert werden. Meine Websites umfassen in der Regel eine große Anzahl kleiner Websites, während Teamwebsites üblicherweise eine geringere Anzahl recht großer Websites darstellen. Indem Sie diese verschiedenen Typen von Websites in unterschiedlichen Webanwendungen platzieren, enthalten die Ergebnisdatenbanken Daten mit einheitlichen Merkmalen, wodurch die Datenbankleistung optimiert wird. Im Entwurfsbeispiel verfügen Meine Websites und die Teamwebsites über keine speziellen Isolierungsanforderungen und befinden sich daher im selben Anwendungspool. Allerdings befinden sie sich in getrennten Webanwendungen, um die Leistung zu optimieren.

• Optimieren der Verwaltbarkeit. Da das Erstellen separater Webanwendungen zu separaten Websites und Datenbanken führt, können Sie verschiedene Websitegrenzwerte festlegen (Papierkorb, Ablaufdatum und Größe) und unterschiedliche Vereinbarungen zum Servicelevel (SLAs) aushandeln. Beispielsweise können Sie für die Wiederherstellung von Meine Websites-Inhalten mehr Zeit einräumen, wenn dies nicht der wichtigste Inhaltstyp in Ihrem Unternehmen ist. Dadurch haben Sie ausreichend Zeit zum Wiederherstellen wichtigerer Daten, bevor Sie Meine Websites-Inhalte wiederherstellen. Im Entwurfsbeispiel befindet sich Meine Websites in einer separaten Webanwendung, damit die Administratoren genauer auf die Größe dieser Websites achten als bei anderen Anwendungen.

Websitesammlungen

Websitesammlungen schlagen eine Brücke zwischen der logischen Architektur und der Informationsarchitektur. Aufgaben der Websitesammlungen im Entwurfsbeispiel sind die Erfüllung der URL-Entwurfsanforderungen und die Erstellung logischer Unterteilungen des Inhalts.

Damit die Anforderungen an den URL-Entwurf erfüllt sind, enthält jede Webanwendung eine einzelne Websitesammlung auf Stammebene. Verwaltete Pfade dienen zum Integrieren einer zweiten Ebene mit hochrangigen Websitesammlungen. Weitere Informationen zu den URL-Anforderungen und zur Verwendung verwalteter Pfade finden Sie unter "Zonen und URLs" weiter unten in diesem Artikel. Neben der zweiten Ebene von Websitesammlungen verfügt jede Website über eine Unterwebsite.

Die folgende Abbildung veranschaulicht die Websitehierarchie der Teamwebsites.

Neben der Anforderung einer Websitesammlung auf Stammebene betreffen die Entwurfsentscheidungen die zweite Websitesammlungsebene. Das Entwurfsbeispiel bietet Auswahlmöglichkeiten basierend auf dem Anwendungstyp.

Veröffentlichte Intranetinhalte

Die Annahme für die Webanwendung für veröffentlichte Intranetinhalte ist, dass mehrere Abteilungen innerhalb des Unternehmens veröffentlichte Inhalte hosten werden. Im Entwurfsbeispiel wird der Inhalt jeder Abteilung in einer separaten Websitesammlung gehostet. Dies bietet folgende Vorteile:

• Jede Abteilung kann ihre Inhalte unabhängig verwalten und die Berechtigungen selbst festlegen.

• Die Inhalte jeder Abteilung können in einer dedizierten Datenbank gespeichert werden.

Es folgen die Nachteile der Verwendung mehrerer Websitesammlungen:

• Gestaltungsvorlagen, Seitenlayouts, Vorlagen, Webparts und die Navigation können websitesammlungsübergreifend gemeinsam verwendet werden.

• Das websitesammlungsübergreifende Koordinieren von Anpassungen und Navigation erfordert mehr Aufwand.

Je nach Informationsarchitektur und Entwurf der Intranetanwendung kann der veröffentlichte Inhalt als transparente Anwendung für den Benutzer angezeigt werden. Alternativ kann jede Websitesammlung als separate Website angezeigt werden.

Meine Websites

Meine Websites haben spezielle Merkmale, und die Empfehlungen für die Bereitstellung dieser Websites sind recht unkompliziert. Im Entwurfsbeispiel enthält diese Anwendung eine Website auf der obersten Ebene mit der URL http://my. Die Websitesammlung der obersten Ebene verwendet die Hostvorlage von Meine Websites. Ein verwalteter Pfad ist integriert (mit Platzhaltern), der eine unbestimmte Anzahl von Benutzerwebsites zulässt. Alle Websites unterhalb des verwalteten Pfads sind unabhängige Websitesammlungen, die die Hostvorlage erben. Der Benutzername wird an die URL im Format http://my personal/Benutzernameangefügt. In der folgenden Abbildung ist Meine Websites dargestellt.

Teamwebsites

Sie können einen der folgenden beiden Ansätze zum Entwerfen von Websitesammlungen innerhalb einer Teamwebsiteanwendung verwenden:

• Erlauben Sie den Teams das Erstellen von Websitesammlungen mithilfe von Self-Service Site Creation. Der Vorteil dieses Ansatzes ist, dass die Teams problemlos eigene Websites erstellen können, ohne die Hilfe eines Administrators zu benötigen. Es gibt jedoch einige Nachteile bei diesem Ansatz, z. B.:

  • Sie verlieren die Möglichkeit, eine durchdachte Taxonomie zu implementieren.

  • Die Anwendung kann möglicherweise nur schwierig verwaltet werden.

  • Websites werden schneller nicht mehr verwendet.

  • Sie können Vorlagen und Navigation nicht für mehrere Projekte oder Teams verwenden, für die andernfalls eine gemeinsame Websitesammlung verwendet werden könnte.

• Erstellen Sie basierend auf der Arbeitsweise Ihrer Organisation eine begrenzte Anzahl von Websitesammlungen. Bei diesem Ansatz werden Websitesammlungen von einem SharePoint-Administrator erstellt. Nachdem die Websitesammlung erstellt wurde, können Teams Websites innerhalb der Websitesammlung basierend auf ihren Anforderungen erstellen. Dieser Ansatz bietet die Möglichkeit, eine anspruchsvolle Taxonomie zu implementieren, die das Verwalten und Wachsen der Teamwebsites gestattet. Außerdem können Vorlagen gemeinsam verwendet werden, und die Navigation zwischen Projekten und Teams, die gemeinsam eine Websitesammlung nutzen, ist ebenfalls möglich.

Im Entwurfsbeispiel wird der zweite Ansatz integriert, der eine ähnliche Websitesammlungshierarchie für Teamwebsites und für veröffentlichte Intranetinhalte zur Folge hat. Die Herausforderung für Informationsarchitekten ist das Erstellen einer zweiten Ebene mit Websitesammlungen, die für die Organisation sinnvoll ist. In der folgenden Tabelle sind Vorschläge für verschiedene Arten von Organisationen aufgeführt.

Typ der Organisation	Vorgeschlagene Websitesammlungstaxonomien
Produktentwicklung	Erstellen Sie eine Websitesammlung für jedes Produkt, das entwickelt wird. Ermöglichen Sie mitwirkenden Teams das Erstellen von Websites in der Websitesammlung. Erstellen Sie für jedes langfristige Entwicklungsprojekt eine Websitesammlung für jedes große Team, das am Produkt mitwirkt. Erstellen Sie beispielsweise eine Websitesammlung für jedes der folgenden Teams: Designer, Ingenieure und Inhaltsentwickler.
Forschung	Erstellen Sie eine Websitesammlung für jedes langfristige Forschungsprojekt. Erstellen Sie eine Websitesammlung für jede Kategorie von Forschungsprojekten.
Hochschule/Universität	Erstellen Sie eine Websitesammlung für jeden Fachbereich.
Ministerien	Erstellen Sie eine Websitesammlung für jede politische Partei. Regierungsmitglieder mit derselben Parteizugehörigkeit können Vorlagen und Navigation gemeinsam verwenden. Erstellen Sie eine Websitesammlung für jeden Ausschuss oder eine gemeinsame Websitesammlung für alle Ausschüsse.
Anwaltskanzlei	Erstellen Sie eine Websitesammlung für jeden Mandanten.
Fertigung	Erstellen Sie eine Websitesammlung für jede Produktlinie.

Partnerwebanwendung

Die Partnerwebanwendung dient der Zusammenarbeit mit externen Partnern an umfangmäßig oder zeitlich begrenzten Projekten. Die Websites innerhalb der Partnerwebanwendung sollen nicht unbedingt zusammenhängen. Es folgen die Anforderungen an die Partnerwebanwendung:

• Projektbesitzer können Websites für die Zusammenarbeit mit Partnern problemlos erstellen.

• Partner und andere Mitwirkende haben nur Zugriff auf das Projekt, an dem sie arbeiten.

• Berechtigungen werden von Websitebesitzern verwaltet.

• Suchergebnisse innerhalb eines Projekts enthalten keine Inhalte anderer Projekte.

• Administratoren können Websites, die nicht mehr verwendet werden, mühelos identifizieren und löschen.

Zum Erfüllen dieser Anforderungen enthält das Entwurfsbeispiel eine Websitesammlung für jedes Projekt. Auf diese Weise ergeben sich die folgenden Vorteile:

• Einzelne Websitesammlungen sorgen für die gewünschte Trennung zwischen den Projekten.

• Self-Service Site Creation kann implementiert werden.

Da die Partnerwebanwendung auch die Websitesammlungen zum Entwickeln von Inhalten für die Internetwebsite des Unternehmens hostet, werden für Erstellung und Bereitstellung gesonderte Websitesammlungen erstellt.

Internetwebsite des Unternehmens

Die Internetwebsite des Unternehmens umfasst eine einzelne Websitesammlung auf Stammebene. Alle Websites unterhalb dieser Websitesammlung sind Unterwebsites. Diese Struktur vereinfacht URLs für die Seiten innerhalb der Website. Die folgende Abbildung veranschaulicht die Architektur der Internetwebsite des Unternehmens.

Inhaltsdatenbanken

Sie können die folgenden beiden Ansätze befolgen, um Inhaltsdatenbanken in den Entwurf zu integrieren (das Entwurfsbeispiel berücksichtigt beide Ansätze):

• Richten Sie Zielgrößen für die Inhaltsdatenbanken mit entsprechenden Warnungsschwellenwerten ein. Erstellen Sie eine neue Datenbank, wenn der Warnungsschwellenwert erreicht ist. Bei diesem Ansatz werden Websitesammlungen basierend auf der Zielgröße automatisch der verfügbaren Datenbank oder den Datenbanken hinzugefügt. Dies ist die gängigste Vorgehensweise.

• Ordnen Sie Websitesammlungen bestimmten Inhaltsdatenbanken zu. Dieser Ansatz ermöglicht es Ihnen, eine oder mehrere Websitesammlungen in einer dedizierten Datenbank zu speichern, die unabhängig vom Rest verwaltet werden kann.

Wenn Sie Websitesammlungen bestimmten Inhaltsdatenbanken zuordnen möchten, können Sie dazu die folgenden Methoden verwenden:

• Erstellen Sie mit Windows PowerShell eine Websitesammlung in einer bestimmten Datenbank.

• Ordnen Sie eine Datenbank einer einzelne Websitesammlung mit den folgenden Datenbankkapazitätseinstellungen dediziert zu:

  • Anzahl von Websites, bevor ein Warnungsereignis generiert wird = 1

  • Maximale Anzahl von Websites, die in dieser Datenbank erstellt werden können = 1

• Führen Sie die folgenden Schritte aus, um einer dedizierten Datenbank eine Gruppe von Websitesammlungen hinzuzufügen:

  1. Erstellen Sie in der Webanwendung eine Datenbank, und legen Sie als Status Bereit fest.

  2. Legen Sie den Status aller anderen Datenbanken auf Offline fest. Solange die Inhaltsdatenbanken offline sind, können keine neuen Websitesammlungen erstellt werden. Auf vorhandene Websitesammlungen in Offlinedatenbanken kann jedoch weiterhin für Lese- und Schreibvorgänge zugegriffen werden.

  3. Erstellen Sie die Websitesammlungen, die der Datenbank automatisch hinzugefügt werden.

  4. Legen Sie den Status aller anderen Datenbanken wieder auf Bereit fest.

Veröffentlichte Intranetinhalte

Für veröffentlichte Intranetinhalte bietet das Entwurfsbeispiel zur Vereinfachung der Verwaltung eine einzelne Datenbank für jede Abteilungswebsitesammlung. Fügen Sie bei Bedarf Datenbanken basierend auf der Zielgröße zu.

Meine Websites

Bei Meine Websites erreicht das Entwurfsbeispiel eine hohe Effizienz durch das Verwalten der Datenbanken bis zur maximalen Zielgröße. Die folgenden Einstellungen wurden zum Erreichen dieser Vorgabe konfiguriert:

• Websitespeicher begrenzen auf ein Maximum von: Diese Einstellung, die Sie auf der Seite Kontingentvorlagen in der Zentraladministration festlegen, beschränkt die Größe einer persönlichen Website.

• Endgültiger Papierkorb: Diese Einstellung, die Sie auf der Seite Allgemeine Webanwendungseinstellungen konfigurieren, bestimmt, wie viel zusätzlicher Speicherplatz dem endgültigen Papierkorb zugewiesen wird.

• Maximale Anzahl an Websites, die in dieser Datenbank erstellt werden können: Diese Einstellung wird konfiguriert, wenn Sie eine Datenbank erstellen, und dient zur Berechnung der insgesamt zulässigen Größe von Websites mithilfe der Angaben, die Sie für die vorherigen beide Werte festlegen. Basierend auf der Zielgröße für jede Datenbank wird dann bestimmt, wie viele Websites in die Datenbank passen.

Das Entwurfsbeispiel bietet die folgenden Beispielgrößeneinstellungen basierend auf einer Zieldatenbankgröße von 200 Gigabytes (GB) und einer Zielgröße für "Meine Website" von 1 GB.

• Größenbeschränkung pro Website = 1 GB

• Zielgröße der Datenbank = 175 GB

• Reservierte Größe für endgültigen Papierkorb = 15 %

• Maximale Anzahl von Websites = 180

• Warnung zur Anzahl von Websites = 150

Wenn der Wert zur Warnung zur Anzahl von Websites erreicht ist, erstellen Sie eine neue Datenbank. Nach dem Erstellen der neuen Datenbank werden neue Websites vom Typ Meine Website abwechselnd der neuen Datenbank und der vorhandenen Datenbank hinzugefügt, bis die maximale Anzahl der Websites für eine der Datenbanken erreicht ist.

Teamwebsites

Auch bei Teamwebsites erreicht das Entwurfsbeispiel eine hohe Effizienz durch das Verwalten der Datenbanken bis zur maximalen Zielgröße. In den meisten Organisationen sind Teamwebsites wesentlich größer als Meine Websites. Das Entwurfsbeispiel stellt Datenbankeinstellungen basierend auf einem Grenzwert von 30 GB für Websitesammlungen zur Verfügung. Wählen Sie einen Grenzwert, der für Teamwebsites in Ihrer Organisation geeignet ist.

Ein weiterer Ansatz für Organisationen mit Teams mit hohen Speicheranforderungen besteht darin, jeder Teamwebsitesammlung auf oberster Ebene eine einzelne Datenbank dediziert zuzuordnen.

Partnerwebanwendung

Wie bei Meine Websites erreicht die Partnerwebanwendung eine hohe Effizienz durch Verwalten von Datenbanken bis zur maximalen Zielgröße. Im Entwurfsbeispiel hostet jedoch die Partnerwebanwendung auch die Websitesammlung für die Dokumenterstellung für die Internetwebsite des Unternehmens. Folglich enthält der Datenbankentwurf beide Ansätze:

• Die Websitesammlung für die Dokumenterstellung wird in einer dedizierten Datenbank gehostet.

• Datenbank- und Größeneinstellungen werden zum Erfüllen der Anforderungen aller anderen Websites und Datenbanken konfiguriert.

Da die Partnerwebanwendung in einer dedizierten Webanwendung gehostet wird, können Sie Größenbeschränkungen festlegen, die für die erstellten Websitetypen besser geeignet sind. Das Entwurfsbeispiel bietet das folgende Beispiel für Größeneinstellungen:

• Zielgröße der Datenbank = 200 GB

• Speicherkontingent pro Website = 5 GB

• Maximale Anzahl von Websites = 40

• Die Websitesammlung für die Dokumenterstellung wird in einer dedizierten Datenbank gehostet

Internetwebsite des Unternehmens

Indem Sie im Entwurf der Internetwebsite des Unternehmens eine einzelne Websitesammlung verwenden, nutzen Sie für diese Webanwendung eine einzelne Datenbank.

Zonen und URLs

Das Entwurfsbeispiel veranschaulicht, wie URLs innerhalb einer Unternehmensbereitstellung anwendungsübergreifend koordiniert werden.

Entwurfsziele

Die folgenden Ziele beeinflussen die Entwurfsentscheidungen für URLs:

• URL-Konventionen beschränken nicht die Zonen, über die auf Inhalte zugegriffen werden kann.

• Die HTTP- und HTTPS-Standardports (80 und 443) können in allen Anwendungen im Entwurfsbeispiel verwendet werden.

• Portnummern sind nicht in URLs enthalten. In der Praxis werden Portnummern normalerweise nicht in Produktionsumgebungen verwendet.

Entwurfsgrundsätze

Zum Erreichen dieser Entwurfsziele wurden die folgenden Entwurfsprinzipien befolgt:

• Es werden keine Websitesammlungen mit Hostnamen verwendet. Beachten Sie, dass Websitesammlungen mit Hostnamen sich von IIS-Hostheadern unterscheiden. Websitesammlungen mit Hostnamen können nicht zusammen mit alternativen Zugriffszuordnungen verwendet werden. Die alternativen Zugriffszuordnungen sind für den Zugriff auf denselben Inhalt über mehrere Domänen-URLs erforderlich. Folglich stehen bei Verwenden von Websites mit Hostnamen diese Websites nur über die Zone Standard zur Verfügung.

• Zu jeder Anwendung gehört eine einzelne Stammwebsitesammlung. Dies ist eine Voraussetzung für die Verwendung alternativer Zugriffszuordnungen. Wenn mehrere Stammwebsitesammlungen innerhalb einer Webanwendung erforderlich sind und Sie voraussichtlich nur die Zone Standard für den Benutzerzugriff verwenden, sind Websitesammlungen mit Hostnamen eine gute Wahl.

• Für Anwendungen, die mehrere allgemeine Websitesammlungen enthalten, in denen jede Websitesammlung ein übergeordnetes Team oder Projekt (z. B. Teamwebsites) darstellt, enthält das Entwurfsbeispiel verwaltete Pfade. Verwaltete Pfade bieten für diese Websitetypen bessere Steuerungsmöglichkeiten über URLs.

Kompromisse beim Entwurf

Die Erfüllung der Entwurfsziele führt zu einigen Kompromissen, z. B.:

• URLs sind länger.

• Websitesammlungen mit Hostnamen werden nicht verwendet.

Entwerfen von Lastenausgleichs-URLs

Beim Erstellen einer Webanwendung müssen Sie eine Lastenausgleichs-URL auswählen, die der Anwendung zugeordnet wird. Darüber hinaus müssen Sie eine Lastenausgleichs-URL für jede Zone erstellen, die Sie innerhalb einer Webanwendung erstellen. Die Lastenausgleichs-URL enthält das Protokoll, das Schema, den Hostnamen und den Port (falls verwendet). Die Lastenausgleichs-URL muss für alle Webanwendungen und Zonen eindeutig sein. Daher erfordert jede Anwendung und jede Zone innerhalb jeder Anwendung im Entwurfsbeispiel eine eindeutige URL.

Intranet

Jede der drei Webanwendungen, die das Intranet umfasst, erfordert eine eindeutige URL. Im Entwurfsbeispiel sind die Zielgruppen für den Intranetinhalt interne Mitarbeiter und Remotemitarbeiter. Im Entwurfsbeispiel für die anspruchsbasierte Authentifizierung verwenden Mitarbeiter für alle diese Anwendungen unabhängig davon dieselben URLs, ob diese lokal oder remote sind. Wenngleich durch diesen Ansatz der SharePoint-Entwurf mit zusätzlichem Schutz versehen wird (der gesamte Datenverkehr ist SSL-geschützt), erfordert dieser Ansatz entweder ein Routing des internen Datenverkehrs durch das Firewall- oder Gatewayprodukt zusammen mit dem Remotedatenverkehr oder das Einrichten einer geteilten DNS-Umgebung zum Auflösen interner Anforderungen innerhalb des internen Netzwerks.

Beim Entwurfsbeispiel für die klassische Authentifizierung sind die URLs für interne und Remotemitarbeiter unterschiedlich. In der folgenden Tabelle sind die URLs aufgeführt, über die interne und Remotemitarbeiter auf jede Anwendung im Entwurfsbeispiel für die klassische Authentifizierung zugreifen können.

Anwendung	URL für interne Mitarbeiter	URL für Remotemitarbeiter
Veröffentlichte Intranetinhalte	http://fabrikam	https://intranet.fabrikam.com
Teamwebsites	http://teams	https://teams.fabrikam.com
Meine Websites	http://my	https://my.fabrikam.com

Partnerwebsite

Im Entwurfsbeispiel greifen interne Mitarbeiter, Remotemitarbeiter und Partnermitarbeiter auf die Partnerwebanwendung zu. Beim Entwurfsbeispiel für die anspruchsbasierte Authentifizierung geben diese Benutzer unabhängig von der Authentifizierungsmethode dieselbe URL ein. Beim Entwurfsbeispiel für die klassisch Authentifizierung geben die unterschiedlichen Benutzertypen eine andere URL ein. Obwohl Remote- und Partnermitarbeiter extern über SSL (HTTPS) auf die Partnerwebsite zugreifen, benötigt jede Gruppe eine andere URL, um die Vorteile separater Zonen zu nutzen, d. h. verschiedene Authentifizierungsmethoden und unterschiedliche Zonenrichtlinien. In der folgenden Tabelle sind die URLs aufgeführt, über die interne und Remotemitarbeiter sowie Partner auf die Partnerwebsite zugreifen (siehe das Entwurfsbeispiel für die klassische Authentifizierung).

Zone	URL
URL für interne Mitarbeiter	http://partnerweb
URL für Remotemitarbeiter	https://remotepartnerweb.fabrikam.com
URL für Partner	https://partnerweb.fabrikam.com

Internetwebsite des Unternehmens

Die Internetwebsite des Unternehmens ist eine öffentliche Website, auf die alle Benutzer über die Standard-URL zugreifen können: http://www.fabrikam.com. Es gelten die Richtlinien der Internetzone (anonymer Zugriff, Schreibzugriff verweigern).

Zur Unterstützung von Verwaltungs- und Erstellungsaufgaben auf der öffentlichen Website bietet das Entwurfsbeispiel auch URLs für interne und Remotemitarbeiter. Sie können mithilfe von Richtlinien für diese Zonen sicherstellen, dass die gewünschten Sicherheitsgruppen für Erstellungs- und Verwaltungsaufgaben über einen ordnungsgemäßen Zugriff verfügen. Für diese Farm ist der Ansatz in den Entwurfsbeispielen für die klassische und anspruchsbasierte Authentifizierung identisch. Die folgende Tabelle enthält die URLs für jede Zone.

Zone	URL
URL für interne Mitarbeiter	http://fabrikamsite
URL für Remotemitarbeiter	https://fabrikamsite.fabrikam.com
URL für Kunden	http://www.fabrikam.com

Verwenden ausdrücklicher und Platzhalterinklusionen für URL-Pfade

Durch die Definition verwalteter Pfade können Sie angeben, welche Pfade im URL-Namespace einer Webanwendung für Websitesammlungen verwendet werden sollen. Sie können angeben, dass eine oder mehrere Websitesammlungen in einem speziellen Pfad unterhalb der Stammwebsite vorhanden sein sollen. Ohne verwaltete Pfade sind alle unterhalb der Stammwebsitesammlung erstellten Websites Teil der Stammwebsitesammlung.

Sie können folgende beiden Typen verwalteter Pfade erstellen:

• Ausdrückliche Inklusion: Eine Websitesammlung mit der ausdrücklichen URL, die Sie zuweisen. Eine ausdrückliche Inklusion gilt für nur eine Websitesammlung. Sie können viele ausdrückliche Inklusionen unterhalb einer Stammwebsitesammlung erstellen. Eine Beispiel-URL einer Websitesammlung, die mithilfe dieser Methode erstellt wurde, ist http://fabrikam/HR. Jeder weitere hinzugefügte ausdrückliche Pfad wirkt sich auf die Systemleistung aus, weshalb empfohlen wird, die im Rahmen einer ausdrücklichen Inklusion erstellten Websitesammlungen auf ca. 20 zu beschränken.

• Platzhalterinklusion: Ein Pfad, der der URL hinzugefügt wird. Dieser Pfad gibt an, dass alle Websites, die direkt hinter dem Pfadnamen angegeben werden, eindeutige Websitesammlungen sind. Diese Option wird in der Regel für Websitesammlungen verwendet, die eine Erstellung mithilfe von Self-Service Site Creation ermöglichen, z. B. Meine Websites. Eine Beispiel-URL einer Websitesammlung, die mithilfe dieser Methode erstellt wurde, ist http://my/personal/user1.

Im Entwurfsbeispiel werden beide Typen verwendet (siehe die folgenden Abschnitte).

Ausdrückliche Inklusionen: Veröffentlichte Intranetinhalte

Im Entwurfsbeispiel werden in der Webanwendung für veröffentlichte Intranetinhalte ausdrückliche Inklusionen verwendet.

Veröffentlichte Intranetinhalte

In der Anwendung für veröffentlichte Intranetinhalte wird eine ausdrückliche Inklusion für jede Unterwebsite verwendet: HR, Facilities und Purchasing. Jede dieser Websitesammlungen kann bei Bedarf einer anderen Inhaltsdatenbank zugeordnet werden. Die Verwendung ausdrücklicher Inklusionen in diesem Beispiel setzt voraus, dass in der Webanwendung keine anderen Websitetypen, einschließlich Platzhalterinklusionen, erstellt werden.

Der empfohlene Grenzwert für Websites, die mithilfe einer ausdrücklichen Inklusion erstellt werden, ist ca. 20. Sollte Ihre Organisation mehr Websitesammlungen benötigen, erwägen Sie die Platzhalterinklusion oder Websitesammlungen mit Hostnamen.

Im Entwurfsbeispiel für die klassische Authentifizierung führt die Verwendung ausdrücklicher Inklusionen zu den URLs in der folgenden Tabelle.

Interner Mitarbeiter (Zone "Intranet")	Remotemitarbeiter (Zone "Standard")
http://fabrikam	https://intranet.fabrikam.com
http://fabrikam/hr	https://intranet.fabrikam.com/hr
http://fabrikam/facilities	https://intranet.fabrikam.com/facilities
http://fabrikam/purchasing	https://intranet.fabrikam.com/purchasing

In diesem Beispiel stellt die Stammwebsitesammlung, http://fabrikam, die Standardhomepage für das Intranet dar. Diese Website dient zum Hosten von Inhalten für Benutzer.

Platzhalterinklusionen: Teamwebsites, "Meine Websites" und Partnerwebanwendung

Teamwebsites, "Meine Websites" und die Partnerwebanwendung sehen die Verwendung einer Platzhalterinklusion vor. Platzhalterinklusionen sind ideal für Anwendungen, die Benutzern das Erstellen eigener Websitesammlungen erlauben, und auch ideal für Webanwendungen, die zahlreiche Websitesammlungen enthalten. Eine Platzhalterinklusion gibt an, dass das nächste Element nach dem Platzhalter eine Stammwebsite einer Websitesammlung ist.

Teamwebsites

In der Anwendung "Teamwebsites" wird eine Platzhalterinklusion für jede Teamwebsitesammlung verwendet. Zur einfacheren Steuerung wird empfohlen, die Anzahl der Teamwebsites auf der obersten Ebene auf eine verwaltbare Anzahl zu beschränken. Die Taxonomie für Teamwebsites sollte zudem für Ihr Unternehmen logisch sein.

Im Entwurfsbeispiel für die klassische Authentifizierung führt die Verwendung von Platzhalterinklusionen zu den URLs in der folgenden Tabelle.

Interner Mitarbeiter (Zone "Intranet")	Remotemitarbeiter (Zone "Standard")
http://teams/sites/Team1	https://teams.fabrikam.com/sites/Team1
http://teams/sites/Team2	https://teams.fabrikam.com/sites/Team2
http://teams/sites/Team3	https://teams.fabrikam.com/sites/Team3

In diesem Beispiel hostet die Stammwebsitesammlung http://team nicht notwendigerweise Inhalte für Benutzer.

Meine Websites

Die Funktion Meine Websites ermöglicht die eigenständige Websiteerstellung. Wenn ein Benutzer, der das Intranet durchsucht, erstmals auf Meine Website klickt, wird automatisch eine Website vom Typ Meine Website für den Benutzer erstellt. Im Entwurfsbeispiel enthalten Meine Websites eine Platzhalterinklusion mit der Bezeichnung /Personal (http://My/Personal). Die Funktion Meine Website fügt automatisch den Benutzernamen an die URL an.

Im Entwurfsbeispiel für die klassische Authentifizierung führt dies zu URLs mit dem in der folgenden Tabelle gezeigten Format.

Intern (Zone "Intranet")	Remotemitarbeiter (Zone "Standard")
http://my/personal/user1	https://my.fabrikam.com/personal/user1
http://my/personal/user2	https://my.fabrikam.com/personal/user2
http://my/personal/user3	https://my.fabrikam.com/personal/user3

Partnerwebanwendung

Die Partnerwebanwendung soll Mitarbeitern die Erstellung sicherer Websites für die Zusammenarbeit mit externen Partnern ermöglichen. Zur Unterstützung dieses Ziels ist die eigenständige Erstellung von Websites zulässig.

Im Entwurfsbeispiel für die klassische Authentifizierung enthält die Partnerwebanwendung eine Platzhalterinklusion mit der Bezeichnung /sites (http://partnerweb/sites). Dies führt zu URLs mit dem in der folgenden Tabelle gezeigten Format.

Interner Mitarbeiter (Zone "Intranet")	Remotemitarbeiter (Zone "Standard")
http://partnerweb/sites/project1	https://remotepartnerweb.fabrikam.com/sites/project1
http://partnerweb/sites/project2	https://remotepartnerweb.fabrikam.com/sites/project2
http://partnerweb/sites/project3	https://remotepartnerweb.fabrikam.com/sites/project3

Mitwirkende bei Partnern können auf die Partnerwebsites über die URLs zugreifen, die in der folgenden Tabelle angegeben sind.

Partner (Zone "Extranet")
https://partnerweb.fabrikam.com/sites/project1
https://partnerweb.fabrikam.com/sites/project2
https://partnerweb/fabrikam.com/sites/project3

Die Ausnahme für Partnerwebanwendung (wie im Entwurfsbeispiel dargestellt) bildet die Websitesammlung, die für die Erstellung des Inhalts für die Internetwebsite des Unternehmens reserviert ist. Für diese Websitesammlung wird eine ausdrückliche Inklusion verwendet. Dies ist ein Beispiel für die Verwendung von ausdrücklichen und Platzhalterinklusionen in derselben Webanwendung.

Zonenrichtlinien

Sie können eine Richtlinie für eine Webanwendung erstellen, um Berechtigungen auf Webanwendungsebene zu erzwingen. Eine Richtlinie kann im Allgemeinen nur für die Webanwendung oder eine bestimmte Zone definiert werden. Eine Richtlinie erzwingt Berechtigungen für sämtliche Inhalte innerhalb der Webanwendung oder Zone. Richtlinienberechtigungen überschreiben alle anderen Sicherheitseinstellungen, die für Websites und Inhalte konfiguriert sind. Sie können Richtlinien basierend auf Benutzern oder Benutzergruppen, jedoch nicht basierend auf SharePoint-Gruppen konfigurieren. Wenn Sie eine Zonenrichtlinie hinzufügen oder ändern, muss die Suchfunktion Websites erneut durchforsten, um die neuen Berechtigungen zu erfassen.

Im Entwurfsbeispiel für die anspruchsbasierte Authentifizierung werden für die zusammenarbeitsorientierte Farm, bei der mehrere Authentifizierungstypen für eine einzelne Zone aktiviert sind, keine Richtlinien verwendet. Im Entwurfsbeispiel für die klassische Authentifizierung und für die veröffentlichte Farm im Entwurfsbeispiel für die anspruchsbasierte Authentifizierung, bei dem die Windows-Authentifizierung vorgeschrieben ist, werden Richtlinien implementiert. Für die veröffentlichte Farm fügt die Verwendung von Richtlinien eine weitere Schutzebene zwischen anonymen Benutzern und Benutzern mit Zugriff auf die Websiteverwaltung hinzu.

Das Entwurfsbeispiel bietet Beispiele für mehrere Richtlinien, die Folgendes bezwecken:

• Verweigern des Schreibzugriffs auf veröffentlichte Inhalte

• Sicherstellen, dass Autoren und Tester über entsprechenden Zugriff auf veröffentlichte Inhalte verfügen