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. Bovebb információt a protokollról itt találhatsz: https://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 belole. 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 egyszeruen.
Mit kaptunk az SP1-el?
Az SP1 szerver oldali telepítésével létrejött egy Organization szintu új beállítási lehetoség. Ez az új Organization szintu 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 szintu 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 mukö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 egyszeru feladat. Az Organization szintu beállítás értékét false-ról, true-ra kell állítanunk, amit a következo parancs segítségével egyszeruen 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 egyszeruen ellenorizhetjü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 kettot, 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 belso FQDN címe és a külso, 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ülso 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ülso és a belso 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 legegyszerubb 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 ezido 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ülso és belso 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ülso kapcsolódás esetén a tuzfal. Általában korlátozott az, hogy milyen elérési utra érkezo kéréseket engedünk be az Exchange kiszolgálóhoz. A MAPIHTTP protokoll esetében a tuzfalon 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 egyszeruen 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övetkezoket tettük:
- Engedélyeztük Organization szinten a protokollt
- Beállítottuk a külso elérési pontot a MAPI virtuális directory-n, valamint az azonosítást
- Engedélyeztük a tuzfalon a külso 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ülso és belso URL értékeket és azonosítási módszereket, akkor könnyen elofordulhat 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 elobb beállítjuk a külso és belso 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-tol az új beállításokat. Rendszeres idoközönként (alapértelmezésben 2 óra) az Outlook kliens érdeklodik, 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övetoen néhány apróság tunhet 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özelebbrol megnézzük, akkor észrevehetjük azt, hogy az egész Outlook Anywhere beállítási panel eltunt. Ne is keressük többé. Viszlát. :)
Az Outlook 2013 SP1 elotti kliensek a szolgáltatás engedélyezésébol 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 idore kell berendezkednünk de az új idoszámítás ezzel elindul.