The Transport service on Mailbox servers and the Edge Transport role perform simi- lar tasks. You use both for messaging routing, and both have a similar set of filters to protect an organization from spam and viruses. The key difference is in where you place servers with these roles. You place a Mailbox server in the internal network and configure it as a member of the organizational domain. If you use a server with the legacy Edge Transport role, you place it in the organization’s perimeter network, and you do not configure it as a member of the organizational domain.
For computers with the Mailbox server or legacy Edge Transport role, the server cannot have the SMTP or Network News Transfer Protocol (NNTP) service installed separately. Although you install legacy Edge Transport servers outside the Active Di- rectory forest, you must have a DNS suffix configured, and you must be able to per- form name resolution from the legacy Edge Transport server to any Mailbox servers.
TIP Transports store all incoming mail in a database file called mail.que until the transport verifies that all of the next hops for that message have been completed. This database has an associated transaction log in which changes are first committed. If you are using an Exchange server’s internal drive(s) for storage in a high-volume en- vironment in which one million or more messages are persisted, you should consider placing the database and the transaction log on separate disks for optimal perfor- mance and fault tolerance. With Storage Area Networks (SANs), it might not be im- mediately apparent whether disks are physically separate. This is because the volumes you see are logical references to a portion of the storage subsystem. In this case, you might be able to use the Storage Manager For SANs console or a similar tool to help you select logical unit numbers (LUNs) that are on physically separate disks.
MORE INFO Transports have many different queues for messages. These queues are all stored in a single Extensible Storage Engine (ESE) database called mail.que. By de- fault, this database is located in %ExchangeInstallPath%\TransportRoles\data\Queue. Thanks to shadow redundancy, the deletion of a message in the database is delayed until the transport verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting back successful delivery, the message is resubmitted for delivery to that next hop.
Both Mailbox servers and legacy Edge Transport servers can perform protocol logging and message tracking. Only Mailbox servers perform content conversion to format messages for recipients. Protocol logging allows you to verify whether a pro- tocol is performing as expected and whether any issues need attention. Because this feature is designed for troubleshooting, it is disabled by default. Message tracking creates logs that track messages sent and received. Incoming mail from the Internet is converted to Summary Transport Neutral Encoding Format (STNEF) prior to being delivered. STNEF messages are always MIME-encoded and always have a Content- Transfer-Encoding value of Binary. Because content conversion is performed in the temp folder, you can improve performance by ensuring that the temp folder is not on the same physical disk as the paging file and operating system.
The transport pipeline used by Exchange 2013 is different from the transport pipeline for Exchange 2010 and has the following key components:
■ Front End Transport service ■ Transport service
■ Mailbox Transport Submission service ■ Mailbox Transport Delivery service
The Front End Transport service running on Client Access servers proxies all inbound and outbound SMTP traffic for Exchange 2013. Although the Transport service running on Mailbox servers performs nearly the same tasks as the Hub Transport role, it’s important to point out the differences. As with Exchange 2010, the Transport service handles all SMTP mail flow. The service also performs message categorization and message content inspection. Unlike Exchange 2010, however, the Transport service doesn’t communicate directly with mailbox databases. Instead, the Mailbox Transport Submission and Mailbox Transport Delivery services are used to provide separate mail submission and delivery processes.
The basic submission process works like this:
1. The Mailbox Transport Submission service receives SMTP messages from the Transport service on the local Mailbox server or on other Mailbox servers.
2. The Mailbox Transport Submission service connects to the local mailbox database.
3. The Mailbox Transport Submission service uses RPC to deliver the message. The basic delivery process works like this:
1. The Mailbox Transport Delivery service connects to the local mailbox data- base using RPC to retrieve messages.
2. The Mailbox Transport Delivery service submits messages over SMTP to the Transport service on the local Mailbox server or on other Mailbox servers.
3. The Transport service routes messages using SMTP.
Messages from inside the organization enter the transport pipeline through a Receive connector, from the Mailbox Transport Delivery service, from the Pickup or Replay directories, or from agent submission. Messages from outside the organi- zation enter the transport pipeline through a Receive connector in the Front End Transport service on a Client Access server and are then routed to the Transport service on a Mailbox server.