Tag: exchange

Cache vagy nem Cache, ez itt a kérdés

Van egy kis bajom az Exchange szerverünk sebességével.

Az egyik gyanúsítottam, hogy néhány kliens nem Cached Mode-ban használja az Outlookot és ez terheli a szervert. Át kéne őket állítani.

Itt jön a kérdés, hogy melyeket. Hogyan tudjuk kideríteni, hogy mely klienseink mennek Online módban?

Így:

Get-LogonStatistics | Where-Object { $_.ClientMode -eq “Classic” } | ft -Property UserName,ClientMode

IMCEA

Még a szék sem tudott megmelegedni alattam, amikor rögtön átpasszoltak nekem egy hibajegyet. Első ránézésre semmi különös, valaki nem kap meg minden levelet. Ilyesmi elő szokott fordulni, egyszerű nyomozás.

Viszonylag hamar kiderült, hogy nem. Kértem egy NDR-t, ahol is elég furcsa cím szerepelt:

IMCEAEX-_O=CEGNEVORG_OU=BUDAPEST_cn=Recipients_cn=UserAlias@cegnev.hu
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

Hát, nem csoda, hogy ilyen címet nem talált. Életemben nem láttam még hasonlót. Egyáltalán, mi a lópikula ez az IMCEAEX- címtipus?

Szerencsémre Jason Nelson meghallotta a segélykiáltásomat és azon nyomban írt is róla egy cikket. Indulásnak remek.

Tehát cím kapszulázás. Minden emailcím, amely úgy kezdődik, hogy IMCEA, az valami olyasmi, hogy értelmetlen, vagy nem létező smtp cím helyett gyárt egy létező smtp címet, de olyan szintaktikával, hogy az egyrészt értelmes smtp cím legyen, másrészt vissza lehessen belőle fejteni az eredeti, nem smtp címet.
Példaként Jason a korai, Exchange 4.0 időket említette, amikor simán előfordulhatott olyan eset, hogy a rendszerbe csak utólag került bele az Internet Mail Connector (IMC), azaz az SMTP protokoll. Az alapértelmezett levelezési cím X.400 volt, ergo egyáltalán nem volt biztos, hogy aki kifelé akart levelet küldeni, annak volt smtp címe is. Ilyenkor lépett színre Miranda, a Proxy – aki legyártott az eredeti címből egy smtp címet. Az IMCEA előtag tuti volt, utána jött a kiindulási cím tipusa, majd a kiindulási címből generált többi tag.
Nézzük meg ilyen szemmel az ismeretlen címet. IMCEAEX: EX tipusú cím. Hogy ez mi? Majd később meglátjuk. A többi viszont gyanúsan X.400 jellegű, de ha jobban megnézzük, mégsem az. De valahonnan nagyon ismerős. Gondolkozósarok, gondolj, gondolj…  aztán beugrott: legacyExchangeDN!  Megnéztem a konkrét felhasználónál és ezt találtam: /o=CEGNEVORG/ou=BUDAPEST/cn=Recipients/cn=UserAlias. Megérkeztünk.

Innentől kezdve kettéágazik a nyomozás:

  • Miért nem találja meg legacyExchangeDN alapján a létező postafiókot?
  • Miért próbálkozik egyáltalán ezzel a bonyolult módszerrel, amikor a felhasználónak van rendes smtp címe is?

Elkezdtem kisérletezgetni. A sok hasonlóság mellett azért van különbség is, például a keresett cím végén ott fityeg egy @cegnev.hu is. Nyilván a legacyExchangeDN értéket nem lehet módosítani – hiszen akkor elvesztené a felhasználó a postafiókját. De ha úgysem találja meg, akkor lehet azzal próbálkozni, hogy felveszünk neki egy X.500(!) címet. (Azért X.500, mert a legacyExchangeDN érték tulajdonképpen egy X.500 cím.) Mit is írnak itt?

The Lightweight Directory Access Protocol (LDAP) filter that is used for address resolution is described as follows:
* For the EX e-mail address type, the LDAP filter is based on the recipient legacyExchangeDN Active Directory attribute or the recipient proxyAddresses Active Directory attribute. The legacyExchangeDN Active Directory attribute takes precedence.
* For all other e-mail addresses types, the recipient proxyAddresses Active Directory attribute is used as the LDAP filter.

Azaz a címfeloldásnál a legacyExchangeDN csak precedenciát élvez. De ha nincs, akkor jó lehet az X.500 cím is.

Oké, miket érdemes módosítgatni. Arra viszonylag hamar rájöttem, hogy a konverzió során a ‘/’ jelből ‘_’ lesz, tehát ezek egyenértékűek. De ezt a kukaccégnévhu-t érdemes lenne kipróbálni.
Sajnos nem segített, aztán persze jobban elolvasva rájöttem, mennyire gyökér voltam.

The algorithm works like so (for the click challenged).  Alpha numerics:  Ok.  Slashes get converted to _.  Everything else gets “Plus” encoded.  That means there’s a + and the two digit hex value of the character. Finally the Exchange server’s primary domain is appended (so that hopefully replies get back to it).

Ergo ez a kapálózás nem vezetett sehova. A felhasználó legacyExchangeDN értéke teljesen rendben van.

Nézzük a második szálat, ránézésre úgyis ezen a nyomon lehet megfogni az egész jelenséget. Miért próbálkozik bekapszulázott címmel a normális smtp cím helyett?
Erről is van egy nagyon jó írás, itt.
Azt írja, hogy ha auto-complete módon írunk be címet, akkor az Outlook a cache-ből X.500-as címet varázsol elő. Ha a cache-ben rossz cím ragadt be, akkor tényleg nem lesz meg a címzett. Megoldás: törölni a cache-t, azaz a feladó profiljában az .n2k fájlt. (Illetve megemlíti megoldásként az általam is elkövetett X.500-as címmel való bűvészkedést.)
Ezzel csak két probléma volt:

  • Az ügyfélnél még mindig Outlook2000 a standard, az pedig nem használ auto-complete cache-t. Nincs .n2k fájl.
  • Amikor nekiálltam tesztelni, az ötödik küldésnél én is megkaptam a hibaüzenetet. Pedig addig az alkalomig soha nem küldtem még levelet a felhasználónak.

Kezdett frusztráló lenni az eset. Egyre jobban viszketett az eszkaláló izmom, de jelen esetben a továbbpattintás szóba sem jöhetett, mivel az Outlook 2000 már nem támogatott az MS részéről.
Vegyük sorra. A levelek nagy részét megkapja a felhasználó, tehát alapvetően megvan mindene: van smtp címe, van X.500 címe (legacyExchangeDN). Ő is tud levelezni mindenkivel. Előfordul viszont, amikor se smtp címe nincs – ezért jön feladó oldalról az IMCEAEX címkapszulázás – de ilyenkor legacyExchangeDN értéke sincs, mert a kikapszulázott címre sem kapja meg. Búvópatak? Láthatatlanná tévő köpönyeg? Miaf?
Persze ebben a korban már nem hiszünk a mesében: több tartományvezérlős környezetben simán előfordulhat, hogy egy tartományvezérlő megmakkan, aztán ha tőle kérdeznek, akkor hülye válasz jön, ha mástól, akkor meg jó. Ilyen például akkor lehet, ha az egyik DC-re nem működik a replikáció. Nosza, replmon, kérem az összes replikációs hibajelentést. Semmi. Üres halmaz. Ez ugye egyfelől jó hír, másfelől pedig meglehetősen frusztráló. Akkor most az van, hogy minden DC tökre ugyanazt az objektumot tartalmazza. De biztos, hogy DC-t kérdez a kliens? Illetve biztos, hogy az AD ldap adatbázisát? Hiszen ott van a globális katalógus, azaz jelen esetben a GAL. Meg ott van a pillanatkép a globális katalógusról, az OAB.  Valamelyik gépen sérült lenne a GC adatbázis? Ezt végülis le lehet ellenőrizni, ldp-vel rá lehet kapcsolódni, csak arra kell vigyázni, hogy ne a 389-es portot adjuk meg, hanem a 3268-ast.
De itt sincs semmi rendellenesség.

Jó, akkor elkezdtem vadul tesztelni. Outlook 2000/2003/2007. Egy idő után mindenhol megjelent a hiba. Ergo már biztosan nem kliens oldali problémáról van szó.

Nézzük, mit kapok OWÁ-ból.

Szöget. Kibújni a zsákból.

Amikor ki akartam választani a címzettet a GAL-ból, hibaüzenetet kaptam. Azt mondta, hogy az objektum vagy nem létezik, vagy korrupt lett vagy nincs hozzá jogosultságom elérni. Miután kipróbáltam néhányszor és volt, amikor láttam, volt amikor nem – így az az egy lehetőség maradt, hogy a felhasználó korrupt lett.
Kivégezni.

Kollégák lementették a postafiókját, feljegyezték a beállításait… majd törölték a felhasználót postafiókostól, később pedig újra létrehozták. (Választhattuk volna az autoritatív restore-t is, de valahogy inkább nem.) Azóta nincs hibaüzenet.

Case solved.

Mondjuk, a lelkem békéje nem állt teljesen helyre. Soha nem fogjuk megtudni, mi is volt a jelenség mögött. Akármi is volt, a törléssel eltávozott a rendszerből.
Manapság pedig az SLA fontosabb, mint a rejtélyek teljes felgöngyölítése.