Exchange 2016: Zustell- Lesebestätigungen werden oft erst Stunden oder Tage später zugestellt
Hallo zusammen,
ich stehe hier vor einem Rätsel, was ich mir nicht unbedingt erklären kann.
Hintergrund: Bei uns im Unternehmen wird mit Zustell-/Lesebestätigungen gearbeitet. Nun kommt es vor, das teilweiße die Lesebestätigungen extrem verzögert ankommen.
Dies betrifft interne sowie auch externe Mails.
Server: Exchange Server 2016 Cumulative Update 8 (CU8) 15.1.1415.2
z.B.:
Die Lesebestätigung kam jedoch am Montag, 14.10. um 13:28 an
Hier der Zustellbericht seitens Exchange von der gesendeten Email:
Hier der Zustellbericht seitens Exchange von der Lesebestätigung:
Dieses Phänomen tritt nicht immer auf. Aus den Ereignis-/Performance-Logs lässt sich hier kein Rückschluss ziehen, soweit läuft alles ohne Probleme und Verzögerung.
Hab auch bereits recherchiert, jedoch keinen Hinweis auf das eventuell mögliche Problem. Einzig die Aussage "Email ist halt kein Echtzeit-Kommunikationsmittel" wäre eine Erklärung
Ist dies Verhalten so in Ordnung (nach dem Motto: "Ist halt einfach so...") oder könnte mir jemand hier einen Tipp geben, wo ich hier ansetzen könnte?
Schöne Grüße
Joe
ich stehe hier vor einem Rätsel, was ich mir nicht unbedingt erklären kann.
Hintergrund: Bei uns im Unternehmen wird mit Zustell-/Lesebestätigungen gearbeitet. Nun kommt es vor, das teilweiße die Lesebestätigungen extrem verzögert ankommen.
Dies betrifft interne sowie auch externe Mails.
Server: Exchange Server 2016 Cumulative Update 8 (CU8) 15.1.1415.2
z.B.:
Ihre Nachricht
An: NAME
Betreff: BETREFF
Gesendet: Donnerstag, 10. Oktober 2019 17:05:18 (UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien
wurde am Freitag, 11. Oktober 2019 10:23:40 (UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien gelesen.
Die Lesebestätigung kam jedoch am Montag, 14.10. um 13:28 an
Received: from EXCHANGE.DOMAENE.intern (XXX.XXX.XXX.XXX) by
EXCHANGE.DOMAENE.intern (XXX.XXX.XXX.XXX) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
15.1.1415.2 via Mailbox Transport; Mon, 14 Oct 2019 13:28:29 +0200
Hier der Zustellbericht seitens Exchange von der gesendeten Email:
Zustellbericht für NAME (name@email.de)
Übermittelt
10.10.2019 17:05 EXCHANGESERVER
Die Nachricht wurde an EXCHANGE.DOMAENE.intern übermittelt.
Ausstehend
10.10.2019 17:05 EXCHANGE.DOMAENE.intern
Nachricht wurde durch EXCHANGE.DOMAENE.intern von EXCHANGE.DOMAENE.intern empfangen.
Gruppe erweitert
10.10.2019 17:05 EXCHANGE.DOMAENE.intern
Die Liste der Mitglieder der Gruppe "alle@email.de" wurde erweitert, sodass die Nachricht jedem Empfänger zugestellt werden kann.
Ausstehend
10.10.2019 17:05 EXCHANGE.DOMAENE.intern
Die Nachricht wurde von EXCHANGE.DOMAENE.intern nach EXCHANGE.DOMAENE.intern übertragen.
Zugestellt
10.10.2019 17:05 EXCHANGE.DOMAENE.intern
Die Nachricht wurde erfolgreich zugestellt.
Hier der Zustellbericht seitens Exchange von der Lesebestätigung:
Zustellbericht für NAME (name@email.de)
Übermittelt
14.10.2019 13:28 EXCHANGESERVER
Die Nachricht wurde an EXCHANGE.DOMAENE.intern übermittelt.
Ausstehend
14.10.2019 13:28 EXCHANGE.DOMAENE.intern
Nachricht wurde durch EXCHANGE.DOMAENE.intern von EXCHANGE.DOMAENE.intern empfangen.
14.10.2019 13:28 EXCHANGE.DOMAENE.intern
Die Nachricht wurde von EXCHANGE.DOMAENE.intern nach EXCHANGE.DOMAENE.intern übertragen.
Zugestellt
14.10.2019 13:28 EXCHANGE.DOMAENE.intern
Die Nachricht wurde erfolgreich zugestellt.
14.10.2019 13:28
Die Nachricht wurde in den Ordner 'Sendeberichte' im Postfach des Benutzers verschoben.
Dieses Phänomen tritt nicht immer auf. Aus den Ereignis-/Performance-Logs lässt sich hier kein Rückschluss ziehen, soweit läuft alles ohne Probleme und Verzögerung.
Hab auch bereits recherchiert, jedoch keinen Hinweis auf das eventuell mögliche Problem. Einzig die Aussage "Email ist halt kein Echtzeit-Kommunikationsmittel" wäre eine Erklärung
Ist dies Verhalten so in Ordnung (nach dem Motto: "Ist halt einfach so...") oder könnte mir jemand hier einen Tipp geben, wo ich hier ansetzen könnte?
Schöne Grüße
Joe
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 505307
Url: https://administrator.de/contentid/505307
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
8 Kommentare
Neuester Kommentar
HI Joe,
Du fragst dich nicht im Ernst bei einem dysfunktionalen System (und wenn ein Update, welches gemeinhin funktioniert nicht geht, ist es das), warum ein Nebenbetriebsteil nicht solide funktioniert? Ich vermute, dass da mehr (und wenn es nur eine Kleinigkeit ist) im argen ist. Also entweder komplett angehen (gerne PN, wenn Wunsch nach einem anderen Dienstleister) oder erstmal damit "leben", bis der Neuaufbau erfolgt (hier gilt selbiges: gerne PN, wenn ihr hierfür noch einen Dienstleister sucht).
Ebenfalls schöne Grüße,
Christian
b) Der Server wurde zuvor durch einen externen Dienstleister konfiguriert, ich bekam ihn leider nicht dazu, auf die aktuelle CU14 zu upgraden.
Problem hier ist, das er während der Installation immer einen Rollback ausführt. Hab da schon unzählige Stunden in dieses Thema investiert.
Aktuell ist die Situation "never touch a running system" - Anfang nächstes Jahr wird dann auf aktuelle Systeme migriert (inkl. DC-Umzug)
Problem hier ist, das er während der Installation immer einen Rollback ausführt. Hab da schon unzählige Stunden in dieses Thema investiert.
Aktuell ist die Situation "never touch a running system" - Anfang nächstes Jahr wird dann auf aktuelle Systeme migriert (inkl. DC-Umzug)
Du fragst dich nicht im Ernst bei einem dysfunktionalen System (und wenn ein Update, welches gemeinhin funktioniert nicht geht, ist es das), warum ein Nebenbetriebsteil nicht solide funktioniert? Ich vermute, dass da mehr (und wenn es nur eine Kleinigkeit ist) im argen ist. Also entweder komplett angehen (gerne PN, wenn Wunsch nach einem anderen Dienstleister) oder erstmal damit "leben", bis der Neuaufbau erfolgt (hier gilt selbiges: gerne PN, wenn ihr hierfür noch einen Dienstleister sucht).
Ebenfalls schöne Grüße,
Christian
Zitat von @BCCray:
Hallo Christian,
doch - es ist mein Ernst. Meine Intention war hier nicht primär die Problemlösung oder das mir eine solche hier präsentiert wird.
Hallo Christian,
doch - es ist mein Ernst. Meine Intention war hier nicht primär die Problemlösung oder das mir eine solche hier präsentiert wird.
Dazu fehlte aber von vornherein die Info mit dem fehlerhaften Update.
Vielmehr geht es mir darum, ob andere hier im Forum auch das Phänomen haben und sich damit mal auseinandersetzten.
Wir sind auch nicht auf der Suche nach einem anderen Dienstleister, da dies nun alles Inhouse durchgeführt wird. Vielen Dank trotzdem für dein Angebot!
Gerne, besteht natürlich weiterhin.
Oftmals ist es so, das ein elementarer Betriebsfunktionsteil nicht umgehend ersetzt bzw. erneuert werden kann.
Ich sehe hier eher das Troubleshooting bzgl. des Updates als ersten Schritt, nicht den Ersatz, insbesondere da der Ex 2016 nun ja auch noch nicht zwangsläufig "raus" muss.
Oftmals lassen es innerbetriebliche Abläufe dies nicht umgehend zeitnah zu.
richtig, dennoch s.o, denn kleinere Probleme werden bei Nichtbehandlung oftmals zu größeren.
Mit solchen "Problemchen" zu leben ist dann natürlich zu akzeptieren. Es steht jedoch außer Frage, das man sich doch mit solchen Themen mal beschäftigt, und hinterfragt an was sowas liegen könnte.
bin ich absolut bei dir.
Für mich stünde im Vordergrund, ob sich jemand mal mit so einem Thema auseinander gesetzt hat, wieso dies so sein kann.
Schöne Grüße,
Joe
Schöne Grüße,
Joe
Moin,
Gruß,
Dani
b) Der Server wurde zuvor durch einen externen Dienstleister konfiguriert, ich bekam ihn leider nicht dazu, auf die aktuelle CU14 zu upgraden. Problem hier ist, das er während der Installation immer einen Rollback ausführt. Hab da schon unzählige Stunden in dieses Thema investiert.
Könnten evtl. am .NET Framework liegen: siehe hierGruß,
Dani