• Artikel

Einblicke in SharePointErstellen einer SharePoint-Infrastruktur

Pav Cherny

Laden Sie den Code für diesen Artikel herunter: SharePoint2008_05.exe (412KB)

Genau wie E-Mail-Nachrichten die Geschäftskommunikation revolutioniert haben, ändert die webbasierte Zusammenarbeit die Art, wie Menschen zusammenarbeiten und Informationen freigeben. Sehen Sie sich zum Beispiel an, was die SharePoint-Technologie bietet. Mit Microsoft Windows SharePoint Services (WSS) 3.0 und Microsoft Office SharePoint Server

(MOSS) 2007 können Sie Teamwebsites, Portale, Lösungen für das Verwalten von Webinhalten, Dokumentbibliotheken und Suchcenters erstellen, ganz zu schweigen von der 2007 Microsoft® Office System-Integration, den XML-basierten Formularen, Workflows, der Mobilitätsunterstützung und so weiter.

Die ersten Schritte mit SharePoint® sind jedoch nicht immer einfach. Die Terminologie ist möglicherweise verwirrend. Die Systemarchitektur kann komplex sein, und SharePoint erfordert, dass Sie mit mehreren Komponenten arbeiten, einschließlich IIS, Microsoft .NET Framework, SQL Server® und vielleicht anderen Technologien wie Business Intelligence, InfoPath® Forms Services, Rights Management Services (RMS), Exchange Server und ForefrontTM Security.

Angesichts der vielen Verfahren, mit denen sich SharePoint-Lösungen über die integrierte Benutzeroberfläche oder programmgesteuert erstellen lassen, können Sie bei Integration und Anpassung schnell die Orientierung verlieren. Hinzu kommt, dass die Problembehandlung kompliziert werden kann, wenn eine SharePoint-Anwendung nicht funktioniert. Oftmals müssen Sie die Denkweise eines Anwendungsentwicklers annehmen, um die beteiligten Komponenten und ihre Interaktionsweise zu verstehen. Wie können Sie angesichts all dieser Herausforderungen eine stabile, skalierbare und überschaubare SharePoint-Infrastruktur erstellen?

In diesem Artikel erfahren Sie, wie Sie den Einstieg am besten bewältigen: Zunächst wird in einer allgemeinen Architekturabhandlung eine Grundlage erarbeitet, dann erhalten Sie einen tieferen Einblick in die Bereitstellung von WSS, einschließlich grundlegender Brandinganpassungen Mithilfe der Self-Service Site-Verwaltung von WSS 3.0 werden Sie feststellen, wie Sie Berechtigungen für das Erstellen und Verwalten von SharePoint-Websites auf einzelne Benutzer delegieren, während Sie die zentrale administrative Kontrolle über die SharePoint-Infrastruktur beibehalten.

Durch eine anfängliche genauere Untersuchung der SharePoint-Architektur können Sie einfacher verstehen, welche Bereitstellungs- und Konfigurationsschritte erforderlich sind, um eine flexible und skalierbare Infrastruktur zu implementieren. Im Folgenden wird zunächst der Bereich Abhängigkeiten näher beleuchtet, anschließend geht es dann direkt um die Bereitstellung von WSS 3.0. Ausführliche Bereitstellungsanweisungen finden Sie im Begleitreferenzmaterial. Sie können das Referenzmaterial im Downloadbereich auf der Website des TechNet Magazins unter technetmagazine.com herunterladen.

SharePoint-Architektur

Bei SharePoint ist es hilfreich, die Technologie vom Standpunkt eines Systemarchitekten zu betrachten. Allerkleinste Details brauchen Sie nicht zu kennen, doch wenn Sie mit den allgemeinen Abhängigkeiten vertraut sind, die sich aus der SharePoint-Architektur ergeben, können Sie schneller mit Lösungen aufwarten, weil Sie voraussehen können, was konfiguriert werden muss und aus welchem Grund.

SharePoint ist eine Technologie zum Bereitstellen von Webanwendungen und Websites. Es handelt sich um eine auf IIS basierte Websitelösung, die durch ASP.NET in IIS integriert ist und auf einem SQL Server-Datenbank-Back-End für das Speichern von Konfigurationsdaten und -inhalten beruht. Kurz gesagt besteht SharePoint im Wesentlichen aus einer Kombination von drei verschiedenen Architekturen (IIS, .NET und SQL Server), wie in Abbildung 1 dargestellt.

Abbildung 1 Auf IIS 6.0 und ASP.NET 3.0 basierte WSS 3.0-Architektur

Abbildung 1** Auf IIS 6.0 und ASP.NET 3.0 basierte WSS 3.0-Architektur **(Klicken Sie zum Vergrößern auf das Bild)

Lassen Sie sich durch dieses Diagramm nicht abschrecken. Die Architektur sieht anfangs angesichts der großen Anzahl von Komponenten womöglich gigantisch aus. Doch all diese Komponenten passen in ein logisches Framework, das bei einer systematischen Untersuchung einen Einblick in die Komponentenabhängigkeiten vermittelt.

Wie dargestellt, verlässt sich SharePoint bei der Behandlung von HTTP-Anforderungen und -Antworten auf IIS und ASP.NET. Standard-IIS-Komponenten, z. B. der HTTP-Kernelmodustreiber (http.sys) und der Arbeitsprozess (w3wp.exe), führen das anfängliche Einreihen in die Warteschlange und das Weiterleiten von Anforderungen durch, bis sie am ASP.NET-ISAPI-Filter (aspnet_isapi.dll) ankommen. Bei der Installation von .NET Framework registriert die Setuproutine „aspnet_isapi.dll“ folgendermaßen in der IIS-Metabasis (C:\Windows\System32\Inetsrv\metabase.xml):

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

Wenn IIS den ASP.NET-ISAPI-Filter geladen hat, können alle eingehenden Anforderungen für eine Website an ASP.NET weitergeleitet werden, was wichtig ist, da SharePoint diese Anforderungen letztendlich über ASP.NET empfangen muss. Um dies zu erreichen, erweitert SharePoint die Konfiguration der ausgewählten Website durch Hinzufügen einer Platzhalteranwendungszuordnung, die alle eingehenden Anforderungen unabhängig von der Dateinamenerweiterung zum ASP.NET-ISAPI-Filter weiterleitet.

Dies ist in IIS-Manager ersichtlich, wenn Sie WSS 3.0 mithilfe der Option für die einfache Installation installieren. Die WSS-Setuproutine deaktiviert die vorhandene Standard-IIS-Website auf dem Server und erstellt eine neue Standardwebsite auf Port 80, in der die ASP.NET-Platzhalteranwendungszuordnung definiert wird (siehe Abbildung 2).

Abbildung 2 Platzhalteranwendungszuordnung für ASP.NET-ISAPI-Filter

Abbildung 2** Platzhalteranwendungszuordnung für ASP.NET-ISAPI-Filter **(Klicken Sie zum Vergrößern auf das Bild)

Damit ASP.NET wiederum Anforderungen an SharePoint weiterleitet, muss SharePoint auch die HTTP-Anforderungspipeline durch ein benutzerdefiniertes HttpApplication-Objekt erweitern, das mithilfe einer Klasse namens „SPHttpApplication“ in der Microsoft.SharePoint-Assembly implementiert wird. SharePoint definiert dieses benutzerdefinierte Anwendungsobjekt in der ASP.NET-Anwendungsdatei (global.asax), die Sie im Dateisystem im Stammordner der mit SharePoint erweiterten Websites finden können. Der folgende Code listet den Inhalt einer solchen global.asax-Datei auf:

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

ASP.NET führt eine dynamische Analyse und Kompilierung dieser Datei durch, um das SharePoint-Anwendungsobjekt zu instanziieren.

Für jede empfangene Anforderung löst ASP.NET eine Reihe von Ereignissen aus, die die Webanwendung verarbeiten kann, z. B. BeginRequest, AuthenticateRequest, ProcessRequest und EndRequest. Die Details der Ereignisverarbeitung gehen über den Rahmen dieses Artikels – das Bereitstellen und Verwalten von SharePoint – hinaus, doch Sie sollten wissen, dass SharePoint zusätzlich zur SPHttpApplication, die in „global.asax“ angegeben wird, benutzerdefinierte in der web.config-Datei definierte HTTP-Handler und Module für die Website implementiert. Zum Beispiel verwendet SharePoint ein auf der SPRequestModule-Klasse basiertes HTTP-Modul, das als das erste HTTP-Modul noch vor den Standard-ASP.NET-Modulen registriert wurde. SPRequestModule initialisiert die SharePoint-Laufzeitumgebung, zum Beispiel durch das Registrieren einer SPVirtualPathProvider-Komponente in ASP.NET. Das SPRequestModule ist für die interne SharePoint-Verwendung bestimmt, aber Entwickler von SharePoint-Lösungen können die web.config-Datei ändern, um zusätzliche Komponenten, z. B. benutzerdefinierte HTTP-Handler und Module, zu registrieren. SharePoint nutzt ASP.Net sowohl mit benutzerdefinierten als auch mit Standard-HTTP-Modulen, während alle Anforderungen an SharePoint-Anwendungen weiterhin strikt kontrolliert werden.

Beachten Sie Folgendes: Beim Erstellen einer Webanwendung mithilfe der Website „SharePoint 3.0-Zentraladministration“ fügt WSS der ausgewählten IIS-Website die ASP.NET-Platzhalteranwendungszuordnung hinzu und erstellt die Dateien „global.asax“ und „web.config“ im Stammordner der Website. Jede Webanwendung verwendet ihren eigenen Satz von global.asax- und web.config-Dateien der höheren Ebene.

Um Anforderungen zu verarbeiten und aussagekräftige Informationen an Browser zurückzugeben, verlassen sich WSS 3.0 und MOSS 2007 auf den Standard-ASP-NET-Seitenparser, der die angeforderten ASP.NET-Seiten kompiliert oder sie im Nichtkompilierungsmodus verarbeitet. Doch die ASP.NET Seiten, die SharePoint an den ASP.NET-Parser weiterleitet, sind nicht unbedingt dort platziert, wo sie sich allem Anschein nach befinden. Zum Beispiel werden Sie keine default.aspx-Datei im Stammordner einer mit SharePoint erweiterten Website wie der „SharePoint 3.0-Zentraladministration“ finden können, und doch öffnen Sie „default.aspx“, wenn Sie die Homepage dieser Website anzeigen. Die SPVirtualPathProvider-Komponente erstellt nämlich eine virtuelle Umgebung, indem der Seiteninhalt vom lokalen Dateisystem oder einer SQL Server-Inhaltsdatenbank geladen und als virtuelle Datei zum ASP.NET-Seitenparser weiterleitet wird. Für die Zentraladministrationswebsite lädt SharePoint die default.aspx-Datei vom Ordner „C:\Programme\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin“.

Die Homepage und die meisten anderen SharePoint-Webseiten sind mit einer ASP.NET-Masterseite verknüpft (default.master), über die ein allgemeines Layout für Menüs und Navigationssteuerelemente implementiert wird. Die default.master-Datei befindet sich im Order „C:\Programme\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions\12\Template\Global“ und enthält benannte Platzhalter für weitere Inhaltsseiten, die sich auch auf dem lokalen Dateisystem oder in einer SQL Server-Inhaltsdatenbank befinden können. Wichtig ist Folgendes: Wenn Sie eine SharePoint-Website in einem Webbrowser öffnen, zeigen Sie eigentlich Informationen aus einer Sammlung von Inhaltsseiten an, die sich nicht unbedingt auf dem lokalen Webserver befinden und die entsprechend einem in einer Masterseite definierten Layout angeordnet sind.

Die allgemeine Regel ist die, dass unveränderte Seiten (oder in SharePoint-Terminologie nicht angepasste Seiten) als Seitenvorlagen auf dem lokalen Dateisystem jedes SharePoint-Servers existieren, während angepasste Seiten in die Inhaltsdatenbank geschrieben werden, damit alle SharePoint-Server in einer Webfarm Zugriff auf den gleichen Satz von Seiten haben (siehe Abbildung 3). Es wird angenommen, dass nicht angepasste Seiten für alle Server und Websites in der Webfarm identisch sind. Wenn Sie jedoch eine Inhaltsseite oder eine Masterseite in einer SharePoint-Website anpassen, vielleicht mithilfe von Office SharePoint Designer 2007, speichert SharePoint die angepasste Seite automatisch in der Inhaltsdatenbank.

Abbildung 3 Nicht angepasste und angepasste ASP.NET-Seiten in einer SharePoint-Anwendung

Abbildung 3** Nicht angepasste und angepasste ASP.NET-Seiten in einer SharePoint-Anwendung **(Klicken Sie zum Vergrößern auf das Bild)

Zusätzlich zu angepassten Seiten und anderem Websiteinhalt speichert SharePoint auch Konfigurationsdaten in einer SQL Server-Datenbank. SharePoint hält die Konfigurationsdaten vom Inhalt fern, weil die Konfigurationsdaten ihrer Natur nach global sind, während der Inhalt einzelner Webanwendungen und Websitesammlungen spezifisch ist. Dementsprechend kann eine Webfarm nur eine einzige Konfigurationsdatenbank, aber mehrere Inhaltsdatenbanken haben.

Alle WSS-Server in der Webfarm verwenden die gleiche Konfigurationsdatenbank für die Freigabe von Metadaten, Konfigurationseinstellungen und Informationen zu jeder IIS-Website, die in der Webfarm mit SharePoint erweitert wurde. Einzelne Webanwendungen dagegen können einer oder mehreren Inhaltsdatenbanken zugeordnet werden (obwohl jede Inhaltsdatenbank nur einer Webanwendung zugeordnet werden kann).

Die Beziehung zwischen IIS-Websites, Webanwendungen, Websitesammlungen, Websites und Inhaltsdatenbanken kann verwirrend sein. In SharePoint-Terminologie bezeichnet der Begriff Webanwendung eine mit SharePoint erweiterte IIS-Website. Eine Webanwendung kann mehrere Websitesammlungen enthalten, und jede Websitesammlung kann wiederum eine Website einer höheren sowie Websites einer untergeordneten Ebene enthalten, die über die gleichen Konfigurationseinstellungen verfügen.

Unter anderem ermöglicht Ihnen das Erstellen mehrerer Websitesammlungen, die Verwaltung der Websitesammlungen an verschiedene Benutzer und Gruppen zu delegieren. Eine einzige Websitesammlung kann nicht mehrere Inhaltsdatenbanken enthalten, aber eine Webanwendung kann mehrere Inhaltsdatenbanken für mehrere Websitesammlungen verwenden, um die Skalierbarkeit zu erhöhen, und die Leistungsbeeinflussung bei großen Websites zu verringern, die einen beachtlichen Anteil an Datenbankaktivität auf anderen SharePoint-Websites generiert. Es empfiehlt sich jedoch nicht, jede SharePoint-Website in ihre eigene Websitesammlung zu stellen, weil durch diese Art von Bereitstellung die websiteübergreifende Funktionalität eingeschränkt wird.

WSS 3.0 unterstützt die Inhaltssuche über mehrere Websitesammlungen nicht. Solche Suchvorgänge erfordern MOSS 2007 oder Microsoft Search Server 2008. Sie können zum Beispiel eine Webanwendung und Website der höheren Ebene für „http://contoso“ erstellen, und ein Websitesammlungsadministrator kann dann mithilfe der SharePoint-Benutzeroberfläche untergeordnete Websites erstellen, z. B. „http://contoso/info“ und „http://contoso/events“. All diese Websites existieren in derselben Inhaltsdatenbank, weil sie zur selben Websitesammlung gehören.

Als Webfarmadministrator können Sie in „SharePoint 3.0-Zentraladministration“ auch einen verwalteten Pfad verwenden, z. B. „/sites“, und dann zusätzliche Websitesammlungen definieren, z. B. „http://contoso/sites/IT“ und „http://contoso/sites/HR“. Diese drei Websitesammlungen (http://contoso, http://contoso/sites/IT und http://contoso/sites/HR) können unterschiedliche Websitesammlungsadministratoren, Konfigurationseinstellungen und Inhaltsdatenbanken haben, doch der Zugriff auf sie erfolgt weiterhin über die IIS-Website (http://contoso), und sie verwenden dieselbe Anwendungspoolidentität der Webanwendung.

Selbstverständlich gibt es noch viele weitere Details zu beachten, aber es ist äußerst wichtig, beim Arbeiten mit SharePoint diese Beziehung zwischen IIS, ASP.NET und SQL Server zu verstehen. Wenn Sie sich für weitere Informationen zur SharePoint-Architektur interessieren, empfiehlt sich der im MSDN® Magazin veröffentlichte Artikel von Ted Pattison „Entdecken Sie bedeutende Verbesserungen für Entwickler in SharePoint Services“, der unter msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview verfügbar ist.

SharePoint-Infrastrukturelemente

Als Nächstes soll diese kurze Architekturabhandlung in eine flexible SharePoint-Infrastruktur umgesetzt werden. Wie Sie sicher bemerkt haben, sind Windows Server®, IIS, .NET Framework 3.0 (beides für ASP.NET und Windows® Workflow Foundation), WSS 3.0 oder MOSS 2007 sowie SQL Server erforderlich. Obwohl Sie sich auf IIS 7.0 unter Windows Server 2008 freuen können, wird für den vorliegenden Zweck IIS 6.0 unter Windows Server 2003 verwendet, weil dies zum Zeitpunkt dieses Artikels die am häufigsten bereitgestellte Version ist. WSS 3.0 bleibt, weil für dieses anfängliche SharePoint-Pilotprojekt keine MOSS 2007-spezifischen Features erforderlich sind.

Für einen minimalistischen Ansatz können Sie WSS 3.0 mit allen erforderlichen Komponenten auf einem einzigen Computer installieren (siehe Beschreibung in der PDF-Datei zu WSS 3.0 auf einem einzelnen Computer, die im Begleitmaterial für diesen Artikel verfügbar ist). Dies ist für einen Testumgebungsserver oder eine kleine Arbeitsgruppenumgebung völlig ausreichend. Wenn Sie jedoch die Absicht haben, Ihre SharePoint-Infrastruktur möglichst flexibel zu gestalten, sollten Sie nicht mit einer eigenständigen Bereitstellung in Ihrer Produktionsumgebung starten. Aus Gründen der Verfügbarkeit und der zukünftigen Skalierbarkeit ist es besser, gleich eine mehrstufige Infrastruktur einzusetzen und bei Bedarf weitere Server hinzuzufügen.

In Abbildung 4 sehen Sie die SharePoint-Infrastruktur, die sich für eine einfache und flexible Systemkonfiguration empfiehlt. Sie enthält eine Webfarm mit zwei SharePoint-Servern und einen separaten Computer mit SQL Server. Diese Konfiguration beseitigt den Datenbankverarbeitungsaufwand auf den Webservern, erhöht die Verfügbarkeit und die Skalierbarkeit und vereinfacht die Systemwartung. Beachten Sie, dass Active Directory® erforderlich ist, weil dies bei einer Webfarmbereitstellung mit WSS 3.0 eine Softwareanforderung ist. Schritt-für-Schritt-Anleitungen für die Bereitstellung finden Sie in der PDF-Datei zur grundlegenden SharePoint-Infrastruktur im Begleitmaterial.

Abbildung 4 Grundlegende SharePoint-Infrastruktur für zukünftiges Wachstum

Abbildung 4** Grundlegende SharePoint-Infrastruktur für zukünftiges Wachstum **(Klicken Sie zum Vergrößern auf das Bild)

Das Domänenkonto, das für die Bereitstellung von SharePoint in dieser Anordnung verwendet wird, erfordert lokale Administratorberechtigungen für die Webserver. Es ist außerdem erforderlich, dieses Konto den SQL Server-Rollen „dbcreator“ und „securityadmin“ sowie der Datenbankrolle „db_owner“ für die Masterdatenbank in SQL Server 2005 hinzuzufügen, wie in der PDF-Datei zur grundlegenden SharePoint-Infrastruktur beschrieben. Sie können dann Konfigurations-Assistenten für SharePoint-Produkte und -Technologien bei der WSS 3.0-Installation verwenden, um die erforderliche Konfigurationsdatenbank für die Webserverfarmen und eine Inhaltsdatenbank für die Website „SharePoint 3.0-Zentraladministration“ zu erstellen. Andernfalls muss ein SQL Server-Administrator diese Datenbanken für Sie bereitstellen und der Rolle „db_owner“ die WSS-Systemkonten hinzufügen.

Bedenken Sie auf jeden Fall, dass das von Ihnen verwendete Benutzerkonto zum Installieren von SharePoint nicht das Konto ist, das SharePoint für den Zugriff auf die Konfigurationsdatenbank oder die Inhaltsdatenbank für die Zentraladministrationswebsite verwendet. Stattdessen verwendet SharePoint das Systemkonto, das als Anwendungspoolidentität für die Website „SharePoint 3.0-Zentraladministration“ konfiguriert wurde.

Der Konfigurations-Assistent für SharePoint-Produkte und -Technologien fordert Sie zur Eingabe der Konteninformationen auf. Es ist sinnvoll, hier ein dediziertes Domänenbenutzerkonto zu verwenden, z. B. CONTOSO\WssConfigAdmin. Ich persönlich verwende in der Regel individuelle, dedizierte Benutzerkonten für alle zusätzlichen Webanwendungen, die ich nachfolgend erstelle. Das Verwenden eines separaten Anwendungspools für jede Webanwendung trägt zum Gewährleisten einer Prozessisolation bei, das Verwenden eines unterschiedlichen Benutzerkontos für jeden Anwendungspool sorgt dafür, dass die Sicherheitsisolation beibehalten wird. Beachten Sie jedoch, dass dies nur ein möglicher Ansatz ist, und dass die potenziellen Auswirkungen auf die Verwaltbarkeit und Leistung anhand Ihrer eigenen Umgebung und Geschäftsanforderungen evaluiert werden müssen.

Ein anderes wichtiges Systemkonto, das der Domänenadministrator für Sie erstellen sollte, ist das Suchdienstkonto. Sie können das Zentraladministrationskonto verwenden, doch für eine erhöhte Sicherheit ist es vorzuziehen, ein dediziertes Suchkonto wie „CONTOSO\WssSearch“ zu verwenden, das keine Administratorberechtigungen hat und nicht jeden Inhalt ändern kann. Eine Schreibberechtigung für Inhaltsdatenbanken ist nicht erforderlich, weil der Suchdienst den Inhalt lediglich für Indizierungszwecke crawlt und die Suchdaten in einer separaten Datenbank verwaltet.

Wenn Sie eine Webanwendung in einer Serverfarm erstellen, können Sie diese Inhaltsdatenbank einem Suchserver zuordnen, der das entsprechende Suchdienstkonto implizit der Richtlinie „Alles lesen“ der Webanwendung hinzufügt. Suchserver sind SharePoint-Server, die den Windows SharePoint Services-Suchdienst ausführen. Wenn Sie die Schritt-für-Schritt-Anweisungen in der PDF-Datei zur grundlegenden SharePoint-Infrastruktur befolgt haben, wurden beide Webserver als Suchserver konfiguriert, damit Sie die durch Crawlen und Indizieren mehrerer Inhaltsdatenbanken verursachte Last besser verteilen können. Es ist jedoch auch möglich, einen dedizierten Suchserver in einer Webfarm zu konfigurieren, der vom Netzwerklastenausgleich und von Clientverbindungen ausgeschlossen ist, sodass die Clientverbindungen nicht von Crawlaktivitäten betroffen sind.

Self-Service Site-Verwaltung

Da nun eine grundlegende SharePoint-Infrastruktur eingerichtet ist, können Sie die Verwaltung von Websitesammlungen und Websites an einzelne Abteilungen und Benutzer delegieren, ohne die Kontrolle über Active Directory, die Webserverfarmen oder die SQL Server-Datenbanken zu dezentralisieren. Als Webfarmadministrator arbeiten Sie mit Active Directory- und SQL Server-Administratoren zusammen, um Anwendungspoolkonten und Inhaltsdatenbanken für Ihre Webanwendungen bereitzustellen. Innerhalb dieser Webanwendungen erstellen Sie dann Websitesammlungen und legen Websitesammlungsadministratoren mit der Berechtigung zum Erstellen untergeordneter Websites fest. Auf diese Weise können Websitesammlungsadministratoren innerhalb einzelner Abteilungen ihre SharePoint-Ressourcen unter minimaler Beteiligung der IT-Abteilung verwalten (siehe Abbildung 5).

Abbildung 5 Dezentralisierte Websiteverwaltung in einer zentralisierten SharePoint-Infrastruktur

Abbildung 5** Dezentralisierte Websiteverwaltung in einer zentralisierten SharePoint-Infrastruktur **(Klicken Sie zum Vergrößern auf das Bild)

Weiterhin kann Benutzern ermöglicht werden, Websitesammlungen unter verwalteten Pfaden zu erstellen (wie dem „/sites“-Pfad oder anderen verwalteten Pfaden mit Platzhalterinklusionen, die Sie in der SharePoint 3.0-Zentraladministration erstellen). Wenn Sie das Feature „Self-Service Site-Verwaltung“ innerhalb einer Webanwendung aktivieren, können Benutzer eigene Websitesammlungen erstellen und Websitegruppen und Berechtigungen innerhalb der SharePoint-Benutzeroberfläche verwalten. Im Unterschied zu untergeordneten Websites erben Websitesammlungen nicht die Berechtigungen einer übergeordneten Website.

Self-Service Site-Verwaltung ist nicht für jede SharePoint-Umgebung geeignet und daher standardmäßig deaktiviert. Wenn Sie dieses Feature aktivieren, führt dies möglicherweise zu einer großen Zahl selten verwendeter Websitesammlungen in den Inhaltsdatenbanken. Dieses Feature illustriert jedoch die Flexibilität der SharePoint-Verwaltung, und es empfiehlt sich, es in Ihrer Pilotbereitstellung auszuprobieren. (Darüber hinaus gibt es Optionen innerhalb von SharePoint, um Benutzer und/oder Administratoren über inaktive Websites zu benachrichtigen, damit sie gegebenenfalls entfernt werden können.) Sie müssen „Self-Service Site-Verwaltung“ explizit für eine Webanwendung aktivieren, wie es in der PDF-Datei zum Zulassen der Self-Service Site-Verwaltung im Begleitmaterial beschrieben ist.

SharePoint-Anpassungen und Branding

SharePoint-Ressourcen

An diesem Punkt kommt natürlich der Wunsch auf, das Logo, den Namen und die Farben des Unternehmens in die SharePoint-Benutzeroberfläche aufzunehmen. Bedenken Sie jedoch, dass Sie Ihr SharePoint-Projekt dadurch auf die ASP.NET-Entwicklerebene befördern. Als Mindestvoraussetzung benötigen Sie dazu ein Entwicklungssystem, z. B. einen eigenständigen WSS 3.0-Server mit Microsoft Office SharePoint Designer 2007 (siehe die PDF-Datei zur Installation von SharePoint Designer im Begleitmaterial), damit Sie Ihre Anpassungen erstellen und testen können, ohne die Produktionsumgebung zu beeinflussen. Außerdem empfiehlt sich der Besuch des „Windows SharePoint Services-Developer Center“ unter msdn2.microsoft.com/sharepoint, um mehr über die Fülle von Anpassungsoptionen in SharePoint zu erfahren.

Auch wenn die SharePoint-Entwicklung in diesem Artikel nicht behandelt werden kann, sollen kurz einige Überlegungen aufgeführt werden, die Sie in Betracht ziehen sollten. SharePoint speichert angepasste Seiten in der Inhaltsdatenbank der entsprechenden Websitesammlung. Anders ausgedrückt: Alle Anpassungen, die Sie auf Seiten, Anwendungsseiten, Masterseiten, Stylesheets und so weiter vornehmen, werden in einer SharePoint-Website nur auf die Websitesammlung oder die Websiteebene angewendet. Dies ist für einzelne Websitesammlungsadministratoren, die das äußere Erscheinungsbild ihrer Websites mithilfe von SharePoint Designer 2007 anpassen wollen, hervorragend, nicht jedoch für den Farmadministrator, der das Unternehmensimage auf allen Webanwendungen, Websitesammlungen und Websites in einer Webfarm durchsetzen will.

Sie können benutzerdefinierte Websitethemen oder benutzerdefinierte Websitedefinitionen erstellen, die auf einer Kopie des Standard-SharePoint-Themas oder der Websitedefinition basieren. Weiterhin können Sie benutzerdefinierte Masterseiten erstellen und diese dem Masterseitenkatalog hinzufügen. Allerdings setzt keine dieser Optionen das globale Branding durch, wenn das Feature „Self-Service Site-Verwaltung“ aktiviert ist, weil ein Benutzer mit den Berechtigungen zum Erstellen von Websitesammlungen oder Websites immer noch eine Standardwebsitevorlage auswählen kann, die das Unternehmensbranding nicht enthält.

Globales Branding erfordert, dass Sie die Standard-SharePoint-Komponenten ersetzen, damit stattdessen Ihre benutzerdefinierten Komponenten verwendet werden. Entwickler sind darum bemüht, dies ohne eine Änderung der ursprünglichen Dateien zu erreichen. Ein Ansatz besteht darin, die Konfiguration der virtuellen Verzeichnisse in IIS-Manager zu ändern und sie auf neue Ordner mit angepassten Dateien zu verweisen. Eine andere Methode besteht darin, ein benutzerdefiniertes HTTP-Modul oder einen ISAPI-Filter zu implementieren, um die URLs neu zu schreiben, sodass Anforderungen für bestimmte Standardseiten an angepasste Versionen umgeleitet werden.

Schlussbemerkung

Schwerpunkt dieses Artikels waren die Grundlagen für das Einrichten einer SharePoint-Infrastruktur mit WSS 3.0. Andere Features wie etwa Workflows, Umfragen, Nachrichtenintegration und Antivirus oder MOSS 2007-spezifische Funktionen wie Portale, Websiteverzeichnisse und Geschäftsdatenkataloge wurden nicht erörtert. Auch bei den Anpassungen für die Websiteverwaltung und das Unternehmensbranding wurde nur oberflächlich auf die Möglichkeiten von SharePoint eingegangen. Sie können weitere Anpassungen mit WSS 3.0 vornehmen, indem Sie benutzerdefinierte Anwendungen in Visual Studio® programmieren.

Die Infrastruktur ist stabil genug für zukünftiges Wachstum, wenn Sie weitere Webserver oder Datenbankserver hinzufügen. Mit der Piloteinführung einiger Anpassungen können Benutzer individuelle Websites erstellen und sich nach und nach mit SharePoint vertraut machen. Auf diese Weise können die zentralen Komponenten sowohl im Bereich Benutzerakzeptanz als auch bei Hardware und Software etabliert werden. Sie erhalten die Flexibilität, Änderungen zuzulassen, und schaffen die Grundlage für eine ausgereifte Produktionseinführung.

Pav Cherny ist IT-Experte und Autor, der sich auf Microsoft-Technologien für die Zusammenarbeit und einheitliche Kommunikation spezialisiert. Seine Veröffentlichungen umfassen Whitepapers, Produkthandbücher und Bücher mit dem Schwerpunkt IT-Vorgänge und Systemverwaltung. Pav Cherny ist Vorsitzender der Biblioso Corporation.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.