Front End Transport service Routing
As explained in the previous articles of
this series, this service runs on all Client Access servers and acts as a
stateless proxy for all inbound and outbound external SMTP traffic.
For outgoing messages, the
Transport service on Mailbox servers uses Send connectors to
communicate with the Front End Transport service. Specifically, outgoing
messages are proxied through the Front End Transport service when the FrontEndProxyEnabled parameter on an applicable Send connector is set to $True in the Exchange Management Shell, or the Proxy through client access server option is selected in the Exchange Administration Center:
Figure 3.1: Exchange 2013 Send Connector Proxy Enabled
For incoming messages, the
Front End Transport service looks for a single healthy Transport
service on a Mailbox server to receive the message. Failure to do so
results in the e-mail service being perceived as unavailable by the
external senders as this service does not queue messages.
The Front End Transport service resolves
message recipients to mailbox databases (unless the recipient is a
distribution group, for example) by querying AD. Then, for each mailbox
database, it looks up the delivery group (which can be a Routable DAG, a
Mailbox delivery group or an AD site) and the associated routing
information.
Based on the number and type of recipients, the Front End Transport service performs one of the following actions:
- For messages with a single mailbox recipient, select a Mailbox server in the target delivery group and give preference to the Mailbox server based on the proximity of the AD site;
- For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox server in the closest delivery group, based on the proximity of the AD site. Because message bifurcation doesn't occur in Front-End Transport, only one Mailbox server is selected;
- If the message has no mailbox recipients, select a random Mailbox server in the local AD site.
Mailbox Transport service Routing
For incoming messages, the
Mailbox Transport Delivery service receives SMTP messages from the
Transport service and connects to the local mailbox database using
Remote Procedure Call [RPC] to deliver the message. For outgoing
messages, the Mailbox Transport Submission service connects to the
local mailbox database using RPC to retrieve messages and submits the
messages over SMTP to the Transport service. The Mailbox Transport service is stateless, and does not queue any messages locally.
When a user sends an e-mail, the Mailbox
Transport Submission service resolves the message recipients to mailbox
databases (unless the recipient is a distribution group, for example) by
querying AD. Then, for each mailbox database, it looks up the delivery
group (which can be a Routable DAG, a Mailbox delivery group or an AD
site) and the associated routing information.
Based on the number and type of recipients, the Mailbox Transport Submission service performs one of the following actions:
- For messages with a single mailbox recipient, select a Mailbox server in the target delivery group and give preference to the Mailbox server based on the proximity of the AD site;
- For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox server in the closest delivery group, based on the proximity of the AD site;
- If the message has no mailbox recipients, select a Mailbox server in the local delivery group.
When the Mailbox Transport Delivery service
receives a message from the Transport service, it accepts or rejects
the message for delivery to a local mailbox database as it can only
deliver the message if the recipient resides in an active copy of a
local mailbox database. If not, then the Mailbox Transport Delivery
service can't deliver the message and must provide a non-delivery
response to the Transport service. This might happen if, for example,
the active copy of the mailbox database recently moved to another server
and the Transport service incorrectly transmitted a message to a
Mailbox server that now holds an inactive copy of the mailbox database.
In this case, the non-delivery response that the Mailbox Transport
Delivery service returns to the Transport service is one of the
following:
- Retry delivery;
- Generate an NDR;
- Reroute the message.
Tracking Message Flow
Similar to Exchange 2010, we can use Delivery Reports
to track messages sent to or from users in an Exchange 2013
organization (sent using Outlook or Outlook Web App only and not POP or
IMAP!) and check their delivery status.
However, to better understand the flow of messages in Exchange 2013, we need to turn to our good old friends Message Tracking Logs.
There is only one difference in this new version of Exchange: because
we no longer have a dedicated Hub Transport Server role, the Get-TransportServer cmdlet is getting replaced by two new cmdlets:
- the Get-TransportService cmdlet which returns transport configuration information for the Transport service on Mailbox servers or for Edge Transport servers;
- the Get-MailboxTransportService cmdlet which returns transport configuration information for the Mailbox Transport service on Mailbox servers
So, let’s look at the flow of an e-mail
sent from the internal user Nuno (whose mailbox is on server MBX1) to
the internal user Mota (whose mailbox is on server MBX2). Using the
Exchange Management Shell, we run the following cmdlet to get
information regarding this particular e-mail (in this case it doesn’t
matter which of the above cmdlets we run as all we need are the names of
the Mailbox servers possibly involved in the mail flow, which both
cmdlets return):
Get-TransportService | Get-MessageTrackingLog –ResultSize Unlimited –Start “11/11/2012” –Sender nuno@letsexchange.com -Recipients mota@letsexchange.com –MessageSubject “Testing Mail Flow” | Sort TimeStamp | Select ClientHostname, ServerHostname, ConnectorId, Source, EventId
Analyzing the output of this search, we obtain the following which we can map into the following diagram:
Figure 3.2: Exchange 2013 Transport Pipeline
1. The Mailbox Transport
Submission service uses the Store Driver to connect to the mailbox
database using RPC and retrieves the e-mail:
ClientHostname : MBX1.letsexchange.com
ServerHostname : MBX1
ConnectorId :
Source : STOREDRIVER
EventId : RECEIVE
2. After resolving the
message recipient to its mailbox database, the Mailbox Transport
Submission service looks up the delivery group, a Mailbox delivery group
in this case. So the Store Driver passes the e-mail to the Hub Selector
for this to be sent over SMTP to the appropriate server.
In this case the e-mail is not passed to the Transport service. You can test this by stopping the Microsoft Exchange Transport service on your source mailbox server and you will see the e-mail will still be sent.
ClientHostname : MBX1
ServerHostname : MBX2.letsexchange.com
ConnectorId :
Source : STOREDRIVER
EventId : SUBMIT
3. The Transport service
on the MBX2 mailbox server receives the e-mail sent over SMTP from the
Mailbox Transport Submission service of server MBX1 using its default
receive connector. Content inspection is performed, transport rules are
applied and anti-spam/anti-malware inspection is performed (if enabled).
As the e-mail is not rejected by any of these, it is put in the
Submission queue.
ClientHostname : MBX1.letsexchange.com
ServerHostname : MBX2
ConnectorId : MBX2\Default MBX2
Source : SMTP
EventId : RECEIVE
4. The Categorizer picks
up the e-mail from the Submission Queue, processes it and puts into a
delivery queue based on the destination of the message (in this case, a
mailbox database):
ClientHostname : MBX2
ServerHostname :
ConnectorId :
Source : AGENT
EventId : AGENTINFO
5. The e-mail is sent over SMTP from the Transport service to the Mailbox Transport Delivery service:
ClientHostname : MBX2
ServerHostname : MBX2.letsexchange.com
ConnectorId : Intra-Organization SMTP Send Connector
Source : SMTP
EventId : SEND
6. The e-mail is received over SMTP by the Mailbox Transport Delivery service from the Transport service:
ClientHostname : MBX2.letsexchange.com
ServerHostname : MBX2
ConnectorId : MBX2\Default Mailbox Delivery MBX2
Source : SMTP
EventId : RECEIVE
7. The Mailbox Transport
Delivery service uses the Store Driver to connect to the mailbox
database using RPC and writes the e-mail to the mailbox database:
ClientHostname : MBX2
ServerHostname : MBX2
ConnectorId :
Source : STOREDRIVER
EventId : DELIVER
Simplifying the diagram in Figure 3.2 for this example, we end up with:
Figure 3.3: Mail Flow Trace
Queues
As we saw several times now, out of the
three services involved in Mail Flow, only the Transport service
provides local queuing. The Front End Transport service and the Mailbox
Transport service, do not provide local queuing.
This is different from earlier versions of
Exchange as we do have queues in the Exchange 2007/2010 Edge servers. I
do not know the reason behind this decision but if you use a Client
Access server as the e-mail gateway to your organization, be very
careful! If there are no mailbox servers available to receive e-mails
(either the one where the recipient’s mailbox resides or any other), a
failure notification will be issued to the sender’s server
immediately... Although most servers will keep trying to deliver the
e-mail to your organization for 24, 48 or even 72h, this might lead to
message failures especially with applications or other devices other
than mail servers.
Therefore, if you have a custom Receive
Connector for applications, printers, or other devices, with Exchange
2013 you might want to create it on your Mailbox servers and not on the
Client Access servers for this exact reason.
Conclusion
In this article series we explored Mail Flow and the changes introduced to the Transport Pipeline by the new architecture of Exchange 2013.
No comments:
Post a Comment