Enable-PSRemoting succeeds but Test-WSMAN fails

I wish to use Invoke-Command with Get-Process, so I issued locally the Enable-PSRemoting on the target computer successfully (see screenshot), verified the four WinRM endpoints were created, then verified the four Windows Advanced Firewall Inbound Rules for the WinRM group were enabled.

Alas, issuing the Test-WSMan cmdlet from my Windows 8.1 workstation (logged in as Domain Administrator) results in the well-known error message “WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer.” Supplying the IP address instead of the target computer’s name resulted in the same error message. Running Test-WSMan from another domain computer resulted in the same error message.

My workstation and the target fileserver belong to the same domain & subnet, so are “Trusted Hosts.” From my workstation I can Ping the name & IP address of the remote computer, perform NSlookup on the remote computer’s name, and open a Shared Network Folder [SMB] located on the fileserver.

Opening an elevated command prompt from the keyboard of the target file server, I ran “WinRM quickconfig”, yet still received the same error message when attempting Test-WSMan from my workstation to the file server. This Windows Server 2012 R2 fileserver is not running any antivirus, security software, or applications, simply is a file server with the minimum Server roles installed. Is their some additional step I need to take because of the 2012 R2 O/S?

You’re trying a couple of things that aren’t necessary. For example, Enable-PSRemoting already runs Quickconfig, so that’s not expected to change anything.

You mentioned that the client and server are in the same domain. Are you attempting to access the server by specifying it’s fully-qualified domain name? An IP address is not expected to work; Kerberos can’t look up the computer in AD by IP address, and so it can’t obtain a ticket. Typically, the FQDN works best. Similarly, pinging and NSLookup aren’t really useful tests, because they’re using DNS to resolve the name to an IP address - which is only part of the process WinRm uses, and which doesn’t include the AD lookup portion.

I tried Test-WSMan using the fully qualified computer name – alas, same error message as posted earlier.

I have verified that the four WinRM firewall rules are enabled (see screenshot attached to this post).

Being a Windows Server 2012 System Administrator, on the target file server [] I queried the WinRM Listener configuration

C:> WinRM.exe enumerate WinRM/Config/Listener
Address = *
Port = 5985
Transport = HTTP
Enabled = True
ListeningOn =,

Then I locally executed Telnet to test the TCP Listener – it successfully opened a Listener window on the underlying fileserver.

C:> Telnet localhost 5985

Returning to my administrator’s Windows 8.1 computer, I first tried testing WinRM, which failed (with the error message I posted earlier).

PS C:> Test-WSMan -ComputerName FS1.publicioc.org

Then I tried Telnet, which failed to connect remotely via HTTP to that 5985 port on the target fileserver, even when I turned off the Windows Advanced Firewall on the target fileserver.

C:> Telnet 5985

In summary:

  1. I ran “Enable-PSRemoting -Force” successfully on the target fileserver – no error messages.
  2. Get-PSSessionConfiguration on the target fileserver showed the correct four WinRM endpoints created (see screenshot from earlier post)
  3. “WinRM enumerate” showed port 5985 enabled and listening for HTTP traffic to from all (*) IP addresses
  4. Windows Advanced Firewall Inbound Rules on the target fileserver shows the group of four WinRM rules all enabled on Domain & Public for all IP addresses (see screenshot attached to this post)
  5. Telnet localhost 5985 succeeds if run locally on the target fileserver but fails if run remotely from the administrator’s workstation

Event though port 5985 is enabled and listening, it is not accepting any traffic (from Telnet or WinRM] – I cannot think of any other settings to review or modify. Suggestions?

So I just read point 5. That suggests there is indeed a lower-level IP-related thing going on. If you can’t even get 5985 to fess up from a remote machine, then you’re at TCP, not even up to WS-MAN. Again, strongly consider enabling Firewall diagnostics and peering in the log, and see what else on your network might be stopping 5985 traffic. Like, a switch or router. If you can’t even make a basic TCP connection, nothing else is going to work.

FROM THE FILE SERVER, can you Enter-PSSession localhost?

I have resolved this issue and post these notes for others who encounter the circumstance that:

  1. Enable-PSRemoting executes successfully with no errors,
  2. the presence of the four WinRM endpoints is verified with Get-PSSessionConfiguration,
  3. the TCP Listener is verified by “C:> WinRM enumerate WinRM/Config/Listener”,
  4. yet Test-WSMan and Telnet only connect locally (not remotely) on the default TCP port 5985.

The target computer (and my administrator workstation) are running on the same physical machine – a Windows 2012 R2 Server running Hyper-V. Rebooting those machines failed to clear the TCP issue – rebooting the host Hyper-V machine did. Therefore, I conclude that the TCP Stack, buffers, etc. overflowed or went awry, not the underlying PowerShell code or necessarily the O/S code. If this issue does recur in the near future, then I will suspect some flaw in the Server 2012 R2 O/S code that is not managing TCP resources correctly, and open an incident with Microsoft Technical Support to see if they can run some diagnostic tool to pinpoint the cause.

I am getting the same error and I don’t have the rights to reboot the server or Hyper V,

Don & Jeffery , can you suggest something here for the same issue ?

I had this issue and it was down to the fact that, even though WINRM QC or ENABLE-PSREMOTING had been run (as they are on W10 by default anyway), the WINRM service was OFF and set to Manual on the machines which was surprising. One group policy change, the firewall inbound exception on 5985/6 and configuring the listeners and off we go! Off to test it all out now and to make changes in serial to a group of Surface Pro 4’s.

Thanks to Don - the Enter-PSSession Localhost led me to what was wrong.

It’s normally always something simple.