Exchange 2013: Nachrichtenfluss, Connectoren und Warteschlangen

In diesem Beitrag geht es mal wieder um etwas Basiswissen. Es geht um den Nachrichtenfluss, die Connectoren und die Warteschlangen. Einiges ist identisch mit Exchange 2010, aber es haben sich ein paar Dinge geändert. Dazu gleich mehr.

Nachrichtenfluss (Mailflow)

Bei Exchange 2007/2010 gab es 3 Rollen die zum Betrieb von Exchange benötigt wurden: HubTransport, ClientAccess und Mailbox. HubTransport kümmerte sich um den Nachrichtentransport und das Nachrichtenrouting, während ClientAccess die Clientverbindung von Outlook, Smartphones und anderen Geräten verwaltet hat. Die Mailbox Rolle kümmerte sich um alles was Postfächer und Datenbanken betraf.

Mit Exchange 2013 wurde dieses Konzept der Rollentrennung wieder vereinfacht. Im Prinzip handelt es sich um ein Front- und Backend Prinzip, welches es auch schon unter Exchange 2003 gab. Exchange 2013 kennt also nur noch 2 Rollen: ClientAccess und Mailbox. ClientAccess dient allerdings nur als Proxy für die verschiedenen Protokolle die Exchange 2013 beherrscht und ist dafür verantwortlich einen geeigneten Mailbox Server für die Verbindung auszuwählen. Die eigentliche Arbeit übernimmt dann die Mailbox Rolle.Die Exchange 2013 Mailbox Rolle vereint aus Exchange 2010 Sicht die Rollen ClientAccess, HubTransport und Mailbox. Die Exchange 2013 ClientAccess Rolle ist vergleichbar mit einem vorgeschalteten Proxy, der die Verbindungen nur entgegennimmt und an die eigentliche Rolle weiterreicht.

Für den Nachrichtenfluss bedeutet das folgendes: Die Exchange 2013 ClientAccess Rolle nimmt SMTP-Verbindungen auf Port 25 entgegen, wählt dann eine geeignete Mailbox Rolle aus und leitet die Verbindung auf Port 2525 der Mailbox Rolle weiter. Es mit dem Transport Dienst, der Bestandteil der Mailbox Rolle ist, landet die Mail in einer Warteschlange. Hier eine kleine Grafik zur Verdeutlichung:

Zeichnung1

Auch wenn eine Mail gesendet, wird dieser Weg eingehalten. Der Mailbox Server schickt die Mail an einen ClientAccess Server, der ClientAccess Server wiederrum schickt die Mail an die weite Welt. Die Grafik oben ist natürlich etwas vereinfacht dargestellt, daher gibt es ein paar mehr Details im nächsten Abschnitt.

Connectoren

Nachrichten werden über Connectoren verschickt und empfangen. Bei Exchange 2010 wurden 2 Empfangsconnectoren automatisch angelegt. In einer Exchange 2013 Umgebung gibt es 5 Empfangsconnectoren. Hier ein Beispiel wenn Client Access und Mailbox Rolle auf einem Server installiert sind:

image

Die Connectoren mit der Rolle FrontendTransport laufen auf dem Client Access Server, die Connectoren mit der Rolle Hubtransport auf dem Mailbox Server. Hier sieht man das die Exchange 2010 Hub Transport Rolle nun Bestandteil der Mailbox Rolle bei Exchange 2013 ist.

Die Funktionen der Connectoren:

Default Frontend: Der Connector läuft auf allen Client Access Servern unter dem Port 25 und arbeitet als stateless Proxy für eingehende Mails und leitet die Mails weiter an die Mailbox Server. Wichtig ist hier die stateless Proxy Funktion: Der Client Access Server wählt einen Mailbox Server mit dem Prozess „Hub Selector“ aus und übergibt die Verbindung dem Mailbox Server. Die SMTP Status Codes, wie zum Beispiel „250“ werden nicht vom Client Access Server erzeugt, sondern vom Mailboxserver. Der Connector nimmt alle Nachrichten von allen IPs (also auch aus dem Internet) ohne Authentifizierung entgegen. Dies ist also der Standard Empfangsconnector.

Outbound Proxy Frontend: Der Connector läuft auf allen Client Access Servern mit dem Port 717. Der Connector dient als Proxy für ausgehende Nachrichten. Mailbox Server mit Sendeconnector nutzen den Outbound Proxy zum verschicken von Mails in die weite Welt. Ein Mailbox Server schickt also nicht direkt an einen SmartHost oder anderen Relay Server, sondern nutzt auch dazu den Proxy auf dem Client Access Server.

Client Frontend: Dieser Connector läuft auf allen Client Access Servern mit dem Port 587. Dieser Connector akzeptiert nur Mails von authentifizierten Exchange Benutzern, also internen Clients. Auch dieser Connector leitet die Verbindung nur an den Mailbox Server weiter.

Default: Dieser Connector läuft auf allen Mailbox Servern und nimmt die Verbindungen vom Default Frontend Connector entgegen. Der Connector läuft auf Port 2525. Der Connector lässt nur Verbindungen von Exchange Benutzern und Exchange Servern zu.

Client Proxy: Der Client Proxy Connector ist das Äquivalent  zum Client Frontend Connector. Der Client Frontend Connector leitet die Verbindungen an den Client Proxy Connector weiter. Dieser Connector läuft ebenfalls auf allen Mailbox Servern und lässt nur Verbindungen von Exchange Servern und Exchange Benutzern zu.

Sendeconnector: Der Sendeconnector muss manuell erstellt werden. Hier hat man selbst die Wahl ob ausgehende Nachrichten wieder über den FrontEnd Proxy laufen sollen, oder ob der Mailbox Server die Mails direkt, also ohne Proxy verschicken kann:

image

Das folgende Bild verdeutlicht die Funktionsweise (Quelle: Microsoft TechNet)

Nachrichtenfluss

Das Mailrouting und die Warteschlangen laufen also alle auf dem Mailbox Server. Der Client Access Server übernimmt die Proxy Funktionen und das Auswählen eines geeigneten Mailbox Servers.

Warteschlangen

Sobald die Nachrichten von den ClientAccess Servern an die Mailbox Server übergeben und von den Connectoren verarbeitet wurden, landen die Nachrichten in den Warteschlangen. Die Warteschlangen können über die Exchange Toolbox angezeigt werden. In der Warteschlangenanzeige werden immer nur die Warteschlangen angezeigt, die gerade aktiv sind. Die Warteschlange mit dem Namen „Übermittlung“ wird allerdings auch dann angezeigt, wenn Sie keine Nachrichten enthält.

image

Im Screenshot oben, sieht man eine weitere Warteschlange mit dem Namen eines weiteren Exchange Servers. Hier handelt es sich um eine Warteschlange vom Typ „Shadow-Redundanz“. In diesem Beitrag habe ich bereits die Funktionsweise von erklärt. Es ist also normal wenn Nachrichten eine gewisse Zeit lang in der Shadow Queue liegen:

image

Exchange selbst schickt übrigens selbstständig Mails um die Funktion der Dienste zu prüfen. Die Mails werden über die HealthMailbox versendet und empfangen, diese Funktion gehört zu der mit Exchange 2013 eingeführten „Managed Availability“:

image

Zusätzlich zu diesen Warteschlangen, werden Warteschlangen für Domains und Mailbox Datenbanken erstellt, die aber nur dann angezeigt werden, wenn sie aktiv sind oder gerade aktiv waren

image

Ich hoffe das reicht um einen kleinen Überblick zu bekommen Smiley

6 thoughts on “Exchange 2013: Nachrichtenfluss, Connectoren und Warteschlangen”

  1. Hallo,

    nach einer ursprünglichen Installation mit POPCon zum Mails abholen und an Exchange zustellen sind die Empfangsconnectoren „verstellt“.
    Gibt es eine Funktion, den Standard wiederherzustellen?

    Reply
  2. Hallo, ich habe auch gerade eine Testumgebung Exchange 2007 coexistens mit Exchange 2013 eingerichtet. Mails von 2007 Postfächern zu 2007 PF kommen an. 2013 zu 2013 auch. Nur nicht im Mix :-(. In der Exchange 2007 Console sehe ich in der Warteschlangenanzeige kein Bewegungen…. Beim 2013 sehe ich in den Zustellberichten das z. B. 1 Mail noch nicht zugestellt wurde (an einen MA der noch auf dem EX2007 ist). Beim Versuch die Meldung zu versenden kam diese Nachricht zur Anzeige:

    Fehler: Der Benutzer und das Postfach befinden sich an unterschiedlichen Active Directory-Standorten.

    Kann es sein das der EX2013 nicht mit SPLIT-DNs zurechtkommt? Habe im DNS-Server 1 zone zusätzlich angelegt MeineDomain.de wo alle 2 Server aufgeführt sind. legacy.MeineDomain.de (interne IP, EX2007), mail.MeineDomain.de und autodiscover.MeineDomain.de (interne IP, EX2013).

    Das macht mich echt fertig….

    Reply
  3. Sehr Hilfreiche Artikel, danke dafür.

    Aber dennoch ergeben sich bei mir einige Probleme. Mein Exchange 2016 verschickt keine Emails an web.de (und „Konsortien“). Diese werden nicht von WEB.DE angenommen, weil sich mein Server mit Win2012Exc.meinedomäne.int meldet.

    Intern ist das ja richtig, aber extern sollte sich der Exchange doch mit mail.meinedomäne.de melden und die Emails auch verschicken… Den PTR-DNS habe ich (eigentlich) angepasst. Der Versand an andere Mail-Adressen funktioniert auch einwandfrei.

    Reply
  4. Danke für die Erklärungen. Haben mir schon einiges witergeholfen.

    Hätte noch ne Frage die sie vielleicht beantworten können.

    Ich habe hier einen Exchange Server 2007 und einen neu aufgezogenen Exchange 2013.
    Beider Server sehen sich. die Postfachverwaltung der 2007-Postfächer über den Exchange 2013 ist möglich.
    Nun stellt sich folgendes Bild.

    Wenn ich vom ex2013 eine Nachricht an ex2007 sende kommt diese nicht an.
    Wenn ich vom ex2007 eine Nachricht an ex2013 sende kommt diese nicht an.
    Wenn ich von Extern eine Nachricht an ex2007 sende kommt diese an.
    Wenn ich von ex2007 an Extern eine Nachricht sende kommt diese an.
    Wenn ich von Extern eine Nachricht an ex2013 sende kommt diese an.
    Wenn ich von ex2013 eine Nachricht an Extern sende kommt diese nicht an.

    Können Sie mir sagen woran das liegt ?

    Reply
    • Hi,
      kann es sein das Exchange 2007 und Exchange 2013 „externe DNS Server“ konfiguriert haben, konkret: DNS Server die nicht AD integriert sind? Die Mails müssen ja in den Warteschlangen hängen bleiben, was wird da für eine Fehlermeldung angezeigt? Zufällig folgends: 451.4.4.0 DNS query failed SMTPSEND.DNS NonExsistenDomain?
      Gruss, Frank

      Reply

Leave a Comment