MonthJune 2008

Echange 2007 és backup

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

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

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

Linkek:

Spagetti routing tábla

Egyik ügyfelünknél beköltözött a nagy Sztochasztikus Vezetékelharapó az informatikai rendszerükbe. Időnként ugyanis az egyik kritikus telephelyükről nem érték el a központi Exchange szervert. Máskor viszont minden tökéletesen ment.
– Máskor tökéletesen ment? – kérdeztem vissza – Akkor hívjátok a networkos emberünket, mert ez nem Exchange hiba lesz.
És dobáltam tovább a dartsokat.

A networkos ember megnézte a routereket, switcheket, tűzfalakat… minden tökéletesen működött. Nem volt mit tenni, meg kellett várni egy üzemzavart. Meg is jött. Networkos ember ismét átnézett mindent. Alles oké. Csak éppen az Exchange szerver se telnet, se icmp szinten nem volt elérhető.
Vicces.
Aztán a kolléga tovább vizsgálódott, végül arckarmolás mellett felüvöltött: a rohadt istenit az Exchange szervernek!
Ekkor tettem le a nyílhegyeket. Lehet, hogy mégis érintve vagyok?

Mielőtt továbbmennénk, pár szó a hálózatról. Ez egy országos kiépítettségű hálózat, rengeteg telephellyel, subnettel, dmz-vel. Nem viccelek, a dmz-k mennyiségre kétszámjegyűek, nem ritka a két-három kijárattal bíró subnet sem. Nem is a szétszórt routerek kezelik a route logikát, hanem van középen egy RSP (Route Switch Processor), ő az ész. Meg a default gateway is mindenhol.
És akkor nézzük meg, mi borította ki a kollégát. Kéremszépen, megnézte az Exchange szerver route tábláját – és vagy 187 bejegyzést talált benne. 187 rosszat. Ez már nem volt annyira vicces.
Arra viszonylag hamar rájöttünk, mi történik: jön egy Outlook kliens valamelyik másik subnetből, az Exchange szerver meg felveszi annak a routernek a lábát a route táblába, ahonnan a kliens jött, természetesen a szabályban a kliens IP címe szerepel 255.255.255.255 maszkkal.
De miért is okozott ez a jelenség ekkora problémát?
Az elején mondtam, hogy az a bizonyos telephely borzalmasan kritikus az ügyfél számára. Ergo redundáns bérelt vonal van kihúzva, úgy, hogy a szolgáltatók sem azonosak. Ha ledől az egyik vonal, a routerek automatikusan átváltanak a másikra, az RSP is ennek megfelelően módosítja az útvonalakat. Csakhogy az a szerencsétlen helóta Exchange szerver minderről semmit sem tud, továbbra is a route táblájában lévő, immár fals kijárattal próbálkozik. Miért nem megy el az RSP-hez? Mert a 255.255.255.255 maszk szorosabban illeszkedik a csomagra, mint a default gateway maszkja.

Vadul elkezdtem keresni a neten, de nem igazán tudtam jól megfogalmazni a kérdésemet. Ha legalább a jelenség nevét tudnám. Végső menedékként dobtam egy körlevelet nagytudású, művelt cimboráimnak, hogy ki találkozott már ilyesmivel. Rövidesen meg is jött a válasz. Gömöri Zoli szerint a router dumál vissza a szervernek, hogy van egy rövidebb út Géza, mostantól menj arra, engem meg hagyj ki a buliból. Stone pedig megírta a jelenség nevét és azt, hogy hol lehet kikapcsolni. Imhol:

  • A jelenség – és a kulcs – neve: EnableICMPRedirects
  • Registry ág: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\

Ha az érték nulla, akkor a szerver magasról leszarja, mit mond a router.
Beállítottuk, az incidens elhárult.
Jöhetett a problémamegoldás. Biztos, hogy nem okoz galibát ez a registry módosítás? Mivel most már volt név a kezemben, körbenéztem. Találtam is egy ajánlást, hogyan védjük szervereinket (D)DOS ellen – hát például úgy, hogy a fenti értéket egyre állítjuk. Oké. Akkor ez a kérdés meg lett válaszolva.
De miért csak mostanában jelentkezett a hiba, régebben miért nem? Nos, kiderült, volt korábban egy RSP csere. A művelet tökéletesen sikerült, az új RSP remekül működött – csakhogy ez az ún. icmpredirect érték defaultban engedélyezett volt minden lábán. A réginél meg nyilván nem.
Azaz, ha biztosra akartunk menni, akkor nem csak az Exchange szerveren kellett beállítani, hogy ne figyeljen arra, mit mond a router – hanem a routeren is, hogy ne molesztálja a hostokat.
Most, és csak most mondhatjuk azt, hogy lekezeltük a problémát… írhatjuk végre a változásigénylést.

Pagefile

Mennyire lerágott csont már? Emlékeztek a régi vitákra? Hogy mennyi legyen: a fizikai RAM+11 vagy +12? Ölni tudtunk volna az igazunkért.

Aztán, hogy legyen-e vagy sem? Ez már komolyabb téma. Az egyik fél azt mondja, hogy a pagefile csak egy szükség szülte megoldás: pakoljuk tele a gépet RAM-mal – és akkor már nem is kell lapozófájl. A másik fél meg azt mondja, inkább legyen: ki tudja, mi mindenre használja az oprendszer, láttunk már karón varjút. Csakhogy… Exchange 2007… 64 bit… 32 GB RAM. Adjunk neki még 32 GB pagefile-t?

Ehhez a vitához szólt hozzá Paul Robichaux, xch MVP. Nyilván, Exchange oldalról. (Megjegyzem, ő +10 MB-t mond. A windows levlistán ezzel a véleménnyel nem állt volna meg a lábán. 🙂 )

Egy rövid összefoglaló a cikk alapján:
Hallottál már a Dynamic Buffer Allocation viselkedésről? Szépen hangzó elnevezés… azt a hozzáállást takarja, hogy az Exchange szerver (az 5.5-től) kapásból lenyúlja az összes RAM-ot, aztán ha a többi alkalmazás már zokogva könyörög, akkor odavet nekik egy keveset. Esetleg.
De mit is takar az, hogy zokogva könyörög? Tud egy alkalmazás térdenállva zokogni egy másik előtt? Nem igazán. Ehelyett az van, hogy a kiebrudalt alkalmazás – jobb híján – nekiáll a pagefile-ba dolgozni. _Ezt_ veszi észre az Exchange, ez alapján mondja azt dörmögve, hogy ‘na jó, fiúk, akkor összébbhúzom magamat’.
Mi történik, ha nincs pagefile?
Megsüketül az Exchange.

GUI-k, gombamódra

Kaján vigyorral figyelem, hogyan szaporodnak a GUI-k a Powershell körül. Félre ne értsd, a Powershell az egyik legjobb dolog, ami az utóbbi években történt az MS világban… csak azon vigyorgok, ahogy a felhasználói igények – csobogó patakként – megtalálják a rövidítéseket, az alacsonyabb partszakaszokat.

Most például Glenn dobott össze egy apró kis szkriptet. Semmi extra, egyszerűen csak csinált egy GUI-t, mely a spamfilter ügynökök naplójából összevadászgatja azt, hogy mi is történt konkrétan egy-egy levéllel. Nyilván ugyanezt meg lehetne csinálni egy egyszerű szövegszerkesztőből is… csak sokkal fapadosabban, sokkal kényelmetlenebbül.

Beindult az evolúció. Amire van igény, az előbb-utóbb el is fog készülni. Én például határozottan biztos vagyok benne, hogy hamarosan lesz egy olyan szkript, mely a régi message tracking vizuális formájában mutatja meg egy-egy legyűjtés eredményét – a jelenlegi ugyanis borzasztóan kényelmetlen.

Linkek:

A Powershell és a Windows Server 2008 Core

Ez bizony két különböző világ. A Powershell az .Net alapú, márpedig a Server Core alatt nem fut a .Net.

Két dolgot tehetünk:

  • Megvárjuk, amíg a Microsoft valamelyik Feature Pack-ba belerakja.
  • Hekk!

Dimitrij Sotnyikov az utóbbit választotta. Istenem, türelmetlen típus.

Habár le is lehetne fordítani az írását, de mégsem teszem. A lépések annyira egyértelműek, a megértésükhöz sincs szükség semmilyen Rigó utcai certifikációra.

Szóval az írás. Itt.

ps1. Bár Dimitrij bevallja, ő is ‘szerezte’ az ötletet, Alex Kibkalo blogjából. De valamiért mégsem azt az írást linkeltem be.

ps2. Az írás korábban készült, de már erre a blogra terveztem kirakni. Gondoltam, pár napot csak tudok vele várni. Hát, nem. Közben Kurbli is kirakta.

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