Exchange 2013: Message flow, connectors and queues

This article is once again about some basic knowledge. It's about the message flow, the connectors and the queues. Some things are identical to Exchange 2010, but a few things have changed. More on this in a moment.

Message flow (Mailflow)

In Exchange 2007/2010 there were 3 roles that were required to operate Exchange: HubTransport, ClientAccess and Mailbox. HubTransport took care of message transport and message routing, while ClientAccess managed the client connection from Outlook, smartphones and other devices. The Mailbox role took care of everything related to mailboxes and databases.

With Exchange 2013, this concept of role separation has been simplified again. In principle, it is a front-end and back-end principle that already existed under Exchange 2003. Exchange 2013 therefore only recognizes 2 roles: ClientAccess and Mailbox. However, ClientAccess only serves as a proxy for the various protocols that Exchange 2013 can handle and is responsible for selecting a suitable mailbox server for the connection. The Exchange 2013 Mailbox role combines the ClientAccess, HubTransport and Mailbox roles from an Exchange 2010 perspective. The Exchange 2013 ClientAccess role is comparable to an upstream proxy that only receives the connections and forwards them to the actual role.

This means the following for the message flow: The Exchange 2013 ClientAccess role accepts SMTP connections on port 25, then selects a suitable mailbox role and forwards the connection to port 2525 of the mailbox role. With the transport service, which is part of the mailbox role, the mail ends up in a queue. Here is a small graphic to illustrate this:

This path is also followed when a mail is sent. The Mailbox Server sends the mail to a ClientAccess Server, the ClientAccess Server in turn sends the mail to the wider world. The diagram above is of course a little simplified, so there are a few more details in the next section.

Connectors

Messages are sent and received via connectors. In Exchange 2010, 2 receive connectors were created automatically. In an Exchange 2013 environment, there are 5 receive connectors. Here is an example if Client Access and Mailbox Role are installed on a server:

The connectors with the FrontendTransport role run on the Client Access Server, the connectors with the Hub Transport role on the Mailbox Server. Here you can see that the Exchange 2010 Hub Transport role is now part of the Mailbox role in Exchange 2013.

The functions of the connectors:

Default Frontend: The connector runs on all Client Access Servers under port 25 and works as a stateless proxy for incoming mails and forwards the mails to the mailbox servers. The stateless proxy function is important here: The Client Access Server selects a mailbox server with the "Hub Selector" process and transfers the connection to the mailbox server. The SMTP status codes, such as "250", are not generated by the Client Access Server, but by the mailbox server. The connector accepts all messages from all IPs (i.e. also from the Internet) without authentication. This is therefore the standard receive connector.

Outbound Proxy Frontend: The connector runs on all Client Access Servers with port 717. The connector serves as a proxy for outbound messages. Mailbox servers with a send connector use the outbound proxy to send mails to the rest of the world. A mailbox server therefore does not send directly to a SmartHost or other relay server, but also uses the proxy on the client access server for this purpose.

Client Frontend: This connector runs on all Client Access Servers with port 587. This connector only accepts mails from authenticated Exchange users, i.e. internal clients. This connector also only forwards the connection to the mailbox server.

Default: This connector runs on all mailbox servers and accepts connections from the Default Frontend Connector. The connector runs on port 2525 and only allows connections from Exchange users and Exchange servers.

Client Proxy: The Client Proxy Connector is the equivalent of the Client Frontend Connector. The Client Frontend Connector forwards the connections to the Client Proxy Connector. This connector also runs on all mailbox servers and only allows connections from Exchange servers and Exchange users.

Send connector: The send connector must be created manually. Here you can choose whether outgoing messages should be sent via the front-end proxy again or whether the mailbox server can send the mails directly, i.e. without a proxy:

The following image illustrates how it works (source: Microsoft TechNet)

The mail routing and the queues therefore all run on the mailbox server. The Client Access Server takes over the proxy functions and the selection of a suitable mailbox server.

Queues

As soon as the messages have been transferred from the ClientAccess servers to the mailbox servers and processed by the connectors, the messages end up in the queues. The queues can be displayed via the Exchange Toolbox. Only the queues that are currently active are shown in the queue display. However, the queue with the name "Transmission" is displayed even if it does not contain any messages.

In the screenshot above, you can see another queue with the name of another Exchange server. This is a queue of the type "Shadow redundancy". In this article I have already explained how this works. It is therefore normal for messages to remain in the shadow queue for a certain period of time:

Exchange itself sends emails automatically to check the function of the services. The mails are sent and received via the HealthMailbox, this function is part of the "Managed Availability" introduced with Exchange 2013:

In addition to these queues, queues are created for domains and mailbox databases, which are only displayed if they are active or have just been active

I hope that's enough to give you a brief overview