Ötlet2

Ha nemcsak ldp-ből nézzük meg az objektumot, hanem ADSIedit-ből is, egyszercsak szemünkbe tűnik egy canonicalName nevű tulajdonság. Hö. Mifene. Ebben pont az az útvonal van, hogy hol található az objektum. Háde a címek egy meghatározott OU-ba fognak pottyanni - tehát elegendő lenne egy ‘!canonicalName=Domain/OU/*’ feltétellel kiegészíteni a jelenlegi globális címlista lekérdezési feltételét és máris Bob lenne a bácsikánk. Nosza kimásoltam a globális címlista feltételét (még szerencse, hogy engedik használni a ctrl+C-t…), egy editorban hozzáfűztem a fenti feltételt és az egészet bevágtam ADSIedittel a tesztcímlista megfelelő tulajdonságába. Darts, teszt - és üres halmazt kaptam. Habár szeretek dartsozni, de szorított a határidő, így gyorsítottam a tesztelésen. Nem a címlistáknál vacakoltam, hanem a már korábban emlegetett AD custom search ablakban teszteltem a lekérdezést - itt egyből látom az eredményt és van beíróablak. A tesztcímlista lekérdezésével egyből hibaüzenetet dobott. Jó, hagyjuk a GAL-t. Összekattogtattam egy jó általános lekérdezést, az eredményt kimásoltam, editorban hozzátettem a szükséges feltételt és visszamásoltam a custom search mezőbe, és… nem fogadta el! Szószerint ez történt: kurzor be az ablakba, ctrl+v, egy villanás - és nem történt semmi. Nem került be a szöveg. Azannya. Biztos elrontottam valamit az editorban. Fogtam a kattogtatás adta eredményt és egyből visszamásoltam a szövegablakba. Villanás, üres ablak. Mifasz? Adjuk be cseppenként. Editorból kezdtem feltételenként visszamásolni és most már megjelentek a sorok. Szépen haladtam is, de az utolsó feltétel bemásolásakor újból jött a villanás. Bazdmeg. És akkor még messze nem adtam vissza az akkori hangulatomat. Az idióták lekorlátozták a szövegablakban a bevihető karakterek számát. Olyannyira, hogy begépeléssel nem tudom összerakni azt a lekérdezést, melyet kattogtatással igen.

Habár szó sem volt replikációról, de megint sürgős dartsozhatnékom támadt.

Jó, menjünk vissza az elejére. Tesztként beírtam a ‘!canonicalName=Domain/OU/*’ lekérdezést - és erre is hibaüzenet jött. Így már sokkal tisztább a helyzet. Valamiért ez a feltétel nem jó. Miután tíz percig vizsla szemekkel ellenőriztem betűről betűre, hogy nem gépeltem-e el valamit, elkezdtem végre gondolkodni. Hogyan is működik egy AD query? Hol keres?

Hoppá. Ez bizony nem az egész AD-t túrja át, helyette csak az index adatbázist piszkálja - azt az adatbázist, melyet a globális katalógusok kezelnek. Benne van ebben az adatbázisban a canonicalName tulajdonság?

Nézzük meg. Schema management, canonicalName - bizony, üres az összes checkbox. Hát ezért halt meg futás közben az összes lekérdezés.

Itt volt az idő konzultálni az ügyféllel. Előtte azért megkérdeztem a Microsoftot, hogy mekkora plusz terhelést fog okozni az AD-nak egy új tulajdonság felvétele a GC adatbázisba. Ugyanazt a választ kaptam, mint Arthur Dent a bulldózer előtt: „semekkorát”. Ügyfélnek elmagyaráztam a helyzetet, azt mondták, hajrá, felvehetem a tulajdonságot.

Megvártam a péntek délutánt, nekifeszültem a sémának, bekattintottam a ‘vedd fel az index adatbázisba’ checkbox-ot és a ‘replikáld a GC-k között’ checkbox-ot… majd elgyönyörködtem két hibaüzenetben, miszerint ez a tulajdonság a System Class-ba tartozik, tehát se nem indexeltethető se nem replikáltatható.

Csak.

Ötlet3

Más választási lehetőség híján maradtunk az első módszernél. Közben eszembejutott egy újabb komplikáció: kliensoldalon mindenki a globális címlistát használja; ha bevezetek egy új címlistát, akkor mindenkinél át kell állítgatni. Az ügyfél viszont határozottan irtózik a kliensoldali beavatkozásoktól.

Kellene egy újabb ötlet.

Nos, eddig is bátrak voltunk. Miért ne lehetnénk még bátrabbak? Módosítsuk a globális címlistát. A neve marad globális, de kibelezzük és az álca alatt egy nem globális címlista lenne, mely megegyezne azzal a címlistával, melyet most használnak. A tesztlistát meg átberhelnénk és az lenne a tulajdonképpeni globális címlista.

Az ötlet jó. Némi fennakadást okoz, hogy a globális címlista (GAL) nem módosítható. A grafikus felületről. De itt van a jó öreg ADSIedit, és természetesen a GAL-nak is megvan a ‘purportedsearch’ tulajdonsága. A lekérdezés kimásolása a GAL-ból, átmásolása a tesztcímlistába, kibővítése a plusz feltétellel és visszamásolása a GAL-ba alig volt öt perc.

Csak hogy töltsem a helyet, idemásolom:
(& (extensionattribute2=Valami)(mailnickname=*)
(| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))
(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))
(&(objectCategory=person)(objectClass=contact))
(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchDynamicDistributionList) ))

Enyhe szépséghiba, hogy mindez kliens oldalon egyelőre nem látszik.

De ráérünk, mert még fel kell tölteni az AD-t szkriptből és ez sem apró feladat. Először is figyelni kell arra, hogy a nemlétező tulajdonság és az üres tulajdonság nem ugyanaz, dacára, hogy lekérdezéskor ugyanazt a választ kapjuk az Isempty() függvénnyel. Habár van valami módszer - lekérdezve az Err értékét -, de nekem ez sohasem működött. Viszont jelen esetben igen fontos rögtön az elején különbséget tenni a két lehetőség között, ha ugyanis egy olyan objektum Exchange tulajdonságának adunk értéket, mely se nem mail-, se nem mailbox-enabled, akkor egy olyan szürke zónába léptünk, melytől minden tisztességes adminisztrátor irtózik. Meg a tisztességtelenek is. A zóna kizárólag a hülyéknek van fenntartva.

Szerencsére van egy másik tulajdonság, melynek mindig van értéke, ha az objektum mail/mailbox-enabled: ez a proxyaddresses tulajdonság. Ez gyakorlatilag egy tömb, amelyben az objektum összes e-mailcíme van felsorolva - márpedig egy darab mindenképpen van neki.

A többi már nem nagy ügy. Még arra kell figyelni, hogy a romantikus nevű MsExchHideFromAddressLists változó értéke hamis legyen - azaz az objektum ne legyen kirejtve a címlistákból.

Mehet is. De még mennyire. És de még hányszor. Eszméletlen eldugott sarkai lehetnek egy 3 fás 6 tartományos erdőnek, zegzugos OU-kal, konténerekkel - márpedig addig kell erőszakolni a szkriptet, amíg a globális címlistával megegyező számú objektumot kapunk vissza. (Igen, megírhattam volna rekurzívnak is. Későn jutott eszembe.)

De végül ez is rendbe jött. Ennek ellenére kliensoldalon semmi változás. A tesztgépen továbbra is a régi címlisták látszanak.

Itt van egy láb, kibe rúgjak? Ki mögött rejtőzködik az MSExchangeAL? A legvégén biztos a System Attendant lesz, de azért durva lenne az egész szervert restartolni egy frissítés miatt.

Miről is írtam az elején? Hogy a listatagság beleíródik az objektumba. Ez egy bulk jellegű írási művelet. Melyik komponens lát el hasonló funkciót? Igen, a Recipient Update Service, a jó öreg RUS. Haza is érkeztünk. Ugyanazt kell csinálnunk, mint amit egy új recipient policy bevezetésekor: minden tartományi RUS-ba bele kell rúgni egy jó nagyot. Figyelem: nagyot. Én úgy tapasztaltam, hogy a hivatalos véleménnyel szemben kicsi rúgásra a füle botját sem mozgatja. (Segítség. Kis rúgás: update. Nagy rúgás: rebuild.)

Egy-két óra várakozás következett, közben volt egy röpke őszülés is: ugyanis befigyelt egy jó hosszú periódus, amikor üres volt a teljes globális címlista. Roppant lehangoló látvány. Szerencsére nem sokan látták, ez ugyanis már péntek éjfél körül volt. Hogy a modemesek mennyit fognak átkozódni, amíg az új offline Address Book-ok leérnek hozzájuk, azt nem tudom. Remélem, nem találnak meg.

Tulajdonképpen most már készen is vagyunk, boríthatják a címeket.

És ha már itt lesznek, át kell túrnom alaposan a tulajdonságaikat, hátha találok valami különbséget, ami alapján automatizálható lehet a listázás.