Monitoring Exchange Server 2010 : Monitoring Mail Flow (part 2) - Monitoring Transport Queues

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:

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:

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:

  • DNSConnectorDelivery

  • NonSMTPGatewayDelivery

  • SmartHostConnectorDelivery

  • SmtpRelayWithinAdSitetoEdge

  • MapiDelivery

  • SmtpRelayWithinAdSite

  • SmtpRelaytoRemoteAdSite

  • SmtpRelaytoTiRg

  • Undefined

  • Unreachable

• 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.

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.