Inhaltsdatenbank von SharePoint 2010 nach 2013 migrieren

Dieser Beitrag beschreibt, wie man eine Inhaltsdatenbank von SharePoint 2010 nach SharePoint 2013 migriert und welche Probleme dabei im Bezug auf die Authentifizierungsmethode auftreten können. Es geht dabei wirklich nur um die Vorgehensweise beim Migrieren einer Inhaltsdatenbank. Beim Planen und Durchführen einer kompletten Migration ist wesentlich mehr zu beachten! Hier finden sich dazu ausführliche Informationen bei TechNet.

Ich habe diesen Prozeß bereits einige Male gemacht, mußte aber immer wieder Kleinigkeiten z.B. zur genauen Syntax der PowerShell-Cmdlets nachschlagen. Es handelt sich hierbei also durchaus auch um eine Nachschlagemöglichkeit für mich selbst.

Datenbankbackup auf dem alten System

Zunächst wird die Inhaltsdatenbank vom alten zum neuen System verschoben. Es gibt dazu mehrere Möglichkeiten, aber die einfachste dürfte in den meisten Fällen Backup und Restore sein. Dazu verwendet man z.B. das SQL Management Studio. Weil es in diesem Blog in erster Linie um SharePoint und nicht um SQL Server geht, werden die einzelnen Schritte hier nur kurz erläutert.

Wenn man ein Backup einer Inhaltsdatenbank erstellen möchte, sollte man verhindern, daß ein SharePoint-Prozeß während des Backups in die Datenbank schreibt. Dazu kann man entweder die Verbindung zwischen SharePoint und SQL Server kappen oder den oder die SharePoint-Server herunterfahren oder ganz einfach die Datenbank auf read-only setzen. Natürlich kann in dieser Zeit kein SharePoint-Benutzer mit den Daten dieser Datenbank arbeiten.

Um eine Datenbank read-only zu machen, klickt man im SQL Management Studio mit der rechten Maustaste darauf und dann auf Properties. Die entsprechende Einstellung findet sich hier unter Options:

Jetzt kann man durch Rechtsklick > Tasks > Back Up… ein Backup der Datenbank erstellen. Dabei ist im Grunde nichts Besonderes zu beachten. Der Dialog kann z.B. so aussehen:

Falls die Benutzer mit dem alten System weiterarbeiten sollen, z.B. weil es sich nur um eine Testmigration handelt, kann jetzt die read-only Einstellung wieder von der Datenbank entfernt werden.

Datenbank auf dem neuen System wiederherstellen

Man kopiert sich jetzt die oben erstellte Backupdatei auf den neuen SQL Server (nur lokal abgelegte Dateien können wiederhergestellt werden). Über das SQL Management Studio legt man eine neue Datenbank an. Die Einstellungen sind dabei völlig egal. Über Rechtsklick auf die neue Datenbank und dann Tasks > Restore > Database stellt man jetzt das oben erstellte Backup auf dieser Datenbank wieder her.

Man wählt dazu unter Device die Datei aus und prüft unter Destination, daß die korrekte Datenbank überschrieben wird:

Unter Files kann man prüfen, daß die zugehörigen Datenbankdateien (mdf und ldf) auch an der gewünschten Stelle landen. Wichtig ist noch, daß unter Options der Haken bei Overwrite the existing database gesetzt wird:

 

Nach dem Wiederherstellen der Datenbank nicht vergessen, die read-only Einstellung wieder zu entfernen!

Datenbank prüfen

Zum Test, ob die Datenbank auf dem neuen System verwendet werden kann, gibt es ein PowerShell-Cmdlet. Man öffnet dazu eine SharePoint Management Shell als Administrator und gibt diesen Befehl ein:

Test-SPContentDatabase –Name <NameDerDatenbank> -WebApplication http://sharepoint

Das Cmdlet Test-SPContentDatabase ist hier beschrieben.

Falls das Cmdlet Warnungen betreffs fehlender Feature ausgibt, sollten die entsprechenden Solutions (WSPs) auf dem Zielsystem bereitgestellt werden. Man kann die Datenbank zwar trotzdem einbinden, aber die enthaltenen Sites werden dann höchstwahrscheinlich nicht (korrekt) funktionieren.

Classic und Claims Authentifizierung

Sehr häufig wird man bei einer Migration von 2010 nach 2013 von Test-SPContentDatabase aber folgende Meldung erhalten:

The web application is configured with claims authentication mode however the content database you are trying to attach is intended to be used against a windows classic authentication mode.

Bei SharePoint 2010 war die Verwendung der Claims Authentifizierung optional, während sie bei SharePoint 2013 Standard ist und genau das macht uns jetzt Probleme. Im Web findet man viele Anleitungen dazu, wie man mit der Problematik umgeht. Es werden jeweils zwei Möglichkeiten beschrieben:

Möglichkeit 1: Upgrade der Datenbank auf Claims im alten System vor dem Backup. Wie man das macht, ist hier beschrieben. Dabei werden allerdings Änderungen an einem bestehenden und eventuell produktiv genutzten System gemacht. Wenn z.B. die Migration erstmal nur getestet werden soll, ist das nicht unbedingt erwünscht.

Möglichkeit 2: Erstellen einer Classic Webanwendung in SharePoint 2013 per PowerShell, anhängen der Datenbank an diese Webanwendung und danach Upgrade auf Claims. Wie man das macht, ist hier beschrieben (weiter unten auf der Seite). Auch diese Vorgehensweise ist nicht immer praktikabel, well man dabei eine neue Webanwendung im Zielsystem benötigt. Wenn bereits eine Webanwendung mit Inhalt besteht und die Datenbank dort angehängt werden soll, ist dieser Weg nicht direkt gangbar.

Es gibt aber eine dritte Möglichkeit, bei der die Meldung ignoriert werden und die Datenbank trotzdem an die Webanwendung angehängt werden kann.

Datenbank anhängen

Die Datenbank wird mit Hilfe von PowerShell einer SharePoint-Webanwendung angehängt:

Mount-SPContentDatabase <NameDerDatenbank> -DatabaseServer <Servername> -WebApplication http://sharepoint

Das Cmdlet Mount-SPContentDatabase ist hier beschrieben.

Nach dem Anhängen der Datenbank kann ein Farmadministrator die in der Datenbank enthaltenen Websites im Browser aufrufen. Alle anderen Benutzer erhalten aber eine Zugriff verweigert Fehlermeldung. Um das zu reparieren, muß jetzt noch die Authentifizierung angepaßt und die Benutzer migriert werden. Das geht jetzt mit

Möglichkeit 3: per PowerShell nachträglich auf Claims umstellen. Dazu führt man in der SharePoint Management Shell folgendes aus:

$wa = Get-SPWebApplication http://sharepoint
$wa.MigrateUsers($true)
$wa.ProvisionGlobally()

Und schon sind alle Websitesammlungen der Datenbank migriert und können von allen Benutzern verwendet werden.