Category2000/2003

targetAddress avagy spóroljunk a licenszeken

Most következik az az eset, amikor bebizonyítom, hogy nem értek az Exchange-hez.

Mit csinálunk olyankor, amikor van egy email címünk, amiért a saját Exchange szervezetünk a felelős, de az ide érkező leveleket tovább kell küldenünk egy külső címre, és saját rendszerünkön soha egy darab levelet sem kell tárolnunk, ami a megadott címre érkezik?

Én (és az a gyanúm, hogy ezzel nem vagyok egyedül) a következőt tettem a fenti esetben. Létrehoztam a saját címünkhöz egy postaládát, a külső címhez egy kontaktot és a postaládát ráirányítottam a kontaktra. Megbékéltem azzal, hogy ez ronda, sőt minden egyes ilyen akció visz magával egy nem is túl olcsó CAL-t.

Mostanában a több ügyfélnél az Exchange 2003 – Exchange 2010 Cross-Forest migrációval birkózom (ez egyszer még megér egy másik cikket). Ennek kapcsán meglepetten tapasztaltam, hogy a migráció végén a rendszer egy olyan Mail Enabled User-t (ez ugye Exchange szempontból egy kontakt, és mint ilyen nincs postaládája) hagy maga után. Ami viszont képes leveleket továbbítani pontosan úgy, ahogy a fenti kérdésben szerepel.

Némi nyomozás után kiderült, hogy a tettes a targetAddress nevű AD property. Tehát minden levél, ami a kontakt egyik proxyaddress-ére érkezik azt a rendszer tovább küldi a targetAddress property-ben szereplő címre. Ráadásul a rendszer azt a kedvességet is megteszi (mind Exchange 2003 mind 2010 esetén), hogy a targetAddress property-t eleve kitölti a kontakt email címére.

Ebből adódóan az eredeti kérdésre adott válasz így változik:

Felveszünk egy kontaktot a külső címmel, majd a kontakt proxyAddresses listájába felvesszük az átirányítani kívánt saját címet.

Kész vagyunk. Mínusz egy CAL.

Exchange esettanulmány

Van egy ügyfelünk és van nála egy régóta elhúzódó probléma.
Az Exchange organizácójuk nem túl bonyolult, a lentebbi módon néz ki.

Nagyítás

Azaz két administrative/routing group, jelezve, hogy ez valamikor két cég volt, külön IT szervezettel. Mindkét RG-nek saját Internet kijárata van. Mindkét smarthoston X-re végződő operációs rendszer fut. Ami még fontos a történet szempontjából, hogy ‘A’ cég rendszergazdája valamivel paranoiásabb, mint ‘B’ cégé… azaz a smarthoston nem engedi át azokat a kifelé menő leveleket, melyeknek feladója @a.ceg.hu. ‘B’ rendszergazda ellenben mindenkit kienged.
Az elvárt működés az lenne, hogy mindenki a saját kijáratát használja. Ezzel szemben, amennyiben felvesszük ‘A’ cég SMTP konnektorába a * névteret, minden levél – tehát a ‘B’-ben feladottak is – ‘A’ kijáratán mennek ki. Ahol a smarthost el is meszeli a nem oda valókat. Emiatt most gyakorlatilag ‘A’ konnektor le van zárva, mindenki ‘B’-n keresztül levelez.
A cégnél az email meglehetősen kritikus, tehát idő sem nagyon van kísérletezni, meg hibázni sem nagyon lehet.

Kollégám egy évvel ezelőtt kapott egy éjszakát, reggelig sportolt a rendszeren, de nem jutott előbbre. Amint hozzányúlt, felvette a * névteret, megindultak vissza ‘A’ smarthostjáról az NDR-ek, lett is egyből sírás-rívás, árvák könnyeinek potyogása.
Én múlt héten kezdtem el foglalkozni az esettel, péntek délután volt lehetőségem megpiszkálni a rendszert.
Első körben – még hétközben – felvettem mindkét konnektorra egy senki más által nem használt névteret, ahol nekem van egy eldugott postafiókom. (Nem írkálom ki egyenként, de minden smtp névtérhez 1-es súly tartozik.) Ez délután volt, szépen hagytam, hagy terjedjen el az infó a Link State Táblában (LST). Másnap reggel teszteltem, mindkét szerverről küldtem egy levelet magamnak, gyönyörűen a megfelelő kijáraton ment ki mindegyik. Nem lesz itt semmi probléma – nyugodtam meg – akár munkaidőben is át lehetne állítani.
Azért csak megvártam a péntek délutánt. Beírtam a * névteret ‘A’ konnektorába, újraindítottam a Routing Engine Service-t (RES) és az SMTP szolgáltatást, megvártam, amíg az LST frissül, mindenhonnan küldtem egy tesztlevelet – és csak az ‘A’-ból feladott érkezett meg. Jeges rémület szorította össze a szívemet, gondolatban elnézést kértem a kollégámtól, hogy ennyire amatőrnek néztem – és megpróbáltam összekapni magam, hogy megbírkózzak az ismeretlennel. Első körben gyorsan visszaállítottam a kiindulási állapotot, nehogy elvesszenek a levelek. Mondhatnád, hogy mit vacakolok, az smtp konnektoron be lehet állítani, hogy milyen csoportok küldhetnek levelet rajta keresztül, egyszerűen fel kell venni, hogy ‘A’ konnektoron ‘B’ userek ne küldhessenek – és már kész is, lehet menni a pénztárhoz felmarkolni a zsét. Ugyanerre vezetne, ha mindkét konnektoron csak a saját RG-jére érvényesen definiálnám a névtereket. El is raktároztam ezeket a megoldásokat, végső esetben jók lesznek – de itt elsősorban a ‘miért’-et kell megtalálnom és tisztességes megoldást összerakni. A workaround-dal mindig az a baj, hogy nem ismerjük, mi váltja ki, nem tudjuk, milyen más rendellenéséget okozhat. Nehéz így felelősen rendszert üzemeltetni.

Szóval jöhetett a kísérletezgetés. Első körben lecsekkoltam minden elemet. (Az organizáció messze nem ilyen egyszerű, mint amit rajzoltam. Az csak a lényegi vázlat.) Aztán elkezdtem rugdosni a rendszert. (Igen, így identifikálunk: belerúgunk a rendszerbe és lessük, mekkorát sikít.) Nos, láttam olyan csodákat, hogy szemem-szám elállt. A legdurvább az volt, hogy felvettem jó magasra (10) az RG konnektoron a súlyokat, RES újraindít, tesztlevél. És igen, megjött mindkét feladótól! Boldogan csaptam a levegőbe, majd a biztonság kedvéért megnéztem mindkét levél fejlécét. Elég sokáig néztem, egyre üvegesebb szemekkel… majd szóltam Janinak, hogy jöjjön ide, mert ilyesmit még ő sem látott. A ‘B’ szerveren lévő postafiókból a levél az 1-es súlyú út helyett átment a 10-es súlyú RGC-n, majd az ottani 1-es súlyú SMTP konnektor helyett visszament B szerverre – újabb 10-es súly -, végül most már kiment a ‘B’ SMTP konnektoron; azaz mindösszesen összeszedett 21 egységnyi súlyt, az 1 egység helyett. A sportember.

Ha azt mondom, hogy tanácstalan voltam, akkor meglehetősen enyhén fejeztem ki magam. Először is elmentem darts-ot dobálni pár percig. Ránézésre nyugodtnak látszódtam, a figyelmes szemlélőnek legfeljebb az tűnhetett fel, hogy a tábla mellé dobott nyilak is beleálltak a falba. Pedig műanyag hegyűek.

Végül érdekes módját választottam a monitorozásnak. Beírtam újból a * névteret ‘A’ konnektorába, újraindítottam a szolgáltatásokat, mindeközben egy perces auto frissítésre állítottam a Winroute-ot – és fel-alá szkrolloztam a képernyőn, hátha elkapok valahol valami érdekeset. És úgy döntöttem, hogy nem leszek gyáva nyúl, teszek rá, hogy NDR-ek jönnek vissza.
Nos, igen, végül csak elkaptam valamit.
A következő sorozatot láttam:

  • Körülbelül két perc telt el, amíg ‘A’ SMTP konnektora state up állapotba jutott.
  • Körülbelül öt perc telt el, mire az LST frissült.
  • Majdnem tíz percbe telt, mire ‘B’ SMTP konnektora state up állapotba került.

Itt van minden. A magyarázat is, és a megoldás is.
Látható, hogy van egy olyan kritikus öt perc, amikor az organizáció már észleli, hogy két konnektoron is rajta van a * névtér, de a ‘B’ konnektor még nem él. Tehát ebben az öt percben az ‘A’ felé küldi a leveleket. Egyéni balszerencse, hogy mind a kollégám, mind én ebben az öt percben teszteltünk, majd a sikertelen teszt után pánikszerűen álltunk vissza az eredeti állapotra.
Nézzük meg az egyes eseteket:

  • Amikor a teszt névteret vettem fel, nem siettem. Délután beírtam, elmentem haza, reggelig volt ideje elterjedni a változásnak. Azaz nem indítottam újra a szolgáltatásokat, nem került egyik konnektor sem state down állapotba. Persze, hogy ment minden rendben.
  • Na, azzal a súlyemelővel még a hiba gyökerének ismeretében sem igen tudok mit kezdeni. Valószínűleg pont úgy küldtem meg a tesztlevelet, hogy ‘B’ kijárata még éppen nem élt, ezért átment ‘A’-ra, aztán ott valahogy észrevette, hogy időközben életre kelt a ‘B’ SMTP konnektor – és visszament afelé. Elég perverz – és nem is igazán értem, mert nem logikus.

Gyors teszt, immáron jócskán kivárva – és minden levél a saját kijáratán ment ki.
A feladat megoldva.

Aki velem együtt dőlt hátra a székében, elégedetten csettintve, hogy ez egy korrekt lezárása volt az esetnek – igen nagyot tévedett. Ez a megoldás ugyanis – dacára annak, hogy működik – életveszélyes.
Gondolkodjunk el a következő eseteken:

  • ‘B’ rendszergazda újraindítja az Exchange szerverét.
  • Vagy elég csak a Routing Engine Service-t újraindítania.
  • Ledől a ‘B’ smarthost. Oké, tudom, hogy Unix, de a kalapács ellen azok sem rendelkeznek erős védelemmel.

Mindegyik esetben hosszabb-rövidebb ideig az organizáció azt fogja látni, hogy csak ‘A’ konnektor él – és mivel nem tud róla, hogy azon az úton leselkedik Szkülla és Karübdisz – így arra küldi az összes levelet. Azaz nem az történik, hogy ‘B’ konnektor felállásáig a levelek egy kényelmes queue-ban várakoznának – nem, ehelyett egy gusztustalan NDR-rel pattannak vissza.
Szépen végiggondolva a szituációt, visszaállítottam az eredeti állapotot, leírtam, mit tapasztaltam – majd az egészet bedobtam az ‘It needs business decision’ dossziéba.
Amíg ‘A’ rendszergazda nem enged ki minden levelet, addig jobb, ha az a konnektor nem is működik.

Pont, pont, vesszőcske

Egyik ügyfelünk anyacége leszólt, hogy “Béláim, legyetek kedvesek már használni a céges előírás szerinti formát a levelezési címlistában, köszi”.
Kérték, megcsináltuk, hátradőltem. Túlontúl hamar.
Pár nap múlva jöttek a reklamációk: néhány külsős partner nem tud levelet küldeni belsős címekre. Első reflexből visszaírtam, hogy “sorry, de tudomásom szerint az Exchange szerver nagy ívben nem foglalkozik az AD általunk módosított display name paraméterével, itt maximum véletlenek tragikus összejátszásáról lehet szó”. Pedig megtanulhattam volna az eddigi szívásokból, hogy nem jó első reflexből válaszolni, még akkor sem, ha maximálisan biztos vagyok magamban.
A módosítás lényege ugyanis az volt, hogy megvesszőztük a nevet. Azaz ami eddig “Kis Pál” volt, az mostantól “Kis, Pál” lett. Jó, persze fel lehet szisszenni, de hangsúlyozom, ez display name – azaz az a felület, melyet az AD a felhasználónak mutat. A levelezés nyilván a proxyaddresses alapján megy.
És ez bizony így is van. Egészen addig, amíg csak a szerver játszik. Egy igazi admin itt be is hunyja a szemét, mert ami a szervereken túl van, az már a gyehenna. Levelezőkliensek. Fúj.

Nos, boncoljunk levelet.
Egy közönséges email áll egyfelől borítékból és tartalomból. A borítékon van egy feladó (ezt adjuk meg a MAIL FROM smtp paranccsal) és van egy címzett (ezt adjuk meg az RCPT TO smtp paranccsal). A tartalom – mely a DATA smtp parancson belül utazik – meglehetősen összetett valami, pl. meglepő módon neki is van FROM mezője. És itt jönnek be a képbe a levelezőkliensek. A boríték kitöltésével nincs gond, azt kutyakötelességük ugyanúgy kitölteni – de a belső FROM mező már szabad préda. Ma már teljesen elterjedt forma pl. ez: “displayname” <emailaddress>.
Jó, ezt tudjuk. Mi a probléma?
Csináljunk egy kísérletet. Küldjünk magunknak egy levelet, telnettel.
telnet smtp.sajat.domain.hu 25
helo
mail from: nagymagyartarka@sajat.domain.hu
rcpt to: sajat.email@sajat.domain.hu
data
from: “nagymagyar, tarka” <sajat.email@sajat.domain.hu>
subject: apuhodmedbe
pamparampampam
.
quit
És most nézzük meg, mit csináltunk. Küldtünk magunknak egy levelet, melynek a borítékjára feladóként ráírtunk egy fantom címet (nagymagyartarka@sajat.domain.hu), címzettként pedig magunkat (sajat.email@sajat.domain.hu). A trükk ott van, hogy a belső FROM mezőbe beírtuk a saját címünket!
A levelet természetesen meg fogjuk kapni. Nyomjunk rá egy reply-t! Bizony, azt fogjuk látni a címmezőben, hogy nagymagyar, tarka <sajat.email@sajat.domain.hu>, kedvesen aláhúzva. Reménykedőbbek még mondhatják, hogy jó-jó, az Outlook odamaszkol valamit a címsorba, de küldéskor úgyis az email Return-Path mezőjét fogja használni. Ha már itt járunk, nézzük is meg. Nyissuk meg az eredeti levelet, view/options, rögtön az első sorban ott fog vigyorogni, hogy Return-Path: nagymagyartarka@sajat.domain.hu. Tehát, gondoljuk naívan, ha ezt a replyt elküldjük, akkor ez berepül a fekete lyukba – feltéve, hogy valamelyik sunyi kollégánk időközben nem hozott létre nagymagyartarka címet.
Van egy rossz hírem. Az emailt meg fogjuk kapni. A belső FROM értéke űbereli a borítékra írt címet. És ebben a FROM mezőben már szerepel a display név értéke.
Persze még mindig nem látszik, mi itt a baj. Oké, ott van a címben egy vessző. Na és? Kellően körbezártuk idézőjellel, kedves levelezőkliens, tessék nyugodtan nem figyelembe venni.
Most visszaásunk a múltba. Van egy remek oldal, ahol le van írva, milyen karakterek szerepelhetnek az emailcímben. A vesszőre spec azt írja, hogy “megbolondultál?”. Az ugyanis az RFC822 szerint elválasztó karakter. Igenám, de az RFC822-t 2001-ben érdemei elismerése mellett nyugdíjazták, bejött helyette az RFC2822, mely már megengedi a vesszőt, feltéve, hogy idézőjelek között van.
Most már közel vagyunk. Semmi másra nincs szükségünk, mint egy 2001 előtti levelezőkliensre, melynek halvány fogalma sincs az RFC2822-ről. Mit fog csinálni a szerencsétlen, ha ez kerül a címsorába, hogy “Kis, Pál” <kispal@sajat.domain.hu>? Azt fogja mondani, hogy ez két cím: “Kis az egyik, Pál” <kispal@sajat.domain.hu> a másik. Aztán nekiáll visítozni, hogy nem találja a címeket.
Aki szeret kísérletezgetni, nekiugorhat a Freemail webes felületének, remekül hozza a hibát – legalábbis a múlt héten még hozta.

Szuper, megvan a gizda. Mit lehet vele csinálni?

  1. Szólunk a multi Anyucinak, hogy ne legyen vessző a displaynévben. Oké, oké, tudom, csak a teljesség kedvéért írtam ide.
  2. Beállítjuk Exchange organizáció szinten, hogy ne küldje el a display nevet, csak az email címet. (Message format ablak, valamelyik fül.) Nekem, kockafejűnek, ez teljesen jó megoldás lett volna, de az üzlet egyből Apage Satanas-t kiáltott.
  3. Kivezetjük az ősembereket a barlangból a fényre. Magyarul, nekiállunk supportálni az ügyfél üzleti partnereit is, hogyan kell beállítaniuk azt a többezer fajta levelezőklienst, amelyekből néhány nem tudja lekezelni ezt a szituációt.
    Az élet szép.

[Update]
Azóta kisérleteztem egy kicsit és rájöttem, hogy nem ilyen egyszerű a helyzet. Könnyű lenne mindent a kliensre tolni, de mégsem ő tehet a balhéról – hanem a levelezőszerver. A kliens átadja a megfelelő smtp parancsot – nagyjából ugyanúgy – de a szerver az, mely – feltéve, hogy nem ismeri, vagy nem jól ismeri a szabványt -, belebukik a vesszőbe.
Tényleg érdekes.

Minden összefügg mindennel

De rég is volt, te jó ég. Itt írtam egy orbitális nagy zöldségről. Annyira rég volt, hogy azóta a fiúk ki is irtották azt a KB cikket, felszántották, helyét sóval vetették be.
Ettől persze a problémánk nem múlt el. A komment szerint a hibát bejelentettük a PSS-nek, akik rá is uszították embereiket. Több, mint egy évvel ezelőtt. Nem lehet azt mondani, hogy nem vagyunk kellően makacsok.
A bejelentés után a dolgok mentek a maguk útján. Bekértek mindenféle adatot, beküldtem mindenféle adatot. Aztán eszkalálták a problémát a németekhez, akik megint bekértek mindenféle adatot. Ők is megkapták. Aztán nekiálltak kipróbálni ezt-azt – és az egyik próbára az ügyfél azt mondta, hogy ezt pedig már nem. Itt meg is álltunk. Az MTA szolgáltatás hiánya nem érintette őket annyira tragikusan, hogy belemenjenek egy routing groupok közötti szervermigrációba. Köszönték szépen, inkább nem – még akkor sem, amikor az MS bejelentette, hogy ugye tudják, hogy az MTA nélküli Exchange szerver automatikusan nem támogatottá válik.
Eltelt hét-nyolc hónap. Lehulltak a levelek, fehérre váltott a táj, majd elkezdtek bimbózni a rügyek. Az ügyfélnél leváltották az IT vezetőt, az új fiúval jobban lehetett tárgyalni, belement a migrációba. Létrehoztam egy új routing group-ot, telepítettem egy új szervert, konnektorok, routing rendben. Levelezés tesztelve, frankó. MTA indít – hibaüzenet.
Ez bizony övön aluli volt. Az eddigi koncepció szerint biztosan a szerver telepítésénél történt valami gikszer, amely miatt a routing group nem volt teljesen százas. Nos, nem.
Habár. Az új szerver Windows2003, szemben a régivel, mely Windows2000. És az új szerver azt írja az üzenetben, hogy az MTA elindult ugyan, de aztán rögtön le is állt, mert úgy érezte, őrá itt nincs is igazán szükség. Hasonlóan, mint a perfmon szervíz. Kipróbáltam, tényleg az is ezt írja ki.
Ennyi lenne? Az a nagy rejtélyes hiba pusztán csak annyi, hogy nincs kedve elindulni? (Mely valahol érthető, ugyanis közel-távol sincs Exchange5.5 – mindemellett az organizáció még mixed módú.)
Ebbe akár bele is nyugodhatnék, de az eventlogban könyörtelenül ott van ismét a két ominózus hibaüzenet. Most akkor melyiknek higyjek? A direkt üzenetnek? Az eventlognak? Mit tenne az adott helyzetben Steve Jobs a MOM?
Rábíztam a PSS-re. Ha írásba adják, hogy ez jó, akkor jó lesz nekem is.
Nem mondom, hogy nem inogtak meg. A beküldött adatok szerint olyan pöpec az Active Directory, amilyen csak lehet. Az őscsökevény MTA ráadásul nem is az AD alapján működik, saját adattáblái vannak. Tehát minden észérv azt mondja, hogy tojni rá.
Persze ezt nem adták írásba. Az eltelt időre való tekintettel megint bekértek egy valag adatot. Mire beküldtem, kijött egy újabb EXBPA, így kedvesen megkértek, hogy ismételjem meg az adatgyűjtést. Szóval elvoltunk.
Természetesen próbáltam önállóan is nyomozni, találtam is egy figyelemre méltó levélváltást, de a legacyDN értékek sajnálatosan rendben voltak.
A magam részéről innen már nem igazán bíztam semmiben, de egyszer csak jött egy teljesen vad ötlet a német hapitól. Azt mondta, a hiba oka egy kilométerrel távolabbi Exchange szerveren keresendő. A távolságot nem csak fizikailag kell érteni: bár az Exchange szerverek ugyanabban az organizációban vannak, de AD szinten két különböző szájton, melyek között csak egy harmadik szájton keresztül van kapcsolat, tartományilag pedig nemcsakhogy más domainban üzemelnek, de teljesen más fában is. Azt mondta erre a szerverre az EXBPA, hogy a jogosultsági rendszerében el van vágva az öröklődés. Ezt az üzenetet láttam én is, de csak megvontam a vállam. Igen, el van vágva, valamiért valószínűleg anno el kellett vágni. (Még az se kizárt, hogy pont ennek a case-nek a kezelése során. Legalábbis gyanús, de most nincs kedvem utánakeresni.) Ahogy néztem, elvágáskor rákerült minden jogosultság, tehát pánikra nincsen ok.
Mivel a két szervernek tényleg nagyon halvány köze van egymáshoz, meglehetősen tamáskodtam, amikor ezt az öröklődés elvágást kiáltották ki bűnösnek. De fegyelmezetten beklattyintottam, megvártam, amíg elterjed az AD-ban, mint a kolera, aztán teszt. És itt fehéredtem el: az MTA elindult.

Ez a cikk akkor lenne tökéletes, ha most roppant precíz szikekezeléssel bemutatnám, hogy mi rejlik a megoldás mélyén. De őszintén bevallom, halványlila fogalmam sincs. Annyit sikerült megtudnom, hogy a német srác a regtrace alapján jutott erre a következtetésre – ez viszont megint egy olyan cucc, mely bináris formában gyűjti az adatokat, azaz mezei halandó képtelen értelmezni az outputot.
Ehelyett azt tudom csak mondani Shakespeare kollégával egyetemben, hogy “Több dolgok vannak földön és égen, oh, Horatio, mintsem bölcselmetek álmodni képes”.
És ilyenkor ver ki a víz, ha belegondolok, hogy egy ilyen bonyolult Exchange/AD rendszerbe hány embernek van joga belepiszkálni. És ennyi közül elég, ha csak egy gondolja, hogy nem kell szarozni, csak ide-oda kattintunk néhányat és minden oké lesz.

[Update]
Jó persze, azt észrevettem, hogy miután engedtem az öröklődést, rákerült az ezer éve üzemelő Exchange szerver jogosultságlistájára a nagyon-nagyon távoli tartomány ‘exchange domain servers’ csoportja, read jogosultsággal. De ez valahogy még nem elégítette ki a kíváncsiságomat.

Hülye nevek

Vannak olyanok. Annyira hülye nevek, hogy józan ésszel nem is lehet kitalálni, mi van mögöttük.

Az első példám ahhoz a bizonyos régi szilikáttechnológiai vizsgához kötődik.
Ugyanis megpróbáltam legalább elolvasni az anyagot – de már viszonylag az elején belefutottam egy olyan kifejezésbe, hogy ‘doghouse adagolás’. A porok készülékbe adagolásáról a kézzel – máséval – írott jegyzet több információt nem tartalmazott. Megkerestem pár évfolyamtársamat, de csak annyit tudtam meg, hogy az előadó nem részletezte a dolgot, egyszerűen csak lediktálta.
Én viszont belekapaszkodtam, mint Floki a lábtörlőbe. Próbáltam név alapján kilogikázni. Megkérdeztem idősebbeket, ők sem tudták. Internet, google… ugyan, hol voltak még ezek. Nyomtatott jegyzet? Maximum a holdban. Aztán valószínűleg Buzz Aldrin hozhatott egyet, mert sikerült felkajtatnom egy példányt. Ebből tudtam meg, hogy a roppant tudományosan hangzó szilárdanyag adagolási módszer Jenőt takarja a lapátjával. Komoly.

A másik ilyen kifejezés a ’round robin’ volt. Először tanfolyamon hallottam, még az előző évezredben. Csak néztem nagy gülü szemekkel, de kérdezni nem mertem, mert mindenki más szemmel láthatóan tudta, miről van szó. Vagy csak sokkal értelmesebb képet tudott vágni, mint én. Hiányos angol tudásommal annyit összeraktam, hogy a round az kör, a robin meg vörösbegy… de ebből csak nem állt össze, hogyan lesz ebből redundáns DNS névfeloldás. Azóta persze kupálódtam, megtanultam, hogy az informatikában a ’round robin’ az ‘ad-hoc’ kifejezést takarja, azaz jó magyarosan azt, hogy ‘ahogy esik, úgy puffan’. De hogy ennek mi köze van a ’round robin’ hétköznapi jelentéséhez, mely a ’sokak által aláírt kérdőív’-et jelenti… megint nem tudom.

A harmadik példány még teljesen friss. Exchange 2003 disaster recovery kapcsán olvashatunk olyan módszerről, hogy dial-tone visszaállítás. Első hallásra elsápad tőle még a sokat látott exchange admin is: micsoda… modemen keresztül kell visszaállítani valamit… vagy neadjisten, mobiltelefonról kell sms-ben parancsokat osztogatni? De persze, hogy nem; a névnek megint nincs semmi köze a módszerhez.
Mely nagyjából a következőképpen néz ki.
Legyen egy elszállt Exchange store. Az eredeti mérete – betartva a Microsoft erre vonatkozó ajánlásait – legyen 99.99 GB.
Legyen ez a VIP store.
A CEO legyen teljesen átlagos:

  • 1 perc emailtelenség után bevörösödik a feje,
  • 2 perc után kitör rajta a légiós betegség,
  • 10 perc után sátáni kacagással kezdi kilapátolni a HR ablakán az infomunkások munkakönyveit.

Ezzel szemben a restore rendszer nézzen ki a következőképpen:

  • Az adatbázis visszatöltési ideje másfél óra.
  • Mire megtaláljuk Jenőt, aki tudja, hol vannak a kazetták, megint másfél óra.

Mit lehet ilyenkor csinálni? Igen, dial-tone.

  • Letöröljük az adatbázis maradékait.
  • Felmountoljuk az adatbázist. Nem, nem szedtem be semmilyen tudattágító szert… tényleg felmountoljuk a semmit. Az Exchange2003 ilyenkor lesz olyan kedves, hogy létrehoz egy tök üres store-t, azokkal az adatbázis nevekkel, melyek a store tulajdonságlapján szerepelnek.
  • Lehet telefonálni a vezérnek, hogy működik a levelezés. Igaz, még nem mindenki éri el a régi leveleit, de a visszatöltés folyamatban van. Lehet levelet írni, kapni. A vezér meg fog nyugodni. Látja, hogy az emberek dolgoznak – és azt a betyár mindenit, tudnak a fiúk, milyen hamar működőképessé tették a rendszert!
  • Elindítjuk a visszatöltést a recovery storage group-ba.
  • Ha visszajöttek az adatok, ráküldünk egy összefésülést és hipp-hopp, vissza fognak kerülni a régi levelek a postafiókokba. Hátradőlünk és elégedett mosollyal kiélvezzük… azt a pár percet, amíg a munkaviszonyunk még tart. Ugyanis elég hamar rá fognak jönni kedvenc VIP felhasználóink, hogy nem működnek a szabályaik. Naná. Mivel eltűnt az összes. Ugyanis a merge csak a postafiókok tartalmát másolja, a metaadatokat, szabályokat nem. Az üres adatbázis meg egész konkrétan megszámolható szabályt tartalmazott.
  • Probléma szál sem, a nyúl már a cilinderben van – csak tudni kell, hogyan húzzuk elő. Miután visszajött az eredeti store a recovery storage group-ba, lemountoljuk. Hasonlóképpen lecsatoljuk a VIP store-t is, majd lemountolt állapotban kicseréljük a kettőt – értelemszerűen mindegyiket a megfelelő névre átnevezve.
  • És most már jöhet felcsatolás után a merge – hogy megkapják az ideges fiúk azokat a leveleket is, melyek a visszaállítás ideje alatt keletkeztek.

Jó, mi? De hogy miért dial-tone? A fene tudja.

Részletesebb írás a módszerről Jim McBee blogján.

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.

Link state – hova dugjam?

Life long learning. Ez már csak egy ilyen szakma. Szerencsére.
Jó egy hónapja álltam rá arra, hogy rendszeresen tanulok. A hangsúly a rendszerességen van – tanulni eddig is kellett.
A stratégia a következő: reggel tea felrak, elkortyol, internet átfut (email/feed/link). Utána, amennyiben nyugis nap van, ebédig tanulok. Ha zűrös, akkor csak egy órát. Outlookba jegyzetelek, a végén a levelet hazaküldöm.
Napközben az anyag ülepedik… a vérnyomás meg emelkedik… de ez a természetes.
Este rászánok egy órát és a délelőtt átvett anyagból csinálok egy írott jegyzetet. (Nekem ez jön be – leírni kézzel a vázlatot. Egyetemi vizsgára készüléskor a konyhaasztalunkra készítettem apró betűkkel jegyzeteket. A vizsga előtti napon már úgy nézett ki az asztal, mint egy burda szabásminta: vázlatpontok, nyúlfülek, nyilak. A szép nagy asztalon át lehetett tekinteni az egész tantárgy kapcsolatrendszerét – feltéve, ha a takarítónő nem törölte le közben. De ez igen erősen meg lett neki tiltva.)
Honnan jön a témaválasztás? Több méter könyv gyűlt fel a szekrényemben, ezekkel szép módszeresen haladok. De magunk között szólva, jobban szeretek csapongani – ha a reggeli feed olvasás során találok valamit, szívesen indulok el inkább azon a nyomon.
A napokban futottam rá egy témára és a linkek olyan oldalhoz vezettek, melyet véleményem szerint nem jegyzetelni érdemes, hanem értelmezni, összekapni – lefordítani. És persze elkalandozni. De ha ilyet csinálok, miért ne tegyem a blogban?
Ez merőben újdonság lesz, eddig ugyanis IT témakörben csak szívásokról irkáltam. Dehát mindig azt sulykolják, legyünk proaktívak… nosza.

A téma: routolás Exchange organizációban, azon belül is a link state table környéki problémák kezelése.

Kályha… ahonnan elindulunk: routing group (RG).
Azt gondolom mindenki tudja, hogy az Active Directory leánykori neve Exchange 5.x volt. Itt kisérletezték ki a fiúk a később nagyobb léptékben alkalmazott módszereket. Az összefonódás később is jól látható, az Exchange 200x úgy tapad rá az AD-re mint a kígyók Laookon családjára az ismert szoborcsoporton. Rengeteg átfedés van közöttük és akad analógia is szépen. Egyik ilyen a routing group – site analógia. Nagyjából ugyanaz létezésük oka: információs folyam terelgetése. Site esetén ez a replikáció, routing group esetén pedig a levéltovábbítás. Mindkettőre igaz, hogy egy egységen belül nagysebességű kapcsolattal rendelkező gépeknek illik lenniük – póriasan szólva, az a jó, ha egymásba ér a farkuk.

Kitérő: Azért nem csak a kapcsolat sebessége szabja meg a csoportosítást. Ha mixed módú organizációnk van, és szeretnénk több administrative group-ot is bevezetni, szomorúan fogjuk látni, hogy mindegyiknek külön RG kell.

A routing group létezésének értelme: csoporton belül a szerverek orrba-szájba kommunikálnak egymással (ugye, a nagy sávszélesség) – csoporton kívül viszont adminisztrátor által szabályozott módon, konnektorok segítségével. (Imádom ezt a szót: konnektor… konnektor. Azannya. Plasztikus. Fogom az egyik végét és feldugom az Exchange szerverbe. A másik végét meglengetem a fejem fölött és beleállítom valamibe, legyen az bármilyen alkalmazás. És ezt tessék szószerint érteni: az Exchange mind a külvilággal, mind saját magával legnagyobbrészt különböző konnektorokon keresztül kommunikál.)

No, tehát vannak routing groupok, melyeket konnektorok kötnek össze. Nincs megkötve, mennyi; nincs megkötve, hány bridgehead szerver lehet. Szabad a pálya. Ellenben minden routing groupban lennie kell egy routing group masternek. Ő az óvónéni. Ő tud mindenkiről mindent; ő terelgeti a leveleket konnektorról konnektorra (egy kis dombra lecsücsülünk, csüccs); ő rak rendet, ha kitör a balhé. Nem fontos, hogy ő legyen a bridgehead – de fontos, hogy tudjon mindenről.
Mi is ez a minden? Nos, a konnektoroknak állapotaik vannak: ezeket hívjuk link state-nek. És van egy táblázat, amelyikben a routing groupok összes link state információja megtalálható: ez a link state table.

Hosszú, de legalább körülményes bevezetőm végén eljutottam végre ahhoz a vadhoz, melynek természete képezi leginkább ezen cikk mondanivalóját. Huh.

Tudjuk, hogy az optimális route útvonalhoz az RG master a következő információkat használja fel: a konnektor költsége, az üzenet típusa, a különböző tiltások. Logikus, hogy ezeknek szintén bent kell lennie a link state táblában – amellett, hogy a konnektor éppen Up vagy Down.
Ha valaki el akar gyönyörködni egy ilyen táblázatban, javaslom, próbálja ki a winroute programot. Aki nem akar elgyönyörködni benne, az ráfaragott, mert a leírt módszerek közül elég sokban kell használni a programot – és higyjétek el, jobb gyönyörködve, jó hangulatban bogarászni, mint fásultan.

Felmerülhet a kérdés, hogy honnan fog tudni mindenről az RG master? Természetesen a member szerverek folyamatosan tömik feljelentésekkel.

  • A member szerveren lévő levélkezelő mechanizmus, az ún Advanced Queue (önállóan megérne egy cikket) rányalja a kimenő levélre a legközelebbi hop címét. Az infót a lokális link state táblából veszi.
  • A levél visszapattan.
  • A member szerver vár max. 10 percet majd feljelenti a konnektort. Jól.
  • Az RG master down-ba teszi a konnektort a központi link state táblában majd szétküldi azt a member szervereknek.
  • De a member szerverek nem nyugszanak. Sutyiban folyamatosan pingetik a ledőlt konnektort.
  • Tegyük fel, hogy a konnektor visszatér a harcmezőre. A member szerverek, mivel pingetik, észreveszik, boldogan üdvözlik és közlik az örömhírt az RG masterrel.
  • Az RG master blazírtan újra módosítja a link state táblát és ismét szétküldi.

Az egész kommunikáció a 691-es TCP porton történik. Emellett játszik még a 25-ös is – de ez az Exchange-ben mindenhol játszik, lévén ez az SMTP portja. A routing információk küldözgetéséért a Routing Engine Service, röviden RESrvc felel. (Gyakorlati jótanács: ha újra kell indítani, akkor praktikusabb az IISadmin szervízt piszkálni – ez ugyanis újraindítja az SMTP szolgáltatást is, praktikus sorrendben.)

Mi van akkor, ha pont az RG master dől ki a sorból? Értelemszerűen minden member szerver a lokális link state táblát használja, függetlenül attól, milyen változások történnek a nagyvilágban. Aztán egyszer csak visszajön az RG master – akár megjavítják, akár újat húznak fel, akár kinevezik valamelyiket. (System manager, RG, Members, Server, Set as master) Az új főnök körbenéz a nagyvilágban, gyorsan begyűjti a lokális link state táblákat, lekezeli a feljelentéseket, szétküldi a jó táblákat… röviden szólva asztalra csap és gatyába rázza a macska nélkül cincogó egereket. (Gyönyörű.)

Láthatjuk tehát, hogyan működik egy egészséges rendszer. (Ez olyan, mint az ideális – nem létezik. De állandó cél.) A működés ismerete pedig már fél siker a hibajavításhoz.
Milyen eszközöket fogunk használni:

  • Winroute segédprogram. (Igen, mondtam, hogy meg kell szeretni.)
  • Felemelt logolás.
  • Józan ész. (Valahonnan időben szerezzük be.)

A logolást az Exchange System Managerben lehet állítani, a megfelelő objektumokon. Legalábbis a tankönyvek szerint. Érdekes módon, amikor nagy szar van, mindig bele kell turkálni a registrybe és még feljebb csavarni a logolást. (Az ESM csak 5-ös szintig engedi állítani – pedig a legerősebb a 7-es szint.)
A felcsavarás a következőképpen történik: a registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services ágában megkeressük a minket érintő szolgáltatást, azon belül leásunk a Diagnostic menübe, megkeressük a minket érintő eseménycsoportot és 7-re állítjuk az értékét.
Arra azért készüljünk fel, hogy ilyenkor olyan 70 szerzetesnyi sebességel íródik a kódex log.

Nem beszéltem még egy érdekességről. Ha elindítjuk a Winroute programot, láthatjuk, hogy minden routing groupnak verziószáma van, [major.minor.user] formátumban.
Meglehetősen magáért beszélők a nevek, de érdemes egy-két apróságot megemlíteni róluk.
Átfogóan nagy – major – változás viszonylag ritkán történik. Ez alatt leginkább olyan változásokat kell érteni, amikor az AD nyúlkál bele az Exchange lelkivilágába. (Megjegyzés: ha a major index 0, az azt jelenti, hogy nincs link state táblás ökörködés -> azaz vagy csak egy routing group van az organizációban, vagy az illető routing group Exchange5.5 alapú – a jó öreg GWART.)
Közepes – minor – változás általában a konnektorokhoz kötődő változást jelent.
A legutolsó szám – user – változását mindenféle szutyok apróságok okozhatják: WMI piszkálta meg az RG mastert, megváltozott a routing group tagsága, át lett nevezve a routing group, elköhögte magát a szerverszoba egere, stb.

És most akkor lássunk konkrét hibajelenségeket és azok lekezeléseit:

1. A member szerver nem látja mesterét

Bizony, ez baj. A fentiek alapján sejthetjük, hogy ilyenkor a lokális link state tábla dolgozik, valamilyen őskori adatokkal.
A jelenséget könnyen felismerhetjük, elég a Winroute-ban a piros X-ekre koncentrálnunk. Ott találjuk, közvetlenül a szerver(ek) neve(i) mellett.
Mik okozhatják? Csupa triviális dolgok:

  • A Routing Engine Service nem fut valamelyik érintett gépen. Vagy fut, csak nem jól.
  • Egy gonosz firewall blokkolja a 691-es portot. Ezt telnettel tudjuk ellenőrizni.
    Emellett konkrétan azt is meg tudjuk nézni, hogy mi a helyzet a 691-es porttal a szervereken. A ‘netstat -a -n’ parancs megmutatja, mely portjaink nyitottak és merrefelé. Member szerver esetén látnunk kell egy kapcsolatot az RG master felé – RG master esetén látnunk kell egy-egy kapcsolatot minden member szerver felé. (Pontosabban, nem csak egyet, két szerver több szálon is kapcsolódhat.)
  • Okozhat problémát a computer felhasználó hibás autentikációja is. (Logikus – ilyenkor a számítógép kiesik a haveri körből.) Érdemes átnézni az eventlogot. Ugyanitt fogjuk megtalálni a transzport hibára utaló jeleket is. (Event kód: 961/962)
  • Elveszhet a bűnös szerver ‘Send as’ jogosultsága. (Elég cifra jogosultsági rendszerben vannak a szerverek; a domainprep létrehoz nekik néhány csoportot és ezekre beállít egy default jogosultságot. Elég könnyű ezt a rendszert felrúgni – bőven elég, ha átrakjuk a csoportokat egy másik OU-ba. Tesztelve.)
    A nyomozáshoz a Microsoft a Regtrace programot ajánlja. Én is ezt tenném a helyükben, tekintve, hogy ez egy nagyon praktikus program – nekik. Mezei halandó sajnos nem tud vele mit kezdeni. (Szépen le van írva, hogyan kell elindítani, hogyan kell paraméterezni, egyáltalán hogyan monitorozza a program a történéseket, miközben reprodukáljuk a hibát, szépen le van az is írva, hol találjuk az eredményként kapott bináris fájlt és hogyan kell azt elküldeni a PSS-nek visszafejtés céljából.)
  • Lehet, hogy a szerver rossz nevet használ a bemutatkozáskor. Elismerem, ez annyira azért nem triviális ok. A szerverek az ún. ServerPrincipalName (SPN) értékkel azonosítják magukat a routing groupban. Ez az érték a szerver Network Adress attribútumának ncacn_ip_tcp változójában tárolódik, megtekinteni illetve módosítani ADSIEdit-tel vagy LDP-vel lehet. Kicsit háklis banda ez a routing group, csak akkor fogadják el a bemutatkozást, ha FQDN formájú a név. Netbios név, IP cím nem megfelelő. Olyan ez, mint a nyakkendő az elit mulatókba.
  • Az, hogy a többiek nem ismerik fel a bűnös szervert, sokféle okból következhet. Lehet jogosultsági hiba, lehet bemutatkozási hiba – és lehet Kerberos autentikációs hiba, mondjuk egy lejárt computer jelszó miatt. Ekkor célszerű az NLTEST segédprogit használni. (Ez igaz általánosan is, minden olyan esetben, amikor netlogon hibára gyanakszunk.) A program használatáról van egy jó leírás. Röviden annyi, hogy el kell indítani a megfelelő paraméterrel – mely paraméterek egy szép nagy táblázatban találhatók és arra vonatkoznak, hogy mire vagyunk kíváncsiak – majd újraindítjuk a Netlogon szolgáltatást és megnézzük, mi került a %windir%\debug\netlogon.log fájlba.
  • Természetesen DNS. Ezt talán mondanom sem kellett volna. Ha a szerverek eltérő tartományokban vannak, meg kell nézni, rendesen megy-e a névfeloldás. A magam részéről megnézném akkor is, ha azonos tartományban vannak. Fontos, hogy a virtuális SMTP szerveren található FQDN megegyezzen a DNS-beli FQDN-nel.
  • Legvégül érdemes elgondolkodni, nem vezettünk-e be mostanában valami elkefélt GPO-t, mely esetleg belepiszkálhatott a korábban részletezett folyamatba.

2. RG mesterek háborúja

Megjelenik a sötét oldal.
Egy routing groupban az az RG master, akiről a szerverek fele+1 szerver azt állítja. Ezt a member szerverek ún. link state attach információk küldözgetésével beszélik meg. Értelemszerűen egy szervernél ő maga lesz a főnök – azaz alaphelyzetben mindig az elsőnek telepített szerver az RG master. Az is marad, amíg az adminisztrátor másképp nem rendelkezik.
Mikor tör ki a háború?

  • Például akkor, ha az adminisztrátor úgy léptet elő RG mesterré egy gépet, hogy az öreg mestert nem lépteti vissza.
  • Az egyik member szerver megőrül és hamis információkat kezd terjeszteni.
  • Hálózati hibák következtében nem érnek célba a link state attach információk, miközben főnökváltás történt.

Mi lehet a teendő? Először is megvizsgáljuk a hálózatot, mennyire atombiztos. Elérhetők-e azok a bizonyos 691/25 portok? Megy-e az AD replikáció? Nem rágta-e el a patkány a vezetéket?
Másrészt magunkba szállunk és végiggondoljuk, nem töröltük-e pusztán szórakozottságból azt az Exchange szervert, amelyik eddig az RG master volt? Esetleg nem léptettünk-e elő egyet úgy, hogy még a régi is megvan?
Ha ez utóbbi esetek egyike történt, akkor az ADSIEdit vagy LDP programokkal gyorsan korrigálhatunk, az üzemzavart meg ráfoghatjuk a napfolt tevékenységre. (Itt található egy írás, hogyan állítható vissza egy véletlenül kigyapált routing group. Azért ne próbáljátok ki éles rendszeren.)

3. Van olyan routing group, amelyik nincs

Felmerülhet a kérdés, hogy ha nincs, akkor hogyan látjuk. Nos, például a Winroute segédprogramból. Mutatja, hogy itt kérem van egy routing group, de a fene se tudja, hogyan hívják és mi ez.
Mondhatnánk, hogy a francot sem érdekli, nem kér enni. Csakhogy ott van. Érvényes routing információkkal. Hogy neki vannak konnektorai. Balszerencsés esetben egészen olcsók – és ilyenkor ebbe az irányba próbálnak menni a levelek. Mely irány nem létezik.
Nyilván törölni kell… de hogyan? Hiszen nem létezik!
Farkába harapott a kígyó.
Ravasz trükkök vannak a rendrakásra.

  • A legelső, hogy megnézzük, olyan felhasználóval vagyunk-e belépve, akinek legalább olvasási jogai vannak az AD konfigurációs névterében? Ha olyan a felhasználó, be tudott-e rendesen lépni? Ha belépett, eléri-e a konfigurációs névteret? Tudom, triviális… de egy autentikációs hiba miatt egyszer kis híján megőrültem egy hasonló szituációban.
    Általában is az egyik legfontosabb hibafelderítési lépés meggyőzödni, hogy egyáltalán fennáll-e a hiba… nem az észleléssel van-e inkább gond?
  • Nos, benne vagyunk az Atyauristens csoportban, közvetlenül az RG master gépen futtatjuk a Winroute-ot, mégis látszik, aminek nem lenne szabad látszódnia. Erre mondják azt városiasan, hogy kaki van a ventillátorban. (A póriast most inkább hagyjuk.)
    A helyzet az, hogy valószínűleg egy törölt routing group-ra vonatkozó bejegyzés beragadt a link state táblába – és a RESvc képtelen kitörölni. Az egyetlen megoldás a tabula rasa – kezdjünk mindent előlröl. Választhatjuk azt is, hogy újratelepítjük az összes Exchange szervert (nemröhög – a Microsoft eszköztárában szerepel ez a lehetőség is), de szerencsére van egy egyszerűbb megoldás is: a bűvös újraindítás. Némi kényelmetlenséget okoz, hogy az organizáció összes szerverét kell egyszerre újraindítani, úgy, hogy először mindenhol az RG master gépek álljanak fel. Kényelmetlen, de ha worldwide organizációnk van, akkor itt a lehetőség néhány potya repülőjegyre.
  • Az előbb hazudtam, de csak a drámai hatás kedvéért. Van egy másik lehetőség is: felhergelhetjük a REMonitor segédprogramot, hogy injection módban működjön. Erről igen jó cikket írt az Exchange gárda, én itt csak összefoglalom.
    Először a rossz hír: a program nem tölthető le szabadon, a Support-tól kell igényelni. Ha megvan, akkor első lépésben be kell állítani a futtatásához szükséges jogosultságot. A fiúk elég sokat vacakolnak ezzel, végül arra jutnak, hogy a legegyszerűbb, ha trükkös módon a local system account nevében futtatjuk. Ez – gondolom – ismerős. Beidőzítünk egy command prompt-ot és az a local system account nevében fog elindulni. Nos, itt csak annyi a probléma, hogy távolról ütemezve a taszkot, az a konzolon fog promptot adni. (Windows2003 esetén no problemo, az ‘mstsc /console’ kihúz a bajból.) Azért nálunk valamivel mások a viszonyok… feltételezem, minden Exchange adminisztrátor azzal kezdte a tevékenységét, hogy az Atyauristen felhasználónak visszaadta a “Send as”/”Receive as” jogokat – ez meg éppen elég a program futtatásához. (Jaj, ne üssenek… nem mondtam semmit…micsoda?… három év vasban?…)
    Ha rendeztük a jogosultsági matyit, akkor végre elkezdhetünk dolgozni. Bemásoljuk a progit a bin könyvtárba, elindítjuk. Kedvesen közli, hogy mely fázisnál jár, mit talált… majd vége.
    Mit is csinált?

    • Ha talált beazonosíthatatlan routing group-ot, törölte belőle a szerverek és konnektorok bejegyzéseit.
    • A routing group-hoz tartozó névterek címeibe belebiggyesztette a ‘deleted’ kifejezést.
    • A major indexet megnövelte eggyel.

    Ezzel sikeresen elérte, hogy egyrészt efelé a routing group felé soha a büdös életben nem fog levél kóvályogni, másrészt a link state table is lecsökkent valamelyest – ami nem hátrány nagyméretű organizációk esetében.
    Amit viszont nem ért el, az az, hogy nem tűnik el a rosszindulatú routing group bejegyzés a táblából. Sajnálatosan ezt csak az újraindításos módszer biztosítja.

4. Egy ledőlt konnektor üdének, frissnek látszik

Ilyesmi is előfordulhat. Mondanom sem kell, elég ciki, amikor szembesülünk a ténnyel, megtekintve a Winroute listáját.
Pedig simán előfordulhat.

  • Olyan konnektorunk van, amelyiknél bizonytalan a hídfőállás létezése. Akkor fordulhat ilyesmi elő, ha a konnektorunk pl. DNS-t használ ahhoz, hogy a következő hop-ot meghatározza. Tipikus példa erre egy SMTP konnektor, amelyik nem smarthost-hoz kapcsolódik.

    Megjegyzés: Amikor azt írom, hogy SMTP konnektor, mindig kicsit zavarban vagyok – mert eszembe jut, mennyit agyaltam anno, hogy mi is az a virtuális SMTP szerver és mi is az az SMTP konnektor és tulajdonképpen milyen viszonyban is vannak ezek? Fóti Marci gondolatát beépítve imhol egy plasztikus kép: van az SMTP szolgáltatás, mely tetszőleges számú virtuális SMTP szervert képes üzemeltetni. Az SMTP konnektor pedig tulajdonképpen a virtuális szerverekre vonatkozó SMTP policy.

    De akkor is előfordulhat ez a jelenség, ha az ún Routing Group konnektornál (RGC) a forrás bridgehead rovatba az <any> opciót hagyjuk bent. (Nem akarok most kitérni az egyes konnektor típusokra, mert a cikk lassan kezd fárasztó lenni. Nekem legalábbis meglehetősen.)

  • Smart host esetén sem vagyunk teljesen biztonságban, ha nemrég állítottuk át a távoli bridgehead szerver paramétert.
  • A konnektorunk Exchange5.5 verziójú konnektor vagy a konnektor egyik hídfőállása 5.5-ös szerver. Már tudjuk, ekkor nem játszik a link state table.

5. A konnektor bungee-jumping-ot játszik

Azaz meglehetősen nagy frekvenciával hol ledől (down), hol feláll (up). Lehet, hogy ez egy kellemes szórakozás a konnektor számára, de elég sokba kerül az Exchange rendszernek. Ugyanis a konnektor minden egyes állapotváltása bősz kommunikációt indít el a member szerverek és az RG master között, mire berendezik a megváltozott állapotnak megfelelő link state táblát. Aztán mire befejezik, az a hülye konnektor megint ugrik egyet.
A szóbajöhető okok:

  • Zavar az erőben, a network hülyéskedik. Netmon, vagy Ethereal… izé Packetyzer. Kinek melyik a szimpatikusabb.
  • A konnektorok alatt dübörgő protokoll bolondul meg. Összeakadnak az X.400 protokoll rétegei. Egymásba gubancolódnak az SMTP protokoll alsóbb rétegeiben lévő lábai. A Microsoft szerint ez leginkább a külső fejlesztésű implementációknál fordul elő. Naná.
    A megoldás ebben az esetben is Netmon és barátai.

Illetve létezik egy átmeneti megoldás, úgynevezett körbedolgozás. Van egy patch… mely valamit csinál. Sajnos, hogy mit, az nem derül ki. Csak az, hogy ilyen esetekben tegyük fel.
Pontosabban, eredetileg arra találták ki, hogy amikor Exchange5.5-ről frissítettünk Exchange2000-re és a nagyméretű rendszerinformációs forgalom (ORG_INFO) megakadályozza a levélküldést a lassú vonalon, akkor toljuk a képébe a foltot. Feltételezem, valahogy cseppekben adagolja a változásokat.
Élesebb szemű olvasók valószínűleg észrevehették, hogy itt nem ez a szituáció forog fenn. De ez egy remek folt, most is használhatjuk, csak bele kell túrni egy kicsit a registry-be. (Már vártam.) A HKLM\SYSTEM\CurrentControlSet\Services\RESvc\Parameters alatt kell létrehozni egy AttachedTimeout nevű dword kulcsot, majd értékének beírni egy szimpatikus számot 1 és 604800 között. Nem mondhatjuk, hogy nem kaptunk elég teret fantáziánk kibontakoztatásához.

Nos, a végére értem.
Akit ennél is mélyebben érdekelnek a routolási furfangok, itt talál egy remek letölthető könyvet a témáról.

REMonitor

Egy újabb rémálommal kevesebb.
Emlékszem, amikor először találkoztam ilyesmivel, nem hittem a fülemnek.
Egy nagyobb migráció után Exchange routing group-okkal zsonglőrködtem egy meglehetősen nagy organizációban. A végén minden beállt abba az állapotba, amilyenben lennie kellett. Szerintem.
Csak éppen nem tűnt el egy kitörölt routing group – emiatt a levelek véletlenszerűen félrementek. Jó lett volna ténylegesen is megszabadulni a rossz routing group-tól… de még flex-szel sem tudtam eltávolítani. Egy idő után feladtam, call PSS. Azt mondták, igen, elő szokott ilyesmi fordulni, a routing információk cache-ben vannak és néha beragad valami szemét. Ki kell üríteni a cache-t.
– Oké – mondtam – csapjunk bele… hogyan kell?
– Nagyon egyszerű – mondták – az összes szervert le kell állítani egy időben.
– A routing groupban?
– Nem. Az egész organizációban.
Ekkor ültem seggre. Nem kis munka volt megszervezni, hogy minden helyszínen legyen egy ember, aki adott jelre (mobiltelefon) lekapcsolja a szervereket majd adott másik jelre visszakapcsolja. Távoli újraindításról szó sem lehetett, mert addig mindegyik gépnek kikapcsolva kellett lennie, amíg a routing master Exchange szerver fel nem állt.
Viszont ettől tényleg megjavult a levelezés.
Azért úgy belegondoltam, hogy mondjuk egy multicégnél, ahol garmadával vannak szerverek különböző kontinenseken, mekkora meló lehet egy ilyen akciót megszervezni.
Valószínűleg belegondolt a Microsoft is, mert kihoztak végre egy eszközt, mely kezeli ezt a problémát. Az a neve, hogy Routing Engine Monitor (REMonitor) és az Exchange Team szépen le is írja, hogyan kell kezelni. A logika azt mondatja velem, hogy nagyon jó eszköznek kell lennie, ha ennyi időbe tellett a kifejlesztése.

A GC sem mindenható?

Őszintén szólva, még mindig tátva van a szám. Ettől a cikktől maradt úgy… pontosabban egy új, a GC-kre vonatkozó információtól.
A cikk egyébként több okból is nagyon jó. Meg lehet pl. tanulni belőle, hogyan tudom gyorsan megállapítani, mely GC-ket lát az Exchange szerver. (Pontosabban a DSACCESS szolgáltatása, mely a GC-XCH kapcsolatért felel.) Élvezetes a gondolatmenet, ahogy Jasper felgöngyölte a problémát. És megtudhatjuk, hogy megint a Public Folderek a bűnösek. És hogy a GC-k sem tudnak mindent.
Számomra ez utóbbi volt az igazán megdöbbentő:

It turns out that Exchange does not always use the local GCs. For certain specific security related user attributes like tokenGroups and tokengroupsGlobalandUniversal (used to determine what security groups a user is a member of and therefore what permissions s/he has to secure resources such as public folders). Exchange MUST query a DC that is authoritative for the user’s home domain, which will likely be an out-of-site DC—in this case it happened to be a DC in Australia. This behavior was introduced around the Exchange 2000 SP2 time frame to address an issue where users from remote domains (sibling or parent) were denied access to public folders even when the security groups they were in should have allowed them access. Pre-SP2 we had made the false assumption (in the product) that a local GC can service ALL queries that Exchange issues. A local GC can (and should) service MOST queries in a well designed multi-site AD environment.

Eltekintve attól, hogy erősen hiányzik egy ige a második mondatból, kihámozható, hogy Jasper szerint a GC adatbázisok nem tartalmazzák azokat az információkat, hogy a felhasználók mely biztonsági csoportoknak a tagjai. Ez alapjaiban rendítette meg az elképzelésemet a GC-k működéséről. De tényleg. Hiszen pont azért találták ki, hogy gyorsan, mindenféle DC abuzálás nélkül el lehessen dönteni, hogy Géza hozzáfér-e egy erőforráshoz, vagy sem?
A többi már csak hab a tortán; hogy Exchange SP2 előtt ilyenkor meghalt a PF elérés, SP2 után viszont megpróbálja a világ másik végén lévő helyi GC-t használni. Aztán van amikor ezzel több kárt okoz, mint hasznot.

Érik a fekete

Nem, nem cseresznye. Szeder. És nem be, hanem – ha rajtam állna -, akkor ki.

Már az ókori görögök is tudták, mi a jó nekik – még a legelvetemültebb kutatások során sem találtak a régészek semmi nyomot, hogy őseink használtak volna valaha is Blackberry mobil üzenettovábbító rendszert.

Az ügyfél nem volt ennyire elővigyázatos. Neki_ilyen_kellett. A magyarázat egyszerű: habár már telepítve van két darab Onebridge SyncServer (mindegyik organizációhoz egy-egy), de ezek csak PDÁ-val tudnak szinkronizálni. (Kutatásaim szerint valahogy össze lehet lőni Blackberry-vel is, de ebbe most ne menjünk bele.) És amikor a vezig Amerikában járt és az összes CEO előrántotta a kütyüjét, tízből kilenc Blackberry volt. Kinézték szegényt a PDÁ-jával.

Uccu, megvették az egészet tokkal-vonóval. Rám várt a nagy feladat, hogy beüzemeljem.
Az első olvasgatások után nem tűnt túl bonyolultnak. Volt telepítési kézikönyv is – mi más kellhet még? Idő, türelem… novemberben mindezek még megvoltak.

Feltelepítettem a Windows2003 szervert, összeszedtem minden szükséges komponenst. Rengeteg volt, nem véletlenül kézikönyv formában adták mellé a telepítési leírást. De végül tényleg összejött minden.
Aztán a sokadik oldalon azt mondta, hogy telepítsük fel rá az Exchange System Managert. Csakhogy a becélzott organizáció még 5.5-ös. Az Exchange Admin meg nem ment föl Windows2003 szerverre, de nem ám.
Újabb kör a Dataplexbe, Windows2000 szerver felugrott – persze ehhez teljesen más garnitúra lószart kellett leszedni. (IE6, CDO patch, ADODB, stb…) De minden munka elfogy egyszer (vagy nem?) és eljutottam odáig, hogy aktiváljuk a kézi egységet. Vállalati aktiválás elindul, aztán vár. Vártam vele én is. Azóta is ott várnánk együtt, ha a qrtafarkú malac ki nem túrt volna.
Jöhetett a szokásos vajákolás. Logok nézegetése, önmarcangolás (biztos, hogy mindent jól telepítettem?); ilyen kísérlet, olyan kísérlet. Ügyfél kapcsolattartója megpróbálta a lehetetlent: támogatásért folyamodott a T-online-hoz, aki spec. a rendszer eladója volt. Jöttek is az ötletek: ne a wireless aktiválással sportoljunk, hanem a drótossal. Dugjuk fel a kütyüt egy PC-re és indítsuk el úgy a folyamatot. Ehhez lazán bele kellett durrantani a tűzfalba egy páncélököllel, de nem probléma. És már a tűzfalas emberünk is felgyógyult.Viszont az aktivizálás így sem ment. Jött a következő zseniális ötlet: dugjuk fel a kézi egységet közvetlenül a szerver USB portjára. Mert egy szervernek ilyesmi csak úgy van. A vicces az, hogy ez spec desktop gép volt, tehát véletlenül pont volt neki USB ivarszerve. Ekkor egy kicsit rettegtem, hogy ez a módszer _nehogy_ működjön: ebben az esetben ugyanis minden készülék aktiválásakor villamosozhattam volna a Dataplexbe. De a modern technikában lehet bízni: ha eddig sehogy sem működött az aktiválás, akkor ezzel a módszerrel sem produkált meglepetést.
Közben az ügyfél átrágta magát a T-online védelmi vonalain (CRM, te drága) és eljutott egy szakemberig. Az első kérdés az volt, eltávolítottam-e az Outlook-ot. Nem is volt rajta. És az Outlook Express-t? Izé… nem. Hol is van ez leírva? Sehol. De tapasztalat, hogy nem lehet fent.
Jó, szedjük le. Bár az emlékeimben úgy rémlett, hogy ez össze van nőve az Internet Explorer-rel és annyira masszív részei az operációs rendszernek, hogy csak ördögűzéssel távolíthatók el. Naív módon először a Microsoftnál néztem szét.
Most mondja azt valaki, hogy a fiúknak nincs humorérzékük. A következő KB cikken órákig röhögtem.

Cím:
Nem tudjuk leszedni az Outlook Expresst Windows2000 alatt.
Jelenség:
A Windows2000 helpjében leírt módon nem tudjuk eltávolítani az Outlook Expresst.
Ok:
A help fájl hazudós.
Megoldás:
Nem tudod eltávolítani az Outlook Expresst a Control Panel Add/Remove Programs segítségével.

Gyönyörű…
Aztán persze megtaláltam az igazi KB cikket is, illetve ennek különböző, kevésbé aggódós változatait. Mindenesetre elég durva munkának igérkezett, egy csomó könyvtárat, registry kulcsot és rendszerfájlt kellett kigyilkolni, megküzdve közben az állásait elkeseredetten védő Windows File Protection szolgáltatással.
Illetve első körben nem tudtam megküzdeni vele, ugyanis nem dobta fel a megjósolt ‘Uramatyám, mit csinálsz’ ablakot. Ehelyett gondolkodás nélkül visszarakta a dll-eket, még akkor is, amikor a dllcache-ben töröltem és a telepítőkészlet a fasorban sem volt. Nem részletezem, mennyit őszültem közben, a megoldás végül az lett, hogy oda kellett menni fizikailag a szerverhez, barackot nyomni a buksijára és konzolról törölni a rendszerfájlokat. Ekkor már feldobálta a WFP a fehér zászlókat én pedig könyörtelenül legéppisztolyoztam a követeket.
Jöhetett az újabb aktiválási kísérlet. Nem koronázta siker.
Ezután lépésről lépésre végigmentünk a folyamaton és kiugrott, hogy bizony az Exchange organizáció nem érhető el az internet felől. Bizony-bizony, ez egy ilyen organizáció: az ügyfél, aki egy nagy multi hazai leánya, ezen keresztül tartja a kapcsolatot Anyucival. Ja, sóhajtott fel a support legény, akkor ez nem is fog menni. A központi Blackberry server e-mailben küldi el a tanúsítványt a szinkronizálandó postafiókba. Biztos? Igen. Le is írnád? Persze.
Ez után a levél után az ügyfélnél egyes emberek napokig csak egy irányba tudtak menni. A vezig ugyan egy nagyon kedves ember, de ha nem kapja meg a játékát, roppant kedvesen tudja ki is rúgni az embert. (Olyan átmenet Mr Gatto és Mr Teufel között.)
Persze jött a felelős keresése. Én széttártam a kezem: a dokumentációban erről a kitételről egy szó sincs, nekem meg eszembe sem jutott, tekintve, hogy a konkurrens Onebridge simán veszi ezt az akadályt. A T-online meg elfelejtett szólni erről az apróságról; hja, mindenre ők sem gondolhatnak.
Az ügyfél roppant szerencséjére éppen folyik egy másik projekt is. Az anyacég átrendezi sorait és az egész 5.5 organizációt átmigrálja egy E2k3 környezetbe. Ergo nekünk is meg kell lépnünk egy hasonló migrációt, velük egyeztetve. Történetesen az ügyfélnek már van egy E2k3 organizációja, tehát mindösszesen annyi a dolgom, hogy az 5.5 organizációt be kell migrálni az E2k3-ba, azt pedig konnektorokon, DNS-en és MIIS-en keresztül összekötni Anyucival. Bagatell.
De ha ez lemegy, akkor lesz egy olyan organizáció, amelyikben landolnak az anyacég levelei és amelynek lesz Internet kijárata -> ergo bele lehet kötni a Blackberry-t -> ergo Mr Vezig legközelebb nagy arccal elő tudja majd rántani a handheldet az USÁ-ban. (Bár, ahogy most mennek a dolgok, lehet, hogy addigra már pont a többieknek lesz PDÁ-ja.)

Ehhez viszont nyilván újra kell telepíteni a Blackberry szervert, immáron Windows 2003 szerverrel.
A két projektet simán lehet vinni egymás mellett is, így egyszerre telepítettem a két kulcsszervert. (Lásd itt.) Érdekes nap volt.
Most arra számítasz, hogy egy ilyen bonyolult folyamatban milyen összetett szívásokról fogok írni. Nos, nem. A következő szívás nagyon egyszerű, de annál hatásosabb volt. Dönci – a korábban már emlegetett páncélszekrény – azóta őrzi a lábnyomaimat. Meg a harapásmintámat.
Újratelepítés. Eljutottam odáig, hogy partícionálás. Ugye addig volt egy C: – system és boot partíció egyben; emellett egy D:, melyen közel 2 GB, nehezen összevadászott telepítőanyag figyelt. Én csak a C: partíciót terveztem újrahúzni. Igenám, de a telepítésnél feljövő menüben fel volt cserélve a két partíció betűjele! Ha meg akartam őrizni a telepítőkészletet, akkor csak a másik partícióra tudtam telepíteni, ekkor viszont az eredeti D: – amelyik most át lett nevezve C:-nek – lett a boot partíció (amelyiken a system van); míg az eredeti C: – amelyik most át lett nevezve D:-nek, lett a system partíció (amelyikről bootol a rendszer.)
Tudtok követni? Mert most kezdődik igazán a keverés.
Hogy véletlenül se tudjak hibázni, mindkét partícióra felmásoltam a telepítőkészletet. Új telepítés, a partíciók megadásakor letöröltem a D-t, a C-re tettem a windowst. Ekkor egy partíciót kaptam a telepítés után – csakhogy ez volt a nagy és a másik, a D: lett a kicsi. Nekem viszont pont fordítva kellett. Semmi gond, létrehoztam egy kis partíciót, átneveztem X-re, átmásoltam rá is a telepítőkészletet és újratelepítettem a windowst. A partíciók megadásakor a régi C-t (amelyik most egyszerre volt boot és system is) letöröltem és meglepetten konstatáltam, hogy az általam X-nek nevezett partíciót E-re nevezte át. A telepítés lefutott, lett rendesen C: partícióm, egy nagy büdös partícionálatlan rész és valahol a diszk végén egy E: partíció. Amelyikre ez a szerencsétlen nyáladzó elmebeteg rátette a system partíciót.
Aki esetleg elvesztette a fonalat, most jön a visszacsatlakozási pont.
Ennek a büdöslábú operációs rendszernek nem lehet megmondani, hogy telepitéskor ne bántson egy már meglévő partíciót. Ha már van egy partíció és létrehozok egy másikat, hogy arra települjon, akkor automatikusan mindkettore telepíti az operációs rendszer egy részét (system/boot partíciók). És nyilván ezeket a partíciókat utána már nem lehet bántani.
Két választási lehetőségem volt:
– valami unattend szkriptes matyival megmondom neki, ki legyen a system és boot partíció,
– vagy a 2GB adatot hálózaton keresztül átnyomom egy másik gépre, majd mindkét partíciót törlöm. Telepítéskor pedig csak egy partíciót adok meg, így nem tud a nyomorult variálni.
Ez volt a gyorsabb, ezt választottam. Szerencsére nem jött reklamáció szolgáltatás lassulásról.
De akárhogy is nézem, megint ugyanaz a történet: egy MS termék megint azt hisz magáról, hogy ő a kurva okos és nem, az istennek sem engedi, hogy valami kósza admin belepofázzon. Ha két partíció van telepítéskor, akkor külön lesz a system és a boot. Ha úgy gondolja jónak, akkor a partíciókat is átnevezgeti. Mindenkinek pofabe.
Amikor először futottam bele ebbe, akkor azt hittem, biztosan én voltam figyelmetlen.
De nem.
Szégyen.

Na, mindegy, az operációs rendszer felment. Egymás után négyszer is. Visszakerült a jó öreg Windows 2003 szerver.
És ennek már volt egy hatalmas előnye. Amikor másnap eszembe jutott, hogy nem gyaktam ki az Outlook Expresst, akkor már nem kellett kimennem ismét a Dataplexbe, tekintve, hogy ennek már van mstsc /console üzemmódja. Kis lépés az emberiségnek, nagy lépés egy aggresszív klímától torokgyíkban szenvedő adminnak.
Mondjuk a biztonság kedvéért rákerestem, nem változott-e valami a gyilkolászással kapcsolatban. És igen, változott. Azt írták – már fogalmam sincs, hol -, hogy a Windows 2003 alól sehogyan sem lehet eltávolítani az OE-t. Depressziós lesz, kardjába dől, zsúfolt buszon felrobbantja magát.
Ugyan. Mivel más választásom nem volt – a T-online veszettül ragaszkodott hozzá, hogy ez a remek, XXI. századbeli program nem képes együttműködni egy évek óta masszív Windows rendszerkomponenssel – szóval kénytelen voltam kipusztítani a dll-eket. Bár a WFP bedobott még egy apró trükköt – W2k3-nál a Search már nem keres a dllcache könyvtárban -, de terminátorként megkerestem a menekülő fájlokat és nem volt kegyelem.
Nyilván újraindítottam műtét után távolról a gépet – és nem állt fel.
Hmm. Lehet, hogy a Microsoftnak tényleg igaza volt és tényleg ennyire kritikus komponens az Outlook Express?
Mese nincs, duzzogva bár, de ki kellett mennem megint a Dataplexbe. Az Árpád-hídnál lévő rétesárusnak jól ment ebben az időben, mindig bedobtam nála egy mákosat.
Amikor beléptem a szobába, kellett egy kis idő, míg levegőhöz jutottam. Az történt, hogy egy kolléga bekötött egy tesztgépet és mivel nem talált hozzá szabad konzolt, lehúzta a Blackberry szerverét. Az a süket BIOS meg várta, hogy valaki majd megnyomja az F1-et a hiányzó billentyűzettel.
Alapvetően tiszta szerencse, hogy ilyenkor én már hangolódok a szeretet ünnepére.

A sok kanyar után megint összejött egy tesztelhető állapotú konfiguráció. Vállalati aktiválás – és igen, megérkezett a teszt postafiókba a vezérlő levél. Aztán ennyiben is maradtak. A Blackberry központ negyedóránként elküldte a levelet, a handheld meg cseszett aktiválni. Vagy a jó ég tudja, melyik komponens.
Újabb levél a support hapinak. Két napig semmi. Ekkor felhívtam a srácot, olvasta-e. Még nem. Be van havazva. Oké. Levél az ügyfélnek, így állunk. Vezig hogy érzi magát?
Huh. Újabb kapkodás. Ingerült levélváltások. Hogy milyen support is ez? A T-online büszkén válaszol, hogy semmilyen. Ugyanis ehhez a cucchoz nem is adnak el supportot, mert hivatalosan nincs is olyan termékük, hogy támogatás. De ha ennyire bénák vagyunk, akkor kijönnek és jó pénzért feltelepítik ők.
Szóval ment az agyalás. Én közben – sokadszor – átolvastam a telepítési útmutatót. És basszus, megakadt a szemem egy megjegyzésen: ne telepítsük a Blackberry szervert dmz-be. Lehet, hogy az a baj, hogy túl okosnak képzeltem magam. Azt gondoltam, hogy legfeljebb majd megnézzük jól, mit akar ez kommunikálni, aztán azokat jól átengedjük. Aztán lehet, hogy ez meg egy olyan termék, amelyik csak akkor működik, ha egy LAN-on van az Exchange szerverrel. Mittudomén, lehet, hogy azt se tudja, mi az a default gateway. (Tudom, nem az a szint… de ha az ember el van kettyenve, akkor szinte mindegy mit, csak csinálni akar valamit.)
Kimentem megint a Dataplexbe és átkábeleztem a belső LAN-ra. NIC, routing tábla, minden rendben, a gép működött, távolról is. Akkor újabb kísérlet, és újabb döbbenet: a Blackberry Manager azt mutatta, hogy a szerver nem működik.
Vazze, ez a szerencsétlen nem bírta elviselni, hogy megváltozott az IP címe. Nyess. Blackberry szerver le, aztán fel. És már csodálatosan működött is. Jöhetett a teszt, levél megérkezett és a negyedórás próbálkozások is.
Közben jött e-mail a supporttól – gondolom ráléptek a figura farkára jól; pedig ő tehetett a legkevésbé a helyzetről. Azt mondta, akkor szokott ilyen történni, ha nem jól távolítják el az Outlook Expresst. Ekkor sikítoztam egy kicsit. Ugyan már, mi a megfelelő eltávolítása egy eltávolíthatatlan programnak?
Nem sokkal később jött egy másik levél is, benne egy csomó tippel. Köztük azzal, hogy ugye, a service account user nevében léptem be és csináltam a telepítést. Nem. Már miért tettem volna? Általában domain adminnal telepítek, ha kell service account user, akkor legfeljebb átírom a service adatlapját. No, mindegy, egy próbát megér.
És igen. Ez hozta a megoldást. Bármennyire is hihetetlen, a service account user valami démoni lény és csak ő tudja azt a titkot, amitől életre lehelődik a Blackberry szerver. És hol van ez leírva? – kezdtem dühöngeni. Újból elővettem a rongyos telepítési leírást… és megtaláltam. Egyszer leírták nagy vonalakban a folyamatot, egyszer pedig szájbarágósan. És az utóbbi változatnál volt ott, elég apró betűkkel.
Legközelebb annyira betű szerint fogok telepíteni, amennyire csak lehet.
Bár ismerve a rajtam ülő átkot, akkor meg biztosan egy sajtóhibába fogok belebukni.

Szóval öröm, petárdák, hejehuja, pezsgőbontás. Most már van egy Blackberry kütyüm is. Illetve eddig is volt, csak nem működött.
Még annyi lett volna hátra, hogy visszaköltöztetjük a cuccot a dmz-be, de a support gyorsan szertefoszlatta az elképzeléseimet: felhívta a figyelmemet, hogy az első aktivizálás után már ne változtassuk meg a szerver IP címét, az ugyanis be lett regisztrálva a Blackberry központban, a licenszkulccsal együtt. A belső IP? – hűledeztem. Ja – jött a válasz.

Én általában vonzódom a bizarr dolgokhoz, de ez már meghaladta az én tűrőképességeimet is. Sóhajtottam egy nagyot, megírtam az üzemeltetési dokumentációt és lerúgtam magamról az egész bagázst.
Nem is akarom látni többet.

Kész katasztrófa

Tegnap egész nap BRS teszten voltam. Ez gyk. katasztrófa utáni visszaállítás teszt, időre. Kimegy egy talicska informatikus egy isten háta mögötti telephelyre(1) és megpróbálja lemezekről, szalagokról visszaállítani az éles rendszert. Izgalmas foglalkozás.
Először is megkérnék mindenkit, hogy az elkövetkező napokban finoman, nőiesen beszéljen velem, mert káromkodásból egy hónapra fel lettem töltve. Köszönöm.
Az én feladatom egy kulcsfontosságú Exchange szerver visszaállitása volt. Bármennyire szűk is ilyenkor az idő, szoktunk azért kísérletezni is. Most például kipróbáltuk, mennyire járható a /disasterrecovery kapcsolós visszaállítás, élesben. (Annak ellenére játszottunk vele, hogy van teljes mentésünk az Exchange szerverről.)
Na szóval, nyers szerver felugrott, particiók/könyvtárak beállítva, régi gép eltávolítva a tartományból, új gép beléptetve, jöhet a szerver telepítés. Next-next-nekemnepofázz-finish,… hűdegyors volt ez a telepítés. Nem is rakott fel semmit, csak egy dll-t. Újabb próba, most már le is nyitogatva a menüpontokat,… hát, azt mondja, hogy a prerekvizitek nem stimmelnek. És tényleg, teljesen kiment a fejemből, hogy az Asp.net és a Pop3 szervízek telepités után manuálba kerülnek. Elindítottam őket, de továbbra is hibaüzi jött, amikor ki akartam választani a kollaborációs komponenst. Jó, akkor szedjük le ezt az elb… izé, nyomorult telepítést. Nem jött le. Még a szerver csodálkozott a legjobban; azt mondta, hogy némá, milyen vicces, váratlanul nem tudom leszedni ezt a komponenst.
Jó. Újratelepítés. Sittysutty megvolt. Hoznám létre az adatbázisok könyvtárait, amikor látom, hogy teljesen össze vannak borzolva a partíciók. Visszanevezés közben jött a hidegzuhany: az E partíciót nem lehet átnevezni, mert az lett a system. Miaf? Ez még akkor is durva, ha tudjuk, hogy a system partíció az, amelyikről bootol a rendszer, a boot partíció pedig az, amelyiken a system van. És tényleg, az E particion ott figyelt a boot.ini. Hajjaj. Újratelepítés, de most még a szöveges setupnál töröltem mind a nyolc partíciót – így nem tudott hibázni a kedves. Ez a telepítés már teljesen olajozottan ment, öröm volt nézni. Nem volt egy felesleges mozdulatom sem. Illetve volt – egy beintés, amikor megint nem volt hajlandó települni az Exchange. Nagyítóval néztem át a prerekvizit listát, de minden klappolt, az utolsó szögig. Lassan már eljött az ideje abbahagyni a kísérletezést, de szerencsére a fájlszerver visszatöltés lefoglalta a szalagos egységet, tehát próbálkozhattam még egyszer. És ismét rámmosolygott a google power, egy link eréjéig.
Érdemes idézni:

I called Microsoft Product Support and their solution was to uninstall 2003 Server SP1, install Exchange, install Exchange SP1 then install 2003 Server SP1. This sounds far too shaky a solution for me and on my front-end servers I installed 2003 Server slipstreamed with SP1, so, since I’m the position to do it, I’m just reinstalling the servers from scratch without SP1 until I have Exchange installed.

Nos, erre nem számítottunk; nem volt nálunk külön Windows2003 szerver telepítő cédé, külön felrakható SP1-gyel. Odamentem a konzolhoz és megtippeltettem a kollégával, hogy vajon mit fogok most csinálni. Fogalmam sincs, honnan találta ki elsőre, hogy szervert fogok újratelepíteni. Amíg a bitek tepertek a vasra, nekiálltam leszedni az Internetről az Sp1-et. Aki netán elfelejtette volna: ez a dög 330 MB. Nem kicsit bonyolította a dolgot, hogy idén újítottunk: nem vittünk laptopot, desktopot; ehelyett az ügyfél unixosaitól kaptunk egy-egy Kanotix Linux live distro cédét. Erről tetszőleges vasat be tudtunk bootolni – volt egy csomó, egymásrahajigálva a sarokban – és rdesktop-pal már csűrtűnk is fel a szerverekre. Töredelmesen beismerem, az ikszre végződő nevű rendszerekben nem vagyok nagy spíler, így okozott némi nehézséget, az Sp1 terelgetése. Windowsban azt csináltam volna egy vinyó nélküli gépnél, hogy bemeppeltem volna K: meghajtóként a szerver valamelyik megosztását és arra töltöttem volna le böngészőből a stuffot. Ez itt nem jött össze. SMB-n tudtam ugyan kapcsolódni, de letöltéskor nem tudtam megadni ezt a kapcsolatot. Végül leszedtem a csomagot ramdiszkre (hálistennek volt bőven), onnan krusader-rel ment tovább a szerverre. (Sorry, MC-vel nem sikerült.) Mindenesetre, amíg a memóriába tőtikézte lefelé a fájlt, addig csak lábujjhegyen mertem közlekedni a szobában.
Közben felment a Windows2003 szerver is, Sp1 nélkül. Ránézésre egy csomó rendszerkomponenst nem ismert fel, driverek meg nem voltak, de úgy döntöttem, nem is kellenek. Ha száguldozni akarok egy autóval, akkor nincs szükségem karosszériára. Ugyan már kilométerekre kerültünk attól az elvtől, hogy a visszaállítandó rendszerhez minél hasonlóbbat állítsunk össze – de amikor a hasonlóságra törekedtünk, az nem jött be. Na, mindegy, a kasztni nélküli cucc beröffent. Ment rá az új install. És nem volt inkompatibilitásra utaló hibaüzenet az Exchange setup indításakor! Elégedett mosoly… de nem. Megjött ugyanaz a nyomoronc 0xC007003A(58) hiba.
Újabb varázslások következtek. De tényleg. A mosoly egyre görcsösebb lett az arcomon. Holnap ITIL vizsga. Közben nemhogy a mai tanulásnak, de a mai lefekvésnek is egyre biztosabban lőttek.(2)
Átnéztem a DNS-t és ott virított benne egy hasonló nevű gép. Ki a lilafaszom tette ezt bele? Nyess. De ettől sem javult meg semmi. Oké. Netdiag. Nagy büdös Kerberos hiba. WTF?! Aszongya nem tudja autentikálni a gépet – de névként a hasonló nevű hostot nevezte meg. Mivan? Valami derengeni kezdett, rátekertem a gépnév rovatra. Basszus. Az eredeti gép nevében szerepelt egy ‘0′ karakter. A nagy kapkodásban megszokásból magyar kiosztásúként használtam egy pillanatra a konzolbillentyűzetet, és nulla helyett a felsőfütyi karaktert tettem be. Az oprencer meg volt annyira intelligens, hogy sem ezt a karaktert, sem az utána következőket nem vette figyelembe. Esetleg figyelmeztetni? Ugyan már. A figyelmeztető csapat az összes aktivitását kiélte akkor, amikor a nem használatos desktop ikonokról volt szó – másra már nem maradt lendület.
Gép kilép/belép, közben átnevez, AD reset. De ettől sem jutottunk előre. Jobb híján rászálltam a Kerberos hibaüzenetre, de semmire sem jutottam vele. Pontosabban annyira, hogy csaltam és megkérdeztem az éles rendszeren dolgozó kollégát telefonon, hogy nézze már meg, az éles szerveren – mely játszásiból most ugye le volt bombázva – mit mond a netdiag. És azon is ott volt a Kerberos hiba.
Tehát ez rossz nyom.
Itt érkeztünk el egy döntési ponthoz. A felkészülési dokumentációk egyik része azt írta, hogy az Exchange /disasterrecovery előtt töltsünk vissza system state mentést. Másik része meg meg sem említette ezt a lépést. Nekem ez utóbbi tűnt logikusnak, hiszen arról szól a történet, hogy _csak_ adatmentés van – az Exchange paraméterek majd az AD-ból fognak visszajönni.
Ötlet híján csapást váltottunk: jöjjön az a system state. De majd csak másnap reggel.
Új nap, új remények. De hamar kiderült, hogy a világegyetemben minden változik, csak a szívás állandó. Akkora volt a hardver különbség a két gép között, hogy képtelenség volt rá visszatölteni a system state mentést.
Ekkor járt le az időm. Visszatértünk a jól bevált Exchange visszaállítási módszerre, hanyagolva az új utakat.
Kár érte, mert reméltem, hogy ennél a visszaállítási módszernél meg tudjuk kerülni az adatbázisonkénti hét órás konzisztencia ellenőrzést.

(1) Csak úgy megjegyzem, hogy ez egy nagyon nagy nevű cég direkt erre a célra felingerelt telephelyén zajlott. Nem csak mi használjuk ezt a szájtot, az ügyfelünkön kívül sokan mások is igénybe szokták venni. Pontosan tudom, hogy kik, ugyanis a nagynevű cég emberei csesztek bezárni a dokumentációs szekrényt. Pusztán unaloműzőként lehetőségem volt áttanulmányozni néhány nagy magyar cég informatikai rendszereinek a leírását.

(2) Yes; hajnal kettő lett belőle.

A nagy levélelkapó manó

Mottó:
A patkó miatt a ló elveszett,
A ló miatt a lovas elveszett,
A lovas miatt a csata elveszett,
A csata miatt az ország elveszett,
B+ nézd már meg jobban azt a patkószeget.

Bevezetés:

Nagy ügyfélnek van egy nagy Exchange organizációja. Van neki két kisebb, többé-kevésbé független leányvállalata. Ezek szintén benne vannak az organizációban, saját Exchange/DC szerverekkel. Az egyik leánnyal nincs is gond, az ő szervereiket mi üzemeltetjük. A másik viszont zűrösebb, elméletileg semmi közünk sincs a gépeikhez – gyakorlatilag muszáj bele-belenyúlkálnunk. Persze a saját adminjaik is bele-belenyúlkálnak.
A nagy ügyfélnek van saját levelezési internet kijárata.
A leányvállalatnak önálló routing groupja van, de az Exchange-t csak belső levelezésre használták. Kifelé saját linuxos levelezési rendszert építettek ki. A kettő között nem volt átjárás.
Megkérték, hagy használhassák külső levelezésre is az Exchange-t. Beállítottam az organizációban, hogy a továbbiakban érezzen felelősséget az új emailtartományért (kaptak egy email policyt), szóltam nekik, hogy írassák át az MX rekordjukat és elmentem nyaralni külföldre.
Csakhogy ők kreatívan értelmezték a lehetőségeiket, ugyanis felraktak egy új smtp konnektort a saját tűzfaluk és Exchange szerverük közé majd erre iratták át az MX rekordot. A konnektoron 1-es súlyt állítottak be (naná!), ezzel sikeresen magukra rántották a nagy testvér teljes kifelé menő levelezését. Ez még nem is lett volna olyan nagy gond – de nem sokkal később lekorlátozták, hogy csak ők használhassák a konnektort. Ekkor állt le a nagy cég levelezése és tört ki a botrány. Kollégáim hosszas munkával kinyomozták, mi történt, felemelték a kalózkonnektor súlyát, a levelezés megjavult. Persze felelőst kellett találni. A leányvállalat elegánsan mindent rám fogott, mondván, hogy én csináltam a konnektort. Sőt, már a nyomozás kezdeti fázisában is mosták kezeiket, mind a nagy cégnek, mind a kollégáimnak azt állítva, hogy én csináltam mindent. Emiatt sokáig mindenki azt hitte, hogy ez a konnektor teljesen legális és jól van konfigurálva.

Amikor visszajöttem a nyaralásból, találtam néhány ejnye-bejnye levelet a postafiókomban. Marhára nem értettem a dolgot. Tiszta szerencse volt, hogy éppen nem akadt túl sok munkám, így megpróbáltam utánajárni a leveleknek. Lefényképeztem néhány képernyőt, megmutattam mind a főnökeimnek, mind a nagy ügyfélnek, hogy itt akkor történt a disznóság, amikor külföldön voltam. Ezzel rendeződött is a helyzet. (Mindenesetre akár örülhetnék is, hogy annyira jól fekszem mind az ügyfélnél, mind a saját cégemnél, hogy egy ekkora – nekem tulajdonított – malőrt tkp egy ejnye-bejnyével úsztam volna meg.)

Cselekmény:

Jött egy bejelentés, hogy a leányvállalat és a nagy cég között megszűnt a public folder replikáció. Tudjuk, hogy a replikáció levelek útján történik – tehát első dolgunk benézni a Message Trackingbe, hogy mi a helyzet. A PF replikáció az Exchange szerverek Information Store (IS) szolgáltatásai között zajlik, ők leveleznek egymással. Az IS-ek email címei így képződnek: Servername-IS@domain.root. Erre kell rákeresni a logban.

    Kitérő:ezzel azért óvatosan kell bánni. A Message Tracking azt a címet mutatja, amelyik a borítékon belül(!), azaz a levél data mezőjén belül van. Csakhogy a levelezés az alapján a cím alapján történik, amelyik a borítékra van írva – és ez a tracking logban nem látszik. Jártam már úgy – pont ennél a cégnél -, hogy installálás után az IS nem kapott email címet, emiatt nem ment a PF replikáció. A tracking log azt mutatta, hogy a levél jó címre ment ki: a data mezőben ott is volt a jó cím; csakhogy a nem látható ‘rcpt to’ üres volt. Az event log és az Archive Sink mondta meg végül az igazat és az AdsiEdit-tel írtam be a jó emailcímet az IS adatai közé.

Visszatérve a mostani szituációhoz. Szépen látszott, hogy a nagy cég szervere elküldi a replikációt indító levelet a leányvállalatnak és nem kap választ. Nocsak. Korábban már írtam, hogy kényszeres telnetelésben szenvedek. Beléptem a leányvállalat szerverére, telnettel küldtem egy levelet a nagy cégnél lévő postafiókomba és megnéztem a levél tulajdonságlapján, milyen úton jött meg. Jól sejtettem, körbement: nem a két routing group közötti konnektort (RGC) használta, hanem kiment az internetre a leány kapuján és bejött a nagy cég internet kapuján. (Ídes babám, engedj ki, hagy jöjjek be!)
Nézzünk be a System Managerbe. Azt mondja, nincs hozzá jogom. Nekem?! Az Exchange Atyaúristen nevében voltam belépve: enterprise admin, domain admin, localadmin, schema admin. és ennek nevében történt az organizáció létrehozása is. Szóvá is tettem a legközelebbi összeröffenésen a leánycég vezetőinek, hogy ugyan miért rúgtak ki a szerverükről? Harsány tiltakozás, persze – dehát nekik ekkoriban volt némi szavahihetőségi deficitjük.
Mindenesetre az adminjukkal nekiugrottunk a rendszernek és tényleg nem volt egyszerű a helyzet. A DC-n belépve tudtam menedzselni a felhasználóikat. Ő az Exchange szerverre belépve el tudta indítani a System Managert és látszott, hogy a routing group-on megvan a full admin jogom. Meg lefelé is mindenhol. Ha én léptem be, még az ADUC-ot sem tudtam elérni.
Hmm… elvonultam gondolkodni.
Engem igazából a Winroute érdekelt volna, megnéztem: azt mondta, ismeretlen organizáció és egyáltalán, minden ismeretlen. Nocsak, nyomon vagyok? Nézzük, mi van az AdsiEdittel – itt sem értem el a tartományt. Ldp? És igen – az ldp-vel sikerült végre kapcsolódnom a tartományhoz. Tesztként átírtam egy felhasználó emailcímét, működött. Mit tudhat az ldp, amit az MMC illetve az AdsiEdit sem tud? Fogalmam sincs. Nézzük meg Netmonnal. (Pontosabban elsőre Ethereal-lel ugrottam neki, de az nem tudta értelmezni az LDAP forgalmat. (??))
Először az RST-kre figyeltem fel és csak később esett le, hogy némá, az Exchange szerver a forest root DC-vel akar ldapozni. Vajon minek? Mindkét tartományi DC GC is egyben – elméletileg le kellene tudniuk kezelni azt a helyzetet, hogy a felhasználó a forest rootban lett létrehozva. Bár a szituáción lehetett volna egy csomót agyalni, de az egyszerűbb utat választottam, írtam egy levelet a tűzfalasunknak, hogy léccilécci engedd már át az ldap-ot e két gép között. És innentől működött minden adminisztrációs eszköz. (Mondjuk továbbra is érdekelne, miért volt ravaszabb az ldp, mint a többi.)
Persze a PF replikáció az nem javult meg.
Átnéztem jól az organizáció routolását, hangolgattam is, végül ez lett:
InternetN(SMTP)(2) – (2)(SMTP)Nagycég(RGC)(1) – (1)(RGC)Leány(SMTP)(2) – (2)(SMTP)InternetL
Ennek működnie kellett volna, különösen, hogy az RGC-nek kutya kötelessége lett volna a belső leveleket szállítania, függetlenül az SMTP konnektoron lévő súlytól. Kínomban írtam az MS TAM-unknak, ugyan szerezzen már valami anyagot arról, hogy hogyan működnek testközelből ezek a konnektorok, különös tekintettel arra az esetre, amikor egyszerre van RGC és SMTPC – ugyanis ilyen szituációról a Resource Kit sem tett említést. Visszaírt, hogy ennek így tökéletesen kellene működnie, itt más lesz a gáz. Beszélt Mészáros Kornéllal és küldtek egy checklistát, mit nézzek át. És igen, itt lett nyakoncsípve az aljas: a virtuális SMTP szerveren is be volt állítva egy smarthost – a leánycég internetkijárata előtti spamszűrőre célozva. Amikor csinálták az illegális konnektort, nem bízták a véletlenre, beállították itt is – ezáltal nemcsak azok a levelek mentek az SMTP konnektor felé, melyeknek arra kellett volna menniük, hanem mindegyik. Ugye milyen egyszerű, mi? Csak meg kellett volna nézni azt a nyomorult patkószeget.

A fiúk persze elfelejtették a beállítást és hagyták, hagy szívjak vele pár napot.
Persze, ha nem így tesznek, szegényebbek maradtunk volna ezzel a cikkel.

Apu hod med be

Rendszeresen hallani olyan esetekről, amikor nem figyelt oda az Exchange adminisztrátor és az adatbázis mérete átlépte a bűvös 16 GB értéket. (Pedig a problémát meg lehet előzni: írni kell egy wmi szkriptet, beidőzíteni napi egyszeri futásra. Ez azt csinálja, hogy ha az adatbázis mérete nagyobb, mint 15 GB, akkor mondjuk pirosra váltja a háttérképet. Ha nagyobb lesz, mint 16 GB, akkor meg postázza az admin munkakönyvét.)(1)

No mindegy, megtörtént a baj, mit lehet ilyenkor csinálni? Nyilván offline tömörítés, törlés, offline tömörítés gyógyítja a túlsúlyt… de nem biztos, hogy erre pont az az időpont a megfelelő, amikor az adatbázis elment kávézni. Mit nem adnánk ilyenkor egy kis haladékért?

A jó hír az, hogy létezik ilyen haladék. Természetesen registry turkálással aktivizálható. (A magam részéről utálom ezt a technikát. Ebből származnak azok a mítoszok, hogy registry buherával mindent meg lehet csinálni. Hogyan lesz a Windows szerveremből kenyérpirító? Írd be ezt meg ezt a registrybe…)

A matatás előfeltétele, hogy vagy Exchange 2003 legyen a szoftver vagy 2000 alatt legyen felugratva a post service pack 3 rollup. A beállítás után újra kell indítani a gépet és máris kaptunk plusz egy gigát. Ja, és mit kell beírni? Itt van a KB cikk.

Oké. Most nézzük, mi van akkor, ha standard Exchange szerverünk van, nem akarunk enterspájzot, de az adatbázisunk mérete rakétaként szárnyal? Probléma szál se, tiszta szerencse, hogy műveltek vagyunk. Például tudjuk, hogy az Exchange 2003 SP2-ben a méretkorlát felugrik 75GB-re. Ez a csomag ugyan még nincs kint, de a béta verzió már igen és a korlátfeloldást ez is tudja. Azaz ha nagyon szorongat az ügyvezető és átvállalja a béta kockázatát (MS természetesen nem ajánlja), akkor meg lehet próbálni ezt az utat.

Csakhogy. Feltettük, az adatbázis átvágtatott a 16 GB célvonalon és eldőlt. Ilyenkor mi van?
Szokásos trükk. A méretkorlát feloldása nem automatikus. Vajon hol lehet bekapcsolni? Úgy van. Registry. I like this company.
Kellemes mellékhatás, hogy az SP2 után létezik egy másik paraméter is a registryben – ezzel figyelmeztető értéket lehet beállítani az adatbátisméretére.
Mindez szépen le van írva az Exchange csapat blogjában.

[Update]
(1) Gömöri Zoli szólt, hogy ő már írt egy ilyen szkriptet. Íme.
Én a magam részéről egyszerűbbre gondoltam – szvsz. elég lehet fájlszinten lekérdezni az .edb/.stm méreteket – bár így sem rossz.

A lehetetlenre egy kicsit várni kell

Úgy kezdődött, hogy Ügyfél egyik középvezetője nem tudta összeszinkronizálni Sony-Ericsson kütyüjét az Exchange szerverrel. (A szinkronizáció nem közvetlen, van egy erre a célra felingerelt Onebridge szerver a hálózaton. Ezt mi üzemeltetjük, de nem mi támogatjuk.)
A hibát kolléga bejelentette az alkalmazás támogatójának, akitől azt a választ kapta, hogy mentsük ki a postafiók tartalmát pst-be, töröljük a mailboxot, majd hozzuk újra létre – és ettől meg fog javulni a szinkronizáció. Sajnos a kolléga elhitte. Megkérte a középvezetőt, hogy másoljon ki mindent pst-be, majd amikor az jelezte, hogy oké, akkor törölt, purgált és újralétrehozott. A szinkronizáció természetesen nem javult meg, de ezzel a szállal a továbbiakban nem foglalkozunk.
A középvezető visszamásolta a cuccait – és reklamált, hogy valami nem stimmel, nem találja a kontaktjait. Egyeztetés után kiderült, nem tudta, hogy a Contact foldert is ki kellett volna másolnia. Legyünk már olyan kedvesek és állítsuk vissza az eredeti állapotot.
Ekkor jöttem be a képbe én és egyből elszürkült a tekintetem. Mentések természetesen vannak, de ez a purgált, majd újra létrehozott postafiók semmi jót nem ígért. A dumpsteren keresztüli visszaállítás természetesen szóba sem jöhetett.
Elsőkörben be kellett izzítani a Recovery Storage Group-ot az Exchange szerveren, felvenni a piszkálandó adatbázist. Gyors ellenőrzés a registryben: a HKLM\System\CCS\Services\MsexchangeIS\ParametersSystem kulcs alatt a Recovery SGOverride értéke nehogy 1 legyen, mert akkor a visszatöltés fejbevágja az eredeti adatbázist. Nyilván még helyet is kellett keresni a logoknak és az adatbázisnak, ennek megfelelően korrigálni az adatbázis adatlapját – és be kellett állítani, hogy az mentésből felülírható legyen.
Ennyit az előkészületekről, jöhetett a Tivoli Exchange kliens. Itt ért az első kellemetlen meglepetés: az aktív mentések sorából pont kicsúszott az a mentés, amelyre szükségem lett volna, az összes mentések listájának felolvasása meg jó másfél órába telt. Bejelöltem, hogy melyiket szeretném visszaállítani, aztán hagy szóljon.
Jó egy óra után, 99% körül elszállt a visszaállítás, miközben a szerver felsikított, hogy betelt a C:\. Amikor ennek a partíciónak a közelébe sem lett volna szabad mennie. Rövid bogarászás után megtaláltam, hogy a saját profilom verte ki a biztosítékot, simán felhízott 2,5 gigára. További bogarászás után azt is megtaláltam, hogy a Tivoli kliensben üres a temporary directory beállítás; a kis okos tehát a profilomba szemetelt. Kiganéztam, megadtam neki egy másik lemezt és újrakezdtem. Másfél óra a listáig, egy óra a visszatöltés.
Exchange sp1 óta a Recovery Storage Groupból elérhető a Mail Merge funkció (egyfajta lebutított Exmerge), ez nekem tökéletesen megfelelt. Kiválasztottam a másolás alfolderbe opciót és elmentem haza (1.5 GB; 20000 item).
Másnap leellenőriztem a kontaktokat: a folder üres volt. Miaszösz? Dismount, törlés, kezdjük újra az egészet. A másfél órás listavisszatöltés után megvizsgáltam a Tivoli klienst és azt találtam, hogy alapban be van kattintva az automatikus kijelölés opció. Tehát amikor kijelöltem a korábbi adatbázist, akkor ő a biztonság kedvéért végigjelölte a következő teljes mentésig a logokat is és persze a visszatöltés után rá is játszotta azokat – azaz visszakaptam egy olyan állapotot, amikor már az új postafiók volt az adatbázisban.
Kíváncsiságból kipróbáltam, mi történik, ha nem jelölök ki log visszatöltést és nem kérek rájátszást. Visszatöltés előtt figyelmeztetett, hogy lehet, hogy nem fogom tudni felmountolni az adatbázist. És milyen igaza volt: tényleg nem tudtam. Törlés, kezdjük előlről. Bejelöltem a megfelelő adatbázist, kikapcsoltam az automatikus kijelölést, bejelöltem az aznapi logokat (csak azokat!), kértem a rájátszást és beállítottam a temp directoryt.
Nna, így már sikerült.Ezt abból is észre lehetett venni, hogy ekkor már nem működött a Mail Merge. De még az Exmerge sem. Egyik sem találta a produkciós adatbázisban a recovery adatbázisbeli postafiók párját. Nyilván nem, mert ugye törölve lett, purgálva lett, sóval behintve lett. A felhasználóhoz rendelt postafiók már vadiúj volt, akkor is, ha minden látható név ugyanaz volt rajta. Nem kicsit frusztráló, hogy a kezelői felületen ott látom a mailboxot, de képtelenség kimenteni a tartalmát, mert minden eszköz merge műveletre van tervezve; ahhoz meg kell a régi postafiók. Pst-be másolás? Felejtsd el.
Iránya jó öreg google haver. Első körben itt van egy link; azt írják, hogy milyen állapotai vannak egy postafióknak és milyen állapotokban van esély visszaállításra. Purgálás után pl. semmi. Aztán a cikk végén felcsillantottak egy lehetőséget, megadtak egy másik cikket. Ennek már a címe is izgalmas volt, azt mondta: “Hogyan állítsunk vissza purgált postafiókot“. Átolvastam. Fejvakarás. Átolvastam még egyszer. Kezdtem érteni. Zseniális! Hogyan hekkeljük meg a Recovery Storage Group-ot? Először töltsük vissza az adatbázist az RSG-be, ahogyan kell, mountoljuk fel, majd azonnal le. Fontos, hogy ez simán történjen, érdemes a státuszt rögtön leellenőrizni az ’eseutil /mh’ paranccsal.
És itt jön a trükk: nevezzük át az adatbázis fájlokat, pakoljuk át máshová, csináljunk neki produkciós storage groupot, abba csináljunk neki adatbázist és mountoljuk fel.
Nem, nem kell a szívünkhöz kapni, nem lesz innentől kezdve mindenkinek két postaládája – ugyanis amikor felmountoltuk az adatbázist a Recovery Storage Groupban, akkor automatikusan minden postafiók lecsatolt állapotba került és ez a dismount során igy is maradt. (Mondjuk a zabszemteszten nem mentem volna át, amikor csatlakoztattam; mondtam már, hogy ez a VIP adatbázis volt?)
Most előreszaladtam egy kicsit, mert közben azért bejött a képbe a Nagy Harci Fasz.
Amikor ugyanis megértettem, hogy mit kell csinálnom, nekiálltam dismountolni az RSG adatbázist. Nem sikerült, a System Management konzol befagyott. Vártam másfél órát, majd kilőttem a Task Managerből. Kolléga összedugta fejét az ügyfél kapcsolattartójával, este hétkor engedélyezték a szerver újraindítását. Fél nyolckor jött a telefon, hogy gáz van, az Exchange szolgáltatások nem indultak újra. Fél nyolc után öt perccel jött az újabb telefon, hogy nagyobb gáz van, tkp. a szerver nem is állt le, csak úgy lebeg élet és halál között. Oké, irány a Dataplex. Érdekes látvány fogadott: a szerver működött, csak éppen a távoli elérést biztosító szolgáltatásai haltak el. Az egész leállási folyamat az Information Store leállására várt, az viszont beragadt ’stopping’ állapotba. Egyébként a szerver köszönte szépen, jól volt. Az eseménynaplót percenként szemetelte tele a System Attendant, hogy nem tud leállni, mert az Exchange szerver nem elérhető. Elég hülye kifogás. Megnéztem a Filemon cuccal, hogy egyáltalán mi történik: semmi különös, a store.exe egyfolytában a temp könyvtárat csesztette. Az adatbázisok viszont ott vigyorogtak lezáratlanul. Ezután dehogyis mertem kigyilkolni az IS-t. Ahogy a szakirodalom is mondja, ilyenkor kell felhívni a a Microsoft Premier Support-ot: hagy harapjanak ők is egy jó nagyot a felelősségből.

Tudom, minden rendszermérnök életében eljön az a pillanat, amikor éles szituációban be kell jelenteni telefonon egy hibát az amerikai PSS-nek. Ez, úgymond, egyfajta evolúciós lépcső. De nem hiszem, hogy mindenki annyit szerencsétlenkedik vele, mint amennyit én.
Ott kezdődött, hogy a szerverszobában 40-50 szerver duruzsolt a fülembe. Ki lehetett ugyan menni a folyosóra, de ott meg nagyon figyelni kellett a padlólapokat, mert tény, hogy bizonyos lapoknál elmegy a térerő. És persze a teljes kommunikáció egy pici mobillal történt.
Nos,én voltam annyira zöldfülű, hogy már rögtön az első hapinak nekiálltam magyarázni a technikai problémát, bőven ecsetelve az előzményeket. Kicsit ugyanis ideges voltam, mivel ez az ügyfél fő produkciós levelezőszervere volt, a kapcsolattartó pedig elnézte a dolgot, a cég legfontosabb projektjében ma kellett volna külföldre küldeni bizonyos záródokumentumokat.
(Ugyan javasoltam nekik, hogy küldjék el privát postafiókból webes felületen, de azt kaptam, hogy na ne már, verziókövetés van, előzmények vannak, subject kódok vannak, nekik válaszolni kell az előző levélre. Fóti Marci örökbecsűje jutott eszembe: ‘Az informatika még nem érte el azt a biztonsági szintet, hogy rábízzuk az életünket – de mi rábíztuk.‘)
Szóval egyáltalán nem lepődtem volna meg, ha megtudom, hogy az ügyfél verőemberei már melegítenek valahol.
Ehhez képest gyönyörűen elbeszéltünk egymás mellett: én állandóan a problémámat hajtogattam, a hapi meg állandóan azonosítgatni akart: Mi a cégem azonosítókódja? Mi az én azonosítókódom? Mit tudom én! – sikítoztam.
Végül javasoltam, hogy hagyjuk a fenébe az egészet, van hozzáférésem az Online Premier Support oldalhoz, majd bejelentem írásban. (Ott már valamikor hozzá lett rendelve a .net jelszómhoz az egész miskulancia.) Hát, az ötlet jó volt, de valamiért nem akart összejönni a belépés.
Végső kétségbeesésemben felhívtam a TAM-ot. Kolléga szerint nem koránfekvős fajta; Isten tartsa meg a szokását, ébren volt most is. Kikereste nekem a szükséges kódokat és elmagyarázta, hogy az első ember technikailag zokni, annak csak az a dolga, hogy beazonosítson. És azt is javasolta, hogy ha olyan helyen vagyok, ahonnan rosszul hallom a szöveget, kérjek Translation Service-t. Ingyenes és minden nyelvre meg van szervezve. Remek. Megkértem, hogy küldje el az adatokat az otthoni címemre, majd webfelületről leszedem. 10 percig vártam, nem jött semmi. Egy kicsit téptem a hajamat – tényleg csak egy kicsit, aztán valahogy összehegesztettem a céges OWA elérést – lassú is volt, bizonytalan is, de a miénk… és működött. Oda is megkértem a levelet és megjött.
(Másnap esett le: otthonról olyan gyorsan jöttem el, hogy bejelentkezve maradtam a gépemnél – és persze, az Outlook pop3-mal mindig lekapta a levelet. Elmehettem a búsba a webfelülettel.)
Mindegy, megtanultam a leckét: company id nélkül ma már sehová se megyek; itt fityeg a PDÁ-n.
Innentől kezdve már csak egy óra kellett, hogy eljussak a technikai emberhez. Mondjuk az idő nagy részét az tette ki, hogy vártuk a Translation Service-t, aki végül ezen a napon nem jelent meg.
A többi már viszonylag simán ment: elmondtam a problémát, a hapi elkérte az applikációs logot (16MB – bizonytalan OWÁ-n keresztül…), majd némi fejvakarás után közölte, hogy nincs más hátra, gyilkoljam ki a store.exe-t. Eddigis hülyén nézhettem ki – gondolom, a dataplexes fiúk jót szórakozhattak a monitorszobában, hogy percenként rohangászok ki a folyosóra (sorry, I’ll go out… please repeat it…), utána meg vissza a gépterembe, minden alkalommal beriasztva őket… de ezt a lépést már nem voltam hajlandó pusztán szóbeli utasításra meglépni. Megkértem a fazont, hogy írja le emailben, mert nem hallom jól, amit mond. Leírta, kigyilkoltam, újraindítottam és felállt minden. Mármint szolgáltatás. Mondjuk az alatt az öt perc alatt, amíg az IS húzta a csíkot, öregedtem egy kicsit: 8db adatbázis figyelt a gépen, összesen olyan 600 GB méretben. Ha az IS nem indult volna el egyből, akkor életem végéig mentésből kellett volna adatokat töltögetnem.
De elindult. Már csak azt kellett kinyomozni, mi a lószar volt ez? Délután is, amikor nekem beragadt a System Manager és este is, amikor a leállítás ragadt be, a víruskergető jegyzett be gyanús hibaüzeneteket a logba.

Ez egy hálás toposz, exchange adminok előszeretettel szeretnek mindent ráfogni a víruskergetőre – és nem is ok nélkül.
Csak a rend kedvéért, hogy mi mindent tud okozni egy rosszul beállított víruskereső:
-A fájl szintű víruskereső megfogja az exchange adatbázist. Information Store nem fér hozzá, kardjába dől.
-A fájl szintű víruskereső karanténba dobja a tranzakciós log egy-egy fájlját. Information Store kardjába dől, a rendszergazda szintén.
-Ilyenről is olvastam: ha nincs elzárva a fájl szintű kereső elől az exchange szintű kereső temporary könyvtára, akkor a fájlszintű kereső ráharap az ideiglenes állományokra és lefagyasztja az exchange víruskergetőt. Még jó, hogy egy cégnél dolgoznak a fiúk. Bár a cikkben büszkén írták, hogy az ő termékük egy ilyen crash után képes meggyógyítani magát, nem kell újratelepíteni.

Nos, lássuk csak, nálam mi történhetett. Visszatöltöttem mentésből az adatbázist,és… hoppá. Nem a szokott helyre töltöttem, mert ott nem volt elég hely – ehelyett egy másik partíción csináltam neki egy könyvtárat. Kitiltottam belőle a fájlszintű víruskergetőt? Bizony nem. Megint hoppá.
Mekkora farok vagy, Joep – mormogtam hajnalban – ekkora potyagólt a te korodban már nem illik kapni.
És jobb későn, mint soha alapon bementem a víruskereső konfig menüjébe, ahol… meglepetten láttam, hogy az aranykezű kolléga korábban az egész partícióról kitiltotta a víruskeresőt. Tehát farok vagyok ugyan, de szerencsére megúsztam, nem én hibáztam.
(Mondjuk ekkor már voltam annyira fáradt, hogy a folyosón nekimentem az ajtónak: valamiért azt hittem, hogy ki fog nyílni magától. Pedig öreg dataplexes vagyok, pontosan tudom, mely ajtókat kell ballal húzni és melyeket jobbal tolni. Komolyan mondom, kész szerencse, hogy az ügyfél nem látja, hogy milyen állapotban hajt végre életveszélyes műtéteket időnként az üzemeltető.)
A magam részéről itt abba is hagytam a nyomozást egy ‘holnap is nap lesz‘ rikkantással.
Úgyis lett. Első lépésben kikapcsoltam a fájlszintű keresőt. Aztán megnéztem, hogy is áll az RSG adatbázis. Az eseutil szerint a státusz: Dirty shutdown. Hát, nem pont ez állt a cikkben. Adatbázis fájlok törlése, logok törlése, Tivoli. Másfélóra várás a listára, az egyetlen lehetséges kombináció összekattogtatása,visszatöltés. Aztán elindítottam egy Filemont, hogy lássam mi is történik mountolás/dismountolás közben. Semmi érdekes. A store.exe gyanúsan sokszor piszkálta a temp könyvtárat, mely nem volt kizárva a fájlszintű ellenőrzés alól. Kizártam. Az exchange szintű kereső ideiglenes könyvtárát is. Meg kiterjesztés alapján is kizártam az Exchange fájlokat, nemcsak könyvtárnév alapján.
Aztán megint net és kiderült, hogy teljesen rossz nyomon jártam: az az applikáció, mely teleszemetelte a logot a lefagyások előtt, az nem a fájlszintű víruskereső, hanem az exchange szintű. Itt dobtam egy négylábas megadást; összeszedtem a bizonyítékokat és elküldtem a feljelentést a gyártó képviselőjének.

Sokkal jobban izgatott, hogy mi lesz a középvezető kontakt listájával. Az újabb visszatöltés, mount/dismount után az RSG adatbázis státusza szépen Clean shutdown lett, tehát kezdődhetett a hekkelés.
Új, produkciós storage group létrehoz, adatbázis definiálódik. Természetesen másik könyvtárban, a biztonság kedvéért átnevezve. Utána adatbázis fizikailag is átmásolódik, átneveződik, nagy levegő, mount. Egyből jött is a hibaüzenet: adatbázis nem található. Kezdő exchange adminokra ilyenkor törhet rá az az érzés, hogy sürgősen keresni kell egy konnektort vizeletürítési céllal. Ne tegyétek. Sokkal praktikusabb odasétálni a pár méterre lévő darts táblához(1), leemelni a nyilakat és önfeledten hajigálni 10-15 percig. Ha esetleg átfúródik a táblán, nem gond, a fal azért megfogja. Ahogy eltelik az idő, az Active Directory csak szétreplikálja az egész hóbelevancot – és már mountolható is az adatbázis. És igen, mindegyik postafiók le volt csatolva. Nyertünk.
A doksi szerint meg kell keresni a diverzáns postafiókot és hozzávágni egy dummy felhasználóhoz. (Melyet természetesen megcsináltunk, miközben az AD replikációt vártuk.) Oké, dobjuk meg egy postafiókkal. (Sánta, van púpod? Nesze!)
Megint hibaüzenet jött: azt mondta, hogy az a legacyExchangeDN, mely ehhez a postafiókhoz tartozik, már másik felhasználóhoz van rendelve. Hja, mindenre mi sem gondolhattunk. Persze, könnyű a doksinak, ott nem feltételezték azt, hogy purgálás után rögtön újra létrehozzák az új postafiókot a régi felhasználóhoz.
Végülis, nem olyan nagy gond ez, a középvezető user adatainál átírtam AdsiEdittel a legacyExhangeDN értéket valami marhaságra, a recovery usernél átírtam a jóra, 10 perc darts és már csak be kellett pöckölni a labdát: a régi postafiókot hozzá tudtam rendelni a recovery userhez, megnyitottam outlookból mind a két postafiókot és átmásoltam azt a szájbanyomott kontakt listát a pacákhoz. Finita.
Persze még hátravolt a takarítás. El akartam tüntetni ezt a hibrid adatbázist, mert valahogy nem vagyok nyugodt, ha ilyenek kóricálnak a szerver körül. (Jártam már úgy, hogy törölt felhasználók valahogy megtalálták az RSG adatbázit és boldogan csatlakoztak hozzá.) Viszont az sem kizárt, hogy a hapi pár nap múlva veszi észre, hogy valami még kell neki. A tiszta munka átmozgatni a postafiókot egy létező adatbázisba, a hibridet meg lecsatolni, letörölni.
Másolás elindult. Az alkotó hátradőlt és várta, hogy besöpörje a hálás telefonhívások özönét. Ehelyett a helyi kolléga telefonált, hogy a középvezető igen zabos, mert fontos levelet vár, de semmilyen levelet nem kap meg; az összes levele valamilyen recovery usernél landol. Hoppá.
Elfelejtettem visszaírni másolás előtt a legacyExchangeDN értéket. Hát… most már meg kell várni a folyamat végét. 1,5 GB, 20000 item, 30 perc darts.
Az indikátor kijelzi a 100%-ot, majd a másolás könnyed sóhajtással befagy. Ez a szerver nem fér a bőrébe. Szerencsére ezen a területen már megszívtam az összes megszívnivalót, tudtam, mit kell tenni.
Hagy idézzek egy korábbi írásomból:

Végülmár csak ketten maradtunk a porondon: a 4.6 GB méretű mailbox és én. Szembenéztünk egymással, a szél ördögszekeret sodort keresztül az úton. Hirtelen mozdulattal rávetődtem a billentyűzetre és megismételtem a másolási parancsot – de most egy másik adatbázisba. Két óra szuttyogás után megint behalt a másolás… Task Manager, kilőni. Most már 3 példányban volt meg a mailbox – és mind a 3 működött. Egyszerre. Ha elvettem az egyiket a felhasználótól, mind felszabadult. Ha visszaakasztottam rá az egyiket, akkor a többit sem lehetett törölni, mert azt mondta, hogy használatban vannak. A helyzet kezdett kínossá válni. Végül kimentegettem az anyagot pst-kbe, lecsatoltam a mailboxot, töröltem a két rosszat, a maradékot visszacsatoltam – és gyönyörűen működött. Nem sokat dobott a kedvemen, hogy közben megtaláltam a helyes megoldást: a behalt mozgatást kilövés után folytatni kell _ugyanabba_ az adatbázisba, amelyikbe elkezdtük. Szószerint azt írták, hogy az Exchange van olyan intelligens, hogy észreveszi a sikertelen másolás darabjait. Usually. Hát… engedtessék meg nekem a kétkedés joga.

Nos, tulajdonképpen szerencsésnek tarthatom magam: lehetőségem volt kipróbálni, hogy milyen brilliáns hibajavító algoritmust tartalmaz a mailbox move folyamat arra az esetre, ha egy postafiók mozgatás 100% elérése után fagyott le. Tippelj.
Az nyert, aki arra voksolt, hogy nemes egyszerűséggel letörli a félbehagyott postafiókot és azt mondja, hogy kezdd újra, Gézám.
De legalább vissza tudtam állítani a legacyExchangeDN értéket. Újabb 10 perc darts és a középvezető megnyugodhatott: ő lett ő és megvolt a kontaktlista. Aztán végül nem töröltem semmit, lecsatoltam a recovery userről a postafiókot és dismountoltam az adatbázist.
Ősi cowboy szólás, hogy csak a dismountolt adatbázis a jó adatbázis.
Most már tényleg hátradőlhettem: megoldottam a lehetetlent, csak egy kicsit várni kellett rá. A kiajánlott (és kifizetett) 4-5 óra helyett 33-at.
Persze igazán nyugodt nem lehetek: kiváncsi vagyok, mikor veszi észre, hogy a Calendar is üres. Ekkor leszek igazán bajban: fogalmam sincs, hogyan lehet egy Calendarnak azt mondani, hogy select all, aztán copy másik mailbox. Hallottam már olyan emberről, aki látott olyan embert, akinek pst-n keresztül már sikerült ilyesmi – de arról is kiderült, hogy más volt.

(1) Ne mondd, hogy nincs. Nem lehetsz ennyire kezdő a szakmában.

Requesting data from the Exchange Server

Valószínűleg több sorstársamnak is keserítette már meg az életét a fenti üzenet. Az Outlook kliens monoton homokórázik, a felhasználó csak ül, és a rendszergazdával karöltve szelíden bámulják a monitort.
Ashley Webb leírt egy történetet, ahol igen trükkösen kerítették be ezt a vadat.

Megjegyzés: a sztori – sajnos – nem egy univerzális módszer a probléma megszüntetésére. Csak érdekes megoldás egy szituációra.

Arról volt tehát szó, hogy a klienseknél teljesen sztochasztikusan bejött ez a hiba, miközben az Exchange szerver összes lényeges teljesítménymutatója teljesen rendben volt. (Innentől speciális a történet; a jelenséget ugyanis általában valamilyen szerveroldali/hálózati szűk keresztmetszet okozza.)
Webb szerette volna, ha a homokórázás alatt le tudja menteni az Information Store és a System Attendant által használt memóriatartalmakat (ADPlus.vbs), de ennek igen komoly akadálya volt a véletlenszerű előfordulás. Egész nap csak nem ülhet ott egy biorobot a szerver előtt, a telefonra koncentrálva…
Viszont rájöttek, hogy van egy mutató (Average RPC Latency), mely felugrik, ha bekövetkezik a hiba. Ez jó, mert a permormance monitorban rátettek egy alertet erre a mutatóra, mely egy küszöb átlépésekor automatikusan elindított egy programot – az ADPlus.vbs-t.
79 példányban. Ugyanis a dump elég hosszú ideig tartott, közben pedig az érték többször is leesett, majd visszaugrott. Itt egy garázsszagú buhera következett, összedobtak egy parancsfájlt, ez úgy indult, hogy megvizsgálta egy bizonyos txt fájl létezését: ha nem létezett, akkor létrehozta, majd futott tovább; ha létezett, akkor a szkript megállt.
És ennyi. Megszerezték a kívánatos memóriatartalmat.
A módszernek volt egy apró mellékhatása: a dump igen erőforrásigényes művelet, rendesen leterhelte az Exchange szervert. Amíg futott, addig nem is volt ideje kiszolgálni a klienseket.
Mit csinált helyette? Úgy van, kiszórta nekik is a címben szereplő üzenetet.:-)

[Update]
Benne volt a levegőben. Ha az Exchange csapat egyik tagja csak mellékesen is megemlít egy ennyire összetett és nehezen kezelhető hibát, biztosra lehet fogadni, hogy rengetegen követelnek majd részletes magyarázatot róla.
Nos, itt van a cikk, Nino Bilic tollából. Ez se rossz.

A saga folytatódik

Korábban már sokat írtam egy Exchange migrációról. Röviden összefoglalva: van egy Active Directory, ebben pedig egy több szerverből álló Exchange 5.5 organizáció, melyhez kapcsolódnak az AIX alapú rendszerek is. Az internet felé Symantec SMTP Gateway biztosítja a kijáratot.

Vázlatosan: Internet – SMTPGW – Exchange5.5 (+Outlook kliensek) – AIX.

A migráció célja a középső rész Exchange2003-ra történő cseréje volt.
Ez valamikor tavaly augusztusban kezdődött, decemberben volt a nagy ugrás és a folyamat idén februárban ért véget. Gondoltam én.
Május első hetében kaptunk egy bejelentést az ügyfél fejlesztőitől, hogy az adatbáziskezelő rendszerükből automatikusan generált levelek januári dátummal mennek ki. Megnéztem, a levél belsejében (data mező) lévő dátum tényleg rossz volt. A borítékra viszont már minden szerver a jó dátumot pecsételte rá. Visszadobtam a bejelentést, hogy tessék már egy kicsit a saját ház előtt sertepertélni, mert a levél összerakásakor történik valami a dátummal.
Megnézték a szervereik dátumait, közölték, hogy az bizony jó. Erre megírtam a kedvenc nagymamás hasonlatomat:

A nagyi remegő kezekkel odabiggyeszti levele végére a keltezést, becsúsztatja a lapot a borítékba, leragasztja, bélyeget nyal rá és feladja a postán. Szállítás közben az összes postahivatal rápecsételi bélyegzőjét a levélre. A címzett kibontja és megdöbbenve látja, hogy rossz dátum van a levél végén. Bemegy reklamálni a postahivatalba és csodálkozik, hogy a postások kórusban kiröhögik.

Azt a választ kaptam, hogy náluk fejlesztés van, nem kupleráj. Minden változtatás változásmenedzsmenten keresztül történik és az utóbbi hetekben nem változtattak semmit. Ergo az Exchange hülyült meg. Oldjam meg a feladatot. (Ilyenkor szívja a fogát egy MS adminisztrátor – ugyanis fogalma sincs arról, hogy mije változott a rendszerében azáltal, hogy szorgalmasan pecselgeti – ergo nem mondhatja azt, hogy nálam sem változott semmi, beee.)
Nos, itt már egy kicsit izzottak a vonalak, a probléma felszivárgott a középvezetők szintjére. Én váltig állítottam a saját középvezetőim felé, hogy tkp. a fejlesztők azt szeretnék, hogy mi végezzük el az ő munkájukat; a fejlesztők pedig meggyőzték a saját főnökeiket, hogy eszkaláltassák velünk a problémát a Microsoft felé, ha már mi ilyen bénák vagyunk.
Épp itt volt az ideje mélyebben elgondolkodni, hogy mi is történhet itt tulajdonképpen. A fő gubanc az, hogy a probléma két rendszer találkozási pontján keletkezik és egyik rendszer szakértője sincs képben, hogy mi van a másik oldalon. Megtettem az első lépést, megírtam a fejlesztőknek, hogy _szerintem_ hogyan működik a rendszerük. Egész jól tippeltem, alig kellett korrigálniuk: eszerint az adatok Oracle adatbázisokban vannak, ezeket AIX-en hajtja egy Oracle motor. A leveleket egy gyári Oracle modul készíti el és tolja bele szabványos SMTP-n keresztül a levelezőszerverbe – mely MX rekord alapján az Exchange2003 virtuális SMTP szervere.
Nem tehetek róla, de ha meghallom, hogy ’szabványos SMTP’, akkor nekem mindig telnetelhetnékem van. Saját gépről kipróbáltam, nem írtam a data blokkba dátumot és ennek ellenére a levélben benne volt a jó dátum. Innentől akár fel is dughattam magamnak a nagymama-hasonlatot, mert nem igaz: ha az első SMTP host (ahol a levél készül) nem talál dátumot a data-ban, akkor beleteszi a saját átvételi dátumát – azaz a postás bizony beleír a levélbe. Közben a fejlesztők is letesztelték, hogy mi történik, ha nem raknak az adatbázisuk dátum mezőjébe semmit – a levelek gyönyörűen megérkeztek, jó dátummal.
Vov: a workaround előállt. Valahol megnyugodtam – velem együtt a főnökeim is -, mert innentől kezdve a napnál is világosabb volt, hogy a fejlesztők adnak át rossz dátumot. De a fiúk nem nyugodtak. Főnökük kifejezetten ingerült levelet küldött, hogy _ök_nem_változtattak_semmit és már napok óta levelezünk, de senki nem vette a fáradtságot, hogy letolja a képét hozzájuk. Az én agyam itt dobta le a szíjat – simogassam meg a szerverüket?! -, és mivel volt egy lezárásközeli projektem, mely akkor már a harmadik határidőmódosítást szenvedte el, megkértem a főnökömet, hogy legyen kedves, priorizálja a feladataimat. Ő is úgy gondolta, hogy inkább az egyre cikisebb projektet zárjam le, a fejlesztőkhöz meg majd lemegy egy helyi emberünk és megcirógatja őket. Helyi emberünk nem sokat tökölt: megkérdezte, kipróbálták-e, hogy mondjuk júniusi dátumot írnak az adatbázisba. Beírták, jó lett. Hoppá.
Persze az eredményt értelmezni is kellett. Íme a megoldás:
Kiderült, hogy az alkalmazásuk, melynek része a levélküldő modul is, magyar nyelvű – tehát az adatbázisban lévő dátum is magyar formában jön ki az Oracle modulból. Rakjuk csak egymás mellé az angol és a magyar formát.

Dec – Dec – oké
Jan – Jan – oké
Feb – Feb – oké
Mar – Már – bejött egy ékezethiba
Apr – Ápr – bejött egy ékezethiba
May – Máj – hoppá, ékezethiba és karakterhiba
Jun – Jún – sima ékezethiba.

Mint látható, a Microsoft SMTP szerver, amikor összerakja a leveleket, az ékezethibákat még le tudja kezelni – de az ‘y’ helyett a ‘j’-t már nem. És május elsején megzakkant a belső dátum generáló algoritmusa és a hónapot januárra javította. A fejlesztők angolra állították a kritikus dátum formátumát és egyből megjavult a májusi levelezés is.
Most akkor mégis az Exchange szerver a hülye? A látszat – és a fejlesztők is – ezen a véleményen vannak. Én – már csak a mundér becsületének megóvása érdekében is -, visszaírtam, hogy ugye tudják, hogy a levél ‘forráskódjának’ formai szabályai vannak… és ezen szabályok szerint a data SMTP parancson belül a dátum szabvány szerint angol formátumú; és nem érdekel, hogy ők, vagy az Oracle modul, de legyenek kedvesek igazodni a szabványhoz.

Viszont van itt valami, ami miatt igazából tartani kellene a pofámat: a korábbi Exchange 5.5 szerver IMS megvalósítása valahogy megbírkózott a feladattal. Gondolom, megnézte, hogy milyen nyelvi támogatások vannak a rendszerben és azok alapján próbálta meg értelmezni az ismeretlen hónapneveket.
A 2003 már bekeményített. Nyilván lehet mögé ideológiát gyártani, de tény, hogy már a sokadik sunyi változtatást szívjuk meg azzal, hogy az öreg SMTP motort a fejlett újra cseréltük.

Kompati bili

Még mindig ugyanarról a migrációról fogok írni.
Nem örömmel, de így telnek a napjaim.
Vázlatosan a levelezési lánc:
Symantec smarthost – Exchange organizáció – UNIX.
Itt frissítettük az Exchange szervereket 5.5-ről 2003-ra.
Az utóbbi napok tapasztalatai alapján kezd új értelmet nyerni számomra a ‘kompatibilitás’ szó.
Ma kaptam egy levelet. 650 hibaüzenet volt benne. És egy idegbeszakadt Unix adminisztrátor minden szívfájdalma. Meg egy figyelmeztetés, hogy ezek a fájdalmak a közeljövőben akár valóságosak is lehetnek a számomra.
Az NDR-ek a következő üzenetet tartalmazták:
The following recipient(s) could not be reached:
User, Jolan on 25/02/2005 09:38
The message contains a content type that is not supported
<mail-server-00.companyA.com #5.6.1 smtp;554 5.6.1 Body type not supported by Remote Host>
Nem sok, de legalább kevés. A legszebb, hogy ezek a levelek egy olyan alkalmazásból jöttek, melyet teszteltünk az új Exchange szerverekkel és akkor rendesen működött. Azóta pedig nálunk nem változott semmi. Tanácstalanul rákattintottam az eseménynaplóra, ahol a következőt találtam:
“A non-delivery report with a status code of 5.6.1 was generated for recipient rfc822;user.jolan@company.com (Message-ID <00…>).”
Ez nagy áttörés volt, mert volt hibakódja. Viszonylag rövid nyomozás során megtaláltam egyrészt azt, hogy az 5.6.1 státuszkód az RFC 1893 alapján azt jelenti, hogy… nos, baj van a levéllel. Másrészt ráleltem egy KB cikkre, melyben leírják, hogy hogyan kell kiherélni az ESMTP-t. Itt még nagyon nem sejtettem, hogy hogyan lesz ebből megoldás.
Mit csinál ilyenkor az ember? Telnetelget. Hoppá… a smarthost nem támogatja az ESMTP-t. Hogyan is állt ehhez a kérdéshez az 5.5 Exchange? Tudta az ESMTP-t ugyan, de nem mindegyik parancsát: pl. nem ismerte a 8bitmime formátumot. Izé, nézzünk már meg egy eredeti levelet: bingó, van benne csatolás. És amikor teszteltünk? Akkor nem volt. Ez már szag…
Ilyenkor szoktam bezárkózni a klotyiba – ott lehet a legnyugodtabban végiggondolni a szituációt. Tehát: régebben a UNIX megkérdezte az 5.5 szervert, hogy mit tudsz, öcsi? Mivel az nem tudta a 8bitmime-ot, elküldte a leveleket 7bitesen kódolt csatolásokkal – ezt meg még a smarthost is értette. Csakhogy bejött az 5.5 helyett a 2003, aki már azt mondta a Unix-os levelezőszerver kérdésére nagy arccal, hogy nyomjad Gézám 8 biten, bírom én a strapát. És utána esett pofára, amikor a smarthost nem bírta tőle átvenni. Persze intelligens levelezőrendszertől talán el lehetne várni, hogy ilyenkor átkonvertálja a csatolást… de ezt a magasságot inkább kihagyták a fiúk. Majd az E12.
No, mindegy, az Exchange visszadobott egy ‘message content’-re vonatkozó NDR-t és ráfogta a nyuszira.
Ekkor vettem hasznát az ESMTP kiajánlást részletező KB cikknek. Ugyan elég pilótavizsgásnak tűnt a helyes érték kikalkulálása, de szerencsém volt, mert véletlenül(?) pont a 8bitmime eltüntetését hozták fel példának. Már csak be kellett írni. Hová? Hát persze, a Metabase-be. De már tudjuk, hogy a Metabase képes – részlegesen – visszaszinkronizálódni az Active Directory-ból, azaz nyomulhatunk a jól megszokott ADSIEdittel is. A szokásos teaszünet, gyors telnet teszt és tényleg, már nem sorolja fel az Exchange2003 az ismert parancsok között a 8bitmime-ot.
Éles teszt, hurrá.
És a Unix-os srác is visszacsavarta a széklábat a helyére.

ps: Csak megjegyzem, hogy most éppen Zappa “The torture never stops” számának maratoni koncertverzióját hallgatom.

Egyszerű másolás

Nem, nem akarom, hogy ez Exchange blog legyen. Az, hogy én mostanában mindig ezzel akadok össze, az csak egy gonosz tréfa.
A hétvégén egy teljesen egyszerű feladat várt rám: volt egy marha nagy adatbázis, szét kellett szedni négyfelé. Tipikus klaty-klaty-klaty, egykisdombralecsücsülünk munka.
(Emiatt is volt ilyen sok időm irkálni.)
Az első négy postafiók simán átment. Az ötödik már ránézésre sem ígért túl sok jót, lévén 4.6 GB a mérete. (Egész egyszerűen nem tudom elképzelni, hogyan lehet ennyi levelet összeszedni. 1997 óta tárolom pst-ben a leveleimet és rajta vagyok egy talicska levlistán – jó részükön pusztán archiválási célból -, de így is csak 3 darab cédé méretű pst-m van. Küldtek neki egy dvd image-et csatolásban?)
No, jól sejtettem, a postafiók 2 óra alatt átment, aztán a directory rendezésnél 2 újabb óra után gyanús lett, hogy befagyott a másolás. Nyomtam egy cancel-t -> ha lehet, még jobban befagyott. Telefon egy kollégának, aki tavaly nyáron már csinált ilyet: persze, jött a válasz, szokott ilyesmi történni. Task manager, kilőni, és valahogy visszahegeszteni az adatbázist. Sajnos többre nem emlékszik.
Folytattam a másolást. 10 embernél nem tudta megnyitni a mailboxot: elvettem tőlük, majd a kósza postafiókokat visszaraktam a hátukra. Egyből meg tudta nyitni. (Volt egy 11.8 GB méretű postafiók, 220000 levéllel. Ezzel nyolc órát mókolt. Végül 20 percbe tellett, mire másolás után lezárta: ezalatt a 20 perc alatt őszültem némiképp.)
Végül már csak ketten maradtunk a porondon: a 4.6 GB méretű mailbox és én. Szembenéztünk egymással, a szél ördögszekeret sodort keresztül az úton. Hirtelen mozdulattal rávetődtem a billentyűzetre és megismételtem a másolási parancsot – de most egy másik adatbázisba. Két óra szuttyogás után megint behalt a másolás… Task Manager, kilőni. Most már 3 példányban volt meg a mailbox – és mind a 3 működött. Egyszerre. Ha elvettem az egyiket a felhasználótól, mind felszabadult. Ha visszaakasztottam rá az egyiket, akkor a többit sem lehetett törölni, mert azt mondta, hogy használatban van. A helyzet kezdett kínossá válni. Végül kimentegettem az anyagot pst-kbe, lecsatoltam a mailboxot, töröltem a két rosszat, a maradékot visszacsatoltam – és gyönyörűen működött. Nem sokat dobott a kedvemen, hogy közben megtaláltam a helyes megoldást: a behalt mozgatást kilövés után folytatni kell _ugyanabba_ az adatbázisba, amelyikbe elkezdtük. Szószerint azt írták, hogy az Exchange van olyan intelligens, hogy észreveszi a sikertelen másolás darabjait. Usually. Hát… engedtessék meg nekem a kétkedés joga.
Mindegy, most már csak rendszerpostafiókok voltak az adatbázisban és azt írta ezekről egy srác, hogy ez nem probléma. Igaz, hogy a System Attendant Mailbox a fő Exchange szolgáltatás postafiókja és az adatbázis törlésekor hőbörögni fog az Exchange, de nem kell vele foglalkozni. A szervíz újraindításakor le fogja gyártani. (Imádom, ezeket a finom jövőidőket. És ha nem?)
Ennek ellenére nem tudtam törölni az adatbázist. Az Exchange közölte, hogy ebben bizony még vannak. A szemgolyóm már összemaszatolta a képernyőt, de akkor sem láttam senkit az adatbázisban. Szerencsére az üzenetnek volt kódja, irány a net. (Hogyan boldogultunk valamikor Google nélkül? És internet nélkül…?!) Meglepetésemre ugyanannak a srácnak a blogjában találtam meg a választ, akinél korábban már jártam egyszer. Ezt már nem úszta meg, feliratkoztam.
A belinkelt KB cikk alapján előhúztam az ldp-t és megvizsgáltam az adatbázist: a rendszer postafiókok mellett még 5(!) postafiók volt benne. Miközben a kezelői felületen nem látszott egy sem.
Ekkor jött el az a pillanat, amikor sorbaállítottam az irodában a székeket és nekifutásból felrúgtam az elsőt.
A többi már úgyis borult magától.
A mutatvány meghozta az eredményt, ugyanis beugrott a magyarázat: az AD-ban addig nem létezik egy objektum, amíg nem kap értéket. Ha valakinek nincs levele, akkor nem fog látszani az admin felületen a postafiókja – még akkor sem, ha az adatbázisba beíródik, hogy ő bizony ide tartozik.
A többi már sétagalopp volt. Átmozgattam a nemlétező postafiókokat is, adatbázistörléskor ignoráltam a visítozást, SA szervíz újraindult és lám az SA mailbox be is mászott a VIP adatbázisba. Ott jó helyen lesz.
Még kihúztam diskpart-tal egy partíciót – nehogy már leessen a végére az adrenalin – és átmozgattam erre a partícióra az adatbázisokat. Gyors teszt, inkább csak a biztonság kedvéért: benéztem néhány postafiókba. Illetve, csak benéztem volna. De nem sikerült. Már rutinosan navigáltam a Firefox ablak jobb felső sarkába – és persze erre is meglett a válasz: nem, ne hidd el, hogy az Exchange felmountolta az adatbázist. Dismount, mount – és már működik is minden.

Jó mulatság, férfimunka volt.
20 óra hétvégi munka feljegyezve.
Úgy, hogy magát a szétrángatást váltott műszakban végeztük egy kollégával.

Amikor a logika már szaltózik bukfenc helyett

Hihetetlenül ráérek, így leírok egy másik esetet is a korábban említett átállásból.
Exchange5.5 rendszert upgradeltünk 2003-ra egyik ügyfelünknél. Az SMTP konnektor (illetve a korábbi Internet Mail Service – IMS) nem közvetlenül kapcsolódik az internetre, hanem egy Symantec SMTP gateway ( a továbbiakban SSGW) vállalja magára az ezzel járó fáradalmakat. Azaz a részfeladat: van egy – egyébként korrekten működő – 5.5 IMS, melyet ki akarunk lökni a smarthost elől és egy 2003 SMTP konnektort (továbbiakban SC-t) tennénk a helyére.
Szépen felhúztuk az új szervert, első körben ráállítottuk a bejövő forgalmat, feltettük az Archive sinket, leszkripteltük a mailarchív biztonságos helyre mentését – remekül működik. (Illetve elsőre nem, de ez majd egy másik cikk lesz.) Jöhet a kifelé menő levelezés átállítása: névtér átír, forgalom átmegy – és bedugul. Miaf…?
Gyors ellenőrzés: mailbox server: queue üres; SC: queue tele; SSGW: queue üres. Tesztlevelek 10-200 perc között érkeznek meg és az SC queue folyamatosan dagad.
Ki a bűnös? Valszeg az SSGW, az szokott ilyesmiket csinálni. Konstans javítási mód: újraindítjuk. Semmi. Visszaállítjuk az e-mail routolást, az IMS 5 perc alatt kiszórja a leveleket. Most ki a bűnös? Talán az új SC?
Ilyenkor az első ötlet természetesen a névfeloldás átnézése: DNS, WINS, TCP/IP beállítások, route tábla, napfolttevékenység. Minden rendben.
Jó, akkor tartsuk be a Microsoft ajánlásokat.
Pontosabban a nem-ajánlásokat. Leinstalláljuk az Archive sinket (csak diagnosztikai célokra javasolják) és megszüntetjük a kifelé menő levelek feladó szerinti szűrését (egyáltalán nem ajánlják). Semmi változás.
Nézzük telnettel. Az SC-ről rámegyek az SSGW-re, a mail from beadása után elmegy vadászni és kb 1 perc után szól vissza, hogy sender ok. Tehát mégis az SSGW a hibás! Ellenpróba: ugyanezt megcsinálom az IMS-ről – és itt is befigyel az 1 perc várakozás! Várjunk csak… akkor az SSGW lenne a hibás, de az IMS ezt nagy ívben letojja, míg az SC megsértődik? Dehát ez az újabb termék!
Na jó, elő a netmont. Majd az eldönti. Először megszaglásszuk a jó forgalmat. Tesztlevél elmegy, az Ethereal szépen összerakja a levélhez tartozó forgalmat. Ugyanez a lassú forgalomnál teljes káoszhoz vezet: valami akkora dzsuvát rak össze az Ethereal _1_ levélnek, hogy az őrület. Arról nem is beszélve, hogy _nyoma sincs_ a tesztlevélhez tartozó csipcsipcsókának (SYN/ACK/ACK; copyright by FótiMarci) az egész fájlban! De hát… ez fizikai képtelenség!?
Itt döntöttünk úgy, hogy szoptunk mi már eleget, szopjon most már más is -> Microsoft Premier Support.
Az első másfél hónap meglehetősen nyugodtan telt. A magyar részleg bekért párszáz mega anyagot, majd továbbpasszolta az egészet a német csoportnak. Ők újra bekértek párszáz mega adatot és elmentek gondolkodni. Sajnos olyasvalakihez került az úgy, aki nem igazán állt a helyzet magaslatán. Folyamatosan jött a hülyébbnél hülyébb ötletekkel – dobjuk ki a Symantec gateway-t, használjuk a virtuális smtp szervert az smtp konnektor helyett, meg ilyenek. Látszott, hogy fogalma sincs, mi történik a háttérben, de próbálkozott. Én meg nem győztem végezni a szemmel láthatóan vezérfonal nélküli kísérleteket. Végül levélváltásaink kezdtek túlmenni azon a határon, amit egészséges iróniának nevezünk – így egy másik mérnök vette át az ügyet.
Természetesen bekért párszáz mega anyagot. Aztán jött egy levél, amitől melléültem a széknek.
Azt írta, hogy az 5.5 IMS – erőforráspazarló módon – minden levélküldéshez külön sessiont nyitott. A 2003-ban ezt már átdolgozták, és alaphelyzetben minden session 20 levelet küld. (Ezért nem találtam a tesztlevélhez tartozó csipcsipcsókát – mert 20 levélhez tartozott 1. És ezért mutatta az Ethereal 1 levélnek a huszat.) Csakhogy. Ugye ott van az az 1 perc, amíg az SSGW ellenőrzi a mail from adatot. És addig a 20 levél nem áll össze az SSGW-n, amíg a huszadiknak is le nem ellenőrizte a feladóját. Na, ekkor küldi csak ki a köteget. Közben meg szépen torlódik az SC-n a queue.
Persze valami gubanc még ezenkívül is lehetett, mert valahogy össze kellett jönnie a mért 200 perces csúszásnak is – de a jelenség okozója a kötegelés volt, melyet az a jelentéktelennek tűnő 1 perces kivárás borított ki. Az 5.5 IMS ezzel nem foglalkozott: minden levél várt 1 percet, aztán ment tovább. Nagy ügy.
A workaround se volt akármi. Annyit beszélünk Exchange-dzsel kapcsolatban az AD-ról, meg adatbáziskezelésről, hogy az ember hajlamos elfelejteni, hogy az SMTP valahol az IIS része – tehát a működését befolyásoló paraméterek a Metabase-ben vannak(1). Nyilván nem mindegyik van kivezetve a grafikus felületre; többek között az sem, amelyik megmondja, hogy hány levelet küldjön egy sessionben.
Ha esetleg valakinek szüksége lenne rá, ezt a változót kell megkeresni: MaxBatchedMessages – és ki kell javítani az ott lévő értéket 1-re. (Vigyázat, két helyen is szerepel; és csak akkor történik változás, ha mindkét helyen átírjuk. És persze befigyel még az IIS Admin szolgáltatás obligát újraindítása.)

Ps: Természetesen ez csak a workaround. Az igazi megoldás az lesz, ha megtaláljuk, miért szuttyog annyit a feladóellenőrzés a ’smart’ hoston.

(1) Persze ez sem teljesen igaz. Erre az első újraindításkor jöttünk rá, amikor az AD-ból visszaszinkronizálódótt a Metabase-be az a bizonyos 20-as szám. A levelezés meg ismételten fejreállt.