Desired State Configuration und SharePoint: Nutzung von DSC in einem Migrationsprojekt

In unserem Beispielprojekt soll es um die Migration von SharePoint 2013 auf 2016 mittels SharePointDSC und MinRole gehen. Wie muss die Projektplanung aussehen, welche Teilschritte sind zu gehen und welche Fallstricke treten bei der Implementierung oder im Nachgang auf? Hier gibt es die Antworten.

SharePointDSC in einem Migrationsprojekt zu verwenden, erfordert nochmal eine Ebene mehr an Planung und Struktur, denn der reine Durchlauf des SPDSC erfüllt eben nicht die Anforderungen, die ein Migrationsprojekt im Allgemeinen hat – unabhängig von den speziellen Anforderungen des Kunden während der Migration. Wir beschränken uns hier tatsächlich nur auf SPDSC.

Vermutlich geht jeder Consultant anders an eine Migration heran, aber die wesentlichen Schritte sollten in der Regel gleich sein:

1. Planung

2. Bereitstellung der Infrastruktur des neuen Systems inkl. OS, Ports, Antivirus etc.

3. Bereitstellung der SQL-Ebene des neuen Systems inkl. Konfiguration

4. Installation und Basiskonfiguration des SharePoint

   1. Anlegen der relevanten Webanwendungen

   2. Anlegen der zur Funktion notwendigen Dienstanwendungen

5. Migration und Ausrollen der Custom-Solutions

6. Migration der Datenbanken

Im Groben lässt sich jede Migration wohl auf diese Schritte zurückführen. Je nach Farm kommen dann noch Nintex-Migrationen, ScheduledTasks, manuelle web.config-Anpassungen (OMG! Please don’t!), Feature-Aktivierungen und so weiter hinzu.

Grundsätzlich passiert bei einer Migration mithilfe von SPDSC auch nicht viel anderes. Mit Ausnahme der Schritte, die SharePoint betreffen, wird auch alles genau so ausgeführt. Die Installation des SharePoint erfolgt dann aber per SPDSC.

In unserem Beispielprojekt migrieren wir von SharePoint 2013 auf 2016. Wir müssen also auch MinRole bedenken. Weiterhin stehen in der alten Farm zwei APP- und zwei WFE-Server, während in der neuen Farm zwei APP- und drei WFE-Server vorhanden sein werden. Aufgrund verschiedener Voraussetzungen haben wir folgende MinRole-Verteilung:

• APP-Server: Custom

• WFE-Server: Front-End with Distributed Cache

Es besteht kein Internetzugriff auf den Servern. Es werden vier Webanwendungen (inkl. MySites) migriert, deren Datenmenge etwa 3TB, 100 Inhaltsdatenbanken und 1.500 SiteCollections umfasst. Es gibt circa 100 individuelle Farm Solutions, etwa 400.000 Nutzerprofile und 15 Inhaltsquellen der Suche. Migriert werden sollen zudem verschiedenste Dienstanwendungen (Suche, Secure Store etc.). Hinzu kommt die Verwendung von zahlreichen Nintex-Workflows, Reports mithilfe von Reporting Services, verschiedenste PowerShell-Skripte, die über den Windows Task Scheduler getriggert werden und alles per SSL und Kerberos.

Gelinde gesagt: Wir haben ein Brett vor der Brust.

Bevor man ein solches Projekt anfängt, empfiehlt es sich, mit dem Kunden zu klären, was das SPDSC machen muss und was nicht. Erwartungshaltungen zu klären, ist grundsätzlich eine gute Sache und in diesem Fall auch. Entschieden wurden folgende Punkte:

• Installation des SharePoint

• Konfiguration des SharePoint

  • Alle relevanten Dienstanwendungen

  • Alle relevanten Webanwendungen

• Konfiguration der Server

  • Setzen von Berechtigungen

  • SQL-Aliase

  • Registry-Einträge etc.

• Konfiguration der Dienstanwendungen

  • SyncConnections des User Profile Service etc.

• Ausrollen der migrierten Custom Solutions

Die große Frage ist: Was macht SPDSC, wenn die Datenbanken aus dem alten System dazukommen?

Schlussendlich müssen Sie für jede einzelne Web- und Dienstanwendung entscheiden, ob, wie und wann diese migriert wird. Die Nutzung einer migrierten Inhaltsdatenbank im SPDSC für eine bestehende Webanwendung stellt kein Problem dar. Die Konfiguration muss einfach korrekt sein. Den Rest erledigt SPDSC.

Folgende Schritte haben im Beispielprojekt zum Erfolg geführt:

1. SPDSC-Durchlauf zur SharePoint-Basisinstallation

2. SPDSC-Durchlauf zum Ausrollen der migrierten Custom Solutions

3. Löschen der leeren Inhaltsdatenbanken auf der neuen Farm

4. Upgrade der migrierten Datenbank per Script und Mount-SPContentDatabase bzw. Upgrade-SPContentDatabase (bei uns ohne SPDSC)

5. Anpassung der Parameterdatei für die Farm entsprechend der neuen Datenbanknamen

   1. Inkl. der kopierten Servicedatenbanken

      1. Managed Metadata

      2. Business Data Connectivity

      3. Secure Store

      4. PerformancePoint

   2. User Profile wurde nicht migriert

   3. Suche wurde nicht per SPDSC migriert

6. SPDSC-Durchlauf mit den kopierten Datenbanken

   1. SPDSC korrigiert alle noch unterschiedlichen Werte

7. Manuelle Schritte im Nachgang

SPDSC ist tatsächlich so intelligent und migriert die oben angegebenen Service Applications. Vermutlich funktioniert das auch für den User Profile und die Suche, aber diese wurden im Projekt aus anderen Gründen im Nachgang migriert bzw. gar nicht migriert. Es gibt allerdings ein paar Dinge, die nicht funktionieren und die als Custom Script eingebaut oder als Post-Migrations-Schritt durchgeführt werden müssen.

Unabhängig von den Themen, die im SPDSC als reine Implementierung fehlen, wie zum Beispiel der Search Alert, gibt es einige zusätzlichen Dinge, die bei einer Migration beachtet werden müssen.

Der Secure Store MasterKey muss nach der Migration erneut gesetzt werden – und zwar mit dem Wert aus der alten Umgebung.

Die Unattended Service Accounts für PerformancePoint und Visio Services sind nach der Migration mit SPDSC nicht mehr gesetzt und müssen im Nachgang gesetzt werden. Passen Sie aber auf, dass Sie dann im Secure den korrekten Account hinterlegen.

Führen Sie kundenspezifische Anpassungen aus, wie zum Beispiel die Aktivierung von Features oder das Setzen von PropertyBag-Einträgen. PropertyBag-Einträge an der WebApplication werden durch eine Migration nicht gesetzt und es gibt dafür bis jetzt auch keine SPDSC-Ressource. Diese musste als Custom Script implementiert werden, was bei uns wie folgt aussieht:

Es ist kaum zu glauben, aber bei einer Migration mit SPDSC sind am Ende nicht so viele allgemeine Sachen zu beachten. Die kundenspezifischen Anforderungen sind da deutlich komplizierter. Der oben beschriebene Ansatz funktioniert überraschend gut und mit ein bisschen gesundem Menschenverstand und einer ausreichenden Prise Respekt ist SPDSC sehr gut dafür geeignet. Hätte man im Beispielprojekt jetzt auch schon eine Konfiguration der alten Farm gehabt, hätte man sicherlich viel Zeit und Nerven sparen können. Und das ist auch ein Punkt, auf den wir im nächsten Teil eingehen – Bugs und Fehlersuche.

Überblick über die Themen der Blogreihe

• Desired State Configuration und SharePoint – SharePointDSC: Nutzung von DSC in einem Migrationsprojekt

• Desired State Configuration und SharePoint – SharePointDSC: Bugs und Fehlersuche