Archiv für den Monat: März 2016

Tipp: Beliebige Programme starten in einer Remoting-Sitzung

Mit einer PowerShell-Remoting-Sitzung geht eine gewollte Einschränkung einher: Da zwangsweise eine Session vom Typ NonInteractive angelegt wird, ist es im Rahmen der Session nicht möglich, Meldungen auf dem Remote-Computer auszugeben, Eingaben entgegenzunehmen und Programme mit einer Fensteroberfläche zu starten. Der unter Kollegen beliebte Trick irgendwelche Fenster auf dem Desktop des Nachbarn aufpoppen zu lassen, funktioniert daher nicht.

Es gibt eine Alternative, die relativ einfach umsetzbar ist: Das zu startende Programm wird über eine geplante Aufgabe gestartet, die durch Invoke-Command auf dem Remote-Computer angelegt wird.

Der folgende PowerShell-Scriptcode veranschaulicht das Prinzip – er legt eine Aufgabe an, die 30s danach den Windows-Rechner startet. Damit er auch tatsächlich funktioniert, müssen die üblichen Voraussetzungen für PowerShell-Remoting erfüllt sein.

Tipp: Mit Regex auf das Nichtvorhandensein von Text prüfen

Regexe (reguläre Ausdrücke) sind enorm praktisch, aber wie ich es aus meinen PowerShell-Schulungen weiß, sie wirken nicht gerade einladend. Ein weiteres „Problem“ ist, dass einfache Dinge am Anfang enorm kompliziert wirken. Ein einfaches Beispiel: Wie prüfe ich per Regex, dass eine Zeichenkette nicht mit einem bestimmten Muster beginnt? Der NotMatch-Operator ist nur scheinbar eine Lösung, der prüft, ob das gesamte Muster nicht vorkommt.

Ausgangspunkt ist eine Liste von Namen:

Das Ziel soll es sein, dass alle Namen ausgegeben werden, die nicht mit „Server“ beginnen. Klar, dafür gibt es den Like-Operator, doch als kleine Schwierigkeitssteigerung soll auch die Zahl am Ende ausgegeben werden (auf die theoretisch wiederum Buchstaben folgen könnten).

Das folgende Muster löst die Aufgabe:

Es kann entweder per Match-Operator:

oder per [Regex] angewendet werden. In diesem Fall erhält man auch die Ziffer über die zweite Gruppe:

Wo bleibt PowerShell 5.0 (bzw. WMF 5.0)?

Das PowerShell-Team macht es äußerst spannend was die offizielle Freigabe der Version 5.0 des Windows Management Framework und damit der PowerShell 5.0 angeht. Nachdem mit Windows 10 bereits (lange ist es her;) im Sommer letzten Jahres eine Vorabversion „offiziell“ wurde, gab es im Dezember letzten Jahres die RTM-Version (Release to Manufacturing – ein netter Anachronismus und eine Art „Hommage“ an die Ära, als Betriebssysteme noch auf Disketten ausgeliefert wurden), die aber kurz danach aufgrund eines kleinen Bugs im Zusammenhang mit der Umgebungsvariablen PSModulePath wieder zurückgezogen werden musste. Seit ein paar Tagen gibt es die RTM-Version wieder, u.a. auch für Windows 7, so dass die Frage zwangsläufig im Raum steht wann es denn die offizielle Version geben wird. Wie es aus einer Antwort zu den Kommentaren des Blog-Eintrags des PowerShell-Teams hervorgeht, soll es Ende März soweit sein:

https://blogs.msdn.microsoft.com/powershell/2016/01/19/windows-management-framework-wmf-4-0-update-now-available-for-windows-server-2012-windows-server-2008-r2-sp1-and-windows-7-sp1/#comments

Insgesamt gibt es WMF 5.0 RTM für 7 verschiedene Windows-Vesionen. Da es naturgemäß daher nicht ganz einfach ist, den für ein bestimmtes Betriebssystem erforderlichen Download zu finden, empfehle ich den sehr hilfreichen Blogeintrag des PowerShell-MVPs Emin Atac:

https://p0w3rsh3ll.wordpress.com/

PowerShell goes Open Source?

Noch ist es nicht offiziell, aber ich kann mir gut vorstellen, dass das PowerShell-Team im Laufe des Jahres den Kern von WMF (Windows Management Framework) im Quellcode unter GitHub freigibt und die PowerShell damit zu einer Open Source-Anwendung wird.

Die Adresse gibt es bereits:

https://github.com/powershell

Aktuell sind dort u.a. alle von Microsoft veröffentlichten DSC-Ressourcen, Module wie PSReadLine, die Open SSH-Portierung und die Sprachspezifikation zu finden. Interessant ist, dass offenbar auch die PowerShell-Dokumentation (endlich) in verschiedene Sprachen übersetzt wird. Die entsprechenden Unterverzeichnisse und damit Projektnamen liegen bereits vor.

Damit keine Missverständnisse entstehen. Ob es eine „Open Source-PowerShell“ jemals geben wird ist aktuell pure Spekulation meinerseits, aber ich denke, dass einiges dafür spricht. Es ist aus meiner Sicht weniger eine Frage des Wollens, sondern eher eine Frage des Könnens bzw. der Organisation. Damit ein Projekt „Open Source“ gehen kann, das nicht von Anfang an quelloffen entwickelt wurde, ist viel Vorbereitunsaufwand erforderlich, so dass dies nicht einfach auf Knopfdruck geschehen kann. Ein Open Source-Projekt bedeutet (natürlich) nicht nur, dass der Quellcode auf GitHub heruntergeladen werden kann, es bedeutet in erster Linie, dass die Community in den Entwicklungsprozess integriert werden kann und Änderungen in Gestalt von „Pull requests“ aus der Community wieder in den Entwicklungsprozess einfließen können. Dazu muss ein interner Prozess etabliert werden, bei dem z.B. sichergestellt ist, dass die Änderungen zuvor getestet wurden. Ähnlich oder identisch jenem Prozess, der bereits für .NET Core, dem Open Source-Kern des .NET Framework, etabliert wurde. Und dieser Prozess bedeutet bei Microsoft, dass sich festangestellte und in der Regel gut bezahlte Mitarbeiter darum kümmern. Es entbehrt daher nicht einer gewissen Ironie, dass die inzwischen zahlreichen Open Source-Projekte auch Microsoft jedes Jahr ein paar Millionen kosten dürften.

Auf alle Fälle ist es eine spannende Entwicklung. Ich kann mir gut vorstellen, dass es anlässlich der Build-Konferenz Ende März oder anlässlich der Ignite-Konferenz im September dieses Jahres entsprechende Ankündigungen geben wird.