COMPAREX AG
Desired State Configuration und SharePoint: Nutzung von DSC in einem Migrationsprojekt, Teil 4 (Header)

Desired State Configuration und SharePoint: Nutzung von DSC in einem Migrationsprojekt (Teil 4)

Im dritten Teil der Blogreihe ging es um Custom Scripts und ihre Herausforderungen. Nach dem recht tiefen Thema bewegt sich Teil 4 wieder etwas aus der Materie heraus. 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.

Ein Blogbeitrag von Henrik Krumbholz, Senior Consultant SharePoint

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.

Vorüberlegungen bei einer „normalen” Migration

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
4.1. Anlegen der relevanten Webanwendungen
4.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.

Szenario im Beispielprojekt

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.

Planung

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.

Implementierung und Schritte

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
5.1. Inkl. der kopierten Servicedatenbanken
5.1.1. Managed Metadata
5.1.2. Business Data Connectivity
5.1.3. Secure Store
5.1.4. PerformancePoint
5.2. User Profile wurde nicht migriert
5.3. Suche wurde nicht per SPDSC migriert
6. SPDSC-Durchlauf mit den kopierten Datenbanken
6.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.

Manuelle Schritte nach der Migration

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

Setzen des Secure Store MasterKeys

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

Abbildung 1: Setzen des Secure Store MasterKeys. (Quelle: COMPAREX)Abbildung 1: Setzen des Secure Store MasterKeys. (Quelle: COMPAREX)

Setzen des Unattended Service Account

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.

Abbildung 2: Setzen des Visio Unattended Service Accounts. (Quelle: COMPAREX)
Abbildung 2: Setzen des Visio Unattended Service Accounts. (Quelle: COMPAREX)

Kundenspezifische Anpassungen

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:

Abbildung 3: Setzen des PropertyBags einer Webanwendung. (Quelle: COMPAREX) 
Abbildung 3: Setzen des PropertyBags einer Webanwendung. (Quelle: COMPAREX)

Fazit

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 in Teil 5 eingehen – Bugs und Fehlersuche.

Überblick über die Themen der Blogreihe

Sie haben Fragen zu diesem oder anderen Themen rund um SharePoint?

Kontaktieren Sie kostenfrei und unverbindlich unsere SharePoint-Experten.

Kontakt zu den SharePoint-Profis aufnehmen

Diesen Artikel teilen

Artikel vom:
22.01.2019

geschrieben von:

TAGS:
SharePoint

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben