Beláncolva

Régen írtam már szakmai témáról. Ez nektek rossz, nekem jó: ugyanis azt jelenti, hogy mostanában nincsenek nagy szívások a munkahelyemen.
Ez a mostani írás is inkább a munka melletti tanulás eredménye. (Érdekes módszer szerint szoktam tanulni. Előveszek egy könyvet, kinézem, mely fejezetet fogom átnézni, majd nem ritkán amíg a teámat kortyolom és átnézem a reggeli feedeket, postokat, elindulok valamelyik íráson és jó másfél-két órán keresztül próbálom letisztázni, mi is van a cikk mögött. Az előkészített könyv meg csak duzzog az asztalon.)

Van egy olyan valami az Active Directoryban, hogy ‘linked value’. Hallani már hallottam róla, különösen akkor, amikor az AD2003 előnyeit tanultam vizsgára – de olyan nagyon nem mélyedtem bele, mi is ez. Pedig elég érdekes.
Először az a bizonyos előny: az AD2003-ban jobb lett az LVR. Ugye, mennyivel könnyebb immár a lelkünk? De tényleg; az LVR rövidítés a linked value értékek replikációját jelenti.
Most már azért jó lenne tudni, mit is takar az a kifejezés. Könnyű lenne azt mondani, hogy kérem, a linked value az objektum egyik tulajdonságának olyan értéke, mely több elemből áll. Látni fogjuk, hogy ez messze nem igaz, de egyelőre maradjunk ennél a meghatározásnál. Az LVR pedig annyival lett jobb, hogy az AD2003-ban, ha az értékeket tartalmazó tömb egyik eleme megváltozott, nem az egész tömb replikálódik, csak a megváltozott elem. Ez különösen akkor lehet izgalmas, ha mélyebben belemegyünk a susnyásba.
És most akkor felejtsük is el gyorsan az előző defíniciót. Az ugyanis egész pontosan a multi-valued fogalmat fedi, melynek ellentéte a single-valued fogalom. A linked value egy egészen más szempontból történő csoportosítás eredménye. Például ellentéte a DN-valued fogalom.
Nos, eleget ködösítettem már és mivel a blogon nem szótagszám alapján fizetnek, épp ideje rendet raknom. Röviden:
DN-valued: amikor Géza írja be valamilyen eszközzel (kőbalta) a tulajdonság értékét.
Linked value: amikor az AD belső mechanizmusa gyűjti össze az értékeket, más objektumok tulajdonságaiból.
Azaz általában igaz, hogy a linked value körbe tartozó értékek tömbök. De tény, hogy vannak egyelemű tömbök is.
Nézzünk egy konkrét példát:
Minden postafióknak van egy homeMDB tulajdonsága. Az értéke lentebb látható. Itt tárolódik, hogy a konkrét postafiók mely szerver mely store-jában virít. Tippeljünk, milyen tulajdonság lehet ez? Akár DN-valued is lehetne… de nem az.

Kényelmi okokból nem az. Ugyanis létezik egy másik tulajdonság, egy másik objektumon. Minden store objektumnak van egy HomeMDBBL tulajdonsága, itt egy tömbben szerepelnek azon felhasználók CN értékei, melyeknek az adott store-ban van a postafiókjuk. Meg se kérdezem, látszik, hogy ez tipikus linked value tipusú tulajdonság. Az AD belső mechanizmusa mazsolázza össze a HomeMDB értékekből a HomeMDBBL (a BL a BackLink rövidítése) tömböt. Az meg csak egyszerű technikai megfontolás, hogy egyszerűbb a mazsolázás, ha a HomeMDB is linked value típusú.

Most gondoljuk el. Van egy Exchange szerverünk, ahol a konkrét store-ban van négyszáz postafiók. Jön az adminisztrátor, felvesz egy újabb felhasználót, postafiókkal. Amíg az LVR úgy működött, hogy mindig ment az egész tömb, ha akár csak egy eleme is megváltozott, addig volt itt nyüzsgés a dróton, rendesen.
De még így is kell trükközni a replikációval. Ilyen trükk, hogy először a DN-valued tulajdonságokat küldik át a replikációs ügynökök a túloldalra (ahol ugye az igazság lakozik) és csak utána jöhetnek a linked value tulajdonságok.

Érdekes dolgok sülhetnek ki ebből.
Vizsgáljuk meg a fenti példát.
Létezik olyan az Exchange-ben, hogy system policy. Ezen belül van olyan, hogy Mailbox Enable User Policy. Ő a felelős a postafiókokhoz tartozó mailnickname, homeMDB, homeMTA és msExchHomeServerName tulajdonságok kezeléséért. Felvettünk egy új felhasználót (igen, leesett az asztalról), az adatai feliratkoztak a replikációra. Most már tudjuk, hogy a homeMDB tulajdonság linked value típusú, tehát egy konkrét replikációs csomag rájátszásakor csak akkor kerül sorra, ha a többi érték már a helyére került. Leterhelt DC esetén ez akár 10-20 másodperc is lehet. Eközben viszont aktivizálódhat a Mailbox Enable User Policiy. Mit lát? A postafióknak már van mailnickname, homeMTA és msExchHomeServerName értéke (mert ezek már megjöttek), de nincs homeMDB értéke. Nosza, ad neki egyet. A helyi szerver default store értékét. Azaz lazán áthelyezte a postafiókot egy másik store-ba. Jó esetben akár még egy másik szerverre is. A legszebb az egészben, hogy mivel ez a módosítás történt később, így ez az érték fog szétreplikálódni a továbbiakban. Aranyos.
Itt található egy KB cikk, amelyikben leírják, hogyan kell módosítani a Mailbox Enable User Policiy szűrőparaméterét, hogy csak akkor induljon be, ha a postafióknak már van homeMDB értéke.
De nem csak ezt a policyt lehet behülyíteni. Gondolkozzunk el, mi történik, ha a recipient policyt például a homeMDB értékhez kötjük? (Ez egyáltalán nem nagy ügy: amikor kiválasztjuk azon postafiókok körét, amelyekre a megadott emailcímnek rá kell esnie, össze lehet kattogtatni olyan szűrőfeltételt, amelyikben szerepel, hogy mely szerver mely store-jára vonatkozzon a policy.)

Itt állítható be a szűrőfeltétel.

És itt látható a konkrét ldap filter – benne gyönyörűen a homeMDB vizsgálat.

Nos, vegyük elő a korábban felvázolt esetet. A replikáció még nem fejeződött be, a postafiók még nem kapta meg a linked value homeMDB értéket. Közben viszont beköszön a recipient policy – melyet ugye a homeMDB-hez kötöttünk. A feltétel nem teljesül, tehát a postafiók a default recipient policyben megadott címeket fogja első körben megkapni. A következő körben, amikor már meglesz a homeMDB értéke, megkapja a jó emailcímeket is, de a korábbi emailcímek nem törlődnek.
Mit lehet itt tenni? Egyszerű: barátaim, ne kössünk recipient policyt linked value értékhez.

Nos, ennyi. A bevezetőben említettem, hogy imádok elcsatangolni egy-egy cikk nyomán. Ez a mostani írás is így született, az ihletője pedig Bill Long szaki kíváló cikke.

Leave a Reply

Your email address will not be published. Required fields are marked *