In meiner Arbeit mit IT-Teams – sei es in Trainings oder im Consulting – ist ein PowerShell-Thema eigentlich immer ein zentraler Bestandteil: PowerShell Remoting. Oft unterschätzt, doch immens mächtig, wenn man es richtig versteht und sicher einsetzt. In diesem Beitrag möchte ich die verschiedenen Remoting-Ansätze strukturieren, auf Versionen und Sicherheitsaspekte eingehen und aus der Praxis berichten, was funktioniert – und wo Stolperfallen lauern.
Grundlagen: Was ist PowerShell Remoting eigentlich?
Viele Administrator:inen stehen vor der Frage: Wann verwende ich Invoke-Command, wann Enter-PSSession – und wie stelle ich sicher, dass PowerShell Remoting sicher und zuverlässig funktioniert?
Diese Entscheidung hängt von vielen Faktoren ab: dem Zweck der Verbindung, der Infrastruktur, Sicherheitsrichtlinien und der eingesetzten PowerShell-Version.
PowerShell Remoting ist eine Funktionalität, mit der sich PowerShell-Befehle und -Skripte auf entfernten Computern ausführen lassen. Dies erfolgt in der Regel über WinRM (Windows Remote Management) bei Windows PowerShell 5.1 und PowerShell 7 oder optional über SSH (Secure Shell) in PowerShell 7. Das Ziel: administrative Aufgaben zentralisiert und automatisiert über Systemgrenzen hinweg durchführen.
Remoting-Typen im Vergleich
Ad-hoc vs. Sitzungsbasiertes Remoting
Ad-hoc Remoting eignet sich für spontane, einmalige Befehlssätze. Dabei wird ein Befehl direkt an ein oder mehrere Zielsysteme gesendet:
Invoke-Command -ComputerName 'Server01' -ScriptBlock { Get-Service }Dieser Aufruf stellt eine temporäre Verbindung mit dem Remotesystem her, führt auf dem Zielsystem den Befehl Get-Service aus und beendet die Verbindung sofort wieder. Es findet kein Erhalt von Kontext oder Sitzung statt – wird daher direkt vor oder nach der oben aufgeführten Pipeline auf etwaig vorhandene Remotesizungen via Get-PSSession geprüft, sollte es keine Verbindungen geben, bzw. diese wurde für die entsprechende Anfrage nicht genutzt. Alternativ kann Ad-hoc Remoting auch über das Cmdlet Enter-PSSession geführt werden.
Sitzungsbasiertes Remoting hingegen erlaubt es, eine Verbindung aufzubauen, die für mehrere Befehle persistiert bleibt. Dies ist sinnvoll, wenn man z. B. ein Modul auf dem Zielsystem importieren oder mehrere Schritte in Folge ausführen möchte:
$session = New-PSSession -ComputerName 'Server01'
Enter-PSSession $session
Get-Process
Exit-PSSessionIn diesem Beispiel wird zunächst eine Remotesitzung mit dem Zielsystem aufgebaut und diese Verbindung in der Variable $session gespeichert. Anschließend wird diese Sizung durch das Cmdlet Enter-PSSession aufgerufen. Die übrigen beiden Befehle werden anschließend in der Remotsitzung ausgeführt. Nach dem Verlassen der Remotesitzung durch Exit-PSSession sollte noch immer die entsprechende Remotesitzung im Speicher vorliegen, was durch das Cmdlet Get-PSSession geprüft werden kann. Der Vorteil des Sitzungsbasierten Remotings liegt in der Effizienz und der besseren Kontrolle über komplexere Abläufe.
Tipp: Verwende Ad-hoc Remoting für einfache Einzelbefehle. Für aufeinanderfolgende Aufgaben empfiehlt sich eine Sitzung mit New-PSSession und Enter-PSSession.
One-to-One vs. One-to-Many Remoting
Beim One-to-One Remoting – ob Ad-hoc oder sitzungsbasiert – wird eine Verbindung zu genau einem Zielsystem aufgebaut. Für interaktive Fehleranalyse oder gezielte Wartung ist die direkte Sitzung oft der praktikabelste Weg:
Enter-PSSession -ComputerName 'Server01'
Get-EventLog -LogName System -Newest 10
Exit-PSSessionOne-to-Many Remoting hingegen ist ideal für administrative Aufgaben, die auf mehreren Systemen parallel ausgeführt werden sollen. Mehrere Zielcomputer werden dazu als Array angegeben:
Invoke-Command -ComputerName 'Server01','Server02','Server03' -ScriptBlock { Get-HotFix }Die Ergebnisse werden als gruppierte Objekte zurückgegeben und lassen sich mittels Group-Object oder Format-Table weiterverarbeiten.
Tipp: One-to-Many Remoting ist besonders effizient für Inventarisierungen oder Statusabfragen in größeren IT-Umgebungen. zurückgegeben und lassen sich mittels Group-Object oder Format-Table weiterverarbeiten.
Explizites vs. Implizites Remoting
Beim expliziten Remoting wird die Verbindung zum Zielsystem direkt aufgebaut und sichtbar gesteuert. Besonders praxisnah ist hier die Verwendung einer interaktiven Sitzung mit Enter-PSSession, um direkt auf dem Zielsystem zu arbeiten:
Enter-PSSession -ComputerName 'DC01'
Get-ADUser -Filter *
Exit-PSSessionDiese Methode erlaubt eine direkte Interaktion mit dem entfernten System, etwa zur Analyse von Benutzerkonten, laufenden Prozessen oder Logs. Alternativ kann explizites Remoting auch durch die Verwendung des Cmdlets Invoke-Command realisiert werden.
Tipp: Interaktive Remotesitzungen mit Enter-PSSession eignen sich besonders gut für Diagnosen und einmalige Änderungen auf einem Zielsystem. mit dem entfernten System, etwa zur Analyse von Benutzerkonten, laufenden Prozessen oder Logs.
Beim impliziten Remoting hingegen werden Cmdlets und Funktionen eines entfernten Systems lokal zur Verfügung gestellt und als sogenannten Proxy-Cmdlets in den lokalen Speicher geladen. Das geschieht über den Import einer Remoting-Sitzung:
$session = New-PSSession -ComputerName 'DC01'
Import-PSSession -Session $session -Module ActiveDirectoryNach dem Import kann man scheinbar lokal mit Active Directory Cmdlets arbeiten, obwohl die Ausführung remote auf dem Domain Controller erfolgt. Das ist besonders dann hilfreich, wenn lokale Systeme die entsprechenden Module nicht installiert haben oder nicht Mitglied der Domäne sind. Ein Beispiel:
Get-ADComputer -Filter * | Where-Object -Property Enabled -eq $trueDiese Abfrage läuft über die Session gegen den Domain Controller und liefert dennoch lokal nutzbare Ergebnisse. Implizites Remoting eignet sich somit zum komfortablen Skripting auf einer lokalen Worstation unter Nutzung von Ressourcen eines einfacheren Remotesystems, z.B. ein Windows ServerCore, der die entsprechenden Schnittstellen vorhält.
Tipp: Implizites Remoting eignet sich hervorragend, wenn du remote installierte Module auf deinem lokalen System verfügbar machen möchtest – etwa das Active Directory-Modul vom Domänencontroller. gegen den Domain Controller und liefert dennoch lokal nutzbare Ergebnisse.
Exkurs: Remotesitzungen und PowerShell Scope
Beim Arbeiten mit PowerShell Remoting ist es essenziell, das Verhalten von Remotesitzungen im Kontext von PowerShell Scopes zu verstehen – insbesondere, wenn mehrere Fenster oder Prozesse parallel genutzt werden oder Sitzungen scheinbar ‚verschwinden‘.
Was passiert beim Schließen eines PowerShell-Fensters?
Wird ein PowerShell-Fenster geschlossen, während eine Remotesitzung aktiv war (z.B. über $session = New-PSSession ...), so bleibt die Sitzung auf dem Zielsystem bestehen, sofern sie nicht explizit entfernt wurde. Diese persistente Verbindung kann weiter existieren, was insbesondere in Skriptumgebungen oder bei der späteren Wiederverwendung von Sitzungen relevant ist.
Beispiel:
$session = New-PSSession -ComputerName 'Server01'
# PowerShell-Fenster wird jetzt geschlossenIn diesem Fall bleibt die Sitzung auf Server01 bestehen, bis sie manuell mit Remove-PSSession oder durch Zeitüberschreitung (IdleTimeout) beendet wird.
Was passiert bei paralleler Arbeit mit mehreren PowerShell-Fenstern?
PowerShell-Sitzungen sind an den lokalen Prozess gebunden, in dem sie erstellt wurden. Öffnet man also ein neues PowerShell-Fenster oder startet eine neue Konsole, sind bestehende PSSessions nicht automatisch verfügbar. Es handelt sich um getrennte Prozesse mit jeweils eigenem Variablenspeicher (Scope).
Das bedeutet: Eine in Fenster A erzeugte Sitzung ($sessionA) ist in Fenster B nicht bekannt und müsste dort entweder neu erzeugt oder über eine andere Technik (z.B. Skriptdateien, Transkripte oder Export/Import von Variablen) verfügbar gemacht werden.
Empfehlungen für den produktiven Umgang:
- Verwende konsistente Sitzungskonzepte in Skripten – z. B. mit
Using:-Scopes oder über zentrale Funktionsbibliotheken. - Führe
Remove-PSSessionkonsequent durch, wenn eine Sitzung nicht mehr benötigt wird. - Nutze
$PSSession-Objekte bewusst und übergib sie gezielt zwischen Modulen oder Skriptabschnitten. - Für dauerhafte oder zentrale Aufgaben lohnt sich ein Blick auf PowerShell JEA (Just Enough Administration) oder zentrale Remoting-Proxies.
Remotesitzungen sind mächtig – aber ihr Lebenszyklus ist eng an den lokalen Kontext gebunden. Wer das Verhalten in Bezug auf Prozessgrenzen und Scopes kennt, kann gezielter automatisieren und Fehler vermeiden.
Windows PowerShell 5.1 vs. PowerShell 7 im Remoting-Kontext
Administrator:innen haben aktuell die Wahl zwischen der Windows PowerShell in der Version 5.1 – die selbst bei aktuellen Betriebssystemen wie Windows 11 und Windows Server 2025 noch vorinstalliert ist – oder der plattformunabhängig entwickelten Version PowerShell 7, die sowohl unter Windows, Linux und macOS nachinstalliert werden kann. In der aktuellen Betrachtung ist jedoch ausschließlich Bedeutsam, dass mit beiden PowerShell-Varianten PowerShell Remoting realisiert werden kann. Dennoch gibt es einige Detailunterschiede:
| Merkmal | Windows PowerShell 5.1 | PowerShell 7 |
|---|---|---|
| Plattform | Nur Windows | Windows, Linux, macOS |
| Standardprotokoll | WinRM | SSH (empfohlen), WinRM |
| Parallelisierung | Eingeschränkt | ForEach-Object -Parallel verfügbar |
| Modulkompatibilität | Vollständig für Windows-Module | Eingeschränkt, teilweise Workarounds erforderlich |
| Sicherheitsfeatures | GPO, TrustedHosts, Kerberos/NTLM | SSH-Schlüssel, plattformübergreifende Authentifizierung |
Während PowerShell 5.1 insbesondere für klassische Windows-Infrastrukturen optimiert ist, bietet PowerShell 7 deutlich mehr Flexibilität für heterogene Umgebungen. Die Wahl des Protokolls – WinRM oder SSH – ist dabei entscheidend für Kompatibilität und Sicherheit.
Tipp: Wenn du plattformübergreifend arbeitest oder auf moderne Authentifizierung setzen möchtest, ist PowerShell 7 mit SSH die langfristig tragfähigere Lösung. optimiert ist, bietet PowerShell 7 deutlich mehr Flexibilität für heterogene Umgebungen. Die Wahl des Protokolls – WinRM oder SSH – ist dabei entscheidend für Kompatibilität und Sicherheit.
Exkurs: PowerShell-Generationen – von Windows PowerShell zu PowerShell 7
Die Welt der PowerShell hat sich in den letzten Jahren grundlegend gewandelt. Wer heute mit PowerShell arbeitet, begegnet nicht mehr nur der klassischen Windows PowerShell, sondern auch den plattformübergreifenden Nachfolgern wie PowerShell 7. Gerade im Kontext von Remoting ist es entscheidend zu verstehen, welche Version welche Funktionalitäten bietet – und welche technischen Grundlagen dahinterstehen.
Windows PowerShell: Altbewährt, aber gebunden
Windows PowerShell (aktuell bis Version 5.1) ist tief im Windows-Ökosystem verwurzelt. Sie basiert auf dem klassischen .NET Framework und ist standardmäßig auf allen modernen Windows-Versionen vorinstalliert. Diese enge Integration bringt Vorteile im Zusammenspiel mit Windows-Komponenten, limitiert jedoch die Portabilität und Weiterentwicklung der Shell.
Zudem wurde die Weiterentwicklung von Windows PowerShell mit Version 5.1 weitgehend eingestellt. Microsoft hat den Fokus längst auf die plattformübergreifende Weiterentwicklung gelegt – und damit den Grundstein für PowerShell Core und PowerShell 7 gelegt.
PowerShell Core 6: Der erste Schritt in die Freiheit
Mit PowerShell Core 6 wagte Microsoft den Bruch mit alten Abhängigkeiten. Die Shell wurde komplett neu auf dem modularen, plattformunabhängigen .NET Core (statt .NET Framework) aufgebaut. Dadurch konnte PowerShell erstmals auch unter macOS und Linux betrieben werden.
Dieser Schritt brachte zwar neue Möglichkeiten – insbesondere für heterogene IT-Umgebungen und DevOps-Szenarien –, aber auch Einschränkungen: Viele Windows-spezifische Cmdlets und Module funktionierten in Core 6 nicht oder nur eingeschränkt. PowerShell Core 6 war somit ein technologischer Meilenstein, aber noch kein vollwertiger Ersatz für Windows PowerShell im Unternehmensumfeld.
PowerShell 7: Der neue Standard
Mit PowerShell 7 (und den aktuellen Folgeversionen) wurde die Brücke zwischen Alt und Neu geschlagen. Die Shell basiert weiterhin auf dem modernen .NET (ab Version 5+), integriert aber wieder viele bekannte Cmdlets aus der Windows-Welt – durch den sogenannten Windows Compatibility Layer. Dadurch können viele bestehende Skripte und Module weiterverwendet werden, ohne auf plattformübergreifende Möglichkeiten verzichten zu müssen.
PowerShell 7 ist heute der empfohlene Weg für neue Projekte – besonders, wenn Interoperabilität, Zukunftssicherheit und moderne Remoting-Szenarien gefragt sind. Sie bietet nicht nur eine einheitliche Basis über Betriebssystemgrenzen hinweg, sondern bringt auch zahlreiche Verbesserungen bei Performance, Parallelisierung und Debugging mit.
Sicherheit beim Einsatz von PowerShell Remoting
TrustedHosts und Domänenmitgliedschaft
In Active Directory-Umgebungen funktioniert PowerShell Remoting meist out-of-the-box über das Authentifizierungsprotokoll Kerberos. In Arbeitsgruppen hingegen muss der Zielhost auf dem lokalen System manuell als vertrauenswürdig eingetragen werden:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'Server01'Dies öffnet grundsätzlich die Kommunikation, bedeutet aber auch ein erhöhtes Risiko, wenn nicht zusätzliche Schutzmaßnahmen wie HTTPS oder eingeschränkte Benutzerrechte umgesetzt werden.
Authentifizierungsmethoden
PowerShell Remoting unterstützt verschiedene Authentifizierungsmechanismen:
- Kerberos (Standard in Domäne, sicher, keine Passwortübertragung)
- NTLM (in Arbeitsgruppen, unsicherer als Kerberos)
- Basic (nur über HTTPS akzeptabel)
- Public Key Authentication (bei SSH, in PowerShell 7)
In produktiven Umgebungen empfiehlt sich der Einsatz von Kerberos oder SSH mit Public-Key-Authentifizierung.
Firewall- und Dienstkonfiguration
Auf Windows Server Systemen ist PowerShell Remoting seit der Version 2012 standardmäßig aktiviert, für Workstation muss eine separate Aktivierung erfolgen. Dazu muss folgendes Cmdlet administrativ abgesetzt werden:
Enable-PSRemoting -ForceIm Resultat führt dieses Cmdlet zu drei Effekten:
- Der Starttyp des WinRM Dienstes wird auf Automatisch gestellt
- Ein Listener wird für den WinRM Dienst erstellt
- Die entsprechenden Firewallausnahmen werden generiert
In dieser Hinsicht ist es auch nicht nachteilig, wenn dieser Befehl ggf. erneut ausgeführt wird, da so entweder die korrekte Konfiguration bestätigt wird, oder nicht korrekte Einstellungen nachgebessert werden.
Sofern es sich bei dem lokalen Netzwerk um ein Privates oder Domänennetzwerk handelt werden die notwendigen Firewallregeln automatisch aktiviert. Im Falle einse Öffentlichen Netzwerks schlägt der Befehl in dieser Hinsicht fehl. Bei PowerShell 7 und SSH müssen OpenSSH installiert und der entsprechende Port (standardmäßig 22) freigegeben sein.
Fazit: Ein Werkzeug mit Verantwortung
PowerShell Remoting ist kein Selbstzweck, sondern ein strategisches Werkzeug für die zentrale und automatisierte Verwaltung moderner IT-Infrastrukturen. Die Vielzahl an Remoting-Varianten – ob Ad-hoc oder sitzungsbasiert, explizit oder implizit, One-to-One oder One-to-Many – erlaubt eine hohe Flexibilität in der täglichen Praxis.
Mit dem Wechsel von Windows PowerShell 5.1 zu PowerShell 7 entstehen neue Möglichkeiten, insbesondere durch die Unterstützung plattformübergreifender Szenarien und der Integration von SSH. Gleichzeitig steigen aber auch die Anforderungen an das Sicherheitskonzept: Trusted Hosts, Authentifizierung, Firewall- und Dienstkonfiguration sind keine Randthemen, sondern zentrale Stellschrauben für einen stabilen und sicheren Betrieb.
Wer PowerShell Remoting professionell einsetzen möchte, sollte sich nicht nur mit den technischen Grundlagen befassen, sondern auch eine langfristige Strategie für den sicheren und skalierbaren Einsatz entwickeln – dokumentiert, getestet und an die eigene Infrastruktur angepasst.