Entwurfsbeispiel für logische Architektur: Websites für die Zusammenarbeit
Inhalt dieses Artikels:
Informationen zum Modell
Allgemeine Entwurfsziele
Serverfarmen
Benutzer, Zonen und Authentifizierung
Verwaltungswebsites
Anwendungspools
Webanwendungen
Websitesammlungen
Inhaltsdatenbanken
Zonen und URLs
Zonenrichtlinien
Sichern und Wiederherstellen von Websites für die Zusammenarbeit
Entwerfen für eine sichere externe Zusammenarbeit
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 für logische Architektur: Windows SharePoint Services-Zusammenarbeit (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=124861&clcid=0x407).
Informationen zum Modell
Das Modell veranschaulicht eine Bereitstellung für ein fiktives Unternehmen namens Fabrikam, Inc. Wenn Sie eine Lösung mit mindestens einem der in diesem Modell veranschaulichten Typen von Websites für die Zusammenarbeit planen, können Sie das Modell als Grundlage für Ihren eigenen Entwurf verwenden.
Das Modell veranschaulicht eine allgemeine Bereitstellung von Windows SharePoint Services 3.0 mit drei verschiedenen Typen von Websites für die Zusammenarbeit:
Teamwebsites
Self-Service-Websites
Websites für die Partnerzusammenarbeit
Bei diesem Modell wurden fast alle Komponenten der logischen Architektur angewendet. Es veranschaulicht, wie diese in den Gesamtentwurf integriert wurden. In diesem Artikel werden die Entwurfsziele für das Modell beschrieben und erläutert, wie diese Ziele mithilfe der Komponenten der logischen Architektur, die im Modell dargestellt sind, erreicht werden können.
Jeder der verschiedenen Typen von Websites für die Zusammenarbeit:
Hostet Daten mit verschiedenen Datenmerkmalen.
Unterliegt einem anderen Verwendungsprofil.
Erfordert eine andere Strategie für die Berechtigungsverwaltung.
Daher ist die Entwurfsauswahl des Modells darauf ausgerichtet, die Leistung und Sicherheit jeder Anwendung zu optimieren.
Teamwebsites
Teamwebsites stellen stark strukturierte und verwaltete Websites für die Zusammenarbeit mit den folgenden Merkmalen dar:
Es liegt eine kleinere Anzahl von Websitesammlungen der obersten Ebene vor, und diese Websitesammlungen sollen eine große Datenmenge umfassen (im Gegensatz zu Self-Service-Websites).
URLs der obersten Ebene sind für jedes Team aussagekräftig.
Zusätzliche Planung wird in Websitehierarchien, Taxonomien und Anpassungen gesteckt.
Die Inhalte der einzelnen Teams befinden sich in gesonderten Datenbanken und können separat verwaltet werden.
Das folgende Diagramm veranschaulicht die Websitehierarchie für Teamwebsites:
.gif "Organisation von Teamwebsites")
Self-Service-Websites
Self-Service-Websites bieten eine Alternative zu stark verwalteten Teamwebsites. Sie können mithilfe der Self-Service Site-Verwaltung Benutzern die Möglichkeit geben, eigene Websitesammlungen zu erstellen. Aktivieren Sie hierzu die Self-Service Site-Verwaltung in der Zentraladministration. Diese Methode eignet sich am besten, wenn Sie Gruppen oder Communitys das Erstellen von Websites ermöglichen möchten. Diese Methode funktioniert auch dann, wenn Sie Websites hosten und Benutzern das Erstellen von Websites ermöglichen möchten, ohne auf einen ausführlichen Prozess warten zu müssen.
In der Regel unterscheiden sich die Merkmale von Self-Service-Websites von stark verwalteten Websites. Diese Merkmale können wie folgt aussehen:
Eine hohe Anzahl von Websitesammlungen der obersten Ebene.
Eine geringe Datenmenge pro Websitesammlung.
URLs, die automatisch generiert werden, aber normalerweise nicht aussagekräftig sind.
Das folgende Diagramm veranschaulicht die Implementierung von Self-Service-Websites im Entwurfsbeispiel:
.gif "Webseiten für die eigenständige Websiteerstellung")
Wenn die Implementierung von Self-Service-Websites geplant ist, müssen mehrere Kompromisse eingegangen werden. Diese Kompromisse wirken sich auf die Art der Verwaltung dieser Websitetypen aus:
Anstelle der Implementierung einer anspruchsvollen Taxonomie werden Websites nach Belieben erstellt, ohne siteübergreifende Prinzipien festzulegen. Da es sich bei jeder neuen Website um eine Websitesammlung handelt, können Vorlagen und die Navigation von Self-Service-Websites nicht gemeinsam genutzt werden.
Da jede Websitesammlung die Suche nur nach Inhalten in dieser Websitesammlung bereitstellt, wird keine Summierung der Suchergebnisse über Websitesammlungen hinweg erzielt.
Websitesammlungen können hinsichtlich ihrer Größe und Verwendung deutlich variieren.
Websites können problemlos aufgegeben werden.
Zur Verwaltung von Self-Service-Websites können auch die Verwaltung von Inhaltsspeichern auf der Grundlage der Zielgröße von Inhaltsdatenbanken sowie das regelmäßige Löschen von nicht mehr benötigten Websites gehören.
Weitere Informationen zur Implementierung der Self-Service Site-Verwaltung finden Sie unter Plan process for creating sites (Windows SharePoint Services).
Websites für die Partnerzusammenarbeit
Die Partnerwebanwendung 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 sichere Websites für die Zusammenarbeit erstellen können. Zu den Schlüsselfaktoren der Entwurfsauswahl 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.
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 folgenden Diagramm werden Websites für die Partnerzusammenarbeit veranschaulicht.
.gif "Hierarchie von Projektseiten in einer Partner-Webanwendung")
Allgemeine Entwurfsziele
Das Modell veranschaulicht eine praktische Implementierung von Windows SharePoint Services 3.0-Features in mehreren unterschiedlichen Typen von Anwendungen für die Zusammenarbeit (Teamwebsites, Self-Service-Websites und Partnerwebsites). Die Entwurfsimplementierungen für die einzelnen Websiteanwendungen werden in diesem Artikel beschrieben. Zu den wichtigsten Entwurfszielen des Modells gehören die folgenden:
Erstellung eines Frameworks für das Entwerfen einer Umgebung, die noch wachsen kann. Die Entwurfsentscheidungen für einzelne Anwendungen für die Zusammenarbeit verhindern nicht das Hinzufügen von anderen Anwendungen. Beispielsweise könnte eine Erstbereitstellung nur Teamwebsites für die Zusammenarbeit oder nur Partnerwebsites enthalten. Mithilfe eines ähnlichen logischen Architekturentwurfs können Sie der Lösung andere Typen von Websites für die Zusammenarbeit hinzufügen, ohne dass sich Auswirkungen auf den Entwurf der ersten Websites für die Zusammenarbeit ergeben. 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 verschiedenen Anwendungen für die Zusammenarbeit 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 Erstentwurf nur für den Zugriff durch interne Mitarbeiter gedacht gewesen sein. Durch Verwendung eines ähnlichen Entwurfs können Sie nun jedoch auch Remotemitarbeitern, Partnermitarbeitern oder selbst Kunden den Zugriff ermöglichen.
Stellen Sie sicher, dass der Entwurf in einer Extranetumgebung verwendet werden kann. Durch überlegte Entwurfsentscheidungen können Sie sicherstellen, dass die Serverfarmen sicher in einem Umkreisnetzwerk oder in den unter Design extranet farm topology (Windows SharePoint Services) erläuterten Extranettopologien 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 veranschaulicht eine Farm mit fünf Servern. Das Modell könnte jedoch auf einer Farm beliebiger Größe implementiert werden, einschließlich einer Farm mit einem einzelnen Server. Die Serverfarm im Modell setzt sich aus fünf Servern mit der folgenden Topologie zusammen:
Zwei Front-End-Webserver
Ein Anwendungsserver für den Suchserver
Zwei Datenbankserver, entweder gruppiert oder gespiegelt
Das Modell veranschaulicht die logische Architektur von Windows SharePoint Services 3.0 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 Plan for performance and capacity (Windows SharePoint Services).
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 veranschaulicht, wie die Authentifizierung auf Benutzer aus verschiedenen Netzwerkzonen angewendet wird. In der folgenden Tabelle wird auch dargestellt, wie die Authentifizierung auf jeden Benutzer- und Zonentyp angewendet wird.
| Zone | Benutzer | Authentifizierung |
|---|---|---|
Intranet |
Interne Mitarbeiter |
NTLM (in Windows integriert) |
Standard |
Remotemitarbeiter |
NTLM (in Windows integriert) oder Formularauthentifizierung mit LDAP (Lightweight Directory Access Protocol) |
Extranet |
Partnermitarbeiter |
Formularauthentifizierung |
Interne Mitarbeiter
Die Intranetzone wird für den internen Mitarbeiterzugriff verwendet. Es wird die integrierte Windows-Authentifizierung verwendet.
Remotemitarbeiter
Die Standardzone wird für den Remotemitarbeiterzugriff verwendet. Die Entwurfsziele für die Standardzone lauten wie folgt:
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 Windows SharePoint Services 3.0 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 Optionen zum Authentifizieren von Remotemitarbeitern bereit. Mit der ersten Option (Integrierte Windows-Authentifizierung mit NTLM) werden beide Entwurfsziele erreicht. Die zweite Option (Formularauthentifizierung mit LDAP) entspricht dem ersten Ziel, jedoch nicht dem zweiten. Folglich ist die erste Option die bevorzugte Methode für Remotemitarbeiter.
In der folgenden Tabelle werden die Unterschiede zwischen diesen beiden Ansätzen dargestellt.
| Art des Vergleichs | Integrierte Windows-Authentifizierung mit NTLM | Formularauthentifizierung mit einem LDAP-Anbieter |
|---|---|---|
Funktion |
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 Windows SharePoint Services 3.0. Diese Server verwenden die Formularauthentifizierung zur Benutzerauthentifizierung in der Active Directory-Umgebung. Sie leiten die Windows-Anmeldeinformationen dann an Windows SharePoint Services 3.0 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" nachstehend in diesem Artikel. |
In Windows SharePoint Services 3.0 wird die Formularauthentifizierung mit einem LDAP-Anbieter zur Authentifizierung von Remotemitarbeitern bei der internen Active Directory-Umgebung verwendet. |
Vorteile |
In Windows SharePoint Services 3.0 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, IAG 2007 oder eines anderen Proxyserverprodukts. |
Wenn Benutzer sowohl intern als auch remote eine Verbindung zu Windows SharePoint Services 3.0 herstellen, werden in Windows SharePoint Services 3.0 zwei verschiedene Benutzerkonten erstellt. Folglich erfordern beide Konten Berechtigungen für Websites und Dokumente. 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.
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 beim Entwurf des Modells berücksichtigt wurden.
Konfigurationsanforderungen der Standardzone
Die Zone, die die meisten Überlegungen betreffen, ist die Standardzone. In Windows SharePoint Services 3.0 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.
Die Indexkomponente muss über mindestens eine Zone auf Inhalte zugreifen können, um diese crawlen zu können. Die Indexkomponente verwendet die NTLM-Authentifizierung. Folglich muss mindestens eine der Zonen für die NTLM-Authentifizierung konfiguriert werden, um Inhalte zu crawlen. Außerdem ruft der Crawler Zonen in der folgenden Reihenfolge ab, bis eine Zone gefunden wird, über die die Authentifizierung möglich ist: Standard, Intranet, Internet, Benutzerdefiniert und Extranet. Wenn der Crawler jedoch als erstes auf eine Zone trifft, die für die Kerberos-, Standard- oder Digest-Authentifizierung konfiguriert wurde, wird der Crawler nicht authentifiziert und versucht nicht, auf die nächste Zone zuzugreifen. Stellen Sie daher sicher, dass das Crawlen von Inhalten nicht durch die Konfiguration von Zonen verhindert wird. Weitere Informationen zu Authentifizierungsanforderungen im Hinblick auf das Crawlen von Inhalten finden Sie unter Plan authentication methods.
Administrative E-Mails werden mit Verknüpfungen aus der Standardzone gesendet. Hierzu gehören E-Mail-Nachrichten an Besitzer von Websites, die sich bald ihren Kontingentgrenzen nähern. Benutzer, die diese Art von E-Mail 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 Verknüpfungen in administrativen E-Mails zugreifen, unabhängig davon, ob sie intern oder remote auf die Websites zugreifen.
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 vertraulichen 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.
Benutzern ist die Zusammenarbeit über mehrere Webanwendungen hinweg möglich. So können beispielsweise interne Mitarbeiter sowie Remotemitarbeiter potenziell Beiträge liefern und Inhalte über alle Webanwendungen hinweg verwalten: Teamwebsites, Self-Service-Websites und Partnerwebsites.
Folgende Entwurfsprinzipien sollten in einer Extranetumgebung beachtet werden:
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.
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 wird nur für eine Webanwendung konfiguriert.
Alternative Zugriffszuordnungen werden beim Erstellen der Zone automatisch erstellt. Wenn Sie jedoch einen Proxyserver oder ein Gatewayprodukt verwenden, um Websites über das Internet zur Verfügung zu stellen, müssen Sie einen zusätzlichen alternativen Zugriffszuordnungseintrag für jede Zone hinzufügen. Dadurch wird sichergestellt, dass URLs, die Benutzern außerhalb des internen Netzwerks zurückgegeben werden, diesen in Übereinstimmung mit dem Kontext ihrer Zone verfügbar sind. Weitere Informationen finden Sie unter Plan alternate access mappings.
Wenn zonenübergreifende Webanwendungen 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.
Verwaltungswebsites
Im Modell wird die Website für die Zentraladministration auf dem Suchserver 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 Website für die Zentraladministration dennoch verfügbar. Darüber hinaus wird die Website für die Zentraladministration innerhalb eines dedizierten Anwendungspools und einer Webanwendung gehostet.
Die Lastenausgleich-URLs für die Verwaltungswebsites 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 Verwaltungswebsites erhöht werden, wenn Sie für den Zugriff auf diese Websites nicht standardmäßige Ports festlegen.
Erstellen Sie separate DNS-Einträge für Verwaltungswebsites.
Anwendungspools
Separate IIS-Anwendungspools (Internetinformationsdienste, Internet Information Services) werden normalerweise implementiert, um eine Prozessisolierung zwischen Websites 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 werden mögliche Sicherheitslücken geschlossen, die es einem Angreifer ermöglichen, Code auf dem Server für Angriffe auf andere Websites einzufügen.
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 Websites, die vorrangig auf die Zusammenarbeit mit externen Partnern oder Kunden ausgerichtet sind. Dadurch werden externe Konten auf Websites innerhalb eines Anwendungspools isoliert.
Isolieren von Websites, 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:
Die Verwaltungswebsite wird in einem dedizierten Anwendungspool gehostet. Dies ist eine Anforderung von Windows SharePoint Services 3.0.
Die internen Websites für die Zusammenarbeit (Teamwebsites und Self-Service-Websites) werden in einem Anwendungspool gehostet.
Die Partnerwebanwendung wird in einem dedizierten Anwendungspool gehostet.
Webanwendungen
Eine Webanwendung ist eine IIS-Website, die von SharePoint-Produkte 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 Inhalten von authentifizierten Inhalten.
Zum Isolieren von Benutzern. Im Modell wird die Partnerwebanwendung in einer dedizierten Webanwendung und in einem Anwendungspool gehostet, um sicherzustellen, dass die Partner keinen Zugriff auf interne Inhalte für die Zusammenarbeit haben.
Erzwingen von Berechtigungen. Eine dedizierte Webanwendung bietet die Möglichkeit zum Erzwingen von Berechtigungen mithilfe der Seite Richtlinie für Webanwendung in der Zentraladministration. Beispielsweise können Sie eine Richtlinie auf den internen Websites für die Zusammenarbeit erstellen und so den Zugriff auf Partnerkonten 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. Websites erzielen eine bessere Leistung, wenn sie zusammen mit anderen Anwendungen mit ähnlichen Datenmerkmalen in Webanwendungen platziert werden. Die Datenmerkmale von Self-Service-Websites umfassen beispielsweise 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 Teamwebsites und Self-Service-Websites ü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 Self-Service-Websites 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 diese Websites wiederherstellen. Im Modell befinden sich Self-Service-Websites in einer separaten Webanwendung, damit die Administratoren genauer auf die Größe dieser Websites achten als bei anderen Anwendungen.
Websitesammlungen
Websitesammlungen schlagen eine Brücke zwischen der logischen Architektur und der Informationsarchitektur. 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" nachstehend in diesem Artikel. Neben der zweiten Ebene von Websitesammlungen verfügt jede Website über eine Unterwebsite.
Die folgende Abbildung zeigt die Websitehierarchie der Teamwebsites.
.jpg "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.
Self-Service-Websites
Im Modell enthalten die Self-Service-Websites eine Website der obersten Ebene mit der URL http://sites. 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 Websitevorlage erben, die zum Erstellen der Website der obersten Ebene verwendet wurde. In der folgenden Abbildung sind Self-Service-Websites dargestellt.
Weitere Informationen zu Self-Service-Websites finden Sie unter Plan process for creating sites (Windows SharePoint Services).
Teamwebsites
Beim Entwerfen von Websitesammlungen innerhalb einer Teamwebsiteanwendung wird empfohlen, eine begrenzte Anzahl von Websitesammlungen für Ihre Organisation zu erstellen, basierend auf der Arbeitsweise Ihrer Organisation. Bei diesem Ansatz werden Websitesammlungen durch einen Windows SharePoint Services 3.0-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. Zudem stehen mehr Möglichkeiten zur Verfügung, Vorlagen und Navigation für Projekte und Teams freizugeben, die eine Websitesammlung gemeinsam nutzen. Die Herausforderung für Informationsarchitekten ist das Erstellen einer zweiten Ebene mit Websitesammlungen, die für die Organisation sinnvoll ist. In der folgenden Tabelle sind Vorschläge für verschiedene Arten von Organisationen aufgeführt.
| Typ der Organisation | Vorgeschlagene Websitesammlungstaxonomien |
|---|---|
Produktentwicklung |
|
Forschung |
|
Hochschule/Universität |
|
Bundesministerien |
|
Anwaltskanzlei |
|
Produktion |
|
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-Webanwendung sollen nicht unbedingt zusammenhängen. Die Anforderungen für die Partner-Webanwendung umfassen die folgenden:
Projektbesitzer können problemlos Websites für die Zusammenarbeit mit Partnern erstellen.
Partner und andere Mitarbeiter haben nur Zugriff auf die Projekte, an denen 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; somit ergeben sich die folgenden Vorteile:
Die einzelnen Websitesammlungen sorgen für eine Trennung zwischen den Projekten.
Self-Service Site Creation kann implementiert werden.
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 der 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 anwenden:
Anzahl an 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:
Erstellen Sie die Datenbank in der Webanwendung und legen für sie den Status Bereit fest.
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 mittels Lese- und Schreibvorgängen zugegriffen werden.
Erstellen Sie die Websitesammlungen. Diese werden automatisch der Datenbank hinzugefügt.
Legen Sie den Status aller anderen Datenbanken auf Bereit fest.
Teamwebsites
Das Modell integriert 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.
Self-Service-Websites
Bei Self-Service-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 Websites 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 an Websites = 200
Websiteanzahlwarnung = 175
Wenn der Schwellenwert für die Websiteanzahlwarnung erreicht ist, erstellen Sie eine neue Datenbank. Nach dem Erstellen der neuen Datenbank werden neue Self-Service-Websites abwechselnd der neuen Datenbank und der vorhandenen Datenbank hinzugefügt, bis die maximale Anzahl der Websites für eine der Datenbanken erreicht wird.
Partner-Webanwendung
Wie Self-Service-Websites erreicht die Partner-Webanwendung eine hohe Effizienz durch Verwaltung der Datenbanken bis zur maximalen Zielgröße.
Da die Partner-Webanwendung in einer dedizierten Webanwendung gehostet wird, können Sie Größenbeschränkungen erstellen, die für die erstellten Typen von Größen besser geeignet sind. Das Modell bietet das folgende Beispiel für Größeneinstellungen:
Zielgröße der Datenbank = 100 GB
Speicherkontingent pro Website = 5 GB
Maximale Anzahl an Websites= 20
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 Inhalte 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 diese Websites bei Verwendung von Hostnamen-Websites nur über die Standardzone zur Verfügung. Das alternative Zugriffszuordnungsfeature bietet auch Unterstützung für off-Box-Terminierung von SSL (Secure Sockets Layer), wodurch Remotemitarbeiterzugriff und Partnerzugriffsszenarien für die Verwendung von SSL (HTTPS) möglich werden. Weitere Informationen zur Verwendung von Websitesammlungen mit Hostnamen finden Sie unter White paper: Create shared hosting solutions on Windows SharePoint Services.
Jede Anwendung umfasst eine einzelne Stammwebsitesammlung. 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 Websitesammlungen mit Hostnamen eine gute Option.
Für Anwendungen, die mehrere allgemeine Websitesammlungen enthalten, in denen jede Websitesammlung ein übergeordnetes Team oder Projekt (z. B. Teamwebsites) darstellt, enthält das Modell verwaltete Pfade. Verwaltete Pfade bieten bessere Steuerungsmöglichkeiten ü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 gegebenenfalls das Protokoll, das Schema, den Hostnamen und den Port. 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.
Websites für die interne Zusammenarbeit
Die zwei unterschiedlichen Typen von Websites für die interne Zusammenarbeit erfordern jeweils eine eindeutige URL. Im Modell bilden interne Mitarbeiter und Remotemitarbeiter die Zielgruppe für diese Websites. In der folgenden Tabelle werden die URLs für interne Mitarbeiter und Remotemitarbeiter für den Zugriff auf die einzelnen Anwendungen aufgelistet.
| Anwendung | Interne Mitarbeiter-URL | Remotemitarbeiter-URL |
|---|---|---|
Teamwebsites |
http://teams |
https://teams.fabrikam.com |
Self-Service-Websites |
http://sites |
https://sites.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 von den Vorteilen der Verwendung separater Zonen zu profitieren – d. h. verschiedene Authentifizierungsmethoden und andere Zonenrichtlinien. In der folgenden Tabelle sind die URLs aufgeführt, die diese internen Mitarbeiter 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 |
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 die folgenden zwei Typen 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://team/Team1.
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 Self-Service Site Creation unterstützen. Eine Beispiel-URL für eine Websitesammlung, die mithilfe dieser Methode erstellt wurde, ist http://sites/site1.
Das Modell umfasst die Verwendung beider Typen, wie in den folgenden Abschnitten beschrieben.
Ausdrückliche Inklusionen: Teamwebsites
Im Modell ermöglichen beide Teamwebsiteanwendungen die Verwendung von expliziten Inklusionen.
Teamwebsites
In der Teamwebsiteanwendung 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 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 Inhalte für Benutzer.
Platzhalterinklusionen: Partner-Webanwendung und Self-Service-Websites
Sowohl die Partner-Webanwendung als auch Self-Service-Websites ermöglichen 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.
Self-Service-Websites
Im Modell enthalten die Self-Service-Websites eine Platzhalterinklusion mit der Bezeichnung /sites (http://selfservice/sites).
Dies führt zu URLs in dem Format, das in der folgenden Tabelle aufgeführt ist.
| Intern (Intranetzone) | Remotemitarbeiter (Standardzone) |
|---|---|
http://selfservice/sites/site1 |
https://selfservice.fabrikam.com/sites/site1 |
http://selfservices/sites/site2 |
https://selfservice.fabrikam.com/sites/site2 |
http://selfservice/sites/user3 |
https://selfservices.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 Erstellung von Self-Service-Websites zulässig.
Im Modell enthält die Partner-Webanwendung eine Platzhalterinklusion mit der Bezeichnung /sites (http://partnerweb/sites). Dies führt zu URLs in 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 aufgeführt sind.
| Partner (Extranetzone) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
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 Inhalte konfiguriert sind. Sie können Richtlinien basierend auf Benutzern oder Benutzergruppen, jedoch nicht auf SharePoint-Gruppen konfigurieren.
Das Modell enthält ein Beispiel: Partnerkonten den Zugriff auf Websites für die interne Zusammenarbeit verweigern.
Sichern und Wiederherstellen von Websites für die Zusammenarbeit
Es bestehen mehrere Optionen zum Sichern und Wiederherstellen von Inhalten, die für Websites für die Zusammenarbeit geeignet sind:
Integrierte Sicherungs- und Wiederherstellungstools – Verwenden Sie die zum Lieferumfang von Windows SharePoint Services 3.0 gehörenden Tools, wenn Datenbanken kleiner als 100 GB sind und nicht viele Anpassungen vorliegen oder die Anpassungen in Lösungspaketen vorliegen.
Microsoft SQL Server 2005-Sicherungs-und Wiederherstellungstools – Verwenden Sie diese Tools, wenn Sie über einen SQL-Datenbankadministrator verfügen.
Weitere Informationen finden Sie unter Choose backup and recovery tools (Windows SharePoint Services).
Entwerfen für eine sichere externe Zusammenarbeit
Das Entwurfsbeispielposter enthält eine Übersicht über die Planung der sicheren externen Zusammenarbeit. Dieser Abschnitt enthält den Einführungstext für jedes Element sowie Verknüpfungen zu den entsprechenden Artikeln in der TechNet-Bibliothek.
| Entwurfsempfehlung | Anleitung |
|---|---|
Auswählen einer Extranettopologie |
Schützen Sie Ihre Serverfarm entweder mithilfe einer Edgefirewall oder durch Integrieren der Serverfarm in ein Umkreisnetzwerk. Weitere Informationen finden Sie in den folgenden Artikeln auf der TechNet-Website:
|
Sichern der Client-Server-Kommunikation |
Die sichere Zusammenarbeit in einer Extranetumgebung hängt von der sicheren Kommunikation zwischen Clientcomputern und der Server-/Farmumgebung ab. Verwenden Sie gegebenenfalls SSL (Secure Sockets Layer), um die Kommunikation zwischen Clientcomputern und Servern zu sichern. Weitere Informationen finden Sie in den folgenden Artikeln auf der TechNet-Website: |
Schützen von Back-End-Servern und der Website für die Zentraladministration |
Für eine externe sichere Zusammenarbeit sind mit dem Internet verbundene Server erforderlich. Sie können die Gefährdung aus dem Internet einschränken, indem Sie einen Firewall zwischen Webservern und anderen Servern einrichten und die Website für die Zentraladministration auf einem Back-End-Server hosten. Weitere Informationen finden Sie in den folgenden Artikeln auf der TechNet-Website:
|
Konfigurieren alternativer Zugriffszuordnungen |
Alternative Zugriffszuordnungen unterstützen Internetbereitstellungsszenarien, in denen die URL einer von Internetinformationsdienste (Internet Information Services, IIS) empfangenen Webanforderung nicht der URL entspricht, die vom Endbenutzer eingegeben wurde. Dies tritt häufig in Bereitstellungsszenarien auf, in denen Reverseproxyveröffentlichungen und Lastenausgleich verwendet werden. So können beispielsweise Reverseproxys erweiterte Funktionen ausführen, z. B. eine Webanforderung über SSL (HTTPS) empfangen und diese über HTTP an den Server weiterleiten. Dies wird als "Off-Box-SSL-Beendigung" bezeichnet. Weitere Informationen finden Sie unter Plan alternate access mappings. |
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 Windows SharePoint Services.