In Exchange 2010 a number of improvements were made in regards to message transport. The introduction of Database Availability Groups required a different approach to ensure that message loss would not occur in the event of a failure of a mailbox server. In this article I’m going to highlight some of those improvements as well as provide an overview of the transport process.
Alright let’s start with the major transport changes, some of which were mentioned in my previous post on high availability.
- Shadow redundancy- Ensures messages are delivered to each next hop reaching their destinations before they are deleted.
- MailTips-Provides information to senders while a message is being composed. For example, if a recipient has their out of office message set the sender will be notified while composing the message.
- Moderated transport-A type of approval workflow where messages sent to set senders require an approval from a moderator.
- Federated delivery-Sharing of information between two Exchange organizations.
- Latency service level agreement (SLA) management- Ability to measure latencies for each hop, as well as end-to-end latency.
- End-to-end message tracking-Allows users to track the delivery of messages from submission to its destination mailbox.
- Incremental EdgeSync- Reducing network traffic and increasing efficiency Incremental EdgeSync only synchronize the changes since the last replication cycle.
- Transport rules integration with AD RMS-The ability to create rules the utilize AD rights management services based on content.
- Transport database improvements-Improvements in the transport database have resulted in reduced database IOPS per message increasing throughput.
- Transport dumpster improvements-the transport dumpster now receives information from the replication pipeline to determine the status of message delivery and replication.
Ok, now that we’ve highlighted some of the improvements let’s take a look at how transport works in Exchange 2010. There’s a great article on TechNet that highlights the process in more detail but I’ve simplified it below.
- SMTP Receive-Messages are filtered and the sender and recipient are identified. If the message isn’t rejected it is then put into the submission queue.
- Submission-Messages await here until the categorizer picks them up for categorization
- Categorizer-It is here that the messages are categorized by completing the following processes
- Recipient resolution
- Content conversion
- Local Delivery-Messages with a mailbox in the same Active Directory site are considered a local delivery. The messages are picked up by the store driver from a delivery queue.
- SMTP Send-Messages in a different Active Directory site are delivered to the remote site or routed to an external organization.
Now on to the high availability component of Exchange 2010 transport, Shadow Redundancy. To illustrate a simple scenario I’ve borrowed a snippet from a TechNet article, the complete version can be found here. I recommend reading the complete article for a thorough explanation of the feature.
- The Hub Transport server delivers a message to the Edge Transport server.
- The Hub Transport server opens an SMTP session with the Edge Transport server.
- The Edge Transport server advertises shadow redundancy support.
- The Hub Transport server notifies the Edge Transport server to track discard status.
- The Hub Transport server submits the message to the Edge Transport server.
- The Edge Transport server acknowledges the receipt of the message and records the Hub Transport server identity for sending discard information for the message.
- The Hub Transport server moves the message to the shadow queue for the Edge Transport server and marks the Edge Transport server as the primary server. The Hub Transport server becomes the shadow server.
- The Edge Transport server delivers the message to the next hop.
- The Edge Transport server submits the message to a third-party mail server.
- The third-party mail server acknowledges the receipt of the message.
- The Edge Transport server updates the discard status for the message as delivery complete.
- The Hub Transport server queries the Edge Transport server for discard status (success case).
- At the end of each SMTP session with the Edge Transport server, the Hub Transport server queries the Edge Transport server for discard status on messages previously submitted. If the Hub Transport server hasn't opened any SMTP sessions with the Edge Transport server after the initial message submission, it will open an SMTP session with the Edge Transport server just to query for the discard status after a specific amount of time.
- The Edge Transport server checks the local discard status and sends back the list of messages that have been delivered, and removes the discard information.
- The Hub Transport server deletes the list of messages from its shadow queue.
- The Hub Transport server queries the Edge Transport server for the discard status and resubmits the message (failure case).
- If the Hub Transport server can't contact the Edge Transport server, the Hub Transport server resumes the primary server role and resubmits the messages in the shadow queue.
- Resubmitted messages are delivered to another Edge Transport server and the workflow starts from stage 1.
There are a number of improvements in transport for Exchange 2010. If you’d like more information on some of the features I’ve mentioned please leave a comment below and I’ll address. Check back next week for a new article, on the upcoming Microsoft Exchange Conference which we'll be attending later this month.