Teil 1–Migration der Project Server WSS_Content_DB mit aktivierten SQL RBS (Remote Blob Storage)

Vor langer Zeit installierte ich bei einem unserer Kunden einen Project Server 2013. Der Kunde benötigte neben der PWA ebenfalls die Projektwebsites (SharePoint-Teamswebsites) für die Ablage der Projektdokumente. Da neben der normalen PDF-, Word-, Excel- oder PowerPoint-Dateien eine große Zahl an Bilder für die Projektdokumentation benötigt wurden, wuchs die Größe der WSS_Content_DB schon nach einer kurzen Zeit stark an. Damals fragte mich der IT-Leiter, wie man das Problem lösen könnt und ich riet im die Verwendung des SQL-Features RBS (Remote Blob Storage). Dieses Feature ermöglicht größere Daten auf einen Filestore abzulegen. Damit werden nicht mehr die Dateien selber im SQL Server abgelegt, sondern nur noch der Link zu dem Dokument auf dem Fileserver (Dies nur grob erläutert). Wie man RBS einrichtet hatte ich damals in diesem Blog-Artikel erklärt (Link). Nach knapp sieben Jahren kam der Kunde auf mich erneut zu und möchte nun die Migration von Project Server 2013 (SharePoint Server 2013) auf SharePoint Server 2019 vornehmen. Dadurch stellte sich für mich die Herausforderung, die aktuelle WSS_Content_DB mit aktivierten RBS in die neue Umgebung zu migrieren. Da ich dieses Migrationsszenario nicht jeden Tag mache, suchte ich natürlich eine ordentliche Beschreibung im Internet. Leider blieb meine Suche erfolglos. Zwar fand ich einige Mosaik-Beschreibungen von einzelnen Schritten, nicht aber ein komplett beschriebenes How-To. Aus diesem Grund möchte ich den Wenigen helfen, die sich an dieser Dinosaurier-Technik versuchen müssen und genau wie ich vor der gleichen Herausforderung stehen.

Hinweis: Wie Sie sicherlich wissen kann man sehr viele Schritte über die PowerShell durchführen. Ich persönlich finde dies allerdings nicht besonders hilfreich für Menschen, die nicht besonders Fit im Umgang mit der PowerShell sind. Ich stelle immer wieder fest, dass oft einfache Sachen unnötig in die Komplexität ausgebreitet werden. Aus diesem Grund werde ich die meisten Beschreibungen über das SharePoint Admin-Center erläutern. Die Admins unter Ihnen, die mit der PowerShell fit sind, können die hier beschriebenen Schritte natürlich gerne über die PowerShell machen.

Im ersten Schritt werden wir nun die Relation beider Systeme anlegen.

Anlegen der neuen Teamwebsite

Legen wir also los. Im ersten Schritt müssen wir sicherstellen, dass die Website-Struktur des alten SharePoint Servers auch auf dem neuen SharePoint Server existiert. Das gilt nicht nur für die „Root-Site“, sondern auch für alle angelegten Sub-Sites. Schauen wir uns als erstes einmal die angelegte Website-Struktur auf dem alten Server an. Wechseln Sie hierzu auf ihren alten SharePoint Server und öffnen Sie die Central-Administration. Klicken Sie dann auf der linken Seite den Link „Anwendungsverwaltung“ und wählen Sie jetzt die Option „Alle-Websitesammlungen anzeigen“ aus.

Wählen Sie dann auf der rechten Seite die entsprechende Webanwendung aus. Ihnen werden nun alle Sub-Site angezeigt die unter der ausgewählten Websitesammlung liegen. Genau diese Hierarchie müssen Sie nun auf dem neuen Server anlegen.

Wichtig! Mit dem Anlegen der Sub-Sites ist es natürlich nicht getan.

Bitte beachten Sie, dass Sie sicherstellen müssen, dass neben dem richtigen Namen der Subsites auch das entsprechende Templates angelegt werden muss. Beim Project Server ist das relativ einfach, da hier von Seiten des Project Server in der Standardinstallation für Projektseiten immer das Template Teamwebsite bereitgestellt wird, ob das aber auch für alle bei Ihnen existierenden SharePoint-Website und Sub-Sites gilt müssen Sie überprüfen. Dies können Sie am einfachsten über die PowerShell durchführen. Öffnen Sie hierzu die ISE als Administrator auf dem SharePoint (Project Server). Binden Sie das SharePoint Modul mit dem folgenden Befehl ein:

„Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue“.

Geben Sie den danach den Befehl:

„Get-SPWeb http://intranet/websites/apps | Select-Object -Property WebTemplate“

ein, um das verwendete Template der Sub-Site /apps abzufragen. Wie Sie erkennen können besitzt die Sub-Site das Template „APPCATALOG“.

In diesem Fall ist die Schlussfolgerung, dass es sich um das Template APP-Katalog handelt relativ einfach. Wie sieht das ganze aber bei etwas selteneren benutzten Templates aus? Hierzu können Sie den Befehl „Get-SPWebTemplate“ nutzen und Ihnen werden alle Templates des SharePoint-Servers angezeigt.

Wechsel Sie nun auf Ihren neuen SharePoint Server und legen Sie dort alle Seiten genau wie auf dem Produktivsystem an! Dies können Sie einmal über die SharePoint-Central-Administration machen – oder natürlich über die PowerShell. Klicken Sie hierzu in der Central-Administration auf „Websitesammlungen erstellen“. Achten Sie darauf, dass Sie die richtige Webanwendung ausgesucht haben, in meinem Beispiel: „http://intranet“ und legen Sie hier die weiteren Sub-Sites an. Sollte die Webanwendung noch nicht existieren, so legen Sie diese ebenfalls, mit gleichem Namen und Port, wie auf dem alten SharePoint an.

Hinweis: Natürlich kann eine Websitesammlung nur einmal über eine URL aufgerufen werden. Ich empfehle eine alternative URL (Bsp.: http://intranet1) in Ihrem DNS-Server zu verwenden und diese dann in der entsprechenden neuen Teamwebsite als „Alternative Zugriffsordnung“ anzulegen. Konfigurieren Sie diese dann einfach als weitere Bindung in dem IIS-Server des neuen SharePoint.

Im zweiten Schritt werden wir nun den RBS auflösen und die Dateien zurück in die Datenbank migrieren. Danach werden wir eine neue Content-DB aus unserer Websitesammlung anlegen und dann die bestehenden Sub-Sites mit den Daten in diese Content-DB verschieben.