MAPI HTTP

  • Article

Egy új protokollal gazdagodunk az Exchange Server 2013 SP1-ben. A részleteket lásd ebben az írásban.

Exchange Server 2013 esetében az Outlook kliens csak az úgynevezett Outlook Anywhere protokollon keresztül képes csatlakozni a szerverhez. Az Outlook Anywhere korábbi neve az RPC over HTTP, ami technikailag jobban kifejezi azt, hogy valójában mirol is van szó.

Az RPC over HTTP kapcsolódás során van egy RPC over HTTP kliens és szerver. Ez a protokoll alapvetoen nem Exchange szerver exkluzív protokoll. A Windows NT 4.0 Optiona Pack-al jelent meg eloször a szerver oldali komponens. Ez egy RPC proxy komponens, ami egy virtual directory valójában az IIS-ben. Ez fogadja a bejövo HTTP kéréseket és az rpcproxy.dll az RPC forgalmat kibontja és továbbítja a szerver RPC rétegén keresztül az RPC üzenet címzettjének. Ez egy teljesen általános proxy protokoll, amit bárki más is implementálhatott volna. Az Exchange és Outlook csapat a lehetoségre lecsapott és implementálta. Kevés más implementációról tudok, ilyen szélesköru megoldásról nem.

Az Outlook és Exchange szerver esetében az RPC over HTTP egészen új megoldás volt. Végre nehézkes VPN kapcsolat nélkül is teljes Outlook hozzáférést tudtunk és tudunk ma is biztosítani a felhasználóknak. Míg a 2000-es évek elején ez komoly gondot okozott - elérhetové tegye Internetol a teljes Outlook funkcionalitást - a helyi rendszerek üzemeltetojének, addig napjainkban a felho alapú technológiai megoldások esetében a felho üzemeltetoknek jelent komoly kihívást a teljes Outlook szolgáltatás biztosítása. De annyira nem, hiszen itt van az RPC over HTTP.

Az RPC over HTTP esetében az Outlook az RPC kliens. Az Exchange kiszolgáló pedig egy RPC szerver. Az Outlook az Exchange szerverrel -hogy még komplikáltabb legyen a kép-, valójában MAPI protokollon keresztül kommunikál. Ebben a környezetben tehát az RPC kliens valójában egy MAPI kliens, az RPC szerver pedig egy MAPI szerver. A feladat az, hogy a MAPI klienstol a MAPI szerverhez eljusson a kérés és vissza a válasz, mindez biztonságosan az Interneten keresztül. Ez ma a következo módon muködik:

  • A MAPI kliens elkészíti a MAPI kérést
  • A MAPI kérést egy RPC csomagba tesszük
  • Az RPC csomagot egy HTTP csomagba helyezzük és így küldjük át az RPC Proxy szervernek, ami az Exchange esetében a CAS vagy Front-End verziótól függoen
  • Az Exchange szerveren az IIS fogadja a kérést
  • Az rpcproxy.dll feldolgozza a kérést
  • Továbbítjuk az RPC csomagot a Mailbox vagy Back-End szervernek
  • Az RPC csomagból kiszedjük a MAPI kérést és azt feldolgozza az Exchange kód

Nagyvonalakban kb. ez történik. Persze a http transzport során még az SSL encrypt/decrypt megtörténik.

A megoldás kreatív, jól muködik. Azonban túl sok a komponens amit használunk. Ebben történik most lényegi és egyben architektúrális változás. Elkészült egy új protokoll aminek a neve a MAPI HTTP. Ennek a protokollnak a célja az, hogy a MAPI kliens közvetlenül HTTP-n keresztül legyen képes a MAPI szerverrel kommunikálni. Ezzel az RPC réteget szerver és kliens oldalon egyaránt kihagyva.

A szerver oldalon az új protokoll az Exchange Server 2013 SP1 berzióval jelenik meg. Az engedélyezheto és tiltható lesz Exchange organizáció szinten. Implementálva két új IIS virtuális directory formában lesz. Kliens oldalon a támogatás eloször az Outlook 2013 SP1 verzióban lesz az új megoldás.

Az Outlook Anywhere (RPC over HTTP) továbbra is változatlan módon muködik SP1 után is. Az új protokollt ismero kliens a Autodiscover kérésben jelzi azt, hogy ismeri a MAPI HTTP-t. Ezt a kérést érto Exchange szerver verzió az Autodiscover válaszában visszaküldi a MAPI HTTP beállításokat. Ebbol látható, hogy a régi kliens-új szerver és az új szerver-régi kliens verzió muködése nem okoz problémát.

Az új protokollról bovebb információ: