Entwerfen der logischen Architektur für Zusammenarbeitswebsites

Inhalt dieses Artikels:

• Informationen zu Teamwebsites innerhalb einer Intranetumgebung

• Entwurfsempfehlungen für Teamwebsites

• Hosten von Teamwebsites in einer dedizierten Webanwendung

• Planen von allgemeinen Einstellungen für Webanwendungen

• Entscheiden, ob Benutzer Websitesammlungen erstellen können

• Entwerfen von Inhaltsdatenbankeinstellungen für Teamwebsites

• Automatisches Löschen von nicht verwendeten Websites

• Organisieren von Teamwebsite-URLs mithilfe von Pfaden

• Planen benutzerdefinierter Elemente

• Planen der Teamwebsites zuzuweisenden Berechtigungen

In Microsoft Office SharePoint Portal Server 2003 besaßen Teamwebsites im Vergleich zu Portalwebsites eine eingeschränkte Funktionalität. Dies ist in Microsoft Office SharePoint Server 2007 nicht der Fall. In Microsoft Office SharePoint Server 2007 können für Zusammenarbeitswebsites innerhalb einer Intranetumgebung dieselben Features wie für veröffentlichte Intranetportalwebsites verwendet werden, wenn die Features in der Intranetumgebung verfügbar gemacht wurden. In diesem Artikel werden solche Websites mit dem früheren Begriff "Teamwebsites" bezeichnet. Allerdings sollten Sie beachten, dass diese Websites, anders als in der früheren Version, hinsichtlich der Features, die sie enthalten können, nicht eingeschränkt sind. Stattdessen impliziert der Begriff "Teamwebsites", dass diese Websites, im Gegensatz zu veröffentlichten und gesteuerten Intranetportalwebsites, von kleineren Gruppen oder für eine stärker ad-hoc-basierte Zusammenarbeit verwendet werden.

Teamwebsites stellen einen wichtigen Bestandteil der meisten Bereitstellungen von Microsoft Office SharePoint Server 2007 dar und sind für Intranetbereitstellungen besonders wichtig. Die durch Teamwebsites ermöglichte Zusammenarbeit und der von diesen gebotene Speicherplatz eignen sich für langfristige und kurzfristige Projekte, Kommunikation und gruppenübergreifende Zusammenarbeit. Wenn Sie Teamwebsites als Teil der Bereitstellung anbieten möchten, sollten Sie diese in den ursprünglichen Architekturentwurf integrieren, sodass Sie das Hosten und die Verwaltung der Websites planen können. Beispielsweise müssen Sie die zum Hosten des Teamwebsiteinhalts erforderlichen Inhaltsdatenbanken planen, die Archivierung und Löschung von Teamwebsites für kurzfristige Projekte planen, um Speicherplatz für weitere Projekte freizugeben, und die Teamkommunikationswebsites überwachen, um sicherzustellen, dass deren Größe Sicherungen und Wiederherstellungen weiterhin zulässt.

Dieser Artikel enthält Empfehlungen zum Entwurf der logischen Architektur für die Bereitstellung von Teamwebsites in einer Serverfarm. Nicht besprochen wird in diesem Artikel die Informationsarchitektur – d. h. die interne Struktur – von Teamwebsites. Informationen zum Entwerfen der Informationsarchitektur finden Sie unter Planen der Websitestruktur und Veröffentlichung (Office SharePoint Server). Weitere Informationen zu Teamwebsites finden Sie unter Planen von Websites für die Zusammenarbeit.

Informationen zu Teamwebsites innerhalb einer Intranetumgebung

In einer Microsoft Office SharePoint Server 2007-Intranetumgebung können Teamwebsites mit Ihrer veröffentlichten Intranetportalwebsite verbunden werden, indem Sie diese im Websiteverzeichnis auflisten. Diese können Sie über das Websiteverzeichnis für die veröffentlichte Website erstellen, sodass für beide derselbe Hostname verwendet wird, Sie können aber auch dem Websiteverzeichnis bereits vorhandene Websites hinzufügen, um alle zueinander gehörenden Teamwebsites an einem Ort zu aggregieren. Unabhängig von den URLs können diese daher als Teil des veröffentlichten Intranetportals angezeigt werden.

Da Teamwebsites SharePoint-Websites darstellen, die dieselben Features wie alle veröffentlichten Websites in Ihrer Umgebung aufweisen, können Sie auch die Business Intelligence, Formulare und anderen Features in Ihrer Umgebung verwenden. Diese Features können sich auf die Architektur für die Teamwebsites auswirken. Wenn Sie beispielsweise auf einer Teamwebsite Geschäftsdaten aus dem Geschäftsdatenkatalog anzeigen müssen, stellen Sie sicher, dass die Mitglieder dieser Teamwebsite über entsprechenden Zugriff zum Anzeigen der Daten verfügen. Business Intelligence-Features und Sicherheit werden auf SSP-Ebene (Shared Services Provider, Anbieter für gemeinsame Dienste) konfiguriert, sodass für alle Teamwebsites, für die Verbindungen mit den gleichen Geschäftsdaten hergestellt werden, derselbe SSP verwendet werden muss, außerdem müssen sie sich in Webanwendungen befinden, die diesem SSP zugeordnet sind.

Weitere Informationen zur Planung von Business Intelligence und Formularen in Ihrer Umgebung finden Sie in die folgenden Ressourcen:

• Planen von Business Intelligence

• Planen von InfoPath Forms Services

Entwurfsempfehlungen für Teamwebsites

In den meisten Organisationen steigt die Anzahl der Teamwebsites und wächst die Größe der einzelnen Teamwebsites, in manchen Fällen ziemlich schnell. Wenn Teams umorganisiert oder Projekte abgeschlossen und neue Projekte gestartet werden, erstellen Teams neue Teamwebsites und geben alte auf, oder sie erweitern die derzeitigen Teamwebsites so, dass diese immer mehr Daten enthalten können. Zum Verwalten oder Steuern dieses Wachstums müssen Sie die Unterstützung der Teamwebsites sorgfältig planen.

Folgende Entwurfsziele gelten für Teamwebsites:

• Optimieren der Leistung der Serverfarm insgesamt

• Erstellen logischer Unterteilungen von Datenbanken für Teamwebsites zur laufenden Wartung (d. h. Sicherung, Wiederherstellung und Upgrade)

• Ermöglichen der Anwendung geeigneter Richtlinien und Einstellungen auf Teamwebsites ohne Auswirkungen auf andere Websitetypen im Intranet

Als Entwurfshinweise für Teamwebsites gelten die folgenden Empfehlungen, die in den folgenden Abschnitten jeweils genauer erläutert werden:

• Hosten Sie Teamwebsites in einer dedizierten Webanwendung.

• Wenden Sie allgemeine Einstellungen für Webanwendungen auf Webanwendungsebene an, z. B. für Kontingente und die Verwaltung des Lebenszyklus. In diesem Fall können Sie die Vergrößerung von Teamwebsites verwalten und Inhalte auf dem aktuellen Stand halten.

• Entwerfen Sie Inhaltsdatenbankeinstellungen für geeigneten Speicherplatz und geeignete Skalierung, um sicherzustellen, dass Sie Datenbanken der Entwurfsgröße sichern und wiederherstellen können.

• Lassen Sie nicht verwendete Websites automatisch löschen

• Organisieren Sie Teamwebsite-URLs mithilfe von Pfaden.

• Planen Sie geeignete Richtlinien und Berechtigungen.

Hosten von Teamwebsites in einer dedizierten Webanwendung

Hosten Sie Teamwebsites in einer dedizierten Webanwendung oder in einer Webanwendung, die auch für Meine Websites verwendet wird. Es wird empfohlen, Teamwebsites nicht in derselben Webanwendung wie eine veröffentlichte Intranetportalwebsite zu hosten. Wenn Sie Teamwebsites von den Intranetportalwebsite getrennt halten, sind Datenwiederherstellung und -wartung leichter möglich. (Wenn Sie die Größe der Inhaltsdatenbanken verwalten, bildet dies ein geringeres Problem.) Die folgende Abbildung zeigt die Webanwendung mit den Teamwebsites für eine Intranetlösung:

Sie können zum Hosten der Teamwebsites mehrere dedizierte Webanwendungen verwenden. Betrachten Sie die folgenden Beispiele:

• In einer Recherchefirma für Investitionsbanking und Firmenkapital in den USA müssen die Websites für die Abteilungen Investitionsbanking und Firmenkapitalrecherche vollständig voneinander isoliert gehalten werden, um die Regulierungen der US-amerikanischen Kontrollkommission für den Wertpapierhandel (U.S. Securities and Exchange Commission) einzuhalten. In diesem Beispiel müssen in der Firma für die beiden Abteilungen zwei Webanwendungen mit isolierten Teamwebsitesammlungen verwendet werden. In der Firma müssen zudem Webanwendungsrichtlinien und separate SSPs verwendet werden, um sicherzustellen, dass Benutzer in den beiden Abteilungen keine Inhalte der jeweils anderen Abteilung anzeigen können.

• Ein Forschungs- und Produktionsunternehmen muss strenge Kontrolle über geistiges Eigentum und Forschungsergebnisse ausüben. In diesem Beispiel können im Unternehmen Forschungsteamwebsites in einer separaten Webanwendung gehostet und Webanwendungsrichtlinien verwendet werden, um Berechtigungen zu erzwingen und sicherzustellen, dass die Inhalte der Forschungsteamwebsites nur vom Forschungspersonal angezeigt werden können.

• In einer Organisation werden interne (Intranet-) und externe (Extranet-)Teamwebsites gehostet. Diese sollen unterschiedlich implementiert und verwaltet werden. In diesem Beispiel werden von der Organisation zwei Webanwendungen zum Hosten der beiden Gruppen von Teamwebsites geplant und implementiert. Daher können bei Bedarf in jeder Umgebung verschiedene Authentifizierungsmethoden, verschiedene Datenbanken und verschiedene IIS-Protokolle verwendet werden. Weitere Informationen zur Planung von Extranets finden Sie unter Entwerfen einer Extranetfarmtopologie (Office SharePoint Server).

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

• Trennen anonymer Inhalte von authentifizierten Inhalten

• Isolieren von Benutzern

• Erzwingen von Berechtigungen

• Optimieren der Leistung

• Optimieren der Verwaltbarkeit

Weitere Informationen zum Entscheiden, ob gemeinsame oder dedizierte Webanwendungen verwendet werden sollen, finden Sie unter Logisches Architekturmodell: Unternehmensbereitstellung.

Überlegungen zur Leistung

Wenn Teamwebsites in einer dedizierten Webanwendung gehostet werden, verfügen Sie über mehrere Inhaltsdatenbanken, die nur Teamwebsitesammlungen enthalten. Wenn in Inhaltsdatenbanken Websites mit ähnlichen Datenmerkmalen gehostet werden, ist die Microsoft SQL Server-Datenbanksoftware effizienter, da von SQL Server ein Abfrageplan ausgewählt wird, der auf den Merkmalen einer Datenbank basiert. Wenn dagegen in einer Datenbank Websites mit stark unterschiedlichen Datenmerkmalen gehostet werden, stellt der von SQL Server ausgewählte Abfrageplan nicht unbedingt die effizienteste Methode für den gesamten Inhalt der Datenbank dar. Wenn in einer Datenbank beispielsweise Teamwebsites (d. h. eine große Anzahl von Websites mittlerer Größe) und Portalwebsites (d. h. eine kleine Anzahl sehr großer Websites mit vielen Anforderungen) gehostet werden, ist der ausgewählte Abfrageplan für einen der Websitetypen ineffizient. Daher können Sie durch Platzieren von Inhalten für Teamwebsites in dedizierten Datenbanken die Leistung von SQL Server optimieren, was zu einer besseren Leistung der gesamten Serverfarm führt.

Überlegungen zur Verwaltbarkeit

Durch Hosten von Teamwebsites in einer dedizierten Webanwendung können Sie die Verwaltbarkeit auf folgende Weise verbessern:

• Die folgenden Elemente können separat verwaltet werden:

  • Datenbankeinstellungen

  • Kontingentvorlagen

  • Papierkorbeinstellungen

  • Automatisierte Aktionen für nicht verwendete Websites

  • Authentifizierung

  • Richtlinien

• Sie können die Vergrößerung von Teamwebsites effektiver verwalten, indem Sie Teamwebsites getrennt von anderen Websitetypen verwalten.

• Sie erstellen eine Möglichkeit, eine bestimmte Servicelevelvereinbarung auszuhandeln. Beispielsweise könnten Sie zusammen mit der Servicelevelvereinbarung zum wöchentlichen Speichern vollständiger Sicherungen und täglicher differenzieller Sicherungen der Inhaltsdatenbanken mithilfe des endgültigen Papierkorbs auch eine kürzere Verarbeitungszeit für die Wiederherstellung einzelner Inhaltselemente anbieten.

Auswählen eines Anwendungspools

In einer Unternehmensumgebung kann für Teamwebsites derselbe Anwendungspool wie für Webanwendungen verwendet werden, wenn diese ähnliche Anforderungen an Zusammenarbeit und Isolierung aufweisen. Beispielsweise kann für Teamwebsites derselbe Anwendungspool wie für Meine Websites verwendet werden, da beide für die Zusammenarbeit zum Speichern von Informationen und Dokumenten verwendet werden. Zudem werden ihnen zu Isolierungszwecken meist ähnliche Bereiche zugewiesen (d. h., beide sind für die gesamte Organisation verfügbar).

Im Allgemeinen ist ein dedizierter Anwendungspool erforderlich, wenn Sie folgende Aktionen ausführen müssen:

• 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

Weitere Informationen zu den Fällen, in denen dedizierte Anwendungspools verwendet werden sollten, finden Sie unter Logisches Architekturmodell: Unternehmensbereitstellung.

In einer Hostumgebung, in der Inhalte für mehrere Unternehmen in einer einzigen Serverfarm gehostet werden, wird empfohlen, den gesamten Inhalt für ein einzelnes Unternehmen in demselben Anwendungspool hosten. Auf diese Weise erzielen Sie eine bessere Skalierbarkeit (mit weniger Anwendungspools, da weniger Prozesse ausgeführt werden) sowie eine Prozessisolierung zwischen den Anwendungspools (sodass beim Anhalten des Anwendungspools für Kunde A die Websites von Kunde B nicht beeinflusst werden). Dies hängt auch von der Anzahl der Organisationen sowie von der empfohlenen Leistungsplanung und den Isolierungsanforderungen ab.

Planen von allgemeinen Einstellungen für Webanwendungen

Auf der Seite Allgemeine Webanwendungseinstellungen stehen verschiedene Einstellungen zur Verfügung, mit denen Sie das Wachstum von Daten sowie des aktuellen Inhalts von Teamwebsites in der Umgebung verwalten können. Diese Einstellungen gelten für alle Websites innerhalb einer Webanwendung. Planen Sie mindestens die Implementierung der folgenden Einstellungen, die jeweils weiter unten in diesem Abschnitt erläutert werden:

• Definieren Sie eine Kontingentvorlage, um die maximale Größe von Teamwebsites einzuschränken, und wenden Sie diese an.

• Richten Sie eine maximale Uploadgröße ein. Wählen Sie je nach Geschäftsanforderungen einen großzügigen Wert aus, sodass Benutzer problemlos zusammenarbeiten können.

• Aktivieren Sie die Papierkörbe für Websites, und verwenden Sie den endgültigen Papierkorb.

Zusätzlich zu den bereits aufgeführten Einstellungen sollten Sie alle Featureeinstellungen auf der Seite Allgemeine Webanwendungseinstellungen auswerten, um sicherzustellen, dass die Features für die Teamwebsites in Ihrer Organisation geeignet sind. In der Standardeinstellung sind die folgenden Features aktiviert:

• Smarttag und Onlinestatus für Personennamen (Onlineanwesenheitsinformationen werden angezeigt)

• Benachrichtigungen (Benutzer können in der Standardeinstellung maximal 500 Benachrichtigungen erstellen)

• RSS-Feeds (Really Simple Syndication)

• Anwendungsprogrammierungsschnittstelle (Application Programming Interface, API) für Blogs (Verknüpfung zum Erstellen eines Blogs)

Festlegen der Kontingentvorlageneinstellungen

Für Teamwebsites in einer Microsoft Office SharePoint Server 2007-Umgebung ist keine Standardvorlage für Kontingente verfügbar. Die folgenden Einstellungen werden jedoch als Ausgangspunkt empfohlen:

• Wenn die Größe einer Website 450 MB erreicht, wird an den Websitebesitzer eine automatisierte E-Mail-Nachricht gesendet.

• Wenn die Größe einer Website 500 MB erreicht, werden Benutzer am Hochladen weiterer Dokumente gehindert.

Diese Einstellungen können für Ihre Organisation gut geeignet sein, jedoch sollten Sie die zu erwartende Größe und Anzahl der von Benutzern auf Teamwebsites gespeicherten Elemente auswerten und diese Einstellungen nach Bedarf anpassen, um sicherzustellen, dass Teamwebsites wie beabsichtigt in der Organisation verwendet werden.

Wenn in Ihrer Organisation beispielsweise Forschungs- oder Entwurfsteams tätig sind, bei deren Zusammenarbeit ein hohes Inhaltsvolumen erzeugt wird, das gespeichert und archiviert werden muss, erwägen Sie, die Kontingenteinschränkungen zu erhöhen. Beispielsweise können Sie die Größenbeschränkung auf 5 oder 10 GB erhöhen. In solchen Szenarien wird durch Hosten des Inhalts auf Teamwebsites sichergestellt, dass der Inhalt regelmäßig gesichert wird und dass dies allen beitragenden Personen möglich ist. Sie können auch eine Websitesammlung mit 5 bis 10 GB Größe in einer eigenen Inhaltsdatenbank platzieren, insbesondere, wenn Sie ein schnelles Wachstum dieser Websitesammlung erwarten.

Wenn die Teamwebsites andererseits hauptsächlich für kurzfristige Projekte oder Kommunikationsteamwebsites verwendet werden, sollten Sie eine niedrigere Kontingentbegrenzung verwenden. In diesem Fall speichern die Teams meist nur die Informationen, die für den Fortschritt kurzfristiger Projekte erforderlich sind (der Wert sollte jedoch nicht zu niedrig festgelegt werden, andernfalls riskieren Sie gesteigerte Kosten im Zusammenhang mit Helpdeskanforderungen zur Erhöhung der Kontingente). In diesem Szenario wird gefördert, dass Teams allgemeine Teaminhalte oder Inhalte für ein neues Projekt auf separaten Teamwebsites speichern.

Wenn ein bestimmtes Team oder eine bestimmte Gruppe in der Organisation aus geschäftlichen Gründen ein größeres Inhaltsvolumen auf den Teamwebsites speichern muss, können Sie die Kontingentgrenzen für eine einzelne Websitesammlung anpassen. Wählen Sie zum Anpassen der Kontingentbeschränkungen auf der Seite Kontingente und Sperren für Websitesammlungen die Websitesammlung für das Team oder die Gruppe aus. Ändern Sie die aktuelle Kontingentvorlage in Persönliches Kontingent, und geben Sie dann die entsprechende Begrenzung an.

Beim Planen von Kontingentvorlagen wählen Sie Beschränkungen aus, die für die meisten Teamwebsites in der Organisation geeignet sind. Zur Verbesserung der Verwaltbarkeit passen Sie Kontingente für einzelne Benutzer nur an, wenn dies zum Erfüllen einer Geschäftsanforderung notwendig ist.

Bestimmen der maximalen Uploadgröße

Die maximale Standardgröße für Uploads beträgt 50 MB. 50 MB stellt eine großzügige Einschränkung dar, mit der Benutzer genügend Flexibilität erhalten, um zahlreiche Typen und Größen von Dokumenten hochladen zu können, ohne dass sich dies auf die Leistung negativ auswirkt. Wenn Benutzer in der Organisation größere Dateien auf den Teamwebsites speichern müssen, können Sie diese Einstellung anpassen. Überwachen Sie unbedingt die IIS-Zeitlimiteinstellungen, wenn Benutzer über langsamere Verbindungen verfügen.

Festlegen der Papierkorbeinstellungen

Das Aktivieren des Papierkorbs bildet eine einfache Möglichkeit zur Verbesserung der Verwaltbarkeit von Teamwebsites. Der Papierkorb ermöglicht es Websitebesitzern, gelöschte Elemente abzurufen, ohne dass über die Zentraladministration eingegriffen werden muss (d. h., Wiederherstellen von Sicherungsbändern).

In der folgenden Liste sind die Standardeinstellungen für den Papierkorb beschrieben, die für die meisten Organisationen geeignet sind:

• Status des Papierkorbs: Aktiviert

• Elemente aus dem Papierkorb löschen: Nach 30 Tagen

• Endgültiger Papierkorb: 50 Prozent des Live-Websitekontingents endgültig gelöschter Elemente

Im endgültigen Papierkorb werden Elemente gespeichert, die Benutzer im Papierkorb gelöscht haben. Nur Websitesammlungsadministratoren können Elemente im endgültigen Papierkorb wiederherstellen. Durch die für den endgültigen Papierkorb angegebene Größe wird die Gesamtgröße der Teamwebsite erhöht. Wenn die Beschränkung der Teamwebsite beispielsweise bei 500 MB liegt und der endgültige Papierkorb auf 50 Prozent festgelegt ist, kann der von der Website eingenommene Speicherplatz 750 MB betragen. Planen Sie die Datenbankkapazität daher entsprechend.

Wie beim Papierkorb werden Elemente im endgültigen Papierkorb automatisch gelöscht, wenn der Zeitraum für gelöschte Elemente (in der Standardeinstellung 30 Tage) erreicht wurde. Wenn jedoch die Größenbeschränkung des endgültigen Papierkorbs erreicht ist, werden Elemente im endgültigen Papierkorb automatisch gelöscht. Dabei wird mit dem ältesten Element begonnen. Websitesammlungsadministratoren können den endgültigen Papierkorb auch manuell leeren.

Die Verwendung des endgültigen Papierkorbs und die Menge des zu reservierenden Speicherplatzes bilden wichtige Überlegungen für die Verwendung des Features Papierkorb. Sie sollten zumindest eine kleine Menge Speicherplatz (z. B. 10 %) für den endgültigen Papierkorb reservieren, für den Fall, dass ein Benutzer ein wichtiges Dokument, einen Ordner in einer Dokumentbibliothek oder eine Spalte in einer Liste versehentlich gelöscht hat.

Planen der Methode zum Erstellen von Websites

Sie können entscheiden, ob Websitesammlungen für die Teamwebsites zentral erstellt werden oder Benutzer mithilfe der Self-Service-Site-Verwaltung eigene Websitesammlungen erstellen können. Beide Verfahrensweisen bieten Vor- und Nachteile.

Wenn Sie Teams das Erstellen von Websitesammlungen über die Self-Service-Site-Verwaltung ermöglichen, können Teams problemlos nach Bedarf und ohne Unterstützung von einem Administrator Websites erstellen. Dieser Ansatz bietet jedoch zahlreiche Nachteile, u. a. die folgenden:

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

Wenn Sie stattdessen Websitesammlungen je nach Organisationsstruktur zentral erstellen, erhalten Sie die Möglichkeit, eine durchdachte Taxonomie zu implementieren, mit der der Verwaltung und Vergrößerung von Teamwebsites eine Struktur gegeben wird. Zudem stehen mehr Möglichkeiten zur Verfügung, Vorlagen und Navigation für Projekte und Teams freizugeben, für die eine gemeinsame Websitesammlung verwendet wird. Bei diesem Ansatz können Teams nach dem Erstellen der anfänglichen Websitesammlung nach Bedarf Websites innerhalb der eigenen Websitesammlung erstellen. Allerdings werden jedes Mal IT-Ressourcen beansprucht, wenn ein Benutzer eine Website erstellen möchte.

Beispiele zum Verwenden der einzelnen Methoden finden Sie unter Logisches Architekturmodell: Unternehmensbereitstellung. Weitere Informationen zum Planen der Websiteerstellung finden Sie unter Planen des Prozesses zum Erstellen von Websites (Office SharePoint Server).

Wenn in Ihrer Organisation entschieden wurde, Websitesammlungen für Teamwebsites zu erstellen und es Benutzern nicht zu ermöglichen, eigene Websitesammlungen zu erstellen, legen Sie auf dem Arbeitsblatt "Websitepfade" (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=73149&clcid=0x407), die Ebene fest, auf der die Teamwebsites erstellt werden: Stammwebsites in eigenen Websitesammlungen oder eine große Websitesammlung mit mehreren Unterwebsites. Weitere Informationen zum Bestimmen, ob viele Websitesammlungen oder aber nur wenige Websitesammlungen mit vielen Unterwebsites erstellt werden sollen, finden Sie in der technischen Bibliothek zu Windows SharePoint Services 3.0 im Artikel Determine sites and subsites needed [Windows SharePoint Services] im Abschnitt über das Entscheiden, ob einzelne Websitesammlungen oder Unterwebsites in einer Websitesammlung verwendet werden. Weitere Informationen zu den in Microsoft Office SharePoint Server 2007 verfügbaren Websitetypen finden Sie unter Bestimmen von Websites und Unterwebsites.

Entwerfen von Inhaltsdatenbankeinstellungen für Teamwebsites

Im Logisches Architekturmodell: Unternehmensbereitstellung werden Teamwebsites in dedizierten Datenbanken gespeichert, in jeweils einer für jede Websitesammlung. Bei dieser Methode können Sie jede Websitesammlungs-Datenbank hinsichtlich Sicherung, Wiederherstellung und Migration unabhängig verwalten. Wenn ein Projekt abgeschlossen ist, können Sie zudem die Datenbank für das Projekt problemlos archivieren. Zwar erstellen Sie bei diesem Ansatz zahlreiche Datenbanken, doch erhalten Sie die Fähigkeit zum Steuern der einzelnen Datenbanken für jede Websitesammlung.

Beachten Sie jedoch, dass die Leistung von SQL Server von der Anzahl der Datenbanken pro SQL Server-Instanz beeinflusst wird. Anders gesagt, wenn Sie 300 Teamwebsitesammlungen oder mehr planen, kann bei Speicherung jeder einzelnen in einer dedizierten Datenbank die Leistung von SQL Server beeinträchtigt werden. Die Ursache dafür besteht darin, dass jede Datenbank eine Verbindung zwischen dem Anwendungspool und SQL Server darstellt. Beim Hinzufügen von Webservern und Datenbanken wird die Anzahl aktiver Verbindungen erhöht. Wenn Sie zu viele Verbindungen hinzufügen, reagiert SQL Server möglicherweise nicht mehr.

Wenn Sie mehr als 300 Teamwebsitesammlungen planen, sollten Sie keine dedizierten Datenbanken verwenden. Stattdessen sollten Sie in jeder Datenbank mehrere Websitesammlungen speichern. Beachten Sie, dass 300 Datenbanken die in der IT-Abteilung von Microsoft verwendete Anzahl darstellt. Beachten Sie auch, dass 300 Datenbanken keinen Grenzwert für Fehler bilden, sondern eine Schätzung auf der Grundlage von SharePoint Portal Server 2003:-Daten, wobei 300 Datenbanken für Microsoft IT einen vertrauenswürdigen Wert für die Anzahl der Websitesammlungen bildeten, die problemlos auf jedem Server gehostet werden konnten. Die Anzahl hängt von verschiedenen Parametern ab, u. a. von der Anzahl der Datenbanken. Beispielsweise kann der Sinn der Verwendung dedizierter Datenbanken auch von folgenden Faktoren abhängen:

• Gelten für die Teams unterschiedliche Servicelevelvereinbarungen (z. B. unterschiedliche Sicherungsanforderungen)?

• Benötigen die Teams mehr als 8 GB Speicherplatz?

• Verfügen die Teams über unterschiedliche Projektzeitpläne? Wenn Sie Teams mit kurzfristigen Projekten und Teams mit langfristigen Projekten mischen, wird die Archivierung von Websites und das Verschieben der Websites aus der Produktionsumgebung möglicherweise erschwert, wenn für diese dieselbe Datenbank verwendet wird.

• Erwarten die Teams ein hohes Maß an Autonomie und Unabhängigkeit für Vorgänge auf Datenbankebene?

Wenn Sie eine der oben genannten Fragen mit "Ja" beantworten, sollten Sie die Verwendung dedizierter Datenbanken für Websitesammlungen erwägen.

Wenn Sie in jeder Datenbank mehrere Websitesammlungen speichern möchten, können Sie die Anzahl der in den einzelnen Datenbanken zu speichernden Websitesammlungen berechnen, indem Sie die maximale Größe jeder Datenbank und die maximale Größe jeder Websitesammlung ermitteln (basierend auf dem Wert der Speicherbegrenzung für die Kontingentvorlage plus zugewiesenem Papierkorb). Beachten Sie, dass selbst bei Kontingentzuweisung von jeweils 500 MB nicht alle das vollständige Kontingent verwenden, sodass Sie möglicherweise zu viele Inhaltsdatenbanken erstellen. Verwenden Sie die Kontingentschätzungen als Aspekt bei der Datenbankplanung, doch verfolgen Sie die wirkliche Auslastung, und nehmen Sie entsprechende Anpassungen vor. Wenn Sie zuvor eine Umgebung mit SharePoint Portal Server 2003: oder Windows SharePoint Services 2.0 verwendet haben, können Sie auch die Größe dieser Websitesammlungen als Ausgangspunkt verwenden und die Datenbanken auf der Grundlage der tatsächlichen Größe der Websitesammlungen und nicht der Kontingentschätzungen erstellen.

In einer verwalteten Umgebung werden Größenbeschränkungen für Datenbanken häufig durch die folgenden beiden Faktoren bestimmt:

• Zeitaufwand für das Sichern einer Datenbank. Ab einer bestimmten Datenbankgröße sind Sicherungsvorgänge ineffizient, erfordern mehr Zeit als praktisch ist und werden für andere Unterbrechungen anfällig. Ab diesem Punkt sollten Sie sich möglicherweise entscheiden, der Umgebung weitere Datenbankserver hinzuzufügen.

• Das Dienstfenster (d. h. der Zeitraum) zum Wiederherstellen für Inhalt, wie in der Vereinbarung zum Servicelevel festgelegt. Wenn das Dienstfenster zum Wiederherstellen von Inhalt beispielsweise vier Stunden beträgt, ist die Größe der Datenbank auf einen Umfang beschränkt, der innerhalb dieser Zeitspanne wiederhergestellt werden kann.

Bestimmen Sie die maximale verwaltbare Datenbankgröße für Teamwebsitesammlungen anhand der Werte in der folgenden Tabelle.

Die maximale verwaltbare Datenbankgröße Ihrer Organisation ist der kleinere der beiden angegebenen Werte für den Inhaltsumfang (B und D).

Nach dem Bestimmen der Zielgröße für Inhaltsdatenbanken können Sie die Anzahl der Websitesammlungen berechnen, die pro Datenbank unterstützt werden können. Die folgende Tabelle veranschaulicht die Anzahl der Websitesammlungen pro Datenbank anhand der Datenbankgröße und der Größenbeschränkungen für Websitesammlungen. In die Größenbeschränkungen der Websitesammlungen ist der Speicherplatz für den endgültigen Papierkorb eingerechnet.

Ändern Sie beim Erstellen der Webanwendung für Teamwebsites die Einstellungen auf der Seite Inhaltsdatenbanken verwalten für die erste Inhaltsdatenbank so, dass die maximale Anzahl der Websitesammlungen dem Größenziel für die Datenbank und den Größenbeschränkungen für die Websitesammlungen entspricht (Maximale Anzahl Websites). Geben Sie auch den Schwellenwert für die Anzahl von Websites an, bei dem eine Warnung verursacht wird (Websiteanzahlwarnung). Erstellen Sie eine neue Datenbank mit denselben Einstellungen, wenn der Wert für die Warnung erreicht ist. Wenn die maximale Anzahl von Websitesammlungen erreicht wird, werden keine neue Websitesammlungen in der Datenbank erstellt. Wenn keine weitere Datenbank erstellt wurde, tritt beim Erstellen einer Website ein Fehler auf.

Automatisches Löschen von nicht verwendeten Websites

Sie können die Aktualität von Inhalten auf Teamwebsites erhöhen, indem Sie nicht verwendete Websites automatisch löschen. Auf diese Weise können Sie auch die Gesamtvergrößerung der Teamwebsites besser steuern. Wenn Teamwebsites in einer separaten Webanwendung gehostet werden, können Sie nicht verwendete Teamwebsites anders als persönliche Websites verwalten, z. B. indem Sie diesen eine längere Lebensdauer zuweisen, bevor Sie mit dem Abfragen nicht verwendeter Websites beginnen.

In der Standardeinstellung sind die Einstellungen für das automatische Löschen von Websites nicht aktiviert. Klicken Sie zum Verwalten der Einstellungen für das Löschen von Websites auf der Seite Anwendungsverwaltung im Abschnitt SharePoint-Websiteverwaltung auf Bestätigung der Websiteverwendung und Löschung.

Wenn Sie dieses Feature aktivieren, lauten die Standardeinstellungen wie folgt:

• E-Mail-Benachrichtigungen werden an Besitzer von Websitesammlungen 90 Tage nach Erstellung der Websitesammlung gesendet, oder es wird die Verwendung bestätigt. Wenn also eine Website nach 90 Tagen nicht als in Verwendung bestätigt wurde, erhält der Websitebesitzer eine Benachrichtigung.

• Vom System wird auf nicht bestätigte Websitesammlungen überprüft, und täglich um Mitternacht werden Mitteilungen gesendet.

• Die Option zum automatischen Löschen nicht bestätigter Websitesammlungen ist nicht aktiviert. Wenn diese Einstellung aktiviert ist, werden Websites automatisch gelöscht, nachdem 28 Mitteilungen gesendet wurden. Sie können die Anzahl der Mitteilungen auch angeben.

Bei Verwendung der Standardeinstellungen wird eine Websitesammlung, die 90 Tage lang nicht verwendet wurde, nach 28 Mitteilungen oder 118 Tage nach der letzten Bestätigung der Website gelöscht. Sie können die Einstellungen angeben, die für Ihre Organisation am besten geeignet sind. Da dieses Feature auf Bestätigungen und nicht auf der Verfolgung der tatsächlichen Websiteverwendung beruht, müssen Sie unerwartete Abwesenheiten von Websitebesitzern einplanen und dürfen die Ablauf- und Löschfristen für Websites nicht auf kurze Zeiträume festlegen. Darüber hinaus sollten Sie immer mehrere Websitesammlungsadministratoren beschäftigen, sodass ein Reserveadministrator die Verwendung der Website bestätigen kann, wenn der primäre Websitesammlungsadministrator für einen längeren Zeitraum abwesend ist.

Durch automatisches Löschen von Websites können Sie Ihre Umgebung steuern, jedoch besteht die Gefahr, dass unternehmenswichtige Daten auf einer Website gespeichert wurden, die automatisch gelöscht wurde. Zur Verringerung dieses Risikos wird Folgendes empfohlen:

• Legen Sie einen sekundären Kontakt für alle Websites als erforderlich fest. Dadurch ist zum Bestätigen der Websiteverwendung weiterhin ein Kontakt verfügbar, wenn der Websitebesitzer nicht verfügbar ist oder die Organisation verlassen hat. Wenn Sie keinen sekundären Kontakt festgelegt haben und die Anzahl der Tage oder Hinweise vor dem Löschen einer nicht verwendeten Website verkleinern, besteht die Gefahr, dass eine benötigte Website versehentlich gelöscht wird. Implementieren Sie diese Empfehlung, wenn Sie die Self-Service-Site-Verwaltung aktivieren, oder als Geschäftsprozess zum Erstellen von Websitesammlungen in der Zentraladministration.

• Archivieren Sie Websites, bevor diese automatisch gelöscht werden. In vielen Organisationen, in der die automatische Löschung nicht verwendeter Websites implementiert ist, wird auch in die Entwicklung eines Tools investiert, mit dem alle Websites archiviert werden, bevor diese automatisch gelöscht werden, sodass sie wiederhergestellt werden können, wenn sie unternehmenswichtige Informationen enthalten. Sie können auch das langfristige Speichern von Inhaltsdatenbanken für den Fall planen, dass eine gelöschte Website zu einem späteren Zeitpunkt wiederhergestellt werden muss.

Organisieren von Teamwebsite-URLs mithilfe von Pfaden oder Hostnamen

Je nach Ihrer Organisation und der jeweiligen Verwendung von Teamwebsites sollten Sie die Verwendung von Pfaden zum Organisieren der URLs für die Teamwebsites in Betracht ziehen. Wenn Sie beispielsweise für die Teamwebsites der verschiedenen Abteilungen verschiedene URLs verwenden möchten, können Sie URLs der folgenden Formate verwenden: http://Firmenname/Abteilungsname /sites oder http://Firmenname/research/sites. Auf ähnliche Weise können Sie die Zuordnung zu einer veröffentlichten Intranetwebsite verdeutlichen, indem Sie http://Intranetname/teamsites verwenden. Bei Verwendung der Self-Service-Site-Verwaltung lautet die Standard-URL für Teamwebsites http://Servername/sites, Sie können jedoch auch für http://Servername/team oder für das von Ihnen für Teamwebsites bevorzugte Präfix eine Platzhalterinklusion erstellen.

Weitere Informationen zu Pfaden finden Sie in den folgenden Ressourcen:

• Planen von Websites für die Zusammenarbeit

• Bestimmen von Websites und Unterwebsites

• "Verwenden von expliziten Inklusionen und Platzhalterinklusionen für URL-Pfade" in Logisches Architekturmodell: Unternehmensbereitstellung

• Erstellen von Lösungen mit freigegebenen Hostservern mithilfe von Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=86128&clcid=0x407)

Sie können auch Websites mit Hostnamen erstellen, wenn Sie über Teamwebsites verfügen, die eine wichtige Rolle in der Organisation spielen. Wenn beispielsweise die Website der Personalabteilung eine Teamwebsite darstellt, die nicht Teil der veröffentlichten Intranetwebsite ist, können Sie eine Teamwebsite mit einem Hostnamen für die Website http://hrsite oder http://humanresources erstellen.

Planen benutzerdefinierter Elemente

Durch Anpassungen kann die Komplexität der Umgebung gesteigert werden, insbesondere, wenn Sie alle Lösungspacks mehrmals testen möchten: bevor Sie diese bereitstellen, wenn Sie ein Update anwenden möchten und wenn Sie die Umgebung aktualisieren möchten. Sie sollten die Richtlinie Ihrer Organisation bezüglich der Verwendung benutzerdefinierter Features, Vorlagen, Webparts usw. festlegen. Planen Sie zudem die Verwaltbarkeit, Supportfähigkeit und Verwendbarkeit dieser Elemente in der Umgebung.

• Verwaltbarkeit Wenn Sie die gesamte Umgebung sichern und wiederherstellen müssen (z. B. beim Szenario einer Notfallwiederherstellung oder beim Verschieben von Hardware), benötigen Sie Sicherungen für alle benutzerdefinierten Elemente (z. B. für Ihre Umgebung entwickelte benutzerdefinierte Webparts oder eine benutzerdefinierte Websitedefinition). Beachten Sie, dass Sie diese beim Wiederherstellen der Umgebung wieder hinzuzufügen müssen. Der Grund dafür besteht darin, dass Sie die Konfigurationsdatenbank mit sämtlichen Verweisen auf diese benutzerdefinierten Elemente nicht wiederherstellen können. Daher müssen Sie sie der wiederhergestellten Umgebung erneut hinzufügen. Beispielsweise müssen Sie die benutzerdefinierten Websitedefinitionen erneut hinzufügen und die benutzerdefinierten Webparts installieren. Wenn Sie ein benutzerdefiniertes Element vergessen, wenn Sie einen Verschiebevorgang auf einen neuen Server vornehmen oder einen Server wiederherstellen, können Sie Fehler in den Teamwebsites der Benutzer verursachen, sodass Sie den benötigten Code suchen müssen, während die Benutzer warten.

• Problembehandlung Bei aufgetretenen Problemen können benutzerdefinierte Elemente in der Umgebung zu verlängerten Problembehandlungszeiten führen. Jeder benutzerdefinierte Codeabschnitt ist eindeutig, kann komplex oder einfach sein sowie zusätzlichen Arbeitsspeicher beanspruchen. Planen Sie die Anzahl der Stellen, an denen benutzerdefinierter Code verwendet wird, und welche Auswirkungen dieser auf das System zeitigt. Überlegen Sie bei der Problembehandlung auch, wie Sie die Anpassungen als Teil der eigentlichen Ursache eines Problems ausschließen können. Wenn Sie den benutzerdefinierten Code selbst erstellen, sollten Sie diesen so entwerfen, dass etwaige durch die Anpassungen verursachte Fehler im Ereignisprotokoll (bei MOM-Ereignissen (Microsoft Operations Manager))und an einem beliebigen anderen in der Organisation für die Problembehandlung verwendeten Speicherort protokolliert werden, sodass Sie die Fehler behandeln können.

• Verwendbarkeit Treffen Sie Überlegungen zur Verwendbarkeit Ihrer Lösungen, Webparts und Vorlagen. Wenn Sie über so viele benutzerdefinierte Vorlagen für Teamwebsites in der Umgebung verfügen, dass zum Anzeigen der Liste von Vorlagen oder Webparts ein Bildlauf über mehrere Bildschirme erforderlich ist (z. B. sind 50 zu viele, um gelesen und unterschieden zu werden), sollten Sie erwägen, ob Sie alle benutzerdefinierten Elemente benötigen, ob Sie die Liste in einer bestimmten Weise aufteilen können oder ob Sie diese in allgemeinen Feature Packs zusammenfassen können, um die Navigation und Nachverfolgung zu erleichtern.

In einigen Organisationen werden mehrere Richtlinien zu Anpassungen festgelegt. Beispielsweise kann ein zweistufiges oder dreistufiges System ausgewählt werden, wobei Stufe 1 einfache Websites (nur mit Standardvorlagen) umfasst, auf Ebene 2 einige Anpassungen möglich sind (mit einer anderen Servicelevelvereinbarung) und auf Ebene 3 die Hardware von der Organisation gehostet wird, während das Team, das Besitzer der Teamwebsites ist, für das Ausführen und Verwalten der eigenen angepassten Umgebung auf dieser Hardware verantwortlich ist. Dies ist einer weiterer Fall, in dem Teamwebsites von mehreren Webanwendungen gehostet werden können, wobei für jede Webanwendung eine andere Servicelevelvereinbarung gilt.

Planen der Teamwebsites zuzuweisenden Berechtigungen

Mit den auf Teamwebsites angewendeten Berechtigungen und Richtlinien bestimmen Sie Folgendes:

• Die Personen, die Teamwebsites erstellen können

• Die Personen, die Teamwebsites anzeigen und zu diesen Websites beitragen können

• Die Personen, denen der Zugriff auf Inhalte von Teamwebsites verweigert wird

Es wird empfohlen, dass Sie zum Verwalten von Berechtigungen Sicherheitsgruppen verwenden. Die folgenden Tabelle enthält eine Anleitung zur Konfiguration von Berechtigungen und gibt an, wo Berechtigungen konfiguriert sind.

Herunterladen dieses Buchs

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

• Planung und Architektur für Office SharePoint Server 2007, Teil 2 (in englischer Sprache)

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