Date2008. January 03. Thursday

Tartományi konszolidáció

A helyi erők a migrációt már elvégezték. Amikor odakerültem, már minden kongott az ürességtől.
Az összeszorított fogak közül kiszüremlő kifejezések ennek ellenére már az első körülnézéskor előbukkantak. Ha azt mondom, hogy a megszűntetendő tartomány ebek harmincadján volt, akkor finom voltam. Tartományvezérlő, melyet egyszerűen csak kikapcsoltak és újratelepítettek máshol. Ugyanez Exchange szerverrel is. Az egyetlen fizikailag létező Exchange szerver külön Routing Groupban volt. Némileg cifrázta a helyzetet, hogy a Routing Group Connector-t viszont másfél éve lebontották. A postafiókokat pst-kkel lapátolták át. Kismillió public folder. Szükség van rájuk? Persze! – jött a válasz.

Visszaépítettük az RGC-t. Kismillió replikációs konfliktust jelző levél söpört végig napokon keresztül a levelező szervereken. (Ugye tudjuk, a public folderek a két replikáció közötti párhuzamos módosítások esetén nem az időbélyeg alapján döntik el, melyik módosítás a frissebb, hanem levelet küldenek mindkét módosítónak, hogy csókolom, tessék leharcolni egymás között, kié legyen az érvényes. És itt volt másfél év, replikáció nélkül.)

Végül mindegyik folderről született replika másik szerveren is, így levehettük a példányokat a megszűntetendő szerverről. Ez már csak napok kérdése volt. Az IT vezető itt kezdte el rágni a kefét, hiszen az egész tartománytörlésre egy nap volt ütemezve.
De végre eltűntek a public folderek, lehetett eltakarítani az Exchange szervereket. Rögtön az elsőnél földön koppant az állam: az Add/Remove panel szerint a Windows szerveren két példányban is futott az Exchange szerver. Ráadásul az egyiknek olyan verziószáma volt, mely a hivatalos táblázatok szerint nem is létezett. Fejvakarás. Megpróbáltam mindkettőt eltávolítani. Az egyiknél már a telepítő sem indult el. A másiknál elindult, de amikor azt mondtam neki, hogy mars ki, azt válaszolta, hogy “There is no such object on the server”. Azaz a kettőből elméletileg egy sem létezett. Ismerjük el, azért van abban némi kihívás, hogyan távolítsunk el egy gépről két darab nemlétező Exchange szervert. Feltettem a hegesztőszemüveget, előkészítettem a registry editort, az adsieditet és a szokásos mmc konzolomat. Csak nagy vonalakban:

  • Exchange szolgáltatások leállít
  • Exchange registry beállítások kigyomlál:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DAVEX
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ExIPC
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXOLEDB
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IMAP4Svc
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeActiveSynchNotify
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeADDXA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeAL
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeES
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeFBPublish
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMGMT
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMU
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOMA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSRS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\POP3Svc
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc
  • IIS eltávolít a gépről
  • Másik gép Exchange System Manager programjából az Exchange szerver töröl
  • AD-ból a gép kiléptet.

Egy szerverrel végeztünk. Jöhetett az utolsó Exchange szerver a Routing Groupban. Add/Remove, eltávolít… ugyanaz a hibaüzenet: “There is no such object on the server”. Eszelős guglizás. Ugyan eltávolíthatnám ugyanúgy, ahogy a másikat, de ez akkor is az utolsó szerver, legalább ezt tisztességesen kellene kirúgni. Aztán szerencsés találat, egy newsgroupban azt írják, hogy látszani ugyan nem látszik a postafiókok között, de minden szervernek van egy postmaster accountja is. A következő objektumon – CN=Configuration,DC=SUBDOMAIN,DC=DOMAIN,DC=COM\CN=Services\CN=Microsoft
Exchange\CN=EXCHANGE\CN=Global Settings\CN=Message Delivery – meg kell keresni az msExchAdminMailbox tulajdonságot. Ennek értéke mondja meg, melyik felhasználóhoz van hozzárendelve a postmaster mailbox. Ha ez megvan, akkor adsieditből megnyitjuk a felhasználó objektumát és meglessük a HomeMDB tulajdonságát. Ha ez a letörlendő szerverre mutat, akkor töröljük. Ha nincs már meg a felhasználó, akkor az msExchAdminMailbox tulajdonságnál adunk meg egy másik felhasználót.
És bejött. Egy már ezer éve nem létező service account userre mutatott az érték. Átírtam… és rögtön más hibaüzenettel állt le az eltávolítás. De ez már ismerős volt korábbról. Anélkül, hogy mélyebben belemennék, a HomeMDB értékekhez kapcsolódik egy backlink, a HomeMDBBL, abból lehet kimazsolázni a sunnyogó postafiókokat, lásd KB279202.
Most már semmi akadálya nincs az eltávolításnak. El is indult a folyamat… majd az Information Store leállítása befagyott. Hosszú várakozás után közölte, hogy oké… pedig ádehogy. Újabb fejvakarás. (Csodálod, hogy kopaszodok?) Átnéztem a szolgáltatásokat… hát ilyen nincs. El volt indítva a Site Replication Service. Natív Exchange 2000 organizációban. Az eszem megáll. Leállítottam előre minden szolgáltatást, beleértve az IIS és Winmgmt szolgáltatásokat is – és innentől már tényleg leesett a gépről az Exchange.

A többi már rutinmunka volt. Egy kicsit megpörgettem az ntdsutil-t (metadata cleanup), hogy eltávolítsam a szabálytalanul leállított DC-t, aztán dcpromo az utolsó DC-re végül egy óriási nagy takarítás az AD konzolokból, DNS-ből, WINS-ből, Exchange konzolokból.
Hajnali egy óra és már végeztünk is.

Második felvonásként rendezkedni kellett a gyökértartományban is. Az erdő szintű FSMO szerepeket birtokló tartományvezérlő… minden volt, csak nem acélos. Amennyit fagyott, attól akár Gorenje gyártmányú is lehetett volna. Olyan trükköt tudott, amilyet én még számítógéptől nem láttam: a szoftveres tükör mindkét lemeze külön-külön is látszott: az egyik C: néven, a másik meg talán V: néven. Nyilván ez így nem maradhatott. A FSMO szerepek szerencsére simán átmentek egy másik DC-re, jött volna a dcpromo. Jött is, aztán udvarias köhintéssel megkérdezte, hogy mit is csináljon a rajta lévő enterprise root CA szerverrel.
– Ez mi? – néztem meglepve a rendszergazdára.
– Nem tudom – vonta meg a vállát.
– CA szervernek tűnik – tippeltem.
– Lehet. Tudtam, hogy valahol van egy.
– Kik használják?
– ? – vonta meg a vállát.
Itt a magam részéről befejeztem a munkát. Mondtam, hogy amíg nem tudják, kik és mire használják ezt a CA szervert, addig én nem bolygatom meg. Meg utána sem szívesen, mert CA téren nem mozgok olyan biztos lábakkal. A takarításnak ezt a részét az insource vállalta be. Lementették a CA adatbázist, dcpromo le, operációs rendszer újratelepítése – a CA miatt szigorúan ugyanolyan néven – dcpromo fel, CA telepítés, adatbázis visszatöltés. Itt futottak bele egy pofonba, mert a régi CA hol a C: meghajtóra hivatkozott, hol a V: meghajtóra – amely ugyebár megszűnt. De a srác becsületére legyen mondva, ügyesen összekötözgette valahogy a szálakat. Végül visszamásztak a FSMO-k is.

Aztán jöttek a tartományvezérlő frissítések. Rendben meg is történtek. A rendszergazda éppen a drivereket telepítette fel a vacakabb, immár w2k3 tartományvezérlőre, amikor az úgy döntött, hogy elég volt neki ebből a világból. Olyan szinten szakadt össze, hogy esély sem volt feltámasztani. A fiúk vettek egy új vasat, és arra már közvetlenül w2k3 oprendszert telepítettek. És ekkor derült csak ki, hogy a CA adatbázis ugyan átkonvertálódott w2k3-ra, de az a géppel együtt elszállt. A mentésben lévő w2k formátumú CA adatbázistból meg nem lehet visszaállítani w2k3 CA alá semmit. Mivel közben a tartomány is natív lett, így elég bonyolult forgatókönyvek adódtak a visszaállításra. Olyannyira bonyolultak, hogy az IT vezető úgy döntött, inkább telepítsünk egy új CA szervert. Némileg kellemetlen, hogy még mindig nem lehet tudni, kik és mire használták a régit..
Na, mindegy, a tartomány legalább szépen működött.

Boldog új évet!

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.

  1. Vegyük ki a tartományból majd tegyük vissza. Hevesen tiltakoztam. (Lásd korábban.)
  2. 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.
  3. 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.
  4. 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.
  5. 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.