Tag: exchange 2007

Exchange javítások

Két új hotfix jelent meg.

Az egyik az Exchange 2010 SP1 soron következő immár 6-os rollupja. Letölthető innen, további infók róla itt.

A másik egy igen bosszantó, ugyanakkor nem életbevágóan fontos hibát hivatott orvosolni. Ha az Exchange Management Console-t futtató gépen fenn van az IE9 és a Mailbox szerepkör tualjdonságait piszkáljuk akkor nem lehet becsukni a konzolt. Ezt az üzenetet kapjuk és csak a Task Managerből lehet kilőni az MMC-t: “You must close all dialog boxes before you can close Exchange Manaagement Console.”

Bővebben itt.

Trükkös telepítés

Ide a bökőt, hogy kevesen tudnak róla. Én is véletlenül botlottam bele. Hallottál már az “Exchange Server 2007 Password Reset Tool”-ról? Ugye, nem? Pedig izgalmas dolog.
Arról szól, hogy ha feltelepíted a CAS szerveredre, akkor OWA2007 alól is képesek lesznek a felhasználóid megváltoztatni a jelszavaikat, még akkor is, ha éppen nem ISA/TMG szerveren keresztül publikáltad ki az OWA-t. (Ha igen, akkor ez a leírás a barátod.)
Némi kellemetlenség, hogy a fenti tool nem minden rendszerre telepíthető.

Két szigorú kritériuma van:

  • A CAS szervernek Exchange 2007 SP3-nak kell lennie.
  • IIS7 kell hozzá. (Azaz a CAS szerver alatt Windows 2008 kell dübörögjön.)

Oké, lássuk, honnan lehet letölteni, hogyan kell telepíteni.

Trükkösen.

Fogsz egy regeditet, és a HKEY_LOCAL_Machine\System\CurrentControlSet\Services\MSExchange OWA objektumban létrehozol egy új DWORD (32 bit) tipusú változót ChangeExpiredPasswordEnabled néven, majd az értékére beírsz egy 1-est.

Ennyi. Meg egy iisreset -noforce.

Nem az idegbetegek sportja

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

Megyen a log vándorútra

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.

Vicc

Van egy meglehetősen rejtélyes hibánk. Időnként az Address List szolgáltatás megáll a CCR clusteren és ilyenkor nem tudunk új postafiókokat létrehozni. A workaround az, hogy ráküldünk egy failover/failback párost, azaz gyakorlatilag újraindítjuk az AL szolgáltatást is magába foglaló System Attendant szolgáltatást.
Nyilván ez így még nem igazán kielégítő, emiatt turkáltam egy kicsit a neten. Így találtam meg a KB viccrovatát. Kicsit régi a történet, ma már nem is aktuális… de jó.

You cannot create a new mailbox or enable a mailbox in an Exchange Server 2007 environment on February 29, 2008

Sorvezető

Ha ISA 2006 szerveren keresztül szeretnénk Exchange 2007 webszolgáltatásokat kipublikálni, ahhoz ma már nem kell remegő kézzel nekifogni. Az internet tele van cikkekkel, írásokkal, tényleg minden információ begyűjthető. Konkrétan itt van egy MS cikk, ez alapján nem lehet semmi gond.

Vagy mégis?

Nos, amennyiben az Exchange szervered alatt Windows Server 2008 fut, akkor azért fognak érni meglepetések.

Nem akarom végig leírni a folyamatot, az említett cikk tényleg nagyon jó. Itt inkább csak a buktatókat gyűjteném össze.

Először is, a Windows 2003-as CA szerver nem fog tudni neked SAN tanúsítványt gyártani. A következő paranccsal lehet erre rábeszélni:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Majd újra kell indítani a Certification szolgáltatást.

Oké. Fogod, elindítod a böngészőt az Exchange szerveren, rácsatlakozol a http://ca-server.cegnev.hu/certsrv/ weblapra – és már nem emlékszem pontosan, mit kapsz válaszul, de nem a megszokott nyitólapot. Valami olyasmit mond, hogy ez a tartalom a számodra nem érhető el.
Kedves.
A magyarázat itt található: http://support.microsoft.com/kb/922706.
A Windows Server 2003 alatti tanúsítványosztogató weblap olyan activex kontrollt használ, melyet a Windows Server 2008 / Vista undorral lök el magától. A megoldás: fel kell telepíteni egy patch-et a CA szerverre, hogy úgy is tudjon tanúsítványt osztogatni, ahogy az újabb fiúk kérik.

Akkor most már mehetünk is vissza a weblapra. De mégsem. Azt mondja, immár a helyi böngésző, hogy a CA weblapjának https-en keresztül kellene jönnie. Addig ő nem fogja megmutatni a tartalmat.

Kitérő: Szeneslapáttal igazítanám meg a frizuráját annak, aki ezt az egész nevetségesen idióta ‘Enhanced Security’ módú Internet Explorert kitalálta. Tipikusan az, amikor átesünk a ló túloldalára: használhatatlanná tesszük a terméket és a végtelenségig elbonyolítjuk az egyébként is meglehetősen érthetetlen konfigurálást. Ráadásul úgy tudom, W2k8 szerver alatt kikapcsolhatatlan – miközben ott már épp elég védelmet jelentene az UAC is. Amióta ez van, azóta az az első, hogy telepítem a Firefox-ot a szerverekre is. Szerveren úgyse nézeget az ember pornó oldalakat.

Fogcsikorgatás. Nyilván valahol át kell kattintani valamit, melynek a neve még csak nem is utal arra, hogy mit befolyásol. Szerencsére itt van a net, ahol egy sorstárs már megtalálta rá a workaround-ot.
Hurrá. Elérhető lett a CA weblapja.

Lehetne igényelni az Exchange tanúsítványát… de ez mégsem ennyire egyszerű. Amennyiben az Exchange szerverünk Windows Server 2003 alatt fut, akkor – ahogy a cikk is írja – powershell-ből tudunk tanúsítványt generálni. Csakhogy jelen esetben már W2k8 az alap, ezen már van grafikus felület is. Összedobunk egy custom MMC konzolt, felvesszük bele a Certificates (local machine) snapin-t. A Personal folderen jobbkattintunk, majd a lenti képen elmegyünk a ‘Create Custom Request’ menüponthoz.

Nagyítás

Tulajdonképpen mehetnénk a ‘Request New Certificate’ menüpontba is, hiszen itt van, LAN-on belül a CA szerver, mindenki domaintag, ne kelljen már bináris fájl tartalmát kopipasztázgatni. Mehetnénk… de nem működik. A varázsló második ablakán minden szürke – és közli, hogy nekem bizony nincs lehetőségem webserver tanúsítványt igényelnem. Márpedig hidd el nekem, hogy ha nekem nincs meg ez a jogom, akkor senki másnak sem.
Marad a custom request.

Maga az igény összerakása nem túl bonyolult, egy kicsit szokni kell az újfajta grafikus elemeket, de nem vész. Rá kell kattintani minden izére, meg bigyóra, megnézni, mi is van mögöttük. (Shinder bácsi írása elég jól képbe rakhat bárkit.)
Az alábbi ábrán azt a részt emelném ki, amitől SAN lesz a tanúsítvány.

Nagyítás

Igen, az alternatív nevek. Ahogy az előző linken is van – meg máshol is – beírtam a Subject mezőbe CN-ként a külső nevet, az Alternative Name alá meg az összes szóbajöhető lehetőséget, beleértve azt is, hogy bentről esetleg rövid névvel nyomul valaki. Amit a Subject mezőbe írtam, azt nyilván már nem írtam be az Alternative Name alá is. Aztán végigmentem a láncon, igényeltem, kiadtam, importáltam, majd exportáltam végül megint importáltam… szóval ahogy az első linken szépen le van írva – végül jött kintről az OWA teszt.

Nem sikerült. Azt írta ki, hogy a tanúsítvány nem erre a weblapra szól. A Firefox ennél imformatívabb volt, kiírta azt is, hogy mely weblapokra lenne jó ez a tanúsítvány: csak azokra, amelyek az Alternative Name mezőben szerepeltek. A Subject, az nem jött szóba.

Hozzáteszem, nem vagyok tanúsítvány guru. Fogalmam sincs, mennyire kötelező a Subject alatt CN tipusúnak megadni a nevet, nem tudom, lehet-e ott is DNS formátumot használni. Mindenesetre az egyszerűbb utat választottam, az Alternative Name alá is bedobtam a külső nevet – ahogy az ábrán is láthatod. Működött.

Odahaza ne próbáljátok ki

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?

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

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

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

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

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

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

Miaf?

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

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

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

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

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

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

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

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

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

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

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

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

MI IS helyett MI SE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Csak éppen levelet nem lehet küldeni nekik.

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

Beszéljünk nyelveket

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

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

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

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

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

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

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

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

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

Exchange 2007 – első adatbázis törlése

Két hete volt egy rendszerátállásunk. Mintegy háromszáz felhasználó költözött egy hétvégén Windows Server 2003/Exchange 2003-ról Windows Server 2008/Exchange 2007-re.

A költözés mondhatni sikeresen, láthatóan buktatók nélkül zajlott le. Két nappal az átállás után a helyi informatikus hívott, hogy valami (azóta is relytéjes) okból elkezdett nőni az Exchange adatbázis mérete 100% processzor terhelés mellett úgy, hogy közben senki sem dolgozott. Sikerült óránként kb. 10GB-ot hozzátenni az adatbázishoz.

Az Event Log-tól nem lettem okosabb és miután még igazán fontos adatok nem kerültek az adatbázisba megkockáztattam a gép teljesen szabályos újraindítását.

Elindult, a store is. Nem nőtt tovább a mérete (ekkor potom 42GB volt). Miután ez egy esti időpillanat volt, arra gondoltam, hogy majd másnap foglalkozom vele.

Ezt a számításomat keresztül húzta a következő telefon. Elkezdtek store hibaüzenetek keletkezni az Event Logba.

Na ez két lehetőséget adott:

1. A mindig fennálló gyűlölt csoda: eseutil

2. Miután a store még valamilyen szinten élt, átköltöztetni az összes fiókot egy új adatbázisba.

Ez utóbbit választottam. Létrehoztam egy új storage group-ot, benne egy új store-t és hiba nélkül átpakoltam mindenkit.

Ez rendben is van. Kaptam egy 2GB-os adatbázist, örülök. De mi legyen a régivel. Régi Exchange ismereteim arra figyelmeztetnek, hogy az infrastruktúra első adatbázisa, első szervere, első anyámtyúkja mindig tartalmaz valami olyan információt, amit meg kell őrizni.

Végigtúrtam a netet és azt találtam, hogy az egyetlen dolog, ami az első adatbázisban van és a mozgatás során nem költözik el az a System Attendant mailbox. Ennek a költözésével pedig nem kell foglalkozni, mert amikor megszüntetjük azt az adatbázist, amelyikben volt, akkor automatikusan újragenerálódik egy másik adatbázisban (az eredeti cikk linkjét idetenném, ha nem dobálna 500-as hibákat a Microsoft fóruma).

Kipróbáltam. Működik. Probléma megoldva. Az eredeti hiba azóta nem fordult elő.

ClamAgent

Elkészült a legújabb elkövetményem. Ezt most remegő kézzel adom közkézre, mert ilyet még nem csináltam. Mit is? Portált. Pontosabban írtam egy programocskát (ilyen már volt) és ehhez készítettem egy web portált (ilyen még nem volt).
Ha valakit érdekel, hogyan lehet az Exchange 2007-hez ingyenesen vírusirtót fabrikálni, akkor az itt talál megoldást:
http://www.clamagent.org

Névtelen nulla

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

Akkor csapjunk bele.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ISA Server 2006 Sp1

I’m swamped in the snow.
Ugye, mi azt mondjuk, hogy ‘el vagyok havazva’, az amerikaiak meg, hogy ‘I’m swamped’. Nos, ha lehet fokozni a kifejezés erejét, akkor én most be vagyok mocsarasodva into the hó.

De a blog is kezd pókhálós lenni, így ha hosszú cikkben nem is, de legalább említés szinten ejtek pár szót arról, hogy kijött az ISA 2006 Sp1.

Igen, tudom, az a blog neve, hogy Email és a Detektívek. Mit keres itt akkor az ISA?

Tessék csak megnézni a feature listából ezt a tételt:

Support for use of server certificates containing multiple Subject Alternative Name (SAN) entries
Certificates with multiple SAN entries are now supported at the web-published servers.
Previously, ISA Server was able to use only either the subject name (common name) of a server certificate, or the first entry in the SAN list.

Illetve meg lehet nézni az előzményeket.

Mi is az a SAN? Jelen kontextusban Subject Alternative Name. Érintett benne rendesen az Exchange 2007 is. Anélkül, hogy elmerülnék a részletekben: a SAN tanusítvány olyan tanusítvány, mely nem csak egy névre szól, hanem tartalmazhat alternatív neveket is. Márpedig ha a CAS szerverünket kintre is és bentre is publikálni akarjuk valós tanusítvánnyal, akkor SAN tanusítványt kell használnunk.

Nos, összeállt a kép?

Exchange 2007 és a Relay

Az egyik kollégám jött azzal az igénnyel, hogy szeretne a cégen belülről is és kívülről is leveleket küldeni (ez ugye nem kaland), de mindezt egy MacBookról és egy iPhone-ról. Nosza rajta, beizzítottam az IMAP-ot és a Client Server nevezetű default SMTP receive connectort. A dolog működött, én nyugodtan hátradőltem, béke.

Eltelt 2-3 nap és a kolléga szól, hogy a céges mail-jét tudja így használni, de a magánt nem. Hirtelen nem értettem a dolgot, hiszen (tudomásom szerint) a Client SMTP connector pont azért van, hogy a bejelentkezett felhasználók tudják relay-nek használni.

El kezdtem keresgélni és kiderült, hogy rosszul tudom. A bejelentkezett felhasználó alapból, csak a rendszerben létező domainek nevében tud küldeni. Azt, hogy bármilyen domain-t használhasson a következő PowerShell paranccsal lehet megengedni:

Get-ReceiveConnector -Identity “SERVER\Client SERVER” | Add-ADPermission -user “DOMAIN\Domain Users” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Sender”

További információk itt:
http://technet.microsoft.com/en-us/library/bb232021.aspx

Kliens trotyli, avagy hátrébb az agarakkal

Valljuk be, az embernek ritkán van lehetősége ipari környezetben pontos kisérleteket végezni. Meg lehet tervezni a kísérletet virtuális gépen… de köztudott, hogy a méretkülönbségek miatt nem számíthatunk arra, hogy az éles környezetben minden ugyanúgy fog menni, mint a laborban.
Amikor nemrég átállítottuk egyik ügyfelünk levelezési rendszerét Exchange2007-re, volt egy olyan időszak, amikor enyém volt a pálya. Rendes, ipari erősségű szerver dübörgött a gépteremben, 1 teszt user postafiókja volt csak rajta. Remek lehetőségem nyílt arra, hogy kimonitorozzam, 1 átlagos felhasználó mekkora terhelést okoz egy valós szervernek. Vannak rá ügyes perfmon counterek, ezek közül ez érdekelt engem konkrétan: ‘RPC operations per second per user’. (Természetesen nem a perfmon-ból vizsgálódtam, vannak az EMC-ben erre a célra felingerelt varázslók bőségesen a Tools menüpont alatt.) Nagyjából annyit illik erről az értékről tudni, hogy ha az értéke 0,25 fölé megy, az már gáz.
Ekkortájt hülyült meg a laptopom, időnként be-bevillantott egy-egy kékhalált. Mivel az Outlook-om cached módban ment, ilyenkor nyilván jönnie kellett egy ost adatbázis reparációnak is az újraindítás után. Nos, ezt is lemonitoroztam… és kikerekedett rendesen a szám: a mutató 0.41-re lendült ki.
Próbáljuk meg értelmezni:

  • Nyilván ahhoz, hogy a szerveren tárolt adatokat össze tudja vetni az ost-ben tárolt adatokkal, rengeteg információt kellett MAPI-n keresztül lerántania a szerverről. Márpedig a MAPI az RPC.
  • Valószínűleg az “extrém nagy” terhelés meg se kottyant a szervernek, hiszen egyedüli felhasználó voltam, azaz a “per second per user” érték lehetett nagy, de az abszolút terhelés bőven normálison belül maradt.

Ennek ellenére mégis érdemes elgondolkodni a számon. Sok felhasználó esetén nem tudhatjuk, ki milyen kérésekel bombázza a szervert: az ost reparálás mellett bejátszik a desktop search is, amennyiben beállítottuk, hogy az legyen a keresőnk az Outlook alatt, de ugyanígy bejátszik, ha alternatív keresőt – pl. lookout – használunk, bejátszhatnak archiváló szoftverek, bejátszhat egy CRM… bejátszhat minden, ami a postafiókot piszkálja. Ja, és bejátszhat a felhasználó is, pusztán azzal, hogy használja az Outlook-ját: levelez, megbeszélést szervez, kontaktok között keres.
A kérdés: mi történik, ha túlterheljük a szervert? Ha túl sok RPC kérést kap?

Alapvetően három viselkedési mód képzelhető el:

  • A szerver megpróbálja kiszolgálni az ígényeket, csak gyűjti, gyűjti… aztán halk sóhajtással összeszakad. A levelezés megáll.
  • A szerver, amikor észreveszi, hogy baj van, nem bír többet, nemes egyszerűséggel nem foglalkozik a bejövő kérésekkel, amíg nem lesz rájuk erőforrása. Ekkor néhány kliens fogja úgy érezni, hogy a szerver nem működik – dea többiek makacsul nyomulnak.
  • A szerver, amikor észreveszi, hogy baj van, akkor visszaszól. Egész pontosan azt fogja mondani a nagy terhelést okozó klienseknek, hogy lassítsatok be, nem bírom feldolgozni a kéréseiteket.

Nyilván az első mentalitás halálos. Nem szeretjük. A másodikat se túlzottan, de már megszoktuk: az Exchange szerver eddig ugyanis így működött. Eddig. Az Exchange 2007 SP1 viszont átváltott a harmadik módszerre. Ezt hívják úgy, hogy client throttling, azaz kliens fojtogatás.

Nézzük a részleteket. A szerver kezd lemerülni. Ekkor gyorsan beazonosítja, kik azok a kliensek, akik a legnagyobb terheléseket okozzák, majd küld nekik egy-egy pofabe üzenetet. Ezt úgy hívják, hogy back-off. Aztán mit mond erre a kliens? A nevelésétől függ.

  • Az Outlook 2007 kliensek úgynevezett ropBackoff üzenetet kapnak. Ebben benne van az az információ, hogy mennyi ideig ne próbálkozzanak új RPC kéréssel. De mi van, ha a kliens csak azért is próbálkozik? A szerver türelmesen küld neki egy újabb ropBackoff üzenetet, módosított időlimittel.
  • A korábbi kliensek nem értenék ezt az üzenetet, ezért nem is ezt kapják. Helyette a szerver a képükbe tol egy RPC_S_SERVER_TOO_BUSY üzenetet. Ilyenkor a kliens beállításától függ a várakozási idő. Alapban 1 másodperc. Aztán ha túl sűrűn kapja vissza ezt az üzenetet, akkor bontja a kapcsolatot és kiírja, hogy az RPC szerver nem elérhető.

Aki komolyabban is kíváncsi a jelenségre, perfmonból meg lehet tekinteni. A countert úgy hívják, hogy RPC Client Backoff/sec. Vigyázat, más nagyságrendeket fogunk látni, attól függően, hogy milyen klienseink vannak: ropBackoff üzenetek sokkal sűrűbben keletkeznek, pont a finomabb szabályozás érdekében. A normál értékek: Outlook 2007: 50/kliens, korábbi Outlook kliensek: 1/kliens. Azaz a korábbi kliensek csak 1 pofont kapnak, de az jó nagy.

Mi van még? Igen, lehet állítani azt a küszöbértéket, amikortól a szerver úgy érzi, hogy baj van. Természetesen registry varázslással. A magam részéről úgy vélem, átlagos környezetben erre nincs túl nagy szükség. Bízzunk a szerverben, csak tudja, mikor fárad el. Amennyiben valaki mégis állítgatni akarja, akkor ebben a cikkben megtalálja a szükséges matekozást.

Exchange 2007 SP1 Update Rollup 2

Megjelent az Exchange 2007 SP1 utáni második összefogott gyorsjavítás. Jujj, tudok fogalmazni. Lövésem sincs, hogy magyarul minek hívjam ezt a csomagot. Összesen arról van szó, hogy a Microsoft időnként összefogja egy csokorba a fontos hibajavításokat és kiadja. Ez nem olyan átfogó, mint egy szervizcsomag, ugyanakkor jóval sűrűbben jelenik meg. Az Exchange 2007 RTM és SP1 közötti alig több mint egy évben öt ilyet sikerült generálni. Ennyit a fogalmazásról.
A csomag letölthető innen, a benne lévő frissítések listája pedig itt található.