Engedélyezzük a MAPIHTTP-t

Korábban már írtam arról, hogy az Exchange Server 2013 SP1 megjelenésével egy új protokoll került a termékbe. Ez a MAPIHTTP. Bővebb információt a protokollról itt találhatsz: http://blogs.technet.com/b/zoltanh/archive/2014/01/30/mapihttp.aspx

Most, hogy megjelent az SP1, annak telepítése után engedélyezzük. A frissített, MAPIHTTP képes eszközeink profitálni fognak belőle. Röviden áttekintjük most azt, hogy mit is kaptunk az SP1-el, mi az alapértelmezett beállítás, valamint azt, hogy hogyan tudjuk engedélyezni a szolgáltatást gyorsan és egyszerűen.

Mit kaptunk az SP1-el?

Az SP1 szerver oldali telepítésével létrejött egy Organization szintű új beállítási lehetőség. Ez az új Organization szintű tulajdonság a MapiHttpEnabled (true / false). Alapértelmezésben ennek értéke false, tehát ki van kapcsolva a MAPIHTTP szolgáltatás. Az Organization szintű beállítás mellett 1-1 új Virtual direcotry-t is kaptunk az IIS-ben, a back-end és a default web site alatt. Természetesen a MAPIHTTP esetében is követjük a proxy logikát és az új architektúrát, csak úgy mint az összes többi protokoll és alkalmazás esetében. Ezért hát a két virtual directory.

Tehát alapértelmezett beállítások esetén a MAPIHTTP nem működik. Ezen a ponton még minden kliens RPC/HTTP protokoll segítségével kapcsolódik az Exchange szerverhez, ahogy az az én környezetemben is látható:

Engedélyezzük

A szolgáltatás engedélyezése viszonylag egyszerű feladat. Az Organization szintű beállítás értékét false-ról, true-ra kell állítanunk, amit a következő parancs segítségével egyszerűen elvégezhetünk: Set-OrganizationConfig -MapiHTTPEnabled $true

Ha a parancs sikeresen lefutott, akkor készen is vagyunk. De csak részben. Ezen a ponton a MAPIHTTP képes kliensek az AutoDiscover válaszban visszakapják a MAPIHTTP beállításokat. Ezt egyszerűen ellenőrizhetjük a Test E-mail AutoConfiguration futtatásával:

A többi beállítás mellett, a kliens megkapja a MAPIHTTP elérési utat. Abból is rögtön kettőt, egyet a postaláda eléréséhez (MailStore) és egyet a címjegyzék eléréséhez (Address book), ami az NSPI végpont. A fenti Autodiscover válaszban jól látszik az, hogy a szerver neve az Exchange kiszolgálóm belső FQDN címe és a külső, Internetre publikált nevét nem tartalmazza a válasz. Ennek az oka az, hogy mint bármelyik másik virtual directory, a MAPI virtual directory is rendelkezik egy externalURL és egy internalURL tulajdonsággal. Az externalURL alapértelmezésben nincs kitöltve:

A Set-MAPIVirtualDirectory cmdlet segítségével megadhatjuk a külső elérési nevet. Jelenleg a parancs futtatásakor meg kell adni az IISAuthenticationMethod értékét is:

Ha most újra futtatod a Test E-mail AutoConfiguration-t akkor azt várhatod, hogy ott lesz a külső és a belső elérési pont is. Azonban nem ez fog történni ez szinte biztos. Azért nem, mert az AutoDiscover alkalmazásnak szerver oldalon van egy gyorsítótára (cache), amibe az Exchange beállításokat letárolja. Így ha valamilyen értéket módosítasz, akkor arra az AutoDiscover nem fog azonnal reagálni és még a régi beállítások alapján fog válaszolni. A cache törlésének a legegyszerűbb módja az, ha újraindítod az MSExchangeAutoDiscoverAppPool -t (ne rémülj meg, ha leállítod, utána 1-2 mp-ig hiába is nyomod a Start gombot, csak hibát kapsz, hogy nem tud elindulni. Várj nyugodtan pár mp-et. Természetesen ezidő alatt a szervered az AutoDiscover kéréseket nem szolgálja ki):

Ha az újraindítás megtörtént, akkor a Test E-mail AutoConfiguration segítségével a teszteléskor azt fogod látni, hogy a külső és belső elérési pontokat egyaránt válaszként visszaküldi az AutoDiscover:

Hurrá, ezzel már majdnem készen is vagyunk. Már csak egy pont van, amire gondolni kell. Az pedig a külső kapcsolódás esetén a tűzfal. Általában korlátozott az, hogy milyen elérési utra érkező kéréseket engedünk be az Exchange kiszolgálóhoz. A MAPIHTTP protokoll esetében a tűzfalon az RPC over HTTP publikációs szabályunkat ki kell egészíteni úgy, hogy a /mapi virtual directory-t is engedélyezzük. TMG esetében egyszerűen adjuk hozzá a /mapi/* elérési utat a PATH-hoz:

Ezzel az új protokollt sikeresen engedélyeztük, azt konfiguráltuk. Ha átgondoljuk, akkor a következőket tettük:

1. Engedélyeztük Organization szinten a protokollt
2. Beállítottuk a külső elérési pontot a MAPI virtuális directory-n, valamint az azonosítást
3. Engedélyeztük a tűzfalon a külső hozzáférést

Az 1-es és 2-es lépéseket azonban nem jó sorrendben hajtottuk végre. :) Nagyobb tétben mernék fogadni, hogy az ügyfelek is ebben a sorrendben fogják elvégezni. De mi ezzel a baj? Nagy baj nincs de nem szép. Ha Org szinten engedélyezzük a protkolt úgy, hogy még nem állítottuk be a szükséges külső és belső URL értékeket és azonosítási módszereket, akkor könnyen előfordulhat az az eset, hogy az Outlook kliensek már megkapják a nem végleges beállításokat és az alapján próbálnak meg csatlakozni a szerverhez. Ez nem fog mindig és minden helyzetben problémát okozni, de lássuk be, hogy akár okozhat is kapcsolódási problémát. Ezért aztán a helyes sorrend az, hogy előbb beállítjuk a külső és belső URL értékeket, az azonosítási módszert és csak utána engedélyezzük Org szinten a protkoll használatát. Halmozottan igaz ez akkor, ha egynél több szerverünk van.

Mi fog történni az engedélyezés után?

Outlook 2013 SP1 esetén az Outlook szólni fog, hogy indítsuk újra az Outlook-t mert olyan változtatást végzett a Rendszergazda, hogy csak na. :)

Ezt a kliens akkor fogja feldobni, ha már megkapta az AutoDiscover-től az új beállításokat. Rendszeres időközönként (alapértelmezésben 2 óra) az Outlook kliens érdeklődik, hogy van-e új konfiguráció. Ha van, akkor azt alkalmazza. Nos, ha megkapja a MAPIHTTP beállításokat és azt alkalmazza, akkor szól, hogy indítsuk újra. Tudom-tudom, már megígértük, hogy többet nem lesz ilyen...

Az újraindítást követően néhány apróság tűnhet fel:

• A szerver neve megváltozott és látható, hogy a /mapi/ elérési útra mennek a kérésék. A használt protokoll pedig HTTP.
• Ha az Outlook profil beállításait közelebbről megnézzük, akkor észrevehetjük azt, hogy az egész Outlook Anywhere beállítási panel eltűnt. Ne is keressük többé. Viszlát. :)
  
• 
  

Az Outlook 2013 SP1 előtti kliensek a szolgáltatás engedélyezéséből nem tapasztalnak semmit. Ennek az az oka, hogy az Autodiscover kliens jelzi azt a szerver felé, hogy érti a MAPIHTTP-t. Az AutoDiscover szerver oldali komponens ezt értelmezi és csak a MAPIHTTP képes klienseknek adja vissza az AutoDiscover válaszban a MAPIHTTP beállításokat. Így aztán azok a kliensek amik nem értik ezt a protkollt, nem is kérik ezt a beállítást. Tehát nincs hatással a nem kompatibilis kliensekre a beállítás. Hosszú együttélési időre kell berendezkednünk de az új időszámítás ezzel elindul.