COMPAREX AG
Desired State Configuration und SharePoint – SharePointDSC: Custom Scripts im DSC (Teil 3) (Header)

Desired State Configuration und SharePoint – SharePointDSC: Custom Scripts im DSC (Teil 3)

Teil 2 der Blogserie handelte von kleineren und größeren Fallstricken, die, wenn man sie kennt, recht simpel zu umgehen sind, aber bei Unkenntnis zu zahlreichen grauen Haaren führen. Der dritte Teil steigt nun noch tiefer ein und klärt die Frage: „SharePointDSC (SPDSC) kann das nicht, was ich konfigurieren will. Was mache ich nun?“. Der Beitrag widmet sich Custom Scripts und deren Aufbau als Lösung.

Ein Blogbeitrag von Henrik Krumbholz, Senior Consultant SharePoint

Custom Scripts – dann kann ich es ja gleich selbst machen…

Custom Scripts hört sich schon nach einer halbgewalkten Lösung für irgendwelche verrückten Geschichten an, die der Kunde unbedingt haben will, bei der jeder Consultant aber ein unwillkürliches Augenzucken bekommt (oder zumindest sollte). Schlussendlich wird es trotzdem gemacht, weil der Kunde es eben will. Und ja, Custom Scripts können dafür verwendet werden. Sie sind dafür aber nicht erdacht worden (hoffe ich).

Die Bereitstellung eines SharePoints ist komplex und in der Regel nicht fehlerfrei. Die Wizards, Installationen, Anleitungen oder auch Commandlets, die Microsoft bereitgestellt hat, sind allesamt sehr gut, aber eben auch nicht fehlerfrei bzw. nicht immer 100% passend für die aktuelle Situation.

Diesen Nachteil hat auch SPDSC mit dem kleinen Unterschied, dass SPDSC OpenSource ist. Wenn also etwas falsch ist oder fehlt, kann man es ändern und in den SPDSC-Prozess einbauen. Bei den proprietären Methoden kann ich nur drumherum bauen.

Die Custom Scripts des DSC dienen an dieser Stelle dazu, fehlende Funktionen oder Eigenheiten des Kundensystems an der richtigen Stelle zu platzieren, sodass wir keinen Workaround bauen, sondern eine Lösung schaffen, die dann beim nächsten Release des SPDSC mit eingebunden und von allen SharePointis genutzt werden kann (Pluspunkte fürs Karma).

Weitere hilfreiche Infos gibt es in diesem MSDN-Artikel.

Aufbau eines Custom Scripts

Custom Scripts werden genauso wie andere SPDSC-Ressourcen behandelt, nur dass sie vielleicht nicht so übersichtlich sind. Wie jede Ressource besteht ein Custom Script aus einer Get-, Test- und Set-Methode. Diese werden in den bereits entwickelten SPDSC-Ressourcen in der Regel immer gleich implementiert:

Abbildung 1: Allgemeiner Ablauf der Methodenaufrufe im SPDSC. (Quelle: COMPAREX) 
Abbildung 1: Allgemeiner Ablauf der Methodenaufrufe im SPDSC. Genaueres dazu in Teil 1 der Blogserie. (Quelle: COMPAREX)

Dieser Ablauf ergibt durchaus Sinn und den kann man auch so im Custom Script implementieren.

Beispiel eines Custom Scripts

Im Folgenden bauen wir uns ein Custom Script, welches den Search Alert der Suchdienst-Anwendung unserer Farm setzen soll. Denn das ist, soweit ich bisher gesehen habe, noch nicht im SPDSC implementiert. Zu Beginn sieht unsere Ressource relativ banal aus und muss in unserer Konfiguration platziert werden:

Abbildung 2: Basis einer Script-Ressource. (Quelle: COMPAREX) 
Abbildung 2: Basis einer Script-Ressource. (Quelle: COMPAREX)

Mit den drei Methoden haben wir den Grundanforderungen genüge getan. Das TestScript gibt sogar schon einen Wert zurück. Die Eigenschaft DependsOn setze ich aus Gewohnheit und aus Sicherheit. In diesem Fall bedeutet diese:

» DependsOn: Wird erst ausgeführt, wenn die Suchdienstanwendung geprüft und wenn nötig gesetzt/korrigiert wurde.

Nun ist es an Ihnen zu entscheiden, mit welcher Implementierung Sie beginnen – da hat ja jeder seine Vorlieben oder Vorschriften. Ich beginne mit der SetScript-Methode:


Abbildung 3: SetScript-Methode mit PowerShell-Code, der auch in der SharePoint-Shell funktioniert. (Quelle: COMPAREX)

Abbildung 3: SetScript-Methode mit PowerShell-Code, der auch in der SharePoint-Shell funktioniert. (Quelle: COMPAREX)

Das ist der Code, den ich auch manuell in der PowerShell einfügen würde, wenn ich den Wert ändern will. Ich weiß also, dass das funktioniert und das ist das Schöne daran: Es funktioniert und alles andere ist nur Unwissenheit bzgl. SPDSC. Die Variable $search ist dabei nur der Verweis auf die Parameterdatei, in der meine Werte für die aktuelle Farm stehen.

Abbildung 4: Verwendung der Parameterdatei in der Konfiguration. (Quelle: COMPAREX) 
Abbildung 4: Verwendung der Parameterdatei in der Konfiguration. (Quelle: COMPAREX)

Die Parameterdatei ist dabei recht simpel aufgebaut und man erkennt die Struktur aus Abbildung 4 in der Parameterdatei wieder:

Abbildung 5: Beispielhafter Aufbau einer Parameterdatei. Siehe auch Blog Teil 2. (Quelle: COMPAREX)Abbildung 5: Beispielhafter Aufbau einer Parameterdatei. Siehe auch Teil 2 der Blogserie. (Quelle: COMPAREX)

Der Bereich der Suche sieht im Beispielprojekt so aus:

Abbildung 6: Die Suche in der Parameterdatei mit allen relevanten Werten der aktuellen Farm. (Quelle: COMPAREX) 
Abbildung 6: Die Suche in der Parameterdatei mit allen relevanten Werten der aktuellen Farm. (Quelle: COMPAREX)

Das Skript ist also nun schon so weit, dass es funktionieren könnte, wird es aber nicht. Die SharePoint-Commandlets sind dem SPDSC nicht bekannt. Damit dieser Aufruf korrekt funktionieren kann, muss ich die SharePoint-Commandlets laden, was ich wie folgt mache:

Abbildung 7: Erweiterung der SetScript-Methode um den Invoke-SPDscCommand-Befehl, damit die SharePoint-Commandlets verfügbar sind. (Quelle: COMPAREX) 
Abbildung 7: Erweiterung der SetScript-Methode um den Invoke-SPDscCommand-Befehl, damit die SharePoint-Commandlets verfügbar sind. (Quelle: COMPAREX)

Das Invoke ist derartig umgesetzt, dass der ScriptBlock SharePoint-Commandlets nutzen kann. Das manuelle Einfügen des PowerShell-Snapins ist daher nicht notwendig. Leider geht dadurch die Kenntnis der aktuellen Variablen verloren, da innerhalb dieses Invokes ein Invoke-Command aufgerufen wird. Das bedeutet, dass der Block nicht funktioniert, weil die Variable $search nicht mehr bekannt ist.

Glücklicherweise bietet der Befehl die Möglichkeit Argumente mitzugeben. Über den Parameter „Arguments“ kann ich mehrere Variablen mitgeben. Ich kürze es ab: Auch das funktioniert nicht immer. Es gibt hier zwei wesentliche Fälle:

  1. Übergabe einer Variablen, die in der Script-Ressource selbst definiert wurde oder
  2. Übergabe einer Variablen, die global verfügbar ist (z.B. aus der Parameterdatei)

In Fall 1 können wir tatsächlich die Variable übergeben:

Abbildung 8: Übergabe von Parametern an Invoke-SPDscCommand in Fall 1 und entsprechende Verwendung. (Quelle: COMPAREX)  
Abbildung 8: Übergabe von Parametern an Invoke-SPDscCommand in Fall 1 und entsprechende Verwendung. (Quelle: COMPAREX)

Fall 1 tritt, wie sollte es anders sein, bei uns aber nicht ein, da wir auf $ConfigurationData innerhalb der Methode so nicht zugreifen können. Die Variable wird bei uns außerhalb definiert, weshalb es insgesamt wie folgt aussieht und damit Fall 2 trifft:

Abbildung 9: Übergabe von Parametern an Invoke-SPDscCommand in Fall 2. (Quelle: COMPAREX) 
Abbildung 9: Übergabe von Parametern an Invoke-SPDscCommand in Fall 2. (Quelle: COMPAREX)

Achten Sie unbedingt auf das „using“ beim Parameter „Arguments“. Eine Mischung aus Fall 1 und 2 geht, aber an irgendeiner Stelle wird das „using“ fällig. Ich nutze nun die args-Variable (wie in Fall 1 auch), wie man das von früher noch kennt. Diese Implementierung ist für uns relevant und jetzt haben wir tatsächlich ein lauffähiges Skript. Das wird bereits funktionieren und wir haben die größte Hürde gemeistert. Sowohl die Get- als auch die Test-Methode sind mit diesem Wissen recht simpel. Dabei ist nur zu beachten, wofür die Methoden gedacht sind:

» Get: Abrufen der aktuellen Konfiguration des SharePoint
» Test: Test der aktuellen Konfiguration des SharePoint gegenüber des Desired States

› Muss true oder false zurückgeben

» Set: Bei false der Test-Methode, Setzen des Desired State

Die komplette Implementierung der Search Alert sieht am Ende wie folgt aus:

Abbildung 10: Fertige Script-Ressource zum Setzen des Search Alert. (Quelle: COMPAREX)
Abbildung 10: Fertige Script-Ressource zum Setzen des Search Alert. (Quelle: COMPAREX)

Man könnte jetzt noch diverse Sicherheitsabfragen bzw. DAU- und DAP-Abfragen (dümmster anzunehmender User und dümmster anzunehmender Programmierer) und Erweiterungen (bspw. mehrere Suchdienstanwendungen) einbauen, aber das ist hier nicht zielführend.

Fazit

Custom Scripts ermöglichen uns die Implementierung von noch fehlenden Features, die wir dann natürlich direkt in der Community teilen, damit der Change eingebaut werden kann. Zudem können wir so individuelle Anforderungen des Kunden, die nicht im allgemeinen SPDSC landen sollen, implementieren und damit ein individuelles SPDSC für den Kunden bereitstellen. Aber was machen wir, wenn wir dann migrieren wollen? Dazu komme ich in Teil 4.

Ü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:
06.12.2018

geschrieben von:

TAGS:

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben