Transport Queues Test

Mailbox queues hold messages that are being delivered to a Mailbox server that is located in the same site as the Hub Transport server. Mailbox delivery queues exist only on Hub Transport servers. One mailbox delivery queue exists for each destination Mailbox server.

If the number of messages in the queue grows continuously, it could indicate a processing bottleneck. You might want to investigate this condition further.

Retry is a renewed connection attempt with the destination domain, smart host, or Mailbox server.

Messages in this queue are in a retry state because an issue prevented their delivery. If the issue is transient, a subsequent reattempt to send the message may be successful.

A high value for this measure could indicate any of the following:

• A domain to which you send a large amount of e-mail is down or experiencing problems.
• A computer on your network may be infected with a virus which is sending messages through your Exchange servers.
• Your DNS server may have some issue resolving fully qualified domain names (FQDNs) to IP addresses.
• There may be a network connectivity issue that is preventing your server from properly connecting to destination servers, or the internet. Some possible issues that could affect your connection are:
• Router or routing issues between your server and the destination
• Proxy or gateway server issues.
• Internet Service providers (ISP) issues, such as a cut line, downed system, routing issues, global disturbance, or some other issue.

The resolution to a high retry remote delivery queue length depends on the root cause of this problem. Try one or more of the following to identify and resolve the problem causing the high volume of messages in the remote delivery queue.:

• Check the destination addresses for the messages in the retry queue. If the messages are all addressed to a single domain or small number of domains, verify that the specified domains are valid and functional.
• Verify that there are no machines on your network that are infected with a virus which might be sending messages through your Exchange server(s). Take steps to remove the virus from the infected machine, or remove the machine from your network.
• Check where the retry messages are being sent to, if there a large number of messages addressed to companies that you do not know, do not regularly work with, or with unusual subject lines that look to be spam in nature.
• Confirm that your DNS server can resolve the FQDNs of the affected domains mail exchanger (MX) resource records to IP by using the NSLOOKUP command.

Confirm that there are no network connectivity issues preventing your server from properly connecting to destination servers or the Internet.

Remote delivery queues hold messages that are being delivered to a remote domain or smart host by using the Simple Mail Transfer Protocol (SMTP). After all messages are delivered, these queues persist for three minutes and then are automatically deleted.

A high value of this measure could indicate a processing bottleneck or a poor network link between the Hub Transport server and the remote domain to which messages are to be delivered.

Retry is a renewed connection attempt with the destination domain, smart host, or Mailbox server.

Messages in this queue are in a retry state because an issue prevented their delivery. If the issue is transient, a subsequent reattempt to send the message may be successful.

A high value for this measure could indicate any of the following:

• A domain to which you send a large amount of e-mail is down or experiencing problems.
• A computer on your network may be infected with a virus which is sending messages through your Exchange servers.
• Your DNS server may have some issue resolving fully qualified domain names (FQDNs) to IP addresses.
• There may be a network connectivity issue that is preventing your server from properly connecting to destination servers, or the internet. Some possible issues that could effect your connection are:
• Router or routing issues between your server and the destination
• Proxy or gateway server issues.
• Internet Service providers (ISP) issues, such as a cut line, downed system, routing issues, global disturbance, or some other issue.

The resolution to a high retry remote delivery queue length depends on the root cause of this problem. Try one or more of the following to identify and resolve the problem causing the high volume of messages in the remote delivery queue.:

• Check the destination addresses for the messages in the retry queue. If the messages are all addressed to a single domain or small number of domains, verify that the specified domains are valid and functional.
• Verify that there are no machines on your network that are infected with a virus which might be sending messages through your Exchange server(s). Take steps to remove the virus from the infected machine, or remove the machine from your network.
• Check where the retry messages are being sent to, if there a large number of messages addressed to companies that you do not know, do not regularly work with, or with unusual subject lines that look to be spam in nature.
• Confirm that your DNS server can resolve the FQDNs of the affected domains mail exchanger (MX) resource records to IP by using the NSLOOKUP command.
• Confirm that there are no network connectivity issues preventing your server from properly connecting to destination servers or the Internet.

This refers to the number of messages in the queue for which the Delivery Type has been set to NonSmtpGatewayDelivery. The messages in such a queue are typically queued for delivery to an external recipient by using a non-SMTP connector on the local server.

Messages in this queue are in a retry state because an issue prevented their delivery. If the issue is transient, a subsequent reattempt to send the message may be successful.

The value of this measure could rise, owing to the following reasons:

• A connector that connects to the Non-SMTP mail server might not be functioning properly.
• A domain that you connect to via a Non-SMTP connector might be down or unreachable.
• Your DNS server may have some issue resolving fully qualified domain names (FQDNs) to IP addresses.
• There may be a network connectivity issue that is preventing your server from properly connecting to destination servers or the Internet. Some possible issues that could affect your connection are:
• Router or routing issues between your server and the destination
• Proxy or gateway server issues.
• Internet Service providers (ISP) issues, such as a cut line, downed system, routing issues, global disturbance, or some other issue.

When this value is high, the server cannot establish a SMTP session to the other Hub Transport or Edge Transport server. Other symptoms you may experience when this threshold is reached are reduced intra-site, inter-site, and external mail flow. This alert may be caused by one or more of the following conditions:

• Problem with a specific Hub Transport server or Edge Transport server. For example, one or more required services may not be running.
• Issues with network connectivity, routers, or firewalls.

The categorizer sends messages to the unreachable queue when there is no known route to their destinations. Typically, an unreachable destination is caused by a configuration error that affects the delivery path

By default, the messages in the unreachable queue have the status of Ready. Messages in the unreachable queue are never automatically resubmitted. Messages remain in the unreachable queue until they are manually resubmitted by an administrator, removed by an administrator, or the value specified in the MessageExpirationTimeOut parameter passes.

The poison message queue contains messages that are determined to be potentially harmful to the Microsoft Exchange server 2007/2010 server after a server failure. The messages may be genuinely harmful in their content and format. Alternatively, they may be the results of a poorly written agent that has caused the Exchange server to fail when it processed the supposedly bad messages.

Messages remain in the poison message queue until they are manually resumed or removed by an administrator. The messages in the poison message queue are never automatically resumed or expired.