CategoryCAS

CAS Array 03/03 – Exchange 2013

Ez elméletileg a világ legrövidebb cikke lehetne: az Exchange 2013-ban nincs CAS Array. Pont.

De nem ússzuk meg ennyivel. Hiszen a CAS Array funkcionalitása hasznos volt. Valahol kell lennie valami hasonlónak.

Mindenekelőtt vizsgáljuk meg az előző írásban feltett két kérdést.

  1. Ha minden RPC forgalom RPC over HTTPS formában menne, szükségünk lenne-e marha drága loadbalancer készülékekre?
    A válasz egyértelműen az, hogy nem. A loadbalance algoritmus a layer7-ről lecsúszna a layer4-be, ott pedig már elboldogul egy sokkal olcsóbb reverse webproxy is.
  2. Át lehet-e terelni minden RPC forgalmat RPC over HTTPS-re?
    Ez már fogósabb kérdés. Mi dönti el, hogy az Outlook melyik metódussal próbálkozik? Gyakorlatilag a sikertelenség. Ha beállítjuk az Outlook profilunkban a belső szerver/CAS Array elérhetőségét, majd megadunk hozzá egy proxy szervert is, akkor az Outlook először megpróbálja RPC over TCP protokollon keresztül elérni a belső szervert. Ha a belső hálón van, akkor ez valószínűleg sikerül is neki. Ha a külső hálón van, akkor jó eséllyel nem. (Ha csak el nem konfigurálod.) Ilyenkor vált át RPC over HTTPS-re és támadja meg a proxyként megadott címet.
    Látható, hogy ha csak külső felhasználóink vannak, akkor a probléma megoldható. De ha már van belső felhasználónk is, akkor az először a belső címre próbálkozik, RPC over TCP-vel. Nyilván ezt blokkolhatjuk, vagy a CAS Array IP címének beállíthatunk valami marsbéli IP címet is – de ezekért súlyos timeout-tal, közvetve pedig felhasználói elégedetlenséggel fizetünk. Mivel az Outlook elsősorban a sima RPC-t favorizálja, így a belső hálón nem ússzuk meg a loadbalancert.

Itt jön be a képbe az Exchange 2013. Ebből ugyanis kidobták az RPC over TCP protokollt.
Elég markáns megoldása a problémának, nem mondom. Ezzel ugyanis teljesen megváltozott a leányzó fekvése. Mivel az Exchange 2013 CAS nem fogad el RPC over TCP-t, marad az RPC over HTTPS. Ez pedig már webes protokoll, melyet minden további nélkül tudunk loadbalancolni a Linux szerverünkkel. Aztán gondoljuk tovább: szükségünk van-e még az adatbázisok RPCClientAccessServer változójára? Miért lenne? Az Outlook már nem innen fogja megtudni a CAS szerver nevét. Ezért nincs szükség magára a CAS Array objektumra sem.
Ha nem innen, akkor viszont honnét? Hát az Autodiscover szolgáltatástól, mint minden más normális webes elérés az Exchange-ben. Az Outlook Anywhere szolgáltatásnak is lesz internalhostname és externalhostname paramétere, ahol az internalhostname mondja meg, melyik szervert kell támadnia bentről az Outlooknak.
Ismerős?
Na, ebből a névből lehet CAS Array-t faragni. Létrehozunk egy bejegyzést a DNS-ben, a megszokott outlook.cegnev.local névhez. Ez lehet egy kitüntetett CAS szerver IP címe, lehet DNS round robin formában az összes CAS szerver IP címe és természetesen lehet ez a reverse proxy szerverünk “külső” IP címe is. Aztán egyenként átírjuk az összes CAS szerverünkön az internalhostname paramétert erre a névre.

A CAS Array esetében láttuk, hogy kulcsfontosságú volt, mikor hoztuk létre. Jelen esetben ez már nem annyira lényeges. Amint átírtuk az értéket, az Autodiscover véges időn belül észleli a változásokat és szét is küldi.

CAS Array 02/03 – Amikor kezd bonyolódni az élet

Nos, nézzük meg alaposabban, mi is történik a különböző RPC kapcsolatok esetén, ha már van CAS Array objektumunk és rendesen be is lett állítva mind az adatbázisokban, mind az Outlook profilokban.

1. Sima RPC over TCP

From Segédlet

Ez egy viszonylag egyszerű eset. Van egy CAS Array, mondjuk outlook.cegnev.local. (Javasolt best practice.) Ennek az IP címét a DNS-ben úgy állítjuk be, hogy az egyik CAS szerverre, jelen esetben a CASy-ra mutasson. Az Outlook profilban az outlook.cegnev.local név szerepel, így az RPC kérés elmegy a CASy-ra, ott az MSExchangeRPC szolgáltatás a felhasználó MDBHome értéke alapján megkeresi, melyik Mailbox szerveren van éppen az aktív adatbázisa, és már proxyzza is a kérést.

2. Magas rendelkezésreállású RPC over TCP

From Segédlet

Magas rendelkezésreállás. Csináltunk DAG-ot, van több DC-nk, mind a hardverek, mind a network eszközök redundánsak. Most már csak az Exchange elérésének kellene annak lennie. Az RPC kommunikációt kétféleképpen tehetjük azzá:

  • Windows Load Balance Service, magunk között csak WLBS.
    Felejtős. Anyira, hogy a Microsoft sem ajánlja. Ha érdekelnek a részletek, akkor a legnagyobb hiányossága az affinitás. Pontosabban a hiánya. Csak akkor hagy figyelmen kívül egy node-ot, ha az már IP szinten sem érhető el. Exchange esetében van még egy durva hátrány: a failover cluster és a WLBS nem fér el egy gépen, tehát a korrekt megoldás még két Windows és még két Exchange licenszbe kerülne.
  • Hardware loadbalancer
    Ennyi pénzért már korrekt hardveres loadbalancer kapható. Ez ügyes, okos, mindent tud.

Tehát betettük a loadbalancer clustert a belső hálózatunkba. Cluster, mert ugye magas rendelkezésreállás. Belső háló, mert az RPC csak ott van értelmezve. Jól is néznénk ki, ha kintről is jönnének RPC kérések.
A CAS Array IP címe egyben a loadbalancer cluster virtuális IP címe. A kliensről ide érkezik be a kérés, a loadbalancer pedig a beállított konfigurációja alapján továbbítja a kérést valamelyik CAS szerver felé. Jelen esetben ez megint a CASy. Onnantól minden megy ugyanúgy, mint az előző esetben.

3. RPC over HTTPS

From Segédlet

Eddig beszéltünk a belső hálózatról. De mi van azokkal, akik valamilyen okból kifolyólag kívülről szeretnék elérni a postafiókjukat? Outlookból?
Erre találták ki az RPC over HTTPS-t. Az Outlook kliensben megadom az elérendő belső címet (outlook.cegnev.local), de mellette megadjuk a DMZ-ben elrejtett reverse proxy kinti nevét is. (Ez simán lehet egy mezei virtuális Linux egy akármilyen webszerverrel.) A reverse proxy tudja, hogy a kívülről jövő HTTPS kérést – mert ő csak ennyit lát belőle – melyik belső webszerverre kell dobnia. (Megjegyzem, itt már remekül lehet affinitást is konfigurálni – de webproxynál csak webes protokollokra működik.) A fenti ábrán a CASx webszervert választotta. A CASx terminálja a HTTPS csatornát. Itt bújik ki belőle az RPC és nekiáll keresni a CAS Array-t. A DNS vissza fogja dobni neki a beállított IP címet, a kérés továbbpattan, majd onnan megy minden, mint korábban.

4. Magas rendelkezésreállású RPC over HTTPS

From Segédlet

Ha már van egy loadbalancer készülékünk, mely az Exchange szerverek RPC szolgáltatásait proxyzza, simán használhatjuk arra is, hogy ugyanezen szerverek webszolgáltatásaival is megtegye ugyanezt. (Sajnos a Linux szervert nem tudjuk használni RPC proxyzásra, mert az már layer7.) Ettől persze egészen érdekes lesz a táncrend. A loadbalancer VIP címe van kiforgatva a külvilág felé, ide érkezik be a HTTPS forgalom. Az eszköz a HTTPS loadbalance paraméterek szerint dobja tovább a kérést egy tetszőleges CAS szervernek, ez megint a CASx. A CASx terminálja a HTTPS forgalmat, kibújik az RPC, keresi a CAS Array-t – mely jelen esetben megint a loadbalancer VIP címe. Viszont ekkor már RPC forgalomról beszélünk. A forgalom az RPC loadbalance szabályok szerint megy tovább, immár a CASy-ra, ahonnan már ismerjük a mókát.

Hogy tetszik?
Mert nekem nem túlzottan. Az utolsó két ábra olyan, mint egy Klampár-Jónyer pingpongmeccs. Muszáj ekkora adok-kapokba belemennünk?
Nem. Az MSExchangeRPC szolgáltatás képes arra, hogy megtalálja a rövidebb utat az erdőn keresztül.
De ehhez durván le kell szarnia az etikettet.
A valós működés az, hogy abban a pillanatban, amint egy CAS szerver kap egy proxyzandó kérést, mindent félretéve megpróbálkozik maga elérni az illetékes Mailbox szervert. Amennyiben ez sikerül, akkor a kérés már nem pattog tovább.

Tessék ezen egy kicsit elgondolkodni. Az utolsó két ábráról egyből látszik, hogy hülyeség. Valótlan. Már a CASx szerver megpróbálkozik elérni a Mailbox szervert és amennyiben sikerül neki, akkor a többi elem nem játszik.
Konkrétan letojja, hogy van-e CAS Array és mi a konfigurációja. Megpróbálja elérni a Mailbox szervert, és ha sikerül, akkor sínen vagyunk. Sőt, a sima RPC over TCP kapcsolatoknál sem foglalkozik egyik CAS szerver sem a CAS Array objektummal. Tőlük fel is fordulhat.

Fogadok, most összezavarodtál. A cikkek lényege éppen az lett volna, hogy megmutassam, mennyire fontos dolog ez a CAS Array objektum. Aztán kiderül, hogy a kutya sem használja. Írtam két hosszú cikket, ábrákat rajzoltam… majd kinyírtam a főhőst, mintha egy Trónok Harca szereplő lett volna. Ennek mi értelme?

Jó, pihenjünk meg egy kicsit.

Ha már lehiggadtunk, észre fogjuk venni, hogy tulajdonképpen minden rendben van: az MSExchangeRPC szolgáltatás akkor önállóskodik, amikor a kérés már elérte a CAS szervert; a CAS Array pedig arra szolgál, hogy a kliens elérje az első CAS szervert. A CAS Array nem tehet arról, hogy az RPC over HTTPS egy reverse proxyn keresztül jön be és már ez a proxy megmondja, melyik CAS szervert kell elérni. Az RPC over TCP protokoll esetében meg természetes, hogy a CAS szervereket nem érdekli a CAS Array: nem nekik találták ki. A CAS Array objektumot a MAPI kliensek használják.

Viszont ajánlanék a figyelmedbe két töprengenivalót.

  1. Ha minden forgalmat sikerülne RPC over TCP helyett RPC over HTTPS-re terelni, akkor szükség lenne-e a magas rendelkezésreállás biztosításához a drága loadbalancer cuccokra? Nem lenne-e elég helyettük az ingyenes Linux reverse proxy?
  2. Meg lehet-e oldani, hogy minden kliens forgalom RPC over HTTPS-en keresztül menjen?

CAS Array 01/03 – Alapozás

Már régóta terveztem írni egy részletesebb cikket az Exchange 2010 CAS Array működéséről, mert úgy tapasztaltam, hogy még a legprofibbak fejében sem tiszta teljesen a kép.

Kezdjük rögtön a fogalom tisztázásával. Sokan az ‘array’ névből egyből magas rendelkezésreállásra gondolnak, és összekeverik a loadbalance megoldásokkal. Hiba. Nagyon pongyola megfogalmazással a loadbalance feladata a kliens kérését egy adekvát szerveren futó szolgáltatás felé irányítani, míg a CAS Array feladata… tulajdonképpen ugyanez, de nagyon nem mindegy, mit értünk adekvát szerver kifejezés alatt, hol történik meg az irányítás… és természetesen terheléselosztásról szó sincs.

Mielőtt teljesen belebonyolódnék, kezdjük el boncolgatni az Exchange 2010 kliens oldali hozzáféréseit.
Vannak a tiszta webes hozzáférések. Ezekről túl sokat nem kell magyarázni, mindenki látott már webszervert, webes szolgáltatást. Aztán van az RPC over TCP, azaz a klasszikus MAPI. Ezt használja a vastag kliens – Outlook – de léteznek más külső alkalmazások is, mint például a Blackberry szerver. Ez nagyon nem webes hozzáférés: alaphelyzetben több tízezer port közül választhat kapcsolatonként egyet, illetve kell neki a 135-ös, ahol az endpoint mapper azt mondja meg, melyik is lett kiválasztva. (Szerencsére ez az egész konfigurálható, de jelen sorozatban ezzel nem foglalkozok.) Az Exchange-ben létezik az RPC-nek webre erőszakolt verziója is, az RPC over HTTPS, azaz az Outlook Anywhere. Itt az RPC forgalmat HTTPS csatornába gyömöszölték, így lett belőle webes adatforgalom.

Foglalkozzunk most egy kicsit részletesebben ezzel az RPC-vel. A 2010-es verzióban az RPC over TCP elérésben nagy változás történt: az Outlook kliensek immár nem közvetlenül a Mailbox szerverre kapcsolódnak, hanem egy baráti CAS szerverre, mely proxyzza az RPC kérést a Mailbox szerver felé. Innentől lesz érdekes a dolog. Honnét tudja az Outlook, hogy ki az a baráti CAS szerver, aki valószínűleg el fogja tudni érni a Mailbox szervert?

Amikor létrehozunk egy adatbázist, akkor annak az RPCClientAccessServer változójába beleíródik egy név. Ha magán a szerveren fut CAS szerepkör is, akkor a saját neve, ha nem, akkor az Exchange keres egy közeli, RPC-n elérhető CAS szervert és annak a nevét írja bele. Ez lesz az a CAS szerver, aki proxyzza a kérést az adott adatbázis felé.
Amikor a felhasználó létrehoz egy Outlook profilt a gépén, akkor az történik, hogy az Outlook kiolvassa, melyik adatbázisban van a felhasználó postafiókja, majd megkeresi ennek az adatbázisnak az RPCClientAccessServer értékét – és erre a szerverre állítja be a profilban a kapcsolódást.
Ez szépen működik is addig, amíg az a bizonyos CAS szerver elérhető. De mi van akkor, ha ledől? Az Outlook továbbra is a profilban lévő CAS szervert fogja ostromolni – sikertelenül. Hiába létezik másik CAS szerver és hiába tökéletesen egészséges az adatbázis, a felhasználó nem fér hozzá a postafiókjához.

Akár külön cikkben is lehetne részletezni, hogy mikor, mi történik. A pontos forgatókönyv csak a következőktől függ: az Exchange verziója, service pack száma, rollup pack száma, hány AD site-on vannak Exchange szerverek, használunk-e DAG-ot, loadbalancer-t, reverse proxy-t, vannak-e public foldereink és nem utolsósorban, milyen verziójú Outlook-ok vannak a cégnél.

Maradjunk annyiban, hogy ilyen esetben kisebb-nagyobb kényelmetlenségek történhetnek, melyek között szerepel az elérhetetlenség is.

Ennek a szituációnak az elegáns kezelésére találták ki a CAS Array-t.

A CAS Array egy meglehetősen absztrakt objektum az Active Directoryban. Van neki neve, FQDN értéke és egy listája, hogy mely CAS szerverek tartoznak bele. Ez egy AD site szintű objektum, azaz automatikusan a site-on belüli összes CAS szerver tagja lesz. A létrehozását nem fogom leírni, tele van ilyesmivel a net. Arról, hogy az FQDN értelmezhető legyen, nekünk kell gondoskodnunk, azaz létre kell hozni hozzá egy DNS bejegyzést.

Innentől kezdve ha kreálunk egy új adatbázist, akkor annak az RPCClientAccessServer értéke a CAS Array neve lesz. A MAPI kliensek a CAS Array nevét kapják meg. Itt jön be a képbe a DNS. A CAS Array IP címe magas rendelkezésreállású környezetben lehet a loadbalancer IP címe, egyébként pedig lehet egy általunk kiválasztott CAS szerver IP címe.
Nézzük, mi történik most a korábban vázolt példában. Azt mondtuk, hogy a Mailbox szerveren nincs CAS funkció, ezzel szemben van több különálló CAS szerverünk. Ha kidől az egyik, akkor semmi gond sincs, a DNS-ben átírjuk a CAS Array IP címét a másikra. Életszagúbb példa, hogy teszem azt, lecseréljük a CAS szerverünket. Megint csak elég átírni az IP címet a DNS-ben. A kliensek mindkét esetben gond nélkül veszik az akadályt, hiszen nem kell módosítani a profiljukban semmit. (Természetesen ezek a szituációk kezelhetőek CAS Array nélkül is, de sokkal nyögvenyelősebben. Természetesen a korábbi kiemelés megjegyzései most is érvényesek.)

Még egy apróság: a régi, azaz a CAS Array létrehozása előtti adatbázisokban az RPCClientAccessServer értéke nem változik meg magától, itt manuálisan kell módosítanunk. Hasonlóképpen a már létrejött Outlook profilokban sem történik meg magától az átállás, ehhez különféle varázslások kellenek. (Nem mindig, és nem minden varázslás működik minden esetben, de ebbe most megint ne menjünk bele.) Ezért szokták azt mondani, hogy Exchange 2010-es környezetben az első dolgunk legyen létrehozni a CAS Array-t, még azelőtt, hogy a kliensek hozzákapcsolódnának. (És persze a default adatbázisban írjuk át manuálisan az értéket.) Ezt célszerű megtenni még akkor is, ha nem foglalkozunk magas rendelkezésreállással, hiszen nem tudhatjuk, mit hoz a jövő, és a legótvarabb munka egy Exchange organizáció átvariálásakor a kilensek átkonfigurálása.

Mit fogunk ekkor látni? Ha megnézzük az Outlookban, akkor azt, hogy a kliensünk mind a webes kapcsolódásokban, mind az RPC-ben immár a CAS Array nevet használja, azaz azt az IP címet fogja támadni, amit mögé tettünk. Innentől bármikor nagyon könyen tudjuk terelni a forgalmat.

Két megjegyzés:

  • A fenti állítás nem teljesen igaz. A Public Folderek RPC elérése nincs proxyzva, tehát ott, ha mandinerből is, de a Mailbox szervert támadja a kliens.
  • Bárkiben felmerülhet az ötlet, hogy hoppá, itt olcsón lehet magas rendelkezésreállást létrehozni: a DNS-ben round robin módon felveszem ugyanarra a névre az összes CAS szervert. Ez jó addig, amíg mindegyik CAS szerver működik, de ha bármelyik ledől, arról a DNS nem fog tudni és simán kiadja a nem elérhető címeket is a hozzá fordulóknak.

Ennyi volt az alapozás. A következő írásban némileg mélyebben beleásunk a különböző RPC kapcsolódásokba, megvizsgáljuk, hogyan befolyásolja mindezt a loadbalancer, illetve a HTTPS csatornázás.

Kosztüm

Adott a feladat, publikáljunk egy Exchange 2010 OWA szolgáltatást TMG-n keresztül. Ez ma már egyáltalán nem pilótavizsgás munka, nosza.

Úgy döntöttünk, saját SAN tanúsítványt használunk, így első lépésben azt gyártjuk le. Certification snap-in, advanced, create a request. Itt kapjuk a következő ablakot.

From Segédlet

Először is pár szívélyes szóval megemlékeznék az UI tervezőjének felmenőági rokonairól. Hogy a szöszbe lehet olyan felületet tervezni, ahol nem látszik, mi kattintható választás és mi egyszerűen csak szöveg? Aki először jár erre, kénytelen az egérrel végigszkennelni az ablakot, figyelve, hol változik meg a kurzor.
Jó, nézzük a lehetőségeket. Aszongya, hogy… az Igazi Rendszergazda mindig a custom opciót választja, így akkor mehetünk is tovább.

From Segédlet

Mondjuk, nem fogunk dúskálni a lehetőségekben, az Igaz Rendszergazda egy kicsit meg is szeppen, mert egy kukkot sem ért a beállításokból, de aztán vállat von, biztosan jó lesz az alapértelmezés, és nyomja tovább bátran a varázslót. Elkészül a tanúsítvány, lecseréli az Exchange alatt, minden rendben, a napocska mosolyog, a madarak trilláznak. A belső hálóról működik az OWA, működik a MAPI, sehol nem jön fel tanúsítványhibára figyelmeztető ablak.

Kiexportáljuk a tanúsítványt, figyelve, hogy benne legyen a privát kulcs, felmásoljuk a TMG szerverre. Elkezdjük összerakni a web listenert. Elérkezünk oda, hogy kiválasszuk hozzá a tanúsítványt… de nincs. Azt mondja, hogy az a tanúsítvány, melybe az összes bizalmunkat helyeztük, az bizony inkorrekt. Hogy a manóba? Hiszen az Excange elfogadta, a kliensek elfogadták, az Active Directory elfogadta, a TMG tartományi tag, tehát a root CA tanúsítványa rajta van, a dátumok jók… akkor miért inkorrekt? Ezért.

Ott, amikor a custom sablont választottuk a tanúsítvány igénylésénél, ott csak V3-as (CNG) tanúsítványt igényelhettünk. Igenám, de ebből a tipusú tanúsítványból a TMG nem tudja kiolvasni a privát kulcsot, azaz úgy érzékeli, hogy nincs benne, azaz a tanúsítvány inkorrekt. Kuka.

Visszamegyünk ahhoz a bizonyos ablakhoz és most azt választjuk, hogy Active Directory Enrollment Policy.

From Segédlet

Itt már a jól ismert legördülő menü fogad, kiválasztjuk a V2-es Web Server sablont, és máris minden kiegyenesedik.

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.

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.

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.

OWA

Nejem, amikor meglátta a monitoromon az akronimhalmazt, ennél az egynél jelzett be boldog sikkantással, hogy végre egy, melyet ismer. Nem akartam elvenni a kedvét, de a helyzet az, hogy ez az OWA már nem a jól ismert régi OWA.

Kezdjük ott, hogy már a rövidítés sem ugyanazt takarja: Outlook Web App. Oké, tudom, nem ettől szoktunk a nadrágba pisilni.
Az átnevezés mögött viszont egy komoly változtatás van.

Nagyítás

Nagyítás

A felső kép – az URL-ből is látszik – az OWA képernyőjének fejlécét mutatja. Az alsó kép pedig az ECP fejlécét.
Hasonlít? Ja. És akkor ahhoz mit szólsz, hogy az OWA webalkalmazásból az ‘Options’ linkre kattintva átmész az ECP-be, az ECP-ből pedig a ‘My Mail’ link az OWA-ba tesz át? Külön bejelentkezés nélkül? Gyakorlatilag folyamatosan tudod váltogatni, hogy melyik alkalmazásban mit csinálsz – olyan szinten, hogy egy idő után össze is mosódik, hogy most melyikben vagy. Mindegy. Outlook Web App – és ez betakarja mindkettőt. Én például elsőre külön felvettem a kedvencek közé mindkét linket – aztán egy idő után már meg se néztem, melyikre kattintok. Mindegy.

Formulázva ez így nézne ki:

OWA(Outlook Web App) = OWA(Outlook Web Access) + ECP.

A képlet jobb oldalán álló ECP-ről már írtam, most az ugyanazon oldalon álló OWA-ról kellene. Csakhogy a probléma ugyanaz, mint korábban az ECP-nél is. A termék újdonságairól írni nem lehet – csak demózni, elmutogatni azokat. Nem is akarok most ebbe mélyebben belemenni, egyszerűen csak felsorolok néhányat:

Házirendből konfigurálható

Nagyítás

Ez abszolút új. Gyakorlatilag sebészi pontossággal tudjuk szabályozni, hogy weben keresztül mely részeit használhatják a felhasználók a levelezőrendszer szolgáltatásainak. A képen éppen egy olyan házirendet láthatunk, amelyikben letiltottam az autosignature használatát. Lehetőségből pedig van bőven, a gördítősávból látható, hogy nem is fértünk bele egy ablakba. (Azért ilyenkor el tudnék beszélni azzal a GUI-ból felmentett szerencsétlennel, aki szerint a mai képernyőfelbontások mellett is van értelme átméretezhetetlen ablakokat kitenni a képernyőre.)
Természetesen a lehetőségek nemcsak házirend formájában érhetők el, beállítgathatjuk postafiók szinten is.

Böngészőfüggetlen

Erről már volt szó korábban, Ajax (Asynchronous JavaScript and XML) azért kell.

Conversation View

Nagyítás

Ezt már egyszer próbáltam megmutatni, de 800*600-ban nem igazán sikerült. Nagyobb felbontásban azért már jobban látszik. Egész pontosan a kép jobb oldaláról beszélek, ott látható, hogy az a levél, amelyre a középső panelen ráálltam, milyen láncba illeszkedik. Tessék észrevenni, hogy az alsó levelet a ‘Sent Items’-ből vakarta elő, a felette lévő levelet viszont már az ‘Inbox’-ból… azaz tényleg képes mutatni az egész levelezési szálat. Mint a Gmail. 😛

Chat

Igen, tényleg van… de csak akkor, ha van OCS2007 szerverünk és össze van lőve az Exchange rendszerrel is.

Filterek, kibővített helyzetérzékeny menük

Ez úgy ránézésre nem nagy dolog… de praktikus. Egyfelől gyorsan tudunk váltani nézetek között, másfelől gyorsan tudjuk elérni az új rendszer extra szolgáltatásait is.

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.