teelittle
Goto Top

Win2K12 AD: alles OK, aber Outlook-Zugriff auf externen HostedExchange "verlustbehaftet"

Hallo,

wir betreiben seit Jahren ein Domänen-Netzwerk mit einem Dutzend Clients und einem Win-2012R2 DC.
Netzwerkdrucker, SMB-Shares, MSSQL-DB für SAP Business One - alles läuft soweit.
E-Mail haben wir vor Jahren auf einen externen Hosted Exchange 2013 (df.eu) umgestellt, dazu haben wir Outlook-Clients (2010 und 2013), die im Cache-Modus arbeiten.
Jeder Client hat die Sammel-Mailbox sowie die Mailbox des jeweilien Users gleichzeitig geöffnet (Postfachgrößen 3..8 GB; die Sammel-Mailbox hat so um die 1.000 Ordner in max. drei Hierarchiestufen)

Seit der Umstellung der Rechner von Win 7x64 auf Win 10x64 vor ein paar Wochen haben wir massive Problem mit Verbindungsabbrüchen und zäher Synchronisation sowie einem volllaufenden "Postausgang"-Ordner (letzteres gab es allerdings sporadisch schonmal zu Win7-Zeiten bei größeren Anhängen von 0,5..4 MB - ohne erkennbare Regelmäßigkeit).
Alles in allem eine untragbare Situation, da wir täglich hunderte E-Mails bearbeiten müssen und dies der Haupt-Kommunikationsweg ist.

Andererseits ein schwer zu kommunizierendes Problem, weil es schlecht zu greifen ist und Outlook "ein bisschen" funktioniert - es ist also nicht wirklich kaputt, und keiner ist bereit, den Schwarzen Peter zu nehmen.
Ich habe jetzt den Support von DELL (Hardware mit OEM-Office), Microsoft (Outlook) und unserem lokalen EDV-Dienstleister durch, und jedesmal heißt es, man solle dieses und jenes updaten oder neu installieren usw.
Um des lieben Friedens willen habe ich Office komplett neu installiert, schließlich eine komplette Win-10-Neuinstallation auf neuer Platte mit Office 365 (=Outlook 2019) gemacht - immer noch das gleiche Problem *grrr*
Und keiner der Dienstleister macht sicht die Mühe, mal vom Problem her zu denken, was ich im labilen Verbindungsstatus von Outlook sehe (d. Screenshot):
outlook_hostedexchange--labilerverbindungsstatus

Heute bin ich auf die Idee gekommen, auf einem Client einen VPN-Client zu installieren - und siehe da: Outlook synchronisert wie am Schnürchen, und der "Postausgang" ist in zwei Sekunden leergefegt.
Worin ich meine These bestätigt sehe, dass die Software OK ist, sondern irgendwas in unserem LAN faul ist.

Die Frage ist nur: wie gehe ich jetzt ran an die Analyse - denn intern spüre ich keine Funktionsstörungen...

Content-ID: 553760

Url: https://administrator.de/contentid/553760

Ausgedruckt am: 08.11.2024 um 05:11 Uhr

TRDSRLZ
TRDSRLZ 03.03.2020 aktualisiert um 17:40:00 Uhr
Goto Top
Wenn du den Fehler im Netzwerk vermutest, solltest du da ansetzen.

Ping, nslookup und tracert auf den FQDN unter dem der Exchange erreichbar sein soll. Split DNS, respektive DNS Weiterleitung habt ihr ja sicher sauber oder?

Aber Moment. Ich hab jetzt gesehen mit VPN geht's. . Wo befinden sich die Clients die Probleme haben? Innerhalb oder außerhalb deines LANs?
TRDSRLZ
TRDSRLZ 03.03.2020 um 17:38:14 Uhr
Goto Top
Und den hier hast du auch schon mal gemacht?

https://testconnectivity.microsoft.com/
LordGurke
LordGurke 04.03.2020 aktualisiert um 01:56:34 Uhr
Goto Top
Vielleicht wird die Anzahl Verbindungen pro IP auf dem externen Server limitiert und ihr rennt da die ganze Zeit rein?
Der Client mit dem VPN-Zugang hat dann seine eigene IP und rennt nicht in das Limit.
Da müsste DF also mal schauen, wo das Limit steht und das ggf. anpassen.
TeeLittle
TeeLittle 04.03.2020 um 09:24:55 Uhr
Goto Top
Hi LordGurke,
da die Probleme erst mit der Umstellung von Win7 auf Win10 entstanden sind und wir nur mit 3 Clients á 2 Postfächer auf den Hosted Exchange zugreifen (das sollte jetzt keine außergewöhnliche Anzahl sein), halte ich diese Theorie für nicht plausibel.
Trotzdem danke für den Hinweis - ich teste mal, ob das Problem auch auftaucht, wenn alle Clients über VPN über den gleichen Server laufen.
Gruß
TeeLittle
TeeLittle
TeeLittle 04.03.2020 um 16:38:16 Uhr
Goto Top
Ich hab jetzt gesehen mit VPN geht's. . Wo befinden sich die Clients die Probleme haben? Innerhalb oder außerhalb deines LANs?

Alle Clients hängen im (unsegmentierten) LAN, DNS macht der DC.
Gateway ist eine Fritzbox (7272), die mit einem Ethernetport an der Glasfaseranbindung nach draußen hängt.
TeeLittle
TeeLittle 04.03.2020 um 19:22:58 Uhr
Goto Top
Hi TRDSRLZ,

danke für die Hinweise. Habe alles nochmal nach bestem Wissen geprüft und sehe keinen Fehler (bin ich blind??).
Reverse-DNS etc. muss ich mich nochmal einlesen - aber warum sollte es beim Wechsel Win7 > Win10 einen Funktionseinbruch geben??

tracert ist m.E. auch unauffällig:
C:\Windows\system32>tracert exchange2013.df.eu

Routenverfolgung zu exchange2013.df.eu [80.67.16.224] über maximal 30 Abschnitte:

  1    <1 ms    <1 ms    <1 ms  192.168.1.254
  2     6 ms     6 ms     6 ms  100.124.250.1
  3     5 ms     5 ms     5 ms  100.127.1.6
  4     6 ms     5 ms     5 ms  100.127.1.7
  5     5 ms     5 ms     5 ms  185.22.45.31
  6     6 ms     6 ms     5 ms  185.22.45.30
  7     6 ms     5 ms     5 ms  et-7-0-0-u100.cr-polaris.fra1.bb.godaddy.com [80.81.192.239]
  8     6 ms     7 ms     9 ms  ae0.cr-antares.fra10.bb.godaddy.com [87.230.115.1]
  9     8 ms     8 ms     8 ms  87.230.114.4
 10     8 ms     9 ms     8 ms  ae0.sr-jake.cgn1.dcn.heg.com [87.230.114.222]
 11     8 ms     8 ms     8 ms  exchange2013.df.eu [80.67.16.224]

Ablaufverfolgung beendet.
TeeLittle
TeeLittle 09.03.2020 aktualisiert um 12:21:50 Uhr
Goto Top
Hallo, TRDSRLZ,

danke für den Hinweis auf testconnectivity - kannte ich in der Tat noch nicht.
Das Tool kommt auf allen Rechnern zu den gleichen Ergebnissen - ob Outlook nun reibungslos oder mit Hemmungen läuft.
Ist mir wirklich schleierhaft...

Als erstes wird die Verbindung über Autodiscover getestet - die erste autodiscover-Möglichkeit wird schnell als nicht gangbar verworfen, aber bis erkannt wird, dass über die zweite autodiscover-Möglichkeit (Anfrage an autodiscover.DomainName.de:443/...) keine Verbindung auf Port 443 möglich ist, vergehen glatte ca. 20 Sekunden...

Es wird versucht, die mögliche AutoErmittlungs-URL https://autodiscover.DomainName.de:443/Autodiscover/Autodiscover.xml zu testen.
Fehler beim Testen dieser potenziellen AutoErmittlungs-URL.
[...]
Weitere Details
Verstrichene Zeit: 21013 ms.
Testschritte
Es wird versucht, den Hostnamen autodiscover.DomainName.de im DNS aufzulösen.
Der Hostname wurde erfolgreich aufgelöst.
Weitere Details
Zurückgegebene IP-Adressen: xx.yy.zz.nn
Verstrichene Zeit: 0 ms.
Es wird getestet, ob TCP-Port 443 auf Host autodiscover.DomainName.de überwacht wird/geöffnet ist.
Der angegebene Port ist blockiert, wird nicht überwacht oder sendet nicht die erwartete Antwort.
Weitere Informationen zu diesem Problem und zu möglichen Lösungen
Weitere Details
Es ist Netzwerkfehler bei der Kommunikation mit dem Remotehost aufgetreten. .
Verstrichene Zeit: 21013 ms.

Am Ende kommt aber heraus, dass die Verbindung über RPC over HTTPS hergestellt werden kann, und das funktioniert ja auch.

Außerdem gibt es eine Warnung (aber keinen Fehler) bzgl. SSL-Zertifikaten:

Die Zertifikatketten werden auf Kompatibilitätsprobleme mit Windows-Versionen analysiert.
Test mit Warnungen bestanden. Erweitern Sie die zusätzlichen Details.
Weitere Details
Die Microsoft-Verbindungsuntersuchung kann die Zertifikatkette nur überprüfen, wenn die Funktion zum Aktualisieren von Stammzertifikaten aus Windows Update verwendet wird. Möglicherweise wird Ihr Zertifikat von Windows nur dann als vertrauenswürdig eingestuft, wenn die Funktion zum Aktualisieren von Stammzertifikaten aktiviert ist.

Ich kriege bei den Symptomen keine Verbindung dazu, dass der OS-Wechsel von Win 7 zu Win 10 ursächlich gewesen zu sein scheint...