Tagexchange 2007

Kinyírják SIS-t?

A szemetek.

De tényleg. Egy kicsit nem figyelek oda és majdnem lemaradtam egy érdekes fejtegetésről. Arról van ugyanis szó, hogy létezik az Exchange adatbáziskezelésében egy metódus, az a neve, hogy Single Instance Storage, azaz SIS. Vén, mint az országút, már az Exchange 4.0-ában is létezett. Az elv lényege az, hogy ha egy levelet több embernek is elküldtek, akkor adatbázison belül csak egy példány létezett belőle, a felhasználók postafiókjaiból pedig pointer mutatott erre az egy példányra.

Nos, az Exchange2007 esetében úgy döntöttek, hogy nem igazán van szükség SIS-re. Miért is? Először is a – maximálisan lehetséges – 50 adatbázis miatt. Ha ugyanis kellően nagy postafiókokat szeretnénk adni a felhasználóinknak, azt úgy tudjuk csak elérni, ha sok adatbázist hozunk létre. Mennyi értelme van ilyenkor a SIS-nek? Elég halvány, tekintve, hogy lecsökken annak az esélye, hogy a címzettek ugyanabban az adatbázisban lesznek. Ráadásul nézzük csak meg, mit nyerünk, mit vesztünk? Nyerünk merevlemezterületet, vesztünk adatkezelési sebességet. Mennyibe kerül a merevlemezterület? Bagó. Mennyire fontos a levélkezelés sebessége? Baromira.
Nem jó üzlet.

Ezért a fiúk nemes egyszerűséggel úgy döntöttek, hogy az Exchange2007-ben a levelek törzsére megszüntetik a SIS-t, egyesül a csatolásokra hagyják meg. És erősen gondolkodnak, mi legyen vele a következő verzióban.

Az a szerencsétlen public folder…

Rájár a rúd, rendesen. Persze, igazából még a Microsoft se nagyon tudja, mit csináljon vele.

Amikor kijött az Exchange Server 2007, azt mondták, hogy már csak megtűrt lett szegény. Nem is kapott GUI-t, csak parancssort. Aztán felhorgadt a népharag, az Sp1-ben beépült az Exchange Management Console-ba. De mindig ott lógott fölötte Damoklész kardja, hogy majd az E14-ben, na ott már úgy ki lesz hajítva az udvarra, mint macskát anyagcserélni.
Ehhez képest tegnap jelent meg egy írás az Exchange blogon, mely teljes mellszélességgel kiáll a Public Folderek mellett. Hogy persze. Támogatjuk. De azért ismerkedjél bőszen a Sharepointtal, Kedves Rendszergazda.
Nem egyszerű helyzet.

De nem is erről akartam írni. Hanem arról, hogy mi is a helyzet a public folder referrals beállításokkal az Exchange 2007-ben. Azaz mennyire lesznek virulensek a public folder eléréseink.

Messziről fogok nekifutni. Egészen az Exchange 2000/3 termékvonaltól. Sőt.
A Public Folderek némileg egyedi figurák egy Exchange rendszerben. Van nekik adatbázisuk, a szokásos .edb formátumban. Meg lehet adni, mely szervereken legyenek. De nem csak adatból állnak, fontos komponensük a hierarchia is. Igen, a folderszerkezet. Ez, ha jobban megnézzük, egy halom pointerből áll, ezek mutatnak a bináris .edb fájl megfelelő pontjaira.
A lényeg az, hogy külön-külön élnek. A hierarchia egységes, organizáció szinten. De adat, az nem feltétlenül kell, hogy ott legyen minden szerveren.

Ismerkedjünk meg még a Routing Group fogalmával. Ez gyakorlatilag a Telephelyet jelenti, Exchange szlengben. A Routing Group Connector (RGC) pedig a kapcsolat közöttük – azaz a gyenge, vékony, lassú vonalakkal elválasztott hálózati entitások között.

Nézzünk egy példát. Az Outlook kliensemből létrehozok egy új Public Folder alfoldert valahol, jó mélyen a struktúrában. Hol is fog ez létrejönni? Természetesen annak a szervernek a Public Folder adatbázisában, amelyiken a postafiókom van. De az új alfolder a hierarchiában egyből megjelenik, látni fogják Alaszkától Hódmezővásárhelyig, mindenhol.
Mi történik, ha valaki le akarja kérni a tartalmát? Ez leginkább attól függ, hogy én, mint adminisztrátor, mit állítottam be. Ugyanis a Public Foldereknél alfolder szinten állíthatjuk, hogy mely szervereken legyen belőlük példány – és mikor történjen a példányok között a replikáció.
Mondjuk, az van beállítva, hogy ne replikálódjon sehová. Ebben az esetben azok járnak jól, akiknek ugyanazon a szerveren – nevezzük AL-nak – van a postafiókja, mint nekem. Ők egyből hozzá fognak férni az alfolder tartalmához. Mi van, ha valakinek az én Routing Groupomban lévő másik szerveren van a postafiókja? Hát, a hierarchiát látja… és az ún. public folder referral megadja, hogy mely szerverek PF adatbázisában létezik ennek az alfoldernek tartalma is. Tehát ők szépen átvándorolnak AL-hoz a tartalomért.
Mi van, ha valaki egy másik Routing Groupból akarja elérni az alfolderemet? Attól függ, mi van beállítva az RGC-n. Ugyanis létezik egy egyállású kapcsoló: Enabled/disabled public folder referral. Ha engedélyezve van, akkor a másik RG-ből eljönnek az én szerveremhez a tartalomért. Ha nincs, akkor hibaüzenetet kapnak vissza.
Jó ez? Nyilván nem – és az egésznek nem is az a célja, hogy hibaüzenetet kapjunk vissza.
Az elsődleges cél a gyenge vonal védelme az elárasztás ellen. Ha a vonal annyira nem gyenge, akkor engedélyezhetjük a PF referral-t, nem fogja padlóra küldeni, ha sokan lesznek kíváncsiak az alfolderemre. Ha viszont gyenge, akkor más stratégiát kell választanunk: azt mondjuk, hogy az alfolderemet lereplikáltatjuk egy másik szerverre a távoli RG-ban, méghozzá úgy, hogy csak este engedélyezünk replikációs forgalmat. Ekkor nyugodt szívvel tilthatjuk le a konnektoron a PF referral engedélyezést, hiszen minden lent lesz a lenti szerveren, ami kell. Nagyjából 24 órán belüli állapotban.

Így játszhattunk a régebbi Exchange rendszerekben. De mi van az Exchange 2007-ben? Hát, Routing Group, például nincs. Értelemszerűen RGC sincs. Akkor mi szabhat határt a public folder referralok burjánzásának?
Az RGC utódja. Az Active Directory IP Site link.

Tippeljünk!
Vajon az Active Directory IP Site linken tudunk-e Exchange Public Folder referral-t szabályozni?

  • Nem. Hogyan nézne már az ki? AD linken Exchange tulajdonság? Olyan lenne, mint hajszárítóval permetezni.
  • Miért ne? McGywer például egészen biztos, hogy permetezett már hajszárítóval. Gondoljunk csak bele, Exchange telepítés előtt lemegy egy sémamódosítás. Miért ne módosíthatná ez az IP Site link objektum definícióját úgy, hogy kiegészíti Exchange specifikus tulajdonsággal? Hiszen meg is teszi, ha EMS-ből lefuttatjuk a get-help set-adsitelink -detailed parancsot, láthatjuk, hogy az Active Directory IP Site linknek lett olyan tulajdonsága, hogy exchangecost, meg maxmessagesize.

Nos, melyikre tippelsz?
Sajnos az első. Elméletileg semmibe sem került volna felvenni egy igen/nem jellegű tulajdonságot az IP Site link objektumra – de nem tették. Csak saccolni tudok: tervezéskor nem is számoltak a Public Folderekkel. Csakhogy az élet máshogy döntött, Public Folderek bizony lesznek.
Korlátozhatatlanul.
Akkor mégis, mit tehetünk, hogy a Patagóniában létrehozott alfolder tartalmáért ne menjen el mindenki, aki pl. a calcutta-i részlegünknél dolgozik?

  • Előremenekülünk. Ha eddig nem is volt a cégünknél megtervezett PF replikáció, akkor mostantól lesz. Megtervezzük, hogy minden Active Directory site-on, ahol van legalább egy Exchange 2007 szerver, melyiken legyenek ott a site leginkább használt Public Folderei. A replikációt mindenhol úgy időzítjük, hogy akkor történjen, amikor a vonalon alacsony a forgalom.
  • Minden postafiók adatbázison van egy olyan beállítás, hogy azoknak, akiknek ebben az adatbázisban van a postafiókjuk, melyik legyen a default public folder adatbázisuk. Értelemszerűen ez mindenhol a Routing Group PF szerverére kell, hogy mutasson.
  • Természetesen ezzel nem zártuk ki a Routing Group-ok közötti PF elérések forgalmát. De minimalizáltuk. Ha már megtiltani nem tudjuk.

Tíz körömmel kapaszkodva

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.

Tüskék a köröm alá

Nem is tudom, mikor lesz ennek vége. Az ember azt gondolná, most már minden menni fog a maga útján, semmi extra, semmi meglepetés.

Ja.

1. tüske:

Tesztuser hív estefelé. Nem megy az OWA hozzáférése. Belépek, ránézek a szerverre: Ó Irgalom Atyja, ne hagyj el. Az Exchange szolgáltatások több, mint a fele nem megy. Csoda, hogy napközben használni tudtuk. Aztán eszembe jut, hogy nem is. Például az otthoni postafiókomba küldött tesztlevél sem érkezett meg. Nézzük csak, mi van a queue-ban? Azt mondja, balhé – mert hogy nem tudja megnyitni. Miért? Mert állnak a szervizek.
Ezt jól körbejártuk.
Újraindítás.
Service szeretkezik újraindulni.
Azt mondja, kevés neki az idő. Pedig tőlem még próbálkozhatna…
Gugli.
Ha annyiszor lenne egymillióm, ahányszor leírtam ebben a sorozatban a nevét, már az enyém lenne a cég.

És igen… meg is lett. (Néha tényleg úgy érzem, a szakmámban a legfontosabb képesség a keresnitudás a neten.)

Cikk elolvas, székről leborul. Hát, azért már… mégis. Fiúk, ez nagyon durva volt.

Azt mondja, hogy a .Net2.0 programok már digitálisan alá vannak írva. Derék. Csakhogy a tanúsítvány része a CRL (Certficate Revocation List) elérhetősége is. Márpedig a .Net2.0 program minden induláskor leellenőrzi, nem vonták-e időközben vissza azt a tanúsítványt, amellyel őt aláírták.
Pontosabban… ellenőrizné, ha tudná. Ha volna a gépnek internet elérhetősége.
Gyors ellenőrzés… nahát, ennek a szervernek éppen volt. Akkor mi lehet a baj?

Hát az az átok WinHTTP.

Már egyszer keresztbeakadt a torkomon egy windowsupdate mókánál, most megint belémkötött. Az ugyanis egy dolog, hogy te a böngésződből tudsz böngészni, ha beállítottad a proxy beállításokat – de ugyanezt WinHTTP rutint használó szolgáltatások (BITS, .Net2.0 programok) alapból nem látják. Neked kell a proxycfg programmal beállítanod, vagy egyszerűen csak a ‘proxycfg -u’ parancs segítségével az Internet Explorerből átmásoltatnod.

Átmásoltattam, a szervizek be is indultak, mint a kisangyal.

2. tüske:

Már úgy nagyjából muzsikál minden, de a vidéki telephelyen nem működik az OWA. Az ügyfél csak egy internetkijáratot szeretne, a cég központjában. Minden tartományban, minden telephelyen van legalább egy CAS szerver, tehát az OWA proxy-nak kutyakötelessége lenne működnie. Egyik tartományból a másikba megy is, de egyik telephelyről a másikra az istennek sem. Ezt írja:

Outlook Web Access is not available. If the problem continues, contact technical support for your organization and tell them the following: There is no Microsoft Exchange Client Access server that has the necessary configuration in the Active Directory site where the mailbox is stored.

Most az egyszer a guglipower sem működött, mindenféle hülyeségek jönnek fel. Töröljem le a CAS szerepkört, töröljem le az IIS-t, telepítsem újra az IIS-t, telepítsem újra a CAS-t, persze közben áldozzak kecskét is keresztútnál. Valahogy nem volt kedvem ennyire vajákolni.
Még szerencse, hogy emlékeztem rá, az Exchange blogon boncolgatták rendesen ezt az OWA proxy témát. És igen, az egyik cikkben ott is van konkrétan az én hibaüzenetem. A megoldás sem bonyolult: engedélyezni kell a becélzott CAS szerver OWA virtuális könyvtárán az Integrated autentikációt. Megnéztem az IIS menedzserben, tényleg nem volt bekattintva. Ihaj. Bekattintottam, persze le is csorgott az alatta lévő könyvtárakra. Vártam egy kicsit, újabb próba.
Innentől kezdve belülről sem működött az OWA, átirányítás nélkül. Miaf. Azt mondta, hogy 440 Login Timeout.
Visszaállítottam az eredeti állapotot – az alkönyvtárakon is – de nem javult meg a helyzet. Ebből emberhalál lesz.
Gugli. Megint.
A találat kissé vajákolás szagú, de talán jó lesz. OWA virtuális könyvtár letöröl, pihen, újra létrehoz. És igen, ismét nem működik az OWA proxy, de legalább már eltűnt a hibaüzenet.

Akkor kezdjük előlről. Mi lehetett a probléma? Hát persze, kellett nekem az IIS adminból állítgatni, amikor van beállítási lehetőség az Exchange Management konzolból is! Gyors teszt: átírtam az autentikációt az IIS adminból – nyilván nem jelent meg az átállítás a címtárban. Ahhoz a konzol kell. Jaj. A lustaság. Vegyük észre: hiába van a jó jogosultság beállítva a virtuális könyvtáron, ha az nincs lekönyvelve az AD-ben, akkor nem működik. A fogadó CAS nem veszi a fáradtságot, hogy kontaktáljon a távoli CAS-sal, megnézi a címtárat és elhiszi azt, amit ott talál.

Gyors nagytakarítás, OWA újból le, majd fel, az InternalURL paraméter újra bevésése – a new-owavirtualdirectory parancs alapértelmezésben kihagyja – majd egy óra várakozás. Zöld tea, darts. Élni tudni kell.

És működik. Én már ideges sem vagyok.

Konnektória

Ez az írás már hetek óta itt aszalódik a piszkozatok között, de valahogy úgy éreztem, hogy ábra nélkül nem igazán lenne élvezhető. (Nem mintha azzal valami nagy mámor lenne.)
Mostanra készült el.

Nagyítás

Értő szemű olvasók gondolom kapásból kiszúrják a hibát: igen, egy budapesti Exchange2000 szerver és egy vidéki Exchange 2000 szerver ugyanabban a routing groupban van, dacára annak, hogy egy igen vékonyka WAN vonal feszül a két telephely között.
Hát, igen. Exchange 2000 alatt még lehetett ilyesmit csinálni. Az Exchange 2007 alatt már nem annyira, az ugyanis routing group-ok helyett az AD telephelyeket használja.
Ezzel el is érkeztünk a rajzon található kaotikus állapothoz.

Igen, kénytelen voltam extra konnektorokat beledöfni az organizációba – ha el akartam kerülni azt, hogy vidék a vidékkel Budapesten keresztül levelezzen. A postafiók migrációról már nem is beszélve.

Össze is raktam. Át is migráltam 3 szerencsétlent a BP2-XCH2000 szerverről a BP2-XCH2007 szerverre. Meg is halt a levelezésük, legalábbis bizonyos irányokba.

Mi történhetett?
A Winroute látott valami konnektorszerűséget, méghozzá működőnek látta. Csak éppen unknown objektumként. De azért arra küldte a leveleket – csakhogy azok nem jutottak el odáig. (Megragadom az alkalmat, hogy itt is rúgjak egyet a Message Tracking Centerbe. Sokkal rosszabb lett, mint az Exchange 2003-ban volt.)
A levelek ott álltak a queue-ban. Dühömben levertem minden extra konnektort – a levelezés hamarosan be is indult, igaz bejárta a fél világot a levél, mire kitalált.
Menetközben jött az újabb sokk: a tesztuserek emailcíme evolválódott. kovacs.bela@leany.hu -> bela@leany.hu

Slatty. Ez az a hang volt, amikor a fejemre csaptam. Hát, persze. Email address policy – mint korábban is írtam, adatbázis szintre. Csakhogy a userek átkerültek másik szerverre, másik adatbázisba, mely még nem szerepelt a házirendben. A default policy meg – most nem részletezendő okból – ilyen idétlenke.
Kivettem, hogy ne essen a userekre a policy, emailcím visszaír, eredmény vár.
Semmi.
Szokásos körök: RUS (bár itt már nem kellene), OAB generálás, OAB lekérés gyakorisága 1 perc, SCP? Mindegyik CAS-ra leellenőriztem. Jöhetett a szokásos keresztúton kecskeáldozás, közben állandóan nyomkodva az outlookban a download OAB gombot. Semmi.
Adsiedit, összes DC-ről megnézve a proxyaddress tulajdonságot. mindenhol jó. Ldp-vel belekukkoltam a GC adatbázisába, jó.
Hol a francba ragadt be az a hülye emailcím?
Aztán egyszer csak eltűnt a 3 tesztuser a GAL-ból. Újabb rángatózások, majd leesett, hogy most ért körbe a lebontott konnektor hatása. (Ekkor indult be a levelezés is.)
Új konnektorokat álmodtam magamnak. (Más színes tintákkal szokott.)
Semmi javulás.
Küldtem néhány tesztlevelet. Megkapta. A benne lévő cím jó. Reply. Elment. Majd visszajött, hogy nincs olyan címzett, hogy bela@. Miért??
Aztán valahonnan beugrott, hogy minden felhasználónak, még a postafiókkal nem rendelkezőknek is van olyan tulajdonságuk, hogy ‘mail’. Eddig úgy tudtam, hogy csak megjelenítésre szolgál. Azért ránéztem. Bakker, ott volt. Létezik ugyanis egy automatizmus, mely amikor policy változtatja meg a default emailcímet, akkor átírja ezt a tulajdonságot is. Ha én, manuálisan változtatom meg, akkor nem. És úgy látszik, mégis van szerepe.
Átírtam, megrángattam a szálakat, hamarosan meg is jelentek a jó címek a GAL-ban. Méghogy öreg kutya nem tanul új trükköket….
De az OAB letöltés továbbra sem ment. Google. Néhány óra szenvedés. Aztán összedobtam egy új profilt (az egyik tesztalanynak) a gépemen. Működött. Tehát az outlook profilban romlott el valami. Remek. Új profil, kismillió új beállítások, új ost. Mondjuk, ki nem szarja le. Működik.

Csak a nyolc terminálablak bezárása eltartott egy negyedóráig.
Hajnali fél kettő. Mehettem haza.

Mondjuk nem aludtam jól. Valami zavart. De még reggel is. Éreztem, hogy nem kerek a történet.

Másnap reggel folytattam a levélküldési teszteket. Volna. De nem működött sem a Free/Busy, sem az OAB elérésem. (Ja, nem mondtam: az egyik teszt postafiók az én tesztfelhasználóm volt.) Agyalások, gyötrések. Valamiért nem fordul a dög a CAS-hoz – legalábbis nem jön fel a selfsigned certre figyelmeztető ablak. Próbaprofil másik – tegnap szintén elkutyult – felhasználóval. Működik. Azaz az én mapi profilomba ragadt be valami szemét. Csináltam magamnak egy újabbat. Aztán a sokadik OAB letöltési kisérletnél egyszer csak megjelent a CERT ablak. Onnantól már a régi profilomból is ment. Idióta.

Most már tényleg levelezési tesztek. Gáz: nem tudtam vidékre levelet küldeni. Visszafelé ment. Nyomozás. Winroute: A konnektor megint ledőlt. Letöröltem a francba. Nem változott semmi. Ilyen nincs. Most már csak az IP site link ívelt át a telephelyre, a címtár replikáció működött, de az Exchange routolás nem. Set-adsitelink, költségek különválasztása, akkor sem.

Ekkor tettem meg azt, amit jóval korábban kellett volna: oda-vissza telnet 25. Lefelé nem ment, lent viszont egyik szerverről a másikra igen. Tűzfal!! – ordítottam fel. Jött is egy tűzfalas ember. Elkezdtem demonstrálni neki:
– Látod, nem megy a 25 port. De ha teszem azt, a 135-öst adom meg, akkor sem… – mondtam, miközben pörgött a kezem… és a 135-ös port átment.
– Igen? – nézett rám kérdőn az ember.
– Any/any van? – hebegtem.
– Persze – bólintott.
– Bocs.

Mi a retek lehet? Transport szolgáltatások futnak. – Receive connector! – csaptam a fejemre. Autentikációk rendben. Network… és akkorát csaptam a fejemre, hogy lefordultam a székről. Egy, azaz egy szám el volt írva a három IP range közül az egyikben a Default smtp receive konnektornál. Így onnan nem fogadott el kapcsolatot. Ez a range pont az egyik pesti LAN volt, két Exchange szerverrel. Ráadásul következetes voltam: a tervben – a jól kidolgozott tervben! – gépeltem el a számot, és utána már mindkét helyen ész nélkül írtam be a rossz értékeket az implementáció során.

Innentől már csak a törmelékeltakarítás volt hátra. Mindent visszaállítani az eredeti elképzelés szerintire. Az összes CAS disztributálja az OAB-ot. Ekkor viszont nem megy az, hogy cegnev user belép a leánynál és letölti az OAB-ot. Szomorú lettem. Végül az lett, hogy anonymous autentikáció az autodiscovery, ews (availability) és oab website-okon. Igen, hőbörgött… de legalább működött.

Persze az OWA továbbra sem ment a vidéki telephelyen – de minden más, mint a svájci óra.

A betervezett döbbenet

E-he. Azt hittem, már nem lesz miről írnom. Tévedtem. Van. Csak már nem olyan sok.

Az egyik az a bizonyos ékezetes probléma. Hát, az bizony nem oldódott meg, pontosabban nem úgy, ahogy szerettük volna. A német mérnök ugyanis, miután kijelentette, hogy az Exchange 2007 eltérő viselkedése by design és az ügyfélnek kell újrafordítania a programját, keresztbe tette a karját és várt. Én ugyan célozgattam rá, hogy foglalkozhatna azzal is, hogy miért nem lehet állítani a locale paramétert a Mailbox szerveren, de a füle botját sem mozgatta. Aztán az ügyfél megmozgatott minden követ, felvette a kapcsolatot azzal a külső fejlesztő céggel, aki anno a programot készítette, megolajozta a folyamatot egy kis zsével, újrafordították a programot – és most már jó. Eset lezárva – még csak bug report sem lett belőle. Aztán nem győzött csodálkozni a customer survey hapi, hogy csak úgy röpködtek részemről a hármasok.

A másik… hát, az jó nagy égés volt. Az előző írást ott fejeztem be, hogy leállítottunk minden észnélküli kapkodást, szépen felmértük a terepet, megterveztem mind a rendrakást, mind a további lépéseket. A rendrakás egyik lépése az volt, hogy az AD integrált DNS zónákat átpakoljuk a domain partícióból az applikációs partícióba. Ez egy logikus lépés, így ugyanis a DNS rekordok nem terhelik a GC replikációt.
Megcsináltam. Természetesen bejelentések folyamatosan jöttek az ügyféltől, mint mindig. A gyerektartományban nem működött az OWA – de az mindig is trágya volt. Időnként belassult az ügyfél befelé jövő levelezése. Felhívtak. Visszakérdeztem: hol lassú? – Hát, a unixos smarthost és a nem általunk támogatott brightmail között. Akkor? – kérdeztem vissza, talán túl ingerülten is. Jó, jó – mondták, csak úgy érdeklődtünk.
Ment tovább az élet. Aztán jött egy újabb telefon a helyi rendszergazdától. Hogy mi a jó francot csináltam a DNS zónájukkal? Mondtam, hogy terv szerint átraktam az applikációs partícióba. Miért? Mert megtalálták a hiba okát – közölte – A külső rendszerek számára ugyanis megszűnt mind a cegnev.hu, mind a leany.cegnev.hu zóna. Azt is megtalálták, hogy azért, mert az összes zónáról törölve lett az a pipa, mely engedélyezi a zónatranszfert. Bang. A pofám fémes reccsenéssel szakadt le. Ennyit az alapos tervezésről. A fene sem gondolta volna, hogy azzal, hogy áthelyezem máshová a zónát, valami ellenállhatatlan kényszertől vezérelve a zóna beállításait is megváltoztatja valami idióta mechanizmus. Rémálom… de le kellett nyelnem a békát. Végül is… én nem gondoltam rá a tervezéskor. Persze ennyi erővel arra is gondolhattam volna, hogy a gombra kattintáskor zöld koboldok törnek ki a My Computer ikonból és magukkal ragadják az egérkurzoromat, majd perverz leveleket küldözgetnek a nevemben a nőnemű munkatársaknak.
Hogy még nagyobb legyen az égés, tudni kell, hogy az ügyfél hatalmas erőket ölt bele a probléma megoldásába. Network-ös szakemberei hihetetlen méretű logokat túrtak át. A tűzfalas ember napokon keresztül bogarászta a szabálylistákat. A unixos emberük órákon keresztül reszelgette a smarthostot. Az ügyfél összes informatikusa a problémán pörgött, durván két napon keresztül.
Így amikor kiderült a jelenség oka, biztos lehettem benne, hogy az ügyfél összes informatikusa egyszerre csapott a fejére: már megint az a szerencsétlen nem tudja, mit csinál.

Jó szakma.

További faragások

Tesztelgettek egy kis Calendar-t, OWÁ-t, Blackberry-t, végül a helyi rendszergazda úgy döntött, hogy átmigrálja az összes postafiókot az új Exchange szerverre. Távolról – egyenesen Barcelonából – szurkoltam neki.
Amikor visszajöttem, alapvetően elégedett embereket találtam. Még működött a rendszer. Az utóbbi időben kicsit visszavettek az igényeikből.

De persze kisebb-nagyobb problémáik voltak.

Az Insource panaszkodott, hogy nem látják senkinek sem a foglaltsági információját. Meg hiába foglalnak le tárgyalókat, nem jelenik meg a foglalásuk. Ellentesztek. Mindenkinek működik. Kérdeztem a rendszergazdát, mi különleges lehet az Insource gépeken. Hosszas fejvakarás. Végül kinyögi, hogy ők külön címtárban vannak, mely össze van trustolva a cég címtárával. B+. Egy preparálatlan címtár. Pár óra vakaródzás nálam is, aztán szép lassan megszületett a megoldás: abban a tartományban nincs SCP objektum a címtárban, így nem érik el az Autodiscovery szolgáltatást. Outlook teszt, kibogarásztam, milyen DNS néven keresi a kliens a szolgáltatást. Rövid nyomozás, milyen DNS szervert is használnak a fiúk, aliasként felvettem benne a CAS-ra az autodiscovery nevet, egyből megjavult minden.

A gyerektartományba nemrég felvett úriember neve viszont nem jelenik meg a globális címlistában. Az istennek sem. Várunk vele, rugdosok mindent, nem és nem. Hazafelé már a fákat és a köveket is rugdosom, hátha az segít. (A mélypont és a lenyugvás.)
Elsőre persze a GAL-ra gyanakodtam. Végigböngésztem, mit is csinál és úgy véltem, túl bonyolult a szűrőfeltétel. Ki kellene cserélni. Szűrőcsere… mint a gépkocsikban. Végülis… elég lenne annyi kritérium, hogy legyen alias értéke az objektumnak. Nosza. Nem lehet. Ha már egyszer sikeresen módosítottad a GAL-t, akkor azt többször nem lehet. Miaf? Ez mekkora kreténség már…?
Beleástam magam a szakirodalomba. Utólag már azt mondom, megérte az a másfél nap kinlódás. Most már sokkal jobban átlátom, mi is zajlik a mélyben. (Olyannyira, hogy lett is belőle egy Technet cikk.) Végigmentem egyenként a láncon, begyorsítottam mindent, amit csak lehetett, végül megtaláltam azt is, hogy a leánytartományi RUS egy olyan GC-hez volt rendelve, melyet menetközben a rendszergazda – velem egyeztetve – megszűntetett, emiatt állt le az aszinkron frissítgetés. Ez is ki lett pipálva.

Aztán belefutottunk egy olyan szopásba, hogy van egy SQL rendszer, mely ékezetes karaktereket tartalmazó ASCII kódolású leveleket küld a leánytartomány Exchange2000 szerverére. Ott még ékezethelyesek a levelek. Aztán amint átjutnak az Exchange 2007 Mailbox szerverre, akkor teljes katyvasz lesz a levelekből. Az első gyanú a locale beállítás. Az Exchange2000 szervereken magyar és angol. Az Exchange2007-ben… default. A get-mailboxserver szerint ugyanis üres az érték. És nem is lehet módosítani, hiába próbáltam akár szöveges formában, akár decimális, akár hexadecimális formátumban beadni a magyar locale-t.
Tudomány elfogy. Bejelentettük az esetet a PSS-nek. Még mindig náluk van… de egyre inkább úgy tűnik, azt fogják mondani, hogy ez by default és RFC kompatibilis és alakítsam át úgy az SQL rendszert, hogy más karakterkészlettel menjen a levél. Az ügyfél baromira fog neki örülni. Eddig egyedül az Exchange2007 OWA jött be nekik, minden másra azt mondta, hogy sok kényelmetlenség semmiért.

Aztán egyszer csak váratlanul vége szakadt az őrületnek.
Menetközben beindult a többtelephelyes gyerektartomány tartományi migrációja, gyakorlatilag nélkülem. Ekkor már amit lehetett, azt helyi emberrel csináltatták meg – a rendszergazda meg már végigcsinált egy tartományi migrációt, látta, hogyan megy. Egyedül a DHCP okozhatott problémákat, erre megigértem, hogy majd utánanézek. Ehhez képest azért meglepődtem, hogy anélkül demotáltak egy DC-t, hogy nem szóltak, azt sem várták meg, utánanéztem-e a DHCP-nek. Aztán az üzemeltetési szempontból kritikus telephelyen egyszer csak megállt a DHCP szolgáltatás. Rövid időn belül mindenki szaladgált össze-vissza, mint pók a falon. Routermágusok vetették be magukat, eredmény nélkül. Már olyan embereket is felhívtak, akik anno a rendszert építették, csak azóta máshová mentek dolgozni. Gondoltam, én is megnézem, mit tehetnék. Rövid keresgélés után belebotlottam, hogy a telephelyi DC-re DHCP Relay lett telepítve, mely a demotált DC-re mutatott. Átállítottam az újra, beindult minden. Aztán kiderült, hogy a DNS áthelyezése sem igazán sikerült – és ekkor még igen finom voltam. Azt is rendbetettem. De már késő volt, ezt a bakit a cég már nem nyelte le. Csúnya veszekedések jöttek, indulatos ordibálások. Aztán az IT vezető írt egy körlevelet, miszerint az egész projekt műszaki tartalmáért én egyszemélyben vagyok a felelős, tehát tessék engem anyázni. Erre bepöccentem, én is írtam egy levelet, hogy a projektnek ebben a formában vége. Le fogok ülni, összeszedem, hogyan állunk, és aprólékosan meg fogom tervezni, hogyan lehet a rendszert egyenesbe tenni. Csak ez a tervezés tartott 3 hétig. Érdekes módon most már nem volt tiltakozás – pedig ekkor már negyedik hónapja(!) ment ez a projekt ilyen eszetlen tempóban.

Tanulság? Már itt is látszik. Az olcsójános technika megbosszulja magát. A durrbele-észnélkül-ügyesekvagytokfiúk_megtudjátokcsinálni mentalitás ekkora átalakításoknál nem működik. Ami több hónapos projekt, azt nem lehet hetekbe sűríteni, különösen úgy nem, hogy a tervezést hagyjuk el belőle. Ráadásul szakmailag ismeretlen terepen… Itt is látszott, még akkor is belefutottunk volna egy-egy nagyobb szopásba, ha mindent alaposan megtervezünk a rendelkezésre álló szakirodalom alapján. Ezért kell ismeretlen terepen külön időt hagyni laborkisérletre is – és az alapján kell írni a tervet. Persze nehéz akkor, ha stratégiai okból a munkát el kell vállalni, az ügyfél IT vezetője viszont nem érzékeli a munka nagyságát, nem tartja fontosnak a tervezést – aztán a végén persze mindent a külső cég nyakába varr. (Amiben persze meglehetősen groteszk módon _formálisan_ igaza van: a helyi rendszergazda és a tűzfalas ember valamikor az Ügyfél alkalmazásában álltak, aztán átkerültek hozzánk, a projekt idején teljes mellszélességgel éppen hozzánk tartoztak, de most, amikor ezt írom, már megint az Ügyfél alkalmazottai.)
Még valami. Nem tudom, ki mennyire figyelmesen olvasta el az írásokat… de talán akad egy-két ember, akiben felhorgadt valamiféle hiányérzet. Igen, sehol sem említettem meg egy nevet: azt, hogy projektmanager. Nem volt. Elfogyott. Gyakorlatilag mindkét cég úgy állt hozzá, hogy ez egy hipp-hopp upgrade, lekeverjük hamar. Én hiába küldözgettem mindkét irányba a jeleket, hogy ez így nem fasza, csak mosolygásokat kaptam: ügyes gyerek vagy, majd megoldod. Hát, nem. Kockafejűként nehéz ilyet beismernem, de egy bizonyos bonyolultság felett már szükség van dedikált PM-re. Ne a technikai embernek kelljen már a (fejben)tervezéssel meg az implemetálással küszködve még az Ügyféllel is harcolni.

Tulajdonképpen a történetnek itt vége is van. A projekt még megy, egész biztosan lesznek még benne izgalmas dolgok, de innentől már sínen vagyunk. Tervezés, döntés, implementálás – és ugyanez annyiszor, míg az átalakítás végére nem érünk. Ebből nem fogok engedni.
Ha már én lettem az egyszemélyi felelős.

Faragások

A szerverek telepítése pénteken volt. Szombat délelőtt már csörgött is a telefon: nem megy az OWA. Érezhető volt a gyanú, hogy mivel tegnap mi piszkáltuk az Exchange szervereket, biztosan mi keffentettünk el valamit. Nekem meg egyértelmű volt, hogy az organizáció upgrade nem volt szabad, hogy beleszóljon a webes elérésbe… de azért az ördög nem alszik. Megkértem a rendszergazdát, telnetelgessen már be az smtp porton az OWA szerverről a backend Exchange szerverre. Semmi. Akkor esetleg beszélgessen el a tűzfalas emberrel – tettem le a telefont. Mint később kiderült, a tűzfalas kolléga, anélkül, hogy bárkinek is szólt volna, ugyanazon a pénteken cserélt tűzfalat – és a szabályok visszatöltésébe valami hiba csúszott, emiatt az OWA szerver leszakadt. Teljeskörű tűzfal teszt az átállás után… az nem volt. Gondolták, ha valakinek valami baja van, majd szól.
Néhány újabb felesleges ősz hajszál a bozontomban.

Hétfő reggel a helyi rendszergazda kétségbeesett telefonja fogadott: az új konzolból nem érhetők el a gyerektartomány postafiókjai. A fene. Nézzük azokat a Routing konnektorokat… jók. Mi lehet? Nézzük csak az admin konzolját… hát persze, a View beállítás alaphelyzetben csak a root tartomány felhasználóit mutatja. Üde reggel.

Aztán még aznap a Nagyvezér behívatta az IT vezetőt. Hogy sem ő, sem a kulcsemberei nem tudtak a hétvégén OWÁzni. Egy ilyen kritikus időpontban. Úgy lebaszták a hapit, mint a pengős malacot. Közölték vele, hogy az Exchange projektben több hiba nem fordulhat elő. Nyilván az IT vezető is közölte velem, hogy ugye megértettem: több hiba nem lehet. Ja.

Akkor jöhetett a filter konverzió. Az ldap filterek megvoltak, a feltételeket átalakítottam, bemásolnám az OPATH filtert – kövér syntax error. Fejvakarás. A francba… az OPATH nem ismeri az AD objektumokat. De akkor mit ismer? Hát, AD objektumokat. Legalábbis néhányat – de nem mindet. A homeMDB értéket például nem. Hosszú napnak nézünk elébe. Blogböngészés. Evan azt írja, hogy nincs leprogramozható út a két filtertípus közötti konverzióra, ezért nem rakták bele a telepítőbe az automatikus konverziót. Mondjuk, ettől azért zabos vagyok egy kicsit, hiszen emiatt még nem kellett volna megölni a telepítést: például az Address List-ek ldap filterei sem konvertálódtak át, mégis tovább tudott menni a folyamat. Miért kellett a Recipient policy-knél leblokkolni?
Aztán ahogy továbbolvastam ugyanazt a blogot, még zabosabb lettem. Bill Long visual basic-ben ugyanis megírta azt a segédprogramot, melyet kollégája szerint nem lehetett megírni. Letöltöttem. Kipróbáltam. Működött. Néha. Volt olyan feltétel, amelyre működött, volt olyan, amelyikre nem. (Érdekességképpen megjegyzem, hogy a homeMDB érték neve Database lett. Mindjárt más, ugyebár.) Aztán azt is észrevettem, hogy ott nem működött, ahol szerepelt egy olyan feltétel, hogy ‘ne $null’, azaz ‘a tulajdonságnak van-e értéke’ vizsgálatnál. Akárhogy tekergettem, nem fogadta el vele a -recipientfilter paramétert a cmdlet – miközben a net tele volt ilyen példákkal és sehol sem említették, hogy trükközni kellene. A ‘ne $null’ nélkül viszont ment minden. Őszültem megint egy kicsit. Végül kínomban zárójel helyett kapcsos zárójelbe tettem az egész feltételt – és akkor már elfogadta. Az élet apró szépségei.
El se hittem, de délutánra átkonvertáltam az összes Recipient Policyt, tesztek, mindegyik működött. Be lehetett újra röffenteni a RUS-t.

Második forduló: címlisták. Emlékszünk, mind a GAL, mind az Address List-ek ugyanúgy ldap lekérdezések. Itt már nem vacakoltam, Bill Long kis programjával sorra konvertáltam át a filtereket, majd nyomtam be a cmdletből.
Szégyen… annyiszor szoktam mondogatni, hogy ‘ember, gondolkozz’… aztán én magam sem mindig teszem. Miután átkonvertáltam a filtereket, utána kezdtem csak végiggondolni, mit is tesznek ezek egyáltalán? És látszott, hogy a bonyolult átkonvertált cuccok helyett van sokkal egyszerűbb út is az OPATH-on belül, sőt, ezekhez varázsló is van. Na, nem mindhez, de a legtöbbhöz. Itt egy példa:

Ez az az OPATH filter, mely az eredeti Exchange2000 ‘All Users’ ldap filter transzformációjából keletkezett:
(& (mailnickname=*)
(| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))
( ( Alias -ne $null ) -and ( ( ( ObjectCategory -like ‘person’ ) -and ( ObjectClass -eq ‘user’ ) -and -not ( Database -ne $null ) -and -not ( ServerLegacyDN -ne $null ) ) -or ( ( ObjectCategory -like ‘person’ ) -and ( ObjectClass -eq ‘user’ ) -and ( recipientType -eq ‘UserMailbox’ ) ) ) )

Tulajdonképpen bele lehet erőszakolni egy Address List-be. Működni is fog. De ha végiggondoljuk, mit is csinál a szűrő, akkor rájövünk, hogy ugyanezt varázslóval is be tudjuk nyomni.

A varázslónak megfelelő Powershell cmdlet egyébként így néz ki:
Set-AddressList “All Users” –IncludedRecipients MailboxUsers

Nyilván ezekre a szűrőkre is igaz, hogy az egyszerű a szép. És a gyors is.

Már csak a globális címlistával kellett valamit kezdeni – a GAL-hoz ugyanis nincs varázsló. Semmilyen. Elfogyott. Egy logikus kísérlet: get-globaladdresslist. És igen. Innen nyílván működött a set-globaladdresslist is, na meg Bill Long progija. Szuper.
Teszt: új postafiók, mennyi idő után jelenik meg a GAL-ban. Soha. Tudom, nem szabad rohanni, az Exchange a nyugodt emberek platformja, de ennyi zen azért még nekem is sok volt. Jé, van olyan parancs is, hogy refreshGAL. Aztán semmi. Úgy hagytam, mint a vasalt ruhát. És lám, másnap már meg is jelent az új postafiók. A helyi rendszergazda morgott ugyan valamit, de a probléma megoldását elhalasztottuk. Majd, ha sok időnk lesz.

Érdekesség még az ütemezési lehetőség az email address policy/address list kreálásánál. Az ember elsőre azt hinné, ez valami olyasmi, hogy megadott időnként lefut és érvényesíti a házirendet. De persze ennél műveltebbek vagyunk, tudjuk, hogy RUS jellegű tevékenység ebben a verzióban már nincs. Kiváncsian bekapcsoltam, egy héttel későbbre véve az aktualizálást. Nos, azt csinálta, hogy amikor leokéztam a varázslót, megjelent egy számlálóablak. Amelyikben elkezdett visszafelé számolni. Másodpercenként. Egy hetet. Addig persze a konzolt nem lőhetem ki, mert menne vele a számlálós ablak is. MegaLOL. Cancel.

Szünet. Egy hét idegnyugtatás az őszi erdőben. Hegynek föl, völgynek le.
Ügyfél ezalatt hozzá se nyúlt a rendszerhez.
Visszajöttem. Az első barátságos pillantások hamar elsötétedtek: a System Attendant nem megy. Az Information Store megy ugyan, de újraindításkor bevés valami hülye hibát az eseménynaplóba. Az SA meg elindul ugyan, ezt be is írja, de utána egyből leáll. Hibaüzenet utáni turkászás, sehol semmi. EventID hallgat, Google szintúgy. Addig jutok, hogy jó eséllyel valami ldap cucli lesz. Beugrik, hogy valahol be lehet állítani, melyik GC-t részesítse előnyben a szerver. Lehet, hogy az a baj, hogy van a címtárban néhány nem w2k3 DC/GC? Állítsuk be mind organizáció, mind szerver szinten, melyik DC-t használja. Semmi javulás. Kínomban újraindítottam a gépet – és innentől tökéletesen megy.
Nem jósolok hosszú karriert a gyerektartomány W2k tartományvezérlőinek.

ps.
Nem sokat dobott a jókedvemen, hogy az egész cirkusz után jelent meg Bill Long írása erről az egészről. Ebből az derült ki, hogy a telepítő csak a _felesleges_ zárójelektől és & jelektől akad ki – ergo maradhatott volna az ldap filter, csak adsiedit-tel ki kellett volna műteni a többletet. Köszönöm, fiúk. Azért a KB cikkbe is beleírhattátok volna.

Cause 3
There is a parenthesis or an ampersand in a recipient filter. Additionally, Exchange 2007 uses OPATH filters instead of LDAP filters.

Itt ugye egy szó sincs arról, hogy _felesleges_.

De azért ne hagyjuk ezt annyiban, nézzük csak meg pontosabban, mit is mond Bill?

Although Active Directory itself has no problem ignoring the unnecessary ‘&’, Exchange 2007 setup doesn’t like this at all.

The parentheses surrounding the server name in the value confuse setup, causing the same behavior.

Érted? Tehát azok az emberek, akik az Active Directory-t fejlesztették, le tudták kezelni azokat az eseteket, amikor egy név az ldap filterben zárójelet tartalmazott, vagy bekerült egy felesleges műveleti jel (&). Ellenben azok a kutyaütők, akik az Exchange setupot írták, sajnos már nem. Ezért hal be a setup.
Valamikor mindenesként dolgoztam, ami azt jelentette, hogy kódoltam is, mint állat. Volt egy beosztottam is, egy gépésztechnikus srác, akit én tanítottam meg programozni. Azt hiszem, zokogva szúrtam volna tökön magam, ha a srác képtelen lett volna egy ilyen beviteli stringet parszolni. Pedig mi tényleg kutyaütők voltunk.

Az Exchange organizáció átállítása

Nekiállhattunk becsempészni az első Exchange2007 szervert.
A szakirodalom ajánlása szerint – ha azt akarjuk, hogy az OWA proxyzások jól működjenek – a CAS szerepkört érdemes külön gépre tenni, tehát mi is két szervert terveztünk. Szintén ajánlás, hogy először a CAS szervert állítsuk üzembe, de mivel mi egyelőre egyik 2007-es szervert sem terveztük élesben használni – tényleg csak becsempészni szándékoztuk – ezért nekünk jó a régi OWA is.

Mielőtt bármibe is belekezdtünk volna, lefuttattam a telepítő cédéről az MBSA-t. Volt is nagy csodálkozás. Egy csomó piros jelecske mutatta, hogy ez a telepítés bizony nagyon hamar lyukra futott volna. Ilyenek voltak benne pl, hogy az egyik Exchange2000 szerverre még kell az SP3. Kérdőn néztem a helyi rendszergazdára. Oké, oké, mindjárt fent lesz – szaladt el. Valamelyik szerverre már le volt töltve, gyorsan felszórta. Abban a pillanatban megfeküdt az éles szerver, nem indult el az Information Store. Hurrá. Bogarászás, kurkászás, majd kiderült, hogy az Exchange 2000 SP3 szerver verziószáma nem egyezik a hivatalos verziószámmal. Rákeresve a neten az is kiderült, hogy a korábban általuk letöltött cucc egy béta SP3 volt, melyről rémtörténetek keringtek a neten. Szerencsére le lehetett vakarni, letöltöttük a jó szervízcsomagot, felraktuk, minden rendbe jött.

Telepítés elindult, bekattogtattam, hogy akkor egy Mailbox és Hub Transport szerver rendel. Csíkhúzás, hibaüzenet. Az elsőnek telepíteni szándékozott HTR szerepkör nem megy fel, az üzenet szerint hiányzik egy /64 könyvtár a telepítő cédé egyik bugyrából. Mivan? Megnéztem, tényleg nem volt ott. Milyen telepítőmédiát adtál már megint? – néztem kérdőn a helyi rendszergazdára. Szegény, nem győzött szabadkozni, hogy ez aztán tényleg az és tényleg originál. Irány az MSDN, az a biztos, amit saját egérrel kattogtatok össze. 5,5 GB. Amíg vánszorgott lefelé, nekiálltam kószálni a neten. Mint kiderült, a hiba ismert. A Microsoft szerint rossz a telepítő média. Ja, persze. Szerencsére máshol is megtaláltam a hibát és itt már többen is jelezték, hogy ádehogy, ez egy bug. Újra neki kell szaladni a telepítésnek, akkor már átdöccen ezen az akadályon.
Hát, jó. Megpróbáltuk, bevette. Most a Mailbox szerver komponensnél szállt el. Azt mondta, hogy “The Exchange server address list service failed to respond”. Jó, irány újra a net. Meg is van hozzá az írás, KB935636. Hamar kiderült, hogy az első két eset irreveláns volt, maradt a harmadik. Ezt elég nehezen értettem meg, elsőre csak annyi jött le, hogy illegális karakterek vannak a recipient policy beállításokban. Megnéztem, tényleg. Ugyanis Exchange2000-ben ha automatikus emailcímgenerálást választottunk, akkor az ‘ö’ helyett ‘oe’-t, az ‘ü’ helyett ‘ue’-t generált a szoftver. Ennek kivédésére a rendszergazda lecserélte a karaktereket, még mielőtt a generálás megtörtént volna. (%röo %rüu %rÖO %rÜU.) Tuti ez a baj. Kitöröltük az összes cserét. A telepítés ugyanúgy zátonyra futott. Elolvastam figyelmesebben a KB cikket. Aztán elkezdtem hisztérikusan kacagni. Azt mondja, az a problémája, hogy az ldap filterben ‘(’ és ‘&’ karakterek vannak. Persze, hogy vannak! Ezek kábé annyira lényegi részei egy ldap filternek, mint szélsőjobbos nénike sétafelszerelésének a tojás és a kereplő. Enélkül nem az, aki.

Dehát… más megoldás nem volt. Kiszórtuk mind a 8 recipient policy-t. Innentől az organizáció nem fogadott levelet sehonnan. Szerencsére hülye címeket sem osztogatott, mert leállítottuk a RUS-t.

És igen, most már lefutott a telepítő. Gyorsan lecsekkoltuk az accepted domain értékeket, hogy legalább leveleket kapjunk. Utána megnéztük, mit tudnánk kezdeni az email address policy beállításokkal. A helyi rendszergazda majdnem elsírta magát, amikor meglátta mennyi lehetőséget nyújt a varázsló. Nagyon ragaszkodott szegény az adatbázisonkénti külön emalcím megadásához. Szerencsére beugrott, hogy olvastam én valahol az OPATH filterekről. Ezek fogják leváltani az ldap filtereket. És tényleg. Megtaláltuk az írást, megtaláltuk, melyik cmdlet melyik paraméterével lehet beemelni a filtert – aztán gyorsan félreraktuk a problémát. Van sürgősebb. A RUS áll, policy nincs – reméljük, ebben az átmeneti időszakban címváltozás sem lesz.

Nézzük a routingot. Katasztrófa. Az új Routing Group létrejött ugyan, de konnektor nincs. Az ExchangeLegacyInterop csoport is üres. Bakkerbakkerbakker… haza akarok menni. Gyümölcsfát akarok ültetni. Bármit, csak ezt nem. Szerencsére a korábbi fórumos linken Nick megírta a frankót: egyenként le kell szedni a szerepköröket, amíg el nem tűnik a szerver. Aztán újrakezdeni a telepítést, de immár parancssorból – és egyenként felrakva a szerepköröket.
Egész konkrétan:

  • Hub Transport szerver telepítése:
    setup.com /mode:install /roles:hubtransport /targetdir:d:/exchsrvr /domaincontroller:dc2003sp1gc.cegnev.hu /legacyroutingserver: exchange2000.cegnev.hu
    Értelemszerűen az utolsó paraméterként azt az Exchange szervert kell megadni, amelyikhez szeretnénk kötni az Exchange2007 routing groupot.
  • Mailbox szerver telepítése:
    setup.com /mode:install /roles:mailbox /targetdir:d:/exchsrvr /domaincontroller:dc2003sp1gc.cegnev.hu /enablelegacyoutlook
    Nem győzöm az utolsó paraméter fontosságát hangsúlyozni. Részletesebben lásd itt.

Mondjuk a Mailbox szerepkör megint lehalt: már van fent adatbázis. Nem sokáig. Gyors ellenőrzés: minden oké. Végre. Igaz a policy nem működik, a címlisták nem működnek, a jogosultsági rendszerre visszamásztak a deny-k… de már nagyjából Exchange formája van.
Jöhetett külön vasra a CAS telepítés, most már dafke parancssorból. Menetközben kékhalál. Fel sem vettük, újraindítottuk a masinát, a telepítés simán továbbment.

Mára vége. Már megint holnap lett.

A diszpécser a taxiközpontban hangról beazonosított. Éjfél után úgy látszik nincs nagy mozgás errefelé.

Bénázás a parancssorban

Tiszta volt a terep, mint a téli ünnepek között a legtöbb iroda.
Kezdhettük preparálni a címtárat.

Első lépésben nem akartuk az összes Exchange szervert átállítani, csak a forest root tartomány szervereit céloztuk be. Ebből kifolyólag a gyerektartományt nem is frissítettük, meghagytuk Windows2000 natív módban. Az itiner is azt mondta, hogy

“In each Active Directory site where you plan to install Exchange 2007, you must have at least one domain controller that is also a global catalog server and is running Windows Server 2003 SP1 or a later version.”

Azaz csak azon a telephelyen kell lennie W2k3Sp1 GC-nek, ahová Exchange2007 szervert akarunk tenni. Márpedig egyedül a gyerektartománynak van külön telephelye, a többiek egy kupacban vannak.
Ügyfél egy kicsit megnyugodott, idén csak ennyi pénze volt, a teljes átállás második felére akkor ráér jövőre erőforrást ütemezni.

Ennek jegyében a gyökértartományt w2k3 szintre frissítettük. Bedugtam az Exchange telepítő cédét a friss, harmatos gépbe, aztán
setup.com /PrepareLegacyExchangePermission.
Azt mondta, hogy nincs ilyen paraméter, próbáljam meg a setup /? figurát. Megpróbáltam. Tényleg nem volt. Egy világ dőlt össze bennem. Írtam cikket erről a parancsról. Vizsgán egy csomószor adtam meg helyes válaszként. Akkor most mi van?!
Utánaolvastam. Az van, hogy a parancs sok jogosultságot módosít. Tehát permissions.

Boldogan elindít, parancs dolgozik, majd kikattan, mint órarugó. Azt mondja, hogy a gyerektartományban nincs w2k3sp1 GC. Persze, hogy nincs. Direkt nincs. Úgy terveztük. Mit akadékoskodik a köcsög? Itt van, pár sorral feljebb, hogy csak akkor kell, ha e2k7 megy oda.
Most akkor kinek van igaza?

A parancs helpje továbbra is hülye, marad a gugli. Ott van, hogy létezik egy /domaincontroller:<dc_fqdn> paraméter. Remek, adjuk meg az egyik root dc-t. Ugyanaz. Kikattan.
Én is. Ezután tuti, hogy elevenen nyársalnak fel. Az egész projekt azon alapult, hogy a gyerektartományt békén kell hagyni, a gyökértartományt meg át kell csúsztatni. Én meg bátran alapoztam arra a bizonyos mondatra az MS dokumentációban – mely szemmel láthatóan nem igaz.

Eszeveszett további keresések. Az eventid.net akkora baromságot mond a hibára, hogy én szégyellem magam. Aztán jön egy szerencsés találat: kiderül, hogy a parancsnak van egy speciális változata:
setup.com /PrepareLegacyExchangePermissions:<domain-fqdn>
Ekkor csak azt a tartományt frissíti, melyet megadtunk, a többit nem nézi.

Mehetünk tovább. Replikáció letilt, prepareschema. Megint ugyanaz. Kell neki a w2k3 GC. Megadóan keresem a /domain kapcsolót… de itt már nincs. Bakker…. a projektünk csak bedőlt az árokba. Kétségbeesett keresés. Első találat: egy MVP kolléga, ki van kattanva, de rendesen. Hogy szar a doksi, más a valóság. Én legalább ennyire ki vagyok kattanva: frissíttessem a gyerektartományt az ügyféllel, plusz szerverek, plusz pénzek, egy-két hét csúszás? A következő találat se nagyon dobott fel: az Exchange blogon írják, hogy hát, igen, elkúrtuk. De majd a sohakinemjövő sp1-ben javítjuk. Addig vagy ne telepítsél Exchange-t, vagy pakold tele – feleslegesen – a tartományaidat új vasakkal. Végül az ügyfél úgy dönt, hogy inkább leperkál 800k-t és belevágunk most a gyerektartományba is. Nekem ég a pofám… és az ügyfél szerint jogosan, mert én vagyok a szakértő. Az nem nagyon vígasztalja, hogy a hivatalos doksiban annak ellenére van valótlan követelmény, hogy a fejlesztők a nyilvánosság előtt ismerték be, hogy nem úgy van. Ahelyett, hogy a specifikációt frissítették volna a dokumentumtárban…

Preparáció elhalasztva.

Később kiderült, nem eszik annyira forrón a kását, elég betenni egy Windows2003 Sp1 DC/GC szervert a meglévő Windows2000 DC mellé, akkor már jók vagyunk, a tartományi upgrade ráér. Nagy sóhaj, csináljuk. Rossz sejtéseim vannak. (Azóta kijött az SP1, elméletileg már nincs ez a hiba, van helyette másik, lásd itt. Aranyos. 2007.12.30)
Mindenesetre a preparáció végül szépen lement. Apró finomság, hogy a setup /preparedomain parancs kiadásához nem volt jogom a gyerektartományban – nem voltam domain admin – de a gyökértartományban kiadott setup /preparealldomains már végigsöpört az összes tartományon – ugyanis ahhoz az enterprise admin jog kell, az meg megvolt.

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.

Bevezetés

A novemberi Technet Magazinban jelent meg egy cikk arról, hogyan állt át egy cég Microsoft infrastruktúrára. Örült a lelkem, amikor olvastam, hiszen jó látni, hogy vannak helyek, ahol ez flottul megy. Nekem valahogy mindig a csatornákban mászkálás marad.
Gondolkodtam is, hogy megírjam-e az egészet ennyire részletesen, de aztán győzött a grafomániám. Nekem is jó, ha egyben látom, mi mindent csináltam/csináltunk rosszul, na meg másoknak is segíthet.
Ami még kérdéses volt, hogy hová írjam? Ide mély szakmai írásokat már nem szántam – de ebben a szakmai tartalom mellett lesz rendesen hőbörgés is, azt meg a katedráról talán mégsem kellene. Szóval maradt az egész a kocsma jellegű blogban.

A feladat látszólag egyszerű volt: rendbe kell tenni az ügyfél címtárát, Exchange organizációját, úgy, hogy menetközben upgradeljük a tartományt és a végén átállunk Exchange 2007-re. Gondolom, érezhető, hogy a ‘látszólag’ szó az iróniát hivatott képviselni az előző mondatban.
A helyzetet bonyolította, hogy az ügyfélnek vannak insource informatikusai is, azaz nemcsak mi, mint outsourcing cég kezelgetjük az IT rendszerüket. Hogy fokozzam a helyzetet, eddig alig fértünk hozzá a rendszerükhöz, a helyi rendszergazda sokáig elkövetett mindent, hogy ne kapjunk komolyabb jogosultságot. Embereink maximum egyszerűbb feladatokat láttak el, jórészt felhasználóadminisztrációt. A rendszerről meglehetősen homályos képünk volt. Meg is lepődtünk, hogy ezt a munkát végül mi nyertük el, nem az insource.
Maradjunk egy kicsit még a kiindulási feltételeknél. A meglévő rendszer a következőképpen nézett ki:

  • Windows2000 erdő, natív windows2000 tartományok. Egy gyökértartomány, két gyerektartomány. A projekt része az egyik gyerektartomány megszűntetése, az erőforrások átmigrálása a gyökértartományba.
  • Exchange 2000 szerverek, különösebb cifrázások – cluster, nlbs – nélkül. Minden tartomány mindegyik telephelyén van legalább egy szerver.

Tervezés… minimális. Az ügyfélnek nagyon sürgős. Az egész projektre tokkal-vonóval adott 3 hetet. Habár jeleztem, hogy igazából ez a rendszer megismerésére sem elég, de akkora nagy volt a különbség az ügyfél időbecslése és az enyém között, hogy nem is láttam értelmét a vitának. Csináljuk, aztán majd kialakul. Néha megpróbáltam tervezgetni, de annyira nem volt rá idő, hogy végül belementem egy kompromisszumos munkamódszerbe: a koncepció nálam megvan fejben, hetente összeülünk, én elmondom, mi várható a következő egy hetes etapban, felvázolom a döntési lehetőségeket, ha kell rajzolgatok is a táblára, aztán döntünk, ütemezünk. Végül a helyi IT vezető gyárt egy meeting minutes doksit, melyet egy hét múlva átnézünk, utána pedig megtervezzük a következő hetet.
Eddig sem hangzott túl jól, de aztán kiderült, hogy igazából a helyi rendszergazda sem ismeri részleteiben a saját rendszerét. Többször futottunk bele olyasmibe, hogy ‘ja, tényleg, emlékszem, mintha XY valamikor ezt meg azt telepített volna’ – mindez olyankor, amikor éppen valami nem várt falba ütköztünk. Dokumentáció nem volt semmiről sem. Életem első éles Exchange2007 bevezetése volt. Elég vadul hangzik. Ha tisztességesen akartam volna csinálni, akkor azt mondom, hogy egy-két hét rendszerfelmérés, két-három hét tesztlabor, lemodellezés, jegyzőkönyv, aztán az alapján egy hét tervezés. Ez durván a duplája volt az ügyfél által a _teljes_ projektre szánt időnek.

Nos, így. Ennyi volt a bevezetés. Legközelebb már szakmai dolgok jönnek.

Gotcha!

Elkaptam. Avagy a zombi visszanéz.

Jó két napja az összes agykapacitásomat ez a címlistás balhé kötötte le. Aztán tegnap este fél tizenegykor bevillant a fejembe egy beállító panel. Bakker, tuti, hogy azon rossz adat van! Beléptem az ügyfél rendszerébe, megnéztem – és tényleg. A gyerektartományra vonatkozó RUS olyan GC-re hivatkozott, mely időközben megszűnt. (Miért zombi? Mert elméletileg Exchange2007 organizációban a címlista frissítésében már nem lenne szabad, hogy a RUS szerepet játsszon. Aztán mégis.)
Mindenesetre, anélkül, hogy túlzottan belemennék a részletekbe – úgyis cikk lesz belőle valamilyen formában – ettől még nem lett barátságosabb ez a címlista szétosztás. Csak hogy két rétegét említsem:

  1. A kijelölt Exchange szerver alapértelmezésben naponta egyszer csomagolja bele a GAL pillanatnyi állapotát az Offline Address Book-ba.
  2. A cached módban működő Outlook kliensek alapértelmezésben 24 óránként töltik le az OAB-ot.

Azaz extrém esetben simán összejöhet, hogy az adminisztrátor létrehoz egy postafiókot, de a kliensnél csak 48 óra múlva jelenik meg a címlistában. Döbbenetes. És akkor a többi rétegről, a kiszámíthatatlan RUS stemplizésekről, a hasonlóan kiszámíthatatlan Public Folder replikációról, a kiszámítható, de szintén időt befolyásoló címtárreplikációról még nem is beszéltem. Nagyon ráfért már erre az egész koncepcióra egy ráncfelvarrás – szomorú, hogy az új disztributálás csak Exchange2007/Outlook2007 kombinációban működik.

Az egyiknek sikerül, a másiknak nem

Van olyan, hogy nem csak a politikus, hanem a szoftvergyártó is elk elrontja. De hogy annyira büszke legyen rá, hogy erre a hibára vizsgakérdéseket is hegyezzen ki, az már azért valahol pikáns.

A 70-237-es vizsgáról van szó, ez a neve: PRO: Designing Messaging Solutions with Microsoft Exchange Server 2007.

Nézzük a következő szituációt. (Ne örülj, a kérdés ilyen formában nem szerepel a vizsgán, itt csak az elv a lényeg.)
Van egy működő Exchange 2003 organizációd, benne egy Front-end és egy Back-end szerverrel. Ezt az egészet át szeretnéd slisszantani (transition) egy Exchange2007 organizációba, úgy hogy a végén legyen egy CAS/Mailbox/Hub Transport szervered. Milyen sorrendben tervezed megvalósítani a folyamatot?
Mivel utáljuk a komplikációkat, így egyszerűen azt mondjuk, hogy preparáljuk a címtárat, felhúzzuk a szervert a szükséges funkciókkal, majd átirányítjuk rá az owa.cegnev.hu címet, kiléptetjük a régi Front-end szervert, átmozgatjuk a postafiókokat, replikáljuk a public foldereket és a régi Back-end szervereket meghagyjuk az Sp1-ig. Működni fog? Nagyjából. De megdöbbentő módon, owá-n keresztül nem fogjuk elérni a public foldereket, hiába tartottuk meg a régi szervert is.
Mit ajánl ehelyett a módszer helyett a Microsoft? (Ugye, ezt is kell válaszolni majd a vizsgán.)
Azt, hogy húzzál fel először egy külön CAS szervert (HTR lehet rajta), majd egy másikra tedd a Mailbox/HTR szerepköröket. A többi már ugyanaz, mint az előbb. Azaz amíg nem jön ki az Sp1, addig nem egy, hanem két Exchange2007 szervered legyen – és a CAS ne legyen egy gépen a Mailbox szerepkörrel.

Természetesen ezt meg lehet tanulni. Hány olyan dolog van egyébként is, amit megtanultunk, de nem értünk?
De erre speciel van magyarázat.

Kicsit távolról futunk neki.
Az első sarokpont az, hogy az Exchange2007 Mailbox szerveren lévő public folderek webes protokollon keresztül nem érhetők el. Ezt mondjuk, tudtuk – de nem árt elismételni. (Majd Leonárd az Sp1.) Ezért kell a régi Back-end szerver, a public folderekkel.
Menjünk tovább. Amikor egy webes kérést le kell kezelni, az történhet átirányítással vagy proxyzással. Jelen esetben, amikor bejön a /public alkönyvtárra irányuló kérdés, akkor valaminek át kellene irányítania a kérést a régi Back-end szerverre. Ez az átirányítás nem működik az egyik esetben – és működik a másik esetben.

Merüljünk mélyebbre. Van két dll, a DaveX.dll és az ExProx.dll. Mindkettőben van olyan függvény, amely képes ennek az átirányításnak az elvégzésére. Csakhogy… a DaveX.dll ezt az átirányítást az FQDN alapján végzi. Pontosítok: a belső FQDN alapján. Azaz ül Átlag János felhasználó otthon, bedönget az owá-n, ott azt kapja, hogy menjen tovább az exhange-backend.cegnev.local szerverre – és erre azt mondja az Internet szolgáltatójának DNS szervere, hogy ‘mivan, vazze?’. Ezzel szemben az ExProx.dll sokkal intelligensebb, ő ezt tisztességesen le tudja rendezni, berkeken belül. Igenám, de ha a két dll együtt van jelen, akkor DaveX győz – az a DaveX, aki a Mailbox szerepkörrel települ.
Tehát ha egy gépen van a CAS/Mailbox funkció, akkor DaveX irányít, bele a semmibe. Ha külön van a CAS funkció, akkor ExProx irányít, a jó helyre.

Ennyi volt a mese. Látható, a rendszer két helyen is el lett cseszve. Valószínűleg egyszer majd ki is javítják ezeket a hibákat.
De addig vizsgakérdés lesz a körbedolgozásuk.

Megyen a log vándorútra

Az már önmagában jó ötlet volt, hogy SCC helyett LCR meg CCR lett, de az igazi nagy dobássá az SCR vált.

Nem, nem golyóztam be, legalábbis nem szignifikánsan. A fenti mondat Exchange adminok folyosói beszélgetésében teljesen természetesnek számít. (Ha jót akarsz magadnak, kerülöd az Exchange adminokat folyosói beszélgetés közben.)

Hogy érthető legyen, amiről beszélni fogok, tisztázzuk le, mi is történik a levelekkel, miközben bekerülnek az adatbázisba. Most azzal nem akarok foglalkozni, hogy mi is az az ESE, jelen esetben nem lényeges. Sokkal fontosabb, hogy tudjuk, hogyan működik a tranzakció alapú adatbáziskezelés. Az alapelv az, hogy van egy napló, egy úgynevezett tranzakciós log, melybe vezetjük, hogy tulajdonképpen mit is szeretnénk tenni az adatbázissal. Az első félreértés már rögtön itt adódik: melyik adatbázissal? És jön is visszakézből: miért, hány adatbázis van? A válasz egyszerű: kétszer annyi. Mindig. Ugyanis minden megnyitott adatbázisnak van egy példánya, mely a merevlemezen van és van egy példánya/szelete a memóriában. Értelemszerűen sokkal gyorsabb azzal a példánnyal dolgozni, mely a memóriában van – csakhogy az a példány olyan, mint az élet: ha lekapcsolják a főkapcsolót, elillan. Amelyik megmarad, az a merevlemezen lévő. Melynek kezelése lassú, mint idő múlása a fogorvosi váróban. Jó lenne, ha egybe tudnánk gyúrni az előnyöket, anélkül, hogy a buliról a hátrányokat értesítenénk.
Nos, jön az a tranzakció. Tokkal vonóval beírjuk a logba, hogy pl. Kis Piroska törölte a ‘Ph@nt@st1c V I A G R A buy n0w’ tárgyú levelét. Ki is töröljük, a memóriában lévő példányból. A levelezőkliensek a memóriában lévő példányt látják, tehát azt hiszik, tényleg ki lett törölve a levél. Pedig nem, a lemezen lévő példányban ott van. Onnan akkor fog eltűnni, ha éppen ráér a szerver. Vagy hátbavágja egy backup. Akkor, amikor ténylegesen kitörlődik a lemezen lévő példányból, akkor lesz lezárva a tranzakció a logban. Nézzük, mi történik, ha a takarítónő elemet akar tölteni és emiatt a porszívó mellett a másik konnektorra is lecsap, kihúzva a redundáns tápunk mindkét madzagját? Az Exchange szerver leállt, a memóriában lévő adatbázispéldány füstté vált… de ott van a merevlemezen lévő adatbázis és a tranzakciós logok. Látjuk, hogy mely tranzakciókhoz tartozik lezárás – azok már kikerültek a vinyóra. De a lezáratlanok még nem – nosza, írjuk ki. Ezt hívják úgy, hogy rájátsszuk a logokat az adatbázisra.
Igen, jogos a kérdés… mit nyertünk ezzel? Hiszen írunk a lemezre… Írni ugyan írunk, de nem mindegy, hogyan. Ugye mindenki tudja, hogy a tranzakciós lognak külön merevlemeze van, ahová a fej folyamatosan ír, olvasni gyakorlatilag nem olvas? Ég és Föld különbség van eközött az írás és egy többszáz gigás adatbázisba illesztő írás között.

A hosszú bevezetésnek annyi volt az összes értelme, hogy tudjuk: aktuális adatbázis = merevlemezen lévő adatbázis + tranzakciós logok. A sok CR végű akronim pont ezzel a képlettel trükközik.

És akkor oldjuk is fel őket:

  1. SCC – Single Copy Cluster
  2. LCR – Local Continuous Replication
  3. CCR – Cluster Continuous Replication
  4. SCR – Standby Continuous Replication

Az első a sima cluster. Exchange2003-ban csak és kizárólag erre hivatkozhattunk, ha magas rendelkezésreállásról faggattak az ügyfeleink.
Exchange 2007-ben viszont már megjelentek az ún. log shipping technikával dolgozó eljárások is. Ezek a *CR-ek.

LCR: A konkrét Exchange gépen egy megadott könyvtárba ‘elülteti’ (seeding) az adatbázist – azaz másolatot készít róla. Innentől miközben dübörög az Exchange szerver, pörögnek a logok, mindegyikről másolat is készül az előző könyvtárba. Mit védtünk ki ezzel? Azt, hogy ha például megsérül az adatbázisfájl. Ha felrobban az adatbázist tartalmazó merevlemez. Ekkor ugyanis a másik merevlemezről – mert annyi eszünk gondolom volt, hogy az LCR könyvtár másik merevlemezre került – manuális beavatkozással beröffentjük az adatbázist. (Ugye van minden: log és adatbázis.) Ez a legegyszerűbb log shipping, nem kell hozzá semmi se, igaz, csak merevlemezhiba ellen véd.

CCR: Ez már komolyabb. Kell hozzá a cluster szolgáltatás. És kell hozzá a Microsoft Exchange Replication szolgáltatás. A forgatókönyv az, hogy van egy cluster, két node, ahogy kell… de nincs közös adatterület! Nincs quorum. Kell a francnak, csak baj volt vele. Ehelyett van egy file share valahol, oda irkál mindkét node. (Igen, van egy kicsi ‘Majority Node Set’ áthallás.) Az adatok naprakészségét pedig úgy biztosítja az előbb említett szép hosszú nevű szolgáltatás, hogy a logokat másolgatja folyamatosan mindkét node-ra. Látható, hogy ez már komolyabb dolog: automatikus failover/failback, komoly rendelkezésreállás, de böszme hardverköltség nélkül. Viszont vannak hátrányai is: a cluster két node-ja nem lehet külön alhálózaton. Ezzel gyakorlatilag nem tudunk védekezni az épület lebombázása ellen.

SCR: Egyfajta arany középút. De tényleg arany. Mit is tud? Van egy éles Exchange szerverem és van egy standby Exchange szerverem. Mindkettő működik, a magvetés után mindkettőn ott van az adatbázis, de a felhasználók az éles szervert érik el. A logmásolás folyamatos. Ha kidől az éles szerver, a standby szerveren lévő adatbázist előléptetjük – és megy minden tovább. Nézzük az előnyöket: kitörtünk a szerverszobából. Nincs alhálózatra vonatkozó megkötés, ha jó a vonalunk, akár Balatonfőkajárra is lerakhatjuk a standby szervert. Nem kell hozzá cluster szolgáltatás. Egyszerre több standby gépet is használhatunk, maximum négy lehet. A forrás gép lehet egyszerű Exchange szerver, de lehet LCR, CCR, SCC is. Hoppácska. Azaz mezei szerverekkel össze tudok hozni egy olyan figurát, hogy a szerveren belül LCR-t használok, telephelyen kívül pedig SCR-t. (Viszont SCC/CCR esetében él az alhálózati korlát, hiszen ezt végül is a cluster szolgáltatás kényszeríti ki. Kivéve persze az MNS-t.) Hátrány: nincs automatikus átállás, össze kell piszkolnunk a kezünket. Másik hátrány: majd az SP2-ben jelenik meg végleges formában; viszont a béta2-ben már tesztelhető.

Smirgli

Kedvelem a fanatikus embereket, még akkor is, ha néha nehéz velük kijönni.
A hosszú hétvégére kinyomtattam Thomas Shinder ötrészes eszmefuttatását az Exchange2007 szolgáltatásainak kipublikálása témakörében. (Ember, legalább 200 oldal!)
Még csak a harmadik oldalig jutotam – sokáig aludtam, na – de már most is nagyokat vigyorogtam rajta.
Azt mondja, hogy a laboratóriumi körülményeit nehogy alkalmazzuk éles környezetben, mert nem oda valók.

  • Például itt olyat csinál, melyet éles környezetben soha: a Client Access Server (CAS) szervert beteszi a Mailbox szerver mellé. Éles környezetben természetesen DMZ-be rakná – de eddig még nem tudta beazonosítani az összes protokollt, melyekkel a két szerepkör egymással kommunikál.
    Miközben az összes Microsoft ajánlásban kifejezetten azt javasolják, hogy a CAS szervert semmiképpen ne tegyük DMZ-be, hiszen az Exchange2003 Front-end szerepkörétől eltérően a CAS már üzleti logikát is tartalmaz, szerves része az organizációnak – annyi számítógéppel kommunikál, annyiféle protokollon, hogy ementáli sajttá kellene hozzá luggatni a tűzfalat. Mely persze ezután semmit sem érne.
  • Azt mondja, hogy Edge Transport szervert meg azért nem használ, mert ha rendesen akarná megcsinálni, akkor azt is a DMZ-be rakná, de egyelőre nem tudja, milyen protokollok kellenek hozzá, ezért majd. Ha megtudja.
    Mit mondjak… smarthost… email transport… SMTP. Pure smtps. Meg az Edgesync szinkronizációhoz secure ldap.
  • Közben az égre néz és súlyos szavakkal kárhoztatja a teremtőket, hogy volt képük a POP3 és IMAP4 konfiguráláshoz szükséges grafikus felületet mellőzni. Szószerint: „giant management hole”.
    Hát, nem tudom. Hirtelen tudnék most sorolni vagy 15 olyan dolgot, melynek sokkal fájóbb a hiánya. Ha az övé ‘giant’, akkor az enyémekre már nem maradna megfelelő kifejezés.
  • De a legszebb rész az, amikor kijelenti, hogy nem publikál SMTP-t, meg SMTPS-t, mert az Exchange2007-ben az SMTP szervíz el lett rejtve – nem konfigurálható annyira direkt módon, mint az Exchange2003 alatt dübörgő IIS SMTP. Volt pofájuk az egész transzport konfigurálást Powershell mögé rejteni, melyet ő semmi pénzért nem hajlandó használni. Szószerint: „is hidden behind the Powershell shell interface, which I try to avoid at all costs”. Majd ezt később ki is fejti, hogy a Microsoft útja a grafikus felület, erről nem lenne szabad letérnie.

Erre mondják azt, hogy nem szép, de legalább kedves ember. Ha a maradék 197 oldal is ilyen lesz, akkor – a várakozásommal ellentétben – jól fogok szórakozni.

ps: Félre ne értsd, ismerem a szerzőt, ha nagyon akartam volna, személyesen is találkozhattam volna vele, mivel ő is MVP. Kedvelem is az írásait, nagyon jó ISA könyvei vannak és ez a hosszú szösszenete is valószínűleg hasznos lesz. Csak éppen úgy kell hozzáállni az írásaihoz, hogy észre kell venni, mikor gurultak el a gyógyszerei.

[Update]

Eltelt két nap, lehiggadtam.
Emberek! Ne olvassátok el. Egyáltalán nem szórakoztatóak a cikkek, viszont remekül illusztrálják, hogyan működik az aggkori agyelgyengülés.
Egyedül az 5. cikk ér valamit, azt talán érdemes.

A misztikus public folder replikáció III.

Az előző részekben szó esett a public folderek felépítéséről, részletesen leírtam egy egyszerű replikációs folyamatot és alaposan belementem abba, hogy milyen mechanizmusok támogatják az atombiztos multimaster replikációt.
Jelen írásban viszont inkább arra térnék ki, mi van akkor, ha valami mégsem működik annyira biztosan? A gyors válasz könnyű: akkor a replikáció betonbiztosan nem működik.
A legegyszerűbb megoldás, ha néhány konkrét eseten keresztül mutatom be ezt a nemműködést.

IV Tipikus problémák és megoldások

A címben első ránézésre van egy kis barokkos túlzás. A tipikus probléma ugyanis úgy néz ki, hogy nem működik a public folder replikáció. És itt meg is szokott állni a tudomány. Nem is csoda – a folyamat mélyebb ismerete nélkül az adminisztrátor leginkább csak hadonászik fakardjával a sötétben.

Nézzük, milyen eszközökre lesz szükségünk a megoldási folyamatban:

  • Eventlog, applikációs log.
  • Message tracking center.
  • ADSIedit.
  • ArchiveSink.
  • Józan ész.

Különösen az utóbbi fontosságát nem győzöm hangsúlyozni. A többi simán megvásárolható a boltban – de a tiszta gondolkodás nem található egyik polcon sem. Nevelgetni kell.

Az első, józan észhez kötődő megjegyzés: mindig pontosan legyünk tisztában vele, hogy hol vagyunk. Multimaster replikációnál talán ez a legfontosabb kiindulási pont. Tudni kell, melyik szerveren változtatunk és mely szervereken várjuk, hogy a változás – a replikáció révén – megjelenjen. Az Exchange System Manager-ben állítható, hogy melyik Exchange szerveren lévő public foldert támadjuk be. (Connect to… opció)

5. ábra A vizsgálandó Exchange szerver kiválasztása

Ha kliens oldalról piszkálódunk, akkor kiindulhatunk abból, hogy első körben azt a replikát fogjuk elérni, mely azon a szerveren van, ahol a postafiókunk. Amennyiben azon a szerveren pont nincs replika, akkor valószínűleg azt a szervert fogjuk elérni, amelyiken van replika és egy site-on van a postafiókunkat tartalmazó szerverrel. Habár létezik tool ennek pontos kiderítésére (MFCMAPI), de a használata nem nevezhető egyszerűnek. (Ez a segédeszköz az Information Store-ban tárolt paramétereit mutatja meg az egyes foldereknek. Jelen esetben a PR_REPLICA_SERVER paraméter tartalma érdekelhet minket.)
Ejtsünk még pár szót az applikációs logról. Alaphelyzetben az Exchange szerver nem túl bőbeszédű. Ha azt szeretnénk, hogy megeredjen a nyelve, fel kell emelni a logolás szintjét. Ezt megtehetjük a grafikus felületen vagy a registry-n keresztül. Nyilván van valami különbség a kettő között: a grafikus felületen beállítható maximum paraméter 5-ös erősséget takar, míg a registry-n keresztül beállíthatjuk az abszolút legerősebb logolási szintet, a 7-est.
Még azt kell eldöntenünk, melyik paraméteren állítsunk erősséget. Habár a Replication Errors paraméter nagyon illegeti magát, gyakorlati haszna nincs. Válasszuk helyette a Replication Incoming és a Replication Outgoing paramétereket; becsületszóra jobban járunk velük.

6. ábra Logolási erősség állítása grafikus felületről

7. ábra Logolási erősség állítása a registry-ben

Érdemes megfigyelni, hogy a 6. ábrán bekattintott Maximum erősség a 7. ábra szerint egyáltalán nem a maximum.

És most akkor jöjjenek a tipikus problémák.

1 A szerver nem publikálja a változásokat

Szokásos alaphelyzet. Jön Béla és módosít egy nyilvános mappa elemet – mert Béla már csak ilyen. Csakhogy Jenőnél a változás nem jelenik meg.
Induljunk el a változás forrásától. Első körben nézzük meg, azon a szerveren, amelyen a módosítás történt, be van-e kapcsolva a public folder replikáció. (A replikáció időzítését a 4. ábrán látható panelen tudjuk megnézni.) Az ‘always run’ érték jelenti a 15 percet. A legtöbbször egyébként nem folder szinten szokták hangolni a replikációs időzítéseket, hanem store szinten.
Amennyiben be van kapcsolva, akkor emeljük fel az események logolási szintjét a korábban említett módon és változtassunk meg egy újabb elemet. Most jön 15 perc dartsozás. (Alternatívaként lehet a képernyőt is bámulni üveges szemmel.) Ha nem találunk az applikációs logban 0×4 vagy hierarchia változtatás esetén 0×2 bejegyzést, akkor gáz van – a szerver nem publikálja, hogy rajta változtatás történt. Nagy valószínűséggel a PFRA nem indult el – és ez bizony nagyon nem jó hír. Általában ez az eset mixed módú organizációkban fordul elő, ahol még vannak 5.5 szerverek is. (Egy ilyen esettel foglalkozik pl. a 272999 KB cikk.) Ugyanezt a jelenséget tapasztaljuk, ha az 5.5 – 2000/2003 rendszerek között nem működik megfelelően a legacyDN – SID konverzió. (Ilyen eset lehetséges, ha a konverzió során ugyanaz a SID generálódott le két különböző felhasználónak. Értelemszerűen, ezt manuálisan kell korrigálni.)

2 Tényleg a szükséges szervernek lett elküldve a replikációs csomag?

Folytassuk az előző esetet. Tegyük fel, hogy 15 percen belül megtaláltuk a 0×2/0×4 bejegyzést az applikációs logban – tehát a szerver elküldte a replikációs csomagot. Kérdés, hogy hová? Ugye az alap probléma, hogy Jenő szerverén nem látszik a változás – azaz a szerver nem kapja meg a csomagot. Ez klasszikus levéltovábbítási probléma – úgy is kell megoldani.
Ilyenkor vesszük elő a Message Tracking Centert. Jó tudni, hogy a replikációs üzeneteket a PFRA-k úgy küldözgetik egymásnak, hogy mind a feladó, mind a címzett az adott szerver Public Folder Store szolgáltatása. Ezek smtp címei pedig a következőképpen generálódnak: <servername>-IS@<domain.name>; azaz pl. Clack1-IS@cegnev.hu.
Mind a hiba oka, mind a konkrét megoldás sokféle lehet. Mindet nem áll szándékomban sorba venni, inkább leírok egy konkrét esetet a saját élményeimből. Clack1-n változtattunk public folder tartalmat, de a változás nem ment át Clack2-re. Applikációs log szerint a replikációs üzenet elment – és ugyanezt tapasztaltam a Message Tracking szerint is. Clack2 ennek ellenére már nem kapta meg a replikációs csomagot. Hirtelen ötlettől vezérelve elkezdtem másképp kérdezgetni a Message Tracking-et. Addig ugyanis úgy vizsgálódtam, hogy beírtam egy időintervallumot és ott látszott, hogy igen, az egyik IS elküldte a másiknak a levelet. Most beírtam a konkrét emailcímeket (lásd fent), és amikor a címzettére kerestem rá, akkor nem kaptam találatot.

Kis kitérő: az smtp cím érdekes állatfajta. A címzett címe szerepel egyfelől a borítékon, másfelől magában a levélben is. Az ‘okos’ levélmutogatók ezt a belső címet szokták mutatni, mondván, hogy ez való inkább emberi fogyasztásra. Sajnálatos módon a levéltovábbítás a borítékra írt cím alapján működik – legalábbis az első lépésben. (A reply… az egy más világ.)

Nos, ez történt itt is. A szép cím a levélben tényleg a távoli IS neve volt, de a borítékra nem került fel semmilyen cím sem – tehát a levelek elmentek a nagy fekete semmibe. Ez onnan derült ki, hogy elővettem az ADSIedit segédprogramot és megnéztem az Active Directory konfigurációs névterében, hogy a célzott szerver IS szolgáltatásán belül konkrétan mi a Public Folder Store smtp címe. Konkrétan üres volt.

8. ábra Public Folder Store smtp címének tárolási helye a címtárban

Miután beírtam a megfelelő címet és megvártam, hogy szétreplikálódjon, beindult a public folder replikáció is.

3 Eljutott-e odáig a csomag?

Ha Clack1 elküldte a replikációs csomagot és ténylegesen Clack2 smtp címét írta bele, de ennek ellenére Clack2 mégsem kapta meg azt (nem szerepel az applikációs logjában a 0×2/0×4 üzenet), akkor ott levéltovábbítási problémával állunk szemben. Belépett a levélelkapó manó az organizációba. Ilyenkor segíthet a Message Tracking, az ArchiveSink segédprogram, illetve az egyes konnektorok és egyáltalán az email routolás átnézése. (Ez utóbbiról már írtam egyszer egy részletesebb cikket.)

4 A fogadó szerver megkapja a replikációs csomagot, de nem történik semmi.

Egyre cifrább, mi? Clack2 megkapta a replikációs csomagot – a Message Tracking szerint – de az applikációs logja nem mutat semmit. (Nyilván itt is maximálisra állítottuk a két paraméter logolási szintjét.) Ilyenkor mi van?
Alapvetően két eset lehetséges.

Elképzelhető, hogy a szerveren korrupttá vált a Replication State táblázat.
Gyors ismétlés: ez egy olyan táblázat, melyben a szerver adminisztrálja az egyes replikációs csomagokat. Minden replikabeli foldernek külön sora van.
Simán előfordulhat, hogy egy sor kiesik a táblázatból. Ekkor, hiába szerepel Clack1 replika listájában, hogy Clack2-n is van a konkrét foldernek replikája, és hiába látszik ugyanez Clack2-n is a grafikus felületen, Clack2 a Replication State tábla alapján úgy érzi, hogy nála bizony nincs – és lepergeti magáról a replikációs csomagokat. Gyógyítani lehet a klasszikus kiszáll-beszáll módszerrel: eltávolítjuk a folder replika listájáról Clack2-t, majd újra visszarakjuk.
Azért létezik ennél cizelláltabb megoldás is, az isinteg programnak van egy olyan kapcsolója, hogy replstate. (Egész konkrétan lásd a 889331 KB cikkben.)

Nézzük a másik esetet.
Exchange2003 esetében képbe kerülhet egy jogosultsági problémára visszavezethető hibaforrás is. Az Exchange2003 ugyanis igényli, hogy a feladó szervernek meglegyen a Send As joga a fogadó szerver virtuális SMTP szerverén. Ellenkező esetben a fogadó szerver nem fogja tudni lejátszani a replikációs csomagot. Alaphelyzetben ez a jogosultság adott… de a jogosultságok arról híresek, hogy az adminisztrátorok elállítgatják. (Nem feltétlenül kell persze semmit sem elállítani: elég, ha a feladó szerver kikerül az Exchange Domain Servers csoportból.) Hogy cifrázzam a helyzetet, olyasmi is előfordulhat, hogy habár a jogosultságok léteznek, de a fogadó szerver Kerberos hiba miatt képtelen autentikáltatni a feladó szervert.

5 Tudja-e a PFRA, hogy hiányzik adata?

Honnan is tudná az a szerver? Emlékszünk rá, egy konkrét folder teljes CNset-je a státusz üzenetekben utazik. Ha kimarad egy változás, akkor bizony a szerver egész addig nem értesül a változtatásról, amíg ugyanabban a folderben nem következik be egy másik változás. (Eltekintve azon ritka esetektől, amikor módosítjuk a replika listát vagy visszatöltünk mentésből egy régebbi állapotot – illetve el nem telik 24 óra a legutóbbi változás óta.)
Arra is emlékszünk, hogy a hiányzó változás rákerül a szerver kívánságlistájára, majd a timeout letelése után a szerver elküldi a backfill igényt. (0×8) A kívánságlistát közvetlenül nem tudjuk olvasni, de ha meredt szemmel figyeljük az applikációs logot, akkor észrevehetjük a 0×8 üzeneteket. Ha van ilyenünk, akkor biztosak lehetünk benne, hogy a PFRA tudja, hogy valami hiányzik.
A módszer egyetlen hátránya, hogy kicsit sokat kell várni. Ha például egy másik site-on van egyedül megfelelő replika, akkor az első timeout 12 óra, a második 24 és a harmadik 48 óra. Ennyi még dartsból is sok.
Le lehet egyszerűsíteni a szituációt úgy, hogy rákényszerítjük a szervert arra, hogy vegye tudomásul a hiányzó változást. Ehhez természetesen különböző módszerekkel státusz információkkal kell bombáznunk.

    1. A kijelölt szerver 0×20 (status request) csomagot küld a replikáknak.
    2. A kijelölt szerveren lenullázódik a backfill timeout.
  • Egyik lehetőség, hogy elmegyünk egy másik szerverre és megváltoztatunk valamit az illető folderben. Ilyenkor a replikációs csomagba belekerül a folder státusz információja is, tehát a lazsáló szerver biztos megkapja a szükséges információkat.
  • Van egy remekül eldugott opció, melynek segítségével kikényszeríthetjük a tartalom szinkronizálást.
  • 9. ábra Tartalomszinkronizálás kikényszerítése

    Ha itt azt mondjuk egy folderen állva, hogy Synchronize Content, akkor két dolog történik:

    Ebből az első a lényeges most számunkra: az egyik szerverről kiadott status request ugyanis mellékesen tartalmazza a szerver által ismert státusz információt is – nekünk pedig pont az a célunk, hogy a távoli szerverhez eljussanak ezek az információk.
    Konkrétan: ha azt szeretnénk, hogy Clack2 megtudja, hogy nála hiányzik egy változás, akkor Clack1 megfelelő folderén kell megnyomni a Synchronize Content gombot. (És nagy ívben nem fog érdekelni minket, hogy Clack2 visszaküld majd egy 0×10 üzenetet.)

  • Ugyanezt a trükköt tudjuk eljátszani a Send Hierarchy / Send Contents opciókkal is.
  • 10. ábra Hierarchia replikáció kikényszerítése

    11. ábra Tartalom replikálásának kikényszerítése

    Ekkor ugyan backfill válaszokkal küldjük meg a célzott szervert, de jelen esetben ez mindegy; az a lényeg, hogy az státusz információkhoz jusson, azok pedig a backfill válaszokban is benne vannak.

  • Használhatjuk a korábban említett Replication Flag registry turkálást.

6 Ha tudja, akkor igényli is?

Miután jól kitömtük a szervert státusz információkkal, most már egész biztosan tudnia kell, hogy nem teljesen naprakészek a folderei. Kérdés, hogy ezután fog-e tenni valamit tudásbéli hiányosságainak leküzdésére?
Amit konkrétan szeretnénk látni, az az, hogy a szerver nekiáll a megfelelő replikákat tartalmazó szerverek felé 0×8 (backfill request) csomagokat küldeni. Ugyan várhatunk, hátha egyszer megjelenik az applikációs logban, de azért a timeout értékek meglehetősen ijesztőek. Jobb, ha akcióba lépünk. Az előző pontban szóba került egy módszer, a Synchronize Content. Megemlítettem, hogy ez mellékesen lenullázza a backfill timeout-ot is. Pont ez kell nekünk. Immár azon a szerveren, ahol hiányzik a tartalom, kiadunk egy Synchronize Content parancsot és egyből ki is kell menniük a 0×8 csomagoknak.

Mi van, ha mégsem mennek ki? Pontosabban valamerre kimennek, de pont a minket érintő csomagok nem jelennek meg? (Mi is érdekel minket? Van egy konkrét folder, amelyikben tudjuk, hogy nem frissül egy objektum. Tudjuk, hogy ennek mely szervereken vannak replikái – tehát szeretnénk olyan 0×8 csomagokat látni, melyek e replikák felé mennek és a kérdéses folder tartalmat igénylik.)
Ha ebbe az esetbe ütközünk, akkor jobb, ha tudjuk, hogy kivertük a biztosítékot. Van ugyanis egy ún. lassító mechanizmus a public folder replikációs folyamatban. (Én mondtam, hogy az Exchange fejlesztők nem kapkodó idegbetegek.) Ezt úgy hívják, hogy Outstanding Backfill Limit – és azt szabályozza, hogy a kívánságlista ne nőhessen a végtelenségig. Alaphelyzetben 50 elemet tartalmazhat. Természetesen ha egy backfill csomag beérkezett, akkor a PFRA kihúzza azt a listáról és bekerülhet helyére egy újabb. Viszont ha a szerver olyan csomagokat igényel, melyek már nincsenek meg egyik Exchange szerveren sem, vagy a szükséges Exchange szerver éppen elérhetetlen, akkor ez az ötven kívánság beragad és a többiek nem jutnak lehetőséghez.

Két dolgot tehetünk:

  • Nekiállunk dolgozni. Megnézzük az applikációs logban, hogy hová mennek a 0×8 csomagok és mit igényelnek. Aztán megpróbáljuk elérhetővé tennük számukra a szükséges változtatásokat.
  • Berugdossuk a dögöt az ágy alá. Registry piszkálással a fenti limit megnövelhető, egészen ötezerig. Ekkor viszont időszakonként komoly backfill viharokra számíthatunk, mely veszélybe sodorhatja az Exchange szerverek elérhetőségét.

7 Foglalkozik-e a többi szerver az igénnyel?

Az eddig leírtak alapján már nagyon könnyen nyomozhatunk. Láttuk, hogy az igénylő szerver elküldte a 0×8 backfill kéréseket.
Vizsgáljuk meg a megcélzott szerverek applikációs logját, hogy megkapták-e a csomagokat?
Ha megkapták, nézzük meg, válaszolnak-e rájuk. Ha igen, akkor azt kell látnunk, hogy megjelennek az applikációs logban a 0×80000002 illetve 0×80000004 backfill válasz üzenetek. (Értelemszerűen nem ugyanannyi válasz lesz, mint amennyi igény érkezett. Az igény azt mondja meg, hogy melyik változás kell neki. A válaszban meg megy a módosított elem – és ha a módosított elem nagyobb, mint a replikációs üzenet maximális engedélyezett mérete, akkor a PFRA több üzenetbe tördeli. Ugyanezért ne essünk kétségbe, ha a válasz nem egyből jelenik meg az igény fogadása után – elképzelhető, hogy sokat kell a csomag összeállításával bajlódnia a PFRA-nak.)

8 Megkapja-e a szerver az igényelt válaszokat?

Szinte már semmit nem kell írnom. A szokásos módon, az applikációs logok és a Message Tracking segítségével nyomon tudjuk követni, hogy mi történt a backfill válasz csomagokkal. Ha a szerver nem kapta meg, akkor levéltovábbítási problémánk van megint. Ha megkapta, de nem érvényesül a változás, akkor pedig a 4. pontban írtakkal állunk ismét szemben.

Nos, ennyi.
Remélhetőleg sikerült utat vágnom a dzsungelben.

Mi van még?
Az irodalom.
A cikk összeállításában sokat segített a Microsoft Technet Exchange szakkönyvtár és az Exchange csapat blogja. Mindkettő erősen ajánlott olvasmány.

A misztikus public folder replikáció II.

Az előző részben szó esett nagy általánosságban a public folderekről, felépítésükről és a public folder replikáció építőelemeiről. Leírtam, alaphelyzetben hogyan replikálódik egy elem, miután módosította őt Béla.
Ebben a részben elindulunk a dzsungel belsejébe. Vigyázat, túristaösvény csak az első pár méteren lesz.

III Kínzó kérdések

1. Mi történik akkor, ha egy szerver – a rajta tárolt adatokhoz képest – régebbi módosítást tartalmazó csomagot kap?

Tulajdonképpen nem is az a kérdés, hogy mi történik – sokkal inkább az, hogy hogyan derül ez ki? Mint korábban írtam, a replikáció nem időbélyeg alapú. A kulcsszereplő jelen esetben a Message State információk közül a predecessor change lista. Ebben van az összes olyan CN, mely valaha is hozzá volt rendelve az adott objektumhoz.

Nézzünk egy példát.

Legyen az objektum predecessor change listája a következő:

<guid -Clack1>-1210
<guid -Clack2>-6547
<guid -Clack1>-1068

Értelemszerűen ez mindegyik replikánál egyforma. Jön Béla és módosítja a Clack1 gépen lévő objektum nevét. Ekkor Clack1 predecessor change listája így fog kinézni:

<guid -Clack1>-1541
<guid -Clack1>-1210
<guid -Clack2>-6547
<guid -Clack1>-1068

Ezt a PFRA belecsomagolja a replikációs csomagba és elküldi Clack2-nek. Ő kicsomagolja és az összehasonlítás után észreveszi, hogy az őnála lévő predecessor lista részhalmaza az újonnan küldött listának, tehát az új lista a király.
Ha valamilyen baleset következtében régebbi módosítást kap meg, akkor azt fogja találni, hogy az új lista részhalmaza a nála lévő listának – kacag egy jóízűt és ignorálja a replikációs csomagot.

2. Mi történik ha egyszerre módosítják ugyanazt a – különböző replikákban létező – objektumot?

Jön Béla és kegyetlenül megint módosítja az előző objektumot. Igenám, de színre lép Jenő is, akit szintén ellenállhatatlan kényszer gyötör, hogy módosítsa ugyanazt az objektumot. Sajnálatosan Jenő postafiókja Clack2-n van. Ráadásul mindez azonos replikációs intervallumon belül történik meg.
Nézzük a példát:

Kiindulási állapot:

Clack1 Clack2
<guid -Clack1>-1210 <guid -Clack1>-1210
<guid -Clack2>-6547 <guid -Clack2>-6547
<guid -Clack1>-1068 <guid -Clack1>-1068

Béla módosít:

Clack1 Clack2
<guid -Clack1>-1541
<guid -Clack1>-1210 <guid -Clack1>-1210
<guid -Clack2>-6547 <guid -Clack2>-6547
<guid -Clack1>-1068 <guid -Clack1>-1068

Jenő módosít:

Clack1 Clack2
<guid -Clack2>-7124
<guid -Clack1>-1210 <guid -Clack1>-1210
<guid -Clack2>-6547 <guid -Clack2>-6547
<guid -Clack1>-1068 <guid -Clack1>-1068

Megtörténik a replikációs csomagok elküldése. Ezeket a predecessor change listákat kell összehasonlítaniuk a szervereknek:

Clack1 Clack2
<guid -Clack1>-1541 <guid -Clack2>-7124
<guid -Clack1>-1210 <guid -Clack1>-1210
<guid -Clack2>-6547 <guid -Clack2>-6547
<guid -Clack1>-1068 <guid -Clack1>-1068

Látható, hogy egyik sem részhalmaza a másiknak. Replikációs konfliktus keletkezett.
Mi alapján döntik el a PFRA-k, hogy melyik módosítás nyert? Aki azt mondja, hogy majd az időbélyeg dönt, azzal közlöm, hogy ugyan logikusan tetszik gondolkozni, de jelen esetben nincs szivar. A konfliktusnak ugyanis kifejezetten csalafinta feloldását fundálták ki az Exchange fejlesztők.
Maga a PFRA lép akcióba és küld egy ún. conflict message üzenetet Bélának és Jenőnek. Mindemellett a konkrét folder összes tulajdonosánál is bemószerolja őket. Sőt, az üzenetet bemásolja a public folderbe, ahol persze szétreplikálódik az összes szerverre, ahol létezik replikája. Majd ezek után angyali mosollyal kisétál a szobából és hagyja, hogy az érintettek ököljog alapján rendezzék a helyzetet.
(Hierarchia replikációs ütközésnél egy kicsit visszafogottabb a PFRA, ekkor csak a folder tulajdonosait értesíti.)

3 Mi történik, ha el lett lazsálva egy replikáció?

Eddig egy ideális világról beszéltünk. Clack1 észlelte a változást, elküldte a csomagot Clack2-nek, aki lelkesen frissítette is az objektumot. De mi van, ha pont arra jár a levélelkapó manó és a replikációs csomag nem érkezik meg? Ugye, tudjuk, Clack1 a csomag elküldésének pillanatában el is könyvelte, hogy Clack2 is módosított. Ő ugyan több értesítést nem fog küldeni. Clack2 meg elégedetten üldögél a fenekén, fogalma sincs, hogy neki módosítania kellett volna.
Pánikra nincs ok. (Az Exchange egyébként is a türelmes adminisztrátorok platformja.) Létezik egy mechanizmus, mely ezeket a lyukakat hivatott felderíteni. Az egyes szerverek PFRA szolgáltatásai időnként státusz információkkal bombázzák egymást – márpedig a státusz információk CNset-ekből állnak, azok meg CN értékekből. Ebből mindegyik PFRA ki tudja bogarászni, hogy megvan-e nála az összes módosítás, amely egy objektumot érintett. Ha talál olyat, amelyik nála nincs, akkor azt a módosítást felveszi a kívánságlistájára. Ez utóbbit backfill array-nek hívják.
De ne rohanjunk ennyire. Először járjuk körül, milyen esetekben is cserélnek státusz információkat az egyes szerverek?
Mikor kér egy public folder státusz információkat? (0×20, status request)

  • Egy folderhez hozzáadunk egy replikát… vagy ellenkezőleg, elveszünk tőle egyet.
  • Elindul egy új public folder store.
  • Visszatöltöttünk egy store-t backupból és felcsatoltuk.
  • Újraindítunk egy store-t, úgy, hogy bekattintjuk az ún Replication Flag értékeket a registry-ben. Ekkor a PFRA kéri az összes hierarchia státusz információkat és a nyilvántartása szerint hiányzó tartalom státusz információkat. (Részletesen lásd a 813629 KB cikkben.)
  • Újraindítunk egy store-t, úgy, hogy bekattintjuk az ún Enable Replication Messages On Startup értékeket a registry-ben. Ekkor a PFRA kéri az összes hierarchia státusz információkat és az összes tartalom státusz információkat. (Részletesen lásd a 321082 KB cikkben.)

És vajon mikor küld egy PFRA státusz információkat? (0×10, status message)

  • Minő meglepetés: ha valamelyik szervertől status request (0×20) kérést kapott.
  • Ha már huszonnégy órája nem érkezett frissítés egy folderhez. Ekkor az összes olyan szerver felé elmegy a státusz üzenet, amelyiken van replikája az adott foldernek.

Végül ne felejtsük el, hogy mindegyik replikációs csomagba bele van csomagolva a frissítésben érintett folder státusz információja.

Oké. Státusz információk jönnek-mennek, Clack2 fejéhez kap: Úristen, hiányzik egy konkrét CN számú frissítés!. Fel is veszi egyből a frissítést a kívánságlistájára. Mivel az Exchange programozók is ismerik azt a dalszöveget, hogy “sokkal jobb, ha úgy szerzed, hogy vágyol utána”, ezért nem elégítik ki egyből Clack2 kívánságát. Várnak. Nem is kispályások, a timeout értékek viszonylag magasak. Ha a megkívánt update olyan Exchange szerveren van, mely azonos site-on van az ígénylő Exchange szerverrel, akkor a timeout értékek sorban: 6/12/24 óra – ellenkező esetben 12/24/48 óra.
Nem mondom, hagytak időt bőven arra, hogy a hiányzó értékek esetleg maguktól is odataláljanak.

Kis kitérő. Háromfajta Exchange adminisztrátor van:

  • A legrosszabb típus, a türelmetlen versenyző. Össze-vissza kattogtat és dühöng, hogy miért nem történik semmi. Képtelen felfogni, hogy az Exchange időnként kifejezetten nagy holtidőkkel működő rendszer.
  • Egy fokkal jobb, aki üveges szemekkel bámul apatikusan a képernyőre, de legalább nem kattogtat. Neki ugyanis már van esélye arra, hogy eszébe is jut valami értelmes, nagyjából addigra, amikorra a változások is végighullámoznak a rendszeren.
  • A legérdekesebb az, hogy külső szemlélő számára az előző adminisztrátor és a profi között nem látszik semmi különbség. A profi is ugyanúgy üveges szemekkel ül a monitor előtt – de közben tudja, mi zajlik a háttérben: tisztában van vele, mire vár.

Vissza a száraz elmélethez. Clack2 tehát tudja, melyik CN számú upgrade hiányzik, felvette a kívánságlistára és letelt az első timeout (6/12 óra). A PFRA fogja magát és küld egy backfill request-et (0×8). Kinek? Ez bizony jó kérdés.
Imhol az algoritmus.

  • Clack2 készít egy listát azokról a szerverekről, ahol megtalálható az a replika, mely a kérdéses változáshoz tartozik.
  • A lista elemeit sorba rendezi, a következő szempontok szerint:
    • Működik-e a szerver?
    • Ki a preferred backfill server? (Nem szokott lenni.)
    • Mennyi a transzport költsége?
    • Milyen verziójú az illető Exchange szerver?
    • Hány igényelt változáshoz tartozó csomag található a szerveren?

Nem minden szempont bír azonos súllyal. Általában elmondható, hogy a transzport költsége mindent visz. Logikus, hiszen ha van frissítés az azonos site-on lévő Exchange szervereken, akkor először azoktól kell begyűjteni, még akkor is, ha azok csotrogány 5.5 szerverek.
Most már tulajdonképpen készen is vagyunk. Tudjuk, melyik csomag hiányzik. Tudjuk, melyik szerverről szerezhetjük be optimálisan. Elküldjük neki a backfill request-et (0×8) és meg is kapjuk a csomagot (0×80000002 v. 0×80000004).
Vagy nem. Ha nincs válasz, akkor a szervert úgy veszi a PFRA, hogy nem működik és újra összeállítja a listát. Persze közben a timeout értékek próbálkozásonként szépen nőnek – hasonlóan az Exchange admin ősz szakállához.

4 Mi történik replika hozzáadásakor, elvételekor?

Ez:

  1. Egy konkrét folderből csak egy példány létezik, Clack2 gépen.
  2. Clack1-n dolgozva az adminisztrátor hozzáadja Clack1-t a folder replika listájához.
  3. Clack1 küld egy hierarchia üzenetet Clack2-nek, aki szintén felveszi a replika listára Clack1-t.
  4. Clack1 küld egy status request-et (0×20) Clack2-nek.
  5. Clack2 visszaküld egy status üzenetet (0×10) Clack1-nak, benne a folderre vonatkozó státusz információkkal. (Full CNset.)
  6. Clack1 észreveszi, hogy egyik CN sincs meg nála. Felveszi az egész bagázst a kívánságlistájára.
  7. Letelik az első backfill timeout. Ha még mindig hiányzik a tartalom, Clack1 elkezdi küldözgetni a backfill igényeket (0×8).
  8. Clack2 szorgalmasan küldözgeti vissza a backfill válaszokat (0×80000002 v. 0×80000004).
  9. Clack1 kicsomagolja és lejátssza a módosításokat. Ezzel párhuzamosan törli a megadott számú változást a kívánságlistájáról.
  10. Amennyiben letelik a következő backfill timeout, Clack1 újra elküldi a backfill igényeket.
  11. Előbb-utóbb átkerül a kérdéses folder összes tartalma Clack1-re is.

Mint látható, ilyenkor a szerverek státusz információk segítségével derítik ki, hogy az új szerveren olyannyira hiányoznak a változtatások, hogy tulajdonképpen nincs is rajta semmi. Az összes tartalom átlapátolása ilyeténképp a backfill folyamat segítségével történik. Meg lehet saccolni a dinamikát.
Ebből következik egy gyakorlati tanács is. Ha egy konkrét foldert át szeretnénk migrálni egyik szerverről egy másikra, akkor először fel kell venni a folder replika listájára az új szervert, majd megvárni, amíg az új szerveren a Public Folder Instance listában megtalálható lesz a folder. Utána érdemes csak levenni a régi szervert a replika listáról.

5 Mi történik, ha úgy rakok át egy public folder tartalmat egyik szerverről a másikra, hogy a folder replika ablakában hozzáadom a listához az új szervert, leveszem a régit, majd törlöm a régi szerverről a komplett store-t?

Balhé.
Vizsgáljuk meg alaposabban, mi is játszódik le ilyenkor.
Egyáltalán nem meglepő módon, ha letörlök egy szervert a replika listáról, akkor a szerver nem szabadul meg pánikszerűen a tartalomtól. Ehelyett küld egy speciálisan preparált 0×20 status request-et az összes többi replikának. Ennek van böcsületes neve is, Replica Delete Pending Status Request-nek hívják és RDPSR-nek becézik. Ebben a csomagban van egy flag, amely jelzi, hogy a replika függőben lévő törlésben szenved. Ha a többiek megkapják ezt az üzenetet, akkor egy szintén speciális csomaggal válaszolnak. Ez egy különleges 0×10 csomag, melyet Replica Delete Pending Ack-nek hívnak. (A becenév kitalálása házi feladat.) Azt jelzi, hogy a megszűntetni kívánt replika által birtokolt CN változtatások megtalálhatók egy másik replikán is. (Nyilván csak akkor jön ilyen válasz, ha a változás tényleg létezik máshol.) Nna, ekkor törli csak a PFRA a tényleges tartalmat.
Tegyük fel, rossz napunk volt, türelmetlenek vagyunk, mint egy bespeedezett gepárd. Ahogy módosítottuk a replika listát, egyből megyünk is a megfelelő szerver public folderéhez és töröljük a store-t.
Nos, hacsak nem Exchange2003 Sp2 szerverünk van, akkor nagy valószínűséggel ezzel el is veszítettünk valamennyi nyilvános mappa tartalmat. A korábbi verziók ugyanis nem foglalkoznak azzal, hogy üres-e a Public Folder Instances lista a store törlése előtt. (Az Sp2-t is meg lehet erőszakolni, de az legalább figyelmeztet.)
(Van még egy másik különbség is. Az Sp2 előtti szerverek csak egyszer küldik ki az RDPSR-t, aztán várnak, akár az örökkévalóságig az RDPÁ-ra – persze közben a konkrét szerverről nem tűnnek el a folder példányok. Ilyenkor annyit lehetett tenni, hogy újra felvettük a szervert a replikák közé, majd ismét töröltük, ezzel generálva újabb RDPSR-t. Sp2 után gyakorlatilag óránként generálódik újabb RDPSR.)

Mára ennyit. Holnap újra jövök.

A misztikus public folder replikáció I.

Ez a hosszú írás eredetileg nem ide íródott, de aztán később úgy döntött, hogy visszajön Apucihoz. Pusztán a jobb olvashatóság érdekében szedtem darabokra, egyben valószínűleg igen durva lett volna.

Miről is lesz szó? A csapból évek óta folyik az Active Directory replikációjának boncolgatása. Viszont szó sem esik egy másik nagy replikációs témáról, a nyilvános mappák replikációjáról. Az AD replikáció multimaster replikáció, az adatbázis pedig egy JET alapú adatbázis. Ezzel szemben a public folder replikáció multimaster és JET alapú adatbázisok játszanak benne.

Nocsak. Akkor most ugyanarról beszélünk vagy sem?

Természetesen nem. Az egyik esetben az AD ldap adatbázisa replikálódik, a másik esetben az Exchange Information Store adatbázis egyik adatbázisa. Történelmi okokból a két replikáció működési mechanizmusa még csak véletlenül sem hasonlít egymásra.
Hogy még cifrább legyen a helyzet, a public folderek adatai egy kicsit össze is vannak keverve az adatbázisok között. De erről majd később. Most ugorjunk neki az első témának.

I. Általában a public folderekről

Gondolom, itt nincs túl sok szükség szószaporításra. Akinek volt már postafiókja Exchange szerveren – bármilyenen – és próbálta már azt MAPI kliensen keresztül elérni, pontosan tudja, miről beszélek.
Igen, a folder lista alján található nyilvános mappákról. Ezek egyfajta kollektív tárolóhelyek, mindenféle közösen használt anyagokat szoktak itt tárolni az egyes cégek. Láttam már itt céges telefonkönyvet e-mailbe ágyazott Excel tábla formájában, láttam már különböző szintű vállalati rendelettárat… és végtelen a fantázia szárnyalási tere, hogy mi mindent lehet még ide betenni.

Persze mi műszaki emberek vagyunk, minket sokkal jobban érdekel, hogy hogyan is tárolja mindezt az Exchange szerver. Nos, jelen esetben két különböző helyen tárolódnak adatok: egy részük az Active Directoryban helyezkedik el, más részük pedig az Information Store adatbázisaiban. Az első adatcsoporttal most nem szándékozom túl sokat foglalkozni, ezek az adatok jól érzik magukat a címtárban, boldogan használják annak replikációs szolgáltatásait, köszönik szépen. Ide tartoznak az egyes store-ok paraméterei és konkrét nyilvános mappák meglehetősen sok tulajdonsága is. Például amennyiben az egyes folderekhez smtp címet rendelünk, az a cím is a címtárban rögzül.

1. ábra Public folder smtp címe az Active Directory-ban

(Mondjuk egy pillanatra álljunk meg és gondolkodjunk el, hogyan is működik _egymás mellett_ a kétfajta replikáció: a címtáré és az Information Store-ban tárolt nyilvános mappákké. Megvan? Akkor várjunk egy kicsit, amíg elmúlik a szédülés.)

Jelen írás mindemellett azokra az adatokra fókuszál, melyek az Information Store adatbázisában helyezkednek el.

A legfontosabb, hogy tisztában legyünk az adatok tárolási formájával. Pongyolán fogalmazva, a JET tárolási forma lényege, hogy van egy adatbázis, amelyben ömlesztve találhatók mindenféle adatok és egy másik, ehhez kapcsolódó adatbázis, melyben tömérdek pointer mutat rá a másik adatbázis egyes adataira, értelmezhetővé téve azokat. Ezután egyáltalán nem meglepő, hogy a public folderek tárolását is úgy célszerű elképzelni, hogy van külön a folder hierarchia és van külön a tartalom.

Amíg egy szerverünk van, nincs is különösebb baj. Ott vannak rajta a postafiók adatbázisok (melyiken mennyi) és emellett ott van az egy darab MAPI oldalról elérhető public folder adatbázis. (Több, ha megfeszülünk sem lehet.) A hierarchia és a tartalom egy szerveren figyel, az élet szép – és legfőképpen egyszerű. Nagyobb cégeknél viszont teljesen normális, hogy több Exchange szerverük van, esetenként egymástól meglehetősen távoli telephelyeken is. A felhasználói postafiókokkal nincs probléma, azok nyilván azokon a szervereken lesznek, amelyeket a konkrét felhasználók gyors hálózaton keresztül érnek el. De mi legyen a public folderekkel? Valamennyit itt is lehet szeparálni, amennyiben léteznek telephely specifikus folderek… de ez általában csak kis hányad. Marad az, hogy a public foldereket le kell tükrözni mind a központi, mind a telephelyi Exchange szerverekre. (Ez mellékhatásként egyben a rendelkezésre állást is növeli. Egyet fizet, kettőt kap.)

Vizsgáljuk meg, mit is jelent ez a kifejezés, hogy ‘letükrözni’? Le kell tükröznünk a hierarchiát? Nekünk ugyan nem. Az ugyanis olyan, mint az Alien nyála: áteszi magát még a saválló acélmenyezeten is. Amennyiben a folderek jogosultságát nem piszkáljuk, a folderszerkezetet – hierarchiát – minden telephelyen egyformán látni fogják. A tartalom… az már egy másik történet. Itt már mi szabályozhatjuk, hogy mi történjen. Ha akarjuk, letükrözzük. Ekkor ha valaki el akar olvasni egy nyilvános mappában lévő levelet, azt a helyi Exchange szerverről fogja megkapni. Alapértelmezetten biztos lehet benne, hogy ez a levél 15 percen belül friss. Persze nem kötelező tükröznünk. Biztos vannak olyan mappák, melyeket szökőévente használnak egyes telephelyeken. Ilyenkor rábízzuk magunkat az Exchange belső mechanizmusaira: ha nem találja meg a tartalmat azon a szerveren, amelyiken a felhasználó postafiókja van, ki fogja nyomozni, hogy melyik másik szerveren van belőle példány és onnan adja ki. Végül előfordulhat olyan eset, hogy a telephelyen csak szökőévente használnának egy foldert és akkor is tilos nekik: ilyenkor a két Exchange szerver közötti konnektoron egyszerűen le kell tiltani a public folder tartalmak elérhetőségének a közlekedését.

2. ábra Public folder referral tiltása

Közeledünk a cikk fő témájához. Akik üzemeltetnek többszerveres Exchange organizációt, tudják, hogy a tükrözés, vagy nevezzük mostantól népszerűbb nevén – a replikáció – egyáltalán nem olyan kezes bárány, mint ahogy a tankönyvek írják. Sőt. Megismerve a működési mechanizmusát, egyből Pratchett Korongvilágának sárkányai jutottak eszembe: azok a lények annyira bonyolult működésűek voltak, hogy csoda, hogy egyáltalán éltek.

II. A replikáció közelebbről

Meglehetősen száraz anyag fog következni: bemutatom a replikációban résztvevő szereplőket és a köztük lévő viszonyokat.

Magát a public folder replikációt az Information Store szolgáltatás menedzseli, azon belül is a Public Folder Replication Agent, becenevén PFRA. (Természetesen a replikációs üzenetek szállítását nem ő végzi – azért a mindenkori szállítási mechanizmus felel. Minden másért a PFRÁ-t kell ütni.)

A különböző szervereken található azonos foldereket replikáknak nevezzük.

3. ábra Egy konkrét nyilvános mappa replika listája

Az AD replikáció és a PF replikáció között időnként találhatunk hasonlóságot: az egyik ilyen az, hogy az időbélyeg egyik esetben sem domináns. Az AD replikáció esetében az ún USN érték hordozza a fontos információt, PF replikáció esetén pedig a Change Number, röviden CN.
Ez a következőképpen épül fel: <is -GUID>-counter. Gondolom, nem kell magyaráznom, mindegyik szerver Information Store szolgáltatása objektumként szerepel a címtárban és mint ilyen, van neki egy GUID értéke. A számláló pedig egy szerverhez kötődő, monoton növekvő érték. Amikor bármit változtatnak valamelyik lokálisan tárolt nyilvános mappabéli elemen, akkor a számláló értéke eggyel nő. Az így keletkező CN kötődik hozzá a megváltoztatott objektumhoz és lesz egyben a változás azonosítója is. (Amikor létrejön az objektum, az is egy változás – azaz már születése pillanatában mindenki kap egy CN értéket.)

Ez azért önmagában kevés. Létezik egy olyan fogalom, hogy Message State Information. Minden változáshoz rendelhető egy ilyen csomag. Három fő eleme van:

  • CN: change number
  • Predecessor change list: Ez egy lista. Azokat a CN értékeket tartalmazza, melyek már korábban kötődtek az illető objektumhoz. Figyelem, itt azok a CN értékek is megtalálhatók, melyek más szervereken keletkeztek!
  • Időbélyeg

A Message State Information elemek szerverek között utaznak.

Mindemellett a replikáció adminisztrálásához szükség van lokális információtárolásra is, erre valók az ún. Replication State táblázatok. Durván úgy kell elképzelni, mintha a Message State információkból egy olyan Excel táblát építenénk fel minden szerveren, amelyikben replikánként külön sora van az objektumoknak.

A CN értékeket általában össze szokták kapni egy csokorba. Ezt a csokrot CNset-nek nevezzük. Egy konkrét folder összes objektumának CNset csokrát pedig státusz információnak.

Fontos tisztáznunk, hogy mit tartunk a replikáció elemi egységének. Ez az egység az objektum – azaz ha egy objektum bármelyik tulajdonságának az értéke megváltozik, akkor a teljes objektum utazik. Egész konkrétan:

  • Hierarchia esetén pl. létrehozunk egy új könyvtárat vagy megváltoztatjuk egy könyvtár egyik tulajdonságát, – mondjuk a nevét -, akkor a könyvtárobjektum tokkal-vonóval, összes tulajdonságával együtt fog résztvenni a replikációs folyamatban.
  • Tartalom esetén új üzenet létrehozása, meglévő üzenet tulajdonságának megváltoztatása egyaránt azt fogja okozni, hogy az üzenet – az összes tulajdonságával együtt – részt fog venni a replikációban. (Értelemszerűen az összes tulajdonságba az elem tartalma is beleértendő.)

Látható, hogy a replikációs mechanizmus igazából sok kisméretű objektum replikációja esetén érzi jól magát. Ha nagyméretű csatolások vannak a levelekben, és valaki bármilyen apróságot is megváltoztat egy levél objektumon, az egész üzenet fog utazni, böszme csatolásával együtt.

A replikációs csomagokat a következőképpen kell elképzelni. A PFRA elkészíti a Message State információs táblát, ehhez hozzácsapja a megváltozott objektumot, a folder státusz információit, az egészet elkódolja, majd rávési a címzett nevét és továbbpasszolja a szállító mechanizmusnak. A kódolás base64 algoritmussal történik és úgy hívják, hogy TNEF (Transport Neutral Encapsulated Format). Az eredmény az oly hőn szeretett winmail.dat csatolás a levélben.

A felsorolás végére hagytam a legfontosabb táblázatot. Akármilyen replikációs lépés is történik, arról bejegyzés kerül az eseménynapló applikációs logjába – feltéve, hogy érzékenyre van állítva a logolás. Az események ‘type’ paramétere utal arra, hogy mi is volt a replikációs lépés.

Type Magyarázat
0×2: hierarchia A hierarchia egyik elemének replikációja történt meg.
0×4: tartalom A tartalom egyik elemének replikációja történt meg.
0×8: backfill igénylés Hiányzó elem (hierarchia/tartalom) pótlásának igénye.
0×80000002 (hierarchia) v. 0×80000004 (tartalom): backfill válasz Hiányzó elemek elküldése.
0×10: státusz Egy folder teljes CNset-jének elküldése egy replika felé (hierarchia/tartalom)
0×20: státusz igénylés Egy replikabeli folder teljes CNset-jének megigénylése.

Ez egy nagyon fontos táblázat. Aki tényleg érteni szeretné a későbbieket, addig ne is olvasson tovább, amíg egy firkálólapra fejből nem tudja reprodukálni ezt a táblát.
Amikor nyomozni kell, hogy mi is történt, ezekkel a számokkal fogunk dolgozni.

Most pedig menjünk végig egy egyszerű replikációs folyamaton, lépésről lépésre.

1. Béla módosít egy elemet a nyilvános mappában. (Ez a változás azon a szerveren fog megtörténni, amelyiken Bélának a személyes postafiókja is van. Amennyiben azon nincs meg a public folder elem, akkor az a szerver fog játszani, amelyikről Béla beolvasta az elemet.)

2. Az illetékes szerveren futó PFRA észleli a változást.

3. A következő replikációs ciklusban (alapértelmezésben 15 perc, egyébként pedig a konkrét public folder store tulajdonságlapján állítható) a PFRA megvizsgálja, hogy létezik-e a megváltoztatott elemnek replikája.

4. A PFRA kioszt egy CN-t és hozzárendeli az objektumhoz.

5. A PFRA elkészíti a replikációs csomagocskát. Ez objektumonként tartalmazza a Message State információs táblát és magát az objektumot. Emellé odacsomagolja még a feladó folder státusz információját is.
A levélforgalom csökkentése miatt egy csomagba nem csak egy változás adatai kerülhetnek bele. Hierarchia változások nagyon jól elvannak egymás mellett, hasonlóan az egy folderhez tartozó tartalomváltozások is. Hierarchia változás nem keveredhet egy csomagon belül tartalomváltozással. Hasonlóan különböző folderekhez tartozó tartalomváltozások sem keverhetők. (Ekkor egy csomagon belül két státusz információ menne.)

6. A PFRA ráírja a csomagra a címzett nevét és feladja. Akárhány replika is létezik, ő csak egy példányban adja fel a csomagot – a többiről már az Exchange szállítási mechanizmusa gondoskodik. A PFRA olyan szinten megbízik ebben a mechanizmusban, hogy minden visszajelzési igény nélkül be is vési a maga kis táblázatába, hogy az illető replikák szinkronban vannak.
Az applikációs logba bekerül egy 0×2 vagy 0×4 típusú bejegyzés, amennyiben érzékenyre van állítva a logolás.

4. ábra Replikációs csomag elküldésére utaló 0×2 bejegyzés az applikációs logban

7. A fogadó szerver PFRA szolgáltatása kicsomagolja a csomagot. Az applikációs logba bekerül egy 0×2 vagy 0×4 típusú bejegyzés.

8. A PFRA elemzi a Message State információs táblák értékét és ez alapján eldönti, mely elemeket kell módosítania a saját lokális adatbázisában.

9. A PFRA elvégzi a módosításokat.

10. A PFRA adminisztrál: átvezeti a módosításokat a saját Replication State táblázatában. A státusz információkban lévő CNset alapján leellenőrzi, hogy a folderre vonatkozóan minden objektumból tényleg a legfrisebb verzióval rendelkezik-e? Amennyiben nem, akkor pánikba esik és a backfill folyamatért szalajt. (Lásd később.)

Ezzel megvolt az alapozás. Holnap folytatom.