Sie haben Fragen zu diesem oder anderen Themen rund um SharePoint?
Kontaktieren Sie kostenfrei und unverbindlich unsere SharePoint-Experten.
Kontakt zu den SharePoint-Profis aufnehmenIn 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:
Planung
Bereitstellung der Infrastruktur des neuen Systems inkl. OS, Ports, Antivirus etc.
Bereitstellung der SQL-Ebene des neuen Systems inkl. Konfiguration
Installation und Basiskonfiguration des SharePoint
Anlegen der relevanten Webanwendungen
Anlegen der zur Funktion notwendigen Dienstanwendungen
Migration und Ausrollen der Custom-Solutions
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:
SPDSC-Durchlauf zur SharePoint-Basisinstallation
SPDSC-Durchlauf zum Ausrollen der migrierten Custom Solutions
Löschen der leeren Inhaltsdatenbanken auf der neuen Farm
Upgrade der migrierten Datenbank per Script und Mount-SPContentDatabase bzw. Upgrade-SPContentDatabase (bei uns ohne SPDSC)
Anpassung der Parameterdatei für die Farm entsprechend der neuen Datenbanknamen
Inkl. der kopierten Servicedatenbanken
Managed Metadata
Business Data Connectivity
Secure Store
PerformancePoint
User Profile wurde nicht migriert
Suche wurde nicht per SPDSC migriert
SPDSC-Durchlauf mit den kopierten Datenbanken
SPDSC korrigiert alle noch unterschiedlichen Werte
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
Kontaktieren Sie kostenfrei und unverbindlich unsere SharePoint-Experten.
Kontakt zu den SharePoint-Profis aufnehmenHinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!
Kommentar hinterlassen