Month: December 2012

Exchange patch és egyebek

Nemrég megkérdezték tőlem, miért paráznak az Exchange adminok a hotfixek telepítésétől. Megemlítettem, hogy két olyan esetről is tudok, amikor egy-egy rollup pack hazavágta a rendszert, és a kardjukba dőlt adminokat nem igazán vigasztalta, hogy az MS később visszavonta a csomagokat.

Nos, itt egy újabb csapda. Azt írják az Exchange blogon, hogy habár a Windows Update / WSUS / SCCM mind lelkendezve ajánlja ki az opcionális frissítések között a Windows Management Framework 3.0-t – igen, benne a csábos Powershell 3.0-val – az Exchange 2007/2010-et futtató gépekre inkább ne telepítsük. Ha mégis feltennénk, számíthatunk arra, hogy a rollup packok nem települnek fel, illetve az EMS begolyózik. Szóval óvatosan.

Agysebészet kőbaltával

Nem, most nem Matolcsyról fogok beszélni. Bár vad dolgok ebben az írásban is lesznek.

Habár az előzményekről már esett szó a privát blogomban (itt és itt és itt) – leginkább dühöngés és káromkodás formájában – de itt, ebben az írásban valamelyest újra felelevenítem ezeket, immár higgadtabban és szakmai szemmel.

Tehát a jelenség az volt, hogy 9-én este, amikor le akartam játszani egy videót a médiailag felturbózott Windows 2008 R2 szerveren, elment a hang, illetve beszaggatott a kép, minden lejátszóprogramban. Már amelyik egyáltalán elindult. Bementem a Control Panel / Programs panelbe, kiszórtam az összes Creative programot és drivert, emellett kiszórtam mindent, amit felesleges hulladéknak, telepítési szemétnek tartottam. A videólejátszás rögtön megjavult, a hang nyilván nem, de egyfelől írtam Jánosnak – akitől a hangkártyát kaptam kipróbálásra – hogy mi is ennek a szutyoknak a pontos neve, másfelől megrendeltem egy párezer forintos USB hangkártyát, mert több helyen is írták, hogy a HP ML110 PCI csatija nem annyira szereti a hangkártyákat.
Reggel, még az ágyban, átfutottam az éjszakai leveleket, ott volt benne a hangkártya pontos neve. Gut. Úgy pizsamásan lementem, lekaptam a Creative oldaláról a Microsoft(!) által írt drivert, feltettem, kért egy újraindítást, leokéztam… aztán kék halál.

From Segédlet
From Segédlet

Oké, láttam már ilyet, hibás drivertől nem ijedünk meg. Last good configuration. Megint kék halál. Nofene. Safe mode. Ugyanaz. Ekkor felejtettem a konyhában a kávémat. A safe módban látható volt, hogy a classpnp.sys betöltésével van a baj. Jobb híján rákerestem a neten… és rámdőlt a világ. Mint földrengéskor a tízemelet. Vajákolások, kinlódások, jószándékú, de fogalmatlan topicok, hosszan elnyúlva, aztán egy-két értelmes bejegyzés, melyek azért adtak némi támpontot és ötleteket a továbbhaladáshoz. A továbbhaladást értsd úgy, hogy egyre beljebb a mocsárba. Az első nap végén eljutottam oda, hogy realizáljam, őrült nagy baj van, de még azt se tudom, hogy a Windowsban, a hardverben, vagy a Biosban. János szerint a Creative programozóinál csak az Adobe programozói idiótábbak, szóval ő a maga részéről arra tippelt, hogy a hangkártya driver vágta haza a rendszert. Nekem meg kiesett a fejemből, hogy ez MS driver volt, és hát azért az MS csak nem öli meg a saját rendszerét. Viszont a rossz driver mellett szólt, hogy a Startup Repair is azt üzente, hogy BadDriver. Attól meg végleg kikattantam, hogy egy driver hogyan tud megölni egy szerver operációs rendszert.
Az egész napot pizsamában nyomtam végig, kaja nélkül. Hajnalban hullafáradtan dőltem bele az ágyba.
Reggel folytköv. Pizsama, a dohányzóasztal, mint szék. Éjjel még támadt néhány ötletem, azokat ki akartam próbálni, illetve előkészíteni az újratelepítést. Az ötletek közül egy sem működött, a telepítéshez összeraktam mindent (ez sem volt egyszerű, de most ne részletezzük)… aztán fellázadtam. Hagytam a francba az egészet, reggeliztem, zuhanyoztam, melegítőt cseréltem, főztem egy kávét… szóval megpróbáltam kultúrembert faragni a két napja széjjelfrusztrált gnómból.

Ez a szünet mentette meg a gépemet.

Közben ugyanis a blogbejegyzésben megjelent egy komment, melyben újabb ötletek voltak, illetve nem sokkal később egy másik, amelyikben volt egy link. Egy olyan írásra mutatott, melyet olvasván tátva maradt a szám. Bakker, ez pont az én történetem! Fura volt látni, mert az a több száz bejegyzés, melyet az utóbbi másfél napban olvastam, mind úgy nézett ki, mintha az én esetem lett volna, de aztán mégsem. Ez viszont pontosan az volt.

Amikor telepítettem a segédprogramokat, valamelyik (VLC? K-Lite? DaemonTools? Egyéb?) felajánlotta, hogy felrak egy McAfee Scan nevű cuccot. Habár az MSE már fent volt, de tapasztalataim szerint az eléggé harmatos, ezt a gépet pedig négyen fogjuk gyötörni, köztük két húszéves padaván, szóval úgy gondoltam, inkább több védelem legyen, mint kevesebb. Aztán amikor 9-én este szétesett a gép, nemcsak a hangkártya drivert és segédprogramokat szedtem le, hanem sok egyéb mellett ezt a McAfee cuccot is. Ezzel helyeztem el a pokolgépet a rendszerben. Aktiválni pedig a restarttal lehetett, melyre másnap reggel, a driver telepítésekor került sor. Jó, mi? Azt hinnéd, hogy a driver ölte meg a gépet. A fene sem gondolná, hogy a McAfee Uninstall a háttérben már szétkeffentette a lemezen az oprendszert és az egész gyakorlatilag a memóriából megy.

A KB cikk a McAfee oldalára mutatott, a kettőből szépen össze lehetett rakni a történetet. Létezik egy könyvtár, a %systemroot%\system32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\, ahol úgynevezett .cat katalógusfájlokban található minden szolgáltatásról, driverről és hotfixről minden azonosító adat. (Pontosabban a katalógusfájlok az egyes csomagok fájljairól készített hash-ek gyűjteménye, természetesen szintén aláírva.) Ezekből az adatokból a rendszer kiszed bizonyos információkat és eltárolja azokat a %systemroot%\system32\CodeIntegrity könyvtárban egy bootcat.cache nevű fájlban. Ezt a fájlt próbálja felolvasni a classpnp.sys driver. Ha nem sikerül neki, akkor megpróbálja legenerálni azt a catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár tartalmából. És itt jön a balhé: ha az innen felszedett információk nem egyeznek meg a gép konfigurációjával (értsd driver, service, hotfix szinten), akkor a classpnp.sys eldobja az agyát: kék halál.

Ezek után lássuk, mit csinált McAfee.

Amikor azt mondtam, hogy uninstall, akkor fogta és azt a bizonyos guidnevű könyvtárat átnevezte(!?) temp????.tmp névre, létrehozott helyette egy üres újat… majd a fene tudja, mit tervezett vele, mert ebben a pillanatban tökönszúrta magát és elhalálozott. A gép pedig a következő újraindításkor szembesült vele, hogy a catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár üres. Persze, hogy a classpnp.sys eldobta az agyát. Arra kérlek, hogy ha van előtted akár egy Windows 7, vagy akár egy Windows 2008 szerver, akkor nézzél bele ebbe a könyvtárba. Több ezer .cat fájl. Na, az ott látott szolgáltatások és driverek, illetve pecselt komponensek mind kipurcantak, mert nem volt meg hozzájuk a bootoláskor szükséges információ.
Csoda-e ezek után, hogy McAfee-t le akarják lőni Belizében?
Mondjuk, az is egyfajta understatement, hogy a Windows csak annyit mondott, hogy BadDriver. Bakker, az összes driver és az összes szolgáltatás Bad lett.

A workaround nyilván az, hogy Emergency Repair módban visszamásoljuk a temp????.tmp könyvtárból a .cat fájlokat a guidnevű könyvtárba, a bootcat.cache fájlt pedig töröljük.

Csakhogy. Nálam valahogyan a McAfee Uninstall valamelyik gonoszabb változata garázdálkodott, ez nem hozott létre temp könyvtárat, viszont a guidnevű tartalmát törölte. Ott álltam egy tök pucér katalóguskönyvtárral, úgy, hogy nem volt meg az előző állapot. Nézz bele légyszíves megint abba a könyvtárba! Hogy érzékeld a helyzetet: itt mindennek pontosan klappolnia kell: a drivereknek, a szolgáltatásoknak, méghozzá verziószámra azonosan, és persze jelen kellett lennie az összes patch katalógusfájljának, amelyik a gépen volt. Az a nyomorult classpnp.sys csak akkor indult el, ha minden egyezett.
Jópofa vadászat kezdődött. Először átmásoltam a Windows RE változatból – mely gyk. a Repair Tools opcióval indul el – a .cat fájlokat. Nem indult el. Kaptam egy bootcat.cache fájlt, bemásoltam. Kiröhögött. Újabb ötlet: ott van a szerveren egy csomó virtuális 2008 R2 szerver, szedjük ki azokból a .cat fájlokat. Windows RE alól a diskpart segédprogrammal fel lehet mountolni a vhd fájlokat, kimásoltam a {F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár tartalmát. Nagy levegő. Megint nem indult el. Pedig úgy emlékeztem, a host és a guest gépek azonos pecseltségi szinten vannak. Újabb ötlet: a %systemroot%\servicing\packages könyvtárban ott van az összes hotfix katalógusfájlja, küldjük még rá azt is. Le van szarva, ha több lesz. És igen, ezzel nyertünk: a három helyről összemásolt katalógusfájlokban már megvolt minden, pontosan olyan verziókkal, ahogy az a fránya kényes ízlésű classpnp.sys elvárta. Habár malmozott pár percig, de aztán kék képernyő helyett a Windows logon képernyő jött be.

Ha meglett volna a forgószékem, akkor elégedetten dőltem volna hátra.

Nyilván jött még egy nagytakarítás, a lakás gyk. tele volt romokkal, aztán rendezni kellett a kártyákat, drivereket (a találgatások során szanaszét állítgattam a registry-t), de ez már egyszerű hamupipőke munka volt, szerencsére mindent logoltam egy noteszbe.

Végezetül a Köszönet rovat. Ez az írás nem jöhetett volna létre a Microsoft nélkül. Ez kivételesen nem irónia akart lenni. Onnantól kezdve, hogy délben üdén és tisztán kijöttem a fürdőszobából és megtaláltam azt a bizonyos linket, István vezette a kezemet. Tőle kaptam az ötleteket, az én dolgom csak annyi volt, hogy utánaolvassak, megértsem, mit csinálok, majd végre is hajtsam az újabb és újabb feladatokat. A magam részéről teljesen le vagyok nyűgözve, mert egyrészt ez nem volt hivatalos bejelentés, másfelől, mint kiderült, nem is az MS sara volt az oprendszer halála – mégis teljes vehemenciával dolgoztak a hiba megszüntetésén.
És köszönettel tartozom Jánosnak is, aki a hardver irányában tett kisérletezéseimben segített.
Köszönet mindkettőjüknek.

Hyper-V 2012 + Storage Sapces

Amikor megjelent a Windwos Server 2012 megtetszett a Storage Spaces nevű szerkezet. Azt gondoltam, hogy az új Hyper-V tetején kialakítok egy virtualizált háttértároló infrastruktúrát.

Építettem egy szervert. Az alaplapi 6 csatornás intel RST RAID vezérlőre felraktam 6db merevlemezt. Ebből az első kettőből RAID 1-es tömb készült, a maradék négyet pedig hagytam magában. A RAID tömbre felraktam a Hyper-V Server 2012-t, tettem rá egy virtuális gépet, ami a raiden lévő vhd-ból bootol, és odaadtam neki a maradék négy lemezt pass-through módban. A virtuális gépre felraktam egy Windows Server 2012-t. A virtuális gépen belül pedig a pass-through lemezekből összeraktam egy Storage Spaces Pool-t.

Minden szépen működött. Adat is került az újonnan kialakított virtuális “NAS”-ra.

Elkövetkezett a kies november 19.-ei hétfői nap, amikor is látom a Nagios-ban, hogy jónéhány gépet frissíteni kéne, köztük a virtuális nas alatti Hyper-V hosztot is.

Végigmentem a gépeken, utoljára maradt a Hyper-V. Felmentek a frissítések, újraindult. Elindítottam a különböző virtuális gépeket, minden elindult

kivéve…

a remek virtuális nas-om.

1. pofon:

Közölte a drága, hogy nem tudja felcsatolni a lemezeit. Remek. 🙁

Megnéztem a diskpartban, ahol a boot lemezen kívül nem láttam semmit. Itt kellene lennie négy darab offline disknek.

Az első gyanúsítottam az integrált Intel RST vezérlő meghajtója/menedzsmentje volt. Ilyen ugyanis nincs. Mind a mai napig az Intel nem adott ki hozzá 2012-n működő darabot. Azt feltételeztem, hogy a non-raid diskeket valamelyik hotfix miatt nem látja az operációs rendszer.

Körül akartam nézni a device managerben, hogy lássam mi a helyzet.

2. pofon:

A Hyper-V Szerverből adódóan ez egy core edition. Mint ilyen, nincs device manager rajta.

– Távolról még read-only módban sem lehet device managert indítani, mert ezt, a korábban meglévő lehetőséget a Microsoft eltávolította
Itt írják, hogy tegyük fel a Server-Gui-Mgmt-Infra windows feature-t, de ezt nem tudom megtenni, hiszen ez nem egy teljes Windwos core, hanem a Hyper-V szerver, amin nincs ilyen
– PowerShell alapú device management nem része az operációs rendszernek. Van hozzá letölthető, de ezt valahogy nem akartam feltenni (így utólag kár volt)

Miután nincs device manager, tehát jön a vakrepülés. Nézzük meg, hogy mi történik, ha a lemezeket áttesszük egy másik vezérlőre. Volt a fiókban egy Intel RS2BL040 RAID vezérlő. Gondoltam erre átrakom a lemezeket és meglátom mi lesz.

3. pofon:

Szétszedtem a gépet. Amikor kihúztam az alaplapról a SATA kábeleket, az egyik beakadt és az alaplapi SATA csatlakozó műanyag része jött a kábellel együtt. 🙁 Remek. Alaplapcsere.

Még a kinyírt alaplappal és a fenti vezérlővel megpróbálkoztam.

4. pofon:

A jelzett Intel vezérlő az okosabb fajta. Mint ilyen nem adja tovább az operációs rendszernek a konfigurálatlan lemezeket (JBOD mód). A butábbik testvére az RS2WC040 persze igen. Azt nem mertem megkockáztatni, hogy felkonfiguráljam őket egyesével RAID 0-ának, mert ki tudja mit ír vissza és mi lesz az adatokkal.

Szereztem olcsón (5eFt/db) HP SC40Ge vezérlőket, amik tudják a JBOD módot. Beraktam a gépbe. Semmi sem változott. a diskpart nem lát semmit.

Tegnap reggel nekiálltam, hogy megejtsem az esedékes alaplapcserét. Miután még mindig az Intel/MS hotfix volt a gyanúsított, félreraktam a rendszer eredeti boot lemezeit, és két új lemezre raktam fel a Hyper-V-t minden hotfix nélkül. És láss csodát, még mindig nem látta a hiányzó lemezeim.

Ekkor megfogalmazódott bennem a gyanú, hogy lehet, nem is ott keresgélek, ahol kellene. Mi van, ha a Storage Spaces által felkonfigurált pool-t a Hyper-V szerver maga önhatalmúlag bevételezi.

Felraktam egy teljes Window Server 2012-t, hogy lássak is valamit, vége legyen végre ennek a vakrepülésnek.

Nyertem. 🙂 A device managerben látszanak a lemezek és a Storage Spaces konfig lát egy read-only pool-t (azt amit kerestem). Ezek után találtam is erről egy thread-et a Microsoft support fórumon.

Visszaraktam az eredeti boot lemezeket, rendbeszedtem a konfigurációt. Innen kezdve a Storage Pool-t a Hyper-V szerver kezeli és a Storage Pool virtuális kötetei lettek átadva a NAS-nak pass-through lemezként.

A véleményem, hogy a tipikus “not a bug it’s a feature” esettel állunk szemben. Ezt valaki csúnyán benézte az MS-nél: Ami pass-through az pass-through, teljesen mindegy, hogy a virtuális gép mit rak rá.