Sharepoint 2010: Teil 4 - Administration von Sharepoint Server 2010

Nachdem unsere Sharepoint Installation und Erstkonfiguration abgeschlossen sein sollte, startet die Weboberfläche und präsentiert die neue Central Administration.

Hier fällt gleich zu Beginn auf, dass sich ein Konfigurationswizard startet, der anbietet alle Schritte zur Erstellung eines Portals zu erledigen. Die Idee eines Wizards is gut, wir machen das Ganze jedoch händisch :-) damit wir 1.) den Prozess kennenlernen und 2.) flexibel sind und alle Einstellungen selber festlegen können.

Abb. 1 – Sharepoint Farm Configuration Wizard

Erstellung eines Intranet Portals

Wir wollen ein neues Top-Level Portal zum Einstieg in ein Intranet erstellen – was brauchen wir dazu?

1.) Eine (ASP.NET) Web-Anwendung, die das Portal hosted.
2.) Einen dedizierten Application Pool, damit unser Intranet unabhängig verwaltet werden kann
3.) Eine Site-Collection. Eine Site Collection in Sharepoint stellt einen Container für eine Sammlung von Sites dar. Also unser Top-Level Portal unter dem dann verschiedenste Abteilungssites etc. angelegt werden.

- Webanwendung erstellen

Beginnen wir mit dem Erstellen der Webanwendung. In der Sharepoint Central Administration findet sich der Punkt “Application Management”, dahinter verbirgt sich eine Liste von Webanwendungen. Im Ribbon oben befindet sich eine “New” Button, über diesen kommt man zum Erstellungsdialog. Diese dialog-artigen Seiten sind übrigens eine neues Feature von Sharepoint 2010.

Abb. 2 – Endpunkt der Webanwendung

Einige Angaben sind nötig, für die neue Anwendung. Die wichtigsten Punkte sind: Wir erstellen eine neue IIS Website (“Create new IIS web site”) damit unsere Anwendung sauber vom Rest der Sites am IIS getrennt ist.

Unter “Port” und “Host Header” haben wir die Möglichkeit, den “Endpunkt” zu definieren über den die Anwendung erreichbar ist. Bei Webanwendungen, welche von End-Usern bedient werden, bietet es sich immer an den Standard-Port 80 zu verwenden, da kein User gewohnt ist den Port (abc.com:82) an die URL anzuhängen.

Um unsere Webanwendungen alle auf Port 80 betreiben zu können, werden sie über “Host Header” unterschieden. In Abbildung 2 oben sieht man den Host Header (portal.development.local). Damit diese URL erreichbar ist muss man natürlich auch einen entsprechenden DNS Eintrag erzeugen oder erzeugen lassen!

Abb. 3 – Application Pool und Content Datenbank erzeugen

Ein weiterer wichtiger Punkt bei der Erstellung ist die Auswahl oder Erzeugung eines Application Pools. Man sollte bei der Planung für Sharepoint darauf achten, alle Webanwendunge sauber administrativ zu trennen. Liegen 2 Anwendungen im selben Application Pool, ist es nicht möglich sie getrennt zu “resetten” –> und das Zurücksetzen ist eine häufige Tätigkeit bei Sharepoint Entwicklung. Wenn zB. das Intranet und ein Kundenportal im selben Application Pool liegen, kann es sehr unangenehm für die Kunden sein, wenn der Application Pool “recycled” wird; alle Session enden dann nämlich abrupt!

Im Beispiel legen wir einen neuen Application Pool für die Anwendung an und geben den Service Account, den wir für Sharepoint erstellt haben als Dienstkonto für den Application Pool an.

Danach wird noch der Datenbankserver und der Name der Inhaltsdatenbank angegeben. Wichtig hierbei: Sprechende Namen für die Datenbank! Der DB Admin wirds beim Backup danken, wenn einfach ersichtlich ist welche Webanwendung welche Datenbank verwendet.

Dienstanwendungen verbinden

Bis zu Version 2007 von Sharepoint Server wurden farm-weite Dienst von einem oder mehreren Shared-Services-Provider angeboten. Diese Dienste umfassten Excel Services, Suche, Index, uvm. Das Problem mit SSP’s war das jede Webanwendunge mit genau einem Provider verbunden war und alle Dienste konsumieren musste. Das führte dazu, dass man mehrere SSP’s anlegte mit verschienden Diensten und Einstellungen – ein administrativer Overhead.

Die Service Applications in Sharepoint 2010 lösen dieses Problem. Die Architektur wurde flexibler gestaltet. Die Dienste laufen auf einem Server und Webanwendungen “abonnieren” Dienste, welche für sie relevant sind. Diese “Service Associations” sind in der Central Administration zu verwalten und man kann sie einzeln parametrisieren, sodass jede Anwendung genau nur die passenden Dienste mit den passenden Einstellungen konsumiert.

Abb. 4 – Dienstezuordnungen für die Webanwendung erstellen

- Site Collection erstellen

Nachdem die Webanwendung erzeugt wurde, ist sie über ihre URL erreichbar, aber natürlich “leer”. Also ist es an der Zeit Inhalte zu erzeugen.

Abb. 5 – Erstellen einer Sitecollection

In der Central Administration unter “Create Sitecollection” erzeugen wir uns eine neue Site Collection. Die Site Collection stellt das oberste Elemen in einer Sharepoint Hierarchie dar. Sie ist der “Container” für die darunterliegenden Websites und ermöglich das gemeinsame Administrieren einer Gruppe zusammengehöriger Sites (zB Abteilungen). Weiters können somit Inhalte und Vorlagen erstellt werden, die für alle darunterliegenden Websites verfügbar sind. Siehe Abb. 6

Abb.6 – Sharepoint Site Hierarchie

Zum Erzeugen der Site Collection geben wir einen Titel an und einen Pfad unter dem sie verfügbar ist. Normalerweise beim Portal auf oberster Ebene ist das die Root-URL der Webanwendung - also zB. portal.development.local. Es ist aber auch möglich mit “Managed Paths” Pfade anzugeben sodass nicht nur eine sondern viele Site Collections unter einem gemeinsamen Root laufen können zB. portal.development.local/sites/[PORTAL] . Nähere Informationen zu Managed Paths und wann man sie verwenden sollte finden sich in der “Links” Sektion am Ende des Artikels.

Wir wählen als Vorlage das “Publishing Portal”. Diese Vorlage ist ganz gut für ein Intranet geeignet das sie via Sharepoint Publishing Feature eine Art Web-Content-Management System bietet. Das bedeutet dass User basierend auf vorgegebenen Templates eigenen Content erzeugen können – eine nette Motivation für die Benutzung des Intranets.

Wichtig ist noch die 2 Site Collection Admins auszuwählen! Warum 2 ? Ein Punkt der oft übersehen wird, ist dass AD – Domain Admins NICHT automatisch Site Collections Admins in Sharepoint sind, sondern nur die 2 die man explizit angibt. Man sollte sich also gut überlegen wer zB. gleichzeitig mit wem auf Urlaub ist (sogar Admins machen gerüchteweise Urlaub).

Damit ist die Einrichtung der Sitecollection abgeschlossen und nachdem alles erstellt wurde erstrahlt unser erstes Sharepoint Portal in vollem Glanz!

Mehr zum Arbeiten mit Sites/Site Collections, Listen, Bibliotheken etc. gibts dann in Teil 5.

Bis dahin – viel Spass beim Testen !