In Exchange Server 2010 hat Microsoft auch Techniken implementiert, um den Ausfall von Hub-Transport-Servern abzufangen und den Versand von E-Mails sicherzustellen, indem der Quellserver diese erneut versendet. In Exchange Server 2010 wartet der sendende Server immer darauf, dass der empfangende Server die E-Mail entweder in ein Postfach oder einen weiteren Transportserver zugestellt hat. Stellt der sendende Server fest, dass eine E-Mail auf dem Empfangsserver nicht zugestellt werden kann, versucht Exchange Server 2010 eine Zustellung auf einem alternativen Weg.
Das Ganze kann wie folgt ablaufen: Server A schickt eine Mail an Server B. der die E-Mail zwar entgegennimmt, sie aber aufgrund von Netzwerkproblemen nicht an Server C weiterleiten kann. Server A hat die E-Mail zwar erfolgreich an Server B zugestellt, diese aber noch nicht gelöscht. Stellt Server A nun fest, dass Server B die E-Mail nicht an Server C weitersenden kann, versucht Server A auf einem alternativen Weg, zum Beispiel Server D, die E-Mail an Server C zuzustellen. Auch hier behält Server A die E-Mail weiterhin auf dem Server, bis sichergestellt ist, dass Server D die E-Mail an Server C zugestellt hat. Geht die Kette weiter, übernimmt Server D die Überwachung, ob Server C die Mail an Server E weitergeleitet hat, und so weiter.
Welche Neuerungen der Microsoft Exchange Server 2010 noch mit sich bringt, verrät Ihnen der Beitrag Microsoft Exchange Server 2010 – Outlook Web Access, Unified Messaging und Archivierung. Was es bei Umstrukturierungen von Mail-Systemen zu beachten gilt, behandelt der Artikel Mail-Datenbanken richtig migrieren.
Funktionsweise von Transport-Cache
Exchange überwacht nicht nur die Zustellung an den nächsten Server, sondern auch an den übernächsten. Die Kommunikation für diese Technik erfolgt mit den beiden SMTP-Befehlen XSHADOW und XQDISCARD. Haben Sie auf einem Server die beiden Rollen Postfach und Hub-Transport installiert, versucht Exchange auch bei einer lokalen Zustellung von E-Mails, diese an einen weiteren Hub-Transport-Server zu senden, bevor eine direkte Zustellung erfolgt. Sinn dieser Technik ist, dass eine E-Mail immer auf zwei Transportservern liegen muss, um sicherzustellen, dass sie nicht verloren geht.
In Einzelfällen kann es durchaus passieren, dass E-Mails einem Anwender doppelt zugestellt werden. Allerdings ist das sicher besser als ein Totalverlust der E-Mail. Damit diese Technik funktioniert, muss der empfangende Server dem sendenden Server mit XSHADOW mitteilen, dass er diese Technik auch beherrscht. Die Meldung wird beim Senden an den sendenden Server übertragen. Mit dem SMTP-Befehl XQDISCARD fragt der sendende Server beim empfangenden Server ab, welche E-Mails er an weitere Server übertragen hat und der sendende Server daher löschen kann.
Versandkontrolle
Erst wenn sich der sendende Server beim empfangenden Server authentifiziert hat und er dann die XSHADOW-Meldung erhält, legt er eine spezielle Warteschlange an, in der er die E-Mails, die er an den empfangenden Server sendet, zwischenspeichern kann; vorher werden die E-Mails ganz normal behandelt. Nach der erfolgreichen Übertragung von XSHADOW fragt der sendende Server immer wieder mit XQDISCARD beim sendenden Server nach, ob die E-Mails versendet sind und aus der Cache-Warteschlange entfernt werden kann.
Fünf Minuten ist das Intervall lang, in dem der Server jeweils dreimal mit XQDISCARD nachfragt. Erhält der sendende Server innerhalb dieser Zeit keine Antwort, versucht er die Zustellung an andere Transportserver der Organisation. Insgesamt läuft dieses Procedere bis zu sieben Tage lang, bevor die E-Mail als nichtzustellbar erkannt wird und der Absender einen Nichtzustellbarkeitsbericht erhält. Über das Internet kann diese Technik nur dann zum Einsatz kömmen, wenn sich der sendende Server am empfangenden Server authentifiziert; erst danach findet die XSHADOW-Abfrage statt.
Konfiguration des Transport-Cache
Der Transport-Cache ist standardmäßig nach der Installation von Exchange Server 2010 bereits aktiviert. Sie können sich den Status über die Exchange-Verwaltungs-Shell anzeigen, wenn Sie den Befehl get-transportconfig eingeben. Den Status finden Sie im Bereich ShadowRedundancyEnabled.
Mit dem Befehl Set-TransportConfig -ShadowRedundancyEnabled $true aktivieren Sie den Transport-Cache in Exchange Server 2010, der Befehl Set-TransportConfig -ShadowRedundancyEnabled $false deaktiviert die Technik. Mit den Optionen ShadowHearbeatTimeoutInterval (Standard sind fünf Minuten) und ShadowHearbeatRetryCount (Standard sind drei Minuten)des CMDlets Set-TransportConfig konfigurieren Sie das Intervall. Die Option ShadowMessageAutoDiscardInterval steuert den maximalen Verbleib in der Cache-Warteschlange.
Hier ein Beispiel für die Änderung auf zehn Minuten und acht Versuche: Set-TransportConfig -ShadowHeartbeatTimeoutInterval 00:10:00 -ShadowHeartbeatRetryCount 8
Senden Sie mit Outlook oder Outlook Web App eine E-Mail, stellt der Client diese in den Postausgang. Anschließend holt sich ein Hub-Hransport-Server die E-Mail ab. Der Client bemerkt das und kopiert die E-Mail in den Ordner für gesendete Objekte. Kann der Hub-Transport-Server die E-Mail nicht zustellen, bemerkt das der Postfachserver, und veranlasst, dass ein weiterer Hub-Transport-Server die E-Mail aus den gesendeten Objekten abholt und zustellt.
Transport-Cache mit Exchange Server 2003/2007
Setzen Sie Exchange Server 2010 zusammen mit Exchange Server 2003/2007 ein, erhält ein Transportserver keine Antwort durch XSHADOW, da die älteren Exchange-Versionen diese Technik nicht beherrschen. In diesem Fall sendet Exchange die Nachricht dennoch, verwendet aber nicht den Transport-Cache. Das heißt, bei gemischten Umgebungen kann der Versand von E-Mails nicht sichergestellt werden. Das gilt natürlich auch, wenn Exchange die Nachricht an ein externes System versendet, das den Cache nicht unterstützt.
Auch hier funktioniert der Empfang, ist aber nicht durch den Cache abgesichert. Mit der Option MaxAcknowledgementDelay des Cmdlets Set-ReceiveConnector konfigurieren Sie die maximale Verzögerung, während der der Empfangsconnector beim Empfang von Systemen ohne Unterstützung des Transport-Cache auf eine SMTP-Bestätigung wartet. Standardmäßig ist für den Empfangsconnector eine Bestätigungsverzögerung von bis zu 30 Sekunden eingestellt. (mje)