7

I have a virtual testing environment for developing scripts. As .NET isn't capable of all the possibilities PowerShell offers I use Remote PowerShell Runspaces.

My problem is now, that I can't reach the WinRM-Service on the FileShare-Memberserver, although the service is running.

fail message

Initial Situation:

  • winrm quickconfig tells me that the service is running and configured on all parties.
  • If I run the command Test-wsman on the FileShare itself it isn't a problem either.
  • I obviously restarted the service a couple of times
  • With my remote script, I can reach the Exchange Shell on the FileShare, but not the MS PowerShell
  • I can connect to the server manually with the "Remote Desktop Connection"-Application
  • At one point I deactivated all firewalls, because I wanted to merge out the possibility that the request gets stopped there.

I made a quick drawing of the Server structure within my virtual testing Environment. (Red Arrows mean that the Test-WSMan command didn't work)

Server structure

I'm have no clue how to continue on with this problem. I've read so many things on the Internet which didn't help. I went through all the steps of the TechNet Blog "about_Remote_Troubleshooting". Most of all that that my script can reach the Exchange PS on the same server blows my mind. I asked a question on this topic on SO a couple of months ago, because I thought the ShellUri of my script was wrong, although it worked for the PS on the DC.

So if anybody has a hint for me what I could try next, I'd be very thankful.

Community
  • 1
GrindelOh
  • 175

2 Answers2

7

As discussed in the comments, local group policy is blocking the winrm quick config from creating http listener on the server - to solve this conflict.

connect to the remote server run the group policy editor (start >> run >> gpedit.msc)

Expand Computer Configuration, Administrative Templates, Windows Components, Windows Remote Management, and then select 'Allow remote Server Management through WinRM'*

* Windows server 2008 might read 'allow automatic configuration of listeners'

enable it/ allow it. put an * in the IP filter to listen on on all IP's

enter image description here

run gpupdate

restart WinRM

Sum1sAdmin
  • 2,004
1

WinRM relies on WS-Man which can bind to port 80 since it is a SOAP based protocol. If this happens, WinRM can be reset to default settings:

  1. winrm d winrm/config/listener?address=*+transport=http

  2. netsh http del iplisten ipaddress=127.0.0.1

  3. rm -v wsman:\localhost\listener\listener*\ -fo -r

  4. winrm invoke restore winrm/config

    5. set-pssessionconfiguration Microsoft.powershell -SecurityDescriptorSddl "O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)"

    6. restart-service winrm

    7. winrm qc -q

It is not enough to just delete & re-add the listener. NT Authority\Network Service & Remote Management Users permissions must be configured properly to bind the listening port to the default route 0.0.0.0 instead of the loop back 127.0.0.1. After resetting WinRM, the proper settings can be verified a few ways.*

Netstat can verify the WinRM port was setup properly:

PS C:\> netstat -ano|sls 5985
        TCP    0.0.0.0:5985           0.0.0.0:0              LISTENING       4
        TCP    [::]:5985              [::]:0                 LISTENING       4

WS-Man provider can verify the WinRM port was setup properly:

PS C:\> ls wsman:\localhost\listener\listener_GUID\
Type            Name                           SourceOfValue   Value
----            ----                           -------------   -----
System.String   Address                                        *
System.String   Transport                                      HTTP
System.String   Port                                           5985

Netsh should also be blank:

PS C:\> netsh http show iplisten
IP addresses present in the IP listen list:
-------------------------------------------

Hope this saves someone the 12+ hours it took me to figure it all out!

nu_nad
  • 11