PowerShell Remoting ist eine der leistungsfähigsten Funktionen im Windows-Administrations-Toolkit. Es ermöglicht Ihnen, Befehle auszuführen, Skripte zu starten und Konfigurationen auf Remotecomputern zu verwalten — einzeln oder gleichzeitig auf Hunderten von Rechnern. Im Kern stützt sich PowerShell Remoting auf Windows Remote Management (WinRM), Microsofts Implementierung des WS-Management-Protokolls. In diesem Leitfaden erfahren Sie, wie Sie WinRM aktivieren und konfigurieren, die wichtigsten Remoting-Cmdlets verwenden, Anmeldeinformationen sicher verwalten, domänenübergreifende Szenarien handhaben und SSH-basiertes Remoting für die plattformübergreifende Verwaltung nutzen.

Voraussetzungen

Bevor Sie mit der Konfiguration von PowerShell Remoting beginnen, stellen Sie sicher, dass folgende Voraussetzungen erfüllt sind:

  • Windows Server 2016 oder neuer (oder Windows 10/11 Pro/Enterprise für Client-Rechner)
  • PowerShell 5.1 oder neuer installiert (PowerShell 7+ empfohlen für SSH-basiertes Remoting)
  • Administratorrechte auf Client- und Remotecomputern
  • Netzwerkkonnektivität auf Port 5985 (HTTP) oder 5986 (HTTPS) zwischen Client und Server
  • Active Directory-Domäne (empfohlen, aber nicht erforderlich — Arbeitsgruppen-Setups werden unten behandelt)
  • Grundlegende Vertrautheit mit PowerShell-Cmdlets und der Windows-Firewall-Konfiguration

WinRM aktivieren und konfigurieren

WinRM ist auf modernen Windows-Systemen standardmäßig installiert, aber der Dienst ist auf Client-Betriebssystemen in der Regel nicht aktiv und die Firewall-Regeln sind nicht aktiviert. Auf Windows Server-Editionen ab 2012 ist WinRM standardmäßig aktiviert, dennoch sollten Sie die Konfiguration überprüfen.

PSRemoting aktivieren

Der schnellste Weg, alles auf einmal zu aktivieren, ist das Cmdlet Enable-PSRemoting:

# In einer erhöhten PowerShell-Sitzung auf dem Remotecomputer ausführen
Enable-PSRemoting -Force

Dieser einzelne Befehl führt mehrere Aktionen aus: Er startet den WinRM-Dienst, stellt ihn auf automatischen Start ein, erstellt einen HTTP-Listener auf Port 5985, fügt Windows-Firewall-Ausnahmen hinzu und registriert die Standard-PowerShell-Sitzungskonfigurationen.

WinRM-Listener überprüfen

Bestätigen Sie nach der Aktivierung, dass der Dienst läuft und die Listener aktiv sind:

# Dienststatus prüfen
Get-Service WinRM

# Aktive Listener auflisten
Get-WSManInstance -ResourceURI winrm/config/listener -Enumerate

# Schneller Konnektivitätstest vom Client
Test-WSMan -ComputerName SERVER01

TrustedHosts konfigurieren

In einer Domänenumgebung übernimmt Kerberos die Authentifizierung transparent. In Arbeitsgruppen- oder domänenübergreifenden Szenarien müssen Sie TrustedHosts auf dem Client-Rechner konfigurieren:

# Einzelnen Host hinzufügen
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "SERVER01"

# Mehrere Hosts hinzufügen (kommagetrennt)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "SERVER01,SERVER02,192.168.1.50"

# Allen Hosts vertrauen (NICHT empfohlen für Produktionsumgebungen)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*"

# Aktuelle TrustedHosts anzeigen
Get-Item WSMan:\localhost\Client\TrustedHosts

HTTPS-Transport konfigurieren

Für Produktionsumgebungen, insbesondere über nicht vertrauenswürdige Netzwerke, verschlüsselt der HTTPS-Transport die gesamte WinRM-Sitzung:

# Auf dem Remoteserver: selbstsigniertes Zertifikat erstellen
$cert = New-SelfSignedCertificate -DnsName "SERVER01.contoso.com" `
    -CertStoreLocation Cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(5)

# HTTPS-Listener mit dem Zertifikats-Thumbprint erstellen
New-WSManInstance -ResourceURI winrm/config/listener `
    -SelectorSet @{Address="*"; Transport="HTTPS"} `
    -ValueSet @{CertificateThumbprint=$cert.Thumbprint}

# Firewall-Regel für HTTPS hinzufügen
New-NetFirewallRule -DisplayName "WinRM HTTPS" -Direction Inbound `
    -LocalPort 5986 -Protocol TCP -Action Allow

Konfiguration über Gruppenrichtlinien

Für die domänenweite Bereitstellung verwenden Sie Gruppenrichtlinien, um WinRM im großen Maßstab zu aktivieren:

  1. Navigieren Sie zu Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Windows-Remoteverwaltung → WinRM-Dienst
  2. Aktivieren Sie Remoteverwaltung über WinRM zulassen
  3. Setzen Sie den IPv4/IPv6-Filter auf * oder bestimmte Subnetze
  4. Konfigurieren Sie Windows-Remote-Shell → Remote-Shell-Zugriff zulassen auf Aktiviert

Invoke-Command und Enter-PSSession verwenden

PowerShell bietet zwei primäre Cmdlets für die Remote-Ausführung, die jeweils für unterschiedliche Arbeitsabläufe geeignet sind.

Invoke-Command — Parallele Stapelausführung

Invoke-Command sendet einen Skriptblock an einen oder mehrere Computer und führt sie standardmäßig parallel aus (bis zu 32 gleichzeitige Verbindungen):

# Befehl auf einem einzelnen Remote-Host ausführen
Invoke-Command -ComputerName SERVER01 -ScriptBlock {
    Get-Process | Sort-Object CPU -Descending | Select-Object -First 10
}

# Auf mehreren Servern gleichzeitig ausführen
$servers = @("SERVER01", "SERVER02", "SERVER03", "SERVER04")
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-Service -Name "W3SVC" | Select-Object Status, MachineName
}

# Parallelität für große Umgebungen drosseln
Invoke-Command -ComputerName $servers -ScriptBlock {
    Restart-Service -Name "Spooler" -Force
} -ThrottleLimit 10

# Lokale Skriptdatei auf Remotecomputern ausführen
Invoke-Command -ComputerName $servers -FilePath "C:\Scripts\Audit-Security.ps1"

Enter-PSSession — Interaktives Remoting

Enter-PSSession eignet sich ideal für die Ad-hoc-Fehlersuche, bei der Sie eine interaktive Shell benötigen:

# Interaktive Sitzung starten
Enter-PSSession -ComputerName SERVER01 -Credential (Get-Credential)

# Sie befinden sich nun auf SERVER01 — Befehle wie lokal ausführen
[SERVER01]: PS C:\> Get-EventLog -LogName System -Newest 20
[SERVER01]: PS C:\> Get-Disk | Format-Table
[SERVER01]: PS C:\> Exit-PSSession

Persistente Sitzungen (PSSessions)

Für wiederholte Verbindungen erstellen Sie eine persistente Sitzung, um den Overhead einer neuen Verbindung jedes Mal zu vermeiden:

# Persistente Sitzungen erstellen
$sessions = New-PSSession -ComputerName SERVER01, SERVER02, SERVER03

# Sitzung für mehrere Befehle wiederverwenden
Invoke-Command -Session $sessions -ScriptBlock { Get-HotFix | Select-Object -Last 5 }
Invoke-Command -Session $sessions -ScriptBlock { Get-WindowsFeature | Where-Object Installed }

# Dateien über eine Sitzung kopieren
Copy-Item -Path "C:\Deploy\app.zip" -Destination "C:\Install\" -ToSession $sessions[0]

# Aufräumen wenn fertig
Remove-PSSession $sessions

Anmeldeinformationen und Sicherheit

Die ordnungsgemäße Verwaltung von Anmeldeinformationen ist entscheidend für sicheres Remoting im großen Maßstab.

Get-Credential und PSCredential verwenden

# Interaktive Abfrage
$cred = Get-Credential -UserName "CONTOSO\admin" -Message "Enter remote admin password"

# Programmatische Anmeldeinformationen (für Automatisierung — Passwortquelle schützen)
$securePass = ConvertTo-SecureString "P@ssw0rd!" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential("CONTOSO\admin", $securePass)

Anmeldeinformationen sicher speichern

Hardcodieren Sie niemals Passwörter in Skripten. Verwenden Sie einen dieser Ansätze:

# Verschlüsselte Anmeldeinformationen in Datei exportieren (benutzer- und maschinenspezifisch)
Get-Credential | Export-Clixml -Path "$HOME\cred.xml"

# In einer anderen Sitzung importieren (nur gleicher Benutzer, gleicher Rechner)
$cred = Import-Clixml -Path "$HOME\cred.xml"

# Windows-Anmeldeinformationsverwaltung über das CredentialManager-Modul
Install-Module -Name CredentialManager -Force
New-StoredCredential -Target "WinRM-Admin" -UserName "CONTOSO\admin" `
    -Password "P@ssw0rd!" -Persist LocalMachine
$cred = Get-StoredCredential -Target "WinRM-Admin"

CredSSP für Double-Hop-Szenarien

Wenn ein Remote-Befehl auf eine zweite Ressource zugreifen muss (das „Double-Hop”-Problem), konfigurieren Sie die CredSSP-Delegierung:

# Auf dem Client: CredSSP-Client-Rolle aktivieren
Enable-WSManCredSSP -Role Client -DelegateComputer "SERVER01.contoso.com"

# Auf dem Server: CredSSP-Server-Rolle aktivieren
Enable-WSManCredSSP -Role Server

# Verbindung mit CredSSP-Authentifizierung herstellen
Invoke-Command -ComputerName SERVER01 -Credential $cred `
    -Authentication CredSSP -ScriptBlock {
    # Kann jetzt auf Netzwerkressourcen wie Dateifreigaben zugreifen
    Get-ChildItem "\\FILESERVER\Share$"
}

Warnung: CredSSP sendet Anmeldeinformationen an den Remoteserver. Verwenden Sie es nur mit Rechnern, denen Sie vertrauen, und vorzugsweise über HTTPS.

Just Enough Administration (JEA)

Für Remoting mit minimalen Berechtigungen konfigurieren Sie JEA-Endpunkte, die einschränken, was Benutzer tun können:

# Rollenfähigkeitsdatei erstellen
New-PSRoleCapabilityFile -Path "C:\JEA\HelpDeskRole.psrc" `
    -VisibleCmdlets @("Restart-Service", "Get-Service", "Get-Process") `
    -VisibleFunctions @("Get-HotFix")

# Sitzungskonfiguration erstellen
New-PSSessionConfigurationFile -Path "C:\JEA\HelpDesk.pssc" `
    -SessionType RestrictedRemoteServer `
    -RunAsVirtualAccount `
    -RoleDefinitions @{ "CONTOSO\HelpDesk" = @{ RoleCapabilities = "HelpDeskRole" } }

# Endpunkt registrieren
Register-PSSessionConfiguration -Name "HelpDesk" -Path "C:\JEA\HelpDesk.pssc"

SSH-basiertes Remoting für plattformübergreifende Verwaltung

Ab PowerShell 7 können Sie SSH als Transportschicht anstelle von WinRM verwenden. Dies ist besonders nützlich für die Verwaltung von Linux- und macOS-Rechnern neben Windows-Servern.

OpenSSH installieren und konfigurieren

# Unter Windows: OpenSSH-Server installieren
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service sshd -StartupType Automatic

# SSH-Subsystem für PowerShell in sshd_config konfigurieren
# Diese Zeile zu C:\ProgramData\ssh\sshd_config hinzufügen:
# Subsystem powershell c:/progra~1/powershell/7/pwsh.exe -sshs -NoLogo -NoProfile
Restart-Service sshd

Unter Linux fügen Sie das PowerShell-Subsystem zu /etc/ssh/sshd_config hinzu:

# PowerShell unter Ubuntu installieren
sudo apt-get update && sudo apt-get install -y powershell

# Subsystem zur sshd_config hinzufügen
echo "Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile" | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart sshd

SSH-basiertes Remoting verwenden

# Interaktive Sitzung über SSH
Enter-PSSession -HostName linux-server01 -UserName admin -SSHTransport

# Befehle auf Linux von Windows aus ausführen
Invoke-Command -HostName linux-server01 -UserName admin -ScriptBlock {
    uname -a
    df -h
    systemctl status nginx
}

# Gemischte Betriebssysteme ansprechen
$windowsSession = New-PSSession -ComputerName WIN-SRV01 -Credential $cred
$linuxSession = New-PSSession -HostName LINUX-SRV01 -UserName admin -SSHTransport

Invoke-Command -Session $windowsSession, $linuxSession -ScriptBlock {
    if ($IsLinux) { cat /etc/os-release } else { Get-ComputerInfo | Select-Object OsName }
}

Vergleich: WinRM vs SSH-basiert vs OpenSSH unter Windows

MerkmalWinRM (HTTP/HTTPS)SSH-basiertes Remoting (PS7)OpenSSH unter Windows
ProtokollWS-ManagementSSHSSH
Standard-Ports5985 / 59862222
AuthentifizierungKerberos, NTLM, CredSSPSSH-Schlüssel, PasswortSSH-Schlüssel, Passwort
PlattformübergreifendNur WindowsWindows, Linux, macOSNur Windows (Server)
PowerShell-Version5.1+7.0+ erforderlichBeliebig (nur SSH-Shell)
VerschlüsselungHTTPS oder NachrichtenebeneImmer verschlüsseltImmer verschlüsselt
Double-HopCredSSP oder Kerberos-DelegierungSSH-Agent-WeiterleitungSSH-Agent-Weiterleitung
DomänenintegrationNative AD/KerberosManuelle SchlüsselverwaltungManuelle Schlüsselverwaltung
GPO-VerwaltungVolle UnterstützungEingeschränktEingeschränkt
Ideal fürReine Windows-UmgebungenGemischte BetriebssystemeLinux-Admins mit Windows

Praxisszenario

Stellen Sie sich vor, Sie sind Systemadministrator und verwalten über 50 Windows-Server in drei Umgebungen — Entwicklung, Staging und Produktion — sowie eine Handvoll Linux-Rechner mit Nginx-Reverse-Proxies. So würden Sie Ihren PowerShell-Remoting-Workflow strukturieren:

# Servergruppen definieren
$devServers = Get-Content "C:\ServerLists\dev.txt"
$stagingServers = Get-Content "C:\ServerLists\staging.txt"
$prodServers = Get-Content "C:\ServerLists\prod.txt"

# Persistente Sitzungen mit gespeicherten Anmeldeinformationen erstellen
$cred = Import-Clixml "$HOME\admin-cred.xml"
$devSessions = New-PSSession -ComputerName $devServers -Credential $cred
$stagingSessions = New-PSSession -ComputerName $stagingServers -Credential $cred

# Morgendlicher Gesundheitscheck über alle Entwicklungsserver
$healthReport = Invoke-Command -Session $devSessions -ScriptBlock {
    [PSCustomObject]@{
        Server     = $env:COMPUTERNAME
        Uptime     = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
        CPUPercent = (Get-CimInstance Win32_Processor).LoadPercentage
        FreeGB     = [math]::Round((Get-CimInstance Win32_LogicalDisk -Filter "DeviceID='C:'").FreeSpace / 1GB, 2)
        Services   = (Get-Service | Where-Object { $_.StartType -eq "Automatic" -and $_.Status -ne "Running" }).Count
    }
}

$healthReport | Format-Table Server, Uptime, CPUPercent, FreeGB, Services -AutoSize

# Hotfix mit gedrosselter Parallelität auf Staging bereitstellen
Invoke-Command -Session $stagingSessions -ThrottleLimit 5 -ScriptBlock {
    Start-Process msiexec.exe -ArgumentList "/i C:\Deploy\hotfix-kb123.msi /quiet" -Wait
    Write-Output "$env:COMPUTERNAME — Hotfix installiert"
}

# Linux-Proxies über SSH prüfen
$linuxSessions = New-PSSession -HostName "proxy01","proxy02" -UserName admin -SSHTransport
Invoke-Command -Session $linuxSessions -ScriptBlock {
    systemctl is-active nginx
    curl -s -o /dev/null -w "%{http_code}" http://localhost
}

Dieses Muster hält Sitzungen für die Dauer Ihrer Arbeit offen, minimiert den Authentifizierungs-Overhead und ermöglicht es Ihnen, bestimmte Umgebungsgruppen mit gedrosselter Ausführung anzusprechen.

Stolperfallen und Sonderfälle

  • Firewall-Blockierung: WinRM verwendet Port 5985 (HTTP) und 5986 (HTTPS). Wenn Remoting lautlos fehlschlägt, prüfen Sie sowohl die Windows-Firewall als auch alle Netzwerk-Firewalls zwischen Client und Server.
  • TrustedHosts-Zurücksetzung: Das Setzen von TrustedHosts mit Set-Item ersetzt die gesamte Liste. Verwenden Sie -Concatenate zum Anhängen: Set-Item WSMan:\localhost\Client\TrustedHosts -Value "NEWSERVER" -Concatenate.
  • MaxMemoryPerShellMB: Das Standardlimit (1024 MB) kann dazu führen, dass Sitzungen bei speicherintensiven Operationen abbrechen. Erhöhen Sie es mit Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 2048.
  • Double-Hop-Fehler: Der Zugriff auf Netzwerkressourcen aus einer Remote-Sitzung schlägt standardmäßig fehl. Verwenden Sie CredSSP, eingeschränkte Kerberos-Delegierung oder ressourcenbasierte eingeschränkte Delegierung, um dies zu lösen.
  • Sitzungslimits: WinRM erlaubt standardmäßig 25 gleichzeitige Shells pro Benutzer. Erhöhen Sie bei großen Umgebungen MaxShellsPerUser in der WinRM-Konfiguration.
  • Zeitzonen-Abweichung: Zeitstempel aus Remote-Sitzungen verwenden die Zeitzone des Remote-Servers. Verwenden Sie [DateTime]::UtcNow für Konsistenz in Multi-Region-Umgebungen.
  • SSH-Subsystem-Pfad: Unter Windows muss der Subsystem-Pfad in sshd_config das 8.3-Kurzpfadformat (progra~1) oder den vollständigen Pfad ohne Leerzeichen verwenden.
  • Serialisierungslimits: Objekte, die aus Remote-Sitzungen zurückgegeben werden, sind deserialisiert — sie verlieren ihre Methoden. Was zurückkommt, ist ein Snapshot, kein Live-Objekt. Planen Sie Ihre Skriptblöcke so, dass sie die benötigten Daten auf der Remote-Seite extrahieren.
  • PowerShell-Versionskonflikt: Wenn der Remotecomputer PowerShell 5.1 und der Client PowerShell 7 ausführt, sind nicht alle Cmdlets verfügbar. Testen Sie mit -ConfigurationName PowerShell.7 für PS7-Endpunkte.

Zusammenfassung

  • Enable-PSRemoting ist der zentrale Befehl zur Konfiguration von WinRM auf jedem Windows-Rechner.
  • TrustedHosts muss auf dem Client für Arbeitsgruppen- oder domänenübergreifende Verbindungen konfiguriert werden.
  • HTTPS-Transport sollte in der Produktion verwendet werden, um den Remoting-Datenverkehr durchgängig zu verschlüsseln.
  • Invoke-Command ist das Arbeitspferd für die parallele Ausführung auf mehreren Servern; Enter-PSSession eignet sich am besten für interaktive Fehlersuche.
  • Anmeldeinformationen sollten über Export-Clixml, Credential Manager oder einen Secrets-Vault verwaltet werden — niemals hartcodierte Passwörter.
  • CredSSP oder eingeschränkte Kerberos-Delegierung löst das Double-Hop-Problem.
  • SSH-basiertes Remoting in PowerShell 7+ ermöglicht die plattformübergreifende Verwaltung von Linux und macOS aus denselben Skripten.
  • JEA-Endpunkte bieten Remoting mit minimalen Berechtigungen für die delegierte Administration.
  • Achten Sie auf Sitzungslimits, Serialisierungsverhalten und Firewall-Regeln, wenn Ihre Umgebung wächst.

Verwandte Artikel