MonthMay 2009

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.

Exchange 2007 SP1 Update Rollup 8

Megjelent.

Bővebb információ itt:

http://msexchangeteam.com/archive/2009/05/19/451371.aspx

Az ígéretek szerint javították az Update Rullup 7-ben elkövetett hibát, mely szerint a DSN üzenetek valami borzalom Guid-os címről jönnek.

Beszéljünk nyelveket

Velem mostanában nem történik semmi érdekes: tervezek ugyan egy többrészes ismeretterjesztő cikket, de ahogy mostanában a csillagok állnak, problémamegoldást, nyomozást ne nagyon várjatok tőlem.

Inkább leírom, hogyan járt egy kollégám a napokban.

Exchange 2007-et kellett telepítenie. Ez ma már szerencsére nem annyirra horror, mint eleinte. (No, nem azért, mintha egyszerűbb és hibátlanabb lenne: csak már annyian szívtak vele, hogy mindenre megvan a megoldás a neten.)

Neki is állt. Nyilván először végigolvasta a feltételeket. Ki is pipálta mindegyiket. Ugyan volt egy pont, ahol elgondolkodott egy kicsit, de végül csak rálegyintett. Arról volt szó konkrétan, hogy a telepítési doksik szerint minden érintett tartományban lennie kell legalább egy minimum Windows 2003 Server Sp1 DC-nek, plusz a Schema Master-nek is minimum ennek kell lennie. Ez bőven meg is volt, mindenhol SP2-es volt a környezet… csak éppen az összes DC magyar nyelvű volt. (Kéretik nem anyázni, mi azzal dolgozunk, ami az ügyfélnél van.)

Végül belevágott. Rögtön az első lépésben fejreállt a setup /preparelegacyexchangepermissions. Káromkodás, nyomozás. Nyilván először az ember a triviális problémaforrásokra koncentrál, no meg persze a hibaüzenet is eléggé félrevezető volt. Nem talált semmit. Többször is beszéltünk, de én se tudtam neki segíteni. Maximum annyit, hogy toljad haver a guglit ezerrel, mert ha ott sem lesz megoldás, akkor sehol sem. Tolta. Végül egy órával később jött a telefon, hogy oké, minden rendben.

Mi is történt?
Mielőtt elmélyednék a válaszban, egy gyors segédinformáció. Miért is kell annyira az Exchange 2007 szervernek minimum a Windows 2003 SP1? Azért, mert az SP1-ben jött be egy úgynevezett Service Notification funkció. Ez azt tudja, hogy bármi változás is történt a címtárban, akkor erről értesíti az érintett alkalmazásokat. Az Exchange 2007 erősen épít is rá.

Na most, ha te lennél egy Exchange setup folyamat programtervezője (és a végeredmény alapján simán lehetnél is, sőt , ahogy elnézem, akár az Újpest Központ metróállomás nyáladzó hajléktalanjai is lehettek volna), akkor hogyan ellenőriznéd, hogy a DC-k megfelelőek-e? Én – és a hajléktalanok – valószínűleg úgy, hogy rávizsgálnánk, működik-e ez a szolgáltatás. A fejlesztők nem ezt az utat választották: ránéztek egy registry értékre, hogy oda mi van beírva. Angolul. Tehát a Windows Server 2003 Service Pack 1 nyilván jó, ha a végén a szám nagyobb, mint egy, az még jobb… és ennyi. A Windows Server 2003 Szervízcsomag 1 például már nem volt jó.
Most gondolj bele, hogy már csak strukturálisan, logikusan nézve is, mekkora baromság ez? Ha egy funkcióra vagyok kíváncsi, akkor nem a funkció működését vizsgálom, hanem egy tőle független karakterlánc értékét. Miközben nem tudom, mit csinál a másik kéz… mely egész egyszerűen nem angolul írja be a karakterláncba az értéket.

Miután a kollégám rájött, át is írta adsiedittel a DC tulajdonságainál a megfelelő értéket. Egyből lefutott a jogosultsági rendszer preparációja. Kolléga boldogan felsóhajtott, kiment, ivott egy kávét, kifújta magát. Majd visszament és beírta a sorban következő parancsot: setup /prepareschema.
Zsíros hibaüzenet.
Tekintve, hogy kollégámnak ez volt az első találkozása az Exchange 2007 szerverrel, egész pontosan el tudom képzelni, mit gondolhatott ekkor. De nem fogom leírni. Habár ez nem egy prűd blog, de egyáltalán nem vagyok benne biztos, hogy a monitorod ilyen szinten is elviselné a túl erős kifejezéseket.
Gyors ellenőrzés a registry-ben… és igen: amíg ő kint kávézott, egy automatikus mechanizmus észrevette, hogy módosítva lett a szerver verziószáma. Természetesen gyorsan javította is. Melytől persze ismét fejreállt az Exchange telepító. Ha valaki hülye, akkor az legyen következetesen is hülye.
Innentől nyilván gyorsan ment a prepare folyamat: kolléga minden parancs kiadása előtt megnézte a registry-t és ha kellett, javított. Aztán most már csak reménykedünk, hogy a működés során ez az idióta hiba nem fog többször előjönni.

ps.
Kolléga végül átküldte a linket, ahol megtalálta a megoldást. Külön jól esett, hogy az eset a magyar Technet blogban fordult elő, és viszonylag kevés felesleges kör lefutása után Flowman kolléga be is írta a helyes megoldást.
Csak azt magyarázza el valaki, hogy ez miért a német nyelvű Technet blogon jelent meg?