Tag: exchange 2010

Die PST, die!

Azt hiszem, egyetérthetünk abban, hogy ez az egész pst cucc már rég megérett a kidobásra. Egy dolog miatt nem tehetjük meg: nincs olcsó alternatívája.

Pontosabban, nem volt.

De előtte nézzük meg, mi is a baj a pst-vel? Leginkább az, hogy kígyó simaságú. Akármennyire is szeretnénk felelősen üzemeltetni a rendszerünket, a pst kisiklik a felügyeletünk alól. Ami addig nem is baj, amíg a felhasználó tudatában van, hogy pst-t használ, tudatában van, hogy rendszeresen mentenie kell, hogy a régi formátumú pst nem lehet 2 GB-nál nagyobb… meg ilyenek. A gyakorlatban ugyanis az van, hogy a felhasználó simán legyártja a pst-t, de nem tudja róla, hogy az egy fájl a vincseszteren, használja az autoarchivot és azt hiszi, hogy az a szerverre mentett. Aztán jön egy gépcsere, újratelepítéssel és jönnek az óriási sírások az elveszett borzalmasan fontos levelekről. A pst sérülésekről már nem is beszélve. Meg arról, hogy nem működik rájuk a Discovery (emlékszünk, a spionkodás), illetve egy notebook ellopása üzleti titkok kiszivárgásához vezethet.
Szükség viszont van rá, hiszen a postafiókok kvótázottak, ott nem tárolhatunk sokáig anyagokat – márpedig levelet nem törlünk, mert soha nem tudhatjuk, mikor lesz rá szükség. És akkor még nem beszéltünk egy kínzó dilemmáról: a pst-ket OWA-n belépve nem látjuk, ergo nagyon alaposan kell mérlegelnünk, mely leveleket húzzuk ki a personal storage-ba.

Ebből a bosszantó körből próbál kilépni az úgynevezett Personal Archive, azaz leánykori nevén Archive Mailbox (AMBX).

Nagyítás

A filozófia viszonylag egyszerű: legyen a felhasználónak a normális postafiókja mellett egy jóval nagyobb arcív postafiókja is. Ugyanabban az adatbázisban. A két postafióknak legyenek különbözőek a kvótái. Engedjük meg a felhasználónak, hogy szabadon áthúzogathasson ide leveleket, engedjük meg neki, hogy autoarchivot állíthasson be rá, sőt, mi magunk is tudunk úgynevezett retension policy-t rátenni, mely idő alapján dobálja ki automatikusan az archív postafiókba a leveleket.

Ennyi. Nem egy Enterprise Vault, de ingyenes eszköznek teljesen jó.

Első körben mondjuk elgondolkoztam, mi értelme is van ennek az egésznek – hiszen nem kellene külön két postafiókot kezelni, egyszerűen a felhasználó kapna egy jó nagy kvótát (normál + archív) és tárolhatna mindent egy postafiókban.
Végül két érvet találtam a Personal Archive mellett:

  • Rákényszeríti a felhasználót arra, hogy archívumban gondolkozzon. Hogy felelősen kezelje az anyagait, illetve vegye észre, hogy valakik felelősen kezelik helyette.
  • Amennyiben az Outlook-ot cached módban használjuk, akkor csak a normál postafiók szinkronizálódik le az ost fájlba.

Akkor nézzük a Personal Archive konkrét tulajdonságait.

  • Csak és kizárólag Outlook 2010-ből, illetve OWA-ból látszik. (Ilyenkor belegondolok, hogy kis hazánkban nem ritka még az Outlook 2000, mint céges sztenderd.)
  • Az előbb leírtam, de leírom még egyszer: látszik OWA-ból. Azaz a világ bármely pontjáról, ha az OWA ki van publikálva.
  • Gyárilag beépítve jön egy Default Retention policy. Ha egy felhasználónál engedélyezem a Personal Archive-ot, akkor ez élből ráesik. A tartalma: a két évnél öregebb leveleket kidobja az archívba.
  • Archív kvótának a Microsoft 30 GB-ot ajánl. (Mondjuk egy ekkora postaládától a 2007-es Exchange esetében biztos infarktust kaptunk volna.)
  • A Personal Archive-ot le lehet csatolni egy felhasználó postafiókjáról és 30 napon belül oda lehet adni más felhasználónak.

Végül néhány sceenshot arról, hogyan is néz ez ki valójában.

Nagyítás

Így kell engedélyezni egy felhasználónál. Nem egy pilótavizsgás eljárás.

Nagyítás

Imhol a konfigurálási lehetőségek: átírhatjuk a nevét.

Nagyítás

Itt pedig a kvótát állíthatjuk be.

Természetesen nem csak egyes postafiókonként tudjuk a személyes arcívumokat menedzselni: shellből teszőleges rugalmassággal állíthatunk elég sok mindent.

MoMT

Ez az acronym a MAPI on Middle Tier kifejezést takarja.

Azt hiszem, ezt az újdonságot is lehet simán a szeletelt kenyérhez hasonlítani.

Nagyítás

Ez valójában egy állatorvosi ló, ilyen felállás a valóságban nincsen. Viszont ha berajzoltam volna mindenféle klienst, mindenféle kapcsolódási lehetőséggel, mindenféle szerverekhez, akkor simán Burda szabásmintát kaptunk volna.

Nézzünk meg néhány tipikus kapcsolatot:

  • A legtriviálisabb: a kliens közvetlenül, MAPI-n keresztül kapcsolódik az adatbázishoz. Amióta az Exchange 4.0 kijött a piacra, ez azóta így van.
  • Hazudtam. OWA-n, Activesync-en, Outlook Anywhere kapcsolaton keresztül jövő kliensek HTTP-n keresztül érik el a CAS szervert és csak az megy tovább a mailbox szerverhez.
  • Persze nem csak postaláda elérésről beszélünk, a címlistát például GC-től kapjuk. (Javaslom, ne menjünk bele a részletekbe. Bonyolult.) Tudni kell, hogy vannak olyan kliensek (Outlook 2002 és attól visszafelé), akik azt hiszik, hogy az Exchange mailbox szerver egyben GC is. Az MBX szerver megtartja őket ebben a hitükben és a DSProxy funkción keresztül begyűjti a kliens számára szükséges címeket.
  • Aztán vannak olyan kliensek, akik közvetlenül a GC-től gyűjtik be a címlistát.
  • A cached módba kapcsolt kliensek számára a CAS szerver szedi össze a címlistákat.

Hót zavaros. Ráadásul rögtön az első pont annyira idejétmúlt, hogy ihaj. Mióta is ismerjük a háromrétegű alkalmazásarchitektúrát? Jó régen. Ez ugye azt mondja, hogy legyen egy vékony kliens (pl. egy böngésző), legyen a köztes rétegben az alkalmazás intelligencia (webszerveren futó alkalmazás) és legyen mindez mögött egy adatbázis-motor. A struktúrának számtalan előnye van. A magam részéről tényleg nem is értettem, hogy az Exchange 2007 már miért nem így jött ki.

Hogy is?

Hát úgy, hogy a kliens HTTP-n keresztül csatlakozik a CAS szerverhez – és csak ez, azaz a CAS nyit egy MAPI sessiont a mailbox szerverek felé. Kis lépés egy embernek, de óriási lépés egy Exchange organizációnak.

Nagyítás

Sorolom.

  • Az adatbázis-kezelés eltűnt egy felhőben. A kliensnek nem kell tudnia, éppen melyik adatbázis-szerveren található a postafiókja, hova is kellene konnektálni a MAPI profilban.
  • Történik egy failover, az egyik szerver elérhetetlenné válik. Mivel DAG-ot használunk, így aktivizálódik egy másik szerveren lévő adatbázis-pédány. Mit érez meg ebből a kliens? Régen azért volt egy kábé egyperces kiesés, amíg a failover megtörtént. Most nincs. A CAS tartja a kapcsolatot, majd a failover után már a másik adatbázist használja.
  • Lehetőségünk van online postafiók-mozgatásra. Nem részletezem, az elv nyilván ugyanaz, mint a failover esetében.
  • Exchange adminok tegyék kezüket a szívükre: nem sápadtak-e el mindig, amikor egy kliens telefonált, hogy nem éri el az Exchange szervert, pedig tíz perccel ezelőtt még elérte? Ilyenkor rendszerint kifogyott a mailbox szerverből az RPC. A MAPI ugyanis RPC hívásokon keresztül dolgozik, egy RPC kapcsolatot pedig menedzselni kell, mely memóriába, processzoridőbe és IO-ba kerül. Bármelyik is fogyott el, a kliensek leszakadtak a szerverről. Nézzük, mi van a MoMT esetében? A kliensek gyakorlatilag a CAS szerverre kapcsolódnak, HTTP-n keresztül. Sokkal többen mehetnek egyidőben. A CAS pedig jóval kevesebb RPC-t nyit, mint a töméntelen kliens együtt. Hogy egész konkrét legyek: a hagyományos felállásban maximum 64.000 RPC kapcsolatot tudott fogadni egy szerver, a MoMT esetében ez a szám felugrik 250.000-re.
  • Essen szó az árnyoldalakról is: a DSProxy kinyiffant, így az Outlook 2002 és az előtti kliensek bajban lesznek. Illetve dehogy: használják majd az OWA-t.
  • Végül az adatbázis-kezelés bármilyen lehet. Akár SQL is.

Ez utóbbinál időzzünk el egy kicsit. Ez ugyanis egy rendszeresen felröppenő spekuláció (elképzelted, ahogy egy spekuláció lapul a fűben, aztán felröppen?). Az SQL-ben ugyanis általában jártasak az emberek, míg az ESE nagyon sok embernek ködös. Az SQL-t kézben tudjuk tartani, az ESE meg olyan… izé: eseutil, isinteg. Borzalmas.

Nyilván amint kiderült, hogy az adatbázis-kezelés átköltözik a felhőbe, egyből beindultak a találgatások. Ezeket megelőzendő írt az Exchange csapat egy rövid hírt, miszerint átállították az adatbázis-kezelést SQL-re. Majd egy meglehetősen semmitmondó és ködös magyarázat után közölték, hogy végérvényesen az ESE mellett döntöttek.
Értelemszerűen pont emiatt a ködös magyarázkodások miatt az olyan öreg összeesküvéshívők, mint például David Sengupta, meg vannak róla győződve, hogy a történetnek még nincs vége.

DAG a kkv/soho szegmensnek is

Most már hivatalosan is lehet róla beszélni, meg egyébként is pont illik a sorozatba. Szóval, itt van egy link Henrik Walther blogjára: a DAG benne lesz az Exchange 2010 Standard verziójában is. (Bár gyanakvóbb olvasók már sejthették, ha máskor nem, akkor biztosan, amikor azt írtam, hogy kinyírták az LCR-t is.)

ps.
Kicsit hülye a cím, a magam részéről meglepődnék, ha egy soho cég egyáltalán birtokolna saját Exchange szervert és nem hosztolt email szolgáltatást használna.

Egy kis esti adatbázis-kezelés

Ha már a DAG-gal foglalkozunk, nem mehetünk el egy másik nagyívű változtatás mellett.

Az Exchange 2010-nek igen durván átírták az adatbázisok kezelését végző részét. Illetve magukat az adatbázisokat.

Kezdték ott, hogy megváltoztatták az adatbázisok sémáját. Korábban egy postafiók adatait több adatbázisból kellett összeszedegetni. (Nem, nem több edb-re kell gondolni. Az edb fájl az egy nagy bináris blob, amin belül további kis adatbázisok találhatók.) A sémaváltozás lényege, hogy immár egy postafiók összes adata egy belső adatbázisban található. Ezzel két dolgot értek el: egyrészt kinyírták a SIS-t, másrészt begyorsították az adatbázis-kezelést.
Tudni kell, hogy a SIS (Single Instance Storage) trónja már a 2007-es Exchange szervernél is erősen ingott. Arról van ugye szó, hogy ha küldök egy levelet 10 embernek, akkor a levelet az adatbázisban csak egy példányban tároljuk, ahová az egyes postafiókokból pointerek mutatnak. Exchange 2007 alatt ez már csak a csatolásokra volt igaz – a 2010-nél pedig még azokra sem.
Mit nyertünk vele? Sebességet. Az Exchange fejlesztői már korábban is határozottan jelezték, hogy a sebesség vs tárhely optimalizálás vitában a sebességre szavaznak.

Hogyan lesz ebből sebességnövekedés? Az Exchange 2010 öszes adatbázis-kezelésre vonatkozó átalakítás mögött egy elv húzódott: a sok apró adatművelet helyett kevés, nagyobb adatterületet mozgató műveletek legyenek. A magyarázat roppant egyszerű: a sok kis műveletnél a fej össze-vissza ugrál a lemezen, míg a kevés, nagy műveleteknél sorfolytonosan tudunk dolgozni. Arról nem is beszélve, hogy az IO műveleteket adminisztrálni kell: minél kevesebb van belőlük, annál gyorsabban megy az adatkezelés. Értelemszerűen, ha átalakítjuk a sémát úgy, hogy az összetartozó adatok egymás mellett legyenek, a page méretet 8 KB-ról 32 KB-ra növeljük… ezzel mind-mind gyorsítottunk.

Persze ha ez így van, akkor jogosan kérdezheted, hogy miért nem lépték ezt meg korábban? Nos, a nagy adatbázisdarabokat valahogy kezelni is kellett, mégpedig a memóriában. Mióta vannak nagy memóriaterületeink? A 64-bites váltás óta. Melyik az egyértelműen és szigorúan 64-bites verzió? A 2010-es.

Persze nem csak sebességnövekedésről van szó. Tavasszal olyan értékeket mondtak Redmondban, hogy fel sem írtam: biztos voltam benne, hogy az én angolom béna és félrehallottam. De azóta többször meg lett erősítve írásban is, szóval a számok valószínűleg igazak: egy szerveren 100 vagy 150 adatbázis lehet (remélhetőleg házon belül egyszer majd lefocizzák a végleges számot), egy adatbázisról 16 másolat létezhet és egy adatbázis maximális mérete 2 TB. Nyilván az ajánlott postafiókok mérete is 2-10 GB közé szór, illetve a Personal Archívé 30 GB.

Impozáns, nem?

Természetesen ehhez nem csak gyorsítani kellett az adatbázis-kezelésen, kellett hozzá más is. Például az, hogy az adatbázisok alá mehet nyugodtan az olcsó hardver. Azért egy SAN fajlagos adattárolási költségével kalkulálva ezek a méretek minden IT vezető pulzusát felgyorsítanák. És kellett még egy nagyon fontos dolog: az Online Maintenance felpiszkálása. Még a 2007-es termékben is az Online Maintenance úgy viselkedett, mint egy határozatlan szűzlány. Be kellett időzíteni, hogy mikor dolgozhat az egyes adatbázisokkal, de ha munka közben intenzív tevékenységet észlelt egy adatbázison (pl. backup), akkor szégyenlősen visszavonult. Hogy majd legközelebb. Az Exchange 2010-ben az Online Maintenance _folyamatos_ és határozott.

Sokat lehetne ezeken a számokon agyalni. Én csak egy aspektusra hívnám fel figyelmet. Azért ezek a számok elég nyomós érvek arra nézve, hogy az Exchange fejlesztők miért utálják a backup/restore folyamatokat. Belegondoltál már egy 2 TB-s adatbázis visszatöltési idejébe?

Magas rendelkezésreállás

Az előző írásban ész nélkül beleszaladtunk a DAG-ba, pedig a magas rendelkezésreállással kapcsolatban nem csak erről van szó.

Nagyítás

Nézzük meg ezt a képet. Érdekes módon mindkét középső panelen az adatbáziskezelés a téma. A jobb szélső akciópanalen láthatjuk is, hogy melyik panelen, miket lehet csinálni.

Vajon miért lett két panelre szétbontva a munka?

Azért, mert a felső panel az organizáció szinten egyedi adatbázisokat mutatja és itt az adatbázis paramétereit lehet állítgatni. Az alsó panelen viszont a másolat adatbázisok szerepelnek – itt a replikáció paramétereit láthatjuk, ha lekérjük a tulajdonságlapot.

És ami a legszebb az egészben, az az, hogy a felső panelen láthatjuk, most éppen a Database Management tabon belül vagyunk, a DAG… az egy egészen másik tab.
?
A helyzet az, hogy adatbázisokat tükrözni, log shippinget megvalósítani tudunk DAG nélkül is. Ezt a 2007-es verzióban úgy hívták, hogy Standby Cluster Replication: egy adatbázisról tetszőlegesen sok másolat létezhetett – és ha az aktív adatbázis megsérült, vagy a szervert líbiai terroristák felrobbantották, a rendszergazda aktivizálta az egyik passzív adatbázist és az élet ment tovább.

A DAG ennél több. A DAG a Cluster Continuous Replication örököse(1). A DAG az, aki tudja az automatikus átállást.

(1) Mind a Local Continuous Replication, mind a Single Copy Cluster némán kimúltak. Nem fértek bele a koncepcióba.

Nagyítás

A képen egy csomó ismerős dolgot láthatunk: member servers, witness server, witness directory, network jellegű erőforrások. Mind-mind mutatja, hogy itt a háttérben – miután egy varázslóval gyorsan végigrohantunk a telepítésen – tulajdonképpen egy NFS tipusú failover cluster jött létre.

Nagyítás

Olyannyira, hogy a DAG látszik a Failover Cluster Management konzolból is. Bár sasszemű kollégák kiszúrhatják, hogy ez nem az igazi CCR clusterre jellemző minta, sokkal inkább az ún. standby clusterre hasonlít. (A Services and Applications folder alatt nincs semmi, pedig ott kellene vigyorognia a CMS névnek, azaz a DAG nevének. Mely azért a DNS-be bekerült.)

Nézzünk végre konkrétumokat.

Nagyítás

Az első képen egy viszonylag egyszerű DAG megvalósítást láthatunk. Két szerver – és minden megy rajta. Nem csak a Mailbox szerepkör fut rajtuk, hanem a CAS és HTS is. Korábban mi minden kellett a magas rendelkezésreállású szolgáltatáshoz? Két MBX szerver a CCR-hez, legalább egy CAS/HTS szerver a maradék Exchange funkciókhoz. 2 enterprise licensz, 1 standard. DAG esetében egy vas – licenszestől – kipottyant.

Nézzük meg jobban az ábrát. Vészcsengő kinél jelzett be? Fent a kliens, el akarja érni az adatbázis szervert… egy load balanceren keresztül?! Adatbázisszerver… NLBS mögött? Ordítóan durva hiba lenne… ha a kliens közvetlenül érné el az MBX szervereket. De az Exchange 2010 struktújában nem így megy. Stay Tuned.

Nagyítás

Ez már egy komolyabb DAG. Látható, hogy itt már leszedtük az MBX szerverekről a többi szerepkört, azok külön tömbben feszítenek az MBX szerverek előtt.
Két dolgot kell nagyon észrevenni az ábrán. Az egyik az MBX szerverek száma. Emlékszünk, CCR esetén két node volt. Snitt. SCR szervert akármennyit tehettünk mellé, de CCR-t nem. Ez a korlát immár a múlté – jelenleg 16 szerver a limit. A DAG-ban – hasonlóan a CCR-hez – nem feltétel, hogy a node-ok egy telephelyen legyenek. (Az egy Exchange organizáció viszont igen.) Egy hardverkövetelményt viszont kegyetlenül be kell tartani: a telephelyek közötti késleltetés nem lehet nagyobb 250 miliszekundumnál.
A másik: az aktív és passzív adatbázisok mellett feltűntek a Lagged adatbázisok is. Ez meg mi? Aki játszott már komolyabban SCR rendszerekkel, annak számára nem ismeretlen a fogalom. Ott ugyanis külön szabályozhatjuk, hogy a passzív adatbázisra mennyi kivárással (lag) játszódjon rá a log, illetve a rájátszás után mennyi idő múlva törlődjön fizikailag.
Mire is jó ez? Nos, nem árulok el nagy titkot, ha azt mondom, hogy az Exchange fiúk határozottan utálják a backup/restore eszközöket. Igyekeznek is bedobni minden trükköt, hogy kiváltsák ezeket. (Szvsz nem fog sikerülni.) A lagged adatbázis az egyik ilyen trükk. Amíg nem játszatom rá a logokat az adatbázisra, addig az az adatbázis a múltat mutatja. A maximális kivárás 14 nap. Tudom, most azt kérdezed, hogy és akkor mi van a dumpsterrel? Az is van. De. A dumpster a kuka. Ahová a törölt elemek kerülnek – és ahonnan azok egy bizonyos ideig még előbányászhatóak. (Jut eszembe, kuka ügyben is történtek komoly előrelépések.) De mi van, ha nem törlés jellegű adatmódosítás történt? Teszem azt, Vezérigazgató Árpád vett a lengyel piacon egy kínai e-book readert és amikor összeszinkronizálta az Exchange szerverrel, akkor felülírta az összes kontakját mandarin karakterekkel? Törlés nem történt, kritikus adatmódosítás igen. Ilyenkor jöhet a talonban őrizgetett lagged adatbázis.

Foglaljuk össze, akkor HA téren mik is a fejlemények:

  • Nem kell drága hardver. Nincs szükség közös háttértárolóra, nincs szükség SAN-ra. Bele kell lapátolni egy jó nagy kupac merevlemezt a gépbe (JBOD) vagy hozzákapcsolni egy diszktornyot (DAS), oszt jól van. Sima SATA2-es lemezek is bőven megteszik.
  • Olcsó elemekből, a mennyiség növelésével érünk el nagy megbízhatóságot. Ez az álmoskönyv szerint is jó skálázhatóságot jelent.
  • A redundancia adatbázis szinten szabályozható.
  • Tulajdonképpen az SCR/CCR rendszerek kombinációit használjuk, úgy, hogy a részletekkel nem kell foglalkoznunk(2).

(2) Tudom, te is olyan vagy, aki szeret a részletekkel foglalkozni. De nem mindenki ilyen.

DAG

_Nem_ csak azért ez a kedvenc témaköröm, mert a kajakomnak is ugyanez a neve. 🙂
A magam részéről tényleg ezt tartom az egyik legjelentősebb architekturális változásnak.

DAG: Database Availability Group. Azaz magas rendelkezésreállás, Exchange módra.

De beszéljünk előbb egy kicsit az Exchange 4.0-ról.
Abban ugyanis olyasmi van, ami az Exchange 2010-ben már nincs.
Storage Group.

Hogyan lett ez a szegény SG kegyvesztett? Bár pontosabb lenne a kérdés, hogy hogyan is lett ez ennyire kegyelt?

Tények jönnek.

  • Egy merevlemezre a folyamatos írás sokkal-sokkal gyorsabb, mint a kevert írás/olvasás. Az írás ugyanis sorfolytonos, míg az olvasás véletlenszerű fejmozgással jár.
  • A tranzakció alapú adatbáziskezelés során a logfájlokba gyakorlatilag folyamatos írás történik, minimális olvasással.

Tehát olyan helyeken, ahol alaposan megtervezték az Exchange környezetet és fektettek hangsúlyt a sebességoptimalizálásra is, ott célszerűen az adatbázisokat egy magas rendelkezésreállású diszktömbre tették, a tranzakciós logokat pedig – logonként – külön vincseszterre, illetve tükörre.
Hogyan is nézett volna ki ez konkrétan? Ahány adatbázis, annyi tranzakciós log, azaz annyi merevlemez. Annyi kártya vagy annyi LUN. Ráadásul ezek a logok nem igényeltek ám olyan nagy helyeket, miközben a vásárolható merevlemezek alsó kapacitása folyamatosan kúszott felfelé. És – bármennyire pitiánernek is tűnik első látásra – de az angol ABC betűinek a száma véges. 20 használható betűm van. (Ez mondjuk a 2007-esig még nem okozott gondot.)

A fentiek miatt találták ki a Storage Group fogalmát. Gyakorlatilag az történt, hogy több adatbázis kezelését vonták úgy össze, hogy egy tranzakciós log tartozzon hozzájuk. Ez már mehetett külön vincseszterre.

Az elv működött is szépen, egészen a 2007-es Exchange feltűnéséig. Ebben a termékben jelentek meg a különböző szines-szagos CR technológiák és kavarták meg rendesen az állóvizet. Mindegyik szép is jó is, hasznosak, praktikusak… csak éppen van egy apró hátulütőjük: csak akkor működnek, ha egy Storage Groupban egy, azaz maximum egy adatbázis található.
Az Exchange 2007-ben még volt annyi játékterünk, hogy eldönthettük, használunk-e CR-t, vagy sem. Bár sok érv nem szólt amellett, hogy ne használjunk, de még választhattunk.
Ezt a lehetőséget műtötték ki a 2010-ből. Függetlenül attól, hogy kell-e CR technológia – aka logshipping -vagy sem. Innentől már csak egy adatbázis lehet egy Storage Groupban. Így viszont nincs értelme magának az SG-nek sem… azaz kikukázták.

De nem csak ennyi történt. A hierarchia csökkenhetett volna úgyis egy szintet, hogy az adatbázisok továbbra is szerverekhez kötődnek – de ha már vágtak, akkor rendeset vágtak. Az adatbázisok a továbbiakban az organizációhoz kötődnek – azaz organizáció szinten kell egyedi névvel bírniuk -, a szervereken immár csak tartózkodási preferenciájuk lesz. Azaz amennyiben létrehozunk egy DAG-ot, akkor az abban szereplő adatbázisoknál adhatjuk meg, hogy a körbe bevont szerverek közül melyiken milyen preferenciával tartózkodjanak. (Értelemszerűen a DAG-on belül mindegyik adatbázis példányai között log shipping kapcsolat alakul ki.)

Anélkül, hogy elmerülnénk – egyelőre – a technikai mélységekbe, az elv megértése végett nézzünk most végig egy sorozatot.

Nagyítás

Létrehoztunk egy DAG-ot. Van hozzá öt szerverem, öt adatbázisom. Szerverenként három adatbázist kezelek. A prioritásokat a sorok jelentik, nyilván az első sor jelenti az aktív adatbázis példányokat.

Nagyítás

Patch kedd. Lekapcsoljuk a 2-es szervert, és vadul nekiállunk foltozni. Látható, hogy a DB4, mely korábban ezen a szerveren volt aktív, most az 5-ös szerverre mászott át. A DB5, DB1 adatbázisokkal nincs semmi dolgunk, azoknak továbbra is működik az aktív példányuk.

Nagyítás

A takarítónő bevonul a szerverszobába és porszívózni akar. Kihúzza az egyik rack-et a konnektorból – és leáll a 3-as szerver is. Mit veszünk észre ebből? A DB2 immár az 1-es szerveren lett aktív, a DB3-nak és a DB4-nek még van aktív példánya. Igaz, a DB4-nek viszont már nincs passzív példánya.
A takarítónő pedig fütyürészve tolja a porszívó csövét.

Nagyítás

Befejeztük a hotfixek felrakását, visszaindítottuk a szervert. Az adatbázisok soványmalacvágtában tolják vissza a menetközben keletkezett logokat, majd ha ez megtörténik, a 2-es szerveren lévő DB4 aktívvá válik.

Nagyítás

A takker is befejezte a munkát, visszadugja a rack konnektorát, a helyi emberünk megkapta a riasztást, kisétál, visszakapcsolja a szervert. Az előző fázishoz hasonlóan itt is beindul a logok másolása, egészen addig, amíg ki nem alakul a kavarások előtti helyzet.

Mit vettek ebből észre a felhasználók? Gyakorlatilag semmit. Mindig volt valahol aktív adatbázisuk. (Hogy a váltásokat hogyan vészelték át szakadás nélkül? Erre később fogok kitérni.)

Management Role Assignment Policy

Akkor azon már túl vagyunk, hogyan tudunk kisebb adminisztratív feladatokat kiszórni egyes kiválasztott embereknek. Most azt kellene megvizsgálni, hogyan tudunk tömegesen plusz jogosultságokat adni a felhasználóknak – természetesen csak a saját postafiókjaikra.

Mit is értek ez alatt? Minden postafióknak vannak tulajdonságai, azoknak pedig értékei. Mondjuk display name és ‘Kovács János’. Ebből a kupacból lehet – lehetne – mazsolázgatni, hogy miket módosíthat a felhasználó és miket csak a rendszergazda.

Van ennek értelme? Valamilyen szinten van. (Anno Jim McBee is így gondolta, hiszen már az Exchange 2003-hoz is gyártott egy hasonló funkcionalitású eszközt.) Nagy cégnél dolgozó kollégák biztosan tapasztalták már, hogy például valaki átköltözött a 306-os szobából a 308-asba, de ez a változás az életben nem lett átvezetve a címtárban. Sőt, nem ritkán még a névváltozások is csak hosszú késéssel futnak át a rendszeren. Megváltozik valakinek a mobilszáma? Van akkora rend és fegyelem(1), hogy a telefonkiadó személy értesíti az AD adminisztrátort a változásról?

(1) Megjegyzem, van, ahol van. De legalábbis a szándék. Igazán nagy cégnél nyilván ez az egész nem így működik, hanem vannak kiemelt adatbázisok (HR, HW/SW leltár) először ezekben vezetjük át a változásokat, majd onnan fognak átszivárogni a módosítások a másodlagos adatbázisokba (AD, CMDB).

Mindenesetre kisebb, kevésbé szabályozottan működő cégeknél értelmes alternatíva lehet, hogy magukra a felhasználókra bízzuk, hogy ezeket az apróbb jelentőségű változásokat maguk is adminisztrálhassák. Nyilván az emailcímüket, felhasználói nevüket nem módosíthatják – de a többi módosítás delegálása már pusztán csak bátorság és cégkultúra kérdése.

Ennyi az elv. Amitől viszont nekem égnek állt a szőr a hátamon, az az Exchange 2010 alap hozzáállása. Erősen bízom benne, hogy ez csak RC tulajdonság.
Arról van szó, hogy – a general fültől eltekintve – defaultban mindenki módosíthat minden adatot a postafiókján. A későbbiekben pedig mi szigoríthatunk majd házirendekkel a hozzáféréseken.

Nagyítás

Mint látható, egy átlagos felhasználóval (Vidor) belépve csak a felső mezők szürkék, alatta mindent szabadon szerkeszthetünk, sőt, még el is menthetjük.

Legyen akkor az a feladat, hogy vegyük el az adatmódosítási jogot Kukától.

Kezdjük megint a get-command *role* paranccsal. Nem akarom most már annyira szájbarágósan levezetni, a policy-t a következőképpen fogjuk legyártani:
new-roleassignmentpolicy ‘Alap’

A szerepet a már ismert módon keressük meg.

Nagyítás

Nem, ne lepődjünk meg a szövegen. Elsőre ugyan úgy tűnhet, hogy ez éppen hogy engedélyezné a módosítást… de higgyjél nekem, én végigcsináltam. Ez fogja _letiltani_.

A policy és a szerep összekapcsolása:
new-managementroleassignment –name ‘Alap-MyBaseOptions’ –policy ‘Alap’ –role ‘MyBaseOptions’

A policy ráhúzása egy postafiókra már rutinfeladat:
set-mailbox kuka –roleassignmentpolicy ‘Alap’

Ha az összes postafiókra akarjuk ráküldeni:
get-mailbox | set-mailbox -roleassignmentpolicy ‘Alap’

Értelemszerűen a parancs első felét pofozgatva finomíthatjuk a szűrést.

Elméletileg készen vagyunk. Nézzük is meg, mit csináltunk:
get-managementroleassignment -identity “Alap-MyBaseOptions” |fl

Nagyítás

Ami elsőre feltűnhet: a RecipientReadScope és a RecipientWriteScope tulajdonságok értéke ‘Self’-re változott – azaz a felhasználó ténylegesen csak a saját postafiókjához fér hozzá. Aztán megint érdemes megvizsgálni a Distinguished Name paramétert. Ez most szemmel láthatóan nem a domain névtérben lévő objektumra mutat, a policy a konfigurációs névtérben keletkezett. Szerencsére meg is tudjuk nézni, ha az Active Directory Site & Services konzolból bemegyünk a Services folderbe és követjük a képen látható útvonalat.

Nagyítás

Imhol. Látható, kincset találtunk. Nem csak a házirendek találhatók itt meg, hanem egyéb objektumok is: összerendelések, szerepek, szkópok. Igen, szerepek. Ha legközelebb keresnünk kell, elég, ha ide nézünk be. (Mondjuk, itt viszont csak név van, description tulajdonság nincs.)

Egy dolog van már csak hátra: teszteljünk. A kicsi adminokhoz hasonlóan a plusz postafiók jogosultságokat is az ECP-n keresztül érvényesíthetjük.

Nagyítás

Nem is kell sokat magyaráznom. Kukával belépve az égegyadta világon minden szürke.

Végül álljon itt egy újabb értetlenkedés. Ha megnézed a szerepköröket, van azért ott egy csomó érdekes My* kezdetű szerepkör: MyContactInformation, MyProfileInformation, hogy mást ne mondjak. Szorgalmasan megcsináltam mindegyikhez a házirendet, rácsorgattam a felhasználóra – de az összes eredmény csak az lett, hogy onnantól a felhasználó nem tudott belépni az ECP-be.

RC.

Nos, ezzel nagyjából ki is veséztük a jogosultságokkal kapcsolatos változásokat. Jöhetnek az adatbázisok.

Discovery Search

Az előző írásban létrehoztuk a szorcs nevű MRG-t, belepakoltuk Tudort. Most már csak tesztelni kellene.

De mivel?

Itt bizony komoly filozófiai problémába ütköztünk. Csináltunk egy kicsi admint. A gyakorlatban csinálhattunk volna akár száz különböző szerepkörűt is. Le van szabályozva, mit tehetnek. Oké. De hogyan fognak hozzáférni a rendszerhez? Telepítsünk mindenkinek Exchange admin tools-t? Na ne. Powershell ISE? Egy jogásznak?

Bajban vagyunk. Pontosabban lennénk, ha nem lenne a termék része az Exchange Control Panel, barátainak ECP.

Ez ismét egy webes szolgáltatás, a Powershell ISE cikkben látszik is az ábrán. Egy olyan webes szolgáltatás, melyhez először be kell autentikálnunk(1), aztán az RBAC alapján annyit adminkodhatunk… amennyit engedtek.

(1) Live ID vagy Form-Based Authentication (FBA). Mondjuk megnézném, ki az a Microsofton kívül, aki Live id alapú azonosítást használ.

Van is egy ábra, én ijesztgetésnek szoktam használni. A közepét ne is várd, hogy elmagyarázom. Az maradjon meg a fejlesztőknek.

Nagyítás

A felső blokk a böngésző. Habár a Microsoft ki szokta hangsúlyozni, hogy bármilyen böngészőn elmegy(2), azért az Ajax ismerete feltétel. Lynx-en nem fog futni.

(2) Ez olyannyira így van, hogy tavasszal Redmondban Firefox-szal demózták.

Az a szaggatott vonal a tűzfalat jelképezi. Az ECP áthasít rajta, a 80-as porton.
Alul pedig látjuk, hogy az ECP mögött – minő meglepetés megint a Powershell, pontosabban az Exchange tudással felvértezett Exchange Management Shell áll. (Mivel webszolgáltatás, így nyilván megint WinRM-en keresztül.)

Ennyi elmélet után gépeljük be: https://xch10-xch.xch10.tst/ecp, majd lépjünk be mondjuk Kukával.

Nagyítás

Nézzük, mit látunk. Pontosabban, mit nem látunk. Nincs neki legördülő menüje, szegény csak a saját postafiókjához fér hozzá. Azt nem mondanám, hogy semmi érdekes nincs, hiszen tele van a kép érdekességekkel(3) – de a Discovery Search funkcióval kapcsolatban tényleg nem látunk semmit.

(3) Az ECP pont az az újdonság, melyet írásban nem lehet bemutatni. Semmi kedvem 150 screenshot-ot betolni a blogra – anélkül meg nem megy. Viszont biztos vagyok benne, hogy hamarosan lesz egy csomó screencast a témáról. Ha már eddig nincs.

Menjünk tovább Tudorhoz.

Nagyítás

Hoppá. Van legördülő menüje és van Mailbox Search tabja. Sőt, látható, hogy van is egy bribe11 nevű sikeres keresése. Ha erre kattintunk, láthatjuk a keresés konkrét paramétereit.

Nagyítás

Például a szövegmezőben ott van a kulcsszó. A többi beállítás ablakát nem nyitom ki, a nevekből könnyen elképzelhető, mi rejtőzik mögöttük. Talán a Storage Location beállítás érdemel egy kis külön figyelmet: itt azt adjuk meg, melyik postafiókba kerüljön az eredmény. Ide nem kerülhet ám akármilyen postafiók, gyárilag létezik egy spéci mailbox (Discovery pampam qrvahosszúGUID), csak azt lehet kiválasztani.

Végül nézzük, mi történik, ha Tudor meg is akarja tekinteni a keresés eredményét?

Nagyítás

Pofonvágták. Nincs joga.

Helyes. Pont így is akartuk.

Csakhogy… akkor hogyan tudjuk _mi_ megnézni a keresés eredményét? Azt mondja a net, hogy létezik egy beépített Management Role Group, Discovery Management néven. Csak ennek a tagja tudja megnézni a keresés eredményét. Megnéztem… és a csoport üres volt. Gyorsan beledobtam Hófehérkét, vártam 10 percet, megnéztem – és ő már látta az eredményt.
Remek.

Nagyítás

De azért a kisördög nem hagyott békén. Én is csináltam egy MRG-t, volt egy gyári is… mivel tud többet a gyári?

get-rolegroup -identity “Discovery Management” | fl

Nagyítás

Látszik, hogy két szerepkör van hozzárendelve a csoporthoz: Legal Hold, Mailbox Search. Ezzel bizony nem vagyok kisegítve, a Legal Hold egyfajta cenzúrázásra visszatartási jogot jelent, a másikat meg mi is beállítottuk. Akkor? A megoldás kulcsa a Discovery mailbox jogosultsági tábláján látszik.

Nagyítás

Tehát a Discovery Management MRG csak úgy mellékesen Full Access jogot is kapot a Discovery mailboxra. Így könnyű.

Oké, ennyi mellébeszélés után nézzük meg végül, mi is lett a keresés eredménye.

Nagyítás

Hát, itt látunk is valamit… meg nem is. Egy újabb sorjás eszköz, egy újabb bájos hasraesés.

A helyzet az, hogy ez a csomó minden, amit én most irkálok, egy előadáson alapszik. A konkrét projektor 1024*768-as felbontást tudott, tehát a demózásra használt virtuális gép képernyője 800*600 lett. Ez teljesen kiakasztotta az Exchange 2010 webes szolgáltatásait. Egész egyszerűen erre a képernyőméretre nem készültek fel.
Tessék megnézni alaposan az ábrát. Direkt úgy vágtam ki, hogy teljesen lehessen látni a virtuális gép ablakát. Jobboldalt alul látható, hogy ott lenne még anyag, csak éppen kilóg a képernyőről. Ha kilóg, hát kilóg – mondhatnánk… ha lenne gördítősáv. De nincs. Vagy elfogyott a gyárban, vagy a böngésző gondolja azt, hogy azért még csak kifértünk.
Ernő elszámolta a pixeleket is.
Aztán ha még jobban megnézzük az ábrát, akkor jobb felül, a sárga részen láthatjuk egy fekete téglalap szélét. Megsúgom, az a felhasználó adatait tartalmazná… ott lehetne látni azt, ki van belépve és ott lehetne kilépni is. Azaz nemcsak a függőleges gördítősáv fogyott el, hanem a vízszintes is.

És akkor az ábra. Erről túl sokat nem is lehet mondani. A folder neve a keresés neve lett, alatta pedig felhasználónként folderekre bontva láthatóak az érintett levelek. Jobb oldalon pedig a híres-nevezetes conversation view lenne látható, ha befért volna a képernyőre. (Nyugi, később már nagyobbra állítom a felbontást.)

Ezzel elég jól körbejártuk az MRG, ECP, Discovery témaköröket – nem beszéltem viszont még a házirenden alapuló jogosultságosztásról.

Legközelebb az jön.

Management Role Group

Jó, ez mind szép. De hogyan lehet ezeket a jogosultságokat létrehozni, beállítani, konfigurálni?
Csak és kizárólag shellből.

A feladat: hallottuk valahol, hogy meg tudjuk adni bizonyos felhasználóknak azt a jogot, hogy szavakra, kifejezésekre kereshessenek egy komplett adatbázisban. A Microsoft ezt némi eufémizmussal Mailbox Discovery-nek nevezi – de nyugodtan használhatjuk rá a spionkodás kifejezést is. Értelemszerűen nem is adjuk meg boldog-boldogtalannak ezt a jogot – de például egy jogásznak, vagy egy biztonsági főnöknek talán(1). Csak és kizárólag ezt a jogot.

(1) Ezzel azért óvatosan. Tudomásom szerint – bár nem vagyok jogász, tehát ha valakinek pontosabb infója van, javítson – Magyarországon, amennyiben a cég nem iratott alá engedélyező jellegű nyilatkozatot a felhasználókkal, akkor nem is turkálhat a postafiókjaikban.

Oké. Hogyan induljunk el?

Offline help, az ugye nincs. Csináljunk úgy, mintha semmilyen kerülő úton sem férnénk hozzá az internethez. Így legalább meglátjuk, mennyire készséges eszköz is a shell.

Tehát: annyit tudunk, hogy szerepeket akarunk kiosztani. Először is szeretnénk csinálni mondjuk egy MRG-t.
Nagy bátran gépeljük be:

get-command *role*

Nagyítás

Szerencsére nem is olyan sok. Értelemszerűen a new* kezdetű parancsok érdekelnek. Ez a new-rolegroup például határozottan szimpatikus.

get-help new-rolegroup -detailed

Nagyítás

Nem, nem csak ennyit mond. A -detailed kapcsoló ránkborítja rendesen az információkat. De ez a lényeg. Mit is kell összeraknunk, ha azt akarjuk, hogy Tudor legyen a jogosult?

new-rolegroup -name szorcs -roles ?? -member Tudor

Nem is olyan bonyolult. Igenám, de honnan lesznek meg a szerepek nevei?

Kitérő:
A korábbi get-help parancs nemcsak a szintakszist adta vissza, hanem példákat is. Például ezt.

Nagyítás

Nagyon jó példa! – csillant fel a szemem. Kiadni csak azt a jogot, hogy resetpassword. Be is gépeltem az ábrán található sort, persze felhasználóként Tudort megadva. Kövér errort kaptam. Azt mondta, hogy nincs ilyen szerepkör. Lányos zavaromban kipróbáltam mindenféle elgépelést, de semmi. Később megtaláltam a szerepeket a GUI-ban is (meg fogom mutatni) – és ott sem volt.

Nagyítás

Tekintsük ezt a még kicsit sorjás RC bájos baklövésének.

Kitérő vége.

Menjünk vissza arra a *role* képre. Van-e ott olyasmi, amelyből megtudhatjuk a szerepek neveit, funkcióit? Értelemszerűen most a get* kezdetűek érdekelnek.
Nicsak: get-managementrole.
Lőjünk bele egyet. A sörétespuskával.

get-managementrole | fl

Ez a parancs az összes létező szerepről kiírja az összes létező tulajdonságot, az összes létező értékkel egyetemben. A szöveg pár percig csak görögni fog a képernyőn.
Nem baj. Amikor megállt, nézzük meg az utolsó szerepnél, hogy milyen tulajdonságai is vannak. Van például name és van description. Bőven elég nekünk.

get-managementrole | fl name, description

Nagyítás

No, most is lesz szorgalmas görgés a képernyőn, de már jóval kevesebb. És utána kényelmesen végignézhetjük, milyen beépített szerepkörök vannak és mit is tudnak pontosan.
A fenti ábrán bejelöltem, hogy mi is kell nekünk: Mailbox Search.

Tehát a korábbi parancs valami ilyesmi lesz:

new-rolegroup -name szorcs -roles “Mailbox Search” -member Tudor

Le is fut. Meg is csinálja. Nézzük is meg.

get-rolegroup -identity szorcs | fl

Nagyítás

Hát nem szép?

Nézzük végig, fentről lefelé.

  • RoleAssignments…? Adtunk meg assignment-et? Nem. Létrejött magától. Végülis… minden adott volt, hogy létrejöhessen.
  • Egyedüli tag Tudor. Pont így szerettük volna.
  • DistinguishedName… Van neki. Méghozzá láthatjuk, hogy ez egy valami a Microsoft Security Groups OU-ban.

Nagyítás

Lám, lám, egy univerzális biztonsági csoport, benne egyedül Tudor. De ne legyenek illúzióink, a háttérben azért ez jóval több, mint egy univ.sec. csoport – láttuk, milyen extra tulajdonságai, pontosabban összerendelései vannak.

Kész. Már csak le kellene tesztelni.

Itt meg fogunk ismerkedni egy újabb nagyszerű eszközzel: Exchange Control Panel.

Legközelebb.

RBAC

Oké, túljutottunk a telepítésen. Itt az idő, hogy megvizsgáljuk, mit is kaptunk.

Nyilván neki lehet úgy is állni, hogy elkezdünk össze-vissza kattogtatni a grafikus felületen, aztán figyeljük, hogy mi történik. Csak éppen nem javasolt. Az RBAC-ról speciel a GUI-n keresztül egész konkrétan semmit sem fogunk megtudni.
Pedig az egyik leglényegesebb változás.

A rövidítés azt takarja, hogy Role-Based Access Control.

Gondoljuk el, hogy mennyire kényeztetett el eddig minket az Exchange, ha a jogosultságok finomhangolásáról volt szó?
Van ugye 4 admin jogkörünk:

  • Organization admin: Maga az Atyaúristen.
  • Server admin: Atyaúristen, csak kicsiben: képességeinek korláta egy Exchange szerver.
  • Recipient admin: Szintén az Olümposz lakója: ő a postafiókok terén mindenható.
  • View-only admin: Ő sem kispályás: mindent lát egy organizációban.

Egyébként pedig léteznek még a mezítlábas gyalogok, az úgynevezett júzerek.

Bármi ettől eltérő jogosultságot szerettünk volna kikeverni, be kellett merészkednünk a security descriptorok, access tokenek sűrű, sötét dzsungelébe. És ebben nem is az ismeretlen dzsungel volt a fő baj, hanem az, hogy a nagynehezen összefércelt jogosultságaink upgrade esetén mentek a levesbe.

Szerencsére itt van az RBAC. Illetve lesz.

Két irányban tágítja a lehetőségeket:

  1. Lehetővé teszi ún. kicsi adminok létrehozását. Rengeteg előregyártott szerepkört tartalmaz, de a lista custom szerepkörökkel is bővíthető. Ezeket a szerepeket hozzárendelhetjük univerzális csoportokhoz, a csoportokba pedig behajigálhatunk felhasználót, csoportot, recipientet.
  2. Többlet lehetőségeket biztosíthatunk az egyes felhasználóknak, természetesen csak a saját postafiókjaikra. Nem meglepő, hogy erre a célra házirendeket fogunk felhasználni.

1. Management Role Group

Nagyítás

Az ábrán láthatjuk részletesen is, milyen környezetben létezhetnek a kicsi adminok.
Létezik egy Management Role Group (MRG). Ez egy univerzális group, ide szórjuk be a konkrét szereppel megbízott felhasználót, csoportot, recipientet. A másik oldalon létezik egy vagy több szerepkör. Mint írtam, ez lehet beépített, vagy általunk gyártott. (Első körben mindenképpen az előbbi. Ahogy elnéztem, nem túl egyszerű dolog szerepet gyártani.)
A kettő között egy összerendelés, egy Management Role Assignment hoz létre kapcsolatot. Ennek az összerendelésnek még van egy scope paramétere is, miszerint az MRG a címtár egyes névterein belül – eltekintve persze a schema névtértől – mihez fér hozzá írás/olvasás jogosultságokkal.

2. Management Role Assignment Policy

Nagyítás

Itt elkövettem egy apró bakit, mert szerettem volna a két eset közötti hasonlóságot bemutatni. A valóságban természetesen nem a felhasználók esnek rá a házirendre, hanem pont fordítva.
Tehát. Létrehozunk egy Management Role Assignment Policy-t (MRAP), melyet majd valahogyan (powershell, powershell) ráküldünk bizonyos recipientekre. A jobb oldalon ugyanazok a szerepek találhatók, mint az előző ábránál. Alul pedig a Management Role Assignment kapcsolja össze a házirendet a szerepekkel. Fontos eltérés, hogy ebben az esetben nincs értelme scope-ról beszélni, hiszen a felhasználók a saját postafiókjaikhoz férnek hozzá.

Végül összefoglalva a két eset:

Nagyítás

Ennyit az elméletről. A folytatásban kinevelünk egy nem is kicsi admint, akinek megadjuk azt a jogot, hogy az egész adatbázisban kereshessen (de az külön állítható, hogy meg is tekinthesse a keresés eredményét), illetve házirendből beállítjuk, hogy bizonyos felhasználók ne tudják módosítani a postafiókjukhoz kapcsolódó ún. nem túl fontos tulajdonságokat.

Powershell ISE

Jó. Van egy zsír új Exchange 2010 szerverünk. Piszkálhatjuk konzolból és piszkálhatjuk shellből. Remek.

Egészen addig, amíg el nem bökjük.

Én ugyanis egy hanyag mozdulattal lehúztam a két shortcut-ot a desktopra: ne kelljen keresgélnem, legyenek mindig kéznél. Csakhogy – a fene tudja, miért – de tönkrement a felhasználóm profilja. Nem gond, adminnal belép, profil töröl, felhasználó újra belép. Igenám… de a gyári shortcut-ok a profillal együtt elvesztek.

Ritka hülye helyzet. Van egy teljesen jól működő Exchange 2010 szervered… csak éppen nem férsz hozzá. Oké, a konzol nem probléma. Egyrészt egy üres MMC konzolba is fel lehet venni, másrészt a bin könyvtárban ott van a gyári konzol is. Viszont a konzol ebben a verzióban leginkább csak dekoráció: az igazán komoly dolgokhoz már a shell kell. Naná.

Hogyan is indul a 2007-es EMS? Elindítjuk a Powershell 1.0-át, úgy, hogy paraméterként megadjuk neki az Exchange Extension plugint. Akkor keressünk rá a neten, hogy 2010-nél mi a helyzet.
Szomorú. Azt írják, hogy ugyan el lehet indítani így is, de nem kapunk teljes értékű shellt.
De akkor hogyan indítsam?

Máshogy. Plugin dugaszolás helyett kapcsolódni kell. Találtam ugyanis egy másik írást arról, hogyan lehet rákapcsolódni egy Exchange 2010 számítógépre másik gépről, úgy, hogy megkapjam a shellt. Vad? Ne mondd már. Jó egy éve azt lehet mindenhol olvasni, hogy a Powershell 2.0 már engedni fogja a távoli hozzáférést. Ami esetleg vad lehet, az az, hogy a lokális gépről próbáljuk távoli eléréssel elérni a helyi powershellt. De ha jobban belegondolsz, ez sem olyan szokatlan, hiszen az előző cikkben láthattad, a gyári shortcut is ezt csinálta.

Tehát:

  • Elindítok egy üres powershell ablakot.
  • Beírom egymás után a következő két sort:
    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2010 server>/PowerShell/ -Authentication Kerberos
    Import-PSSession $Session

Teszt: get-mailbox | fl name. Működik.
Na, ez már valami.

Csak éppen nehézkes és egyáltalán nem elegáns. Például a két parancsot be lehetne tenni egy szkriptbe és azt a szkriptet paraméterként átadni a powershell-nek. Meg lehet csinálni? Meg.

De létezik egy sokkal szebb és praktikusabb megoldás is. A Windows Server 2008 R2-nek, illetve a Windows 7-nek része az ún. Powershell ISE, azaz az Integrated Scripting Environment. (Úgy tudom, Windows 2003 szerverhez, Vistához és XP-hez meg letölthető.)

Mit is tud ez?

Nagyítás

Nagyjából ezt.

Kaptunk egy programozói környezetet. Van interaktív ablakunk (legalsó rész), ahová be tudunk gépelni parancsokat, melyeknek az eredménye a középső – output – ablakban jelenik meg. A felső blokkban pedig szkripteket írhatunk, méghozzá akár többet is, hiszen szemmel láthatóan a szkriptekhez tabok tartoznak. Emellett felhívnám még a figyelmet a debug menüpontra. (A helyzetérzékeny help-ről nem is beszélve.)

Hogyan lesz ebből Exchange Management Shell indító shortcut-unk? Hát úgy, hogy azt a bizonyos másfél sort kirakjuk egy ps1 fájlba, majd gyártunk egy shortcut-ot a Powershell ISE-nek, paraméterként meghíva a szkriptünket. Így az induláskor egyből be is töltődik, rögtön meg is lehet futtatni az F5-tel.

Feladat megoldva. Még mindig fogalmam sincs, mi rejtőzik valójában a gyári shell shortcut mögött – de már nem is érdekel. Van jobb.

Mielőtt még lezárnánk ezt a témát, egy gondolat erejéig érdemes elmeditálni, mit is csinál ez a másfélsoros szkript. Első sor: definiálunk egy változót. Második sor: nyitunk egy sessiont, melynek paraméterei az előzőleg definiált változóban vannak. Mik is ezek a paraméterek? Egy név, egy URI… de micsoda URI! Leírom, hogy nálam ez konkrétan hogyan nézett ki:
http:\\xch10-xch.xch10.tst\powershell
Azaz léteznie kell az Exchange szerveremen egy powershell nevű webszolgáltatásnak.

Nagyítás

És tényleg. Létezik. Tehát amikor egy sessiont nyitok, akkor ehhez a powershell webszolgáltatáshoz kapcsolódok- mely mögött a WinRM dübörög -, megkérem az Exchange modult, mindezt kerberos autentikációval.

Amellett, hogy szemmel láthatóan ez a felület sokkal praktikusabb, az ISE-nek van még egy óriási előnye. El is hangzott, de ha Windows7-et használsz, meg is győződhetsz róla: menjél be az Accessories/Powershell menübe – ott lesz az ISE. Ha belemásolod a fenti másfélsoros szkriptet – esetleg kipreparálod, hogy induláskor betöltődjön – akkor úgy tudod a munkaállomásodról menedzselni az Exchange 2010 szerveredet, hogy nem kellett hozzá semmiféle admin tools-t telepítened. Akár egy mezei felhasználó gépéről is tudsz adminkodni, ha éppen olyan szorult helyzetbe kerülsz.

Ja, hogy akkor majd tud a mezei felhasználó is? Nem, nem. Arra való az RBAC.

De erről majd legközelebb.

Ha internet van, minden van

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

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

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

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

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

Nagyítás

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

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

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

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

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

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

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

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

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

Csapjunk bele.

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

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

Háát…

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

Észrevettem.

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

Nagyítás

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

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

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

Nagyítás

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

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

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

Bitvadász vagy-e?

Haladva a korral – ugye tudjuk, előbb-utóbb a Microsoft is nyílt forráskódú lesz (Open Specific Documentation) – egy újabb adag technikai dokumentum került ki az internetre. Hogy egész pontos legyek, az Exchange 2010 működéséhez szükséges MS protokollok teljes és részletes leírása.

A doksik nyitólapja: Microsoft Exchange Server 2010 Beta Protocol Documentation.
De ha nem akarjuk egyenként letöltögetni a pdf fájlokat, akkor az utolsó linkről egy nagy tömörített fájlban is lekaphatóak.

Használati utasítás:

  1. Először nyissuk meg az MS-OXPROTO fájlt, az egy jó nagy nyitódokumentáció.
  2. Keressük meg benne a minket érdeklő protokollt.
  3. Majd nyissuk meg a megadott fájlt.

Én kiváncsiságból az Autodiscovery működését néztem át – MS-OXDISCO – és meg vagyok vele elégedve: tisztességesen részletes.

Database Availability Group

Egy kicsit felpezsdült az élet, ahogy kijött az Exchange 2010 béta. Szép lassan körbe is lehet járni az újdonságait.

Kezdem a DAG-gal, mert számomra ez jelenti a legnagyobb strukturális változást.

Régebben voltak ugye az adatbázisok, ezek storage groupokban helyezkedtek el, a tranzakciós logok pedig SG-khez voltak rendelve. Az adatbázisok és a storage group-ok nevei szerverszinten kellett, hogy egyediek legyenek. (Ugye, a sok Mailbox Database a First Storage Group-ban.)
A magas rendelkezésre állást SG, illetve szerverszinten valósítottuk meg, attól függően, hogy melyik technológiát használtuk. Az adatbázisok ettől még konkrétan szerverekhez tartoztak, ha egy SCR failover miatt váltanunk kellett, akkor át kellett ‘home’-olni a felhasználókat a másik szerverre. (Ez az aktív-aktív jellegű SCR-re vonatkozik.)

Exchange 2010-ben némileg megváltoztak a dolgok. Például tokkal-vonóval ki lett dobva a Storage Group fogalom. Az adatbázisok pőrén léteznek a szervereken. A tranzakciós logok szerverekhez rendeltek, de adatbázis szintűek. (Igen, ez nekem is zavaros egy kicsit, de egyelőre a részletekről nincs túl sok infó.)
Értelemszerűen a redundancia is adatbázis szintű. Ez a DAG.

Kezdjük ott, hogy feltelepítünk egy Exchange 2010 szervert, értelemszerűen – a DAG miatt – Windows Server 2008 Enterprise szerverre. Magát a Failover Cluster szolgáltatást nem is kell telepíteni. Később feltelepítünk egy másik szervert, hasonló felállásban. Az első alkalommal, amikor azt mondjuk, hogy és most szeretnénk egy DAG-ot erre a két szerverre, akkor a Failover Cluster szolgáltatás automatikusan települ, anélkül, hogy külön értesítene minket. Nincs lehetőségünk, hogy nekiálljunk válogatni, CCR vagy SCR technikát szeretnénk. Maga a technológia bekerült a motortérbe, a vezetőülésből már nem látjuk.

A mi dolgunk az lesz, hogy meghatározzuk, hogyan oszoljanak el az adatbázisaink a DAG-ban. Melyikből legyen másolat a másik szerveren? (Több szerver esetén nyilván ennél bonyolultabb figurákat is össze tudunk rakni.) Illetve azt is meg tudjuk adni, hogy a felhasználók mely adatbázisokat milyen prioritással használjanak.

Kíváncsi vagyok, kinél csengetett a vészcsengő? Több szerver? Hiszen eddig a CCR két szerverre korlátozódott? Immár nem.

Folytassuk. Az gondolom látszik, hogy ebbe a struktúrába a hagyományos SCC cluster nem fog beleférni. Béke poraira. Az Exchange 2010 már nem fogja támogatni.

Jó hír a kisebb cégeknek. Immár a magas rendelkezésre állás nem zárja ki azt, hogy más szerepkör is rákerüljön a Mailbox szerverre. Szabad a pálya – így gyakorlatilag két szerverrel megoldható minden.

Logikus következmény, hogy DAG esetén az adatbázisokat már nem szerverhez kell rendelnünk, hanem organizációhoz. Hiszen már több szerveren is előfordulhat. Ebből következően az adatbázis nevének organizáció szinten kell egyedinek lennie.

Létezik egy olyan tendencia az Exchange fejlesztői csapatban, melyet úgy neveznek: Backupless Configuration. Azaz az Exchange szabadulni akar a backup/restore mocsárból. A DAG ebben is nagyot segít, hiszen azzal, hogy több szerveren is megtalálható ugyanannak az adatbázisnak ugyanolyan változatú példánya, az adatvesztés meglehetős nagy eséllyel kizárható. Oké, mondhatnád, de mi van akkor, ha valaki töröl egy elemet, majd később azt kell visszaállítani? Nos, lehetőségünk van késleltetésre is. Ez azt jelenti, hogy megadhatjuk egy DAG-on belül, hogy egy istenhátamögötti, alacsony prioritású adatbázisra a logok csak bizonyos késéssel játszódjanak rá. A késleltetés maximális értéke 14 nap. (Ehhez kell még hozzáadni azt az időt, melyet a Dumpster nyújt.)

Megjegyzés:
Maradjunk annyiban, hogy ezen a téren szkeptikus vagyok. Nagyon. Sok cégnél éveken átnyúló archiválási előírások vannak. Oké, hogy az Archive Mailbox (AMBX) ezen sokat fog segíteni (persze merevlemezterület beáldozásával, szalagra ugye nem tud dolgozni), de mi van, hogyha valaki ebből az AMBX postaládából töröl ki mondjuk egy egyéves levelet? Nem mondhatjuk azt, hogy ‘márpedig ilyen nálunk nem fog előfordulni’. Érzem az Exchange csapat erőfeszítéseit, a lehetőségek 90-95%-át már le is tudták fedni – de a levelek visszakereshetőségének a megadott intervallumra kötelezően 100%-osnak kell lennie. Más nem fogadható el, még a kis cégeknél sem.

Vissza a DAG-hoz. Van-e valamilyen megkötés a két szerver elérhetőségére nézve?
Van. Mindkettőnek azonos címtárban kell lennie. (Nyilván az azonos organizáció a fő követelmény.) Ezen belül a szerverek tetszőleges AD site-on, tetszőleges alhálózaton lehetnek – egy követelmény létezik csak: a szerverek közti késleltetés nem lehet nagyobb, mint 250 ms.

Az írás végére néhány link: