Úgy kezdődött, hogy Ügyfél egyik középvezetője nem tudta összeszinkronizálni Sony-Ericsson kütyüjét az Exchange szerverrel. (A szinkronizáció nem közvetlen, van egy erre a célra felingerelt Onebridge szerver a hálózaton. Ezt mi üzemeltetjük, de nem mi támogatjuk.)
A hibát kolléga bejelentette az alkalmazás támogatójának, akitől azt a választ kapta, hogy mentsük ki a postafiók tartalmát pst-be, töröljük a mailboxot, majd hozzuk újra létre – és ettől meg fog javulni a szinkronizáció. Sajnos a kolléga elhitte. Megkérte a középvezetőt, hogy másoljon ki mindent pst-be, majd amikor az jelezte, hogy oké, akkor törölt, purgált és újralétrehozott. A szinkronizáció természetesen nem javult meg, de ezzel a szállal a továbbiakban nem foglalkozunk.
A középvezető visszamásolta a cuccait – és reklamált, hogy valami nem stimmel, nem találja a kontaktjait. Egyeztetés után kiderült, nem tudta, hogy a Contact foldert is ki kellett volna másolnia. Legyünk már olyan kedvesek és állítsuk vissza az eredeti állapotot.
Ekkor jöttem be a képbe én és egyből elszürkült a tekintetem. Mentések természetesen vannak, de ez a purgált, majd újra létrehozott postafiók semmi jót nem ígért. A dumpsteren keresztüli visszaállítás természetesen szóba sem jöhetett.
Elsőkörben be kellett izzítani a Recovery Storage Group-ot az Exchange szerveren, felvenni a piszkálandó adatbázist. Gyors ellenőrzés a registryben: a HKLM\System\CCS\Services\MsexchangeIS\ParametersSystem kulcs alatt a Recovery SGOverride értéke nehogy 1 legyen, mert akkor a visszatöltés fejbevágja az eredeti adatbázist. Nyilván még helyet is kellett keresni a logoknak és az adatbázisnak, ennek megfelelően korrigálni az adatbázis adatlapját – és be kellett állítani, hogy az mentésből felülírható legyen.
Ennyit az előkészületekről, jöhetett a Tivoli Exchange kliens. Itt ért az első kellemetlen meglepetés: az aktív mentések sorából pont kicsúszott az a mentés, amelyre szükségem lett volna, az összes mentések listájának felolvasása meg jó másfél órába telt. Bejelöltem, hogy melyiket szeretném visszaállítani, aztán hagy szóljon.
Jó egy óra után, 99% körül elszállt a visszaállítás, miközben a szerver felsikított, hogy betelt a C:\. Amikor ennek a partíciónak a közelébe sem lett volna szabad mennie. Rövid bogarászás után megtaláltam, hogy a saját profilom verte ki a biztosítékot, simán felhízott 2,5 gigára. További bogarászás után azt is megtaláltam, hogy a Tivoli kliensben üres a temporary directory beállítás; a kis okos tehát a profilomba szemetelt. Kiganéztam, megadtam neki egy másik lemezt és újrakezdtem. Másfél óra a listáig, egy óra a visszatöltés.
Exchange sp1 óta a Recovery Storage Groupból elérhető a Mail Merge funkció (egyfajta lebutított Exmerge), ez nekem tökéletesen megfelelt. Kiválasztottam a másolás alfolderbe opciót és elmentem haza (1.5 GB; 20000 item).
Másnap leellenőriztem a kontaktokat: a folder üres volt. Miaszösz? Dismount, törlés, kezdjük újra az egészet. A másfél órás listavisszatöltés után megvizsgáltam a Tivoli klienst és azt találtam, hogy alapban be van kattintva az automatikus kijelölés opció. Tehát amikor kijelöltem a korábbi adatbázist, akkor ő a biztonság kedvéért végigjelölte a következő teljes mentésig a logokat is és persze a visszatöltés után rá is játszotta azokat – azaz visszakaptam egy olyan állapotot, amikor már az új postafiók volt az adatbázisban.
Kíváncsiságból kipróbáltam, mi történik, ha nem jelölök ki log visszatöltést és nem kérek rájátszást. Visszatöltés előtt figyelmeztetett, hogy lehet, hogy nem fogom tudni felmountolni az adatbázist. És milyen igaza volt: tényleg nem tudtam. Törlés, kezdjük előlről. Bejelöltem a megfelelő adatbázist, kikapcsoltam az automatikus kijelölést, bejelöltem az aznapi logokat (csak azokat!), kértem a rájátszást és beállítottam a temp directoryt.
Nna, így már sikerült.Ezt abból is észre lehetett venni, hogy ekkor már nem működött a Mail Merge. De még az Exmerge sem. Egyik sem találta a produkciós adatbázisban a recovery adatbázisbeli postafiók párját. Nyilván nem, mert ugye törölve lett, purgálva lett, sóval behintve lett. A felhasználóhoz rendelt postafiók már vadiúj volt, akkor is, ha minden látható név ugyanaz volt rajta. Nem kicsit frusztráló, hogy a kezelői felületen ott látom a mailboxot, de képtelenség kimenteni a tartalmát, mert minden eszköz merge műveletre van tervezve; ahhoz meg kell a régi postafiók. Pst-be másolás? Felejtsd el.
Iránya jó öreg google haver. Első körben itt van egy link; azt írják, hogy milyen állapotai vannak egy postafióknak és milyen állapotokban van esély visszaállításra. Purgálás után pl. semmi. Aztán a cikk végén felcsillantottak egy lehetőséget, megadtak egy másik cikket. Ennek már a címe is izgalmas volt, azt mondta: “Hogyan állítsunk vissza purgált postafiókot“. Átolvastam. Fejvakarás. Átolvastam még egyszer. Kezdtem érteni. Zseniális! Hogyan hekkeljük meg a Recovery Storage Group-ot? Először töltsük vissza az adatbázist az RSG-be, ahogyan kell, mountoljuk fel, majd azonnal le. Fontos, hogy ez simán történjen, érdemes a státuszt rögtön leellenőrizni az ’eseutil /mh’ paranccsal.
És itt jön a trükk: nevezzük át az adatbázis fájlokat, pakoljuk át máshová, csináljunk neki produkciós storage groupot, abba csináljunk neki adatbázist és mountoljuk fel.
Nem, nem kell a szívünkhöz kapni, nem lesz innentől kezdve mindenkinek két postaládája – ugyanis amikor felmountoltuk az adatbázist a Recovery Storage Groupban, akkor automatikusan minden postafiók lecsatolt állapotba került és ez a dismount során igy is maradt. (Mondjuk a zabszemteszten nem mentem volna át, amikor csatlakoztattam; mondtam már, hogy ez a VIP adatbázis volt?)
Most előreszaladtam egy kicsit, mert közben azért bejött a képbe a Nagy Harci Fasz.
Amikor ugyanis megértettem, hogy mit kell csinálnom, nekiálltam dismountolni az RSG adatbázist. Nem sikerült, a System Management konzol befagyott. Vártam másfél órát, majd kilőttem a Task Managerből. Kolléga összedugta fejét az ügyfél kapcsolattartójával, este hétkor engedélyezték a szerver újraindítását. Fél nyolckor jött a telefon, hogy gáz van, az Exchange szolgáltatások nem indultak újra. Fél nyolc után öt perccel jött az újabb telefon, hogy nagyobb gáz van, tkp. a szerver nem is állt le, csak úgy lebeg élet és halál között. Oké, irány a Dataplex. Érdekes látvány fogadott: a szerver működött, csak éppen a távoli elérést biztosító szolgáltatásai haltak el. Az egész leállási folyamat az Information Store leállására várt, az viszont beragadt ’stopping’ állapotba. Egyébként a szerver köszönte szépen, jól volt. Az eseménynaplót percenként szemetelte tele a System Attendant, hogy nem tud leállni, mert az Exchange szerver nem elérhető. Elég hülye kifogás. Megnéztem a Filemon cuccal, hogy egyáltalán mi történik: semmi különös, a store.exe egyfolytában a temp könyvtárat csesztette. Az adatbázisok viszont ott vigyorogtak lezáratlanul. Ezután dehogyis mertem kigyilkolni az IS-t. Ahogy a szakirodalom is mondja, ilyenkor kell felhívni a a Microsoft Premier Support-ot: hagy harapjanak ők is egy jó nagyot a felelősségből.
Tudom, minden rendszermérnök életében eljön az a pillanat, amikor éles szituációban be kell jelenteni telefonon egy hibát az amerikai PSS-nek. Ez, úgymond, egyfajta evolúciós lépcső. De nem hiszem, hogy mindenki annyit szerencsétlenkedik vele, mint amennyit én.
Ott kezdődött, hogy a szerverszobában 40-50 szerver duruzsolt a fülembe. Ki lehetett ugyan menni a folyosóra, de ott meg nagyon figyelni kellett a padlólapokat, mert tény, hogy bizonyos lapoknál elmegy a térerő. És persze a teljes kommunikáció egy pici mobillal történt.
Nos,én voltam annyira zöldfülű, hogy már rögtön az első hapinak nekiálltam magyarázni a technikai problémát, bőven ecsetelve az előzményeket. Kicsit ugyanis ideges voltam, mivel ez az ügyfél fő produkciós levelezőszervere volt, a kapcsolattartó pedig elnézte a dolgot, a cég legfontosabb projektjében ma kellett volna külföldre küldeni bizonyos záródokumentumokat.
(Ugyan javasoltam nekik, hogy küldjék el privát postafiókból webes felületen, de azt kaptam, hogy na ne már, verziókövetés van, előzmények vannak, subject kódok vannak, nekik válaszolni kell az előző levélre. Fóti Marci örökbecsűje jutott eszembe: ‘Az informatika még nem érte el azt a biztonsági szintet, hogy rábízzuk az életünket – de mi rábíztuk.‘)
Szóval egyáltalán nem lepődtem volna meg, ha megtudom, hogy az ügyfél verőemberei már melegítenek valahol.
Ehhez képest gyönyörűen elbeszéltünk egymás mellett: én állandóan a problémámat hajtogattam, a hapi meg állandóan azonosítgatni akart: Mi a cégem azonosítókódja? Mi az én azonosítókódom? Mit tudom én! – sikítoztam.
Végül javasoltam, hogy hagyjuk a fenébe az egészet, van hozzáférésem az Online Premier Support oldalhoz, majd bejelentem írásban. (Ott már valamikor hozzá lett rendelve a .net jelszómhoz az egész miskulancia.) Hát, az ötlet jó volt, de valamiért nem akart összejönni a belépés.
Végső kétségbeesésemben felhívtam a TAM-ot. Kolléga szerint nem koránfekvős fajta; Isten tartsa meg a szokását, ébren volt most is. Kikereste nekem a szükséges kódokat és elmagyarázta, hogy az első ember technikailag zokni, annak csak az a dolga, hogy beazonosítson. És azt is javasolta, hogy ha olyan helyen vagyok, ahonnan rosszul hallom a szöveget, kérjek Translation Service-t. Ingyenes és minden nyelvre meg van szervezve. Remek. Megkértem, hogy küldje el az adatokat az otthoni címemre, majd webfelületről leszedem. 10 percig vártam, nem jött semmi. Egy kicsit téptem a hajamat – tényleg csak egy kicsit, aztán valahogy összehegesztettem a céges OWA elérést – lassú is volt, bizonytalan is, de a miénk… és működött. Oda is megkértem a levelet és megjött.
(Másnap esett le: otthonról olyan gyorsan jöttem el, hogy bejelentkezve maradtam a gépemnél – és persze, az Outlook pop3-mal mindig lekapta a levelet. Elmehettem a búsba a webfelülettel.)
Mindegy, megtanultam a leckét: company id nélkül ma már sehová se megyek; itt fityeg a PDÁ-n.
Innentől kezdve már csak egy óra kellett, hogy eljussak a technikai emberhez. Mondjuk az idő nagy részét az tette ki, hogy vártuk a Translation Service-t, aki végül ezen a napon nem jelent meg.
A többi már viszonylag simán ment: elmondtam a problémát, a hapi elkérte az applikációs logot (16MB – bizonytalan OWÁ-n keresztül…), majd némi fejvakarás után közölte, hogy nincs más hátra, gyilkoljam ki a store.exe-t. Eddigis hülyén nézhettem ki – gondolom, a dataplexes fiúk jót szórakozhattak a monitorszobában, hogy percenként rohangászok ki a folyosóra (sorry, I’ll go out… please repeat it…), utána meg vissza a gépterembe, minden alkalommal beriasztva őket… de ezt a lépést már nem voltam hajlandó pusztán szóbeli utasításra meglépni. Megkértem a fazont, hogy írja le emailben, mert nem hallom jól, amit mond. Leírta, kigyilkoltam, újraindítottam és felállt minden. Mármint szolgáltatás. Mondjuk az alatt az öt perc alatt, amíg az IS húzta a csíkot, öregedtem egy kicsit: 8db adatbázis figyelt a gépen, összesen olyan 600 GB méretben. Ha az IS nem indult volna el egyből, akkor életem végéig mentésből kellett volna adatokat töltögetnem.
De elindult. Már csak azt kellett kinyomozni, mi a lószar volt ez? Délután is, amikor nekem beragadt a System Manager és este is, amikor a leállítás ragadt be, a víruskergető jegyzett be gyanús hibaüzeneteket a logba.
Ez egy hálás toposz, exchange adminok előszeretettel szeretnek mindent ráfogni a víruskergetőre – és nem is ok nélkül.
Csak a rend kedvéért, hogy mi mindent tud okozni egy rosszul beállított víruskereső:
-A fájl szintű víruskereső megfogja az exchange adatbázist. Information Store nem fér hozzá, kardjába dől.
-A fájl szintű víruskereső karanténba dobja a tranzakciós log egy-egy fájlját. Information Store kardjába dől, a rendszergazda szintén.
-Ilyenről is olvastam: ha nincs elzárva a fájl szintű kereső elől az exchange szintű kereső temporary könyvtára, akkor a fájlszintű kereső ráharap az ideiglenes állományokra és lefagyasztja az exchange víruskergetőt. Még jó, hogy egy cégnél dolgoznak a fiúk. Bár a cikkben büszkén írták, hogy az ő termékük egy ilyen crash után képes meggyógyítani magát, nem kell újratelepíteni.
Nos, lássuk csak, nálam mi történhetett. Visszatöltöttem mentésből az adatbázist,és… hoppá. Nem a szokott helyre töltöttem, mert ott nem volt elég hely – ehelyett egy másik partíción csináltam neki egy könyvtárat. Kitiltottam belőle a fájlszintű víruskergetőt? Bizony nem. Megint hoppá.
–Mekkora farok vagy, Joep – mormogtam hajnalban – ekkora potyagólt a te korodban már nem illik kapni.
És jobb későn, mint soha alapon bementem a víruskereső konfig menüjébe, ahol… meglepetten láttam, hogy az aranykezű kolléga korábban az egész partícióról kitiltotta a víruskeresőt. Tehát farok vagyok ugyan, de szerencsére megúsztam, nem én hibáztam.
(Mondjuk ekkor már voltam annyira fáradt, hogy a folyosón nekimentem az ajtónak: valamiért azt hittem, hogy ki fog nyílni magától. Pedig öreg dataplexes vagyok, pontosan tudom, mely ajtókat kell ballal húzni és melyeket jobbal tolni. Komolyan mondom, kész szerencse, hogy az ügyfél nem látja, hogy milyen állapotban hajt végre életveszélyes műtéteket időnként az üzemeltető.)
A magam részéről itt abba is hagytam a nyomozást egy ‘holnap is nap lesz‘ rikkantással.
Úgyis lett. Első lépésben kikapcsoltam a fájlszintű keresőt. Aztán megnéztem, hogy is áll az RSG adatbázis. Az eseutil szerint a státusz: Dirty shutdown. Hát, nem pont ez állt a cikkben. Adatbázis fájlok törlése, logok törlése, Tivoli. Másfélóra várás a listára, az egyetlen lehetséges kombináció összekattogtatása,visszatöltés. Aztán elindítottam egy Filemont, hogy lássam mi is történik mountolás/dismountolás közben. Semmi érdekes. A store.exe gyanúsan sokszor piszkálta a temp könyvtárat, mely nem volt kizárva a fájlszintű ellenőrzés alól. Kizártam. Az exchange szintű kereső ideiglenes könyvtárát is. Meg kiterjesztés alapján is kizártam az Exchange fájlokat, nemcsak könyvtárnév alapján.
Aztán megint net és kiderült, hogy teljesen rossz nyomon jártam: az az applikáció, mely teleszemetelte a logot a lefagyások előtt, az nem a fájlszintű víruskereső, hanem az exchange szintű. Itt dobtam egy négylábas megadást; összeszedtem a bizonyítékokat és elküldtem a feljelentést a gyártó képviselőjének.
Sokkal jobban izgatott, hogy mi lesz a középvezető kontakt listájával. Az újabb visszatöltés, mount/dismount után az RSG adatbázis státusza szépen Clean shutdown lett, tehát kezdődhetett a hekkelés.
Új, produkciós storage group létrehoz, adatbázis definiálódik. Természetesen másik könyvtárban, a biztonság kedvéért átnevezve. Utána adatbázis fizikailag is átmásolódik, átneveződik, nagy levegő, mount. Egyből jött is a hibaüzenet: adatbázis nem található. Kezdő exchange adminokra ilyenkor törhet rá az az érzés, hogy sürgősen keresni kell egy konnektort vizeletürítési céllal. Ne tegyétek. Sokkal praktikusabb odasétálni a pár méterre lévő darts táblához(1), leemelni a nyilakat és önfeledten hajigálni 10-15 percig. Ha esetleg átfúródik a táblán, nem gond, a fal azért megfogja. Ahogy eltelik az idő, az Active Directory csak szétreplikálja az egész hóbelevancot – és már mountolható is az adatbázis. És igen, mindegyik postafiók le volt csatolva. Nyertünk.
A doksi szerint meg kell keresni a diverzáns postafiókot és hozzávágni egy dummy felhasználóhoz. (Melyet természetesen megcsináltunk, miközben az AD replikációt vártuk.) Oké, dobjuk meg egy postafiókkal. (Sánta, van púpod? Nesze!)
Megint hibaüzenet jött: azt mondta, hogy az a legacyExchangeDN, mely ehhez a postafiókhoz tartozik, már másik felhasználóhoz van rendelve. Hja, mindenre mi sem gondolhattunk. Persze, könnyű a doksinak, ott nem feltételezték azt, hogy purgálás után rögtön újra létrehozzák az új postafiókot a régi felhasználóhoz.
Végülis, nem olyan nagy gond ez, a középvezető user adatainál átírtam AdsiEdittel a legacyExhangeDN értéket valami marhaságra, a recovery usernél átírtam a jóra, 10 perc darts és már csak be kellett pöckölni a labdát: a régi postafiókot hozzá tudtam rendelni a recovery userhez, megnyitottam outlookból mind a két postafiókot és átmásoltam azt a szájbanyomott kontakt listát a pacákhoz. Finita.
Persze még hátravolt a takarítás. El akartam tüntetni ezt a hibrid adatbázist, mert valahogy nem vagyok nyugodt, ha ilyenek kóricálnak a szerver körül. (Jártam már úgy, hogy törölt felhasználók valahogy megtalálták az RSG adatbázit és boldogan csatlakoztak hozzá.) Viszont az sem kizárt, hogy a hapi pár nap múlva veszi észre, hogy valami még kell neki. A tiszta munka átmozgatni a postafiókot egy létező adatbázisba, a hibridet meg lecsatolni, letörölni.
Másolás elindult. Az alkotó hátradőlt és várta, hogy besöpörje a hálás telefonhívások özönét. Ehelyett a helyi kolléga telefonált, hogy a középvezető igen zabos, mert fontos levelet vár, de semmilyen levelet nem kap meg; az összes levele valamilyen recovery usernél landol. Hoppá.
Elfelejtettem visszaírni másolás előtt a legacyExchangeDN értéket. Hát… most már meg kell várni a folyamat végét. 1,5 GB, 20000 item, 30 perc darts.
Az indikátor kijelzi a 100%-ot, majd a másolás könnyed sóhajtással befagy. Ez a szerver nem fér a bőrébe. Szerencsére ezen a területen már megszívtam az összes megszívnivalót, tudtam, mit kell tenni.
Hagy idézzek egy korábbi írásomból:
Végülmár csak ketten maradtunk a porondon: a 4.6 GB méretű mailbox és én. Szembenéztünk egymással, a szél ördögszekeret sodort keresztül az úton. Hirtelen mozdulattal rávetődtem a billentyűzetre és megismételtem a másolási parancsot – de most egy másik adatbázisba. Két óra szuttyogás után megint behalt a másolás… Task Manager, kilőni. Most már 3 példányban volt meg a mailbox – és mind a 3 működött. Egyszerre. Ha elvettem az egyiket a felhasználótól, mind felszabadult. Ha visszaakasztottam rá az egyiket, akkor a többit sem lehetett törölni, mert azt mondta, hogy használatban vannak. A helyzet kezdett kínossá válni. Végül kimentegettem az anyagot pst-kbe, lecsatoltam a mailboxot, töröltem a két rosszat, a maradékot visszacsatoltam – és gyönyörűen működött. Nem sokat dobott a kedvemen, hogy közben megtaláltam a helyes megoldást: a behalt mozgatást kilövés után folytatni kell _ugyanabba_ az adatbázisba, amelyikbe elkezdtük. Szószerint azt írták, hogy az Exchange van olyan intelligens, hogy észreveszi a sikertelen másolás darabjait. Usually. Hát… engedtessék meg nekem a kétkedés joga.
Nos, tulajdonképpen szerencsésnek tarthatom magam: lehetőségem volt kipróbálni, hogy milyen brilliáns hibajavító algoritmust tartalmaz a mailbox move folyamat arra az esetre, ha egy postafiók mozgatás 100% elérése után fagyott le. Tippelj.
Az nyert, aki arra voksolt, hogy nemes egyszerűséggel letörli a félbehagyott postafiókot és azt mondja, hogy kezdd újra, Gézám.
De legalább vissza tudtam állítani a legacyExchangeDN értéket. Újabb 10 perc darts és a középvezető megnyugodhatott: ő lett ő és megvolt a kontaktlista. Aztán végül nem töröltem semmit, lecsatoltam a recovery userről a postafiókot és dismountoltam az adatbázist.
Ősi cowboy szólás, hogy csak a dismountolt adatbázis a jó adatbázis.
Most már tényleg hátradőlhettem: megoldottam a lehetetlent, csak egy kicsit várni kellett rá. A kiajánlott (és kifizetett) 4-5 óra helyett 33-at.
Persze igazán nyugodt nem lehetek: kiváncsi vagyok, mikor veszi észre, hogy a Calendar is üres. Ekkor leszek igazán bajban: fogalmam sincs, hogyan lehet egy Calendarnak azt mondani, hogy select all, aztán copy másik mailbox. Hallottam már olyan emberről, aki látott olyan embert, akinek pst-n keresztül már sikerült ilyesmi – de arról is kiderült, hogy más volt.
(1) Ne mondd, hogy nincs. Nem lehetsz ennyire kezdő a szakmában.
Recent Comments