Logisches Architekturmodell: Unternehmensbereitstellung

Inhalt dieses Artikels:

  • Informationen zum Modell

  • Allgemeine Entwurfsziele

  • Serverfarmen

  • Benutzer, Zonen und Authentifizierung

  • SSPs

  • Administrationswebsites

  • Anwendungspools

  • Webanwendungen

  • Websitesammlungen

  • Inhaltsdatenbanken

  • Zonen und URLs

  • Zonenrichtlinien

In diesem Artikel wird die praktische Implementierung von logischen Architekturkomponenten zur Erstellung eines funktionsfähigen Modells beschrieben. Dieser Artikel soll zusammen mit dem folgenden Modellentwurf verwendet werden: Entwurfsbeispiel: Unternehmensbereitstellung logischer Architektur (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=82151&clcid=0x407)

Das Modell veranschaulicht eine allgemeine Unternehmensbereitstellung von Microsoft Office SharePoint Server 2007. Bei diesem Modell wurden fast alle Komponenten der logischen Architektur angewendet. Es veranschaulicht, wie diese in den Gesamtentwurf integriert wurden. Dieser Artikel beschreibt die Entwurfsziele für das Modell und erläutert, wie diese Ziele mithilfe der Komponenten der logischen Architektur, die im Modell dargestellt sind, erreicht werden konnten.

Informationen zum Modell

Das Modell veranschaulicht eine Unternehmensbereitstellung für ein fiktives Unternehmen namens Fabrikam, Inc. Die Bereitstellung umfasst zwei Serverfarmen. Eine Serverfarm hostet das Firmenintranet und die Partnerwebsite. Der zweite Farm hostet die Unternehmenswebsite (www.fabrikam.com).

Intranet

Das firmeneigene Intranet umfasst die folgenden Anwendungen:

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

  • Gemeinsame Teamwebsites

  • Meine Websites

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

  • Hebt die unterschiedlichen Features von Microsoft Office SharePoint Server 2007 hervor.

  • Hostet Daten mit verschiedenen Datenmerkmalen.

  • Unterliegt einem anderen Verwendungsprofil.

  • Erfordert eine andere Strategie für die Berechtigungsverwaltung.

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

Die Verwendung eines einzigen Anbieters für gemeinsame Dienste (SSP) vereint diese drei Anwendungen für:

  • Die Navigation zwischen den Anwendungen.

  • Die unternehmensweite Suche.

  • Die gemeinsame Verwendung von Profildaten.

In der folgenden Abbildung sind die drei Anwendungen dargestellt, die das Unternehmensintranet bilden.

Logische Architektur für Unternehmensmodell

Partner-Webanwendung

Die Partner-Webanwendung hostet extern verfügbare Websites für die sichere Zusammenarbeit mit den Mitarbeitern von Partnerunternehmen. Diese Anwendung ist dafür gedacht, dass die Mitarbeiter problemlos Websites für die sichere Zusammenarbeit erstellen können. Zu den Schlüsselfaktoren der Entscheidung für diese Anwendung gehören die Folgenden:

  • Inhaltliche Trennung Die Partner sind nicht berechtigt, auf andere Inhaltstypen zuzugreifen, die auf der Serverfarm gehostet werden. Mithilfe eines dedizierten SSPs können Sie Inhalt zudem wie folgt weiter isolieren:

    • Beschränkung der Suche auf die Websiteebene

    • Keine Navigation über Websitesammlungen hinaus

    • Keine Verfügbarkeit von Profildaten über Websitesammlungen hinaus

  • Separate Authentifizierung für Partnerkonten Die Partnerkonten werden mittels Formularauthentifizierung verwaltet. Die Partnerkonten werden nicht dem Unternehmensverzeichnis hinzugefügt.

  • Berechtigungsverwaltung Die einzelnen Websitebesitzer verwalten selbst die Berechtigungen für ihre Websites und laden nur benötigte Teilnehmer zur Mitarbeit ein.

Im Modell wird die Partner-Webanwendung 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. Zu den Schlüsselfaktoren der Entscheidung für diese Anwendung gehören die Folgenden:

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

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

  • Sichere Inhalterstellung und Veröffentlichung Separate Websitesammlungen werden auf Farm A in der Partner-Webanwendung für die Dokumenterstellung und das Staging gehostet. Dies ermöglicht eine sichere Zusammenarbeit und Entwicklung von Inhalt sowohl mit internen als auch mit Remotemitarbeitern sowie mit redaktionellen Partnern, die auf die Websiteentwicklung oder Inhalterstellung spezialisiert sind. Die Veröffentlichung von Inhalt ist so konfiguriert, dass Inhalt aus der Websitesammlung für die Dokumenterstellung automatisch an die Stagingwebsitesammlung (auf Farm A) übermittelt und von dort aus automatisch zur Produktionswebsitesammlung auf Farm B weitergeleitet wird. Die folgende Abbildung zeigt den Veröffentlichungsvorgang.

Logische Farmarchitektur – Veröffentlichungsmodell

Allgemeine Entwurfsziele

Das Modell veranschaulicht eine praktische Implementierung von Microsoft Office SharePoint Server 2007-Features in mehreren häufig verwendeten Anwendungstypen. Die Entwurfsimplementierungen für die einzelnen Anwendungen werden in diesem Artikel beschriebenen. Zu den wichtigsten Entwurfszielen für das Modell gehören die Folgenden:

  • 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 noch wachsen kann. Die Entwurfsentscheidungen für einzelne Anwendungen verhindern nicht das Hinzufügen von anderen Anwendungen. Beispielsweise könnte eine Erstbereitstellung nur gemeinsame Teamwebsites 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änglichen Anwendungen hinzufügen. Mit anderen Worten weist der Entwurf keine Entwurfsentscheidungen auf, die die Verwendung der Umgebung beschränken.

  • Zugriff für verschiedene Klassen von Benutzern, ohne die Sicherheit des Inhalts innerhalb der unterschiedlichen Anwendungen zu gefährden. Benutzer aus anderen Netzwerkzonen (sowohl intern als auch extern) mit anderen Authentifizierungsanbietern können an der Zusammenarbeit teilnehmen. Zudem können die Benutzer auch nur auf den Inhalt zugreifen, auf den sie zugreifen 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 könnte 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 und Kunden den Zugriff.

  • Stellen Sie sicher, dass der Entwurf in einer Extranetumgebung verwendet werden kann. Es werden Entwurfsentscheidungen getroffen, die sicherstellen sollen, dass die Serverfarmen in einem Umkreisnetzwerk sicher bereitgestellt werden können.

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

Serverfarmen

Das Modell 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 Modell dargestellt werden.

Lizenzanforderungen

Hinweis

Frühere Lizenzanforderungen verlangten mindestens zwei Server zum Hosten von Intranetinhalt und Internetwebsites (je einen Server pro Lizenztyp). Dies ist nicht mehr erforderlich. Dieser Abschnitt wurde anhand der neuen Lizenzanforderungen aktualisiert, die im September 2008 implementiert wurden.

Für Microsoft Office SharePoint Server 2007 sind zwei Serverlizenzen verfügbar. Diese Lizenzen können auf demselben Servercomputer oder auf derselben Serverfarm kombiniert werden:

  • Microsoft Office SharePoint Server 2007, Serverlizenz Dies ist die passende Lizenz für Intranetinhalt. Diese Lizenz erfordert die Verwendung von Clientzugriffslizenzen (CALs). Wenn Sie Websites für die Partnerzusammenarbeit erstellen, müssen Sie sicherstellen, dass Sie die erforderliche Anzahl von Clientzugriffslizenzen für die Partnermitarbeiter erwerben.

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

Wenn Sie interne Inhalte für Ihre Organisation und über das Internet zugängliche Inhalte für Nichtmitarbeiter aus der gleichen Farm bereitstellen möchten, müssen Sie für diese Farm beide Lizenztypen erwerben. Im Hinblick auf mögliche Bereitstellungsszenarien können Kunden, die ihre Office SharePoint Server 2007-Anforderungen in einer einzigen Bereitstellung konsolidieren möchten, Lizenzen für beide Produkte erwerben. Sie können dann diese Lizenzen dem gleichen Server zuweisen und die gleiche ausgeführte Instanz der Software mit beiden Lizenzen gleichzeitig verwenden. Die Kunden müssen jedoch gemäß den Office SharePoint Server 2007-Nutzungsrechten Clientzugriffslizenzen erwerben für Benutzer und Geräte, die auf eine Weise auf Inhalte zugreifen, die gemäß den Office SharePoint Server 2007-Nutzungsrechten für Internetwebsites nicht zulässig ist.

Weitere Informationen, wie die Lizenzanforderungen die Anzahl der erforderlichen Serverfarmen beeinflussen, finden Sie unter Planen von Serverfarmen.

Obwohl nur eine Serverfarm erforderlich ist, veranschaulicht das Modell die Verwendung von zwei Serverfarmen: eine Serverfarm für interne Inhalte und die andere Serverfarm für an Kunden gerichtete Inhalte. Wenn Sie zwei separate Serverfarmen implementieren, besteht die wichtigste Entwurfsentscheidung darin, welche Farm die Partner-Webanwendung hosten soll. Im Modell hostet Serverfarm A den Intranetinhalt und Serverfarm B die Internetwebsite des Unternehmens. Gemäß den Lizenzierungsbedingungen kann jede der beiden Farmen den Partner hosten.

Wenn zwei Farmen zur Auswahl stehen, kann die Entwurfsentscheidung, welche Webfarm eine Partner-Webanwendung hosten soll, anhand der folgenden allgemeinen Überlegungen getroffen werden:

  • Art der Zusammenarbeit Wenn der Hauptzweck einer Partnerextranetwebsite in der sicheren Kommunikation mit zahlreichen Partnern besteht, ist eine Internetserverfarm sicher die günstigste Lösung. Andererseits, wenn der Hauptzweck die Zusammenarbeit mit einer kleinen Anzahl von Partnermitarbeitern darstellt, ist vielleicht eine Intranetserverfarm die bessere Lösung. Wählen Sie die Option aus, die es Ihnen ermöglicht, die Farm für ihre geplante Rolle (Zusammenarbeit oder schreibgeschützter Inhalt) zu optimieren.

  • Anzahl der Partnermitarbeiter Wenn Sie mit vielen Partnermitarbeitern zusammenarbeiten und die Minimierung der Kosten wichtig ist, können Sie beide Inhalte (Zusammenarbeit und anonym) sicher auf nur einer internetorientierten Serverfarm mit Internetwebsitelizenz hosten.

Im Modell ist die Partner-Webanwendung auf eine intensive Zusammenarbeit mit Partnerfirmen, einschließlich Entwicklung und Bereitstellung der Firmeninternetsite, ausgerichtet. Durch Platzieren der Partner-Webanwendung auf Farm A kann das Unternehmen jede der beiden Serverfarmen für ihre beabsichtigte Verwendung optimieren (Zusammenarbeit oder schreibgeschützter Inhalt).

Weitere Informationen zur Auswahl der geeigneten Anzahl von Serverfarmen für Ihr Unternehmen, einschließlich weiterer Informationen zu den Lizenzanforderungen, finden Sie unter Planen von Serverfarmen.

Topologie der Serverfarmen

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

  • Zwei Front-End-Webserver

  • Ein Anwendungsserver

  • Zwei Datenbankserver, entweder gruppiert oder gespiegelt

Das Modell veranschaulicht die logische Architektur von Microsoft Office SharePoint Server 2007 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.

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

Benutzer, Zonen und Authentifizierung

Das Modell veranschaulicht fünf 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. Eine Webfarm, die mehrere Webanwendungen hostet, kann Benutzeranforderungen aus mehr als fünf Netzwerkzonen unterstützen (bis zu fünf Zonen pro Webanwendung). Das Modell zeigt jedoch nur fünf Zonen.

Benutzer und Authentifizierung

Das Modell zeigt Benutzer aus verschiedenen Netzwerkzonen oder, im Fall von Administratoren, Benutzer mit sehr unterschiedlichen Berechtigungsanforderungen. Das Modell veranschaulicht, wie die Authentifizierung über die Benutzer hinweg angewendet wird. In der folgenden Tabelle wird aufgeführt, wie die Benutzer für jede Zone authentifiziert werden.

Zone Benutzer Authentifizierung

Benutzerdefiniert

Administratoren

Kerberos (in Windows integriert)

Intranet

Interne Mitarbeiter

NTLM (in Windows integriert)

Standard

Remotemitarbeiter

NTLM (in Windows integriert) oder Formularauthentifizierung mit LDAP (Lightweight Directory Access Protocol)

Extranet

Partnermitarbeiter

Formularauthentifizierung

Internet

Kunden

Anonym

Im Modell erhalten nicht alle Benutzer Zugriff auf beide Serverfarmen. Folglich verwendet keine Farm alle fünf Zonen.

Administratoren

Die benutzerdefinierte Zone dient zum sicheren Verwaltungszugriff auf Websites. Dieser Ansatz bietet folgende Möglichkeiten:

  • Implementieren Sie einen unabhängigen Satz von URLs und Richtlinien. Beispielsweise können Administratoren die URLs der benutzerdefinierten Zone für Verwaltungsaufgaben entsprechend den Richtlinien der Zone verwenden. Administratoren können die Intranet-URLs für alle anderen Vorgänge verwenden, solange diese den Richtlinien entsprechen, die für die Anwendungen konfiguriert wurden, die das Intranet bilden. Dieser Ansatz trennt die beiden Kontexte und stellt sicher, dass die Richtlinienberechtigungen keinen Konflikt verursachen.

  • Implementieren Sie eine sicherere Methode der Authentifizierung für Administratoren. Dadurch wird die Sicherheit der gesamten Lösung erhöht.

  • Authentifiziert Benutzer bei einem anderen Anbieter in Szenarien, in denen die Unterstützung für Websites durch einen externen Anbieter bereitgestellt wird.

In diesem Modell wird davon ausgegangen, dass die Administratoren Mitarbeiter von Fabrikam sind und internen Zugriff auf das Netzwerk haben. Das Modell umfasst die Verwendung der integrierten Windows-Authentifizierung für Administratoren (d. h. entweder Kerberos-Authentifizierung oder NTLM).

Interne Mitarbeiter

Die Intranetzone wird für den internen Mitarbeiterzugriff verwendet. Die integrierte Windows-Authentifizierung wird verwendet.

Remotemitarbeiter

Die Standardzone wird für den Remotemitarbeiterzugriff verwendet. Die Entwurfsziele im Modell sind die Folgenden:

  • Authentifizierung bei der internen Active Directory-Verzeichnisdienstumgebung.

  • Vereinfachen Sie die Berechtigungsverwaltung mithilfe der Windows-Authentifizierung sowohl für interne Mitarbeiter als auch für Remotemitarbeiter. Dieses Ziel ist wichtig, da von Microsoft Office SharePoint Server 2007 für jeden Benutzer zwei verschiedene Konten erstellt werden, wenn sie sich über zwei verschiedene Authentifizierungsanbieter bei den Websites anmelden, und jedes dieser beiden Konten muss über Berechtigungen verfügen.

Das Modell stellt zwei verschiedene Möglichkeiten zum Authentifizieren von Remotemitarbeitern bereit. Mit der ersten Option (Integrierte Windows-Authentifizierung mit NTLM) werden beide Entwurfsziele erreicht. Die zweite Option (Formularauthentifizierung) entspricht dem ersten Ziel, jedoch nicht dem zweiten. Folglich ist die erste Option die bevorzugte Methode.

In der folgenden Tabelle werden die Unterschiede zwischen diesen beiden Ansätzen dargestellt.

Diese Authentifizierungsmethode Integrierte Windows-Authentifizierung mit NTLM Formularauthentifizierung mit einem LDAP-Anbieter

Funktionsweise

Diese Methode beruht auf der Verwendung von Internet Security and Acceleration (ISA) Server 2006 oder Intelligent Application Gateway (IAG 2007) zur Authentifizierung von Benutzern und dem Senden der Benutzeranmeldeinformationen an Microsoft Office SharePoint Server 2007. Diese Server verwenden die Formularauthentifizierung zur Benutzerauthentifizierung in der Active Directory-Umgebung. Sie leiten die Windows-Anmeldeinformationen dann an Microsoft Office SharePoint Server 2007 weiter. Weitere Informationen finden Sie in den folgenden Ressourcen:

Da die Zone die Standardzone ist, wird die NTLM-Authentifizierung verwendet, um eine Anforderung der Indexkomponente zu erfüllen. Weitere Informationen finden Sie unter "Konfigurationsanforderungen der Standardzone" weiter unten in diesem Artikel.

In Microsoft Office SharePoint Server 2007 wird die Formularauthentifizierung mit einem LDAP-Anbieter zur Authentifizierung von Remotemitarbeitern bei der internen Active Directory-Umgebung verwendet.

Wenn diese Methode ausgewählt wird, müssen Sie sicherstellen, dass sich die Indexkomponente über eine alternative Zone authentifizieren kann. Weitere Informationen finden Sie unter "Konfigurationsanforderungen der Standardzone" weiter unten in diesem Artikel.

Vorteile

In Microsoft Office SharePoint Server 2007 werden für Benutzer, die sowohl intern als auch remote arbeiten, nicht zwei verschiedene Konten erstellt. Dadurch wird die Berechtigungsverwaltung erheblich vereinfacht.

Erfordert keinen Proxyserver, um Benutzer zu authentifizieren und Anmeldeinformationen weiterzuleiten.

Nachteile

Erfordert eine zusätzliche Koordination mit und die Konfiguration von ISA Server 2006 oder eines anderen Proxyserverprodukts.

Wenn Benutzer sowohl intern als auch remote eine Verbindung zu Microsoft Office SharePoint Server 2007 herstellen, werden in Microsoft Office SharePoint Server 2007 zwei verschiedene Benutzerkonten erstellt. Folglich erfordern beide Konten Berechtigungen für Websites und Dokumente. Die Mitarbeiter können potenziell zwei Instanzen von Meine Websites erstellen. Die Mitarbeiter müssen die Berechtigungen für Ihre eigenen Websites und Dokumente für beide Benutzerkonten selbst verwalten, wenn sie sowohl vom internen Netzwerk aus als auch remote arbeiten möchten.

Partnermitarbeiter

Partnermitarbeiter greifen über die Extranetzone auf das Netzwerk zu und werden mithilfe der Formularauthentifizierung authentifiziert. Dies erfordert ein separates Verzeichnis und einen separaten Anbieter, z. B. eine Microsoft SQL Server-Datenbank und einen Anbieter, zum Speichern der Partnerkonten im Extranet. Die Vorteile dieses Ansatzes sind, dass Sie die Partnerkonten separat verwalten können und Sie dem internen Mitarbeiterverzeichnis keine Partnerkonten hinzufügen müssen.

Alternativ dazu können Sie die einmalige Webanmeldung (Web Single Sign-On, SSO) zur Authentifizierung beim Verzeichnis eines Partners verwenden. Dieser Ansatz erfordert jedoch eine separate Zone für jedes Partnerverzeichnis.

Da bei diesem Modell vorausgesetzt wird, dass Fabrikam mit Partnern aus mehreren verschiedenen Unternehmen innerhalb derselben Partneranwendung zusammenarbeitet, wird die Formularauthentifizierung verwendet. Das Verzeichnis und der Anbieter sind nicht angegeben.

Kunden

Die Internetzone wird für den Kundenzugriff verwendet. Diese Zone ist so konfiguriert, dass den Kunden anonymer Zugriff mit Leseberechtigungen erteilt wird.

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:

  • Die Standardzone

  • Zonen für externen Zugriff

In den folgenden Abschnitten werden die Entscheidungen beschrieben, die in das Modell integriert wurden.

Konfigurationsanforderungen der Standardzone

Die Zone, die die größten Überlegungen betreffen, ist die Standardzone. In Microsoft Office SharePoint Server 2007 werden die folgenden Anforderungen an die Konfiguration der Standardzone gestellt:

  • Wenn eine Benutzeranforderung keiner Zone zugeordnet werden kann, werden die Authentifizierung und die Richtlinien für die Standardzone verwendet.

  • Damit das Crawlen von Inhalt möglich ist, benötigt die Indexkomponente Zugriff auf Inhalt durch mindestens eine Zone. Standardmäßig verwendet die Indexkomponente NTLM für die Authentifizierung. Der SSP-Administrator kann Crawlregeln konfigurieren, die festlegen, dass beim Crawlen eines bestimmten URL-Bereichs entweder die Standardauthentifizierung oder ein Clientzertifikat verwendet werden soll. Folglich muss, um Inhalt zu crawlen, mindestens eine der Zonen für die NTLM-Authentifizierung, die Standardauthentifizierung oder die Zertifikatverwendung konfiguriert werden. Darüber hinaus werden die Zonen vom Crawler in der folgenden Reihenfolge abgefragt, bis er eine Zone findet, über die er sich authentifizieren kann: Standardzone, Intranetzone, Internetzone, benutzerdefinierte Zone, Extranetzone. Wenn der Crawler jedoch zuerst eine Zone findet, die für die Verwendung der Kerberos-Authentifizierung konfiguriert ist, nimmt der Crawler keine Authentifizierung vor und versucht auch nicht, auf die nächste Zone zuzugreifen. Daher müssen Sie sicherstellen, dass die Konfiguration von Zonen mit Kerberos-Authentifizierung nicht verhindert, dass die Indexkomponente den Inhalt crawlt. Weitere Informationen zu den Authentifizierungsanforderungen im Zusammenhang mit dem Crawlen von Inhalt finden Sie unter Planen von Authentifizierungsmethoden (Office SharePoint Server).

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

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

Im Modell wird die Standardzone aus den folgenden Gründen für den Remotemitarbeiterzugriff verwendet:

  • Mitarbeiter können auf die Verknüpfungen in administrativen E-Mails zugreifen, unabhängig davon, wo sie gespeichert sind.

  • Interne Servernamen und URLs sind vor Offenlegung geschützt, wenn die Zone in Verbindung mit einer Benutzeranforderung nicht ermittelt werden kann. Da die Standardzone bereits für Remotemitarbeiter konfiguriert ist, legen die URLs keine vertrauliche Daten offen, wenn diese Zone angewendet wird.

Konfigurieren von Zonen für eine Extranetumgebung

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

  • Benutzeranforderungen können aus mehreren verschiedenen Netzwerken initiiert werden. Im Modell initiieren Benutzer Anforderungen aus dem internen Netzwerk, dem Internet und den Partnerunternehmen.

  • Benutzer verbrauchen Inhalt über mehrere Webanwendungen hinweg. Im Modell umfasst das Intranet drei verschiedene Webanwendungen. Darüber hinaus können interne und Remotemitarbeiter potenziell zum Inhalt beitragen und Inhalt über alle Webanwendungen hinweg verwalten: das Intranet, das Partner-Web und die Internetwebsite des Unternehmens.

Folgende Entwurfsprinzipien sollten in einer Extranetumgebung beachtet werden:

  • Konfigurieren Sie Zonen über mehrere Webanwendungen hinweg, damit 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 Intranetzone über alle Webanwendungen hinweg für dieselben Mitarbeiter verwendet wird. Mit anderen Worten: Konfigurieren Sie die Intranetzone 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 der jeweiligen Ressource.

Im Modell wird die Standardzone für jede der Webanwendungen für den Remotemitarbeiterzugriff identisch konfiguriert. Darüber hinaus wird die Intranetzone für alle Webanwendungen für den internen Mitarbeiterzugriff identisch konfiguriert. Die Extranetzone und die Internetzone werden jeweils für nur eine Webanwendung konfiguriert.

Alternative Zugriffszuordnungen werden beim Erstellen der Zone automatisch erstellt. Microsoft Office SharePoint Server 2007 kann jedoch für das Crawlen von Inhalt in externen Ressourcen, beispielsweise in einer Dateifreigabe, konfiguriert werden. Verknüpfungen für diese externen Ressourcen müssen für jede Zone mithilfe alternativer Zugriffszuordnungen manuell erstellt werden. Angenommen, eine Dateifreigabe kann für interne Benutzer mit einer internen URL (file://) verfügbar gemacht werden. Die gleiche Dateifreigabe kann als eine FTP-Verknüpfung für externe Benutzer verfügbar gemacht werden (ftp://). Dadurch wird sichergestellt, dass diese Ressourcen für die Benutzer entsprechend des Kontexts Ihrer Zone verfügbar sind. Wenn Benutzer in den Suchergebnissen Verknüpfungen zu diesen Ressourcen erhalten, sind die Verknüpfungen verfügbar.

Wenn Zonen, die über Webanwendungen hinweg führen, sich nicht gegenseitig spiegeln und die Verknüpfungen zu externen Ressourcen nicht richtig 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.

SSPs

Ein SSP bietet eine allgemeine Reihe von Diensten und Dienstdaten für eine logische Gruppierung von Webanwendungen und ihre zugeordneten Websites. Die Dienste und Dienstdaten umfassen Folgendes:

  • Personalisierungsdienste

  • Benutzergruppen

  • Geschäftsdatenkatalog

  • Excel Services

  • Office SharePoint Server-Suche

  • Portalverwendungsbericht

Das wichtigste Kriterium dafür, ob in einer logischen Architektur mehrere SSPs benötigen werden, ist das Isolieren von Inhalt. Angenommen, Ihre Serverfarm hostet Anwendungen für verschiedene Klassen von Benutzern. In diesem Fall kann die Verwendung separater SSPs dazu beitragen, die einzelnen Klassen voneinander zu trennen.

Das Modell enthält einen separaten SSP für jede der folgenden Anwendungen:

  • Intranet

  • Partner-Webanwendung

  • Internetwebsite des Kunden

    SSP-Modell für Unternehmensbereitstellung

Intranet

Die drei einzelnen Anwendungen, die das Intranet umfasst – veröffentlichter Intranetinhalt, eigene Sites und Teamwebsites – werden durch einen SSP vereint. Die Intranetanwendung, die im Modell dargestellt ist, ist ein gutes Beispiel für den Balanceakt zwischen sicherer Isolation und der Anforderung eines Unternehmens, Informationen zu teilen und Profildaten anwendungsübergreifend zu nutzen.

  • Die einzelnen Anwendungen sind durch Webanwendungen und Anwendungspools isoliert. Separate Anwendungspools sorgen zudem für isolierte Verfahren. Dedizierte Webanwendungen bieten die Möglichkeit zum Implementieren unterschiedlicher Berechtigungsrichtlinien für jeden Typ von Inhalt.

  • Die Vereinigung der drei Anwendungen unter einem SSP für die Personalisierung und die unternehmensweite Suche über alle Anwendungen hinweg.

    Architektur für Anbieter von gemeinsamen Diensten

Partner-Webanwendung

Durch einen separaten SSP für die Partner-Webanwendung wird sichergestellt, dass die Partnerbenutzer in Ihrer Intranetumgebung keine vertraulichen Informationen suchen oder darauf zugreifen können. Der SSP kann wie folgt für eine weitere Isolierung von Inhalt zwischen Websitesammlungen konfiguriert werden:

  • Schränken Sie Suchbereiche auf einzelne Websitesammlungen ein.

  • Verwenden Sie Benutzergruppen, um Inhalt gezielt an bestimmte Gruppen von Benutzern bereitzustellen.

  • Verwenden Sie das Stsadm-Befehlszeilentool zum Konfigurieren der Personenauswahl, sodass nur Benutzer angezeigt werden, die Mitglieder der Websitesammlung sind. In dieser Konfiguration Sie können jeden Benutzer aus dem Verzeichnis hinzufügen, wenn Sie den Benutzernamen kennen. Allerdings werden nur Benutzer, die bereits der Websitesammlung hinzugefügt wurden, in der Personenauswahl angezeigt. Dies verhindert, dass Partner Ihr Verzeichnis über die Personenauswahl durchsuchen können.

    Verwenden Sie den folgenden Befehl, um diese Konfiguration zu aktivieren:

    Stsadm.exe -o setproperty –url https://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv yes

    Verwenden Sie den folgenden Befehl, um diese Konfiguration zu deaktivieren:

    Stsadm.exe -o setproperty –url https://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv no

Inhalt kann nicht nur durch das Konfigurieren der Dienste innerhalb des SSPs, sondern auch durch Konfigurieren von Berechtigungen isoliert werden:

  • Begrenzen Sie den Zugriff auf bestimmte Websites auf bestimmte Benutzer oder Gruppen.

  • Verwenden Sie SharePoint-Gruppen zum Autorisieren des Zugriffs auf Inhalt.

Internetwebsite des Unternehmens

Im Modell ist die Internetwebsite des Unternehmens für anonyme Benutzer verfügbar. Websites, die für anonyme Benutzer vorgesehen sind, sollten immer von Websites für authentifizierte Benutzer getrennt werden. Das Modell verwendet die folgenden Isolationsmethoden für die Internetwebsite des Unternehmens:

  • Separate Anwendungspools sorgen für Prozessisolation.

  • Separate Webanwendungen ermöglichen die gezielte Bereitstellung von Richtlinien.

  • Ein dedizierter SSP stellt sicher, dass die Suchergebnisse auf die anonyme Anwendung beschränkt sind.

Administrationswebsites

Im Modell wird jede Administrationswebsite innerhalb eines dedizierten Anwendungspools und einer Webanwendung gehostet. In der folgenden Liste werden die einzelnen Administrationswebsite beschrieben:

  • Verwaltungssites der gemeinsamen Dienste Im Modell wird eine dedizierte Administrationswebsite für jeden SSP verwendet. Verwaltungssites der gemeinsamen Dienste können nicht auf einem einzelnen Server oder einer Gruppe von Servern isoliert werden. Diese Websites werden automatisch auf allen Front-End-Servern gespiegelt.

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

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

  • Wenn in administrativen URLs Portnummern verwendet werden, sollten dazu nicht standardmäßige Ports verwendet 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, wenn Sie für den Zugriff auf diese Websites nicht standardmäßige Ports festlegen.

  • Gestatten Sie den Zugriff auf Administrationswebsites nur von einer administrativen Domäne aus.

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

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

Anwendungspools

Separate IIS-Anwendungspools (Internet Information Services) werden normalerweise implementiert, um eine Prozessisolierung zwischen Inhalt zu erreichen. Anwendungspools bieten eine Möglichkeit für mehrere Websites, 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 geboten hätte.

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 (z. B. Verbindung mit dem Geschäftsdatenkatalog)

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

Im Modell werden Anwendungspools in folgender Weise verwendet:

  • Jede Administrationswebsite wird in einem dedizierten Anwendungspool gehostet. Dies ist eine Anforderung von Microsoft Office SharePoint Server 2007.

  • Intranetinhalt wird in zwei verschiedene Anwendungspools unterteilt. Gemeinsamer Inhalt (Meine Websites und Teamwebsites) wird in einem Anwendungspool gehostet. Der veröffentlichte Intranetinhalt wird in einem getrennten Anwendungspool gehostet. Diese Konfiguration bietet Prozessisolierung für den veröffentlichten Intranetinhalt, für die Geschäftsdatenverbindungen häufiger verwendet wird. Beispielsweise verwenden viele Personalabteilungswebsites (HR) Datenverbindungen, um den Mitarbeiterzugriff auf Ihre persönlichen Daten zu aktivieren.

  • Die Partner-Webanwendung wird in einem dedizierten Anwendungspool gehostet.

  • Die Unternehmens-Internetsite wird in einem dedizierten Anwendungspool auf Farm B gehostet Wenn diese Farm auch Host für Partnerzusammenarbeit wäre, würden diese zwei Arten von Inhalt (Internet und Partner) in zwei verschiedenen Anwendungspools gehostet werden.

Webanwendungen

Eine Webanwendung ist eine IIS-Website, die von SharePoint-Produkten und -Technologien erstellt und verwendet wird. Jede Webanwendung wird durch eine andere Website in IIS dargestellt, und jeder Webanwendung wird ein eindeutiger Domänenname zugewiesen, um websiteübergreifende Skriptangriffe zu verhindern.

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

  • Zum Trennen von anonymen Inhalt von authentifizierten Inhalt. Im Modell wird die Unternehmens-Internetwebsite in einer dedizierten Webanwendung und einem Anwendungspool gehostet.

  • Zum Isolieren von Benutzern. Im Modell wird die Partner-Webanwendung in einer dedizierten Webanwendung und in einem Anwendungspool gehostet, um sicherzustellen, dass die Partner keinen Zugriff auf den Intranetinhalt 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 so 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 Modell verfügen Meine Websites und die Teamwebsites über keine speziellen Isolierungsanforderungen und befinden sich daher im selben Anwendungspool. Allerdings befinden sie sich in separaten 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 Servicelevel-Vereinbarungen aushandeln. Beispielsweise können Sie für die Wiederherstellung von Meine Websites-Inhalt mehr Zeit einräumen, wenn dies nicht der wichtigste Inhaltstyp in Ihrem Unternehmen ist. Dadurch haben Sie ausreichend Zeit, um wichtigere Daten wiederherzustellen, bevor Sie Meine Websites-Inhalt wiederherstellen. Im Modell 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 logischer Architektur und Informationsarchitektur. Ziel der Websitesammlungen im Modell 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 Stammebenen-Websitesammlung. 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 zeigt die Websitehierarchie der Teamwebsites.

Logische Architektur von Websites für die Zusammenarbeit

Neben der Forderung nach einer Websitesammlung auf Stammebene drehen sich die Entwurfsentscheidungen um die zweite Ebene von Websitesammlungen. Das Modell bietet Auswahlmöglichkeiten im Hinblick auf die Art der Anwendung.

Veröffentlichte Intranetinhalte

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

  • Jede Abteilung kann ihren Inhalt unabhängig verwalten und die Berechtigungen selbst festlegen.

  • Der Inhalt jeder Abteilung kann in einer dedizierten Datenbank gespeichert werden.

Die Nachteile der Verwendung mehrerer Websitesammlungen umfassen:

  • Masterseiten, Seitenlayouts, Vorlagen, Webparts und die Navigation können nicht über Websitesammlungen hinweg gemeinsam verwendet werden.

  • Das Koordinieren, Anpassen und Navigieren über Websitesammlungen hinweg erfordert mehr Aufwand.

Je nach Informationsarchitektur und Entwurf der Intranetanwendung, kann der veröffentlichte Inhalt als nahtlose 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 Modell 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/benutzername angefügt. In der folgenden Abbildungen ist Meine Websites dargestellt.

Logische Netzwerkarchitektur für 'Meine Websites'

Weitere Informationen zum Entwerfen einer eigenen Meine Websites-Anwendung finden Sie unter Entwerfen einer Architektur für "Meine Website".

Teamwebsites

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

  • Gestatten 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 Hilf 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 eine begrenzte Anzahl von Websitesammlungen für Ihre Organisation, basierend auf der Arbeitsweise Ihrer Organisation. Bei diesem Ansatz werden Websitesammlungen durch einen 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 Taxonomiestruktur 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.

Das Modell integriert den zweiten Ansatz, der eine ähnliche Websitesammlungshierarchie für Teamwebsites und für veröffentlichten Intranetinhalt bewirkt. Die Herausforderung für Informationsarchitekten ist das Erstellen einer zweiten Ebene mit Sitesammlungen, 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 jede großes Team, das zum Produkt beiträgt. 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 jede akademische Abteilung.

Bundesministerien

  • 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 jedes Komitee oder eine gemeinsame Websitesammlung für alle Komitees.

Anwaltskanzlei

  • Erstellen Sie eine Websitesammlung für jeden Klienten.

Produktion

  • Erstellen Sie eine Websitesammlung für jede Produktlinie.

Partner-Webanwendung

Die Partner-Webanwendung soll für die Zusammenarbeit mit externen Partnern an umfangmäßig oder zeitlich begrenzten Projekten eingesetzt werden. Die Websites innerhalb der Partner-Anwendung sollen nicht unbedingt zusammenhängen. Die Anforderungen für die Partner-Webanwendung umfassen die Folgenden: dass:

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

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

  • Berechtigungen werden vom Websitebesitzer verwaltet.

  • Suchergebnisse innerhalb eines Projekts legen keinen Inhalt aus anderen Projekten offen.

  • Administratoren können leicht Websites identifizieren, die nicht mehr verwendet werden, und diese löschen.

Um diese Anforderungen zu erfüllen, enthält das Modell eine Websitesammlung für jedes Projekt. Auf diese Weise ergeben sich die folgenden Vorteile:

  • Die einzelnen Websitesammlungen sorgen für eine Trennung zwischen den Projekten.

  • Self-Service Site Creation kann implementiert werden.

Da die Partner-Webanwendung auch die Websitesammlungen zum Entwickeln von Inhalt für die Unternehmens-Internetsite hostet, werden separate Websitesammlungen für die Erstellung und die Bereitstellung erstellt.

Internetwebsite des Unternehmens

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

Logische Bereitstellungsarchitektur

Inhaltsdatenbanken

Sie können die folgenden zwei Ansätze verwenden, um Inhaltsdatenbanken in den Entwurf zu integrieren (das Modell enthält 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 automatisch der verfügbaren Datenbank oder den Datenbanken hinzugefügt, basierend auf Zielgröße.

  • 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 dem Befehlszeilentool Stsadm eine Websitesammlung in einer bestimmten Datenbank.

  • Reservieren Sie eine Datenbank für eine einzelne Websitesammlung, indem Sie die folgenden Datenbankkapazitätseinstellungen:

    • Anzahl Websites, nach deren Überschreitung eine Warnung 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 in Form von Lese- und Schreibvorgängen zugegriffen werden.

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

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

Veröffentlichte Intranetinhalte

Für veröffentlichte Intranetinhalte integriert das Modell eine dedizierte Datenbank für jede Abteilungswebsitesammlung.

Dieser Ansatz ermöglicht es den Abteilungen, den Inhalt unabhängig voneinander zu verwalten.

Meine Websites

Bei Meine Websites erreicht das Modell eine hohe Effizienz durch Verwaltung der Datenbanken bis zur maximalen Zielgröße. Die folgenden Einstellungen wurden zum Erreichen dieses Ziels 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 mit den allgemeinen Einstellungen für die Webanwendung 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. Sie berechnet die insgesamt zulässige Größe von Sites mithilfe von Zahlen, die sie für die vorherigen zwei Werte angeben. Basierend auf der Zielgröße für jede Datenbank wird dann bestimmt, wie viele Websites in die Datenbank passen.

Das Modell bietet die folgenden Beispielgrößeneinstellungen basierend auf einer Datenbankgröße von 100 Gigabyte (GB) und einer Zielgröße von 500 Megabyte (MB):

  • Größenbeschränkung pro Website = 500 MB

  • Zielgröße der Datenbank = 100 GB

  • Maximale Anzahl Websites= 200

  • Websiteanzahlwarnung = 150

Wenn der Schwellenwert für die Websiteanzahlwarnung erreicht ist, erstellen Sie eine neue Datenbank. Nach dem Erstellen der neuen Datenbank werden neue Meine Websites abwechselnd der neuen Datenbank und der vorhandenen Datenbank hinzugefügt, bis die maximale Anzahl der Websites für eine der Datenbanken erreicht wird.

Weitere Informationen zum Entwerfen von Datenbankeinstellungen für Meine Websites finden Sie unter Entwerfen einer Architektur für "Meine Website".

Teamwebsites

Für Teamwebsites integriert das Modell eine dedizierte Datenbank für jede Teamwebsitesammlung. Mit diesem Ansatz können Sie die Datenbank jedes Teams unabhängig für Sicherung, Wiederherstellung und Migration verwalten. Wenn ein Projekt abgeschlossen ist, können Sie die Datenbank für das Projekt problemlos archivieren.

Partner-Webanwendung

Wie Meine Websites erreicht die Partner-Webanwendung eine hohe Effizienz durch Verwaltung der Datenbanken bis zur maximalen Zielgröße. Im Modell hostet jedoch Partner-Webanwendung auch Dokumenterstellung- und Stagingumgebung-Websitesammlungen für das Unternehmen Internetsite. Folglich enthält der Datenbankentwurf beide Ansätze:

  • Erstellungs- Bereitstellungswebsites werden jeweils in einer dedizierten Datenbank gehostet.

  • Datenbank- und Größeneinstellungen werden zum Verwalten aller anderen Websites und Datenbanken konfiguriert.

Da Partner-Webanwendung in einer dedizierten Webanwendung gehostet wird, können Sie Größenbeschränkungen, die für die Typen von Größen erstellten mehr geeignet sind erstellen. Das Modell bietet das folgende Beispiel für Größeneinstellungen:

  • Zielgröße der Datenbank = 100 GB

  • Speicherung Kontingent pro Website = 5 GB

  • Maximale Anzahl Websites= 20

  • Erstellungs- und Bereitstellungs-Websitesammlungen werden in dedizierten Datenbanken gehostet

Internetwebsite des Unternehmens

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

Zonen und URLs

Das Modell veranschaulicht, wie URLs über mehrere Anwendungen hinweg innerhalb einer Unternehmensbereitstellung koordiniert werden.

Entwurfsziele

Die folgenden Ziele beeinflussen die Entwurfsentscheidungen für URLs:

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

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

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

Entwurfsgrundsätze

Zum Erreichen dieser Entwurfsziele wurden die folgenden Entwurfsprinzipien angewendet:

  • Hostnamen-Websitesammlungen werden nicht verwendet. Beachten Sie, dass Hostnamen-Websitesammlungen sich von IIS-Hostheadern unterscheiden. Hostnamen-Websitesammlungen können nicht mit alternativen Zugriffszuordnungen verwendet werden. Die alternativen Zugriffszuordnungen sind erforderlich für den Zugriff auf denselben Inhalt über mehrere Domänen-URLs. Folglich stehen wenn Hostnamen-Websites verwendet werden, diese Websites nur über die Standardzone zur Verfügung. Das alternative Zugriffszuordnungsfeature bietet auch Unterstützung für off-Box-Terminierung von (SSL), wodurch Remotemitarbeiterzugriff und Partnerzugriffsszenarien für die Verwendung von SSL (HTTPS).

  • Jede Anwendung umfasst eine einzelne Website-Websitesammlung. Dies ist eine Anforderung für die Verwendung alternativer Zugriffszuordnungen. Wenn mehrere Stammwebsitesammlungen innerhalb einer Webanwendung erforderlich sind und Sie voraussichtlich nur die Standardzone für den Benutzerzugriff verwenden, sind Hostnamen-Websitesammlungen eine gute Option.

  • Für Anwendungen, die mehrere allgemeine Websitesammlungen enthalten, an jedem Standort die Auflistung einen übergeordneten Team oder Projekt (z. B. Teamwebsites) darstellt enthält das Modell verwaltete Pfade. Verwaltete Pfade bieten eine größere Kontrolle über URLs für diese Typen von Websites.

Kompromisse beim Entwurf

Die Erfüllung der Entwurfsziele führt zu einigen Kompromissen, einschließlich der Folgenden:

  • Die URLs sind länger.

  • Hostnamen-Websitesammlungen 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 eine eindeutige URL im Modell.

Intranet

Jede der drei Anwendungen, die das Intranet umfasst, erfordert eine eindeutige URL. Im Modell sind die Zielgruppen für den Intranetinhalt die internen Mitarbeiter und die Remotemitarbeiter. In der folgenden Tabelle sind die URLs aufgeführt, über die interne und Remotemitarbeiter auf jede Anwendung zugreifen können.

Anwendung Interne Mitarbeiter-URL Remotemitarbeiter-URL

Veröffentlichte Intranetinhalte

http://fabrikam

https://intranet.fabrikam.com

Teamwebsites

http://teams

https://teams.fabrikam.com

Meine Websites

http://my

https://my.fabrikam.com

Partner-Webanwendung

Im Modell greifen interne Mitarbeiter, Remotemitarbeiter und Partnermitarbeiter auf die Partner-Webanwendung zu. Obwohl Remotemitarbeiter und Partnermitarbeiter beide extern über SSL (HTTPS) auf die Partner-Webanwendung zugreifen, benötigen sie jeweils eine andere URL, um die Vorteile der Verwendung separater Zonen zu nutzen – d. h. verschiedene Authentifizierungsmethoden und andere Zonenrichtlinien. In der folgenden Tabelle sind die URLs aufgeführt, die diese internen und Remotemitarbeiter und Partner für den Zugriff auf die Partner-Webanwendung verwenden.

Zone URL

Interne Mitarbeiter-URL

http://partnerweb

Remotemitarbeiter-URL

https://remotepartnerweb.fabrikam.com

Partner-URL

https://partnerweb.fabrikam.com

Internetwebsite des Unternehmens

Die Internetwebsite des Unternehmens ist eine öffentliche Website und kann von jedem Benutzer über die Standard-URL aufgerufen werden: https://www.microsoft.com/de/de/default.aspx Die Richtlinien der Internetzone werden angewendet (anonymer Zugriff, Schreibschutz).

Zur Unterstützung von Verwaltungs- und Erstellungsaufgaben auf der öffentlichen Website verfügt das Modell auch über URLs für interne und Remotemitarbeiter. Richtlinien für diese Zonen beschränken alle Berechtigungen, die über den Lesezugriff hinaus gehen, auf spezielle Sicherheitsgruppen. In der folgenden Tabelle sind die URLs für jede Zone aufgelistet.

Zone URL

Interne Mitarbeiter-URL

http://fabrikamsite

Remotemitarbeiter-URL

https://fabrikamsite.fabrikam.com

Kunden-URL

https://www.microsoft.com/de/de/default.aspx/

Verwenden von expliziten Inklusionen 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 Websitesammlung oder mehrere Websitesammlungen in einem speziellen Pfad unterhalb der Stammwebsite vorhanden sind. Ohne verwaltete Pfade sind alle unterhalb der Stammwebsitesammlung erstellten Websites Teil der Stammwebsitesammlung.

Sie können folgende zwei Arten von verwalteten Pfaden erstellen:

  • Ausdrückliche Inklusion Eine Websitesammlung mit der expliziten URL, die Sie zuweisen. Eine explizite Inklusion gilt für nur eine Websitesammlung. Sie können viele explizite Inklusionen unterhalb einer Stammwebsitesammlung erstellen. Eine Beispiel-URL für eine Websitesammlung, die mithilfe dieser Methode erstellt wurde, ist http://fabrikam/HR.

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

Das Modell umfasst die Verwendung beider Typen, wie in den folgenden Abschnitten beschrieben.

Ausdrückliche Inklusionen: Teamwebsites und veröffentlichter Intranetinhalt

Im Modell werden sowohl in den Teamwebsites als auch im veröffentlichten Intranetinhalt ausdrückliche Inklusionen verwendet.

Teamwebsites

In der Anwendung Teamwebsites wird eine ausdrückliche Inklusion für jede Teamwebsitesammlung verwendet. Die Skalierungsgrenze für Websitesammlungen, die mit einer ausdrücklichen Inklusion erstellt werden, liegt bei ca. 100 Websites. Zur einfacheren Steuerung wird empfohlen, die Anzahl der Teamwebsites auf der obersten Ebene auf eine zu bewältigende Anzahl zu beschränken. Die Taxonomie für Teamwebsites sollte zudem für Ihr Unternehmen logisch sein. Für viele Unternehmen sind die empfohlenen 100 Websites ausreichend. Wenn Ihr Unternehmen mehr Teamwebsites benötigt, verwenden Sie stattdessen eine Platzhalterinklusion.

Im Modell führt die Verwendung von ausdrücklichen Inklusionen zu den Ergebnissen in den URLs in der folgenden Tabelle.

Interner Mitarbeiter (Intranetzone) Remotemitarbeiter (Standardzone)

http://team/Team1

https://team.fabrikam.com/Team1

http://team/Team2

https://team.fabrikam.com/Team2

http://team/Team3

https://team.fabrikam.com/Team3

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

Veröffentlichte Intranetinhalte

Innerhalb der Anwendung Veröffentlichter Intranetinhalt wird eine ausdrückliche Inklusion für jede Unterwebsite verwendet: HR, Facilities und Purchasing. Dies ermöglicht es jeder dieser Websites, unabhängig verwaltet zu werden. Jede dieser Websitesammlungen kann einer anderen Inhaltsdatenbank zugeordnet werden falls erforderlich, um Datenzuwachs zu bewältigen und eine Sicherung und separate Wiederherstellung dieser Websites zu ermöglichen.

Im Modell führt die Verwendung von ausdrücklichen Inklusionen zu den Ergebnissen in den URLs in der folgenden Tabelle.

Interner Mitarbeiter (Intranetzone) Remotemitarbeiter (Standardzone)

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, das standardmäßige Basisverzeichnis für das Intranet dar. Diese Website soll Inhalt für Benutzer hosten.

Platzhalterinklusionen: Partner-Web und Meine Websites

Partner-Web und Meine Websites beinhalten die Verwendung einer Platzhalterinklusion. Platzhalterinklusionen sind ideal für Anwendungen, mit denen Benutzer eigene Websitesammlungen erstellen können. Eine Platzhalterinklusion gibt an, dass das nächste Element nach dem Platzhalter eine Stammwebsite einer Websitesammlung ist.

Meine Websites

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

Dies führt zu URLs mit dem Format, das in der folgenden Tabelle aufgeführt ist.

Intern (Intranetzone) Remotemitarbeiter (Standardzone)

http://my/sites/user1

https://my.fabrikam.com/personal/user1

http://my/sites/user2

https://my.fabrikam.com/personal/user2

http://my/sites/user3

https://my.fabrikam.com/personal/user3

Partner-Webanwendung

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

Im Modell enthält die Partner-Webanwendung eine Platzhalterinklusion mit der Bezeichnung: named /sites (http://partnerweb/sites). Dies führt zu URLs mit dem Format, das in der folgenden Tabelle aufgeführt ist.

Interner Mitarbeiter (Intranetzone) Remotemitarbeiter (Standardzone)

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

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

Partner (Extranetzone)

https://partnerweb.fabrikam.com/sites/project1

https://partnerweb.fabrikam.com/sites/project2

https://partnerweb/fabrikam.com/sites/project3

Die Ausnahme für Partner-Web, wie im Modell dargestellt, sind die zwei Websitesammlungen, die für die Dokumenterstellung und das Staging des Inhalts der Unternehmens-Internetwebsite reserviert sind. Für diese zwei Websitesammlungen wird eine explizite Inklusion verwendet. Dies ist ein Beispiel für die Verwendung von expliziten und Platzhalterinklusionen in derselben Webanwendung.

Administrations-URLs

Die folgende Tabelle listet die URLs für die Administrationszone jeder Anwendung auf, die auf der Serverfarm gehostet wird.

Anwendung URL

Veröffentlichte Intranetinhalte

http://fabrikam.admin

Teamwebsites

http://teams.admin

Meine Websites

http://my.admin

Partner-Webanwendung

http://partnerweb.admin

Internetwebsite des Unternehmens

http://fabrikamsite.admin

Das Modell setzt voraus, dass Administratoren über internen Zugriff auf das Unternehmensnetzwerk verfügen.

Zonenrichtlinien

Sie können eine Richtlinie für eine Webanwendung erstellen, um Berechtigungen auf Anwendungsebene zu erzwingen. Eine Richtlinie kann im Allgemeinen nur für die Webanwendung oder eine bestimmte Zone definiert werden. Eine Richtlinie erzwingt Berechtigungen für jeglichen Inhalt innerhalb der Webanwendung oder der Zone. Richtlinienberechtigungen überschreiben alle anderen Sicherheitseinstellungen, die für Websites und Inhalt konfiguriert sind. Sie können Richtlinien basierend auf Benutzern oder Benutzergruppen, jedoch nicht auf SharePoint Gruppen konfigurieren.

Das Modell enthält Beispiele für mehrere Richtlinien, die Folgendes bezwecken:

  • Gestatten Sie Administratoren den Zugriff auf sämtlichen Inhalt.

  • Verweigern Sie den Schreibzugriff auf veröffentlichten Inhalt.

  • Stellen sicher, dass Autoren und Tester über entsprechenden Zugriff auf den veröffentlichten Inhalt verfügen.

Herunterladen dieses Buchs

Dieses Thema wurde zum leichteren Lesen und Ausdrucken in das folgende Buch zum Herunterladen aufgenommen:

Die vollständige Liste der verfügbaren Bücher finden Sie unter Bücher zum Herunterladen für Office SharePoint Server 2007.