E-mail és a detektívek

Exchange, Active Directory, Windows server… és ami még belefér

Show menu Hide menu

Categoryszívás

No Feature!

2011. July 07. Thursday / / 7 Comments

Nem, nem a jó öreg Sex Pistols nótáról lesz szó. Rosszabb. Belépsz egy frissen telepített Windows Server 2008 R2 gépre, tennéd fel a kötelező telnet klienst – és nem látsz se feature-t, se szerepet, sőt, amikor rákattintasz az add gombra, kövér hibát kapsz: RPC hiba. Hangsúlyozom, frissen telepített, patchelt oprendszer, semmi extra alkalmazás.
Nyilván újra lehetne telepíteni a rendszert, de csak a foltozás egy fél nap, ergo ha negyed nap alatt megtaláljuk a hibát, már jók vagyunk. (Mint Mr Garrison az üvegcsővel és az egérrel.)
Természetesen gugli. Lehangoló eredménnyel. Némi képzavarral élve, RPC hibával foglalkozó oldalakkal Dunát lehet rekeszteni. Végül csak sikerült megtalálnom a tűt a szénakazalban: Fix my IT system.

A megoldás több, mint érdekes.

Le kell tölteni a Microsofttól egy segédprogramot, a System Update Readiness Tool nevezetűt. Nem kicsi a szentem, közel 100 mega. Ráadásul nem is csak egy böhöm nagy dll, tele felesleges funkciókkal, hanem tényleg dolgozik. Nálam közel 20 percig futott. Átnézte, hogy mi csúszott szét a patchelések során, milyen inkonzisztenciák alakultak ki – és szépen elrendezett mindent. A biztonság kedvéért ráküldtem egy újraindítást – és szépen megjelent az összes tulajdonság és szerepkör.

Katasztrófa

2010. November 20. Saturday / / 0 Comments

Milyen már, amikor a katasztrófa-visszaállítási teszt során következik be a katasztrófa?

Elmesélem a sztorit. Tanulságos. Először ugyanis elböktük, aztán viszont kimásztunk belőle.

Mivel egy komplett datacentert kellett visszaállítanunk, mondanom sem kell, egy csomó ember nyüzsgött a munkán. Az én feladatom meglehetősen korlátozott volt, a levelezésnek kellett mennie a visszaállítás után, oszt jónapot.
Egy teljesen klasszikus CCR/SCR rendszerről van szó, többször is végigjátszottam már ilyen teszteket, bent volt egy dossziéban a szükséges egységcsomag. Nem mondhatnám, hogy túlzottan ideges voltam. A CCR/SCR replikációra ránéztem még a teszt előtt, normálisan ment.

Aztán egyik délután kilőtték a jelzőrakétát, elvágták a vezetéket a két telephely között. Másnap reggel megkérdeztem a PM-et, hogy tényleg elvágták-e a kábelt. Ja.
Oké, a disable-storagegroupcopy paranccsal kiirtottam az irmagját is a standby node-nak az éles rendszerből, majd vártam, mikor szólnak, hogy mehetek a DR telephelyre, stoppolni. (A kiirtás nagyon fontos: mint nemrég is írtam, ha fizikailag elérhetetlenné válik az SCR, akkor a backup nem törli a logokat, így viszont hamar feltelnek a logpartíciók.)

Eltelt pár nap, szóltak.

Kezdtem az első lépéssel, az adatbázisok macerálásával.

Itt most egy kis kitérő jön. Legyen már szakmai anyag is az írásban, ne csak egy szívás története.
Az SCR node az egy furcsa lény. Felkerülnek rá az Exchange dll-ek, lesz rajta konzol és shell… de Exchange szerver, az nem. Nem fogod látni sehol sem a konzolban. De még a shellben sem. A jelenlétéről is csak akkor fogsz tudni, ha néhány parancsnál használod a -standbymachine kapcsolót.
Ennek ellenére vannak rajta adatbázisok. (Még szép, hiszen ez az egész elv lényege.) Information Store, az nincs. Viszont van Microsoft Exchange Replication szolgáltatás.

Na most, mire is lehet használni egy ilyen szervert?

  • Database portability
    Valamilyen oknál fogva egy adatbázisodat egy másik szerveren szeretnéd felcsatolni. Lehet, hogy kidőlt az SCR forrásod alól a diszk alegység, lehet, hogy kidőlt a CCR-ed alól az az egy SAN, amelyiken mindkét adatbázispéldányok laktak (ugye-ugye), lehet, hogy át akarsz vinni egy adatbázist egy tesztkörnyezetbe. Nos, erre az SCR adatbázisok tökéletesek.
  • Site Resilience
    Az SCR forrásod elpárolgott. Semmivé lett. Te pedig szeretnél máshol, más telephelyen, az előzővel egyező néven létrehozni egy új szervert, majd ez alá felcsatolni az SCR adatbázisokat.

Akármelyik esetről is legyen szó – jelenleg ugye a második játszik – az első lépés az adatbázisok preparációja. Rájuk kell játszatni a logokat – és egyáltalán, olyan állapotba kell hozni, hogy az adatbázis felcsatolható legyen.
Erre szolgál a recover-storagegroupcopy parancs, méghozzá a következő szintaktikával:

recover-storagegroupcopy -identity server\sg -standbymachine scrname -force

Térjünk vissza a konkrét történethez. Kiadtam a fenti parancsot – és azt mondta az a gonosz EMS, hogy nincs ilyen nevű SCR szerverem. Nyilván begépeltem még néhányszor, hátha elütöttem egy karaktert, beírtam a teljes DNS nevével, adtam meg -domaincontroller értéket… hiába. Próbálkoztam a guglival is, de csak annyi választ kaptam, hogy ha ezt írja ki, akkor tényleg nincs a rendszerben ilyen nevű SCR.
Hát ez meg hogyan lehet?

Úgy, hogy – most nem részletezendő okok miatt – még rögtön a teszt elején pár percre összenyitották a két telephelyet. Mi történt? A címtár konfigurációs névtere egyből lereplikálódott a DR telephelyre. Benne az az információ, hogy én akkor már lebontottam az SCR kapcsolatot – azaz nincs SCR a rendszerben. Szépen vagyunk. A DR telephelyen nincs más, amiből építkezhetnénk, csak az SCR node. Ami jelenleg nincs.

Vegyük sorra a lehetőségeket.

  • Húzzunk fel egy kamu clustert az élessel megegyező névvel a DR telephelyen, majd építsünk ki egy SCR kapcsolatot? Az égegyadta világon semmi értelme sincs.
  • Tegyük vissza az SCR szervert az éles környezetbe és építsük ki újra az SCR replikációt? Ez megoldás lenne, de DR teszt során még csak gondolni sem szabad ilyesmire. Nincs éles környezet.
  • Egy korábbi system state mentésből töltsük vissza a konfigurációs névteret – azon belül is az Exchange ágat – autoritatív módon a DR telephelyen? Ez akár még működhetne is, csak éppen ekkor már az összes felesleges DC ki volt irtva a DR címtárból, a meglévők meg már annyira el voltak állítva, hogy esélytelen volt a visszatöltés.
  • Próbáljuk meg Eseutil-lal feljátszatni a logokat? Biztos, hogy a restore-storagegroupcopy csak ennyit csinál? Itt ugyanis az a gond, hogy ha mégsem, akkor nagyot bukunk, mivel a különbség nem itt derül ki, hanem egy későbbi lépésben. Ahonnan már nincs visszaút. És akkor már nincsenek adatbázisok sem, ergo bedőlt a DR teszt levelezési része, az meg azért túl nagy blamázs lenne.

Maradt a jó öreg magyaros megoldás, a buhera. Amit biztosan tudtam, az az, hogy az SCR beállításai a címtár konfigurációs névterében laknak, méghozzá az Exchange Services ág alatt. Mi lenne, ha megkeresném ezeket és úgy csinálnék, mintha lenne még SCR node a rendszerben?
Az első probléma ott volt, hogy honnan találom ki, hol vannak ezek az értékek? A DR telephelyen már nem volt SCR, de az élesen sem. Szerencsére volt hozzáférésem más, hasonló rendszerhez, beléptem, turkáltam. Hadd ne mondjam végig a folyamatot… itt van az eredmény. A beállítások a Storage Group objektumokon vannak (mindegyiken egyenként), méghozzá az MsExchangeStandByCopyMachine nevű változóban, a következő kódolással:

scrname.domain.name;1;xx:xx:xx;yy:yy:yy

Ahol az xx:xx:xx a replaylagtime, az yy:yy:yy pedig a truncationlagtime. Az 1-es értékét nem tudom – de őszintén szólva, nem is érdekel. Nem szándékoztam működő SCR-t létrehozni, csak behazudni a címtárnak, hogy az scrname nevű gépem valóban SCR target volt.

Óvnék mindenkit, hogy éles rendszerben ezeket az értékeket módosítsa. A Microsoft hivatalos álláspontja szerint az SCR replikáció paramétereit csak úgy lehet megváltoztatni, ha lebontjuk a replikációt, majd az új paraméterekkel újra létrehozzuk. Nyilván okuk van rá.

Hozzáteszem, a kockázat most is megvolt. De csökkent! Ha Eseutil-lal esek neki, akkor esély sincs rá, hogy a restore-storagegroupcopy esetleges plusz műveletei lemenjenek. Ha viszont behazudok egy SCR-t, akkor lehet, lefut a restore-storagegroupcopy, a továbbiakban meg már kell a fenének az SCR.

Kiválasztottam egy adatbázist, preparáltam, majd lefuttattam rá a restore-storagegroupcopy parancsot. Molyolt, molyolt… majd a várt 1 warning helyett kettő dobott. Ennek azért nem örültem olyan nagyon, tekintve, hogy a plusz figyelmeztetést olyan szinten voltam képtelen értelmezni, hogy még az se derült ki belőle, hogy lefutott-e a parancs? Vadul nekiálltam túrni a netet, de nem találtam megnyugtató választ. Lefuttattam még egyszer a parancsot… erre megint azt mondta, hogy nincs SCR. Háteztmeghogyan? Hiszen éppen az előbb hazudtam be, hogy van?
Vissza az adsieditbe… és tényleg nem volt ott a beírás. Valaki törölte. Tehát van egy érthetetlen warning-om és belefutottam egy önvédelmi mechanizmusba. Nem túl biztató.

Elvonultam gondolkozni.

A kulcs az, hogy a warning ellenére tényleg megcsinálta-e mindazt, amit tennie kellett? És csak utána törölte-e ki az általam beírt adatokat a védelme?
A törlés biztosan utólag történt, mert hibaüzenetet csak az újabb futtatáskor kaptam. De az a warning… Ráküldtem a parancsot a -verbose paraméterrel. Nem lettem okosabb. Végül úgy döntöttem, hogy ha tényleg képtelen lett volna elvégezni a dolgát – akár egy kezdeti ellenőrzés után is – akkor itt hibaüzenet lett volna, nem figyelmeztetés. Meg egyébként sincs más esélyem, csak ez.
Behazudtam a fenti string-et az összes storage group-nál, beírtam az alábbi parancsot, és malmoztam.

get-storagegroup | restore-storagegroupcopy -standbymachine scrname -force

Jó jel volt, hogy nagyon sokáig dolgozott.

Aztán nagy levegő, gyerünk tovább. DNS preparáció, AD jogosultságok állítása, majd jöhet a vízpróba. Cluster telepítése, a recovercms kapcsolóval. Prerequisit-ek ellenőrzése. 10 perc. Az életemből a tízszeresét vette el. Végül átszaladt rajta. Most jött a döntő pillanat: az első adatbázis felcsatolása.
Sikerült. Aztán szépen egyenként az összes.

Innentől meg már a jól ismert ösvényen mentünk tovább.

Nem az idegbetegek sportja

2010. September 27. Monday / / 0 Comments

Exchange és backup… nem dúl közöttük a barátság. Pedig a backup látszólag nem túl bonyolult dolog: egy adott állapotról másolatot kell készíteni. Már az Exchange 5.5 is tudta, hogy amikor elindult a mentés, akkor “befagyasztotta” az adatbázisokat, ezeket lementette, a mentés alatti adatforgalmat ideiglenes adatállományban tárolta, majd a mentés végén az ideiglenes állomány tartalmát rámásolta az élesre. Ennyi.
Mi lehet a baj?

A tudományos fejlődés.

Az hagyján, hogy a tervezők rájöttek arra, hogy a logfájlokkal rengeteg kunsztot lehet bemutatni: full/copy/inkrementális/differenciális backup… ezek régi dolgok. De a cluster koncepció megváltozása, a tranzakciós logokkal bűvészkedő replikációs fürtök már belecsaptak rendesen a lecsóba. Nem is beszélve a fájlmegfogást megkerülő shadow copy-ról, melynél már nem kell vacakolni ideiglenes állományokkal, a VSS writer tud írni akkor is, ha meg van kötve a keze.
Csak éppen maga a folyamat annyira bonyolult lett, annyira sérülékeny, hogy bármilyen kis rendellenesség hetekig tartó kilengéseket képes produkálni. Gondoljunk bele: egyrészt a Windows 2008-ból eltűnt az Exchange mentés lehetősége, később persze visszajött, de bénán: csak egész kötetet enged menteni. Ha ennél finomabb eljárásra van szükségünk, akkor jöhetnek a külső gyártók. Figyeltél? Külső gyártók. Na, innen indul el a totális káosz. Van egy érzékeny, ráadásul a Rollup Packokkal sűrűn változó rendszer, meg a tipikusan lomha és ügyfélérzéketlen külső gyártó. Pusztán csak idő kérdése, hogy jöjjön az a bizonyos apró rendellenesség, melytől hetekig leng a rendszered.
Mi is az, hogy leng? Ha nem megy a mentés, nem törlődnek a logok, ha betelik a logpartíció, megáll a levelezés, ha törlöd a logokat, megáll a cluster replikáció. Egyáltalán nem véletlen, hogy az Exchange team már évek óta azért küzd népnevelésügyileg, hogy felejtsük már el azt a nyűves backupot, próbáljuk meg kiváltani más technológiákkal.

Csak éppen ebben a népművelésben kicsit sok még a köd. Oké, csinálj clustert (CCR, DAG). Ezzel kivédted a katasztrófát. Ha geoclustert csinálsz, akkor elviseled még a telephelyed megsemmisülését is. Great. De mi van a törölt adatokkal? Használd a dumpstert. Remek számítások vannak arra nézve, hogy akár egy évnyi(!) dumpster mennyivel növeli meg az adattárolási kapacitást. Igaz, az Exchange 2010 alá már közértben vásárolható vinyók is jók, de a hosszútávú dumpster egy átlagos felhasználónál durván évi 1,5 GB növekményt jelent. Oké, természetesen lehet trükközni még az archiv postafiókkal is, de azért itt már komolyan neki kell állni számolgatni, mi is az olcsóbb. Azt ugyanis nem szabad elfelejteni, hogy értelmes összegből akkor lesz egy rendszer backupless, ha eleve annak is tervezik. A legtöbbször már van egy SAN, benne egy vagy két rohadt drága storage, azt mondani, hogy ezt innentől tessék nyugodtan kidobni… elég necces. Brutálisan felbővíteni… szintén.

Itt eredetileg egy eszmefuttatás lett volna arról, hogy és akkor mit csinálunk a módosított adatokkal? Ehelyett meaculpa van. Utánaolvastam, és most már tudom, hogy a dumpster 2.0 verziózni is tud. Persze ekkor megint visszajutottunk oda, hogy tárterület, lapátszámra. Különösen, ha egy cégnek mondjuk 5 évre visszamenőleg kell megőriznie a levelezését.

Illetve gondoljunk át még egy szempontot. Ha nincs backup, mi takarítja el a logokat? A Köztisztasági Vállalat nem fogja. Mi is volt a logika a mentés utáni logtörlésekben? Az adatoknak minimum két helyen meg kell lenniük. Eredetileg ez az adatbázis (RAM+HDD) és a log, a mentés után az adatbázis (HDD) és a szalag. Azaz lehet törölni a logot. Ha nincs backup, nincs törlés. Nyilván utánaolvasol, azt találod – de nem túl hangosan reklámozva – hogy használj 3 node-ból álló DAG-ot (mert ekkor nem kell RAID sem, jó a JBOD), ha van rá pénzed, legyen egy lagged copy is, és ha nem akarsz menteni, akkor kapcsold be a cirkuláris logolást. Az Exchange adminok itt kapnak a szívükhöz: 13 éve azt hallják, hogy négy láb jó, két láb rossz, cirkuláris logolás meg a legrosszabb. Elfogadom, tudnunk kell kigondolkozni a dobozból, de valahogy még mindig meglehetősen el vannak rejtve az infók.

Egyáltalán nem meglepő, hogy egy átlagos informatikus – nem beszélve az átlagos IT vezetőről – sokkal inkább azt mondja, hogy backup.

Akit esetleg mélyebben érdekel a dolog, itt talál egy nagyon részletes négyrészes írást Henrik Walthertől. Kötelező darab a tisztánlátáshoz. De a végén tessenek elgondolkodni, mi is a feltétele a 4. részben leírt visszaállításnak.

Na, a hosszú bevezetés után jöjjön a sztori.

Előzmény. Az egyik adatbázis – kampányszerű üzleti tevékenység miatt – bevadult. A logfájlok kihízták a logpartíciót, adatbázis megállt. (Olyan gyors volt a feltelés, hogy bár a figyelő rendszer beriasztott, de mire beavatkozhattunk volna, már fejre is állt minden.) Oké, a logkönyvtárat a már ismert módon áttettük máshová, adatbázis visszaindult.

Nem sokkal később a CCR/SCR rendszerben volt egy failover, majd valamivel később egy failback. A backup külső gyártó szoftverével volt megoldva, méghozzá úgy, hogy a passzív node-ról – és csak arról – ment VSS backup-pal. Egy bibi volt, a szoftver képtelen lekövetni, melyik node a passzív, így azt tudtuk csak beállítani, hogy arról a node-ról mentsen, amelyik az idő nagyobb részében a passzív node. Ez borult fel a pár napos csere miatt és a backup szoftver teljesen bele is zavarodott.

Közben a szerelők felpumpálták a korábbi adatbázis logpartícióját, lehetett visszarakni a logokat. A művelet teljesen hasonlóan zajlott, az eredmény viszont lesújtó lett: az adatbázist ugyan fel lehetett csatolni, de a replikáció failed állapotba került.

Több évnyi tapasztalat után határozottan ki merem jelenteni, hogy az esetek 90%-ában ilyenkor semmi más nem segít, csak a reseed. Nos, most belefutottunk abba a bizonyos 10%-ba: a reseed sem segített. Fejvakarás. Az eventlog szerint hiányzik egy csomó tranzakciós log, és mindenki az anyja életére esküdött, hogy nem ő dugta el. Ekkor derült ki, hogy nem megy a backup, azaz folyamatosan telik fel az összes logpartíció. Miközben reménytelenül nem megy az egyik adatbázisra a logreplikáció. Nem túl biztató a helyzet.

Kipróbáltunk ezt-azt, ahogy az ilyenkor szokás. Nyilván volt közte néhány failover/failback is. Az egyik különösen izgalmasra sikerült, hosszú percekig nem történt semmi, aztán egyszer csak beröffent a cluster. Aznap nem is mertünk hozzányúlni többet.
Másnap összegyűlt a válságstáb. A partíciók monoton teltek befelé, ötlete meg senkinek sem volt. Pontosabban, nekem volt még egy, de azt mondtuk, hogy ha ez sem jön be, akkor eszkalálunk az MS felé.
De mielőtt nekiállhattunk volna, jött az SMS az üzemeltetőtől, hogy reggel ránézett a rendszerre és teljesen váratlanul megjavult a backup. Magától.
Pár hajam azért égnek állt. Megnéztem, és tényleg. Az összes logpartíció tiszta volt… kivéve a replikálatlan adatbázisét.
Huh. Ezt megúsztuk. Bár a fene tudja, hogyan. Én összeraktam ugyan egy elméletet, miszerint a hosszú failoverbe belehülyült a backup szoftver és nem vette észre a failback-et. Emiatt próbálkozott folyamatosan az akkor már aktív node-on, de ez a backup szoftver meg arra képtelen. (Ezeknek a próbálkozásoknak a nyomait láthattuk is.) Ez ment addig, amíg az egyik failback után hirtelen nem realizálta, hogy jé, failback történt. (Ez lett volna az az idegesítően hosszú failback.)
Hülye elmélet, de nem találtunk jobbat.

Kihasználva a lendületet, aznap délután ráküldtem a renitens adatbázisra is egy reseed-et. Hátha ma olyan nap van, hogy minden sikerül. Nem jött be. Másfél óra szuttyogás, aztán a suspend után ugyanúgy ott vigyorgott a failed.

Másnap éppen nagy paláver volt, a sok futó ügy mellett rátértünk erre az esetre is. Sok jót nem tudtam mondani. A logok replikációja a CCR vérkeringése, ha kiesik belőle egy logdarab, azt a replikációt az életben nem rázzuk gatyába. Legegyszerűbb javításnak azt javasoltam, hogy hozzunk létre egy új adatbázist, mozgassunk át mindenkit, majd töröljük a sérült replikációjút. Erre mindenki rá is bólintott, az üzemeltetők elkezdtek teszt postafiókokat mozgatni. (Mert ekkor éppen nem jutott eszembe a disable-storagegroupcopy parancs.)

Délután két üzenetet is kaptam. Az egyik az volt, hogy nincs semmi gond a postafiók-mozgatással. A másik az, hogy nézzek már rá a storage groupra, mert gyanúsan és makacsul úgy néz ki, mint aki egészséges. Ránéztem… és tényleg.
Na, ilyen nincs. Ekkor kerültek bele a fognyomaim az asztallapba. A többi mellé. Ugyanaz a történet, és már másodszor fordul elő, hogy miután fekete színekkel ecseteltem a jövőt, váratlanul megjavult a rendszer. Magától.
Szerencsére elméletgyártásból borzasztó jó vagyok, egy kis idő után itt is találtam valószínűnek tűnő magyarázatot.

Kapkodtam. Amikor ráküldtem a reseed-et, nem vártam eleget. Ha csináltál már ilyesmit, akkor tudod, hogy egy suspend/resume páros után a replikáció mindig healthy állapotot mutat, majd 1-2 perc várakozás és egy refresh után mondja csak meg az igazi értéket. Na, én éppen fordítva jártam, failed értéket mutatott a reseed után, aztán pár perc múlva váltott át healthy-be. Csakhogy akkor én már éppen hazafelé utaztam. (Hogy ne hidd azt, hogy én a fantáziámból élek. A passzív node-on lévő logok dátum értékéből ki tudtam olvasni, mikor röffent be a replikáció. Ebből tudtam, hogy pár perccel később, mint ahogy előző nap bezártam a terminálablakot.)

Na, mindegy, vészforgatókönyv lefújva. Tulajdonképpen minden rendben. Megy a backup, megy a replikáció, madarak ülnek vérebekhez. Eltekintve attól a szépséghibától, hogy a passzív node-on 1 napnyi log volt, az aktívon meg egy heti. De mivel mind a replikáció, mind a backup ment, meg voltam győződve róla, hogy ez a baki hamarosan rendeződni fog.

Nem így történt.

Eltelt két nap, a backup ment, a replikáció szintén… de a logok csak gyűltek. Alapvetően egy Exchange admin élete nem túl bonyolult, csináltam egy újabb reseed-et. Simán lepucolta a logokat a passzív node-ról. Alakul. Az aktív node-ról elmozgattam máshová a replikáció beindulása előtti logokat (ezek biztosan nem játszanak a replikációban), majd trükköztem egyet. Failover. Ekkor az aktívból lett passzív node. Újabb reseed. Innen is lepucolódtak a logok. Failback.

Elégedetten dőltem hátra. Kifogtam a rendszeren… és végre valamit én javítottam meg, a saját agyammal. Replikáció szépen megy, mindkét node-on üres a logpartíció, copyquelength, replayqueuelength értékek masszívan nullák. Tökély.
Persze az abszolút megnyugvás akkor következik be, ha este lemegy a backup és törli is a logfájlokat.

Nem törölte.

Ha láttál már gyilkos tekintetet… akkor szorozd be kettővel. A jelek szerint minden tökéletesen működik… csak éppen a backup nem törli a logokat. Mivel a szituáció egyfelől nagyon általános, másfelől nagyon speciális, esély sincs megoldást találni a guglin.
Marad a szörfözés az eventlogban. Jegyzetfüzet, plajbász, göngyölítsük fel, mi is történik a mentés során. Semmi rendkivüli. A VSS writer megkapja a kérést, összekészíti az adatbázist, a mentő szoftver elviszi, majd jelzi az ESE-nek, hogy a részéről mehet a log file truncation. Az ESE visszaszól, hogy oké, ahogy születik az új loggeneráció, törli a régit. Majd pár órával később egy replikációs lépés során megemlíti az aktuális generáció számát, mely jóval magasabb, mint amit korábban jelzett. Azaz megtörtént a generációváltás – és minden igérete ellenére, az ESE nem törölte a logokat. Őrület.
Gondolkodósarok. Mikor nem törlődnek a logok? Amikor a replikációnak még szüksége van rá. (Emiatt van az, hogy hiába állítod cirkulárisra a logolást egy CCR rendszerben, amíg nem történik meg a logok replikációja, addig nem harap saját farkába a kígyó.) Jó… de ezzel beljebb vagyunk? A replikáció tökéletesen megy. Két ablakban egymás mellé téve a könyvtárakat, akár még animációnak is elmegy, ahogy keletkeznek, vándorolnak.

Kész, itt adtam fel. Egyrészt volt mellette más, igen sürgős munkám, másrészt meg elfogyott a puskapor. Látszólag minden tökéletes, gyakorlatilag meg nem. Hogyan keressek hibát, ha nincs semmilyen nyom?

Hiba volt feladni. Légyszives olvasd el alaposan az eddig írtakat. Minden információ ott van benne, ami a megoldáshoz szükségeltetik. Lehet, én is megtaláltam volna(1), ha nem azon a bizonyos másik munkán járt volna már nagyobbrészt az agyam.

Mindenesetre a beavatkozás nem tűrt halasztást, a logfájlok megint gyarapodtak, a logpartíció szépen telt, telegetett. Microsoft PSS. Leírtam szépen mindent, amit az esettel kapcsolatban tudtam, az üzemeltető kolléga lett a kontakt, én maradtam cc-ben.

Rögtön az első felvetés beletalált a tizes körbe. Ez ugyanis nem szimplán CCR, hanem SCR rendszer is. Csak éppen azzal a szerencsétlen SCR szerverrel soha nem foglalkozik a kutya sem. Azaz ha egyszer, csak úgy véletlenül, beírtam volna a get-storagegroupcopystatus parancs paraméterei közé a -standbyserver kapcsolót, rögtön kiugrott volna, hogy az SCR replikáció még failed állapotban van azon a bizonyos adatbázison. Emiatt volt még szükség a régi tranzakciós logokra, emiatt nem törölte azokat az ESE. Természetesen rögtön nekiugrottunk annak is egy reseed-del, majd amint helyreállt a replikáció, az esti mentés törölte is a logfájlokat. Ahogy kellett.

(1) Különösen úgy, hogy egyszer már ki is írtam magamnak figyelmeztetésként. Azóta egy másik ügyfélnél csináltunk egy katasztrófa utáni visszaállítás-tesztet, és amikor elővettem a korábbi jegyzeteimet, ott vigyorgott az egyikben a kiemelés:

If the SCR source is a clustered mailbox server (CMS) in a CCR environment, the log truncation logic includes successfully copying and inspecting the log files by all SCR targets. This means that if an SCR target is not available, log truncation does not occur on the SCR source even if backups are taken.
http://technet.microsoft.com/en-us/library/bb676465(EXCHG.80).aspx

Rasszista TLD

2010. January 28. Thursday / / 4 Comments

Kutyafuttában, mert tényleg őrült nagy hajtás van.

Belecsöppentem egy újabb remek nemzetközi projektbe. A héten megy az adatgyűjtés, illetve a tesztlabor összerakása. Nem kicsi laborról van szó, rögtön indulásképpen 5 tartományból álló erdőt kell összekötözni két másik erdővel.

A külső erdőknél igyekeztem semleges nevet választani. Az első az lett, hogy akarmi.akarhol. Szépen le is mentek vele a kísérletek. Ekkor derült ki, hogy az egyik partner élesben már Windows 2008 erdőt használ, tehát azt is le kell tesztelnünk. Így jött be még egy erdő, ennek roppant frappánsan az akarmi.akarhol.2008 nevet adtam. Tartomány működik, kliensgépet be lehetett léptetni.

A DNS rendszereket összelőttem, nslookup oda-vissza feloldott minden címet, minden tartományban. Oké, a biztonság kedvéért jöjjön egy ping. Semmi. Nincs ilyen cím.

Aha. Biztosan elgépeltem. A felfelé nyíllal elővettem a korábbi sikeres nslookup sort, átírtam pingre – nincs ilyen cím.

Aztakurva. Ezt meg akkor hogyan? Az nslookup feloldja a címet, a ping meg nem? Dehát nem ugyanazt az algoritmust használják? Mi van itt?

Egy bájos, nem túl gyakran kommunikált bug. Pedig valamikor mintha olvastam volna róla, csak most későn jutott eszembe: a TLD nem lehet szám. Azaz a tartomány nevében bárhol használhatok számot, de a legutolsó elem nem lehet az.

Lebontottam az új tartományt, létrehoztam egy másikat akarmi.akarhol.longhorn néven – és azóta is tökéletesen megy minden.

Csak éppen kiesett egy fél nap. Azon meg már nem is morgok, hogy valami, akármelyik fázisban, igazán figyelmeztethetett volna, hogy ‘hé, te, ez a cím nem lesz frankó mindenhol’.

Geek úr nyaral

2010. January 20. Wednesday / / 4 Comments

Nem tudom, te hogyan vagy vele, én nagyon aggódós utazásszervező vagyok. Akkor nyugszom meg, ha előre minden le van foglalva, ki van fizetve. Igaz, ekkor meg azon szoktam parázni, hogy időben odaérünk-e mindenhová.

Tudtam, hogy hová akarunk menni a nyáron. Igaz, még január volt, de mivel konkrét eseményre terveztünk, az időpont biztos volt. Maga az esemény miatt jókora tömeg várható, a kiválasztott kemping pedig picike. Ráadásul éppen erős is a forint – ergo minden jel afelé mutat, hogy már most foglaljam le a szállást.

Elmentem a weblapra, megkerestem a Reservation menüpontot.

Nagyítás

Erre feljött egy iframe-be ágyazott webes form. Kitöltöttem az adatokat, rányomtam a ‘send’ gombra. Kaptam egy kövér 404-est.

Nagyítás

Nagyítás

Ez bizony baj. Lemenjek úgy, hogy nincs biztos szállás? Egy ilyen frekventált időpontban?

Akkor már inkább varázsoljunk.

Első lépés: keressük meg, melyik az az oldal, amely végül nem érhető el. Szerencsére a Wireshark mostanában gyakorlatilag bootoláskor indul, így nem okozott gondot a beröffentése. Eljátszottam ugyanezt a foglalást.

Nagyítás

A webes formok adatait az OK gomb megnyomására egy POST paranccsal szokták elküldeni a webes alkalmazás számára. Rakjuk össze a HOST headert és a POST paraméterét: www.veniceincoming/camp/.okmailnew.asp. Ennek az alkalmazásnak kellene átadni a kép alján található szép nagy emaildest változó értékét.
Csakhogy az alkalmazás sztrájkol. Vagy kiment pisilni. Nincs.

Ami elsőre gyanús, az a ‘.’ karakter az URI-ban. Nem szoktak. Írjuk be anélkül az egészet a böngésző címsorába: és rögtön egy alkalmazásoldali hibaüzenetet kapunk.
Első lépésnek jó. Megvan az alkalmazás, a hiba meg jogos, hiszen tényleg nem adtam át semmilyen paramétert.

Nosza.

Alapvetően két stratégia közül választhatunk. Kezdjük az ‘ököllel szöget falbaverős’ technikával.

Megkértem a Wireshark-ot, hogy az elkapott csomagokból rekonstruálja a teljes forgalmat.

GET /camp/auk.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.campingsannicolo.com/uk/contattaci-italiano.htm
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Ez volt a kemping weblapjának lekérése.

HTTP/1.1 200 OK
Date: Tue, 19 Jan 2010 18:19:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Length: 26933
Content-Type: text/html; Charset=windows-1252
Cache-control: private

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<html>

Innen jött egy bazi nagy HTML lap. Miért is? Ugye elment egy GET kérés, arra jött egy 200 OK válasz. Nemrég tanultuk, hogy ennek a válasznak a message blokkjában jön vissza a lekért oldal. Mi választja el a message és a header blokkokat? Üres sor. És tényleg.

</body>

</html>

POST /camp/.okmailnew.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.veniceincoming.com/camp/auk.asp
Content-Length: 342
Cache-Control: max-age=0
Origin: http://www.veniceincoming.com
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

emaildest=info%40campingsannicolo.com&cognome=Jozsef&nome=Petrenyi&
email=jpetrenyi%40gmail.com&fax=&mese_arrivo=05&giorno_arrivo=21&anno_arrivo=2010&
totale_notti=3&numero_adulti=4&numero_bambini=&V-TADU=0&V-B2%2F10=0&V-R%2BAUTO=0&
V-CAMP=0&V-TG=0&N-TX2=0&N-TX4=0&N-R4%2F5=1&N-SP=0&N-LAV=0&N-BICI=0&N-ELE=1&
N-PARK=0&N-PARK-M=0&Note=&Submit=Send

Itt történik a lényeg. Először vége van a nagy HTML oldalnak. (Nyilván közben kitöltöttem a mezőket és rányomtam a Send gombra.) A POST paranccsal indul az adatok feltöltése. Egy csomó fejléc mező után jön az üres sor, majd a message blokkban ott figyel az a karakterlánc, melyet a form rakott össze és melyet az alkalmazásnak már jó étvággyal el kellene fogyasztania.

HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 19 Jan 2010 18:20:12 GMT

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
<!HTML><!HEAD><!TITLE>The page cannot be found</TITLE>

De nem teszi meg, ehelyett visszajön egy 404-es hibakód. (Emlékszünk, kliens oldali hiba.) Azaz nincs olyan weblap – jelen esetben alkalmazás, melyet meg akartunk hívni.
Az üzenet message blokkjában még ott van egy formázott HTML üzenet is, hogy a nem kockafejűek is értsék, miről is van szó.

Nos, itt van előttünk a teljes folyamat. Minden parancsot, minden fejlécet, minden message blokkot ismerünk. Azt is tudjuk, hogy a POST parancsban van elgépelve az alkalmazás neve.

Mire várunk? Putty.

Nagyítás

Rácsatlakoztam a webszerver 80-as portjára. Soronként átmásoltam a parancsokat a Wireshark kimenetéből. Ahogy egy üres enter-rel jeleztem, hogy vége a parancsnak, rögtön meg is kaptam a weblapot.

Nagyítás

Ha ez most egy böngésző lett volna, akkor értelmezte volna a HTML kódot és szép, színesszagos weblapom lett volna. De most szöveges kliensem van, abban meg így néz ki a weblap.
Képzeletben kitöltöttük a formot, vissza szeretnénk küldeni.

Nagyítás

Vegyük észre, a küldés első sorát, a POST parancsot nem ész nélkül másoltam be. Töröltem a ‘.’ karaktert. A többi maradt. A message blokk utáni üres enter után el is ment a csomag.

Nagyítás

Sajnos kiábrándító eredménnyel. Hiába találtuk meg az alkalmazást, hiába adtunk át neki egy teljesen szabályos adatcsomagot, az alkalmazás hibát dobott. Maximum annyi vigaszt meríthetünk, hogy ez egy 500-as hibakód, azaz kliensként már jók vagyunk, most a szerver dobta el az agyát.

Mondtam, hogy van egy másik módszer is. Egyszerűbb is, elegánsabb is… de kevesebbet lehet belőle tanulni.

Első lépésben lementjük az iframe-ben lévő weboldal forráskódját. Remélem, ezt nem kell külön részleteznem.

Nagyítás

Megkeressük a form parancs action paraméterét. És tényleg, ott van a hibás hivatkozás az alkalmazásra. Kijavítjuk, méghozzá úgy, hogy nem a relatív hivatkozást hagyjuk benne – hiszen a HTML fájl most már itt van a lokális vinyónkon – hanem az abszolút URI-t. Elmentjük, megnyitjuk a böngészőnkben. Kitöltjük a formot, send.
Hiba.

Nagyítás

Ugye látjuk, hogy ez szószerint ugyanaz a hiba, mint amilyet a Puttyban kaptunk – csak itt a böngésző jelenítette meg a szöveget.

A hibaüzenetből egyébként annyit lehet látni, hogy ez egy asp.net alkalmazás, méghozzá a nevéből itélve egy levélküldő alkalmazás. Valószínűleg az lett volna a terv, hogy az alkalmazás emailben elküldi a kempingnek a regisztrációs adataimat – csakhogy a formból rosszul hívják meg, nincs megadva az a cím, ahová a csomagot küldeniük kellene.

Ez ellen már nem segít semmilyen trükközés. Megkerestem a kemping emailcímét és elküldtem nekik szép, ember által is érthető szöveges formában a foglalási igényemet.

– Az írás egy hamarosan megjelenő könyv része. –

Megyen a log vándorútra

2009. November 06. Friday / / 2 Comments

Nagyjából éppen a bokáig érő lószarban sárban cuppogtam Moritzburg környékén, amikor egyik ügyfelünk nem kicsit bonyolult Exchange mailbox szervere úgy döntött, hogy torkonszúrja magát. No nem nagyon, de két mailbox adatbázis és a public folder adatbázis leállt. Kolléga rávetődött az incidensre. Hamar rájött, hogy a leállást az okozta, hogy betelt egy log partíció. Egy olyan partíció, ahová ez a 3 adatbázis dolgozott.

Kitérő:

Igen, ilyet teljesítményproblémák miatt nem szoktak csinálni. Csakhogy egész egyszerűen az ügyfélnél annyi adatbázis van, hogy nincs annyi betű az angol ABC-ben, hogy minden log könyvtárhoz külön partíciót rendeljünk. Így a 3 legritkábban használt, legkisebb adatbázis log fájljait egy partícióra tettük.

Nos, a két pici mailbox adatbázisból az egyik bevadult. Nem, nem a korábbi bevadulás, ennek üzleti okai voltak. A vadulás miatt elszabadultak a logfájlok, betelt a partíció, méghozzá olyan gyorsan, hogy a riasztás után már cselekedni sem maradt időnk – aztán leállt mindhárom adatbázis.

Kitérő:

Maga az Exchange mailbox rendszer a következőképpen nézett ki: CCR rendszer egy aktív és egy passzív node-dal, melyhez kapcsolódott egy SCR rendszer egy passzív node-dal.

Tehát ez volt a játszótér és adott volt a feladat. Az ügyfél nyilván ki volt kattanva, hiszen mi az, hogy egy ilyen bonyolult cluster elérhetetlenné válik – és természetesen azt várta el, hogy minél hamarabb megint elérhetőek legyenek az adatbázisok. Kolléga fogta, és a CCR mindkét node-ján elmásolta ugyanazt a nagy kupac régi – ergo már biztosan rájátszott – logot mind a public folder, mind a bevadult adatbázis logkönyvtárából, felmountolta az adatbázisokat és minden be is indult szépen. Az adatbázisok működtek, sőt, a konzol alapján a log replikáció is egészséges volt. Problem solved.

Egészen addig mindenki nyugodt volt, amíg el nem érkezett a mentés ideje. De elérkezett. Le is ment – majdnem minden adatbázisra. Egy, csak egy szaladt hibára, az a bizonyos vad adatbázis. Mely ugye nem véletlenül vadult be, a hirtelen megnövekedett üzleti igények okozták a hízást – azaz meglehetősen fontos adatok kerültek az adatbázisba.

Kolléga még megnézte az eseutil /mh paranccsal, hogy konkrétan milyen log fájlok hiányoznak a passzív node-on – de a válasz az volt, hogy semmi. Rá lett küldve egy reseed (update-storagegroupcopy), de csak annyit csinált, hogy a passzív node-on kiürült a logkönyvtár.

Ekkor érkeztem vissza szabadságról és rögtön meg is kaptam a feladatot.

Helyzetfelmérés:

  • Az adatbázis megy, ránézésre a log replikáció egészséges, az ügyfél nyugodt.
  • Ezzel szemben az aktív node-on rengeteg log van, a passzív node-on egy sem. Az adatbázisok azonos méretűek, azaz a reseeding sikerült.
  • Az SCR node-on az a bizonyos partíció fullon volt, a replikáció az említett adatbázisokon állt. Szemmel láthatóan az SCR-rel senki sem foglalkozott.
  • Viszont mivel nem sikerült a mentés, az aktív node-on pár óra múlva megint elfogy a hely, szóval nagyon gyorsan ki kell találni valamit.

Ergo egyfelől meg kellett akadályoznom az újabb leállást, másfelől össze kellett kötözgetnem a szálakat, mert itt valami nagyon félrement.

A feladat első része volt az egyszerűbb. Kerestem egy üres partíciót (későbbi fejlesztésekre volt is félrerakva egy, de a későbbi szó pont azt jelenti ugye, hogy nem mostani), majd átirányítottam ide a logolást.
Ránézésre olyan egyszerűnek és logikusnak tűnik – de nem az. Nem véletlen, hogy a kollégám sem így próbálkozott. Neki ugyanis sietnie kellett.
Első lépésben ugyanis suspendbe kell rakni a log replikációt. Ez még nem is fáj.
Második lépésben dismountolni kell az adatbázist, ráadásul bizonytalan ideig. Ez már fájt az ügyfélnek, nem is mentek bele szó nélkül. Amikor közöltem velük, hogy ez van, törődjenek bele, nincs más lehetőség, rögtön jöttek, hogy bezzeg a kollégám meg tudta oldani máshogyan. Na, ez a szakma kellemetlen része. Elmagyarázni az ügyfélnek a szakmai finomságokat, úgy, hogy közben a mundér becsületét is megvédjük. Végül azért sikerült tisztáznom, hogy a múltkori az egy gyors, ideiglenes megoldás volt, én viszont már a végleges megoldáson dolgozom.
Ha ezzel megvagyunk, akkor jön a move-storagegrouppath parancs, valahogy így:

move-StorageGroupPath -Identity ‘adatbázis‘ -LogFolderPath ‘ujlogkonyvtar‘ -SystemFolderPath ‘ujsystemkonyvtar‘ -configurationonly

Vagy hogy érthetőbb legyen, konkrét példával:

move-StorageGroupPath -Identity ‘server\vad-adatbazis’ -LogFolderPath ‘Z:\exchsrvr\log’ -SystemFolderPath ‘Z:\exchsrvr\log’ -configurationonly

Határozottan felhívom a figyelmet a configurationonly paraméterre! CCR környezetben a logkönyvtárt ugyanis nem lehet csak úgy átrakni. A parancs hatására a következők történnek:

  • Az AD konfigurációs névterében az érintett storage group tulajdonságainál átíródnak a log, illetve system könyvtárak útvonalai.
  • Emellett az új könyvtár (z:\exchsrvr\log) meg lesz osztva, méghozzá egy GUID névvel. Ha visszanézzük, akkor ez a GUID a storage group azonosítója. A megfelelő jogosultságokat szintén beállítja a parancs.

Végül ha ezen túlvagyunk, akkor manuálisan átmásoljuk a lecsatolt adatbázis log és system fájljait a régi helyről az újra, majd felmountoljuk az adatbázist. Ha nem rontottunk semmit el, akkor el is indul.
Látjuk, az időbeli bizonytalanságot a logfájlok másolása jelenti. Viszont amíg a másolás folyik, addig szét is tud replikálódni a címtárban a változás.

Ezzel a sürgős résszel meg is volnánk, jöhet a kötözgetés.

A biztonság kedvéért ráküldtem én is egy reseedet. Hátha apucitól jobban elfogadja. De semmi. Vágjunk mélyebbre. Újraindítottam a passzív node-on a replikációs szolgáltatást.
És végre történt valami. A replikáció státusza elmozdult az egészséges állapotból. Initializing. A végtelenségig. Vártam rá egy kicsit, aztán eluntam. Ennél még a kamu egészséges visszajelzés is jobb volt. Újabb reseed.

Jobb híján nézelődtem, gondolkodtam. A log könyvtár átmozgatása rendberakta az SCR-t, tökéletesen működik. Azért ez is valami: van egy aktív CCR node-om és egy passzív SCR node-om.
Aztán egy kellemetlen gondolat. Eddig azt mondtam, hogy a logfájlok másolása sértett meg valami ismeretlen dolgot az Exchange rejtett mélységeinek szövetében. De akkor a public folder adatbázisok logshipping folyamatának sem kellene működnie. Aztán mégis működik.
Hjaj. De bonyolult az élet.

Get-storagegroupcopystatus. Mindenki healthy. Egészségükre. Aztán hoppá. A CopyQueueLength értéke a vad adatbázisnál 14234. Mit ír erről a manuál? Azt, hogy ha az értéke nagyobb 3-nál, akkor baj van. Hmm. Ide azért most nem kell fejszámolóművész, itt baj van.

Test-replicationhealth. Minden passed – kivéve a vad adatbázis copy queue értéke. Az viszont nagyon nem.

További nézegetés. Hoppá. Nincs a passzív node-on edb.chk. Ezt azért volt nehéz észrevenni, mert abszolút nincs semmi más sem a könyvtárban. Ez azért magyarázza, miért nem ment le a mentés. (Akinek újdonság lenne: az Exchange az edb.chk fájlba írja, melyik lognál indult a mentés, azaz a mentés után meddig kell törölni a logokat.) Lehetséges, hogy nem csak a backup használja ezt, hanem a log replikáció is? Nagyon lehet, hiszen egy normális reseed úgy indul, hogy törli az edb.chk-t és az adatbázist.
Akkor lehet, hogy nem is jó a látszólag jó reseed?

Mint az ínyenc, aki a legfinomabb falatokat a végére hagyja, én is elővettem végül az event logot. Volt is benne érdekesség.

Nagyítás

Ez legalább világos beszéd, végre. Habár az eseutil /mh szerint nem hiányzik neki logfájl, de az eventlog szerint mégis hiányzik a 84679-es számú. (Azért ezen ne lepődjünk meg. Az eseutil csak az adatbázis épségével foglalkozik – és az adatbázisok tökéletesen jók. Itt a logshipping szakadt össze, de ahhoz az eseutil meg nem ért.) Természetesen ilyen nevű logfájl nincsen. De ennyi szívás után az ember már csak legyint és átszámol hexába: 14AC7. Ilyen nevű log már lehet. De hol? Hát például a kolléga által félrementett logok között, melyeket szerencsére nem töröltünk.
Mi lenne, ha bemásolnám az aktív node logkönyvtárába?
Bemásoltam. Egy perc focilabda rugdosás (az új irodámban nincs darts tábla) – és ott van a log a passzív node-on is. Vérszem. Az az, amit kaptam. Bemásoltam a sorban következő 10 logot az aktív node-ra. Egy percen belül megjelentek a passzív node-on is. Ujjé. Elkezdtem név alapján bogarászni az éles log könyvtárat és a mentett logok könyvtárát. Úgy tűnik, hogy az egyik a zsák, a másik meg a foltja. Ha a félremásolt logokat átmásolnám az éles logkönyvtárba, akkor zárt lenne a sor.

Persze ehhez több hely kell.

Újabb telefon az ügyfélnek. Leállnánk pár percre, ugye nem baj? Ügyfél füle egy kicsit rángatózik.

Átmásoltam a logokat egy nagyobb partícióra. (Igen, ez már adatbázispartíció volt. De csak a mentésig lesznek itt a logok, addig meg kibírják.)

Utána pedig megtörtént a nagy családegyesítés. Elvonultam gyakorolni a külső csavarást a nyomtató asztalának lábai közé. 20 perc műlva néztem vissza – és a logok szorgalmasan másolódtak át a passzív node-ra. Remek.

Legyen teljes a győzelem: újabb get-storagegroupcopystatus. A CopyQueueLength értéke szépen le is csökkent… de miaf… elkezdett növekedni a ReplayQueueLength értéke. Ugyan – hessegettem el a kellemetlen gondolatot – ez most kapott hirtelen 14000 logot, persze, hogy nem tudja ilyen tempóban rájátszani. Hagyjuk békén, holnap reggel majd meglátjuk, mi lesz a vége.

Eljött a holnap reggel. A győzelem érzésével gépeltem be a jó öreg get-storagegroupcopystaus parancsot – és a ReplayQueueLength értéke 500 körül volt. Az első gondolatom rögtön az volt: miért? A nullát el tudtam volna fogadni. A 14000 körüli értéket szintén. De miért pont 500?
A magyarázat gyorsan jött. Konzol, gyors vizuális pásztázás: a vad adatbázisnál a logshipping státusza failed. Aha. 500-nál besokkalt, aztán azóta coki.

Hát. Tulajdonképpen előrébb vagyunk. De a beteg még mindig kómában fekszik.

Most már nem álltam neki ködöt rágni, mentem egyből az eventlogba.

Nagyítás

Nagyítás

Keressünk rá a hibakódra. Azt írja, hogy a 1216 azt jelenti, hiányzik néhány tranzakciós log. Kérdezzem le az eseutil /mh paranccsal, mely logok hiányoznak. Lekérdeztem. Semmilyen log sem hiányzik.

Bakker. Mégis köd. Azért ez már kezd bizarrá válni: egyfelől azt mondja, hiányzik neki x darab log, ahhoz, hogy rájátssza végre az összes logot arra az adatbázisra, amelyikre már jó egy hete rá van játszva az összes log – másfelől pedig konkrét kérdésre azt mondja, hogy nem is hiányzik neki egy log sem.
Csak éppen nem indul el a rájátszás.

Ekkor már teli csőrrel gyakoroltam a védhetetlen bombákat a szerverszoba ajtajára.

Végül visszadaráltam az elejére. Emberek, végülis… már van edb.chk fájlunk a passzív node-on. Ez jó hír.
Töröljük gyorsan le. Azaz küldjünk rá egy reseed-et. Mert mi van, ha az a baj, hogy az adatbázis – amelyikre már rá van játszva minden log – nincs szinkronban a logkönyvtárban lévő edb.chk-val, mely még csak nemrég jött létre, a replikáció befejeztével. A reseed ugyanis törli mindkettőt, majd újra létrehozza, immár szinkronban.

És tényleg.

A ReplayQueueLength értéke egyből lenullázódott, a logshipping meggyógyult. A pezsgőbontással vártam még tíz percet, mert ez a nyomorult replikáció képes megint elromlani – de nem.

Tanulság:

  • Amíg elő nem varázsolom valahonnan a hiányzó logokat, addig felesleges a reseed. Nincs értelme. Nincs edb.chk.
  • Ha megvannak a logfájlok, akkor vissza kell másolni az aktívra, a logshipping beindul, legyártódik az edb.chk. Ekkor viszont kötelező a reseed, mert ez hozza összhangba a két node-ot.

Végül egy kényelmetlen gondolat:

És akkor mi van, ha közben töröltem a logokat?
Nos, végső esetben az SCR-en ott kellett lenniük.
De mi van, ha onnan is töröltük? Gáz.
Szóval óvatosan azzal a közvetlen logpiszkálással.

ps.
Elkiabáltam. Utólag derült ki, hogy az SCR node-on sem megy a rájátszás, ott is újra kellett seedelni az adatbázist és a logokat.

Ha internet van, minden van

2009. October 15. Thursday / / 7 Comments

Igenám… de ha nincs, akkor mi is van?

Bár nem is ez az igazi kérdés. Hanem az, hogy miért feltételezték a fejlesztők azt, hogy internetkapcsolat, az mindig lesz?

Kezdjük rögtön az elején. Az Exchange 2010-nek vannak szigorú előfeltételei. Ezek közül néhányat elég a netről letölteni, viszont ott van a .net 3.5sp1, amelynél csak a trailert tudod lekapni, a telepítés maradék része online megy. (Vagy WSUS-ról, persze. De pont a .net 3.5 sp1 esetében láttam már WSUS-on keresztüli nem túl normális települést egy ügyfélnél.)

Itt volt az a pont a tesztlabor összerakásánál, ahol megakadtam. Eredetileg úgy képzeltem, hogy az egész labor csak a virtuális hálón belül lesz látható – nemhogy az internet felé, de még csak a céges háló felé sem fog látszani. De hát a .net… ideiglenesen benyitottam a cég felé, onnan meg kifelé a netre. A sikeres telepítéshez még be kellett konfigurálnom a winhttp proxy beállításait, aztán hajrá. Fel is szaladt a .net, el is távolítottam a plusz hálózati kártyát.
Mentem tovább.

Eljutottam odáig, hogy végignyomkodtam a setup GUI-t, az pedig lelkes tüzijáték mellett közölte, hogy sikerült a telepítés. Aztán megkérdezte, hogy most rögtön szeretnék-e belépni a menedzsment konzolba? Persze. Tekerés, homokóra… majd közölte, hogy a gépen nincs Exchange szerver.
Miközben a háttérben még durrogtak a petárdák.
WTF?
Elindítottam a shellt, de hasonlóan jártam. Az azt mondta, hogy nem fut az IIS, meg a WinRM. Naná, hogy futott mindkettő.

Nagyítás

Nem kicsit néztem ki hülyén a fejemből.

Aztán szerencsére beugrott a megoldás. Hiszen mind a shell, mind a konzol powershellre épül, az pedig lokálisan is távoli elérést használ, azaz a winrm-en keresztül szeretne kapcsolódni a szerverhez. Mivel a winrm fut, a gond csak ott lehet, hogy a szerver nem találja magát. Miért is? Mert a winhttp-ben bentmaradt a proxy konfigurálás, a hálókártya meg már ki lett szedve. Az Exchange szerver nem találta meg a proxy szervert, emiatt meg nem találta meg magát. Ahogy töröltem a winhttp proxy beállítását, egyből lett konzolom, shellem.

Sóhaj. A lényeg, hogy immár minden rendben.

A megkönnyebbülés addig tartott, amíg valamit meg nem akartam nézni a beépített Help-ben. Nincs. Nincs offline Help. Csak olyan van, mely egyből a netre akar tenni.

Itt kezdtem el meredten nézni a plafont. Mi ez az idiotizmus? Miért kellene egy Exchange szervernek internet kijárat? A CAS szervert ISA szerveren keresztül érjük el, úgy, hogy ki van publikálva a 443-as portja. A HTS szerver elé ma már kötelezően kell egy smarthost – mely ugye lehet akár egy Edge Trasnport szerver is. A Mailbox szervernek pedig abszolút semmi köze nincs az internethez. Hogyan gondolják akkor, hogy nincs offline Help?
Jó, nyilván megoldható. Általában úgyis rdp-n keresztül lépek be, tehát a gazdagép böngészőjéből tudok keresni… de akkoris kényelmetlen.
Meg szemléletileg fura.

A setup csapat valószínűleg még mindig be van lőve

2009. October 15. Thursday / / 1 Comment

Hosszú sorozatot indítok el ezzel az írással. Nemrég tartottam egy – számomra is meglepően hosszú – előadást az Exchange 2010-ről. Nem tudom, más hogyan csinálja, nálam felkészülés során egy csomó cetli szokott keletkezni, melyeket aztán vagy felhasználok, vagy sem.

Ezekről a fecnikről fogom előszedni sorban a témákat.

Még egy megjegyzés. A sorozat az RC verzióval megtapasztalt élményekről szól. Az RC ugye feature tekintetben lezárt, de működni még nem működik hibátlanul – márpedig az MS ebben az utóbbiban nagyon jó. Ergo minden morgásnál tessék hozzáérteni, hogy jó eséllyel a végleges verzióban ezek javítva lesznek. (A sorozat végére valószínűleg elérhető lesz az RTM is, abban le fogom ellenőrizni a számomra fájó hiányosságokat – és remélhetőleg revideálnom kell majd az írásokat.)

Csapjunk bele.

Az Exchange 2007 messze kiemelkedően legrosszabb, legvacakabb, legfrusztrálóbb része a setup alkalmazás volt. Rengeteg írásban mondtam már el a véleményemet… bár néha úgy érzem, hogy még mindig nem dühöngtem eleget.

Nyilván borzasztóan kiváncsi voltam, ehhez képest milyen lesz ez a modul az új termékben.

Háát…

Problémába ugyan nem ütköztem, bosszantó kellemetlenségekbe inkább. Ráadásul úgy, hogy a laborkörnyezetben abszolút zöld mezős telepítés folyt, a címtár is, az Exchange organizáció is frissen lett kialakítva, maga az Exchange szerver teljesen általánosan tartalmazta a három fő szerepkört – igazából észre sem lett volna szabad vennem magát a telepítő programot.

Észrevettem.

Bár először csak szélesen vigyorogtam. A Microsoftnak ugyanis sikerült megoldani azt a régóta fennálló kellemetlen problémát, hogyan is tudnák rávenni az olvasót parancssori telepítésnél, hogy olvassa el a licensz szerződést. Születtek persze erre korábban is megoldások, pl. egy felhívás, hogy olvasd el… de ezzel a módszerrel ugye nem lehetett úgynevezett határozottan ráutaló magatartást kicsiholni a felhasználóból.
Lássuk, mit izzadtak ki a hegyek.

Nagyítás

Az történik, hogy amikor elindítod a programot, elindul egy várakozási ciklus. A program megvárja, hogy elolvasd az általa jelzett címen található szerződést. Az idő múlását pöttyök kirakásával jelzi. Ha elveszítenéd a türelmedet és nyomsz neki egy kövér space-t, azzal azt jelzed, hogy nem fogadtad el a szerződést. Végig kell várnod azt az időt, amennyi a programtervezők (feltéve, hogy volt ilyen) szerint arra kell, hogy elolvasd a szerződést.
Mókás.
Elsőre.

Csakhogy a fenti várakoztató eljárás a program minden futásakor elindul. Márpedig egy címtár preparálás – még ha minden simán megy – akkor is négy futtatást igényel.

De az asztalomon a tíz párhuzamos csík nem ekkor keletkezett. Hanem a harmadik lépésben, ahol elfelejtettem megadni egy paramétert. (Szűz telepítés, meg kell adni a keletkező organizáció nevét.)

Nagyítás

Nézzük végig, mi történt. Kiadtam a ‘setup /p’ parancsot. Megjelent a szerződésolvasós abuzálás. Kivártam. Aztán a telepítő bőszen elkezdte felolvasni a szükséges fájlokat. Majd amikor felolvasta, akkor írta vissza, hogy elfelejtettem megadni egy paramétert.
Érted. Végigváratta velem a szerződés tanulmányozására szánt időt, felolvasta a fájlokat – és csak ekkor vizsgálta meg az általam beadott parancsot és vette észre, hogy hiányzik egy paraméter.

Egyszerűen nem túl sok értelmes magyarázat adódik a húzásra. Oké, lehetne mondani, hogy önmagában a setup.exe-ben nincs benne az a tudás, hogy melyik indítási üzemmódhoz milyen paraméterek szükségesek és ezt egy xml fájlból olvassa fel – de ez sem ad magyarázatot arra, miért kell megvárni az ellenőrzéssel a licenszolvasási nyaggatást. Jelzem, nem is az az 1-2 perc zavar, amíg várnom kellett (el tudtam tölteni hasznosan), hanem az ijeszt meg, hogy ha enyire felületesek még ilyen egyszerű esetben is, akkor mire számíthatok bonyolultabb forgatókönyvek esetén?
Féljek annyira, mint a 2007-esnél?

ps.
Találd ki, hogy amikor végre eljutottam a setup GUI-hoz, mi volt a harmadik képernyő?
Úgy van: a licensz szerződés. Melyet le kellett okéznom.

Szorgos hétköznapok

2009. September 07. Monday / / 3 Comments

A feladat első lépése: telepítsünk HP Blade szerverre Windows Server 2008-at. Nem nagy ügy, virtual media bekonnektálva, nextnextfinish. ILO-ról beléptem, a hálókártyát beállítottam, a hardveres kolléga fellapátolta a PSP-t… aztán más projektre szólított a kötelesség. Miután ott eljutottunk odáig, hogy a labda már az ügyfél oldalán pattogott, jöhettem vissza a blade szerveremhez. Melyet időközben tokkal-vonóval, cage-dzsel, storage-dzsal átcipeltek egy másik épületbe. Ez ugye az alkalmazástelepítőt nem érdekli, a lényeg, hogy a drót túloldalán ott ficánkoljon a vas.

Nos, ez ficánkolt. Például az általam beállított IP címen nem tudtam elérni. ILO. A kártya DHCP-n volt. Visszaállítottam. Erre közölte, hogy ilyen konfigja már van egy hálózati kártyának, akarom, hogy azt törölje? Na, a hülye megőrzött valami régi értéket… persze, töröld, fiam.
Gépnév? Ez is átalakult valami random krikszkraksszá. Visszaneveztem, újraindítás. Megint nem lehetett elérni RDP-n. ILO. A hálókártya megint DHCP-s lett. Ekkor tűnt föl, hogy megváltoztatta Local Area Connection mögött a számot. Mi a fene? Ez minden újraindításkor újradetektálja és új kártyának ismeri fel a meglévő hálókártyáját? Visszakonfiguráltam. Megint figyelmeztetett, hogy ilyen konfig már van. Töröld, b+. Az OK után kiváncsiságból visszanéztem: kitörölte a DGW értékét. Visszaírtam.

Mehettünk tovább.

Átnéztem a rendszertervet – és kiderült, hogy más IP tartományba kerültünk, mint amit 1 hónappal ezelőtt tudtam. Már remegő kezekkel mentem be az IPv4 beállítások közé. Átírtam az IP címet, újraindítottam a szervert. Mondanom sem kell, megint elveszett. ILO. Újabb szám a hálókártya neve mellett – és persze DHCP-s. Káromkodás. Visszakonfiguráltam, dühösen lenyomtam a figyelmeztetést, miszerint egy nemlétező hálózati kártyának is ugyanez a konfigurációja. Dögölj meg. A beállítás után visszanéztem: és eldobtam a billentyűzetet. Nem csak a DGW-t törölte ki, hanem visszaállította a régi IP címet is. Kijavítottam. Leokéztam. Visszanéztem. Megint átírta az IP címet.

Ekkor néztem körbe, hová van elrejtve a kandikamera.

Gép újraindítás. Jé, most nem lett DHCP-s. IP konfig, beírtam a DGW-t, átírtam az IP címet – és végre bele is törődött, nem bírált felül.

Oké. Next.

Léptessük be a tartományba. Belépett. Kért egy újraindítást. Ajjaj.

Természetesen megint DHCP-s lett, valami lehetetlen címmel. ILO. Megint befaragtam. Megint visszaragadta a régi IP címét, miközben törölte a DGW-t. Újraindítás. Megint befaragtam. Jó lett.
Huh.
Innentől már volt net. SP2. Gondolom, kitaláltad: újraindítás, DHCP, befaragás, régi IP cím, Default Gateway, újraindítás, befaragás.
Windowsupdate. Újraindítás. DHCP, bef, rIP, DGW, újr, bef.
Itt történt egy érdekesség: az időközben felugrott maliciózus kódokat kirugdosó program mellékesen megjegyezte, hogy volt valami conflicker.b a gépen, de letúrta.
Bakker.
Amíg átmentem a másik projektre, a gép csak úgy állt ott, mint szende lófütty a vadvirágos réten… a conflicker meg beporozta. Szóltam a permetezős kollégáknak, hogy fertőtlenítsenek. Nem mintha nem bíznék meg a maliciózus removal tool-ban… de nem bízok meg. Nos, jelzem, hogy meg lehet – a gép tiszta lett. Csakhogy a kolléga nekiállt feldobni egy SEP-et – és találd ki, mi lett belőle? Újraindítás. DHCP, bef, rIP, DGW, újr, bef.
Pedig itt már azt hittem, hogy megvan a bűnös, innentől már rendben lesz minden.

Bevadultam. Kitöröltem az összes hálókártyát. Becsörtettem a registry-be, kitöröltem minden olyan GUID nevű objektumot, ahol a Connection alobjektumban szerepelt a ‘Local Area Connection’ string. Végül újratelepítettem a HP PSP-t.
Újraindítás. Nos, az eddig letiltott két hálókártya eltűnt. Maradt az az egy, amelyiken link is volt. És átváltott DHCP-re. Bef, rIP, DGW, újr, bef.

Ekkor már keményen délután volt. Az egész napom azzal ment el, hogy egyszerűen csak hozzá akartam férni egy géphez. Közel 9 órát töltöttem el ILO felület előtt – és ha volt már hozzá szerencséd, akkor tudod, mennyire frusztráló is tud ez lenni.

Kész. Projekt lefújva. Ezek voltak az első gondolataim. Másik hardver nincs, ez lett volna egy cluster első node-ja… de egy ennyire kiszámíthatatlan hálózati kártyával öngyilkosság lett volna belevágni. Jön egy failover, aztán DHCP-re vált a kártya. Jól néznénk ki.

Ekkor kezdtem alaposabban gondolkodni. Tényleg nem értem néha magamat. Nagyon szűk határidő, sok feladat – és egy egész napot végigszívok egy lehetetlen hibával, lehetetlen körülmények között – ahelyett, hogy egyből gugliznék. Vagy nák.
Viszont még csak elképzelésem sem volt, hogyan fogalmazzam meg a jelenséget, emiatt kiindultam abból a ritka hülye üzenetből, miszerint egy régi, már nem használt hálózati kártyámnak is ugyanaz a konfigurációja, mint a mostaninak.
Nem írom le a teljes vadászatot, több ugráson keresztül ugyan, de eljutottam ide . Ránézésre baromira nem stimmel. XP. Meg nem konnektált hardverek a Device Manager-ben.

Device Manager displays only non-Plug and Play devices, drivers, and printers when you click Show hidden devices on the View menu. Devices that you install that are not connected to the computer (such as a Universal Serial Bus [USB] device or “ghosted” devices ) are not displayed in Device Manager, even when you click Show hidden devices.

Ez a lényeg kérem, a dőlt betűs rész. Ghost egységek. Hát mi a fene lehet ez, mint egy kupac szellemként rejtőzködő, valójában nem létező hálókártya? Gondold el: van egy hálózati kártya, melyet egyszer így ismert fel, egyszer meg úgy. És ezeket váltogatja. Ilyenkor úgy érzi, hogy kivettem egy hálókártyát és betettem helyette egy másikat. A réginek megőrzi a konfigurációját – mert hátha egyszer vissza fog kerülni – az újat meg DHCP-re rakja. Aztán amikor én beállítom az újon ugyanazt a konfigot és azt mondom neki, törölje a régi hálózati kártyát – akkor nem magát a kártyát törli, hanem csak a konfigját. Jön a következő boot, ekkor a másik kártyának ismeri fel – és kezdődik minden előlről.
Nyilván valami hasonlóra gondoltam én is – de a Device Manager-ben hiába kapcsoltam be a Show Hidden Device opciót, ez csak az ellenség megtévesztése volt. Nem mutatott ez semmit, maximum a szélben lengedező lófüttyöt azon a vadvirágos réten.

Előtte ugyanis el kell indítani egy command promptot adminisztrátori joggal, majd beadni neki, hogy:

set devmgr_show_nonpresent_devices=1

Vigyázat. Én legalábbis megszoptam. Ha ezután elindítottam a Control Panelből egy Device Manager-t, akkor a Show Hidden Device után megint a jólismert árvalányhajas lófütty jött. Ez ugyanis már másik session-nak számít. Azaz nem vagánykodásból kell a promptból indítani a konzolt.

start devmgmt.msc

Na, ekkor jött meg az összes fantom hálózati kártya. Mind a tizensok.

Nagyítás

(A kép már egy későbbi állapotot ábrázol – de jól láthatóak a piros X-szel megjelölt fantom hálókártyák.)

Egyenként kitöröltem a bagázst – és minden rendben lett. Félórán keresztül csak restartoltam, IP címet állítgattam… de tényleg minden rendben.
Aztán eltöltöttem még egy kis időt, mire gatyába ráztam a WINS és DNS szervereket – szegények, mit képzelhettek erről az állandóan máshogy bejelentkezgető hostról – és kész. Jöhet a cluster.

Első lépés: faiover cluster feature telepítése. Lement. Reboot. Na?
Úgy van. DHCP. Csak most ugye megspékelve azzal, hogy a a failover cluster a régi adapterhez rendelődött hozzá, az újnál meg semmi. Illetve lófütty. Hálókártyák rendezése, failover cluster le, failover cluster fel, restart. DHCP. Bef, rIP, DGW, újr, bef.

Péntek éjfél. Ekkor fejeztem be aznapra, mert sürgős kardbadőlhetnékem támadt.

Szombat: új nap, új remények. Először eltávolítottam a rendszerből a HP NIC drivereket, hogy ne tudja keverni, milyen hálókártyának ismeri fel. Nem segített. Sóhaj, partíció töröl, operációs rendszer újratelepül. Kisérletképpen HP PSP nélkül. És csodák csodája, minden muzsikál. A 3 hálózati kártya masszívan tartja magát, se a gépátnevezés, se a tartományba léptetés nem hatja meg. Huh. Ellenteszt. Felraktam a HP Support Pack-ot, restart. DHCP. Bef, rIP, DGW, újr, bef.
Oké. Megvan a bűnös. Valamelyik program/driver a csomagból behülyíti a Windows-t.
Partíció radír, Windows újratelepül. Belépek… erre a hálózati kártyán még mindig ott volt az előző domaintagságra utaló hálózati név. Hát ez meg hogyan élte túl a teljes újratelepítést? Megnéztem a hálózati részt, ott vigyorgott a fantom kártya. Azannya. Újabb gyalu, a biztonság kedvéért 5 GB-vel kisebb új partícióra. Ha ezt is változatlanul éli túl a hálókártya, akkor elnevezem David Copperfield-nek.(1)

(1) Persze én voltam a hülye. Egyszerűen csak DHCP-re váltott, IP címet kapott, azon meg felismerte a tartományt. Csak nekem volt furcsa, hogy frissen telepített oprendszer már tartományt mutat.

De nem. Teljesen szép, szűz Windows 2008 jött fel. Oké. Hálózati kártya bekonfigurálva, gép átnevezés, reboot.
DHCP. Bef, rIP, DGW, újr, bef. Kardbadőlés.
Abszolút üres Windows, sehol semmi – és ott vigyorog a fantom kártya. Ami a reboot előtt az éles kártya volt. Aznapra ennyi jutott a sikerélményekből.

Vasárnap. Sebnyalogatás.

Hétfő. Ekkor már valamennyire állnia kellett volna a clusternek… ehhez képest legszívesebben már rég elhantoltam volna azt a szutyok vasat. Új ötlet. Hardveres kollégával konzultálva kiderült, hogy a gépben egy duálportos és két single portos hálókártya van. Mivel a cage csak három hálózati kimenettel rendelkezik, így az egyik hálózati kártyát letiltották – csakhogy ez pont a duál portos egyik portja lett. Lehet, hogy ettől hülyült meg a Windows. Mivel nekem elég a két hálózati kapcsolat, így váltunk: letiltják a duál portost és marad a két másik.
Kolléga elutazott a szerverekhez, átkonfigurálta.
Teszt.
Két fantom hálózati kártya vigyorgott vissza. Meg a tükörből az őrület. Aztán a remény fénye: lehet, hogy ez a két fantom még korábbi kisérletezések maradéka? Töröltem, Scan for new hardware… és nincs több fantom. Kezdtem reménykedni. Megint Scan. Még mindig jó. Kérem… én nem ehhez vagyok szokva. Elkezdtem őrült módon mindenfélének átnevezgetni a gépet, majd újraindítgattam. (Később csak az volt egy óra, míg a WINS szervereket kipucoltam.) De tartotta magát a gép, nem jöttek elő a fantomkártyák. Jöhetett a tartománybaléptetés, a HP PSP csomag… meg minden más.
28 órányi munka alatt eljutottam oda, hogy elkezdhettem bekonfigurálni az operációs rendszert. Miközben az egész cluster elindítására volt 3 munkanapunk. Szerencsére volt közben egy hétvége – az ugye nem számít, maximum csak nekem, de az meg megint nem számít. Így ha hajnalig nyomom, akkor esély van utolérni magunkat. (Kedd reggelre igértük a működőképes clustert.)

Szóval így.

Proxycfg

2009. September 04. Friday / / 0 Comments

Csak jelzem, hogy élek.

Apró feljegyzés, leginkább magamnak.

Windows Server 2008. SP2-t felraktam. Már csak a maradék hotfixek hiányoztak. Windowsupdate, azt mondta, szétnéz… majd hibaüzenet.
Rutinos öreg róka már gépelte is be, hogy: proxycfg. Erre jött a válasz, hogy: miről beszélsz?
Hmm. Nincs. Végre egy kis izgalom. (Ezt tessék ironikusan érteni.)

De van helyette netsh. Így:

netsh
winhttp
show proxy

És igen, a beállított érték ‘direct access’ volt.

set proxy isaserver:8080
show proxy

És kész. Innentől már söpört is a windowsupdate.

Trükkös HTTPS

2009. August 12. Wednesday / / 0 Comments

Az ember már azt hiszi, ismeri az ISA szervert – aztán az mégis meg tudja lepni.

Jött a kérés az ügyféltől, hogy egy kollégájuk szeretne elérni egy weblapot a 8443-as porton. – Na, megint egy istentől, embertől elrugaszkodott webmester – gondoltam – akinek túl kerek szám a 80-as.

De gond egy szál se, pillanatok alatt összedobtam a megfelelő szabályt.
– Teszteljetek! – írtam vissza.

Nem működött.

Ekkor néztem meg jobban, miről is van szó. Jé, ez https. Persze, csaptam a fejemre, csak én lehetek annyira vak, hogy nem ismerem fel, hogy a portszám csak egy számjegyben különbözik a 443-as https porttól.
– Aha, szóval ez egy szupertrükkös webmester – konstatáltam – aki így akarja átvágni a rosszfiúkat. Szvsz elég béna megoldás, ha én portszkennelnék, simán felvenném ezt is a listára, oszt jól van. Cserébe szopatják a tűzfal mögül érkezőket.

Na, mindegy, nézzük, mi van a logban.

The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests.

Kösz, Csoki. Most, hogy már tudom, hogy a legtöbb böngésző a 443-as portot használja az SSL-hez, most már biztosan nyugodtabban fogok aludni.

Némileg persze bosszantott, hogy nagyon nem értettem ezt az egészet. Miért nem engedélyezett? Hiszen tettem rá szabályt. Nehogymár ne lehessen tűzfalszabállyal egy tetszőleges portot kiengedni? A webproxy nem fogadná el? Azon lehet ugyan https portot állítani, de az nagyon nem erről szól. (Akar a fene proxykat láncolni.)

Irodalmazás. Azaz google.

Nos, kérem a megoldás az, hogy az a kis egyszerű webproxy fogadja a kéréseket a saját bekonfigurált portján – általában 8080 – majd ha https-re kell továbbmennie, akkor bepróbálkozik a 443-as porton. Ha ettől eltérő portot adok meg az URL-ben – mint ahogy a szorgos user ezt is tette – akkor döbbenet és lefagyás következik. Az a port nincs engedélyezve a webproxy számára, mint kimenő ssl port.
Természetesen létezik rá megoldás, Shinder bácsi – ki más – írt is róla: el kell menni a www.isatools.org oldalra, le kell tölteni az isa_tpr.js szkriptet (van 2006-os is)… aztán a többit már lásd ott.

Azért ez a rész külön tetszett :

Note that if you have unbound the Web Proxy filter from the HTTP protocol, then Firewall and SecureNAT client connections made through the ISA firewall will not be redirected to the Web Proxy Filter. In this case, you can create a Protocol Definition for the alternate SSL port and then create an Access Rule allowing outbound access to that protocol.

Pislant a hálókártya

2009. July 21. Tuesday / / 6 Comments

Erre az esetmegoldásra nem leszek büszke, de tanulság azért akad benne.

Nagyon fontos ügyfél (habár hülyeség, mindegyik az) telefonál, hogy megállt a cégnél az internetelérés. Különböző okok miatt az ISA webproxy-ra gyanakszik. Mivel internet nélkül nincs élet, így a bejelentés magas prioritású.
A megoldást nehezíti, hogy magát a belső hálózatot nem mi üzemeltetjük, abszolút semmi hozzáférésünk sincsen. Csak az ISA-t kezeljük mi.

Megnéztem a logokat, mi is a helyzet a webforgalommal: a 80-as porton remekül hasítottak a bitek, még a vizsgálat közben is. Leellenőriztem, hogy ez valós forgalom-e. Az volt. Ment vissza a levél: Kedves Ügyfél, te valamit nagyon benéztél, az ISA-n gyönyörűen megy a http.

Amire jött az indignált válasz, hogy márpedig ez nem megy. Biztos, hogy jó forgalmat néztem?

Bakker. Nem. Hiszen a böngészők webproxy kliensek, akik a webproxy filter listening portján érik el az ISA-t. A 80-as porton csak akkor megy webes forgalom, ha nem webproxy kliens forgalmaz. A konkrét esetben a webproxy filter egy lehetetlen porton (na jó, annyira nem, de akkor sem írom le) figyelt, arra rákeresve rögtön dőltek is a denied connection üzenetek.

Hát, ez már mindjárt más. Akkor itt tényleg baj van.

Event log. Tele volt gyönyörű kövér 14118-as hibákkal. Azt mondja:

Description: The Web Proxy filter failed to bind its socket to IP address port xxxx. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.

A részletes hibakód: 0x80072740.

Néhány perc keresgélés után meg is lett a magyarázat. (Komolyan mondom, ma egy informatikusnál az internetes keresési képesség a második legfontosabb készség. Az első az angol nyelv ismerete.) Itt van a KB cikk.
(Ne keverjük össze ezzel a másik cikkel: habár a hibaüzenet ugyanaz, de ez az írás arra az esetre vonatkozik, amikor IIS is fut az ISA mellett.)

Akkor most mi is a hipotézisünk? A hétvégén valószínűleg volt egy rövid időszak, amikor leesett a link az ISA szerver belső lábáról. Ekkor a Windows Server 2003 le is kapcsolta a konkrét hálózati kártyát. Ezt hívják úgy, hogy Media Sense… és feature. Igenám, de amikor visszajön a link és feléled a hálózati kártya, az ISA szerver webproxy filtere nem képes rákapaszkodni a kijelölt portjára. Támadhatják őt a böngészőkből a kliensek, nincs bind. (A pikáns az, hogy a netstat szerint persze ott figyel a megadott porton.) Megoldás? Újra kell indítani a Microsoft Firewall klienst.
Majd.
Eddigre ugyanis az ügyfél morogva beröffentett egy linux proxy-t, mondván ők nem érnek rá. Annyiból igazuk is volt, hogy az ISA nem csak az internet felé forgalmaz, hanem a nagyon fontos anya- és társvállalatok felé is, azt a forgalmat meg még egy percre sem lehet megszakítani szolgáltatás újraindításával.
Majd este.

Addig volt időm körbenézni – és sikerült be is igazolnom a hipotézist: abban a 10 percben, amikor az ISA log szerint megállt a webproxy filter, ott figyelt két bejegyzés a system event logban is:
Warning Event 4: Adapter xxxxxxx Adapter Link Down.
Majd pár perccel később:
Information: Adapter xxxxxxx Adapter Link Up.

A többi már annyira nem érdekes, késő este újra lett indítva a szervíz, minden a helyére került.

Ja, a tanulság: ISA szerveren lehet, hogy nem hülyeség letiltani a Media Sense opciót.
(Windows Server 2008-ban alaphelyzetben le is van.)

Odahaza ne próbáljátok ki

2009. July 09. Thursday / / 2 Comments

Kollégám futott bele az esetbe. Látszólag ez is X aktaként indult.

Nagy cég, kétszintű domainszerkezet. A felhasználók is és az Exchange 2003 szerverek is a child domainban vannak. Alapvetően minden szépen működik.

A feladat: az Exchange 2007 óvatos beterelgetése.

A címtár preparálása rendben megtörtént, legalábbis a cég alkalmazottja szerint. (A francokat.) Kolléga kiment, szétnézett, látszólag tényleg rendben volt minden.: a csoportok létrejöttek, a séma módosult, az ég kék volt és a madarak csicseregtek.

CAS szerver, HTS szerver rendben be is épült. Jött volna a Mailbox szerver, de a telepítő feldobott egy figyelmeztetést:

Nem tűnik annyira veszélyesnek, nem villog, nem piros… de akkor is, mi lehet ez? Azt mondja, a forest root tartományban nincsen RUS. De hiszen van! Konzolból látszik, adsiedit-ből látszik, a tartományi replikáció nem jelez hibát. Akkor ott RUS-nak kell lennie.

Agyalás. Internet. Kérdések az üzemeltetőkhöz: a setup /preparelegacyexchangepermissions lement minden tartományban?
Persze, hiszen ha paraméter nélkül adják ki, akkor az mindenhol megtörténik.
A setup /preparedomain is lement mindenhol?
Igen.

Ötlet semmi.

Egyáltalán, fontos-e ez egyáltalán? Fórumon valaki felvetette ugyanezt, egy MVP kolléga leoltotta, hogy szarni bele, nem fontos.
Annyiból igaza van, hogy ha a forest root tartományban nincs felhasználó, nincs Exchange szerver, az Exchange 2007 meg úgyis feleslegessé teszi a RUS-t, akkor ki a fenét érdekel, hogy most létezik-e belőle példány a forest root-ban vagy sem?
Annyiból viszont nincs igaza, hogy az AD egy bonyolult, nehezen átlátható rendszer. Ezt tovább bonyolítani csak úgy lehet, ha az adott szinten biztosak vagyunk benne, hogy minden jól működik. Ha nem teljesen százas az AD és ráteszek egy Exchange 2007 szervert, ki garantálja, hogy nem buknak ki váratlan és rejtélyes hibák?

Aludtunk rá egyet.

Másnap leültünk beszélgetni, hátha a közös gondolkodás előrébb visz. És tényleg.

Kitaláltunk egy hipotézist. Mi van, ha – még évekkel ezelőtt – nem történt meg az Exchange 2003 szintű domainprep a forest root tartományban? Most meg a fiúk rányomtak egy setup /preparelegacyexchangepermissions-t, mely kiírta, hogy nincs RUS – aztán ettől megijedve csináltak egyet? Ekkor egy látszólag jó rendszert kapunk – de a domainprep elmaradása miatt az Exchange 2007 nem érzékeli a forest root RUS-t.

Kolléga nekiugrott, tesztrendszeren lemodellezte. Bingo. 2003-as domainprep nélkül pont ehhez a szituációhoz jutottunk. Tulajdonképpen meg is kaptuk a választ: tudjuk, mi okozta a jelenséget, tudjuk, hogy nem fogja zavarni a 2007-es Exchange-t – mi kell még?

Például az, hogy lehet-e javítani? Hiszen van tesztrendszerünk, miért ne néznénk meg?

Kolléga ráküldte – a már 2007-esre preparált tartományra – a 2003-as domainprep-et. Na, ott volt ám csikorgás, meg füstölés. Fogaskerekek sikítottak, recsegett a fém. Végül lement a domainprep – de egy bizarr rendszert kaptunk. Az adminisztrátorok például kapásból le lettek tiltva (deny) egy csomó Exchange objektumról. Ijesztő volt.
Ekkor jött a kisérlet második fele. Kolléga megküldte a tartományra újból a 2007-es preparációkat – és gyönyörűen kiegyenesedett minden.

De az éles rendszeren valószínűleg nem próbáljuk ki.

Bizonytalan vagyok. Vagy nem?

2009. July 08. Wednesday / / 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. May 26. Tuesday / / 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. May 25. Monday / / 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. May 17. Sunday / / 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. March 12. Thursday / / 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. February 11. Wednesday / / 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. February 11. Wednesday / / 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.

Older posts Newer posts

© 2021 E-mail és a detektívek

Theme by Anders Norén — Up ↑