Archívum

Archive for the ‘Windows Server’ Category

Wsus gondok Win 2022 upgrade után

szeptember 19, 2021 2 hozzászólás

Pár napja publikus lett a Windows 2022 (pl. VLSC*), de az “éles” ismerkedésünk nem indult valami jól. Az egy dolog, hogy szűz telepítésnél hogyan viselkedik, de tudjuk, hogy puding próbája az evés – így mondjuk például egy in-place upgrade már jobban kimutatja a problémákat. Természetesen a felmerülő kérdéseket nem szabad általánosítani, hiszen a helyi sajátosságok is közrejátszanak, majd a jövő megmutatja, hogy ez valóban lokális gond volt-e.

Adott cégnél próbálták ki az upgrade-et egy 2019-ről. Maga a telepítés sikeresen lezajlott, de utána máris kellett a segítségem, ugyanis pl. a Wsus upgrade-je sikertelen lett. Maga a hibaüzenet nem ismeretlen az IT-sok világa előtt, hiszen láttunk már ilyent:

Fatal Error: The schema version of the database is from a newer version of WSUS than currently installed. You must either patch your WSUS server to at least that version or drop the database.

Előbb természetesen megnéztem az adatbázis-verziót meg a post-Wsus konfigban szereplő verziót – egyezett (ellenkező esetben az alábbi parancsot érdemes lefuttatni):

C:\Program Files\Update Services\Database\UpdateSchemaVersion.sql

Mivel nem akartak sokat foglalkozni ezzel az adott cégnél, kérték, hogy akkor nulláról indítsuk. Így előbb megpróbáltam simán adatbázis törléssel (SQL Management Studio-ból) és ismételt létrehozással (anno máshol nem WID volt, így a jegyzeteimben ott volt még a szögletes zárójelbeli kiegészítés):

wsusutil.exe postinstall [SQL_INSTANCE_NAME=server\SQLEXPRESS]

Majd, amikor (látszólag) ez sem vezetett eredményre, letöröltük a WID instance-t és a WSUS szerepkört, majd újraindítás után újratelepítettük. Itt már biztossá vált, hogy nem ezzel volt baj, hiszen a WSUS konzol félig-betöltése továbbra is megmaradt.

A rend azután állt helyre, miután a 4GB memória növelésre került. Az eredeti elképzelés szerinti feladatokra lehet, hogy elég volt anno ez a mennyiség, de megnézve az aktuális terheltséget, szükség volt a +1GB-ra, főleg a kezdeti szinkronizációhoz (elég szűkös erőforrásokkal rendelkeznek…).

*VLSC: Ott is nagy változások történnek, hiszen az MS igyekszik kivezetni a “sima” fiókok használatát s “céges” fiókok irányába terelni. Ez részben jogos, hiszen általában a licenszek adott céghez/cégekhez kötődnek, így abban a cégben létre lehet hozni egy új felhasználót – még ha nem is kap licenszt igénylő postafiókot; ugyanakkor véleményem szerint ennek a műveletnek a szükségessége kaphatott volna nagyobb visszhangot.

Kategóriák:Windows Server, Wsus Címkék: , ,

DNS zónák

január 26, 2021 Hozzászólás

Egy “nagytakarítás” során adott helyen felmerült, hogy az ADUC-ban miért látszanak egyes DNS-zónák, mások meg miért nem? Egyáltalán miért vannak ott?

Nos, kezdjük azzal, hogy AD-integrált zónák lévén mindenképp az AD-ban kell tárolódjanak, tehát bizonyos AD-kezelő eszközökkel látnunk kell őket. S bár abban “igazuk” volt, hogy a képen látható (és néhány, nem látható) zónák AD-integráltak, de nem mindegy, hogy kinek is replikálunk zónán belül.

Amennyiben Windows 2000-kompatibilis integráció lesz a kiválasztott, akkor megjelenik az ADUC-ban is (a szokásos DNS-kezelőn kívül), ellenkező esetben (szintén DNS-kezelőn kívül) csak ADSIEdit segítségével látjuk, csatlakozva a DC=DomainDNSZones,DC=tartomany,DC=hu partícióra (vagy, ha a legfelső opció, akkor értelemszerűen a DC=ForestDNSZones,DC=tartomany,DC=hu partícióra).

Mivel adott cégnél már nem volt szükség Windows-2000 kompatibilitásra, így át tudtuk állítani, s már nem zavarta őket, “eltűnt” (hétköznapi ember többet használ ADUC-ot, mint ADSIEdit-et 🙂 )

A tesztelés fontossága

december 2, 2020 1 hozzászólás

Adott helyen megkértek, hogy néhány fürtöt nézzünk át közösen, valamint azokon minimális módosításokat szeretnének. Ahogy haladtunk előre a munkával, dőltek ki a csontvázak a szekrényből, de a legnagyobb az utolsó fürt esetén jött elő.

Ez egy SQL-clusternek nevezett szolgáltatás volt. Az addigi tapasztalatok alapján, no meg a normális emberi gondolkodás szerint is, az első lépés az volt, hogy jelen állapotában teszteljük a működését. Ez azt jelentette, hogy a szolgáltatást a fürt egyik tagjáról átbillentsük a másikra. Nos, “természetesen” elhasalt. Ideiglenesen visszaállítottuk, s elkezdtük a hibakeresést, ami egy számomra teljesen szokatlan helyzetet mutatott ki: nem egy beállítás, nem egy pipa okozta a gondot, hanem az SQL-szerver telepítés hiánya. Előbbit még mondjuk így-úgy meg lehet magyarázni, hogy időközben állítódott el (persze, magától 😛 ), de egy egész SQL-telepítést? Ugye tanfolyamokon szoktunk viccelni, amikor idő szükséges, hogy semmi gond, addig telepítsünk egy SQL-t. Tudjuk jól, hogy nem 2 másodperc. S tudjuk jól, hogy legtöbb ember grafikus varázslóval megy rajta végig, akár telepítés, akár eltávolításról van szó. Szóval egy ilyen, rengeteg paramétert igénylő eltávolítást szerintem nem lehet “véletlenül” végrehajtani. De akkor mi történt?

Nos, valószínűleg emberi mulasztás. Lehet, hogy rohamtempóban kellett felhúzni a fürtöt, s nem volt idő a másik tagra telepíteni az SQL-t. Vagy valamilyen hiba következett be a telepítés során, amire elfelejtettek visszatérni. Vagy tudatlanság miatt: nem tudták, hogy mindkét kiszolgáló kell rendelkezzen telepített SQL-el. Vagy… lehetne sorolni a különböző forgatókönyveket.

A legnagyobb hiba viszont a végén van: átadás előtt tesztelni kellett volna. Hogy valóban átbillen-e, hogy valóban jól működik. S ha igen, csak akkor átadni használatra, ha nem, akkor jelezni, hogy pillanatnyilag működőképes, de NEM fürt. Ezáltal az érintettek is tudták volna, hogy mi is van a motorháztető alatt. Mi lett volna, ha mindez “élesben” derül ki, amikor az addig használt kiszolgáló ilyen-olyan okokból kifolyólag kidől?

Kategóriák:General, Windows Server Címkék: ,

Saját CA által kiállított tanúsítványok vs böngészők

október 7, 2020 Hozzászólás

Nem új keletű a történet háttere, de gondolom az új Edge bevezetésével mind több helyen elő fog jönni, ezért úgy döntöttem, elébe megyek a dolgoknak.

Adott cégnél felmerült, hogy az eddigi http alapú intranet kommunikációt áthelyezik https-re. Ennek érdekében első körben történt egy CA-bevezetés, majd a kiszolgálóra igényeltek egy web-kiszolgálói tanúsítványt.

A tesztelés során kiderült, hogy azok, akik IE vagy “régi” Edge-ről töltik be az oldalt, nem tapasztalnak gondokat, viszont akik Chrome vagy Chromium alapú Edge-ből, azoknak

ERR_CERT_COMMON_NAME_INVALID

hibaüzenettel, a Firefox-ból vonulóknak pedig egy

SEC_ERROR_UNKNOWN_ISSUER

üzenettel kedveskedik a rendszer.

Itt akkor felmerült a kérdés: most akkor mi van? Jó a tanúsítvány vagy nem? Illetve miért függ egy tanúsítvány megítélése a böngészőtől?

Nos, Firefox esetén a böngészőnek saját tanúsítvány-tára (is) van, de esetében mondhatni könnyű dolgunk van: egy házirend segítségével megadjuk, hogy a böngésző az oprendszertől kérje el a megbízható tanúsítványok listáját. S tudjuk, hogy a CA automatikusan lekerült a gépekhez, tehát ez nem lehet gond (erre amúgy másodlagos bizonyíték az is, hogy az MS régebbi böngészői sem reklamálnak). Itt “csak” egy dolog nem teljesen világos számomra: miért szükséges, hogy egyes programok (pl. Adobe, Java, stb) saját tanúsítványtárat használjanak? Értem én, hogy így akár szolgáltatásonként külön tanúsítványt lehet használni – de személy szerint ezt már túlzásnak érzem…

A Chrome / Chromium alapú Edge esetében a megértéshez szükséges a Google böngészőjének működését figyelembe venni. Kb. 3 éve ugyanis a Chrome nem fogadja el a belső CA-k által kiállított tanúsítványokat, csak akkor, ha azok rendelkeznek érvényes SAN-mezővel. Ezzel a gondolattal lehet vitatkozni, ugyanis elvileg az RFC előírja, hogy másodlagos opcióként a CN-t is ellenőrizni kell – de ez figyelmen kívül van hagyva. Egy ideig egy registry-kulccsal lehetett egy kerülő-megoldást alkalmazni, viszont ezt a lehetőséget is már rég megszüntették. Jelen esetben megoldásként az a döntés született, hogy rendben, akkor létrehoznak egy új, célnak megfelelő tanúsítvány-sablont, majd azzal igényelnek tanúsítványt. Ennek szétszedése (Cert, Key, CA) már gond nélkül lezajlott, majd az élesítés után már valóban nem reklamált a böngésző. De hogy mit tesznek azok a cégek, ahol tömegesen használnak web-kiszolgálókat, saját CA-val, s tömegesen akarják lecserélni a tanúsítványokat az újabb sablonból eredőnek – hát, lehet, hogy nem mindenki lesz boldog.

VM nem indul automatikusan

szeptember 25, 2019 Hozzászólás

Adott helyen felmerült a kérdés, hogy egy adott VM miért nem indul el automatikusan, amikor a host-ot újraindítják. A srácok nem igazán értették, ezért a mélyebb megértéshez elővettük az Application naplót, konkrétabban a Microsoft/Windows/Hyper-V-Worker/Admin eseménytárat, abban az alábbi megjelenő 4 hibaüzenetet (időrendi sorrendben alább):

12162: ‘VM’: Failed to configure ‘D:\Hyper-V\Virtual Hard Disks\VM.vhdx’: The storage where the virtual hard disk is located does not support virtual hard disk sharing.

12140: ‘VM’: Failed to open attachment ‘D:\Hyper-V\Virtual Hard Disks\VM.vhdx’. Error: ‘A virtual disk support provider for the specified file was not found.’ (7864368). (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

12010: ‘VM’ Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error ‘A virtual disk support provider for the specified file was not found.’ (0xC03A0014). (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

12030: ‘VM’ failed to start. (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

Ami furcsa, hogy mivel Gen1-es gép boot-lemezéről van szó, ezért értelemszerűen csak IDE-s vezérlő jöhet szóba, s természetesen arra is van kötve (virtual hard disk sharing pedig csak scsi csatoló esetén jöhet szóba). Ugyanakkor feltűnhet, hogy a másik hibaüzenet az, hogy nem találja az állományt.

Akkor gondoljuk végig. Amennyiben kézzel indítjuk a virtuális gépet, akkor csont nélkül elindul – tehát az állomány létezik, van elég jogosultság hozzáférni. Nézzük, akkor melyik köteten van, valamint van-e még másik VM boot ugyanitt: igen, van, az pedig automatikusan el is indul.

Igen ám, de a kötet milyen lemezen van? Nos, egy iscsi LUN-ról beszélünk, tehát még az is lehet, hogy azért nem találja a kötetet (s ezzel együtt az állományt), mert még nincs felcsatolódva, amikor elindul a VM. Ennek az elméletnek igazolása után meg is fejtettük a dolgot, egy kérdés maradt még hátra: ha ez így van, akkor a másik VM (ugyanerről a kötetről) miért indul el? Erre megkaptuk a választ, amint belenéztünk a beállításokba: azért, mert az 120sec-es időkésleltetéssel volt indítva.

A probléma feltárva, a megoldást már a srácokra bíztam (ezt is késleltetik, átteszik másik kötetre, stb), pipa 🙂

AD és O365

július 31, 2019 1 hozzászólás

Aktuális történetem szintén AD-ról szó, bár ez érdekes módon most Exchange-problémából indult. Igen, természetesen tudom, hogy az Exchange az AD-ra épül – de azért mégis két külön termék.

Adott egy elég nagy szervezet, több tartománnyal, több Exchange kiszolgálóval. Egyes helyeken a levelezést már kiszervezték O365-be, míg más tartományok maradtak a hagyományos Exchange-verziónál (ami ráadásul most van migráció alatt, egy újabb verzió kerül bevezetésre – de jelen esetben ez lényegtelen).

A gond ott merült fel, hogy bizonyos tartományokból nem lehetett másik tartománybeli felhasználóknak emailt küldeni, „A postaláda címzettjének nincs postaláda-adatbázisa.” hibaüzenettel eldobta – s itt most csak a „belső” („testvér”) tartományokra gondolok.

Szokás szerint a helyzet nem volt ennyire egyszerű, ugyanis első információk szerint csak egy tartomány volt, amelyik nem tudott a cél-tartományba küldeni, miközben minden más irányba csont nélkül kimentek a levelek.

Kezdjük az elejével. A hibaüzenet alapján látszott, hogy a cél-tartományban (amelyik ráadásul O365-be költözött) nem történt meg minden lépés a migráció során, konkrétan a felhasználók TargetAddress címe nem lett kitöltve. Ha ez viszont igaz, akkor miért csak egy tartományból pattannak vissza a levelek? Utánajárva, letesztelve, kiderült, hogy ez csak feltételezés volt – ugyanis máshonnan nem küldtek levelet a cél-tartományba, ezért feltételezték, hogy akkor mindenki rendben tud küldeni. Amint másik „testvér” próbált emailt küldeni, természetesen ott is jelentkezett a hiba.

Rendben, akkor tehát a megoldás a TargetAddress kitöltése. A kollégák elvégezték a feladatot, majd újabb tesztek következtek. Nos, ekkor már valóban teljesült az előző állítás: csak egy (az eredetileg is jelzett) tartományból voltak sikertelenek a küldések, a többiek rendben tudtak küldeni.

Pontosabban, az előző mondatom sem teljes. Ugyanis ki kell egészíteni egy „általában” szócskával a mondat első felét. Volt, amikor sikeresen megérkezett a levél, volt, amikor nem (s ebben az esetben ugyanezzel a hibaüzenettel akadt el). Ugyanattól a feladótól, ugyanannak a címzettnek.

A nyomozás során újra átnéztem minden beállítást, értéket. ADSIEdit volt egyik fő eszközöm, de mindegyre meggyőződtem róla, hogy bármelyik DC-re is csatlakozom a hibás tartományból, annak GC partíciója (hiszen az tartalmazott infót a testvér-tartományról) helyes értékeket ad vissza a címzettről.

Aki ismer, tudja, hogy nem adom fel egykönnyen. Nos, ebben az esetben is elég komolyan foglalkoztatott a történet, szinte éjjel is ezzel aludtam 🙂

A megoldást egy véletlen hozta el. A „hibás” tartományban a kollégák felvettek egy új felhasználót, email-fiókkal, ahogy illik – de röviddel rá eltűnt a postaláda. Jelezték felém, hogy a Bermuda-háromszög ide költözött, így megkértek, hogy próbáljam én helyretenni a fiókot. Amikor elkezdtem utánajárni, akkor egy hirtelen ötlettől vezérelve megpróbáltam RDP-vel rámenni a DC-kre. Egyikre csont nélkül csatlakoztam, a másik… hát az elfogadta a név/jelszót, de utána nem történt semmi. A kollégát kértem, hogy próbálja ő – neki sem sikerült. A furcsa az volt, hogy mmc-vel, adsiedit-el csont nélkül tudtam rá csatlakozni. Kértem, hogy mindegy, milyen módon (ha lehet, „rendesen”, ha nem, akkor bárhogy) indítsák újra a DC-t – s utána érdekes módon minden megjavult.

Utólag persze könnyű okosnak lenni. A hibás email-küldés azért volt véletlenszerű, mert annak függvényében, hogy melyik DC-től kérdezte le a címzettet, kapott/nem kapott jó adatot. Igen, ennek ellentmond az, hogy a rossz DC is már tartalmazta a jó címet (hiszen más módon lekérdeztem tőle), de hogy mitől volt mesebeli (adott is, meg nem is; működött is, meg nem is)… A szokásos „indítsd újra” megtette a hatását 🙂

Kategóriák:Exchange, Windows Server Címkék: , , ,

Replikációs módszer – újra

június 19, 2019 Hozzászólás

Nem kellett sokat várni, s máris egy másik helyen jött elő az előző cikkemben jelzett probléma – sőt, most egy kicsit összetettebb módon.

A környezetről annyit érdemes tudni, hogy szintén nem egy “zöldmezős” beruházás (valljuk be, elég ritkák az ilyenek 😊 ). Van két tartományvezérlő, amit a korral haladva “görgettek” előre, így Windows Server 2019-re lettek frissítve. A replikációk csont nélkül lezajlottak, így nem is gondoltak semmi problémára, amíg nem olvasták a cikkem (bár elég lett volna eseménynaplókat nézni 😊 ).

Ahhoz, hogy ez a része is rendben legyen, megpróbáltak áttérni az új módszerre – viszont a Windows Server 2019-es egyik bug-jára futottak. Ugyanis amikor az első Win2019-es tartományvezérlő bekerül a csapatba, egy ellenőrzés nem történik meg (személy szerint merem remélni, hogy később ez javítva lesz): milyen replikációs metódus van használatban. Amennyiben még FRS-t használnak az adott helyen, NE engedje előléptetni a kiszolgálót tartományvezérlőnek.

Amennyiben (mint jelen esetben) nincs ilyen ellenőrzés, a DFSR-re történő áttérés hibákba fog ütközni (csak a Win2019 esetén, s többi DC esetén megfelelően végrehajtódik). Egyelőre hivatalosan annyit lehet tenni, hogy minden Win2019-es tartományvezérlőt lefokozni, majd teljes, sikeres áttérés után ismét előléptetni.

Vagy természetesen már tervezési fázisban, ha tudjuk, hogy ilyen tartományvezérlőket akarunk, betervezni az áttérést még előléptetések előtt.

Egy apró „fejlődési” hiányosság

május 30, 2019 1 hozzászólás

Nemrég egy sérült AD-t kellett rendbetennem. Most nem térek ki, hogy a két sérült AD-partíció javítása sem volt egyszerű (az külön megérne egy cikket), helyette az AD-hoz tartozó file-replikációt veszem górcső alá.

Aki még nem foglalkozott vele, annak kezdem az elejével. A tartományvezérlők a feladatuk elvégzése során elég sok feladatot kezelnek – pl. tudjuk, hogy az egész AD egy jó, működőképes DNS nélkül nem ér semmit. No de a DNS nem minden. Ritkán, de előfordul, hogy maga az AD-adatbázis sérül meg (ez tartalmazza a partíciókat), illetve még egy fontos része van: a házirendeket és scripteket tartalmazó Sysvol mappa replikációja.

Ez a replikáció két módon történhet. Egyrészt van a régi, “hagyományos” NT-korszakbeli LAN Manager Replication Service-t váltó FRS (File Replication Service), másrészt az új, 2003 R2-ben bevezetett, de 2008-ban kiteljesedő DFSR (DFS Replication). Manapság, ha új tartományt építünk, alapértelmezés szerint ez utóbbi lesz használva, de régebbről “görgetett” tartományok esetén is tudunk váltani (ehhez minimum 2008-as tartományi-szint szükséges). Sőt, Windows Server 2016 RS3 (1709)-től már az FRS egyáltalán nem támogatott.

Az áttérés nem nehéz, arra érdemes figyelnünk, hogy mindig legyen szinkronban a tartományunk (amennyiben egyik DC nem értesül adott áttérési műveletről, utólag megpróbálja “utolérni” a többieket – akkor van gond, ha bármilyen hiba bekövetkezik).

Visszatérve, a jelzett helyen elég gáz helyzet volt. Mivel nem akartam/akarták a teljes AD-t újrahúzni (jogosan), a már említett adatbázis javítása után következett a replikáció helyretétele. Igen ám, de ekkor derült ki, hogy még FRS-t használnak, így ezt a vonalat elengedve, az a döntés született, hogy akkor most térünk át DFSR-re. Általánosságban a javaslat az, hogy előbb a hibákat hárítsuk el, s egy egészséges környezetben változtassunk – de jelenlegi helyzet egyike a ritka kivételeknek, ahol ezt könnyebb volt meglépni.

A két replikációs módszer összehasonlítását már megtette más – én arra próbálok mindenkit rávenni, hogy egy hozott/kapott, de akár saját “görgetett” tartomány esetén is, amennyiben lehetséges, lépje meg ezt a lépést. Erre utal a cím is, hogy a cég fejlődik, az AD séma változik – de tervezzük bele a replikáció váltását is, egy hibakeresés esetén saját magunk munkáját is megkönnyítve 😉

Kategóriák:General, Windows Server Címkék: , ,

Egy rossz tervezés

április 25, 2019 Hozzászólás

Mivel máshol is belefutottam, gondoltam leírom, hátha van, aki legalább ezt olvasva észbe kap… Volt egy projekt, amelyben a segítségem kérték, egy teljes migrációt kellett végrehajtani a régi szerverekről az újakra. A kliens ugyanakkor nem minden fázist adott át, többek között a mentést és annak beállítását házon belül tervezte megoldani.

A sikeres migráció végéig még mindig nem döntötték el, hogy milyen módszerrel, milyen adattárolóra, milyen rendszerességgel fog történni a mentés. Abban egyetértettünk, hogy ez mindenképp szükséges, de mivel továbbra is saját maguk akarták kivitelezni, nem erőltettem a dolgot.

Szerencsére most nem azzal folytatom, hogy egy kripto-vírusos támadás után nem volt hova nyúlni. Viszont egy másik dolog következett be: a levelező-kiszolgálónak szánt lemezek teltek meg. Az előre egyeztetett elképzelés szerint nem körkörös loggolást használnak (ha lehet, amúgy sem ez a javasolt), ez viszont azzal jár, hogy ha nincs teljes mentés (s itt külön cikk lehetne a mentések típusairól, a piacon található mentőszoftverek módszereinek elnevezéséről), akkor a naplók csak gyűlnek. Ha nem monitorozzuk (akár külön szoftverrel, ami riaszt, akár manuálisan), az emailezési szokásoktól függően elég hamar meg tudják tölteni a rendelkezésre álló területet – amikor is a levelezés megáll. Vannak ugyan beépített korlátok az Exchange-ben, hogy bizonyos szint alá ne engedje megtelni a lemezt, de ezen korlátok elérésekor is lehetnek kellemetlenségeink az email-forgalomban. Helyette a javaslat az, hogy minden esetben tervezzük meg a mentést is (adott cégnél “csak” a levelezés állt le, mert az adatoknak, adatbázisoknak volt elég hely – de azok mentése is szükséges!).

Sajnos még mindig nem mindenhol fordítanak kellő figyelmet a mentésekre. Lehetne azt mondani, hogy cégmérettől függ – de nem igaz. Egy kis cégnél is láttam helyesen beállított mentést – ez a (magyarországi viszonylatban) közepes cég viszont nem rendelkezett ilyennel. Amikor felhívtak, hogy nem megy a levelezés, s megtaláltuk a “hiba” okát, fokozottan jeleztem nekik, hogy ez miből eredt, újból megígérték, hogy beállítják a mentést – majd bizonyos idő múlva, amikor ismét megkerestek, ugyanezzel a problémával, akkor már szerencsére hajlottak rá, hogy közösen átbeszéljük és kivitelezzük a végleges megoldást.

WinRM nem megy

február 14, 2019 8 hozzászólás

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: , ,