New-PSSession does not work locally

Question

I am trying to connect to the localhost using New-PSSession.

I have

• Configured WinRM using

  winrm quickconfig
  

• Enabled PS Remoting

  Enable-PSRemoting
  

• Added Trusted Host

  Set-Item WSMan:\localhost\Client\TrustedHosts * -Force
  

• There is an inbound rule on 8173 port on firewall.

Output of winrm:

PS C:\> winrm get winrm/config/listener?Address=*+Transport=HTTP
Listener
    Address = *
    Transport = HTTP
    Port = 8173
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    Listening on = 127.0.0.1

I am trying to run the following command:

New-PSSession -ConnectionUri http://localhost:8173/WSMAN

but I get this error:

[localhost] Processing data from remote server failed with the following error message:
Error with error code 14 occurred while calling method WSManPluginReceiveResult. For
more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionOpenFailed

EDIT:

The only extra thing that I see is that the network is connected to public $listenerport = "8173" winrmwinrm create winrm/config/Listener?Address=*+Transport=HTTP "@{Port="$listenerport"}"

C:\>winrm get winrm/config
Config
    MaxEnvelopeSizekb = 1039440
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = true
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 8173
            HTTPS = 5986
        TrustedHosts = *
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-21-2458768215-3945602940-3262220185-1045)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 500
        EnumerationTimeoutms = 60000
        MaxConnections = 25
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = true
        Auth
            Basic = true
            Kerberos = false
            Negotiate = true
            Certificate = true
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = *
        IPv6Filter = *
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 180000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 15
        MaxMemoryPerShellMB = 150
        MaxShellsPerUser = 5


PS C:\> Get-PSSessionConfiguration microsoft.powershell | fl *


xmlns            : http://schemas.microsoft.com/wbem/wsman/1/config/PluginConfiguration
Name             : Microsoft.PowerShell
Filename         : %windir%\system32\pwrshplugin.dll
SDKVersion       : 1
XmlRenderingType : text
lang             : en-US
PSVersion        : 2.0
ResourceUri      : http://schemas.microsoft.com/powershell/Microsoft.PowerShell
SupportsOptions  : true
ExactMatch       : true
Capability       : {Shell}
Permission       :

Administrators group have permission as I see in the window popup (Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI)

EDIT 2:

Answer 1

By process of elimination, we can rule out firewall as an issue, as you are only connecting to the loopback address (127.0.0.1). We can also rule out WinRM configuration which looks fine.

The error message suggests that TCP connection to http://localhost:8173/WSMAN is actually successful, but fault occurs while establishing PS session.

This points to Microsoft.PowerShell session configuration.

Looks like there is a discrepancy in the permissions you see when looking at

Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI 

and the permission actually assigned to Microsoft.PowerShell. The output of

Get-PSSessionConfiguration microsoft.powershell | fl *

should have the "SecurityDescriptorSddl" and "Permission" proprieties listed. Like this:

Name                   : microsoft.powershell
Filename               : %windir%\system32\pwrshplugin.dll
SDKVersion             : 1
XmlRenderingType       : text
lang                   : en-US
PSVersion              : 2.0
ResourceUri            : http://schemas.microsoft.com/powershell/microsoft.powershell
SupportsOptions        : true
Capability             : {Shell}
xmlns                  : http://schemas.microsoft.com/wbem/wsman/1/config/PluginConfiguration
Uri                    : http://schemas.microsoft.com/powershell/microsoft.powershell
ExactMatch             : true
SecurityDescriptorSddl : O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
Permission             : BUILTIN\Administrators AccessAllowed

Try removing and reassigning these permissions.

EDIT:

Based on the information you have provided this is not the main problem. I have also noticed that you have a non standard "RootSDDL" in WinRM service settings.

RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;S-1-5-21-2458768215-3945602940-3262220185-1045)(AU;SA;GWGX;;;WD)

by default this should be

RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

I have recreated this on the test VM and Remoting still works. So I had another look at your WinRM configuration ...

Solution

Your problem is this line

MaxEnvelopeSizekb = 1039440

By setting this value I can replicate the issue you have. I would suggest to set this to something more reasonable, or to default.

winrm set winrm/config '@{MaxEnvelopeSizekb="150"}'

Will fix your problem.

Answer 2

setting the following worked for me after I upgraded to computers from win 10 1607 to 1708

the update changed the following reg key to 1, and setting it back to 0 worked for me

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
FilterAdministratorToken=dword:0

Answer 3

In a "strict" IPV4 environent, we had the same Problem as well.

The reason was: WinRM (and other services) seem to use the IpV6-Loopback-Address even if ipv6 is disabled everywhere. (Which is no Problem, except with WinRM)

Hence, if there is no WinRM-Listener for the IPV6-Loopback Adress - you can't connect to localhost, even if WinRM is working from a remote-host.