Outlook getrennt

Manchmal kann Outlook keine Verbindung zum Exchange Server erstellen. Auf dieser Seite beschreibe ich die verschiedenen Ursachen und mögliche Probleme.

Regelfall

Nach meinen Erfahrungen macht Outlook einen richtige guten Job, die Verbindung zum Exchange Server, sei es On-Premises oder in der Cloud immer wieder herzustellen. Aber auch Outlook kann nur so gut funktionieren, wie die Umgebung es zulässt. Der normale Anmeldeprozess bei Outlook läuft wir folgt ab

  • Namensauflösung, HTTP-Verbindung, Zertifikatcheck
  • Erster HTTP-Request erfolgt Anonym
    Outlook weiß ja noch nicht, welche Anmeldeverfahren die Gegenseite anbietet
  • Exchange Backend antwortet mit einem 401 +  Auth Header
    Outlook nutzt die Fehlermeldung um sich eines der angebotenen Anmeldeverfahren auszusuchen.
  • Outlook meldet sich an
    Hier gibt es nun viele Varianten der Anmeldung, sei es durch Kerberos oder NTLM beim internen Zugriff auf einen On-Premises Exchange Server über "BasicAuth" bei der Nutzung eines Proxy-Servers ohne Contraint Delegation Support bis zu OAUTH mit Office 365. Es können also durchaus noch einige Requests passieren, bis Outlook ein Ticket und Cookie für den Zugriff hat

Outlook ist dann verbunden und bleibt auch verbunden. Bis eben etwas passiert.

Fehlerfall

Der Fehlerfall erscheint eigentlich immer in der Taskleiste von Outlook und da kenne ich drei Optionen

  • Verbunden
    Outlook hat eine aktive Verbindung und arbeitet wie erwartet
  • Offlinemodus
    d.h. Sie haben bewusst die Verbindung manuell unterbrochen um z.B. über schwache, teure Verbindungen eine Synchronisation zu unterbinden.
  • Getrennt
    Der Status "getrennt" ist aber in der Regel eine Meldung, dass Outlook eigentlich verbunden sein will aber die Verbindung nicht möglich ist.

Das muss nicht bedeuten, dass die IP-Verbindung tatsächlich nicht vorhanden ist. Es kann auch ein Problem der Authentifizierung sein. Das ist häufiger der Fall und oft die Ursache. Leider ist genau der Fall besonders schwer zu analysieren.

Checkliste

Naheliegend ist natürlich ein Problem in der Netzwerkverbindung oder ein Ausfall des Servers. Aber so einfach ist es häufig nicht, denn ich habe schon in Kundenumgebungen nach Fehlern gesucht, bei denen eigentlich der Client, das Netzwerk und der Exchange Server verfügbar waren und Outlook dennoch am und an mal "getrennt" war. Im Laufe der Jahre hat sich eine Checkliste entwickelt, die keinen Anspruch auf Vollständigkeit erhebt.

Prüfung Erledigt

Physikalisches Netzwerk

Auch mir ist es schon passiert, dass ich 100% sicher war, dass meine Kabelverbindung in Ordnung war. Aber der Teufel steck im Details, z.B.: weil ihr PC hinter einem PoE-Telefon angeschlossen ist oder die nagelneue USB-C DockingUnit nicht komplett angeschlossen war. Ich hatte auch schon PCs, die im falschen VLAN angebunden waren aber die Mitarbeiter per WLAN dies nicht sofort gemerkt haben. Erst als die Firma dann per Policy die WLAN-Karte abgeschaltet hat, wenn LAN besteht, ist dies bei den Notebooks aufgefallen. Je häufiger der Mitarbeiter im Haus "unterwegs" war, desto weniger war er betroffen.

Es gibt aber auch Netzwerk-Links, die elektrisch in Ordnung sind aber dennoch "flackern". Manchmal ist es auch ein Uplink des Switch.

Prüfen Sie, ob sich die Probleme auf einen Client beschränken oder ein Stockwerk oder es sonst Gemeinsamkeiten gibt.

Netzwerkwechsel

Outlook kann mit Autodisover und Einstellungen wie "InternalURL" und "ExternalURL" wunderbar damit umgehen, einmal im LAN direkt zum Server zu kommen oder über das Internet. Knifflig wird es, wenn ihr Client im LAN ist aber je nach Subnetz oder Proxy eine andere Konfiguration bekommt und damit die "falsche" Konfiguration anwendet. Das passiert immer dann gerne, wenn Sie einen Notebook aus der Dockingunit ausklinken und per WLAN weiter arbeiten.

Verstecktes VPN

Windows und Outlook "erkennen", wenn sich das Netzwerk ändert und vergessen z.B. ihren DNS-Cache. Das funktioniert aber nur, wenn Windows auch einen "Netzwerkchange" erkennt. Es gibt aber VPN-Lösungen, die nicht als "virtuelle Netzwerkkarte" erkennbar sind sondern "untendrunter" einfach einen IPSec-Tunnel aufbauen. Wenn die VPN-Lösung dann nicht den DNS-Cache leert, dann wird Outlook beim nächsten Verbindungsaufbau noch den alten Weg versuchen. Das ist besonders dann der Fall, wenn interne und externe Namen gleich sind und sich per Split-DNS nur die IP-Adresse ändert.

Interne Firewalls/WAN-Optimierer/MTU-Size

Auch dieser Fall ist mir schon untergekommen, dass nur Niederlassungen betroffen waren. Aktive Komponenten wie Firewalls, WAN-Optimierer aber auch VPN-Router müssen die Pakete unverändert übertragen. Wenn aber eine zu kleine MTU-Size in Verbindung mit "ICMP blockieren" zusammenfällt, dann kann Outlook keine Verbindung mit großen Paketen aufbauen. Ein kleiner "Ping" geht aber immer noch durch. Eine Analyse ist hier z.B. per Wireshark möglich. Oder versuchen Sie sich mit OWA zu verbinden.

Desktop-Firewalls

Outlook erwartet keine eingehenden Verbindungen, sondern baut von sich aus die Verbindung zum Server auf. Dennoch gibt es immer wieder "Schutzprodukte", die solche Verbindung als "schlecht" verhindern. Es mag in Ordnung sein, wenn ein Virenscanner mit "Verhaltenskontrolle" eine ausgehende Verbindung per SMTP (TCP/25) blockiert.

TLS-Handshake

Wir sind ja mitten im TLS 1.2 Wechsel, d.h. diverse Dienste blockieren Verbindungen mit SSL3, TLS 1.0 oder 1.2. Das gilt auch für Schlüssellängen in Zertifikaten. Auf der anderen Seite gibt es Proxy-Server, die hier noch nicht kompatible sind und so kommt die Verbindung gar nicht erst zustand, obwohl per DNS und IP-Routing ein PING und selbst eine TCP-Verbindung zum Exchange Server über Port 443 möglich ist.

IPv6

Das nächste Adressierungsschema verbreitet sich mehr und mehr. Konfigurationsfehler passieren meist im Firmennetzwerk. Provider wie T-Online, Deutsche Glasfaser, Unitymedia u.a. betreiben schon viele Endkundenanschlüssen mit IPv6, um ihre IPv4-Knappheit zu umgehen. Aber in Firmen kann es schon sein, dass ihr Client per IPv6 den Server auflösen aber dennoch nicht erreichen kann.

Gäste LAN/WLAN Portal

Outlook kann nicht mit Portalen umgehen. Wenn Outlook eine HTTP-Anfrage stellt und es kommt eine Antwort ohne Authentifizierungsinformation zurück, dann stoppt Outlook. Gerade WLAN Accesspoints mit vorgeschaltetem Portal zwecks Werbung oder Anmeldung im Formular bringen Outlook dazu, erst einmal inne zu halten.

DNS-Auflösung

Outlook fragt nach einem Server und bekommt eine IP-Adresse. Prüfen Sie, ob sie per DNS wirklich die richtige IP-Adresse bekommen. Gerade Firmen, die DNS Round Robin statt Loadbalancer einsetzen, addieren neue Server aber vergessen gerne mal alte Server auch wieder zu entfernen. Auch wenn Sie einen Server "in Wartung" nehmen, sollten Sie dessen Adresse nicht mehr bekannt geben.

Loadbalancer und DNS-Auflösung

Mit einem Loadbalancer ist der Weg vom Client zum Loadbalancer einfacher aber auch hier muss der Loadbalancer nach hinten die erreichbaren Server ansprechen. Auch hier hatte ich schon "real Server", die nicht erreichbar waren und dies durch den Verfügbarkeitscheck nicht erkannt wurde.

Authentifizierungsfehler/Internetzonen

Manchmal kommen Outlook und der Exchange Server einfach nicht zusammen. Outlook erwartet auf seine erste Anfrage einen 401-Fehler mit der Information über die mögliche Anmeldeverfahren. Wenn die nicht passen, weil eine Konfiguration im Loadbalancer oder ReverseProxy nicht passt, dann kann Outlook auch keine Dialogbox liefern und ist "getrennt".

Etwas anderes ist es, wenn sich Outlook mit dem Server auf ein Verfahren geeinigt hat aber dann die Zugangsdaten nicht passen. Outlook zeigt dann die Kennworteingabe-Maske. Wenn Sie das richtige Kennwort eingeben und nicht weiter kommen, dann sind die Hinweise auf Kennwortbox vielleicht hilfreich. Es könnte ja auch ein falsch gesetzter SPN sein, der noch beim alten Dienstskonto des alten Exchange Clusters steht anstatt dem neuen Server.

Hoffentlich haben sie bis hierher ihren Fehler schon gefunden und behoben. Ansonsten heißt es doch dem System etwas genauer auf die Finger zu schauen.

Das Programm Fiddler hilft gut, wenn Sie HTTPS-Verbindungen analysieren wollen. Aber auch eine Kontrolle der DNS-Daten per "ipconfig /displaydns" oder "get-dsnclientcache" und der Serverdaten mit NSLOKUP oder Resolve-DNSName ist ein erster Anfang. Wenn Sie den Verdacht auf generelle Übertragungsprobleme haben, dann ist Wireshark natürlich das Mittel der Wahl um die darunterliegenden TCP-Verbindungen auf Anomalitäten zu untersuchen.

Test mit HTTP

Seit Exchange 2013 können sich Client per MAPI/HTTP anmelden und ich bin sicher, das mittlerweile die meisten Clients diesen Zugangsweg nutzen. In Office 365 hat MAPI/HTTP die Protokolle RPC/HTTP und RPC/TCP abgelöst. Für die Fehlersuche kann es durchaus interessant sein, auf dem Client ein Dauerlaufskript zu nutzen, dass z.B. jede Sekunde eine URL abfragt und den Authentication Header auswertet. Hier ein Beispiel, welches einfach eine ungültige Mailbox bei Office 365 abruft und sich den 401-Fehler einsammelt und sich den "www-authenticate"-Header holt

param (
   $url="https://outlook.office365.com/mapi/emsmdb/?MailboxId=1234"
)

[long]$count=0
$HeaderParams = @{ 'Authorization' = "Bearer" }

while ($true) {
   $count++
   if ($count%60 -eq 0) {
       $count=0
       write-host ""
   }
   $authheader=$null
   try {
      invoke-webrequest -UseBasicParsing -Headers $HeaderParams -Uri $url
   }
   catch {
      $authheader = $_.Exception.Response.Headers.WwwAuthenticate
   }
   if ($null-eq $authheader) {
      write-host "E" -backgroundcolor red -nonewline
   }
   else {
       write-host "." -backgroundcolor green -nonewline
   }
   start-sleep -seconds 1
}

Sicher könnte man das Skript noch erweitern und den Inhalt von "authheader" weiter auswerten. Aber das können Sie dann ja auf ihren individuellen Fall anpassen. 

Weitere Links