All articles

Microsoft Exchange 2013 introduces a number of fundamental changes in architecture compared to Exchange 2010 and 2007. In this article, we’ll have a look at Exchange 2013 Mail Flow and its differences from prior versions of Microsoft Exchange, and review how messages are routed through Exchange 2013 to their final destination. Finally, we’ll trace the complete path of a message through all the different services of Exchange 2013 and talk about Exchange message queues.

Exchange 2013 Architecture

Exchange 2013 introduces a number of important architectural changes compared to previous versions of Microsoft Exchange. While some of these changes only affect internal mail flow, some others can and do affect the delivery of messages. Either way, these changes must be taken into consideration if you are writing applications running on the Exchange platform.

Server Roles in Exchange 2013

In order to understand how e-mail flows in the new architecture presented in Exchange 2013, one must first understand the new server roles available in Exchange 2013. In its latest edition, Microsoft Exchange Server has dropped support for all server roles except just two:

• Mailbox Server role
  
  This role handles all activity for a given mailbox and includes all of the following:
  • Client Access protocols;
  • Hub Transport service;
  • Mailbox databases;
  • Unified Messaging.          
    
    
• Client Access Server role
  
  This role enables client access by providing authentication, redirection and proxy services. In its current implementation, the Client Access server is thin and stateless. The Client Access server has no facilities for queuing or storing anything. The following client access protocols are supported:
  • HTTP (ActiveSync, Outlook Anywhere, Web Services);
  • IMAP;
  • POP and SMTP.

Things that are Missing from Exchange 2013

A number of things were removed from Exchange 2013, encapsulated or reassigned to different entities. Let’s see what these are.

MAPI Services

MAPI services are no longer offered. In this edition of Exchange Server, MAPI connections are encapsulated using RPC-over-HTTPS, enabling clients from the Internet to securely access a Microsoft Exchange Server without having to log into a VPN first.

Edge Server

One more thing that is missing from Exchange 2013 is Edge Server. Services previously provided by the Edge Server are now delivered via the Client Access Server. However, if your legacy infrastructure is highly dependent on the use of the Edge Server, there is nothing to prevent you from using a copy of Edge Server from an Exchange 2007 or 2010 installation within your Exchange 2013 infrastructure.

Other Architectural Changes

Architectural changes in Exchange 2013 make Client Access Server and Mailbox Server less dependent on one another compared to previous versions. The Mailbox server now handles all processing and activities persisting to mailboxes, while the Client Access server handles client authentication and redirection and serves as a proxy. This is logical, as an active database copy of a mailbox physically resides on the Mailbox Server. Delegating all mailbox activities to a Mailbox server ensures that all data rendering takes place on a local copy of the mailbox database, reducing the number of interactions between the Mailbox and Client Access servers and eliminating concerns of version compatibility between the two servers.

Transport Pipeline

In Exchange 2013, mail flows through the Transport Pipeline. In this edition, the Transport Pipeline consists of the following three services:

• Front End Transport service

  This service runs on all Client Access servers. It handles all external SMTP traffic, acting as a stateless proxy for all inbound and outbound connections. The Front End Transport service has the following properties:

  • The Front End Transport service does not provide message content inspection;
  • This service only communicates with the Transport service on a Mailbox server;
  • This service does not queue any messages locally.
    
    
• Transport service

  The Transport service runs on all Mailbox servers, taking place of the Hub Transport server role that was available in previous versions of Exchange and removed in Exchange 2013. The Transport service handles all SMTP traffic for the organization. The Transport Service has the following properties:

  • This service performs message categorization and inspects message content;
  • The Transport service no longer communicates directly with mailbox databases. That task is now handled by the Mailbox Transport service. Instead, the Transport service routes messages between the Mailbox Transport service, the Transport service, and the Front End Transport service;
  • This service does queue messages locally.
    
    
• Mailbox Transport service

  The Mailbox Transport Service runs on all Mailbox servers. It and consists of two separate services:

  • Mailbox Transport Delivery service receives SMTP messages from the Transport service on the local Mailbox server or on other Mailbox servers, and delivers the message by connecting to the local mailbox database using an Exchange remote procedure call (RPC);
    
    
  • Mailbox Transport Submission service retrieves messages by connecting to the local mailbox database via RPC. The messages are then submitted over SMTP to the Transport service on the local Mailbox server, or on other Mailbox servers. This service does not queue messages locally.

As I already mentioned, the Exchange 2013 installation no longer includes the Edge Server. As a result, email messages from the Internet can be handled in one of the following ways:

• By using the Exchange 2013 Client Access Server (default);
• By using the Edge Server from the previous installation of Exchange 2007 or 2010;
• By using a third-party email gateway.

Obviously, Microsoft intends Exchange customers to make use of the Client Access Server. In this scenario, external emails enter the Exchange organization through a Receive connector in the Front End Transport service, and are then routed to the Transport service on a Mailbox server.

Unlike Exchange 2010 and 2007, Exchange 2013 can receive emails from the Internet in its default configuration. The Client Access server comes equipped with a pre-configured Receive Connector enabling organizations to receive emails from the Internet. The Receive Connector is named “Default Frontend ”, which already accepts anonymous connections by allowing “Anonymous Users” to connect:

There are four ways for a message within the organization to enter the Transport service on a Mailbox server:

1. Through a Receive connector;
2. Through the Pickup and Replay directories;
3. Through the Mailbox Transport service;
4. Through agent submission.

The Transport Service itself consists of the following components and processes:

• SMTP Receive: this connector handles emails received by the Transport service. When an email message is received, SMTP Receive inspects its content, applies transport rules and performs spam and malware checks, if enabled. If the email was not rejected by SMTP Receive, it is put in the Submission queue.
  
  
• Submission is the process of putting emails into the Submission queue. There are three different ways an email can end up in the Submission queue:
  • Through an SMTP Receive connector;
  • Through the Pickup and Replay directories now residing on Mailbox servers;
  • Through an agent.
    
    
• Categorizer processes messages from the Submission queue one by one. The processing consists of the following steps:
  • Recipient Resolution: this step resolves the email address of the recipient's and determines whether the recipient is internal (has a mailbox within the Exchange organization) or external;
  • Routing Resolution: this next step determines the ultimate destination for each message, and determines the route to the final destination as well as the next hop;
  • Content Conversion: this step converts the email message into the format that can be accepted by the recipient. Examples of such conversions include MAPI to MIME encoding conversion, UUENCODE to base64 etc. In addition, the appropriate rendering can be specified such as by an email client such as HTML, rich text format (RTF) or plain text.
    
    
• Mail flow rules are applied after the Categorizer. Messages are then put into a corresponding delivery queue. Which particular mail queue receives a particular email message depends on the destination of the message. The destination can be the local mailbox database, Database Availability Group [DAG], Active Directory [AD] site, AD forest or external domain.
  
  
• SMTP Send routes messages depending on the recipient’s location. The message can be routed to:
  • the Mailbox Transport service on the same Mailbox server;
  • the Mailbox Transport service on a different Mailbox server that belongs to the same DAG;
  • the Transport service on a Mailbox server that belongs to a different DAG, AD site, or AD forest;
  • the Front End Transport service on a Client Access server if the message is intended for delivery to an address on the Internet.

The following diagram summarizes everything described above, clearly showing the components and the relationships between them.

Transport Agents

The role of Transport Agents has not changed since the previous version of Exchange. Transport Agents are custom extensions that process email messages passing through the transport pipeline.

Organizations can create their own custom agents, or use Transport Agents supplied by Microsoft or a third-party software vendor.

Transport Agents can be used, for example, to intercept all messages received via the SMTP protocol and convert their format into plain text, remove all attachments or add a legal disclaimer at the bottom of each message. Note that Transport Agents have full access to all email messages that they encounter. Exchange applies no sandboxing, no rules and no restrictions on agents’ behavior. Transport Agents obtained from an unknown source may present a security or stability threat to the entire Exchange organization. A good advice would be only using Transport Agents obtained from a known, trusted source or created – and tested – within the organization to fulfill a particular purpose.

There are several types of Transport Agents available: SmtpReceiveAgent, RoutingAgent and DeliveryAgent. Exchange 2013 comes with a number of built-in transport agents. Most of these agents are invisible and cannot be managed. Transport Agents that are visible can be viewed with the Get-TransportAgent cmdlet:

Mail Routing and Categorization

We have already reviewed the changes in Exchange 2013 general architecture and the Mail Flow in particular as compared to Exchange 2007 and 2010. Now let’s have a look at mail routing and categorization in Exchange 2013. This part will be mostly theoretical, so it has lots of text and few pictures. You are encouraged to read this part if you want to understand how messages are routed through Exchange 2013 to their final destination. If you don’t want the theory, you may skip directly to the last part where we will trace the complete path of a message through all the different services of Exchange 2013.

Message Routing

Messages are routed to their final destination with the Transport service which present on all mailbox servers. In order to decide on how to route a particular message, the Transport server must perform categorization, which is an important component of the Transport service. Categorization processes all incoming mail, determining actions to perform based on their final destination. As described in Part I of this series, Exchange 2013 implemented a number of architectural changes. Due to these changes, the Transport service is now hosted on all Mailbox servers. As a result, the routing process becomes more intelligent. The routing process is now fully aware of Database Availability Groups (DAG). DAG membership is used as a routing boundary.

What does that mean in practice? Using the Active Directory site as the primary routing boundary becomes inefficient if the DAG spans multiple Active Directory sites. For this reason, if a Mailbox server belongs to a certain DAG, message routing becomes closely aligned with the DAG.

Of course, if a Mailbox server does not belong to a DAG, Exchange 2013 continues using Active Directory site membership as a routing boundary, just as in previous versions of Exchange.

Due to the architectural changes made in Exchange 2013, the routing process changes significantly compared to earlier versions of Microsoft Exchange.

• In Exchange 2013, there is no direct communication between the Transport service and a mailbox database. Instead, the Transport service establishes communication with the Mailbox Transport service which in turn talks to the mailbox database on the local Mailbox server. When the Mailbox server belongs to a DAG, only the Mailbox Transport service on the Mailbox server holding the active copy of the mailbox database accepts the message for the destination recipient;
• Remote Procedure Calls (RPC) are no longer used for cross-server communication. RPC calls are only used by the Mailbox Transport service when sending or receiving messages to or from the local mailbox database. The SMTP protocol is used for communication between the Mailbox Transport service and the Transport service on different Mailbox servers;
• There is no single message queue for all destinations in a remote Active Directory site. Instead, Exchange 2013 uses individual message queues for specific destinations within theActive Directory site, such as individual Send connectors;
• Linked connectors such as the Receive connector linked to a Send connector have been deprecated.

Categorization

All messages received by the Transport service must be categorized for future routing. The categorization process resolves the recipient first. After resolving the recipient, the ultimate destination of the message can be determined. After that, Exchange performs message routing by determining the path to the final destination, which is also called the Routing Destination. The Routing Destination is determined as follows:

• Mailbox database: all recipients within the Exchange organization having a mailbox have this as the routing destination. Note that Exchange 2013 views public folders as a type of mailbox. For this reason, routing messages to public folder recipients is no different to routing messages to mailbox recipients; 
  
  
• Connector: for SMTP messages, a Send connector is used as the routing destination. For non-SMTP messages, either a Delivery Agent connector or a Foreign connector is used as the routing destination;
  
  
• Distribution Group expansion server becomes the routing destination when a distribution group has a designated expansion server responsible for expanding the membership list of the group.

Exchange 2013 introduces Delivery Groups. In Exchange 2013 architecture, each routing destination has one or several associated transport servers (either an Exchange 2013 Mailbox server or an Exchange 2010 Hub Transport server). These transport servers are called Delivery Groups. Delivery groups are responsible for routing the message to its ultimate destination.

To make things even more complicated, the transport servers in the delivery group can be of different versions. If the routing destination is a mailbox database, the version of transport servers in the delivery group is the same version of Exchange as the mailbox database. If, however, the routing destination is a connector or a distribution group expansion server, the delivery group may consist of a mixture of Exchange 2013 Mailbox servers and Exchange 2010 Hub Transport servers.

Exchange 2013 defines 5 types of delivery groups:

• Routable DAG: a collection of mailbox servers belonging to a DAG. This delivery group services mailbox databases in the DAG as the routing destinations. After the message arrives at the Transport service on a Mailbox server belonging to the DAG, the Transport service routes the message to the Mailbox Transport service on the Mailbox server in the DAG that currently holds the active copy of the destination mailbox database. The message is then delivered to the local mailbox database by the Mailbox Transport service on the destination Mailbox server. Note that the DAG defines delivery group boundary even if a DAG contains Mailbox servers located in different Active Directory sites;
  
  
• Mailbox delivery group: a collection of Exchange servers of the same version located in a single Active Directory site. In this case, the delivery group boundary is defined by the Active Directory site. Those mailbox databases that are located on Exchange 2010 Mailbox servers are serviced by the Exchange 2010 Hub Transport servers located in the Active Directory site, while mailbox databases located on Exchange 2013 Mailbox servers in an Active Directory site that don't belong to a DAG are serviced by the Transport service on Exchange 2013 Mailbox servers in the Active Directory site;
  
  There are differences in how the message is delivered to the mailbox database between Exchange 2010 and 2013.
  • Exchange 2010: in this version of Exchange, the message arrives at a random Exchange 2010 Hub Transport server in the destination Active Directory site. The store driver on the Transport server uses RPC to store the message to the destination mailbox database.
  • Exchange 2013: the message arrives at the destination Mailbox server in the destination Active Directory site. The Transport service uses SMTP to deliver the message to the Mailbox Transport service which then delivers the message to the local mailbox database via RPC.
    
    
• Connector source servers: a mixed collection of Exchange 2010 Hub Transport servers or Exchange 2013 Mailbox servers scoped as the source server for a Send connector, a Delivery Agent connector or a Foreign connector. The connector is the routing destination that is serviced by this routing group. When a connector is scoped to a specific server, only that server is allowed to route messages to the destination defined by the connector. This delivery group may contain Exchange 2010 Hub Transport servers or Exchange 2013 Mailbox servers located in different AD sites;
  
  
• Active Directory site: sometimes, an Active Directory site is not the message’s ultimate destination. If this is the case, the message must pass through either an Exchange 2010 Hub Transport server or an Exchange 2013 Mailbox server in that Active Directory site before reaching its routing destination;
  
  
• Server list: a collection of one or several Exchange 2010 Hub Transport servers or Exchange 2013 Mailbox servers set up as distribution group expansion servers. In this case, the routing destination serviced by this delivery group is the distribution group expansion server.

Being part of one delivery group does not automatically exclude membership in other groups. For example, an Exchange 2013 Mailbox server can be a member of a DAG and, at the same time, can be the source server of a scoped Send connector. Аor mailbox databases in the DAG, this Mailbox server belongs to the routable DAG delivery group. For the scoped Send connector it serves as a connector source server delivery group.

When delivering a message to a remote delivery group, Exchange 2013 must determine the correct routing path in order to be able to perform the task. The algorithm has not changed since version 2010:

1. The most efficient routing path is determined by adding up the cost of the IP site links that must be traversed in order to reach the destination. If the destination is a connector, the system calculates the sum of the cost assigned to the address space with the cost to reach the selected connector. If there is more than one possible routing path available, the system will select one with the lowest aggregate cost;
2. If there are several routing paths with the same cost, the system will select the shortest path (the routing path having the least number of hops);
3. If there are still more than one routing path left, Exchange 2013 considers the names assigned to the Active Directory sites before the destination. The system will choose the routing path where the Active Directory site closest to the destination is lowest in alphanumeric order. Finally, if the site closest to the destination is the same for all routing paths being evaluated, the system selects an earlier site name.

Tracing a Message

OK, enough theory! Now when you understand how Exchange 2013 uses Routing Destination and Delivery Groups to route messages to their correct destination, you are ready for the next part. At this point, we’ll trace a message through all the hoops of Exchange 2013 mechanisms, discuss how the Front End Transport and Mailbox Transport services route messages, and have a closer look at Queues.

Front End Transport Service Routing

The Front End Transport service is executed on all Client Access servers. This service handled all inbound and outbound SMT traffic originating from or addressed to outside of Exchange organization, serving as a stateless proxy.

To process outgoing messages, the Transport service on Mailbox servers communicates with the Front End Transport Service by invoking Send connectors. The Front End Transport service proxies outgoing messages when the FrontEndProxyEnabled parameter on an applicable Send connector in the Exchange Management Shell is set to $True, or when the “Proxy through client access server” option is selected in the Exchange Administration Center: 

To process incoming messages, the Front End Transport service attempts to identify a healthy Transport service on a Mailbox server to receive the message. As the Front End Transport service does not queue messages, it assumes the email service is not available and fails to deliver a message if no single healthy Transport service is found.

Message recipients are resolved to their corresponding mailbox databases by querying Active Directory. The Front End Transport service looks up the delivery group and associated routing information for each mailbox database. The delivery group can be a Routable DAG, a Mailbox delivery group or an Active Directory site.

Depending on the number and type of message recipients, Front End Transport service can do one of the following actions (Table 1):

Mailbox Transport Service Routing

The Mailbox Transport Delivery service delivers incoming mail by receiving SMTP messages from the Transport service and connecting to the local mailbox database via Remote Procedure Call (RPC).

Outgoing messages are retrieved from the local mailbox database via RPC by the Mailbox Transport Delivery service. The messages are then submitted to the Transport service via SMTP.

The Mailbox Transport Service is stateless, and does not queue messages locally.

What happens when a user sends an email message? First, the message recipients are resolved to corresponding mailbox databases by the Mailbox Transport Submission service by querying Active Directory. The associated routing information is retrieved by looking up the delivery group for each mailbox database. The delivery group can be a Routable DAG, a Mailbox delivery group or an Active Directory site..

Depending on the number and type of recipients, the Mailbox Transport Submission service performs one of the actions described in Table 1.

As mentioned before, the Mailbox Transport Delivery is stateless and does not queue any messages locally. As a result, messages are accepted or rejected for delivery to a local mailbox database on the spot, based on whether or not the recipient resides in an active copy of a local mailbox database.

If the recipient does not reside in an active copy of a local mailbox database, the Mailbox Transport Delivery service fails to deliver the message, providing an instant non-delivery response to the Transport service. This could happen if, for example, the active copy of the mailbox database was recently moved to a different server and the message was incorrectly routed by the Transport service to a Mailbox server holding an inactive copy of the mailbox database.

If this happens, the non-delivery response generated by the Mailbox Transport Delivery can be one of the following:

• Retry delivery;
• Generate an NDR;
• Reroute the message.

Tracking Message Flow

Now let’s have a closer look at Front End Transport and Mailbox Transport services route messages. We’ll have a look at how messages travel through all the services and processes by tracing the complete path of an email.

Similar to the previous version, Exchange 2013 generates Delivery Reports that can be used to track messages sent or received in an Exchange 2014 organization. Note that we can only trace messages sent using Outlook or Outlook Web App, but not via POP or IMAP.

However, Exchange 2013 offers an even better way to trace messages via Message Tracking Logs. As you already know, Exchange 2013 no longer provides a dedicated Hub Transport Server role. For this reason, the TransportServer cmdlet is replaced with two new cmdlets:

• Get-TransportService cmdlet returning transport configuration information for the Transport service on Mailbox servers or for Edge Transport servers
• Get-MailboxTransportService cmdlet returning transport configuration information for the Mailbox Transport service on Mailbox servers

So let’s trace a message sent from the internal user Test1 with a mailbox on server MBX1 to the internal user Test2 with a mailbox on server MBX2. The following cmdlet must be executed in order to obtain information about this particular message. Note that we could use either one of the two cmdlets described above.

Get-TransportService | Get-MessageTrackingLog –ResultSize Unlimited –Start “01/09/2013” –Sender test1@e2013.advsoft.info -Recipients test2@e2013.advsoft.info –MessageSubject “Mail flow example” | Sort TimeStamp | Select ClientHostname, ServerHostname, ConnectorId, Source, EventId

The cmdlet returns the names of the Mailbox servers possibly involved in the mail flow. Analyzing the output of the cmdlet, we can make the diagram Figure 2:

1. The Mailbox Transport Submission service uses the Store Driver to connect to the mailbox database via RPC, and retrieves the message:
   ClientHostname : MBX1.e2013.advsoft.info
   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. In our test scenario, this is a Mailbox delivery group. As a result, the Store Driver transfers the message to the Hub Selector. The message will be sent to the appropriate server via SMTP.
   
   Note that in our test scenario, the message has not passed through the Transport service. This can be verified by stopping the Microsoft Exchange Transport service on the source mailbox server and repeating the test. The message will still be sent.
   
   ClientHostname : MBX1
   ServerHostname : MBX2.e2013.advsoft.info 
   ConnectorId :
   Source : STOREDRIVER
   EventId : SUBMIT
   
   
3. The message is then received by the Transport service on the MBX2 mailbox server. The message is sent from the Mailbox Transport Submission service of server MBX1 using its default receive connector via the SMTP protocol. At this time, the Transport service on the MBX2 mailbox server performs content inspection, applying transport rules and checking for spam and malware, if enabled. If the message successfully passes all of these check, it is then put in the Submission queue.
   
   ClientHostname : MBX1.e2013.advsoft.info 
   ServerHostname : MBX2
   ConnectorId : MBX2\Default MBX2
   Source : SMTP
   EventId : RECEIVE
   
   
4. The message is picked from the Submission Queue by the Categorizer. The Categorizer processes the message and puts into a delivery queue. The particular delivery queue is selected based on the destination of the message. In our test, the destination is a mailbox database.
   
   ClientHostname : MBX2
   ServerHostname :
   ConnectorId :
   Source :
   AGENT
   EventId : AGENTINFO
   
   
5. The message is sent from the Transport service to the Mailbox Transport Delivery service via SMTP:
   
   ClientHostname : MBX2
   ServerHostname : MBX2.e2013.advsoft.info 
   ConnectorId : Intra-Organization SMTP Send Connector
   Source : SMTP
   EventId : SEND
   
   
6. The message is received by the Mailbox Transport Delivery: ClientHostname :
   
   MBX2.e2013.advsoft.info 
   ServerHostname : MBX2
   ConnectorId : MBX2\Default Mailbox Delivery MBX2
   Source : SMTP
   EventId : RECEIVE
   
   
7. The Mailbox Transport Delivery service connects to the mailbox database using the Store Driver via RPC. The message is then written to the mailbox database:
   
   ClientHostname : MBX2
   ServerHostname : MBX2
   ConnectorId :
   Source : STOREDRIVER
   EventId : DELIVER

Finally, we end up with the following diagram:

Queues

Finally, let’s talk about the last thing we have left: the queues. Exchange 2013 implements several architectural changes compared to earlier versions of Exchange. Exchange 2007/2010 Edge servers do have queues, while in Exchange 2013 most services involved in mail flow do not queue messages. Out of the three services, only the Transport service maintains message queues. The Front End Transport service and the Mailbox Transport service do not provide local queuing.

What does it mean in practice? If you are using Client Access server as your primary email gateway, you must clearly understand that if there are no mailbox servers available to receive messages, the sender’s server will be issued a delivery failure notification immediately. For regular mail this may not pose a critical problem as most email servers will make several attempts to deliver a message (typically during the 24, 48 or 72 hour period). However, with applications or devices other than mail servers this may lead to message failures.

If you have a custom Receive Connector for applications, printers, or other devices in an Exchange 2013 organization, you may want to create that Receive Connector on your Mailbox servers instead of the Client Access servers.

Conclusion

This article concludes our series discussing mail flow in Exchange 2013. We covered all the architectural changes introduced into the flow of messages in Exchange 2013, traced an email message from start to finish through all processes and services participating in Exchange 2013 Mail Flow. Finally, we reviewed Queues in Exchange 2013, noting their limitations and suggesting a workaround for users of custom Receive Connectors.

Tags: Exchange Server 2013, mail flow