COMPAREX AG
Desired State Configuration & SharePoint – SharePointDSC: Fallstricke, Probleme & Lösungen (Teil 2) (Header)

Desired State Configuration & SharePoint – SharePointDSC: Fallstricke, Probleme & Lösungen (Teil 2)

Im ersten Teil der Blogserie wurden allgemeine Fragen z.B. „Wie arbeitet SharePointDSC (SPDSC)?“ oder „Welche Ressourcen gibt es?“ beantwortet. In diesem Teil geht unser Experte bereits etwas tiefer in die Materie und versucht einige Fallstricke, Probleme und, insofern vorhanden, deren mögliche Lösung darzustellen. Diese Probleme beziehen sich dabei in der Regel auf Unwissenheit des Anwenders und nicht auf die womöglich fehlerhafte Implementierung.

Ein Blogbeitrag von Henrik Krumbholz, Senior Consultant SharePoint

Problem: Zu viele Konfigurationen

Ein Vorteil von SPDSC ist unter anderem die Bereitstellung identischer Farmen für bspw. eine Test-, Produktiv- und Integrationsumgebung. So können Tests für Produktivumgebungen relativ einfach auf Testumgebungen durchgeführt werden. Der Nachteil ist allerdings, dass für alle Umgebungen tatsächlich eigene Konfigurationen geschrieben werden müssen, die sich meist (so sollte es sein) nur in den jeweiligen Parametern unterscheiden. Das Setzen des SQL-Alias zum Beispiel ist in jeder Farm identisch, nur der Alias ist anders. Man hat also stets dieselbe SPDSC-Ressource, aber verschiedene Parameter.
Das ist nicht immer ein Problem, kann aber zu einem werden, weshalb ich in unserem Beispielprojekt mit einer weiteren Datei arbeite.

Lösung/Workaround: Konfiguration vs. Parameter

Diese Datei kann viele lustige Namen haben und heißt bei mir Parameterdatei. Die Konfigurationsdatei bleibt für alle Farmen identisch, nur die Parameterdatei ist pro Umgebung unterschiedlich. Das hat auch den Vorteil, dass die Konfigurationsdatei in zahlreichen Projekten genutzt werden kann. Die Struktur ist für unser Beispielprojekt dann wie folgt:

Abbildung 1: Struktur der SPDSC-Dateien. (Quelle: COMPAREX) 
Abbildung 1: Struktur der SPDSC-Dateien. (Quelle: COMPAREX)

Die Parameterdatei beinhaltet tatsächlich nur zahlreiche Parameter, die bei mir wie folgt aufgeschlüsselt sind:

Abbildung 2: Beispiel einer Parameterdatei. (Quelle: COMPAREX) 
Abbildung 2: Beispiel einer Parameterdatei. (Quelle: COMPAREX)

Innerhalb des AllNodes-Elements befinden sich meine Server. Innerhalb des NonNodeData befinden sich alle allgemeinen Punkte, wie Installationspfade, Serviceanwendungen und deren Parameter oder auch zu installierende Farm Solutions. Die Parameterdatei wird dann an die Konfiguration übergeben.

Problem: Nutzung der richtigen PowerShell

Die eigentlich erste Grundlage für SharePointDSC ist die korrekte PowerShell. Laut SPDSC-Wiki ist dafür mindestens die Version 4.0 notwendig. Die Version 5.0 ist allerdings empfohlen. Ich kann nur raten, dieser Empfehlung zu folgen und ich möchte diese auch noch ergänzen: Wenn Sie mit mehreren Leuten an einem Projekt bzw. auf mehreren Servern arbeiten, nutzen Sie auf gar keinen Fall unterschiedliche PS-Versionen. So schnell wie Ihnen dort graue Haare wachsen, können Sie gar nicht nachfärben. Dabei handelt es sich nicht unbedingt um fehlerhafte oder zusätzliche Module, sondern schlicht um unterschiedliches Verhalten identischer Aufrufe – und zwar nicht nur von SPDSC-Ressourcen, sondern auch von Standardmethoden. Das klingt nicht kritisch, aber wenn Ihnen ein Fehler bei einem Standard-Commandlet von Microsoft ausgeworfen wird und der Kollege nebenan keine Probleme hat, dann ist die PS-Version nicht zwingend das Erste, was Sie checken – jedenfalls checke ich das nicht sofort. In der Regel gehe ich davon aus, dass an Grundlagen nicht viel geändert wird.

Zusammenfassend:

  • Identische PowerShell-Version auf allen relevanten Servern verwenden
    • Sowohl Entwicklungsrechner für Projektmitarbeiter als auch
    • Zielserver des Kunden
  • Testen Sie die Skripte in jedem Projekt neu

Folgen Sie am besten auch der Empfehlung, PowerShell 5.1 zu installieren. In unserem Projekt haben wir das Windows Management Framework 5.1 installiert.

Dass die ausführende PowerShell als Administrator gestartet werden sollte, um unangenehme Fehlermeldungen zu vermeiden, muss ich im SharePoint-Umfeld wohl nicht erwähnen.

Lösung/Workaround: Empfohlene PowerShell-Version nutzen

Installieren Sie auf allen Servern die gleiche und empfohlene PowerShell-Version.

Problem: Debugging

Debugging – essenziell in jeder Entwicklung und anstrengender, je komplexer die Systeme werden. Auch SPDSC lässt sich nicht wirklich einfach oder intuitiv debuggen. Eine ziemlich komplette Anleitung, um SPDSC zur Laufzeit zu untersuchen, findet sich auf der Seite von Microsoft. Dort sind alle wesentlichen und vor allem funktionierenden Schritte dargestellt.

Ich möchte mich an dieser Stelle mit Bewertungen zurückhalten, da ich nicht tief genug in diesem Debug-Prozedere stecke, als dass ich eine valide Aussage treffen könnte. Zudem bin ich noch zu sehr vom Visual Studio Debugging verwöhnt. Die untenstehende Lösung funktioniert, aber ob sie schön ist, bleibt Ansichtssache. Ich drücke Ihnen die Daumen, dass Sie es nicht herausfinden müssen.

Lösung/Workaround: Schrittweise Ressourcen implementieren

Nutzen Sie die Debugging-Lösung von Microsoft für SPDSC bzw. DSC im Allgemeinen.

Alternativ, und so bin ich an die Sache herangegangen bzw. würde es beim nächsten Mal tun, arbeiten Sie schrittweise. Implementieren Sie eine Ressource nach der anderen, um nicht 5.000 Zeilen Konfiguration zu schreiben, um am Ende eine bestimmte Nadel im Nadelhaufen zu suchen.

Problem: Größe der Konfigurationsdateien

MOF-Dateien (Managed Object Format) werden in der SPDSC-Welt einfach gesagt zur Abbildung der Konfiguration für die Ausführung erstellt. Diese werden bei der Ausführung des SPDSC als schlussendliche Konfigurationsquelle herangezogen. Die Erzeugung der MOF-Dateien erfolgt durch die Ausführung der Konfiguration. Der Aufruf dafür sieht in der Regel in etwa so aus:

Abbildung 3: Aufruf der Konfiguration zur Erstellung der MOF-Dateien. (Quelle: COMPAREX) 
Abbildung 3: Aufruf der Konfiguration zur Erstellung der MOF-Dateien. (Quelle: COMPAREX)

Die Accounts sind zu vernachlässigen und je nach Anforderung unterschiedlich. Wir übergeben diese Accounts als PSCredential-Objekt an die Konfiguration. Achten Sie unbedingt auf den Funktionsaufruf „SharePoint“ in Abbildung 3. Das ist keine Standardfunktion irgendeiner Library. Der Name der Funktion wird durch die Konfiguration bestimmt. In unserem Beispielprojekt steht dort Folgendes:

Abbildung 4: Die ersten Zeilen der Konfiguration bestimmen den Funktionsaufruf. (Quelle: COMPAREX)
Abbildung 4: Die ersten Zeilen der Konfiguration bestimmen den Funktionsaufruf. (Quelle: COMPAREX)

Wenn ich den Namen aus Abbildung 4 ändere, wird der Aufruf in Abbildung 3 nicht mehr funktionieren.
Das als kurzer Nebenkriegsschauplatz. Zurück zum Funktionsaufruf (Abbildung 3) und dessen Parametern: Wichtig sind die Parameter ConfigurationData und OutputPath. Der OutputPath definiert den Ausgabeordner der MOF-Dateien. Dieser wird dann auch beim SPDSC-Durchlauf verwendet. Der Parameter ConfigurationData übergibt die Parameterdatei an die Konfiguration – bitte nicht verwechseln. Wie man bereits in der Abbildung sieht, wird eine Variable übergeben. Festgelegt wurde diese direkt davor wie folgt:

Abbildung 5: Einlesen der Parameterdatei. (Quelle: COMPAREX) 
Abbildung 5: Einlesen der Parameterdatei. (Quelle: COMPAREX)

Das funktioniert so auch, bis auf die Hürde, dass es irgendwann nicht mehr funktioniert. Nämlich genau dann, wenn die Parameterdatei zu groß wird. Eine Dokumentation dazu habe ich leider noch nicht gefunden. Die Anhaltspunkte, die ich mitgeben kann, sind:

  • 245 KB bzw. 3546 Zeilen funktionieren und
  • 321 KB bzw. 4730 Zeilen funktionieren nicht.

An welchem Parameter sich das Commandlet genau stört, ist mir nicht bekannt und auch relativ müßig herauszufinden. Wenn jemand die Zeit und Muße hat, es herauszufinden, darf er das gerne teilen.
Die Fehlermeldung ist übrigens recht uneindeutig. Die PowerShell gibt einfach die gesamte Parameterdatei in Rot aus (lustig, dass er sie irgendwie doch einlesen konnte) und wirft ganz am Ende eine für mich recht unklare Ausnahme:

Abbildung 6: Fehlerausgabe, wenn die Parameterdatei zu groß ist. (Quelle: COMPAREX)Abbildung 6: Fehlerausgabe, wenn die Parameterdatei zu groß ist. (Quelle: COMPAREX)

Es gibt zwei mir bekannte Lösungen, das zu umgehen und trotzdem SPDSC zu nutzen.

Lösung/Workaround 1: Reduzierung der Parameterdatei

Man überlegt, ob die Parameterdatei, so wie sie aufgebaut ist, Sinn ergibt und versucht Dinge zu reduzieren – eine Art Code Review. Tendenziell eine sehr gute und wichtige Sache, aber auch an dieser Stelle: Seien wir ehrlich – wer tut das regelmäßig und konsequent? Dies ist aber definitiv eine Maßnahme, die getan werden muss – unabhängig vom Fehler. Sie bringt bei großen Farmen allerdings auch selten einen Mehrwert, da es eben oftmals einfach nur viel Inhalt ist.

Lösung/Workaround 2: Ändern des Commandlets

Die schnellste und einfache Variante ist die Anpassung des Commandlets, sodass der Fehler nicht mehr auftritt. Es besteht die berechtigte Frage, wie ich auf die Idee komme, dass dieses Commandlet existiert. Die Antwort ist recht simpel und kommt in ehrlichen Projekten oft vor: Zufall und Ausprobieren.

Ich habe nämlich rein zufällig kurz vor unserem Beispielprojekt mit diesem Ersatz-Commandlet gearbeitet und es daraufhin einfach ausprobiert und siehe da, auf magische Weise funktioniert SPDSC wieder:

Abbildung 7: Einlesen der Parameterdatei mit „Ersatz-Commandlet“. (Quelle: COMPAREX) 
Abbildung 7: Einlesen der Parameterdatei mit „Ersatz-Commandlet“. (Quelle: COMPAREX)

Problem: Größe der MOF-Dateien

Wer auf die Problematik der zu großen Parameterdateien trifft, wird relativ zeitnah, oder ist es schon, auf die Problematik der zu großen MOF-Dateien stoßen. Diese werden, wie oben beschrieben, aus den Konfigurationen und Parametern gebaut und vom SPDSC als Basis herangezogen. Alles, was in der Konfiguration bspw. als Schleife aufgebaut ist, wird in den MOF-Dateien als einzelnes Objekt dargestellt. Dies kann also dazu führen, dass die Dateien sehr schnell sehr groß werden. In der Regel erscheinen dann bei der Ausführung des SPDSC (nicht beim Bauen der MOF-Datei) solche Fehler:

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.
The WinRM client sent a request to the remote WS-Management service and was notified that the request size exceeded the configured MaxEnvelopeSize quota.
+ CategoryInfo : LimitsExceeded: [root/Microsoft/...gurationManager:String] [], CimException
+ FullyQualifiedErrorId : HRESULT 0x80338111
+ PSComputerName : [servername]
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 0.648 seconds

Quelle: SPDSC-Wiki

Relevant dabei ist die fett markierte Stelle. Sucht man danach, findet man relativ schnell einen Eintrag im SharePointDSC-Wiki, welcher die Lösung beschreibt.

Lösung/Workaround: Setzen der Property „MaxEnvelopeSizeKb“

Diese beschreibt nämlich das Setzen einer bestimmten Property (MaxEnvelopeSizeKb), die im Standard bei 500 KB liegt und entsprechend erhöht werden muss. Das ist alles im oben verlinkten Artikel näher beschrieben. In der Ausführung sieht das ungefähr so aus:

Abbildung 8: Setzen der „MaxEnvelopeSizeKb“ auf dem Server. (Quelle: COMPAREX)Abbildung 8: Setzen der „MaxEnvelopeSizeKb“ auf dem Server. (Quelle: COMPAREX)

Übrigens sind 2048 KB auch nicht immer ausreichend. In unserem Beispielprojekt liegen wir bei 8192 KB.

Problem: Zu viele SPDSC-Durchläufe

Die SPDSC-Funktionalität dient nicht nur dem einmaligen Ausrollen einer Konfiguration, sondern auch der Rekonfiguration. Dies kann manuell oder automatisch getriggert werden. Durch den folgenden Befehl wird ein Durchlauf des SPDSC gestartet – übrigens synchron aufgrund des Wait-Parameters.

Abbildung 9: Starten eines synchronen SPDSC-Durchlaufs. Der „Path“ ist der Ausgabeordner, der schon beim Erstellen angegeben wurde. (Quelle: COMPAREX)Abbildung 9: Starten eines synchronen SPDSC-Durchlaufs. Der „Path“ ist der Ausgabeordner, der schon beim Erstellen angegeben wurde. (Quelle: COMPAREX)

Damit läuft das SPDSC alle Konfigurationen der entsprechenden MOF-Datei ab und setzt die jeweiligen Werte. Dabei orientiert sich SPDSC am Computernamen und sucht die passende MOF-Datei heraus – es gibt je Zielserver eine MOF-Datei. Nach dem Durchlauf kann mit folgendem Befehl der Status des SPDSC abgerufen werden:

Abbildung 10: Status des SPDSC. (Quelle: COMPAREX) 
Abbildung 10: Status des SPDSC. (Quelle: COMPAREX)

Die Ausgabe des Ergebnisses sieht ungefähr wie folgt aus:

Abbildung 11: Ausgabe des Status des SPDSC. (Quelle: COMPAREX)Abbildung 11: Ausgabe des Status des SPDSC. (Quelle: COMPAREX)

Sollte an der Stelle „NumberOfResources“ eine Zahl größer als Null oder ungleich NULL stehen, gibt es noch bestehende bzw. zukünftige SPDSC-Durchläufe. Wenn dies nicht gewünscht ist, zum Beispiel in Testphasen oder auf Entwicklungssystemen, sollte das beendet werden. Die Ausführung des SPDSC führt nämlich, je nach Implementierung, durchaus zu Änderungen, die den Endanwender beeinflussen können – sowohl in der Verfügbarkeit als auch in der Performanz. Noch schlimmer wird dies, wenn Änderungen am SPDSC durchgeführt wurden, die noch nicht getestet wurden und damit ein hohes Risiko erzeugen.

Lösung/Workaround: Erneute Durchläufe abschalten

Um einen erneuten Durchlauf zu verhindern, nutze ich folgende Befehle:

  1. Remove-DscConfigurationDocument
  2. Stop-DscConfiguration

Abbildung 12: Stoppen geplanter SPDSC-Durchläufe. (Quelle: COMPAREX) 
Abbildung 12: Stoppen geplanter SPDSC-Durchläufe. (Quelle: COMPAREX)

Mithilfe des Befehls aus Abbildung 10 können wir nachvollziehen, ob es funktioniert hat.

Problem: Mythos Desired State

Es gibt wohl keine verlässliche Statistik, wie viele Personen dem Mythos von Desired State Configuration erliegen und glauben, dass jedwede Konfiguration, die nicht gewollt ist, durch SPDSC rückgängig gemacht wird. Hier muss ich leider Kindheitsträume zerstören und mitteilen, dass dem nicht so ist und das ist auch gut so!

Hat ein Kunde per SPDSC bspw. einen Managed Metadata Dienst mit dem Namen „CustomerMMD“ bereitgestellt, wird SPDSC diesen Dienst entsprechend der Konfiguration bereitstellen und genauso korrigieren, wenn etwas manuell geändert wurde. Hat der Kunde allerdings manuell noch einen zweiten MMD mit dem Namen „TestMMD“ aufgesetzt, wird dieser nicht automatisch von SPDSC entfernt. Ja, dieser TestMMD widerspricht dem Desired State, aber es gibt dafür schlicht keine direkte Implementierung, dass dieser MMD gelöscht wird. Dies muss also durch den Administrator selbst, vorzugsweise als CustomScript (folgt in Teil 3 der Blogserie) im SPDSC, implementiert werden, insofern gewünscht.

Es lässt sich sehr lange und vor allem ohne Ergebnis darüber diskutieren, ob das ein Bug oder ein Feature ist. Aktuell ist es so und jeder ist dazu aufgerufen, gute Ideen sinnvoll in das SPDSC einzubringen.

Lösung/Workaround: Eigene Funktionsimplementierung

Gibt es nicht. Aktuell wird nur das getestet bzw. konfiguriert, was auch angegeben wurde. Alles andere wird nicht berücksichtigt. Im Zweifelsfall implementiert man die Funktion selbst oder schaut selbst im Quellcode des SPDSC, um sich über die Implementierung im Klaren zu sein.

Fazit

Viele, viele kleine und größere Fallstricke hält SPDSC für uns bereit und sorgt dafür, dass uns als SharePoint Consultant nicht langweilig wird. So ist das mit neuen Technologien, aber der Ansatz bleibt gut und auch die Umsetzung ist gut, wenngleich ausbaufähig. Aber welche neue Technologie ist das nicht? Bevor es zu philosophisch wird: Ich hoffe dieser Blogbeitrag kann den ein oder anderen vor zu vielen grauen Haaren bewahren. Teil 3 der Serie geht dann noch eine Ebene tiefer und klärt die Frage: Ich muss etwas konfigurieren, was SPDSC nicht kann – was nun?

Ü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

Diesen Artikel teilen

Artikel vom:
14.11.2018

geschrieben von:

TAGS:
SharePoint

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben