Exchange Server 2007 uses queues as temporary repositories for messages until they're processed. There are five different types of messaging queues in Exchange Server 2007:
- Submission queue
- Mailbox delivery queue
- Remote delivery queue
- Poison message queue
- Unreachable queue
The submission queue is probably the most important messaging queue in Exchange Server 2007. This queue is persistent, even when empty, and is considered the backbone of Exchange 2007's transport architecture.
The submission queue is related to the submission task, which refers to the process of adding a message to the transport pipeline. Any message that passes through the Exchange Server 2007 transport enters the pipeline through the submission process. There are four ways in which submission can occur.
- SMTP submission -- This process involves an outside entity that sends an SMTP message to the organization. The message enters the organization through an Edge Transport server, which scrutinizes the message to make sure that it's not spam. The Edge Transport server then routes the message through a receive connector to a Hub Transport server, where it is submitted into the submission queue.
Directories -- Submission also occurs when a correctly formatted message is copied into either the replay directory or the pickup directory. These directories exist by default on every Exchange 2007 server that's hosting Edge Transport Server or Hub Transport Server roles.
The replay directory links foreign mail gateways to an Exchange Server. When messages arrive through the foreign gateway, they are placed into the replay directory for submission and delivery.
The pickup directory tests mail flow. Administrators can place correctly formatted messages into this folder, and they will be submitted and eventually delivered. Although the pickup directory was designed mainly for testing, some applications place messages into the pickup directory to send them.
- Store driver -- When a user composes and sends an email message through Microsoft Outlook, the message is sent through the Mailbox server hosting the user's mailbox. Instead of trying to deliver the message itself, the Mailbox Server hands the message off to the store driver, which places it into the submission queue.
Agents -- The transport agent might generate and submit messages, for example. Once messages are submitted into the submission queue, the SMTP categorizer handles them. How the categorizer works differs, depending on whether it's running on a Hub Transport server or an Edge Transport server.
If the categorizer is running on an Edge Transport Server role, its responsibilities are minimal. The categorizer places messages into the delivery queue directly. Messages from an Edge Transport server are delivered to a Hub Transport server, not to final recipients.
On the Hub Transport server, the categorizer must perform three primary tasks:
Recipient resolution -- The categorizer determines who will receive the message. If distribution lists are involved, then they are expanded. If journaling is enabled, then that also takes place at this stage.
Routing decisions -- The categorizer must determine how to route the message. Routing is based on a message's intended destination, and typically falls into one of four categories:
- Messages intended for Internet recipients
- Messages intended for recipients with mailboxes on Mailbox servers that reside in the same Active Directory site as the Hub Transport server
- Messages intended for recipients with mailboxes on Mailbox servers that reside in a different Active Directory site than the Hub Transport server
- Messages intended for recipients whose mailbox resides on a legacy Exchange server
Content conversion -- Hub Transport servers can use transport agents to perform in-line message hygiene. This means that filters can be used to eliminate viruses and spam, or you can apply email disclaimers to messages or impose another transport rule, if desired.
Mailbox delivery queue
Mailbox delivery queues are located only on Hub Transport servers and are used to deliver messages to recipients with mailboxes within the Exchange Server organization. Therefore, if a message is intended for a recipient within your Exchange organization, that message will flow through the submission queue first. It then will be placed into the mailbox delivery queue. From there, the message is sent to the mailbox server using an encrypted remote procedure call (RPC).
Remote delivery queue
When a user sends an SMTP message intended for a recipient in a remote domain, that message passes through the submission queue into the remote delivery queue. From there, the message is forwarded to its final destination.
Remote delivery queues can exist on both Hub Transport and Edge Transport servers. This queue isn't used solely to deliver SMTP messages to servers and remote domains. It's used to deliver messages to any destination outside an Active Directory site that contains the Hub Transport or Edge Transport server that the queue exists on. In most cases, this means that the remote delivery queue will be used to send messages across the Internet.
In large organizations though, the remote delivery queue can be used to send messages to other parts of the Exchange Server organization.
The remote delivery queue doesn't always consist of a single queue; it's destination-specific. When Exchange Server must deliver a message to a remote destination, it checks to see if there is a remote delivery queue for that specific location. If no queue exists, then Exchange Server will dynamically create one. Exchange Server will create as many remote delivery queues as necessary. Each remote delivery queue contains messages that are being routed to a common delivery destination.
Just as Exchange Server dynamically creates remote delivery queues, it also deletes these queues when they're no longer needed. By default, Exchange Server 2007 will delete a remote delivery queue if no messages have passed through it in the past three minutes.
Poison message queue
When either a Hub Transport or Edge Transport server fails, some messages passing through the queues at that time could become corrupted. When the server reboots, Exchange Server temporarily suspends all message queues and checks messages within those queues to ensure that they won't be harmful to the Exchange Server. The server deems harmful messages as poison. Such poison messages might cause a queue to freeze, for example.
Exchange Server 2007 moves poison messages to the poison message queue, which remains suspended at all times to prevent delivery of these messages. Every Hub Transport server and Edge Transport server has its own poison message queue. When the queue is empty, Exchange Server hides it from view. The queue becomes visible if a message enters it. This allows you to use the Queue Viewer to examine and/or delete poison messages.
Messages initially enter the transport pipeline through the submission queue. There, they're sorted into other queues based on their destination. Occasionally, a message with an invalid destination may make it into the transport pipeline. When this message is encountered, Exchange places it into the unreachable queue.
Sending messages to multiple recipients
Suppose that a user in your Exchange Sever organization sends a message to multiple recipients. As the message is added to the submission queue, it's assigned a unique identifier. At this point, the message is treated as a single message, even though there are multiple recipients.
When the submission queue processes the message, it checks to see if the message is be sent to multiple recipients. If so, then the Exchange Server checks to see if all of the recipients are in the same destination, or if the message must be sent to multiple destinations. If it's going to multiple destinations, then Exchange Server 2007 will deal with each destination individually. Delivery queues treat one message being sent to recipients in two different domains as two separate messages.
Monitor mail flow with the Exchange Server 2007 Queue Viewer tool
Home: Monitor mail flow with the Exchange Server 2007 Queue Viewer tool
Part 1: Using Queue Viewer in Exchange 2007 to prevent mail flow problems
Part 2: Understanding message queues in Exchange 2007 Queue Viewer
Brien M. Posey, MCSE
ABOUT THE AUTHOR: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this troubleshooting guide? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.