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.
- 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. - Á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.
2013-06-16 at 17:13
Hello,
egy kérdés: mikor az outlook kliens a belső hálózaton van, akkor az SCP-n keresztül az internalhostname értékeket adja vissza neki a DC?
2013-06-16 at 17:59
Az SCP csak azt mondja meg, ki a CAS szervered. Az azon futó autodiscover szolgáltatás adja meg a webszolgáltatások url-jét. Outlook Anywhere esetén megkapod mind az externalhostname, mind az internalhostname paramétert. (Ugyanide jutsz, ha kintről egy DNS bejegyzés mondja meg, milyen IP címre lett kipublikálva a CAS szervered autodiscover szolgáltatása.) Ha az Outlook fel tudja oldani az internalhostname url-t IP címre, akkor RPC over TCP-vel próbálkozik. Ha nem tudja feloldani, vagy nem jön össze az RPC kapcsolat, akkor vált át RPC over HTTPS-re.
(Őszintén szólva, az még nekem sem világos, hogy az ebből adódó timeout-ot hogyan eliminálták a 2013-as környezetben.)
2013-06-17 at 09:46
Igaz, rosszul kérdeztem.
Szóval, azt mondod, a 2013-ban már nincs RPC over TCP. Így a belső hálózaton lévő outlook kliens kap az autodiscovertől egy internalhostname és externalhostname értéket. Mi alapján dönti el, hogy melyik kell neki? Először rögtön az internal-t próbálja elérni és aztán az externalt?
Bár lehet, meg is tudom magamnak válaszolni: ha SCP elérés megvan, akkor gondolom tudja, hogy belül van és kapásból az internalhostname-t próbálja feloldani. Ha nincs SCP (külső hálózat) akkor marad az externalhostname. Legalábbis pongyolán fogalmazva, de nagyjából.
2013-06-17 at 11:15
Nem így van. A mechanizmus, amit kérdezel, az az Outlook mechanizmusa és független attól, hogy milyen Exchange szerver van mögötte. Az hogy SCP, vagy DNS, az csak arra jó, hogy a CAS szervert megtalálja. Ha pl. belső géped van, amelyik nincs a tartományban, az is DNS alapján fogja megtalálni a CAS-t, mégis belső gép.
A mechanizmus pedig az, amit korábban is írtam: internal névfeloldás, ha nem sikerült, akkor megy az external-ra. Ha sikerült, akkor megpróbál kapcsolódni. Ha nem sikerült, akkor megy az externalra.
2013-06-17 at 11:21
Most már tiszta, köszönöm!
2013-06-19 at 00:59
Timeout akkor van, ha nem erkezik valasz (tuzfalban eldobjuk a csomagot, vagy ertelmetlen IP-re megyunk). Van azonban egy harmadik es egy negyedik lehetoseg is. Az egyik a tuzfalon van, es nem csomageldobas a reakcio, hanem egy korrekt ICMP connection refused. Ekkor elvben (ha jo a Windows halozati stackje) nincs timeout, az Outlook rogton kesz tenyek ele van allitva. A negyedik lehetoseg pedig az RPC-n keresztul visszaadni egy olyat, hogy itt kerem ilyen szolgaltatas marpedig nincsen. Mert ne felejtsuk el, az Exchange 2013 nem az RPC over TCP-t magat szuntette meg, hanem onmaga elerhetoseget ezen protokollon keresztul. Maga az RPC meg egy darabig velunk marad sajnos, a Windows ilyen-olyan cuccainak koszonhetoen.
De persze javits ki, ha tevednek, en nem ertek hozza, csak vegiggondoltam…
2013-06-19 at 08:01
A második (negyedik?) verzió egészen elképzelhetőnek tűnik.
2013-07-12 at 16:41
Mindig tanul az ember. Az Outlookban van egy kapcsoló, hogy különböző tipusú hálózatokon (slow/fast) melyik kapcsolódási formát válassza. Alapértelmezésben gyors hálózaton RPC over TCP, lassú hálózaton RPC over HTTPS – de beállítható, hogy mindegyik esetben az RPC over HTTPS-t használja, és ebben az esetben gyk. összeállt a szegényember loadbalancer-e.
2013-07-12 at 16:51
Viszont cserébe a proxy minden belépésnél autentikáltat egyet.