Archiv für den Monat: April 2016

Wie gut bin ich in PowerShell? Das Very Effective Exam testet Deine Fähigkeiten

Auf dem DevOps and PowerShell Summit 2016, der Anfang April stattfand, gab es wieder die Gelegenheit an einem „Very Effective Exam“ teilzunehmen (den etwas ungewöhnlichen Namen muss sich der Erfinder des Tests, vermutlich Don Jones himself, ausgedacht haben). Der Test ist eine Art „Wie gut kann ich mit der PowerShell umgehen?“-Test und entstand in erster Linie aus dem Umstand einer fehlenden offiziellen Alternative, da sich Microsoft offenbar weigert eine Zertifizierung für die PowerShell einzurichten.

Der Tests bestand dieses Mal darin, dass man ein kleines PowerShell-Skript mit einer Function, in der einfache WMI-Abfragen durchgeführt wurden, und den per Start-Transcript aufgezeichneten Output des Skriptes vorgelegt bekam. Das Skript enthielt ca. 10 Fehler, die dazu führten, dass einzelne Befehle nicht ausgeführt oder so geschrieben waren, dass der angegebene Output nicht hätte resultieren können. Das größte „Rätsel“ (leider auch für mich) war, warum der Aufruf von Get-Help keinen Output produzierte. Für das Finden der Fehler hatte man 60 Minuten Zeit. Hilfsmittel waren keine zugelassen außer einem Blatt Papier und einem Kugelschreiber.

Wenn sich die Aufgabe vielleicht einfach anhören mag, der Test hatte es in sich, denn man musste genau hinschauen, auf Kleinigkeiten achten und vor allem die Feinheiten von Advanced Functions sehr gut kennen, ein wenig über WMI und CIM Bescheid wissen, vor allem aber der Lage sein deduktiv zu arbeiten. Mit anderen Worten: Wenn der Output so aussieht, dann muss das Cmdlet, das diesen Output produziert, mit jenen Parametern und deren Werten aufgerufen werden.

Ich empfand die Aufgabe am Anfang als relativ schwer und vor allem ungewöhnlich aufgrund der Aufgabenstellung, nach einer Weile hatte ich mich etwas daran gewöhnt und etwa eine halbe Stunde später (an dem Tisch, an dem ich saß, schrieben die anderen bereits eifrig – ich kam mir fast vor wie bei einer Klassenarbeit in der Schule oder einer Prüfung an der Fachhochschule) war ich relativ entspannt und hatte das Gefühl fast alles im Griff zu haben. Offenbar eine Selbsttäuschung, denn wie es aussieht habe ich den Test nicht bestanden. Dazu hätte ich mindestens 8 der 10 Fehler finden bzw. die Befehle so ändern müssen, dass das protokollierte Ergebnis herauskam. Der Umstand, dass es nur ca. 20% der ca. 40 Teilnehmer, alle mehr oder weniger erfahrene PowerShell-User, geschafft hatten (also knapp 8) ist in diesem Zusammenhang nur ein kleiner Trost.

Die Lehre aus der Geschichte: Achte auf die Kleinigkeiten und glaube nicht ein Werkzeug verstanden zu haben bis Du es wirklich verstanden hast. Auf der anderen Seite: Es dürfte äußerst selten vorkommen, dass man nur knapp 1 Stunde Zeit hat und in einer künstlichen Stresssituation die Fehler in einem Skript finden und dabei auf jede Kleinigkeit achten muss. Dennoch sind solche Tests eine gute Gelegenheit seine eigene Fähigkeiten einer kritischen Betrachtung zu unterziehen. Allzu oft gibt man sich nach dem Motto „Passt schon“ mit einem Kompromiss zufrieden. Ganz optimal ist diese Einstellung nicht.

Wer sich nun für die Aufgabe interessiert: Don Jones war dieses Mal gnädig und hat die Aufgabe nicht nur veröffentlicht, sondern auch höchstpersönlich die Lösung kommentiert:

http://powershell.org/wp/2016/04/22/verified-effective-exam-results/

Der FizzBuzz-Test in PowerShell

Vor kurzen bin ich per Zufall auf den FizzBuzz-Test gestoßen, der bei Einstellungstests verwendet wird, um festzustellen, ob ein potentieller Entwickler überhaupt mit der Logik des Programmierens klar kommt:

http://c2.com/cgi/wiki?FizzBuzzTest

Die zu lösende Aufgabe ist im Grunde simpel: Es sollen die Zahlen von 1 bis 100 ausgegeben werden. Ist die Zahl glatt durch 3 teilbar, soll anstelle das Wort „Fizz“, ist die Zahl durch 5 glatt teilbar das Wort „Buzz“ und wenn die Zahl sowohl durch 3 als auch durch 5 (glatt) teilbar ist, das Wort „FizzBuzz“ ausgegeben werden.

Auch wenn Admins keine Programmierer sein müssen, hat es mich gereizt die kleine Aufgabe per PowerShell zu lösen, da dies eine gute Gelegenheit ist, die Flexibilität des switch-Befehls zu veranschaulichen.

Eine Lösung sieht wie folgt aus:

Die folgende Variante piept die Zahlen in einen ScriptBlock:

Da im letzten Beispiel der ScriptBlock per Call-Operator ausgeführt wird, muss der Pipeline-Inhalt über die Variable $Input, die für ein Enumerator-Objekt steht, angesprochen werden (das sind Kleinigkeiten, die ich mir nur schwer behalten kann, aber wozu gibt es das Internet;).

Ein weitere Besonderheit ist mir erst aufgefallen als mir die Ausgabe genauer angesehen hatte. Für Zahlen, die sowohl durch 3 als auch durch 5 teilbar sind, soll nur „FizzBuzz“ und nicht auch „Fizz“ und „Buzz“ ausgegeben werden. Der switch-Zweig muss in diesem Fall die weitere Prüfung abbrechen. Da ein break den Befehl komplett abbrechen würde, muss in beiden Varianten continue verwendet werden.

PoshWizard – eine kleine DSL für das Erstellen von Assistenten

Angeregt durch PScribo und einen Vortrag von Kirk Munro auf dem letzten DevOps und PowerShell Summit habe ich selber eine kleine Domain Specific Language (DSL) mit dem Namen PoshWizard erstellt, mit deren Hilfe sich relativ einfach Assistenten erstellen lassen, die den Anwender durch eine Folge von Eingaben führen und mit den eingegebenen Werten am Schluss eine Aktion ausführen.

Der folgende Text erzeugt einen Assistenten mit insgesamt fünf Fenstern:

Das Ergebnis ist ein WPF-Fenster mit einem TabControl, das für jeden Schritt ein Register enthält (ursprünglich wollte ich alle übrigen Register bis auf das aktuelle ausblenden, aber in dieser Varianten steht eine zusätzliche Navigationsebene zur Verfügung und sie ist vor allem etwas leichter umzusetzen).

Am Ende müssen die eingegebenen Daten lediglich über Variablen angesprochen werden. Im Grunde also ganz einfach.

EIn per PoshWizard angelegtes Fenster

EIn per PoshWizard angelegtes Fenster

Die ganze DSL steht als Modul unter GitHub zur Verfügung:

https://github.com/pemo11/PoshWizard

Ich bin gespannt, ob jemand das Modul einsetzen wird und freue mich natürlich über ein FeedBack. Ob das Modul „produktionsreif“ ist, kann ich im Moment noch nicht beurteilen, da ich es noch nicht ausgiebig getestet habe (es fehlen außerdem noch Tests, die der Autor von PScribo konsequent für jede Function verwendet). Auch die Optik ist sicherlich noch verbesserungswürdig was die Platzierung der einzelnen Bedienelemente angeht. Außerdem fehlt noch die eine oder andere Funktionalität. Ein Beispiel ist ein Wenn-Befehl, durch den eine im letzten Schritt getroffene Auswahl für die Entscheidung verwendet wird welches Fenster als nächstes angezeigt wird. Insgesamt bin ich mit dem Ergebnis aber sehr zufrieden, vor allem angesichts des Umstandes, dass ich aktuell ledlgich ein paar Stunden in die Umsetzung investiert habe. Ich sehe es in erster Linie als ein Beispiel dafür welches Potential in der PoweShell in diesem Bereich steckt.

Die ersten Schritte mit PScribo

PScribo von Ian Brighton ist eine Art „PowerShell-Reporting-Tool“, auf welches das Attribut genial auch bei nüchterner Betrachtung zutrifft. Warum? Weil es, genau wie Pester, genau das macht was es machen soll und das mit einer verblüffenden Leichtigkeit. Aktuell steht es nur als Zip-Datei unter GitHub zur Verfügung. Dort hat der Autor aber bereits angekündigt, dass es demnächst auch über die PowerShell Gallery zur Verfügung stehen wird und damit per Install-Module PScribo hinzugefügt werden kann.

Hier ein kleines Beispiel, das ein paar Eckdaten eines AD in einem Report zusammenfasst.

Die Idee ist, dass mit Hilfe der Befehle einer Dokumente-DSL (eine Domänenenspezifische Sprache umfasst Befehle, die im Rahmen einer „Problemdomäne“ zur Lösung von Problemen verwendet werden – dahinter stecken bei der PowerShell in der Regel nur Functions) der Aufbau des Dokuments beschrieben wird. Per Section wird z. B. ein neuer Bereich eingeleitet, per PageBreak ein Seitenumbruch und per Paragraph ein neuer Absatz. Die eigentlichen Daten werden per Table ausgeben, auf Wunsch auch als Liste. Eine weitere Stärke von PScribo ist die Leichtigkeit, mit der sich Tabellen formatieren lassen. Zeilenweise und spaltenweise. Das unscheinbare TOC zu Beginn der Dokumentdefinition fügt ein Inhaltsverzeichnis ein, zu dem automatisch alle Sektionen zusammengefasst werden.

Der Aufruf sieht wie folgt aus:

Das Ergebnis sind jeweils eine Docx- und eine Html-Datei im aktuellen Verzeichnis. Das kleine Beispiel kann natürlich nur einen Teil der Möglichkeiten andeuten. Der Autor stellt im Examples-Unterverzeichnis des Modulverzeichnisses mehrere Dutzend Beispeiele zur Verfügung, die keine Fragen mehr offen lassen sollten. DSL haben Potential. Auf dem DevOps und PowerShell Summit 2016 zeigte PowerShell-Exprte Kirk Munro wie DSLs per PowerShell umgesetzt werden. Das Video sollte es in Kürze auf YouTube geben.

Tipp: Die wichtigsten Infos zu den Parametern eines Cmdlets ausgeben

Die PowerShell-Hilfe zeigt zwar die Details zu allen Parametern an, die Ausgabe ist aber nicht besonders übersichtlich. Möchte man z.B. alle Parameter sehen, die eine Pipeline-Bindung ByPropertyName unterstützen, ist die Ausgabe etwas unübersichtlich. Die folgende Function gibt die Parameter eines Cmdlets als „Custom Object“ aus, so dass sich z.B. bestimmte Parametereigenschaften abfragen lassen.

Der folgende Befehl gibt bei New-ADUser alle Parameter aus, die eine Pipeline-Bindung ermöglichen:

Bericht vom PowerShell und DevOps Summit 2016

Hier ist ein kurzer Bericht vom PowerShell und DevOps Summit 2016, an dem ich Anfang April teilgenommen habe.

Durchgeführt wurde die Konferenz, wie in den letzten Jahren, von PowerShell.org, hinter dem vor allem Don Jones und Jason Helmig stehen.

Alle Infos zu der Veranstaltung gibt es hier: http://powershell.org/wp/summit/

Die Konferenz fand vom 3. bis 6. April im Meydenbauer Center in Bellevue/WA statt. Einer hübschen „Kleinstadt“ vor den Toren der US-Metropole Seattle im Nordwesten der USA und damit fast in „Sichtweite“ zum Microsoft-Campus im benachbarten Redmond.

Mein Fazit vorweg: Die 3 bzw. 4 Tage waren ausgefüllt mit teilweise sehr interessanten Vorträgen. Die Vorträge fanden in der Regel zeitgleich in drei Räumen statt, die Vorträge in zwei Räumen wurden aufgenommen (mit kostspieligem Equipment) und werden sicher in Kürze auf YouTube zur Verfügung stehen (https://www.youtube.com/user/powershellorg).

Aus Deutschland war meines Wissens niemand anwesend, auch Europa war insgesamt sehr spärlich vertreten (ich glaube, jemanden aus Dänemark gesehen zu haben). Ein Grund kann natürlich sein, dass nächste Woche in Hannover die europäische PowerShell User-Konferenz mit Top-Besetzung stattfindet: http://www.psconf.eu/

Hier noch ein paar Details zum Summit. Einen kompletten „Reisebericht“ wollte ich dieses Mal nicht schreiben, so dass es nur ein paar Stichworten bleibt. Wer schon einmal auf einer technischen Konferenz oder auf der deutschen PowerShell Community-Konferenz war, kennt die Atmosphäre und den Ablauf. Man hört Vorträgen zu und hat in den Pausen und danach die Gelegenheit sich mit anderen PowerShell-Usern auszutauschen. Auch die einzelnen Sprecher stehen meistens noch irgendwo herum, so dass man auch mit den Experten ins Gespräch kommen kann. Der Reiz des Summits liegt natürlich in dem Umstand, dass das Microsoft-Hauptquartier in Redmond nur ein paar Autominuten entfernt ist und daher auch Mitglieder des PowerShell-Teams leicht vorbeischauen können. Da Jeffrey Snover in dieser Woche offenbar im Urlaub auf Hawaii war, gab es leider keinen Über- und Ausblick aus seiner Sicht. Dafür gaben am dritten Konferenztag Kenneth Hansen und Angel Calvo einen Überblick über 10 Jahre PowerShell (die Version 1.0 wurde am 10. November 2016 freigegeben), der am Ende sogar in einer kleinen Ankündigung mündete: Mit Windows Server 2016 wird es ein WMF 5.1 und einer etwas überarbeiteten PowerShell-Version geben.

Bruce Payette, der „geistige Vater“ der PowerShell-Skriptsprache war auf der Konferenz anwesend, ohne aber einen Vortrag zu halten. Eine interessante Aussage von ihm war, dass der mit der Version 5 eingeführte class-Befehl nicht nur das Erstellen von DSC-Ressourcen vereinfacht, sondern auch eine neue Semantik für PowerShell-Skripte mit sich bringt, in dem in Zukunft z.B. anstelle von Functions, die einfach etwas dadurch zurückgeben, in dem sie Werte in die Pipeline legen, Klassen mit Eigenschaften verwendet werden, die ihren Wert über den return-Befehl als Teil des „getters“ zurückgeben. Der Trend, dass sich die PowerShell etwas stärker zu einem Entwicklungswwerkzeug (für den „Admin 2.0“ ist Programmierung kein Fremdwort mehr, sondern ein selbstverständlicher Teil seiner Arbeit) wird, wird dadurch auch in der Praxis entsprochen.

Bemerkenswert war wie viele (junge) Frauen im DSC-Team arbeiten. Das wurde am dritten Tag im Rahmen der „Lightning Demos“ deutlich, in denen Mitarbeiter des PowerShell- und des DSC-Teams kleine Neuerungen zeigten, die in den nächsten Wochen vor allem in die PowerShell Gallery einfließen werden.

Ein sehr interessanter Vortrag, den ich jeden empfehlen kann, der mit der PowerShell in die „Tiefen des Betriebssystems“ hinabsteigen möchte, war der Vortrag von Matt Graeber mit dem Titel „Low
Level Techniques for the Win32 API“. Matt ist, was ich nicht wusste, der Autor von PowerSploit und PowerShell Arsenal und betreibt unter http://www.exploit-monday.com/ ein Blog, in dem es um das Thema „Exploits“ geht und damit um ein Thema, das immer wichtiger wird. Da viele Hacker inzwischen die PowerShell als ihr Lieblingstool entdeckt haben (ein Umstand, auf den Bruce Payette sogar ein wenig stolz zu sein schien), müssen Admins, die mit dem Thema Sicherheit betraut sind, Techniken lernen, über die sich Schwachstellen entdecken und beheben lassen bevor es die Hacker tun.