Powershell-remoting-Fehler - Netzwerk-Pfad nicht gefunden
Ich kann keine Verbindung zu remote-server mit enter-pssession -computername serverA. Mein Szenario:
- Ich habe 2 Win 2003 R2 Server in der gleichen Domäne. ServerA ist der WSUS-server ist Server B, eine domain-controller
- Beiden Servern aktiviert haben, powershell-remoting
- Beide Server so konfiguriert haben, dass winrm (
winrm quickconfig) - Beide Server haben TrustedHosts zu *
- setspn.exe richtig eingerichtet ist (http, https, wsman etc.)
- Bei beiden Servern die FireWall deaktiviert
- Beide Server über PowerShell 2.0
Ich versuche enter-pssession -computername serverA unter dem domain-admin-Anmeldeinformationen von serverA serverB und es wirft die folgende Fehlermeldung:
"""Enter-PSSession : Verbindung zum remote-server konnte nicht mit der folgenden Fehlermeldung : der WinRM kann die Anforderung nicht verarbeiten. Der folgende Fehler ist aufgetreten während der Verwendung der Kerberos-Authentifizierung: Der Netzwerkpfad wurde nicht gefunden."""
Wenn ich versuche enter-pssession -computername serverB unter dem domain-admin-Anmeldeinformationen von serverA funktioniert es einwandfrei! Es funktioniert auch, wenn ich mit localhost so: enter-pssession -computername localhost unter dem domain-admin-Anmeldeinformationen (auf serverA) als gut funktioniert, aber wenn ich versuche den Hostnamen auf serverA (statt localhost) enter-pssession -computername serverA es wirft den gleichen Fehler.
Ich habe auch versucht zu verwenden get-credential und stellen verschiedene Typen von Anmeldeinformationen, aber es hat nicht geholfen. Das einzige, was half, war mit einem lokalen (nicht Domänen -) administrator-Konto und läuft enter-pssession -computername serverA -credentials $cred und es hat funktioniert, aber nur lokal, ich war in der Lage, dies zu tun von der lokalen Maschine (von serverA zu sich selbst) aber nicht von serverA serverB unter serverA\administrator-Anmeldeinformationen.
Irgendwelche Ideen?
Dank
- Wenn meine Antwort unten nicht der Fall zu sein scheint, versuchen Sie, hinzufügen -Anmeldeinformationen, parameter des Befehls. Meine Forschung hat gezeigt, dass einige positive Ergebnisse aus der Verwendung von Anmeldeinformationen in der Befehl. Wenn das der Fall ist müssten Sie sich weiter.
- Vielen Dank für Ihre Antwort, Sie gab mir einen kleinen work-around Idee, dass das teilweise funktioniert. Meine Antwort ist unten.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Zunächst erstellte ich credential variable mit meinem Domänen-admin-Konto:
$cred = get-credential- Ich tippte meine Domäne\Benutzername und KennwortDann habe ich die IP-Adresse statt hostname -ComputerName-parameter, also die "enter-pssession" sieht wie folgt aus:
Enter-Pssession -ComputerName 192.168.1.111 -Credential $creddieser Ansatz funktioniert für die invoke-Befehl als auch
invoke-command -ComputerName 192.168.1.111 -Credential $cred -ScriptBlock {hostname}Weiß ich immer noch nicht, warum funktioniert es nicht mit dem Hostnamen und warum habe ich, um $cred, aber ich brauche eine schnelle Lösung, diese funktioniert gut für mich.
Danke für die Hilfe.
Ich hatte das exakt gleiche Problem. Mit der FQDN für mich gearbeitet.
Chris N ist richtig:
Dies ist eindeutig ein DNS Auflösung Fehler; vor allem, wenn die IP-Adresse funktioniert. Ich wage zu sagen, es gibt Name Suffix Routing-Probleme.
Den ComputerName Beschreibung sagt, dass NETBIOS-Namen funktionieren sollte, aber es nicht in meiner Prüfung in meiner Umgebung. Der FQDN ist eine weitere option für die -ComputerName Eigentum und fixiert diesen Fehler für mich.
Versuchen Sie es mit (verwenden Sie Ihre FQDN, natürlich):
Hinweis: Feststellen, es ist in allen Kleinbuchstaben. Mit camel-case (serverA.vertigion.com) scheiterte mit dem gleichen Fehler. Ich merke, dass in der Regel nslookups groß-und Kleinschreibung unterschieden.
Hinweis: ich habe NICHT das Problem mit der Enter-PSSession Befehl. Ich glaube, es gibt einen bug (oder zumindest eine eklatante Inkonsistenz) mit Invoke-Command.
Mehr info: http://go.vertigion.com/PowerShell_Invoke-Command
Es klingt wie das Problem mit der Namensauflösung. Sie können dies überprüfen, indem Sie einen Ping ServerA von ServerB. Wenn es nicht gelingt, Sie könnten von dort aus arbeiten. Versuchen Sie, mit Ping von FQDN (servera.mydomain.com) oder per IP.
Sehen mehr info hier. Ich lief in dieses, in der ein paar von Servern, die gearbeitet hatten, aber dann spontan aufgehört und begann die Ausstellung der OP-Fehlermeldung aus. Ich neu gestartet, den Zielserver und das hat die Dinge wieder zu arbeiten.