Valamelyik népművelő csatornán láttam régebben egy filmet a német tengerészet csúcs hadihajójáról – és arról, hogyan sikerült elsüllyeszteni. Ez jutott eszembe, ahogy a tegnapi éjszaka során folyamatosan süllyedtem én is a letargiába.
A hadihajó a világ egyik legerősebb hajója volt. Tulajdonképpen sebezhetetlennek készült, egy apró hibával. Ha megfelelő szögből belőttek az egyik tatbudi 10 centis ablakán, akkor eltalálhattak valami robbanásveszélyes berendezést, melytől levegőbe röpülhetett a tatfedélzet.
Az egészről film volt. Látszott a viszonylag kicsike angol hajó és a bazi nagy német hadihajó, ahogy szép kényelmesen fordul oldalra, hogy lesorozza a felszínről az angol jószágot. Aztán egyszercsak valamelyik angol belepukkantott egyet a nagyvilágba – és mit ád Isten, a lövedék pont bement a budiablakon, a hajó meg fordulás közben épp a kritikus szögben volt. A következő pillanatban felrobbant a német hajó segge és szép lassan befordult az egész a tengerbe.
Képzeld el, hogy van egy címtárad, meg egy Exchange szervered. Az ügyfelünknek is volt. Aztán január másodikán hajnali négykor a vacak, kifejezetten csak tartalékcélokra szolgáló PIII WS kategóriájú DC2 merevlemeze diszkrét pukkanással elhalt. Dugovics Tituszként magával rántott egy computer objektumot is a címtárból.
Ez még nem olyan nagy tragédia: a DC-t ki kell irtani, újat kell rakni helyette, a computer accountot meg resetelni kell. Mint ahogy Cary W. Shulz – Active Directory MVP – is írja:
There are user account objects just like there are computer account objects. The computer account objects have a secure channel with a Domain Controller. Over this secure channel the workstation and the Domain Controller communicate. In WIN2000 the computer account objects change their secret password every 30 days ( in WINNT 4.0 it was seven days ). Sometimes this secure channel gets flubbed up…for whatever reason. So, based on what I just wrote you can see how this can create a little bit of a problem. So, in order to resolve the problem of the flubbed up secure channel you Microsoft gives us the ability to reset that secure channel.
Illetve később Bizonyos Steve hozzáteszi:
In that scenario I would reset the Computer account first before trying the remove/add to domain. This works for me 99% of the time, the 1% usually require the remove/add method.
Csakhogy… gondolj bele, mi történik akkor, ha a flubbed account pont egy Exchange Server computer accountja – és bejön az 1%, azaz az account reset sem segít.
Hagyok időt végiggondolni.
A fent említett remove/add módszer értelemszerűen nem működik. Pontosabban meg lehet csinálni, de onnantól az Information Store az életben sem fog elindulni.
Az esetet a kollégám kapta tüdőre. Reggeltől estig a tartományt foltozgatta: vacak DC eltávolítása, tartományi replikáció beindítása, kismillió anomália megszűntetése, új DC üzembeállítása, makacs account resetelgetés… nem segített. Este héttől váltottunk, mint a pankrátorok: arénából ki, arénába be, high five.
Mit láttam?
- Az Exchange szerveren a szolgáltatások leállítva, mert minek fussanak.
- Az Exchange szerveren a tartományba belépni nem lehet: azt mondja, nincs olyan account.
- A netdom join azt mondja, hogy már van ilyen account.
- Amikor elrontom szándékosan a jelszavamat, akkor azt írja, hogy rossz a jelszó. Azaz a DC – és az AD – elérés tökéletes.
- Amikor kitiltom a computer accountot, akkor azt írja, hogy ki van tiltva. Az AD acélos.
- Próbaképp egy munkaállomás beléptetése: tökéletes.
- Az eventlog alapján az account “Access Denied”.
- Ha everyone full control-t állítok rajta, akkor is.
Brainstorming.
- Vegyük ki a tartományból majd tegyük vissza. Hevesen tiltakoztam. (Lásd korábban.)
- Promotáljuk DC-vé, majd az account reset után demotáljuk vissza sima szerverré. Újabb heves tiltakozás. (A dcpromo és az Exchange nem férnek meg egy csárdában. Ha ráküldjük egy Exchange szerverre, akkor tönkrevágja az IIS-t meg az asp.net-et, újra kell húzni mindkettőt. És utána belassul, meg össze-vissza működik. De a fekete leves a következő lépés: demotáláskor az IIS és az AD megszűnik egymással kommunikálni. Nem csak a kérdéses szerveren, hanem az egész organizációban. Nem kicsit durva.
- Gondolkozzunk. Mi mehetett tönkre? Az AD szépen működik. Az Exchange számítógéphez nem nyúlt senki, az adatbázisok tutira jók. A network, névfeloldások tökéletesek. Ha valami itt elromlott, az csak a computer objektum lehet.
Hmm… állítsuk vissza. Elméletileg létezik korlátozott hatósugarú autoritatív restore. - Megpróbálkozhatunk egy éles Exchange disaster recovery-vel is. Persze, tudjuk, hogy az Exchange tökéletes, de ha eljátszanánk, hogy ugyanazzal a névvel átraknánk az Exchange szervert egy másik gépre, talán ki tudnánk erőszakolni egy account reset-et.
- Persze nem kizárt, hogy az az elkefélt computer account ellenáll ennek az invitálásnak is. Akkor nincs más hátra, csinálunk egy új Exchange szervert más névvel, átmásoljuk rá az adatbázisokat, a felhasználóknál – szerencsére nincs sok – töröljük az Exchange tulajdonságokat, majd létrehozunk mindegyiknek egy új postafiókot, MAPI profilt, a régi Exchange szervert kiradírozzuk, végül egy offline adatbázismatyizóval kiszedjük pst-kbe a régi leveleket és visszalapátoljuk a felhasználók postafiókjába. Elég gusztustalan, de B tervnek megteszi.
Az utolsó három igéretesnek tűnik. Tudjuk, csak a kombinált bérlet a biztos. Ilyen sorrendben pont jó is lesz nekiindulni az éjszakának.
3. pont. Ahhoz bizony kell egy system state mentés is.
– Van? – kérdezem a helyi rendszergazdát.
– Persze – vágja rá.
Aztán nem sokkal később jön a helyesbítő telefon.
– Volt – közli – Azon a merevlemezen tartottuk, amelyik elpukkant.
Feltúrjuk a gépeket, az egyiken végül beleakadtunk egy két évvel ezelőtti systemdrive+systemstate mentésbe. Volt már akkor ez az Exchange szerver? Éppenhogy: 3 hónappal előtte lett telepítve. Nagyon necces. Nézzük csak, hogyan működik Windows 2000 szerveren az autoritatív restore? Aszongya, belépünk Directory Restore módban, visszatöltünk egy komplett systemdrive+systemstate mentést(!), majd ntdsutil-lal kijelöljük, melyik OU-t akarjuk megtartani, utána újraindítjuk a gépet, mely magára rántja az AD-t. Hát… ennek csak egy veszélye van, az, hogy működik. Gondoljunk bele, visszarántunk egy két évvel ezelőtti állapotot. Lehet, hogy akkor még nem is maguktól tekertek a bitek az alaplapon, hanem kis zöld emberkék hurcolászták őket. Aztán a systemstate… az nem csak az AD-t jelenti, hanem rengeteg operációs rendszer szintű adatbázist is. Azzal, hogy visszarántom az AD-t, az összes többi pókhálós cucc ottmarad. Esetleg azt tudom megcsinálni, hogy mielőtt belevágok, csinálok egy másik systemdrive+systemstate mentést, az első autoritatív restore után visszaröffentem a computer account-ot, ezzel megnövelem az UID-jét, majd csinálok egy non-autoritatív restore-t, melyet teljesen felül fog vágni a jó AD és visszakerülnek a rendszerkomponensek is a helyükre.
Ezzel csak két baj van.
- Egyfelől egyáltalán nem biztos, hogy a két évvel korábbi állapotú DC be fog tudni lépni a tartományba. Meg ugyan nem esküdnék rá, de úgy rémlik, van valami korlát, ameddig felhasználható a mentés.
- Elég rizikós egy pici tartomány hegesztésekor egy baromi nagy AD-t belengetni, felvállalni az inkonzisztencia kockázatát.
- Végül azt írja a manuál, hogy egy ilyen restore során egy csomó AD elem by design tönkremegy. Látható is a blue-frame jellegű elvből, hogy mindent visszarak, még akkor is, ha nem kellene, és abba vág majd egy maszkot. Azaz optimáis esetben visszaáll a computer account, de elszállnak a backlist értékek, az FRS replikáció, a RID pool… meg ilyenek.
Jé, ez három…
Ettől függetlenül ezt az utat túl kockázatosnak ítéltem. Ha a DC 2003-as lenne, a mentés pedig 30 napon belüli, akkor esetleg, de így… inkább nem.
Ennyit az egyenes útról. Nézzük a görbéket.
A korábbi disaster recovery cikk sem rossz, de az igazi recept Petrinél található. Mielőtt bármit is csináltunk volna, a helyi rendszergazda a régi Exchange szerver adatbázisait elmentette félre egy másik hardveren, felhúzott egy nagyjából ugyanolyan operációs rendszerű gépet (oprendszer, SP, patch, Windows komponensek – különösen az utóbbi a fontos). Ezután lehúzta a netről a régi szervert, az újnak átírta az IP címét, én a a nevét, közben reseteltem a computer accountot, majd beléptettem az új szervert a tartományba. Áttörtünk. (Mondjuk elsőre elhűlt bennem a vér, mert egy lépésen belül próbáltam átnevezni is meg beléptetni is a gépet, de az éber – akkor már durván 30 órája ébren lévő – helyi rendszergazda szerencsére figyelt… és a második kisérlet már sikerült.)
Innen már simán ment minden, úgy, ahogy Petri bácsi leírta. A végén extra bónuszként az is összejött, hogy egyszerűen visszamásoltam a korábbi adatfájlokat és az IS szó nélkül felmountolta.
Délután fél egy.
Nem sokkal szilveszter után. Mondanom sem kell, hogy a kollégám is, meg én is szabadságon vagyunk.
De így jár, aki az informatikusok bohó szakmáját választja.
ps.
Éppen befejeztem a jegyzőkönyvet – addig kell írni, amíg emlékszem, mi is történt pontosan – amikor csörgött a telefon. A Service Desk szólt, hogy jött egy bejelentés, miszerint megint nem megy a levelezés az ügyfélnél. Sóhaj, enyhe káromkodás, irány vissza. Átnézni a konnektorokat egytől-egyig, tesztlevelek innen-oda, meg vissza… minden működik. Még be sem fejeztem, amikor újból csörgött a telefon. A felhasználó pontosított, azt szerette volna mondani, hogy reggel nem ment a levelezés.
Délután fél öt van.
Köszönjük, az Ön hívása fontos nekünk.
Recent Comments