Exchange 2016, MAPI/HTTP und der Performance von Outlook in "Online-mode"

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Exchange 2016, MAPI/HTTP und der Performance von Outlook in "Online-mode"

    Moin Forumfreunde,

    ich streue hiermit mal meine Erfahrungen mit Exchange 2016 in unserem Unternehmen (ca. 11000 Mailboxen) und die Probleme die wir im Moment haben.

    In Januar 2017 haben wir mit der Migration von Exchange 2010 nach Exchange 2016 angefangen. Wir haben den Microsoft Service "Onboarding Accellerator" für Exchange 2016 in Anspruch genommen und hatten 3 Wochen lang einen PFE vor-Ort welche unsere Umgebung analysiert, unsere neue Hardware auf Tauchlichkeit untersucht und uns bei der Installation der Exchange 2016 Server begleitet hat.

    Nach Phase I, die Analyse von unsere Exchange 2010 Umgebung haben wir uns 8 Server bestellt (HP Apollo). Die wurden dann mit Jetstress geprüft und von MS als "sehr gut" abgesegnet. Ziel war es die 11.000 Mailboxen über die 8 Server und 48 Datenbanken zu verteilen und ausreichend Reserve für 40% zuwachs bereit zu halten für die nächste 3-5 Jahr. Als Loadbalancer war einen neue F5 vorgesehen.

    Die Migration der ersten, ca 3500 Mailboxen verlief problemlos. Erst nachdem wir ca. 8500 Mailboxen auf Exchange 2016 migriert hatten, begannen die erste Anwender sich über die Geschwindigkeit von Outlook zu beschweren. Uns wurde relativ klar, dass die Probleme nur sichbar waren wenn Outlook in "Online-Mode" betrieben wurde, was bei uns für ca 1600 "Shared Mailboxen" der fall ist.
    Darüberhinaus merkten wir, das die Probleme später in der Mittag verschwunden; dann fahren viele Anwender ihren Rechner herunter und gehen nach hause. Auf der F5 konnten wir gut verfolgen, wie die Anzahl an Connections abnahm und ab eine Bestimmte Anzahl an Verbindungen (ca. 1700 pro Server) waren die Probleme Weg.

    Nachdem Microsoft Premier Support uns nicht weiterhelfen konnte haben wir entschieden zusätzlichen Server zu installieren. Das leitete dazu das Outlook schneller reagierte, nie aber das Niveau von Exchange 2010 erreichte. Mittlerweile haben wir zusäzlich zu den 8 HP Server 12 Virtuellen Server die als quasi CAS Server laufen also nur Clientverbindungen entgegen nehmen, selbst aber keine Postfächer 'hosten'.

    Nach gut 3 Wochen bekamen wir dann die Aussage von Microsoft Support, dass wir tatsächlich nicht die Einzigen mit diesem Problem sind und das die Ursache wol im MAPI/HTTP Protokoll liegt. Bei MAPI/HTTP wird bei jedem Aktion in Outlook ein HTTP Get-Request abgesetzt. Läuft Outlook in Cached Mode, dann gegen der OST, sonst aber direct gegen der Loadbalancer und damit einer der Exchange Server, welcher u.U. den Request wieder weitergeben muss an dem Server wo der Aktive Datenbank mit dem Postfach worauf zugegriffen wird liegt.
    Empfehlung von Microsoft war, diese Postfächer über "set-casmailbox "id" -mapihttpenabled $false auf RPC/HTTP umzustellen.

    Also, wir daran unsere 1600 in Online Mode laufenden Postfächer zu identifizieren und umzustellen.

    Nun bin ich mit meiner Geschichte in der KW22 gelandet, also letzte Woche. Immer mehr Anwender, vor allem die im Ausland beschweren sich, dass Outlook sehr lange braucht zum starten. Ein Englischer Mitarbeiter teilte mir dann mit, das dieses Phenomän erst auftritt, nachdem einige Updates installiert wurden. Es dauerte dann nicht lange bevor wir das April Security Update für Outlook 2010 (KB3118388) gefunden hatten. Update deinstalliert, Outlook startet wieder schneller. Update wieder installiert, Outlook wieder langsam.
    Während dem Arbeiten aber konnten wir keinen Unterschied merken zwischen MAPI/HTTP und RPC/HTTP. Da auch ohne KB3118388 die Performance in den Online-mode Postfächer schlechter war als vor 3 Wochen haben wir heute alle wieder auf MAPI/HTTP umgestellt und hoffen, dass die Anwender am Montag wieder besser arbeiten können (das Rollback von KB3118388 kriegen die Kollegen der SCCM Truppe wohl nicht so schnell hin).

    Mir würde jetzt mal brennend interessieren, ob ihr die gleiche Erfahrungen mit Exchange 2016 habt. Auch über neue Lösungsansätze würde ich mich sehr freuen. Wir überlegen uns jetzt schon die Postfächer über mehrere DAGs zu verteilen und mit mehrere Namespaces zu arbeiten damit wir die Last auf den Servern besser steuern können.

    Viele Grüße,
    Jack
  • Nach eine Woche und einen CritSit sieht es so aus, als liegt das Problem in der Umgang von Exchange 2016 mit der NUMA Architektur.

    Nachdem wir im BIOS unserer Server die Einstellung "NUMA Group Size Optimisation" auf "Flat" geändert haben ist der Performance sehr viel besser.
    Nach Aussage von MS Support, kommt .NET unter Umständen nicht mit mit mehreren KGroups zu recht. Das haben wir gefunden nachdem [system.environment]::processorcount in Powershell nur 10 CPU Cores gezeigt hat, wir aber 20 Cores in den Servern haben.
    Das hat dann dazu geleitet, das der Threadverwaltung durch einander gekommen ist.
    Übrigens ist der Einstellung im BIOS erst seit dem letzten BIOS Update vorhanden :)
    Bilder
    • MSX.PNG

      56,87 kB, 657×374, 124 mal angesehen
  • Der Hintergrund meiner Frage war übrigens ebenfalls langsames Verhalten von Outlook im Online Modus. Hier war es allerdings der Kemp Loadbalancer, der in der aktuellen Version definitiv ein Problem auf Layer7 SSL Services verursacht, was dann zu extrem langsamen Verhalten führt. Downgrade auf die LTS hat das Problem erstmal gelöst. Warten wir auf die nächste aktuelle Version.
  • Moin!

    Uns trifft es mittlerweile auch. Zwar haben wir aus historischen Gründen "MapiHTTPEnabled" nicht eingeschaltet, aber nach der Migration einer größeren Anzahl Benutzer klagen die User die Outlook ohne Cache verwenden über Performanceprobleme. Auf den Servern, Netzwerk und Storage lassen sich keine Engpässe erkennen; es sieht so aus als würde das Exchange 2016 zum einen nicht so performant sein wie das Exchange 2010, zum anderen auf magische Weise ab und an mit sich selber beschäftigt sein ohne daß man das an irgendwelchen Meßwerten festmachen kann.

    Wir betreiben aktuell eine Exchange-Farm mit 8 Servern und ca. 17.000 Mailboxen; die Probleme begannen nachdem die letzten 4500 User auf das System migriert wurden. Die Umgebung (mit 60 Datenbanken) wurde von Microsoft für 20.000 Mailboxen gesized.

    Als Loadbalancer läuft bei uns eine F5, auf der auch keine Probleme oder Peaks zu erkennen sind. Natürlich habe ich das das Thema bei Microsoft eingetütet, allerdings befürchte ich daß da wie so oft keine befriedigende Antwort herauskommen wird.

    Konnte denn jemand mittlerweile neue Erkenntnisse zum Problem gewinnen?

    Viele Grüße
    Rolf