8

I cannot connect to remote server using enter-pssession -computername serverA. My scenario:

  • I have 2 Win 2003 R2 servers in the same domain. ServerA is WSUS server, serverB is a domain controller
  • Both servers have enabled powershell remoting
  • Both servers have configured winrm (winrm quickconfig)
  • Both servers have TrustedHosts set to *
  • setspn.exe is set up correctly (http, https, wsman etc.)
  • Both servers have FireWall turned off
  • Both servers have PowerShell 2.0

I am trying to enter-pssession -computername serverA under the domain admin credentials from serverB to serverA and it throws the following error:

"""Enter-PSSession : Connection to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found."""

When I try to enter-pssession -computername serverB under the domain admin credentials from serverA it works fine! It also works if I use localhost so: enter-pssession -computername localhost under the domain admin credentials (on serverA) works as well, but when I try the hostname on serverA (instead of localhost) enter-pssession -computername serverA it throws the same error.

I also tried to use get-credential and provide different types of credentials, but it did not help. The only thing which helped was using a local (not domain) administrator account and running enter-pssession -computername serverA -credentials $cred and it worked, but only locally, I was able to do this from local machine (from serverA to itself) but not from serverB to serverA under the serverA\administrator credentials.

Any ideas?

Thanks

kubusz
  • 943
  • 3
  • 9
  • 17
  • 1
    If my answer below doesn't seem to be the case, try adding the -Credentials parameter to the command. My research showed that some had positive results from using credentials in the command. If that's the case you'd have to look into that further. – Chris N Jul 30 '12 at 12:20
  • Thanks for your reply, you gave me a little work-around idea, that partly works. My answer is below. – kubusz Jul 31 '12 at 12:47

5 Answers5

4

First of all I created credential variable with my domain admin account:

$cred = get-credential - I typed my domain\username and password

Then I used IP address instead of hostname in -ComputerName parameter, so the enter-pssession looks like:

Enter-Pssession -ComputerName 192.168.1.111 -Credential $cred

this approach works for the invoke-command as well

invoke-command -ComputerName 192.168.1.111 -Credential $cred -ScriptBlock {hostname}

I still do not know why it does not work with the hostname and why do I have to create $cred, but as I need a quick solution, this works fine for me.

Thanks for help.

kubusz
  • 943
  • 3
  • 9
  • 17
  • According to the documentation, you must use -Credential when you use the IP address of the target host. I think that is why you see this need. It also suggests that -UseSSL is required, which you are not specifying. I have seen differing results when that switch is used as well. – Prof Von Lemongargle Feb 05 '16 at 19:27
4

I had the exact same issue. Using the FQDN worked for me.

Chris N is right:

The network path was not found.

This is clearly a DNS resolution error; especially if the IP address is working. I would venture to say there are Name Suffix Routing issues.

The ComputerName description says that NETBIOS name should work, but it does not in my testing in my environment. The FQDN is another option for the -ComputerName property and fixed this error for me.

Try using (use your FQDN, of course):

Invoke-Command -ComputerName servera.vertigion.com

Note: Notice it's in all lowercase. Using camel case (serverA.vertigion.com) failed with the same error. I realize that typically nslookups are case-insensitive.

Note: I did NOT have the issue with the Enter-PSSession command. I believe there's a bug (or at least a blatant inconsistency) with Invoke-Command.

More info: http://go.vertigion.com/PowerShell_Invoke-Command

VertigoRay
  • 5,935
  • 6
  • 39
  • 48
0

It sounds like the issue is with name resolution. You can confirm this by pinging ServerA from ServerB. If it fails you could work from there. Try pinging by FQDN (servera.mydomain.com) or by IP.

Chris N
  • 7,239
  • 1
  • 24
  • 27
0

See more info here. I ran into this in a pair of servers that had been working but then spontaneously stopped and started issuing the OP's error message. I rebooted the target server and that got things working again.

Community
  • 1
  • 1
Prof Von Lemongargle
  • 3,658
  • 31
  • 29
0

Set TCP/IP NETBIOS service to auto start, and enable service. also allow NETBIOS in adapter properties if needed.

metablaster
  • 1,958
  • 12
  • 26