Enable-PSRemoting succeeds but Test-WSMAN fails


This topic contains 5 replies, has 3 voices, and was last updated by Profile photo of ravi kumar singh ravi kumar singh 6 months, 3 weeks ago.

  • Author
  • #25325
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar

    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?

  • #25327
    Profile photo of Don Jones
    Don Jones

    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.

  • #25332
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar

    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?

  • #25334
    Profile photo of Don Jones
    Don Jones

    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?

  • #25389
    Profile photo of Jeffrey Wagar
    Jeffrey Wagar

    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.

  • #37404
    Profile photo of ravi kumar singh
    ravi kumar singh

    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 ?

You must be logged in to reply to this topic.