Neues zur PowerShell (Stand: Mai 2020)

Auch wenn alles im PowerShell-Teamblog zu lesen ist (der unter neuer und etwas gewöhnungsbedürftiger Optik vor einiger Zeit umgezogen ist – die neue Adresse ist devblogs.microsoft.com/powershell), hier eine Kurzzusammenfassung:

>PowerShell 7.0 wurde im Januar freigegeben, die Version 7.1 liegt bereits als Preview vor. Die wichtigste „Neuerung“ ist die Umstellung auf das kommende .NET 5.0, das .NET Framework und .NET Core vereinen wird. Darüber hinaus gibt es aber zahlreiche kleinere Verbesserungen bei einzelnen Cmdlets und Fehlerkorrekturen.

>PowerShellGet 3.0

Es gibt eine komplett überarbeitete Version des mit Version 5.0 eingeführten „Package Managers Managers“ für die Paketverwaltung für Module, Skripte und DSC-Ressourcen. Das ist positiv, da die erste Version von PowerShellGet einige Schwächen hatte.

>Out-GridView für die Konsole

Das ist eine sehr interessante Neuerung. Eine GridView-Ausgabe für die Konsole. Damit lassen sich die Rückgabewerte einer Abfrage deutlich besser darstellen als per Format-Table. Aktuell gibt es die ConsoleGuiTools nur für Linux und MacOS, in Kürze wird es sie natürlich auch für Windows geben (bevor jetzt jemand vermutet, dass dies ein weiterer Beleg dafür ist, dass Microsoft heimlich plant, Windows durch Linux zu ersetzen – technisch wäre es vermutlich mit vertretbarem Aufwand möglich – Schuld ist in diesem Fall lediglich ein harmloser Bug in der externen Datei Gui.cs, die ein portable GUI-Bibliothek im Stile einer MS-DOS-GUI zur Verfügung stellt – wer Programme wie Midnight Command kennt, weiß was gemeint ist;).

>Secret Mangement – was steckt dahinter?

Wenn ein Blog-Eintrag eines weltweiten Konzerns mit „We are excited to release…“ beginnt, muss man eigentlich nicht weiterlesen, denn das ist in den USA seit Jahrzehnten bekanntlich Standard-Marketing-Englisch. Aber wenn es jemand aus dem PowerShell-Team schreibt, lese ich natürlich (ganz aufgeregt;) weiter. Und es geht um Secrets. Wir wissen ja alle, dass der Umgang mit SecureStrings und PSCredentials nicht der Weisheit letzter Schluss sein kann (und die Version 5.0 eingeführten CMS-Cmdlets, die das Verschlüsseln von Texten mit Zertifikaten ermöglichen sollen, dürfte niemand benutzen). Und tatsächlich geht es mit diesem Modul genau in diese Richtung. Ein älterer Blog-Eintrag, den ich aber bislang noch nicht gelesen hatte, geht ausführlicher auf die Hintergründe des Secret Management-Moduls ein:

und

Die Kurzzusammenfassung: Mit dem Modul wird es möglich, beliebige „Geheimnisse“ (z.B. Texte aber auch vorhandene SecureStrings) sicher lokal zu speichern. Diese Technik löst (natürlich) nicht PSCredentials und SecureStrings ab, aber es wird mit ihr möglich, einen SecureString deutlich sicherer und konsistenter abzulegen als es aktuell der Fall ist. Und: Wie es in dem zweiten Blog-Beitrag von Paul Higinbotham beschrieben wird: Der vom SecretManagement-Modul verwendete Default-Vault speichert die Secrets im User Context, also nichts Neues, aber dank Vault Extensions könnte ein Secret so gespeichert werden, dass es übertragbar wird, z.B. für eine Anmeldung an eine Webseite aus einer App heraus (?).

Aktuell ist das SecretManagement-Modul noch Preview – wer es installieren möchte, muss bei Install-Module den (mir bislang unbekannten) Parameter AllowPreview verwenden:

Install-Module Microsoft.PowerShell.SecretManagement -Repository PSGallery -AllowPrerelease

Das grundsätzliche Problem mit SecureStrings wird also nicht „out of the box“ gelöst, wenngleich es grundsätzlich möglich ist – das hätte Blog-Autorin Sidney Smith eigentlich erwähnen sollen. Auf diesen Umstand weist auch Klaus Schulte in seinem Kommentar am Schluss des Blogs hin. Schade, dass solche Beiträge (man muss leider sagen wie üblich) nicht vom PowerShell-Team weiter kommentiert werden. Ein konstruktiver Dialog mit dem „Anwender/Kunden“ kommt damit nicht zustande. Es bleibt bei der Verkündigung einer Neuerung (anders sieht es natürlich im Projektportal aus, wo zwischen den Entwicklern und Usern eine rege Diskussion entsteht, wenn es um „Issues“ wie vermeintliche Fehler oder Verbesserungsvorschläge geht). Interessant ist aber der Hinweis von Klaus Schulte auf KeePass und das PoshKKeePass-Modul, das ich bislang noch nicht verwendet habe.

Zusammenfassung: Die Entwicklung der PowerShell geht in die richtige Richtung. Leider ist die „Kunden-Kommunikation“ des PowerShell-Teams ausbaufähig. Sowohl quantitativ als auch qualitativ. Ich bezweifele, dass sich die Mehrheit der PowerShell-Anwender die Zeit nimmt und versucht, über die unregelmäßigen und leider oft etwas unvollständigen Blog-Einträge auf dem laufenden zu bleiben und sich die gegebenenfalls fehlenden Puzzlestücke zusammenzusuchen. Die entscheidende Frage, warum man eine bestimmte Neuerung im Admin-Umfeld wirklich braucht, wird leider so gut wie nie adressiert.

Positiv ist, wieviele der kleinen Änderungen und Fehlerkorrekturen aus der Community stammen (dabei frage ich mich allerdings immer, wo die Leute die Zeit hernehmen, die für das Einarbeiten in den umfangreichen Quellcode und das Testen einer Änderung erforderlich ist bevor man überhaupt einen Pull Request starten kann).

Bei PowerShell 7.0 sind für mich die wichtigsten Innovationen das Remoting per SSH und die Parallelisierung bei ForEach-Object durch den neuen Parallel-Parameter. Auch das neue PowerShellGet-Modul, das Secret Management-Modul und die portablen GUI-Oberflächen, die zu 100% in der Konsole umgesetzt werden, wirken attraktiv und werden die Möglichkeiten, Leistungsfähigkeit und damit auch die Reichweite von PowerShell-Skripten verbessern.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.