Upgrade auf SharePoint 2010

Bereits heute sind erste Informationen betreffend dem Upgrade auf SharePoint 2010 verfügbar. Nachfolgend möchte ich auf die möglichen Migrationsszenarien, die Anforderungen, die Risiken sowie die Vorbereitungen, welche bereits heute angegangen werden können, eingehen. Wir werden ein standardisiertes Vorgehen definieren, um Risiko und Kosten zu minimieren und unseren Kunden einen schnellen Wechsel auf SharePoint 2010 zu ermöglichen. Mehr dazu, wenn es konkreter wird, in diesem Blog.

Microsoft hat bedeutend mehr in den Upgrade auf SharePoint 2010 investiert als in jenen auf SharePoint 2007. Der Upgrade läuft stabiler, kann besser überwacht werden und nach Problemen wieder fortgeführt werden.

Migrierte Sites werden zuerst in einem Visual Upgrade Modus angezeigt. Die alten CSS und Master Files werden angewendet, wodurch der User das alte UI sieht. Über die Site Settings kann testweise auf das neue UI mit den Ribbons umgeschaltet werden. Läuft alles glatt, kann das UI definitiv geändert werden. Diese Umstellung kann zentral erfolgen (vom Administrator) aber durch den Site Owner erfolgen.

Anforderungen

SharePoint 2010 braucht für alle Rollen (Web Frontend, Application aber auch SQL Server) 64bit Plattformen. Als Betriebssystem muss Windows Server 2008 SP2 oder R2 installiert sein. Die Version des Datenbankservers muss mindestens SQL Server 2005 SP2 oder 2008 SP1 CU2 sein.

Upgradeszenarien

Microsoft bietet nur zwei Upgradeszenarien an:

• Ein In-Place Upgrade migriert eine SharePoint Farm von MOSS 2007 SP2 nach SharePoint 2010. Während des Upgrades ist die Farm nicht verfügbar. In diesem Szenario muss aber die bestehende Farm die oben erwähnten Anforderungen erfüllen.
• Das bessere Upgradeszenario ist in meinen Augen der Database Attach Upgrade. Dabei wird eine zweite Farm, inkl. SQL Server, mit SharePoint 2010 bereitgestellt, auf welche dann die Content Datenbanken sowie die Profile Datenbank kopiert und angehängt werden. Beim Hinzufügen der Datenbanken wird das Upgrade durchgeführt.

Vorbereitungen der Content Datenbanken

Grundlage für ein erfolgreiches Upgrade ist eine “saubere” und schlanke SharePoint 2007 Installation. Damit kann bereits heute begonnen werden.

• Nicht verwendete Site Collections oder Sites löschen sowie Dokumentversionen einschränken: durch die kleinere Datenmenge läuft der Upgrade schneller durch.
• Fehlerfreie Templates, Features und Web Parts. Deployt via WSP: Damit können die Customizations auf SharePoint 2010 installiert werden.
• Wurden Out-of-the-Box Site Definitions verändert, können diese Sites nicht migriert werden. Es bleibt nichts anderes übrig als den Content in neue Sites zu migrieren.
• Eventuell korrupte Datenbanken reparieren: Ansonsten tauchen die Probleme beim Upgrade auf.
• Und wer die grösste Sünde (Änderungen an der Content Datenbanken vorgenommen hat) begannen hat, muss diese Rückgängig machen. 

Mit Service Pack 2 und dem Oct 2009 CU von SharePoint 2007 wurde ein Pre-Upgrade-Checker mitgeliefert (stsadm Befehl). Das Tool liefert viele wichtige Informationen über die SharePoint Farm in einem Report. Weiter prüft es sämtliche Sites auf fehlende Site und List Definitions, Features und Assemblies. Auch Orphan Data (d.h. nicht mehr verknüpfte Sites, Lists, etc.) werden aufgespürt.

InfoPath Formulare können neu auch mit einem STSADM Befehl (exportIPFSAdminObjects) als WSP extrahiert werden und so auf die neue Farm gezügelt werden.

Customizations

Ist die Farm wie oben beschrieben stabilisiert worden, liegen die grössten Risiken bei den Customizations. Normale Web Parts und Workflows werden ohne Recompile lauffähig sein. Das Objektmodell ist mehrheitlich kompatible.

Wurden Customizations mit dem SharePoint Designer vorgenommen (customized files), gehen diese beim Switch auf das neue UI verloren. Bei Customizations, welche über WSP eingespielt wurden, stehen die neuen UI Funktionen logischer nicht zur Verfügung. In beiden Fällen gilt es vor dem Upgrade der Live Umgebung abzuklären, wie mit diesen Customizations weiter verfahren werden soll.

Fazit

Der Upgrade Prozess wurde in meinen massiv verbessert. Der SharePoint Admin hat viel die bessere Kontrolle. Bei den Customizations stellt sich die Frage, ob die Funktion mit SharePoint 2010 nicht out-of-the-box gelöst wird oder ob diese unter SharePoint 2010 weiterbestehen soll. Im zweiten Fall empfiehlt es sich, frühzeitig Tests durchzuführen. Bereits mit Beta 2 (ab November) kann der Upgrade getestet werden.