Outlook synchronisiert nicht

Outlook für Windows arbeitet mittlerweile fast immer im "Cached Mode", d.h. der Client repliziert das Postfach mit einer lokalen OST-Datei und wenn Sie Änderungen vornehmen, werden diese Deltas nicht sofort, sondern etwas verzögert zum Server hoch repliziert. Manchmal kommt der Prozess aber zum Stocken.

Symptom erkennen

Meist sind es Anwender, die sich zuerst darüber beschweren, dass eine neue Mail z.B.: im Postausgang "hängen" bleibt oder der Posteingang nicht aktuell ist. Gerade in Verbindung mit einem Smartphone, welches ja ein anderes Protokoll nutzt, fällt es gerne mal auf, dass eine Mail auf dem Smartphone schon "vibrierte" hat aber in Outlook nichts angezeigt wird.

Das ist auch so erwartet, wenn sich das im Bereich von wenige als einer Minute abspielt. Wenn z.B. vom Transport-Service eine neue Mail in den Posteingang abgelegt wird, dann informiert die CAS-Funktion den ActiveSync Client über eine bestehende HTTPS-Verbindung über diese Mail. Das klassische "Push"-Szenario und da die Verbindung schon mal steht und das SmartPhone eh gerade "wach" ist, kann die Mail auch gleich angefordert und übertragen werden.

Auch Outlook bekommt natürlich eine Information über eine Veränderung im Postfach. Früher war dies ein UDP-Paket vom Server zurück zum wartenden Client. Das funktioniert über Internet und mit NAT-Routern natürlich nicht. Daher hat Microsoft schon seit Outlook 2007 langsam auf TCP umgestellt. Der Outlook Client öffnet eine TCP-Verbindung zum Server, die vom Client aufrecht erhalten wird. Über diesen etablierten Kanal kann der Server die Benachrichtigung an den Client senden und dieser synchronisieren.

Allerdings synchronisiert Outlook nun nicht sofort die Änderungen sondern wartet bis zu 20 Sekunden erst einmal ab. Kommt in dieser Zeit noch eine Info über eine Veränderung, wird der Counter zurück gesetzt. Im Extremfall wartet Outlook bis zu 3x20 Sek = 1 Min, ehe es dann mit der Replikation anfängt. Das ist durchaus sinnvoll, um den Server zu entlasten. Wenn Sie z.B. eine Mail oder Termineinladung senden, dann kommen in der Regel kurz darauf gleich mehrere Meldungen (Zusagen, Absagen, OOF-Meldungen etc.) Da wäre es unsinnig für jede Mail einen Synchronisationslauf zu starten. Daher wartet Outlook etwas und es ist quasi "normal", dass Outlook im Cached-Mode eine Mail nicht "sofort" anzeigt.

Auch beim Versand geduldet sich Outlook etwas. für die Anwender ist dies in der Regel gar nicht auffällig, schließlich ist Mail kein "Echtzeit-Medium". Hier sind dann eher Skype für Business oder andere SIP-basierte Messenger gefragt. Es kann aber auch passieren, dass die Synchronisation "hängt".

Ansätze zur Einkreisung

Eine unterbrochenen Synchronisation fällt den Anwendern meist schnell auf, wenn Sie eine Mail versenden und diese den Postausgang nicht verlässt. für den Anwender und Administrator gibt es mehrere Ansätze das Problem einzukreisen.

  • Mail ist "ungelesen" im Postausgang

    Normalerweise landet eine Mail direkt nach dem Versendevorgang im Postausgang und wird versendet. Je nach Größe und Verbindung kann das etwas dauern. Gerade mit Office 365 oder Heimarbeitsplätzen wird gerne der Uplink einer Leitung überschätzt. DSL16.000 hat oft nur 1-2 Megabit Uplink. für eine "kleine" 1 Megabyte Datei sind das netto schon 10 Sekunden.
    Der häufigste Fehler ist aber, dass die Mail im Postausgang nicht "Kursiv" ist, sondern durch irgend einen Prozess "gelesen" wurde. Damit sendet Outlook diese Mail nicht mehr weg, sondern behält sie als Entwurf, damit der Anwender Sie überarbeiten und erneut senden kann.
    Auf die Frage, wer die Mail denn vor dem Versand "liest" können ich zwei Optionen:
    • Outlook als "Vorschau"
      Einige Outlook-Versionen bieten eine "Vorschau" auf Mails und wenn diese Ansicht auch beim Postausgang aktiv ist und der Anwender den Postausgang ausgewählt hat, wird die Mail nach dem Seiten gleich wieder auf Entwurf gesetzt.
      Test: Öffnen Sie die Mail im Postausgang, ändern sie dann im Outlook Fenster den Ordner und klicken dann erst in der der Mail wieder auf senden.
    • Add-ons
      Beliebt sind natürlich auch fehlerhaft implementierte Add-ons, die z.B. ausgehende Mails "anhalten" um diese auf Viren zu prüfen, einen Index zu erstellen oder andere Zusatzfunktionen einbauen. Deaktivieren Sie temporär die Add-ons oder starten Sie Outlook mit gedrückter CTRL-Taste in der abgesicherten Betriebsart und wiederholen Sie den Versand
  • Unterbrochene Verbindung
    Sollte warum auch immer Outlook keine Verbindung mit dem Server haben, dann sehen Sie dies in der Fußzeile von Outlook. In dem Fall gilt es dies zu prüfen
  • Verbindung vorhanden ohne kein Versand
    Es soll schon mal passiert sein, dass eine Mail wirklich nicht versendet wurde, obwohl alles korrekt erscheint. Über den Hotkey "F9" können Sie eine Synchronisation anstoßen. Dann sollte Outlook auch eine unbemerkt unterbrochene Verbindung neu aufbauen.

Ein wichtiger Ansatz für die Fehlersuche ist der Vergleich von Clients. Ein Exchange Server wird in der Regel von vielen Clients angesprochen. Am einfachsten und ohne technisches Wissen kann geschaut werden, ob das Problem alle Clients betrifft, was eher auf einen Fehler am Server oder dem LAN hinweist oder ob es nur eine Teilmenge der Clients betrifft. Wenn nur eine Teilmenge betroffen ist, dann gilt es herauszufinden, warum es eben nur diese Teilmenge ist.

Manchmal hilft es auch einen möglichst "einfachen" Client als Testsystem zu nutzen. Einfach nur ein Windows und Outlook in den jeweils genutzten Version ganz ohne Zusatzprodukte oder umfangreiche Gruppenrichtlinien, gerne auch ohne Domänenmitgliedschaft, um die Grundfunktion zu testen.

Störfaktoren

Eine pauschale Antwort, welche Komponente ihnen hier die Verbindung stört gibt es nicht. Das Problem ist ja meist so gelagert, dass es mal geht und mal nicht und immer dann, wenn es analysiert werden soll, gerade nicht auftritt. Daher eine lockere Liste von Störfaktoren, mit denen ich schon konfrontiert war:

  • 3rd Party Firewall aus dem Desktop
    Die Windows Firewall ist seit längerem Bestandteil von Windows und macht eigentlich seit Windows 7 einen sehr guten Job. Viele Zusatzdienste wie z.B. DirectAccess oder HTTP-Listener auf einem Webserver benötigen die Windows Firewall und entsprechend zertifizierte Programme müssen ebenfalls damit umgehen können, bei der Installation ggfls. Regeln einzubauen. Dennoch gibt es immer noch Produkte, die Teil ihres Schutzes auch eine Firewall mitbringen. Teilweise geht deren Absolutheitsanspruch so weit, dass Sie die Windows Firewall nicht nur im Netzwerkprofil abschalten, sondern gleich den kompletten Dienst beenden und deaktivieren. (z.B. gesehen bei Symantec Endpoint Protection 2015 (SEP))
  • Virenscanner auf dem Desktop mit "Filter" Denkweise
    Es gibt auch Virenscanner, die sich nicht nur auf das Dateisystem beschränken, sondern über verschiedenste Schnittstellen auch Netzwerkverkehr und Anwendungen gegen die Schädlinge der Welt schützen wollen. Da jede Software auch Fehler haben kann, können genau diese "Guten" aufgrund ihrer umfassenden Funktionsweise die Ursache eines Problems sind.
  • WAN Optimierer auf dem Weg
    Bandbreite ist kostbar und es gibt jede Menge Protokolle, die für den Einsatz im LAN ausgelegt waren aber im WAN ein ungünstiges Verhalten an den Tag legen. Seit vielen Jahren gibt es WAN Optimizer wie z.B. von Riverbed, die den Datenverkehr "optimieren", sei es durch Kompression, Spoofing von Antworten, Caching von Dateien etc. Diese Produkte müssen dazu das Protokoll und das Optimierungspotential sehr gut können. Und das ist nicht immer der Fall. Gerade wenn die Clientsoftware aktualisiert wurde, kann so ein Optimizer Probleme machen. Hier kann es temporär zur Fehlersuche nützlich sein, die Optimierung bezogen auf die IP-Adresse der Exchange Server zu deaktivieren.
  • Proxies und Firewalls auf dem Weg
    In einem LAN gibt es seltener Firewalls aber wenn ein Client extern über ein VPN oder Proxy zugreift oder ein interner Client auf Exchange in einer Cloud zugreift, können diese Systeme in Verbindungen über Outlook Anywhere oder MAPI over HTTP eingreifen und diese stören. Gerade wenn ein Proxy-Server in den SSL-Datenstrom "reinschaut"  (SSL Offloading), können die vielleicht ungewöhnlichen Datenpakete und Header bei der Umsetzung gestört werden.
    Hinzu kommt, dass Outlook ja eine inaktive TCP-Verbindung auch mehrere Minuten oder sogar Stunden ohne ein Paket aufrecht erhalten kann. Wenn eine Firewall dann die Verbindung aus der Session-Table kickt ohne den Endpunkten mit einem RESET Bescheid zu sagen, glauben Exchange und Outlook, dass Sie noch eine Verbindung hätten und warten einfach.
  • Intrusion Detection Systeme
    Immer mehr Firmen setzen zusätzliche Systeme im LAN ein, um Fehlverhalten und Schadcode zu erkennen. Wenn solche Systeme aufgrund einer erkannten Protokollverletzung Alarm schlagen und den Ethernet-Port des Clients abschalten, dann ist die Fehlersuche schnell abgeschlossen. Perfider ist es, wenn das System einfach nur die verdächtigen Pakete unterdrückt und vielleicht die Meldung dazu, so sie generiert wird, nicht bei de richtigen Person ankommt.
  • Netzwerkkartentreiber
    Zuletzt sollten Sie auch nicht die lokalen Treiber übersehen. Es gibt durchaus Versionen von Netzwerkkartentreibern, die in Verbindung mit TCPChimney und RSS habe ich hier schon die wunderlichsten Dinge erlebt. Ein Treiber für eine Gigabit-Netzwerkkarte sollte jünger als 2 Jahre sein. Ansonsten würde ich hier zuerst nach einem Update suchen. Das geht schnell und ist meist gefahrlos. Das gilt für Clients aber auch für Server

Soweit eine erste sicher unvollständige Liste an Störfaktoren, die ich in meiner langen Erfahrung mit Outlook und Exchange schon auf die ein oder andere Weise erlebt habe.

Fehlersuche Exchange Server

Wenn die ersten Checks keine Auffälligkeiten ergeben haben, dann bleibt nur der Blick auf dem Server und ggfls. eine Netzwerkanalyse. Mit dem Wissen um den Client und dessen Zugriffsweg können Sie auf dem Exchange-Server natürlich erst einmal die IISLogs zu Rate ziehen. Mit dem Ende von MAPI/TCP und dem Wechsel auf Outlook Anywhere und MAPI over HTTP kommunizieren die Clients per HTTPS mit dem Webserver, der darüber in den IISLogs Buch führt. Hier sollte also der Zugriff des Clients auf "/MAPI" oder "/RPC" zumindest finden können und an Ende den Statuscode sehen.

Outlook Client Logging

Eine weitere Option der Fehlersuche ist das Logging auf dem Outlook Client. Siehe dazu auch die gesonderte Seite auf:

Fiddler

Wenn die Kommunikation zwischen Client und Server per HTTPS erfolgt, können Sie natürlich auch hier mit "Fiddler" mitschneiden. Wenn Sie hier HTTPS-Debugging aktivieren und das von Fiddler dann genutzte Root-Zertifikat als "vertrauenswürdig" installieren, können Sie alle Anfragen des Clients mit dem Server analysieren. Allerdings ist dies ein sehr tiefer und aktiver Eingriff in die Kommunikation. Das kann dazu führen, dass der Fehler gerade nicht mehr auftritt oder andere Fehler in den Vordergrund rücken. Zudem bedeutet es die Installation auf dem Client, was nicht immer möglich ist. Daher ist diese Option eine der letzten Möglichkeiten einen Fehler einzukreisen.

  • Fiddler
  • 929779 How to help the Outlook.com support team collect FiddlerCap traces

Netzwerk Trace

Noch mehr Aufwand  aber als "Beweismittel" für unklare Netzwerklagen unschlagbar, ist ein Mitschnitt mittels Netmon oder Wireshark. Idealerweise wird der Capture auf dem Server und dem Client parallel gestartet mit einem Filter auf explizit diese Verbindung. Oft reicht es schon die Anzahl der Pakete zu zählen oder die ersten Pakete zu verfolgen, die nach dem Eingang einer neuen Mail versendet werden und beim Client ankommen sollten.

Weitere Links