MonthSeptember 2010

Elég furán nézek ki a fejemből

Már megint az üzlet. Nem is igazán tudom hová tenni a dolgot.

Na szóval. Van itt egy hasznos oldal. Arról szól, hogy az Exchange egyes verzióváltásaival milyen elemek tűntek el a korábbi verzióból. Külön, hangsúlyozottan hívnám fel a figyelmet az egyikre. Arról van szó, hogy ha felteszed az Exchange 2010 RTM-re az SP1-et, akkor onnantól fogva nem fog működni az Enable-AntispamUpdates parancs. Azaz nem tudod frissíteni a spamfiltered adatbázisát. A “hát akkor mi lesz velem?’ kérdésre ennyi a válasz:

Use Forefront Security for Exchange Server to obtain automatic anti-spam updates. For more information, see Microsoft Forefront Security for Exchange Server(1).

Azaz vegyél meg egy fizetős terméket.

Hangsúlyozom, ezzel az Exchange Server 2007 Edge szerepkörének a lényegét lőtték ki. Pontosabban, összekapcsolták egy másik MS termék – egy vírusirtó – megvételével. Mindezt egy Service Pack-be csomagolva.

(1) Arról nem is beszélve, hogy legalább nekik ismerniük kellene a saját termékeik nevét. Az Exchange 2010-hez adott víruskergető már Forefront Protection for Exchange Server néven fut.

Megint back pressure

Emailben kaptam egy kérdést és ez ráébresztett arra, hogy talán érdemes lenne ejteni pár szót erről az ‘apróság’-ról.

Megint a back-pressure. Az ezerszer elátkozott. Rengeteget gyaláztam már, könyvben, is, blogban is.
Itt az ideje, hogy meg is védjem. Egy kicsit.

Az Exchange ESE adatbázis-kezelése tranzakciós alapú. Erről most nem akarok túl sokat írni, a lényeg az, hogy a friss, illetve a frissen használt adatok főleg a RAM-ban és a logfájlokban vannak, az adatbázisba csak akkor íródnak ki, ha az alkalmazás éppen ráér. Az elmélet gyenge pontja az, hogy mi történik akkor, ha éppen elfogy a tárterület az adatbázisok alól? A korábbi verziók védelméből létezik még két placeholder fájl a logkönyvtárban, de két lognyi hely… nem tudok olyan gyorsan pislogni, amilyen gyorsan az elfogy.
Ezért találták ki a back-pressure-t. Hogy amikor egy kritikus érték alá esik a szabad tárterület, az Exchange állítsa le tisztán az adatbázisokat (clean shutdown), mielőtt azok inkonzisztens állapotban dőlnének be (dirty shutdown). Megáll a levelezés? Bizony meg. De a tárterület bővítése után simán visszaindul.

Az elv oké. Nem azzal volt a baj. Hanem azzal, hogy a 2007-es RTM-ben – mely közel egy évig volt kint a piacon – ezt a kritikus értéket 4 GB-re tették. Azaz ha egy 10 GB-s partíciódból elfogyott 6, leállt a levelezés, a közepesen tájékozott admin pedig szaladgálhatott, mint pók a falon.
Nem csoda, ha ez a feature az első számú közellenség lett az Exchange rendszergazdák körében. Elméletileg, ha nem is egyszerűen, de lehet hangolgatni, ki is lehet kapcsolni – de ehhez ismerni kell az elvet. Itt követte el a második nagy hibát az MS. Én biztosisten, 40 pontos betűkkel írtam volna ki minden Exchange cikk fejlécébe, hogy vigyázz barátom, errefelé tombol a back-pressure.

Aztán az SP1-ben már finomítottak a gyakorlaton, a leállás már csak 500 MB alatt következik be, ami, valljuk be őszintén, teljesen rendben is van. Ellenben a tájékoztatás… az még mindig tré.

Ezen próbálok most javítani, egy extrém szopási lehetőség bemutatásával.

Ugyan írtam már róla, de talán annyira nem volt hangsúlyos a felvetés. Tudni kell, hogy az Exchange 2007 alatt már a queue is adatbázis! Azaz minden olyasmi elv is vonatkozik rá, mint ami a többi adatbázisra. Spec a back-pressure is!

Gondold el. Kis cég vagytok, nem akarsz túl nagy feneket keríteni a dolognak, az Exchange-t simán feltelepíted a C: meghajtóra. Az adatbázisok természetesen külön diszken vannak, szabad tárhely, mint a pelyva. Hol is van ilyenkor a queue? Hát a C:\Program files\exchrsrv alatt valahol.
Az élet vidáman megy tovább. A pagefile nő, nődögél, a patchek is zabálják a helyet a C:-n, meg ott van az az istentudja mennyi rejtélyes folyamat, melyek mind fogyasztják a rendszerpartíciót. De amíg megy a rendszer, a fene sem veszi észre. Aztán egyszer csak megáll a levelezés.
Az adatbázisoknál bőven van hely. Oké, a C:-n annyira nem, de kit érdekel most a C:?
Hát például a művelt Exchange admint.

When the back pressure limits for hard disk drive space utilization are set to their default levels, the hard disk drive that stores the message queue database on an Edge Transport server or Hub Transport server must always have a fixed amount of free hard disk drive space. In Exchange 2007 RTM, the amount of required free hard disk drive space is 4 GB. In Exchange 2007 SP1, the amount of required free hard disk drive space is 500 MB. If the available free space is less than the required amount of free hard disk drive space, the hard disk drive utilization level is considered high. Therefore, all message flow stops. In that case, you must follow one of these steps:
– Relocate the message queue database to a different hard disk drive that has more free space. For more information, see How to Change the Location of the Queue Database.
– Increase the values of the PercentageDatabaseDiskSpaceUsedHighThreshold, PercentageDatabaseDiskSpaceUsedMediumThreshold, orPercentageDatabaseDiskSpaceUsedNormalThreshold parameters.
http://technet.microsoft.com/en-us/library/bb201658(EXCHG.80).aspx

Durva pofon, nem?

Persze elkerülhető lett volna, ha:

  • Az Exchange alkalmazást nem a C:-re telepíted, hanem egy külön alkalmazáspartícióra, mondjuk D:-re – és ezt a partíciót nem is használod semmi másra. Ekkor a szabad hely csak egy extra nagy levéltömeg bezúdulásakor lenne képes elfogyni.
  • Használsz valamilyen monitorozást. Ne mondd azt, hogy a SCOM baromi drága. Akkor tegyél fel linuxon egy nagios-t, abszolút ingyen van és – többek között – a szabad tárterületet is tudja monitorozni.
  • Legfőképpen pedig ismerd meg az eszközt, amit használsz. Tudod, a törvény nem ismerete nem ment fel a következmények alól.

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

Ne mentsd a cache-t

Az idegenek köztünk élnek, azaz egy félelmetesen bravúros nyomozás leírása Yuri Diogenes blogján.

PF replikáció

Ízlés kérdése, de nekem szimpatikus, amikor az MS többé-kevésbé hivatalosan elismeri, hogy valamit elbökött – és ki is javítja.

2008 körül, amikor először futottam bele, rengeteget anyáztam az Exchange migrációs (pardon, tranzíciós) stratégiájával kapcsolatban. Emlékszünk, ekkor volt az, hogy beraktuk az első Exchange 2007 szervert (mailbox, cas és hts szerepkörökkel, mert akkor még naívak voltunk), majd az organizáció upgrade kellős közepén lehalt az egész, mert talált egy általa értelmezhetetlen ldap filtert. A hajamat téptem. Mert vagy nagyon fontos ez az ldap filter konverzió (nem az), és akkor legyen egy előzetes check, ahol hiba után nem indul el az upgrade, vagy ha nem annyira fontos, akkor legyen egy figyelmeztetés, de menjen tovább az organizáció upgrade. Ugyanis egy félbeszakadt frissítést utána borzasztóan kellemetlen volt egyenesbe rakni.

Hasonló probléma volt a Public Folderek replikációját hasbaakasztó jótétemény. (Személyesen szerencsére nem futottam bele.) Arról van szó, hogy amikor 2003-ról átálltunk 2007-re (vagy 2010-re), akkor később bizonyos PF elemek nem replikálódtak le. A hiba oka egy lelkes ellenörző modul volt, mely az általa hibásnak tartott (egyébként pedig a hiba ellenére még használható) elemeket nem volt hajlandó átreplikálni az új PF adatbázisba. Anno Bill Long írt egy szkriptet, mely ki tudta javítani ezeket az adathibákat és ki is rakta ezt a szkriptet a saját blogjára(1),

(1) Megint Bill Long és megint a saját blogja. Utálhatják a fickót, rendesen. Amikor az MS azt nyilatkozta, hogy azért nem csinálták meg az ldap filter konverziót az upgrade esetére, mert túl bonyolult lett volna, Bill Long összedobott egy VB szkriptet és kirakta a saját blogjára.

Szóval a helyzet kezelhető volt, de érezzük, hogy nem ez a korrekt megoldás. Gondold el, ott vagy egy ilyen tranzíció kellős közepén, és nem bírod eltávolítani a régi szervert, mert valamiért néhány PF elem nem megy át az új replikára, anélkül meg nem lehet a régit adatbázist, illetve szervert törölni. Ilyen szituációba tolni az admint, úgy, hogy igazából nem is reklámozták, miért nem megy a replikáció… nem túl barátságos dolog.

Ezen a hozzáálláson változtatott az Exchange 2010 SP1. Ha erre állunk át 2003-ról, akkor már hagyja a fenébe a replikáció közbeni adatellenőrzést. Bill Long szerint már készül a patch az Exchange 2007-re is.

Mi lesz veled ActiveSync?

Ma olvastam egy hírt:
“A RIM kezébe került a DataViz”

Azt gondolom, hogy egy átlag Exchange rendszergazda jó eséllyel átsiklik felette. Nálam viszont megkongatta a vészharangot. Miért?
Először is a két cégről:
RIM: gondolom mindenki ismeri őket. Aki mégsem annak a BlackBerry név biztosan ismerősen hangzik. Ez a cég aki a BlackBerry-t, a hozzá tartozó operációs rendszert és szoftvereket gyártja. Valamint ő a (jelenleg az Exchange ActiveSync-ben is használt) Direct-Push szinkronizációs technika atyja.
DataViz: Egy jóval kevésbé ismert cég. Mobil szoftver fejlesztő társaság. Gyártanak kliens szoftvert az Exchange ActiveSync-hez.

Az Exchange ActiveSync ugye egy a Microsoft által fejlesztett szinkronizációs technika, ami eljuttatja a szerveren tárolt adatainkat a mobiltelefonunkra. Microsoft fejlesztésben csak a Microsoft Windows Mobile operációs rendszert használókra. Ezt a többi platformra úgy tették elérhetővé, hogy különböző cégek megvásárolták a technológia licenszét. Ebből született pl. az iPhone 2.0 exchange kapcsolata, vagy a Nokia Mail for Exchange-e. Ez szép, de mi van azokkal a készülékekkel, amelyeket nem a Nokia vagy az Apple gyárt?

Itt jön a képbe a DataViz. Van nekik egy RoadSync nevű termékük. Ez, talán mondanom sem kell, egy ActiveSync kliens. Ebből viszont egy kitüntetett darab. Azok a cégek, ugyanis akik nem vették a fáradságot, hogy saját klienst fejlesszenek, szinte kizárólag e termék licenszének megvásárlásával jutottak ActiveSync klienshez. Így lett Exchange kapcsolat a Sony-Ericsson, az LG, a Samsung készülékein. Ezen túl a terméket még külön is árulják azokra az eszközökre, amelyeken nincs előre telepítve.

Ez a felvásárlás számomra kicsit kétségessé teszi a jövőt. A RIM-nek véleményem szerint nem érdeke a RoadSync termékvonalat tovább vinni, következő okból:
Ha nincs széles támogatottsága az ActiveSyncnek akkor a nagyvállalatok könyebben választják a RIM szinkronizációs megoldását. Ezzel több készüléket és több BlackBerry Enterprise Server-t lehet eladni.

Hey dude, where are my free/busy data?

Szép nagy játszótér. Egy multi cég amerikai központja szeretné az összes leányvállalatával összelőni az Exchange free/busy információit. Ahány cég, annyi független címtár. Azaz annyi önálló Exchange organizáció.

Ezt nevezik interorg free/busy szinkronizációnak.

Anélkül, hogy különösebben belemennék a részletekbe, azért essen róluk pár szó. Ahhoz, hogy ez az egész működjön, előtte kell egy címlista-szinkronizáció. Egyébként nem fogják látni egymást a recipientek. (Már amennyire egy postaláda látni képes.) Ilyesmire általában metacímtárakat szoktak használni. Jelen esetben egy MIIS szerveren belüli ún. Galsync process húzza az igát. Meg a címeket. Egy szkript felolvassa a leányvállalatoktól a postafiókok adatait (név, smtp cím), ezeket belegyúrja egy metacímtárba, majd a masszát contact formában visszatolja a távoli címtárakba. (Nyilván figyelve arra, hogy ahonnan felolvassa, oda ne menjen vissza ugyanannak a címnek a contact változata is.)
Persze ez csak leírva ilyen egyszerű, a 2007-es Exchange-ben már nincs RUS, a MIIS meg sunyiban tolja be a kontaktokat, azaz a különböző címlisták frissítéséről nekünk kell gondoskodnunk, mint ahogy a legacyexchangedn mező kitöltéséről is.

No, tehát címlista szinten megy a szinkron, mindenki örül. Most jönne az, hogy nemzetközi szinten működjön a megbeszélés-szervezés is.

Itt megint beléptünk a klasszikus szervezési nadrágba: a nadrágnak két szára van, hasonlóképpen nekünk is két alesetre bomlik a feladatunk. A free/busy információk szinkronja ugyanis kétféleképpen történhet. Exchange 2007 előtt az egész hóbelevanc public foldereken keresztül ment, 2007 után pedig klienstől függően vagy maradt, vagy már az Availability webes szolgáltatásra terhelődött. Szerencsére ez a leányvállalatokat túlzottan nem érdekli, a központi helyen kell telepíteni egy ún. InterOrg Replication segédprogramot, ez figyel (subscriber), nekünk pedig nincs más dolgunk, csak nyomjuk az anyagot (publisher). Az Availability szolgáltatással megint nem kell túlzottan foglalkozni, a CAS szerverek megtalálják egymást, az illetékes CAS szerverek meg megtalálják az érintett felhasználók MBX szervereit. (Oké, kell azért konfigurálgatni is rendesen, de a cikkben minden szépen le van írva.)

Ez mind szép, amikor működik. A probléma akkor van, amikor nem. Mit csináljunk? Hová nyúljak? Annyit látunk mindösszesen, hogy a megbeszélés szervezésénél ferdén van besraffozva a kiválasztott ember időcsíkja.

Jöttek a kezdeti tapogatózó lépések. X tesztfelhasználó látja-e Y felhasználó adatait Z levelezőkliensből? És Z tesztfelhasználó X felhasználó adatait Y kliensből? Meg valahány név a naptárban.

Az első meglepő tapasztalat, hogy Outlook 2007-ből minden simán ment. Azaz az Availability service tökéletesen működik, még egy ilyen bonyolult, agyontűzfalazott rendszerben is. A public folderen, az ezerszer elátkozott nyilvános mappán keresztüli terjesztés viszont nem.

Aki egy kicsit jártas az Exchange-ben, annak most szürkült el tekintete. Ha úgy általában gáz van az Exchange működésével, ezeregy eszközünk van arra, hogyan piszkáljunk bele akár a legvadabb mélységekig is az AD konfigurációs névterébe – de hogyan nyúljunk hozzá az adatbázisokhoz? Hogyan nézzünk bele? Különösen a public folder system folderébe? Hiszen ez már keszonveszélyes zóna.

Először nézzünk rá magasról. Egy organikusan kialakult Exchange szervezetben találunk egy csomó subfoldert a Free/Busy system folder alatt. Gyakorlatilag itt találjuk az összes Administrative Group-ot, mely valaha is előfordult a cég történelmében. Még azt is, amelyik hivatalosan nem is létezik. (Ugye tudjuk: Exchange Administrative Group (FYDIBOHF23SPDLT)) Hogyan élték ezek túl azt a rengeteg migrációt? Muszájból. Egész egyszerűen Exchange szervert úgy nem tudsz kitörölni, hogy van rajta olyan subfolder a public folderben, melynek nincs máshol replikációs párja. Azaz amíg van Exchange szerver az organizációban, addig az összes system folder bolyong benne, mint zsidóban a fájdalom. Törölni nem lehet. Pontosabban lehet, de system foldert törölni, az már a vak ló esete. (Nem vak ez, hanem bátor!) Márpedig az ügyfélnél 10+ éve létezik Exchange organizáció (több is), a szervezeti változások értelemszerűen Administrative Group-okat szültek, illetve szüntettek meg.
Ekkor hangzott el az a kérdés Amerikából, hogy áruljuk már el, melyik folderben vannak az éles felhasználók F/B adatai? Hát az Exchange Administrative Group (FYDIBOHF23SPDLT) nevűben – vágtam rá határozottan. Melyik másikban lennének? Hiszen az összes többi admin group már régesrégen megszűnt. Csak fityegnek itt a neveiket viselő subfolderek, mint az a valaki a Keleti pályaudvar márványtermében.
Mentünk is tovább, senki nem tulajdonított nagy jelentőséget a kérdésnek.

Aztán megálltunk, mert a szinkronizáció nem működött, az ötletek meg elfogytak. Én meg kínomban nekiálltam nézegetni ezeket a subfoldereket.

get-publicfolderstatistics -identity “NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX:/o=orgname/ou=admin-group-name

Nocsak. Az eredmény több, mint meglepő. Nemhogy a 2007 bevezetése előtt közvetlenül létező admin group nevét viselő subfolderben lébecolnak még adatok, de a migráció előtt bő egy évvel – általam – megszüntetett admin group nevét viselő subfolderben is. Hát hogyan kerültek oda ezek a zombik? És mit csinálnak még ott? Könyörgöm, 2007-ben már admin group, mint fogalom sincs! Honnan, honnan jönnek elő ezek a nevek? És legfőképpen ki használja őket?
Baromira szerettem volna belenézni ezekbe a folderekbe. Márpedig ha az ember nagyon akar valamit, akkor előbb-utóbb meg is teszi.

MFCMapi.

Ahogy ilyenkor a szakmai írásokban meg szokták jegyezni, innentől letolok magamról minden felelősséget. A programmal ugyanis nem csak bele lehet nézni egy edb adatbázisba, hanem bele is lehet írni. Elismerem, léteznek az edb szerkezeténél bonyolultabb dolgok a világon, de nem sokan. Egy fájlban akár millió(!) adattábla, közöttük pointer hegyek teremtik meg a kapcsolatot… perverz cucc, nagyon.

Szerencsére eszem ágában sem volt beleírni, bőven elég volt belenéznem. Rögtön megoldódott a rejtély.

De addig egy röpke bemutató.

Ha elindítjuk és rákattanunk a saját Outlook profilunkra, ekkor ezt látjuk.

From Segédlet

Igen, jól értetted. Outlook profile kell hozzá (min O2k3) és csak azt látod belőle, amit a profilodból is elérsz. Jelen esetben ez a postafiókom és a public folderek. Ha lennének archív foldereim vagy Sharepoint listáim, azok is látszódnának innen.

Menjünk bele a public folderekbe.

From Segédlet

Itt láthatóak a system folderek, azon belül is a free/busy folderek kiindulási pontja. (Schedule+… rémlik még valakinek? Na, ez az ág azóta megvan.) Ezt kell majd lenyitni, és onnét kezdődnek az érdekes dolgok.

Akármilyen recipient születik bele egy Exchange organizációba, kötelezően lesz egy legacyexchangedn nevű attribútuma. (Az értéke megegyezik az objektum x.500-as címével.)

Mindig? Ugye, itt megint bejön a MIIS sunyisága. Régen ezt az értéket a RUS pecsételte rá az objektumra. A 2007-ben nincsenek aszinkron folyamatok, itt minden pecsételés (legacyexchangedn, címlistatagság – beleértve a GAL-t is – rögtön akkor kerül rá az objektumra, amikor akár a konzolból, akár a shellből létrehozzuk az objektumot. De mi van akkor, ha a Galsync tolja be az objektumot, távolról? Akkor ezek az értékek üresek. Márpedig legacyexchangedn nélkül az objektum nem létezik, szerencsére a listatagság nélkül nem is látszik. Ezért kell a szinkron után ráfuttatni a korábban belinkelt írásban említett szkriptet.

De nem is ez a lényeg. (Remélem, észrevetted, hogy csak ismételtem magamat.) Hanem az, hogy a legacyexchangedn értékben benne van az administrative group neve. Annak az administrative groupnak a neve, amelyikben éppen akkor az objektum tartózkodott. (Exchange 2007-ben ez az admin group az Exchange Administrative Group (FYDIBOHF23SPDLT). Ennyit arról, hogy 2007 óta már nincsenek admin group-ok, nem él a koncepció.) Változhat a legacyexchangedn értéke? Istenments. Azzal kinyírtuk az objektumot. (Majd próbáld ki egyszer, heccből írd át adsiedittel a vezérigazgató userén a legacyexchangedn értékét. Mondjuk, ha meg akarod tartani az állásodat, akkor jegyezd meg, mi volt ott, mert visszaírás – és AD replikáció – után meggyógyul.)

Nos, márpedig ha belenézünk egy Free/Busy subfolderbe, láthatjuk, hogy az F/B információk a legacyexchangedn értékből kiolvasott nevű subfolderbe kerülnek! Azaz amikor létrejött az objektum és megkapta – akárhogyan is – a legacyexchangedn értéket, akkor azzal meg is lett határozva, melyik F/B subfolderben lesznek az adatai. Legacyexchangedn értéket pedig menetközben már nem változtatunk, mert azzal kinyírjuk először a recipientet, utána magunkat.

Így őrződik meg az örökkévalóságnak minden valaha is volt administrative group neve, mégha recipient már nem is tartozik hozzá.

Természetesen visszajeleztem az amerikaiaknak, hogy sorry, boys, ha van rá lehetőségetek, vegyétek fel a listára az összes létező F/B system foldert.
Az más kérdés, hogy ettől még mindig nem javult meg a szinkronizáció, de egy lehetséges hibaforrást immár kilőttünk.

Espéegy a porcelánboltban

Arról, hogy kijött az Exchange2010 SP1, szándékosan nem írtam semmit. Aki nem tudja meg tizenhét forrásból egy napon belül, az vagy traktorbelsőben él, vagy nem is érdekli a dolog. Azt is leírták sokan, sok helyen, hogy mi újdonságokat hozott a rendszerbe.

Foglalkozzunk most azzal, hogy mi mindent nyírt ki? Nem szándékosan persze, de hát így sikerült.

1.
Henrik Walther írt rögtön az elején egy cikket arról, hogy milyen meglepetésekre készüljünk fel.

2.
Aztán nem sokkal később az Exchange blogon jelent meg egy írás arról, hogy milyen problémák derültek ki nem sokkal az SP1 kibocsátása után.

3.
Végül Yuri Diogenes tett ki a blogjára egy cikket arról, hogy ne, hangsúlyozom, ne tegyél olyat, hogy a TMG E-mail Protection rendszeredben lévő Exchange 2010 Edge szerverre ráhúzod az SP1-et. Amennyiben mégis ilyet tettél volna, akkor ne, hangsúlyozom, ne nyúlj semmihez, mert csak tovább rontod a helyzetet. Várd meg a hotfixet, a fiúk a bányában ezerrel dolgoznak. (Hasonló tanáccsal szolgál a hivatalos ISA/TMG blog is.)