COMPAREX AG
Desired State Configuration und SharePoint – SharePointDSC: Vor- und Nachteile (Teil 1) (Header)

Desired State Configuration und SharePoint – SharePointDSC: Vor- und Nachteile (Teil 1)

Desired State Configuration (DSC) im SharePoint Umfeld – schöne neue Welt. In unserer Blogreihe zum Thema SharePointDSC widmen wir uns Fallstricken und entsprechenden Lösungen, Custom Scripts und Migrationsprojekten sowie Bugs und Fehlersuchen. Wir beantworten Fragen wie: Wie können wir DSC innerhalb einer Migration verwenden? Wie kann man DSC in anderen Projekten wiederverwenden? Welchen Vorteil hat SharePointDSC gegenüber normalen SharePoint Cmdlets? Es wird also spannend. In diesem Beitrag nähern wir uns dem Thema allgemein und erläutern zunächst Vorteile und Nachteile von SharePointDSC.

Ein Blogbeitrag von Henrik Krumbholz, Senior Consultant SharePoint

Endlich können wir unsere Systeme über alle Stages hinweg identisch halten und dies lediglich per Konfiguration. Alle Änderungen, die früher manuell gemacht wurden, können jetzt darüber abgedeckt werden. Änderungen, die außerhalb der Administratorverantwortung getätigt wurden, werden beim nächsten Durchlauf der DSC-Konfiguration wieder korrigiert. Wir müssen nicht mehr mit dem liebgewonnenen und robusten AutoSPInstaller arbeiten, der seine Vorteile hat, aber auch einige Nachteile.

Mit diesen Vorstellungen bin ich an die Verwendung von SharePointDSC (ich kürze es zur Vereinfachung mit SPDSC ab) gegangen, wie wahrscheinlich viele. Meine Erwartungshaltung war:

1. Aufsetzen mehrerer Farmen mit überschaubar großen Konfigurationsdateien.
2. Der Vorteil, eine Änderung zu machen.
3. Diese direkt ausrollen zu können.

Um die Spannung etwas herauszunehmen: Ich habe mich teilweise getäuscht. In der Blogserie möchte ich auf einige Dinge hinweisen und Erfahrungen teilen, die wir während eines Projekts mit SharePointDSC gemacht haben. Diese Blogserie ist keine Handlungsanleitung für die Verwendung von SharePointDSC. Wer die Blogs liest, ist danach nicht in der Lage, das gesamte SPDSC anwenden oder verstehen zu können. Das liegt zum einen daran, dass ich selbst nicht behaupten würde, SPDSC zu 100% zu verstehen, allerdings hat es für die Bereitstellung einer Farm mit über 400.000 Nutzern, 100 ContentDBs und 100 Custom Solutions gereicht. Zum anderen ist das Wiki des SPDSC sehr gut und die Blogserie ist nicht als Grundlagenschulung gedacht.

Vorteile des SPDSC

Microsoft bewirbt DSC in durchaus gewohnt charmanter Weise:

„Konfigurationen sind leicht zu lesen, zu speichern und zu aktualisieren. Konfigurationen definieren den Zustand, den Zielgeräte haben sollen, anstatt Anweisungen zu schreiben, wie diese in den jeweiligen Zustand versetzt werden können. Dadurch ist der Aufwand wesentlich geringer, eine Konfiguration über DSC zu erlernen, zu übernehmen, zu implementieren und beizubehalten. Das Erstellen von Konfigurationen bedeutet, dass komplexe Bereitstellungsschritte als kompakte Lösung an einem zentralen Ort erfasst werden. Dadurch wird die wiederholte Bereitstellung bestimmter Computergruppen wesentlich weniger fehleranfällig. Auf der anderen Seite werden Bereitstellungen schneller und zuverlässiger, sodass sich komplexe Bereitstellungen schneller realisieren lassen.“ (1)

Klingt großartig und ist es in der Theorie auch. Jetzt kommt die Überraschung: Auch in der Praxis überzeugt SPDSC, wenn man die anfänglichen Hürden überwunden hat. Die Trennung von Konfiguration und Logik ist ein gewohntes Mittel in der IT und auch schon beim AutoSPInstaller realisiert, wenn auch mit einigen hart kodierten Fallstricken. Das SPDSC hat den Vorteil, dass die Fehlerquellen meist beim Anwender und nicht im SPDSC selbst liegen.

In der Regel gibt es beim SPDSC zwei Ebenen:

SharePointDSC, Abbildung 1: Aufbau der DSC-Skripte, Quelle: COMPAREX 
Abbildung 1: Aufbau der DSC-Skripte, Quelle: COMPAREX

In Abbildung 1 erkennt man, dass es ein „einziges Skript“ (in Realität die SPDSC-Ressourcen) gibt, das die Logik enthält. Die Konfigurationsdateien mit bspw. unterschiedlichen URLs sind pro Stage getrennt, aber werden durch die Logik immer identisch ausgeführt.

Einmal verstanden ist der Aufbau auch relativ simpel. Um bis dorthin zu kommen, dauert es aber einen Moment. Die Logik wird durch die SPDSC-Ressourcen bereitgestellt und der Anwender kommt damit nicht direkt in Kontakt. Die Konfigurationsdatei ist eine reine ps1-Datei, die der Anwender selbst verfasst.

Mithilfe von aktuell über 100 Ressourcen, die die verschiedensten Dinge tun und in den SPDSC-Modulen gekapselt sind, ist das Gros an SharePoint Einstellungen erschlagen. Die Dokumentation ist, wie erwähnt, recht gut und die Community sehr rege. Auch wenn OpenSource-Projekte manchmal belächelt werden, hat dies durchaus den Vorteil, potenzielle Fehler im Code direkt beseitigen zu können.

Die SPDSC-Ressourcen funktionieren über drei Methoden – Get, Test, Set.

Get: Gibt mir die Konfiguration zurück
Bspw.: Rückgabe des Managed Accounts im Modul SPManagedAccount

Test: Testet auf die korrekte Implementierung
Bspw.: Ist der Managed Account vorhanden

Set: Setzt die Konfiguration insofern der Test fehlschlägt
Bspw.: Setzen des Managed Account

SharePointDSC, Abbildung 2: Ablauf innerhalb einer DSC-Ressource - in der Regel, Quelle: COMPAREX

Abbildung 2: Ablauf innerhalb einer DSC-Ressource - in der Regel, Quelle: COMPAREX

Das bedeutet: Es wird ein Test gemacht, der sich die aktuelle Konfiguration holt, gegen den gewünschten Status prüft (deswegen übrigens auch Desired State Configuration) und true oder false zurückgibt. Bei false wird die Set-Methode ausgeführt und so die gewünschte Konfiguration hergestellt – einfach oder? Ja, deshalb kommen wir zu den Nachteilen.

Nachteile des SPDSC

Wie das immer so ist mit Tests: Wenn der Test unglücklich formuliert ist, ist er erfolgreich, aber die Umsetzung vielleicht trotzdem fehlerhaft. Je besser der Test, desto besser auch das Ergebnis – klingt wie eine Phrase aus einem Unilehrbuch, ist aber in diesem Fall tatsächlich hilfreich. Auch AutoSPInstaller hat Tests integriert, die aber, soweit ich bisher feststellen konnte, oft nur die reine Existenz der bspw. Dienst- oder Webanwendung testen. Das ist schon mal viel wert, bringt mir bei Konfigurationsänderungen allerdings nicht viel.

Die Konfigurationsdatei ist vom Nutzer selbst zu verfassen. Diese muss in der Regel in jedem Projekt neu geschrieben werden.

Nicht alle möglichen Konfigurationen sind im SPDSC integriert, weshalb an den jeweiligen Stellen nachgearbeitet werden muss. Entweder über eigene Erweiterungen im SPDSC oder individuelle Skripte, die separat angestoßen werden. Zudem kapselt SPDSC in der Regel auch „nur“ SharePoint Cmdlets, weshalb die Unzulänglichkeiten dieser Befehle auch hier greifen – insofern bekannt, sind diese aber teilweise auch schon behoben bzw. wurden umgangen.

$ma = Get-SPManagedAccount -Identity $params.AccountName -ErrorAction SilentlyContinue

Code 1: Aufruf eines Standard-Cmdlets in der SPDSC-Ressource SPManagedAccount.

SharePointDSC funktioniert weiterhin nur für SharePoint 2013 SP1 oder höher. Es lässt sich darüber streiten, ob das ein Nachteil ist. SharePoint Foundation ist ebenfalls nicht unterstützt – ist wohl auch zu verkraften.

SharePointDSC, Abbildung 3: Vor- und Nachteile der einzelnen Methoden zur Installation und Konfiguration von SharePoint. Der Wizard ist keine Option. Die Bewertung erfolgte subjektiv. (Quelle: COMPAREX)Abbildung 3: Vor- und Nachteile der einzelnen Methoden zur Installation und Konfiguration von SharePoint. Der Wizard ist keine Option. Die Bewertung erfolgte subjektiv. Quelle: COMPAREX

Voraussetzungen und Ausführung

Alle Voraussetzungen, die gegeben sein müssen, um mit SharePointDSC zu arbeiten, sind der Dokumentation zu entnehmen. Mithilfe der Codeverwaltung wie TFS oder Git ist dann sogar eine sehr gut nachvollziehbare Historie möglich.

Die Ausführung des SPDSC auf den Servern ist recht simpel, wenn man die simple Variante nimmt: Ausführung auf dem oder den Zielrechnern. Bei der wollen wir es hier auch erstmal belassen. Dabei müssen folgende Schritte getan werden:

1. Kopie aller relevanter Dateien auf den Zielrechnern

1.1. SPDSC-Module
1.2. Installationsdateien (sinnigerweise auf jeden Fall die von SharePoint)
1.3. Konfigurationsskripte

2. Installation aller relevanten SPDSC-Module (einmalig, insofern keine neuen Module)
3. Ausführen des SPDSC

Sieht einfach aus und ist es schlussendlich auch. Die große Herausforderung ist, die Skripte korrekt zu formulieren und, sobald die Farmen aufgesetzt sind, dem stetigen Wandel der eigenen IT-Landschaft Rechnung zu tragen und so einen Mehrwert als ein Hindernis zu erzeugen.

Allgemeines Fazit

SharePointDSC dient dazu, Farmen mit gleichen Konfigurationen ohne großen Aufwand aufzusetzen und auch schnell wieder in den definierten Zustand zurückzuversetzen, um so Wildwuchs zu vermeiden. Es ersetzt keine genaue Planung und Anforderungsanalyse. Es gibt, wie sollte es bei so einem komplexen System wie SharePoint auch anders sein, zahlreiche Hürden, die mit Erfahrung und etwas Verständnis für die Materie gemeistert werden müssen. Damit Sie nicht bei allen Hürden stürzen, folgen in Kürze einige nähere Informationen zu Fallstricken, Lösungen und anderen interessanten Geschichten aus der SharePointDSC Welt.

Überblick über die Themen der Blogreihe:

Ihr nächster Schritt

Sie wünschen eine persönliche Beratung und weitere Informationen über das COMPAREX SharePoint Portfolio? Kontaktieren Sie uns und wir zeigen Ihnen wie SharePoint in Ihrem Unternehmen erfolgreich eingesetzt werden kann.

Jetzt Kontakt aufnehmen

(1) https://docs.microsoft.com/de-de/powershell/dsc/decisionmaker
(2) Von Null beginnend
(3) Vollständigkeit aller Konfigurationsmöglichkeiten
(4) Anpassung der Konfigurationen
(5) Bspw. neue Server hinzufügen
(6) Existenz valider Tests

Diesen Artikel teilen

Artikel vom:
25.10.2018

geschrieben von:

TAGS:
DSC, SharePoint

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben