Szép nagy játszótér. Egy multi cég amerikai központja szeretné az összes leányvállalatával összelőni az Exchange free/busy információit. Ahány cég, annyi független címtár. Azaz annyi önálló Exchange organizáció.

Ezt nevezik interorg free/busy szinkronizációnak.

Anélkül, hogy különösebben belemennék a részletekbe, azért essen róluk pár szó. Ahhoz, hogy ez az egész működjön, előtte kell egy címlista-szinkronizáció. Egyébként nem fogják látni egymást a recipientek. (Már amennyire egy postaláda látni képes.) Ilyesmire általában metacímtárakat szoktak használni. Jelen esetben egy MIIS szerveren belüli ún. Galsync process húzza az igát. Meg a címeket. Egy szkript felolvassa a leányvállalatoktól a postafiókok adatait (név, smtp cím), ezeket belegyúrja egy metacímtárba, majd a masszát contact formában visszatolja a távoli címtárakba. (Nyilván figyelve arra, hogy ahonnan felolvassa, oda ne menjen vissza ugyanannak a címnek a contact változata is.)
Persze ez csak leírva ilyen egyszerű, a 2007-es Exchange-ben már nincs RUS, a MIIS meg sunyiban tolja be a kontaktokat, azaz a különböző címlisták frissítéséről nekünk kell gondoskodnunk, mint ahogy a legacyexchangedn mező kitöltéséről is.

No, tehát címlista szinten megy a szinkron, mindenki örül. Most jönne az, hogy nemzetközi szinten működjön a megbeszélés-szervezés is.

Itt megint beléptünk a klasszikus szervezési nadrágba: a nadrágnak két szára van, hasonlóképpen nekünk is két alesetre bomlik a feladatunk. A free/busy információk szinkronja ugyanis kétféleképpen történhet. Exchange 2007 előtt az egész hóbelevanc public foldereken keresztül ment, 2007 után pedig klienstől függően vagy maradt, vagy már az Availability webes szolgáltatásra terhelődött. Szerencsére ez a leányvállalatokat túlzottan nem érdekli, a központi helyen kell telepíteni egy ún. InterOrg Replication segédprogramot, ez figyel (subscriber), nekünk pedig nincs más dolgunk, csak nyomjuk az anyagot (publisher). Az Availability szolgáltatással megint nem kell túlzottan foglalkozni, a CAS szerverek megtalálják egymást, az illetékes CAS szerverek meg megtalálják az érintett felhasználók MBX szervereit. (Oké, kell azért konfigurálgatni is rendesen, de a cikkben minden szépen le van írva.)

Ez mind szép, amikor működik. A probléma akkor van, amikor nem. Mit csináljunk? Hová nyúljak? Annyit látunk mindösszesen, hogy a megbeszélés szervezésénél ferdén van besraffozva a kiválasztott ember időcsíkja.

Jöttek a kezdeti tapogatózó lépések. X tesztfelhasználó látja-e Y felhasználó adatait Z levelezőkliensből? És Z tesztfelhasználó X felhasználó adatait Y kliensből? Meg valahány név a naptárban.

Az első meglepő tapasztalat, hogy Outlook 2007-ből minden simán ment. Azaz az Availability service tökéletesen működik, még egy ilyen bonyolult, agyontűzfalazott rendszerben is. A public folderen, az ezerszer elátkozott nyilvános mappán keresztüli terjesztés viszont nem.

Aki egy kicsit jártas az Exchange-ben, annak most szürkült el tekintete. Ha úgy általában gáz van az Exchange működésével, ezeregy eszközünk van arra, hogyan piszkáljunk bele akár a legvadabb mélységekig is az AD konfigurációs névterébe – de hogyan nyúljunk hozzá az adatbázisokhoz? Hogyan nézzünk bele? Különösen a public folder system folderébe? Hiszen ez már keszonveszélyes zóna.

Először nézzünk rá magasról. Egy organikusan kialakult Exchange szervezetben találunk egy csomó subfoldert a Free/Busy system folder alatt. Gyakorlatilag itt találjuk az összes Administrative Group-ot, mely valaha is előfordult a cég történelmében. Még azt is, amelyik hivatalosan nem is létezik. (Ugye tudjuk: Exchange Administrative Group (FYDIBOHF23SPDLT)) Hogyan élték ezek túl azt a rengeteg migrációt? Muszájból. Egész egyszerűen Exchange szervert úgy nem tudsz kitörölni, hogy van rajta olyan subfolder a public folderben, melynek nincs máshol replikációs párja. Azaz amíg van Exchange szerver az organizációban, addig az összes system folder bolyong benne, mint zsidóban a fájdalom. Törölni nem lehet. Pontosabban lehet, de system foldert törölni, az már a vak ló esete. (Nem vak ez, hanem bátor!) Márpedig az ügyfélnél 10+ éve létezik Exchange organizáció (több is), a szervezeti változások értelemszerűen Administrative Group-okat szültek, illetve szüntettek meg.
Ekkor hangzott el az a kérdés Amerikából, hogy áruljuk már el, melyik folderben vannak az éles felhasználók F/B adatai? Hát az Exchange Administrative Group (FYDIBOHF23SPDLT) nevűben – vágtam rá határozottan. Melyik másikban lennének? Hiszen az összes többi admin group már régesrégen megszűnt. Csak fityegnek itt a neveiket viselő subfolderek, mint az a valaki a Keleti pályaudvar márványtermében.
Mentünk is tovább, senki nem tulajdonított nagy jelentőséget a kérdésnek.

Aztán megálltunk, mert a szinkronizáció nem működött, az ötletek meg elfogytak. Én meg kínomban nekiálltam nézegetni ezeket a subfoldereket.

get-publicfolderstatistics -identity “NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX:/o=orgname/ou=admin-group-name

Nocsak. Az eredmény több, mint meglepő. Nemhogy a 2007 bevezetése előtt közvetlenül létező admin group nevét viselő subfolderben lébecolnak még adatok, de a migráció előtt bő egy évvel – általam – megszüntetett admin group nevét viselő subfolderben is. Hát hogyan kerültek oda ezek a zombik? És mit csinálnak még ott? Könyörgöm, 2007-ben már admin group, mint fogalom sincs! Honnan, honnan jönnek elő ezek a nevek? És legfőképpen ki használja őket?
Baromira szerettem volna belenézni ezekbe a folderekbe. Márpedig ha az ember nagyon akar valamit, akkor előbb-utóbb meg is teszi.

MFCMapi.

Ahogy ilyenkor a szakmai írásokban meg szokták jegyezni, innentől letolok magamról minden felelősséget. A programmal ugyanis nem csak bele lehet nézni egy edb adatbázisba, hanem bele is lehet írni. Elismerem, léteznek az edb szerkezeténél bonyolultabb dolgok a világon, de nem sokan. Egy fájlban akár millió(!) adattábla, közöttük pointer hegyek teremtik meg a kapcsolatot… perverz cucc, nagyon.

Szerencsére eszem ágában sem volt beleírni, bőven elég volt belenéznem. Rögtön megoldódott a rejtély.

De addig egy röpke bemutató.

Ha elindítjuk és rákattanunk a saját Outlook profilunkra, ekkor ezt látjuk.

From Segédlet

Igen, jól értetted. Outlook profile kell hozzá (min O2k3) és csak azt látod belőle, amit a profilodból is elérsz. Jelen esetben ez a postafiókom és a public folderek. Ha lennének archív foldereim vagy Sharepoint listáim, azok is látszódnának innen.

Menjünk bele a public folderekbe.

From Segédlet

Itt láthatóak a system folderek, azon belül is a free/busy folderek kiindulási pontja. (Schedule+… rémlik még valakinek? Na, ez az ág azóta megvan.) Ezt kell majd lenyitni, és onnét kezdődnek az érdekes dolgok.

Akármilyen recipient születik bele egy Exchange organizációba, kötelezően lesz egy legacyexchangedn nevű attribútuma. (Az értéke megegyezik az objektum x.500-as címével.)

Mindig? Ugye, itt megint bejön a MIIS sunyisága. Régen ezt az értéket a RUS pecsételte rá az objektumra. A 2007-ben nincsenek aszinkron folyamatok, itt minden pecsételés (legacyexchangedn, címlistatagság – beleértve a GAL-t is – rögtön akkor kerül rá az objektumra, amikor akár a konzolból, akár a shellből létrehozzuk az objektumot. De mi van akkor, ha a Galsync tolja be az objektumot, távolról? Akkor ezek az értékek üresek. Márpedig legacyexchangedn nélkül az objektum nem létezik, szerencsére a listatagság nélkül nem is látszik. Ezért kell a szinkron után ráfuttatni a korábban belinkelt írásban említett szkriptet.

De nem is ez a lényeg. (Remélem, észrevetted, hogy csak ismételtem magamat.) Hanem az, hogy a legacyexchangedn értékben benne van az administrative group neve. Annak az administrative groupnak a neve, amelyikben éppen akkor az objektum tartózkodott. (Exchange 2007-ben ez az admin group az Exchange Administrative Group (FYDIBOHF23SPDLT). Ennyit arról, hogy 2007 óta már nincsenek admin group-ok, nem él a koncepció.) Változhat a legacyexchangedn értéke? Istenments. Azzal kinyírtuk az objektumot. (Majd próbáld ki egyszer, heccből írd át adsiedittel a vezérigazgató userén a legacyexchangedn értékét. Mondjuk, ha meg akarod tartani az állásodat, akkor jegyezd meg, mi volt ott, mert visszaírás – és AD replikáció – után meggyógyul.)

Nos, márpedig ha belenézünk egy Free/Busy subfolderbe, láthatjuk, hogy az F/B információk a legacyexchangedn értékből kiolvasott nevű subfolderbe kerülnek! Azaz amikor létrejött az objektum és megkapta – akárhogyan is – a legacyexchangedn értéket, akkor azzal meg is lett határozva, melyik F/B subfolderben lesznek az adatai. Legacyexchangedn értéket pedig menetközben már nem változtatunk, mert azzal kinyírjuk először a recipientet, utána magunkat.

Így őrződik meg az örökkévalóságnak minden valaha is volt administrative group neve, mégha recipient már nem is tartozik hozzá.

Természetesen visszajeleztem az amerikaiaknak, hogy sorry, boys, ha van rá lehetőségetek, vegyétek fel a listára az összes létező F/B system foldert.
Az más kérdés, hogy ettől még mindig nem javult meg a szinkronizáció, de egy lehetséges hibaforrást immár kilőttünk.