FAQs zu PowerShell-Remoting

Ja. Um remote arbeiten zu können, müssen der lokale und der Remotecomputer über PowerShell, das Microsoft .NET Framework und das WS-Management-Protokoll (Web Services for Management) verfügen. Alle Dateien und andere Ressourcen, die zum Ausführen eines bestimmten Befehls erforderlich sind, müssen sich auf dem Remotecomputer befinden.

Computer, auf denen Windows PowerShell 3.0 ausgeführt wird, und Computer, auf denen Windows PowerShell 2.0 ausgeführt wird, können remote miteinander verbunden werden und Remotebefehle ausführen. Doch einige Features, z. B. die Möglichkeit, die Verbindung mit einer Sitzung zu trennen und neu herzustellen, funktionieren nur, wenn auf beiden Computern Windows PowerShell 3.0 ausgeführt wird.

Sie müssen über die Berechtigungen zum Herstellen einer Verbindung mit dem Remotecomputer, zum Ausführen von PowerShell und zum Zugreifen auf Datenspeicher (z. B. Dateien und Ordner) und die Registrierung auf dem Remotecomputer verfügen.

Weitere Informationen finden Sie unter about_Remote_Requirements.

Wenn Sie einen Remotebefehl übermitteln, wird er über das Netzwerk an die PowerShell-Engine auf dem Remotecomputer übertragen und im PowerShell-Client auf dem Remotecomputer ausgeführt. Die Ergebnisse des Befehls werden an den lokalen Computer zurückgesendet und in der PowerShell-Sitzung auf dem lokalen Computer angezeigt.

Um die Befehle zu übertragen und die Ausgabe zu empfangen, verwendet PowerShell das WS-Management-Protokoll. Informationen zum WS-Management-Protokoll finden Sie unter WS-Management-Protokoll in der Windows-Dokumentation.

Ab Windows PowerShell 3.0 werden Remotesitzungen auf dem Remotecomputer gespeichert. Dadurch können Sie die Verbindung mit der Sitzung trennen und mit einer anderen Sitzung oder einem anderen Computer neu herstellen, ohne die Befehle zu unterbrechen oder den Zustand zu verlieren.

Wenn Sie eine Verbindung mit einem Remotecomputer herstellen, verwendet das System die Anmeldeinformationen aus Benutzername und Kennwort auf dem lokalen Computer oder die im Befehl angegebenen Anmeldeinformationen, um Sie beim Remotecomputer anzumelden. Die Anmeldeinformationen und die restliche Übertragung werden verschlüsselt.

Für zusätzlichen Schutz können Sie den Remotecomputer so konfigurieren, dass er Secure Sockets Layer (SSL) anstelle von HTTP verwendet, um auf WinRM-Anforderungen (Windows-Remoteverwaltung) zu lauschen. Dann können Benutzer den Parameter UseSSL der Cmdlets Invoke-Command, New-PSSession und Enter-PSSession beim Herstellen einer Verbindung verwenden. Diese Option verwendet den sichereren HTTPS-Kanal anstelle von HTTP.

Nein Einige Cmdlets haben den Parameter ComputerName, mit dem Sie Objekte vom Remotecomputer abrufen können.

Diese Cmdlets verwenden kein PowerShell-Remoting. Sie können sie also auf jedem Computer verwenden, auf dem PowerShell ausgeführt wird, selbst wenn der Computer nicht für PowerShell-Remoting konfiguriert ist oder der Computer die Anforderungen für PowerShell-Remoting nicht erfüllt.

Zu diesen Cmdlets zählen:

• Get-Hotfix
• Rename-Computer
• Restart-Computer
• Stop-Computer

Um alle Cmdlets mit dem Parameter ComputerName zu finden, geben Sie Folgendes ein:

Get-Help * -Parameter ComputerName
# or
Get-Command -ParameterName ComputerName

Ob der Parameter ComputerName eines bestimmten Cmdlets PowerShell-Remoting erfordert, können Sie in der Parameterbeschreibung nachlesen. Um die Parameterbeschreibung anzuzeigen, geben Sie Folgendes ein:

Get-Help <cmdlet-name> -Parameter ComputerName

Zum Beispiel:

Get-Help Get-Hotfix -Parameter ComputerName

Für alle anderen Befehle verwenden Sie das Cmdlet Invoke-Command.

Um einen Befehl auf einem Remotecomputer auszuführen, verwenden Sie das Cmdlet Invoke-Command.

Schließen Sie Ihren Befehl in geschweifte Klammern ({}) ein, um einen Skriptblock zu bilden. Verwenden Sie den Parameter ScriptBlock von Invoke-Command, um den Befehl anzugeben.

Sie können den Parameter ComputerName von Invoke-Command verwenden, um einen Remotecomputer anzugeben. Oder Sie können eine persistente Verbindung mit einem Remotecomputer (einer Sitzung) erstellen und dann den Parameter Session von Invoke-Command verwenden, um den Befehl in der Sitzung auszuführen.

Beispielsweise führen die folgenden Befehle den Befehl Get-Process remote aus.

Invoke-Command -ComputerName Server01, Server02 -ScriptBlock {Get-Process}

#  - OR -

Invoke-Command -Session $s -ScriptBlock {Get-Process}

Um einen Remotebefehl zu unterbrechen, geben Sie STRG+C ein. Die Unterbrechungsanforderung wird an den Remotecomputer übergeben, auf dem sie den Remotebefehl beendet.

Weitere Informationen zu Remotebefehlen finden Sie unter „about_Remote“ und in den Hilfethemen zu den Cmdlets, die Remoting unterstützen.

Sie können das Cmdlet Enter-PSSession verwenden, um eine interaktive Sitzung mit einem Remotecomputer zu starten.

Geben Sie an der PowerShell-Eingabeaufforderung Folgendes ein:

Enter-PSSession <ComputerName>

Die Eingabeaufforderung ändert sich, um anzuzeigen, dass Sie mit dem Remotecomputer verbunden sind.

<ComputerName>\C:>

Jetzt werden Ihre eingegebenen Befehle auf dem Remotecomputer ausgeführt, als würden Sie sie direkt auf dem Remotecomputer eingeben.

Um die interaktive Sitzung zu beenden, geben Sie Folgendes ein:

Exit-PSSession

Eine interaktive Sitzung ist eine persistente Sitzung, die das WS-Management-Protokoll verwendet. Das ist nicht das Gleiche wie die Verwendung von Telnet, bietet aber eine ähnliche Erfahrung.

Weitere Informationen finden Sie unter Enter-PSSession.

Ja. Sie können Remotebefehle ausführen, indem Sie den Namen des Remotecomputers, seinen NetBIOS-Namen oder seine IP-Adresse angeben. Alternativ können Sie Remotebefehle ausführen, indem Sie eine PowerShell-Sitzung (PSSession) angeben, die mit dem Remotecomputer verbunden ist.

Wenn Sie den Parameter ComputerName von Invoke-Command oder Enter-PSSession verwenden, stellt PowerShell eine temporäre Verbindung her. PowerShell verwendet die Verbindung, um nur den aktuellen Befehl auszuführen, und schließt dann die Verbindung. Das ist eine sehr effiziente Methode zum Ausführen eines einzelnen Befehls oder mehrerer nicht zusammenhängender Befehle, auch auf vielen Remotecomputern.

Wenn Sie das Cmdlet New-PSSession zum Erstellen einer PSSession verwenden, stellt PowerShell eine persistente Verbindung für die PSSession her. Dann können Sie mehrere Befehle in der PSSession ausführen, einschließlich Befehle, die gemeinsame Daten verwenden.

In der Regel erstellen Sie eine PSSession, um mehrere zusammenhängende Befehle auszuführen, die gemeinsame Daten verwenden. Ansonsten ist die temporäre Verbindung, die vom Parameter ComputerName erstellt wird, für die meisten Befehle ausreichend.

Weitere Informationen über Sitzungen finden Sie unter about_PSSessions.

Ja. Der Parameter ComputerName des Cmdlet Invoke-Command akzeptiert mehrere Computernamen, und der Parameter Session akzeptiert mehrere PSSessions.

Wenn Sie den Befehl Invoke-Command ausführen, führt PowerShell die Befehle auf allen angegebenen Computern oder in allen angegebenen PSSessions aus.

PowerShell kann Hunderte gleichzeitige Remoteverbindungen verwalten. Doch die Anzahl der Remotebefehle, die Sie senden können, kann durch die Ressourcen Ihres Computers und seine Fähigkeit zum Herstellen und Aufrechterhalten mehrerer Netzwerkverbindungen begrenzt sein.

Weitere Informationen finden Sie im Beispiel des Hilfethemas zu Invoke-Command.

PowerShell-Profile werden nicht automatisch in Remotesitzungen ausgeführt, sodass die Befehle, die das Profil hinzufügt, nicht in der Sitzung vorhanden sind. Zudem wird die automatische Variable $profile in Remotesitzungen nicht ausgefüllt.

Um ein Profil in einer Sitzung auszuführen, verwenden Sie das Cmdlet Invoke-Command.

Mit dem folgenden Befehl wird beispielsweise das Profil CurrentUserCurrentHost vom lokalen Computer in der Sitzung in $s ausgeführt.

Invoke-Command -Session $s -FilePath $profile

Der folgende Befehl führt das Profil CurrentUserCurrentHost vom Remotecomputer in der Sitzung in $s aus. Da die Variable $profile nicht ausgefüllt wird, verwendet der Befehl den expliziten Pfad zum Profil.

Invoke-Command -Session $s {
  . "$home\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"
}

Nach dem Ausführen dieses Befehls sind die Befehle, die das Profil zur Sitzung hinzufügt, in $s verfügbar.

Sie können auch ein Startskript in einer Sitzungskonfiguration verwenden, um ein Profil in jeder Remotesitzung auszuführen, die die Sitzungskonfiguration verwendet.

Weitere Informationen über PowerShell-Profile finden Sie unter about_Profiles. Weitere Informationen über Sitzungskonfigurationen finden Sie unter Register-PSSessionConfiguration.

Um die Verwaltung der Ressourcen auf Ihrem lokalen Computer zu erleichtern, enthält PowerShell ein Feature zur Drosselung pro Befehl, mit dem Sie die Anzahl der gleichzeitigen Remoteverbindungen einschränken können, die für jeden Befehl hergestellt werden.

Der Standardwert beträgt 32 gleichzeitige Verbindungen, aber Sie können den Parameter ThrottleLimit der Cmdlets verwenden, um ein benutzerdefiniertes Drosselungslimit für bestimmte Befehle festzulegen.

Wenn Sie das Feature zur Drosselung verwenden, denken Sie daran, dass es auf einzelne Befehle angewendet wird, nicht auf die gesamte Sitzung oder den Computer. Wenn Sie Befehle gleichzeitig in mehreren Sitzungen oder PSSessions ausführen, ist die Anzahl der gleichzeitigen Verbindungen die Summe der gleichzeitigen Verbindungen in allen Sitzungen.

Um Cmdlets mit einem ThrottleLimit-Parameter zu finden, geben Sie Folgendes ein:

Get-Help * -Parameter ThrottleLimit
-or-
Get-Command -ParameterName ThrottleLimit

Wenn Sie PowerShell lokal verwenden, dann senden und empfangen Sie .NET Framework-Liveobjekte, also Objekte, die tatsächlichen Programmen oder Systemkomponenten zugeordnet sind. Wenn Sie die Methoden oder Eigenschaften von Liveobjekten aufrufen bzw. ändern, wirken sich die Änderungen auf die tatsächlichen Programme oder Komponenten aus. Und wenn sich die Eigenschaften von Programmen oder Komponenten ändern, ändern sich auch die Eigenschaften des Objekts, das sie repräsentiert.

Doch da die meisten Liveobjekte nicht über das Netzwerk übertragen werden können, „serialisiert“ PowerShell die meisten Objekte, die in Remotebefehlen gesendet werden. Das bedeutet, dass jedes Objekt in eine Serie von XML-Datenelementen (Constraint Language in XML [CLiXML]) für die Übertragung konvertiert wird.

Wenn PowerShell ein serialisiertes Objekt empfängt, werden die XML-Daten in einen deserialisierten Objekttyp konvertiert. Das deserialisierte Objekt ist eine genaue Aufzeichnung der Eigenschaften des Programms oder der Komponente zu einem früheren Zeitpunkt, aber es ist nicht mehr „live“, also nicht mehr direkt mit der Komponente verbunden. Und die Methoden werden entfernt, da sie nicht mehr wirksam sind.

In der Regel können Sie deserialisierte Objekte genauso verwenden, wie Sie Liveobjekte verwenden würden, aber Sie müssen ihre Einschränkungen beachten. Zudem haben die vom Cmdlet Invoke-Command zurückgegebenen Objekte zusätzliche Eigenschaften, mit denen Sie den Ursprung des Befehls bestimmen können.

Einige Objekttypen, wie „DirectoryInfo“-Objekte und GUIDs, werden wieder in Liveobjekte konvertiert, wenn sie empfangen werden. Diese Objekte erfordern keine spezielle Behandlung oder Formatierung.

Informationen zum Interpretieren und Formatieren der Remoteausgabe finden Sie unter about_Remote_Output.

Ja. Ein PowerShell-Hintergrundauftrag ist ein PowerShell-Befehl, der asynchron ausgeführt wird, ohne mit der Sitzung zu interagieren. Wenn Sie einen Hintergrundauftrag starten, kehrt die Eingabeaufforderung sofort zurück, und Sie können in der Sitzung weiterarbeiten, während der Auftrag ausgeführt wird, auch wenn er für einen längeren Zeitraum ausgeführt wird.

Sie können einen Hintergrundauftrag sogar starten, während andere Befehle ausgeführt werden, da Hintergrundaufträge immer asynchron in einer temporären Sitzung ausgeführt werden.

Sie können Hintergrundaufträge auf einem lokalen oder Remotecomputer ausführen. Standardmäßig wird ein Hintergrundauftrag auf dem lokalen Computer ausgeführt. Doch Sie können den Parameter AsJob vom Cmdlet Invoke-Command verwenden, um einen Remotebefehl als Hintergrundauftrag auszuführen. Und Sie können Invoke-Command verwenden, um den Befehl Start-Job remote auszuführen.

Weitere Informationen zu Hintergrundaufträgen in PowerShell finden Sie unter about_Jobs und about_Remote_Jobs.

Sie können PowerShell-Remotebefehle verwenden, um Windows-basierte Programme auf Remotecomputern auszuführen. Sie können z. B. Shutdown.exe oder Ipconfig.exe auf einem Remotecomputer ausführen.

Doch Sie können PowerShell-Befehle nicht verwenden, um die Benutzeroberfläche für ein Programm auf einem Remotecomputer zu öffnen.

Wenn Sie ein Windows-Programm auf einem Remotecomputer starten, wird der Befehl nicht abgeschlossen, und die PowerShell-Eingabeaufforderung kehrt erst zurück, wenn das Programm beendet ist oder Sie STRG+C drücken, um den Befehl zu unterbrechen. Wenn Sie beispielsweise das Programm Ipconfig.exe auf einem Remotecomputer ausführen, kehrt die Eingabeaufforderung erst zurück, wenn Ipconfig.exe abgeschlossen ist.

Wenn Sie Remotebefehle verwenden, um ein Programm zu starten, das über eine Benutzeroberfläche verfügt, wird der Programmprozess gestartet, aber die Benutzeroberfläche wird nicht angezeigt. Der PowerShell-Befehl wird nicht abgeschlossen, und die Eingabeaufforderung kehrt erst zurück, wenn Sie den Programmprozess anhalten oder STRG+C drücken, wodurch der Befehl unterbrochen und der Prozess angehalten wird.

Wenn Sie beispielsweise einen PowerShell-Befehl verwenden, um Notepad auf einem Remotecomputer auszuführen, wird der Editor-Prozess auf dem Remotecomputer gestartet, aber die Editor-Benutzeroberfläche wird nicht angezeigt. Um den Befehl zu unterbrechen und die Eingabeaufforderung wiederherzustellen, drücken Sie STRG+C.

Ja. Jede Remotesitzung muss eine der Sitzungskonfigurationen auf dem Remotecomputer verwenden. Sie können die Sitzungskonfigurationen auf Ihrem Computer (und die Berechtigungen für diese Sitzungskonfigurationen) verwalten, um zu bestimmen, wer welche Befehle remote auf Ihrem Computer ausführen kann.

Eine Sitzungskonfiguration konfiguriert die Umgebung für die Sitzung. Sie können die Konfiguration mit einer Assembly definieren, die eine neue Konfigurationsklasse implementiert, oder mithilfe eines Skripts, das in der Sitzung ausgeführt wird. Die Konfiguration kann die Befehle bestimmen, die in der Sitzung verfügbar sind. Und die Konfiguration kann Einstellungen zum Schutz des Computers enthalten, z. B. Einstellungen zum Einschränken der Datenmenge, die von der Sitzung remote in einem einzigen Objekt oder Befehl empfangen werden kann. Sie können auch eine Sicherheitsbeschreibung angeben, die die Berechtigungen bestimmt, die für die Verwendung der Konfiguration erforderlich sind.

Das Cmdlet Enable-PSRemoting erstellt die standardmäßigen Sitzungskonfigurationen auf Ihrem Computer: Microsoft.PowerShell, Microsoft.PowerShell.Workflow und Microsoft.PowerShell32 (nur 64-Bit-Betriebssysteme). Enable-PSRemoting legt die Sicherheitsbeschreibung für die Konfiguration so fest, dass nur Mitglieder der Gruppe „Administratoren“ auf Ihrem Computer sie verwenden können.

Sie können die Cmdlets für die Sitzungskonfiguration verwenden, um die standardmäßigen Sitzungskonfigurationen zu bearbeiten, neue Sitzungskonfigurationen zu erstellen und die Sicherheitsbeschreibungen aller Sitzungskonfigurationen zu ändern.

Ab Windows PowerShell 3.0 können Sie mit dem Cmdlet New-PSSessionConfigurationFile benutzerdefinierte Sitzungskonfigurationen mithilfe einer Textdatei erstellen. Die Datei enthält Optionen zum Festlegen des Sprachmodus und zum Angeben der Cmdlets und Module, die in Sitzungen verfügbar sind, die die Sitzungskonfiguration verwenden.

Wenn Benutzer die Cmdlets Invoke-Command, New-PSSession oder Enter-PSSession verwenden, können sie den Parameter ConfigurationName verwenden, um die Sitzungskonfiguration anzugeben, die für die Sitzung verwendet wird. Zudem können sie die Standardkonfiguration ändern, die ihre Sitzungen verwenden, indem sie den Wert der Einstellungsvariable $PSSessionConfigurationName in der Sitzung ändern.

Weitere Informationen zu Sitzungskonfigurationen finden Sie in der Hilfe zu den Cmdlets für die Sitzungskonfiguration. Um die Cmdlets für die Sitzungskonfiguration zu finden, geben Sie Folgendes ein:

Get-Command *PSSessionConfiguration

Das häufigste Szenario für PowerShell-Remoting mit mehreren Computern ist die 1:n-Konfiguration, bei der ein lokaler Computer (der Computer des Administrators) PowerShell-Befehle auf mehreren Remotecomputern ausführt. Das wird als „Fan-Out“-Szenario bezeichnet.

Doch in einigen Unternehmen wird eine n:1-Konfiguration verwendet, bei der viele Clientcomputer eine Verbindung mit einem einzelnen Remotecomputer herstellen, auf dem PowerShell ausgeführt wird, z. B. einem Dateiserver oder Kiosk. Das wird als „Fan-In“-Konfiguration bezeichnet.

PowerShell-Remoting unterstützt sowohl Fan-Out- als auch Fan-In-Konfigurationen.

Für die Fan-Out-Konfiguration verwendet PowerShell das WS-Management-Protokoll (Web Services for Management) und den WinRM-Dienst, der die Microsoft-Implementierung von WS-Management unterstützt. Wenn sich ein lokaler Computer mit einem Remotecomputer verbindet, stellt WS-Management eine Verbindung her und verwendet ein Plug-In für PowerShell, um den PowerShell-Hostprozess (Wsmprovhost.exe) auf dem Remotecomputer zu starten. Der Benutzer kann einen alternativen Port, eine alternative Sitzungskonfiguration und andere Features angeben, um die Remoteverbindung anzupassen.

Zur Unterstützung der Fan-In-Konfiguration verwendet PowerShell Internetinformationsdienste (IIS), um WS-Management zu hosten, das PowerShell-Plug-In zu laden und PowerShell zu starten. In diesem Szenario wird nicht jede PowerShell-Sitzung in einem separaten Prozess gestartet, sondern alle PowerShell-Sitzungen werden im selben Hostprozess ausgeführt.

IIS-Hosting und Fan-In-Remoteverwaltung werden in Windows XP oder Windows Server 2003 nicht unterstützt.

In einer Fan-In-Konfiguration kann der Benutzer einen Verbindungs-URI und einen HTTP-Endpunkt angeben, einschließlich Übertragung, Computername, Port und Anwendungsname. IIS leitet alle Anforderungen mit einem angegebenen Anwendungsnamen an die Anwendung weiter. Die Standardeinstellung ist WS-Management, das PowerShell hosten kann.

Sie können auch einen Authentifizierungsmechanismus angeben und die Umleitung von HTTP- und HTTPS-Endpunkten verbieten oder zulassen.

Ja. PowerShell-Remoting ist selbst dann verfügbar, wenn sich der lokale Computer nicht in einer Domäne befindet. Sie können die Remotingfeatures verwenden, um sich mit Sitzungen zu verbinden und Sitzungen auf demselben Computer zu erstellen. Die Features funktionieren genauso wie beim Herstellen einer Verbindung mit einem Remotecomputer.

Wenn Sie Remotebefehle auf einem Computer in einer Arbeitsgruppe ausführen möchten, ändern Sie die folgenden Windows-Einstellungen auf dem Computer.

Achtung: Diese Einstellungen wirken sich auf alle Benutzer im System aus, und sie können das System anfälliger für einen Angriff machen. Seien Sie vorsichtig, wenn Sie diese Änderungen vornehmen.

• Windows Vista, Windows 7, Windows 8:

  Erstellen Sie den folgenden Registrierungseintrag, und legen Sie dann den Wert auf 1 fest: LocalAccountTokenFilterPolicy in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

  Sie können den folgenden PowerShell-Befehl verwenden, um diesen Eintrag hinzuzufügen:

  $parameters = @{
    Path='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
    Name='LocalAccountTokenFilterPolicy'
    propertyType='DWord'
    Value=1
  }
  New-ItemProperty @parameters
  

• Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows Server 2012 R2:

  Es sind keine Änderungen erforderlich, denn die Standardeinstellung der Richtlinie „Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten“ ist „Klassisch“. Überprüfen Sie die Einstellung, falls sie geändert wurde.

Ja. In der Regel werden die Befehle ohne Fehler ausgeführt, aber möglicherweise müssen Sie den Parameter Credential der Cmdlets Invoke-Command, New-PSSession oder Enter-PSSession verwenden, um die Anmeldeinformationen eines Mitglieds der Gruppe „Administratoren“ auf dem Remotecomputer bereitzustellen. Das ist manchmal auch dann erforderlich, wenn der aktuelle Benutzer ein Mitglied der Gruppe „Administratoren“ auf dem lokalen und Remotecomputer ist.

Doch wenn sich der Remotecomputer nicht in einer Domäne befindet, der der lokale Computer vertraut, kann der Remotecomputer eventuell die Anmeldeinformationen des Benutzers nicht authentifizieren.

Verwenden Sie zum Aktivieren der Authentifizierung den folgenden Befehl, um den Remotecomputer zur Liste der vertrauenswürdigen Hosts für den lokalen Computer in WinRM hinzuzufügen. Geben Sie den folgenden Befehl in der PowerShell-Eingabeaufforderung ein.

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <Remote-computer-name>

Wenn Sie beispielsweise den Server01-Computer zur Liste der vertrauenswürdigen Hosts auf dem lokalen Computer hinzufügen möchten, geben Sie den folgenden Befehl in der PowerShell-Eingabeaufforderung ein:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value Server01

Ja. Weitere Informationen finden Sie unter PowerShell-Remoting über SSH.

Weitere Informationen

about_Remote

about_Profiles

about_PSSessions

about_Remote_Jobs

about_Remote_Variables

Invoke-Command

New-PSSession