Category: 2007

Bizonytalan vagyok. Vagy nem?

2009-07-08 / / 2 Comments

Van egy CCR rendszerem, rengeteg adatbázissal. A hiba: az egyik adatbázis nem mountolható. A copy status: initalizing.
Vizuális vizsgálat: az adatbázis is, a logfájlok is szépen a helyükön vannak. Átnéztem a passzív node-ra… ott is.

Oké, mountoljuk fel. Nem megy, kiírja, hogy hiányzik neki egy logfájl. Nem mondom, hogy a popsimat vertem földhöz örömömben, de éreztem egy kis kellemes bizsergést. Itt van, végre élesben is ki lehet próbálni, mit ér a CCR. Az update-storagegroupcopy parancsot használtam már annyit a passzív node-on, hogy unom – ezzel szemben most van lehetőségem először alkalmazni a restore-storagegroupcopy parancsot az aktív node-on.

Azt írta ki, hogy ‘database was already marked as available for a mount, no action was taken‘. Azaz szerinte minden frankó, ez egy mountolható adatbázis.
Még egyszer megnéztem a passzív node-ot, megvolt az adatbázisról és a logfájlokról a replika. Oké. Fogtam, kitöröltem az aktív node-on az adatbázist.
Na, erre legyen bőr a képeden azt mondani, hogy mountolható!

Azt mondta.

Letöröltem az összes logfájlt is. Újabb restore. Megint azt mondta, hogy minden rendben, ez egy mountolható adatbázis. Miközben se adatbázis nem volt a partíción, se egy nyomoronc logfájl.
Irígyeltem az optimizmusát.

Futottam még egy bátortalan kört, hogyan lehetne _mindenképpen_ ráfuttatni a restore parancsot… de nem lehet. A -force kapcsoló sajnos nem ezt jelenti.
Törődjünk bele, ha az Exchange úgy gondolja, hogy minden rendben, akkor nincs visszaállítási lehetőséged. Még akkor sem, ha tokkal-vonóval hiányzik az egész adatbázis.

Nyilván a körbedolgozás működött. Elindítottam egy failovert, a korábbi passzív node-on ezután már felállt a problémás adatbázis, fel is lehetett mountolni. Ekkor a korábbi aktív node-on, mely most ugye már passzív lett, ki lehetett adni az update-storagegroupcopy parancsot, melynek van egy bűvös -deletexistingfiles kapcsolója. Na, ez képes gyökeresen elrendezni a terepet, csak a sávszélesség bírja.
Aztán jöhetett egy failback, és újra minden rendben.

MI SE, még mindig

2009-05-26 / / 4 Comments

Tehát ott jártunk, hogy boldogan lejelentettük, miszerint itt van az összes cím, barátaim, feleim, levelezzetek.

Aztán jött az indignált újabb bejelentés. Oké, a cím ott van, de ha levelet küldenek neki, akkor másodpercen belül hibaüzenet jön vissza. A levelet nem lehet kiküldeni.

Nézzük, mi is van az NDR-ben? A következő felhasználó nem létezik: IMCEAEX_******@cegnev.hu.
Naná, hogy nem. Szépen is néznénk ki, ha létezne. Ja, hogy mi is ez az IMCEAEX***? Írtam már róla, olvasd el bátran. De ha nem akarod, rövid összefoglalás: ez egy kapszulázás. Ha valakinek nincsen SMTP címe, akkor az Exchange az egyéb címéből (x.400) szigorú szabályok alapján gyárt egy meglehetősen bonyolult smtp címet, majd ezzel küldi el a levelet. Aztán a válasznál meg – a szigorú szabályok ismeretében – kikapszulázza, azaz az IMCEAEX_****@cegnev.hu címből visszafejti az x.400 címet és oda küldi tovább a levelet.
Nos, ez mind szép, de hogyan kerül ez a sáros bakancs az asztalra? Itt a _címzett_ kapott IMCEAEX címet! Az Exchange 2007 ennyire optimista lenne? Azt mondja, nem lát a címzettnél SMTP címet, tehát abszolút vaktában hasra üt, legyárt egy IMCEAEX_****@cegnev.hu címet és bízik benne, hogy ha a túloldalon kikapszulázzák, akkor pont lesz olyan x.400-as cím? Bizony, így. Ne tudd meg, mennyi felháborodott levelet kaptam, hogy honnan meri az Exchange a @cegnev.hu tartományba küldeni a török, cseh, lengyel és még mittudoménmilyen leveleket? Hát ennyire hülyék vagyunk?

Ehe. Mosoly nyáladzó szájszéllel. Igen, reménytelenül debilek vagyunk.

Aztán elkezdtem kisérletezgetni… és a helyzet egyre durvább lett. Küldtem egy új levelet. Kiválasztottam a címzettet a Worldwide címlistából. Kiváncsiságból ránéztem a tualjdonságlapjára, gyönyörűen ott voltak a tulajdonságai, köztük a jó SMTP cím is. Oké. Elküldtem. Már jött is vissza az NDR, benne az IMCEAEX-es címmel.

Miaf?

Eljátszottam ugyanezt OWA-ból is. Tökéletes. A levél elment. Hát ezt meg hogyan? Elméletileg mindkét levél ugyanazt az útvonalat kell, hogy bejárja. Hát itt már semmi sem úgy működik, ahogyan működnie kellene?

Nézzük meg EMC-ből, látjuk-e az összes kontaktot. Feljött egy hibaüzenet. Lehet, hogy pont a mi emberünk sérült? A hibaüzenetre kattintva üres ablak jött elő. Hmm… lehet, hogy 40000 kontaktnál várni kell egy kicsit? Otthagytam éjszakára. Másnap reggel még mindig üres volt az ablak. Hmm. Ott van egy üzenet az alján, hogy a ‘ctrl+c’ kiteszi vágólapra a szöveget. Legyen. És tényleg, a notepad-ben már ott is volt a lista. Lehet, hogy valami idióta fehér betűkkel írta ki az ablakban fehér háttérre a listát? Már ezen sem lepődnék meg. Mindenesetre kellemetlen, a keresett cím nincs a hibások között. (Megjegyzem, itt is látok cuclizási lehetőséget: a hibás címek azért hibásak, mert space van a display név elején, illetve végén. Főbelőni. Mindet.)

Egy gyors, de bátortalan pillantás a GC adatbázisba. (Ugye tudod: ldp, a 3268-as porton.) Ott volt szépen a kontakt.

Eddig tartott a dal. Habár szívesen elmolyoltam volna még napokat a problémán, de mivel priority2-vel jelentették be, így ha nem akartam SLA-t sérteni, eszkalálnom kellett. PSS.

Hosszú beszélgetések. Lista, hogy miket küldjek el.
Aztán az ldp dump-ban a Sólyomszem Brigád kiszúrta, hogy a vizsgált kontaktnak üres a legacyExchangeDN értéke. (Konkrétan, nem szerepelt a dump-ban. Ugye tudjuk, hogy az ldp csak azokat a tulajdonságokat listázza, melyeknek van értéke.) Szinte hallani lehetett, ahogy a felfelé görgetett kőgolyó átbillent a csúcsponton.
– Ez baj – hívott vissza a mérnök.

Adtunk a kontaktnak. Mármint értéket.

Itt kellett megemelnem a kalapomat. Azt, hogy üres a legacyExchangeDN – különösen a korábban belinkelt cikk alapján – valószínűleg előbb-utóbb én is megtaláltam volna. De mit kellett volna beírnom? A kontaktnak volt vagy tíz x.500-as címe. Melyik legyen a legacyExchangeDN?

A mérnök segített: egyik sem. A legacyExchangeDN mindig a _helyi_ objektum helyzetére vonatkozik. Hiába tolják ki ugyanazt a kontaktot Amerikából Japánba, Grönlandra és Budapestre – a legacyExchangeDN értéke mindenhol más és más kell, hogy legyen. Míg az x.500 címe pedig annak a nyomát mutatja, hogy az objektum honnan hová lett migrálva.

Itt kezd a szituáció logikussá válni. Az elején, mondjuk, nem néztem volna ki belőle. Hogyan is működik a MIIS? Legyártja a távoli címtárban a kontakt objektumot. Ír neki legacyExchangeDN értéket? Hát, miért írna, amikor arra találták ki a helyi RUS-t? Majd amikor az végigmegy a recipienteken, akkor beírja a helyes értéket. (Hasonlóképpen békén hagyja a ShowInAddressBook értéket is. Ezt majd beállítják a helyiek.)

Ja, hogy az Exchange 2007-ben nincs RUS? Cucl.

Megoldási lehetőségek?
Elvégezni a RUS munkáját – azaz valamilyen jól definiált pontban mindenhová, ahol üres a legacyExchangeDN mező értéke, beírni a jó értéket. Yep. Mi lesz a jól definiált pont? Hát, nemrég derült ki, hogy az MIIS szinkronizáció után úgyis szkriptből kell frissítenünk a címlistákat. Akkor nincs is más hátra, mint ki kell bővíteni a szkriptünket.

Ja, a legszebbet meg nem is mondtam. Honnan tudod, hogy az adott környezetben mi lenne a kontakt helyes legacyExchangeDN értéke? Mindegy. Nem kell tudnod. Elég, ha felolvasod a kontakt objektum tulajdonságait, majd visszaírod. Ekkor a rendszer automatikusan beírja a legacyExchangeDN értéket.
Így: get-mailcontact “user-alias” | set-mailcontact.
Nyilván, tömeges módosításnál játszani kell a szkóppal (nem elég az alias), meg illenék rá is vizsgálni, hogy üres-e az érték vagy sem… dehát ez már mind iszonyúan részletkérdés.

MI IS helyett MI SE

2009-05-25 / / 6 Comments

Irkáltam már arról az ügyfelünkről, akik kinyitották a szelencét és rájukborult 40000 kontakt. (Egyik, másik, harmadik.) Köszönik szépen, élnek még… de ez a rengeteg cím, melyet csak a dolgozók kb 5%-a használ, továbbra is komoly problémát okoz nekik.

Különösen úgy, hogy a közelmúltban álltak át Exchange 2007-re.

A legszebb ugyanis az volt, hogy elméletileg semmi problémát sem lenne szabad okoznia ennek a tömérdek címnek… de valahogy éreztem, hogy nem lesz ez olyan sima menet.

Akik nem akarják elolvasni a kilométer hosszúságú előzményeket, azoknak összefoglalom:

  • Trükkös módon a Global Address List mögött kicseréltem a keresőfeltételt, így csak a helyi címek kerültek bele. Ezt mindenki boldogan használta.
  • Létrehoztam egy Worldwide nevű listát, mely mögé odatettem az eredeti GAL keresőfeltételét. Ha az az 5% külföldre akarat írni, akkor címlistát váltott.

Még egy technikai előzmény. Az egyes nemzeti leányvállalatok között a címlista szinkronizáció úgy zajlik, hogy a tengerentúlon egy MIIS szerver felolvassa a felhasználók smtp és egyéb címeit, beledolgozza egy adatbázisba, majd mindenkinek a címtárába visszatolja a címeket, mail kontakt objektum formájában. Ez az a bizonyos negyvenezer, ki dalolva ment.

Az átállás után kezdtek rendeződni a sorok, kezdtek beérkezni az első rejtélyes panaszok.

(Nem tudom, ki hogy van vele, nekem ez a legnehezebben elviselhető időszak. Én általában beleadok apait-anyait, heteken, hónapokon keresztül megfeszítetten dolgozok, hogy időre tökéletesen működjön az új rendszer. Ez általában össze is jön, maximum a haragosaim száma növekszik. És amikor hátradőlnék, arcomon az elégedett mosoly, miszerint ‘használjátok, népeim, nektek csináltam…’ majd várnám a dicséreteket… azok valahogy nem jönnek. Egy csepp sem. Ezzel szemben beindulnak a hőbörgések. Hogy micsoda szar ez. Nem tudja ezt, meg azt. Ja, meg minden máshol van. És rossz! Majd jön, hogy mindezért ki is a felelős? A megrendelő persze elkezdi védeni a seggét, hogy ők sem így akarták. Eh.
Nyilván oktatással mindezt ki lehetne védeni, de az ügyfél helyett nem tudom tanítani a felhasználóit, különösen, hogy ezt rendszeresen nem rendelik meg. Így pont akkor, amikor a legfáradtabb vagyok, pont akkor, amikor az asszertív szóról maximum annyi jut eszembe, hogy biztosan egy perzsa hadvezér lehetett, szóval pont ekkor kellene türelmesen elmagyaráznom az embereknek, hogy nem szar, csak más.
Nem szokott sikerülni.
És a legdurvább az, hogy az esetek 1-2%-ában a bejelentőnek tényleg igaza van. Csak ez nem derül ki elsőre. Ilyenkor még elnézést is kell kérnem a végén.)

Nos, ilyen elnézéskérős esetekről lesz most szó.

Az első bejelentés az volt, hogy néhányan hiányolták a Worldwide listákról a külföldi ismerőseiket. (Ja, mondanom sem kell, külföldre leginkább a VIP-ek leveleznek. Ezt, mint türelmetlenségi faktort tessék figyelembe venni.) Megnéztem… és tényleg. Először felrémlett bennem a GAL és annak cefettül bonyolult szerver- illetve kliensoldali függőségei… de aztán lehiggadtam. A Worldwide lista sima Address List, azaz egy szűrő a Global Catalog adatbázisra.
De akkor hogyan lehet, hogy nem kerül bele egy kontakt? Ugyanis a címtárban megnéztem, a kontakt objektumot a MIIS rendesen beletojta az OU-ba.
Aztán később eszembe jutott, hogy valahol olvastam már ilyesmiről. Aztán még később eszembe jutott, hogy nem is olvastam, hanem írtam. Ebben a könyvben. (Igen, öregszem. Igen, én is leszek szenilisek.) Konkrétan arról van szó, hogy az Exchange 2007-ből kiműtötték a RUS-t. Ez a szolgáltatás nem csak a recipient policy-k betartásáért felelt, hanem minden kötegelt, asszimetrikus műveletért. (Mi is az, hogy asszimetrikus? Bekattintok valamiket, aztán csak pár óra múlva fut le egy kötegelt folyamat, mely érvényesíti a hatásokat.)
Tipikusan ilyen folyamat volt a címlisták tagságának érvényesítése is: a RUS megvizsgálta az egyes címlisták szűrőfeltételeit, majd minden recipient objektumra bejegyezte annak a címlistának a nevét, amelyiket a szűrőfeltétel eltalált. (Nem, nem röptében történt a szűrőfeltétel érvényesítése. Ezt nem igazán bírták volna a GC-k.)
Az Exchange 2007-ben ez megváltozott. Amikor létrehoztunk egy recipient objektumot, akkor egyből rá is esett minden, aminek kellett. Ha bármit piszkáltunk rajta, akkor szintén. De kötegelt folyamatok már nincsenek.
Látjátok már a kiskaput? Amikor a MIIS tojja be a kontaktot, akkor megkerüli a folyamatot. Létrejön egy új kontakt, de nem jegyződik be rá, hogy ő mind az ‘All Contact’, mind a Worldwide címlistának a tagja lesz. Nem is lesz. Jogos az ügyfél reklamációja.

Szerencsére a megoldás nem túl bonyolult: mivel a kontaktok éjjel jönnek, reggelre be kell időzíteni két EMS parancsot:

update-addresslist -identity “All Contact\”
update-addresslist -identity Worldwide

Ahogy mondani szokás, az ördög a részletekben lakik. A mocsok.

Időzítettél már be EMS parancsot Windows 2008 szerveren? Ráadásul olyat, melyhez Exchange Organization Administrator (Atyauristen) jogosultság kell?
Egy élmény.

  1. Létrehozol egy kellő erősségű felhasználót, nem lejárós jelszóval.
  2. Létrehozol egy könyvtárat ‘d:\scripts’ néven, úgy, hogy csak az Atyauristen nevű felhasználónak legyen benne írási joga.
  3. Létrehozol egy frank-drebin.ps1 nevű fájlt, melybe beleírod a fenti két parancsot.
  4. Elindítod a Task Scheduler konzolt és ugyanazzal a mozdulattal beveszel egy marék Seduxent.
  5. Beidőzíted a taszkot, beállítod a felhasználót, tesztelsz. Természetesen nem fog történni semmi. Hogyan is gondoltad, hogy egy Exchange szerver fel fogja ismerni az Exchange Management Shell (ps1) parancsát?
  6. Indul a vajákolás. Először is szeretnéd látni, mit is ír ki futás helyett a szkript. Ehhez volt régebben a /i (interactive) kapcsoló. A grafikus felületen nyoma sincs. Parancssorban? A-ha. /IT lett belőle. De nem is ez a lényeg. Hanem az a megjegyzés, hogy ilyesmi csak akkor van, ha a felhasználó ténylegesen be is van jelentkezve. Eszedbe jut, hogy volt egy rádiógomb, miszerint
    – Run only when user is logged on
    – Run whether user is logged on or not
    Nos, bármilyen furcsa is, az első jelenti az interaktív futást, a második a nem interaktívat. Tudnak fogalmazni a fiúk, szó se róla.
  7. Most már látod, hogy egyszerűen az operációs rendszer nem tud mit kezdeni a .ps1 fájlokkal. Megkíméllek a rengeteg utánajárástól, a következőket kell beírnod:
    – A program/script mezőbe: c:\windows\system32\windowspowershell\v1.0\powershell.exe
    – Az add argument mezőbe: -psconsolefile “c:\exchsrvr\bin\exshell.psc1” -command “. ‘d:\script\frank-drebin.ps1′”
    Feltéve, hogy az Exchange alkalmazást a C:\exchsrvr könyvtárba telepítetted.
  8. Azt hiszed, mi, hogy működik? Hát nem. Megjelent az eddig még csak barlangjában szunyókáló UAC. Nem fog lefutni a szkripted, mert hiába vagy maga az Atyauristen, ha nem Atyauristen módban indítottad. Na jó, de hol lehet? A fene tudja. Nézzük meg a runas parancsot… semmi. Csak a jó öreg /savecred van, de az már kilenc évvel ezelőtt is maximum vicc volt. (Jelszót beleírni a parancsba… egy mindenható felhasználónál. Aha.) Na jó, nem csigázlak, ezt a csekkbokszot kell bebillentened: ‘Run with highest privileges’. Biztos ugyanaz a mókus fogalmazta, aki az előző objektumot. Még az is lehet, hogy ideológiát is gyártott hozzá: security through obscurity, azaz hülye ember ne tudja már beállítani. Mintha ez a fajta védekezés valaha is ért volna akár egy koszvadt hajítófát is.

És nagyjából ennyi. A szkriptünk minden reggel lefut, a nevek pedig megjelentek a Worldwide címlistában.

Csak éppen levelet nem lehet küldeni nekik.

De ez már majd a következő írás témája lesz.

Beszéljünk nyelveket

2009-05-17 / / 9 Comments

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

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

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

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

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

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

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

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

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

IMCEA

2009-03-12 / / 5 Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Case solved.

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

Formás levél

2009-02-11 / / 3 Comments

Érdekes jelenségre hívta fel a figyelmemet az ügyfél egyik fejlesztője. Ha az Exchange 2007 OWÁ-ból küld html levelet, akkor a túloldalon már csak plain text-ként látszik. Miközben ha megnézzük a Sent Items folderben, ott bizony html.
Ez vajon mi lehet?

Ellenteszt. Mi van, ha Outlookból küldök html levelet? Úgy is érkezik meg.

Gyors teszt más cégek OWA rendszereiben – mindenhol ugyanez a jelenség.

Ez érdekes. Hiszen elméletileg nem szabadna, hogy különbség legyen a levélben, függetlenül attól, hogy OWÁ-ban vagy Outlookban állították elő. A formátumot saccra a Remote Domain objektumon lehet még utánállítani – és az egyformán kell vonatkozzon minden abba az irányba küldött levélre. De van egyáltalán ilyen állítási lehetőség a Remote Domain objektumokon? Bizony nincs. Legalábbis konzolból nincs.
Persze shellből van. Nézzük csak meg a get-remotedomain | fl parancs kimenetlét. Ott van, elbújva a többi tulajdonság közé a ContentType tulajdonság. Melynek értékei a következők lehetnek:

  • MimeHtmlText: Ha az eredeti levél text volt, akkor text MIME formátumba konvertál. Minden egyéb esetben html MIME formátumba.
  • MimeText: Text MIME formátumba konvertál.
  • MimeHtml: Html MIME formátumba konvertál.

Az alapértelmezés – a set-remotedomain parancs szerint – a MimeHtmlText beállítás. Ez jól is hangzik.

Csakhogy. Az én konkrét esetemben az volt, hogy MimeText.

Rögtön kérdések merültek fel:

  • Ha alapértelmezésben telepítettem, akkor miért nem az alapérték van beállítva?
  • Ha csak text MIME formátumban megy ki a levél, akkor hogyan mehetett ki Outlookból mégis html formátumban?

Jó magyar infomunkásként először azért beállítottam a MimeHtmlText értékét, leteszteltem – és tényleg ez volt a megoldás. Ment OWA alól a html levelezés.

Most már lehetett tipródni, mit is csináltunk. Mitől javult meg a rendszer?

Az első kérdésre viszonylag hamar meglett a válasz. Szűz rendszernél tényleg a MimeHtmlText az alapértelmezés. De ha 2003-ból migrálunk, akkor attól függően, hogy mi volt beállítva a kimenő levelek (Internet Message Formats) MIME kódolására, attól függően már más. Ha ott az volt, hogy ‘Provide message body as plain text’, akkor a migráció során a MimeText jön át. Azaz valószínűleg az összes helyen, ahol teszteltem, ez volt a beállítás a migráció előtt.

A második kérdésre a válasz már fogósabb egy kicsit. Logikusan gondolkodva, ha van egy organizáció szintű beállítás, de bizonyos levelekre vonatkozik, bizonyos levelekre meg nem, akkor léteznie kell legalább egy magasabb prioritású beállításnak, mely felülbírálja azt. Ezzel a témával kapcsolatban ezt a cikket találtam. Olvasgattam, olvasgattam… de nem akart összeállni a kép.

Mit is írnak a cikk vége felé?

Order of Precedence for Message Encoding Options
Exchange 2007 uses the order of precedence as described in the following list to determine the message encoding options for outgoing messages that are sent to recipients outside the Exchange organization:

  • Remote domain settings
  • Outlook settings
  • Mail user or mail contact settings

The list specifies the order of precedence from lowest to highest. A setting made at a higher level may override a setting made at a lower level.

Az utolsó pont szorulhat némi magyarázatra: az Outlook 2007-ben lehetőségünk van nekünk, személy szerint is bejelölgetni a kontaktokat (akár a sajátjainkat, akár a közöseket), hogy milyen formátumban szeretnénk nekik levelet küldeni.
Mondanom sem kell, ritka hülyén van megfogalmazva a szöveg. Hogyan értelmezzük a sorrendet? A higher level azt jelenti, hogy a legalsó a leggyengébb, a legfelső meg a legerősebb? De hát nem ez történt. Amikor beállítottam Outlook szinten, hogy html-ben akarok levelezni, akkor az úgy is ment ki, függetlenül attól, hogy remote domain szinten MimeText volt beállítva.
Megint a logikára kell hagyatkoznom. Ha ugyanis a felsorolás sorrendjét tekintem prioritási sorrendnek is, azaz fentről haladnék lefelé, akkor az a következőket jelentené:

  • Akárhogy is jelölném be a konkrét levél tipusát, ha a címzettre más típus van beállítva, akkor az utóbbi felülírja az elsőt.
  • Hiába van beállítva organizáció szinten a tartalomtípus, ha én a konkrét levelemben más adtam meg, akkor az lesz az erősebb. A levél úgy megy ki.

Ez már annyiból tetszetősebb, hogy ez lehetőséget ad megmagyarázni a jelenséget. Valamiért ha OWÁ-ból küldök html levelet, azt a remote domain nem úgy érzékeli, mintha Outlook-ból állítottam volna be, magasabb precedenciával. Tehát sima szövegként csomagolja MIMÉ-be. Ellenben amikor a remote domain objektumon azt állítom be, hogy vizsgálja meg a levelet, majd aszerint döntsön, akkor már felismeri, hogy ez eredetileg html levél volt – és így csomagolja MIMÉ-be.

Nagyon fontos. Amit a második kérdéssel kapcsolatban írtam, színtiszta spekuláció. Számomra így tűnik logikusnak. Ettől függetlenül abszolút máshogy is lehet.
Az életedet ne tedd fel rá.

DotNet

2009-02-11 / / 0 Comments

Egész biztosan vannak kellemetlenebbül hangzó szavak. De nem sokan.

Mit tudunk róla? Keretrendszer. Valami olyasmi, mint a Java. Megírnak egy programot valamilyen nyelven, a keretrendszer pedig képes értelmezni és az adott operációs rendszer keretein belül futtatni is azt. Mi itt a baj?
A fejlődés, barátom, a fejlövés fejlődés. Az első dotnet az 1.1 volt, aztán jött az sp1, majd jött a 2.0, persze az is kapott sp1-et, feltartóztathatatlanul jött a 3.0 az adekvát sp1-gyel, végül előmászott a 3.5, persze neki is van sp1 csomagja. Szerinted mire számíthat egy akármilyen program? Ezek közül vajh melyik lesz fent az operációs rendszeren? Ha azt mondod, mindegy, akkor látszik, nemrégóta vagy a szakmában. Ez az egész kóceráj visszafelé nem kompatibilis. Azt hiszed, ha van 2.0 verziód, akkor futni fognak az 1.1-hez írt programok? Erre csak annyit tudok mondani, hogy probatbicol pfdavadmin. Akkor esetleg elférnek egymás mellett ezek a keretrendszerek? Talán. De ha például az Exchange 2007 mellé (.Net 2.0) fel akarnád tenni a pfdavadmint és emiatt utólag a .Net 1.1-et… nem csak én nem tanácsolnám. (Mindemellett, ha a az 1.1 után teszed fel a 2.0-át, akkor simán elketyegnek egymás mellett.)

A röpke bemelegítés után térjünk a tárgyra. Hiszen projekt van.

Eddig nem beszéltem róla, de az ügyfél nem csak Exchange 2007 clustert akart, hanem profi levélarchiválási rendszert is. A választásuk a Symantec Enterprise Vault (a továbbiakban SEV) rendszerre esett. Az ajánlatot tevő cég a projekt során az alvállakozónk lett. Némi vérgőzös ütésváltás szakmai egyeztetés után abban maradtunk, hogy a SEV egy Windows 2003 clusterre kerül, ahol az ún. Storage Foundation (SF) lövi ki a klasszikus failover cluster spof-ját. (Nem baj, ha nem érted elsőre, annyira nem lényeges.)
Bele is vágtunk. Feltelepítettük az operációs rendszereket. A kolléga kérdezte, hogy tegyen-e rá valamilyen dotnet-et. Elgondolkodtam. Ha már fent lesz a cluster meg az SF, utólag sokkal bonyolultabb lesz biztosítani a megfelelő dotnet keretrendszert. Végül azt mondtam, tegye fel a .Net 3.5-öt, az olyan ultimate dolog, az felrakja az összes olyan keretrendszert, mely még nem volt fent. Aztán ha minden fent van, akkor a SEV is ki fogja majd tudni választani, melyik kell neki.
Utána jött a cluster, jött az SF, szépen haladtunk. Jött a SEV telepítő ember is. Elkezdtük silabizálni a prerekviziteket. És amikor odaértünk, hogy a számíítógépen _nem lehet_ dotnet kettőnél _magasabb_ verziójú keretrendszer, akkor azért kezdtem hülyén érezni magam. Miért? Erre nem tért ki a doksi. De tudjuk, milyen ravasz dolog a felelősség – ha telepítési előírás, akkor be kell tartani, még akkor is, ha azt írja, hogy a telepítő mérnöknek aranyszínű tangabugyiban kell felszaladnia virradatkor a Gellérthegyre, fényáldozatra bemutatva telepítő cédét.

Jó, távolítsuk el. Itt másztunk bele a mocsárba. Hivatalosan ugyanis el lehet. De. Az internet tele van rémtörténetekkel, mi is történt azokkal, akik naív módon nekiálltak uninstallálni a keretrendszert. Eleve a 3.5 csomagot csak úgy tudod kilőni, ha minden csomagot leszedsz, melyet az rakott fel. De le tudod szedni? A történet ott kezdett tragikomédiába fordulni, amikor rátaláltam Aaron Stebner – MS alkalmazott srác – blogjára, ahol megemlíti, hogy szabadidejében írt egy progit – As Is – mely le tudja szedni akkor is a dotnetrusnyákat, ha azok nem akarnak eltávozni. (Legfrissebb változat.) Ekkor mondtam azt, hogy kösz, de nem. Legalább induláskor legyek biztos abban, hogy a rendszer flottul működik, nincs belekódolva semmiféle döglött(?) akna.

Formatcé.

Szépen összeraktuk újra az egészet, csak most már kihagytuk a dotnet kettő feletti csomagokat. Mindenki megnyugodott, csak bennem maradt némi tüske a dotnetekkel kapcsolatban.

Aztán itt volt a mai nap.

A héten keresett egy kolléga, hogy az ügyfél rendszerében, ha Outlook 2007-ből akarnak megbeszélést szervezni, nem látják a foglaltsági információkat.
Sóhaj.
Apa, kezdődik.

Egy nagyméretű rendszerben, ahol egyszerre vannak jelen Exchange 2003 és 2007 szerverek, ahol egyszerre van jelen az összes MAPI kliens, melyet a Microsoft az utóbbi tíz évben gyártott, beleértve az összes service pack kombinációt is – nagyjából huszonötmillió oka lehet, hogy egy konkrét kliensen miért nem megy a Free/Busy.
– Látja a CAS szervert? Internet Explorer beállításainál benne van a CAS a proxy kivételek között? – kérdeztem rá.
– Hoppá – jött a válasz.
Nem volt benne.
– Megjavult?
– Nem mondhatnám. Mostantól Váratlan Hibával elszáll az Outlook.
– Hah. Kliens oldali hiba. Apage Satanas.
– Mi legyen?
– Pecseljétek halálra. Aztán majd meglátjuk.
Felraktak rá minden létező szervízcsomagot, javítófoltot.
– Na? – kérdeztem rá.
– Ugyanaz. Sőt, az Out of Office be sem jön.
– Miaf? Állítsátok be légyszi, hogy elérjek egy tesztgépet.

És tényleg. Pedig az Autoconfiguration teszt szépen megmutatta, hogy az Autodiscovery a pontos OOF webservice útvonalat adta vissza. (Azaz az EWS útvonalát.) Ha ezt az útvonalat bemásoltam az IE-be, meg is kaptam a korrekt xml-t. Jogosultság az EWS-en? Tökéletes.
Az mindenesetre ekkor már látszott, hogy nem kliens oldali hibáról van szó. Mind az OOF, mind az Availabilty service (Free/Busy) az EWS-t használja, tehát ott lesz valami gubanc. De mi?

Nézzük, itt van a test-outlookservices parancs. Mit mond, ha megkérdezzük?
Ekkor koppant az állam a padlón: a harmadik lépésben error-ral elszállt. Na de kérem…? Egy default telepítésű CAS+HTS szervernél nem működik az EMS? Szar a powershell?

Vad guglizás következett.

Nem akarom a végtelenségig fokozni a feszültséget, az első értelmes nyom ez a thread volt egy fórumon. A jelenség pont ugyanaz, gyönyörűen látni, hogyan gyűlnek a károsultak, hogyan válik belőlük izgatott tömeg, hogyan saccolnak először a .Net 3.5 sp1-re, hogyan lesz egyre élesebb a gyanú, végül hogyan válik bizonyossággá: az egyik bátor jelentkező leszedte a 3.5 sp1-et (Hogyan?? – hördült fel a közönség.) és egyből megjavult nála a helyzet. Végül kialakult az a konklúzió, miszerint a tuti módszer az sp1 leszedése, bár valaki megjegyezte, hogy a Microsoftnak mintha lenne egy nem publikus javítófoltja is.

Ehhez képest volt felüdülés a következő találat, ahol az a bizonyos javítófolt nevesítve is lett. Innen lehet letölteni a csomagot. (Igen, csomagot. Nem csak a 3.5-höz kell patch, hanem az egész bagázshoz. Vigyázat, a sorrend is számít.)

Most már jó. Legalábbis, majdnem. A kliensek már nem panaszkodnak, megy rendesen minden, ami EWS-re épül. Egyedül a test-outlookservices nem fut még le rendesen, telesírja a képernyőt sémahibákra panaszkodva. Azaz lesz még itt néhány tiszteletkör.

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.

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.

Adide, nemadom

2008-12-11 / / 2 Comments

Na, kérem, itt van a magyarázat ahhoz, ami miatt pár nappal ezelőtt csak kapkodtam a levegőt.

Nemrégiben jött ki az Exchange 2007 SP1 termékhez a Rollup Pack 5. (Csak gondoljunk bele… az SP1 előtt volt megint 5 Rollup Pack… és mindegyik megváltoztatta a termék viselkedését… nem könnyű ám Exchange adminnak lenni.)

Nos, az egyik hiba, melyet a csomag javított, így szólt: CCR vagy SCC clusterben megvalósított Mailbox szerveren nem működött a GAL disztribúció, amennyiben Outlook 2007 kliensről próbálkoztunk.
Ránézésre nem olyan vészes, pedig de. Összeraksz kemény munkával egy clustert, jön egy felhasználó Outlook 2007-tel – annyira azért már nem ritka jószág – és nem lát címlistát.

Eddig nem lehetett sokat tudni arról, mi is okozta a hibát – de Dave Goldmann nemrég írt egy cikket. Most már tudjuk. Most már verjük a fejünket a falba. Velük együtt. Annyira idióta hibáról van szó, hogy tényleg nem értem, hogyan kerülhetett bele a rendszerbe.

Nem húzom tovább az időt, itt a magyarázat: az OABGen process a \\gepnev\ExchangeOAB könyvtárba tette le a legenerált xml fájlt, mint ahogy mindig is szokta. A CAS szerver viszont nem ott kereste, mert ő hogyan is látja a clustert? A virtuális Exchange szerver nevén keresztül. Azaz a CAS a \\CMS\ExchangeOAB megosztást kereste, nem találta, tehát az OAB weblapon nem is tudott publikálni semmit.

Függöny.

Sírok

2008-12-08 / / 0 Comments

Most kivételesen nagyon negatív leszek. Úgy értem, negatív negatív. Általában ugyanis pozitív negatív szoktam lenni: ha szidok is valamit, azt javító szándékkal teszem – hiszen alapvetően azért kedvelem azt az izét.

Blackberry. És Onebridge.

A projektünk az ügyfélnél szépen haladt, elérkeztünk odáig, hogy foglalkozzunk az Exchange szerverekhez kapcsolódó külső szerverekkel. Igen, a fenti szerverekről van szó.

Na most, én már akkor kis híján lepetéztem, amikor a múltkor kiderült, hogy – dacára mindenféle natolásnak – a BB szervert a belső IP címével regisztrálják be odakint. Azaz ha egyszer feltelepítetted, akkor azt már át nem rakod máshová. De ami most jött, az felért egy tökönrúgással.
Közölték, hogy a fenti két szerver közül egyik sem bírja lekezelni azt a roppant bonyolult szituációt, hogy egy Active Directory több tartományból áll. Négylábas megadás. Érted, Windows környezetbe tervezek egy alkalmazás szervert, de az sajnos nem tud lekezelni olyan szituációkat, melyeket az alatta lévő Windows egyébként messzemenően támogat. De továbbmegyek: mindkét alkalmazás olyan rendszerhez – Exchange – kötődik szorosan, mely deklaráltan címtár szintű… azaz tartományok feletti. Az Exchange mindig a teljes címtárban gondolkodik, nem érdekli, hogy ki melyik tartományban van.
És akkor közlik, hogy telepítsük újra a régi BB/OB szervereket, mert az új Exchange másik tartományba került. Agybaj.

Kezdtük egy Onebridge teszttel. Kijött a nagynagy internetszolgáltató szakembere, mi is delegáltunk egy helyi rendszergazdát. Belevágtak. Aztán délután 5-kor jött a levél: help.
Napközben annyi történt, hogy a szakértő hozott egy telepítési leírást, meg néhány OB knowledge base cikket, hogyan kell felkészíteni az Exchange-t az együttműködésre. Ezeken becsülettel végig is mentek, majd jött a kapcsolódás… meg az error. Kipróbáltak mindent, de nem lett jobb a helyzet.
Ekkor kapaszkodott bele a szakértő és az ügyfél delegált embere abba a kitételbe, hogy az OB KB a preparációknál megemlítette azt, miszerint győződjenek meg róla, hogy az Exchange szerveren nincs-e letiltva a MAPI. Tény, le lehet. De nem egyszerűen. Ha a telepítésnél nem figyelünk, ész nélküll nyomjuk az OK-t, akkor belefuthatunk ilyen szituációba. (Írtam is erről anno.) De ha rendesen telepítünk, akkor már nincs ilyen veszély. Igaz, le lehet tiltani utólag is registrybuherával… de azért csak emlékeznék rá.
Így ment is vissza a levél a fiúknak, hogy nem, nincs letiltva a MAPI. De ezt egyből láthatják is, hiszen tudnak kapcsolódni régebbi Outlookkal, ráadásul láthatják, van Public Folder is. Erre jött az a válasz, hogy ez nem bizonyíték, tekintve, hogy mindenki tudja, miszerint az MS más MAPI-t használ, mint amit a külső cégeknek biztosít.
Itt szökött fel plafonig a szemöldököm. Ekkor lett nyilvánvaló, hogy a nagynagy internetszolgáltató szakértőjének halvány fogalma sincs arról az architektúráról, amelynek egyébként a szakértője lenne. Addig ugyanis oké, hogy más mapixx.dll települ fel mondjuk az Outlookkal, mint amit a külső cégeknek ajánlanak… de ettől a MAPI, mint távoli eljáráshívásokon alapuló függvénygyüjtemény köteles ugyanolyannak lenni ugyanazon szerver esetében, hiszen a túloldalon a szerver csak az eljáráshívásokra reagál, nem kér előtte személyi igazolványt.
A helyi mérnökünk mindenesetre rámutatott, hogy először talán azzal a tömérdek MAPI errrorral kellene foglalkozni az OB szerveren, melyek az eventlogban vannak… és csak utána piszkálni az Exchange oldalt. Különösen, hogy amit a KB cikkük előírt, azt pontosan beállítottuk.
És most itt állunk. Szószerint is.

Nos, eddig ez akár egy szokásos köcsögjózsis történet is lehetne.

De amitől hirtelen ledobtam magamról minden toleranciát és billentyűzetet ragadtam, az egy KB cikk volt. Az egyik fázisban a szakértő megadta a hozzáférését az OB KB cikkekhez, hátha én, Exchange szemszögből kiszúrok valamit. Hát… kiszúrtam.
Mivel nem publikus anyag, így a lényegi részből nem idézek. Nagyjából arról van szó, hogyan is kell pontosan kipreparálni az Exchange szervert a korrekt kapcsolathoz. Egy csomó jogosultáságállításról van szó, mind felhasználói, mind szerveroldali konfigurációkról. A közös mindegyikben, hogy a címtárban állítgatod az értékeket: hol a domain névtérben, hol a configuration névtérben. Kizárólag csak ezeken a helyeken.
És akkor most követek el egy bűnös kiszivárogtatást. Akit esetleg komolyabban is érdekel, lementettem az írást, nálam meg lehet tekinteni. Szóval ez annak a bizonyos KB cikknek (#4267) az utolsó mondata:

It might be necessary to restart affected servers, such as Domain Controllers and Exchange Servers, in order the changes to take effect.

Megégetni az architektet. Megégetni. Most.

Gondolj, bele, egy ilyen alkalmazásnak adunk mindenféle erős jogot egy nagy ügyfél nagy Exchange rendszerében. Ráadásul mosolyogva kell.

Minden jó, hajó a vége

2008-12-04 / / 1 Comment

Valamikor írtam róla, hogyan járt szerencsétlen ügyfelünk: az anyacége dömperrel beborított vagy 30000 kontaktot a címtárába. Szaladgáltak is szegények, mi lesz most a címlistákkal: végül egy illegalitásba hajló lépéssel megpatkoltuk a rendszert.

Aki nem olvasta át a két linket, röviden összefoglalom: szerencsére kiderült, hogy a távoli tartományban született kontaktok msexchoriginatingforest tulajdonsága megőrzi az eredeti forest értékét. A helyben született objektumoknál viszont ez üres. Azaz a GAL mögötti ldap filterbe ‘és’ kapcsolattal becsatoltunk egy !(msexchoriginatingforest=*) feltételt – így csak azok jelentek meg a globális címlistában, akiknek üres volt ez a tulajdonsága. Természetesen az eredeti GAL filtert kimentettük egy custom címlistába, hogy akik abban akarnak keresni, azért tudjanak.

Mindenki boldog volt.

Egészen az Exchange 2007 migrációig.

Igazából nem az a legnagyobb baj, hogy ebben a termékben kinyírták az ldap alapú szűrést. Hiszen bejött helyette az OPATH – és ha megszokod, rájössz, hogy ez tényleg jobb. Még csak nem is az a katasztrófa, hogy beszuszakoltak egy plusz réteget a filter és a címtár közé. Igaz, hogy mostantól a feltételekben nem direktben hivatkozol az objektumok tulajdonságainak értékére, hanem helyette ujjból szopott nevű változókat kell használnod… de ez maximum kényelmetlenség. A tragédia az, hogy nem definiáltak minden tulajdonsághoz változót. Költői kérdés: találd ki, használhatjuk-e OPATH filterben az msexchoriginatingforest tulajdonságra definiált változót? Nem… mert nincs. Nyugodtan böngészd át a választékot.

Mondtam, ugye, hogy a legnagyobb szopás az ldap filter az egész upgrade-ben?

Akkor mi legyen? Adódik, hogy szűrjünk rá a szerver nevére. Az ügyfélnél egy darab nagy teljesítményű központi szerver lesz, tehát még a szűrőfeltétel sem lesz túl bonyolult. Alapvetően működhetne is… csak éppen nem elegáns. Mi van, ha valamikor üzembeállítanak majd egy másik MBX szervert is? Mi van, ha egyszer átmigrálják a postafiókokat egy másik szerverre? Ki fog emlékezni rá, hogyan lett megbuherálva a GAL? Ráadásul…ugye az átállás ideje alatt még két szerver van, tehát mindkettőnek a nevét be kellene írni a feltételbe. Pedig a régi csak pár hétig fog még élni. Jó, majd utólag módosítjuk.
Meséltem már erről? Lehet. De ismétlés a tudás k. anyja.
Szóval, a GAL-t a set-globaladdresslist paranccsal tudjuk upgradelni. Exchange 2007 alatt ugyanis minden szűrős objektumnak két szűrője is van. (Logikus, hiszen illeszkednie kell mind a régi, mind az új rendszerhez.) A címtár preparálásakor meg is jelenik az új tulajdonság, de sehol, hangsúlyozom, sehol sem történik automatikus filter konverzió, amikor betoljuk az első MBX szervert az organizációba.
Magad uram, ha szolgád nincsen.
Címlistáknál, email address policy-knél nem is gond. De a GAL-nál igen. A set-globaladdresslist parancs ugyanis egylövetű. Egyszer beírhatod az OPATH szűrőt. A következő futtatáskor már azt kapod, hogy ‘Hohó, valaki nem bír magával!’. Nyilván adsiedit és purportedsearch… de nem lehetsz benne biztos, nem csináltál-e valami visszafordíthatatlant. Lehet, hogy valahol a mélyben elpattant egy fogaskerék, a szerver teliholdkor életre kel és szakrálisan feláldozza az éjszakai recepcióst. Vagy bármi. De hogy nem lesz supportált, az tuti biztos.
Márpedig, ha a szervernevekkel játszol, akkor kétszer is módosítanod kell a GAL-t.

De azért megpróbáltam körbejárni. Leginkább azért, hogy közben időt hagyjak ott hátul a megoldáskeresésnek.
Összedobtam az Exchange 2003-ban egy teszt címlistát. Varázslóval. Középső fül, szervernév megad. Nézzük az eredményt… hoppá. Brian… leestem a székről. Ott voltak benne a külföldi címek. Most én vagyok a hülye… vagy a varázsló? Szerintem az utóbbi. Nézzük csak a konkrét feltételt… jézusmária. Sőt, ez már inkább duplajézusmária erősségű volt. Ez az idióta kuruzsló ‘vagy’ kapcsolatba tette a szervernévre vonatkozó feltételt az első panelen bepipált ‘contact’ feltétellel. Így mindenki beleesett. Döbbenet.

Kitérő:

Ha csak lehet, ne használj varázslót.
Ha ez eddig nem lenne egyértelmű, elmagyarázom, miért.
Nézzük az előbbi példát, kattogtassunk össze egy címlistát, amelyikben az Exchange postafiókkal bíró felhasználók címei vannak. Első fül, ‘Users with Exchange mailbox’ checkbox. Ez lesz a szűrőfeltétel:

(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))

Azaz mindenki, akinek nem üres a homemdb (melyik adatbázisban van) és az msexchhomeservername (melyik exchange szerveren van) tulajdonságának az értéke.

Jelöljük be mellé a külső emailcímmel bíró felhasználókat is. Ez ugyanazon a panelen a következő két checkboxot jelenti: ‘Users with Exchange mailbox’ és ‘Users with external mail addresses’. A szűrőfeltétel:

(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))

Azaz mindenki, akinek nem üres a homemdb (melyik adatbázisban van) és az msexchhomeservername (melyik exchange szerveren van) tulajdonságának az értéke – illetve mindenki, akinek meg üres. Jópofa, mi? Ha belegondolsz, hogy beviszünk egy feltételt, majd ‘vagy’ kapcsolattal annak az ellenkezőjét is, akkor tkp megkapjuk az univerzumot. Ami nem baj, mert ugye pont azt kértük… csak éppen megkaphatjuk egyszerűbben is, sokkal kevesebb munkával.
A helyes, varázslótlanitott szűrő:

(&(mailnickname=*)(objectCategory=person)(objectClass=user))

Ha belegondolsz, hogy ez a szűrőfeltétel minden RUS futáskor végigmegy a címtáradon… ugye nem mindegy, mennyit kell tökölnie a feltétel kiértékelésén.

Kitérő vége.

Szóval nem tetszett a szerverneves vizsgálódás. Ldp-ből kinyomtattam mindenfajta objektumból egy-egy teljes tulajdonságlistát, majd egy kihúzófilc társaságában félrevonultam. Kerestem, hol lehet ezt az egészet megfogni.
Hamar kiderült, hogy a szervernévvel egész konkrétan nem. Az ugyanis a magyar kontaktoknál is üres, nemcsak a kintről betoltaknál.
Gyakorlatilag nem találtam semmit. Illetve találtam, de. Nekem, emberi aggyal egyből látszott…de látszik-e ez a programnak is? Ugye ott van a distinguishedname, mint paraméter. Ebben szépen benne van az objektum elérési útvonala is. Márpedig a letolt címek, mégha egy nagyon bonyolult OU struktúrában is, de egy OU-n belül vannak. Azaz a distinguishedname valahogy így néz ki: cn=blabla,,,ou=PamPam,ou=blabla,dc=blabla. A vastaggal jelölt rész mindegyik idegen címben megegyezik, és csak azokra jellemző. Nosza, nézzük csak meg azt az OPATH szintakszist. Jé, ez a nolike egész szimpatikus. Tud ez wildcardot? Tud. A distinguishedname tulajdonságra létezik változó? Létezik, méghozzá ugyanazzal a névvel. Mire várunk?

Hölgyeim és Uraim! Imhol az új GAL:

alias -ne $null -and distinguishedname -nolike ‘*ou=PamPam*’

Már csak be kell gépelni. Jelzem, elsőre úgysem fog sikerülni. A filterek beadása rendszeresen kész katasztrófa. Elsőre úgyis csak címlistákon gyakorlunk, tehát dobjuk be ezt a keresést egy már létező ‘teszt’ nevűbe:

set-addresslist -identity teszt domaincontroller dc.domain.hu -recipientfilter {alias -ne $null -and distinguishedname -nolike ‘*ou=PamPam*’} -whatif

A -whatif azért van a végén, hogy ne csinálja meg, csak írja ki, mi lett volna.
Nos?
Ha jól csináltuk, akkor egy kövér errort kaptunk. Azt mondja, ennél a tulajdonságnál nem használhatunk wildcard-ot.
Ez már maga a Turáni Átok. Miért, ó miért? Bakker, hiszen ezen tudtuk (volna) egyedül megfogni a külsős címeket.
Gugli. Ezen a fórumon valaki hasonlóba futott bele, választ persze nem kapott. Viszont a Szkriptelő Fiúk egy helyen elkottyantották magukat:

Alas, this won’t work, either. As it turns out, the DN is a “constructed” attribute. The DN isn’t actually stored in Active Directory, it’s constructed on-the-fly any time you request it. Thus you can’t do a wildcard search on the distinguishedName attribute. And don’t bother asking about the ADsPath attribute, which also contains the OU name; you can’t do a wildcard search on the ADsPath, either.

Nem örülök… de beletörődtem.

Viszont az agyam, az kiürült. Szórakozottan nézegettem a papírjaimat, meg a változókat. Aztán az agyam kezdett magára találni, szép lassan összerakta az újabb variációt. Nézzük csak, proxyaddress tulajdonság, melyet itt emailaddresses-nek hívnak. Határozottan jelzi a táblázat, hogy nyomjuk csak bátran neki a wildcardot, bírja. Csakhogy ez egy tömb. Hogyan szűrjünk rá? Ezt is megmondja: a tömb elemei vesszővel vannak elválasztva és az egész egy szép nagy sztring. Nocsak. Persze az SMTP cím nem megoldás, rengeteg fajta van a cégen belül, aztán meg ott vannak a külsős kontaktok is. Na de… itt van ez az őskövület. Az X400-as cím. Mely már az égegyadta világon semmire sem jó. Csakhogy ennek a ‘P’ paramétere (Private Management Domain Name) pont az organizáció neve. És X400-as címe mindenkinek van – hiszen ez csak az email address policy-n múlik.

Azaz a következő kisérlet:

alias -ne $null -and emailaddresses -like ‘*p=orgname*’

Na, ez már jó. Mennyire? Túl.
Ez ugyanis beleveszi az összes emailcímmel bíró public foldert is, azt meg mi nem igazán szeretnénk. De innentől már rutinmunka. Úgy csinálunk, mintha gyártanánk egy új címlistát, bejelölünk mindenkit az első panelen (vegyük észre, hogy a public folderek fel sincsennek sorolva, azokat csak EMS-ből lehet felvenni), majd az utolsó panelről ctrl+v-vel lekapjuk a recipientfilter paraméter értékét, beleírjuk az emailaddresses figyelést… és készen is vagyunk. Imhol.

set-addresslist -identity teszt -domaincontroller dc.domain.hu -recipientfilter {emailaddresses -like ‘*p=orgname*’ -and (RecipientType -eq ‘UserMailbox’ -or RecipientType -eq ‘MailContact’ -or RecipientType -eq ‘MailUser’ -or (RecipientType -eq ‘MailUniversalDistributionGroup’ -or RecipientType -eq ‘MailUniversalSecurityGroup’ -or RecipientType -eq ‘MailNonUniversalGroup’ -or RecipientType -eq ‘DynamicDistributionGroup’) -or (RecipientType -eq ‘UserMailbox’ -and ResourceMetaData -like ‘ResourceType:*’ -and ResourceSearchProperties -ne $null))}

Habár már éppen eleget dolgoztunk ma, de azért ellenőrizzünk. Számoljuk össze, hány emberből áll az egyik lista és hányból a másik. Apró baki, hogy Exchange 2007-ben már csak preview van az Address List tulajdonságlapján, számláló nincs. Na de ott van még a régi szerver! Meg tudja számolni a 2003-as Exchange System Manager a 2007-es címlista elemeit? Meg hát. Igaz, eleinte hőbörög, de aztán beletörődik és számol.
A jó hír az, hogy kicsi az eltérés. A rossz hír az, hogy van. Nyilván annak a húsz embernek nem vigasz, hogy csak huszan nem látszanak a listában. És persze az egyik biztosan a vezérigazgató.
Akkor mégsem végeztünk. Nyilván az történt, hogy a több ezer emberből húsznál ki van kapcsolva a recipient policy, manuálisan meg nem kaptak X.400 címet. Semmi gond, megkeressük, levadásszuk.
Nyilván szkripttel.
Egy általános keresőszkript mindig itt figyel a gépemen, pusztán csak a kilistázott adatokat kell konkretizálnom. X400-as cím… az ugye a proxyaddresses tömb része. Nem tudom, ki szeret tömböt boncolni, én nem igazán. Kerülő út? Persze, hogy van. Tudni kell, hogy létezik olyan, hogy textEncodedORAddress változó, ebben a felhasználó elsődleges X400-as címe figyel. Pusztán csak ezeket kell lekérni egy Excel táblába, majd vizuálisan kiszúrni, kinél nincs adat.

Innentől már tényleg csak a piszkos munka van hátra.

Vazze

2008-11-30 / / 0 Comments

Tudod, én igazán szeretem az Exchange szervert, mint terméket. De időnként komolyan fel tud bosszantani.

Nem, ezek nem az én szavaim. Nekem sokkal durvábbak csúsztak ki a számon, amikor hasonló problémába futottam bele, mint Jim McBee.

Már a W2k8 NFSM cluster is megdolgoztatott, mire minden stimmelt. Hol ez nem volt, hol az viselkedett teljesen máshogy… és persze örök kedvencem, az a nyomorult Internet Explorer a nyomorult fokozott biztonságával. De végül összeállt minden, jöhetett az Exchange cluster. CAS és HTS szerver már duruzsolt a hálózatban, tehát megágyazva már meg volt rendesen. Kell is, mert a legtöbb baj mindig a Mailbox szerverrel van – érdemes előtte az összes egyéb szerepkört pöpecül belőni.

Kíváncsi vagyok, ha feltenném a kérdést, vajon szerintetek egy Exchange 2003 – Exchange 2007 átállásnak mi a legkritikusabb része, mit válaszolnátok? Én már a másodikat csinálom élesben, nagy ügyfélnél – és van egy pont, ahol mindig elhasalunk, ahol garantáltan behal a telepítés és mely után lehet a félbehagyott telepítés szutykait kivakarni és reménykedni, hogy a következő telepítést nem fogják a romok bezavarni. A címtárról nem is beszélve.

Mik ezek a félelmetes, bonyolult dolgok? A címlisták és a recipient policy-k. Nem gondoltad volna, mi? Hiszen nem is néznek ki olyan veszélyesen. De annak az embernek a kezét, aki ezt a setup darabot leprogramozta, beledugnám könyékig annak a seggébe, aki ezt a folyamatot megtervezte, és vica-versa – majd kiakasztanám őket a Nagykörútra karácsonyi dísznek, egy szál mikulássapkában.

Ugye, leírtam, hogy a múltkor hogyan jártunk. (Egyik, másik.) Tanultam belőle, most időben átvizsgáltam az összes címlistát, recpolt. Nem volt bennük névbe ágyazott zárójel, nem volt bennük felesleges ‘&’. Meg hát azért ez már SP1, az meg csak RTM volt.
A magam részéről mondjuk nem bántam volna, ha van előzetes validálási lehetőség, de hát ugye… Külön nehezítés, hogy itt az első MBX szerver rögtön egy CCR cluster aktív lába lesz…. ezt nem kellene elrontani, mert utána kivakarni a koszt… brrrr… nem kellemes.

No mindegy, még egyszer átfutottam az ldap lekérdezéseket… jóknak tűntek.
Hajrá.

Húzza a csíkot… húzza a csíkot… majd megáll. Hogy van egy policy, amelyikben szerinte nem stimmelnek a zárójelek. Szerencsére még nem történt semmi visszavonhatatlan, aktív a retry gomb a varázslóban, ráadásul megadja a policy nevét is. Megvizsgálom, ránézésre teljesen jó. De ami még durvább, az az, hogy ez az ldap feltétel nem valami egyedi dolog, hanem varázslóval lett összekattogtatva. Mi az, hogy az egyik varázsló nem eszi meg azt, amit a másik állított össze?
Néztem pár percig, végül felhívtam a rendszergazdát, mi is ez a recpol? Nem fontos, törölheted – jött a megnyugtató válasz. Huss.
Ez az egy policy akadt csak meg a torkán, nyugodtan nyomtam rá a retry gombra pár perc várakozás után. Be is fejezte a Mailbox szerepkör telepítését, belevágott az utolsó fordulóba, az MBX clusterezésbe.
És belehalt. Közölte, hogy

Summary: 4 item(s). 3 succeeded, 1 failed.
Elapsed time: 00:08:56

Copy Exchange Files
Completed
Elapsed Time: 00:01:13

Management Tools
Completed
Elapsed Time: 00:00:07

Mailbox Role
Completed
Elapsed Time: 00:06:34

Clustered Mailbox Server
Failed
Error:
The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error.
Elapsed Time: 00:01:01

Érted??? Ennyit mondott csak, és itt már nem volt retry. Meghalt a telepítés. Kaptam egy nem clusterezett MBX szerepkört egy clusteren. Sokáig nem is tértem magamhoz. Úristen, hogyan fogom én ezt úgy egyenesbe tenni, hogy később ugyanezen a néven és ugyanezen az IP-n működő CCR szervereim legyenek?
És mi a büdös istenharagja nem tetszett már megint neki a listákon vagy recpolokon? És egyáltalán, melyiken? Hiszen az ügyfélnél volt belőlük épp elég.

A hangulatom…. képzelheted. Dühöngtem. Hogy nem igaz, hogy ezekkel a szar ldap konvertálásokkal ekkorát kell szopni. Hogy nem lehet előre lefuttatni egy próbát, megvizsgálni, hogy végigmenne-e a telepítés. Vagy belerakni a telepítésbe, hogy ha ilyet talál, írja ki egy logba, hagyja ki… és _fejezze be rendesen a telepítést_. Nem hiszem, hogy egy filter ekkor stopper kell legyen a telepítésben. Illetve ha az, akkor meg ne lehessen addig telepíteni, amíg nincsenek rendberakva.
És akkor ott van még, hogy csesznek megmondani, konkrétan melyik filter volt és mi is volt a baj vele. Ha szándékosan akarták volna szívatni a jónépet, akkor sem csinálhatták volna meg ennél aljasabbul.

Tea. Utána nekiálltam feltúrni az eventlogot. És hoppá, ott egy hibaüzenet, benne a bűnös policy neve: Akármi Teszt. Micsoda? Egy teszt policy? Huss. (Későbbi elemzésre persze elmentettem az ldap filtert.)

Most már csak a takarítás volt hátra. Először halványan reménykedtem, hogy talán végigment a telepítés, csak a szervíz nem indult el, de a törlés után majd el fog indulni… és már készen is vagyunk. De megnéztem jobban, ez nem telepített public folder adatbázist… márpedig akkor ez más gazságra is képes lehetett. Radír. (Csak az érdekesség kedvéért jegyzem meg, hogy ez a befejezetlen torzó, ez a nem clusterezett MBX szerepkörű virtuális szerver olyan szépen failoverezett, hogy öröm volt nézni.)
Nem részletezem. Levakartam. Újra telepítettem. Gyönyörűen működött.
Egészen a Rollup Pack 5 telepítéséig. A csomag ugyan nem kért újraindítást… csak éppen mindkét gépen kinyírta a clustert. Egész konkrétan a cluster szolgáltatást. Baromi rondán nézett ki az MMC konzol, tök üresen. De egy bűvös újraindítás megoldotta ezt a problémát is.

Maradt az ldap filter megvizsgálása. Elhiheted, láttam már néhányat… de ebben tényleg voltak meglepő dolgok. Már az is érdekes volt, hogy SID-re szűrt. De a végén volt egy olyan feltétel, hogy (anr=nev*). Ez meg mi a fene lehet? ‘Anr’ nevű tulajdonság nincsen. Gugli.

Hát… itt van a megoldás. Érteni most már értettem… de ki ír ilyen szűrőket egy éles rendszerben? Még akkor is, ha teszt? Ebbe a rendszerbe ilyen szinten csak én szoktam belenyúlkálni, én meg nem emlékszem erre a szürőre. A varázsló…?
Most sajnáltam, hogy egyből kitöröltem. Soha nem fogjuk megtudni.

Ez nem fair

2008-11-25 / / 1 Comment

De tényleg. Azt hittem, hogy ezen a szinten már nem érhet meglepetés. Ha az ember profin hajt egykerekű bringát, akkor nem lehet kihívás a tricikli.

Címtárpreparálás, Exchange 2007 bevezetés előtt. Erről már mindenki leírt mindent, amit csak lehetett. Kockázatos művelet, de ha az ember odafigyel, meg bebiztosítja magát, nem lehet belőle baj.

Ment is minden. Egy ideig. A ‘setup /preparelegacyexchangepermissions’ simán lefutott. A ‘setup /prepareschema’ is… pedig ennél rágtam a legtöbbet a körmöm. Jöhetett a ‘setup /preparead’. Ettől már nem tartottam, hiszen ez már nem szánt olyan mélyen a címtárban.
Aztán kaptam egy valag hibaüzenetet:

The name property contains leading or trailing whitespace, which must be removed.

Hmm… elméletileg egy szavam sem lehet. A Microsoft standard-hez képest kifejezetten korrekt hibaüzenetet kaptam. Pontosan megmondta, mi a hiba.
Csak azt nem, hogy hol.
Hány olyan objektum van, amelyiknek van ‘name’ tulajdonsága? Az összesnek. Cca pár millió lehet az ügyfél rendszerében. Hogyan látod meg, ha whitespace van a név végén? Sehogy.

Na, ez a kihívás, nem a tű a szénakazalban.

Kezdjük szokás szerint a guglinál. Három találat. Elég vérszegény. Az első egy fórum, ahová egy hapi bedobta ugyanezt a kérdést. Választ nem kapott. A második ennek a fórumnak letükrözése. A harmadik meg egy pdf doksi. Azt írja a fazon, hogy nála a Recipient Policy-k között volt egy ilyen név.
Sokat nem segített. Mivel akárhol is kezdhetem a keresést, elkezdtem én is a Recipient Policy-knél. Van vagy húsz. Jobb kattintás, rename, bemeszelés. És a tizenvalahanyadiknál rámmosolygott a szerencse, egy kövér szóvégi whitespace képében.

15-20 perc várakozás, újabb kisérlet: siker.

Egy láthatatlan karakter valahol… mekkora retkes hiba már…

Tétova cluster

2008-11-23 / / 2 Comments

Exchange 2007 CCR cluster Windows 2008 NFSM cluster alapokon… izgalmas dolgok ezek. Nyilván össze is dobtam egy tesztrendszert, hogy nézegessem, simogassam, babusgassam. Na meg időnként agyon is vágjam.
A cluster, mint egy hiperaktív kisbaba, szépen felállt minden fejberúgás után, működött rendesen. Ide-oda terelgettem az aktív node-ot, tette a dolgát. (Már ahogy.)

Aztán eltelt egy hét, úgy, hogy nem nyúltam hozzá. Volt dolgom épp elég, máshol.

A hosszú álldogálás után újra beléptem, barátságosan hátbaszúrtam az aktív node-ot, figyeltem a failovert… mely nem következett be. Közölte, hogy az egyik Storage Group nem állt vissza online-ba, tehát a virtuális szervernek is Sándor. Néztem, mint Rozi a moziban. Oké, failback. Az működött.
Eljátszottam néhányszor ezt a failover/failback testcselt, de az eredmény mindig ugyanaz volt. Remek. Még jó, hogy a tesztrendszeren jött elő. Meg hát az amerikaiak úgyis azon aggódtak, hogy nem fogunk érteni a clusterhez…. nos, akkor itt a lehetőség, hogy kipróbáljam magam: rendbe tudom-e rakni ezt a rakoncátlankodó clustert. Mondjuk elsőre séróból, google nélkül.

Event viewer. Semmi. Annyit mond csak, hogy nem működött a failover – de ezt nélküle is tudtuk. Cluster.log… nos, az már nincs. (Illetve van, de egyelőre ugye google nélkül nyomjuk.) Nézzük, mi a helyzet az EMC-ből. Azt mondja, hogy a storage group adatbázisa (ugye, csak egy lehet) mountolva van, viszont a replikáció státusza: suspended. Hoppá… ez ledőlt pihenni. De miért? Resume, az anyád mindenit. És egyből healthy is lett. Kábé 10 másodpercig, mert utána megint elfáradt.
Nézzük a node-okat: látszólag minden rendben. Megvannak a könyvtárak, hely van bőven a vinyón… akkor mi a francért nem éled fel a passzív node adatbázisa?

Ismételjük át a tananyagot. Hogyan lehet életre lehelni egy hibás adatbázist CCR clusteren?

  • Ha az aktív node-on sérült az adatbázis, akkor eleve nem lehet felmountolni. Ilyenkor a ‘Recover database’ segít, az aktív node-on kiadva: ekkor a passzív node-ról történik egy visszamásolás. Jelen esetben ugye nem ez a helyzet, a Recover menüpontot választva az Exchange csak visszamorog, hogy ‘hülye vagy Ödön’.
  • Amennyiben a passzív node-on lévő példány sérül meg, akkor jön az ‘Update database’, de a passzív node-on kiadva. (Egyébként el sem ronthatjuk, az aktív node grafikus felületén nincs update opció és vica-versa.) De ha már durvulunk, legyünk extra durvák: jelöjük be, hogy mindent töröljön, ami az adatbázishoz tartozik. Ez a tuti. Ilyenkor a passzív node-ról törli a hibás adatbázist, törli a hozzátartozó checkfile-t és a logokat, majd újraseed-eli az adatbázist.

Naná, hogy az utóbbi segített.

Ami a jó hír a történetben, hogy el tudtam bánni a hibával, szolgáltatás nem esett ki. A rossz hír, hogy nem tudom, mi történt. Egy hétig hozzá sem nyúltam a rendszerhez, ment minden… és csak az EMC konzolban lehetett volna észrevenni – ha valaki rendszeresen rá-ránézett volna – hogy az egyik adatbázisra nem megy a háttérben a replikáció. Természetesen ez egész addig nem tűnik fel senkinek, amíg nem történik valami, mely failovert indikálna. Mely ugye ebben az esetben előre nem látott körülmény miatt elmarad. És ekkor már a reseed sem segít, hiszen pont az aktív node dőlt le.

Erre bizony hamarosan megoldást kell találnunk.

Halálra replikálva

2008-11-19 / / 0 Comments

Furcsa ez a szakmai blogolás. Van, amikor hónapokig nem történik semmi érdekes, nincs miről írni. Aztán van, amikor teljesen bevadul az élet, hirtelen rengeteg minden történik – de ekkor meg idő nincs megírni.

Ez utóbbi van most.

Így mindenféle körítés, mindenféle hangulatkeltés, mindenféle érzelemfelcsigázás és feloldás, azaz katarzis nélkül most egyszerűen csak leírom, mibe futottam bele a napokban.

Egy ügyfelünknél Windows Server 2008 alapon rakunk össze egy Node and File Share Majority clustert, melyre majd egy Exchange 2007 CCR cluster kerül. (És ez csak apró része a projektnek… nem mondhatnám, hogy mostanában szénné unatkozom magam.)

Nos, tesztrendszer. Minden frankó, rángatom a clustert, mint Floki a lábtörlőt, failover, failback az MMC konzolból … minden működik. Kisördög belémbúj: mit csinál igazi lehalás esetén? Fogtam, lekapcsoltam az aktív node-ot. Erőforrásék szépen el is haltak, majd elindultak vissza online-ba… kivéve a public folder adatbázist. Az nem. Ugocsa non coronat. Persze emiatt a virtuális szerver sem állt fel. Ráböktem a public folderre: bring online. És visszajött. Szép kis cluster: működik a failover, de csak egy kattintás után. Mint a viccben a Microsoft légzsák. Mi lehet ez: tesztelésnél minden remek, éles hibánál meg halál?
Az eventlogban nyilván nem volt semmi.

RTFM.

De tényleg. Elő kellett túrni a Technet Library-ból azt a cikket, hogyan tervezzünk CCR clustert – és ott szépen le is volt írva. Ez kérem, by design.
Mit is takar az a név, hogy CCR? Cluster Continuous Replication. És hogyan is néznek ki a public folderek? Van egy organizáció szintű hierarchia, melynek tartalma több Exchange szerver adatbázisaiból áll össze. Hogyan disztributálódik a public folderek tartalma? Replikációval. Replikáció itt, replikáció ott. Márpedig két dudás nem fér meg egy csárdában.
Azaz a következő választási lehetőségeink vannak:

  1. Ha CCR clusteren akarjuk tárolni a public foldereinket, akkor azok más szervereken nem lehetnek. Ez működhet centralizált felállás esetén.
  2. Ha intenzíven használjuk a public foldereinket és több telephelyen is el szeretnénk érni azokat, akkor nincs CCR. Pontosabban van, de akkor nem lehet public folder replika a clusteren.
  3. Tojunk az alkotmányra. Ekkor kapjuk a fenti viselkedést: a clusterünk valódi hiba esetén nem fog automatikusan átvándorolni a másik node-ra.

Nos… ez van. Mondhatni, ez egy szimpla tervezési probléma.

Hát… nem egészen. Gondoljuk csak el: egyszerűen nem létezik olyan szituáció, hogy valamilyen/akármilyen rendszer upgrade-jével állítjuk elő a CCR clustert. Az bizony ott helyben születik. tehát a public folder adatbázist is rá kell varázsolni valahogyan. Erre pedig jelenleg csak egyetlen szóbajöhető módszer létezik: replikációval. Azaz teljesen szabályosan járunk el, mégis beleütközünk a 3-as megoldásba. Oké, nyilván nem egy világrengető tragédia… de jobb ha felkészülünk rá, hogy arra a pár napra (ritka lusta jószág ám ez a public folder), amíg a teljes public folder tartalom fel nem másolódik a CCR-re, addig a cluster megszűnik cluster lenni.

[Update]
Asztakurva. Most olvasom egy teljesen harmatos blogbejegyzésben a hamarosan kijövő SP1 Rollup5-ről:

While we will have a full list of issues fixed when the Rollup releases, some of major issues are:
…
Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters

Tehát, ha teljesen logikusan, az egyébként szintén teljesen logikus Windows 2008 alapú CCR clusteren futtatjuk az OABGEN processzt, akkor a – megint teljesen logikusan – cached módba kapcsolt Outlook 2007 userek nem kapnak címlistát. Se rosszat, se jót.
Téphettem volna megint a hajam. Mintha olyan sok lenne.

Névtelen nulla

2008-07-29 / / 0 Comments

Habár a címkonvencióból annyira már nem látszik, de ez az írás az ún. ‘félresiklott projekt’ sorozat része. Akit érdekel a történet többi része is, itt, alul, a ‘félresiklott’ tag-re kattintva tudja elérni azokat.

Akkor csapjunk bele.

A világ legfeleslegesebb nyomógombjai – azaz az UI designer csapat újra száguld.

Leszedném a következő Exchange 2000 szervert. El is indult a telepítő, állítgatja le a szolgáltatásokat. Ekkor jutott eszembe, hogy sokkal biztosabb lenne a művelet, ha előtte én állítgatnám le kézzel a szervízeket, manuálba tenném mindet, újraindítanám a gépet – és utána esnék csak neki a leszedésnek. Gond egy szál se, aktív az ablakon a Cancel gomb, lényegi művelet meg még nem történt. Rákattintottam. Erre feljött egy ablak, hogy “Mit képzelsz? Csak úgy össze-vissza kattintgatsz? Itt fontos dolgok történnek, _nem lehet_ leállítani!”
Alatta két nyomógomb: Igen, Nem. Mindkettőre továbbmegy a remove. (Direkt kipróbáltam később, egy másik szervernél.)

Az anonymous, mint korlátozó lehetőség

Minden rendben. Pontosabban majdnem minden rendben.
A központi site-ról ugyanis nem látszódnak a vidéki telephelyen lévők free/busy információi, amennyiben Outlook 2007-et használunk – azaz nem lehet velük megbeszélést szervezni az egyre terjedő új céges sztenderd munkaállomásokól. Korábbi kliensekről megy, de hát tudjuk, az Public Folder alapú. A 2007-es viszont webes szolgáltatásokon keresztül működik: először SCP, aztán Autodiscovery, aztán Availability szolgáltatások. (Lsd. részletesen ezt a cikket .)
Nem túlzok, hetekig gyököltem rajta. No persze, nem 100%-ban ezen, de ha volt egy kis időm, törtem a fejem. Nézegettem a pfdavadminnal, mi is a helyzet. Ez első ránézésre hülyeség, hiszen ez a rész működik… de kíváncsi voltam, hogy rendben van-e a MAPI hozzáférés a központi site CAS szervere és a vidéki site CAS/MBX/HTR szervere között. (Az Availability szolgáltatás mögött megbújó EWS ugyanúgy MAPI-val dolgozik, mint a pfdavadmin.) És hopp! Rögtön egy hiba:

Could not expand https://utvonal/public%20folders/ : name cannot begin with the ‘0′ character, hexadecimal value 0×30. Line 1, position 416′

Hah! Rávetődtem.
Azt írták, hogy akkor van ilyen, ha nincs feltelepítve a .Net 1.1. Dehát, nem is mondta senki, hogy kell. .Net 2.0, az igen, azt tudom. Már majdnem fel is raktam, amikor elolvastam Jim McBee írását a témáról.

If you get this message, do NOT install the v1.1 Framework on an existing Exchange 2007 server. You run the risk of resetting some of the v2.0 Framework settings and, thus, breaking Exchange Server 2007! If you want to run PFDAVADMIN from the console of an Exchange 2007 server, you need to install the v1.1 .NET Framework prior to building Exchange.

Kár érte. De most már legalább tudjuk, hogy a pfdavadmint _nem_ futtatjuk szerverről, csak munkaállomásról. Mert nem lehet.

Mihez nyúljak? Mármint magamon kívül. Nézzük meg azt a test-outlookwebservices parancsot!
Döbbenet.
A kimenetben az volt, hogy a távoli site CAS Exchange szerverén az EWS szolgáltatás 403-as hibával dob el. Ez ugye az Ekszessz Dániel. Viszont emellett _ugyanez_ a szolgáltatás tökéletesen működik _ugyanarra_ a felhasználóra az OAB tesztben.
Meg kell bolondulni. Ilyen nincs. Ha access denied egy webes szolgáltatás – egész konkrétan ugyanaz az Exchange.asmx progi, akkor igenis legyen következetes. Milyen már, hogy egyszer engedi, egyszer meg nem?

További guglizás. Hoppá .
A figurának pont ugyanaz a betegsége, mint nekem. A megoldás?

it was as simple as change to reject client certificates in IIS Directory security, edit, configuration.

A jó szószátyár nénikédet. Természetesen az IIS adminban _nincs_ ilyen ‘reject client certificates’ menü vagy nyomógomb. De hogyan lehetne másképpen? Metabase turka .
Hú, de ronda. Meg a többiek is: egy , kettő , három , négy .
Nem tetszik. Egyelőre mennek talonba.

Kulimunka következett. Hihetetlen mennyiségű jogosultságot néztem át. (Mert szimatra azért éreztem, hogy itt valami jogosultsági balhé van. Hiszen a 403, az azért elég konkrét utalás.) Felhasználókon, adatbázisokon, mi öröklődik, hol vannak esetleg elvágások, mi van a gyári csoportokkal, /domainprep újra, ki melyik csoportban mit is kap végül, mi van beállítgatva kliens oldalról… jojózott a szemem.
Innen külön üdvözlöm azt a GUI tervező zsenit, aki a jogosultságokat részletező ablakot _nem méretezhetőnek_ álmodta meg, még valamikor 1995 táján, az NT3.51-ben. Amikor szerveren a 640*480 felbontás már vad ollézást váltott ki az adminokból. Aztán külön csókoltatom azt a másik barmot, aki képes volt ezt az idiotizmust változtatás nélkül továbbvinni az újabb meg újabb termékekben.
Itt vagyok, 1600*1200-as monitorom van – és nézegethetek egy bélyeg méretű ablakot, ronggyá szkrollozva a csuklómat.
De itt sem találtam semmi használható nyomot.

Aztán kész. Eddig tartott a hajat vadul lobogtató vágta. Bár még agyalhattam volna a problémán, de vannak más ügyfeleink, vannak más munkáink, várnak az új szopások. Erre már nincs idő.
Eszkaláltunk a Microsoft felé.
Összeállítottam egy derék esetleírást (úgyis kellett dokumentálnom is). A támogató mérnök rögtön kért is pár napot, hogy átolvasgathassa.

Aztán közölte, hogy a test-outlookservices nem mérvadó, felejtsük el. Ez ugyanis szeret localhoston próbálkozni, de ott meg pofán vágják. (DisableLoopbackCheck: itt megtalálod a részleteket.) De jelen esetben ez irreveláns volt, mi 403-as errort kaptunk, nem 401-est.

Nyomoztunk tovább, a szokásos módon: a support irányított, én meg toltam az egeret. Aztán a srác egy helyen felsikított. (Na, jó, többször is, de ez hozta meg a megoldást.)
– Miért van engedélyezve az EWS webszolgáltatáson az anonymous access?
– Hát, izé. A fene tudja. Azt se tudom, mi volt a default. Még az is lehet, hogy fentről örökölte, hiszen egyszer már volt egy jogosultság reset. Lehet, hogy a sokadik kisérletezésnél vagy én vagy a helyi admin kattintottuk be, hátha ettől megjavul a Free/Busy terjesztés.
– Vegyük ki.
– Örömmel… de nem az a bajunk most, hogy túl szigorú az autentikáció? Ha elveszem az anonymoust, akkor csak tovább szigorítok.
– Nem. Ha az van beállítva, hogy anonymous, akkor _nem kér autentikációt_. Viszont később, amikor az EWS a kérelmező nevében fordul a Mailbox szerveren megcélzott postafiókhoz, pofára fog esni, mert mivel nem autentikálta a kérelmezőt, így a nagy büdös semmi nevében szeretne hozzáférni a mailboxhoz. Persze, hogy elhajtják.
– Azannya.

Tehát, értelmezzük. Ha megadom, hogy anonymous, azaz bárki jöhet, akkor azzal tulajdonképpen lehetetlen feladat elé állítottam az EWS-t… hiszen hiába van mellette az is bepippantva, hogy ‘integrated’, az anonymous miatt nem fog autentikációt kérni. És ebben a pillanatben az EWS még nem tudja, hogy én most az OAB-ot kértem el (amelyhez nem kell spéci jogosultság, tehát az anonymous is elviheti), vagy valaki Free/busy információja kell, melyhez viszont kellene jogosultság, pontosabban credential… de az anonymous miatt nem lett credential bekérve. Tehát azzal, hogy kiszélesítettem a kört az anonymous hozzáférésre, tulajdonképpen hazavágtam azokat, akik nagyon szívesen megadnék a nevüket, jelszavukat. Csak nem fogja megkérdezni senki.

De tényleg ez volt a megoldás. Mindenhonnan kivettük az anonymous hozzáférést – és beindult a Free/Busy információk terjesztése.
Ez egy hihetetlen levelezőrendszer.

Echange 2007 és backup

2008-06-23 / / 5 Comments

Ki tudja, mi a viszony az Exchange 2007 és a Windows Server 2008 NtBackup programja között? Illetve, ha már itt járunk, mi a helyzet a Windows Server 2003 NtBackup programjával?

Az első kérdésre könnyű a válasz: a Windows Server 2008-nak nincs NtBackup programja. Pont. A beépített backup program (Windows Server Backup) nem ismeri az Exchange szervert, ergo képtelen menteni is az adatállományait, képtelen kezelni a tranzakciós logokat. Pont. Akinek nem tetszik, el is lehet költözni az országból.
Azért szerencsére ennyire nem durva a helyzet. Megint egy remek iterációs folyamatot figyelhetünk meg. Először az Exchange és a Windows Server 2008 team-ek dugták össze a fejüket, mint megannyi hétfejű sárkány. Aztán azt sütötték ki, hogy tele van az ipar jobbnál jobb külső gyártók jobbnál jobb (oké, csak viccelek) termékeivel – miért kellene annyit görcsölniük a Windows Server Backup-pal? És ebben tényleg van valami, én itt Magyarországon még egy ügyfélnél sem találkoztam NtBackup-ra épülő Exchange mentéssel – pedig mi az amerikai cégekhez képest maximum kerekítési hibák vagyunk. (Na jó, a MOL-nak megszavazok egy nullával való osztást is. 🙂 )
Így is lett. Csakhogy amint ez az egész kiderült, vérig sértett SOHO rendszergazdák kötözték magukat a redmondi mamutfenyőkhöz. Erre beindult a negyedrangú rungekutta, az algoritmus végén pedig kiiterálódott a megoldás: az Exchange-s fiúk készíteni fognak egy plug-int a Windows Server Backuphoz, melynek segítségével VSS-re épülő(!) mentést tudunk készíteni a gyári programmal az Exchange szerverről, tudunk majhd játszani a logtörlésekkel, meg ilyenek. Bár a fejlesztók sejtelmesen megcsillogtatták, hogy a granularitás nem lesz az igaz, de az nem derült ki, ez miben is fog megnyilvánulni: nem lehet majd adatbázis szinten menteni vagy nem lehet inkrementálisat/differtenciálisat menteni? Nem tudjuk. Az egész még csak ötlet szintjén létezik.

Na és akkor mi is a helyzet a 2003 világban? Létezik NtBackup, ismeri a VSS-t, integrálva van az Exchange 2007-tel is. De vajon tudunk-e árnyékmentést végezni Exchange adatbázisról? Nos, VSS ide vagy oda, nem. Illetve igen. Pontosabban, attól függ.
Nagyon nem mindegy, ugyanis, hogy egy adatbázisra pusztán fájlként tekintünk-e? Ekkor működik ugyan a VSS, de az elmentett adatbázis állapota ‘dirty shutdown’ státuszú lesz – és ha belegondolunk, ez teljesen normális is, hiszen nem lettek rájátszva a logok. Ha viszont Exchange-et is értő mentést akarunk készíteni NtBackup-pal, akkor felejtsük el a VSS-t. Ilyesmit csak külső backup programmal fogunk tudni.

Linkek: