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.
2009-05-26 at 08:35
Szia Józsi,
Hasonlóba én is belefutottam. A get-mailcontact – set-mailcontact helyett az update-recipient parancsot kéne használni:
http://technet.microsoft.com/en-us/library/bb738148.aspx
üdv,
Zoli
2009-05-27 at 00:06
Nos, igen. Ez egy fokkal elegánsabb.
Át is írtam a szkriptet. 🙂
2009-05-27 at 06:08
Szia Józsi,
Kapcsolódva a fentiekhez, az ugye nem fordul elő, hogy az MIIS olyan kontaktot is felvesz akinek az e-mail címe már létezik exchange userként?
Ezt ugyanis az AD nem ellenrzi és balhé lehet belőle.
üdv,
Zoli
2009-05-27 at 07:17
Ennyire nem ismerem a MIIS-t. Gyakorlatilag nem fordul elő ilyesmi – de hogy azért, mert a MIIS eleve nem engedi, vagy azért, mert a MIIS rendszergazda okosan írta meg a szkriptjeit… ezt nem tudom.