Frage Outlook kann über Direct Access 2012 R2 keine Verbindung zu einem Exchange 2013-Cluster mit Lastenausgleich herstellen


Wir haben einen Exchange 2013 SP1-Cluster mit Lastenausgleich, auf dem MAPI über HTTP ausgeführt wird.

Client-Konnektivität in unserem eigenen Netzwerk funktioniert einwandfrei, während Clients, die über Direct Access verbunden sind, keine Verbindung herstellen. Die Outlook-Anmeldung am Client zeigt absolut keinen Fehler.

Auf dem Direct Access-Server wird 2012 R2 ausgeführt, die Clients sind alle Windows 8.1. Alles ist gepatcht.

Ich habe die letzten Wochen wie verrückt gesucht, und die einzigen interessanten Treffer, die ich bekomme, sind TMG 2010 (UAG), die die Anfragen aufgrund der Quell-IP-Änderung herausfiltert (der Exchange Load Balancer). Da ist ein Wissensdatenbankartikel (982604) das beschreibt das und a eher heftiger Blogbeitrag über das Problem von Premier-Support, aber leider funktioniert das Skript nicht auf unserem Server, da es nicht TMG und es ist Windows Server 2012 R2 ..

Ich bin hier ratlos. Ich werde diese Frage eine Woche lang beantworten, dann werde ich einen erstklassigen Supportfall bei Microsoft ansprechen.


19
2018-06-17 14:54


Ursprung


Meinst du MAPI über HTTP? Welche Version von Outlook? Können Sie Details oder Screenshots von den DA-Clients Outlook veröffentlichen, Verbindungsstatus anzeigen und E-Mail-Autokonfiguration testen? Was verwenden Sie zum Lastenausgleich? - mfinni
@mfinni Sorry, natürlich MAPI :-) Outlook 2013 SP1 mit den neuesten Patches. Unser Lastausgleicher ist KEMP VLM-1000. Ich werde versuchen, einen Screenshot zu posten, aber die Office-Installation ist norwegisch .. wird Ihnen wahrscheinlich nicht viel Sinn machen? - pauska
Nun, was wir suchen ist, wenn der Client versucht, eine Verbindung zur internen AutoErmittlungs-URL (wie es sein sollte, mit DA) oder der externen, die möglicherweise fehlschlagen und Ihre Probleme verursachen könnte. Eine Menge davon könnte auf Ihre DNS-Konfiguration zurückzuführen sein. Wenn AutoErmittlung korrekt funktioniert, aber ein Teil der Verbindung fehlschlägt. - mfinni
@mrfinni Ich habe das überprüft, da wir kein erzwungenes Tunneling verwenden. Wir haben ein Split-Brain-DNS mit einem einzigen Namespace, so dass alle internen und externen Domänen explizit getunnelt werden. In Wirklichkeit bedeutet dies, dass der Client keinen unserer externen DNS-Einträge auflösen kann. Ich werde eine englische Version von Outlook installieren, wenn ich die Zeit habe .. - pauska
EvanAnderson: Ich werde später an diesem Tag Screenshots und Protokolle bereitstellen. Azeth: Entschuldigung, es ist SP1 (in der Q geklärt). Longneck: Es macht keinen Unterschied. Ich weiß, dass der LB die Quell-IP (Nat) neu schreibt, und ich denke, dass dies ist, wo es bricht. - pauska


Antworten:


Ich habe diese Art von Problem zuvor (auf einer HAproxy-basierten Lösung), in meinem Fall war es Exchange 2010 und ISA 2006 Server mit dem RPC-Filter aktiviert. Wir haben den RPC-Filter und glückliche Tage wieder deaktiviert ...

Ich habe mich ein wenig um mich selbst gekümmert und das habe ich gefunden:

http://geek.martinwahlberg.com/problem-using-forced-tunneling-mode-in-directaccess

Das schlägt Probleme mit Outlook, DirectAccess und dem Tunnel-Modus vor, die nie gelöst wurden (außer einem möglichen Client-Registrierungs-Hack ...), also habe ich mich gefragt, ob es das Gleiche war. Er hat seine Fall-ID in den Kommentaren. Wenn Sie also zu MS gehen, können Sie Ihrem Fall etwas Gewicht hinzufügen.


1
2017-09-20 14:39



Ich habe auch eine Menge Beiträge über RPC-Filter und ISA gefunden, aber leider benutzen wir keines von beiden. Unsere Umgebung läuft jetzt mit reinem HTTP-MAPI, daher sollte überhaupt kein RPC beteiligt sein. Ich habe das ganze Problem vorerst aufgegeben und den Outlook-Verkehr aus dem DA-Tunnel ausgeschlossen. - pauska


Welche Version von Exchange 2013 werden die CAS-Server ausgeführt? Ich bin nicht vertraut mit "KEMP VLM-1000", aber ich habe Load Balanced Exchange 2013 mit NGINX und kam zu einem ähnlichen Problem mit Pre Exchange 2013 SP1, wo RPC Last nicht ausgeglichen über HTTPS funktioniert.

In der kürzlich erschienenen Version von Exchange 2013 SP1 wurde MAPI über HTTPS implementiert, um dieses Problem zu beheben. Ich habe es noch nicht getestet

Exchange 2013 SP1 - MAPI über HTTPS

Lassen Sie mich wissen, wie Sie vorankommen, da ich noch nicht dazu gekommen bin, dies zu implementieren, da ich gerade Haproxy zum TCP-Lastausgleich zwischen den CAS-Servern verwendet habe.


0
2018-06-30 20:56



Hallo. Wir verwenden MAPI über HTTPS auf SP1 (und RPC über HTTPS für Pre-2013-Clients). Dies alles wurde in der Frage behandelt. - pauska
Nur weil du es gerade bearbeitet hast! lol. Haben Sie die im Link beschriebenen Schritte ausgeführt? Haben Sie versucht, die Exchange-Mapi-Protokolldateien zu testen und zu durchsuchen?% ExchangeInstallPath% Logging \ MAPI-Clientzugriff \% ExchangeInstallPath% Logging \ HttpProxy \ Mapi \ - Aceth
Wenn es möglich ist, versuchen Sie, Ihren Lastenausgleich für NGINX auszuwechseln (sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch 100 100 sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch 100 100 sch sch sch sch sch sch dieser -100 sch sch 100 sch 100 sch 100 sch 100 sch 100 sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch 100 sch sch sch sch sch sch sch sch sch 100 sch sch sch sch sch 100 sch sch sch sch sch 100 sch sch sch sch sch dieser Die eine, die ich für die MAPI über HTTP implementieren möchte, basiert auf .. sch sch sch 100 100 100 100 sch sch 100 100 100 sch 100 100 sch sch 100 100 100 sch 100 100 100 100 sch 100 100 sch 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 dieser - Aceth
oder wenn Sie keinen HTTP-basierten Load Balancer benötigen, der versucht, HAProxy zu verwenden, ist das, was ich getan habe und funktioniert gut. - Aceth
Das Ersetzen unseres Loadbalancers, nur weil die Outlook-Verbindung DirectAccess durchbricht, ist keine Option. Wir haben viel Geld dafür bezahlt, und das Lastenausgleichsverfahren für alles, was wir ausführen (RDS-Farmen, Gateway-Server, Proxies usw.), ist perfekt. Es ist nur unter DA, dass Outlook bricht. Ich habe diese Protokolle nicht überprüft, also mache ich das später, wenn ich einen neuen Test von zu Hause aus mache. - pauska