Versenden großer Anhänge

[JoeJedermann 0]

Hallo zusammen,

 

ein Kunde bzw der Geschäftsführer eines Kunden kann häufig keine großen Anhänge versenden.

Groß bedeutet in diesem Fall schon 3 MB.

Da er unter Outlook 2010 permanente Verbindungsabbrüche zum Exchange (2010) hatte, die ich auch in einer virtuellen Umgebung reproduzieren konnte habe ich sein Benutzerprofil (das ohnehin auch andere Probleme hatte) neu erstellt und nach erfolgreichen Tests in der virtuellen Umgebung mit Office 2016 sein lokales Profil auf dem Laptop gelöscht und Office 2016 installiert.

 

Die Verbindung ist nun stabil, es gibt keinerlei Abbrüche mehr. Mails lassen sich versenden.

 

Kurz vor Feierabend ruft er wieder an, er kann wieder keine Mails mit "großen" Anhängen versenden.

Wir vereinbaren einen Termin für später, als ich ihn dann anrufe ist die mail samt Anhang rausgegangen.

Ich versuche also mir diese Mail weiterzuleiten und es funktioniert wieder nicht.

Zu diesem Zeitpunkt gab es keine Verbindungsabbrüche, wenn ich den Versand aber manuell anstosse steht in der Fehlermeldung timeout bei der Verbindung zu Exchange...

 

Grenzwerte sind hoch genug, throttling policy unlimitiert und ews laufen ordnungsgemäß.

Der Kunde nutzt outlook anywhere.

 

Ich steh total auf dem Schlauch und wäre dankbar für jegliche Hinweise...!

 

VG

Joe

bearbeitet 19. Juni 2017 von JoeJedermann

[testperson 1.680]

Hi,

 

welcher Virenscanner läuft denn auf dem Client und Server? Hat der irgendwelche spannenden Features um Outlook zu schützen / im Traffic rumzuschnüffeln?

Steht zwischen Client und Exchange eine Firewall o.ä.?

Welchen Patchstand hat der Exchange?

 

Gruß

Jan

[JoeJedermann 0]

Moin,

 

danke erstmal für die Rückmeldung.

 

Die Exchange Version ist 14.03.0351.000, SP3, UR17.

 

Auf dem Server läuft gar kein Virenscanner, auf dem Client SEP.

 

Outlook-Feature ist nicht installiert. Sämtliche Outlook Add-Inns sind deaktiviert.

 

Die Firewall dazwischen, eine Fortigate leitet eingehende Anfragen stumpf weiter, andere user mit der gleichen Konstellation haben dieses Problem nicht, OA wird von allen genutzt.

[testperson 1.680]

Der Exchange ist (gehosted) im RZ und alle greifen von überall per OA auf den Exchange zu?

Oder greifen die User nur von unterwegs / zu Hause per OA auf den Exchange zu?

Welche Bandbreiten bzw. was für Leitungen sind denn wo und wie involviert?

 

"Andere User" versenden auch entsprechend "häufig" Anhänge bzw. wurde es bei anderen mal intensiv getestet, ob es da definitiv keine Probleme gibt?

Wie oft ist den "häufig" beim GF und was für Anhänge sind das?

Das ist schon immer so? Oder wurde irgendetwas geändert?

 

Die Fortigate macht (definitiv) einfach nur NAT auf den Exchange? Bis jetzt war es immer die Firewall (Auch wenn der Netzwerker die Firewall schon 3x geprüft hat) ;)

[JoeJedermann 0]

Genau, MX wird im RZ gehostet, Zugriff erfolgt immer per OA.

Seine Bandbreite Zuhause kenne ich nicht, hab es aber auch mit LTE 100 Mbit getestet.

 

Häufig bedeutet jeden Tag, getestet wurde mit pdf und doc/docx.

Beim GF besteht das Problem schon länger bzw immer wieder mal.

 

Geändert wurde nichts, abgesehen davon, dass ich die Grenzwerte nochmal erhöht habe und ihm eine unlimited throttling policy erstellt und zugewiesen hab.

Laut fw-admin macht die forti nur das NAT auf die beiden CAS Server (Sorry, dass Array hätte ich noch erwähnen sollen).

 

Ich warte grad noch auf Rückmeldung diesbezüglich um mir die Regeln selbst nochmal anzuschauen.

Ich hatte auch dpi oder ssl offloading auf der fw im Verdacht aber wenn eines von beidem die Fehlerquelle wäre würde es ja durchgehend nicht funktionieren...

[Piranha 18]

Welche Art von Attachments sind das? Unterschiedlich, oder tritt es evtl. immer bei einem bestimmten Dateityp auf?

Tritt das "Phaenomeaen" auch auf wenn er die Anhaenge "zippt"?

[JoeJedermann 0]

Ja, ist unterschiedlich. "Komischerweise" funktioniert es in 8/10 Fällen, wenn Outlook geschlossen und wieder geöffnet wird. Dann bekomme ich nämlich auch eine Authentifizierungsabfrage, die ich beim ersten Start nicht bekomme. Ich gehe also jetzt davon aus, dass es ein Authentifizierungsproblem ist, möglicherweise durch timeouts ausgelöst und versuche das jetzt zu eruieren...

[JoeJedermann 0]

Update

 

Es lag zunächst tatsächlich mal wieder an der firewall, auf der ssl offloading und dpi aktiviert war.

Ich habe ssl offloading dann auch auf den cas Servern aktiviert und siehe da, es funktioniert.

Gestern hatte ich frei, komme heute zurück und tadaa- nichts geht mehr- zumindest nicht der Versand von Anhängen über 2 MB.

Die einzige Änderung die ich feststellen konnte war, dass statt basic wieder ntlm für oa eingestellt war- ist natürlich niemand gewesen...

Rückgängig gemacht, Dienste neugestartet und- nichts...

Ich bin echt ratlos mittlerweile...

[testperson 1.680]

Ist da noch ein Windows NLB oder Hardware LB vor bzw. wer macht das Loadbalancing?

D.h. die Firewall macht immer noch eine DPI evtl. auch noch andere Security Features?

[NorbertFe 2.035]

Die Firewall "leitet stumpf weiter" und macht dabei DPI? Wir haben unterschiedliches Verständnis von "stumpf weiterleiten" ;)

Die einzige Änderung die ich feststellen konnte war, dass statt basic wieder ntlm für oa eingestellt war- ist natürlich niemand gewesen...

Wo hast du das denn konfiguriert? Im IIS oder per EMS?

[JoeJedermann 0]

Sowohl als auch, da ich ja nicht wissen kann wer möglicherweise wo was angefasst hat.

Stumpf weiterleiten...glaube wir haben da schon ein ähnliches Verständnis aber ich bin da nicht der fw-admin und der hat gesagt "wird stumpf weitergeleitet".

Der Punkt ist ja die Einstellung wurde nicht nochmal angefasst- wenn es also jetzt noch an der firewall liegt kann ich es nicht beurteilen, ich habe lediglich lesenden Zugriff und muss auch zugeben, dass fortigate mir ein ziemliches Rätsel ist...

[NorbertFe 2.035]

Sowas "nur" im exchange konfigurieren. Wenn du es über die iis Verwaltung tust setzt der Exchange das zurück.

[JoeJedermann 0]

Ja, ist mir dann auch aufgefallen^^

 

Ich bin bei der Recherche noch auf die Arbeitsprozesse auf dem IIS, bzw die Timeout-Einstellungen und die Wiederverwendung von Arbeitsprozessen gestoßen.

 

Kann ich rpc gefahrlos in einen neuen Anwendungspool verschieben?

 

Dann würde ich nämlich die Wiederverwendung von Arbeitsprozessen deaktivieren und den timeout für die Warteschlangenlänge erhöhen...

 

Edit: ok, das war's auch nicht...

bearbeitet 26. Juni 2017 von JoeJedermann

[JoeJedermann 0]

Es ist wirklich merkwürdig- zwischendurch liessen sich gestern etwa eine Stunde lang wieder sämtliche Anhänge versenden, mit einem Testuser reproduzierbar.

 

Die timeout-Einstellungen auf dem Anwendungspool hatte ich vorher wieder zurückgesetzt, nachdem sich die Testergebnisse dadurch nicht geändert hatten.

 

Ohne dass weitere Änderungen vorgenommen worden wären funktionierte es dann wieder nicht. Keine Einträge dazu im Eventlog auf den Servern.

 

Um genau zu sein- es funktioniert genau 1x, danach bleibt wieder alles im Postausgang hängen, wir aber versandt wenn ich outlook schliesse und wieder öffne.

 

Keine Änderungen in der Netzwerkkonnektivität, auch keine drops oder timeouts auf der Firewall...

 

Teilweise trennt Outlook die Verbindung clientseitig und stellt sie wieder her, aber auch das ist nicht einheitlich, dh manchmal wenn der Versand nicht funktioniert trennt outlook, manchmal ist die Verbindung aber durchgängig hergestellt, der Versand funktioniert aber trotzdem nicht ohne zwischendurch zu schliessen...

 

In den rpc logs kann ich keine Unterschiede erkennen, die Verbindung wird hergestellt und etwas später wieder sauber getrennt, in beiden Fällen.