Category: address list

GAL szegmentáció

Nem sokkal korábban beszélgettünk a kommentekben arról, hogy mi is ez tulajdonképpen és most létezik, vagy sem? A konklúzió az volt, hogy igen, létezik, de csak hosted módban. Akinek hagyományos Exchange rendszere van és valamilyen okból kifolyólag szeretné mégis valahogy elszeparálni egymástól a címeket – azaz elérni azt, hogy ne láthasson mindenki mindenkit – jelenleg még kénytelen az ACL értékekkel bűvészkedni. Azt viszont már tudjuk, hogy az ACL matyizás nem igazán jól menedzselhető módszer. (Akit érdekelnek a részletek, ebben a whitepaper-ben megtalálja.)

Az Exchange 2010 SP2-ben végre vége ennek az áldatlan állapotnak, bejön a rendszerbe az Address Book Policy. A technikai részletekbe túlzottan nem mennék bele, a név mindent elmond: le kell gyártani a címlistákat (beleértve a globálisakat is), majd házirendből szabályozhatjuk, ki melyikhez fér hozzá.

Megszokhattuk már, hogy az ördög a részletekben rejtőzik. Henrik Walther összerakott egy rövid, de frappáns írást, ahol az ABP árnyoldalait is feltűntette: mennyire korlátozott a hatóköre, hogyan lehet megkerülni, mikor nem alkalmazható, mikor csak korlátozottan, stb. Ha valaki komolyan gondolkodik a bevezetésén, érdemes először ezt az írást elolvasnia.

MI SE, még mindig

Tehát ott jártunk, hogy boldogan lejelentettük, miszerint itt van az összes cím, barátaim, feleim, levelezzetek.

Aztán jött az indignált újabb bejelentés. Oké, a cím ott van, de ha levelet küldenek neki, akkor másodpercen belül hibaüzenet jön vissza. A levelet nem lehet kiküldeni.

Nézzük, mi is van az NDR-ben? A következő felhasználó nem létezik: IMCEAEX_******@cegnev.hu.
Naná, hogy nem. Szépen is néznénk ki, ha létezne. Ja, hogy mi is ez az IMCEAEX***? Írtam már róla, olvasd el bátran. De ha nem akarod, rövid összefoglalás: ez egy kapszulázás. Ha valakinek nincsen SMTP címe, akkor az Exchange az egyéb címéből (x.400) szigorú szabályok alapján gyárt egy meglehetősen bonyolult smtp címet, majd ezzel küldi el a levelet. Aztán a válasznál meg – a szigorú szabályok ismeretében – kikapszulázza, azaz az IMCEAEX_****@cegnev.hu címből visszafejti az x.400 címet és oda küldi tovább a levelet.
Nos, ez mind szép, de hogyan kerül ez a sáros bakancs az asztalra? Itt a _címzett_ kapott IMCEAEX címet! Az Exchange 2007 ennyire optimista lenne? Azt mondja, nem lát a címzettnél SMTP címet, tehát abszolút vaktában hasra üt, legyárt egy IMCEAEX_****@cegnev.hu címet és bízik benne, hogy ha a túloldalon kikapszulázzák, akkor pont lesz olyan x.400-as cím? Bizony, így. Ne tudd meg, mennyi felháborodott levelet kaptam, hogy honnan meri az Exchange a @cegnev.hu tartományba küldeni a török, cseh, lengyel és még mittudoménmilyen leveleket? Hát ennyire hülyék vagyunk?

Ehe. Mosoly nyáladzó szájszéllel. Igen, reménytelenül debilek vagyunk.

Aztán elkezdtem kisérletezgetni… és a helyzet egyre durvább lett. Küldtem egy új levelet. Kiválasztottam a címzettet a Worldwide címlistából. Kiváncsiságból ránéztem a tualjdonságlapjára, gyönyörűen ott voltak a tulajdonságai, köztük a jó SMTP cím is. Oké. Elküldtem. Már jött is vissza az NDR, benne az IMCEAEX-es címmel.

Miaf?

Eljátszottam ugyanezt OWA-ból is. Tökéletes. A levél elment. Hát ezt meg hogyan? Elméletileg mindkét levél ugyanazt az útvonalat kell, hogy bejárja. Hát itt már semmi sem úgy működik, ahogyan működnie kellene?

Nézzük meg EMC-ből, látjuk-e az összes kontaktot. Feljött egy hibaüzenet. Lehet, hogy pont a mi emberünk sérült? A hibaüzenetre kattintva üres ablak jött elő. Hmm… lehet, hogy 40000 kontaktnál várni kell egy kicsit? Otthagytam éjszakára. Másnap reggel még mindig üres volt az ablak. Hmm. Ott van egy üzenet az alján, hogy a ‘ctrl+c’ kiteszi vágólapra a szöveget. Legyen. És tényleg, a notepad-ben már ott is volt a lista. Lehet, hogy valami idióta fehér betűkkel írta ki az ablakban fehér háttérre a listát? Már ezen sem lepődnék meg. Mindenesetre kellemetlen, a keresett cím nincs a hibások között. (Megjegyzem, itt is látok cuclizási lehetőséget: a hibás címek azért hibásak, mert space van a display név elején, illetve végén. Főbelőni. Mindet.)

Egy gyors, de bátortalan pillantás a GC adatbázisba. (Ugye tudod: ldp, a 3268-as porton.) Ott volt szépen a kontakt.

Eddig tartott a dal. Habár szívesen elmolyoltam volna még napokat a problémán, de mivel priority2-vel jelentették be, így ha nem akartam SLA-t sérteni, eszkalálnom kellett. PSS.

Hosszú beszélgetések. Lista, hogy miket küldjek el.
Aztán az ldp dump-ban a Sólyomszem Brigád kiszúrta, hogy a vizsgált kontaktnak üres a legacyExchangeDN értéke. (Konkrétan, nem szerepelt a dump-ban. Ugye tudjuk, hogy az ldp csak azokat a tulajdonságokat listázza, melyeknek van értéke.) Szinte hallani lehetett, ahogy a felfelé görgetett kőgolyó átbillent a csúcsponton.
– Ez baj – hívott vissza a mérnök.

Adtunk a kontaktnak. Mármint értéket.

Itt kellett megemelnem a kalapomat. Azt, hogy üres a legacyExchangeDN – különösen a korábban belinkelt cikk alapján – valószínűleg előbb-utóbb én is megtaláltam volna. De mit kellett volna beírnom? A kontaktnak volt vagy tíz x.500-as címe. Melyik legyen a legacyExchangeDN?

A mérnök segített: egyik sem. A legacyExchangeDN mindig a _helyi_ objektum helyzetére vonatkozik. Hiába tolják ki ugyanazt a kontaktot Amerikából Japánba, Grönlandra és Budapestre – a legacyExchangeDN értéke mindenhol más és más kell, hogy legyen. Míg az x.500 címe pedig annak a nyomát mutatja, hogy az objektum honnan hová lett migrálva.

Itt kezd a szituáció logikussá válni. Az elején, mondjuk, nem néztem volna ki belőle. Hogyan is működik a MIIS? Legyártja a távoli címtárban a kontakt objektumot. Ír neki legacyExchangeDN értéket? Hát, miért írna, amikor arra találták ki a helyi RUS-t? Majd amikor az végigmegy a recipienteken, akkor beírja a helyes értéket. (Hasonlóképpen békén hagyja a ShowInAddressBook értéket is. Ezt majd beállítják a helyiek.)

Ja, hogy az Exchange 2007-ben nincs RUS? Cucl.

Megoldási lehetőségek?
Elvégezni a RUS munkáját – azaz valamilyen jól definiált pontban mindenhová, ahol üres a legacyExchangeDN mező értéke, beírni a jó értéket. Yep. Mi lesz a jól definiált pont? Hát, nemrég derült ki, hogy az MIIS szinkronizáció után úgyis szkriptből kell frissítenünk a címlistákat. Akkor nincs is más hátra, mint ki kell bővíteni a szkriptünket.

Ja, a legszebbet meg nem is mondtam. Honnan tudod, hogy az adott környezetben mi lenne a kontakt helyes legacyExchangeDN értéke? Mindegy. Nem kell tudnod. Elég, ha felolvasod a kontakt objektum tulajdonságait, majd visszaírod. Ekkor a rendszer automatikusan beírja a legacyExchangeDN értéket.
Így: get-mailcontact “user-alias” | set-mailcontact.
Nyilván, tömeges módosításnál játszani kell a szkóppal (nem elég az alias), meg illenék rá is vizsgálni, hogy üres-e az érték vagy sem… dehát ez már mind iszonyúan részletkérdés.

MI IS helyett MI SE

Irkáltam már arról az ügyfelünkről, akik kinyitották a szelencét és rájukborult 40000 kontakt. (Egyik, másik, harmadik.) Köszönik szépen, élnek még… de ez a rengeteg cím, melyet csak a dolgozók kb 5%-a használ, továbbra is komoly problémát okoz nekik.

Különösen úgy, hogy a közelmúltban álltak át Exchange 2007-re.

A legszebb ugyanis az volt, hogy elméletileg semmi problémát sem lenne szabad okoznia ennek a tömérdek címnek… de valahogy éreztem, hogy nem lesz ez olyan sima menet.

Akik nem akarják elolvasni a kilométer hosszúságú előzményeket, azoknak összefoglalom:

  • Trükkös módon a Global Address List mögött kicseréltem a keresőfeltételt, így csak a helyi címek kerültek bele. Ezt mindenki boldogan használta.
  • Létrehoztam egy Worldwide nevű listát, mely mögé odatettem az eredeti GAL keresőfeltételét. Ha az az 5% külföldre akarat írni, akkor címlistát váltott.

Még egy technikai előzmény. Az egyes nemzeti leányvállalatok között a címlista szinkronizáció úgy zajlik, hogy a tengerentúlon egy MIIS szerver felolvassa a felhasználók smtp és egyéb címeit, beledolgozza egy adatbázisba, majd mindenkinek a címtárába visszatolja a címeket, mail kontakt objektum formájában. Ez az a bizonyos negyvenezer, ki dalolva ment.

Az átállás után kezdtek rendeződni a sorok, kezdtek beérkezni az első rejtélyes panaszok.

(Nem tudom, ki hogy van vele, nekem ez a legnehezebben elviselhető időszak. Én általában beleadok apait-anyait, heteken, hónapokon keresztül megfeszítetten dolgozok, hogy időre tökéletesen működjön az új rendszer. Ez általában össze is jön, maximum a haragosaim száma növekszik. És amikor hátradőlnék, arcomon az elégedett mosoly, miszerint ‘használjátok, népeim, nektek csináltam…’ majd várnám a dicséreteket… azok valahogy nem jönnek. Egy csepp sem. Ezzel szemben beindulnak a hőbörgések. Hogy micsoda szar ez. Nem tudja ezt, meg azt. Ja, meg minden máshol van. És rossz! Majd jön, hogy mindezért ki is a felelős? A megrendelő persze elkezdi védeni a seggét, hogy ők sem így akarták. Eh.
Nyilván oktatással mindezt ki lehetne védeni, de az ügyfél helyett nem tudom tanítani a felhasználóit, különösen, hogy ezt rendszeresen nem rendelik meg. Így pont akkor, amikor a legfáradtabb vagyok, pont akkor, amikor az asszertív szóról maximum annyi jut eszembe, hogy biztosan egy perzsa hadvezér lehetett, szóval pont ekkor kellene türelmesen elmagyaráznom az embereknek, hogy nem szar, csak más.
Nem szokott sikerülni.
És a legdurvább az, hogy az esetek 1-2%-ában a bejelentőnek tényleg igaza van. Csak ez nem derül ki elsőre. Ilyenkor még elnézést is kell kérnem a végén.)

Nos, ilyen elnézéskérős esetekről lesz most szó.

Az első bejelentés az volt, hogy néhányan hiányolták a Worldwide listákról a külföldi ismerőseiket. (Ja, mondanom sem kell, külföldre leginkább a VIP-ek leveleznek. Ezt, mint türelmetlenségi faktort tessék figyelembe venni.) Megnéztem… és tényleg. Először felrémlett bennem a GAL és annak cefettül bonyolult szerver- illetve kliensoldali függőségei… de aztán lehiggadtam. A Worldwide lista sima Address List, azaz egy szűrő a Global Catalog adatbázisra.
De akkor hogyan lehet, hogy nem kerül bele egy kontakt? Ugyanis a címtárban megnéztem, a kontakt objektumot a MIIS rendesen beletojta az OU-ba.
Aztán később eszembe jutott, hogy valahol olvastam már ilyesmiről. Aztán még később eszembe jutott, hogy nem is olvastam, hanem írtam. Ebben a könyvben. (Igen, öregszem. Igen, én is leszek szenilisek.) Konkrétan arról van szó, hogy az Exchange 2007-ből kiműtötték a RUS-t. Ez a szolgáltatás nem csak a recipient policy-k betartásáért felelt, hanem minden kötegelt, asszimetrikus műveletért. (Mi is az, hogy asszimetrikus? Bekattintok valamiket, aztán csak pár óra múlva fut le egy kötegelt folyamat, mely érvényesíti a hatásokat.)
Tipikusan ilyen folyamat volt a címlisták tagságának érvényesítése is: a RUS megvizsgálta az egyes címlisták szűrőfeltételeit, majd minden recipient objektumra bejegyezte annak a címlistának a nevét, amelyiket a szűrőfeltétel eltalált. (Nem, nem röptében történt a szűrőfeltétel érvényesítése. Ezt nem igazán bírták volna a GC-k.)
Az Exchange 2007-ben ez megváltozott. Amikor létrehoztunk egy recipient objektumot, akkor egyből rá is esett minden, aminek kellett. Ha bármit piszkáltunk rajta, akkor szintén. De kötegelt folyamatok már nincsenek.
Látjátok már a kiskaput? Amikor a MIIS tojja be a kontaktot, akkor megkerüli a folyamatot. Létrejön egy új kontakt, de nem jegyződik be rá, hogy ő mind az ‘All Contact’, mind a Worldwide címlistának a tagja lesz. Nem is lesz. Jogos az ügyfél reklamációja.

Szerencsére a megoldás nem túl bonyolult: mivel a kontaktok éjjel jönnek, reggelre be kell időzíteni két EMS parancsot:

update-addresslist -identity “All Contact\”
update-addresslist -identity Worldwide

Ahogy mondani szokás, az ördög a részletekben lakik. A mocsok.

Időzítettél már be EMS parancsot Windows 2008 szerveren? Ráadásul olyat, melyhez Exchange Organization Administrator (Atyauristen) jogosultság kell?
Egy élmény.

  1. Létrehozol egy kellő erősségű felhasználót, nem lejárós jelszóval.
  2. Létrehozol egy könyvtárat ‘d:\scripts’ néven, úgy, hogy csak az Atyauristen nevű felhasználónak legyen benne írási joga.
  3. Létrehozol egy frank-drebin.ps1 nevű fájlt, melybe beleírod a fenti két parancsot.
  4. Elindítod a Task Scheduler konzolt és ugyanazzal a mozdulattal beveszel egy marék Seduxent.
  5. Beidőzíted a taszkot, beállítod a felhasználót, tesztelsz. Természetesen nem fog történni semmi. Hogyan is gondoltad, hogy egy Exchange szerver fel fogja ismerni az Exchange Management Shell (ps1) parancsát?
  6. Indul a vajákolás. Először is szeretnéd látni, mit is ír ki futás helyett a szkript. Ehhez volt régebben a /i (interactive) kapcsoló. A grafikus felületen nyoma sincs. Parancssorban? A-ha. /IT lett belőle. De nem is ez a lényeg. Hanem az a megjegyzés, hogy ilyesmi csak akkor van, ha a felhasználó ténylegesen be is van jelentkezve. Eszedbe jut, hogy volt egy rádiógomb, miszerint
    – Run only when user is logged on
    – Run whether user is logged on or not
    Nos, bármilyen furcsa is, az első jelenti az interaktív futást, a második a nem interaktívat. Tudnak fogalmazni a fiúk, szó se róla.
  7. Most már látod, hogy egyszerűen az operációs rendszer nem tud mit kezdeni a .ps1 fájlokkal. Megkíméllek a rengeteg utánajárástól, a következőket kell beírnod:
    – A program/script mezőbe: c:\windows\system32\windowspowershell\v1.0\powershell.exe
    – Az add argument mezőbe: -psconsolefile “c:\exchsrvr\bin\exshell.psc1” -command “. ‘d:\script\frank-drebin.ps1′”
    Feltéve, hogy az Exchange alkalmazást a C:\exchsrvr könyvtárba telepítetted.
  8. Azt hiszed, mi, hogy működik? Hát nem. Megjelent az eddig még csak barlangjában szunyókáló UAC. Nem fog lefutni a szkripted, mert hiába vagy maga az Atyauristen, ha nem Atyauristen módban indítottad. Na jó, de hol lehet? A fene tudja. Nézzük meg a runas parancsot… semmi. Csak a jó öreg /savecred van, de az már kilenc évvel ezelőtt is maximum vicc volt. (Jelszót beleírni a parancsba… egy mindenható felhasználónál. Aha.) Na jó, nem csigázlak, ezt a csekkbokszot kell bebillentened: ‘Run with highest privileges’. Biztos ugyanaz a mókus fogalmazta, aki az előző objektumot. Még az is lehet, hogy ideológiát is gyártott hozzá: security through obscurity, azaz hülye ember ne tudja már beállítani. Mintha ez a fajta védekezés valaha is ért volna akár egy koszvadt hajítófát is.

És nagyjából ennyi. A szkriptünk minden reggel lefut, a nevek pedig megjelentek a Worldwide címlistában.

Csak éppen levelet nem lehet küldeni nekik.

De ez már majd a következő írás témája lesz.

Adide, nemadom

Na, kérem, itt van a magyarázat ahhoz, ami miatt pár nappal ezelőtt csak kapkodtam a levegőt.

Nemrégiben jött ki az Exchange 2007 SP1 termékhez a Rollup Pack 5. (Csak gondoljunk bele… az SP1 előtt volt megint 5 Rollup Pack… és mindegyik megváltoztatta a termék viselkedését… nem könnyű ám Exchange adminnak lenni.)

Nos, az egyik hiba, melyet a csomag javított, így szólt: CCR vagy SCC clusterben megvalósított Mailbox szerveren nem működött a GAL disztribúció, amennyiben Outlook 2007 kliensről próbálkoztunk.
Ránézésre nem olyan vészes, pedig de. Összeraksz kemény munkával egy clustert, jön egy felhasználó Outlook 2007-tel – annyira azért már nem ritka jószág – és nem lát címlistát.

Eddig nem lehetett sokat tudni arról, mi is okozta a hibát – de Dave Goldmann nemrég írt egy cikket. Most már tudjuk. Most már verjük a fejünket a falba. Velük együtt. Annyira idióta hibáról van szó, hogy tényleg nem értem, hogyan kerülhetett bele a rendszerbe.

Nem húzom tovább az időt, itt a magyarázat: az OABGen process a \\gepnev\ExchangeOAB könyvtárba tette le a legenerált xml fájlt, mint ahogy mindig is szokta. A CAS szerver viszont nem ott kereste, mert ő hogyan is látja a clustert? A virtuális Exchange szerver nevén keresztül. Azaz a CAS a \\CMS\ExchangeOAB megosztást kereste, nem találta, tehát az OAB weblapon nem is tudott publikálni semmit.

Függöny.

Minden jó, hajó a vége

Valamikor írtam róla, hogyan járt szerencsétlen ügyfelünk: az anyacége dömperrel beborított vagy 30000 kontaktot a címtárába. Szaladgáltak is szegények, mi lesz most a címlistákkal: végül egy illegalitásba hajló lépéssel megpatkoltuk a rendszert.

Aki nem olvasta át a két linket, röviden összefoglalom: szerencsére kiderült, hogy a távoli tartományban született kontaktok msexchoriginatingforest tulajdonsága megőrzi az eredeti forest értékét. A helyben született objektumoknál viszont ez üres. Azaz a GAL mögötti ldap filterbe ‘és’ kapcsolattal becsatoltunk egy !(msexchoriginatingforest=*) feltételt – így csak azok jelentek meg a globális címlistában, akiknek üres volt ez a tulajdonsága. Természetesen az eredeti GAL filtert kimentettük egy custom címlistába, hogy akik abban akarnak keresni, azért tudjanak.

Mindenki boldog volt.

Egészen az Exchange 2007 migrációig.

Igazából nem az a legnagyobb baj, hogy ebben a termékben kinyírták az ldap alapú szűrést. Hiszen bejött helyette az OPATH – és ha megszokod, rájössz, hogy ez tényleg jobb. Még csak nem is az a katasztrófa, hogy beszuszakoltak egy plusz réteget a filter és a címtár közé. Igaz, hogy mostantól a feltételekben nem direktben hivatkozol az objektumok tulajdonságainak értékére, hanem helyette ujjból szopott nevű változókat kell használnod… de ez maximum kényelmetlenség. A tragédia az, hogy nem definiáltak minden tulajdonsághoz változót. Költői kérdés: találd ki, használhatjuk-e OPATH filterben az msexchoriginatingforest tulajdonságra definiált változót? Nem… mert nincs. Nyugodtan böngészd át a választékot.

Mondtam, ugye, hogy a legnagyobb szopás az ldap filter az egész upgrade-ben?

Akkor mi legyen? Adódik, hogy szűrjünk rá a szerver nevére. Az ügyfélnél egy darab nagy teljesítményű központi szerver lesz, tehát még a szűrőfeltétel sem lesz túl bonyolult. Alapvetően működhetne is… csak éppen nem elegáns. Mi van, ha valamikor üzembeállítanak majd egy másik MBX szervert is? Mi van, ha egyszer átmigrálják a postafiókokat egy másik szerverre? Ki fog emlékezni rá, hogyan lett megbuherálva a GAL? Ráadásul…ugye az átállás ideje alatt még két szerver van, tehát mindkettőnek a nevét be kellene írni a feltételbe. Pedig a régi csak pár hétig fog még élni. Jó, majd utólag módosítjuk.
Meséltem már erről? Lehet. De ismétlés a tudás k. anyja.
Szóval, a GAL-t a set-globaladdresslist paranccsal tudjuk upgradelni. Exchange 2007 alatt ugyanis minden szűrős objektumnak két szűrője is van. (Logikus, hiszen illeszkednie kell mind a régi, mind az új rendszerhez.) A címtár preparálásakor meg is jelenik az új tulajdonság, de sehol, hangsúlyozom, sehol sem történik automatikus filter konverzió, amikor betoljuk az első MBX szervert az organizációba.
Magad uram, ha szolgád nincsen.
Címlistáknál, email address policy-knél nem is gond. De a GAL-nál igen. A set-globaladdresslist parancs ugyanis egylövetű. Egyszer beírhatod az OPATH szűrőt. A következő futtatáskor már azt kapod, hogy ‘Hohó, valaki nem bír magával!’. Nyilván adsiedit és purportedsearch… de nem lehetsz benne biztos, nem csináltál-e valami visszafordíthatatlant. Lehet, hogy valahol a mélyben elpattant egy fogaskerék, a szerver teliholdkor életre kel és szakrálisan feláldozza az éjszakai recepcióst. Vagy bármi. De hogy nem lesz supportált, az tuti biztos.
Márpedig, ha a szervernevekkel játszol, akkor kétszer is módosítanod kell a GAL-t.

De azért megpróbáltam körbejárni. Leginkább azért, hogy közben időt hagyjak ott hátul a megoldáskeresésnek.
Összedobtam az Exchange 2003-ban egy teszt címlistát. Varázslóval. Középső fül, szervernév megad. Nézzük az eredményt… hoppá. Brian… leestem a székről. Ott voltak benne a külföldi címek. Most én vagyok a hülye… vagy a varázsló? Szerintem az utóbbi. Nézzük csak a konkrét feltételt… jézusmária. Sőt, ez már inkább duplajézusmária erősségű volt. Ez az idióta kuruzsló ‘vagy’ kapcsolatba tette a szervernévre vonatkozó feltételt az első panelen bepipált ‘contact’ feltétellel. Így mindenki beleesett. Döbbenet.

Kitérő:

Ha csak lehet, ne használj varázslót.
Ha ez eddig nem lenne egyértelmű, elmagyarázom, miért.
Nézzük az előbbi példát, kattogtassunk össze egy címlistát, amelyikben az Exchange postafiókkal bíró felhasználók címei vannak. Első fül, ‘Users with Exchange mailbox’ checkbox. Ez lesz a szűrőfeltétel:

(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))

Azaz mindenki, akinek nem üres a homemdb (melyik adatbázisban van) és az msexchhomeservername (melyik exchange szerveren van) tulajdonságának az értéke.

Jelöljük be mellé a külső emailcímmel bíró felhasználókat is. Ez ugyanazon a panelen a következő két checkboxot jelenti: ‘Users with Exchange mailbox’ és ‘Users with external mail addresses’. A szűrőfeltétel:

(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))

Azaz mindenki, akinek nem üres a homemdb (melyik adatbázisban van) és az msexchhomeservername (melyik exchange szerveren van) tulajdonságának az értéke – illetve mindenki, akinek meg üres. Jópofa, mi? Ha belegondolsz, hogy beviszünk egy feltételt, majd ‘vagy’ kapcsolattal annak az ellenkezőjét is, akkor tkp megkapjuk az univerzumot. Ami nem baj, mert ugye pont azt kértük… csak éppen megkaphatjuk egyszerűbben is, sokkal kevesebb munkával.
A helyes, varázslótlanitott szűrő:

(&(mailnickname=*)(objectCategory=person)(objectClass=user))

Ha belegondolsz, hogy ez a szűrőfeltétel minden RUS futáskor végigmegy a címtáradon… ugye nem mindegy, mennyit kell tökölnie a feltétel kiértékelésén.

Kitérő vége.

Szóval nem tetszett a szerverneves vizsgálódás. Ldp-ből kinyomtattam mindenfajta objektumból egy-egy teljes tulajdonságlistát, majd egy kihúzófilc társaságában félrevonultam. Kerestem, hol lehet ezt az egészet megfogni.
Hamar kiderült, hogy a szervernévvel egész konkrétan nem. Az ugyanis a magyar kontaktoknál is üres, nemcsak a kintről betoltaknál.
Gyakorlatilag nem találtam semmit. Illetve találtam, de. Nekem, emberi aggyal egyből látszott…de látszik-e ez a programnak is? Ugye ott van a distinguishedname, mint paraméter. Ebben szépen benne van az objektum elérési útvonala is. Márpedig a letolt címek, mégha egy nagyon bonyolult OU struktúrában is, de egy OU-n belül vannak. Azaz a distinguishedname valahogy így néz ki: cn=blabla,,,ou=PamPam,ou=blabla,dc=blabla. A vastaggal jelölt rész mindegyik idegen címben megegyezik, és csak azokra jellemző. Nosza, nézzük csak meg azt az OPATH szintakszist. Jé, ez a nolike egész szimpatikus. Tud ez wildcardot? Tud. A distinguishedname tulajdonságra létezik változó? Létezik, méghozzá ugyanazzal a névvel. Mire várunk?

Hölgyeim és Uraim! Imhol az új GAL:

alias -ne $null -and distinguishedname -nolike ‘*ou=PamPam*’

Már csak be kell gépelni. Jelzem, elsőre úgysem fog sikerülni. A filterek beadása rendszeresen kész katasztrófa. Elsőre úgyis csak címlistákon gyakorlunk, tehát dobjuk be ezt a keresést egy már létező ‘teszt’ nevűbe:

set-addresslist -identity teszt domaincontroller dc.domain.hu -recipientfilter {alias -ne $null -and distinguishedname -nolike ‘*ou=PamPam*’} -whatif

A -whatif azért van a végén, hogy ne csinálja meg, csak írja ki, mi lett volna.
Nos?
Ha jól csináltuk, akkor egy kövér errort kaptunk. Azt mondja, ennél a tulajdonságnál nem használhatunk wildcard-ot.
Ez már maga a Turáni Átok. Miért, ó miért? Bakker, hiszen ezen tudtuk (volna) egyedül megfogni a külsős címeket.
Gugli. Ezen a fórumon valaki hasonlóba futott bele, választ persze nem kapott. Viszont a Szkriptelő Fiúk egy helyen elkottyantották magukat:

Alas, this won’t work, either. As it turns out, the DN is a “constructed” attribute. The DN isn’t actually stored in Active Directory, it’s constructed on-the-fly any time you request it. Thus you can’t do a wildcard search on the distinguishedName attribute. And don’t bother asking about the ADsPath attribute, which also contains the OU name; you can’t do a wildcard search on the ADsPath, either.

Nem örülök… de beletörődtem.

Viszont az agyam, az kiürült. Szórakozottan nézegettem a papírjaimat, meg a változókat. Aztán az agyam kezdett magára találni, szép lassan összerakta az újabb variációt. Nézzük csak, proxyaddress tulajdonság, melyet itt emailaddresses-nek hívnak. Határozottan jelzi a táblázat, hogy nyomjuk csak bátran neki a wildcardot, bírja. Csakhogy ez egy tömb. Hogyan szűrjünk rá? Ezt is megmondja: a tömb elemei vesszővel vannak elválasztva és az egész egy szép nagy sztring. Nocsak. Persze az SMTP cím nem megoldás, rengeteg fajta van a cégen belül, aztán meg ott vannak a külsős kontaktok is. Na de… itt van ez az őskövület. Az X400-as cím. Mely már az égegyadta világon semmire sem jó. Csakhogy ennek a ‘P’ paramétere (Private Management Domain Name) pont az organizáció neve. És X400-as címe mindenkinek van – hiszen ez csak az email address policy-n múlik.

Azaz a következő kisérlet:

alias -ne $null -and emailaddresses -like ‘*p=orgname*’

Na, ez már jó. Mennyire? Túl.
Ez ugyanis beleveszi az összes emailcímmel bíró public foldert is, azt meg mi nem igazán szeretnénk. De innentől már rutinmunka. Úgy csinálunk, mintha gyártanánk egy új címlistát, bejelölünk mindenkit az első panelen (vegyük észre, hogy a public folderek fel sincsennek sorolva, azokat csak EMS-ből lehet felvenni), majd az utolsó panelről ctrl+v-vel lekapjuk a recipientfilter paraméter értékét, beleírjuk az emailaddresses figyelést… és készen is vagyunk. Imhol.

set-addresslist -identity teszt -domaincontroller dc.domain.hu -recipientfilter {emailaddresses -like ‘*p=orgname*’ -and (RecipientType -eq ‘UserMailbox’ -or RecipientType -eq ‘MailContact’ -or RecipientType -eq ‘MailUser’ -or (RecipientType -eq ‘MailUniversalDistributionGroup’ -or RecipientType -eq ‘MailUniversalSecurityGroup’ -or RecipientType -eq ‘MailNonUniversalGroup’ -or RecipientType -eq ‘DynamicDistributionGroup’) -or (RecipientType -eq ‘UserMailbox’ -and ResourceMetaData -like ‘ResourceType:*’ -and ResourceSearchProperties -ne $null))}

Habár már éppen eleget dolgoztunk ma, de azért ellenőrizzünk. Számoljuk össze, hány emberből áll az egyik lista és hányból a másik. Apró baki, hogy Exchange 2007-ben már csak preview van az Address List tulajdonságlapján, számláló nincs. Na de ott van még a régi szerver! Meg tudja számolni a 2003-as Exchange System Manager a 2007-es címlista elemeit? Meg hát. Igaz, eleinte hőbörög, de aztán beletörődik és számol.
A jó hír az, hogy kicsi az eltérés. A rossz hír az, hogy van. Nyilván annak a húsz embernek nem vigasz, hogy csak huszan nem látszanak a listában. És persze az egyik biztosan a vezérigazgató.
Akkor mégsem végeztünk. Nyilván az történt, hogy a több ezer emberből húsznál ki van kapcsolva a recipient policy, manuálisan meg nem kaptak X.400 címet. Semmi gond, megkeressük, levadásszuk.
Nyilván szkripttel.
Egy általános keresőszkript mindig itt figyel a gépemen, pusztán csak a kilistázott adatokat kell konkretizálnom. X400-as cím… az ugye a proxyaddresses tömb része. Nem tudom, ki szeret tömböt boncolni, én nem igazán. Kerülő út? Persze, hogy van. Tudni kell, hogy létezik olyan, hogy textEncodedORAddress változó, ebben a felhasználó elsődleges X400-as címe figyel. Pusztán csak ezeket kell lekérni egy Excel táblába, majd vizuálisan kiszúrni, kinél nincs adat.

Innentől már tényleg csak a piszkos munka van hátra.

Faragások

A szerverek telepítése pénteken volt. Szombat délelőtt már csörgött is a telefon: nem megy az OWA. Érezhető volt a gyanú, hogy mivel tegnap mi piszkáltuk az Exchange szervereket, biztosan mi keffentettünk el valamit. Nekem meg egyértelmű volt, hogy az organizáció upgrade nem volt szabad, hogy beleszóljon a webes elérésbe… de azért az ördög nem alszik. Megkértem a rendszergazdát, telnetelgessen már be az smtp porton az OWA szerverről a backend Exchange szerverre. Semmi. Akkor esetleg beszélgessen el a tűzfalas emberrel – tettem le a telefont. Mint később kiderült, a tűzfalas kolléga, anélkül, hogy bárkinek is szólt volna, ugyanazon a pénteken cserélt tűzfalat – és a szabályok visszatöltésébe valami hiba csúszott, emiatt az OWA szerver leszakadt. Teljeskörű tűzfal teszt az átállás után… az nem volt. Gondolták, ha valakinek valami baja van, majd szól.
Néhány újabb felesleges ősz hajszál a bozontomban.

Hétfő reggel a helyi rendszergazda kétségbeesett telefonja fogadott: az új konzolból nem érhetők el a gyerektartomány postafiókjai. A fene. Nézzük azokat a Routing konnektorokat… jók. Mi lehet? Nézzük csak az admin konzolját… hát persze, a View beállítás alaphelyzetben csak a root tartomány felhasználóit mutatja. Üde reggel.

Aztán még aznap a Nagyvezér behívatta az IT vezetőt. Hogy sem ő, sem a kulcsemberei nem tudtak a hétvégén OWÁzni. Egy ilyen kritikus időpontban. Úgy lebaszták a hapit, mint a pengős malacot. Közölték vele, hogy az Exchange projektben több hiba nem fordulhat elő. Nyilván az IT vezető is közölte velem, hogy ugye megértettem: több hiba nem lehet. Ja.

Akkor jöhetett a filter konverzió. Az ldap filterek megvoltak, a feltételeket átalakítottam, bemásolnám az OPATH filtert – kövér syntax error. Fejvakarás. A francba… az OPATH nem ismeri az AD objektumokat. De akkor mit ismer? Hát, AD objektumokat. Legalábbis néhányat – de nem mindet. A homeMDB értéket például nem. Hosszú napnak nézünk elébe. Blogböngészés. Evan azt írja, hogy nincs leprogramozható út a két filtertípus közötti konverzióra, ezért nem rakták bele a telepítőbe az automatikus konverziót. Mondjuk, ettől azért zabos vagyok egy kicsit, hiszen emiatt még nem kellett volna megölni a telepítést: például az Address List-ek ldap filterei sem konvertálódtak át, mégis tovább tudott menni a folyamat. Miért kellett a Recipient policy-knél leblokkolni?
Aztán ahogy továbbolvastam ugyanazt a blogot, még zabosabb lettem. Bill Long visual basic-ben ugyanis megírta azt a segédprogramot, melyet kollégája szerint nem lehetett megírni. Letöltöttem. Kipróbáltam. Működött. Néha. Volt olyan feltétel, amelyre működött, volt olyan, amelyikre nem. (Érdekességképpen megjegyzem, hogy a homeMDB érték neve Database lett. Mindjárt más, ugyebár.) Aztán azt is észrevettem, hogy ott nem működött, ahol szerepelt egy olyan feltétel, hogy ‘ne $null’, azaz ‘a tulajdonságnak van-e értéke’ vizsgálatnál. Akárhogy tekergettem, nem fogadta el vele a -recipientfilter paramétert a cmdlet – miközben a net tele volt ilyen példákkal és sehol sem említették, hogy trükközni kellene. A ‘ne $null’ nélkül viszont ment minden. Őszültem megint egy kicsit. Végül kínomban zárójel helyett kapcsos zárójelbe tettem az egész feltételt – és akkor már elfogadta. Az élet apró szépségei.
El se hittem, de délutánra átkonvertáltam az összes Recipient Policyt, tesztek, mindegyik működött. Be lehetett újra röffenteni a RUS-t.

Második forduló: címlisták. Emlékszünk, mind a GAL, mind az Address List-ek ugyanúgy ldap lekérdezések. Itt már nem vacakoltam, Bill Long kis programjával sorra konvertáltam át a filtereket, majd nyomtam be a cmdletből.
Szégyen… annyiszor szoktam mondogatni, hogy ‘ember, gondolkozz’… aztán én magam sem mindig teszem. Miután átkonvertáltam a filtereket, utána kezdtem csak végiggondolni, mit is tesznek ezek egyáltalán? És látszott, hogy a bonyolult átkonvertált cuccok helyett van sokkal egyszerűbb út is az OPATH-on belül, sőt, ezekhez varázsló is van. Na, nem mindhez, de a legtöbbhöz. Itt egy példa:

Ez az az OPATH filter, mely az eredeti Exchange2000 ‘All Users’ ldap filter transzformációjából keletkezett:
(& (mailnickname=*)
(| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))
( ( Alias -ne $null ) -and ( ( ( ObjectCategory -like ‘person’ ) -and ( ObjectClass -eq ‘user’ ) -and -not ( Database -ne $null ) -and -not ( ServerLegacyDN -ne $null ) ) -or ( ( ObjectCategory -like ‘person’ ) -and ( ObjectClass -eq ‘user’ ) -and ( recipientType -eq ‘UserMailbox’ ) ) ) )

Tulajdonképpen bele lehet erőszakolni egy Address List-be. Működni is fog. De ha végiggondoljuk, mit is csinál a szűrő, akkor rájövünk, hogy ugyanezt varázslóval is be tudjuk nyomni.

A varázslónak megfelelő Powershell cmdlet egyébként így néz ki:
Set-AddressList “All Users” –IncludedRecipients MailboxUsers

Nyilván ezekre a szűrőkre is igaz, hogy az egyszerű a szép. És a gyors is.

Már csak a globális címlistával kellett valamit kezdeni – a GAL-hoz ugyanis nincs varázsló. Semmilyen. Elfogyott. Egy logikus kísérlet: get-globaladdresslist. És igen. Innen nyílván működött a set-globaladdresslist is, na meg Bill Long progija. Szuper.
Teszt: új postafiók, mennyi idő után jelenik meg a GAL-ban. Soha. Tudom, nem szabad rohanni, az Exchange a nyugodt emberek platformja, de ennyi zen azért még nekem is sok volt. Jé, van olyan parancs is, hogy refreshGAL. Aztán semmi. Úgy hagytam, mint a vasalt ruhát. És lám, másnap már meg is jelent az új postafiók. A helyi rendszergazda morgott ugyan valamit, de a probléma megoldását elhalasztottuk. Majd, ha sok időnk lesz.

Érdekesség még az ütemezési lehetőség az email address policy/address list kreálásánál. Az ember elsőre azt hinné, ez valami olyasmi, hogy megadott időnként lefut és érvényesíti a házirendet. De persze ennél műveltebbek vagyunk, tudjuk, hogy RUS jellegű tevékenység ebben a verzióban már nincs. Kiváncsian bekapcsoltam, egy héttel későbbre véve az aktualizálást. Nos, azt csinálta, hogy amikor leokéztam a varázslót, megjelent egy számlálóablak. Amelyikben elkezdett visszafelé számolni. Másodpercenként. Egy hetet. Addig persze a konzolt nem lőhetem ki, mert menne vele a számlálós ablak is. MegaLOL. Cancel.

Szünet. Egy hét idegnyugtatás az őszi erdőben. Hegynek föl, völgynek le.
Ügyfél ezalatt hozzá se nyúlt a rendszerhez.
Visszajöttem. Az első barátságos pillantások hamar elsötétedtek: a System Attendant nem megy. Az Information Store megy ugyan, de újraindításkor bevés valami hülye hibát az eseménynaplóba. Az SA meg elindul ugyan, ezt be is írja, de utána egyből leáll. Hibaüzenet utáni turkászás, sehol semmi. EventID hallgat, Google szintúgy. Addig jutok, hogy jó eséllyel valami ldap cucli lesz. Beugrik, hogy valahol be lehet állítani, melyik GC-t részesítse előnyben a szerver. Lehet, hogy az a baj, hogy van a címtárban néhány nem w2k3 DC/GC? Állítsuk be mind organizáció, mind szerver szinten, melyik DC-t használja. Semmi javulás. Kínomban újraindítottam a gépet – és innentől tökéletesen megy.
Nem jósolok hosszú karriert a gyerektartomány W2k tartományvezérlőinek.

ps.
Nem sokat dobott a jókedvemen, hogy az egész cirkusz után jelent meg Bill Long írása erről az egészről. Ebből az derült ki, hogy a telepítő csak a _felesleges_ zárójelektől és & jelektől akad ki – ergo maradhatott volna az ldap filter, csak adsiedit-tel ki kellett volna műteni a többletet. Köszönöm, fiúk. Azért a KB cikkbe is beleírhattátok volna.

Cause 3
There is a parenthesis or an ampersand in a recipient filter. Additionally, Exchange 2007 uses OPATH filters instead of LDAP filters.

Itt ugye egy szó sincs arról, hogy _felesleges_.

De azért ne hagyjuk ezt annyiban, nézzük csak meg pontosabban, mit is mond Bill?

Although Active Directory itself has no problem ignoring the unnecessary ‘&’, Exchange 2007 setup doesn’t like this at all.

The parentheses surrounding the server name in the value confuse setup, causing the same behavior.

Érted? Tehát azok az emberek, akik az Active Directory-t fejlesztették, le tudták kezelni azokat az eseteket, amikor egy név az ldap filterben zárójelet tartalmazott, vagy bekerült egy felesleges műveleti jel (&). Ellenben azok a kutyaütők, akik az Exchange setupot írták, sajnos már nem. Ezért hal be a setup.
Valamikor mindenesként dolgoztam, ami azt jelentette, hogy kódoltam is, mint állat. Volt egy beosztottam is, egy gépésztechnikus srác, akit én tanítottam meg programozni. Azt hiszem, zokogva szúrtam volna tökön magam, ha a srác képtelen lett volna egy ilyen beviteli stringet parszolni. Pedig mi tényleg kutyaütők voltunk.

Gotcha!

Elkaptam. Avagy a zombi visszanéz.

Jó két napja az összes agykapacitásomat ez a címlistás balhé kötötte le. Aztán tegnap este fél tizenegykor bevillant a fejembe egy beállító panel. Bakker, tuti, hogy azon rossz adat van! Beléptem az ügyfél rendszerébe, megnéztem – és tényleg. A gyerektartományra vonatkozó RUS olyan GC-re hivatkozott, mely időközben megszűnt. (Miért zombi? Mert elméletileg Exchange2007 organizációban a címlista frissítésében már nem lenne szabad, hogy a RUS szerepet játsszon. Aztán mégis.)
Mindenesetre, anélkül, hogy túlzottan belemennék a részletekbe – úgyis cikk lesz belőle valamilyen formában – ettől még nem lett barátságosabb ez a címlista szétosztás. Csak hogy két rétegét említsem:

  1. A kijelölt Exchange szerver alapértelmezésben naponta egyszer csomagolja bele a GAL pillanatnyi állapotát az Offline Address Book-ba.
  2. A cached módban működő Outlook kliensek alapértelmezésben 24 óránként töltik le az OAB-ot.

Azaz extrém esetben simán összejöhet, hogy az adminisztrátor létrehoz egy postafiókot, de a kliensnél csak 48 óra múlva jelenik meg a címlistában. Döbbenetes. És akkor a többi rétegről, a kiszámíthatatlan RUS stemplizésekről, a hasonlóan kiszámíthatatlan Public Folder replikációról, a kiszámítható, de szintén időt befolyásoló címtárreplikációról még nem is beszéltem. Nagyon ráfért már erre az egész koncepcióra egy ráncfelvarrás – szomorú, hogy az új disztributálás csak Exchange2007/Outlook2007 kombinációban működik.

Eljöttek az angyalok

A címekkel együtt.

Előzmények:
Itt írtam róla, hogy egyik ügyfelünknél váratlan áldás érkezik: közel 33000 kontakt pottyan az égből a címtárukba. Azt is írtam, hogy sikerült megvédeni ezektől a globális címlistát – de nem túl elegáns módon. Mindenképpen szükség lett plusz adminisztrálásra, ami emberi munka, következésképpen hibaforrás. (Nem mintha a gép nem tudna…)

A héten megkaptuk az első adag címet és alaposan szemügyre vettem őket ldp-vel. Ahogy haladtam sorról sorra, egyre szomorúbb lettem. Sajnos bejött a logika – ha ezek az idegen sejtek látszódni akarnak a szervezetünkben, akkor teljesen hasonulniuk kell. Még az exchangeLegacyDN érték is teljesen ugyanaz, mint a saját címeinknél.
Nem hatásvadászatból írom, tényleg így történt: amikor a tulajdonságok végére értem, akkor találtam – az utolsó sorban – egy olyan bejegyzést, amely egyből bearanyozta a napomat. Ez a neve: msExchangeOriginatingForest. A név magáért beszél: annak az erdőnek a neve van benne, ahonnan a címet migrálták. Értelemszerűen azoknál a címeknél, melyek helyben születtek, ez a tulajdonság üres – azaz nem látszik az ldp-ben.
Innentől kezdve egyszerűen csak ki kell egészítenem a GAL lekérdezést a (!(msExchOriginatingForest=*)) feltétellel és az a bizonyos sokat emlegetett Bob már rögtön a bácsikám is.

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é.

Ö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.