Adott helyről azzal kerestek meg, hogy egy Win2012R2-n nem működik a WinRM. Ez onnan látszott, hogy egy másik gépről, ServerManagerből nem tudott csatlakozni, azt írta, hogy “Online – Verify WinRM3.0 service is installed, running, and required firewall ports are open“.

Tudjuk, hogy alapból ez az oprendszer elég jól fel van készítve a távoli csatlakozásra, ezért nem igazán értettem a dolgot. Ellenőriztük a WinRM szervízt – fut. .Net komponensek – telepítve. WMF verzió, ami ugye szorosan kötődik a PS verzióhoz ($PSVersionTable.PSVersion) stimmel. Listener lekérdezés:

winrm e winrm/config/listener

eredménye pipa, a kért 5985 porton hallgat. Tűzfal kivétel: pipa.

Szóval az alapok átfutva, minden rendben levőnek tűnik. Akkor kicsit menjünk mélyebbre.

Tudjuk, hogy az “elindítás” miként szokott történni: a winrm qc (=QuickConfig) parancssal. Ez mit is csinál? Röviden, az alábbi parancsokkal tudnánk leírni a működését:

sc config “WinRM” start= auto

net start WinRM

winrm create winrm/config/listener?Address=*+Transport=HTTP

netsh firewall add portopening TCP 80 “Windows Remote Management”

Rendben, tehát ha töröljük a listenert, s ismét létrehozzuk, akkor nem lehet gond. (Listener törlés: winrm delete winrm/config/Listener?Address=*+Transport=HTTP)

A törlés után ismét létrehozva valamelyik módszerrel (akár winrm qc, akár winrm create… verzióban) továbbra sem változott semmi.

Futtattam egy

Test-WSMan -ComputerName GépNév

parancsot – szintén hibára futott, teledobta pirossal a képernyőt.

Akkor nézzük magát a kapcsolatot, illetve a nyitott portot. Amikor lokálisan kipróbáltuk, akkor csont nélkül tudott csatlakozni a kérdéses porthoz, távolról már nem (a telnet is alkalmas lehet, de ez “beépített”):

Test-NetConnection localhost -port 5985

Ekkor már kezdtem gyanakodni, hogy valahol itt lehet a kutya elásva. Lefuttatva egy

netstat -ano | findstr 5985

lekérdezést, kiderült a turpiság: valamiért csak a 127.0.0.1-en hallgatott a WinRM szolgáltatás, a helyes 0.0.0.0 helyett. Ezt megerősítette a

netsh http show iplisten

parancs is, így nem maradt más hátra, mint

netsh http delete iplisten 127.0.0.1

futtatása, ami után helyreállt a béke. S hogy miért volt ez? Valószínűleg egy bug lehet, ami bizonyos esetekben ilyen eredményt produkál…

Forrás: https://asteriksz.wordpress.com/