Neu für Windows-Administratoren - das Windows Management Framework

Die PowerShell ist eine auf dem .NET Framework 2.0 basierende Shell, die aus einer objektorientierten Pipeline, einer modernen Skriptsprache, einem erweiterbaren Typensystem und einen Satz von Cmdlets (,,Commandlets") besteht. Die Version 1.0 wurde im Herbst 2006 offiziell freigegeben, 3 Jahre später liegt mit der Version 2.0 ein Nachfolger vor. Die drei wichtigsten Neuerungen sind:1. Die Möglichkeit, beliebige Befehle und Skripte auch auf einem Computer im Netzwerk ausführen zu können (entweder im Rahmen einer Remote-Session oder, in dem der Name des Computers angegeben wird).2. Die Möglichkeit, beliebige Befehle und Skripte als Hintergrundprozesse (Job) auszuführen zu können (lokal wie remote). 3. Ein kleiner GUI-Editor mit dem Namen PowerShell ISE (als WPF-Anwendung), die auch einen Script-Debugger enthält. Darüber hinaus gibt es über 100 neue Cmdlets, viele erweiterte Cmdlets und manches, was es auf Zeitgründen nicht in die Version 1.0 geschafft hatte. Während die PowerShell 2.0 bei Windows 7 und Windows Server 2008 R2 von Anfang an dabei ist (bei Server Core muss sie nachträglich als Feature hinzugefügt werden), steht sie für XP, Vista, Windows Server 2003 und Windows Server 2008 unter dem Namen ,,Windows Management Framework" als Download zur Verfügung[1].Neu: Das Windows Management Framework Während die PowerShell 1.0 nur die ,,neue Shell von Microsoft" war, ist die PowerShell inzwischen von strategischer Bedeutung. Alle Server-Produkte sollen mit den nächsten Versionen mit der PowerShell ausgestattet werden (bei Exchange Server 2007 ist sie in Gestalt der Exchange Verwaltungsshell bereits dabei, bei SharePoint Server 2010 wird sie ebenfalls die zentrale Adminschnittstelle darstellen). Da Remoting bei der PowerShell 2.0 das entscheidende Feature für die Server-Administration ist, wird PowerShell 2.0 mit WinRM 2.0 und BITS 4.0 unter dem Namen ,,Windows Management Framework" zusammengefasst. Abbildung 1: Die PowerShell ISE ist ein integrierter Editor/Debugger auf der Basis der WPF Endlich RemotingEin großes Manko der Version 1.0 war die fehlende Remoting-Fähigkeit. Skripte konnten nur lokal ausgeführt werden. Mit Version 2.0 ist das Vergangenheit. Allerdings hat sich Microsoft aus verschiedenen Gründen nicht für SSH entschieden, sondern für den Webservice-Standard WsMan. WsMan ist auch die Grundlage für Windows Remote Management, das bereits mit Windows Server 2003 eingeführt wurde, und das, vollkommen unabhängig von der PowerShell, eine auf Cmd.exe basierende Remote-Shell bietet.Remoting im praktischen Einsatz könnte einfacher nicht ein. Entweder wird über Invoke-Command der Name des Computers als weiterer Parameter angegeben oder es wird über New-PSSession eine Remote-Session gestartet, in der alle Befehle auf dem Remote-Computer ausgeführt werden. EinInvoke-Command -ScriptBlock Get-Service | Where-Object { $_.Status -ne "Running" } -Computer Server1, Server2, Server3listet alle nicht laufenden Dienste auf den angegebenen Servern auf. Falls eine Anmeldung erforderlich ist, geschieht dies über den Credential-Parameter. Die Alternative besteht darin, über New-PSSession eine Session auf dem Remote-Computer zu starten: Enter-PSSession -Computer Server1 Steht die Session ändert sich der Eingabeprompt entsprechend und jeder Befehl wird auf diesem Computer ausgeführt. Es ist wichtig zu verstehen, dass ein Remote-Befehl keinen Text zurück, sondern Objekte, die auf dem Client weiterverarbeitet werden können.Das Remoting muss auf dem Server einmalig aktiviert werden. Entweder (bei Windows Server 2008 R2) im Server-Manager oder über das Cmdlet EnablePS-Remoting. Auf dem Client sind keine Vorbereitungen erforderlich mit einer Ausnahme. Ist der Server nicht Teil der Domäne, muss sein Name auf dem Client zur Liste der ,,Trusted Hosts" hinzugefügt werden, was sich im Rahmen der PowerShell sehr einfach durchführen lässt, in dem per cd wsman:ocalhost\client auf die Client-Konfiguration umgeschaltet und per Set-Item der Name des Hosts an den Wert des TrustedHosts-Element angehängt wird. PowerShell soll IT-Kosten senkenWährend die Rolle der Version 1.0 in erster Linie die einer modernen, auf dem .NET Framework basierenden Shell war, mit der sich Skripte erstellen und typische ad hoc-Abfragen durchführen lassen, soll die Version 2.0 ganz konkret dazu beitragen, dass IT-Abteilungen Abläufe optimieren können und damit Zeit und Geld sparen. Die Grundlage dafür sind zahlreiche PowerShell-Module, die bei Windows 7 und Windows Server 2008 R2 von Anfang an dabei sind, gegebenenfalls aber erst einmal dazu geladen werden müssen. Ein Modul umfasst bei der PowerShell Funktionen und Cmdlets und ist bevorzugte Art und Weise wie die PowerShell um neue Funktionalitäten erweitert wird.Einer Windows 7-Module ist das ,,TroubleShooting Pack", das mit Windows 7 eingeführten ,,Problembehandlungsroutinen" (die selber auf PowerShell-Skripten basieren) zugänglich macht. EinGet-TroubleShootingPack -Path C:\Windows\Diagnostics\System\Printer | Invoke-TroubleShootingPack startet z.B. die Problembehandlung für den Drucker, was auch Remote durchgeführt werden kann, und Administratoren dabei behilflich sein kann, Problemen schneller auf die Spur zu kommenEin weiteres wichtiges Modul, das Teil von Windows Server 2008 R2 ist, ist das ServerManager-Modul, das den mit dieser Version eingeführten Best Practices Analyzer (BPA) umfasst. Damit können Administratoren mit minimalem Aufwand Weise feststellen, ob ein System richtig konfiguriert ist. Zuerst wird per Import-Module BestPracticesdas entsprechende Modul importiert. Anschließend überprüftInvoke-BPAModel Microsoft/Windows/DirectoryServicesdie ActiveDirectory-Konfiguration auf dem lokalen Computer, in dem ein BPA-Scan durchgeführt wird. Möglichkeiten für EntwicklerDie PowerShell hat als .NET-Anwendung auch für Entwickler einiges zu bieten. Auch wenn bei der PowerShell 2.0 in erster Linie die auf PowerShell-Skripten basierenden Funktionen im Mittepunkt stehen, spielen in C# (oder VB.NET) entwickelte Cmdlets nach wie vor eine wichtige Rolle, um anwendungsspezifische Funktionalitäten zur Verfügung zu stellen. Über selbstentwickelte Provider lassen sich beliebige ,,Ablagen" ansprechen, die Computermanagementkonsole kann um Snapins erweitert werden, die auf PowerShell-Cmdlets basieren, werden und die PowerShell-Assemblies lassen sich mit relativ wenig Aufwand in eine Windows- oder Web-Anwendung einbauen, so dass auch dort die PowerShell-Funktionalität zur Verfügung steht.Mit der Version 2.0 macht die PowerShell als Teil des neuen Windows Management Frameworks einen großen Sprung, sowohl funktional als auch in seiner neuen Rolle als strategisches IT-Tool. War die Version 1.0 in erster Linie eine Skript- und Abfrageshell, stellt die aktuelle Version mit ihren Modulen, die allerdings nur unter Windows Server 2008 R2 in vollem Umfang zur Verfügung stehen, konkrete Hilfestellungen für Administratoren zur Verfügung, mit denen sich der Aufwand für Routineaufgaben deutlich reduziert.Links[1] http://support.microsoft.com/kb/968929 Peter Monadiemi