SharePoint Server-Entwurfsbeispiele: Unternehmensportal und Extranetwebsites

 

**Gilt für:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Letztes Änderungsdatum des Themas:**2017-08-21

Zusammenfassung: Hier finden Sie Informationen zu den Designoptionen der logischen Architektur für die gängigsten SharePoint 2013- und SharePoint 2016-Entwurfsbeispiele beschrieben.

In diesem Artikel werden mehrere Entwurfsbeispiele erläutert, die als Ausgangsarchitekturen für SharePoint-Websites verwendet werden können. Die in diesem Artikel beschriebenen Entwurfsbeispiele veranschaulichen Standardarchitekturen für die gängigsten SharePoint-Websitetypen, die in einem Unternehmen oder einer Organisation bereitgestellt werden.

Inhalt dieses Artikels:

• Informationen zu den Entwurfsbeispielen

• In den Entwurfsbeispielen enthaltene Websites

• Allgemeine Entwurfsziele

• Serverfarmen

• Benutzer, Zonen und Authentifizierung

• Dienste

• Administrationswebsites

• Anwendungspools

• Webanwendungen

• Websitesammlungen

• Inhaltsdatenbanken

• Zonen und URLs

• Zonenrichtlinien

Informationen zu den Entwurfsbeispielen

In diesem Artikel sind die folgenden Entwurfsbeispiele beschrieben:

• Unternehmensportal mit pfadbasierten Websites

• Unternehmensportal mit Websites mit Hostnamen

• Extranet mit dedizierten Zonen für die Authentifizierung

Die Entwurfsbeispiele veranschaulichen Websites für das fiktive Unternehmen Fabrikam, Inc. Die Entwurfsbeispiele enthalten nahezu alle logischen Architekturkomponenten und verdeutlichen deren Integration in den Gesamtentwurf. 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.

Entwurfsbeispiel für ein Unternehmensportal – zwei Versionen

Websitesammlungen mit Hostnamen in SharePoint Server bieten URL-Verwaltung und Skalierbarkeit von Websites in einer einzelnen Webanwendung. Die beiden Versionen des Entwurfsbeispiels für ein Unternehmensportal zeigen Implementierungen, die auf die Verwendung der herkömmlichen pfadbasierten Websitesammlungen oder Websitesammlungen mit Hostnamen. Beide Entwurfsbeispiele verwenden die anspruchsbasierte Authentifizierung mit einer einzelnen Zone. Diese Beispiele werden später im Artikel ausführlicher behandelt.

Grundsätzlich wird der auf Websitesammlungen mit Hostnamen basierende Entwurf empfohlen – es sei denn, besondere Anforderungen sprechen für pfadbasierte Websites mit alternativer Zugriffszuordnung (siehe Websitesammlungsarchitektur mit Hostnamen und Bereitstellung in SharePoint Server). Dieser Entwurf wird empfohlen, da der Office 365-Umgebung dieselbe Architektur zugrunde liegt. Demzufolge ist dies die meistgetestete Konfiguration. Neue Features, wie z. B. das App-Modell und die Anforderungsverwaltung, wurden für diese Konfiguration optimiert. Somit stellt dies die zuverlässigste Konfiguration dar.

Extranet mit dedizierten Zonen für die Authentifizierung

Das Entwurfsbeispiel für ein Extranet mit dedizierten Zonen für die Authentifizierung umfasst nur die Partnerwebsite. Es bietet eine Alternativkonfiguration für die Partnerzusammenarbeit, bei der für jede Authentifizierungsmethode dedizierte Zonen verwendet werden. Alle Entwurfsbeispiele verwenden die anspruchsbasierte Authentifizierung für Webanwendungen. Der Unterschied zwischen den Entwurfsbeispielen für ein Unternehmensportal und dem Beispiel für ein Extranet besteht in der Konfiguration der Zonen. Das Extranet mit dedizierten Zonen für die Authentifizierung verwendet mehrere Zonen, und pro Zone wird eine Authentifizierungsmethode konfiguriert. Die Entwurfsbeispiele für ein Unternehmensportal verwenden eine Zone, und es werden mehrere Authentifizierungsmethoden für verschiedene Benutzerklassen konfiguriert.

Das Entwurfsbeispiel für ein Extranet mit dedizierten Zonen für die Authentifizierung führt auch eine neue Empfehlung für Zugriff durch Remotemitarbeiter ein – den direkten Zugriff mit Windows Server 2012. Eine Alternative zu dieser Empfehlung ist das Erstellen eines virtuellen privaten Netzwerks (VPN). Sie können auch die formularbasierte Authentifizierung für das Firewall- oder Gatewayprodukt zum Erfassen und ggf. Weiterleiten von Anmeldeinformationen verwenden.

Implementierung der Websitesammlungen in den Entwurfsbeispielen

Frühere Versionen des Entwurfsbeispiels für ein Unternehmensportal verwendeten pfadbasierte Websitesammlungen. Künftig werden jedoch Websitesammlungen mit Hostnamen empfohlen, außer wenn durch Anforderungen festgelegt ist, dass die herkömmlichen pfadbasierten Websites mit alternativer Zugriffszuordnung (Alternate Access Mapping, AAM) erforderlich sind. Dies wird folgendermaßen in den Entwurfsbeispielen widergespiegelt:

• Unternehmensportal mit pfadbasierten Websitesammlungen – dieses Beispiel veranschaulicht herkömmliche pfadbasierte Websitesammlungen, bei denen Websites in dedizierten Webanwendungen angeordnet sind, sowie eine einzelne Websitesammlung auf oberster Ebene pro Webanwendung. Verwenden Sie diese Methode, wenn Sie die zusätzliche Sicherheit nutzen möchten, die bei mehreren Webanwendungen mit separaten Anwendungspools gegeben ist.

• Unternehmensportal mit Websitesammlungen mit Hostnamen – dieses Beispiel veranschaulicht die Verwendung von Websitesammlungen mit Hostnamen für alle in einer einzelnen Webanwendung in der Farm bereitgestellten Websites. Diese Methode bietet eine hohe Skalierbarkeit und mehr Flexibilität beim Verwalten von URLs.

• Extranet mit dedizierten Zonen für die Authentifizierung – dieses Beispiel veranschaulicht zahlreiche Projektwebsites auf oberster Ebene mit Vanity-URLs, indem für jede Projektwebsite Websites mit Hostnamen verwendet werden (anstatt Projektwebsites unterhalb einer Websitesammlung auf oberster Ebene anzuordnen). Ein Vorteil einer solchen Verwendung von Websitesammlungen mit Hostnamen ist das Erzeugen von zusätzlicher Isolation zwischen Domänen-URLs, die in einer Partnerzusammenarbeitslösung möglicherweise wünschenswert ist. Der Kompromiss bei dieser Methode besteht jedoch in den zusätzlichen Kosten für die Verwaltung einer größeren Anzahl von Hostnamen, einschließlich der Verwaltung von SSL-Zertifikaten. Außerdem sind bei Verwendung der SAML-Authentifizierung zusätzliche Konfigurationen erforderlich (siehe "Verwenden der SAML-Authentifizierung mit Websites mit Hostnamen" weiter unten in diesem Artikel).

Anspruchsbasierte Authentifizierung für SharePoint Server

Die Funktionsweise der Authentifizierung in SharePoint Server beeinflusst u. U. Entwurfsentscheidungen im Zusammenhang mit der Implementierung von Optionen, die von diesen Entwurfsbeispielen dargestellt werden. Es folgen einige Beispiele:

• In SharePoint Server ist die anspruchsbasierte Authentifizierung der Standardmodus und als einzige Option über die Zentraladministration verfügbar. Der klassische Authentifizierungsmodus kann mithilfe von PowerShell implementiert werden.

• In SharePoint Server müssen Sie für die Verwendung der SAML-Anspruchsauthentifizierung auf dem Lastenausgleichsmodul keine Serveraffinität konfigurieren. Der Lastenausgleich ohne Affinität wird von SharePoint Server vollständig unterstützt.

In SharePoint Server erfordert das Konto für die Durchforstung von Inhalten Zugriff auf Inhalte über die Standardzone mithilfe der integrierten Windows-Authentifizierung (NTLM oder Kerberos). Da die Anspruchsauthentifizierung mehrere Authentifizierungstypen in einer Zone zulässt, sollte sich diese Anforderung nicht auf andere Authentifizierungsanforderungen auswirken.

Zusammenfassung der Entwurfsbeispielfeatures

Die folgende Tabelle enthält eine Zusammenfassung der drei in diesem Artikel behandelten Entwurfsbeispiele.

Tabelle: Zusammenfassung der Entwurfsbeispiele

Entwurfsbeispiel	Inhalt	Wichtige Entwurfselemente
Unternehmensportal mit pfadbasierten Websites	Gängigste in einer Organisation bereitgestellte Websitetypen	Pfadbasierte Websitesammlungen Anspruchsbasierte Authentifizierung Mehrere in einer einzelnen Zone implementierte Authentifizierungsanbieter und -typen
Unternehmensportal mit Websites mit Hostnamen	Gängigste in einer Organisation bereitgestellte Websitetypen	Websitesammlungen mit Hostnamen Anspruchsbasierte Authentifizierung Mehrere in einer einzelnen Zone implementierte Authentifizierungsanbieter und -typen
Extranet mit dedizierten Zonen für die Authentifizierung	Nur die Partnerwebsite. Bietet eine alternative Konfiguration für die Partnerzusammenarbeit.	Websitesammlungen mit Hostnamen Anspruchsbasierte Authentifizierung Verschiedene Zonen für alle Authentifizierungsmethoden

In den Entwurfsbeispielen enthaltene Websites

In diesem Abschnitt werden die in den Entwurfsbeispielen enthaltenen Websites beschrieben.

Intranetwebsites

Das Unternehmensportal enthält folgende Websites für die Verwendung innerhalb eines Intranets:

• 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 hat folgende Eigenschaften:

• Hebt die unterschiedlichen Features von SharePoint Server 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 folgende Features zu ermöglichen:

• Suchen im Unternehmen

• Gemeinsam genutzte Profildaten und Unternehmensmetadaten

Die folgende Abbildung aus dem Entwurfsbeispiel für das Unternehmensportal mit pfadbasierter Websitesammlung zeigt die drei Websitetypen, die das Unternehmensintranet umfasst.

Websitetypen, die das Unternehmensintranet umfasst

Partnerwebanwendung

Die Partnerwebanwendung hostet extern verfügbare Websites für eine sichere Zusammenarbeit mit Partnerunternehmen und einzelnen Partnern. Diese Anwendung ist dafür vorgesehen, dass Mitarbeiter Websites für eine sichere Zusammenarbeit problemlos erstellen können. Partner können nicht auf andere Inhaltstypen zuzugreifen, die in der Serverfarm gehostet werden. Der Entwurf für Zonen und Dienstanwendungen unterstreicht dieses Ziel. Darüber hinaus verwalten einzelne Websitebesitzer die Berechtigungen für Ihre Websites und laden nur die relevanten Teilnehmer zur Zusammenarbeit ein.

Im Entwurfsbeispiel für das Extranet ist dies der einzige dargestellte Websitetyp.

Allgemeine Entwurfsziele

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

• Erstellung eines Frameworks für das Entwerfen einer Umgebung, die auf Wachstum ausgelegt ist.

  Entwurfsentscheidungen für einzelne Websitetypen verhindern nicht das Hinzufügen von anderen Websitetypen. Beispielsweise kann eine Erstbereitstellung nur Teamwebsites für die Zusammenarbeit oder nur die drei Websitetypen enthalten, die zusammen das Intranet bilden (Teamwebsites, "Meine Websites" und veröffentlichter Intranetinhalt). Mithilfe eines ähnlichen logischen Architekturentwurfs können Sie der Lösung Websites 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 einschrä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), die andere Authentifizierungsanbieter verwenden, können an der Zusammenarbeit teilnehmen. Zudem dürfen die Benutzer auch nur auf Inhalte zugreifen, die dafür vorgesehen sind. Wenn Sie einem ähnlichen logischen Architekturentwurf folgen, können Sie Benutzern an mehreren Standorten und mit verschiedenen Zielen den Zugriff ermöglichen. Beispielsweise kann Ihr anfänglicher Entwurf nur für den Zugriff durch interne Mitarbeiter gedacht gewesen sein. Durch Verwendung eines ähnlichen Entwurfs können Sie nun jedoch auch Remotemitarbeitern, Partnermitarbeitern, Partnerunternehmen und Kunden den Zugriff ermöglichen.

• Stellen Sie sicher, dass der Entwurf in einer Extranetumgebung verwendet werden kann.

  Treffen Sie Entwurfsentscheidungen, die gewährleisten sollen, dass die Lösung in einem Umkreisnetzwerk sicher bereitgestellt werden kann.

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

In diesem Abschnitt werden die Topologien der im Entwurfsbeispiel dargestellten Serverfarmen beschrieben und die Skalierung außerhalb einer einzelnen Farm erläutert.

Topologie der Serverfarmen

Jede Serverfarm im Entwurfsbeispiel besteht aus sechs Servern mit folgender fehlertoleranten Topologie:

• Zwei Front-End-Webserver

• Zwei Anwendungsserver

• Zwei Datenbankserver mit SQL Server, die zur Unterstützung von SQL Server-Clustering, -Spiegelung oder AlwaysOn installiert und konfiguriert sind. AlwaysOn erfordert SQL Server 2012.

Das Konzept des Front-End- und Anwendungsservers unterscheidet sich in SharePoint Server 2016 (siehe Übersicht über MinRole-Serverrollen in SharePoint Server 2016).

Das Entwurfsbeispiel veranschaulicht die logische Architektur von SharePoint Server 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 nur wichtig, um bei Bedarf die Kapazität zu erhöhen und die Leistung zu verbessern. Sie können die logische Architektur unabhängig von der Serverfarmtopologie entwerfen. Der Prozess der 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 Planen der Leistung in SharePoint Server 2013 Planung.

Benutzer, Zonen und Authentifizierung

Die anspruchsbasierte Authentifizierung ist der standardmäßige Authentifizierungsmodus in SharePoint Server, und in jedem Entwurfsbeispiel wird die anspruchsbasierte Authentifizierung verwendet. Mithilfe von Windows PowerShell können Sie die klassiche Authentifizierung implementieren. Allerdings sind einige Features von SharePoint Server im klassischen Modus nicht verfügbar. Weitere Informationen zu Entwurfsbeispielen mit klassischer Authentifizierung finden Sie unter Entwurfsbeispiel: Bereitstellung im Unternehmen (SharePoint Server 2010)

Die folgende Tabelle enthält die Unterschiede zwischen den beiden Methoden, die in den Entwurfsbeispielen für das Unternehmensportal und das Extranet veranschaulicht werden.

Tabelle: Vergleich der Methoden für die Zonenkonfiguration in den Entwurfsbeispielen

	Unternehmensportal mit Websites mit Hostnamen und Unternehmensportal mit pfadbasierten Websites	Extranet mit dedizierten Zonen für die Authentifizierung
Authentifizierungsmodus	Anspruch	Anspruch
Zonenkonfiguration	Eine Zone mit mehreren für verschiedene Benutzerklassen konfigurierten Authentifizierungsmethoden.	Mehrere Zonen mit einer für alle Zonen konfigurierten Authentifizierungsmethode.
URLs	Alle Klassen von Benutzern verwenden dieselbe URL für jede Website. Mitarbeiter verwenden dieselbe URL, unabhängig davon, ob sie sich innerhalb oder außerhalb des Unternehmensnetzwerks befinden.	Jede Benutzerklasse verwendet eine andere URL, um auf eine Website zuzugreifen. Mitarbeiter verwenden eine andere URL, abhängig davon, ob sie sich innerhalb oder außerhalb des Unternehmensnetzwerks befinden.
Interne Anforderungen	Innerhalb des Unternehmensnetzwerks initiierte Anforderungen werden aus dem Netzwerk geleitet und über ein Gateway oder einen Proxyserver zurückgeleitet. Diese Anforderungen werden mit dem SSL (Secure Sockets Layer)-Protokoll gesichert. Als Alternative kann Split-DNS zum direkten Weiterleiten der Anforderungen an die interne Schnittstelle für die Server verwendet werden.	Innerhalb des Unternehmensnetzwerks initiierte Anforderungen verbleiben im Netzwerk.
Verwendung durch den Benutzer	Alle Benutzer werden aufgefordert, den Kontotyp auszuwählen, den Sie bei der Anmeldung verwenden.	Die Authentifizierungsmethode ist vordefiniert. Benutzer müssen den Kontotyp auf einer Anmeldeseite nicht auswählen.

In den folgenden Abschnitten wird insbesondere erläutert, wie die Authentifizierung in die beiden Entwurfsbeispiele integriert wird.

Entwurfsbeispiel für ein Extranet mit dedizierten Zonen

Das Extranet-Entwurfsbeispiel veranschaulicht drei verschiedene Klassen von Benutzern, wovon jeder einer anderen Zone zugeordnet ist. Innerhalb jeder Webanwendung können Sie bis zu fünf Zonen mit einem der verfügbaren Zonennamen erstellen: Standard, Intranet, Internet, Benutzerdefiniert oder Extranet. Das Konto für die Durchforstung von Inhalten benötigt unter Verwendung der integrierten Windows-Authentifizierung (NTLM- oder Kerberos-Protokoll) Zugriff auf die Standardzone, die im Entwurfsbeispiel ermittelt wird. Die folgende Tabelle stellt dar, wie Zonen im Extranet-Entwurfsbeispiel eingerichtet werden.

Tabelle: Zonen, Benutzer und Authentifizierungstypen im Entwurfsbeispiel für Extranet

Zone	Benutzer	Authentifizierung
Intranet	Interne und Remotemitarbeiter Durchforstungskonto	NTLM- oder Kerberosprotokoll Remotemitarbeiter, die sich mithilfe von Direct Access oder VPN verbinden.
Standard	Einzelne Partner	Optionen: LDAP-Verzeichnis mit formularbasierter Authentifizierung. Dem Internet zugewandte AD DS-Gesamtstruktur mit einer unidirektionalen Vertrauensstellung zur internen Gesamtstruktur und integrierten Windows-Authentifizierung. Vertrauenswürdiger Identitätsanbieter mit SAML-Authentifizierung
Extranet	Partnerunternehmen	Vertrauenswürdiger Partneridentitätsanbieter mit SAML-Authentifizierung

Entwurfsbeispiele für ein Unternehmensportal

Die anspruchsbasierte Authentifizierung lässt mehrere Authentifizierungsmethoden in derselben Zone zu. Die beiden Versionen des Beispiels für ein Unternehmensportal verwenden jeweils die Standardzone für alle Authentifizierungstypen.

Die folgende Tabelle zeigt die Zonen, Benutzer und Authentifizierungsmethoden, die von den Entwurfsbeispielen vorgeschrieben werden.

Tabelle: Zonen, Benutzer und Authentifizierung für die Entwurfsbeispiele für ein Unternehmensportal

Zone	Benutzer	Anbieter und Authentifizierungstyp
Standard	Interne und Remotemitarbeiter	AD SD (Active Directory Domain Services)- oder LDAP-Speicher mit formularbasierter Authentifizierung oder SAML-Authentifizierung.
Standard	Einzelne Partner	vertrauenswürdiger Identitätsanbieter mit SAML-Authentifizierung oder SQL Server-Datenbank mit formularbasierter Authentifizierung
Standard	Partnerunternehmen	Vertrauenswürdiger Partneridentitätsanbieter mit SAML-Authentifizierung
Standard	Durchforstungskonto	AD DS mit Windows-NTLM-Authentifizierung

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 für jede dieser Websites nur eine URL (mithilfe von SSL) implementiert, die intern und extern verwendet werden kann. Es werden AD DS-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 Zugriff haben. Die anspruchsbasierte Forderung in diesem Szenario erfordert die Konfiguration der Vertrauensstellung mit mindestens einem externem Identitätsanbieter. Wenden Sie eine der folgenden Methoden an:

• Sie können die SharePoint-Farm so konfigurieren, dass sie einem externen Identitätsanbieter vertraut, z. B. dem Anbieter, der sich in einem Partnerunternehmen befindet (damit eine direkte Authentifizierung im Abgleich mit den Partnerverzeichnissen erfolgen kann).

• Sie können den Identitätsanbieter innerhalb der Unternehmensumgebung so konfigurieren, dass er einem externen Identitätsanbieter vertraut. Administratoren in beiden Organisationen müssen diese Vertrauensstellung explizit bereitstellen. In diesem Szenario vertraut die SharePoint-Farm dem Identitätsanbieter in der eigenen Unternehmensumgebung. Wenn der Identitätsanbieter ein Token sendet, bestätigt die Farm die Gültigkeit des Tokens mithilfe des Tokensignaturzertifikats, das beim Einrichten der Vertrauensstellung angegeben wurde. Dieses Verfahren wird empfohlen.

Die formularbasierte Authentifizierung ist eine Alternative zu einer anspruchsbasierten Umgebung zum Authentifizieren von Partnern. Sie verwenden einen gesonderten Speicher wie z. B. eine Datenbank zum Verwalten dieser Konten.

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 für die 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 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 enthalten Links von der Standardzone. 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 Standardzone auf die Links zugreifen können. Dies ist besonders wichtig für Websitebesitzer.

In SharePoint Server kann von allen Zonen aus auf Websitesammlungen mit Hostnamen zugegriffen werden.

Konfigurieren von Zonen für eine Extranetumgebung

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

• Mehrere verschiedene Netzwerke können Benutzeranforderungen auslösen. In den Entwurfsbeispielen lösen Benutzer Anforderungen im internen Netzwerk, dem Internet und den Partnerunternehmen aus.

• Benutzer verwenden Inhalte von verschiedenen Webanwendungen. In den Entwurfsbeispielen besteht das Intranet aus drei Webanwendungen. Zudem können interne und externe Mitarbeiter potenziell Inhalte zur Partnerwebanwendung beisteuern und diese verwalten.

Wenn eine Extranetumgebung mehr als eine Zone umfasst, achten Sie darauf, folgende Entwurfsprinzipien zu befolgen:

• Konfigurieren Sie Zonen für mehrere Webanwendungen als einheitliches Abbild voneinander. Die Konfiguration der Authentifizierung und der zulässigen Benutzer sollte einander entsprechen. Die mit einer Zone verbundenen Richtlinien können sich jedoch je nach Webanwendung unterscheiden. Beispielsweise sollten Sie sicherstellen, dass die Intranetzone über alle Webanwendungen hinweg von den gleichen Mitarbeitern verwendet wird. Konfigurieren Sie daher keine separate Intranetzone für interne und externe Mitarbeiter in unterschiedlichen Webanwendungen.

• Wenn Sie pfadbasierte Websitesammlungen verwenden, konfigurieren Sie alternative Zugriffszuordnungen ordnungsgemäß und entsprechend der jeweiligen Zone und Ressource. Alternative Zugriffszuordnungen werden beim Erstellen einer Zone automatisch erstellt. Sie können SharePoint Server jedoch so konfigurieren, 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 Sie Websitesammlungen mit Hostnamen verwenden, achten Sie darauf, für die Zuordnung von URLs an die entsprechenden Zonen PowerShell zu verwenden.

Wenn webanwendungsübergreifende Zonen sich nicht gegenseitig spiegeln und Links zu externen Ressourcen nicht ordnungsgemäß sind, können folgende Risiken auftreten:

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

Verwenden der SAML-Authentifizierung mit Websites mit Hostnamen

Wenn ein Entwurf die Verwendung der SAML-Authentifizierung mit Websites mit Hostnamen umfasst, erfordert jede Vanity-URL Folgendes:

• Einen neuen Bereich auf dem SPTrustedIdentityTokenIssuer

• Eine entsprechende Relaypartei im Identitätsanbieter.

Dienste

Die Dienstarchitekturen unterscheiden sich je nach Entwurfsbeispiel. Das Entwurfsbeispiel für ein Unternehmensportal mit Websites mit Hostnamen enthält die einfachste Architektur für Dienste, da sie nur eine Webanwendung verwendet, die nur eine Dienstanwendungsgruppe (auch als "Proxygruppe" bezeichnet) tragen kann.

Das Beispiel für ein Unternehmensportal mit pfadbasierten Websites verwendet partitionierte Dienste für die Partnerwebsites, um Daten zwischen Projekten zu isolieren. Dieses Entwurfsbeispiel berücksichtigt zwei Dienstgruppen, eine für die Intranetwebsites und eines für die Partnerzusammenarbeits-Websites. Für die Partnerwebsites werden separate Instanzen verwalteter Metadaten und der Suchfunktion bereitgestellt, und diese Dienste sind partitioniert. Partitionierte Dienste erfordern den Abonnementeinstellungsdienst, der nur mithilfe von PowerShell bereitgestellt werden kann.

Dienstarchitektur für das Unternehmensportal mit pfadbasierten Websites

Die Architektur wird durch das Bereitstellen von partitionierten Diensten komplexer, sodass Websites später nur schwer zu Office 365 migriert werden können. Eine einfachere Option für die Partnerwebsites ist die Bereitstellung von dedizierten aber nicht partitionierten Instanzen der des verwalteten Metadatendiensts und des Suchdiensts, wenn diese separat bereitgestellt werden müssen. Viele Organisationen setzen auf die Funktion zum Einschränken der Sicherheit der Suche anstatt dedizierte Instanzen des Suchdiensts bereitzustellen.

Das Extranet-Entwurfsbeispiel umfasst nur eine Proxygruppe, verwendet aber auch partitionierte Dienste für die verwaltete Metadatendienstanwendung und die Suchdienstanwendung.

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. Im Entwurfsbeispiel für das Unternehmensportal mit pfadbasierten Websites ist eine Instanz des verwalteten Metadatendiensts 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.

Im Beispiel für das Unternehmensportal mit pfadbasierten Websitesammlungen, ist die Partnerwebanwendung zur Verwendung der dedizierten Suchdienst- und verwalteten Metadatendienstanwendungen konfiguriert; dazu wird eine benutzerdefinierte Dienstgruppe verwendet. Der benutzerdefinierten Gruppe werden weitere Dienstanwendungen hinzugefügt und für die Standardgruppe freigegeben. Das Entwurfsbeispiel umfasst nicht die Benutzerprofildienst-Anwendung, um zu verhindern, dass Partnerbenutzer personenbezogene Daten in der Organisation durchsuchen können.

In der vereinfachten Architektur des Unternehmensportals mit Websitesammlungen mit Hostnamen (eine Dienstgruppe) 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 Dienstanwendungen (wie in diesem Artikel veranschaulicht) eine gute Wahl. Dadurch wird die Komplexität der Architektur der Dienste erhöht, aber sichergestellt, dass Partner nicht auf Metadaten zugreifen können, die dem Intranetinhalt oder gar anderen Projekten in der Partnerwebsite zugeordnet sind. Das Extranet-Entwurfsbeispiel verwendet auch partitionierte Dienste.

Administrationswebsites

Im Entwurfsbeispiel hostet ein Anwendungsserver die Website für die SharePoint-Zentraladministration für jede Serverfarm. Dies schützt die Website vor direktem Benutzerkontakt. Wenn ein Leistungsengpass oder Sicherheitsproblem die Verfügbarkeit der Front-End-Webserver beeinträchtigt, bleibt die Website für die SharePoint-Zentraladministration 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 Website für die SharePoint-Zentraladministration optional 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. Dies verhindert, dass ein Angreifer, der Code auf einer Website einfügt, andere Server oder Websites an anderen Standorten beeinträchtigt.

Wenn ein einzelner Anwendungspool und eine Webanwendung zusammen mit Websitesammlungen mit Hostnamen verwendet werden, ist zwar Isolation zwischen Domänen-URLs vorhanden, jedoch nur auf Skriptebene.

Wenn Sie mehr als einen Anwendungspool implementieren ziehen Sie einen dedizierten Anwendungspool für jedes der folgenden Szenarien in Erwägung:

• Trennen authentifizierter Inhalte von anonymen Inhalten. Wenn dieselbe Farm die Internetwebsite des Unternehmens hostet, platzieren Sie diese Website in eine dedizierte Webanwendung und einen Anwendungspool.

• Isolieren von Websites, in denen Kennwörter für Back-End-Datensysteme gespeichert werden, mit denen sie interagieren (wenngleich der Secure Store Service für diesen Zweck verwendet werden kann)

In den Entwurfsbeispielen für das Unternehmensportal mit Websites mit Hostnamen und das Extranet mit dedizierten Zonen für die Authentifizierung wird jeweils ein einzelner Anwendungspool und eine Webanwendung für alle Inhalte implementiert. Separate Anwendungspools sind für Dienstanwendungen und die Website für die SharePoint-Zentraladministration erforderlich.

Im Beispiel für ein Unternehmensportal mit pfadbasierten Websites wird mithilfe separater Anwendungspools folgendermaßen eine Prozessisolation zwischen Inhalten implementiert:

• Die Administrationswebsite wird in einem dedizierten Anwendungspool gehostet. Dies ist eine Anforderung von SharePoint Server.

• Alle Dienstanwendungen werden in einem einzigen Anwendungspool bereitgestellt. Wenn kein besonderer Grund besteht, Dienstanwendungen in unterschiedlichen Anwendungspools bereitzustellen, ist dies die empfohlene Konfiguration. Ein gemeinsamer Anwendungspool für alle Dienstanwendungen optimiert die Leistung und verringert die Anzahl der zu verwaltenden Anwendungspools.

• Intranetinhalte werden in zwei verschiedene Anwendungspools unterteilt. Ein Anwendungspool hostet gemeinsame Inhalte ("Meine Websites" und Teamwebsites). Ein separater Anwendungspool hostet die veröffentlichten Intranetinhalte. Diese Konfiguration bietet Prozessisolierung für veröffentlichte Intranetinhalte, für die Geschäftsdatenverbindungen häufiger verwendet werden.

• Ein dedizierter Anwendungspool hostet die Partnerwebanwendung.

Webanwendungen

Eine Webanwendung ist eine von SharePoint Server erstellte und verwendete IIS-Website. Jede Webanwendung wird durch eine andere Website in IIS dargestellt.

Wenn Sie mehr als eine Webanwendung implementieren möchten, berücksichtigen Sie die folgenden Verwendungsszenarien:

• Trennen anonymer Inhalte von authentifizierten Inhalten.

  Wenn dieselbe Farm die Internetwebsite des Unternehmens hostet, platzieren Sie diese Website in eine dedizierte Webanwendung und einen Anwendungspool.

• Isolieren von Benutzern

  Im Entwurfsbeispiel wird die Partnerwebsite von einer dedizierten Webanwendung und einem Anwendungspool gehostet, um sicherzustellen, dass Partner keinen Zugriff auf den Intranetinhalt haben.

• Erzwingen von Berechtigungen

  Eine dedizierte Webanwendung bietet die Möglichkeit zum Implementieren von Richtlinien in den Zonen innerhalb der Webanwendung, um Berechtigungen zu erzwingen. Beispielsweise können Sie Richtlinien auf der Internetwebsite des Unternehmens erstellen und dadurch einer oder mehreren Gruppen von Benutzern den Schreibzugriff explizit verweigern. Richtlinien werden unabhängig von den Berechtigungen erzwungen, die auf einzelnen Websites oder Dokumenten in der Webanwendung konfiguriert sind.

• 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 die Möglichkeit 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.

Wenn Sie Websitesammlungen mit einer einzelnen Webanwendung implementieren, ist jede Website auf oberster Ebene eine unterschiedliche Domäne. Daher können Sie einige dieser Ziele erreichen, z. B. das Optimieren der Verwaltbarkeit durch das Implementieren verschiedener Websitelimits.

Websitesammlungen

Die empfohlene Konfiguration zur Bereitstellung von Websites ist die Verwendung von Websitesammlungen mit Hostnamen, wobei sich alle Websites in einer Webanwendung befinden. Diese Konfiguration wird für die Bereitstellung von Websites empfohlen, da es sich hierbei um dieselbe Architektur handelt, die die Office 365-Umgebung verwendet. Es handelt sich somit um die am besten geprüfte Konfiguration. Neue Features, einschließlich App-Model und Anforderungsverwaltung, werden für diese Konfiguration optimiert, und es handelt sich auch künftig um die zuverlässigste Konfiguration.

Obwohl die Verwendung von hostbenannten Websitesammlungen für die meisten Architekturen empfohlen wird, sollten Sie die herkömmlichen pfadbasierten Websitesammlungen und alternativen Zugriffszuordnungen verwenden, wenn folgende Bedingungen gelten:

• Sie müssen das Feature Self-Service Site Creation verwenden, das Teil der Standardinstallation von SharePoint Server 2016 ist.

  Dies gilt nicht für benutzerdefinierte Self-Service Site Creation-Lösungen.

• Eine Webanwendung erfordert eindeutige Platzhaltereinschlüsse oder explizite Ausschlüsse.

  Sie erstellen Einschlüsse für Websitesammlungen mit Hostnamen auf Farmebene, und die Einschlüsse sind für alle Websitesammlungen mit Hostnamen verfügbar. Für alle Websitesammlungen mit Hostnamen in einer Farm gelten dieselben Einschlüsse, müssen jedoch nicht verwendet werden. Im Gegensatz dazu gelten Einschlüsse, die Sie für pfadbasierte Websitesammlungen erstellt haben, nur für eine einzelne Webanwendung.

• Die SSL-Beendigung ist erforderlich, Ihr SSL-Beendigungsgerät kann jedoch nicht für die Erstellung des notwendigen benutzerdefinierten HTTP-Headers konfiguriert werden.

  Sie können dennoch SSL-Bridging für Websitesammlungen mit Hostnamen mit diesen Geräten verwenden, wenn die SSL-Beendigung nicht erforderlich ist.

• Sie planen die Verwendung verschiedener Anwendungspools, um die dadurch bereitgestellte zusätzliche Sicherheit zu nutzen, oder Sie müssen mehrere Proxygruppen verwenden.

Weitere Informationen zu Websitesammlungen mit Hostnamen, einschließlich eines Vergleichs mit pfadbasierten Websitesammlungen, finden Sie unter Websitesammlungsarchitektur mit Hostnamen und Bereitstellung in SharePoint Server.

Entwerfen von Zielen für Websitesammlungen

Websitesammlungen schlagen eine Brücke zwischen der logischen Architektur und der Informationsarchitektur. Die Aufgaben der Websitesammlungen sind die Erfüllung der URL-Entwurfsanforderungen und die Erstellung logischer Unterteilungen des Inhalts. Verwaltete Pfade binden für jede Websitesammlung eine zweite Ebene von Websitesammlungen auf oberster Ebene ein. 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 ist jede Website eine Unterwebsite.

Die folgende Abbildung veranschaulicht die Websitehierarchie der Teamwebsites.

Websitehierarchie für Teamwebsites

Sowohl für pfadbasierte Websitesammlungen als auch für Websitesammlungen mit Hostnamen ist die zweite Ebene von Websitesammlungen von zentraler Bedeutung für die Informationsarchitektur. Der folgende Abschnitt beschreibt, wie Entwurfsbeispiele Entscheidungen basierend auf dem Websitetyp einbinden.

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 Inhalte unabhängig verwalten und die Berechtigungen selbst festlegen.

• Jede Abteilung kann ihre Inhalte in einer dedizierten Datenbank speichern.

Mehrere Websitesammlungen haben u. a. folgende Nachteile:

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

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

Je nach Informationsarchitektur und Entwurf der Intranetwebsites 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 Bereitstellungsempfehlungen für diese Websites sind recht unkompliziert. In den Entwurfsbeispielen enthält die Websiteanwendung "Meine Websites" 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 Vorlage "Persönliche Website" verwenden. Der Benutzername wird an die URL im Format http://my personal/username angefügt. In der folgenden Abbildung ist Meine Websites dargestellt.

Websitehierarchie für "Meine Websites"

Teamwebsites

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

• Ermöglichen 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. Dieser Ansatz birgt jedoch u. a. folgende Nachteile:

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

  • 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 erstellt ein SharePoint-Administrator Websitesammlungen. Nachdem eine Websitesammlung erstellt wurde, können Teams Websites innerhalb der Websitesammlung 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. Auch dieser Ansatz birgt jedoch einige Nachteile:

In den Entwurfsbeispielen 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.

Tabelle: Vorgeschlagene Websitesammlungstaxonomien

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.
Recherchieren	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 in 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 können nur auf das Projekt zugreifen, an dem sie arbeiten.

• Websitebesitzer verwalten Berechtigungen.

• 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. In beiden Entwurfsbeispielen für das Unternehmensportal wird ein verwalteter Pfad verwendet, um eine zweite Ebene von Websitesammlungen unterhalb einer Stammwebsitesammlung zu erstellen. Als Alternative wird im Extranet-Entwurfsbeispiel jede Partnerwebsite zu einer Websitesammlung auf oberster Ebene gemacht, in dem Websitesammlungen mit Hostnamen verwendet werden. Einzelne Websitesammlungen sorgen bei beiden Verfahren für die gewünschte Trennung zwischen den Projekten.

Wenn Sie die Verwendung des Features "Self Service Site Creation" planen, das Teil der Standardinstallation von SharePoint Server ist (anstatt einer für Ihre Organisation entwickelten benutzerdefinierten Lösung), verwenden Sie pfadbasierte Websitesammlungen. Websitesammlungen mit Hostnamen funktionieren mit diesem Feature noch nicht.

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 eine Datenbank Warnungsschwellenwerte erreicht. 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 Administratoren unabhängig vom Rest verwalten können.

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

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

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

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

  • Maximale Anzahl an 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 bieten die Entwurfsbeispiele für ein Unternehmensportal zur Vereinfachung der Verwaltung eine einzelne Datenbank. Fügen Sie bei Bedarf Datenbanken basierend auf der Zielgröße zu.

Meine Websites

Bei Meine Websites erreichen die Entwurfsbeispiele für ein Unternehmensportal 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 die Menge des zusätzlichen Speicherplatzes, der 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.

Die Entwurfsbeispiele bieten die folgenden Beispielgrößeneinstellungen basierend auf einer Zieldatenbankgröße von 175 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 der Inhaltsdatenbank mit den wenigsten Websitesammlungen neue Websites vom Typ "Meine Website" hinzugefügt.

Teamwebsites

In den meisten Organisationen sind Teamwebsites wesentlich größer als Meine Websites. Teamwebsites werden unter einem verwalteten Pfad erstellt, unter dem eine Inhaltsdatenbank pro Teamwebsitesammlung zulässig ist. 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.

Partnerwebanwendung

Wie bei Meine Websites erreicht die Partnerwebanwendung eine hohe Effizienz durch Verwalten von Datenbanken bis zur maximalen Zielgröße.

Die Entwurfsbeispiele bieten 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

Zonen und URLs

Die Entwurfsbeispiele veranschaulichen, wie URLs innerhalb einer Unternehmensbereitstellung websiteübergreifend koordiniert werden. Die folgenden Ziele beeinflussen die Entwurfsentscheidungen für URLs:

• URL-Konventionen beschränken nicht die Zonen, über die Benutzer auf Inhalte zugreifen können.

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

Entwerfen von Lastenausgleichs-URLs

Beim Erstellen einer Webanwendung müssen Sie eine Lastenausgleichs-URL auswählen, die der Anwendung zugeordnet wird. Die von Ihnen gewählte URL gilt für die Standardzone. Darüber hinaus müssen Sie eine Lastenausgleichs-URL für jede zusätzliche 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 Websitesammlungen, die das Intranet umfasst, erfordert eine eindeutige URL. In den Entwurfsbeispielen für das Unternehmensportal sind die Zielgruppen für den Intranetinhalt interne Mitarbeiter und Remotemitarbeiter. Mitarbeiter verwenden für alle diese Websites unabhängig davon dieselben URLs, ob sie lokal oder remote sind. Durch diesen Ansatz wird der SharePoint-Entwurf mit zusätzlichem Schutz versehen (der gesamte Datenverkehr ist SSL-geschützt). Dieser Ansatz erfordert jedoch auch, dass Sie eine Alternative für zusätzliche Konfigurationen wählen:

• Leiten Sie internen Datenverkehr zusammen mit Remotedatenverkehr durch die Firewall oder das Gatewayprodukt.

• Richten Sie eine geteilte DNS-Umgebung zum Auflösen interner Anforderungen innerhalb des internen Netzwerks ein.

Partnerwebsite

In den Entwurfsbeispielen greifen interne Mitarbeiter, Remotemitarbeiter und Partnermitarbeiter auf die Partnerwebsite zu. In den Entwurfsbeispielen für das Unternehmensportal geben alle Benutzer unabhängig von der Authentifizierungsmethode dieselbe URL ein. Beim Entwurfsbeispiel für das Extranet geben die unterschiedlichen Benutzertypen verschiedene URLs ein. Obwohl einzelne Partner und Partnerunternehmen extern über SSL (HTTPS) auf die Partnerwebsite zugreifen, benötigt jede Gruppe eine andere URL, um die Vorteile der Verwendung separater Zonen zu nutzen, d. h. verschiedene Authentifizierungsmethoden und unterschiedliche Zonenrichtlinien.

Da im Extranet-Entwurfsbeispiel Direct Access oder VPN für den Zugriff durch Remotemitarbeiter verwendet wird, benutzen Remotemitarbeiter und interne Mitarbeiter dieselben URLs. Wenn der Zugriff für Remotemitarbeiter durch ein Reverseproxygerät konfiguriert ist, benötigen Remotemitarbeiter eine separate URL mit SSL, die eine zusätzliche Zone erfordert. Schließlich bindet das Extranet-Entwurfsbeispiel Websitesammlungen mit Hostnamen statt einer einzelnen Websitesammlung auf oberster Ebene ein. Daher ist die URL für alle Projektwebsites unterschiedlich.

In der folgenden Tabelle sind Beispiel-URLs aufgeführt, über die interne und Remotemitarbeiter sowie Partner auf die Partnerwebsite zugreifen (siehe das Entwurfsbeispiel für ein Extranet).

Tabelle: Beispiel-URLs aus dem Entwurfsbeispiel für ein Extranet

Zone	Beispiel-URL
Interne und Remotemitarbeiter	http://project1
Einzelne Partner	https://project2.fabrikam.com
Partnerunternehmen	https://TrustedPartnerProject1.fabrikam.com

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

Verwaltete Pfade ermöglichen Ihnen die Angabe, 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 Websites unterhalb der Stammwebsitesammlung Teil der Stammwebsitesammlung.

Sie können folgende zwei Arten von verwalteten Pfaden 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://intranet/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.

Wenn verwaltete Pfade für Websitesammlungen mit Hostnamen implementiert werden, werden diese verwalteten Pfade auf der Farmebene erstellt und gelten für alle Webanwendungen. wenn die Lösung mehrere Webanwendungen umfasst. Wenn verwaltete Pfade für Pfadbasierte Websites implementiert werden, gelten diese verwalteten Pfade nur für die Webanwendung, in der sie erstellt wurden.

Das Entwurfsbeispiel bindet die Verwendung beider Arten von verwalteten Pfaden ein (ausdrückliche Inklusionen und Platzhalterinklusionen, wie in den folgenden Abschnitten beschrieben).

Ausdrückliche Inklusionen: Veröffentlichte Intranetinhalte

In den Entwurfsbeispielen bindet die veröffentlichte Websitesammlung ausdrückliche Inklusionen für jede Unterwebsite ein, z. B. für Personalwesen, Einrichtungen und Einkauf. Jede dieser Websitesammlungen kann bei Bedarf einer anderen Inhaltsdatenbank zugeordnet werden. Wenn keine Websitesammlungen mit Hostnamen verwendet werden, setzt die Verwendung ausdrücklicher Inklusionen in diesem Beispiel voraus, dass in der Webanwendung keine anderen Websitetypen, einschließlich Platzhalterinklusionen, erstellt werden.

Die Verwendung ausdrücklicher Inklusionen ergibt folgende URLs:

• https://intranet.fabrikam.com

• https://intranet.fabrikam.com/hr

• https://intranet.fabrikam.com/facilities

• https://intranet.fabrikam.com/purchasing

In diesem Beispiel stellt die Stammwebsitesammlung "http://intranet.fabrikam.com" 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.

Die Verwendung von Platzhalterinklusionen ergibt folgende URLs:

• https://teams.fabrikam.com/sites/Team1

• https://teams.fabrikam.com/sites/Team2

• https://teams.fabrikam.com/sites/Team3

In diesem Beispiel hostet die Stammwebsitesammlung https://teams.fabrikam.com 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.

Daraus ergeben sich URLs in folgendem Format:

• https://my.fabrikam.com/personal/User1

• https://my.fabrikam.com/personal/User2

• https://my.fabrikam.com/personal/User3

Partnerwebanwendung

Bei der Verwendung von pfadbasierten Websitesammlungen können Sie das Feature "Self-Service Site Creation" implementieren, um Mitarbeitern das Erstellen von sicheren Websites für die Zusammenarbeit mit externen Partnern zu ermöglichen. Bei der Verwendung von Websitesammlungen mit Hostnamen können Sie ein benutzerdefiniertes "Self-Service Site Creation"-Feature implementieren, oder Administratoren können auf Anfrage Partnerprojekt-Websites erstellen.

In den Entwurfsbeispielen für ein Unternehmensportal enthält die Partnerwebanwendung eine Platzhalterinklusion mit der Bezeichnung /sites (http://partnerweb/sites). Dies führt zu URLs mit folgendem Format.

• https://partnerweb.fabrikam.com/sites/Project1

• https://partnerweb.fabrikam.com/sites/Project2

• https://partnerweb.fabrikam.com/sites/Project3

Koordinieren von URLs mit AAM und DNS

Wenn pfadbasierte Websitesammlungen implementiert werden, konfigurieren Sie alternative Zugriffszuordnungen für jede Website-URL in der Farm. Auf diese Weise wird sichergestellt, dass Webanforderungen der richtigen Website zugeordnet werden, vor allem in Umgebungen, in denen Lastenausgleich- oder Reverseproxytechnologien verwendet wird.

URLs mit einfachem Namen wie http://teams können für den Intranetzugriff konfiguriert werden. Diese URLs werden von einem Clientcomputer aufgelöst, indem das DNS-Suffix des Clientcomputers, z. B. fabrikam.com, angefügt wird und anschließend eine DNS-Suche nach dem Namen mit diesem Suffix ausgegeben wird. Wenn beispielsweise ein Clientcomputer in der Domäne fabrikam.com die URL http://teams anfordert, sendet der Computer die Anforderung http://teams.fabrikam.com an das DNS.

Das DNS muss für die Verwendung eines A-Datensatzes (oder AAAA für IPv6) für jeden vollqualifizierten Domänennamen (FQDN) konfiguriert werden. Der Datensatz verweist auf die IP-Adresse mit Lastenausgleich für die Webserver, die eine Website hosten. In einer typischen Produktionsbereitstellung werden Server für die Verwendung von statisch zugewiesenen IP-Adressen konfiguriert, zusätzlich zu statisch zugewiesenen A- oder AAAA-Datensätzen im DNS.

Sobald ein Clientbrowser die IP-Adresse mit Lastenausgleich erhält, stellt der Clientbrowser eine Verbindung mit einem Front-End-Webserver in der Farm her und sendet dann eine HTTP-Anforderung mit der ursprünglichen URL mit einfachem Namen http://teams. IIS und SharePoint Server erkennen dies auf der Grundlage der in der alternativen Zugriffszuordnung konfigurierten Einstellungen (siehe vorstehende Tabelle) als Anforderung für die Zone Intranet. Fordert ein Benutzer stattdessen https://teams.fabrikam.com an, ist der Prozess ähnlich, IIS und SharePoint Server erhalten stattdessen jedoch diesen FQDN und erkennen diese Anforderung daher für die Standardzone.

Geben Sie in Umgebungen mit mehreren Domänen für das DNS in den Domänen, in denen sich die Websites nicht befinden, CNAME-Datensätze ein. Wenn die Fabrikam-Netzwerkumgebung beispielsweise eine zweite Domäne mit dem Namen europe.fabrikam.com enthält, werden für diese Websites in der Domäne Europe CNAME-Datensätze eingegeben. Für die Team-Intranetwebsite (http://teams) wird der Domäne europe.fabrikam.com, die auf teams.fabrikam.com verweist, ein CNAME-Datensatz mit dem Namen teams hinzugefügt. Wenn anschließend das DNS-Suffix eines Clientcomputers an die DNS-Suchanforderung angefügt wird, wird eine Anforderung für http://teams von der Domäne Europe eine DNS-Suche nach teams.europe.fabrikam.com ausgeben und von dem CNAME-Datensatz zu teams.fabrikam.com weitergeleitet.

Zonenrichtlinien

Sie können Richtlinien für eine oder mehrere Zonen konfigurieren, um Berechtigungen für alle Inhalte innerhalb einer Webanwendung zu erzwingen. Im Anspruchsmodus kann eine Richtlinie nur für eine bestimmte Zone (nicht für die Webanwendung allgemein) konfiguriert werden. Eine Richtlinie erzwingt Berechtigungen für alle Inhalte, auf die Benutzer über eine Zone zugreifen. 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 anzuwenden.

In den Entwurfsbeispielen werden keine Richtlinien verwendet, da entweder mehrere Authentifizierungstypen in einer einzelnen Zone aktiviert sind, oder alle Websites in einer Webanwendung enthalten sind (oder beides).