PowerShell 4.0 im Überblick

Frank-Michael Schlede und Thomas Bär sind IT-Consultants und freiberufliche Mitarbeiter unserer Schwesterpublikation TecChannel. Wer die verschiedenen Versionen der PowerShell und ihre unterschiedlichen Features in den vergangenen Jahren verfolgt hat, konnte eine stetige Entwicklung von einer einfachen Batch- und Scripting-Sprache hin zu einem ausgereiften Werkzeug zur Administration und Automatisierung der Windows-Systeme beobachten. Auch wenn der Wechsel der Versionsnummer von 3.0 auf 4.0 ein grosses Release erwarten lässt, sind die Aktualisierungen wenig spektakulär. Zu den Neuerungen zählen: • die Unterstützung für Workflow- und RemoteDebugging von Scripts; • verbesserte Funktionen für das Workflow-Authoring, die auch zur Vereinheitlichung mit dem Script-Authoring dienen; • als allgemeiner Parameter steht nun «-PipelineVariable» zur Verfügung; • verbesserte Unterstützung zum Herunterladen aktualisierbarer Hilfe unter Verwendung von «Save-Help» und «Update-Help», die nun auch für Offline-Systeme verwendet werden kann; • Verbesserung bei der integrierten Entwicklungsumgebung ISE; • verbesserte PowerShell Web-Dienste und • die «Desired State Configuration» als wichtigste Neuerung für Administratoren. Nächste Seite: Hilfe zur Selbsthilfe Wer die PowerShell 3.0 auf seinem System installiert hatte, kennt das Problem, die Hilfe zu verwenden: Hatte Microsoft mit der Version 2.0 noch vollständige, sogar lokalisierte Hilfedateien automatisch eingerichtet, war ab Version 3.0 ein Grossteil nachträglich zu installieren. Grundgedanke dabei: Microsoft wollte sicherstellen, dass die Daten immer aktuell sind. Per sofort gibt es keine lokalisierten Hilfedateien mehr. Die Nutzer müssen mit den englischen Texten vorliebnehmen. So erscheinen dann auch bei den ersten Versuchen mit dem Cmdlet «Get-Help» keine ausführlichen Hilfetexte. Allerdings funktioniert im Gegensatz zur vorherigen Version nun auch das Nachladen der englischsprachigen Texte auf Systemen in deutscher Sprache. Dazu müssen Sie in einer PowerShell-Konsole mit Administratorrechten den folgenden Befehl aufrufen:

! KASTEN !

Ohne zusätzliche Parameter überprüft dieses Cmdlet die Versionen der Hilfedateien auf dem System und lädt die aktuellsten Dateien herunter. Für den Offline-Einsatz ist es bei der PowerShell 4.0 nun auch möglich, mithilfe des Cmdlets «Save-Help», diese Dateien aus dem Internet zu laden und im Dateisystem abzulegen. Danach können Administratoren diese Dateien mittels «Update-Help» und des Parameters «-SourcePath » auch auf Systemen verteilen, die nicht mit dem Internet verbunden sind. Es ist auch möglich, den Aufruf von «Update-Help» in das PowerShell-Profil einzubinden, um so immer auf dem aktuellen Stand zu sein. Standardmässig führt die Shell diesen Befehl nur einmal täglich aus, der Parameter «-Force» hebt diese Beschränkung auf. Nächste Seite: Serververwaltung per Script Besondere Aufmerksamkeit bei diesem Release verdienen die Möglichkeiten der Desired State Configuration (DSC). Mit dem neuen Managementsystem können Administratoren deklarative Scripts erstellen, in denen beschrieben wird, wie zum Beispiel ein Windows- oder auch ein Web-Server konfiguriert sein soll. Dabei ist in diesem Zusammenhang der Begriff «Script» eher irreführend: Der Systemverwalter erstellt mithilfe des neuen Schlüsselworts «Configuration» eine Art Funktion, die eine gewisse Ähnlichkeit mit .ini-Dateien unter Windows hat. In ihr stehen Blöcke (als «Nodes» bezeichnet) zur Verfügung, mit denen dann unter anderem lokale Nutzer und Nutzergruppen, Verzeichnisse, Registry-Schlüssel, Dateien und gerade bei Serversystemen auch Rollen und Features aktiviert beziehungsweise deaktiviert werden können. Eine solche Deklaration wird wie eine PowerShell-Funktion erstellt. Im folgenden Listing ist eine stark vereinfachte Version einer solchen Konfiguration zu sehen. Diese können Systemverwalter dann aufrufen und damit das «Configuration Instance Document» als MOF-Datei (Management Object File) erstellen. Das geschieht im Beispiel mit dem folgenden Aufruf:

! KASTEN !

Den Befehl wir schon mit in diese Script-Datei hineingeschrieben haben: Der «Configuration»-Block wird dabei wie eine PowerShell-Funktion abgearbeitet. Mithilfe des neuen Cmdlets «StartDscConfiguration» werden dann diese Einstellungen auf das entsprechende System angewendet:

! KASTEN !

Das geschieht mit dem Pfad, in dem Sie zuvor die MOF-Datei abgelegt haben. Auch die Zuweisung dieser Einstellungen an ein anderes System ist möglich:

! KASTEN !

Der Aufruf dieses Cmdlets gibt ein PowerShell Job-Objekt zurück, was gerade bei länger währenden Konfigurationsaufgaben sehr nützlich sein kann. Soll die Konfiguration interaktiv ablaufen, so kann dazu der Parameter «-wait» verwendet werden:

! KASTEN !

Die Möglichkeiten, mithilfe der Desired State Configuration die Serversysteme auf den vorgesehenen Stand zu bringen und auch zu halten, sind sehr vielfältig und können hier nur angerissen werden. Laden Sie bei der Installation des WMF die «Desired State Configuration Quick Reference» mit herunter. Diese nützlichen Informationen können Sie auch einzeln herunterladen, wenn Sie bereits mit Windows 8.1 oder Windows Server 2012 R2 arbeiten. Hier wird ein sehr vereinfachtes Beispiel gezeigt, das den grundsätzlichen Aufbau der «Configuration» demonstriert, mit deren Hilfe dann die entsprechende MOF-Datei erstellt wird:

! KASTEN !

Nächste Seite: PipelineVariable spart Arbeit Zu den kleineren Verbesserungen, die sich aber bei der täglichen Arbeit mit der PowerShell schnell als nützlich erweisen können, zählt die Möglichkeit, mittels des allgemein verfügbaren Parameters «-PipelineVariable» Objekte innerhalb einer Pipeline zwischen zu speichern. Dies kann dann nützlich sein, wenn der Anwender beispielsweise auf ein Objekt zugreifen möchte, das sich bei der Abarbeitung einer Pipe am Ende nicht mehr im Zugriff befindet. Bei dem folgenden Aufruf:

! KASTEN !

werden Dateiobjekte, die vom Cmdlet «Get-Childitem» weitergegeben werden, während der Abarbeitung in der Pipe durch die Matchinfo-Objekte von Select-String ersetzt – was grundsätzlich richtig ist, denn das soll ja am Ende der Bearbeitung herauskommen. Soll nun aber in einem derartigen Aufruf auf das FileInfo-Objekt von «Get-Childitem» zugegriffen werden, so mussten die Anwender bisher eine Zwischenvariable anlegen und diese mithilfe einer Schleife abarbeiten, um darauf zugreifen zu können. Durch den neuen Parameter «-PipelineVariable» ist das nun nicht mehr nötig: Diese Objekte werden in der mitgegebenen Variablen zwischengespeichert und stehen damit auch am Ende der Pipeline noch zur Verfügung. Das folgende Beispiel des Entwicklers Keith Hill, das wir ein wenig abgewandelt haben, zeigt das sehr schön:

! KASTEN !

Dieser Aufruf gibt die Dateien, in denen der String «micha» gefunden wurde, in der Form Verzeichnisname\Dateiname auf dem Bildschirm ohne den führenden Pfad aus. Der Zugriff auf die Eigenschaft «Directory.Basename» wäre aber am Ende der Pipeline ohne die Zwischenvariable nicht möglich, da das Fileinfo-Objekt nach Aufruf von «Select-String» nicht mehr zur Verfügung steht.

Wenn die Suche nach einer bestimmten PowerShell-Funktion im Internet eine ganze Reihe unterschiedlicher Lösungen für genau dieses Problem präsentiert, ist es ziemlich sicher, dass ein entsprechender Bedarf bei den Anwendern besteht. So ist es auch mit «Get-FileHash», und Microsoft liefert diese Funktionalität nun mit der PowerShell 4.0 als Cmdlet mit. Der Aufruf:

! KASTEN !

berechnet den Hashwert für die ausführbare PowerShell-Datei und zeigt ihn in formatierter Form an. Durch den Parameter «-Algorithm» kann der Anwender zudem angeben, mit welcher kryptografischen Hash-Funktion er den Inhalt der übergebenen Datei berechnet haben möchte. Dabei stehen SHA1, SHA256, SHA384, SHA512, MACTripleDES, MD5 und RIPEMD160 zur Verfügung, wobei die Entwickler in der Dokumentation darauf hinweisen, dass sowohl MD5 als auch SHA1 nicht mehr als sicher betrachtet werden. Gibt der Nutzer keinen Algorithmus an, so verwendet das Cmdlet automatisch SHA256. Das Cmdlet gibt nach dem Aufruf ein Objekt zurück, das den Pfad zu der geprüften Datei, den berechneten Hash-Wert und den zur Berechnung verwendeten Hash beinhaltet. Interessant ist dabei noch der Parameter «-LiteralPath», der im Gegensatz zum bekannten «-Path»-Parameter einen übergebenen Pfad genauso annimmt, wie er eingegeben wird, ohne dabei Wildcard-Zeichen zu interpretieren. Befinden sich im Pfad Escape-Zeichen, werden sie bei Verwendung dieses Parameters ignoriert, wenn der Pfad in einfachen Hochkommas eingeschlossen wird. Nächste Seite: Windows Defender im Griff Für die in Windows 8.1 enthaltende Sicherheitslösung Windows Defender stehen mit dem aktuellen PowerShell-Release durch das Windows Defender Modul ebenfalls neue Cmdlets zur Verfügung. Die PowerShell 4.0 stellt diese Cmdlets damit auch auf dem Windows Server 2012 R2 zur Verfügung, allerdings sollten Administratoren dabei bedenken, dass Windows Defender nur im Core-Modus des Servers automatisch mit installiert wird. Unter Windows Server 2012 oder 2012 R2 mit der vollen Windows-Oberfläche wird er nicht installiert. Ist der Windows Defender nicht auf dem System installiert oder deaktiviert, weil eine andere Antivirus-Lösung diese Aufgaben übernimmt, so bricht die PowerShell mit der wenig aussagekräftigen Meldung «Die extrinsische Methode konnte nicht ausgeführt werden» ab. Wer sich zunächst einmal einen Überblick über die vorhandenen Cmdlets für die Arbeit mit dem Windows Defender verschaffen möchte, kann das leicht mit dem folgenden Kommando tun:

! KASTEN !

Elf Befehle werden angezeigt, wobei der einfachste Aufruf nach dem aktuellen Status der Maschine folgendermassen aussieht:

Get-MpComputerStatus

Ein Aufruf, der eine umfangreiche Liste von Informationen auf dem Bildschirm präsentiert. Übersichtlicher wird es da, wenn der Nutzer das Ergebnis entsprechend filtert, zum Beispiel nach den Versionen der Signaturen und nach dem Datum der letzten Updates:

Get-MpComputerStatus | select *version, *updated

Stellt der Anwender dabei fest, dass die Signaturen nicht mehr auf dem aktuellen Stand sind, so ist auch deren Update direkt mittels eines PowerShell-Kommandos möglich:

Update-MpSignature

Schliesslich kann auch der Scan mittels eines Kommandos aufgerufen werden. Hier kann der Nutzer mittels des Parameters «-ScanType» zwischen «FullScan», «CustomScan» oder «QuickScan» wählen:

Start-MpScan -ScanType quick