none
Verbindungsabbruch in Outlook 2007/2010 RRS feed

  • Frage

  • Hallo zusammen,

    wir haben hier ein seltsames Phänomen das seit einiger Zeit auftritt. Erstmal ein paar Eckdaten zur Umgebung:

    Exchange 2010 mit insgesamt 5 Server (2x HUB/CAS/MB und 3x MB)

    Die beiden HUB/CAS/MB Server sind über einen Citrix Netscaler gebalanced (vorher über NLB, CAS Array existiert noch). Die 3x MB Server sind alle Mitglied einer DAG.

    Das Patchlevel der Exchange Server ist auf SP1 RU2

    Zum Einsatz kommt weiterhin auf allen Clients Outlook 2007 und vereinzelt auch Outlook 2010.

    Nun zum eigentlich Problem:

    Während dem arbeiten passiert es bei einigen Nutzern (nicht bei allen, bis jetzt haben sich ca. 10-12 User mit diesem Problem bei uns gemeldet) das die Outlookverbindung kurz wegbricht und dann ein Popup erscheint das dazu auffordert die Anmeldedaten einzugeben ("Fallback" auf Outlook Anywhere, auch so zu sehen im Outlook Verbindungsstatus).

    Weder auf Server noch auf Clientseite wird etwas im Ereignisprotokoll protokolliert.  

    Weiterhin haben wir schon festgestellt das nur die Verzeichnisverbindungen verloren gehen. Zugriffe auf GAL, Stellvertreterfunktion etc. sind nicht möglich, allerdings können weiterhin E-Mails verschickt werden und auf freigegebene Kalender zugegriffen werden.

    Autodiscover und Zertifikat sind auch in Ordnung (DNS Einträge für autodiscover existieren Intern und Extern und sind auf den Virtuellen Directorys auch entsprechende eingetragen, im Zertifikat sind alle Namen abgedeckt).

    Auch der Autodiscover Test über www.testexchangeconnectivity.com läuft fehlerfrei durch.

    Hat jemand evtl. noch eine Idee woran da Problem liegen könnte und wie man es am besten behebt? 

    Freitag, 20. April 2012 11:56

Antworten

  • Hallo Frickeladmin,

    klingt für mich auf den ersten Blick nach einem Load-Balancing Problem.

    Da ein HW-Load-Balancer mit zum Einsatz kommt, könnte das Ganze mit nicht korrekt konfigurierter Stickyness / Persistence zu tun haben.

    Kurz:

    Wichtig und Pflicht ist für Outlook / Outlook-Anywhere Verbindungen, dass der Client für die Dauer der Session immer wieder vom Loadbalancer zum gleichen CAS-Server verbunden wird. Dies kann am Loadbalancer für die verschiedenen Protokolle (https / MAPI ..) über bestimmte Einstellungen realisiert werden. Der Punkt ist dass der Loadbalancer anhand irgendeines Kriteriums den Client wiedererkennen muss und diesen dann eben immer wieder auf den gleichen Server verteilt. Wenn das nicht korrekt gemacht wird, kann es zu Verbindungs-Abbrüchen und Fehlern kommen.

    Meist kommt bei MAPI - Verbindungen als Persistence-Methode "Source IP" zum Einsatz. Dass heisst der Loadbalancer merkt sich die Clients anhand ihrer Quell-IP-Adresse.  Nun zum Problem : Wenn deine Clients zum Beispiel hinter NAT-Verfahren versteckt sind, kann der Loadbalancer die Persistence nicht gewährleisten, da ja immer die gleiche IP-Adresse kommt.

    Prüfe also folgende Punkte :

    zunächst: Wie sieht euer Load-Balancer Deployment aus.

    a) welche Persistence Methode ist am Loadbalancer für das entsprechende Client-Protokoll konfiguriert

    b) Haben die Clients mit den Problemen Gemeinsamkeiten  (z.b. alle hinter NAT oder im gleichen Subnet oder dergleichen)

    ein paar Hilfen dazu gibt es auch noch hier bei Frank : http://www.msxfaq.de/cluster/loadbalancer.htm

    ein Link zur Anleitung der Konfiguration des Netscaler findet sich hier: http://technet.microsoft.com/en-us/exchange/gg176682


    Grüße, Christoph

    • Als Antwort markiert Frickeladmin Montag, 23. April 2012 10:45
    Freitag, 20. April 2012 15:24

Alle Antworten

  • Hallo Frickeladmin,

    klingt für mich auf den ersten Blick nach einem Load-Balancing Problem.

    Da ein HW-Load-Balancer mit zum Einsatz kommt, könnte das Ganze mit nicht korrekt konfigurierter Stickyness / Persistence zu tun haben.

    Kurz:

    Wichtig und Pflicht ist für Outlook / Outlook-Anywhere Verbindungen, dass der Client für die Dauer der Session immer wieder vom Loadbalancer zum gleichen CAS-Server verbunden wird. Dies kann am Loadbalancer für die verschiedenen Protokolle (https / MAPI ..) über bestimmte Einstellungen realisiert werden. Der Punkt ist dass der Loadbalancer anhand irgendeines Kriteriums den Client wiedererkennen muss und diesen dann eben immer wieder auf den gleichen Server verteilt. Wenn das nicht korrekt gemacht wird, kann es zu Verbindungs-Abbrüchen und Fehlern kommen.

    Meist kommt bei MAPI - Verbindungen als Persistence-Methode "Source IP" zum Einsatz. Dass heisst der Loadbalancer merkt sich die Clients anhand ihrer Quell-IP-Adresse.  Nun zum Problem : Wenn deine Clients zum Beispiel hinter NAT-Verfahren versteckt sind, kann der Loadbalancer die Persistence nicht gewährleisten, da ja immer die gleiche IP-Adresse kommt.

    Prüfe also folgende Punkte :

    zunächst: Wie sieht euer Load-Balancer Deployment aus.

    a) welche Persistence Methode ist am Loadbalancer für das entsprechende Client-Protokoll konfiguriert

    b) Haben die Clients mit den Problemen Gemeinsamkeiten  (z.b. alle hinter NAT oder im gleichen Subnet oder dergleichen)

    ein paar Hilfen dazu gibt es auch noch hier bei Frank : http://www.msxfaq.de/cluster/loadbalancer.htm

    ein Link zur Anleitung der Konfiguration des Netscaler findet sich hier: http://technet.microsoft.com/en-us/exchange/gg176682


    Grüße, Christoph

    • Als Antwort markiert Frickeladmin Montag, 23. April 2012 10:45
    Freitag, 20. April 2012 15:24
  • Hallo,

    nach weiteren Versuchen und dem hinzufügen von Kerberos Authentifizierung zum Exchange, haben wir festgestellt das auf dem Netscaler noch entsprechende Timeouts auf 2 bzw. 3 Minuten konfiguriert waren.

    Das Problem trat nämlich immer noch auf, nachdem wir die Verbindungen fest auf einen der CAS Server gelenkt hatten. 

    Vielen Dank nochmal an Christoph :-)

    Gruß

    Frickeladmin

    Montag, 23. April 2012 10:45