Category2010

Mennyi is az annyi?

Feltehetően mindenki hallott már az Exchange adminok életét megkeserítő a remek stub alapú archiválási technikáról. Arról van szó, hogy egy külső gyártó terméke (pl Symantec Enterprise Vault) MAPI felületen végigszkenneli az Exchange kijelölt adatbázisait, majd a beállított feltételeknek eleget tevő levelekből (méret, időpont) a tartalmat kiveszi, átrakja a saját adatbázisába, az eredeti helyen pedig csak egy pointert hagy ott, mely az átmásolt tartalomra mutat.
Az elv még nem is lenne rossz – bár látjuk, hogy összességében helyet nem nyertünk, viszont az Exchange adatbáziskezelő műveletei felgyorsultak. Persze ennek ára is van, a csonkolt levelek elérése lassabb, egy disaster utáni recovery kész horror (pedig eleve sem egy leányálom), plusz adminisztráció, na meg több zsák pénz.

Most ne menjünk bele, hogy ennek van-e egyáltalán létjogosultsága Exchange 2010 alatt (itt ugye az adatbázisok maximális mérete a tera tartományban mozog). Tételezzük fel, hogy már van ilyen rendszerünk, megörököltük a korábbi Exchange verziónkkal. Jelen cikkben csak egy apróságra hívnám fel a figyelmet: hogyan lehet egy pitiáner tervezési hibával hülyét csinálni magunkból.

De előbb számoljunk. Exchange 2003 alatt a default blokkméret az adatbázisban 4 Kbyte, Exchange 2007 alatt 8 Kbyte. Azaz bármekkora is volt a levél, egy 4/8 Kbyte méretű stub marad a levél helyén. A felszabaduló helyet pedig az Online Maintenance visszadolgozza a szabad területek közé.
Az Exchange 2010 alatt a blokkméret 32 Kbyte lett. Gondoljuk el: akármekkora volt a levél, 32 Kbyte hely mindig foglalt marad a számára. Rólam tudni kell, hogy hajlamos vagyok több képernyő hosszúságú emaileket írni, de még ezek sem érik el a 32K méretet. Gyakorlatilag ezt a határt csak csatolással szokták átlépni – igaz, azzal nagyon.
Akkor mi is az a pitiáner hiba? Az, amikor úgy állítják be a külső rendszert, hogy alaphelyzetben a csatolásokat archiválja, de egy bizonyos idő eltelte (mondjuk egy év) után minden levelet. Ez az utóbbi húzás az, amelynek az égegyadta világon semmi értelme sincsen. A levél után ott marad a 32K hely, igaz, ezen belül a sok szöveg helyett csak egy link lesz benne – de a felszabaduló hellyel az Online Maintenance nem tud mit kezdeni. Foglalt marad. Cserébe megnyerjük, hogy plusz helyet foglalunk el az archiváló rendszerben, a felhasználó lassabban éri el a régi levelét, egyszerre kell gondoskodnunk mind a két rendszer rendelkezésreállásáról és kinlódhatunk mind a backup/restore, mind a DR folyamatainkkal.

Azaz, ha használunk ilyen külső rendszereket, akkor felejtsük el az idő alapon történő archiválást az összes levélre, koncentráljunk csak a csatolásokra. (A magam részéről pedig azt tenném hozzá, hogy gondolkozzunk el a Personal Archive és menedzselt mailbox kombináción, sokkal olcsóbban – és egyszerűbben – is el tudjuk érni ugyanazt, mint a külső cuccokkal.)

RUP4 újra

Valószínűleg senkinek nem mondok vele újat, de azért csak jobb, ha le van írva.

Röviden a sztori.

A közelmúltban kijött az Exchange 2010 Rollup Pack 4. Aztán pár nappal később pánikszerűen visszavonták. Az történt ugyanis, hogy bizonyos esetekben a move furán viselkedett: a subfolderek tartalmát nem másolta át az új helyre, ellenben a régiről törölte. Eléggé ciki.

Most jött a hír, hogy átnézték, kijavították és immár itt az új, hibátlan RUP4, emellett pedig igyekeztek meg is magyarázni, hogyan történhetett ez meg.

Mondd meg a Ferinek, hogy szóljon a Janinak

Ügyfél haladt a korral. A saját alkalmazásai korábban MAPI-n keresztül érték el az alkalmazásokhoz tartozó Exchange postafiókokat. A felhasználók autentikálták magukat az alkalmazások indulása után, aztán vagy volt joguk az egyes funkciók postafiókjaihoz, vagy sem – attól függően, milyen jogosultságok voltak beállítva közvetlenül a postafiókon.

Mint írtam, haladtak a korral. Az alkalmazások új verziójában úgy döntöttek, hogy szakítanak a MAPI-val, helyette inkább webes protokollokon keresztül érik el a postafiókokat.
Első ránézésre nincs is nagy gond, megkapták a mailbox szerver helyett a CAS szerver nevét, aztán hajrá.
Nem sikerült. Még az atyaúristen jogosultsággal bíró fejlesztők sem tudtak kapcsolódni egy postafiókhoz sem. Azt a választ kapták, hogy nincsenek megszemélyesítve.

Hmm? Ez meg mi?

A CAS szerver önérzete. Ugyanis most nem közvetlenül fordulunk a mailbox szerverhez, hanem egy CAS (azaz web) szerveren futó webes szolgáltatáson (EWS) keresztül. Márpedig ahhoz, hogy ez az egész működjön, az kell, hogy a webes szolgáltatás megszemélyesítse a hozzáforduló személyt a mailbox szerveren. (Megjegyzem, a Free/Busy információk webes lekérdezése is hasonlóképpen működik.)

A megszemélyesítésben két jogosultság is keresztbetehet:

  • ms-Exch-EPI-Impersonation: Ez egy, a CAS szerverekre vonatkozó jogosultság. Azt lehet vele szabályozni, hogy a kérelmező egyáltalán bekerülhessen a megszemélyesítés bizniszbe. Ha ez a jogosultság tiltott, akkor az illetőt már a CAS szerver elhajtja.
  • ms-Exch-EPI-May-Impersonate: Ez a jogosultság a mailbox szerveren értelmezendő. Szintjei nincsenek (azt továbbra is a postafiókon szabályozzuk), itt csak az dől el, hogy a kérelmezőt megszemélyesítő webes szolgáltatás hozzáfér-e valaki nevében a postafiókhoz, vagy sem.

Mondanom sem kell, ebből az egészből semmi nem volt beállítva. Nyilván el lettek hajtva az alkalmazásokon keresztül érkezők.

Szerencsére a megoldás technikailag nem volt túl bonyolult. Kérni kellett egy listát arról, hogy milyen postafiókokhoz milyen felhasználóknak kell hozzáférniük. Mindegyik postafiókhoz készült egy biztonsági csoport, benne a megadott felhasználókkal, illetve az összes biztonsági csoportot betettem egy CAS-Impersonate biztonsági csoportba.

Első lépésben a CAS-Impersonate csoportnak megadtam a CAS szerveren a megszemélyesítési jogot.

Add-ADPermission -Identity <CAS_server_name> -User <CAS-Impersonate> -extendedRight ms-Exch-EPI-Impersonation

A következő lépésben postafiókonként (PFname) lefutattam a következő parancsot:

Add-ADPermission -Identity <PFname> -User <PfGroup> -extendedRight ms-Exch-EPI-May-Impersonate

Ugye, milyen egyszerű?

Hát, nem.

Az ördög megint a részletekben vigyorog. Az Add-ADPermission ugyanis roppant kényes ízlésű jószág, semmilyen más azonosító paramétert nem fogad el, csak az objektum distinguished name értékét. Mindenhol. Az első parancs sikeres végrehajtásához le kell vadásznod (adsiedit) mind a CAS szerver dn értékét, mind a CAS-Impersonate csoport dn értékét. A második parancs még durvább. Így, ahogy fentebb látod, nem is működik.

Add-ADPermission -Identity <Username> -User <PfGroup> -extendedRight ms-Exch-EPI-May-Impersonate

Ahol az <Username> egy konkrét felhasználói objektum dn értéke, a <PfGroup> pedig az általam a postafiókhoz kreált csoport dn értéke. Ebben az esetben a csoport pontosan azt a szintű jogosultságot kapja meg a postafiókra a megszemélyesítésen keresztül, mely az <Username> felhasználónak is van.

Az eljárásról van cikk, itt találod.

Miszter X és a fejléc tűzfal

Egyszer már piszkálgattam a receive konnektorokat, csakhogy ezek olyanok, hogy nem lehet sokáig piszkálatlanul hagyni őket.

De most egy kicsit más perspektívából szeretnék foglalkozni velük, sőt, nem is csak velük. Bemelegítésképpen nézzük meg ezt az ábrát.

From Segédlet

Szép ábra, sokat szoktam nézegetni. (Az eredeti, poszter méretben itt található.) De nem csak szép, hasznos is. (Tipikus háttérkép a desktopra.)
Nos, ha eleget nézegetjük, feltűnhet, hogy van egy elem, mely többször is szerepel rajta. Narancssárga téglalap és az van beleírva, hogy header firewall. Ahhoz képest, hogy mennyiszer szerepel, nem mondhatni, hogy túlzottan benne lenne a köztudatban.

Na, ezen szeretnék most javítani.

Első lépésben vizsgáljuk meg, mi is az a header, amit tűzfalazni kell. Nagy vonalakban az email (és most csak a belső részéről beszélek, a boríték jelen cikkben nem játszik) két részből áll: fejlécből és tartalomból. A fejlécen belül pedig megkülönböztetünk szabványos mezőket és nem szabványos (vagy ronda szóval élve kvázi-szabványos) mezőket. A szabványosakat RFC írja le, a nem szabványosakról nem ír semmit az RFC (azért nem szabványosak), de elterjedt, hogy az X betűvel kezdődő fejlécmezők gyakorlatilag bármiből állhatnak, bármit jelenthetnek. Azaz ezek a mezők gyártóspecifikusak: egy konkrét gyártó smtp szervere érteni fogja, mit akar üzenni neki egy másik, hasonló szerver, a többi smtp szerver meg nem foglalkozik ezekkel a mezőkkel.
A valóságban itt is lezajlott egy evolúció, néhány X-mező annyira elterjedt, hogy ma már a kitalálójától eltérő gyártók is használják.

Mire jók ezek a mezők? Rengeteg mindenre. A feladó smtp szerver belerak egy csomó információt, melyeket utána a többi smtp szerver is fel tud használni. Ide kerülhet bele, hogy a levél mikor lépett be az Exchange birodalomba, milyen autentikációs módszerrel jutott be, milyen transport rule-ok gyötörték meg a levelet, sima levél vagy journaling… és egy csomó egyéb dolog. Akár magunknak is gyárthatunk X-mezőket. (Igaz, ez a cikk még eventsink-kel dolgozik, de ügynökkel sem lehet sokkal bonyolultabb.) X-mezőbe kerül bele az például, hogy a levelet mennyire érezte szpemnek egy korábbi smtp szerver (Spam Confidence Level, SCL), illetve az is, hogy már átment egy vizsgálaton és ne vizsgálják többet.

Hoppá.

Bejelzett a vészcsengő? Egy szpemmer számára mi sem lenne egyszerűbb, mint rögtön az elején belerakni a levelekbe egy X-mezőt, miszerint ezt a levelet már ne vizsgálják, oszt jónapot.

Na, itt lép be a képbe a header firewall. Ez ugyanis azt csinálja, hogy – beállítástól függően – kipucolja akár az Exchange által használt X-mezőket, akár az egyéb fejlécmezőket a levelekből. Így bejövő levél esetében nem hiszünk el semmit a többi smtp szervernek, kimenő levél esetén nem adunk ki olyan információt, mely segíthet feltérképezni a belső rendszerünket.

Ennyit a bevezetésről, jöhet a vadulás.

Hogyan tudjuk aktivizálni a header firewallt? Hát, úgy, hogy letiltjuk. Gyárilag ugyanis általában működik. De nagyon nem mindegy, hogy kifelé megy a levél, vagy befelé jön, illetve a feladó smtp szerver milyen jogosultságokkal bír a konkrét (receive/send) konnektoron. Érzem, hogy ebből nehéz lesz érthetően kijönnöm, inkább írok egy példát. Egy konkrét receive konnektoron engedélyezem az Ms-Exch-Accept-Headers-Organization jogosultságot mondjuk az ExchangeServers jogosultsági csoportnak. Ebben az esetben, ha egy levél ezen a receive konnektoron keresztül jött be és a sessiont kezdeményező akárki tagja az ExchangeServers jogosultsági csoportnak, akkor a header firewall kussol, legalábbis az organizáció szintű X-mezőkkel kapcsolatban. (Az Exchange X-mezőknek két nagy csoportja van, az organizáció szintűek és az erdő szintűek. Az előző jogosultságnak az erdő szintű X-mezőkre vonatkozó párja az Ms-Exch-Accept-Headers-Forest jogosultság.) Ha a sessiont kezdeményező nem tagja az ExchangeServers permission groupnak, azaz tiltva van számára az a bizonyos accept-headers jogosultság, és a levél ezen a receive konnektoron keresztül jön be, akkor a header firewall már ugrik és gyapálja is ki az organizáció szintű X-mezőket. Értelemszerűen a send konnektorokkal is hasonlóan tudunk elbánni.

Szóval, jogosultság és jogosultsági csoportok. Emlékszünk?

From Segédlet

Látható, hogy gyárilag létezik néhány előre definiált jogosultsági csoport (permission group). Hogy még durvább legyen a helyzet, létezik néhány előre definiált receive konnektor tipus is.

From Segédlet

Gondolom, senkit nem lep meg, hogy mindegyikhez – tehát jogosultsági csoporthoz is és konnektortipushoz is – eleve be van állítva, hogy működjön a header firewall, vagy sem.

Na, ezt nem kis munka lesz nyomon követni.
Szerencsére annyira nagy sem.

Mind az organizáció, mind az erdő szintű X-mezőket illetően a receive konnektoroknál csak az internal tipusnál és csak az ExchangeServers jogosultsági csoportnál nem működik a header firewall, minden más esetben igen.
Send konnektor esetén némileg bonyolult a helyzet, ott gyárilag nem jogosultsági csoport van hozzárendelve a konnektorhoz, hanem security group. Nagy általánosságban elmondható, hogy ha internal tipusú konnektort gyártottunk, akkor az Exchange szervereket tartalmazó csoportoknál nem működik a header firewall, minden más esetben igen.

Jogos lehet a kérdés, hogy bele tudunk-e ebbe piszkálni? Nos, egy irányba igen. Ha nagyon megerőszakoljuk a rendszert, akkor be tudjuk állítani, hogy az Exchange szerverekre is vonatkozzon a tűzfal.

Azaz összességében elmondható, hogy az Exchange 2010 elég kegyetlenül bánik a saját X-mezőivel: se ki nem engedi, se be nem engedi azokat, de még bent is csak az ExchangeServers jogosultsági csoport élvez mentességet. És ezek közül sem mindegyik. Organizáció, illetve erdő szintű X-mező eleve csak a 2007-es verziótól felfelé létezik, azaz ha korábbi verziójú szerverről jön levél, akkor dolgozik a header firewall (mert vagy nincs benne ilyen X-mező, ha meg van, akkor biztosan sunyi módon került bele), illetve amennyiben korábbi verziójú Exchange szerverre megy a levél, akkor meg azért lép akcióba a header firewall, mert tök felesleges lenne az X-mezőket benne hagyni, a szerver úgysem értené.

Megjegyzem, a levélküldésbe nem csak konnektorokon keresztül kerülhetnek be a levelek. Tessék csak megnézni, a narancssárga téglalapok ott vannak minden kilométerkőnél.

  • Pickup könyvtár: Ide lehet manuálisan leveleket behajigálni. A header firewall működik.
  • Replay könyvtár: Ide kerülnek azok a levelek, melyek egyszer már bent voltak a queue-ban, csak éppen valamiért kikerültek onnan. Ha ez a queue Exchange2010-es volt (az X-Createdby X-mező értéke MSExchange14), akkor a header firewall békén hagyja a levelet, ha nem, akkor rávetődik.
  • Drop könyvtár: A külsős alkalmazások könyvtára, a foreign konnektorok révén ezen keresztül tudnak leveleket küldeni, fogadni. A header firewall aktív.
  • Store driver: A kapcsolat a mailbox adatbázis és az smtp motor között. A kifelé menő levelek esetében a header firewall kivágja az illetékes X-mezőket, a befelé jövő levelek esetében válogat: bizonyos X-mezők repülnek, mások maradhatnak. (Oké, pongyola voltam. Általánosságban elmondható, hogy a szpemekkel kapcsolatos X-mezők maradnak, a többiek nem. Az ugye tiszta, hogy ezeket az infókat csak a mi smtp szerverünk rakhatta bele a levélbe, mert a kintről jövő levelekből az Edge/Hub már korábban kivágta az ilyesmit, már ha léteztek egyáltalán.)
  • Delivery Status Notfication, DSN: A header firewall mindig kigyapálja az X-mezőket a DSN-be ágyazott eredeti levelekből.

Jó. A trükkös szpemekkel elbántunk. (Az SCL is X-mező, Exchange 2010-ben egész pontosan így hivják: X-MS-Exchange-Organization-SCL.) Az X-mezők kaptak egy tockost meg egy kokit, nem mennek kifelé, nem jönnek befelé. De jó-e az nekem, ha pl. egy alkalmazásszerverem az Exchange szerveren keresztül küld ki levelet, és ez az útvonal benne marad a levélben? Nevekkel együtt? Ki tudnám ezt gyapálni?
Ki.
A logika teljesen hasonló az organizáció illetve erdő szintű X-mezőkhöz. Ha egy konnektoron engedélyezve van egy identitás számára a Ms-Exch-Accept-Headers-Routing jogosultság, akkor a routing információk benne maradnak a levél fejlécében. Ha nem, akkor a header firewall kitörli azokat.
Nézzük az alapértelmezéseket. Receive konnektoron a a következő jogosultsági csoportok számára helyből engedélyezve van a jog (azaz tiltva a header firewall): Anonymous, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, Partner. Valamennyi név a naptárban. (Vessünk egy pillantást a fenti ábrára: csak ezek vannak.) Hogy lehet akkor aktivizálni a header firewallt, hogy mégiscsak rúgja ki a routing információkat? Úgy, hogy Custom konnektort készítünk és nem adunk meg semmilyen jogosultsági csoportot. Vagy meglévő konnektorból töröljük ki az összeset. Vagy az Add-ADPermission paranccsal vesszük el egy-egy csoporttól a konkrét konnektoron a jogot.
A Send konnektorokok esetében nagyjából hasonló a helyzet, alapértelmezésben a routing információk maradnak, de ha akarjuk, akkor a jogosultság tiltásával a header firewall kiszedi azokat. Érdemes megemlíteni itt is az alternatív útvonalakat: a Replay, Drop könyvtárak, illetve az ügynökökön keresztül érkező levelek esetében a header firewall nem bántja a routing információkat. A Pickup könyvtár esetében mindig törlődnek a routing információk. Szintúgy a DSN-be ágyazott levelek esetében. A Store driver a kifelé menő levelek esetében töröl, a befelé jövők esetében nem. (Ez egy kicsit félrevezető lehet. A Store driver a mailbox és a hub transport szerepkör között dolgozik. Azaz ha jön egy levél a mailbox adatbázisból, melyet a kliens mondjuk MAPI-n keresztül rakott össze, annak a routing információit – ha vannak egyáltalán – nem engedjük ki. De a következő lépésben a hub transport szerver belerakja a saját routing információját és az már marad.)

A sok elmélet után jöjjön most egy konkrét példa. Van egy Oracle szerverünk, meg egy csomó alkalmazásunk. A szerveren fut egy smtp szerver is, az alkalmazások azon keresztül leveleznek, illetve a cégből kifelé egy Exchange szerveren keresztül. Hogyan tudjuk megoldani, hogy az internetre ne kerüljenek ki az Oracle szerverre vonatkozó routing információk? Úgy, hogy a szerver kap egy egyedi receive konnektort (csak az ő IP címe szerepel benne), a jogosultsági csoportok közül meg egyet sem adunk meg. Ekkor a konnektoron nem lesz Ms-Exch-Accept-Headers-Routing jogosultság, amit a header firewall úgy értelmez, hogy tiltva van – azaz törli az addigi routing információkat.
Aha. Viszont rögtön belefutunk abba, hogy ez egy open relay tipusú konnektor (igaz, csak egy IP címre), amelyhez Externally Secured autentikáció kell. Ez viszont kiköveteli az ExchangeServers jogosultsági csoportot. Megoldás: az Add-ADPermission paranccsal csak ezen a konnektoron deny-re állítjuk az ExchangeServers permission group jogosultságát az Ms-Exch-Accept-Headers-Routing elemi jognál.

Ezzel tulajdonképpen be is fejeződhetne a cikk. Beszéltünk 3 jogosultságról (Ms-Exch-Accept-Headers-Organization, Ms-Exch-Accept-Headers-Forest, Ms-Exch-Accept-Headers-Routing), arról, hogy mi történik, ha ezeket a jogosultságokat elvesszük, illetve arról, hogy mik a gyári beállítások. Úgy gondolom, hogy hasznos lehet a másik oldalról is ránézni az összerendelésekre: milyen jogosultságokkal rendelkeznek beépítetten az egyes jogosultsági csoportok?

Anonymous (Anonymous user account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
– Ms-Exch-Accept-Headers-Routing

ExchangeUsers (Authenticated user accounts)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-Accept-Headers-Routing

ExchangeServers (Hub Transport servers, Edge Transport servers, Exchange Servers (Hub Transport server only), Externally Secured servers)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50
– Ms-Exch-Accept-Headers-Organization (Kivéve az Externally Secured servers.)
– Ms-Exch-Accept-Headers-Forest (Kivéve az Externally Secured servers.)

ExchangeLegacyServers (Exchange Legacy Interop security group)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50

Partner (Partner Server account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-Accept-Headers-Routing

És legvégül két link a témában jobban elmélyülni szándékozóknak:

GAL szegmentáció

Nem sokkal korábban beszélgettünk a kommentekben arról, hogy mi is ez tulajdonképpen és most létezik, vagy sem? A konklúzió az volt, hogy igen, létezik, de csak hosted módban. Akinek hagyományos Exchange rendszere van és valamilyen okból kifolyólag szeretné mégis valahogy elszeparálni egymástól a címeket – azaz elérni azt, hogy ne láthasson mindenki mindenkit – jelenleg még kénytelen az ACL értékekkel bűvészkedni. Azt viszont már tudjuk, hogy az ACL matyizás nem igazán jól menedzselhető módszer. (Akit érdekelnek a részletek, ebben a whitepaper-ben megtalálja.)

Az Exchange 2010 SP2-ben végre vége ennek az áldatlan állapotnak, bejön a rendszerbe az Address Book Policy. A technikai részletekbe túlzottan nem mennék bele, a név mindent elmond: le kell gyártani a címlistákat (beleértve a globálisakat is), majd házirendből szabályozhatjuk, ki melyikhez fér hozzá.

Megszokhattuk már, hogy az ördög a részletekben rejtőzik. Henrik Walther összerakott egy rövid, de frappáns írást, ahol az ABP árnyoldalait is feltűntette: mennyire korlátozott a hatóköre, hogyan lehet megkerülni, mikor nem alkalmazható, mikor csak korlátozottan, stb. Ha valaki komolyan gondolkodik a bevezetésén, érdemes először ezt az írást elolvasnia.

Hulljon a férgese

Biztosan sok emberben felmerült már, hogy milyen jó móka lenne rendszergazdaként a szerver konzolból látszólag véletlenül beletörölni a felhasználók postafiókjaiba. Az Exchange 2007-ben, illetve az Exchange 2010 RTM-ben erre a célre az export-mailbox parancs szolgált. Mind exportálni, mind törölni lehetett vele.
Az Exchange 2010 SP1-ben a fenti két funkció kettévált. Exportálásra a New-MailboxExportRequest parancsot kell használnunk.

Minket viszont sokkal jobban érdekel, hogyan tudunk törölni. Nos, bár fura, de logikus: a search-mailbox paranccsal. Tessék megnézni a kapcsolókat. Egyrészt megadjuk a keresési feltételeket, majd jöhet az akció definiálása. Az első lépésnél izgalmas lehet a -searchdumpster kapcsoló, a másodiknál pedig a -deletecontent. Ha mindkettőt alkalmazzuk, akkor a levelet az se menti meg, ha a felhasználó előrelátóan már korábban törölte. (De csak a kukáig.) Az összes paramétert nem fogom felsorolni, a fenti linken részletesen is megtalálható a magyarázatuk.

Habár a Pokoli Operátor sem rossz játék, de azért a parancsnak léteznek értelmes felhasználási területei is. Tudom, hogy nehéz, de képzeljük el, hogy a titkárnő szétküldött hivatalszinten egy államfői levelet, mely tele volt helyesírási hibával. Nyilván ez így blamálja az elnököt, akit nem fog érdekelni, hogyan, de tüntessük el a levelet a rendszerből. Természetesen tágabb értelemben el tudunk vele tüntetni bármilyen, meghatározható paraméterű (pl subject) szpemet, vírust és bármit, ha éppen nincs erre a célra dedikált külső alkalmazásunk.

Welcome

Az ember azt gondolná, hogy ezek a receive konnektorok olyan kicsi, ártalmatlan lények. Aztán ádehogy. (Nem véletlenül szoktam mondani, hogy a konnektorok közül ők a nőneműek. Elvégre az ő dolguk a behatolási engedélyek kiosztása.)

És ha olyan egyszerű lenne behangolni őket! De nem. Hiába tudod, mit szeretnél, ha egyáltalán nem olyan egyértelmű azt összekattogtatni. Az első két fül (general, network) még hagyján, itt minden érthető. De hogyan is kell értelmezni az authentication, illetve permission group fogalmakat? Hiszen mind a kettő ugyanazt jelenti, nem? Nem. Az autentikáció azt mondja meg, hogy a konnektor milyen autentikációs módszereket, milyen technikákat fogadjon. A permission group pedig azt, hogy – az autentikációs technológia alkalmazása után – kik, milyen csoportok férhessenek hozzá a konnektorhoz.
Hogy egy hasonlattal éljek. Odamész egy bankautomatához. Rá van írva, milyen kártyákat ismer. Pl. Visa és ECMC. Ha csak American Express kártyád van, akkor ez nem a te automatád, biztosan nem vehetsz ki pénzt belőle. Ha van ECMC kártyád, akkor bedugod, az automata felismeri, mehetsz tovább. (Ami persze nem jelent automatikusan pénzt, kell a pinkód, kell, hogy legyen zsé a kártyádon, kell, hogy legyen zsé az automatában, stb.)

From Segédlet
From Segédlet

Játszunk el egy kicsit a beállításokkal.

1. kísérlet

Authentication: Externally secured
Permission Groups: anonymous, exchange servers

Ez egy kikényszerített beállítás. Igazából azt szerettem volna elérni, hogy a konnektor teljesen nyitott legyen (ribanc), azaz mindenhonnan mindenkitől befogadjon minden levelet, függetlenül attól, hogy azok neki szóltak, vagy más, akár külső címzettnek. Ezt nevezik egyébként open relay-nek. Ehhez csak az anonymous-t akartam megadni, de a varázsló ragaszkodott hozzá, hogy be legyen kattintva az exchange servers jogosultsági csoport is. Őszintén szólva, fogalmam sincs miért. Hiszen az autentikációs módszernél azt mondtuk, hogy nem foglakozunk az autentikációval, eleve megbízunk a feladóban.

Eredmények:
Levélküldés bentről kintre: sikerült
Levélküldés kintről bentre: sikerült.
Levélküldés kintről kintre: sikerült.

(A tesztről pár szót. Telnet-tel kapcsolódtam a szerverre, a bent és a kint az gyakorlatilag belső, illetve külső feladót jelent. A siker pedig azt, hogy a szerver befogadta a levelet az smtp queue-ba. A továbbküldés – mely már a send konnektor dolga – most nem érdekelt.)

2. kísérlet

Authentication: semmi
Permission Groups: anonymous

Eredmények:
Kintről bentre: sikerült.
Bentről kintre: unable to relay
Kintről kintre: unable to relay.

Fura, nem? Az ember azt gondolná, hogy ez aztán az igazi open relay, nem autentikálunk és csak anonymous hozzáférést engedélyezünk. Ehhez képest igen durva az eredmény, a szerver csak befelé jövő levelet fogad. Már kifelé sem tudunk küldeni, még létező belső felhasználóval sem.

3. kísérlet

Elegem lett a kotyvasztásokból, gondoltam, megnézem, milyen lehetőségeket adnak a beépített tipusok. (Amikor létrehozunk egy receive konnektort, akkor sablonokból választhatunk. Az előző kettő custom sablon volt.)

From Segédlet

Authentication: TLS
Permission Groups: anonymous

Ez az internet sablon volt.

Eredmények:
Kintről bentre: sikerült.
Bentről kintre: unable to relay
Kintről kintre: unable to relay.

Gyakorlatilag ugyanaz történt, mint az előbbi esetben. Ami nem baj, hiszen pont ezt is akartuk: a receive konnektor mindenkitől elfogad levelet, feltéve, hogy a címzett belső ember.

4. kísérlet

Authentication: TLS, exchange server authentication
Permission Groups: exchange servers

A fenti kombináció az internal sablon.

Eredmények:
Hát, az most nincs. Rögtön az első próbálkozásnál, már a ‘mail from’ paraméternél ezt kaptam vissza: client was not autenticated. Ami teljesen rendben is van, hiszen nem vagyunk Exchange szerverek.
Mindenesetre éles rendszerben használva a konnektor remekül működik, a szerver elfogadja a kifelé menő leveleket.

Oké, játszottunk. Most viszont, a kísérletek fényében, rakjunk össze működő receive konnektorokat, különböző esetekre.

Edge Transport szerver

Én a magam részéről törölni szoktam az automatikusan létrejövőket, mert gyakorlatilag nem működnek. Ehelyett a következőket használom:

from corenet
Azok a levelek, melyeknek a címzettje kint van a nagyvilágban. A sablon, amelyikből a konnektor készül, az az internal(!), a network fülön csak a belső Exchange szervereket adom meg.

from internet
Azok a levelek, melyek kintről jönnek és a címzettjük a cégen belül van. A sablon, amelyikből készül, az internet, a network fülön a teljes IP tartományt (0.0.0.0 – 255.255.255.255) kell megadni.

relay
Mindenki, aki a DMZ-ből az Exchange SMTP szerverét használva próbál levelet küldeni. A sablon a custom, a beállítások az 1. kísérletben leírtak. A network fülön csak azokat az IP címeket adjuk meg, amelyek küldhetnek. (Ezzel azért bánjunk óvatosan, hisz ezekre az IP címekre nézve az Exchange szerver open relay lesz.)

Hub Transport szerver

A különbség az, hogy ez a szerver már bent van a belső hálózatban.

client
Gyári konnektor. Ha megnézed, egész érdekes portot használ (587). Ez az SMTP Submission protokoll portja. A történet arról szól, hogy ha van olyan felhasználónk, akinek van belső postafiókja (exchange users permission group), de nem Outlookból levelez, hanem bármilyen más levelezőklienssel (Thunderbird, Eudora, Pine, Pegasus és egyebek), akkor nem RPC-n adja fel a levelét, hanem azon a bizonyos SMTP Submission protokollon. Ha nincs ilyenünk, akkor nyugodtan tiltsuk le a konnektort, ha van, akkor pedig értelemszerűen állítsuk be az IP címeket a network fülön.

default
Ez a – szintén gyári – konnektor leginkább az internal sablonra hasonlít. Ezen annyit szoktam változtatni, hogy nem engedem a teljes IP tartományt, hanem csak a létező Exchange HTS/ETS szerverek IP címeit engedélyezem.

relay
Nagyjából megegyezik az Edge szervernél írtakkal. Annyi az összes különbség, hogy itt már a belső hálón vagyunk, ergo itt azon belső, de nem Exchange szerverek IP címeit adjuk meg, amelyeknek levelezési kényszerük van.

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

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.

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.)

Exchange 2010 SP1

Tegnap óta ettől hangos az Exchange blogoszféra, gondoltam, én sem maradok le.

Nem, az SP1 még nem jött ki. Várhatóan hamarosan, de legalábbis idén még ki fog jönni. (És akkor elkezdhetnek végre a magyar döntéshozók is gondolkozni az Exchange 2010 bevezetéseken.)

Most az első publikus infók jelentek meg arról, mi minden lesz benne.

Röviden összefoglalva:

  • A triviális rész: tömérdek patch, beleértve a korábbi Rollup csomagok tartalmát is.
  • A Personal Archive postafiókok külön adatbázisba pakolhatók. Innentől tényleg lesz értelme a koncepciónak. (Eddig ugyanis nem sok volt.)
  • PST import. A szanaszét burjánzó PST-ket akár a felhasználó is képes lesz betolni a személyes archív postafiókjába.
  • Még mindig a régi levelek kezelése: bejött egy segédprogram a Retention Policy tag-ek létrehozásához.
  • Kicsit tuningoltak a discovery funkción is: egyrészt bejött egy search preview lehetőség, másrészt kiszűrték a keresési eredményekből a duplikátumokat. (Emlékszünk, a discovery az az eufemizált neve a full adatbázisos keresésnek.)
  • Reszeltek egy csomót az OWA-n is. Sokkal gyorsabb lett, kiszedték belőle a lassú, bosszantó folyamatokat. Másrészt a felhasználói élményen is javítottak, át lett szabva a kezelői felület. (Hogy a netbook felhasználók is örüljenek.) Ja, és lesznek OWA skinek is.
  • IRM integráció OWA-ba, Activesync-be.
  • Egy csomó új, eddig csak EMS-ből elérhető taszk kapott grafikus felületet az EMC-ben.

Akit bővebben is érdekelnek a részletek:

Mythbuster

Ezt írtam korábban.

Utána egy csajszi Mythbuster stílusban verte a fejünkbe, hogy miket kell mondani, hogyha az Exchange kellemetlen tulajdonságairól faggatnak. Háát… a backup részt továbbra is csak kerülgették, mint macska a forró kását.

Nos, a varázsnak vége, a mítoszrombolás nyilvános lett. Igaz, itt csak éppenhogy érintve (nálunk másfél órás előadás volt), de a lényeg benne van. Pontosabban, a lényeg itt van: Large Mailbox Vision whitepaper.

2010 CAS NLB

Véleményem szerint Exchange 2010 HA témakörben a legforróbb terület jelenleg a CAS NLB: egyszerűen szükség van rá, nem lehet megkerülni – viszont igazán optimális megoldás nem létezik.

Ezt írtam itt. És szemmel láthatóan nem csak engem zavar a dolog. Egy MVP kolléga ki is fakadt a blogján – segítve rajtam, mert így nem nekem kellett megírnom a cikket.

Éj a szerverszobában – 02

Oké, szorgalmatos rőzseszedegető anyókaként kezdjünk el gyűjtögetni.

Rögtön van egy rossz hírem. Az eventlog nagy. Nem, még annál is nagyobb. És nekünk ebből kell kimazsolázni durván egy hónap Online Maintenance bejegyzéseit.

Akár fel is vehetnénk középső névnek a Hamupipőkét.

Nos, akinek szerencséje van, az Windows Server 2008-ra telepítette az Exchange szerverét. Itt ugyanis már tudunk custom view-t generálni az eventlogon belül. A Windows Server 2003 kedvelői… most így jártak. Hamupipőke.

Nagyítás

A fenti ábrán láthatók a custom view beállításai. Úgy gondolom, a kép magáért beszél.

Nagyítás

Ha beállítottuk, akkor a következő nézethez jutunk. Mekkora öröm, már… csak és kizárólag az OM bejegyzéseket látjuk. Nem mintha ebből nem lenne durva még kinyerni az összetartozó adatokat… de legalább már van némi esélyünk.

A következő event azonosítók vonatkoznak az Online Maintenance folyamatra:

  • 700: Online defragmentation is beginning a full pass on database XY
    Az XY adatbázison elindult az offline defregmentálás.
  • 701: Online defragmentation has completed a full pass on database XY
    Az XY adatbázison befejeződött az offline defregmentálás. Ekkor kiír egy csomó adatot. Az általa jelzett időtartamokkal ( x sec) bánjunk óvatosan, köszönő viszonyban sincsenek a mért értékekkel. Viszont az átmozgatott lapok száma hasznos információ: egy lap 8 KB (Exchange 2003-ban 4K), tehát ebből megtudjuk, mekkora hely (whitespace) szabadult fel az adatbázison belül.
  • 702: Online defragmentation is resuming its pass on database XY
    Korábban lezárt folyamat folytatása. (Egy folyamat lezáródhatott úgy, hogy váratlanul nagy terhelés érte az adatbázist, illetve lezáródhatott úgy, hogy letelt a folyamatra engedélyezett időablak.)
  • 703: Online defragmentation has completed the resumed pass on database XY
    Lezárult egy olyan folyamat, mely menetközben meg lett megszakítva.
  • 704: Online defragmentation of database XY was interrupted and terminated. The next time online defragmentation is started on this database, it will resume from the point of interruption.
    Az XY adatbázis online defregmentálása meg lett szakítva.
  • 717: Database checksumming background task has started.
    Elindult egy Online Checksumming folyamat.
  • 718: Database page zeroing background task has started.
    Elindult egy Page Zeroing folyamat.
  • 721: Database checksumming background task has completed.
    Lezárult egy Database Checksumming folyamat.
  • 722: Database page zeroing background task has completed.
    Lezárult egy Page Zeroing folyamat.
  • 723: Database checksumming background task encounters an error.
    A Database Checksumming folyamat közben hiba történt.
  • 724: Database page zeroing background task encounters an error.
    A Page Zeroing folyamat közben hiba történt.
  • 729: Database page zeroing has been paused.
    A Page Zeroing folyamat félbeszakadt.

Na, kérem, mindent tudunk. Már csak dolgozni kell.

Az első feladat lesz a legkönyebb: ne csináljunk egy hónapig semmit. Hagyjuk az adatbázisokat az alapértelmezett értékeken – és várjuk, hadd gyűljenek a bejegyzések.

Nagyítás

Az eventlogból kigyűjtött adatokat táblázatban összesítjük.

Igen, tudom, hogy erre a feladatra lehetne szkriptet is írni. De most levetkőzöm a rendszergazda mentalitást és azt javaslom neked is, hogy bogarászd ki egyenként az adatokat és szépen gépeld be mindet az Excel táblába. Hidd el, ennek hamarosan meglesz a jelentősége.
Ugyanis ahogy készen van a táblázat, jöhet az optimalizálás. Az egyetlen olyan feladat, amelyre nincs algoritmus. Csak te vagy és a józan ész.
Ezért fontos, hogy mire ide eljutsz, összebarátkozzál az adatbázisokkal. Ha egyenként gyűjtöd be az adatokat, akkor már menetközben össze fognak állni a történetek. Jellemük, viselkedésük lesz az adatbázisoknak. Lesz a lusta disznó. Lesz a lassú behemót. Lesz a szorgalmas cingár. Látod, hogy amíg az egyik nem és nem ér egy folyamat végére, mert mindig megszakad, addig a másik olyan sokszor zajlódik le, hogy rendszerint már nulla, vagy tíznél kevesebb lapot szabadít csak fel. Megtapasztalod, mitől függnek az időértékek.
Mire kitöltöd a táblázatot, előtted lesz az egész bagázs, mint osztályfőnök előtt a diákok az első év végén.

Optimalizáljunk.

Tételezzük fel, hogy CCR rendszerünk van, a backup a paszív node-ról megy, azaz az OM mehet az aktív node-on. Az egyszerűség kedvéért most ne foglalkozzunk a Database Checksumming folyamattal.

A munkaidőt természetesen tiszteletben tartjuk, tehát reggel 7 és este 7 között az üzleté a terep. Hétvégén viszont mi vagyunk, egész nap.
Ez annyi mint 5*12+2*24 = 108 óra.
Mennyi is jött ki a táblázatból?
21+9+9+21=60. Simán beleférünk. Mi itt a probléma?

Hát példul az, hogy az OM folyamatok nem annyira udvariasak, hogy pont az időintervallum elején induljanak el. Akkor általában már egy korábban félszakadt defrag fog folytatódni. Azaz, ha teljesen biztos akarok lenni abban, hogy egy héten belül biztosan lemenjen minden adatbázisra az OM, akkor dupla annyi időt kell kapniuk, mint amennyit mértünk. Ez 120 óra.
Annyi viszont nincs.
Jöhetnek a kompromisszumok.

A DB04 a VIP adatbázis. Itt nincs kompromisszum, sőt, ők inkább 44 órát kapnak, azt is összefüggően. A DB01 adatbázisban is vannak kritikus postafiókok, ők is megkapják a 42 órájukat. Viszont mi lenne, ha a maradék két adatbázis ugyanabban a szegmensben lenne? A szerver elbírja (úgyse dolgozik éjszaka rajta senki), és ha a maradék időt (108-44-42=22) adjuk oda nekik, akkor jó eséllyel mind a kettő le tud futni egyszer.

Nagyítás

Itt is van. A VIP 44 óra és nem szakad meg, a DB01 42 óra, de azért már szakadozik, a többiek meg majd csak ellesznek valahogyan.
De ez már egészen jó kiindulási alap.

Már csak egy lépés van hátra, belőni a backupot. Habár a két folyamat független egymástól, de célszerű a mentést rögtön az OM utánra időzíteni, így gyorsan el is takarítjuk a felesleges logfájlokat.

Nagyítás

És ugye nem felejtettük el, hogy negyedév múlva újra elvégezzük a vizsgálatot, megnézzük, hogy amit kitaláltunk, mennyire működik jól hosszú távon.

Hasznos linkek:

Éj a Szerverszobában – 01

A háttérben tessék elképzelni az Éj a Kopár Hegyen dallamát. (Ugye, a Sátán fellátogat a Földre, az őt imádó boszorkányok szombatjára.)

Nos, azt mi csak hisszük, hogy amikor estefelé végre becsukjuk a szerverszoba ajtaját és hazaindulunk, akkor a szerverek kismacskaként összekucorodnak és békés dorombolás mellett várják, hogy majd reggel megint eléjük borítjuk az ennivalót. Szervereink – ha jól vannak nevelve – akkor bizony éjszaka sem pihennek. Ilyenkor jön el általában a backup ideje – és természetesen a különböző adatbázis-karbantartásoké is.

A mostani írásban az Exchange szerver adatkarbantartási folyamataival fogok foglalkozni.

A backup-pal speciel nem. Meg később se nagyon. Az Exchange-t illetően jelenleg ez a legképlékenyebb terület, ahol éppen nem technikai megoldások, hanem koncepciók rivalizálnak.

Az adatkarbantartás, azaz nevezzük már nevén, az Online Maintenance, mindig is benne volt a termékben, de soha nem került úgy igazán a reflektorfénybe. Olyan félénk fajta a szentem. Pedig nem kellene szégyenkeznie, mert nagyon fontos szerepe van. Viszont egészen a 2010-es verzióig olyannyira visszafogottan viselkedett, hogy amint nagyobb terhelés érte az adatbázist, rögtön leállt. Azaz hiába időzítettük be adatbázisonként, hogy minden este fusson le, ha ráindítottuk közben a backupot is az adatbázisra, akkor az OM kiszállt a partiból. Majd holnap – gondolta. De ha másnap is jött az erőszakos backup… akkor az OM soha nem futott le végig.

Részletesebben a 2007-es verzióval fogok foglalkozni, de azért vetünk majd egy pillantást a 2010-esre is.

Adatkarbantartás. Mit is takar ez a fogalom? Miket kell csinálni azokkal az adatokkal, hogy karbantartva érezzék magukat?

A következő folyamatokról van szó:

  • Purge Indexes
    A törölt pointerek fizikai eltávolítása az indexfájlból.
  • Tombstone Maintenance
    A törölt elemek törölt státuszát jelző sírkövek menedzselése, lejárat esetén törlése.
  • Dumpster Cleanup
    A törölt elemek – egy beállítható ideig – nem kerülnek törlésre, hanem egy átmeneti tárolóba esnek be. Ezt hívjuk Dumpster-nek. Amint letelik az idő, véglegesen törlődnek.
  • Public Folder Expiry
    A nyilvános mappákban beállítható, meddig ‘élhet’ egy elem. Ezek lejártát vizsgálja a folyamat.
  • Age Folder Tombstone for Public Stores
    Hasonló a korábban említett sírkő kezeléshez. A különbség annyi, hogy nyilvános mappa esetén a public folder replikációt is figyelembe kell venni.
  • Folder Conflict Aging for Public Stores
    Azonos időben módosított nyilvános mappák konfliktusfeloldó folyamatának indítása. (Levelek küldése a két módosítónak.)
  • Update Server Versions for Public Stores
    A nyilvánosmappa replikációkhoz kapcsolódó verziószámok frissítése.
  • Site Folder Check for Public Stores
    Annak ellenőrzése, hogy az Administrative Group-on belül ne legyenek duplikált Site Folderek.
  • Cleanup Deleted Mailboxes for Mailbox Stores
    Azoknak a postafiókoknak a kezelése, melyekhez már nem tartozik tulajdonos felhasználó.
  • Check Messages Table
    Azoknak az elemeknek az eltávolítása, melyekre nem mutat pointer.
  • Online Defregmentation
    Tulajdonképpen ez az a folyamat, amellyel nagyon sokan összekeverik az Online Maintenace folyamatot. Tény, hogy ez a leglátványosabb eleme, de azért bőven nem csak ez játszódik le.
    Az Exchange adatbáziskezelésének a módszeréből következik, hogy a törölt elemek után lyukak maradnak az egy nagy fájlként látszó adatbázisban. Ezek a lyukak későbbi adattárolásra alkalmatlanok. Célszerűen az Online Defregmentation folyamat ezeket a lyukakat (whitespace) rendezi egy helyre, elérve azt, hogy az így kialakuló területek újra részt vehessenek az adattárolásban. Ezzel lehet biztosítani azt, hogy ha már az adatbázis mérete nem csökken, akkor ne is nőjön – feltéve, hogy az újonnan létrejövő elemek száma nem haladja meg jelentősen a töröltekét.
  • Database Checksumming
    Normál Exchange szerver esetén mentés során megtörténik a tranzakciós logok rájátszása az adatbázisra, emellett pedig lefut még egy adatbázis-integritás ellenőrzés is. Amennyiben CCR Exchange clusterünk van, amelynél a passzív node-ról mentünk, akkor az aktív node-on lévő adatbázisokra soha nem fog lefutni az integritás ellenőrzés.
    Ezt lehet úgy kivédeni, hogy engedélyezzük az Online Maintenance folyamatnak – mely ennél a felállásnál szigorúan az aktív node-on fut – hogy menetközben végezzen el egy integritás ellenőrzést is.
  • Database Page Zeroing
    Az Exchange adatbázisban egy elem törlése nem jelenti azt, hogy fizikailag is ki lett radírozva az elem tartalma. Pusztán csak az index jelzi, hogy ott már nincs elem.
    Amennyiben ez nekünk nem megfelelő, beállíthatjuk, hogy az Online Maintenance folyamat során a törölt elemek helyét nullával írja felül az Informaton Store szolgáltatás.

Az utolsó két folyamat csak az Exchange 2007 SP1 utáni rendszerekben működik és alapértelmezésben nincs bekapcsolva.

Mielőtt belecsapnánk a lecsóba, nézzük meg, mi a helyzet az Exchange 2010-ben.

A legnagyobb változás az, hogy kiszedték a karbantartási folyamatok közül az online defregmentálást. Ez innentől kezdve _állandóan_ fut, akármilyen terhelés is éri az adatbázist. Természetesen az Online Maintenance ütemezési lehetőségei továbbra is megmaradnak, csak éppen az elvégzendő feladat mennyisége csökkent.

Megváltozott a Database Checksumming is. Nem csak azért, mert átnevezték Database Scanning-re, hanem egy kicsit erőszakosabbá is tették. Na, nem nagyon, de ha egy adatbázis nem lett 3 napon belül egyszer átvizsgálva, akkor warning keletkezik az eventlogban.
Ennél is fontosabb változás az, hogy kétféle módban futtathatjuk:

  • Beállíthatjuk, hogy ez legyen az utolsó lépés az Online Maintenance folyamatban. Ez azért fontos, mert ha korábban olyan ablakot adtunk egy adatbázisnak, melyben szakadás volt, akkor az újraindulásnál nem az esedékes OM folyamat folytatódott, hanem mindig lefutott egy Database Checksumming. A hivatalos doksi szerint ez a mód főleg a kisebb adatbázisok esetében praktikus.
    Jó kérdés, mi számít kisebb adatbázisnak?

    This option works well for smaller databases that are less than 1 terabyte (TB) in size.

    Aha.

  • Beállíthatjuk azt is, hogy az online defregmentáláshoz hasonlóan a Database Scanning is 7/24-ben menjen.

Oké, térjünk vissza az Exchange 2007-hez.

Mit is tanultunk, mekkora lehet maximum egy Exchange 2007 adatbázis? Attól függ. Általában 100 GB a felső határ, de ettől egy speciális esetben eltérhetünk. Ha ugyanis CCR clustert építünk és elválasztjuk egymástól a két éjszakai orgiát, azaz a backup a passzív node-ról fut, az Online Maintenance meg békésen elpöfög az aktív node-on, akkor a felső határ felugrik 200 GB-re. (Nyilván az egésznek az az értelme, hogy záros időn belül esélye legyen az OM-nek lefutni. Ha a backup állandóan megszakítja, akkor nem lehet nagy az adatbázis.) Értelemszerűen ebben a helyzetben kötelező a Database Checksumming is, hiszen a backup elvégzi ugyan a passzív node-on az adatbázis integritásellenőrzősőt, de az aktív node-on ez nem történik meg.

Kitérő:
Érdekes kérdés, hogy CCR esetében hogyan megy át az OM hatása a passzív node-ra? Addig oké, hogy az aktív node-on buzeráljuk az adatbázist, jobbra-balra pakolgatjuk az adattáblákban az adatokat, döntögetjük a sírköveket, meg ilyesmik – de hogyan gondoskodunk arról, hogy mindez megtörténjen a passzív node-on lévő adatbázissal is? A kulcs: minden OM során elvégzett művelet bekerül a tranzakciós logba, az pedig, mint tudjuk átreplikálódik és előbb-utóbb rá is játszódik a passzív példányra.

Hohó, mondhatja ilyenkor a nagy horgász gyanakvó adminisztrátor, de akkor az OM több szekérderéknyi logot fog generálni! Jó az nekünk? Annyira nem… de ha ügyesek vagyunk, akkor úgy állítjuk be a mentést a passzív node-on, hogy az a konkrét adatbázisnál az OM ablak után nem sokkal induljon, így egyből el is tudjuk tüntetni a rengeteg logot. (Természetesen az OM ablak alatt egy másik adatbázis mentése simán futhat.)
Látható, ez igazából egy nagy csiki-csuki, egy kifejezetten embert próbáló optimalizálási feladat.

Mondjuk, egyszer belőttük. Ülhetünk-e nyugodtan a babérjainkon a továbbiakban? Nyilván nem. Az adatbázisok mérete folyamatosan változik. (Nő.) Igazából nem is ez a baj, hanem az, hogy egymáshoz képest máshogyan nő. Azaz lehet, hogy most a DB01 adatbázisnak kell adnunk a rendelkezésre álló idő 15%-át, mert akkora, de lehet, hogy egy fél év múlva a többi beelőzi és már csak 5% járna neki.

Rossz hírem van. Ezt az optimalizálási folyamatot célszerű negyedévente végigjátszani.

Ezért nem árt, ha kidolgozunk rá egy rögzített folyamatot. Erről fogok írni legközelebb.

Exchange backup módok

Habár a végén belekerült egy kis reklám is, és a cikk részletesen az Exchange 2003 mentésével foglalkozik, de mindenképpen a kötelezően elovasandó írások közé tartozik.
Ha tudni szeretnéd, mi is zajlik pontosan adatbázis-mentés közben, akár egy streaming, akár egy VSS mentés során, akkor feltétlenül fusd át.

Link:
Exchange Backup és Restore

Exchange 2010 – A Practical Approach

Úgy látszik, másnak is megtetszett az ingyenkönyv-modell.

Eddig – tapasztalatom szerint – csak egy-egy fejezeteit szokták kirakni a netre a nagyobb könyveknek… és nemritkán a letöltésekhez meg kellett adnunk egy csomó adatot, emailcím ellenőrzés… ismerjük.

Ehhez képest ennél a könyvnél csak egy emailcímet kérnek, de azt sem ellenőrzik le, szóval mehet akármi. A könyv pedig teljes. Igaz, van a végén vagy tíz oldal reklám, de legfeljebb nem olvassuk el.

Gyorsolvasással átfutottam, nem is rossz. Olyan jó 300-as szint, őrült nagy mélyfúrást ne várjunk tőle, viszont szépen össze lettek szedve a dolgok. És ami külön tetszett, az az 5. fejezet bevezetése. Nagyon szépen, közérthetően írta le a szerző, mi is történik az adott esetekben az adatbázis matyizása közben.

letöltés