Egy élmény volt

Jan-27th-2014

Ha van egy RDS farmod és az egyik szerveren telepítve van a Desktop Experience feature, a többin meg nem, ne lepődj meg, ha a felhasználók bejelentkezéskor hol Desktop-ot, hol Start képernyőt kapnak.

UAG kampec

Dec-17th-2013

A funkcionalitását beleépítik a WAP-ba. A támogatása – a TMG-hez hasonlóan – még él egy darabig, de a halállistára már felkerült.
Részletesen: link.

Technet Magazin kampec

Dec-15th-2013

Nem szűnik meg, csak átalakul: library, wiki, blogok. Valahol szomorú, de ebbe az irányba halad az újságírás. Saját tapasztalat, hogy jó egy éve már én sem olvastam az újságot, a szűkös időmből inkább a blogokra koncentráltam.

Link: bejelentés.

Élet a TMG után

Jul-19th-2013

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

Jun-29th-2013

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 -

Egy jó nagy kupac ingyenes e-book

Jun-20th-2013

Nem is ragozom tovább, menj el, nézz szét, töltögessél.

- link -

CAS Array 03/03 – Exchange 2013

Jun-14th-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

Jun-12th-2013

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?

Teched 2013

Jun-11th-2013

Ha nem tudtál elmenni, és fura módon az előadások is érdekeltek volna, nem csak New Orleans, akkor jó hírem van: az Ask the Core team összeszedett egy tonna videót az érdekesebb előadásokról. Nézhetők, letölthetők.

- Jó böngészést -

CAS Array 01/03 – Alapozás

Jun-9th-2013

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.

Linkedin

Jun-3rd-2013

Hm… ez egészen izgi. Kiváncsi vagyok, mi sül ki belőle.

- cikk -

Copy/Paste a mi barátunk

May-9th-2013

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

May-2nd-2013

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

Apr-30th-2013

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

Apr-19th-2013

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.

Subscribe feed