Wer die verschiedenen Versionen der PowerShell und ihre unterschiedlichen Features in den letzten Jahren verfolgt hat, konnte eine stetige Entwicklung von einer einfachen Batch- und Scripting-Sprache hin zu einem vollwertigen Werkzeug zur Administration und Automatisierung der Windows-Systeme verfolgen. Das wird zudem dadurch bestätigt, dass es Microsoft den Administratoren ermöglicht, eine immer größere Anzahl von Systemverwaltungsaufgaben sowohl auf den Windows- als auch auf Anwendungs-Servern wie Exchange mit Hilfe der PowerShell zu erledigen und vor allen Dingen auch zu automatisieren.
Foto: Sergey Nivens, Fotolia.com
PowerShell 4.0 als Teil des WMF 4.0: Nicht auf allen Systemen installierbar
Die aktuelle Version 4.0 der PowerShell steht Anwendern und Administratoren standardmäßig auf den Systemen unter Windows 8.1 und auf dem Windows Server 2012 R2 sofort nach der Installation der Betriebssysteme zur Verfügung. Insgesamt ist die PowerShell Teil des Pakets Windows Management Framework 4.0 (WMF), das neben der Shell auch neue Versionen von WinRM (Windows Remote Management), WMI (Windows Management Instrumentation) und der integrierten Entwicklungsumgebung ISE (Integrated Scripting Environment) beinhaltet.
Für ältere Windows-Versionen steht das Windows Management Framework zum Download bereit. Es kann auf Systemen unter Windows 7 mit Service Pack 1 (in der 32- und 64-Bit-Version) und auf den Server-Systemen Windows Server 2008 R2 mit Service Pack 1 und Windows Server 2012 installiert werden. Auf dem System muss zudem das .NET Framework 4.5 installiert sein.
Es ist nicht möglich, dieses Systemupdate auf einem Rechner unter Windows 8 zu installieren! Microsoft bezeichnet die PowerShell 4.0 und das WMF als integralen Bestandteil von Windows 8.1, der bei Windows-8-Systemen nur durch das (kostenloses) Update auf Windows 8.1 installiert werden kann. Für Systeme, auf denen einige bestimmte Server-Anwendungen ausgeführt werden, rät Microsoft von einer Installation des WMF 4.0 ab. Das gehören neben dem System Center 2012 Configuration Manager (ohne SP1) auch der System Center Virtual Machine Manager (SCCM) 2008 R2 (mit SP1), der Exchange Server in der Version 2007 und schließlich auch die Version 2011 des Windows Small Business Server. Für den Einsatz auf Server-Systemen, auf denen der Exchange- oder SharePoint-Server in der Version 2010 oder 2013 ausgeführt werden, sind bestimmte Kombinationen von Service Packs und UpdateRollup Voraussetzung, um diese Version der PowerShell problemlos verwenden zu können.
Auch wenn der Wechsel der Versionsnummer von "3" auf "4" ein großes Release erwarten lässt, sind die Auswirkungen nicht so umfassend, wie es beim Wechsel von der PowerShell 2.0 der Fall war. Zu den Neuerungen zählen unter anderem:
• die Unterstützung für Workflow- und RemoteDebugging von Scripts,
• verbesserte Funktionen für das Workflowauthoring, die laut Microsoft auch zur Vereinheitlichung mit dem Script-Authoring dienen,
• als allgemeiner Parameter steht nun "-PipelineVariable" zur Verfügung,
• es gibt eine verbesserte Unterstützung zum Herunterladen aktualisierbarer Hilfe unter Verwendung von "Save-Help" und "Update-Help", die auch 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.
Hilfedateien sind nun da - wenn sie nachgeladen werden
Wer die PowerShell in der Version 3.0 auf seinem System installiert hatte, kennt vielleicht noch das Problem, das sich bei dem Versuch ergab, die integrierten Hilfedateien zu verwenden: Hatte Microsoft mit der Version 2.0 noch vollständige sogar lokalisierte Hilfedateien automatisch mit auf dem System installiert, so waren ein Großteil dieser Dateien ab Version 3 nachträglich zu installieren.
Microsoft will so auch sicherstellen, dass diese Daten immer aktuell sind. Allerdings gibt es seit dieser Version auch keine lokalisierten Hilfedateien mehr, die Nutzer müssen mit den englischen Texten vorlieb nehmen.
So erscheinen dann auch bei den ersten Versuchen mit dem Cmdlet "Get-Help" keine ausführlichen Hilfetexten. Allerdings funktioniert im Gegensatz zur vorherigen Version der PowerShell nun auch das Nachlader der englischsprachigen Texte auf Systemen in deutscher Sprache. Dazu müssen Sie in einer PowerShell-Konsole mit Administratorrechten den Befehl:
Update-Help
aufrufen. Ohne zusätzliche Parameter überprüft dieses Cmdlet die Versionen der Hilfedateien auf dem System und lädt die aktuellsten Dateien aus dem Netz herunter. Für den Offline-Einsatz ist mit der PowerShell 4.0 nun auch möglich, mit Hilfe des Cmdlets "Save-Help", diese Dateien aus dem Internet herunterzuladen und im Dateisystem abzulegen. Danach können Administratoren diese Dateien mittels "Update-Help" und dem Parameter "-SourcePath <Pfadname>" auch auf Systemen verteilen, die nicht mit dem Internet verbunden.
Es ist auch möglich, den Aufruf von "Update-Help" in das PowerShell-Profile einzubinden, um so immer auf dem aktuellen Stand zu bleiben. Standardmäßig führt die Shell diesen Befehl nur einmal täglich aus, der Parameter "-Force" hebt diese Beschränkung auf.
Desired State Configuration (DSC): Hilfe für die Server-Verwaltung/Konfiguration
Neben einer ganzen Reihe kleiner Verbesserungen und Neuerungen sind es die Möglichkeiten der Desired State Configuration (DSC), die bei diesem Release besondere Aufmerksamkeit verdienen. Mit dem neuen Managementsystem DSC können Systemverwalter und 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" nicht wirklich zutreffend: Der Systemverwalter erstellt mit Hilfe des neuen Schlüsselworts "Configuration" eine Art Funktion, die gewisse Ähnlichkeit mit den bekannten .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 Server-Systemen auch Rollen und Features aktiviert beziehungsweise deaktiviert werden können. Eine solche Deklaration wird wie eine PowerShell-Funktion erstellt. Im Listing 1 ist eine stark vereinfachte Version einer solchen Konfiguration zu sehen. Diese können Systemverwalter dann aufgerufen und damit das sogenannte "Configuration Instance Document" als MOF-Datei (Management Object File) erstellen. Dies geschieht in unserem Beispiel mit dem folgenden Aufruf:
MeineTestConfig -ComputerName $env:COMPUTERNAME -OutputPath "d:\Scripts\Konfiguration"
den wir schon mit in diese Script-Datei hineingeschrieben haben: Der "Configuration"-Block wird dabei wie eine PowerShell-Funktion abgearbeitet. Mit Hilfe des neuen Cmdlets "StartDscConfiguration" werden dann diese Einstellungen auf das entsprechende System angewendet:
StartDscConfiguration -Path "d:\Scripts\Konfiguration"
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:
StartDscConfiguration -Computername "Server2" -Path "d:\Scripts\Konfiguration"
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:
StartDscConfiguration -verbose -wait -Path "d:\Scripts\Konfiguration"
Die Möglichkeiten mit Hilfe der Desired State Configuration Server-Systeme auf dem vorgesehen Stand zu bringen und auch zu halten, sind sehr vielfältig und können hier nur angerissen werden. Laden Sie auch jedem Fall bei der Installation des WMF die "Desired State Configuration Quick Reference" mit herunter, die als PDF- und als PowerPoint-Datei zur Verfügung steht. Diese nützlichen Informationen können Sie auch einzeln herunterladen, wenn Sie bereits mit Windows 8.1 oder dem 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:
Configuration MeineTestConfig
{
#Optionale Parameter
param ($ComputerName)
#Es können einer oder mehrere Node-Blöcke folgen
Node $ComputerName
{
# Es folgen die verschiedenen Ressource-Blöcke
# Mit Hilfe von WindowsFeature kann untersucht und sichergestellt werden,
# dass beispielsweise bestimmte Rollen wie hier der IIS installiert sind
WindowsFeature IIS
{
Ensure = "Present" # Steht hier "Absent" so wird die Rolle deinstalliert
Name = "Web-Server"
}
Registry RegistryBeispiel
{
Ensure = "Present" # Auch hier kann "Absent" verwendet werden
Key = "HKEY_LOCAL_MACHINE\SOFTWARE\BeispielKey"
ValueName= "TestWert"
ValueData= "TestDatum"
}
}
}
MeineTestConfig -ComputerName $env:COMPUTERNAME -OutputPath "d:\Scripts\Konfiguration"
# Der Parameter -OutputPath ist optional. Der Aufruf erstellt dort eine MOF-Datei (Management
# Object File), die als "Configuration Instance Document" bezeichnet wird.
Speicherung von Pipeline-Objekten
Zu den eher kleineren Verbesserungen, die sich aber bei der täglichen Arbeit mit der PowerShell schnell als nützlich erweisen können, zählt ohne Zweifel die Möglichkeit, mittels des allgemein verfügbaren Parameters "-PipelineVariable" Objekte innerhalb einer Pipeline zwischenzuspeichern. Dies kann dann nützlich sein, wenn der Nutzer beispielsweise auf ein Objekt zugreifen möchte, dass sich bei der Abarbeitung einer Pipe am Ende nicht mehr im Zugriff befindet. Bei dem folgenden Aufruf:
Get-ChildItem *.txt | Select-String <Suchstring> | Get-Member
werden Dateiobjekte, die vom Cmdlet "Get-Childitem" weitergeben werden, während der Abarbeitung in der Pipe durch die Matchinfo-Objekte von Select-String ersetzt -- was grundsätzlich auch richtig ist, denn das soll ja am Ende der Bearbeitung herauskommen.
Soll nun aber beispielsweise in einem derartigen Aufruf auf das FileInfo-Objekt von "Get-Childitem" zugegriffen werden, so mussten die Anwender bisher eine Zwischenvariabel anlegen und diese mit Hilfe 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 Software-Entwicklers Keith Hill, das wir ein wenig abgewandelt haben, zeigt das sehr schön:
Get-Childitem *.txt -PipelineVariable var1 | Select-String micha | Foreach {"$($var1.Directory.Basename)\$($_.Filename)"}
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.
Neu und nützlich: Get-FileHash
Wenn die Suche nach einer bestimmten PowerShell-Funktion im Internet eine ganze Reihe unterschiedlicher Lösungen für genau dieses Problem präsentiert, so ist 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. So berechnet der Aufruf:
Get-Filehash $pshome\powershell.exe | Format-List
den Hashwert für die ausführbare PowerShell-Datei und zeigt ihn in formatierter Form an. Durch den Parameter "-Algorithm <Zeichenkette>" 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 Microsoft-Entwickler in der Dokumentation noch einmal explizit 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, so werden sie bei Verwendung dieses Parameters ignoriert, wenn der Pfad in einfachen Hochkommas eingeschlossen wird.
Windows Defender voll im Griff mit PowerShell 4.0
Für die in Windows 8.1 enthaltende Sicherheitssoftware Windows Defender stehen mit dem aktuellen PowerShell-Release ebenfalls neue Cmdlets durch das Windows Defender Modul zur Verfügung. Die PowerShell 4.0 stellt diese Cmdlets damit natürlich auch auf dem Windows Server 2012 R2 zur Verfügung, allerdings sollten Administratoren dabei bedenken, dass der Windows Defender nur im Core-Modus des Servers automatisch mit installiert wird und entsprechend zur Verfügung steht - auf einem Windows Server 2012 oder 2012 R2 mit der vollen Windows-Oberfläche wird er nicht installiert.
Ist der Windows Defender nicht auf dem entsprechenden System installiert oder nicht aktiv, weil eine andere AV-Lösung diese Aufgaben übernimmt, so bricht die PowerShell leider mit der für den normalen Anwender 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:
Get-Command -module Defender
Elf unterschiedliche Befehle werden dann angezeigt, wobei der einfachste Aufruf nach dem aktuellen Status der Maschine folgendermaßen aussieht:
Get-MpComputerStatus
Ein Aufruf, die eine ziemlich 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
Schließlich kann auch der Scan mittels eines Kommandos aufgerufen werden. Hier kann der Nutzer dann mittels des Parameters "-ScanType" zwischen "FullScan", "CustomScan" oder "QuickScan" unterscheiden:
Start-MpScan -ScanType quick
Mit Hilfe dieser Kommandos ist beispielsweise eine Automatisierung der Windows Defender auf den unterschiedlichen Client-Maschinen recht schnell erstellt. Da alle Kommandos aus dem Defender-Modul auch den Parameter "-CimSession <CimSession[]" verwenden können, ist es für Administratoren beispielsweise möglich, eine CimSession anzulegen, die eine Verbindung zu einer ganzen Liste von Remote-Systeme aufbaut und ihm so die Statusinformation zu den dort installierten Defender-Versionen liefert.
CIM steht dabei für Common Information Modell. Bei einer solchen Session handelt es sich um Client-seitiges Objekt, das eine Verbindung zu einem lokalen oder einem Remote-System aufbaut. In einer solchen Session werden dann Informationen wie Computername oder auch das verwendete Verbindungsprotokoll hinterlegt. Hat ein Administrator ein solches CIM-Objekt mit allen Informationen für den Verbindungsaufbau angelegt, so wird diese Verbindung aber erst dann aufgebaut, wenn ein Cmdlet diese Session verwendet. Sie wird auch automatisch wieder geschlossen, wenn das Cmdlet beendet wird. Diese Verhaltensweise ist im praktischen Einsatz bei der Verwaltung und Betreuung von Remote-Systemen durchaus sinnvoll und unterscheidet die CIM-Sessions von den normalen PowerShell-Sessions. (mje)