Kezdőlap > General, Windows Server > WinRM nem megy

WinRM nem megy


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…

Kategóriák:General, Windows Server Címkék: , ,
  1. jpetrenyi
    február 14, 2019 - 4:54 du.

    Ilyenkor valahogy örülök, hogy már nem az operatív területen dolgozok.

    • február 20, 2019 - 8:53 de.

      Úgy vagyok vele, hogy néha nem árt besegíteni, főleg ezeréves kollégáknak/ügyfeleknek 🙂

  2. Zomby
    február 19, 2019 - 9:14 du.

    Nem lehet, hogy valamelyik kolléga egy másik problémát a “netsh http add iplisten 127.0.0.1” paranccsal próbált megjavítani?

  3. Zomby
    • február 20, 2019 - 8:50 de.

      Jogos lehetne, de itt csak arra hallgatott, semmi másra. Jelen megoldással viszont arra is, meg minden más címre is 🙂 Amúgy körbekérdeztünk, senki nem nyúlt ehhez a részéhez 😀

  4. soder
    február 20, 2019 - 10:24 du.

    A TCP5986 / HTTPS módiról miért hallgatnak mindenku? Nem annak kellene a defaultnak lennie manapság?

    • február 22, 2019 - 8:57 de.

      Tapasztalatom szerint nagyon sok helyen még mindig nincs bevezetve a CA, s pl. a “winrm quickconfig -transport:https” utasítás hibaüzenete is elég egyértelműen leírja, hogy (többek között) nem lehet önaláírt tanúsítvány…

      • soder
        február 22, 2019 - 6:44 du.

        Pedig szerintem (hétfőn megnézem) nekünk százával vannak workgroup-os(!) w10 gépek winrm TCP5986-on, elég esélyesen önaláírt certtel. Bár ahogy így belegondolok lehet tévedek, és tényleg kaptak a prod domainből PKI chaint+ igazi intra certet.

  1. No trackbacks yet.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés /  Módosítás )

Google kép

Hozzászólhat a Google felhasználói fiók használatával. Kilépés /  Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés /  Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés /  Módosítás )

Kapcsolódás: %s

%d blogger ezt szereti: