Archiv für den Monat: Mai 2017

PoshConf Europe 2017 – ein (relativ) kurzer Bericht

Im Folgenden lest Ihr einen kurzen Bericht von der PoshConf Eu 2017, die Anfang Mai in Hannover stattfand. Wer sich mehr für die Vorträge interessiert, kein Problem, die gibt es inzwischen auf YouTube – in beeindruckender HD-Qualität (ob allerdings bei jedem Vortrag der Sprecher permanent eingeblendet sein muss?)

Den Link findet ihr auf der Konferenzwebseite:

http://www.psconf.eu/

Mein Fazit vorweg: Die drei Tage waren voll gepackt mit Vorträgen, größtenteils auf hohem Niveau. Wenn es einen Kritikpunkt gibt, dann dass es vielleicht schon ein wenig zu viel an „Content“ gab. Ein anderer, dass aufgrund der teilweise langen Wege zwischen den Räumen im Konferenzcenter und dem völligen Verzicht auf eine Beschilderung (man konnte in jeder Regel immer eine der jungen Damen des „Konferenzteams“ fragen) einiges an Zeit verloren ging, die man besser z.B. für Gespräche mit anderen Teilnehmern genutzt hätte.

Positiv war der Umstand, dass das „halbe“ PowerShell-Team aus Redmond (konkret war es ein halbes Dutzend) angereist war:

  • Jeffrey Snover, PowerShell-Erfinder seit ca. 2002 und inzwischen seit einigen Jahren „Lead Architect“ im Windows Server Team bei Microsoft und damit sowohl für Windows Server als auch System Center zuständig
  • Bruce Payette, das „Brain“ hinter der PowerShell-Skriptsprache
  • Kenneth Hansen, der Chef des PowerShell-Teams
  • Angel Calvo, der im PowerShell-Team für die „Visionen“, also für die strategische Planung zuständig ist
  • Joey Aiello, der für das PowerShell Open Source-Projekt als „Chef-Maintainer“ zuständig ist
  • David Wilson, der als Entwickler im PowerShell-Team u.a. für die PowerShell Extension für VS Code und für das relativ neue Phosphor-Modul zuständig ist
  • Mark Gray konnte leider nicht kommen. Er ist im PowerShell-Team für DSC zuständig.

Auf einem der Fotos, die ich am Ende des Beitrags zusammengefasst habe, ist das PowerShell-Team komplett zu sehen, da sie in der letzten Session („Ask Microsoft Anything“) am Freitagnachmittag alle anwesend waren.

Statt langatmiger Prosa gehe ich im Folgenden nur die Vorträge durch, an denen ich persönlich teilgenommen hatte (eine „Auszeit“ für ein Sightseeing in Hannover habe ich mir nicht genommen, was u.a. daran lag, dass ich die Stadt in den letzten 30 Jahren bereits gefühlt 100 Mal zu einer Cebit besucht hatte).

Vortrag: Die Keynote von Jeffrey Snover

Wenn Jeffrey Snover einen Votrag hält, lohnt es sich immer ihn sich anzuhören. Auch nachträglich. Er schafft es jedes Mal, einen neuen Blickwinkel auf ein Thema zu präsentieren, das gefühlt schon „1000 Mal“ behandelt wurde. Dieses Mal ging es um die Notwendigkeit den eigenen „Mindset“ (also die grundsätzliche Herangehensweise an die Umsetzung von Anforderungen) zu ändern und an jene Veränderungen anzupassen, die in der IT-Welt bedingt durch die Umstellung auf eine „DevOps-Kultur bereits im vollen Gange sind. Manche können es sicher mehr hören, aber diese Veränderungen werden viele Bereich der IT betreffen. „DevOps“ ist für mich keines dieser Hype-Wörter, die alle paar Jahre die Runde machen, sondern steht für konkrete Veränderungen beim Bereitstellen von IT-Dienstleistungen. Jeffrey wies daher auch darauf hin, dass einige Admins zurückbleiben werden. Er meinte jene, die solche Veränderungen nicht wollen, die lieber mehr Zeit mit ihrer Familie verbringen, was natürlich alles schön und gut ist (wie dieser Vergleich zu einer vermeintlichen „Verweigerungshaltung“ passen soll habe ich allerdings nicht verstanden – offen für „DevOps“ zu sein und trotzdem sein Privatleben nicht allem unterordnen zu wollen ist für mich kein Widerspruch). Neben diesem eher allgemeinen Aspekt ging es natürlich auch um die künftige Richtung, die PowerShell in einer „DevOps-Welt“ nehmen soll. Dabei ging es weniger um konkrete Features (zur nächsten Version 6.0 ist gerade erst die erste Beta erschienen, das Entwicklerteam geht aber davon aus, sie noch in diesem Jahr offiziell freigegeben zu können).

Ein wenig kurios sind für mich jene Fragen, die immer wieder gestellt werden, und deren Antwort eigentlich schon vorher klar sein sollten. Es dürfte z. B. relativ klar sein, dass Microsoft die ISE nicht einstellen wird, sie wird aber auch nicht mehr grundlegend weiterentwickelt, da sie nicht portabel ist. Auch wenn bedingt durch den aktuellen Fokus auf die PowerShell Extension für VS Code die ISE in den Hintergrund gerückt ist, wird es sie immer geben.

Was mir dagegen immer noch nicht ganz klar ist ist der Umstand, wie in Zukunft die portable Core Edition und die Windows spezifische Desktop Edition der PowerShell weiterentwickelt werden. Erstere basiert auf .NET Core, Letzere auf dem „Full .Net Framework“. Joey Aiello sagte in der kleinen Q&A am Ende des ersten Tages, dass aktuell ein Feature zuerst in die Core Edition eingebaut und dann überlegt wird, ob es auch in die Desktop Edition passt. Dann werden sich beide Editionen (Core und Desktop) nur durch Module unterscheiden und denselben „Kern“ in Gestalt einiger portabler Assemblies (vor allem natürlich System.Management.Automation.dll) verwenden.

Vortrag: Automatisiertes DC Deployment mit DSC mit Jan-Hendrik Peters und Raimund Andree

In diesem Vortrag ging es um ein Projekt, das bei der BMW AG in München zur Zeit umgesetzt wird. Im Wesentlichen geht es um Deployment von Domänenkontrollern per DSC bzw. die Umsetzung eines „Self Service Portals“. Wenn ich es richtig verstanden habe, fällt das Zwischenfazit etwas durchwachsen aus, was u.a. an den kleineren Unzulänglichkeiten der aktuellen DSC-Implementierung liegt. Ein zentraler Punkt in der Keynote von Jeffrey Snover waren daher auch die geplanten Verbesserung bei DSC, u.a. die Implementierung als Systemdienst, mehrere Instanzen und eine Umstellung auf Open Source. Unter Azure soll DSC in Zuukunft eine zentrale Rolle spielen. Es war außerdem nett, Raimund Andreé einmal persönlich kennenzulernen, dessen LocalAccounts-Modul ich schon gefühlt 100 Mal bei diversen Anlässen (in erster Linie Schulungen) heruntergeladen hatte.

Vortrag: The Release Pipeline in Practice mit Matt Hitchcock

Interessanter Vortrag, vor allem, dass PowerShell eher ein Randthema war. In erster Linie ging es um das Aufsetzen einer Release Pipeline für ein Open Source-Projekt mit Circle CI, einem Webportal, vergleichbar mit AppYeyor, das allerdings auf .NET-Projekte beschränkt ist, und natürlich Visual Studio Online.

Vortrag: PowerShell sicher im Unternehmen einsetzen mit David das Neves

Ein allgemeiner Vortrag zum Thema Sicherheit unter Windows mit Bezug auf die PowerShell. Interessant ist, dass David bei Microsoft in München angestellt ist und damit offenbar der einzige Mitarbeiter bei Microsoft in Deutschland ist, in dessen Jobbeschreibung das Wort PowerShell vorkommt.

Vortrag: Azure 101 – PowerShell in der Cloud mit Jan-Hendrik Peters und Raimund Andreé

Dieser Vortrag begann am zweiten Tag bereits um 8 Uhr 30! Ich war pünktlich dort, hätte mir aber noch etwas mehr Zeit lassen können, denn der relativ kleine Raum war nur halbvoll und es ging ohnehin nur um einen Rundumüberblick über ein Thema, das für die meisten immer noch „Neuland“ sein dürfte.

Vortrag: Scoping in Depth mit Bruce Payette

Wenn der Entwickler der PowerShell-Skriptsprache eine Audienz hält ist der Raum natürlich voll. Dabei ging es um ein eher langweiliges Thema, den Gültigkeitsbereich von Variablen und Details wie den Umstand, dass das Ausführen eines Scriptblocks & einen neuen Context mit Session State anlegt, während beim Ausführen mit dem Punkt der aktuelle Session State mit seinen Variablen und anderen Inhalten übernommen wird. Eine weitere Erkennnis war, dass dynamische Module doch ihre Daseinsberechtigung besitzen. Ich bin mir relativ sicher, dass es am Ende auch um „Closures“ ging (also das Kopieren eines Scriptblocks, in dem der Scope des „Eltern-Scriptblocks“ übernommen wird), aber zu diesem Zeitpunkt war ich nur noch bedingt aufnahmefähig. Insgesamt definitiv ein interessanter Vortrag, der einige Zusammenhänge, die bei der Ausführung von Skripten eine Rolle spielen, deutlicher gemacht hat. Ein Detail am Rande: Die lange erwartete Überarbeitung von „PowerShell in Action“ (3. Auflage) ist offenbar fertig und soll im August (2017) kommen.

Vortrag: Advanced PowerShell Module Development with Visual Studio Code mit David Wilson

Sehr guter Vortrag vom Projektkoordinator der PowerShell Extensions für VS Code auch wenn ich leider etwas zu spät kam (u.a. da der Raum ein wenig „versteckt“ war). Der relativ große Raum war zudem komplett voll (ich hatte allerdings Glück, einen der wenigen noch freien Sitzplätze zu finden, ansonsten hätte ich den Rest des Vortrags am Eingang stehend verbringen müssen). Visual Studio Code ist ein genialer Editor, vor allem dank der ebenfalls genialen PowerShell-Erweiterung. Beide werden laufend weiterentwickelt. Es ist allerdings noch nicht alles „out of the box“ verfügbar, wer z.B. Pester-Tests direkt starten möchte, muss aktuell noch etwas an den Konfigurationsdateien basteln.

Vortrag: PowerShell Uncensored mit Jaap Brasser und Jason Yoder

Der Anschlusvortrag zu „Advanced PowerShell Module Development“ im selben Raum. Er begann unterhaltsam, doch gegen Ende war ein wenig die Luft raus und die gezeigten Beispiele (u.a. zu den Kennwortrichtlinien bei Windows Server und das Abfragen von Wetterdaten und Aktienkursen per Webservice-Aufruf) hatten nur noch indirekt etwas mit PowerShell zu tun. Faszinierend waren die Beispiele zum „Projekt Oxford“, auch wenn es hier ebenfalls nur indirekt um PowerShell ging. Auf den Punkt gebracht geht es bei dem Projekt darum, wie sich auf der Grundlage der von Microsoft als Teil des Azure Portals die „Emotion API“ (Stichwort: Machine Learning“ ) einbinden lassen Damit lassen sich z.B. Emotionen in Fotos, aber auch emotionale Stimmungen in Texten, etwa in Twitter Feeds, auswerten. Faszinierend und auch ein wenig beängstigend zugleich, denn ein „Emotionales Profiling“ wird damit zumindestens technisch sehr einfach möglich. Es ist naheliegend, die REST-API-Aufrufe in PowerShell-Functions zu kapseln, so dass sich die Auswertungen interaktiv durchführen lassen. Ein Dank an die beiden Sprecher, dass sie die Teilnehmer des Workshops bzw. die PowerShell Community auf diesen Bereich der IT aufmerksam gemacht haben. Mehr dazu unter https://blogs.msdn.microsoft.com/martinkearn/2016/03/07/using-the-project-oxford-emotion-api-in-c-and-javascript/.

Vortrag: Ghosts of DSC past, present and Yet-to-come

Diesen Vortrag hätte eigentlich Mark Gray aus dem PowerShell-Team halten sollen. Da dieser kurzfristig absagen musste, sprang Bruce Payette. Eigentlich kein schlechter Ersatz, denn Bruce ist einer der „Erfinder“ von DSC. Dennoch war der Vortrag für meinen Geschmack etwas zu allgemein gehalten und zwangsläufig etwas zu theoretisch. Bruce ging im Wesentlichen die Folien seines Kollegen durch und würzte die Inhalte mit eigenen Kommentaren. Für jemand, der DSC bereits in der Praxis einsetzt, war der Informationsgehalt daher gering. DSC ist ein Thema, das von der Praxis lebt.

Vortrag: Using Desired State Configuration in Azure mit Will Anderson

Der Vortrag fand zeigleich zu „PowerShell Past Present and Future“ statt und war bereits eventuell deswegen nur spärlich besucht (trotzdem lief die Klimanlage an dem nicht allzu warmen Tag in dem Raum auf Hochtouren). Ein anderer Grund könnte das Thema selber gewesen sein. Wenn DSC bei uns bislang kaum eingesetzt wird, dann sicher erst recht nicht unter Azure. Der Vortrag war aber trotzdem informativ und gab einen guten Überblick über ein Thema, das in Zukunft nach den Plänen von Microsoft eine größere Rolle spielen soll. Will Anderson ist PowerShell MVP aus den USA und hat bereits „jede Menge“ Artikel über DSC für die „Hey, Scripting Guy“-Kolumne geschrieben. Sein Blog ist http://lastwordinnerd.com.

Vortrag: Test your Powershell code with AppVeyor for ITPros mit André Kamman

Vortrag: PowerShell Present and Future mit Angel Calvo und Kenneth Hansen

Zu diesem Vortrag kam ich nur noch zum Schluss, da ich den parallel laufenden Vortrag zum Thema Azure und DSC vorgezogen hatte. Der kleine Raum war packend voll was bei dem Thema zu erwarten gewesen war. Für mich blieb noch eine kleine Stellfläche unmittelbar an der Tür, die dadurch nicht mehr hätte geöffnet werden können, ohne mich beiseite schieben zu müssen. Allzu viel bekam ich auch nicht mehr mit, außer, dass das PowerShell Team sehr am Feedback seiner Anwender interessiert ist (keine Neuigkeit). Ich denke, dass es bei kommenden Versionen nicht darum gehen kann „jede Menge“ weitere Features einzubauen (was auch nicht geplant zu sein scheint). Sehr viel wichtiger ist es, die Erlernbarkeit der PowerShell zu verbessern bzw. den Umstand zu adressieren, dass die PowerShell für den typischen Admin immer noch zu technisch und damit zu kompliziert ist und damit nicht ihren Zweck erfüllt. Der Umstand, dass ein kleiner Raum auf einer mit knapp 300 Teilnehmern insgesamt eher kleinen Konferenz voll war, ist für mich kein Beleg, dass sich am Umfang der Nutzung der PowerShell bei den Administratoren in den letzten Jahren grundlegend etwas geändert hat. Ich schätze, das der Anteil der PowerShell-Anwender unter den Administratoren immer noch kleiner als 10% ist. Auch wenn der Einstz von PowerShell-Skripten selbstverständlich geworden ist, ist er immer noch die Ausnahme und nicht die Regel.

Vortrag: Ask Microsoft anything mit Angel Calvo, Bruce Payette, David Wilson, Jeffrey Snover, Joey Aiello und Kenneth Hansen

Beim Abbschlussvortrag am letzten Tag gab es noch einmal die Gelegenheit, das PowerShell Team und damit Microsoft alles Mögliche zu fragen (wenngleich es nicht auf jede Frage eine Antwort gab). Diese Gelegenheit wurde von den Anwesenden auch ausgiebig genutzt, so dass die Session ca. 20 Minuten länger ging als geplant (ich habe meinen Zug um 17 Uhr 07 nach Stuttgart aber trotzdem gerade so noch erwischt). Meine Frage, wann es denn endlich auch eine deutschsprachige PowerShell-Hilfe geben würde ergab, dass dies so schnell nicht passieren wird. Schade.

Wer bis hier alles gelesen hat, alle Achtung;) Und dabei waren es nur gerade mal 12 der ingesamt knapp 80 Vorträge, die auf der Konferenz gehalten wurden.

Weitere Stichworte in loser Reihenfolge:

>Für ScriptBlock-Logging wäre ein Auswertungstools praktisch.
>AppLocker kann die Ausführung von Ps1-Skripten verhindern, nur wer verwendet AppLocker?
>WMF 5.1 sollte der Standard sein
>GlusterFS – Einrichten eines verteilten Dateisystems (läuft aktuell aber nur unter Linux)
>Aufruf eines Scriptblocks mit . und & – einmal mit neuem ExecutionContext, einmal wird der vorhandene ExecutionContext übernommen
>Mehr Sicherheit durch systemweite Transcripts?
>Es gibt offenbar eine Variable, durch die sich das implizite Laden von Modulen deaktivieren lässt – in einer DSC-Konfiguration werden Module nicht implizit geladen – den Namen habe ich aber nicht behalten;)
>Phosphor in ein interessantes PowerShell-Modul für das automatische Erstellen einer auf HTML und JavaScript und damit plattformunabhängigen Benutzeroberfläche für PowerShell-Skripte

PowerShell VIPs zum Anfassen


Wie unterscheidet sich die PoshConf von einer StarTrek-Konvention? Ganz einfach, die Autogrammkarten sind kostenlos bzw. es gibt natürlich keine. Wer sich mit Jeffrey, Bruce, Joey oder einem anderen „PowerShell VIP“ fotografieren lassen wollte, hatte dazu jede Menge Gelegenheit. Entweder bei der offiziellen „Foto Box“, die am Dienstagabend auch im Yukon Bay-Restaurant aufgestellt war, oder natürlich per Selfie. Auch Autogramme gab es theoretisch jederzeit auf alle beschreibaren Materialien.

Daneben gab es auch viel PowerShell-Prominenz aus dem Aus- und Inland, u.a. Luc Dekens (Power CLI), Matthew Graeber (u.a PowerSploit), Bartosz Bielawski (u.a. Linux), Ian Brighton (PScribo) und natürlich Chrissy Le Maire (u.a. DBaTools). Beim Schreiben der Namen fällt mir auf, dass ich eigentlich mit keinem der Experten persönlich gesprochen habe und Ian Brighton, dessen PScribo-Modul ich öfter verwende, noch nicht einmal gesehen habe (eventuell war er auch gar nicht dabei, da ein Sprecher kurzfristig absagen musste, ein anderer erhielt offenbar kein Visum für die Einreise). Es waren zwar „alle“ da und theoretisch gab es auch jede Menge Gelegenheiten für ein kurzes Gespräch, per Zufall ergab sich aber relativ wenig (was auch an der Lokalität des Kongresszentrums in Hannover mit seinen langen Wegen, verschlungenen Gängen und den teilweise kleinen Räumen gelegen hat), man musste selber aktiv werden falls man mit einem PowerShell-Guru, den man bislang nur vom Namen her kannte, ins Gespräch kommen wollte.

Fazit


Für PowerShell Pros hat die Teilnahme an der Konferenz mit Sicherheit sehr viel an neuem Know-how, Anregungen und Kontakte gebracht. Dafür sorgten die in der Regel praxisnahen Konferenzthemen und die Anwesenheit zahlreicher PowerShell-Experten aus Europa und natürlich dem PowreShell-Team selber. Auch der Umstand, einmal auf direkte „Tuchfühlung“ mit den Verantwortlichen bei Microsoft gehen zu können, trug dazu bei, dass man das Gefühl haben konnte drei Tage Know-how für die nächsten Monate und eventuell auch Jahre „aufsaugen“ zu können. Vor der Beginn der Konferenz gab es wie üblich noch einen Workshop-Tag, in dem es u.a. um eine Einführung in DSC, PS-Remoting oder „neumodische“ Themen wie Nanoserver und Container ging. Schön war auch, dass es eine europäisch ausgerichtete Konferenz war. Die Teilnahme kostete 1.000€ zzgl. Mwst, durch Anreise und Hotel kamen noch einmal im Durschnitt 400€ hinzu. Das Gesamtpaket PowerShell-Konferenz kostet daher ca. 1.500€. Deutlich weniger als eine klassische Schulung in diesem Bereich.

Windows 7 – von 2 auf 5.1 – mit Zwischenschritt über die Version 5.0

Vor einiger Zeit hatte ich beschrieben, wie man unter Windows 7 in einem Schritt von Version 2.0 auf 5.0 aktualisiert:

http://poshadmin.de/?p=616

Möchte man gleich auf die aktuelle Version 5.1 umsteigen, was ich empfehle, ist wieder etwas mehr Aufwand erforderlich, denn auch hier muss zuerst auf Version 5.0 aktualisiert werden. Erst danach kann das Update für die Version 5.1 installiert werden.

Es ist interessant, dass das Update für Windows 7 als Zip-Datei zur Verfügung gestellt wird, das aus einer Ps1- und der Msu-Dateu besteht. Offiziell soll man die Ps1-Datei starten, die eine Reihe von Tests durchführt, um zu entscheiden, ob das Update durchgeführt werden kann usw. Wer WMF 5.0 bereits installiert hat, startet die Msu-Datei direkt.

Sollte die Installationsdatei wider Erwarten doch in einer Update-Endlosschleife höngen bleiben, liegt dies an der Datei WSUSSCAN.cab. In diesem Fall sieht es fast so aus, als müsste die ganze Prozedur auch für das 5.1-Update für jede einzelne (!) Cab-Datei wiederholt werden. Erst wenn die Neustart-Meldung erscheint, wurden alle Teil-Updates installiert.

Was ich Bruce (Payette) noch hätte fragen können…

Die PoshConf 2017 liegt schon wieder über eine Woche zurück, ein kurzer Bericht folgt in Kürze. Es ist immer wieder ein Erlebnis Bruce Payette, einer Köpfe hinter der PowerShell-Skriptsprache zu treffen. Theoretisch kann man ihn alles fragen was man jemals über die PowerShell wissen wollte, es aber niemanden fragen konnte. Theoretisch. Praktisch gehen die 3 Tage doch schnell vorüber und in dem dicht gefüllten Konferenzprogramm bleibt dann noch zu wenig Zeit. Das nächste Mal schreibe ich mir die Fragen vorher auf bzw. sammele sie in diesem Blog.

Hier ist schon die erste Frage:

Warum braucht ein PowerShell-Ausdruck immer dieses eine Paar runder Klammern extra?

Hier ein Beispiel. Der folgende Befehl soll per Write-Progress den Wert einer Variablen ausgeben und sie vor der Ausgabe um eins erhöhen. Das erledigt der folgende Befehl:

Es stört mich jedes Mal, dass ich es erst nach ein paar Mal ausprobieren hinbekomme, weil ich jedes Mal das zweite Paar runder Klammern weglasse, dass eigentlich überflüssig sein sollte. Eigentlich. Wahrscheinlich hat es was mit den verschiedenen Modi des PowerShell-Interpreters zu tun.

Aus aktuellem Anlass: SMB1 deaktivieren

Zur Zeit treibt der WannaCry-Trojaner sein Unwesen und richtet teilweise erheblichen Schaden an, da die Infrastruktur im öffentlichen Raum (in erster Linie offenbar Krankenhäuser in Großbritannien) vorübergehend nur eingeschränkt funktionsfähig ist. Über den Ursprung des Trojaners möchte ich nicht spekulieren, genauso wenig, ob es unter Windows mehr Sicherheitslücken gibt wie unter Linux&Co. Ein Fakt ist, dass Microsoft einen enormen Aufwand betreibt, um durch das zeitnahe zur Verfügung stellen von Patches den durch die Verwendung von Windows eingetretenen Schaden zu begrenzen. Allerdings darf man nicht Ursache und Wirkung verwechseln. Die Verbreitung wird leider durch den Umstand verursacht, dass es offenbar immer noch Menschen gibt, die E-Mail-Anhänge doppelt anklicken.

Die Verbreitung im LAN geschieht offenbar über eine Lücke im SMB1-Protokoll. Dieses lässt sich per PowerShell sehr einfach deaktivieren:

Die PowerShell muss dazu als Administrator gestartet werden. Ein Get-SmbServerConfiguration fragt die aktuelle Einstellung ab. Dank PS-Remoting ist es theoretisch eine Kleinigkeit, diese Abfrage in der gesamten Domäne durchzuführen. Wenn man dann noch mit Pscribo einen kleinen Report anfertigt, aus dem hervorgeht, dass auf 100% der Computern in der Domäne SMB1 deaktiviert wurde, dürfte das Ganze beim Vorgesetzten einen guten Eindruck machen (natürlich vorausgesetzt, dass SMB1 nicht doch für irgendetwas Unternehmenskritisches benötigt wird;)

ipconfig /displaydns-Output mit ConvertFrom-String verarbeiten

Ipconfig ist ein vielseitiges Tool. Ich benutze es immer noch, auch wenn z.B. Get-NetIPAddress einen etwas übersichtlicheren Output produziert.

Ein Pedant zum Schalter /displaydns gibt es bei den PowerShell-Commmands nicht. Leider ist die Ausgabe etwas unübersichtlich. Da man sich im Allgemeinen nur für die Hostnamen interessiert, mit denen irgendwelche Prozesse auf dem PC eine Verbindung herstellen, wäre es praktisch, wenn es eine Möglichkeit gäbe zu erreichen, dass nur diese Namen ausgegeben werden.

Mit dem vielseitigen ConvertFrom-String-Cmdlet, das ab der Version 5.0 zur Verfügung steht, gibt es eine solche Möglichkeit. Das Cmdlet ist leistungsfähig, aber etwa spärlich dokumentiert und bereits deutlich anspruchsvoller als z. B. Select-String.

Die Idee ist, dass aus meinen Mix aus Mustertext und vereinfachter regulärer Ausdrucks-Syntax ein Muster für einen unregelmäßig strukturierten Text zur Verfügung gestellt wird.

Das folgende Muster ist für die Ipconfig-Ausgabe mit dem Schalter displaydns gedacht:

Wichtig sind die geschweifte Klammer, über die einem Element des Textes ein Name gegeben wird. Der Mustertext wird in einer Textdatei gespeichert.

Der folgende Befehl gibt nur die Hostnamen aus dem DisplayDns-Output aus:

Mit dem ConvertFrom-String-Cmdlet kann man viel Zeit verbringen. Vieles habe ich nur per „Trial and error“ herausgefunden. Der Aufwand lohnt sich, denn wenn ein Muster funktioniert erhält man damit ein mächtiges Werkzeug für die Textauswertung.

Azure VMs konfigurieren per Custom Script Extension

Die Technik der Custom Script Extension gibt es bei Azure schon einige Jahre. Dahinter steckt ein Agent, der ein zuvor festgelegtes Skript auf die VM „anwendet, in dem es in ein Download-Verzeichnis gespeichert und dann ausgeführt wird. Das Skript kann ein PowerShell-Skript sein, es kann aber auch eine Exe-Datei oder etwas Anderes sein. Eine Custom Script Extension ist für spezielle Aktivitäten gedacht, die nach der Bereitstellung einer VM ausgeführt werden sollen. Sie können aber auch zu einem beliebigen Zeitpunkt ausgeführt werden.

Die sparsame Verwendung der Mehrzahlform deutet es dezent an, es kann pro VM nur eine Custom Script Extension geben. Über sie können aber mehrere Skripte zusammengefasst werden, von denen ein Skript automatisch ausgeführt wird.

Die Custom Script Extension ist z.B. für die automatisierte Installation von Anwendungen in einer VM gedacht.

Das soll ein kleines Beispiel veranschaulichen

Ausgangspunkt ist eine Exe-Datei, die in einem Azure Storage-Blob liegt:

$PackageUri = „https://standardspeicher.blob.core.windows.net/packages/SumatraPDF-3.1.2-64-install.exe“

Das ist aber keine Voraussetzung. Grundsätzlich spielt der Aufenthaltsort der Exe-Datei keine Rolle. Irgendwo in der Cloud oder in einem Ftp-Verzeichnis.

Gesucht ist ein PowerShell-Skript, dass diese Exe-Datei herunterlädt und ausführt. Das folgende Skript erledigt das:

Am Ende wird die Exe-Datei zusammen mit dem Schalter /S per Invoke-Expression ausgeführt. Nicht optimal, aber per Start-Process erhielt ich auch mit Admin-Credentials ein „Access Denied“ beim Versuch die Exe-Datei zu starten.

Das Skript selber befindet sich auch in einem Azure Storage-Account:

$FileUri = „https://standardspeicher.blob.core.windows.net/ps1blob/Azure_InstallAppForVM.ps1“

Das Skript, das die Custom Script Extension hinzufügt, ist wie folgt aufgebaut:

Die entscheidende Rolle spielt das Set-AzureRmVMCustomScriptExtension-Cmdlet aus dem AzureRm.Compute-Modul. Es richtet die Custom Sript Extension für die angegebene VM, die dazu ausführen muss, ein.

Der Run-Parameter legt das Skript fest, das ausgeführt werden soll (bei einem einzigen Skript ist er vermutlich nicht erforderlich – ich hatte keine Lust mehr das auszuprobieren;).

Ein

ruft die Custom Script Extension über ihren Namen ab.

In der Praxis müsste man die Installation z.B. über eine CSV-Datei steuern, in der die Namen, Urls usw. der zu installierenden Anwendungen ethalten sind.

Insgesamt ist die Custom Script Extension eine flexible Technik, die, anders als Azure DSC, auch keine zusätzlichen Kosten verursacht.

Azure VM per PowerShell und DSC konfigurieren

*** Rohentwurf – wird in den nächsten Tagen noch einmal überarbeitet ***

DSC ist eine flexible Angelegenheit, das gilt besonders im Zusammenhang mit der Konfiguration einer Azure VM. Per DSC lässt sich eine beliebige Konfiguration auf beliebige VMs anwenden mit minimalem Aufwand, da sich die Azure-Plattform um die „Feinheiten“ kümmert.

Im Folgenden stelle ich ein sehr einfaches Beispiel vor, bei dem lediglich ein Verzeichnis mit einer Datei und einem bestimmten Inhalt angelegt werden. Da der Name des Verzeichnisses und der Inhalt der Datei über Konfigurationsdaten festgelegt werden, wird es auch bei diesem Beispiel etwas interessanter.

Voraussetzung sind:
>Ein Azure-Konto
>Eine Windows VM (theoretisch funktioniert es auch mit einer Linux VM)
>Ein Azure-Automationskonto, das zuvor gegebenenfalls angelegt werden muss

Schritt 1: Die DSC-Konfiguration wird in einer Ps1-Datei lokal gespeichert

Und was ist mit den Konfigurationsdaten? Die kommen etwas später ins Spiel.

Schritt 2: Anlegen einer DSC-Konfiguration im Automations-Konto
Dieser Schritt ist sehr einfach, denn es wird lediglich die Ps1-Datei hochgeladen.

Schritt 3: Die Konfiguration wird in eine Mof-Datei kompiliert und damit ein Knoten angelegt
Dieser Schritt wird bei einfachen Konfiguration direkt im Azure-Portal durchgeführt. Eine Ausnahme liegt vor, wenn Konfigurationsdaten im Spiel sind. In diesem Fall muss die Kompilierung (Stand: Mail 2017) noch per PowerShell-Cmdlets lokal ausgeführt werden.

Das erledigt die folgende Befehlsfolge:

Der Name der VM lautet in diesem Beispiel „TestVM2“.

Die Bereitstellung dauert ein paar Minuten. Ging alles gut, werden am Ende aufgetretene Meldungen ausgegeben. Fehler sollten keine dabei sein, lediglich ein Warnung, die besagt, dass das Microsoft.PowerShell.Managagement-Snapim nicht geladen wurde. Dies ist aber nur eine Warnung, kein Fehler.

Ob das Kompilieren erfolgreich war, erfährt man aus dem Azure-Portal.

Schritt 4: Der Knoten wird einer VM zugeordnet
Im letzten Schritt muss lediglich der Pull Server-Knoten einer VM zugeordnet werden. Dieser Schritt besteht aus weiteren Teilschritten und wird im Portal nicht wirklich intuitiv angeboten:

>Hinzufügen einer Azure VM über +Azure-VM hinzufügen
>Auswahl der VM und Bestätigen mit OK
>Registrieren des Knotens und Bestätigen der Konfigurationsdaten und Bestätigen mit OK
>Erstellen

Ist dies erledigt, dauert es ca. 15 Minuten bis die Konfiguration angewendet wird.

Azure VM per PowerShell und CustomScript Extension vorkonfigurieren

*** noch im Rohmodus – der Beitrag wird in Kürze noch einmal überarbeitet ***

Möchte man man eine Azure VM skriptgesteuert vorbereiten, z.B. bestimmte Anwendungen vorabinstallieren, gibt es dafür grundsätzlich zwei Alternativen, die keine Tools anderer Hersteller oder Microsoft SCCM voraussetzen:

>Azure DSC
>Eine Extension in Gestalt der CustomScriptExtension, die entweder beim Anlegen der VM oder nachträglich als Erweiterung ausgewählt wird

Beide Ansätzen besitzen, wie könnte es anders sein, ihre kleineren Vor- und Nachteile. Variante 1, die ich in seinem separaten Blog-Eintrag in naher Zukunft vorstellen werde, setzt etwas mehr Vorbereitungsaufwand voraus und kann aktuell nicht vollständig im Portal umgesetzt werden, ist aber flexibler, da sich eine beliebige Anzahl an VMs damit konfigurieren lassen. Variante 2 ist einfach, da lediglich ein vorhadenes PowerSHell-Skript geladen wird, dafür aber nicht so flexibel (ich bin mir im Moment nicht sicher, ob die Erweiterung per Azure-Cmdlets einer beliebigen Anzahl an VMs zugeordnet werden kann. Generell empfehle ich DSC, aber mehr nur ein paar VMs vorkonfigurieren möchte, kommt mit Variante 2 schneller zum Ziel.

Schritt 1: Auswahl der Erweiterungen für die VM

Im ersten Schritt meldet man sich am Azure-Portal aus, selektiert die bereits vorhandene VM und danach Erweiterungen.

Auswahl der Erweiterungen für eine VM

Schritt 2: Hinzufügen der CustomScriptExtension

Sollte die CustomScriptExtension noch nicht in der Liste der Erweiterungen enthalten sein, muss sie über das +-Zeichen hinzugefügt werden. Dabei wird ein vorhandenes Ps1-Skript hochgeladen. Theoretisch sollte es auch aus einem Storage Account geladen werden können.

Anlegen einer CustomScript Extension


Schritt 3: Anwenden der CustomScriptExtension
Wurde die CustomScriptExtension eingerichtet, erscheint sie in der Liste der Erweiterungen.

Die CustomScriptExtension wurde bereitgestellt

DSC in der Praxis – Anwendungen installieren über die Ressourcen Package und WindowsProcess

DSC lässt sich für viele Konfigurationsaufgaben einsetzen, z. B. auch für die Installation von Anwendungen. Warum nicht? Die Idee ist, dass man eine Liste von Exe- und Msi-Dateien zusammen mit Argumenten zusammenstellt, die auf einer Reihe von Nodes installiert werden sollen. Man schießt die DSC-Konfiguration per Start-DSCConfiguration ab („Make it so“), DSC verteilt diese auf die einzelnen Nodes und der LCM auf jedem Node arbeitet die Liste ab und installiert jede Anwendung durch Ausführen der Exe-Datei. Hört sich in der Theorie einfach an, die Umsetzung in der Praxis ist auch nicht allzu kompliziert, sieht man von den üblichen Stolpersteinen ab.

Einen guten Überblick für den Einstieg gibt ein Artikel vom PowerShell-Experte Adam Betram: https://4sysops.com/archives/installing-software-with-powershell-dsc. Er beschreibt, wie sich per DSC und der Package Ressource eine Anwendung (7-Zip) installieren lässt. In seinem Beispiel befindet sich die Msi-Datei aber in einem lokalen Verzeichnis. Die Frage ist, wie kommt sie dort hin? Entweder durch Kopieren aus einer Freigabe, die z.B. für ein Azure Storage-Blob angelegt wurde. In diesem Fall kommt aber die Berechtigungsproblematik ins Spiel und das Kennwort muss per Zertfikat verschlüsselt werden. Einfacher und unkomplizierter geht es per direkten Download der Datei. Da es dafür aber offenbar keine Ressource gibt, habe ich solche selber gebastelt.

Meine Lösung soll insgesamt etwas flexibler sein, in dem mehrere Apps installiert werden, deren Namen in den externen Konfigurationsdaten abgelegt sind. Außerdem sollen sich die Exe-Dateien in der Cloud befinden, z. B. in einem Azure Storage Account.

Das folgende Listing zeigt die gesamte DSC-Konfiguration, allerdings ohne die Konfigurationsdaten.

Die Konfigurationsdaten habe ich in einer separaten Psd1-Datei untergebracht.

Ausgeführt wird die Konfiguration per Start-DSCConfiguration:

Ich habe mich in dem Beispiel auf Exe-Installationsprogramme beschränkt, damit es übersichtlich bleibt. Für Msi-Pakete ist die Package-Ressource die etwas bessere Wahl.

Den Download der Exe-Dateien aus meinem Azure Storage-Blob übernimmt eine DSC-Ressource, die ich dafür geschrieben habe. Sie besteht aus zwei Dateien:

>xDownloadFileResource.psd1
>xDownloadFileResource.psm1

Die Psd1-Datei ist wie folgt aufgebaut:

Die Logik der Ressource ist in der Psm1-Datei enthalten:

Leg unter C:\Program Files\WindowsPowerShell\Modules ein Verzeichnis „xDownloadFileResource“ und darin ein Unterverzeichnis „1.0“ an und leg die Psd1- und die Psm1-Datei in diesem Verzeichnis ab.