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.
Comments
- Anonymous
January 01, 2003
Hello!
Sajnos nem tudok ilyen komplett leírásról. Arról nem is beszélve, hogy ez azért sokszor változik is. Az oszlopok is "jönnek-mennek" és a tartalmuk sem mindig konzisztens.
Ha konkrét kérdés van, akkor igyekszem megválaszolni.
-Zoli - Anonymous
January 01, 2003
Richard: engedd, hogy segítsek. Mielőtt veszem a billentyűzetet és mindent lekarmolok erről az ablakról (felkérés elfogadva), addig is tedd fel a kérdésed, hogy lássam, mi nem tiszta. Az információk és az oszlopok jelentős része viszonylag magáért beszél de lehet, hogy igazad van és ezt nem kezeljük helyén.
Köszönöm a visszajelzést és várom a konkrét kérdést. :)
-Zoli - Anonymous
January 01, 2003
Elrontottam a sorrendet és lusta voltam átírni. ;) - Anonymous
January 01, 2003
OK, elkezdtem összeszedni. Kis türelem. - Anonymous
January 01, 2003
Richard: dobj nekem egy emailt kérlek. Jobb oldalon "Email blog author". Szeretném a publikálás előtt megmutatni, hogy ez segít-e neked kicsit jobban megérteni. Köszi. - Anonymous
March 14, 2014
Hello,
akkor miért nem írtad a jó sorrendben rögtön? :)
Vagy így lehetett jól elmagyarázni a dolgot? :) - Anonymous
March 21, 2014
Kicsit offtopic kérdés: van bárhol a széles interneten a product team-től kiveséző részletességű article a "Connection status" ablak tartalmáról és értelmezéséről? Feltúrtam már az egész "Exchange Team" és az "Outlook Global Technical Support Team" blog-ot, hátha akad valami, de semmi, 0 találat. Mindenhol az interneten csak hivatkoznak erre a CTRL+jobb klikk-es trükkre, de onnantól megáll az ismertető, mintha teljesen magától értetődő lenne az a rengeteg információ, és a működés ami abban az ablakban megfigyelhető. - Anonymous
March 24, 2014
Köszi a választ, a semminél ez is több. Azt nem tudom elfogadni (nem feléd, hanem a munkáltatód felé), hogy olyan indokkal miszerint "hát ez izé.. szóval sűrűn változik" nem dokumentálunk róla semmit. De tényleg semmit! Az összes KB article ami Outlook troubleshooting-ről szól, eljut odáig h. CTRL+jobbklikk, nyissad megfele a Connection status ablakot, onnantól csinálj amit akarsz! End of article, lehet ratingelni mennyire volt helpful (semennyire). Se egy reference a cikk alján, se egy best practice, semmi!
Dúrva fejszámolással ha mondjuk pont Outlook 2003-ban vezették be ezt az ablakot (írásos nyoma van h. abban MÁR benne vanik, hogy ennél hamarabb már volt-e, nem tudom) az csak cirka 11 év(!) időhúzás. Szóval se 2003-hoz, se 2007-hez, se 2010-hez, se 2013-hoz nem csinálták meg a házifeladatot. Egyszer elmegy ez a kifogás, 2x talán, 3x már nem veszi be az ember gyomra.
Konkrétumot nincs értelme kérdezni. Mert pl. milyen oszlopok kell látszanak Outlook 2010 mai napon legfrissebbre peccselt verzióval Exchange 2010 szerver esetén? Melyik oszlop mit jelent, és milyen lehetséges értékeket vehet fel? Nem kell itt most végigmenni a történelmen, és minden változást időrendben verzió forkoltan kitáblázatolni. Legyen egy Exchange 2010 + Outlook 2010 mai napi peccselt állapotra, meg egy a Exchange 2013 + Outlook 2013 állapotra, és csókolom. Ezzel már boldog lenne az Exchange ITPRO világ 90%-a. Azzal takarózni, hogy túl nagy munka lenne egy perfekten precíz cikket írni, ezért inkább nem írunk semmit se, ez gagyi kifogás.
Az Exchange master kurzuson se beszéltek erről? Akkor egy exchange masternek sincs róla fogalma mik kerülhetnek ide? Senkinek nem jutott eszébe a community-ügyileg aktívabbak közül bloggolni erről 1 jópofa kis táblázatot? Sajnos az evangelisták is előkerülnek, ha már a kedvenc gyártójuk tojik a témára 10+ éve. - Anonymous
March 24, 2014
Leköteleznél! Az article-ért a számlát küldd Redmond-ba..
Szóval amiket perpill én látod Outlook 2010 + Exchange 2010 kombóban:
CID: ez vmi connection ID? Számít h. mi a sorszám, és hogy hány darab ilyen sor van összesen? Mikor van kevés, mikor van sok ilyen sor?
SMTP address: ez gondolom az aktuális Outlook profilt azonosítja be. De mikor és hány féle típusú dolog lehet itt?
Proxy server: gondolom RPC over HTTPS esetén látszik itt bármilyen server FQND RPC over TCPIP esetén üres
Server name: a CAS server FQDN, ez talán az egyértelmű (kivéve ha itt is van vmi csavar, pl. CAS array vs. konkrétan csatlakozott szerver FQDN különbségére tudok gondolni)
Status: Established a jó, a többi csak tranziensen szabadna ielőfordulnia?
Authn: na ez lenne érdekes, h. Nego, NTLM, Basic stb. között mikor mi látszik, mi befolyásolja (Exchange virtualdirectory / PS állítgatás ereménye?)
Encrypt: Yes --> RPC encryption, SSL --> RPC over HTTP over SSL esetén? Egyéb más lehetőség is van?
RPCPort: itt milyen portok látszanak (kliens v. szerver?) Egy shared port lehet több connection-re v. mindegyikre külön kell?
Type: directory, mail. Ezt a 2-t látom. Ezek pontosan mit jelentenek, van még ezen kívül más típus is?
Req/fail: hány request-ből hány fail-elt el? Baj ha van failed, vagy az ilyen "by design" hogy néha failed lesz? Hol a határ jó arány és már feltűnően rossz arány között?
Avg response: gondolom msec delay kérés --> válasz késleltetés. Tényleg azt jelenti?
Avg proc: na erről semmi ötletem nincs mi lehet
Sess type: látok Foregrond, Background és Cache típust. Na ezek mit jelentenek? Hány féle típus van? Adott connection type meghatározza a session type-ot?
Interface: melyik NIC-en él perpill a connection...?
Conn: RPC over TCPIP / RPC over HTTP közül valamelyik?
Notif: async?? ötletem sincs ez mi
RPC: Async...? Szintén ötlet sincs..
Version: valaminek a verziója. Na de pontosan minek? DC/GC esetén by design üres?
Hirtelen csak ennyi kérdés :). Azért egy tooltip nem ártana minden oszlop fölé, mert így nagyon puritán. Lehet hogy sok sor magyarázatát annyival el lehetne intézni, hogy ha nem érted mit jelent az azért van mert nem érted az Exchange-t. Ez valószínű igaz is, ebben az esetben 1-2 releváns Exchange blog article URL referenciának odabiggyesztve more than welcome!