Month: June 2006

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.

Rafal a Lurdyban

Egész jó volt ma az előadás a Lurdyban. Rafal hozta magát, annak ellenére, hogy most nem adott elő olyan bonyolult sztepptánc produkciókat, mint tavaly.

A sok érdekességből két dolgot emelnék ki.
Az egyik egy szakmai momentum. Rafal – csak úgy mellékesen – megemlített egy terméket, amelytől égnek állt a hajam. Elég sokat igyekszem olvasni Microsoft technológiákról, a területembe is vág… hogy a francba nem hallottam akkor még egy szót sem az IIFP-ről? Tisztességes nevén Identity Integration Feature Pack-nek anyakönyvezték és a Microsoft Identity Integration Server kisöcsikéje. (Remekül láthatóak a családi viszonyok, ugyanis a MIIS eredeti neve Identity Integration Server volt… csak aztán jött az átnevező kommandó.)
Amiért elsápadtam: az utóbbi években többször is beleszaladtunk tartomány konszolidációk, Exchange5.5 migrációk során abba a problémába, hogy igenám, de mi lesz a címtárakkal, ha külön erdőkbe kell tenni az addig békésen egymás mellett élő organizációkat? Igen, tudtuk, hogy van MIIS, de az ügyfelek sokallták az árát – így mindig nekünk kellett addig gyötörnünk az agyunkat, amíg össze nem állt egy megfelelően cifra tartományi rendszer.
Erre most itt van egy termék, mely simán szinkronizál Exchange címlistákat erdők között.
De továbbmegyek. Egyik ügyfelünknél egyre inkább körvonalazódik – hálaistennek -, hogy bizonyos fejlesztési célokra mégsem az AD sémát fogják módosítani, hanem csinálnak maguknak ADAM homokozót. Habár a fejlesztők még csak most ismerkednek vele, de már látom előre, hogy hamarosan fel fog merülni a kérdés: hogyan lehet ezt szinkronizálni az AD-vel? IIFP. Ingyér.

A másik megemlíteni való már nem szakmai jellegű. Morogni fogok.
Ott kezdődik, hogy nem ihatok kávét. Kellemetlen, de ki lehet bírni. Végülis az erős tea ugyanolyan élénkítő hatású, talán még egy kicsit tovább is tart a hatása. Feltéve, hogy van. Egyszerűen el sem tudom képzelni, hogy miért nem tudnak kitenni egy doboz filtert az asztalra a forróvizes tartály mellé. Maximum ötszáz forint – semmi a többi tételhez képest. Így viszont gyakorlatilag végig küzdhettem az álmossággal.
Aztán nem is bírtam végig. Tudom, egyéni szocprobléma, de éppen olyan szigorú méregtelenítő kúrán vagyok, hogy csak gabonakásákat ehetek és teát ihatok. Gondoltam, semmi probléma, majd a szünetekben iszok egy-egy teát, így nem fog kilyukadni a gyomrom az éhségtől és még a szellemem is friss marad. Na ja. Ebédszünetig bírtam. Aztán jó előadás ide, jó előadó oda, a túlélés mellett döntöttem és hazamentem barnarizsnyákot enni vörös teával.
Legközelebb meg majd viszek filtert és merülőforralót.