about_Remote_Troubleshooting
Letzte Aktualisierung: August 2012
Betrifft: Windows PowerShell 2.0, Windows PowerShell 3.0
THEMA
about_Remote_Troubleshooting
KURZE BESCHREIBUNG
Beschreibt die Fehlerbehebung bei Remote-Vorgängen in Windows PowerShell®.
LANGE BESCHREIBUNG
Dieser Abschnitt beschreibt einige der Probleme, die bei Verwendung der auf der WS-Management-Technologie basierenden Remoting-Funktionen von Windows PowerShell auftreten können, und bietet Lösungsvorschläge für diese Probleme.
Vor der Verwendung von Windows PowerShell-Remoting sollten Sie „about_Remote“ und „about_Remote_Requirements“ durchlesen, um eine Anleitung zur Konfiguration und grundlegenden Verwendung der Remoting-Funktionen zu erhalten. Auch die Hilfethemen für jedes der Remoting-Cmdlets und insbesondere die Parameterbeschreibungen enthalten hilfreiche Informationen, die dazu beitragen sollen, Probleme zu vermeiden.
Aktualisierte Versionen dieses Themas und anderer Windows PowerShell-Hilfethemen können mit dem Update-Help-Cmdlet heruntergeladen werden und sind online abrufbar in der Microsoft TechNet Library unter https://technet.microsoft.com/library/hh847850(v=wps.630).aspx.
HINWEIS: Zum Anzeigen oder Ändern der Einstellungen für den lokalen Computer auf dem WSMan: Laufwerk, einschließlich Änderungen an den Sitzungskonfigurationen, vertrauenswürdigen Hosts, Ports oder Listenern, starten Sie Windows PowerShell mit der Option „Als Administrator ausführen“.
FEHLERBEHEBUNG BEI BERECHTIGUNGS- UND AUTHENTIFIZIERUNGSPROBLEMEN
Dieser Abschnitt beschreibt die Remoting-Probleme, die mit Benutzer- und Computerberechtigungen und Remoting-Anforderungen verknüpft sind.
ALS ADMINISTRATOR AUSFÜHREN
ERROR: Access is denied. You need to run this cmdlet from an elevated
process.
Zum Starten einer Remote-Sitzung auf dem lokalen Computer oder zum Anzeigen oder Ändern der Einstellungen für den lokalen Computer auf dem WSMan: Laufwerk, einschließlich Änderungen an den Sitzungskonfigurationen, vertrauenswürdigen Hosts, Ports oder Listenern, starten Sie Windows PowerShell mit der Option „Als Administrator ausführen“.
So starten Sie Windows PowerShell mit der Option „Als Administrator ausführen“:
– Klicken Sie mit der rechten Maustaste auf ein Windows PowerShell-Symbol (oder Windows PowerShell ISE-Symbol) und klicken Sie dann auf „Als Administrator ausführen“.
So starten Sie Windows PowerShell mit der Option „Als Administrator ausführen“ in Windows 7 und Windows Server 2008 R2:
– Klicken Sie in der Windows-Taskleiste mit der rechten Maustaste auf das Windows PowerShell-Symbol, und klicken Sie dann auf „Als Administrator ausführen“.
Hinweis: In Windows Server 2008 R2 ist das Windows PowerShell-Symbol standardmäßig an die Taskleiste angeheftet.
AKTIVIEREN VON REMOTING
ERROR: ACCESS IS DENIED
- or -
ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.
Um einen Computer in die Lage zu versetzen, Remote-Befehle zu senden, ist keine Konfiguration erforderlich. Um jedoch Remote-Befehle empfangen zu können, muss das Windows PowerShell-Remoting auf dem Computer aktiviert sein. Die Aktivierung umfasst das Starten des WinRM-Diensts, das Festlegen des Starttyps für den WinRM-Dienst auf „Automatisch“, das Erstellen von Listenern für HTTP- und HTTPS-Verbindungen und das Erstellen von Standard-Sitzungskonfigurationen.
Das Windows PowerShell-Remoting ist auf Windows Server 2012 und neueren Versionen von Windows Server standardmäßig aktiviert. Führen Sie bei allen anderen Systemen das Enable-PSRemoting-Cmdlet aus, um das Remoting zu aktivieren. Sie können auch das Enable-PSRemoting-Cmdlet ausführen, um das Remoting in Windows Server 2012 und neueren Versionen von Windows Server erneut zu aktivieren, wenn das Remoting deaktiviert wurde.
Um einen Computer zum Empfangen von Remote-Befehle zu konfigurieren, verwenden Sie das Enable-PSRemoting-Cmdlet. Der folgende Befehl aktiviert alle erforderliche Remote-Einstellungen, aktiviert die Sitzungskonfigurationen und führt einen Neustart des WinRM-Diensts durch, damit die Änderungen wirksam werden.
Enable-PSRemoting
Um alle Benutzereingaben zu unterdrücken, geben Sie Folgendes ein:
Enable-PSRemoting -Force
Weitere Informationen finden Sie unter „Enable-PSRemoting“.
AKTIVIEREN VON REMOTING IN EINEM UNTERNEHMEN
ERROR: ACCESS IS DENIED
- or -
ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.
Um das Empfangen von Windows PowerShell-Remote-Befehlen und das Akzeptieren von Verbindungen für einen einzelnen Computer zu aktivieren, verwenden Sie das Enable-PSRemoting-Cmdlet.
Um das Remoting für mehrere Computer in einem Unternehmen zu aktivieren, können Sie die folgenden abgestuften Optionen verwenden.
– Um Listener für das Remoting zu konfigurieren, aktivieren Sie die Gruppenrichtlinie „Automatische Konfiguration von Listenern zulassen“. Eine Anleitung finden Sie unter „Aktivieren von Listenern mithilfe einer Gruppenrichtlinie“ (siehe unten).
– Um den Starttyp von Windows-Remoteverwaltung (WinRM) auf mehreren Computern auf „Automatisch“ zu setzen, verwenden Sie das Set-Service-Cmdlet. Eine Anleitung finden Sie unter „Festlegen des Starttyps des WinRM-Diensts“ (siehe unten).
– Um eine Firewall-Ausnahme zu aktivieren, verwenden Sie die Gruppenrichtlinie „Windows-Firewall: Lokale Port-Ausnahmen zulassen“. Eine Anleitung finden Sie unter „Erstellen einer Firewall-Ausnahme mithilfe einer Gruppenrichtlinie“ (siehe unten).
AKTIVIEREN VON LISTENERN MITHILFE EINER GRUPPENRICHTLINIE
ERROR: ACCESS IS DENIED
- or -
ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.
Um die Listener für alle Computer in einer Domäne zu konfigurieren, aktivieren Sie die Richtlinie „Automatische Konfiguration von Listenern zulassen" unter dem folgenden Pfad der Gruppenrichtlinien:
Computer Configuration\Administrative Templates\Windows Components
\Windows Remote Management (WinRM)\WinRM service
Aktivieren Sie die Richtlinie, und geben Sie die IPv4- und IPv6-Filter an. Platzhalter (*) sind zulässig.
AKTIVIEREN VON REMOTING ÜBER ÖFFENTLICHE NETZWERKE
ERROR: Unable to check the status of the firewall
Das Enable-PSRemoting-Cmdlet gibt diesen Fehler zurück, wenn das lokale Netzwerk öffentlich ist und der SkipNetworkProfileCheck-Parameter im Befehl nicht verwendet wird.
Auf Serverversionen von Windows funktioniert Enable-PSRemoting bei allen Typen von Netzwerkspeicherorten. Es erstellt Firewall-Regeln, mit denen der Remote-Zugriff auf private und Domänennetzwerken („Home“ und „Arbeit“) ermöglicht wird. Für öffentliche Netzwerke erstellt es Firewall-Regeln, die den Remote-Zugriff aus dem gleichen lokalen Subnetz ermöglichen.
Auf Clientversionen von Windows funktioniert Enable-PSRemoting in privaten und Domänennetzwerken. Standardmäßig schlägt das Cmdlet bei öffentlichen Netzwerken fehl, aber wenn Sie den SkipNetworkProfileCheck-Parameter verwenden, ist Enable-PSRemoting erfolgreich und erstellt eine Firewall-Regel, die den Datenverkehr aus dem gleichen lokalen Subnetz zulässt.
Zum Entfernen der Einschränkung auf das lokale Subnetz in öffentlichen Netzwerken und zum Zulassen des Remote-Zugriffs von jedem Standort aus führen Sie den folgenden Befehl aus:
Set-NetFirewallRule –Name "WINRM-HTTP-In-TCP-PUBLIC" –RemoteAddress Any
Das Set-NetFirewallRule-Cmdlet wird vom NetSecurity-Modul exportiert.
HINWEIS: In Windows PowerShell 2.0 erfolgt durch Enable-PSRemoting auf Computern, auf denen Windows Serverversionen ausgeführt werden, die Erstellung von Firewall-Regeln, die den Remote-Zugriff in privaten, Domänen- und öffentlichen Netzwerken ermöglichen. Auf Computern, auf denen Clientversionen von Windows ausgeführt werden, erstellt Enable-PSRemoting Firewall-Regeln, die den Remote-Zugriff nur in privaten und Domänennetzwerken ermöglichen.
AKTIVIEREN EINER FIREWALL-AUSNAHME MITHILFE EINER GRUPPENRICHTLINIE
ERROR: ACCESS IS DENIED
- or -
ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.
Um eine Firewall-Ausnahme für alle Computer in einer Domäne zu aktivieren, aktivieren Sie die Richtlinie „Windows-Firewall: Ausnahmen für lokale Ports zulassen“ unter dem folgenden Pfad der Gruppenrichtlinien:
Computer Configuration\Administrative Templates\Network
\Network Connections\Windows Firewall\Domain Profile
Diese Richtlinie ermöglicht Mitgliedern der Gruppe „Administratoren“ auf dem Computer, mit der Windows-Firewall in der Systemsteuerung eine Firewall-Ausnahme für den Dienst Windows-Remoteverwaltung zu erstellen.
FESTLEGEN DES STARTTYPS DES WINRM-DIENSTS
ERROR: ACCESS IS DENIED
Das Windows PowerShell-Remoting hängt vom Dienst Windows-Remoteverwaltung (WinRM) ab. Der Dienst muss ausgeführt werden, damit Remote-Befehle unterstützt werden.
In Serverversionen von Windows hat der Dienst Windows Remoteverwaltung (WinRM) den Starttyp „Automatisch“.
Allerdings ist der WinRM-Dienst auf Clientversionen von Windows standardmäßig deaktiviert.
Verwenden Sie das Set-Service-Cmdlet, um den Starttyp eines Dienstes auf einem Remotecomputer festzulegen.
Um den Befehl auf mehreren Computern auszuführen, können Sie eine Textdatei oder eine CSV-Datei der Computernamen erstellen.
Beispielsweise wird mit dem folgenden Befehle eine Liste mit Computernamen aus der Datei „Servers.txt“ abgerufen und anschließend der Starttyp des WinRM-Diensts auf all diesen Computern auf „Automatisch“ festgelegt.
C:\PS> $servers = Get-Content servers.txt
C:\PS> Set-Service WinRM -ComputerName $servers -startuptype Automatic
Zum Anzeigen der Ergebnisse verwenden Sie das Get-WMIObject-Cmdlet mit dem Win32_Service-Objekt. Weitere Informationen finden Sie unter „Set-Service“.
ERNEUTES ERSTELLEN DER STANDARD-SITUNGSKONFIGURATIONEN
ERROR: ACCESS IS DENIED
Zum Herstellen einer Verbindung mit dem lokalen Computer und zum Ausführen von Remote-Befehlen muss der lokale Computer Sitzungskonfigurationen für Remote-Befehle enthalten.
Wenn Sie Enable-PSRemoting verwenden, erstellt es Standard-Sitzungskonfigurationen auf dem lokalen Computer. Remote-Benutzer verwenden diese Sitzungskonfigurationen immer dann, wenn ein Remote-Befehl nicht den ConfigurationName-Parameter enthält.
Wenn die Standardkonfigurationen auf einem Computer nicht registriert oder gelöscht wurden, verwenden Sie das Enable-PSRemoting-Cmdlet, um sie erneut zu erstellen. Sie können dieses Cmdlet wiederholt verwenden. Es generiert keine Fehler, wenn ein Feature bereits konfiguriert wurde.
Wenn Sie die Standardkonfigurationen für die Sitzung ändern und die ursprünglichen Standard-Sitzungskonfigurationen wiederherstellen möchten, verwenden Sie das Unregister-PSSessionConfiguration-Cmdlet zum Löschen der geänderten Sitzungskonfigurationen und dann das Enable-PSRemoting-Cmdlet, um sie wiederherzustellen. Enable-PSRemoting bewirkt keine Änderung an vorhandenen Sitzungskonfigurationen.
Hinweis: Wenn Enable-PSRemoting die Standard-Sitzungskonfiguration wiederherstellt, werden keine expliziten Sicherheitsdeskriptoren für die Konfigurationen erstellt. Stattdessen erben die Konfigurationen die Sicherheitsdeskriptoren von RootSDDL, das standardmäßig sicher ist.
Um den Sicherheitsdeskriptor von RootSDDL anzuzeigen, geben Sie Folgendes ein:
Get-Item wsman:\localhost\Service\RootSDDL
Um RootSDDL zu ändern, verwenden Sie das Set-Item-Cmdlet auf dem WS-Man: Laufwerk. Um den Sicherheitsdeskriptor einer Sitzungskonfiguration zu ändern, verwenden Sie das Set-PSSessionConfiguration-Cmdlet mit dem Parameter „SecurityDescriptorSDDL“ oder „ShowSecurityDescriptorUI“.
Weitere Informationen zum WS-Man: Laufwerk finden Sie im Hilfethema für den WSMan-Anbieter („Get-Help Wsman“).
ANGEBEN DER ADMINISTRATOR-ANMELDEINFORMATIONEN
ERROR: ACCESS IS DENIED
Um eine PSSession zu erstellen oder Befehle auf einem Remote-Computer auszuführen, muss der aktuelle Benutzer standardmäßig Mitglied der Gruppe „Administratoren“ auf dem Remote-Computer sein. Manchmal sind Anmeldeinformationen erforderlich, selbst wenn der aktuelle Benutzer mit einem Konto angemeldet ist, das Mitglied der Gruppe „Administratoren“ ist.
Wenn der aktuelle Benutzer auf dem Remote-Computer Mitglied der Gruppe „Administratoren“ ist oder die Anmeldeinformationen eines Mitglieds der Gruppe „Administratoren“ angeben kann, verwenden Sie den Credential-Parameter der Cmdlets New-PSSession, Enter-PSSession oder Invoke-Command für die Remote-Verbindung.
Der folgende Befehl gibt z. B. die Anmeldeinformationen eines Administrators an.
Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01
Weitere Informationen zum Credential-Parameter finden Sie unter „New-PSSession“, „Enter-PSSession“ oder „Invoke-Command“.
AKTIVIEREN VON REMOTING FÜR BENUTZER OHNE ADMINISTRATORRECHTE
ERROR: ACCESS IS DENIED
Um eine PSSession herzustellen oder einen Befehl auf einem Remote-Computer auszuführen, muss der Benutzer über die Berechtigung zum Verwenden der Sitzungskonfigurationen auf dem Remote-Computer verfügen.
Standardmäßig sind nur Mitglieder der Gruppe „Administratoren“ auf einem Computer berechtigt, die die Standard-Sitzungskonfigurationen zu verwenden. Daher können nur Mitglieder der Gruppe „Administratoren“ auf dem Computer eine Remote-Verbindung herstellen.
Um anderen Benutzern die Verbindung mit dem lokalen Computer zu ermöglichen, erteilen Sie dem Benutzer Ausführungsberechtigungen für die Standard-Sitzungskonfigurationen auf dem lokalen Computer.
Der folgende Befehl öffnet eine Eigenschaftenseite, auf der Sie den Sicherheitsdeskriptor für die standardmäßige Microsoft.PowerShell-Sitzungskonfiguration auf dem lokalen Computer ändern können.
Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI
Weitere Informationen finden Sie unter „about_Session_Configurations“.
AKTIVIEREN VON REMOTING FÜR ADMINISTRATOREN IN ANDEREN DOMÄNEN
ERROR: ACCESS IS DENIED
Wenn ein Benutzer in einer anderen Domäne Mitglied der Gruppe „Administratoren“ auf dem lokalen Computer ist, kann dieser Benutzer mit Administratorberechtigungen keine Remote-Verbindung zum lokalen Computer herstellen. Standardmäßig werden Remote-Verbindungen aus anderen Domänen nur mit Standardbenutzer-Berechtigungstoken aufgebaut.
Allerdings können Sie mit dem Registrierungseintrag „LocalAccountTokenFilterPolicy“ das Standardverhalten ändern und Remote-Benutzern, die Mitglieder der Gruppe „Administratoren“ sind, die Ausführung mit Administratorrechten erlauben.
Vorsicht: Der Eintrag „LocalAccountTokenFilterPolicy“ deaktiviert die Remote-Einschränkungen der Benutzerkontensteuerung (UAC) für alle Benutzer von allen betroffenen Computern. Überlegen Sie sorgfältig, welche Auswirkungen diese hat, bevor Sie die Richtlinie ändern.
Um die Richtlinie zu ändern, verwenden Sie folgenden Befehl, um den Wert des Registrierungseintrags „LocalAccountTokenFilterPolicy“ auf 1 festzulegen.
C:\PS> New-ItemProperty -Name LocalAccountTokenFilterPolicy -Path `
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -PropertyType `
DWord -Value 1
VERWENDEN EINER IP-ADRESSE IN EINEM REMOTE-BEFEHL
ERROR: The WinRM client cannot process the request. If the
authentication scheme is different from Kerberos, or if the client
computer is not joined to a domain, then HTTPS transport must be used
or the destination machine must be added to the TrustedHosts
configuration setting.
Der ComputerName-Parameter de New-PSSession-, Enter-PSSession- und Invoke-Command-Cmdlets akzeptiert eine IP-Adresse als gültigen Wert. Da jedoch IP-Adressen von Kerberos-Authentifizierung nicht unterstützt werden, wird standardmäßig die NTLM-Authentifizierung verwendet, wenn Sie eine IP-Adresse angeben.
Bei Verwendung der NTLM-Authentifizierung ist das folgende Verfahren für das Remoting erforderlich.
1. Konfigurieren Sie den Computer für den HTTPS-Transport, oder fügen Sie die IP-Adressen der Remote-Computer zur TrustedHosts-Liste auf dem lokalen Computer hinzu.
Eine Anleitung finden Sie unter „Hinzufügen eines Computers zur TrustedHosts-Liste“ (siehe unten).
2. Verwenden Sie den Credential-Parameter in allen Remote-Befehlen.
Dies ist erforderlich, selbst wenn Sie die Anmeldeinformationen des aktuellen Benutzers senden.
HERSTELLEN EINER REMOTE-VERBINDUNG VON EINEM ARBEITSGRUPPEN-BASIERTEN COMPUTER
ERROR: The WinRM client cannot process the request. If the
authentication scheme is different from Kerberos, or if the client
computer is not joined to a domain, then HTTPS transport must be used
or the destination machine must be added to the TrustedHosts
configuration setting.
Wenn sich der lokale Computer nicht in einer Domäne befindet, ist das folgende Verfahren für das Remoting erforderlich.
1. Konfigurieren Sie den Computer für den HTTPS-Transport, oder fügen Sie die Namen der Remote-Computer zur TrustedHosts-Liste auf dem lokalen Computer hinzu.
Eine Anleitung finden Sie unter „Hinzufügen eines Computers zur TrustedHosts-Liste“ (siehe unten).
2. Stellen Sie sicher, dass auf dem arbeitsgruppenbasierten Computer ein Kennwort eingerichtet ist. Wenn kein Kennwort eingerichtet ist oder der Kennwortwert leer ist, können Sie keine Remote-Befehle ausführen.
Um das Kennwort für Ihr Benutzerkonto festzulegen, verwenden Sie „Benutzerkonten“ in der Systemsteuerung.
3. Verwenden Sie den Credential-Parameter in allen Remote-Befehlen.
Dies ist erforderlich, selbst wenn Sie die Anmeldeinformationen des aktuellen Benutzers senden.
HINZUFÜGEN EINES COMPUTERS ZUR LISTE DER VERTRAUENSWÜRDIGEN HOSTS
Das TrustedHosts-Element kann eine durch Kommas getrennte Liste von Computernamen, IP-Adressen und vollqualifizierten Domänennamen enthalten. Platzhalter sind zulässig.
Verwenden Sie zum Anzeigen oder Ändern der Liste der vertrauenswürdigen Hosts das WSMan: Laufwerk. Das TrustedHost-Element befindet sich am WSMan:\localhost\Client-Knoten.
Nur Mitglieder der Gruppe „Administratoren“ auf dem Computer verfügen über die Berechtigung zum Ändern der Liste der vertrauenswürdigen Hosts auf dem Computer.
Vorsicht: Der für das TrustedHosts-Element festgelegte Wert wirkt sich auf alle Benutzer des Computers aus.
Um die Liste der vertrauenswürdigen Hosts anzuzeigen, verwenden Sie den folgenden Befehl:
Get-Item wsman:\localhost\Client\TrustedHosts
Sie können auch das Set-Location-Cmdlet (alias = cd) verwenden, um auf dem WSMan: Laufwerk zum Speicherort zu navigieren. Beispiel: „cd WSMan:\localhost\Client; Dir“.
Um alle Computer zur Liste der vertrauenswürdigen Hosts hinzuzufügen, verwenden Sie den folgenden Befehl, der den Wert * (alle) in ComputerName platziert.
Set-Item wsman:localhost\client\trustedhosts -Value *
Sie können auch ein Platzhalterzeichen (*) verwenden, um alle Computer in einer bestimmten Domäne zur Liste der vertrauenswürdigen Hosts hinzuzufügen. Beispielsweise fügt der folgende Befehl alle Computer in der Fabrikam-Domäne zur Liste der vertrauenswürdigen Hosts hinzu.
Set-Item wsman:localhost\client\trustedhosts *.fabrikam.com
Um die Namen von bestimmten Computern zur Liste vertrauenswürdiger Hosts hinzuzufügen, verwenden Sie das folgende Befehlsformat:
Set-Item wsman:\localhost\Client\TrustedHosts -Value <ComputerName>[,<ComputerName>]
wobei jeder Wert <ComputerName> das folgende Format aufweisen muss:
<Computer>.<Domain>.<Company>.<top-level-domain>
Beispiel:
Set-Item wsman:\localhost\Client\TrustedHosts -Value Server01.Domain01.Fabrikam.com
Um einen Computernamen zu einer vorhandenen Liste vertrauenswürdiger Hosts hinzuzufügen, speichern Sie zuerst den aktuellen Wert in einer Variablen und legen dann den Wert auf eine durch Kommas getrennte Liste fest, die die aktuellen und neuen Werte enthält.
Um z. B. den Server01-Computer zu einer vorhandenen Liste vertrauenswürdiger Hosts hinzuzufügen, verwenden Sie folgenden Befehl:
$curValue = (Get-Item wsman:\localhost\Client\TrustedHosts).value
Set-Item wsman:\localhost\Client\TrustedHosts -Value "$curValue, Server01.Domain01.Fabrikam.com"
Um die IP-Adressen von bestimmten Computern zur Liste vertrauenswürdiger Hosts hinzuzufügen, verwenden Sie das folgende Befehlsformat:
Set-Item wsman:\localhost\Client\TrustedHosts -Value <IP Address>
Beispiel:
Set-Item wsman:\localhost\Client\TrustedHosts -Value 172.16.0.0
Um einen Computer zur TrustedHosts-Liste eines Remote-Computers hinzuzufügen, verwenden Sie das Connect-WSMan-Cmdlet zum Hinzufügen eines Knotens für den Remote-Computer zum WSMan: Laufwerk auf dem lokalen Computer. Verwenden Sie dann einen Set-Item-Befehl, um den Computer hinzufügen.
Weitere Informationen zum Connect-WSMan-Cmdlet finden Sie unter „Connect-WSMan“.
FEHLERBEHEBUNG BEI COMPUTER-KONFIGURATIONSPROBLEMEN
Dieser Abschnitt beschreibt die Remoting-Probleme, die im Zusammenhang mit bestimmten Konfigurationen eines Computers, der Domäne oder des Unternehmens stehen.
KONFIGURIEREN VON REMOTING AUF ALTERNATIVEN PORTS – UNTERTHEMA
ERROR: The connection to the specified remote host was refused. Verify
that the WS-Management service is running on the remote host and
configured to listen for requests on the correct port and HTTP URL.
Das Windows PowerShell-Remoting verwendet standardmäßig Port 80 für den HTTP-Transport. Der Standard-Port wird immer dann verwendet, wenn der Benutzer in einem Remote-Befehl die ConnectionURI- oder Port-Parameter nicht angegeben hat.
Zum Ändern des von Windows PowerShell verwendeten Standard-Ports verwenden Sie das Set-Item-Cmdlet auf dem WSMan: Laufwerk, um den Port-Wert im Listener-Blattknoten zu ändern.
Beispielsweise ändert der folgende Befehl den Standard-Port auf 8080.
Set-Item wsman:\localhost\listener\listener*\port -Value 8080
KONFIGURIEREN VON REMOTING MIT EINEM PROXYSERVER
ERROR: The client cannot connect to the destination specified in the
request. Verify that the service on the destination is running and is
accepting requests.
Da das Windows PowerShell-Remoting das HTTP-Protokoll verwendet, wird es durch die HTTP-Proxyeinstellungen beeinflusst. In Unternehmen, die über Proxy-Server verfügen, können Benutzer nicht direkt auf einen Windows PowerShell-Remote-Computer zugreifen.
Um dieses Problem zu beheben, verwenden Sie die Proxy-Einstelloptionen in Ihrem Remote-Befehl. Die folgenden Einstellungen sind verfügbar:
– ProxyAccessType
– ProxyAuthentication
– ProxyCredential
Gehen Sie zum Festlegen dieser Optionen für einen bestimmten Befehl wie folgt vor:
1. Verwenden Sie die ProxyAccessType-, ProxyAuthentication- und ProxyCredential-Parameter des New-PSSessionOption-Cmdlets, um ein Sitzungsoptionsobjekt mit den Proxyeinstellungen für Ihr Unternehmen zu erstellen. Speichern Sie die Optionsobjekt in einer Variablen.
2. Verwenden Sie die Variable, die das Optionsobjekt enthält, als den Wert des SessionOption-Parameters eines New-PSSession-, Enter-PSSession- oder Invoke-Command-Befehls.
Beispielsweise erstellt der folgende Befehl ein Sitzungsoptionsobjekt mit Proxy-Sitzungsoptionen und verwendet dann das Objekt, um eine Remote-Sitzung zu erstellen.
C:\PS> $SessionOption = New-PSSessionOption -ProxyAccessType IEConfig `
-ProxyAuthentication Negotiate -ProxyCredential Domain01\User01
C:\PS> New-PSSession -ConnectionURI https://www.fabrikam.com
Weitere Informationen über das New-PSSessionOption-Cmdlet finden Sie hier im Abschnitt „New-PSSessionOption“.Abschnittstext hier einfügen.
Verwenden Sie zum Festlegen dieser Optionen für alle Remote-Befehle in der aktuellen Sitzung das von New-PSSessionOption erstellte Optionsobjekt als Wert der $PSSessionOption-Voreinstellungsvariablen. Weitere Informationen zur $PSSessionOption-Voreinstellungsvariablen finden Sie unter „about_Preference_Variables“.
Zum Festlegen dieser Optionen für alle Remote-Befehle aller Windows PowerShell Sitzungen auf dem lokalen Computer fügen Sie die $PSSessionOption-Voreinstellungsvariable zu Ihren Windows PowerShell-Profil hinzu. Weitere Informationen zu Windows PowerShell-Profilen finden Sie unter „about_Profiles“.
ERKENNEN EINER 32-BIT-SITZUNG AUF EINEM 64-BIT-COMPUTER
ERROR: The term "<tool-Name>" is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the
name, or if a path was included, verify that the path is correct and try
again.
Wenn auf dem Remote-Computer eine 64-Bit-Version von Windows ausgeführt wird und der Remote-Befehl eine 32-Bit-Sitzungskonfiguration verwendet, wie z. B. Microsoft.PowerShell32, lädt Windows-Remoteverwaltung (WinRM) einen WOW64-Prozess, und Windows leitet alle Verweise auf das %Windir%\System32-Verzeichnis automatisch in das %windir%\SysWOW64-Verzeichnis weiter.
Wenn Sie versuchen, die Tools im System32-Verzeichnis zu verwenden, die keine Entsprechungen im SysWow64-Verzeichnis haben, wie z. B. Defrag.exe, können die Tools daher im Verzeichnis nicht gefunden werden.
Um die Prozessorarchitektur zu suchen, die in der Sitzung verwendet wird, verwenden Sie den Wert der PROCESSOR_ARCHITECTURE-Umgebungsvariablen. Der folgende Befehl sucht die Prozessorarchitektur der Sitzung in der $s-Variablen.
C:\PS> $s = New-PSSession -ComputerName Server01 -configurationName CustomShell
C:\PS> invoke-command -session $s {$env:PROCESSOR_ARCHITECTURE}
x86
Weitere Informationen zu Sitzungskonfigurationen finden Sie unter „about_Session_Configurations“.
FEHLERBEHEBUNG BEI RICHTLINIEN- UND EINSTELLUNGSPROBLEMEN
Dieser Abschnitt beschreibt die Remoting-Probleme, im Zusammenhang mit Richtlinien und Einstellungen auf den lokalen Computern und Remote-Computern beziehen.
ÄNDERN DER AUSFÜHRUNGSRICHTLINIE FÜR IMPORT-PSSESSION UND IMPORT-MODULE
ERROR: Import-Module: File <filename> cannot be loaded because the
execution of scripts is disabled on this system.
Die Import-PSSession- und Export-PSSession-Cmdlets erstellen Module, die unsignierte Skriptdateien und Formatierungsdateien enthalten.
Um die von diesen Cmdlets erstellten Module zu importieren – entweder mithilfe von Import-PSSession oder von Import-Module –, darf die Ausführungsrichtlinie in der aktuellen Sitzung nicht „Restricted“ oder „AllSigned“ sein. (Informationen zu den Windows PowerShell-Ausführungsrichtlinien finden Sie unter „about_Execution_Policies“.
Verwenden Sie zum Importieren der Module, ohne die in der Registrierung festgelegte Ausführungsrichtlinie für den lokalen Computer zu ändern, den Scope-Parameter von Set-ExecutionPolicy, um eine weniger einschränkende Ausführungsrichtlinie für einen einzelnen Prozess festzulegen.
Der folgende Befehl startet z. B. einen Prozess mit der RemoteSigned-Ausführungsrichtlinie. Die Änderung der Ausführungsrichtlinie wirkt sich nur auf den aktuellen Prozess aus und ändert nicht die Windows PowerShell-ExecutionPolicy Einstellung in der Registrierung.
Set-ExecutionPolicy -Scope process -ExecutionPolicy RemoteSigned
Sie können auch den ExecutionPolicy-Parameter von PowerShell.exe verwenden, um eine einzelne Sitzung mit einer weniger restriktiven Ausführungsrichtlinie zu starten.
PowerShell.exe -ExecutionPolicy RemoteSigned
Weitere Informationen zu den Cmdlets finden Sie unter „Import-PSSession“, „Export-PSSession“ und „Import-Module“. Weitere Informationen zu den Ausführungsrichtlinien finden Sie unter „about_Execution_Policies“. Weitere Informationen zu den Hilfeoptionen der PowerShell.exe-Konsole erhalten Sie, wenn Sie „PowerShell.exe-?“ eingeben.
FESTLEGEN UND ÄNDERN VON KONTINGENTEN
ERROR: The total data received from the remote client exceeded allowed
maximum.
Sie können Kontingente verwenden, um den lokalen Computer und den Remote-Computer vor übermäßiger Ressourcenverwendung zu schützen, die sowohl versehentlich als auch böswillig erfolgen kann.
Die folgenden Kontingente sind in der Basiskonfiguration verfügbar.
– Der WSMan-Anbieter (WSMan:) bietet mehrere Kontingenteinstellungen, wie z. B. die Einstellungen für MaxEnvelopeSizeKB und MaxProviderRequests im WSMan: \<ComputerName>-Knoten und die MaxConcurrentOperations-, MaxConcurrentOperationsPerUser- und MaxConnections-Einstellungen im WSMan: \<ComputerName>\Service-Knoten.
– Sie können den lokalen Computer schützen, indem Sie die Parameter „MaximumReceivedDataSizePerCommand“ und „MaximumReceivedObjectSize“ der $PSSessionOption-Voreinstellungsvariablen und des New-PSSessionOption-Cmdlets verwenden.
– Sie können den Remote-Computer durch Hinzufügen von Einschränkungen zu den Sitzungskonfigurationen schützen, z. B. mithilfe der Parameter „MaximumReceivedDataSizePerCommandMB“ und „MaximumReceivedObjectSizeMB“ des Register-PSSessionConfiguration-Cmdlets.
Wenn Kontingente im Konflikt mit einem Befehl stehen, generiert Windows PowerShell einen Fehler.
Ändern Sie zum Beheben des Fehlers den Remote-Befehl, um dem Kontingent zu entsprechen. Oder bestimmen Sie die Quelle des Kontingents, und erhöhen Sie dann das Kontingent, um den Abschluss des Befehls zu ermöglichen.
So erhöht z. B. der folgende Befehl die Kontingentgröße des Objekts in der Microsoft.PowerShell-Sitzungskonfiguration auf dem Remote-Computer von 10 MB (Standardwert) auf 11 MB.
Set-PSSessionConfiguration -Name microsoft.PowerShell `
-MaximumReceivedObjectSizeMB 11 -Force
Weitere Informationen über das New-PSSessionOption-Cmdlet finden Sie unter „New-PSSessionOption“.
Weitere Informationen zu den WS-Management-Kontingenten finden Sie im Hilfethema für den WSMan-Anbieter (Eingabe von „Get-Help WSMan“).
BEHEBEN VON TIMEOUT-FEHLERN
ERROR: The WS-Management service cannot complete the operation within
the time specified in OperationTimeout.
Sie können Timeouts verwenden, um den lokalen Computer und den Remote-Computer vor übermäßiger Ressourcenverwendung zu schützen, die sowohl versehentlich als auch böswillig erfolgen kann. Wenn auf dem lokalen und Remote-Computer Timeouts festgelegt sind, verwendet Windows PowerShell die kürzesten Timeout-Einstellungen.
Die folgenden Timeouts sind in der Basiskonfiguration verfügbar.
– Der WSMan-Anbieter (WSMan:) bietet mehrere client- und serviceseitige Timeout-Einstellungen, wie z. B. die MaxTimeoutms-Einstellung im WSMan: \<ComputerName>-Knoten und die EnumerationTimeoutms- und MaxPacketRetrievalTimeSeconds-Einstellungen im WSMan: \<ComputerName>\Service-Knoten.
– Sie können den lokalen Computer schützen, indem Sie die Parameter „CancelTimeout“, „IdleTimeout“, „OpenTimeout“ und „OperationTimeout“ des New-PSSessionOption-Cmdlets und der Voreinstellungsvariablen „$PSSessionOption“ verwenden.
– Sie können den Remote-Computer auch schützen, indem Sie die Timeout-Werte in der Sitzungskonfiguration für die Sitzung programmgesteuert festlegen.
Wenn ein Timeout-Wert den Abschluss eines Vorgang nicht zulässt, beendet Windows PowerShell den Vorgang und generiert einen Fehler.
Um den Fehler zu beheben, ändern Sie den Befehl so, dass er innerhalb des Timeout-Intervalls abgeschlossen wird, oder ermitteln Sie die Quelle des Timeout-Limits, und erhöhen Sie das Timeout-Intervall, um das Abschließen des Befehls zu ermöglichen.
Die folgenden Befehle verwenden z. B. das New-PSSessionOption-Cmdlet, um ein Sitzungsoptionsobjekt mit einem OperationTimeout-Wert von 4 Minuten (in Millisekunden) zu erstellen, und verwenden dann das Sitzungsoptionsobjekt, um eine Remote-Sitzung zu erstellen.
C:\PS> $pso = New-PSSessionoption -OperationTimeout 240000
C:\PS> New-PSSession -ComputerName Server01 -sessionOption $pso
Weitere Informationen zu den WS-Management-Timeouts finden Sie im Hilfethema für den WSMan-Anbieter (Eingabe von „Get-Help WSMan“).
Weitere Informationen über das New-PSSessionOption-Cmdlet finden Sie unter „New-PSSessionOption“.
FEHLERBEHEBUNG BEI NICHT REAGIERENDEM VERHALTEN
In diesem Abschnitt werden Remoting-Probleme erläutert, die das Abschließen eines Befehls verhindern oder die Rückgabe der Windows PowerShell-Aufforderung verzögern.
UNTERBRECHEN EINES BEFEHLS
Einige systemeigene Windows-Programme, wie z. B. Programme mit einer Benutzeroberfläche, Konsolenanwendungen, die zu einer Eingabe auffordern, und Konsolenanwendungen, die die Win32-API-Konsole verwenden, funktionieren nicht ordnungsgemäß im Windows PowerShell-Remote-Host.
Wenn Sie diese Programme verwenden, stellen Sie möglicherweise ein unerwartetes Verhalten fest, z. B. keine Ausgabe, teilweise Ausgabe oder das Nichtabschließen eines Befehls.
Um eine nicht reagierende Anwendung zu beenden, geben Sie STRG+C ein. Um alle Fehler anzuzeigen, die möglicherweise gemeldet wurden, geben Sie „$error“ in der lokalen Host- und der Remote-Sitzung ein.
WIEDERHERSTELLEN BEIM AUSFALL EINES VORGANGS
ERROR: The I/O operation has been aborted because of either a thread exit
or an application request.
Dieser Fehler wird zurückgegeben, wenn ein Vorgang beendet wird, bevor er abgeschlossen wurde. In der Regel tritt er auf, wenn der WinRM-Dienst beendet oder neu gestartet wird, während andere WinRM-Vorgänge ausgeführt werden.
Um dieses Problem zu beheben, stellen Sie sicher, dass der WinRM-Dienst ausgeführt wird, und führen Sie den Befehl erneut aus.
1. Starten Sie Windows PowerShell mit der Option „Als Administrator ausführen“.
2. Führen Sie den folgenden Befehl aus:
Start-Service WinRM3. Führen Sie den Befehl erneut aus, der den Fehler generiert hat.
SIEHE AUCH
Online-Version: https://technet.microsoft.com/library/hh847850(v=wps.630).aspx
about_Remote
about_Remote_Requirements
about_Remote_Variables