Month: June 2006

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 0x4 vagy hierarchia változtatás esetén 0x2 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 0x2/0x4 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 0x2/0x4 ü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. (0x8) 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 0x8 ü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.

• 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:

1. A kijelölt szerver 0x20 (status request) csomagot küld a replikáknak.
2. A kijelölt szerveren lenullázódik a backfill timeout.

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 0x10 ü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é 0x8 (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 0x8 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 0x8 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 0x8 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 0x8 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 0x80000002 illetve 0x80000004 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.

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ő:

É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:

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:

Béla módosít:

Jenő módosít:

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

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? (0x20, 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? (0x10, status message)

• Minő meglepetés: ha valamelyik szervertől status request (0x20) 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 (0x8). 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 (0x8) és meg is kapjuk a csomagot (0x80000002 v. 0x80000004).
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 (0x20) Clack2-nek.
5. Clack2 visszaküld egy status üzenetet (0x10) 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 (0x8).
8. Clack2 szorgalmasan küldözgeti vissza a backfill válaszokat (0x80000002 v. 0x80000004).
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 0x20 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 0x10 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.)