In unserem 4er EX2016 DAG Verbund (jew. 2x Pärchenserver mit allen Rollen) musste ich die MaxAttachmentSize für Mailempfang/Versand hochdrehen.
Da ich eh am patchen war, hab ich jew. 1x Server der Pärchen in Downtime genommen und entsprechend durchgestartet. (das ist nur abends erlaubt :-) Und das über zwei abende.
Downtime bedeutet bei uns... "Maintenance Mode, Umschaltung der Datenbank, Message Redirect, Load Balancing Server deaktivieren, SMTP passend umlenken, Clusternode suspend, Dienste stoppen....
Da ich nun schon 2 Abende dran sitze, hab ich wenig Lust, nochmals 2x abende zu verbringen... Da die Größe nochmals angepasst werden muss. 😤
Was passiert wenn ich den TransportDienst im laufenden Betrieb durchstarte (MIttagspause z.B.)..?. Den IIS muss ich nicht durchstarten, da die Änderungen dort nicht nötig sind.
Riskieren? Oder doch alles an zwei Abenden (unser SMTP DNS Eintrag dauert immer ein bisschen, bis gewissen ERP/CRM Systeme das gezogen haben)....
Da passiert nix, außer dass der Dienst neustartet und ggf. im transport befindliche Nachrichten abgebrochen und neu übermittelt werden.
Da passiert nix, außer dass der Dienst neustartet und ggf. im transport befindliche Nachrichten abgebrochen und neu übermittelt werden.
Gut zu wissen. Bis dato gab es die ANforderung nicht "nur den Transportdienst" durchzustarten. Ich nutze solche Anforderungen immer direkt mit zum Patchen der Systeme... und das kann man gefühlt wöchentlich machen ;-)
Aktuell kämpfe ich noch mit den Einstellungen... (Receive Connectoren hochgedreht, TransportConfig "ExternalDSN/InternalDSN,..."hochgedreht, Mailboxeinstellungen geprüft, IIS Einstellungen gesetzt) und trotz NEUSTART aller Server, bleibt es bei den obligatorischen +-25MB .
bleibt es bei den obligatorischen +-25MB .
Hängt ja vielleicht auch am vorgeschalteten reverseproxy. ;) ansonsten wäre es interessant, welcher Client wann welchen Fehler liefert.
bleibt es bei den obligatorischen +-25MB .
Hängt ja vielleicht auch am vorgeschalteten reverseproxy. ;) ansonsten wäre es interessant, welcher Client wann welchen Fehler liefert.
Der Spamfilter (extern gehostet) zeigt im Tracking aber eher jew. zu einem der vier Mailserver. D.h. die Verbindung wird aufgebaut - aber einer der server lehnt ab...
Clientprobleme kann ich ausschließen. Ich versende zum Test ja von Extern. Mein Provider lässt das Versenden bis 100MB zu. Getestet per Thunderbird + Webmail des Anbieters.
Im Spamfilter sehe ich die Mail ja durchgehen bis zu den Mailservern. Dort wird es dann abgelehnt.
Ich suche noch nach der Nadel im Heuhaufen :-)
Wie findet man eigentlich heraus, welcher ReceiveConnector für Mails von Extern tatsächlich verwendet wird? Einfach mit Messagetracking im detail?
Ich habe da eine MIgrations Altlast meines Vorgängers in Verdacht. Ich hab die ReceiveConnector zwar über IP Ranges von einander abgeschottet - aber wer weiss.
Wir haben für interne Server zwei Connectoren (Server die nur intern mails versenden dürfen, Server die intern+extern mails versenden dürfen).
Wie findet man eigentlich heraus, welcher ReceiveConnector für Mails von Extern tatsächlich verwendet wird? Einfach mit Messagetracking im detail?
Ich habe da eine MIgrations Altlast meines Vorgängers in Verdacht. Ich hab die ReceiveConnector zwar über IP Ranges von einander abgeschottet - aber wer weiss.
Wir haben für interne Server zwei Connectoren (Server die nur intern mails versenden dürfen, Server die intern+extern mails versenden dürfen).
Das findet man raus, indem man in die SMTP Receive Logs schaut. Da sollte der jeweils verwendete Connectorname auftauchen. Ein Grund, warum man für externe Mails nicht den Default Connector verwenden sollte (IMHO). Da sollte man dann übrigens auch den Fehler finden, warum die Mail nicht durchkommt. Ich tippe mal auf einen der vorhandenen Connectoren, der ein kleineres Limit hat.
Wie findet man eigentlich heraus, welcher ReceiveConnector für Mails von Extern tatsächlich verwendet wird? Einfach mit Messagetracking im detail?
Ich habe da eine MIgrations Altlast meines Vorgängers in Verdacht. Ich hab die ReceiveConnector zwar über IP Ranges von einander abgeschottet - aber wer weiss.
Wir haben für interne Server zwei Connectoren (Server die nur intern mails versenden dürfen, Server die intern+extern mails versenden dürfen).
Das findet man raus, indem man in die SMTP Receive Logs schaut. Da sollte der jeweils verwendete Connectorname auftauchen. Ein Grund, warum man für externe Mails nicht den Default Connector verwenden sollte (IMHO). Da sollte man dann übrigens auch den Fehler finden, warum die Mail nicht durchkommt. Ich tippe mal auf einen der vorhandenen Connectoren, der ein kleineres Limit hat.
Zwischenzeitlich hab ich einfach zum testen..... einen ReceiveConnector der eigentlich anhand der IP Ranges gedacht ist, das nur bestimmte Server IPs nach EXTERN Emails mit Mailgrösse X versenden dürfen. - Dem Connector habe ich nun die selbe Größe zugewiesen - Transportdienste durchgestartet und schon gehts.
Damit hab ich weitere Arbeit gewonnen, da das Verhalten nicht zu den Einstellungen passt.
Wir haben eine separaten ReceiveConnector für unseren externen Spamfilter, von dem die Mails mit einer bestimmten IP kommen. Das konnte ich in der Firewall auch nachstellen.
Warum aber nun ein anderer ReceiveConnector zieht, obwohl die IPs dort gar nichts mit der Spamfilter IP Zu tun haben....
Ärgerlich und verwirrend zugleich.
Mal schauen, ob die Kollegen SMTP Traffic von extern "aus versehen" über einen Load Balancer laufen lassen - der natürlich mit ner anderen IP kommt. Da ein paar DMZ Systeme über die Load Balancer Range kommen, wäre das der Ansatz. 😬
Warum aber nun ein anderer ReceiveConnector zieht, obwohl die IPs dort gar nichts mit der Spamfilter IP Zu tun haben....
Dazu müßte man erstens im Log schauen, welcher Connector verwendet wird und dann anhand der jeweiligen Connectoreigenschaften rausfinden, warum. ;) Eigentlich ist das nicht sonderlich komplex an der Stelle.
Warum aber nun ein anderer ReceiveConnector zieht, obwohl die IPs dort gar nichts mit der Spamfilter IP Zu tun haben....
Dazu müßte man erstens im Log schauen, welcher Connector verwendet wird und dann anhand der jeweiligen Connectoreigenschaften rausfinden, warum. ;) Eigentlich ist das nicht sonderlich komplex an der Stelle.
In den beiden Logs finde ich zwar die die verwndetenen Connectoren Namen. Aber genau zu meiner großen Testmail ist nichts auffindbar (nachdem Sie durchging).
Dazu suche ich in den FrontEnd und Hub Logpfaden von:
Get-FrontendTransportService -Identity "XX" | fl Name,Identity,ReceiveProtocolLogPath
Get-TransportService -Identity "XX" | fl Identity,ReceiveProtocolLogPath
In einer ruhigen Minute schau ich mir das nochmals an....
Aber genau zu meiner großen Testmail ist nichts auffindbar (nachdem Sie durchging).
Hast du denn das Logging auch auf allen Connectoren aktiv?
Auch da drückst du in die richtige Wunde rein :-) Einer der Server hatte in zwei Connectoren das Logging nicht aktiv...