Sandra Erb

Viele Unternehmen haben bereits den Microsoft Office SharePoint Server 2007 im Einsatz und stehen nun vor der Aufgabe, diesen nach Microsoft SharePoint Server 2010 zu migrieren. In diesem Beitrag werden die verschiedenen Upgrade Mechanismen vorgestellt und einige allgemeine Hinweise zum Upgrade gegeben.

Wer mit der Migration von SharePoint 2003 auf 2007 schon Erfahrung hat, dem wird es vermutlich vor dem Upgrade auf 2010 grausen. Allerdings kann ich hier bereits sagen, dass Microsoft sich sehr große Mühe gegeben hat und wirklich gute Upgrade Mechanismen entwickelt hat.

Hinweis: Eine Migration von SharePoint 2003 auf 2010 ist nicht möglich. Hier muss zuvor ein Upgrade auf 2007 erfolgen.

Vor dem eigentlichen Upgrade

Wichtig für alle Upgrade Varianten ist, dass die Systemvoraussetzungen für SharePoint 2010 erfüllt sind und dass die bisherige MOSS Installation über das Service Pack 2 verfügt.
Desweiteren sollte man mit Hilfe des “Pre-Upgrade-Checks” überprüfen, welche “Problembereiche” in der aktuellen Farm existieren.

Der PreUpgradeCheck ist ab MOSS SP2 ein Befehl des Administrationstools stsadm:

stsadm –o preupgradecheck

preupgradecheck

Nachdem dieser Befehl durchgelaufen ist wird eine übersichtliche Website angezeigt, welcher man die Ergebnisse des Checks und eventuelle Probleme (inkl. Lösungsvorschlag!) entnehmen kann.

Werden eigene (oder eingekaufte) Solutions/Features oder Webparts verwendet, so müssen auch diese 64-Bit fähig sein, oder entsprechend angepasst werden, bevor die Migration erfolgt.

Variante 1: In-Place Upgrade (Direktes Upgrade)

Das In-Place Upgrade ist wohl die “rabiateste” Methode. Hierbei wird der neue SharePoint 2010 über den bereits existierenden SharePoint 2007 installiert.
Wichtig bei diesem Vorgehen ist, dass auf allen beteiligten Servern die Systemvoraussetzungen bereits erfüllt sind. Sollte die bestehende Umgebung noch nicht auf 64-Bit implementiert sein, so muss vor dem Upgrade auf SharePoint 2010 eine Migration auf 64-Bit erfolgen (gleiches gilt natürlich auch für Windows Server 2008 und die SQL Server Komponenten).
Sind alle Voraussetzungen erfüllt, so sollte die Farm noch einmal mit dem “Pre-Upgrade-Check” überprüft werden.

Ist der “Pre-Upgrade-Check” erfolgreich durchgelaufen, so kann mit dem Upgrade begonnen werden.

Das Upgrade muss in einer bestimmten Reihenfolge erfolgen. (Zuerst auf dem Server, auf dem die Central Administration installiert ist. Konfigurationsassistenten nicht ausführen, bevor das Upgrade nicht auch auf allen Front-End-Webservern ausgeführt wurde!)

Da in SharePoint 2010 kein Shared Service Provider mehr existiert, wird dieser während des Upgrade Prozesses in einzelne Service Applikationen “zerlegt”. Somit werden auch diese Einstellungen übernommen. Die so angelegten Service Applications sollten jedoch genau auf die richtigen Einstellungen und ihre Funktion überprüft werden.

Nach dem Upgrade erscheint das neue Portal zunächst im alten SharePoint 2007 Layout. Dieses kann mit Hilfe des Visual Upgrades auf die neue Ribbon Oberfläche umgestellt werden. Sehr schön bei diesem Vorgehen ist auch die “Vorschau” Funktion. So kann die neue Oberfläche erst für Administratoren zur Verfügung gestellt werden und diese können dann entscheiden, wann das Upgrade auch an den Endanwender weitergegeben wird.

Vorteile Nachteile
Farmweite Einstellungen bleiben erhalten. Die komplette SharePoint Server Farm ist während des Updates offline. Bei einer großen Server Farm kann dieses Verfahren auch entsprechend viel Zeit kosten.
Anpassungen (Webparts, Features/Solutions) sind sofort wieder verfügbar
(Evtl. müssen hier allerdings noch Anpassungen vorgenommen werden)
Fehler während des Upgrades (nicht erfüllte Voraussetzungen, falsche Update Reihenfolge) kann zum Verlust der Farm führen.
Die alte Infrastruktur wird übernommen Migrationsaufwand nimmt mit dem Umfang der Farm proportional zu, ebenso die Dauer der Umstellung (sequenzielles Update der Inhaltsdatenbanken). Große Inhaltsdatenbanken können den Upgrade Prozess verlängern

Für wen ist das In-Place Upgrade geeignet?
Meiner Meinung nach ist das In-Place Upgrade nur geeignet, wenn es sich um eine kleine Serverfarm handelt und wenn die bisherige Architektur übernommen werden soll. Es ist auf jeden Fall ratsam, sich für das In-Place Upgrade professionelle Hilfe zu holen, da dieses das Risiko birgt, die komplette Farm zu “verlieren”.

Variante 2: Database Migration (Upgrade mit Anfügen der Datenbanken)

Die Variante der Database Migration ist in meinen Augen die sanfteste und sicherste Variante, ist jedoch gleichzeitig auch ressourcenintensiv.

Bei der Database Migration wird neben der existierenden Farm eine neue Farm aufgebaut (daher ressourcenintensiv). Diese ist vollkommen unabhängig von der bisherigen SharePoint 2007 Farm. Auch hier gilt: erst alle Voraussetzungen erfüllen, bevor SharePoint 2010 installiert wird. Auch sollten vor dem Umzug der alten Inhaltsdatenbanken unbedingt alle eigenen Features/Solutions installiert werden. Wichtig ist hierbei z.B. auch das eigene Theme.
Steht der neue SharePoint, dann können die alten Inhaltsdatenbanken der neuen Farm hinzugefügt werden (entweder über die Power Shell, oder über den altbekannten stsadm Befehl “addcontentdb”)

Auch nach der Database Migration erscheint das neue Portal zunächst im alten Layout. Dies kann mit Hilfe des Visual Upgrades angepasst werden.

Vorteile Nachteile
Mehrere Inhaltsdatenbanken können gleichzeitig aktualisiert werden (Kürzere Upgrade Dauer als beim In-Place Upgrade) Sie bisherigen Farmeinstellungen werden nicht übernommen, diese müssen manuell übertragen werden
Mehrere Farmen können in einer Farm zusammengefasst werden Anpassungen (Features, Webparts etc.) müssen manuell übertragen werden, wird eines vergessen, führt dies zu Fehlern und Funktionalitätsverlust
Es wird eine neue “saubere” Farm aufgesetzt, so vermeidet man die Übernahme eventueller Altlasten Das Kopieren der Datenbanken über das Netzwerk (wenn auch ein neuer Datenbankserver eingesetzt wird) kostet Zeit und Bandbreite
Die beiden Farmen agieren unabhängig voneinander, so kann die Umstellung ohne lange Offlinezeiten erfolgen. Auch kann vor dem Freischalten der neuen Farm ausgiebig getestet werden, ohne dass dies die Endbenutzer beeinträchtigt.

Für wen ist die Database Migration geeignet?
Die Database Migration ist vor allem für Umgebungen mit sehr vielen und sehr großen Datenbanken geeignet, da hierbei das Upgrade der Datenbanken parallel geschehen kann. Außerdem ist diese Variante auch für alle zu empfehlen, deren Endanwender so wenig wie möglich von der Migration beeinflusst werden sollen. Während man beim In-Place Upgrade die Farm bis zur Vollendung des Upgrades offline nehmen muss, können bei der Database Migration beide Farmen parallel laufen, bis es zur eigentlichen Datenübernahme kommt.

Variante 3: Hybrid Variante

Die Hybrid Variante ist eine Kombination aus dem In-Place Upgrade und der Database Migration.

Die Hybrid Variante selbst teilt sich noch einmal in zwei unterschiedliche Methoden:

Methode 1:
Während des Upgrade Vorgangs wird weiterhin schreibgeschützter Zugriff auf die Inhaltsdatenbanken gewährt, während das Upgrade in einer anderen Farm ausgeführt wird.

Methode 2:
Die Möglichkeiten des In-Place Upgrades werden genutzt, um die Farm zu migrieren, jedoch werden die Datenbanken hierbei nicht migriert. Erst nach dem Upgrade werden die Datenbanken nach dem Verfahren der Database Migration getrennt, aktualisiert und wieder neu angefügt. Somit ist ein paralleles Upgrade der Datenbanken möglich.

Die Hybrid Variante vereinigt somit alle Vor- und Nachteile der In-Place und der Database Migration Variante.

Fazit

Egal für welche Methode man sich entscheidet, alle erfordern einiges an Planung, Vorbereitung und auch Nachbereitung (Beobachtung der Logfiles, evtl. Fehlerbehebung). Microsoft hat sehr viel Arbeit in die neuen Upgrade Mechanismen investiert, viel dokumentiert und vor allem viel Unterstützung geliefert. Dennoch sollte das Upgrade nur von erfahrenen SharePoint Administratoren durchgeführt werden, da es doch immer wieder kleine Stolperfallen gibt.

In meinem nächsten Post werde ich von den Erfahrungen berichten, die wir während des Upgrades auf SharePoint 2010 gemacht haben und etwas detaillierter auf die Variante der Database Migration eingehen.