PowerShell und Remoting (und ein iPod)– es geht doch (Teil 2)

Mit der kommenden PowerShell 2.0 wird es bekanntlich (endlich) ein echtes Remoting auf der Basis von WS-Management geben (ich habe es mit der CPT V3 noch nicht zum Laufen bekommen, es allerdings auch noch nicht besonders intensiv probiert), doch es gibt Alternativen, insbesondere, wenn man SSH-Fan ist und/oder mit der Version 1.0 vorlieb nehmen muss oder möchte. Eine auf SSH basierende Alternative ist PowerShell Server V2.0 von /n Software. Das kleine Tool ist allerdings keine Freeware, sondern ein kommerzielles Produkt, mit 79 U$S für eine „Hobbyisten“-Lizenz aber noch erschwinglich, wenngleich diese Lizenz im Unternehmenseinsatz nicht allzu viel bringt (die Server-Lizenz ist mit 999 US$ ein wenig kostspieliger – alle Preisangaben natürlich ohne Gewähr – alle Infos gibt es unter http://www.nsoftware.com/order/options.aspx). Zum unverbindlichen Kennenlernen gibt es eine 30-Tage-Trial-Version, die den in diesem Blog-Eintrag beschriebenen „Experimenten“ zugrunde liegt. PowerShell Server V2.0 läuft auf einem Windows-Server, auf dem auch die PowerShell 1.0/2.0 läuft und erlaubt SSH-Sessions von einem beliebigen Gerät.

Mein Fazit vorweg: Es funktioniert anscheinend solide, aber es funktioniert nicht auf Anhieb und die Benutzeroberfläche des kleinen Server-Konfigurationsprogramms ist ein wenig spartanisch. Dafür winkt am Ende die Möglichkeit, den (Exchange) Server in der Firma von Unterwegs mit dem iPhone (oder einem anderen x-beliebigen Gerät) via SSH steuern zu können – und das ist doch schon einmal etwas.

Hier die wichtigsten Punkte in Kurzform:

1) Bei der Installation von PowerShell Server 2.0 in Gestalt der Datei NsoftwarePowerShellServerV2.exe kann man weder etwas einstellen, noch etwas falsch machen (sollte der PC, auf dem das Programm installiert wird, offline sein, kann man den auch für die Trial-Version erforderlichen Lizenzschlüssel in Gestalt einer Reg-Datei von der nSoftware-Webseite laden und nachträglich in die Registry überführen).

2) Die bei der Installation dritte angebotene Option, die dazu führt, dass die nSoftware-Cmdlets durch Hinzufügen eines Eintrags zur Profile-Datei automatisch mit dem Start der PowerShell geladen haben, habe ich deaktiviert, da ich es nicht so gerne habe, wenn mein Startprofil erweitert wird.

3) PowerShell Server bringt ein kleines Snapin mit, dass drei Cmdlets umfasst: New-PowerShellServerRunspace, Remove-PowerShellServerRunspace und Invoke-PowerShellExpression. Damit wird ein beliebiger PowerShell-Befehl im Rahmen einer zuvor angelegten Runspace-Session gestartet. Das Snapin wird über Add-Pssnapin powershellserver hinzufügt.

Über Nsoftware.PowerShellServer.exe wird das kleine und eher schlicht gehaltene Konfigurationsprogramm gestartet, über das wiederum der PowerShellServer Dienst gestartet wird.

Wenngleich keine Änderung erforderlich ist, würde ich hier drei Dinge einstellen:

1) Mit dem beigelegten Test-Zertifikat in Gestalt einer Pfx-Datei kommt man nicht weit, zumal es anscheinend auch auf dem Client in die Zertifikatablage eingefügt werden muss. Ich habe mir (im Rahmen von Visual Studio) ein exportierbares Zertifikat (mit einem kennwortgeschützten privaten Schlüssel, wenngleich dies sicher keine Voraussetzung ist) angelegt und dieses in die Ablage LocalMachine\My (also in die Ablage Eigene Zertifikate des Computers) kopiert. Sowohl auf dem Server als auch auf dem Client. Alternativ tut es zum Anlegen eines Zertifikats auch Makecert.exe aus dem .NET Framework SDK oder ein vergleichbares Tool. Alternativ kann man die Pfx-Datei im Register Pfx Store im Register Server Certificate der Options des Konfigurationsprogramms auch direkt auswählen. In diesem Fall muss das Zertifikat in keine Ablage eingefügt werden. Die Zertifikatverwaltung ist eindeutig ein Schwachpunkt von PowerShell Server, denn wenn sich der Dienst später aufgrund eines unpassenden Zertifikats nicht starten lässt, erfährt man es nur indirekt aus der Log-Datei.

2) Im Register Advanced sollte eingestellt werden, dass eine Protokolldatei angelegt wird. Auch wenn die Einträge nicht allzu ausführlich sind, erfährt man nur so, wenn es nicht klappt (und das dürfte gerade am Anfang häufiger der Fall sein).

3) Im Register Connection ist bei Security Group „Administrators” voreingestellt. Hier habe ich die Administratoren-Gruppe stattdessen ausgewählt.

Und natürlich hatte es erst funktioniert als ich (unter Windows 7 RC1) die Firewall deaktiviert hatte, was natürlich keine Dauerlösung ist.

Über Save Changes müssen alle Änderungen im Konfigurationsprogramm gespeichert werden, bevor der Dienst (erneut) gestartet werden kann. Alle Einstellungen werden in der Registry vermerkt (bei der „verzweifelten“ Suche nach einem Hinweis als es am Anfang überhaupt nicht funktionieren wollte habe ich einen Hinweis auf einen undokumentierten Registry-Eintrag gefunden, der dazu führen soll, dass keine „Impersonalisierung“ stattfindet, was im Zusammenhang mit Exchange Server eine Rolle spielen kann).

Läuft der Dienst, kann ein beliebiger Client per SSH auf die auf dem Server laufende PowerShell zugreifen. Da es naheliegend ist, auch auf dem Client die PowerShell einzusetzen, liefert PowerShell Server drei Cmdlets mit. Ein Aufruf von

$Rs = new-powershellserverrunspace -server <Servername> -cred <Benutzername>

legt einen neuen Remote-Runspace an und weist das Resultat einer Variablen zu. In der Regel muss man nach der Ausführung des Befehls die Annahme des Zertifikats bestätigen (wenn man soweit kommt weiß man, dass die Verbindung funktioniert). Ging auch das gut, steht die Session, was immer ein besonderer Moment ist (theoretisch kann der Server am anderen Ende der Welt stehen).

Ein Befehl wird wie folgt ausgeführt:

Invoke-PowerShellServerExpression -SSHRunspace $Rs -command “ get-process calc „

Grundsätzlich kann auf den Command-Parameter ein beliebiger PowerShell-Befehl oder ein Skript folgen. Beendet wird die Session über

Remove-PowerShellServerRunspace $Rs

Das new-powershellserverrunspace-Cmdlet bietet eine Fülle von Parametern für alle möglichen Formen der Authentifizierung, die in der Hilfedatei zwar beschrieben sind, doch leider ohne Beispiele.

PowerShellPuttySession
(Abbildung: Eine Putty-Sesssion mit der PowerShell)

Auch wenn PowerShell Server von n/Software als kommerzielles Produkt nicht den Charme einer freien Lösung wie OpenSSH besitzt, hinter der zudem eine aktive Community steht (allzu viele Blog-Einträge zum Thema PowerShell Server findet man nicht), handelt es sich um ein solides Werkzeug, das seine Aufgabe erfüllt und Administratoren einen echten Remote-Zugriff auf die PowerShell via SSH von theoretisch jedem beliebigen Gerät aus ermöglicht. Das Preis-/Leistungsverhältnis ist in Ordnung, da die Lösung eine Fülle neuer Möglichkeiten für eine „Fern-Wartung“ ermöglicht und es nicht allzu viele Alternativen gibt (das ist vornehm übertrieben, da PowerShell Server die einzige Alternative ist, die ich kenne). Dass es auch mit einem Mobiltelefon klappt, kann man hier bestaunen. Dass es sogar mit meinem iPod Touch funktioniert (ich habe dazu ein kleines SSH-Tool für 79 Cent käuflich erworben) zeigt das folgende Bild.

 

IpodPowerShellRemote
(Abbildung: Das ist keine Fälschung – mit meinem iPod Touch konfiguriere ich Windows-Dienste auf einem Server via SSH)

Advertisements

Kommentar verfassen

Bitte logge dich mit einer dieser Methoden ein, um deinen Kommentar zu veröffentlichen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s