Category: exchange

MS-220 vizsgaélmény

Múltkor utaltam az Exchange vizsgára (Volt vizsga, nem lesz vizsga – E-mail és a detektívek (emaildetektiv.hu) ma nekiláttam.

Sikerült megugrani 800 ponttal, de elég érdekesre rakták össze. A kérdésekről nem beszélek, sokáig úgysem aktuálisak, de tartsuk az NDA-t.

Szóval, csomó powershelles kérdés volt, még a Case Study-kban is. Ezen picit húzom a számat, nem feltétlenül ez a jó tudásmérő, hogy kétsoros ps-eket kell összeraknod. A sima kérdések közül sok olyan volt, ami a való életben felmerült, bár vagy 10 kérdés a journalinggal foglalkozott, talán ez sem olyan releváns.

És nem lehet MS-vizsga félreérthetőség nélkül. Van egy device-od, ami mailt küld az EXO-n keresztül. Melyik a jó válasz, felveszed az ip-t az spf rekordba vagy veszel neki O365 licenszet és azon keresztül állitod be. Tipikusan az attól függ kérdés, de ilyen kevés infóval csak találgathatsz, mire gondolt az MS.

Jó vizsga volt összeségében, sajnálom hogy megszűntetik, mert aktuális a tudásanyaga, de igy alakult. Aki kedvet kapott hozzá (:D) július 31-ig levizsgázhat.

Exchange Server Security Updates – June 2023

Nincs új a nap alatt; ebben a hónapban is kapnak Security Update-et az Exchange Serverek

Exchange 2016 CU 23: Download Security Update For Exchange Server 2016 CU23 SU8 (KB5025903) from Official Microsoft Download Center

Exchange 2019 CU 13: Download Security Update For Exchange Server 2019 CU13 SU1 (KB5026261) from Official Microsoft Download Center

Exchange 2019 CU 12: Download Security Update For Exchange Server 2019 CU12 SU8 (KB5026261) from Official Microsoft Download Center

Grafikus segédlet:

Exchange Online és a throttling/blocking

Nem vadonatúj az infó, de nem árt észben tartani: az EXO blokkolni fogja a sebezhető Exchange szerverektől érkező leveleket.

Sebezhető=nem támogatott verzió/nem megfelelő patch verzió

Kétkörös lesz a bekeményítés:

  • Throttling
    • ha a küldő szerver nem megfelelő, az EXO egy “450 4.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online throttled for 5 mins/hr. For more information see https://aka.ms/BlockUnsafeExchange” üzenetet fog visszadobni
  • Blocking:
    • Ha a throttling után sem lett belőle támogatott Exchange verzió, akkor jön a “550 5.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online blocked for 10 mins/hr. For more information see https://aka.ms/BlockUnsafeExchange” üzenet.

 

Nézzük a timeline-t, hogyan történik majd:

Stage 1: ez a report-only mode, az adminnak 30 napja van hogy rendbeszedje az Exchange kiszolgálót.

Stage 2-4: elkezdődik a throttling és minden 10 napban növekszik.

Stage 5-7: beindul a throttlink ÉS blocking, a blokkolás is 10 naponta növekszik.

Stage 8: az EXO nem fogad el leveleket az Exchange szervertől.

 

Az első áldozata a fenti szigorításnak az Exchange 2007 lesz, abban az esetben ha van outbound connectora az EXO-ba. Bízzunk benne hogy nincs sok ilyen, de soha ne mondd hogy biztos.

A következő körökben a Microsoft bővíti majd a blokkolandó termékek körét, függetlenül attól, hogy EXO konnektoron vagy sima SMTP-n csatlakozna be. Ezekről a Message Centerben lehet majd tájékozódni.

Exchange Server vagy Exchange Online – melyiket válasszuk?

A múltkori cikkben megnéztük, milyen támogatott on-prem verziók maradtak, most járjuk körbe, hogy maradjunk-e a földön vagy költöztessük a felhőbe az egész levelezés miskulanciát.

Tegyük fel hogy szerencsés helyzetben vagyunk, nem vonatkozik ránk az 50-es törvény, egyéb szabályozások, szabadon mehetünk a felhőbe, ha szeretnénk. Ott állunk tehát a döntés küszöbén:

  • Maradjon teljesen on-prem az Exchange?
  • Migrájunk az Exchange Online-ba és végre kapcsoljuk ki az utolsó Exchange Servert?

A döntéshez segitséget adhat a Microsoft Shared Responsibility modeljének áttanulmányozása (Shared responsibility in the cloud – Microsoft Azure | Microsoft Learn) . Egy ábrát emelnék ki, elég beszédes:

Ahogy látjuk, ha on-premise maradunk, akkor bizony minden felelősség a miénk, mindent nekünk kell megoldani; a fizikai szervereinket, storage-okat, hálózatot stb. Ok, eddig is ezt tettük, de manapság ez komoly nyűg is lehet.

Félmegoldásnak felmerülhetne, hogy akkor legyen IaaS, hiszen akkor a Microsoft megoldja helyettünk a datacenter-szerverek üzemeltetésének problémáját.  Ez nagyon rossz ötlet, amellett hogy drága lenne, nem is olyan a performancia, mint pl. az Exchange Online esetén. Egyszóval ne futtassunk felhőben Exchange Servert.

A harmadik út a SaaS, azaz az Exchange Online. Ahogy a fenti képen látjuk, ez tűnik a legkényelmesebbnek, a gyártó szinte minden feladatot levesz rólunk. Technikailag is nehéz érvelni ellene (ok, a felhő is leállhat néha, illetve ha féltjük az adatainkat, hybrid esetén vissza is migrálhatjuk a postafiókokat a földi környezetbe).

Mivel gyakorlatilag minden szervezet használ már O365 vagy M365 licenszeket (főleg a Teams miatt), amikben benne van Exchange Online licensz is (sőt, hybrid esetén a Microsoft ad ingyen Exchange 2019 licenszet is, csak migrálj), adja magát a verdikt: költöztessük fel a felhőbe a levelezést.

Hozzáteszem, hogy ez egy általános megközelítés; minden cégnek a saját szempontjai alapján kell mérlegelni, egyedi igényeket és külső szabályozásokat figyelembe venni.

Exchange Server – miből gazdálkodjunk

Kis áttekintés 2023 júniusában, hogy milyen on-prem Exchange rendszerekkel dolgozhatunk.

Bár gondolnánk, hogy egy levelező szerveren nem kell annyit frissítgetni, a gyártója másképp látja. Nézzük meg az ismert verziókat, hogy állunk most.

  • Exchange 2010 SP3: 2020 október 13-án megszűnt mindenféle támogatás. Váltani kell.
  • Exchange 2013 SP1 : idén április 11-én befejezte földi (haha) pályafutását, no longer supported. Váltani kell.
  • Exchange 2016: még állja a sarat, bár az alap támogatás megszűnt 2020 október 13-án, az utolsó CU 2022-ben jelent meg (CU23) , a security update-ek érkeznek majd egészen 2025 október 25-ig. Microsoft világban jártasak már elkezdenek előre tekinteni.
  • Exchange 2019: jelen tudásunk szerint az utolsó legény a vártán. Egészen 2025 októberéig támogatott lesz, amikor megérkezik az Exchange v.Next (?) Már akinek, mert a Software Assurance kötelező lesz hozzá.

 

Aki tehát a földön szeretne (vagy kötelező neki) maradni, az üzenet világos: migrálj minél hamarabb Exchange 2019-re (hunyorítsunk együtt, hogy elvileg 128 GB RAM a beugró…) és húzd ki 2025-ig, amíg megjelenik a “v.Next”. Aki pedig már 2019-et használ, szorgalmasan frissítse a CU/SU-kat hónapról-hónapra.

 

Hová tartunk?

Üdvözlet az Exchange-szcéna megmaradt tagjainak.

Aki követi kicsit a termék életútját, láthatja, hogy az Exchange halott. A Microsoft gőzerővel tol mindenkit a felhő felé, egyre inkább az a mantra, hogy ne üzemeltesd már, hanem migrálj az EXO-ba és megoldódnak gondjaid.

Borús is lehetne a hangulatunk, de inkább nézzük meg, mit lehet manapság kihozni az Exchange-ből és hogyan lehet összeilleszteni a felhős testvérével. Ezekről szeretnék a jövőben írni, még ha nem is csak szívásokat megörökíteni, de hátha hasznos lesz.

Nemsokára folytatjuk…

Az a szerencsétlen Edge

Már eddig is csak úgy fityegett. Adott valamennyi pluszt, de cserébe pénzt kért és komplikációkat okozott.
Most jött a bejelentés, hogy az MS támogatási elveiben változás történt.

  • A Windows Server 2016-ra telepített Edge szerver nem támogatott.
  • A Windows Server 2016-ra telepített Exchange antispam ügynökök nem támogatottak.
  • A korábbi Windows szervereken használhatod ezeket, de tudjál róla, hogy az a bizonyos Smartscreen – azaz gyakorlatilag a content filter szupertitkos algoritmusa – visszavonásra került, pontosabban, van, de nem frissül. Azaz nincs.

Mit tehetsz? Használd a Microsoft online megoldását, az Exchange Online Protection-t, vagy használj külső gyártótól származó offline megoldást.

Ennyi. A magam részéről annyira nem bánom. Az Edge jelentősége már régóta periférikus volt, az antispam ügynököket lehetett ugyan használni egy utolsó utáni védelmi vonalként, de a menedzselésük tragikus volt, hasonlóan a hatásfokuk is. Vegyük le a kalapunkat és egy perces néma csönd.

Élet a TMG után

Az Exchange rendszerekkel foglalkozók különösen rossz néven vették, amikor a Microsoft kilőtte a TMG-t. Akárhogy is nézzük, az Exchange publikálásához ez egy remek eszköz volt: csont nélkül vitte az összes protokollt, már a DMZ-ben előautentikált, azaz a belső hálóra csak autentikált forgalmat engedett be, ráadásul magát a használt protokollokat is szűrte. A TMG után nem is maradt értelmes opció. Mi rengeteget szívtunk opensource megoldásokkal, de valamin mindegyik elhasalt. Maradt a hardveres loadbalancer, mint egyetlen szóbajöhető megoldás. Igaz ugyan, hogy ez nem autentikál és nem foglalkozik túl sokat a használt protokollok ellenőrzésével, de egyfajta packet filter tűzfal és persze forgalmat oszt.
A Microsoft a TMG kinyírása után hosszú ideig nem mondott semmt. Háát, izé… majd csak lesz valahogy.

A héten indult el egy sorozat az Exchange blogon, ahol immár részletesen körbejárják a lehetőségeket.

Az első írást Greg Taylor követte el és általánosságban járja körül a helyzetet. Hogy kell-e egyáltalán protokollszűrés és előautentikáció? Az nyert, aki arra tippelt, hogy immár nem kell. Természetesen kiosztja a fejlődésben elmaradt szekuritis embereket, sőt, tippeket ad, miket mondjon nekik az Exchange adminisztrátor, ha kötekednének. Ezzel túl sokat nem akarok foglalkozni, számomra a kulcs mondanivaló az, hogy már az MS sem használ preautentikációt a felhőiben – ellenben használ IDS-t. (Gondolom, itt némi slendriánság forog fenn, hiszen IPS-nek valamivel több értelme lenne.)
Illetve, mégis. Greg írja, hogy a CAS már DMZready, azaz nyugodtan mehet rá autentikálatlan forgalom. Oké, de mi van akkor, ha van rajta Mailbox szerepkör is? Mert szép az, hogy négy Exchange szerverrel meg tudjuk oldani a terheléselosztást, de a legtöbbünk azon sportol, hogy maximum két szerver van. Ekkor viszont nagyon hiányzik a TMG.
A lényeg, hogy a szerző bemutatja a versenyzőket: kiket küld a ringbe a Microsoft? Az egyik az ARR (Application Request Routing) – legalább annyira hülye név, mint az ISA vagy TMG, szóval a vonulat megvan – a másik a WAP (Web Application Proxy). Az első egy loadbalancer, a második már egy autentikálni is képes eszköz, igaz, ez csak OWA-t képes publikálni. (És persze kitart még az UAG is, de azt az Exchange esetében jobb hanyagolni.)
Még valami. Most nem kerestem utána, de nekem úgy rémlik, hogy az ARR eredetileg nem támogatta az Exchange-t. Jó látni, hogy most már igen.
Life in a Post TMG World

A második cikkben – mely egy háromrészes sorozat első írása – B. Roop Shankar kezdi el kivesézni, mi is ez, hogyan is működik ez a bizonyos ARR. Nagy vonalakban: ez egy IIS-be épülő modul. A trükkje az, hogy ismeri – és proxyzni is tudja – azokat a Microsoft által megerőszakolt protokollokat, melyeket más webproxyk nem tudnak. Természetesen képes több szerver között terheléselosztásra is.
Egy résznél jót vigyorogtam.

Then click on “Edit Feature Settings” and change the settings for “Maximum allowed content length” to the below.

Azaz a bűvös szám: 2147483648, azaz 2 a 31-ediken. A legtöbb, mi adható.
Vesdd össze ezt az alábbi idézettel, innen:

(Update 17 Apr 2012: Looks like there’s a content-length encoding disagreement between Microsoft and Apache that breaks Outlook anywhere.)

De ez is érdekes írás. Hogy miért is olyan fontos az a content length. Cuki. Hibakódot a ‘bytes’ mezőben küldeni. Ennyit a szabványokról.

Még egy észrevétel. Az ARR Vistától a Windows Server 2012-ig minden IIS-be belerakható, és ez jó. Amit nem tudok, az az, hogy képes-e korábbi Exchange szervereket is publikálni. (A cikk csak a 2013-assal foglalkozik.) Elméletileg működnie kellene, de nálam a nappali fala karón varjúkkal van kidekorálva: én már csak akkor hiszek el valamit, ha explicit leírva látom. (Pedig gugliztam, de így sem egyértelmű a helyzet.)
Reverse Proxy for Exchange Server 2013 using IIS ARR – Part 1

Néhány e-prospektus

Most ilyen töltögetős időszak van. Az MS oldalán összeszedtek néhány Visio doksit arról, hogyan is képes együttműködni az Exchange, a Lync és a Sharepoint. A magam részéről erősen hiszek benne, hogy mérnökember rajz alapján ért meg dolgokat, szóval egy pillantást mindenképpen érdemes ezekre az anyagokra vetni.
link

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.

Copy/Paste a mi barátunk

Jelenleg egy Exchange 2013 alapú hosting infrastruktúra tervezésével foglalkozom. Mint kiderült bizonyos dolgok kikerültek a grafikus management felületből a korábbiakhoz képest. Például nincs OAB reszelés a felületen. A vége az lett, hogy nagyjából mindent PowerShell-ből kell megcsinálni. Ennek kapcsán az ember olvasgatja a helpet. Részletek különböző parancsok helpjeiből:

Get-Help New-DynamicDistributionGroup -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Get-Help New-AddressList -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Get-Help New-GlobalAddressList -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Tombol a copy/paste, ellenőrzés nélkül. Nyugi, ez már a 2010-ben is pontosan ugyanígy van a helpben.

Előadás

Hogy itt is népszerüsítsem.

2013.05.23.-án előadást tartok az Exchange 2013 mobil lehetőségeiről.

Itt nem kifejezetten az újdonságokról lesz szó, hanem arról, hogy összességében mobil oldalról mi hozható ki az Exchange-ből.

A konferencia címe: http://app.hwsw.hu/

Óvatosan az adatbázissal

Ez érdekes. Őszintén szólva, még nem merültem el a 2013-as Exchange rejtelmeibe, pedig már itt van az sp1 a cu1, lassan lehetne. Egyelőre inkább csak olvasgatok.
Például ezt az írást. Paul Cunningham emel ki egy első látásra meghökkentő mozzanatot az Exchange 2013 lelkivilágából: ha létrehozol egy mailbox adatbázist, akkor a cu1 utáni Exchange már figyelmeztet, hogy légy olyan kedves, indítsd újra az Information Store szolgáltatást. Ez, mint tudjuk, az összes adatbázis le- és visszacsatolását jelenti, azaz kemény szolgáltatáskiesést.

Azért ez megérdemel egy ‘ejha!’ füttyentést.

Aztán jön a magyarázat és ettől már valamivel érthetőbb lesz a helyzet, különösen, mivel kedvenc sorozatszereplőm, Scott Schnoll is feltűnik a darabban. Arról van szó, hogy a 2013-as Exchange (már az RTM is, csak az nem figyelmeztetett) nem egy az egyben foglalja le a memóriát az Information Store-nak, mint a korábbi verziók, hanem adatbázisonként. Azaz ha megjelenik egy új fiú a játszótéren, akkor mindenkinek abba kell hagynia a játékot, majd az IS újrakezdéskor igazságosan újraosztja az erőforrásokat.

Ettől persze még meredek volt így megoldani a problémát, de szerencsére tényleg nem olyan sűrűn szoktunk adatbázisokat létrehozni. Innentől pedig már csak a szervízhétvégéken fogunk.

ps.
A DAG üzemeltetőknek egy fokkal jobb a helyzetük, ók egy switchover/switchback párossal megúszhatják a leállást.

Exchange 2013 Setup + EAC

Nekiálltam az Exchange 2013-ra való átállásnak.

Miután az első 2013-as szerver nem abba a site-ba kerül ahol a schema master van, így a schema master site-jában kezdek neki, parancssorból a dolognak (PrepareSchema, PrepareAD, PrepareDomain)

2012-es member gép (ez sosem lesz Exchnange szerver):

Hisztizik, hogy RSAT AD DS kellene neki. Az nincs, ezen a gépen nem is lesz. Válasszunk mást.

2008 R2 DC, minden FSMO role tulajdonosa:

Hisztizik, hogy kéne neki egy .NET 4.0 – Ez átverés, a release notes-ból kiderül, hogy tulajdonképpen 4.5 kell neki. Nem ugrom be, felrakom a 4.5-öt

Kéne még egy Management Framework 3.0. Felrakom.

Ezek után lefutnak a szükséges dologk.

Csak azt tudnám, melyik idióta gyártott ilyen KÖTELEZŐ parancssori kapcsolót: /IAcceptExchangeServerLicenseTerms

Azt hiszem, ha az open világban valaki elkövetne egy hasonlót, keresztbe nyelné le a közösség.

Aki már egy kicsit utánanézett az Exchange 2013-nak az tudja (aki nem azt majd telepítés után fogja képen vágni), hogy az MMC alapú Exchange Management Console-nak vége, meghalt, eltemették.

Ami helyette van az a web alapú Exchange Administration Center.

Hosszas várakozás (2010 SP3, 2013 CU1) és némi küzdelem (Schema Upgrade másik site-on, millió tonna Windows Server Role, Feature, külön letöltendő telepíőkészlet, hatszáz újraindítás) árán sikerült a saját Exchange 2010-es infrastruktúrámba (homokozó) felraknom az első Exchange 2013-at.

A telepítő gyorsan meg is kérdezte, hogy akarom-e elindítani az Administrative Centert.

Akartam. Beléptem. Magyar.

Hogy az a…

Utálok magyarul szervert adminisztrálni.

Miért?

Nem, nem beszélek jobban angolul mint magyarul. Nem, nem felvágós úri hóbort. Hanem:

Ha valami bajom van, a magyar hibaüzenetekre, problémákra kb. 0 megoldást találok a neten.

Ok. Állítsuk át angolra:

Első ötlet: Átállítom az Internet Explorert angolra. Ez magyar, mert az operációs rendszer nyelve ugyan angol, viszont a területi beállítások magyarok, elsősorban a billentyűzet miatt. (Ez az átállítás sem egy matyóhímzés mióta az IE nyelvi beállításait integrálták a control panellel: Win8/IE10)

Kilépek az EAC-ból, becsukom az IE-t.

Megpróbálom elindítani az EAC-ot újra. Csempét nem gyártottak hozzá a start menűbe. Az IE history-ban sincs (vajon miért?). Google.

Kiderül, hogy a cím megyegyezik a 2010 ECP-vel. (https://server/ecp)

Bepötyögöm, belépek, kapok egy 2010-es OWA login ablakot. Mi vaaan?

Megpróbálom a gép összes lehetséges címével (loclhost, FQDN, IP). Mindre ugyanazt kapom vissza.

Google.

Kiderül, hogy abban az esetben, ha a mailbox még a 2010-es szerveren van akkor belépés után átirányít. Ez kikerülhető, ha így: https://server/ecp?ExchClientVer=15 adjuk meg a címet.

Sikerül. Belépek. Magyar.

Gondolkoz. Nézzük meg a postaláda nyelvét.

Belépek a 2010-es OWA-ba, kiderül, hogy magyar. Ok. Átállítom angolra.

IE becsuk, újra kinyit, EAC-ba belép. Magyar.

Get-MailboxRegionalSettings: látszik, hogy angol.

Vajon ez a beállítás honnan jön? AD.

Hopp. Nem azon a site-on van a 2013 mint a felhasználói postaláda 2010-e.

Get-MailboxRegionalSettings -DomainController <Exchange 2013 site DC>

Itt is angol.

Mi van, ha már lefutott a replikáció.

IE kilép, IE belép, EAC: Angol. – véééégre.

Exchange 2013 CU1

Az Exchange Team Blogon jártam. Megláttam a rég várva várt címet Exchange 2013 RTM CU1 … Status.

A “Status” szó így hirtelen nem tett gyanakvóvá. Pedig kellett volna.

Szóval az ígéretekkel ellentétben a fenti update nem jelenik meg az első negyedévben. Tehát még nem tudok a meglévő 2010-es infrastruktúrámba 2013-at telepíteni.

A cél azért nincs messze. Ha igaz amit ígérnek, jövő hét kedden a kezünkbe kerül az új játék. 🙂

Az eltűnt e-mail esete

Tegnapelőtt este egy weboldal nem engedett be. Megpróbáltam resetelni a jelszavam. A folyamat:

Küldenek egy e-mail-t, amiben van egy link, erre kattintva kapok egy másik levelet, benne az egyszerhasználatos jelszavammal. Szokásos eljárás.

Megjött az első levél, rákattintok a linkre, közli, hogy küldi a jelszavam.

Második e-mail sehol. Várok… várok… még mindig várok. Nem jön.

A dolog nem volt se fontos, se sürgős, így napirendre tértem a téma felett.

Másnap reggel a telefonomon nézem az adott postaládát, a levél ott van. A megfelelő időben, előző este érkezett.

Leültem az irodai gépem Outlookja elé. A levelet ott sem látom. Akkor nézzük meg OWA-ban. Bejelentkezek a saját nevemben, majd megpróbálok átlépni abba a postaládába, ahova a levél érkezett (ez nem az elsődleges fiókom, hanem a freemail fiókom “exchange-esített” változata). Nem sikerül, az OWA dob egy ronda hibát valami null property-re.

Keresgélek a neten és ezt találom:

http://support.microsoft.com/kb/2777852

Remek, ezek szerint akkor tudom megnyitni a másik mailboxom ilyen módon az OWA-ban, ha a freemail.hu-t felveszem az accepted domain listára. Ehhez valahogy nincs kedvem.

Belépek a postaládába az eredeti felhasználója nevében.

A keresett levél ott van… és … azt állítja magáról, hogy private. Ok. Ez teljesen érthető. A private jelzéssel rendelkező leveleket a Full Access joggal rendelkező másik felhasználó nem láthatja.

Ez így nekem nem jó.

Tehát a megoldás:

– csinálok egy terjesztési csoportot

– belerakom az összes érintett másodlagos postaládát

– csinálok egy Transport Rule-t amely az összes a terjesztési csoport tagjainak menő levélről leszedi a Sensitivity fejlécet, ha abban private/personal/confidental van.

Teszt kívülről. Működik.