Introduction

Microsoft Exchange Server 2013/2016 brings a new rich set of technologies, features, and services to the Exchange Server product line. Its goal is to support people and organizations as their work habits evolve from a communication focus to a collaboration focus. At the same time, Exchange Server 2013/2016 helps lower the total cost of ownership whether you deploy Exchange 2013/2016 on-premises or provision your mailboxes in the cloud.

For Exchange Server 2013/2016, the new architecture consolidates the number of server roles from four to two: the Client Access Server (CAS) role and the Mailbox Server (MS) role. The Client Access server is a thin, stateless server that serves as a proxy for client connections to the Mailbox server. The Mailbox server handles the processing for all client connections to the active mailbox database.

One of the key functions of these server roles is to support the smooth flow of mails through the transport pipeline. The transport pipeline is a collection of services, connections, components, and queues that work together to route all messages to the categorizer in the Transport service on a Mailbox server inside the organization.

The transport pipeline consists of the following services:

  • Front End Transport service on Client Access servers   This service acts as a stateless proxy for all inbound and (optionally) outbound external SMTP traffic for the Exchange 2013/2016 organization. The Front End Transport service doesn't inspect message content, doesn't communicate with the Mailbox Transport service on Mailbox servers, and doesn't queue any messages locally.
  • Transport service on Mailbox servers   This service is virtually identical to the Hub Transport server role in previous versions of Exchange. The Transport service handles all SMTP mail flow for the organization, performs message categorization, and performs message content inspection. Unlike previous versions of Exchange, the Transport service never communicates directly with mailbox databases. That task is now handled by the Mailbox Transport service. The Transport service routes messages between the Mailbox Transport service, the Transport service, the Front End Transport service, and (depending on your configuration) the Transport service on Edge Transport servers.
  • Mailbox Transport service on Mailbox servers   This service consists of two separate services: the Mailbox Transport Submission service and Mailbox Transport Delivery service. The Mailbox Transport Delivery service receives SMTP messages from the Transport service on the local Mailbox server or on other Mailbox servers, and connects to the local mailbox database using an Exchange remote procedure call (RPC) to deliver the message. 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 on the local Mailbox server, or on other Mailbox servers. The Mailbox Transport Submission service has access to the same routing topology information as the Transport service. Like the Front End Transport service, the Mailbox Transport service also doesn't queue any messages locally.
  • Transport service on Edge Transport servers   This service is very similar to the Transport service on Mailbox servers. If you have an Edge Transport server installed in the perimeter network, all mail coming from the Internet or going to the Internet flows through the Transport service Edge Transport server. This service is described in more detail later in this topic.

The following figure shows the relationships among the components in the Exchange 2013/2016 transport pipeline.

Figure 1 : Overview of transport pipeline

Errors/delays anywhere in the transport pipeline – be it with the CAS, with the Mailbox server, with the transport agents, with the Send/Receive connectors, with the anti-malware/spam engines, with the transport queues, with Exchange search or indexing – can adversely impact mail flow and ultimately, the timely delivery of mails to the designated destination. In an era where time is money, delays in email delivery often translates into loss of revenue, reputation, and the escalation of support costs.

To avoid this, administrators should continuously monitor every aspect of the mail flow and capture even the smallest of deviations from the norm.