Desired State Configuration und SharePoint
SharePointDSC: Bugs und Fehlersuche

Desired State Configuration und SharePoint – SharePointDSC: Bugs und Fehlersuche

Dieser Teil der Serie zu SharePointDSC beschäftigt sich mit einem sehr wichtigen und tiefen Thema: Fehlersuche. Wie erkenne ich Fehler im SharePointDSC und was mache ich dagegen?

Probleme erkennen

Debugging ist nicht einfach, wenn auch nicht unmöglich. Dementsprechend ist die Erkenntnis, dass man ein Problem hat, schon recht schwierig, ohne SPDSC zu verteufeln – was Sie sicherlich noch oft genug tun werden.

Meine Empfehlung:
  • Schreiben Sie die Konfiguration initial und nicht einmal komplett herunter. Sie werden mit sehr großer Wahrscheinlichkeit in Fehler laufen und können nur schwer herausfinden, woran es liegt. Deshalb bauen Sie die Konfiguration Schritt für Schritt und erweitern sie immer in kleinen Schritten.

  • Nutzen Sie unbedingt die Dokumentation des SPDSC. Ich habe selten eine so gute Dokumentation gefunden, die zudem recht aktuell ist. Die Community ist aktuell auch sehr rege und diskutiert viele Dinge.

Sie haben nun herausgefunden, dass die Konfiguration in einen Fehler läuft, aber alle Voraussetzungen wie beispielsweise aktuelle PowerShell erfüllt sind. Aus der Erfahrung heraus haben Sie nur eine Möglichkeit herauszufinden, ob es an SPDSC liegt: Schauen Sie in den Quellcode der entsprechenden Ressource. Nur dadurch können Sie mit Sicherheit sagen, ob Ihre Änderung greifen kann oder nicht. „Mit Sicherheit“ ist es natürlich etwas hoch gegriffen, aber einige Implementationen sind tatsächlich recht einfach zu durchschauen und damit zu verstehen.

Beispiel für einen Bug oder ein Feature

Ein vielleicht einfaches Beispiel ist die SPDSC-Ressource SPWebApplication. Während des Beispielprojekts fiel uns auf, dass Änderungen an bestehenden Webanwendungen nicht durchgezogen wurden. Das Löschen der Webanwendung und Neuerstellen führte dann aber zum Erfolg der Konfiguration. Das kann aber nicht die Lösung sein. Im Quellcode haben wir dann folgende Implementierung der Get-Methode gefunden.

Desired State Configuration und SharePoint – SharePointDSC: Bugs und Fehlersuche
Implementierung der Get-Methode der Ressource SPWebApplication in Version 2.1.0.0. (Quelle: SoftwareONE)

An dieser Stelle nichts Aufregendes. Es wird ein Get auf die Webanwendung gemacht und bei NULL werden Standardwerte und bei Treffer die aktuellen Werte zurückgegeben – alles gut.

Auch die Test-Methode ist nicht aufregend:

Desired State Configuration und SharePoint – SharePointDSC: Bugs und Fehlersuche
Implementierung der Test-Methode der Ressource SPWebApplication in Version 2.1.0.0. (Quelle: SoftwareONE)

Auch hier keine ungewöhnlichen Dinge. Die Funktion „Test-SPDscParameterState“ ist eine Standardfunktion, die allgemein Werte vergleicht. Tendenziell erstmal kein Fehler. Die Spannung wird größer, denn wir haben noch die Set-Methode.

Desired State Configuration und SharePoint – SharePointDSC: Bugs und Fehlersuche
Implementierung der Set-Methode der Ressource SPWebApplication in Version 2.1.0.0. (Quelle: SoftwareONE)

Lassen Sie sich Zeit beim Anblick des Codes. Ich habe bewusst die Parameter und den IF-Zweig in der Mitte zusammengeklappt. Take your time – das macht SharePoint ja auch regelmäßig: This shouldn’t take long.

Gehen wir es mal durch: Die Set-Methode wird aufgerufen, wenn die Test-Methode false zurückgibt. Da ich eine Änderung gemacht habe, erwarte ich, dass der Test auch tatsächlich false zurückgibt und der Einfachheit halber nehmen wir das auch an.

Zeile 167 und 169 können wir ignorieren: Verbose-Ausschrift und Setzen einer Property. Zeile 171 ist schon etwas interessanter. „Ensure“ bestimmt, ob etwas existent („Present“) oder nicht existent („Absent“) sein soll. Unabhängig davon, dass ich es als früherer Entwickler nicht schön finde, dass ein Parameter, der zwei Werte annehmen kann, zweimal in einer IF abgefragt wird, bin ich mir sicher, dass der Zweig ab Zeile 171 für uns relevant ist. Wie komme ich zu dem Schluss? Ich will meine Webanwendung ja existent haben und, ganz banal, in meiner Konfiguration steht bei Ensure der Wert Present.

Geht man dort rein, kommen ein Invoke und das Setzen einer Variable. Zeile 178 ruft die Webanwendung anhand des Namens ab – super, passt. Was mich irritiert, ist Zeile 179. Es wird geprüft, ob die Webanwendung NULL ist und wenn sie das ist, werden unter anderem folgende Dinge durchgeführt:

Desired State Configuration und SharePoint – SharePointDSC: Bugs und Fehlersuche
Umsetzung der Konfiguration einer Webanwendung. (Quelle: SoftwareONE)

Ich habe in der Abbildung 4 noch ein paar Sicherheitsabfragen zusammengeklappt, denn relevant sind die Zeilen ab Nummer 219. Ab diesem Zeitpunkt werden verschiedenste Sachen umgesetzt. Was stört mich daran? Das passiert nur, wenn keine Webanwendung (Zeile 179) mit dem Namen XYZ gefunden wurde! Sobald also eine Webanwendung mit dem Namen XYZ vorhanden ist, kann ich beispielsweise den HostHeader in der Konfiguration ändern wie ich möchte, aber es wird nicht umgesetzt.

Ich möchte nicht ausschließen, dass ich etwas falsch verstehe, aber der Code, den ich in Abbildung 3 lese, ist für mich eindeutig.

Bug oder Feature, das ist hier die Frage

Jetzt ist die große Frage: Bug oder Feature? Bug ganz klar. Wie kann man auf die Idee kommen, dass das ein Feature ist? Ohne darüber zu sinnieren, würde ich mich der Aussage anschließen. Aber gehen wir mal durch, was passiert, wenn ich die Konfiguration ändere. Es erklärt sich, dass es kein Bug ist (aber vielleicht auch kein Feature). Nehmen wir gleich mal die krasseste Variante: Ich habe in der Konfiguration den DatabaseName geändert. Das SPDSC muss nun also feststellen, dass der Name unterschiedlich ist und muss die vorherige Inhaltsdatenbank abhängen und die neue einhängen. Was passiert, wenn die neue DB erst noch migriert werden muss oder schlicht nicht angehangen werden kann oder gar nicht da ist? Wird dann die alte DB wieder eingebunden? Wenn es erfolgreich war, wird dann die abgehangene DB gelöscht? Dieses Szenario kann man recht lange fortsetzen und wahrscheinlich gibt es dazu keine allgemeingültige Lösung, die das SPDSC gleichzeitig überschaubar hält.

Ganz unabhängig von diesen Überlegungen gibt es zwar einen Befehl (Set-SPWebApplication), der Eigenschaften der Webanwendung setzt, aber soweit ich das sehe, keine Eigenschaft der hier im SPDSC genutzten (DatabaseName, HostHeader etc.). Es gibt also keinen einfachen Weg, diese Werte per SharePoint-Commandlet dann auch tatsächlich nachträglich zu ändern.

Bug gefunden – und nun?

Wir können also gerne darüber meckern, wie schlecht eine Ressource implementiert ist und unzählige Foren durchforsten, um Gleichgesinnte zu finden. Das ist eine durchaus gängige Option, bringt nur leider wenig Punkte und löst auch das Problem nicht. Wir können also das Problem bewundern oder eine Lösung suchen. Ich tendiere zur zweiten Option.

Wenn Sie einen Bug gefunden haben, dann nimmt es Ihnen niemand übel, wenn Sie das in der Community teilen, sodass er bekannt gemacht und eine Lösung gefunden wird. Oftmals gibt es auch schon offene Issues zu Ihrem Thema und wenn Sie dann noch eine Lösung haben, dann klopfen Sie sich bitte auf die Schulter und versuchen einen MVP dazu zu bekommen, Sie ebenfalls als MVP zu nominieren. Das ist der große Vorteil im SPDSC: Wenn ein Bug vorhanden ist, können Sie ihn in Ihrer Umgebung fixen und diesen direkt in der Community bereitstellen.

Was die Herausforderung in diesem Blog angeht, fällt mir spontan keine allgemeingültige und vertretbare Lösung ein. Die einzige Option, die ich sehe: Vernünftige Anforderungsanalyse und Planung.

Fazit

SharePointDSC, du hast mich Nerven, Haare und alkoholische Mixgetränke gekostet, aber inzwischen basiert unsere Beziehung auf Vertrauen. SPDSC kombiniert die Möglichkeit von individuellen Skripten und standardisierten Prozessen sehr gut. Auch wenn man an einigen Stellen noch weiße Flecken auf der Entwicklungskarte hat, kann man zum jetzigen Zeitpunkt schon sehr gute Ergebnisse erzielen.

Trotzdem ersetzt die Verwendung von SPDSC weder einen Consultant, noch eine Anforderungsanalyse, noch eine Planung. Das sollte jedem klar sein, der das Tool nutzen will oder generell SharePoint einführen möchte. SPDSC ist nicht dafür gemacht, die Installation und Konfiguration ohne Expertenwissen durchzuführen.

Überblick über die Themen der Blogreihe

Sie haben Fragen zu diesem oder anderen SharePoint-Themen?

Nehmen Sie Kontakt mit unseren Experten auf. Sie beantworten offene Fragen oder unterstützen bei deinem individuellen Beratungswunsch.

Kontakt aufnehmen
  • Donnerstag 31 Januar 2019

Kommentieren Sie diesen Artikel

Hinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!

Kommentar hinterlassen

Autor

Henrik Krumbholz Senior Consultant SharePoint

So steuern und kontrollieren Sie Assets in der Adobe Creative Cloud und Document Cloud
  • 04 Juni 2019
  • Publisher Advisory, User Productivity
  • Adobe

So steuern und kontrollieren Sie Assets in der Adobe Creative Cloud und Document Cloud

In der Adobe Creative Cloud und Document Cloud gibt es Tools, um die Verbreitung von Assets zu kontrollieren. Wir erklären, wie sie funktionieren.

Einführung in PowerApps
  • 16 Mai 2019
  • User Productivity, Unified Communications
  • PowerApps, SharePoint

Einführung in PowerApps

PowerApps ist ein Microsoft Dienst zur Erstellung von Business-Apps für Ihr Unternehmen. Hier erfahren Sie alles zu den Vorteilen und Anwendungsbereichen.

Adobe FrameMaker in der technischen Redaktion
  • 15 Mai 2019
  • Ute Mitschke
  • Publisher Advisory, User Productivity
  • Adobe

Adobe FrameMaker in der technischen Redaktion

Adobe FrameMaker dient in der technischen Redaktion der Erstellung und Verwaltung von Betriebsanleitungen. Wir erläutern die Vorteile des Profi-Programms.