MAPI/HTTP

MAPI over HTTP ist nicht mit RPC/HTTP zu verwechseln. Schon viele Jahre kann ein Outlook über HTTP den RPC-Zugriff auf den Exchange Server selbst in HTTP-Anfragen tunneln. Dazu ist aber ein RPC-Proxy auf der Serverseite erforderlich, der die HTTP-Pakete wieder auspackt und per RPC an den Exchange Server weiter gibt. Seit Exchange 2013SP1 und Outlook 2013SP1 können die beiden Systeme aber direkt MAPI over HTTP nutzen und damit den RPC-Proxy umgehen.

MAPI over HTTP erfordert mindestens Exchange 2013 SP1 Server und Outlook 2010 (April 2015 Hotfix) oder höher.
Exchange 2010 unterstützt kein MAPI/HTTP.

Achten Sie auf die Performance ihrer Clients. Mitte 2017 durfte ich einen Support Call begleiten bei dem letztlich die OnPremise-Umgebung auf RPC/HTTP zurückgestellt wurde. MAPI/HTTP war einfach zu langsam, was beim Online-Zugriff auf Stellvertreter deutlich wurde. Siehe dazu auch Exchange Latenz

Warum ?

Es gibt gleich mehrere Gründe, die für eine direkte Nutzung von HTTP sprechen:

  • Problem mit RPC
    Wenn der Exchange Store die Postfachdaten hält und der Client per RPC kommt, dann sind das ganz viele Ports und einen "Übersetzer". RPC nutzt 135TCP und zwei weitere High-Ports, die meist dynamisch sind. Zudem muss der RPCProxy die Daten des Clients annehmen und zum richtigen Backend weiter leiten. Das skaliert nicht ausreichend für Office 365 und auch On-Premise ist einfacher einfach besser.
  • RPC/HTTP doppelt verpackt
    Der erste Schritt weg von MAPI war die Kapselung der Pakete in HTTPS. So konnte ein Zugriff aus dem Internet seit Exchange 2003 allein über HTTPS (Port 443/TCP) erfolgen. Niemand will RPC direkt aus dem Internet erreichbar machen. Aber Microsoft hat hier einen sanften Weg vorgesehen und packt die MAPI/RPC-Pakete erst mal in HTTPS ein und auf dem Server hat der RPC-Proxy die Daten dann wieder auf die Leitung gesetzt. primäres Ziel war hier also der HTTPS-Tunnel und weniger eine Optimierung.
  • Der Server kann anhand der Session-Kennung die bestehende Sitzung bei sich weiter nutzen.
    Wenn die Verbindung aber nun native per HTTPS erfolgt, dann entfällt eine weitere Verpackung. Das entlastet etwas den Bedarf an Bandbreite aber vor allem kann es auf dem Backend Server die CPU-Last reduzieren. Das macht sich wieder in Office 365 positiv bemerkbar und auch On-Premise profitiert davon.
  • EWS und ActiveSync machen schon HTTP
    MAPI/HTTP ist nicht der einzige Dienst, der nun auch HTTP nutzt. Autodiscover und insbesondere die EWS-Zugriffe sind alle per Definition über HTTP/HTTPS erfolgt und werden auch nicht durch MAPI/HTTP ersetzt.
  • Long Running HTTP-Request
    Immer mehr Geräte mit Windows 8.1 sind Tablets die auch einen "Schlafmodus" unterstützen. Eine RPC-Verbindung ist vom Timing kritischer, so dass nach jedem Aufwecken die Verbindung erst aufwändig (und damit teuer) wieder hergestellt werden muss. MAPI/HTTP kann aber einen HTTP-Request lange "ausstehen" lassen und einfach erneuern. Das reduziert Datenmenge, Energiebedarf und Bandbreite.

Insofern ist wer Weg nur logisch, dass Microsoft den alten RPC-basierten Weg mit Exchange 2016 nicht mehr unterstützen und auf MAPI/HTTP setzen. Der Weg über RPC/HTTP ist aber mit Exchangen 2016 noch möglich.

Wer mit wem per HTTP

Nicht jedes Outlook kann mit jedem Exchange Server sich per MAPI-HTTP verbinden. Auf der Seite "MAPI HTTP" (http://technet.microsoft.com/en-us/library/dn635177(v=exchg.150).aspx) ist eine schöne Tabelle, die aber zumindest im Okt 2015 noch nicht mit Exchange 2016 gerechnet hat. Die Möglichkeit sich per MAPI/TCP zu verbinden, habe ich nicht weiter gesondert aufgeführt, da diese Option bald nicht mehr genutzt werden kann:

  Exchange 2016 Exchange 2013 Exchange 2010 SP3 Exchange 2007 Exchange 2003
Outlook 2016 

MAPI/HTTP

MAPI/HTTP

 RPC/HTTP

Keine Verbindung. zu Alt

Keine Verbindung. zu Alt

Outlook 2013 SP1 

MAPI/HTTP

MAPI/HTTP
 RPC/HTTP
MAPI/RPC

 RPC/HTTP
MAPI/RPC

 RPC/HTTP
MAPI/RPC

Keine Verbindung. zu Alt

Outlook 2010

MAPI/HTTP mit folgenden Updates

KB2878264 (Outlook 2010 Update Jan 2015)
KB2956191 (Office 2010 Update April 2015

MAPI/HTTP mit folgenden Updates
KB2878264 (Outlook 2010 Update Jan 2015)
KB2956191 (Office 2010 Update April 2015

 RPC/HTTP oder RPC

 RPC/HTTP
MAPI/RPC

 RPC/HTTP
MAPI/RPC

Outlook 2007

Keine Verbindung möglich

 RPC/HTTP
MAPI/RPC

 RPC/HTTP
MAPI/RPC

 RPC/HTTP
MAPI/RPC

 RPC/HTTP
MAPI/RPC

Bemerkung

Aktiviert per Default MAPI/HTTP außer bei einer Migration von 2013 ohne bereits aktiviertes MAPI/HTTP

Erste Exchange-Version die MAPI/HTTP unterstützt aber RPC/TCP nicht mehr anbietet

Unterstützt kein MAPI/HTTP

Unterstützt kein MAPI/HTTP

Unterstützt kein MAPI/HTTP
Exchange 2003 war die erste Version, die RPC/HTTP unterstützt hat

Es gibt also  nur eine kleine Teilmenge von Clients und Servern, die MAPI/HTTP unterstützen. Da aber Outlook 2010 als auch Exchange 2010 schon ziemlich alt sind, wird dieser Bereich aber immer weniger bedeutsam.

MAPI/HTTP Vorarbeiten

Microsoft hat klar gemacht, dass MAPI/HTP das neue Protokoll für Outlook und Exchange wird. Es ist aber bis Exchange 2013 nicht per Default aktiv, sondern muss von Administrator erst aktiviert werden. Dies erfolgt in Exchange 2013 Organisationsweit. Vorher sollten Sie aber noch ein paar Dinge prüfen.

  • Aktuelle Outlook Versionen (2010/2013/2016)
    MAPI/HTTP wird nicht von Outlook 2007 und früher unterstützt und auch Outlok2010 braucht zumindest die Updates von April 2015. Sollten Sie ältere Versionen haben, dann können diese weiterhin über RPC/HTTP oder MAPI/TCP mit dem Exchange 2013 und früher kommunizieren.
  • Exchange 2013 Mindestvoraussetzungen
    Exchange 2016 unterstützt von Hause aus MAPI/HTTP, wenn gleich bei bestimmten Migrationswegen es nicht aktiviert wird. Exchange 2013 benötigt mindestens SP1 auf allen CAS und MB-Rollen.
  • NET-Framework 4.5.2
    Dazu gehört, dass alle Server auch das .NET-Framework 4.5.2 oder höher haben müssen. Das können Sie per REGEDIT einfach überprüfen:

    Siehe auch "Gewusst wie: Bestimmen der installierten .NET Framework-Versionen ( https://msdn.microsoft.com/de-de/library/hh925568(v=vs.110).aspx#clr_b)
  • COMPLUS_DisableRetStructPinning
    Diese Einstellung ist eher ungewöhnlich aber auf Exchange 2013SP1 muss eine Umgebungsvariable im System gesetzt werden, damit MAPI/HTTP funktioniert. Dies ist nicht mehr erforderlich, wenn .NET 4.5.2 installiert wurde
    2995145 Performance issues or delays when you connect to Exchange Server 2013 that is running in Windows Server

    Öffnen Sie dazu die erweiterten Systemeigenschaften und addieren Sie hier die Variable
  • Virtuelles Verzeichnis
    Mit MAPI/HTTP gibt es noch ein weiteres virtuelles Verzeichnis "/MAPI" im IIS. Dieses Verzeichnis muss natürlich vergleichbar zu OWA und ActiveSync entsprechend konfiguriert werden:. Hier die verkürzte Ausgabe einer Standardinstallation. Sie sehen hier, dass Sie zumindest die ExternalURL setzen sollten. Stellen Sie dabei natürlich sicher, dass die Zertifikate auch diesen Namen enthalten.
Get-MapiVirtualDirectory

RunspaceId                      : 0f8ba6e1-7389-4682-bfac-9fc37405525f
IISAuthenticationMethods        : {Ntlm, Negotiate}
MetabasePath                    : IIS://EX2013.msxfaq.net/W3SVC/1/ROOT/mapi
Path                            : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\mapi
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
AdminDisplayVersion             : Version 15.0 (Build 1044.25)
Server                          : EX2013
InternalUrl                     : https://EX2013.msxfaq.net/mapi
InternalAuthenticationMethods   : {Ntlm, Negotiate}
ExternalUrl                     :
ExternalAuthenticationMethods   : {}
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
Name                            : mapi (Default Web Site)
DistinguishedName               : CN=mapi (Default Web Site),CN=HTTP,CN=Protocols,CN=EX2013,CN=Servers,CN=Exchange Administrative Group
                                  (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=MSXFAQ,CN=Microsoft
                                  Exchange,CN=Services,CN=Configuration,DC=MSXFAQ,DC=de
Identity                        : EX2013\mapi (Default Web Site)
Guid                            : bf8f38d7-6ae2-4255-bbbd-4ccd84c5d165
ObjectCategory                  : msxfaq.net/Configuration/Schema/ms-Exch-Mapi-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchMapiVirtualDirectory}
Id                              : EX2013\mapi (Default Web Site)
OriginatingServer               : DC1002.msxfaq.net


Set-MapiVirtualDirectory `
   -Identity "EX2013\mapi (Default Web Site)" `
   -ExternalUrl "https://owa.msxfaq.net/mapi"
  • Reverse Proxy und Loadbalancer
    Wenn Sie einen Reverse-Proxy oder Loadbalancer einsetzen, der die URLs überwacht, dann sollten sie hier erst noch "/mapi/*" mit aktivieren.
  • Monitoring und Healthcheck
    Eine neue Funktion muss mit überwacht werden. Das geht am einfachsten mit einer HTTPS-Anfrage auf den "Healtcheck", der seit Exchange 2013 einen Check durch fremde Systeme erlaubt. Alternativ können Sie die Exchange Testfunktionen nutzen (Siehe MSXFAQ.DE:E2013:Heathcheck)
https://owa.<firmenname>.de/mapi/healthcheck.htm
Test-OutlookConnectivity `
   -RunFromServerId EX2013 `
   -ProbeIdentity OutlookMapihttpselftestprobe

Nach den Vorarbeiten "könnte" ihr Exchange Server vermutlich schon MAPI/HTTP anbieten aber er tut es noch nicht. dsa kommt im nächsten Schritt:

MAPI/HTTP global aktivieren/deaktivieren

Ob ein Anwender MAPI/HTTP nutzen kann kann individuell pro Benutzer gesteuert werden. Zusätzlich gibt es noch einen globalen Schalter, der MAPI/HTTP für all die Benutzer steuert, die keine explizite Vorgabe habe. Normalerweise ist MAPI/HTTP pro Benutzer weder erlaubt noch verboten. Mit der globalen Aktivierung werden also alle Mitarbeiter sofort für MAPI/HTTP aktiviert. Ob sie dies wollen, müssen Sie selbst entscheiden.

Bei größeren Umgebungen ist es vielleicht wünschenswert erst ein paar Testpiloten zu betreiben und mögliche Fehler und die Auswirkungen auf Loadbalancer, WAN-Optimierer etc. zu überprüfen. In diesem Fall sollten Sie MAPI/HTTP erst für alle Postfächer abschalten, ehe Sie es global aktivieren. Die globale Einstellung wird wie folgt gestuert:

# Auslesen der aktuellen Einstellng (ab Ex2013)
(Get-OrganizationConfig).mapihttpenabled # Aktivieren von MAPI/HTTP
Set-OrganizationConfig -mapihttpenabled:$true
# Deaktivieren von MAPI/HTTP
Set-OrganizationConfig -mapihttpenabled:$false

Die globalen Einstellungen werden aktiv, nachdem die Änderungen im AD repliziert wurde und der Autodiscover-Service seinen Cache verloren hat. Das kann durch einen Restart des entsprechenden IISApplicationPool forciert werden.

Steuerung pro Benutzer

Seit Exchange 2016 ist es möglich, diese Einstellung pro Mailbox zu überschreiben. Über das Commandlet "Set-CASMailbox" und den Parameter "MapiHttpEnabled" können Sie MAPI/HTTP pro Benutzer abschalten aber auch einschalten.

Benutzern Sie dazu nicht den Parameter "MAPIBlockOutlookExternalConnectivity" Die Steuerung von MAPI per CAS-Mailbox unterscheidet nicht nach den Zugriffsprotokollen MAPI/tcp, MAPI/http oder RPC/http.
Siehe auch https://ingogegenwarth.wordpress.com/2017/01/23/why-using-mapiblockoutlookexternalconnectivity-is-a-bad-idea/ 

Über den Parameter "MapiHttpEnabled" können Sie pro Postfach vom Benutzer abweichende Einstellungen vornehmen. Dsa ist also auch der Hebel, wenn Sie MAPI/HTTp zwar zulassen aber erst einmal mit ien paar Piloten starten wollen. Ehe Sie MAPI/HTTP global aktivieren, sollten Sie dann bei allen Postfächer MAPI/HTTP deaktivieren.

Get-CASMailbox `
   | Set-CASMailbox `
         -MapiHttpEnabled:$False

Sie brauchen dann nur ein Kriterium ihr Piloten zu identifizieren und dort den Parameter wieder auf "$true" zu setzen.

#MAPI/HTTP fuer eine Mailbox aktivieren
Set-CASMailbox -identity <alias> -MapiHttpEnabled:$True

MAPI/HTTP fuer eine Mailbox auf globale Defaults umstellen Set-CASMailbox -identity <alias> -MapiHttpEnabled:$null

Wer mag, kann das auch über eine Gruppenmitgliedschaften per Skript steuern. Siehe auch GRP2CAS oder Group2ExInternet

Über Get-CASMailbox können Sie natürlich in Exchange 2016 dann auch eine Liste mit den Einstellungen der Benutzer erzeugen lassen.

Steuerung nach Internet/Extern

Die Steuerung mittels Set-CASMailbox kontrolliert generell, ob der Benutzer MAPI/Http nutzen darf oder nicht. Er erlaubt aber keine Kontrolle über den Standort des Benutzers. Eine Unterscheidung nach intern oder extern findet nicht statt. Sie können als Administrator damit nicht kontrollieren, dass Anwender von intern MAPI/Http dürfen aber aus dem Internet nicht. Das ist durchaus in Firmen ein Thema, wenn Benutzer im internen LAN oder über VPN nativ mit Exchange kommunizieren dürfen. Hier kann über Gruppenrichtlinien, NAP (Network Access Protektion), 8021.x etc. sichergestellt werden, dass es ein vertrauenswürdiger Client ist. Ist der Zugriff aus dem Internet erlaubt, könnten Anwender auch mit "fremden Clients" arbeiten, die nicht den Sicherheitsvorgaben entsprechend. Diese Herausforderung gab es auch schon mit RPC/HTTP.

Wenn Anwender keinen Zugang aus dem Internet über MAPI/HTTP haben sollten, dann sollten Sie einen Reverse-Proxy mit Preauthentication einsetzen, der bestimmte URLs nur für ausgewählte Benutzer oder Benutzergruppen erreichbar macht.

Steuerung auf dem Client

Aber auch auf dem Windows Client können Sie Outlook anweisen, bestimmte Protokolle nicht zu nutzen. Technisch steuern Sie damit, ob Outlook bei der Autodiscover-Anfrage dem Server mitgibt, ob er MAPI/http kann. Aus Gründen den Kompatibilität bietet der Exchange Server in der Autodiscover-Antwort nur dann auch MAPI/HTTP an, wenn der Client bei der Anfrage mitteilt, dass er es kann. So werden alte Clients nicht gestört. Der folgende Eintrag in der Registrierung auf dem Client steuert, ob Outlook eine Verbindung per MAPI/HTTP versucht.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Exchange]
"MapiHttpDisabled"=dword:00000001

Oder per Kommandozeile:

REM MAPI/http verhindern
REG.exe Add HKCU\Software\Microsoft\Exchange /V MapiHttpDisabled /T  REG_DWORD /D 0x1 /F

REM MAPI/http erlauben
REG.exe Add HKCU\Software\Microsoft\Exchange /V MapiHttpDisabled /T  REG_DWORD /D 0x1 /F

So können Sie z.B. für die Fehlersuche den Weg über MAPI/HTTP temporär unterbinden.

Achtung mit Office 365. Ab Nov  2017 ist MAPI/HTTP das einzige Outlook Zugriffsprotokoll in Office 365. Wenn Sie auf dem Client dies unterbinden, können diese Clients nicht mehr Office 365 nutzen.
RPC over HTTP deprecated in Office 365 on October 31, 2017  https://support.microsoft.com/en-us/help/3201590/rpc-over-http-deprecated-in-office-365-on-october-31,-2017

Protokollwechsel

Ein Outlook Client wechselt nur dann den Zugang, wenn er bisherige im Profil konfigurierte Weg nicht mehr funktioniert. Outlook macht dann eine neue Autodiscover-Anfrage und erhält so einen neuen Weg. Wenn Sie also nachträglich MAPI/http freischalten, dann werden die Clients dennoch erst mal noch weiter auf RPC/HTTP arbeiten.

Das stimmt so aber nicht ganz, denn beim Zugriff auf Stellvertreter wird recht häufig eine AUtodiscover-Frage erfolgen und auch wenn ein Client mal Netzwerkverbindungen verliert oder Outlook warum auch immer glaubt nicht mehr an den Server zu kommen, dann startet Outlook eine Anfrage. Insofern können wir davon ausgehen, dass Client nach einiger Zeit doch schon MAPI/HTTP benutzen. Für eine quantitative Abfrage der Nutzungszahlen bieten sich die Performance Counter der IIS-Application Pools und eine Auswertung der IISLogs und CAS-Proxy-Lost an.

Wenn Sie nachträglich auf dem Server MAPI/HTTP verbieten, dann bekommt der Client keine Verbindung mehr und auf auf eine neue Autodiscover-Anfrage wird MAPI/HTTP nicht mehr angeboten. Stattdessen wird dem Client eben RPC/HTTP angeboten.

Wenn Sie aber MAPI/HTTP auf dem Server und Client erlauben und ein Zwischensystem "Reverse Proxy mit URL-Filterung" das virtuelle Verzeichnis /MAPI nicht durchlässt, dann hat ein Outlook Client ein Problem, der per Autodiscover mitteilt, dass er MAPI/http könnte. Wenn diese Anfrage so den Server unverändert erreicht, bekommt per Autodisover-Antwort die MAPI/http-Zugänge aber keine RPC/http FallBack-Informationen.

Wenn der Protokollwechsel gelingt, dann konfiguriert Outlook quasi "on the fly" auch das Profil um. Ein Neustart sollte nicht stattfinden und maximal eine kurze "Disconnect-"Zeit". Allerdings werden verschiedene Änderungen im Profil erst beim Beenden von Outlook auch zurück geschrieben. Die Anzeige der aktuellenm Konfiguration ist bis dahin niciht immer korrekt. Wer auf der sicheren Seite stehen will, sollte Outlook einmal neu starten.

Exchange 2016 und MAPI/HTTP bei Migrationen

Exchange 2016 nutzt MAPI/HTTP als Defaults und aktiviert die Einstellung automatisch, es sei denn es gibt Exchange 2013 Server in der Organisation und MAPI/HTTP ist nicht aktiv. Bei Exchange 2013 war MAPI/HTTP per Default nicht aktiv und wenn ein Admin das nicht aktiviert hat, dann wird es auch mit Exchange 2016 nicht per Default aktiviert. In allen anderen Fällen ist MAPI/HTTP aktiv.

MAPI/HTTP und Authentifizierung

Clients müssen sich natürlich auch beim Zugriff per MAPI/HTTP authentifizieren. Per Default ist bei Exchange 2016 folgendes eingestellt:

[PS] C:\>Get-MapiVirtualDirectory | fl *

PSShowComputerName              : False
IISAuthenticationMethods        : {Ntlm, OAuth, Negotiate}
Path                            : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\mapi
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
AdminDisplayVersion             : Version 15.1 (Build 396.30)
Server                          : NAWEX16
InternalUrl                     : https://ex2016.msxfaq.de/mapi
InternalAuthenticationMethods   : {Ntlm, OAuth, Negotiate}
ExternalUrl                     : https://mapi.msxfaq.de/mapi
ExternalAuthenticationMethods   : {Ntlm, OAuth, Negotiate}
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
Name                            : mapi (Default Web Site)
DistinguishedName               : CN=mapi (Default Web Site),CN=HTTP,CN=Protocols,CN=EX2016,CN=Servers,CN=Exchange
                                  (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=MSXFAQ,CN=Microsoft
                                  Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de
Identity                        : NAWEX16\mapi (Default Web Site)
ObjectCategory                  : msxfaq.de/Configuration/Schema/ms-Exch-Mapi-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchMapiVirtualDirectory}
WhenChanged                     : 15.12.2015 12:53:12
WhenCreated                     : 15.12.2015 12:42:06
WhenChangedUTC                  : 15.12.2015 11:53:12
WhenCreatedUTC                  : 15.12.2015 11:42:06
OrganizationId                  :
Id                              : EX2016\mapi (Default Web Site)
OriginatingServer               : DC001.msxfaq.de
IsValid                         : True
ObjectState                     : Changed

Es scheint aber ab und an zu passieren, dass die Authentifizierung entfernt wird. Ich habe das noch nicht beobachtet, aber wenn ihr Outlook Client immer nach Anmeldedaten fragt, dann lohnt sich ein Blick darauf.

IISLog mit MAP/HTTP

Da MAPI/HTTP über den IIS abgewickelt wird, ist das IISLog ein erster Anlaufpunkt. Hier ist wieder zu beachten, dass Exchange 2013 z.B. zwei Webseiten nutzt. Die CAS Rolle als Reverse Proxy gibt die Anfrage an die BackendRolle weiter.

 

Achtung: Wenn mit MAPI/HTTP nun viele Clients nicht mehr per MAPI/TCP arbeiten, dann nimmt die Größe der IISLogs stark zu. Da diese per Default auf C:\inetpub\logs\LogFiles liegen, kann die System-Partition schnell voll laufen

In den Logs sind aber die Zugriffe auf "/mapi" gut zu sehen Hier ein Auszug des Exchange Frontend beim Zugriff für das Health Monitoring. Zur Lesbarkeit wurden die Felder umgebrochen

2015-10-21 00:00:21 127.0.0.1 
  GET /mapi/emsmdb mailboxId=31a0cafc-4e7f-4333-9be0-88ad487a0518@msxfaq.net
                   &CorrelationID=<empty>;
                   &ClientId=9LCBAHO0D0I9OAOYVQIW
                   &cafeReqId=cd59f297-10c4-4124-9cb6-641a8502167e; 
      443 MSXFAQ\HealthMailboxe9bc3d7 127.0.0.1 AMProbe/Local/ClientAccess - 200 0 0 31
2015-10-21 00:00:21 fe80::53a:25c1:f8eb:7cfd%13 
  POST /mapi/emsmdb/ mailboxId=19810624-da69-4c2c-8b71-04c301d5951f@msxfaq.net
                   &CorrelationID=<empty>;
                   &ClientId=HDTPFNOMULHBZNNHMA
                   &ClientRequestInfo=R:1208932e-c748-4b08-8cf7-b0208e05501a:1;CI:d51b36c9-45df-4693-a351-165276e906ff:1;RT:Connect
                   &cafeReqId=ea837eb8-dd10-4a1b-90db-d9fb09602769;
       443 MSXFAQ\HealthMailboxdb73e5d 192.168.100.32 MapiHttpClient - 200 0 0 15
2015-10-21 00:00:21 fe80::53a:25c1:f8eb:7cfd%13 
  POST /mapi/emsmdb/ mailboxId=19810624-da69-4c2c-8b71-04c301d5951f@msxfaq.net
                   &CorrelationID=<empty>;
                   &ClientId=HDTPFNOMULHBZNNHMA
                   &ClientRequestInfo=R:1208932e-c748-4b08-8cf7-b0208e05501a:2;CI:d51b36c9-45df-4693-a351-165276e906ff:1;RT:Execute
                   &cafeReqId=01320657-680e-4bff-b40a-4cac63ecd947;
       443 MSXFAQ\HealthMailboxdb73e5d fe80::53a:25c1:f8eb:7cfd%13 MapiHttpClient - 200 0 0 93
2015-10-21 00:00:21 192.168.100.32 
  POST /mapi/emsmdb/ mailboxId=19810624-da69-4c2c-8b71-04c301d5951f@msxfaq.net
                   &CorrelationID=<empty>;
                   &ClientId=HDTPFNOMULHBZNNHMA
                   &ClientRequestInfo=R:1208932e-c748-4b08-8cf7-b0208e05501a:3;CI:d51b36c9-45df-4693-a351-165276e906ff:1;RT:Disconnect
                   &cafeReqId=86e6de8e-836e-4a63-9f7e-6e3d8a9f41c1;
       443 MSXFAQ\HealthMailboxdb73e5d 192.168.100.32 MapiHttpClient - 200 0 0 15

Auf dem Backend Server sieht es ähnlich aus.

2015-10-21 00:00:21 fe80::53a:25c1:f8eb:7cfd%13 
  POST /mapi/emsmdb/ mailboxId=19810624-da69-4c2c-8b71-04c301d5951f@msxfaq.net
                   &FrontEnd=EX2013FE.msxfaq.net
                   &ClientRequestInfo=R:1208932e-c748-4b08-8cf7-b0208e05501a:1;CI:d51b36c9-45df-4693-a351-165276e906ff:1;RT:Connect&ResponseInfo=XRC:0;SC:0;RC:0
                   &AuthInfo=IsAuthenticated:true;AuthenticationType:Negotiate;AuthenticatedUser:MSXFAQ\HealthMailboxdb73e5d;
                   &Stage=BeginRequest:2015-10-21T00:00:21.7073522Z;PostAuthorizeRequest:2015-10-21T00:00:21.7073522Z;EndRequest:2015-10-21T00:00:21.7073522Z
                    444 MSXFAQ\HealthMailboxdb73e5d fe80::53a:25c1:f8eb:7cfd%13 MapiHttpClient - 200 0 0 0
2015-10-21 00:00:21 fe80::53a:25c1:f8eb:7cfd%13 
  POST /mapi/emsmdb/ mailboxId=19810624-da69-4c2c-8b71-04c301d5951f@msxfaq.net
                   &FrontEnd=EX2013FE.msxfaq.net
                   &ClientRequestInfo=R:1208932e-c748-4b08-8cf7-b0208e05501a:2;CI:d51b36c9-45df-4693-a351-165276e906ff:1;RT:Execute&ResponseInfo=XRC:0;SC:0;RC:0
                   &AuthInfo=IsAuthenticated:true;AuthenticationType:Negotiate;AuthenticatedUser:Anonymous;
                   &Stage=BeginRequest:2015-10-21T00:00:21.7229764Z;PostAuthorizeRequest:2015-10-21T00:00:21.7229764Z;EndRequest:2015-10-21T00:00:21.8167270Z
                    444 Anonymous fe80::53a:25c1:f8eb:7cfd%13 MapiHttpClient - 200 0 0 93
2015-10-21 00:00:21 fe80::53a:25c1:f8eb:7cfd%13 
  POST /mapi/emsmdb/ mailboxId=19810624-da69-4c2c-8b71-04c301d5951f@msxfaq.net
                   &FrontEnd=EX2013FE.msxfaq.net
                   &ClientRequestInfo=R:1208932e-c748-4b08-8cf7-b0208e05501a:3;CI:d51b36c9-45df-4693-a351-165276e906ff:1;RT:Disconnect&ResponseInfo=XRC:0;SC:0;RC:0
                   &AuthInfo=IsAuthenticated:true;AuthenticationType:Negotiate;AuthenticatedUser:Anonymous;
                   &Stage=BeginRequest:2015-10-21T00:00:21.8167270Z;PostAuthorizeRequest:2015-10-21T00:00:21.8167270Z;EndRequest:2015-10-21T00:00:21.8323510Z
                    444 Anonymous fe80::53a:25c1:f8eb:7cfd%13 MapiHttpClient - 200 0 0 15

Es sind zwar nur einfache IISLog-Dateien aber für die Fehlersuche als auch diverse Auswertungen ist es sehr hilfreich diese Datenquelle anzuzapfen. Der Request liefert u.a. im Feld "ClientRequestInfo" Hinweise auf die Aktivität. Allein über Logs kann also ermittelt werden, welche Clients und User schon MAPI/HTTP nutzen.

Exchange Diagnose

Weiterhin können natürlich die Protokolldateien in den folgenden Verzeichnissen auf dem Server für einen Fehlersuche herangezogen werden 

%ExchangeInstallationspfad%Logging\MAPI Address Book Service\
%ExchangeInstallationspfad%Logging\MAPI Client Access\
%ExchangeInstallationspfad%Logging\HttpProxy\Mapi\

Besonders interessant sind hier die Dateien in C:\Program Files\Microsoft\Exchange Server\V15\Logging\MAPI Client Access, da Sie sehr ausführlich die Zugriffe von Clients belegen. Hier ein Beispiel eines Exchange 2013 Servers:

#Software: Microsoft Exchange
#Version: 15.00.1044.021
#Log-type: MAPI Mailbox Protocol Logs
#Date: 2015-10-21T20:00:17.853Z
#Fields: date-time,session-id,seq-number,client-name,organization-info,client-software,client-software-version,client-mode,client-ip,client-connection-info,server-ip,protocol,application-id,request-ids,session-cookie,operation,rpc-status,processing-time,operation-specific,failures,performance-data,activity-context-data,user-email,passport-unique-id
2015-10-21T20:00:17.900Z,38538,,/o=MSXFAQ/ou=Kaunitz/cn=Recipients/cn=user1,,OUTLOOK.EXE,15.0.4763.1000,Cached,,,,MapiHttp,Client=MSExchangeRPC,,,SystemLogging,,00:00:00,,,ClientRPCCount=0;AvgClientLatency=00:00:00;ServerRPCCount=13;AvgCasRPCProcessingTime=00:00:00.0168461;AvgMbxProcessingTime=00:00:00;MaxCasRPCProcessingTime=00:00:00.0940000;20%ClientPercentile=10;40%ClientPercentile=10;60%ClientPercentile=10;80%ClientPercentile=10;90%ClientPercentile=10;95%ClientPercentile=10;99%ClientPercentile=10;100%ClientPercentile=10;20%CasPercentile=10;40%CasPercentile=10;60%CasPercentile=10;80%CasPercentile=20;90%CasPercentile=50;95%CasPercentile=70;99%CasPercentile=70;100%CasPercentile=100;20%MbxPercentile=10;40%MbxPercentile=10;60%MbxPercentile=10;80%MbxPercentile=10;90%MbxPercentile=10;95%MbxPercentile=10;99%MbxPercentile=10;100%MbxPercentile=10;ClientRpcFailureData:,S:ActivityStandardMetadata.UserId=ADGuid:<guid>;S:ActivityStandardMetadata.Puid=;S:ActivityStandardMetadata.UserEmail=user1@msxfaq.net;S:WLM.Bal=150000;S:ActivityStandardMetadata.TenantId=msxfaq.net;S:ActivityStandardMetadata.Component=RCA/Mailbox;S:WLM.BT=Rca;S:ActivityStandardMetadata.Protocol=RPC/MapiHttp;S:ActivityStandardMetadata.ClientInfo=OUTLOOK.EXE/15.0.4763.1000;I32:ADS.C[NAWDC002]=1;F:ADS.AL[NAWDC002]=3.4932;I32:ATE.C[NAWDC002.msxfaq.net]=1;F:ATE.AL[NAWDC002.msxfaq.net]=0;I32:ATE.C[NAWDC001.msxfaq.net]=1;F:ATE.AL[NAWDC001.msxfaq.net]=0;Dbl:BudgUse.T[]=216.437796592712;I32:ADS.C[NAWDC003]=2;F:ADS.AL[NAWDC003]=24.99655;I32:ATE.C[NAWDC003.msxfaq.net]=2;F:ATE.AL[NAWDC003.msxfaq.net]=0;Dbl:MAPI.T[EX2013.<guid>]=79;I32:RPC.C[EX2013.<guid>]=16;Dbl:RPC.T[EX2013.<guid>]=79;I32:ROP.C[EX2013.<guid>]=479532680;I32:MAPI.C[EX2013.<guid>]=95;Dbl:ST.T[EX2013.<guid>]=65;Dbl:STCPU.T[EX2013.<guid>]=61;I32:ADS.C[NAWDC001]=1;F:ADS.AL[NAWDC001]=8.1289;I32:MB.C[EX2013.<guid>]=16;F:MB.AL[EX2013.<guid>]=4.9375,user1@msxfaq.net,
2015-10-21T20:00:21.931Z,38538,11,/o=MSXFAQ/ou=Kaunitz/cn=Recipients/cn=user1,,OUTLOOK.EXE,15.0.4763.1000,Cached,,,,MapiHttp,Client=MSExchangeRPC,R:{<guid>}:12|A:<guid>|FE:EX2013.MSXFAQ.NET,C:MAPIxxxx|S:7-1UfPKw==,Disconnect,0,00:15:29.7970000,,,ClientRPCCount=0;AvgClientLatency=00:00:00;ServerRPCCount=1;AvgCasRPCProcessingTime=00:00:00;AvgMbxProcessingTime=00:00:00;MaxCasRPCProcessingTime=00:00:00;20%ClientPercentile=10;40%ClientPercentile=10;60%ClientPercentile=10;80%ClientPercentile=10;90%ClientPercentile=10;95%ClientPercentile=10;99%ClientPercentile=10;100%ClientPercentile=10;20%CasPercentile=10;40%CasPercentile=10;60%CasPercentile=10;80%CasPercentile=10;90%CasPercentile=10;95%CasPercentile=10;99%CasPercentile=10;100%CasPercentile=10;20%MbxPercentile=10;40%MbxPercentile=10;60%MbxPercentile=10;80%MbxPercentile=10;90%MbxPercentile=10;95%MbxPercentile=10;99%MbxPercentile=10;100%MbxPercentile=10;ClientRpcFailureData:,S:ActivityStandardMetadata.UserId=ADGuid:<guid>;S:ActivityStandardMetadata.Puid=;S:ActivityStandardMetadata.UserEmail=user1@msxfaq.net;S:WLM.Bal=150000;S:ActivityStandardMetadata.TenantId=msxfaq.net;S:ActivityStandardMetadata.Component=RCA/Mailbox;S:WLM.BT=Rca;S:ActivityStandardMetadata.Protocol=RPC/MapiHttp;S:ActivityStandardMetadata.ClientInfo=OUTLOOK.EXE/15.0.4763.1000;Dbl:MAPI.T[EX2013.<guid>]=0;I32:ROP.C[EX2013.<guid>]=0;I32:MAPI.C[EX2013.<guid>]=2;I32:MB.C[EX2013.<guid>]=0;F:MB.AL[EX2013.<guid>]=0,user1@msxfaq.net,
2015-10-21T20:00:21.962Z,38542,78,/o=MSXFAQ/ou=Kaunitz/cn=Recipients/cn=user1,,OUTLOOK.EXE,15.0.4763.1000,Cached,,,,MapiHttp,Client=MSExchangeRPC,R:{<guid>}:79|A:<guid>|FE:EX2013.MSXFAQ.NET,C:MAPIxxxx|S:74-sD6dBA==,OwnerLogoff,0,00:00:00,LogonId: 0,,,,user1@msxfaq.net,
2015-10-21T20:00:21.978Z,38542,78,/o=MSXFAQ/ou=Kaunitz/cn=Recipients/cn=user1,,OUTLOOK.EXE,15.0.4763.1000,Cached,,,,MapiHttp,Client=MSExchangeRPC,R:{<guid>}:79|A:<guid>|FE:EX2013.MSXFAQ.NET,C:MAPIxxxx|S:74-sD6dBA==,Disconnect,0,00:14:51.1250000,,,ClientRPCCount=0;AvgClientLatency=00:00:00;ServerRPCCount=80;AvgCasRPCProcessingTime=00:00:00.0142875;AvgMbxProcessingTime=00:00:00;MaxCasRPCProcessingTime=00:00:00.5930000;20%ClientPercentile=10;40%ClientPercentile=10;60%ClientPercentile=10;80%ClientPercentile=10;90%ClientPercentile=10;95%ClientPercentile=10;99%ClientPercentile=10;100%ClientPercentile=10;20%CasPercentile=10;40%CasPercentile=10;60%CasPercentile=10;80%CasPercentile=20;90%CasPercentile=20;95%CasPercentile=40;99%CasPercentile=110;100%CasPercentile=600;20%MbxPercentile=10;40%MbxPercentile=10;60%MbxPercentile=10;80%MbxPercentile=10;90%MbxPercentile=10;95%MbxPercentile=10;99%MbxPercentile=10;100%MbxPercentile=10;ClientRpcFailureData:,S:ActivityStandardMetadata.UserId=ADGuid:<guid>;S:ActivityStandardMetadata.Puid=;S:ActivityStandardMetadata.UserEmail=user1@msxfaq.net;S:WLM.Bal=150000;S:ActivityStandardMetadata.TenantId=msxfaq.net;S:ActivityStandardMetadata.Component=RCA/Mailbox;S:WLM.BT=Rca;S:ActivityStandardMetadata.Protocol=RPC/MapiHttp;S:ActivityStandardMetadata.ClientInfo=OUTLOOK.EXE/15.0.4763.1000;I32:ROP.C[EX2013.<guid>]=-1424960471;Dbl:RPC.T[EX2013.<guid>]=921;I32:RPC.C[EX2013.<guid>]=138;Dbl:MBLB.T[EX2013.<guid>]=4762;I32:ATE.C[NAWDC001.msxfaq.net]=1;F:ATE.AL[NAWDC001.msxfaq.net]=0;Dbl:STCPU.T[EX2013.<guid>]=429;Dbl:ST.T[EX2013.<guid>]=434;Dbl:BudgUse.T[]=1118.91599082947;I32:MB.C[EX2013.<guid>]=138;F:MB.AL[EX2013.<guid>]=6.673913;I32:ADS.C[NAWDC001]=1;F:ADS.AL[NAWDC001]=9.8905;Dbl:MAPI.T[EX2013.<guid>]=921;I32:MAPI.C[EX2013.<guid>]=1590,user1@msxfaq.net,
2015-10-21T20:00:22.009Z,38313,29,/o=MSXFAQ/ou=Kaunitz/cn=Recipients/cn=user1,,OUTLOOK.EXE,15.0.4763.1000,Cached,,,,MapiHttp,Client=MSExchangeRPC,R:{<guid>}:30|A:<guid>|FE:EX2013.MSXFAQ.NET,C:MAPIxxxx|S:16-5G5VFw==,DelegateLogoff,0,00:00:00,LogonId: 0,,,,user1@msxfaq.net,

Interessant sind hier vor allem die ganzen statistischen Daten, die von den Clients über diesen Weg an den Server zurück gesendet werden.

Health Check

Die Erreichbarkeit und wie Exchange selbst seine "Gesundheit" sieht, können Sie einfach über eine URL abfragen. Das funktioniert hier am Beispiel mit Office 365 problemlos.

https://outlook.office365.com/mapi/healthcheck.htm

 

Sie sollten dann natürlich ihre eigene URL eingeben. Zudem gibt es noch folgende URLs für authentifizierte Benutzer mit weiteren Details

https://outlook.msxfaq.com/mapi/nspi
 
https://outlook.msxfaq.com/mapi/emsmdb

Diese URLs funktionieren auch in der Cloud:

Hier habe ich keine Session aktiv, so dass die Debug-Ausgabe gekürzt ist. Sie können das ja gerne einmal mit ihrem eigenen User versuchen.

Ansicht auf dem Client

Ein erster Test, ob der Exchange Server die geänderte Konfiguration umgesetzt hat, erkennen Sie bei einer Autodiscover-Abfrage in Outlook. Hier sollte das Protokoll "MAPI-HTTP" mit den internen und externen URLs für den Postfachspeicher und das Adressbuch erscheinen.

Wenn Sie sich in der XML-Ansicht die komplette URL kopieren, können Sie diese auch im Browser eingeben.

Hinweis: Der Zugriff auf diese URL ist für jeden authentifizierten Benutzer erst einmal möglich. Damit können Sie einfach testen, ob die MailboxGUID und die Exchange Server die Anfragen annehmen und im Fenster wird auch angezeigt, welcher Benutzer sich tatsächlich mit welchem Verfahren authentifiziert hat. Ohne Anmeldung oder mit einer falschen MailboxGUID sehen Sie aber nur einen 404-Fehler.

 

Die Mailbox-GUID können Sie übrigens einfach aus dem Active Directory (msExchMailboxGUID) auslesen oder per Exchange Powershell.

get-mailbox fcarius -ResultSize 1 |ft WindowsEmailAddress,exchangeguid -AutoSize

WindowsEmailAddress       ExchangeGuid
-------------------       ------------
user1@msxfaq.net xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Im Outlook Verbindungsstatus sollte dann auch HTTP als Protokoll erscheinen

Ansonsten sollten Sie in Outlook keinen Unterschied bemerken.

Client mit Fiddler

Da die ganze Kommunikation nun per MAPI/HTTP erfolgt, kann ich natürlich auch auf dem Client z.B. per Fiddler mir genauer die Konversation anschauen. Auch für die Fehlersuche ist dies interessant um zumindest zu sehen, ob der Client die richtige URL anspricht und wie die Anmeldung erfolgt.

 

Sie sehen hier aber auch, .dass Outlook trotz MAPI/HTTP auch noch ab und an eine EWS-Abfrage stellt (hier war es die Abfrage nach den OOFSettings) und auch noch die ein oder andere RPC-Anfrage möglich ist. Die meisten Pakete gehen aber hier über die "/mapi"-URL, die aber wie üblich erst zwei mal einen 401 generiert, bis die Anmeldung letztlich durch ist. Ein Blick in einer dieser Anfragen lässt zwar vermuten, dass hier ein Zugriff auf ein Postfach mit dem Namen "Support" erfolgt ist.

 

Mehr ist aber auf die Schnelle hier nicht zu sehen. Der Content ist "application/mapi-http" und ist letztlich binär. Also doch wieder MAPI nur diesmal in HTTPS eingetunnelt. Schaut man sich aber mal die Größe der Pakete an, dann bin ich schon etwas überrascht über die die Anzahl der Header, die da übertragen werden und das Volumen aufblähen.

Weitere Link