2. Monitoring Transport Queues
If a mailbox database is experiencing performance problems, this typically
manifests itself in excessively long transport queues associated with the
database. If a Hub Transport or Edge Transport server becomes overloaded, this
can result in an excessive number of messages in the transport queues on that
server. It is a good idea to monitor transport queues on a regular basis, and
you would typically look at queue statistics as a matter of course when you
encounter performance problems.
You can use both the EMC and the EMS to monitor transport queues. To use the
EMC on a Hub Transport server, carry out the following procedure:
Open the EMC on the Hub Transport server and expand the Console
tree.
Click Toolbox in the Console tree.
Click Queue Viewer in the Result pane.
Click Open Tool in the Actions pane.
Click the Queues tab in Queue Viewer, shown in Figure 2. This displays a list of the queues on the
server to which you are connected. Note that you are unlikely to see any
queues on your isolated test network.
If you want to export the list of
queues, click Export List in the Actions pane. If you want a list of
messages in a queue, click the queue in the Queues tab in the Result
pane and click View Messages in the Actions pane.
You can use the Get-Queue EMS cmdlet to view transport
queues. For example, the following command lets you view all the queues on the
Hub Transport or Edge Transport server on which it is entered:
Get-Queue | FL
The following command displays detailed information for a queue that exists on
the server VAN-EX1:
Get-Queue -Server VAN-EX1 | FL
Figure 3 shows the output
from this command.
2.1. Filtering Queues
In
a busy Exchange Server 2010 organization, the number of queues can become
very large, depending on the current mail flow. The queue list can change
frequently as messages enter and leave a server. You can filter queues to
search for specific criteria and locate queues that are experiencing mail
flow problems. You can use the Exchange Queue Viewer in the EMC and EMS
commands to filter queues. You can then perform operations that modify the
status of those queues.
To use the Queue Viewer to filter queues on a Hub Transport server, carry
out the following procedure:
Open the EMC on the Hub Transport server and expand the Console
tree.
Click Toolbox in the Console tree.
Click Queue Viewer in the Result pane.
Click Open Tool in the Actions pane.
Click the Queues tab in Queue Viewer.
In the queue property drop-down list, select a queue property. The
options available are shown in Figure 4.
Select a comparison operator from the comparison operator
drop-down list (for example, Equals).
Depending on the queue property you have chosen, either type a
value in the value drop-down list or select a value from the
drop-down list. If the property requires a date/time expression,
change the current date/time values or click the drop-down list
to select
a date from the calendar interface. Figure 5 shows the
options available for the Status queue property.
Optionally, click Add Expression and specify additional filter
criteria. Only queues that meet all filter criteria are
displayed.
Click Apply Filter to display only queues that meet the filter
criteria.
You can also use the Get-Queue EMS cmdlet with the
Filter parameter to filter queues. For example, the following command lists
all the queues on the Hub Transport or Edge Transport server on which it is
entered that contain more than 50 messages:
Get-Queue -Filter {MessageCount -gt 50}
You can also use the Filter parameter of the
Get-Queue cmdlet to display the number of messages
in queues bound for a particular destination. For example, the following
command displays the number of messages in queues on the Hub Transport or
Edge Transport server on which it is entered where the next-hop destination
is the Contoso.com domain:
Get-Queue -Filter{NextHopDomain -eq "contoso.com"}
You can also use a remote server name or site name in place of the SMTP
domain name.
In general, the Filter parameter requires an expression that identifies
the queues that you want to display. The expression includes a property name
followed by a comparison operator and value. The following queue properties
are valid for the Filter parameter:
DeliveryType
The delivery type for a queue must be one of the following
values:
Identity
The queue identity takes the form Server\destination, where
destination is a remote domain, Mailbox server, or persistent
queue name.
LastError
A text string that contains the last error recorded for a
queue.
LastRetryTime
The time when a connection was last tried for this
queue.
MessageCount
The number of items in the queue.
NextHopConnector
The GUID of the connector that was used to create the
queue.
NextHopDomain
The next hop domain of the queue, specified as a remote SMTP
domain, a server name, the name of an Active Directory site, or
a message database identifier.
NextRetryTime
The time when a connection will next be tried for this
queue.
Status
The status of the queue. The queue status can be Active,
Ready, Retry, or Suspended.
Note:
QUEUE STATUS
You can manually suspend and resume queues. The delivery queue on a
Hub Transport or Edge Transport server is automatically put in a Retry
status when the server cannot connect to the next hop. You can use
either the EMC or the EMS to retry a queue.
Note:
The list of queue properties that are valid for the Filter parameter
can look daunting. However, you are unlikely to be asked to generate a
complex filter condition in the examination, although you might need to
do so as part of your job. You might be asked to identify a valid filter
condition that, for example, displays queues marked as unreachable or
queues that are suspended. The best way to become familiar with filter
conditions is to generate and enter commands that use them.
2.2. Queue Types
How a message is routed determines the type of queue in which it is
stored. The following types of queues are used in Exchange Server
2010:
Submission queue
A submission queue is a persistent queue that the categorizer
uses to store messages that need to be resolved, routed, and
processed by transport agents. All messages that are received by
a Transport server are held in the submission queue before
processing. Messages are submitted through SMTP-receive, the
Pickup directory, or the store driver. The categorizer retrieves
messages from this queue and determines the location of the
recipient and the route to that location. After categorization,
the message is moved to a delivery queue or to the unreachable
queue. Only one submission queue exists on each Exchange Server
2007 Transport server. Messages that are in the submission queue
cannot be in other queues at the same time.
Note:
THE CATEGORIZER
The categorizer is an Exchange transport component that
processes all inbound messages and determines what to do with
them on the basis of information about their intended
recipients. In Exchange 2010, a server with the Edge Transport
role uses the categorizer to route messages to their appropriate
destinations. A server with the Hub Transport role uses the
categorizer to expand distribution lists and to identify
alternative recipients and forwarding addresses. After the
categorizer retrieves full information about recipients, it uses
that information to apply policies, route the message, and
perform content conversion.
Mailbox delivery
queue
A mailbox delivery queue holds messages that are delivered to
a Mailbox server by using an encrypted Exchange RPC. Mailbox
delivery queues exist only on servers with the Hub Transport
role. A mailbox delivery queue holds messages that are being
delivered to mailbox recipients whose mailbox data is stored on
a Mailbox server located in the same site as the Hub Transport
server. Several mailbox delivery queues can exist on a server
with the Hub Transport role. The next hop for a mailbox delivery
queue is defined by the distinguished name of the mailbox
store.
Remote delivery
queue
A remote delivery queue holds messages that are being
delivered to a remote server by using SMTP. Remote delivery
queues can exist on servers with both the Hub Transport and the
Edge Transport role, and more than one remote delivery queue can
exist on each server. A remote delivery queue contains
messages that are being routed to
recipients that have the same delivery destination. On a server
with the Edge Transport role, these destinations are external
SMTP domains or SMTP connectors. On a server with the Hub
Transport role, the destinations are outside the Active
Directory site in which the server with the Hub Transport role
is located. A server with the Hub Transport role can also route
Internet email. Remote delivery queues are created dynamically
as required and are automatically deleted from the server when
they no longer hold messages and when their (configurable)
expiration time has passed. By default, a remote delivery queue
is deleted three minutes after the last message has left the
queue. The next hop for a remote delivery queue is an SMTP
domain name, a smart host name or Internet Protocol (IP)
address, or an Active Directory site name.
Poison message
queue
The poison message queue is a special queue that is used to
isolate messages that are potentially harmful to Exchange Server
2010. This queue is typically empty. If no poison messages
exist, the queue does not appear in queue-viewing interfaces
such as Queue Viewer. The poison message queue is always in a
Ready state. By default, all messages in this queue are
suspended. You can delete the messages if you judge that they
are harmful to the system. If an event that causes a message to
enter the poison message queue is unrelated to the message,
message delivery can be resumed. If delivery is resumed, the
message enters the submission queue.
Note:
DETERMINING WHETHER A MESSAGE IS A POISON
MESSAGE
A poison message is a message that has exceeded the maximum number of
delivery attempts to an application. For more information about poison
message identification and how these messages are handled, see
http://msdn.microsoft.com/en-us/library/ms789028.aspx.
Unreachable queue
The unreachable queue contains messages that cannot be routed
to their destinations. An Edge Transport or Hub Transport server
can have only one unreachable queue. Typically, an unreachable
destination can be created when configuration changes modify the
delivery routing path. All messages that have unreachable
recipients reside in the unreachable queue.
When a message is received, a transport mail item is created and saved to
the database, and a unique identifier is assigned to the item. If a message
or transport mail item is being sent to more than one recipient, the item
can have more than one destination. Each destination represents a separate
routing solution for the transport mail item, and each routing solution
causes a routed mail item to be created.
The routed mail item refers to the transport mail item. If a transport
mail item has more than one routing solution, more than one routed mail item
references the same transport mail item. A single message addressed to
recipients in two different domains appears as two distinct messages in the
delivery queues, even if there is only one transport mail item in the
database.