Archívum

Archive for the ‘Windows Server’ Category

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

Hyper-V VM-ek vCPU

november 23, 2018 Hozzászólás

Bár utána lehet nézni a neten, egyik kolléga tőlem kérdezte meg, hogy „Egy Hoston lévő fizikai processzor magok számánál, lehet-e több magot kiosztani a vm-ek közt?”

Nos, a válasz* nem egyszerű igen vagy nem, hanem attól függ (s itt jöhetne egy kétopciós válasz (2016 előtt és után), de kicsit menjünk részleteibe).

Kezdjük a szerver oprendszerű gazdagépekkel. Ha Windows 2008/R2 fut a host-on, akkor a Microsoft által támogatott vCPU-k száma 4 (azért ez a megfogalmazás, mert technikailag megoldható ennek a határnak az átlépése, de az már nem lesz támogatott).

Ha 2012/R2 a gazdagép, akkor már képbe jön a vendég-gép oprendszere is (szerencsére a 2012 R2 esetén megjelenő Gen2 még nem), ideális esetben számolhatunk 64-el – de max a logikai processzorok száma (Logical processors = Sockets * Cores * HyperThreading).

Ha 2016 vagy 2019-ről beszélünk, akkor még bonyolultabb a válasz, ugyanis képbe jön a VM generációja, illetve a vendég OS fajtája: korszerű OS esetén (2016, 2019) G1 VM-nél 64 vCPU, G2 VM-nél 240 vCPU-ig tornászható fel a szám (még ha fizikailag nincs is annyi, de ez – a méretezés – már egy másik téma). Amennyiben 2012 R2, 2012 vagy 2008 R2-nk van, akkor egységesen 64 vCPU a limit, „sima” 2008 esetén pedig max 8.

Amennyiben Windows 10-es host-ról van szó, akkor kicsit változhatnak a számok.

* Ismerve a kollégát, értettem a kérdését is – ugyanis lehet méretezésre is gondolni, de ő most konkrétan nem azt akarta kérdezni 🙂