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.

Ein Gedanke zu “Inhaltsdatenbank von SharePoint 2010 nach 2013 migrieren

  1. (Paperback) First off, Other than Mathew Ranletts posting (in which I am in colpmete agreement) I’m very surprised at the previous posts This book is a must have no matter where you sit regarding experience. If you are a Novice or Expert, there is a TON of great information (contrary to a previous post)and Code Examples . Every SharePoint book that I have purchased has several Chapters that are middle of the road with a few that hit the mark. However, this book seemed to stay on track and serve up the content to help our SP dev team make the decisions required for a Vnext product. We are in the process of upgrading all of our SharePoint code from 2007 to 2010 in which this book was a key read in order to plan and explore the plethora of new features and functionalities in which dovetail with the current suite of features added to 2010.Personally this book is a Must Have hands down.Great Job to the Authors!

    Gefällt mir

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s