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.