Beindítottuk ezerrel a mozgatásokat. Elindultak a Public Folderek és elindultak a felhasználói postafiókok is; a cél az volt, hogy a régi szerverek adatbázisai teljesen üresek legyenek. (Eltekintve egy darab régi szervertől, mert onnan tudtuk elérni a PF adatbázist. Az Exchange 2007 SP1-gyel egyelőre még nem akartuk bonyolítani a rendszert.)
Nem is lett volna ezzel semmi baj… csakhogy az előállt káosz nem működött. Hiába lett alaposan végiggondolva, hiába sikerültek a műveletek előtti tesztek, a valóságban teljesen érthetetlenül alakultak a dolgok. Bizonyos elérések működtek, bizonyos elérések nem. Ha teszteltünk egy elérést, működött, ha használni akartuk a postafiókot, akkor nem. A free-busy mátrixon annyi lyuk volt, mintha sörétespuskával durrantottak volna bele – ráadásul a minta is illogikus volt.
Más lehetőségünk nem lévén, előre menekültünk. Közöltük mindenkivel, hogy _nem_ fogunk hibákat javítani és nem fogunk a rendszer stabilizálásával foglalkozni – ehelyett amilyen gyorsan csak lehet, lepörgetjük a mozgatásokat és kihajítjuk a régi Exchange 2000-es szervereket. (Amilyen gyorsan csak lehet… persze a Public Folderek nem arról híresek, hogy túlzottan kapkodnák a seggüket – és akkor még nem is beszéltem a postafiókmozgatások egyeztetéséről.)
De végül csak elértünk odáig, hogy üres lett a vidéki Exchange 2000 szerver. (Mondjuk, az üres enyhe túlzás: a PF instance-ok között még ott volt egy OAB folder; egy olyan, melyen már nem volt beállítva a kérdéses szerver, mint tulajdonos.) De ettől még nekimentem. Control Panel, Add/remove programs, Exchange 2000, remove. Végigmentünk a varázslón, szervízek leálltak… majd kiírta a következő borzasztóan szellemes üzenetet, minden eltávolítandó szolgáltatásra külön-külön.
Setup failed while (error 0×8000FFFF: An unexpected error occurred.)
Additional information:
An unexpected error occurred.
Ízlelgessük. Garantáltan nem fake, tényleg képes volt az alkalmazás egy ilyen hibaüzenetet a képembe tolni.
Ekkor még nem voltam igazán ideges. Amit az utóbbi években nem tanultam meg Exchange szerver likvidálásból, azt már nem is érdemes tudni. Őszintén szólva, nem is számítottam gyors sikerre.
Elkezdtem a skálázást.
1. Idézet magamtól:
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.
Megkerestem. Teljesen szabályos felhasználót találtam, másik Exchange szerveren lévő postafiókkal.
2. KB279202. Itt találunk különböző módszereket arra nézve, hogyan állapíthatjuk meg, mely felhasználók ragadtak be láthatatlanul egy postafiókba. Végigzongoráztam mindegyik módszert, de nem találtam semmit.
3. Teljes gőzzel beindítottam a guglizást. Rengeteg hivatkozást találtam ugyan rá, de… ezek nagy része más – de azonos kódú – váratlan hibára utalt, a maradékban pedig valami kérdező feldobta egy listára a hibát… aztán néma csend. Senki sem tudott értelmesen válaszolni.
4. Abbahagytam az internet faggatását és használtam egy kicsit a józan eszemet. Mint az közismert (hogy mondta, Safranek?), minden adatbázisnak van egy homemdbbl tulajdonsága, mely tulajdonképpen egy backlist. Egy tömb, mely azon felhasználók DN értékeit tartalmazza, akiknek a homemdb tulajdonságának az értéke az illető adatbázisra mutat. (Azért backlist, mert a visszanyalás automatikus.) Ebből halálpontosan lehet tudni, ténylegesen kik tartoznak még az adatbázishoz. De akárhogy is néztem, mindenhol csak a system felhasználókat találtam, azokat viszont, ahogy Evan is írta, nem érdemes törölni. Nem akadályozzák meg az uninstallt.
5. Maradt volna a durva kiherélés, amelyről itt már írtam. Nem tudom, ki hogy van vele, de én irtózom az ilyesmi brutális módszerektől. Nyilván végső menedékként jó, ha vannak ilyen eljárások is… de kérdés ugye, hogy mennyire lesz megbízható a későbbiekben egy ilyen szétkurkászott szerver. És ezen még fájlszerver volt, mentőrendszer volt… meg mittudomén. Mint ahogy egy erőforráshiányos vidéki telephelyen illik.
6. Nézegettem, nézegettem azt a hibaüzenetet… aztán egyszer csak megtaláltam a gördítősávot – és előjött a hibaüzenet folytatása. Ránézésre valami debug jellegű dolognak tűnt – de nézzük már meg alaposan azt a folyamatot, ahol elhasaltunk.
Function:
CComExchSetupComponent::HrPromptForCDIfNecessary
CComExchSetupComponent::Install
HrPromptForCDIfNecessary – mintha azt mondaná, hogy cédét kér. És mivel nem kap, ezt unexpected (váratlan) hibának tartja. Nézzük csak meg, mi lenne, ha nem a Control Panelből indítanám az eltávolítást, hanem telepítőcédéről? Mi kell ehhez? Telepítő média. Exchange 2000. Péntek délután. Az ügyfélnél. Helyi rendszergazda roppant lelkes, előtúr valahonnan egyet. Igenám, de ez egy vidéki szerver, márpedig a sávszélesség finoman szólva sem acélos. Telefon a vidéki embernek. Ő is talál egy Exchange 2000 telepítőcédét valahol. Amikor elhűltem ekkora mázli láttán, blazírtan megjegyezte, hogy a cédé ott volt közvetlenül a Windows 3.11 telepítő floppyk mellett. Atyám.
A puding próbája az evés. Cédé bele a meghajtóba, telepítő elindít – hibátlanul végigmegy. A szerver megszűnt a továbbiakban Exchange szerverként létezni.
Gondoljuk végig még egyszer, mi történt? Egy program elindult, elkezdett leszedni egy alkalmazást, majd kellett volna neki néhány fájl egy cédéről. Mit csinált? Nem, nem mondta azt, hogy “b+ haver, told már be azt a cédét”, hanem ehelyett beleordította a nagyvilágba, hogy “unexpected error”, majd elszállt. Csak gratulálni tudok mindenkinek, aki részt vett eme csodálatos kód megírásában.
Azt hittem, ebben a projektben többször már nem harapok bele az asztallapba.
Tévedtem.
Recent Comments