7
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):
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...
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):
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...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 553760
Url: https://administrator.de/contentid/553760
Ausgedruckt am: 04.12.2024 um 18:12 Uhr
7 Kommentare
Neuester Kommentar
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?
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?
1
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.
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.
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
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
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.
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:
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.
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.
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:
Ich kriege bei den Symptomen keine Verbindung dazu, dass der OS-Wechsel von Win 7 zu Win 10 ursächlich gewesen zu sein scheint...
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.
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.
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...
