Sandra Erb

Der folgende Beitrag spiegelt unsere Erfahrungen mit der Variante der Database Migration als Migrationsart von SharePoint 2007 nach SharePoint 2010 und beleuchtet einige Eigenheiten dieser Variante. Eine Übersicht über die verschiedenen Upgrade Möglichkeiten können diesem Beitrag entnommen werden.

Für die Migration des ORAYLIS internen MOSS 2007 auf SharePoint 2010 haben wir uns für den Weg der Database Migration entschieden. Dieses Vorgehen wurde vor allem gewählt, da die Migration auch gleichzeitig genutzt werden sollte, um einige infrastrukturelle Änderungen vorzunehmen. Außerdem kann auf diese Art und Weise vermieden werden, dass Altlasten aus dem bestehenden System übernommen werden. Auch ist die Ausfallzeit des Systems bei dieser Variante am geringsten.

Einem erfahrenen SharePoint Administrator sollte das Upgrade mit Hilfe der Database Migration keine allzugroßen Probleme bereiten. Vorteilhaft ist es, wenn bereits Erfahrungen mit dem Austausch oder Umzug der Content Datenbanken gemacht wurden. Und – wie bei so vielen Aufgaben – ist auch hier die Vorbereitung das halbe Leben. Die Dokumentation von Microsoft zum Upgrade sollte gelesen und verstanden sein, genauso sollte bereits im Vorfeld ein wenig Erfahrung mit den neuen Features von SharePoint 2010 gesammelt werden.

Jedem, der die Variante der Database Migration wählt, rate ich dringend dazu, einen “Probelauf” zu machen, bevor der neue SharePoint Server live geschaltet wird. Dies ermöglicht es, die neue Umgebung ausgiebig zu testen, ohne die Endbenutzer zu beeinträchtigen.

Vorbereitung

Als erstes sollte mit Hilfe des PreUpgradeChecks (stsadm Befehl ab MOSS SP 2) überprüft werden, ob es mögliche Konflikte innerhalb der Farm gibt. Der PreUpgradeCheck nimmt keine Modifikationen an der bestehenden Umgebung vor. Aufkommende Konflikte sollten gelöst werden, bevor mit der Migration begonnen wird.

Läuft der PreUpgradeCheck ohne Probleme durch, so kann die zweite Farm aufgesetzt werden. In dieser müssen alle Anpassungen (eigene oder Third Party Features, Solutions, Webparts, Themes etc.) installiert werden, welche derzeit noch von der alten Farm verwendet werden. Alle diese Anpassungen müssen 64Bit fähig sein!

Wer längere Zeit SharePoint 2007 administriert und konfiguriert hat, der wird während der Konfiguration von SharePoint 2010 vieles wiedererkennen. Sofort ins Auge springt die Unterstützung durch einen zweiten Wizard in der Central Administration und die Service Applications. In meinen Augen sollte grade den Service Applikationen der Office Web Apps und der sogenannten “User Profile Service Application” besonders viel Aufmerksamkeit geschenkt werden.
Die “User Profile Service Application” ersetzt den Teil des Shared Service Providers, welcher früher für die Benutzerprofile und MySites zuständig war.

Die Installation und Grundkonfiguration von SharePoint 2010 unterscheidet sich nicht sonderlich von der des SharePoint 2007. Interessant wird dies erst bei der Konfiguration der Service Applications. Allerdings nimmt hier der neue Configuration Wizard in der Central Administration auch eine Menge Arbeit ab.

Language Packs

Alle Language Packs, welche im bisherigen SharePoint 2007 im Einsatz waren, müssen auch auf dem neuen SharePoint 2010 Server installiert werden.
Liegt z.B. eine Site in einer Sprache vor, für welche kein Language Pack installiert wurde, so lässt sich diese Site ohne das entsprechende Language Pack nicht öffnen!

Steht die neue Farm, so kann ein erster Probelauf durchgeführt werden. Bei diesem “Probelauf” wird die neue SharePoint 2010 Farm bereits vollständig konfiguriert und eingerichtet. All diese Einstellungen müssen bei der Übernahme der endgültigen Content Datenbank nicht erneut vorgenommen werden, diese bleiben erhalten.

Datenbank Migration

Als erstes müssen die alten Inhaltsdatenbanken auf dem neuen SQL Server wiederhergestellt werden. Dies kann einfach mit Hilfe der Backup und Restore Funktionalität des SQL Servers erfolgen.

Über die Central Administration muss zunächst eine neue Web Applikation erstellt werden, in welcher später das Portal liegen soll. Bei der Erstellung der neuen Web Applikation wird auch eine neue Content Datenbank angelegt. Diese kann später wieder gelöscht werden.

Zur Sicherheit sollte an dieser Stelle noch der PowerShell Befehl “Test-SPContentDatabase” ausgeführt werden, um sicher zu stellen, dass auch tatsächlich alle erforderlichen Komponenten installiert wurden:

Test-SPContentDatabase -Name <alte Content Datenbank> -WebApplication <URL zur neu angelegten Webapplikation>

Ist auch dieser Test erfolgreich, so kann der neuen Applikation die “alte” Content Datenbank zugewiesen werden.
Wer bereits Erfahrungen mit dem Anfügen von Content Datenbanken hat, dem werden die folgenden Schritte bekannt vorkommen.

  1. In der SharePoint Central Administration in den Bereich Application Management wechseln
  2. Die Seite “Manage content databases” aufrufen

    clip_image0016

  3. Nicht vergessen die neu erstellte Applikation auszuwählen

    clip_image0026

  4. Die alte Content Datenbank entfernen

    clip_image0036

  5. Mit Hilfe des stsadm Befehls “addContentDB” oder über die PowerShell mit “Mount-SPContentDatabase”  die neue Content Datenbank anfügen. Mit diesen Befehlen wird die Datenbank automatisch migriert. In unserer Umgebung hat die Migration einer Content Datenbank mit ca. 3,5 GB knapp 15 Minuten gedauert.
  6. Überprüfen des Upgrade Status in der Central Administration:
    Central Administration –> Upgrade and Migration –> Check upgrade Status

Das ist bereits alles. Natürlich muss dieses Vorgehen für alle Content Datenbanken wiederholt werden. Sollen auch die MySites migriert werden, so muss auch der Shared Service Provider migriert werden.

Sowohl bei dem stsadm Befehl “addContentDB”, als auch beim äquivalenten PowerShell Befehl “Mount-SPContentDatabase” besteht die Möglichkeit zu wählen, ob der Content noch im alten SharePoint 2007 Style, oder direkt im neuen SharePoint 2010 Layout inklusive Ribbons angezeigt werden soll. Setzt man das Flag nicht, so wird standardmäßig das alte Layout beibehalten. Dieses kann später über das Visual Upgrade manuell geändert werden.

Reporting Services (Integrierter Modus)

Waren Reporting Services Reports vorhanden, so müssen diese neu bereitgestellt werden.

Funktionstest

Nachdem die alte Content Datenbank der neuen Applikation zugewiesen wurde, sollte das Portal aufgerufen und getestet werden. Die folgenden Punkte sollten überprüft werden:

  1. Lassen sich alle Seiten öffnen?
  2. Funktionieren alle Webparts?
  3. Wurde das alte Layout fehlerfrei übernommen? / Wird die neue Ribbon Oberfläche angezeigt?
  4. (optional) Funktionieren Reports (sowohl Reporting Services, wie auch Excel Services)?
  5. (optional) Können die neuen Office Web Apps genutzt werden?
  6. (optional) Funktionieren die MySites?
  7. (optional) Funktioniert die Suche?

Des Weiteren sollte nun sowohl das Windows Event Log, wie auch die SharePoint Logs nach Fehlern überprüft und eine Weile beobachtet werden.

Abschluss

Waren alle Tests erfolgreich, kann die endgültige Migration durchgeführt werden:

  1. die alte SharePoint 2007 Farm offline nehmen
  2. ggf. erneut ein Backup der alten Content Datenbank erstellen und diese der neuen Webapplikation hinzufügen. Die Konfigurationen innerhalb der Service Applications müssen nicht neu gesetzt werden. Das Anfügen der alten Content Datenbank hat ausschließlich Auswirkungen auf die Web Applikation, zu welcher die Datenbank gehört.
  3. Den neuen SharePoint Server 2010 live schalten

Fazit

Die Database Migration ist für einen erfahrenen SharePoint Administrator kein Problem. Die meiste Arbeit mach das Installieren und Konfigurieren der neuen Umgebung. Die eigentliche Migration ist im Gegensatz hierzu schnell gemacht und mit wenig Aufwand verbunden.
Desweiteren bietet Sie die optimalen Voraussetzungen für eine (zumindest für den Benutzer) sehr schnelle und unkomplizierte Umstellung. Die Database Migration ist mein absoluter Favorit und eigentlich für alle empfehlenswert, die eine schnelle, sichere und saubere Lösung bevorzugen.