SMTP Routing in Exchange 2010 (Part 1)

By /

If you would like to read the other parts in this article series please go to:

 

 

 

Introduction

 

Starting with Exchange Server 2007 all SMTP traffic in Exchange Server is routed through the Hub Transport Server. The reason behind this is ‘compliancy’. By routing all messages through the Hub Transport Server it is always possible to track messages. It is also possible to temporarily store these messages so when a disaster strikes Exchange can always (try to) recover these messages from the Hub Transport Server such as, during a failover in a CCR cluster or a Database Availability Group. In this series of articles I’d like to explain a bit more about the Hub Transport Server and the SMTP message flow within Exchange Server 2010.

 

Message flow

 

In Exchange Server 2010 all messages are always routed through the Hub Transport Server. This is the case for:

 

 

  • Messages routed to and from the Internet, with and without an Edge Transport Server;
  • Messages routed to other Active Directory sites within the Exchange organization;
  • Messages between mailboxes on the same Mailbox Server, even mailboxes within the same Mailbox Database;

 

Yes, you read that last one correct. If there’s one Exchange 2010 Mailbox Server with only two mailboxes on it, and the first mailbox sends a message to the second mailbox, it is routed through the Hub Transport Server.

 

If the Hub Transport Server is not available, the message will not be sent and the message will not leave the mailbox!

 

Transport internals

 

To get a better idea of the message transport in Exchange Server 2010 we have to identify several services in the Exchange environment that play an important role in message routing.

 

 

  1. Mail Submission Service – when a message is created and the Send button is clicked, the new message is placed in the mailbox outbox. There’s a service running on the Mailbox Server role called the “Exchange Mail Submission Service” which notifies the Hub Transport Server that a new message is awaiting for processing. The Mailbox Server has an internal list of Hub Transport Servers in the same Active Directory site (the submission server list) which is updated every 10 minutes. This is done by the server discovery process. A round robin mechanism is responsible for load balancing the SMTP traffic across these Hub Transport Servers;
  2. Store Drivers – the Hub Transport Server’s Store Driver retrieves the message from the Outbox and puts it in the Submission Queue on the Hub Transport Server. The Store Driver uses RPC to retrieve the message from the Mailbox Server. There’s no traffic on port 25 (i.e. SMTP) between the Hub Transport Server and the Mailbox Server;
  3. Submission Queue – this is a queue, located on the Hub Transport Server where all messages are stored that need to be processed. Not only the Store drivers can store messages in the submission queue, but this can also be done through a receive connector or the pickup directory.
  4. Categorizer – the categorizer retrieves messages from the submission queue and determines where the message needs to be sent to. This can be an internal Active Directory recipient or an external recipient. The categorizer also expands distribution groups and identifies alternative recipients or forwarding addresses.
  5. Pickup Directory – this is a directory that is checked once every 5 seconds for new messages. When a message is in the correct EML format it is picked up from this directory and when the process is completed the file is deleted from the pickup directory.

 


Figure 1: Overview of the Hub Transport Server Role

 

Queues

 

A queue is a temporary location where messages that are waiting for processing are stored. The submission queue is already discussed, but there are more queues:

 

 

  • Mailbox Delivery Queue – This queue stores messages that will be delivered to mailboxes on a Mailbox Server. Again, communication between the Hub Transport Server and the Mailbox Server for mailbox delivery is encrypted RPC. Note: a mailbox delivery queue only exists on Hub Transport Servers and not on Edge Transport Servers;
  • Remote Delivery Queue – this is a queue where messages are stores that need to be delivered remotely.  Remote delivery queues can exists on Hub Transport Servers as well as Edge Transport Servers. There’s a remote delivery queue for every domain the Transport Server is sending messages to. So, if there are outbound messages sent to for example [email protected], then a remote delivery queue exists for the domain hotmail.com. These remote delivery queues only exist for a small amount of time. After successful delivering of the message to hotmail.com, the queue for this domain is deleted, but only when no other messages are sent within a couple of minutes. Besides a remote delivery queue for every external domain, there’s also a remote delivery queue for every Active Directory site that contains other Hub Transport Servers;
  • Poison Message Queue – There are specific messages that Exchange considers to be harmful to the Exchange system after a server failure. If such messages are encountered then they are stored in the poison message queue. The poison message is empty during normal operations and therefore it does not appear in the Queue viewer.
  • Unreachable Queue – This queue contains messages that cannot be routed to their original destination, for example after reconfiguring the routing infrastructure.

 

Queue Database Files

 

In Exchange 2003 and earlier the queues were stored on the local disk in the c:\mailroot\queue directory, or a queue directory in the Exchange Server directory. Exchange Server 2007 and Exchange Server 2010 store their queues in an ESE database. This database is located in the “C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue” directory. ESE operations on this Queue Database file are similar to those of a normal ESE Mailbox Database file. So transactions are stored to the log files first and later on are committed to the Queue Database file. The checkpoint file keeps track of which transactions are already written to the Queue Database file.

 

Log files of the Queue Database file “circular logging” are enabled by default. This means that older log files are deleted when they are no longer needed. Because of this, it is not possible to recover old data from the log files. Since the data in the Queue Database file is volatile (i.e. it exists for a short period of time in the queue and the database) this is not an issue.

 

The Queue Database consists of the following files:

 

 

  • Mail.que – the actual Queue Database file;
  • Tmp.edb – temporary file for Queue Database file operations;
  • Trn*.log – the individual log files for storing Queue Database transactions;
  • Trn.chk – the checkpoint file that keeps track which transactions are already committed to the Queue Database;
  • Trnres00001.jrs and Trnres00002.jrs – two reserved empty log files that are used when the disk is full during normal log file operations.

 


Figure 2: The Queue directory on local disk. Already 2459 log files (99B hexadecimal) are createdon this server.

 

Summary

 

We have seen the message transport in Exchange and services that play an important role in message routing and went through the various queues of the Exchange database. In my next article I will cover the communication between Exchange Hub Transport Servers in more detail.

 

 

If you would like to read the other parts in this article series please go to:

 

 

 

About The Author

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top