Windows Server 2025 / PowerShell-Remoting mit WinRM verwenden

PowerShell-Remoting sendet Befehle an einen anderen Server oder öffnet dort eine interaktive Konsole. Prüfen Sie unter Windows Server 2025 vor Enter-PSSession oder Invoke-Command den Dienst Windows Remote Management (WinRM), den Sitzungsendpunkt und die Authentifizierung.

Trennen Sie Servereinrichtung und Clientverbindung

Konfigurieren Sie den Empfang von Verbindungen an der FS1-Konsole und führen Sie die Verbindungsbefehle auf dem Verwaltungs-PC aus. Vertauschte Ausführungsorte können unnötige Listener öffnen oder den falschen Computer abfragen. Diese Anleitung verwendet Windows PowerShell 5.1 über WinRM und keinen SSH-Transport. Führen Sie die Anweisungen interaktiv und abschnittsweise aus, statt alle Blöcke als ein einziges Skript zu starten.

• Identifizieren Sie FS1 und ein gültiges Administratorkonto für diesen Server.
• Verwenden Sie das vorgesehene isolierte Verwaltungsnetz.
• Halten Sie die Zielkonsole für die Wiederherstellung verfügbar.

Öffnen Sie auf FS1 Windows PowerShell mit Als Administrator ausführen und halten Sie den Ausgangszustand fest; Remoting kann bereits eingerichtet sein. Get-Service zeigt den Dienstzustand, Get-PSSessionConfiguration die verfügbaren PowerShell-Endpunkte und Test-WSMan localhost die lokale WinRM-Antwort. Bei funktionierender Konfiguration erwarten Sie WinRM im Zustand Running, verfügbare Sitzungskonfigurationen und eine WS-Management-Antwort statt eines Fehlers. Dieser lokale Test beweist weder die Erreichbarkeit vom Client noch dessen Befehlsausführungsrechte:

Get-Service WinRM
Get-PSSessionConfiguration
Test-WSMan localhost

Konfigurieren Sie den Server nur bei Bedarf

Ist Remoting nicht eingerichtet, prüfen Sie zuerst hostname an der FS1-Konsole und führen erst danach Enable-PSRemoting aus. Der Befehl kann WinRM starten oder neu starten, Listener anlegen, Sitzungskonfigurationen aktivieren und Firewallregeln ändern. -Force unterdrückt Rückfragen, ersetzt aber keine Berechtigungen und korrigiert keinen falschen Ausführungsort. Auf einem PC, der nur Befehle sendet, ist dieser Empfangsaufbau nicht nötig.

hostname
Enable-PSRemoting -Force
Test-WSMan localhost

Begrenzen Sie den Zugriff auf den benötigten Verwaltungs-PC oder das Verwaltungsnetz. Prüfen Sie in wf.msc unter Eingehende Regeln die WinRM-Regeln, das aktive Profil, den Port und die Remoteadressen. Beachten Sie auch andere Regeln mit weiterem Geltungsbereich. Schalten Sie weder die Firewall ab noch ändern Sie willkürlich das Netzwerkprofil. Die Standardports sind TCP 5985 für HTTP und TCP 5986 für HTTPS.

Ein HTTP-Listener allein bedeutet nicht, dass authentifizierte Nachrichten ungeschützt übertragen werden. Mit Kerberos oder NTLM (NT LAN Manager) verschlüsselt WinRM die Nachrichten nach der Authentifizierung; HTTPS schützt zusätzlich den Transport und setzt eine passende Zertifikatskonfiguration und -prüfung voraus. Die Identität des Servers muss dennoch geprüft werden. Beachten Sie die WinRM-Dokumentation zu Authentifizierung und Nachrichtensicherheit.

Verwenden Sie Servernamen, wenn die Domäne eingerichtet ist

Diese Alternative setzt voraus, dass PC und FS1 derselben Domäne beigetreten sind, die Namensauflösung über das Domain Name System (DNS) und die Zeitsynchronisierung funktionieren und das Konto die nötigen Rechte besitzt. Vor der Domäneneinrichtung ist kein erfolgreicher Verbindungsaufbau zu erwarten. Enter-PSSession startet eine interaktive Sitzung. Führen Sie die Verbindung aus, warten Sie auf die Eingabeaufforderung mit dem Zielnamen und geben Sie danach hostname, whoami und Exit-PSSession einzeln ein.

Test-WSMan -ComputerName 'fs1.ad.example.test'
Enter-PSSession -ComputerName 'fs1.ad.example.test'
hostname
whoami
Exit-PSSession

Nach erfolgreicher Verbindung soll hostname FS1 und whoami die erwartete Benutzeridentität anzeigen. Exit-PSSession führt zum Verwaltungs-PC zurück. Verwenden Sie bei funktionierendem Domänen-DNS den vollständig qualifizierten Domänennamen (FQDN, Fully Qualified Domain Name). Eine IP-Adresse verwendet nicht dieselbe Kerberos-Authentifizierung wie der Servername.

Begrenzen Sie die Vertrauensliste für die Arbeitsgruppenalternative

Arbeitsgruppen- oder IP-Verbindungen brauchen zusätzliche Voraussetzungen: passend konfiguriertes HTTPS oder einen bestimmten TrustedHosts-Eintrag sowie ausdrücklich angegebene Anmeldedaten. Die Anleitung zur Fehlerbehebung bei Remoteverbindungen beschreibt diese Bedingungen. TrustedHosts unterdrückt einen Identitätsprüfungsfehler und authentifiziert nicht den Server. Ziehen Sie für den Betrieb HTTPS mit einem vertrauenswürdigen Zertifikat in Betracht und beachten Sie die Authentifizierungsrichtlinien Ihrer Organisation.

Prüfen Sie im isolierten Labor die tatsächliche IP-Adresse von FS1 an dessen Konsole. Öffnen Sie auf dem Verwaltungs-PC Windows PowerShell als Administrator und stellen Sie sicher, dass WinRM für den Zugriff auf WSMan: verfügbar ist. Das Beispiel speichert die bisherige Liste und ergänzt dieses Ziel; vorhandene Platzhalter bleiben wirksam. Prüfen Sie deshalb den Ausgangswert: TrustedHosts gilt für alle Benutzer des PCs. Ersetzen Sie die Liste nicht durch einen globalen Platzhalter.

Ersetzen Sie im folgenden Beispiel FS1\Administrator durch das tatsächlich vorgesehene Administratorkonto auf FS1 mit nicht leerem Kennwort. Get-Credential mit -UserName kann unter Windows PowerShell 5.1 zuerst den Pflichtparameter Message abfragen. Geben Sie dort eine Beschreibung der Anforderung ein, kein Kennwort; die Anmeldedaten folgen in der eigentlichen Abfrage. Starten Sie Enter-PSSession interaktiv, prüfen Sie nach dem Eintritt hostname und verlassen Sie die Sitzung mit Exit-PSSession.

$previousHosts = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
$labTargets = (@($previousHosts -split ',') + '172.24.50.20' | Where-Object { $_ } | Sort-Object -Unique) -join ','
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $labTargets
$labCredential = Get-Credential -UserName 'FS1\Administrator'
Enter-PSSession -ComputerName '172.24.50.20' -Credential $labCredential
hostname
Exit-PSSession

Selbst angelegte lokale Administratorkonten können den Remotebeschränkungen der Benutzerkontensteuerung (UAC, User Account Control) unterliegen. Prüfen Sie Authentifizierungsdesign und Rechte, statt diese Schutzmaßnahmen pauschal abzuschalten. Stellen Sie nach der Rückkehr zum Verwaltungs-PC den Ausgangswert im selben lokalen PowerShell-Fenster wieder her, in dem $previousHosts gespeichert wurde. Prüfen Sie vorher, ob spätere Änderungen anderer Personen erhalten bleiben müssen. Haben Sie das Fenster geschlossen und die Variable verloren, setzen Sie nicht voraus, dass die ursprüngliche Liste leer war:

if ([string]::IsNullOrEmpty($previousHosts)) {
    Clear-Item WSMan:\localhost\Client\TrustedHosts
} else {
    Set-Item WSMan:\localhost\Client\TrustedHosts -Value $previousHosts
}

Führen Sie eine Remoteabfrage aus und prüfen Sie deren Herkunft

Sind die Domänenvoraussetzungen erfüllt, führen Sie auf dem Verwaltungs-PC die folgende Abfrage für die Betriebssystemdaten von FS1 aus, ohne eine interaktive Konsole zu öffnen:

Invoke-Command -ComputerName 'fs1.ad.example.test' -ScriptBlock {
    Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,LastBootUpTime
}

Prüfen Sie PSComputerName und die zurückgegebenen Werte Caption, Version und LastBootUpTime, um den abgefragten Server zu bestätigen. Verwechseln Sie lokale und entfernte Ergebnisse nicht. Untersuchen Sie DNS, Porterreichbarkeit, WinRM-Antwort, Authentifizierung und Sitzungsberechtigung getrennt; eine Test-WSMan-Antwort beweist keine Befehlsausführungsrechte. Prüfen Sie vor dem Zurücknehmen von Listener- oder Dienständerungen die Abhängigkeiten anderer Werkzeuge und vergleichen Sie mit dem Ausgangszustand.