Month: January 2009

Az okos lány

2009-01-30 / / 0 Comments

Aki jön is, meg nem is. Meg hoz is, meg nem is.

Jött a bejelentés az ügyféltől: amióta átmigrálták a postafiókját, azóta teljesen meghülyült a postafiókon belüli keresése.

Hmm. Mit tudunk?

Fél füllel hallottam róla, hogy az Exchange 2007-ben már nincs full text indexing, helyette mintha az oprendszer Windows Search szolgáltatását használná. Ennek némileg ellentmond, hogy ott figyel a szolgáltatások között a Microsoft Exchange Search Indexer… és valószínűleg nem csak azért van ott, hogy impozánsabb méretű legyen a szervízlista.
Mit tudunk még? A postafiók cefet nagy (ezért fontos nekik a keresés) – és a bejelentés előtt lett átmigrálva. Lehet, hogy még nem lett leindexelve? De a bejelentő azt állítja, hogy másnál is jelentkezik a hiba. Viszont tudjuk, hogy a bejelentők szeretik kivetíteni a bajukat a világra.
Még mit tudunk? Például azt, hogy a projekt magyar fázisának hajrájában vagyunk, ideges az ügyfél, idegesek vagyunk mi is (én meg aztán pláne) – egész biztosan nem fog beleférni az, hogy most pár napig ezen a jelenségen pörögjek. Végül át lett passzolva a probléma egy kollégának – de úgy, hogy azért követtem, mi történik.

Első körben reprodukálták a hibát. Sikeresen. Az idióta keresés megbízhatóan idióta volt kis postafióknál, nagy postafióknál, XP alatt, Vista alatt, Outlokból és OWÁ-ból, usernél is, atyaúristennél is. Egész pontosan így nézett ki a jelenség:

  • Egy konkrét kifejezés: B123456780. (Nem gépi kódban szoktunk társalogni, de a levelezéseinkben gyakran fordulnak elő case number-ek.)
  • Ha a teljes kifejezésre keresek rá, akkor megtalálja.
  • Ha leveszem az elejéről a ‘B’ betűt, akkor nem.
  • Ha leveszem a végéről a ‘0’-t, akkor megtalálja.
  • Ha köztes darabra keresek, akkor megint nem.

Kolléga sportolt rajta egy napig. Megrángatta a kapcsolati hálóját, feltúrta a netet… de minimális sikerrel. Addig biztosan eljutott, hogy meg tudtuk fogni a jelenséget. Az látszott, hogy a Windows Search került egyre inkább a célkeresztbe. Sikerült fájlnevekkel is reprodukálni az esetet. Kapott olyan visszajelzést, hogy igen, másnál is előfordult már ilyesmi. Aztán kapott olyan visszajelzést, hogy máshol, ahol szintén Exchange 2007 van, nem jelentkezik a hiba. Ergo van megoldás, csak annyira nem triviális.
Mivel az ügyfél kiemelt prioritással jelentette be az esetet, így 1 nap nyomozás után eszkaláltunk. PSS.

Lefutottuk a kötelező köröket, majd jött a határozott válasz: emberek, ez nem bug, hanem feature.
Tudom, ez már közhellyé kopott, de jelen esetben véresen komolyan gondolták a választ.

Exchange 2007 alatt ugyanis kétfajta search metódus is működik:

  • Exchange Search
  • Exchange Store Search

Melyik mit tud?

Exchange Search:

  • Gyors.
  • Szavakon, kifejezéseken, mondatokon alapszik.
  • Full-text indexet használ.
  • Csatolásban is tud kereseni, feltéve, ha van a szerveren megfelelő filter.
  • Érzéketlen a kisbetű/nagybetű különbségre.
  • Csak szöveg keresésére alkalmas.

Exchange Store Search:

  • Lassú.
  • A postafióktartalmat bitfolyamnak észleli, szekvenciálisan keres.
  • Index helyett folytonosan keres.
  • Nem keres a csatolásokban.
  • Érzékeny a kisbetű/nagybetű különbségre.
  • Nem szöveg jellegű tulajdoságokra is képes keresni.

Na, melyiket szeressük? A fejlesztők az elsőt, az Exchange Search keresést tették alapértelmezetté.

Csakhogy. A cikk végén jön a fekete leves.

Exchange Search and Localization

Localization support for Exchange Search is limited to scenarios in which the client locale matches the message locale (which must also match the language that is used in the message body). Exchange Search does not support instances where a single message has multiple languages embedded in the body or where the client locale is different from the message locale.
To get consistent results for localized searches, the following must be true:

  • An e-mail message must be written in a single language and that language must match the locale of the message.
  • The search expression must be in a single language.
  • The language must match the locale of the client computer, as identified by the connection to the server.

Na, kérem. Megérkeztünk. Milyen nyelven íródott az, hogy ‘B123456780’? Hát, izé. Ez bizony értelmetlen szó az Exchange Search számára.

A furcsa az egészben az, hogy valamennyire azért beindexeli, hiszen a teljes szót megtalálja. Ahogy a kolléga magyarázta – akinek a PSS magyarázta – az Exchange Search balról jobbra indexeli le a kifejezéseket. Tehát a fenti esetben megtalálja, ha a teljes szót írom be és megtalálja, ha balról tetszőleges számú karaktert írok be… de nem találja meg, ha hiányzik a szó eleje.
Feltéve, hogy egy nyelvet használunk a teljes levélben.

Mire jó egy ilyen kereső algoritmus?

Semmire.

Nekem egyből a tíz évvel ezelőtti pentiumos vicc jutott eszembe – amikor a procik bizonyos lebegőpontos műveleteket hibásan végeztek el.
– Mennyi 2+2?
– 5!
– Ez hülyeség!
– De milyen gyors voltam!

Szóval, erről ennyit. Úgy látszik, még mindig nem értik, hogy a keresés az alapvetően bizalmi dolog. Az ember azért használ keresőt, mert hatalmas, manuálisan már nem kezelhető kupacból kell előkeresnie egy konkrét elemet. Általánosan is elmondható, hogy ezek a kupacok akkorák, hogy lehetetlen leellenőrizni a keresőt, hogy tényleg megtalált-e minden előfordulást. Ergo elég csak egyszer rajtakapni az algoritmust, hogy hibázott… és onnantól mehet a kukába a keresőgép.

Szerencsére meg lehet változtatni az alapbeállítást, itt van hozzá a manuál.

ps. Számomra azért is volt nehezen értelmezhető ez az egész, mivel létezik korrekt megoldás a problémára. Igaz, kliens oldalon… de nem lehet zavarba hozni törmelék szavakkal sem.

Belehalni egy sajtóhibába

2009-01-22 / / 0 Comments

A projekt, mint egy elszabadult úthenger, száguldott tovább. Tegnap jutottunk el addig a lépésig, hogy növeljük a levéltovábbítás rendelkezésreállását, meg elosszuk a terhelést. Azaz berakjunk egy második HUB Transport szervert a meglévő mellé.
Hogy érthetőbb legyen az írás, összedobtam egy skiccet.

Nagyítás

Azaz van jobb oldalon egy CCR MBX szerver, előtte a HTS szerverek. A piros vastag vonal jelöli az Exchange 2007 – Exchange 2003 közötti routing group konnektort. Baloldalt pedig egy smarhost tartja a kapcsolatot a nettel. (A levegőben lógó vonalak egyéb, belső levelezési irányok.)
Kékkel jelöltem az újonnan berakott HTS szervert. HTS1 és HTS2 teljesen megegyező virtuális gépek.

Hogyan lesz ebből érdekes cikk? Hiszen a felállás egyszerű, mint a faék. Működnie kell, oszt jól van.

Csakhogy nem működött.

Abban a pillanatban, ahogy beraktam HTS2-t, bedőlt a kifelé menő levelezés – legalábbis a levelek jó része nem ment ki. A HTS2-n lévő várakozási sorokban pedig elkezdtek gyűlni a levelek. Egész pontosan így hívták az érintett queue-kat:

  • HTS1-xch2003
  • HTS1

A queue viewer azt mondta, hogy a legutolsó hibaüzenet ez volt:

451 4.4.0 Primary Target IP Address responded with :” 451 5.7.3 Cannot achieve exchange server authentication.” Attempted failover to alternate host but that did not succeed.Either there are no alternate hosts or delivery failed to all alternate hosts.”

Target IP. Valószínűleg a fejlesztőknek leesett volna a karikagyűrű az ujjukról, ha ki is írták volna, hogy jelen esetben ki is volt az a target, aki visszaröffent? HTS1? Xch2003? A smarthost?
Na, mindegy. Kezdjük el összerakni a kirakós játékot. A Google szerint ilyen probléma akkor van, ha Exchange 2007 szervert kötünk össze Exchange 2003 szerverrel (eddig jó) és a 2003-ason nincs engedélyezve az integrated autentikáció. Megnéztem, engedélyezve volt. Innentől a Google felejtős, más találat nem volt. Kénytelen voltam az eszemet használni.
A queue-k csak a HTS2-n látszottak. Viszont az első queue neve gyanúsan ugyanaz volt, mint az RGC-é. Lehetséges, hogy nem is az xch2003-2007 határon van a probléma? Mit is tanultunk az Exchange 2007 routolásról? Például azt, hogy queue at point of failure – azaz szállítási hiba esetén a levelek azon a szerveren várakoznak, amelyik legközelebb van a szakadáshoz.
Azaz nem az xch2003 és a HTS1 között van a hiba, hanem már a HTS1 előtt.

Nadehát… mi lehet itt? A közvetlenül egymás mellé bedugott két Exchange 2007 HTS szerver nem tud kommunikálni egymással?

Mindenesetre gyorsan lekötöztem az RSG lábát a HTS2-höz is (ez már nincs a rajzon), így a levelek nagy része huss, kirepült. De ettől a probléma nem oldódott meg. Hiszen még élt a HTS1 queue, és álltak ebben is levelek.

Jogos a kérdés, hogy ezek vajon milyen levelek lehettek? Milyen levelek azok, melyek a fenti rendszerben a CCR-en keletkeztek, a HTS2 átvette továbbításra, majd továbbküldte a HTS1-nek… hogy az továbbítsa vissza cuccot a CCR-nek. Elég bizarr kör, nemde?
Mit tanultunk még az Exchange 2007 routolásáról? Delayed fan out – azaz ha egy levélnek több címzettje van, akkor addig a pontig, amíg a levelek együtt mennek, lejátszódik egy direct relay, majd onnan megy minden csomag a maga útjára, további direct relay-vel. Azaz a vizsgált várakozási sorban azok a levelek álltak, melyeket olyan levelezési csoportoknak küldtek, amelyiknek volt tagja a CCR-en, de volt tagja vagy a külvilágban, vagy az xch2003 rendszerben… vagy bármelyik más célpontban. Ekkor lett volna egy direct relay a HTS1-re, majd onnan a CCR-en lévő postafiókoknak ment volna vissza is a levél.

De nem ment. Illetve…
Nyilván, telnet. Nyilván ‘ismeretlen parancs’ választ kaptam. Hogy mekkora biztonsági fenyegetést jelent Windows 2008 szerveren a default telepített telnet kliens… nem tudom. De én már sokadszor futok bele abba, hogy nincs… és már majdnem annyira frusztrál, mint az UAC.
Na, mindegy. Telepítve. Aztán boldogan telnetelgettem. És sikeresen. HTS2-n belépve, HTS1-re telnetelve, minden irányban elmentek a levelek. Csak a queue-ból nem ürültek.
Itt már kezdtem ingerült lenni.

Nézzünk már egy smtp logot. Hol is van? Az Exchange könyvtárban lévő smtpout könyvtár üres. Jó, akkor kapcsoljuk be az smtp logolást. Hol is kell?
Azt írják, hogy a logolást a send konnektoron kell beállítani.

Kérdés: hol van itt send konnektor? Egyáltalán, ki csinált itt send konnectort? Mert én biztosan nem.
Nem is kellett. Ugyanis amikor beteszünk egy AD site-ra egy második HTS szervert, automatikusan létrejön egy send konnektor a kettő között.
Megint tanulunk. Milyen send konnektorok is léteznek?

  • Explicit: Határozott ráutaló magatartással mi gyártjuk le, vagy a konzolból, vagy a shellből a new-sendconnector paranccsal. Jellegzetessége, hogy látszik: azaz mindkét menedzsment felületről nézegethetjük, konfigurálhatjuk.
  • Semi-explicit: Ugyan automatikusan keletkeznek, de a konnektorok látszódnak, konfigurálhatók. Tipikusan ilyenek az Edge szerver beállításakor az Edge-HTS send konnektorok.
  • Implicit: Automatikusan keletkeznek, nem látszanak, nem hozzáférhetők. Ha nem olvasgatnánk minden szabad percünkben Exchange szakkönyveket, nem is tudnánk róla, hogy léteznek.

Nyilván itt a legutolsóról van szó. Érezzük a bukfencet? Hogyan állítsunk be logolást egy olyan konnektorra, amelyhez semmi hozzáférésünk sincs? Marha egyszerű. Mint a viccben: rostáljuk át a sivatagot és ami fentmarad a rácson, az az oroszlán. Az alábbi írás szerint a következő parancsot kell kiadnunk, ha intra-organization send konnektort akarunk logoltatni:

Set-TransportServer “HTS2” -IntraOrgProtocolLoggingLevel Verbose

Ha kiadjuk… ugyanazt a kövér syntax errort kapjuk, mint amilyent én kaptam. A KB cikk ugyanis hibás. Kérjük le a get-help set-transportserver -full paranccsal a paraméterek listáját – és láthatjuk, hogy a helyes paraméter az -IntraOrgConnectorProtocolLoggingLevel. Ja, és ne lepődjünk meg, ha kigördül a képernyőről a szöveg. Nálam az EMS puffere 999 sor (több nem lehet), ebbe a paraméterlistának kábé a fele fért bele.

Viszont azt gondolom nem kell magyarázni, mi is történik. Azt mondtuk, hogy te, kedves HUB Transport szerver, logoljad lécci az összes send konnektorodat. És az összesben már benne van a szupertitkos is.
Transport szerver újraindít, ekkor ugye kénytelen megabajgatni a beragadt várakozási sort. Végre van log is. De milyen furcsa! HTS2 beehlózik HTS1-hez. HTS1 elsorolja, milyen kunsztokat tud. Majd páros lábbal kirúgja HTS2-t.

?

Gondolom, már hiányérzeted van. Miért nem ír ez a fazon a receive konnektorokról? Ordít, hogy ott lesz a hiba.
Először én is így gondoltam. Átnéztem többször is, az összeset.
– Milyen összeset? – kérdezhetnéd.
– Hát, a gyárit, meg a barkácsoltat – válaszolnám.

Miért is kell barkácsolni? Close Relay. Az ember a default (server) receive konnektoron állítja be, hogy a szóbajöhető IP tartományból mindenki bejöhessen, mindenféle autentikációt használhasson – eltekintve az anonymous hozzáféréstől. Emellett célszerű gyártani egy relay receive konnektort is, melyet úgy állítunk be, hogy ne kérjen autentikációt és engedélyezze az anonymous hozzáférést. De itt, a network fülön csak – és szigorúan csak – azokat a hostokat engedjük, melyek számára engedélyezzük a relay-t… és amelyek annyira rendszeridegenek, hogy kizárt velük minden együttműködés. (Tudom, ne mondjuk soha azt, hogy kizárt… mondjuk helyette azt, hogy egyik oldal sem akar annyi energiát beleölni a mutatványba, hogy összehozzunk egy tisztességes autentikációt. Inkább megbízunk egymásban.)

Nos, receive konnektorok többször is átnézve, ránézésre minden rendben. Pedig az eddigi nyomozásból 110 százalékra tudjuk, hogy kizárólag csak itt lehet a hiba.
Kiváncsiságból kikapcsoltam a relay konnektort. Abban a pillanatban kirepült az összes levél a queue-ból.

Oké. Akkor eddig megvolnánk. Idő? Még ma van. Igaz, éppenhogy csak. Mindenesetre a szemem már annyira kifolyt a helyéről, hogy amikor telefonálgatnom kellett, folyamatosan zárva tartottam. Addig is pihent.

Gyors mérleg: queue üres. Megvan a bűnös. Én viszont már használhatatlan vagyok. HTS2 lekapcsol, relay receive konnektor visszakapcsol. Ezzel el tud zakatolni az ügyfél… aztán holnap is nap lesz.
Hátha megálmodom, mi lehet a baj.

Nem hiszed el, megálmodtam.

Reggel felkeltem… és fogmosás közben lepörögtek előttem a konnektorokban lévő network listák. Bakker, a HTS2 mindkét receive konnektor szkópjában szerepel! Márpedig a relay konnektor a szigorúbb, tehát az lesz rá érvényes… ekkor viszont nem lesz engedélyezve számára az Exchange autentikáció!

Napközben volt éppen elég más dolgom is, az összeszedettség szobrát sem rólam mintázták volna, de délutánra összevakartam magam. (Két redbull, meg egy vizespohár kávé.) Háromkor bejelentettem, hogy éles teszt. A kollégáimnak elszürkült az arcuk. Szerettek volna otthon éjszakázni.
Lecsökkentettem azt az IP tartományt a relay receive konnektoron, mely magába foglalta a HTS2-t is. Majd bekapcsoltuk a HTS2-t. Queue viewer… és gyönyörűen üres.
– Na látjátok, nem kell beszarni – nyugtatgattam a többieket – megy ez.
Már majdnem pezsgőt bontottunk, amikor megjelent az első kézbesítetlen levél a HTS1 queue-ban.
– Miaf? – néztem bambán. Hiszen annyira biztos voltam az elméletemben.
– Figyelj, még egy olyan délutánt nem engedhetünk meg magunknak, mint tegnap – figyelmeztettek.
– Oké, tíz levélig elmegyünk. Ha addig nem tudom megoldani, akkor letiltjuk a relay konnektort és leállítjuk a HTS2-t.

Körülbelül hat levélnél jártunk, amikorra kiszúrtam, hogy a relay receive konnektor network listájában direktben is fel volt véve a HTS2 IP címe. Nyilván a tegnap esti eszetlen rodeó egyik fázisában tehettem egy bátortalan kisérletet. Gyorsan töröltem, pár perc várakozás – és a queue kiürült.
Győzelem. Ugyan vártunk még egy félórát, mielőtt megfújtuk volna a harsonákat – de én már rögtön biztos voltam a győzelemben: hiszen kiürült a feltorlódott queue. Ez már nem fog még egyszer feltorlódni.

Hátravolt még a nyomozás: hogyan történhetett meg egy ilyen félrekonfigurálás?

Ezt is megtaláltam. Nem voltam boldog. Én gépeltem el… méghozzá az implementációs tervben. Egy A4-es oldal méretű táblázatban voltak felsorolva azok az IP címek, akiknek engedélyezve volt a relay. (Az értékeket az Exchange 2003 rendszerből kellett átvinni a 2007-be.)
A táblázat valahogy így nézett ki (az értékek nem valósak):

  1. 192.168.100.0/24
  2. 192.168.101.0/24
  3. 192.168.102.0/24
  4. Meg vagy hatvan szóló IP cím

A harmadik helyen a jó érték az lett volna, hogy 192.168.102.0/25… azaz csak a tartomány alsó felének volt engedélyezve a relay. A HTS2 pedig ugyanezen tartomány felső felében volt.
És amennyire precíz vagyok, az implementáció során pontosan ezt a táblázatot pötyögtem be – így került bele mindkét konnektor szkópjába a HTS2.

Shame on me.

Tudom, a következőket fel lehet fogni egyfajta racionalizálásnak is… de ez nem fog visszatartani attól, hogy elmélkedjek egy kicsit az eseten.

Jó-e egy ilyen hiba a projektben? Dühöngjünk-e miatta? Vagy – és most nagyon meredeket mondok – örüljünk-e egy ilyen hibának?

Én az utóbbira szavazok. És nem csak azért, mert pontosan ezt állítja a talán legkedvesebb könyvemben – A zen és a motorkerékpár ápolásának művészete – Robert Pirsig is… hanem azért, mert én magam is ebben hiszek. Ha belefutsz egy hibába, és ellövöd rá az összes töltényedet, de a hiba makacsul megmarad… akkor ujjonganod kell. Mert a hiba rá fog kényszeríteni arra, hogy átlépd a határaidat… hogy olyan fegyvereket, olyan harcmodort találj ki, melyeket korábban nem ismertél. Az ilyen hiba tágítja a gondolkodásod horizontját.
Most például a valóságban is találkoztunk olyan – korábban csak elméletből ismert – jelenségekkel, mint a ‘queue at point of failure’ vagy a ‘delayed fan out’… megtanultuk, hogyan lehet send és receive konnektorokat logolni… és egyáltalán, elmélyedtünk a levéltovábbítás módjában, beleégettük a gondolkodásunkba a folyamat felépítését.
Innentől jobban fogjuk érteni, mi is történik a mélyben.

Unalmas, szmogos délutánokra

2009-01-13 / / 0 Comments

Egy korábbi írásban Zoli már pedzegette, hogy vannak ám bizonyos anyagok a háttérben, csak éppen még búvópatakként búvnak.

Eddig.

Nagy örömömre szolgál megírni, hogy az Exchange Portálon Szabolcs elérhetővé tette a teljes oktatási anyagot, melyet még tavaly állítottunk össze, az Informatika Tisztán sorozaton belül. A téma: csoportmunka, azon belül is – na ki találja ki? – az Exchange szerver.

Adatbázis rodeó

2009-01-13 / / 11 Comments

Ez egy érdekes alkalom. Tulajdonképpen le kellene írnom egy esetet… de a jelenséget Zoli már leírta, a megoldási lehetőségeket pedig bőségesen kitárgyaltuk a kommentek között.

Akkor mit akarok én itt?

Hát, például összefoglalni. Meg fut éppen egy projektem – és ez a szívás is része volt. Szóval, hajrá.

Karácsony előtt járunk. Az erdő szélén farkasok üvöltenek, a plázákban meg a tolakodó emberek – azaz igazi karácsonyi hangulat van. December 19-én, pénteken az utolsó címlistát is benyeleztem, elégedetten toltam hátra billentyűzetet. Idén is megtettünk mindent, amit ember tehetett. Meg egy kicsivel többet is. Hazamentem. Pihenni. (Mwhaha.)

December 20. Aranyvasárnap szombatja. Az ajándékozási ösztön már a levegőt is kiszorította a plázákból. Mivel mi idén nem vettünk senkinek semmit, angyali békességben készültünk a karácsonyra. Főzőcskéztünk, tettünk-vettünk.

Aztán csörgött a telefon. Kollégám keresett. Hogy mozgatná a postafiókokat, de kardjába dőlt a szerver. Betelt a logpartíció.
– Te, be kellett volna kapcsolni a circular loggingot – korholtam meg enyhén – hiszen mondtam is.
– Bekapcsoltam.
– Igen? Hm… Most is be van kapcsolva?
– Persze.
– És a logok ennek ellenére is kidagadtak a fazékból?
– Ki bizony.
– Hm… ez érdekes. Miaf?
– Ja.
– Oké, elöször rakjunk rendet, nyomozni ráérünk utána is. Csapjatok pár gigát a partícióhoz, mountoljátok fel az adatbázist, kapcsoljátok ki-be a cirkuláris logolást. Ennek meg kell ennie a logokat.

Így is történt.

Kolléga hívott kicsit később.

– Rendben, működik.
– Örülök. Találtál valami nyomot?
– Igen. Az ügyfélnél tesztelnek egy webes ügyfélszolgálati programot. Beismerték, hogy véletlenül ráküldtek 180000 levelet a rendszerre.
– Hogy az a @&xß$…! Hát ezek teljesen meghülyültek? Migráció közben? Úgy, hogy nem is szóltak?
– Azt mondták, véletlen volt.
– Ennél még a fiam is fantáziadúsabb kifogásokat tud! Na, mindegy. A lényeg, hogy túléltük. Akkor most minden oké?
– Ja.
– Akkor hajrá. Migráljatok tovább.

Vissza a karácsonyi hangulatba. Finom ebéd, Nej remekelt. Szieszta.

A telefon csörgése ébresztett.

– Te, megint betelt a log partíció.
– Mfmvmf?
– Megállt az Exchange cluster. Betelt az egyik log partíció.
– Asztakurva.
– Mit csináljunk?
– Amit délelőtt is. Meg hívd fel a tesztelőket és helyezz kilátásba egy élvekibelezést, ha nem mennek legalább két méter távolságba a billentyűzettől. Mondjuk, egy évig.
– Oké.

Innentől nem is volt baj, egészen január 5-ig. Az új év első munkahelyi hívása útközben ért. (De még mindig jobb volt, mint tavaly.)

– Megint betelt a log partíció.
– Micsoda? Mi az, hogy log? Meg partíció?
– Exchange szerver. Tranzakciós log. Kaput. Finito. Konyec.
– Ja, már rémlik. Tudjátok, mit kell csinálni. Hamarosan bent leszek. Ja, és le kell ordítani a hajat a tesztelőkről. Egyáltalán, tesztelnek most?
– A service fut.
– Leállítani!
– Oké.

Cifrázta a helyzetet, hogy mind december 20-án, mind január 5-én mentés teszt is volt. Nem is akármilyen téttel. Nem is akármilyen mentésé.
CCR rendszerről van szó és én VSS alapú mentést álmodtam a passzív node-ra. Mert így egyfelől meg lehet növelni az adatbázisméretet (el se hiszed, milyen kevés betű van az angol ABC-ben), másfelől így az a rövid éjszaka is elég lesz mindenre. Egy valamivel nem számoltam: ez a mentési mód teljesen új volt az ügyfél rendszerében, hiányoztak a tapasztalatok, hiányoztak a kliens szoftverek. Rengeteget kellett volna tesztelnünk. Csakhogy akárhányszor elindítottunk egy mentést, annyiszor vadult be a legelső adatbázis. És ekkor már két hete ment a rendszer, kezdtek üzemszerűen is feltelni a log partíciók.
Csak nem a mentés lenne az, ami behülyíti a rendszert?

Ebben az állapotban olvastam újra Zoli írását. Nem-e lehet-e? Tudom, ezzel már hárman ülnek a gyanúsítottak padján… de mind a három eléggé esélyes.

Az első kettővel túl sokat nem tudtam kezdeni. Maradt a harmadik.

Eleve itt van a Snefi által linkelt KB cikk. Elolvastam. Hajjaj, de hányszor olvastam el. És folyamatosan úgy éreztem, ez a recept arra, hogyan lehet birkavesével földrengést előídézni. Mi köze lehet egy operációs rendszer hibájának ahhoz, hogy bizonyos nyelvi beállítások esetén elhasal rajta az Exchange 2007 adatbázis-motorja?
És mi az a másik, rejtélyes patch, melyet Snefi említett?
Oké, hívjuk a PSS-t.

Rövid idő alatt ki lettem kupálva. (Bigup for Madaras Gábor.) Tehát tényleg van egy operációs rendszer szintjén előbukkanó hiba. Ez egy olyan hiba, mely – bizonyos nyelvi beállításoknál – az Exchange ESE motorját végtelen ciklusba zavarja. Meg lehet figyelni, amikor bevadul a log, igazából nincs is levelezési tevékenység. (Check the Message Tracking Log.) A patch javítja a hibát… de nem javítja az adatbázist. Ez ugyanis olyan, mint egy vírus: ha egy adatbázis bekapja, akkor vége. Hiába gyógyul meg a szerver, az adatbázis élete végéig köhögni fog.
Két megoldás létezik rá:

  • Gyógyszert adunk az adatbázisnak.
  • Megöljük az adatbázist.

Én, személy szerint, az utóbbi megoldást favorizálom. Valahogy… olyan véglegesebb.

De nézzük először az első megoldást. A gyógyszert úgy hívják, hogy interim fix. Azért interim, mert menetközben lett rajtakapva. Tudni kell, hogy a csomag, amelyből majd a rollup pack lesz, az idők során folyamatosan gyűlik. Amíg nem lesz belőle végleges Rollup Pack, addig interimnek hívják.
Azaz az a javítás, mely kikúrálná az adatbázisunkat, jelenleg még csak interim formában létezik. Ráadásul RU7 formában, azaz saccra csak nagyon sok hónap múlva lesz véglegessé. Miközben az interim patch nem egy barátságos jószág, de nem ám. Például nem lehet Rollup Pack-ot telepíteni rá. Ha feltennéd, akkor – mivel ez egy RU7 interim, eleve le is mondhatsz a RU6-ról. Hadd ne részletezzem, mennyi balhé lehet ebből, akár csak a legegyszerűbb PSS eszkaláció esetén is.

Szóval inkább akasszuk fel.

Ehhez bizony neki kell gyürkőzni. A felakasztás ugyanis egész konkrétan offline defregmentálást jelent. Miért is? Mitől gyógyíthat egy tömörítés? Attól, ahogyan tömörít. Az offline defrag ugyanis nyit egy új, temporary adatbázist, ebbe elkezdi átmásolni a még értelmezhető leveleket. Amelyeket nem tud értelmezni, azokat kihagyja. Kihagyásra kerül minden szemét, minden sérült ezmegaz. Csak azok az itemek kerülnek át, amelyek teljesen jók. (Ez a folyamat időnként meglepően pici új adatbázist eredményez. Ezért kell feltétlenül menteni is előtte.) A legvégén pedig törli az adatbázist, a temporary-t pedig átnevezi. Ezzel a módszerrel a fertőzés tuti kiesik, hiszen azt a másoló folyamat sem képes átvinni.
Miért nem vadul be offline defrag közben az adatbázis? Azért, mert ekkor az adatbázsi le van mountolva. Az Information Store service nyüsszögve kussol a sarokban.

Frissítsük csak fel, hogyan is van ez?

Az Exchange adatbázis-kezelésének legmélyén van egy ESE motor. Ez egy nagyon primitív motor, kifejezetten egyszerű utasításokat képes megérteni. Ez fölött van egy database layer – tulajdonképpen címfordítási céllal – majd jön a DSA, mely képes minden hozzáfordulóval megtalálni a közös hangot… és képes a kéréseket lefordítani az ESE hótprimitív nyelvére.

Nagyítás

Tudom, ez nem Exchange. Ez Active Directory. De ne felejtsd el, hogy az utóbbi az előbbiből nőtt ki.

Tehát, a lényeg az, hogy az ESE szempontjából az Information Store is csak egy ügyfél a sok közül. És amikor lemountolod az adatbázist, akkor az IS elveszíti fölötte a hatalmát.
Jöhetnek a többiek, az offline adatbázis-matyizók. Mint például az eseutl. Ez ugyanúgy a DSA-t keresi meg, konkrét kérdésekkel, mint az IS. De mégsem IS.

Tehát ha offline tömörítesz, akkor menetközben védve leszel ettől a misztikus hibától. Ráadásul a végső adatbázis is tiszta lesz. Nem kell vacakolnod az interim fix okozta megkötésekkel.

Ql.

Akkor mi a probléma?

Az idő. Az ügyfelünk magyar viszonylatban a felső-közép kategóriába tartozik, összességében 500 GB adatbázissal. A Microsoft szerint az offline defrag 5-10 GB/óra sebességgel tép. Ez testvérek között is 50-100 óra leállást jelent az ügyfélnél. Ha esetleg nem lennél jó fejszámolásban, akkor ez 2-4 nap. Levelezés nélkül.

El tudod képzelni?

Muszáj lesz. Ez az egyedüli értelmes kiút. Telepíteni kell a patch-et, majd offline defrag-gal gyógyítani az összes adatbázist. Az interim fix… több megkötést hoz, mint amennyi előnyt a leállás nélküli javítás jelentene.

Tesztelve.

Exchange kívánságlista

2009-01-05 / / 3 Comments

Új évet kezdtünk. Én az új évvel egyetemben elkezdtem a régi saját blogom költöztetését. Miután a régi cikkeimen módosítani is akarok, nem egyben pakoltam át mindent, hanem a bejegyzéseket átnézve egyesével rakosgatom át.

Ennek kapcsán belefutottam egy régi cikkembe:

http://www.it-pro.hu/Blogs/tabid/94/EntryId/22/Exchange-kivansaglista.aspx

Ez egy amolyan óhaj lista volt, hogy én mit látnék szívesen az akkor még E12 kódnéven futó jelenleg Exchange 2007 néven létező termékben. Ma, az Exchange 2007-et ismerve, az E14-et várva újra arra adnám a fejem, hogy összeállítsak egy kívánságlistát.

A régi vágyaim:

“Programozható, dokumentált OWA felület. Legalább olyan szinten dokumentált és testreszabható legyen mint az Outlook, hiszen egyre többen már csak ezt használják és ebből következően a mai helyzetben, az Outlook hozzáfejlesztések nem érhetők el az OWA-t használók számára.”

Erről nem tudom, hogy megvalósult-e mert az elmúlt időszakban nem foglalkoztam az OWA testreszabásával. Annyi biztos, hogy ASP.NET lett belőle, valamint webpart-okat használ, így gyanítom, hogy egyszerűbben lehet hozzányúlni.

“SQL motor a JET engine helyett. Tudom, ez nem fog bekövetkezni, de akkor is leírom”

Valóban nem valósult meg, sőt, a következő verzióban sem fog bekövetkezni. Azt az információt kaptam róla, hogy a jelenlegi SQL típusú adatbáziskezelők egyszerűen nem alkalmasak az itt ellátandó feladatra, ebből következően nem óhajtják megfizetni azt a teljesítménycsökkenést, mint árat, amit az átállás okozna.

“Az SMTP szerver jobb scriptelhetősége. Szeretném elérni, hogy ne csak a jelenlegi OnArrival ponton lehessen scriptből beavatkozni, hanem a többi EventHandlernél is.”

Ez meg is valósult, meg nem is. Az SMTP szerver megszűnt scriptelhető lenni, ugyanakkor a programozói felületét közelebb hozták egy olyan botcsinálta kóderhez, mint amilyen én vagyok. Az egész motor .NET-ben programozható.

“A több e-mail címmel rendelkező felhasználók korrekt kezelése. Értem ez alatt, hogy az alapértelmezettől eltérő címekkel lehessen levelet küldeni, a különböző címekre beérkező levelekről a felhasználó lássa, hogy melyik címére érkezett, az elküldött elemek szétválogathatóak legyenek.”

Ennek sajnos nyomát sem látom. Az igény még mindig fent áll, jó lenne, ha a következő verzióban történne valami. Ezt újra felteszem a listámra.

“A scripting egységesítése. A különböző pontokon lévő scripting engine jelenleg különböző tudással rendelkezik. Pl. a Store Eventeket és az Outlook formokat csak VBScriptben lehet megírni. Az SMTP-nél és a WSHnál működik a JScript is.”

Hát ez az egész kérdés megváltozott, hogy úgy mondjam okafogyottá vált. A programozói felületek átmentek .NET-be, Web Service-ekbe, a management felületek pedig PowerShell-be.

Ennyit a múltról. Most jöjjön a jövő. Mit szeretnék a következő verziótól:

– Először is a fentiekből származtatva: A több Exchange e-mail címmel rendelkező felhasználók kezelése.

– Jogosultság kezelés az OWA felületen. Ez talán az egyik legnagyobb hiányossága a webes felületnek az Outlookhoz képes.

– Nem egészen Exchange, de szorosan kapcsolódik: egy normális html viewer/editor az Outlookba. A jelenlegi Word-os verzió egy katasztrófa. Erről bővebben itt: https://www.emaildetektiv.hu/2008/09/11/outlook-2007-es-a-html/

– Jogosultság kezelés a grafikus management felületen (EMC). Ami jelenleg van, az igen gyenge.

– Natív import/export megoldás a store-hoz (ez az import-mailbox, export-mailbox a kötelező 32 bitjével és kötelező telepített Outlookjával egy vicc)

– Normális, egyszerű, API felület a MAPI-MIME (TNEF-HTML) konverzióhoz. A jelenlegi állapot nem egészen kielégítő. Ezt a konverziót belül az Exchange maga megoldja automatikusan, ugyanakkor, ha API-n keresztül ez nem érhető el.

Nekem így hirtelen ennyi jutott eszembe magamtól.

Kéretik kommentezni, megköpködni, kiegészíteni!!!