Windows PowerShellEine Vorschau auf die Remoteverwaltung in Version 2.0

Don Jones

Dieser Artikel basiert auf einer Vorabversion von Windows PowerShell. Änderungen an den in diesem Artikel enthaltenen Informationen sind vorbehalten.

Inhalt

Zwei Arten von Remoting
Synchron oder asynchron
Wiederverwendbare Runspaces
Fan-In-Remoting
Das Prunkstück in 2.0

Hatten Sie schon Gelegenheit, mit der aktuellen Community Technology Preview (CTP) von Windows PowerShell 2.0 zu experimentieren? Die aktuelle Version CTP2 bietet weiterentwickelte Remoteverwaltung, und jetzt ist genau der richtige Zeitpunkt, um sich mit ihren neuen Funktionen vertraut zu machen. Bevor ich anfange, sollten Sie sich etwas Zeit nehmen, um

CTP2 unter go.microsoft.com/fwlink/?LinkID=119707 herunterzuladen.

Lassen Sie mich zuerst einige wichtige Punkte erklären. Bei einer CTP-Version handelt es sich um Vor-Betacode, den Microsoft bereitstellt, um ungeduldigen Benutzern wie mir eine Vorstellung davon zu geben, wie weit Microsoft mit der nächsten Version einer Anwendung schon ist. Jeder CTP-Meilenstein oder -Drop (wie es in der Branche genannt wird) kann sich vollständig von früheren Drops unterscheiden. Das liegt daran, dass das Entwicklungsteam Rückmeldungen sammelt, sie sorgfältig prüft und dann auf der Grundlage dieses Benutzerfeedbacks Änderungen an der Anwendung vornimmt. Diese Methodik bringt für Ihre Verwendung der CTP-Version einen erheblichen Vorteil sowie auch einen erheblichen Nachteil.

Der Vorteil besteht darin, dass, wenn Sie die CTP-Version verwenden, Sie (über die Website connect.microsoft.com) noch während der Entwicklung Feedback zum Produkt geben können, also dann, wenn das Team noch auf dieses Feedback reagieren kann! Wenn Sie bis zur Phase der Betaversion oder, schlimmer noch, bis zur Phase des Release Candidate warten, lässt sich Ihr Feedback nur sehr viel schwieriger berücksichtigen. Während der CTP-Phase ist alles möglich, und das Team kann bei Bedarf noch umfangreiche und radikale Änderungen vornehmen.

Damit komme ich zum Nachteil. Die CTP-Version ist nicht für den Produktionsbetrieb geeignet. Zwar ist Windows PowerShell™ 2.0 CTP2 möglicherweise einer der stabilsten Vorabcodes, den Sie gesehen haben, aber bedenken Sie, dass der nächste CTP-Drop eine vollständig andere Anwendung sein kann. Fangen Sie also nicht an, sich auf CTP2 zu verlassen, denn die nächste Version zwingt Sie möglicherweise, ganz von vorn zu beginnen.

Beachten Sie, dass die CTP-Version nicht parallel mit Windows PowerShell 1.0 installiert werden kann. Für eine ideale Einrichtung sollte auf dem System auch das Microsoft® .NET Framework 3.5 installiert sein, um den vollen Featureumfang nutzen zu können. Andernfalls sind einige Features begrenzt.

Da die CTP-Version ein sehr früher Code ist, hat Microsoft außerdem bisher den größten Wert darauf gelegt, dass die Anwendung unter den aktuellen Betriebssystemen läuft, also unter Windows Vista® und Windows Server® 2008. Eine Kompatibilität mit aktuellen Betriebssystemen ist kein Hinweis auf die Betriebssystemkompatibilität, die Sie für den endgültig veröffentlichten Code erwarten können. Der Rückportierung wird erst später im Entwicklungszyklus Aufmerksamkeit gewidmet.

Zwei Arten von Remoting

Im Bereich der Remoteverwaltung findet man meist zwei Arten von Remoting: Fan-In und Fan-Out. Fan-In-Remoting umfasst mehrere Administratoren, die Secure Shell-Verbindungen zu einem einzigen Server herstellen. Windows PowerShell ist so ausgelegt, dass es dies in einer sicheren, partitionierten Weise ermöglicht, sodass z. B. ein Unternehmen, das Exchange Server bereitstellt, seinen Kunden Administratorzugriff auf ihre Bereiche eines Servers bieten kann. Mit Fan-In-Remoting erhalten Sie von einem Remotestandort aus sicheren interaktiven Zugriff auf die Kopie von Windows PowerShell (nur Version 2.0!), die auf einem Remoteserver installiert ist.

Fan-Out-Remoting findet statt, wenn Sie einen Satz von Befehlen an eine ganze Gruppe von Remoteservern gleichzeitig ausgeben. Die Befehle werden sich gleichzeitig von Ihrer Arbeitsstation „fächerauswärts“ zur Servergruppe gesendet. Die Befehle werden auf jedem Server ausgeführt, und die Ergebnisse werden in Form von Windows PowerShell-Objekten an Ihre Arbeitsstation zurückgegeben, sodass Sie sie überprüfen und mit ihnen arbeiten können. Windows PowerShell unterstützt zwei Kerntechnologien für Fan-Out-Remoting: Windows®-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) und Windows Remote Management (WinRM), das zuerst mit Windows Server 2008 ausgeliefert und dann in der Windows PowerShell 2.0 CTP-Version aktualisiert wurde.

Synchron oder asynchron

Eigentlich hatte sogar Windows PowerShell 1.0 ein paar grundlegende Fan-Out-Funktionen, die an WMI gebunden waren. So konnte man beispielsweise problemlos ein Array von Computernamen erstellen und dann von jedem eine WMI-Klasse abrufen:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem 
    –computer $names

Das Ausführen von Methoden, wie z. B. der Neustart eines Computers, erforderte einen etwas höheren Arbeitsaufwand, da Version 1.0 kein Verfahren bot, WMI-Methoden bündelweise auszuführen. Dies hat sich jedoch in Version 2.0 CTP dank des Cmdlets „Invoke-WmiMethod“ geändert:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot

Allerdings gibt es ein Problem mit diesem Verfahren. Es ist synchron, was bedeutet, dass jeder Computer einzeln angesprochen wird und Sie bei jedem warten müssen, bis er fertig ist, bevor Sie andere Befehle ausführen können. Die CTP-Version führt aber ein neues Konzept ein – die Hintergrundaufträge –, mit denen sich Befehle wie dieser im Hintergrund ausführen lassen. Im einfachsten Fall können Sie durch bloßes Hinzufügen des Parameters „–AsJob“ einen WMI-Befehl im Hintergrund ausführen:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob

Sie können den Status des entstehenden Auftrags durch Ausführen von Get-PSJob überprüfen und das Endergebnis des Auftrags durch Ausführen von Receive-PSJob anzeigen. (In einem künftigen Artikel werde ich mich eingehender mit den Einzelheiten der Auftragverwaltung beschäftigen.) Das Cmdlet „Invoke-Command“ bietet jedoch eine noch bessere Möglichkeit, Befehle im Hintergrund auszuführen, und zwar so:

$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob

Dieses sendet nämlich mit der Push-Methode den Befehl „Get-WmiObject“ an jeden angegebenen Computer und führt ihn dann lokal aus. Er wird in der Regel viel schneller ausgeführt, und ohne von den WMI-RPC-Verbindungen (remote procedure call, Remoteprozeduraufruf) abhängig zu sein. Stattdessen setzt Invoke-Command WinRM ein, das standardmäßig Port 80 oder 443 verwendet. Diese Ports machen es einfach, Firewalls zu passieren, und sind vollständig konfigurierbar. Invoke-Command unterstützt auch zusätzliche Parameter für alternative Anmeldeinformationen und Einschränkung, was Ihnen ermöglicht, auf Hunderte von Computern abzuzielen, von denen aber nur einige wenige parallel laufen. So können Sie Überlastung und übermäßigen Aufwand vermeiden.

Wiederverwendbare Runspaces

Wenn Sie vorhaben, eine bestimmte Gruppe von Computern mehr als einmal von einem Remotestandort aus zu verwalten, sollten Sie in Erwägung ziehen, Runspaces anstelle einfacher Listen von Computernamen zu verwenden. In Windows PowerShell ist ein Runspace einfach eine Instanz des Shell-Moduls, unabhängig davon, ob es lokal auf Ihrem Computer als Shell-Konsolenfenster oder im Hintergrund auf einem Remotecomputer ausgeführt wird. Ein Remoterunspace ist leicht zu starten:

$names = @("server1","server2","server2")
New-RunSpace –computer $names

Da Runspaces auch WinRM verwenden, verwenden sie standardmäßig auch Port 80 (oder 443, wenn Sie den –UseSSL-Parameter angeben). Sie können auch alternative Anmeldeinformationen akzeptieren und so weiter. Wenn Sie die entstehenden Runspaceobjekte abrufen, können Sie diese an Invoke-Command übergeben, und Windows PowerShell sendet den Befehl mit der Push-Methode zu den Computern, auf denen diese Runspaces vorhanden sind:

$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob

Der Vorteil besteht dabei darin, dass die Runspaces so lange aktiv bleiben, wie die Shell offen ist, sodass Sie sie für zusätzliche Befehle einfach wiederverwenden können.

Fan-In-Remoting

Runspaces sind auch der Schlüssel zum Fan-In-Remoting. So zeigt z. B. Abbildung 1, dass ich einen Runspace auf einem Remotecomputer erstellt, einen Verweis auf diesen Runspace abgerufen und dann mithilfe des Cmdlets „Push-Runspace“ den Runspace aktiviert habe. Dann führe ich auf dem Remotecomputer Befehle aus, ähnlich wie SSH oder andere Remoteshelldienstprogramme sie ermöglichen würden. Die Ausführung von Pop-Runspace bringt mich zu meinem ursprünglichen „lokalen“ Runspace zurück, und die Eingabeaufforderung der Shell hilft mir zu verfolgen, wo ich mich gerade befinde.

Abbildung 1 Ausführung von Befehlen auf einem Remotecomputer mithilfe von Runspace (zum Vergrößern auf das Bild klicken)

Die genaue Befehlsfolge, die ich ausgeführt habe, lautet folgendermaßen:

PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>

Dieses Verfahren wird „Fan-In“ genannt, weil mehrere Administratoren gleichzeitig auf demselben Server interaktive Remoterunspaces öffnen können: sie laufen sich „fächereinwärts“ von ihren jeweiligen Arbeitsstationen zum Server. Ein neues Sicherheitsmodell in Windows PowerShell 2.0 ermöglicht Ihnen, eingeschränkte Shells und Cmdlets zu erstellen. So kann verhindert werden, dass Administratoren globale Änderungen vornehmen. Jeder Administrator wird auf seinen eigenen Bereich der Shell begrenzt. (Diese neuen Sicherheitsverfahren erfordern eine benutzerdefinierte Softwareentwicklung in einer an .NET Framework angepassten Sprache. Dieses Thema geht über den Rahmen der Rubrik zu Windows PowerShell hinaus, aber es ist nützlich zu wissen, dass es diese Funktionen gibt.)

Das Prunkstück in 2.0

Die Windows PowerShell 2.0 CTP-Version bietet eine beeindruckende Liste neuer Features. Meiner Meinung nach ist Remoting das Prunkstück. Jeder Administrator in beinahe jeder Umgebung kann sie nutzen.

Sie sollten sich mit diesen Features vertraut machen, damit Sie dem Produktteam Ihre Vorschläge unterbreiten können. Möchten Sie, dass WinRM-Standardports über die Gruppenrichtlinie verwaltet werden? Sollen die Cmdlets anders funktionieren? Gibt es Leistungsprobleme? Ist WinRM genügend einfach zu konfigurieren? Sie können die weitere Entwicklung beeinflussen, indem Sie Vorschläge an connect.microsoft.com senden oder Ihr Feedback mit Empfängern der MVP-Auszeichnung einschließlich meiner Person teilen (um mich zu erreichen, senden Sie Ihr Feedback an die Foren unter ScriptingAnswers.com). Beteiligen Sie sich, und helfen Sie, das Prunkstück für die nächste Generation von Windows PowerShell zu erstellen!

Cmdlet des Monats: Select-Object

Probieren Sie dies aus: Get-Service | ConvertTo-HTML | Out-File Services.htm. Sehen Sie sich jetzt die resultierende HTML-Datei in Ihrem Webbrowser an. Sie enthält ziemlich viele Informationen, nicht wahr? Wenn es nur eine Möglichkeit gäbe, sie ein wenig zurechtzustutzen und nur die für Sie interessanten Informationen auszuwählen. Genau das kann Select-Object für Sie tun. Sagen wir z. B., dass Sie nur eine Liste von Dienstnamen mit deren aktuellen Status haben möchten. Dann können Sie Folgendes verwenden: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.

Sie müssen dabei allerdings beachten, dass Select-Object das ursprüngliche Objekt – in diesem Fall Dienste – verwirft und ein benutzerdefiniertes Objekt erstellt (buchstäblich einen PSCustom-Objekttyp), der nur die Eigenschaften enthält, die Sie angegeben haben. Manche Funktionen des ursprünglichen Objekts sind nicht mehr zugänglich. Deshalb werden Sie Select-Object wahrscheinlich möglichst spät verwenden und so lange wie möglich mit dem ursprünglichen Objekt arbeiten wollen.

Don Jones ist Mitautor von „Windows PowerShell v2.0: TFM“ und der Schulungsleiter hinter den „Special Forces“-Seminaren unter ScriptingAnswers.com (scriptinganswers.com/training.asp). Er ist unter jeepdon@mac.com zu erreichen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.