Címek az égből

Egyik ügyfelünket az a szerencse érte, hogy egyesítenie kellett saját internetes/belső levelezését anyacége belsős levelezésével. Beszélhetnék a két Exchange organizáció egyesítésének szépségeiről, de most elég lesz, ha csak a címekkel foglalkozom.

Nem kis méretekről van szó: az egyesítés révén több, mint harmincezer új cím fog megjelenni a címlistájukban a jelenlegi ezer mellett - miközben az új címeket csak a top50 felhasználó használja. Megjósolható, hogy itt nagyokat kell majd varázsolni a címlistákkal.

Kitérő:

Ha valaki úgy képzeli el a címlistát, hogy van egy nagy lajstrom, benne a tagok neve - az hatalmasat téved. Szó sincs ilyesmiről. Az egész lista tulajdonképpen egy bazi nagy LDAP lekérdezés. (Érdemes megnézni az Exchange System Managerben a címlista tulajdonságlapján. Igen, arról a kínai szövegről van szó. Később részletezni is fogom.) Lehet ujjongani: mekkora ötlet, nincs lista, nincs egyenként postafiókba firkálgatás, egyszerűen van időnként egy gyors ldap query és ennek eredményét használják a kliensek. És az ldap query gyors - hiszen ez az értelme az egész adatbázis faszerkezetnek. (Már látom előre, hogy erre a szóra mennyire rá fognak harapni a keresőrobotok.:)

Nos, ha kiujjongtuk magunkat, jöhet a keserves ébredés. Indítsunk el egy ldp-t (support tools) és vizsgáljuk meg egy felhasználó értékkel is bíró tulajdonságait. Fókuszáljunk rá a showInAddressBook tulajdonságra és lassan forduljunk le a székről. Igen. Minden exchange tulajdonságokkal rendelkező objektum tulajdonságai közé be van vésve, hogy mely címlistáknak a tagja.

Láthatod, nem hazudtam. Nevekből álló lista nincs. Van lekérdezés és van objektumba bevésés. Mindezzel sikerült ötvözni a kényelmetlenséget a lassúsággal. Szerencsére a lassú folyamatok időzíthetők, így végülis nem vészes. (De erről megint később.)

No, nézzük a feladatot. A fentről jövő címeket egy OU szerkezetbe fogja beletojni a MIIS, kontaktok formájában. Természetesen a globális címlistában (Global Address List, GAL) meg fognak jelenni, hiszen azért globális a szerencsétlen.

Ötlet1.

Csináljunk egy alternatív globális címlistát. Na jó, értem én, nem kell kötekedni - igen, ez már nem globális. Csináljunk egy listát és valahogy szűrjük ki a beszülető címeket. Mivel az ügyfélnek is vannak kontaktjai, a legegyszerűbb szűrés - kihajítjuk a kontaktokat - kizárható. Vegyük elő megint az ldp-t, nézzük végig az egyes objektumok tulajdonságait, hátha találunk valami jó szűrőfeltételt. Nos, nem. Nincs. Ez nagyon rossz hír. Kénytelenek leszünk csinálni egyet. Erre valók az ún custom attribute tulajdonságok, van is belőlük tizenhat. Most még csak tesztelünk, tehát egy-egy kontakt, csoport illetve felhasználói postafiók második custom attribute tulajdonságába beírjuk, hogy Valami. Innentől már csak csinálni kell egy teszt címlistát, majd összekattogtatjuk a szűrést ezen tulajdonság értékére. Ja, igen, elfelejtettem mondani, az Address List tulajdonságlapján az egyik fül alatt egy kattogtatógép lapul, ezzel lehet összeállítani ldap query-ket. Legalábbis ez volt a szándék. Sajnos a megvalósítás ettől igen messzire került. Röviden fogalmazva botrányos: a fenti feltételt spec nem lehet összeállítani.

Erről van szó: gyűjts le mindenkit, akinél
vagy userpostafiok.customattribute2=’Valami’
vagy kontakt.customattribute2=’Valami’
vagy group.customattribute2=’Valami’.
Nem egy nagy ügy, így nézne ki:
(|
(&(objektum=user)(customattribute2=Valami))
(&(objektum=kontakt)(customattribute2=Valami))
(&(objektum=group)(customattribute2=Valami))

)

A fenti példán remekül el lehet magyarázni az ldap lekérdezés szintaktikáját. Kezdjük az ún. lengyel logikával. Nem azt mondják, hogy ‘3+3=’, hanem azt, hogy ‘+(3)(3)=’. Az & jelenti az ‘és’ műveletet, a | a ‘vagy’ műveletet és a ! a tagadást.

A valóság ennél jóvabb cifrább, nyilván meg kell vizsgálni, hogy egyáltalán léteznek-e a tulajdonságok és az objektum beazonosítása sem ilyen egyszerű. Kezdjük a kattogtatást.

Első fül: Kellenek a kontaktok, a postafiókok és a csoportok.
Második fül: Kell az összes Exchange szerver.
Marha jól haladunk, már csak egy fül van hátra, ahol a customattribute2 értékét kellene megadnunk.
Harmadik fül: Izé. Csak úgy nem lehet megadni, előtte ki kell választani, hogy user vagy kontakt vagy group. Válasszuk először a felhasználót. Ekkor a tesztnél megjelenik a tesztkontakt és a tesztfelhasználó. A tesztcsoport nem. Oké, válasszuk a csoportot. Ekkor csak a tesztcsoport jelenik meg. Jó, akkor vegyünk fel két feltételt, legyen felhasználó is és csoport is. Ekkor nem jelenik meg semmi. Nyilván az idióta engine ‘és’ feltételt tett közéjük.

Khmm. Valami nem stimmel.
Jelöljük ki a harmadik fülnél csak a felhasználót és nézzük meg, milyen lekérdezést alkot a robot.

Imhol.
(&
(&
(&
(&
(mailnickname=*)
(|(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))
(&(objectCategory=person)(objectClass=contact))
(objectCategory=group)
)
)
)
(objectCategory=user)(extensionAttribute8=Valami*)
)
)

A valóságban nincs tördelve. Kell hozzá némi áttekintőképesség, szó se róla.
A ‘*’ az az aszteriszk, azaz jelentése: ‘bármi’. A ‘valami=*’ jelentése, hogy létezik-e egyáltalán a tulajdonság.

Tessék jobban átnézni. Where is the loony? A végén. Egyszerűen tök felesleges az (objectCategory=user) feltétel. Ez a hülye kattintógép viszont mindenképpen berakja, csak hol ‘user’, hol ‘group’ paraméterrel.

Ilyenkor vonja meg az ember a vállát. Hülyék vagytok. Majd beírom én a feltételt. Csakhogy a hülyeség ritkán áll meg félúton: a gyönyörű kattogtatógépben nincs custom fül; _nem lehet_ saját keresőfeltételt beadni. Ami már csak azért is meglepő, mert szószerint ugyanígy néz ki az AD custom query kattogtatógépe és ott meg van olyan: egyszerűen a legördülő menüben eggyel több a választható lehetőség és bejön egy üres szövegmező, ahová gépelhetsz.

Elég mélyre ástunk eddig is, itt az idő, hogy még mélyebbre hatoljunk. Nyilván ezek a lekérdezőfeltételek valahol le vannak tárolva az AD-ban is. Vegyük elő kedvenc AD matyizó svájcibicskánkat, az ADSIedit mmc snap-int. (Szintén support tools.) Nagyon remélem, hogy senkinek sem mondok azzal nagy újdonságot, hogy az Exchange organizáció összes konfigurációs beállítása az AD konfigurációs névterében van elrejtve, a Services/Exchange alatt. Nem kell sokáig túrni, hamar meglesznek a címlista objektumok is… és igen, az objektum ‘purportedsearch’ tulajdonsága rejti a keresőfeltételt. Hanyag eleganciával töröljük ki a felesleges kérdést, hajigáljunk pár percig dartsot, majd ha a replikáció megtette a dolgát, nézzük meg immár az ESM-ben a tesztcímlistát. Gyönyörű. Ott van a lekérdezésünk. Írjuk még be a description mezőbe, hogy aki a grafikus felületen módosítani meri a lekérdezést, annak letört kezét fogjuk a seggébe dugni.

Nyertünk.

Eltekintve attól az apróságtól, hogy a teszt címlista nem hajlandó megjelenni kliensoldalon. De ez apróság, összehasonlítva azzal a hátul motoszkáló rossz érzéssel, hogy ez nem frankó. Kurvára nem elegáns. Eleve fel kell tölteni az AD-t ezzel a Valami értékkel. Ha új felhasználót, kontaktot veszünk fel, tudni kell, hogy ezt az értéket is be kell írni, ha látni akarjuk a címlistában. Emberi munka. Hibalehetőség. Tré.