Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2011-04-28
This topic provides an overview of queues in Microsoft Exchange Server 2010 and the queue management tasks that administrators can perform.
Looking for management tasks related to managing transport servers? See Managing Transport Servers.
Contents
Message Retry, Resubmit, and Expiration Intervals
Overview
A queue is a temporary holding location for messages that are waiting to enter the next stage of processing. Each queue represents a logical set of messages that a transport server processes in a specific order.
The Exchange Management Shell and Queue Viewer support two types of interaction with queues. You can use these interfaces to view the status and contents of queues and detailed message properties. You can also use these interfaces to perform actions that modify queues or the messages in the queues.
Exchange 2010 uses an Extensible Storage Engine (ESE) database for queue storage. Formerly known as JET, ESE is a method that defines a low-level API to the underlying database structures in Exchange.
Messages that come from and go to the Internet are queued at the computers that have the Edge Transport server role installed. Messages in transit within the Exchange 2010 organization are queued at the computers that have the Hub Transport server role installed.
Types of Queues
The routing of a message determines the type of queue in which a message is stored. The following types of queues are used in Exchange 2010:
- Submission queue A persistent queue
that's used by the categorizer to gather all messages that have to
be resolved, routed, and processed by transport agents. The
categorizer is a component of Exchange transport that
processes all inbound messages and determines what to do with the
messages based on information about the intended recipients. In
Exchange 2010, the Edge Transport server uses the categorizer to
route the message to the appropriate destination. The Hub Transport
server 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.
All messages that are received by a transport server enter processing in the Submission queue. Messages are submitted through a Receive connector, the Pickup directory, or the store driver. The categorizer retrieves messages from this queue and, among other things, 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. Each Exchange 2010 transport server has only one Submission queue. Messages that are in the Submission queue can't be in other queues at the same time.
- Mailbox delivery queue The mailbox
delivery queues hold messages that are being delivered to a Mailbox
server by using encrypted Exchange RPC. Mailbox delivery queues
exist on Hub Transport servers only. Mailbox delivery queues hold
messages that are being delivered to mailbox recipients whose
mailbox data is stored on a Mailbox server that's located in the
same site as the Hub Transport server. More than one mailbox
delivery queue can exist on a Hub Transport server. The next hop
for a mailbox delivery queue is the distinguished name of the
mailbox store.
- Remote delivery queue Remote delivery
queues hold messages that are being delivered to a remote server by
using SMTP. Remote delivery queues can exist on both Hub Transport
servers and Edge Transport servers, and more than one remote
delivery queue can exist on each server. Each remote delivery queue
contains messages that are being routed to recipients that have the
same delivery destination. On an Edge Transport server, these
destinations are external SMTP domains or SMTP connectors. On a Hub
Transport server, these destinations are outside the Active
Directory site in which the Hub Transport server is located. Remote
delivery queues are dynamically created when they're required and
are automatically deleted from the server when they no longer hold
messages and the 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 IP address, or
an Active Directory site name.
- Poison message queue The poison message
queue is a special queue that's used to isolate messages that are
detected to be potentially harmful to the Exchange 2010 system
after a server failure. Messages that contain errors that are
potentially fatal to the Exchange system are delivered to the
poison message queue. This queue is typically empty, and if no
poison messages exist, the queue doesn't appear in the queue
viewing interfaces. The poison message queue is always in a ready
state. By default, all messages in this queue are suspended. The
messages can be deleted if they're considered to be harmful to the
system. If the event that caused the message to enter the poison
message queue is determined to be unrelated to the message,
delivery of the message can be resumed. When delivery is resumed,
the message enters the Submission queue.
- Unreachable queue Each transport server
can have only one Unreachable queue. The Unreachable queue contains
messages that can't be routed to their destinations. Typically, an
unreachable destination is caused by configuration changes that
have modified the routing path for delivery. Regardless of
destination, all messages that have unreachable recipients reside
in this queue.
The following table lists the queues that exist on a Hub Transport server or Edge Transport server and their characteristics.
Queues that exist on a Hub Transport server or Edge Transport server
| Queue name | Server role | Number of queues on the server |
|---|---|---|
|
Mailbox delivery queue |
Hub Transport |
One queue for every unique destination Mailbox server |
|
Poison message queue |
Edge Transport Hub Transport |
1 |
|
Remote delivery queue |
Edge Transport Hub Transport |
Edge Transport: One queue for every unique destination SMTP domain or smart host Hub Transport: One queue for every unique remote Active Directory site |
|
Submission queue |
Edge Transport Hub Transport |
1 |
|
Unreachable queue |
Edge Transport Hub Transport |
1 |
When a message is received by transport, a transport mail item is created and saved to the database. A unique identifier is assigned to the transport mail item when it enters the database. If a message, or transport mail item, is being routed 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 is a reference to the transport mail item and is the unit of operation for queuing actions. If a transport mail item has more than one routing solution, more than one routed mail item references the same transport mail item. A message that's being sent to recipients in two different domains appears as two distinct messages in the delivery queues, even if only one transport mail item is in the database.
About the Poison Message Queue and the Unreachable Queue
The categorizer sends messages to the Unreachable queue when there's no known route to their destinations. Typically, an unreachable destination is caused by a configuration error that affects the delivery path. For example, the messages will be sent to the Unreachable queue if the following conditions are true:
- There are messages in the remote delivery queue named
Contoso.com.
- You delete the Send connector that's used to reach the
Contoso.com domain.
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're 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 Exchange 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. All messages in the poison message queue are in a permanently suspended state. The poison message queue can't be resubmitted with the Retry-Queue cmdlet with the Resubmit parameter. To resubmit the messages in the poison message queue, you can use Queue Viewer or the Resume-Message cmdlet to resume the messages. The messages in the poison message queue are never automatically resumed or expired. Messages remain in the poison message queue until they're manually resumed or removed by an administrator.
Queue Database Files
All the different queues are stored in a single ESE database. By default, this queue database is located at C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue.
Like any ESE database, the queue database uses log files to accept, track, and maintain data. To enhance performance, all message transactions are written first to log files and memory, and then to the database file. The checkpoint file tracks the transaction log entries that have been committed to the database. During an ordinary shutdown of the Microsoft Exchange Transport service, uncommitted database changes that are found in the transaction logs are always committed to the database.
Circular logging is used for the queue database. This means that the history of committed transactions that are found in the transaction logs isn't maintained. Any transaction logs that are older than the current checkpoint are immediately and automatically deleted. Therefore, the transaction logs can't be replayed for queue database recovery from backup.
The following table lists the files that constitute the queue database.
Files that constitute the queue database
| File | Description |
|---|---|
|
Mail.que |
This queue database file stores all the queued messages. |
|
Tmp.edb |
This temporary database file is used to verify the queue database schema on startup. |
|
Trn*.log |
This transaction log records all changes to the queue database. Changes to the database are first written to the transaction log and then committed to the database. Trn.log is the current active transaction log file. Trntmp.log is the next provisioned transaction log file that's created in advance. If the existing Trn.log transaction log file reaches its maximum size, Trn.log is renamed to Trnnnnn.log, where nnnn is a sequence number. Trntmp.log is then renamed Trn.log and becomes the current active transaction log file. |
|
Trn.chk |
This checkpoint file tracks the transaction log entries that have been committed to the database. This file is always in the same location as the mail.que file. |
|
Trnres00001.jrs Trnres00002.jrs |
These reserve transaction log files act as placeholders. They're only used when the hard disk that contains the transaction log runs out of space to stop the queue database cleanly. |
Options for Configuring the Queue Database
You can't use the Exchange Management Console (EMC) or the Shell to configure the queue database. You configure the queue database by modifying the EdgeTransport.exe.config file. The EdgeTransport.exe.config file is an XML application configuration file that's associated with the EdgeTransport.exe file.
For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File.
The <appSettings> section of the
EdgeTransport.exe.config file is where you can add new
configuration options or modify existing configuration options.
Many configuration options that are completely unrelated to the
queue database are also available. However they're outside the
scope of this topic and won't be discussed.
The configuration options for the queue database that are available in the EdgeTransport.exe.config file are described in the following table.
Message queue database configuration options that are available in the EdgeTransport.exe.config file
| Parameter name | Description |
|---|---|
|
QueueDatabaseBatchSize |
This parameter specifies the number of database I/O operations
that can be grouped together before they're executed. The default
value is |
|
QueueDatabaseBatchTimeout |
This parameter specifies the maximum time in milliseconds that the database will wait for multiple database I/O operations to group before it executes them. The database I/O operations are executed without waiting for any more if the following conditions are true:
The default value is |
|
QueueDatabaseMaxConnections |
This parameter specifies the number of ESE database connections
that can be open. The default value is |
|
QueueDatabaseLoggingBufferSize |
This parameter specifies the memory that's used to cache the
transaction records before they're written to the transaction log
file. The default value is |
|
QueueDatabaseLoggingFileSize |
This parameter specifies the maximum size of a transaction log
file. When the maximum log file size is reached, a new log file is
opened. The default value is |
|
QueueDatabaseLoggingPath |
This parameter specifies the default directory for the queue database log files. The default value is C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue. Before you change the queue database logging directory, make sure that the new directory exists. Also make sure that the following file permissions are applied to it: Network Service: Full Control; System: Full Control; Administrators: Full Control. |
|
QueueDatabaseMaxBackgroundCleanupTasks |
This parameter specifies the maximum number of background
cleanup work items that can be queued to the database engine thread
pool at any time. The default value is |
|
QueueDatabaseOnlineDefragEnabled |
The parameter enables or disables scheduled online
defragmentation of the mail queue database. The default value is
|
|
QueueDatabaseOnlineDefragSchedule |
This parameter specifies the time of day in 24 hour format
to start the online defragmentation of the mail queue database. To
specify a value, enter the value as a time: hh:mm:ss, where
h = hours, m = minutes, and s = seconds. The
default value is |
|
QueueDatabaseOnlineDefragTimeToRun |
This parameter specifies the time that span the online
defragmentation task is allowed to run. Even if the defragmentation
task doesn't finish in the time specified, the queue database is
left in a consistent state. To specify a value, enter the value as
a time span: hh:mm:ss, where h = hours, m =
minutes, and s = seconds. The default value is
|
|
QueueDatabasePath |
This parameter specifies the default directory for the queue database files. The default value is C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue. Before you change the queue database directory, make sure that the new directory exists. Also make sure that the following file permissions are applied to it: Network Service: Full Control; System: Full Control; Administrators: Full Control. |
Queue Management
When you experience a mail flow problem or an influx of spam, you can perform operations that modify the status of queues and messages that are located in queues. You can perform an action on a single object, or you can perform a bulk action on more than one selected object. Use the Queue Viewer graphical user interface and commands in the Shell in Exchange 2010 to retrieve information about messages and delivery queues. After you retrieve this information, you can select the queues and messages that you want to manage.
You use Queue Viewer or commands in the Shell to create filter criteria to identify the queues and messages that you want to manage. The filter criteria are based on the following attributes:
- Queue state
- Queue properties
- Message state
- Message properties
For more information about how to filter queues, see Filter Queues. For more information about how to filter messages, see Filter Messages in Queues.
Queue Management Tasks
You use Queue Viewer or commands in the Shell to view information about queues and messages. You can also use these tools to perform the following actions:
- Suspend queue This action temporarily
prevents delivery of messages that are currently in the queue. The
queue continues to accept new messages, but no messages leave the
queue. For more information, see Suspend Queues.
- Resume queue This action reverses the
effect of the suspend queue action and enables delivery of queued
messages to resume. For more information, see Resume Queues.
- Retry queue When a connection to the
next hop for a queue fails, a retry timer is set. The retry timer
schedules subsequent connection tries. The retry queue action
overrides the next scheduled connection attempt and tries to
connect to the next hop immediately. If no connection is made, the
next retry time is reset. For more information, see Retry Queues.
You can also use the Retry-Queue cmdlet together with the Resubmit parameter to cause the messages in the queue to be resubmitted to the Submission queue and to go back through the categorization process. You can manually resubmit messages that have the following status:
- Mailbox delivery queues or remote delivery queues that have the
status of Retry. The messages in the queues must not be in the
Suspended state.
- Messages in the Unreachable queue that aren't in the Suspended
state.
- Messages in the poison message queue.
- Mailbox delivery queues or remote delivery queues that have the
status of Retry. The messages in the queues must not be in the
Suspended state.
- Suspend message This action temporarily
prevents delivery of a message. You can use the suspend message
action to prevent delivery of a message to all the recipients in a
specific queue or to all recipients in all queues. For more
information, see Suspend
Messages.
- Resume message This action reverses the
effect of the suspend message action and enables delivery of queued
messages to resume. You can use the resume message action to resume
delivery of a message to all the recipients in a specific queue or
to all recipients in all queues. You can also use this action to
resubmit messages in the poison message queue. For more
information, see Resume Messages.
- Remove message This action permanently
prevents delivery of a message. You can use the remove message
action to prevent delivery of a message to any recipients in a
specified queue or to all recipients in all queues. You can also
configure the remove message action to send a non-delivery report
(NDR) to the sender when the message is removed. For more
information, see Remove Messages from
Queues.
- Export message This action copies a
message to the file path that you specify. The messages aren't
deleted from the queue, but a copy of the message is saved to a
file location. This enables administrators or officials in an
organization to later examine the messages. Before you export a
message, you must suspend the message in the queue so that typical
delivery doesn't continue during the export process. The export
format is compatible with e-mail applications such as
Microsoft Office Outlook. Save the message in .eml format
to make sure that the operating system associates the file with an
e-mail application. For more information, see Export Messages from
Queues.
Queue Filtering Scenarios
Filtering generates different views of the queues. You use the queue properties as filter options. By specifying filter criteria, you can quickly locate queues and take action on them. The following scenarios are examples of how you can use queue filtering to manage message flow:
- You receive a message from the Microsoft System Center
Operations Manager that indicates that a queue length has exceeded
the established threshold. You want to investigate whether a
server-wide mail flow problem exists.
You can create a filter to view all the queues that have a message count that exceeds what you consider typical. If a mail flow problem is indicated, you can select all the queues in the filter results and suspend the queues while you continue to investigate.
- You suspend several queues to investigate the cause of mail
flow problems. You determine that the problem was caused by an
incorrect connector configuration and is now fixed.
You can create a filter to view all the queues that have a status of Suspended, and then select all the queues in the filter results and resume the queues.
Queue Properties to Use When Filtering Queues
You can use the queue properties to create a filter and locate queues that meet specified criteria. The following table lists the queue properties by which you can filter and the valid values for those properties.
Queue properties
| Queue Viewer queue property | Shell queue property | Property type | Value |
|---|---|---|---|
|
Delivery Type |
DeliveryType |
Enumeration |
This value is determined by the next hop selection. The next hop selection identifies where messages are queued for delivery. To use the delivery type property in a filter, you must use the constant values that are assigned to each type. The delivery type can be one of the following values:
|
|
Identity |
Identity |
QueueIdentity |
This value specifies the identity of the queue. Enter the queue identity in the form of Server\destination, where destination is a remote domain, Mailbox server, persistent queue name, or the integer that identifies this queue in the queuing database. |
|
Last Error |
LastError |
String |
This value specifies a text string of the last error that was recorded for a queue. |
|
Last Retry Time |
LastRetryTime |
DateTime |
This value specifies the time of the last connection attempt for a queue that has a status of Retry. |
|
Message Count |
MessageCount |
Ulong |
This value is expressed as an integer that represents the number of items in the queue. |
|
Next Hop Connector |
NextHopConnector |
GUID |
This value is expressed as a system GUID and is the GUID of the connector that was used to create the queue. |
|
Next Hop Domain |
NextHopDomain |
String |
This value specifies the next destination of a delivery queue. The next hop domain can be expressed as follows:
|
|
Next Retry Time |
NextRetryTime |
DateTime |
This value specifies the time of the next connection attempt for a queue that has a status of Retry. |
|
Status |
Status |
Enumeration |
This value specifies the current queue status. A queue can have one of the following status values:
|
Operators to Use When Filtering Queues
When you create a queue filter, you must include an operator for the property value to match. The following table shows the comparison operators that you can use in a filter expression and how each operator functions.
Filter expression operators
| Operator | Shell value | Function | Shell code example |
|---|---|---|---|
|
Equals |
-eq |
This operator is used to specify that the results must exactly match the property value that's supplied in the expression. |
To display a list of all queues that have a status of Retry:
|
|
Does Not Equal |
-ne |
This operator is used to specify that the results shouldn't match the property value that's supplied in the expression. |
To display a list of all queues that don't have a status of Active:
|
|
Greater Than |
-gt |
This operator is used with properties where the value is expressed as an integer. The filter results only include queues where the value of the specified property is greater than the value that's supplied in the expression. |
To display a list of queues that currently contain more than 1,000 messages:
|
|
Greater Than or Equals |
-ge |
This operator is used with properties where the value is expressed as an integer. The filter results only include queues where the value of the specified property is greater than or equal to the value that's supplied in the expression. |
To display a list of queues that currently contain 1,000 or more messages:
|
|
Less Than |
-lt |
This operator is used with properties where the value is expressed as an integer. The filter results only include queues where the value of the specified property is less than the value that's supplied in the expression. |
To display a list of queues that currently contain less than 1,000 messages:
|
|
Less Than or Equals |
-le |
This operator is used with properties where the value is expressed as an integer. The filter results only include queues where the value of the specified property is less than or equal to the value supplied in the expression. |
To display a list of queues that currently contain 1,000 or fewer messages:
|
|
Contains |
-like |
This operator is used with properties where the value is expressed as a text string. The filter results only include queues where the value of the specified property contains the text string that's supplied in the expression. You can include the wildcard character (*) in a -like expression that's applied to a text string field, but not with a field that has the enumeration type. |
To display a list of delivery queues that have a destination to any SMTP domain that ends in Contoso.com:
|
You can specify multiple expressions in your queue filter by using the -and operator in the Shell or by adding multiple expressions in Queue Viewer. Queues must meet all criteria to be included in the result set. For example, the results of the following command will display a list of queues that have a destination to any SMTP domain name that ends in Contoso.com and that currently contain more than 500 messages.
 Copy Code |
|
|---|---|
Get-Queue -Filter {Identity -like "*Contoso.com*" -and MessageCount -gt 500}
|
|
Message Filtering Scenarios
Filtering generates different views of the messages in queues. By specifying filter criteria, you can quickly locate messages and take action on them. When an e-mail message is sent to multiple recipients, the message may be located in multiple queues. When you filter by message properties, you can locate messages across all queues. The following scenarios are examples of how you might use message filtering to manage mail flow:
- The Submission queue on the computer that has the Edge
Transport server role installed has a high volume of messages that
are queued for delivery. Many of the messages have the same
subject. Therefore, you suspect that spam is being sent to your
organization. You can create a filter to view all the messages that
meet the subject criteria. If you determine that the messages are
spam, you can select them all and delete them from the delivery
queue without sending an NDR.
- A user reports that mail flow is slow. You examine the queues
and see that many messages that have random subjects appear to be
coming from a single domain. You can create a filter to view all
the queued messages from that domain. If you determine that the
messages are spam, you can select them all and delete them from the
queues without sending an NDR.
Message Properties to Use When Filtering Messages
You can use message properties to create a filter and locate messages that meet specified criteria. The following table lists the message properties by which you can filter and the values that are associated with those properties.
Message properties
| Queue Viewer message property | Shell message property | Property type | Value |
|---|---|---|---|
|
Date Received |
DateReceived |
DateTime |
This value specifies the time stamp when the message was received by the server that holds the queue in which the message is located. |
|
Expiration Time |
ExpirationTime |
DateTime |
This value specifies the time stamp when the message will expire and be deleted from the queue if the message can't be delivered. |
|
From Address |
FromAddress |
SMTP Address |
This value specifies the SMTP address of the sender of the message. |
|
Identity |
Identity |
Integer |
This value is an integer that represents a particular message. The message identity is assigned by the queuing database when the message is received for processing. You can include an optional server and queue identity to identify a unique instance of the message. This value can be expressed as follows:
|
|
Internet Message ID |
InternetMessageId |
String |
This value specifies the value of the 67D754D6103DC4FB3BA6BC7205DACABA61231@exchange.contoso.com |
|
Last Error |
LastError |
String |
This value specifies a text string of the last error that was recorded for a message. |
|
Message Source Name |
MessageSourceName |
String |
This value specifies a text string of the name of the component that submitted this message to the queue. |
|
Queue ID |
Queue |
QueueIdentity |
The value of this property specifies the identity of the queue that holds the message. Enter the queue identity in the form of Server\destination, where destination is a remote domain, Mailbox server, persistent queue name, or the queuing database identifier. The database identifier is represented as an integer and can be determined by viewing the message properties. |
|
Retry Count |
RetryCount |
Integer |
This value specifies the number of times that delivery of a message to a destination was tried. |
|
SCL |
SCL |
Integer |
The value of the spam confidence level (SCL) property specifies the SCL of the message. Valid SCL entries are integers from 0 through 9. An empty SCL property value indicates that the message hasn't been processed by the Content Filter agent. |
|
Size (KB) |
Size |
ByteQuantifiedSize |
This value specifies the size of the message. |
|
Source IP |
SourceIP |
IP Address |
This value specifies the IP address of the external server that submitted the message to the Exchange organization. |
|
Status |
Status |
Enumeration |
This value specifies the current message status. A message can have one of the following status values:
|
|
Subject |
Subject |
String |
This value specifies the subject of a message that's expressed as a text string. |
Operators to Use When Filtering Messages
When you create a message filter, you must include an operator for the property value to match. The following table shows the comparison operators that you can use in a filter expression and how each operator functions.
Filter expression operators
| Operator | Shell value | Function | Shell code example |
|---|---|---|---|
|
Equals |
-eq |
This operator is used to specify that the results must exactly match the property value that's supplied in the expression. |
To display a list of all messages that have a status of Retry:
|
|
Does Not Equal |
-ne |
This operator is used to specify that the results shouldn't match the property value that's supplied in the expression. |
To display a list of all messages that don't have a status of Active:
|
|
Greater Than |
-gt |
This operator is used with properties where the value is expressed as an integer. The filter results only include messages where the value of the specified property is greater than the value that's supplied in the expression. |
To display a list of messages that currently have a retry count that's more than 3:
|
|
Greater Than or Equals |
-ge |
This operator is used with properties where the value is expressed as an integer. The filter results only include messages where the value of the specified property is greater than or equal to the value that's supplied in the expression. |
To display a list of messages that currently have a retry count that's 3 or more:
|
|
Less Than |
-lt |
This operator is used with properties where the value is expressed as an integer. The filter results only include messages where the value of the specified property is less than the value that's supplied in the expression. |
To display a list of messages that have an SCL that's less than 6:
|
|
Less Than or Equals |
-le |
This operator is used with properties where the value is expressed as an integer. The filter results only include messages where the value of the specified property is less than or equal to the value that's supplied in the expression. |
To display a list of messages that have an SCL that's 6 or less:
|
|
Contains |
-like |
This operator is used with properties where the value is expressed as a text string. The filter results only include messages where the value of the specified property contains the text string that's supplied in the expression. You can include the wildcard character (*) in a -like statement that's applied to a text string field, but not a field that has the enumeration type. |
To display a list of messages that have a subject that contains the text "payday loan":
|
You can specify a filter that evaluates multiple expressions by using the -and comparison operator in the Shell or by adding multiple expressions in Queue Viewer. To be included in the result set, messages must meet all conditions of the filter. For example, the results of the following command will display a list of messages that are sent from any e-mail address that has a domain name that ends in Contoso.com and that have an SCL that's greater than 5.
| Copy Code |
|
|---|---|
Get-Message -Filter {FromAddress -like "*Contoso.com*" -and SCL -gt 5}
|
|
Message Retry, Resubmit, and Expiration Intervals
Messages that can't be successfully delivered are subject to various retry, resubmit, and expiration deadlines based on the message's source and destination. Retry is a renewed connection attempt with the destination domain, smart host, or Mailbox server. Resubmit is the act of sending messages back to the Submission queue for the categorizer to reprocess. The message is said to time-out or expire after all delivery efforts have failed over a specified period of time. After a message expires, the sender is notified of the delivery failure. Then the message is deleted from the queue.
In all three cases of retry, resubmit, or expire, you can manually intervene before the automatic actions are performed on the messages.
Configuration Options for Message Retry
When a transport server can't connect to the next hop, the queue is put in a status of Retry. Connection attempts continue until the queue expires or a connection is made.
Configuration Options for Automatic Message Retry
The configuration options that are available for message retry intervals are described in the following table.
Configuration options that are available for message retry intervals
| Parameter name | Default value | Where to configure | Description |
|---|---|---|---|
|
QueueGlitchRetryCount |
4 |
EdgeTransport.exe.config |
This parameter specifies the number of connection attempts that are immediately tried when a transport server has trouble connecting with the destination server. Such connection problems are typically caused by very brief network outages. Typically, you don't have to modify this parameter unless the network is unreliable and continues to experience many accidentally dropped connections. |
|
QueueGlitchRetryInterval |
1 minute |
EdgeTransport.exe.config |
This parameter controls the connection interval between each connection attempt that's specified by the QueueGlitchRetryCount parameter. Typically, you don't have to modify this parameter unless the network is unreliable and continues to experience many accidentally dropped connections. |
|
TransientFailureRetryCount |
6 |
Set-TransportServer cmdlet or transport server properties in the EMC |
This parameter specifies the number of connection attempts that are tried after the connection attempts that are controlled by the QueueGlitchRetryCount and QueueGlitchRetryInterval parameters have failed. Connection problems that exhaust the QueueGlitchRetryCount and QueueGlitchRetryInterval parameters can be caused by such things as server restarts or cached DNS lookup failures. |
|
TransientFailureRetryInterval |
|
Set-TransportServer cmdlet or transport server properties in the EMC |
This parameter controls the connection interval between each connection attempt that's specified by the TransientFailureRetryCount parameter. |
|
OutboundConnectionFailureRetryInterval |
|
Set-TransportServer cmdlet or transport server properties in the EMC |
This parameter specifies the retry interval for outbound connection attempts that have previously failed. The previously failed connection attempts are controlled by the TransientFailureRetryCount and TransientFailureRetryInterval parameters. |
|
MessageRetryInterval |
1 minute |
Set-TransportServer cmdlet |
This parameter specifies the retry interval for individual messages that have a status of Retry. We recommend that you don't modify the default value unless Microsoft Customer Service and Support advises you to do this. |
|
MailboxDeliveryQueueRetryInterval |
5 minutes |
EdgeTransport.exe.config |
This parameter controls the retry interval for mailbox delivery queues between Hub transport servers. |
The <appSettings> section of the
EdgeTransport.exe.config file is where you can add new
configuration options or modify existing configuration options.
There are many configuration options available that are completely
unrelated to the message retry, resubmit, and expiration intervals.
Any configuration options that don't involve these intervals are
outside the scope of this topic.
For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File.
For more information, see Configure Message Retry, Resubmit, and Expiration Intervals.
Configuration Options for Manual Message Retry
When a mailbox delivery queue or a remote delivery queue is in the status of Retry, you can manually force an immediate connection attempt by using Queue Viewer in the EMC or the Retry-Queue cmdlet in the Shell. The manual retry attempt overrides the next scheduled retry time. If the connection isn't successful, the retry interval timer is reset. The delivery queue must be in a status of Retry for this action to have any effect.
For more information, see Retry Queues.
Configuration Options for Delay DSN Messages
After each message delivery failure, the Edge Transport server or the Hub Transport server generates a delay delivery status notification (DSN) message and queues it for delivery to the sender of the undeliverable message. This delay DSN message is sent only after a specified delay notification time-out interval, and only if the failed message wasn't successfully delivered during that time. By default, the delay notification time-out interval is 4 hours. This delay prevents the sending of unnecessary delay DSN messages that may be caused by temporary message transmission failures. The sending of delay DSN notification messages can be selectively enabled or disabled for messages that originate inside or outside the Exchange organization.
The configuration options that are available for delay DSN notification messages are described in the following table.
Configuration options that are available for delay DSN notification messages
| Parameter name | Default value | Location | Description |
|---|---|---|---|
|
DelayNotificationTimeOut |
4 hours |
Set-TransportServer |
This parameter specifies how long the server waits before it sends a delay DSN message to the message's sender. The value of this parameter should always be greater than the value of the TransientFailureRetryCount parameter multiplied by the value of the TransientFailureRetryInterval parameter. |
|
ExternalDelayDSNEnabled |
|
Set-TransportConfig |
This parameter specifies whether delay DSN messages can be sent to message senders who are outside the Exchange organization. |
|
InternalDelayDSNEnabled |
|
Set-TransportConfig |
This parameter specifies whether delay DSN messages can be sent to message senders who are inside the Exchange organization. |
For more information, see Configure Message Retry, Resubmit, and Expiration Intervals.
Configuration Options for Message Resubmission
Message resubmission sends undelivered messages back to the Submission queue to be reprocessed by the categorizer.
Automatic Message Resubmission
Undelivered messages are automatically resubmitted if the delivery queue is in the status of Retry and has been unable to successfully deliver any messages for a specified period of time. That period of time is controlled by the MaxIdTimeBeforeResubmit parameter in the EdgeTransport.exe.config application configuration file. By default, the value of the MaxIdTimeBeforeResubmit parameter is 12 hours. Only messages in mailbox delivery queues or remote delivery queues are candidates for automatic resubmission.
For more information, see Configure Message Retry, Resubmit, and Expiration Intervals.
Manual Message Resubmission
You can manually resubmit messages that have the following status on a Hub Transport server or an Edge Transport server:
- Mailbox delivery queues or remote delivery queues that have the
status of Retry. The messages in the queues must not be in the
Suspended state.
- Messages that are in the Unreachable queue and aren't in the
Suspended state.
- Messages that are in the poison message queue.
For more information about the poison message queue and the Unreachable queue, see "About the Poison Message Queue and the Unreachable Queue" earlier in this topic.
If you want to manually resubmit messages that are located in the mailbox delivery queues, the remote delivery queues, or the Unreachable queue without waiting for the time that's specified by the MaxIdleTimeBeforeResubmit parameter to pass, you must use the Retry-Queue cmdlet with the Resubmit parameter. To manually resubmit messages that are located in the poison message queue, you can use Queue Viewer or the Resume-Message cmdlet to resume the message.
For more information, see the following topics:
Another way that you can manually resubmit messages is to suspend the messages, export the messages to text files that have the .eml file name extension, and then copy the .eml files to the Replay directory on any Hub Transport server or Edge Transport server. This resubmission method works for messages that are located in the mailbox delivery queues, remote delivery queues, or the Unreachable queue. Messages that are located in the poison message queue are already in the Suspended state. Messages that are located in the Submission queue can't be suspended or exported.
 Note: |
|---|
| When you export messages from a queue, you don't remove the messages from the queue. After you export the messages and successfully resubmit them by using the Replay directory, you should remove the suspended messages to avoid duplicate message delivery. |
For more information, see Export Messages from Queues and Resubmit Messages in Queues.
Configuration Options for Message Expiration
The message expiration time-out interval specifies the maximum length of time that an Edge Transport server or a Hub Transport server tries to deliver a failed message. If the message can't be successfully delivered before the expiration time-out interval has passed, an NDR that contains the original message or the message headers is delivered to the sender.
Automatic Message Expiration
The message expiration time-out interval is controlled by the MessageExpirationTimeOut parameter in the Set-TransportServer cmdlet or in the transport server properties in the EMC. By default, the value of the MessageExpirationTimeOut parameter is 2 days.
For more information, see the following topics:
Manual Message Expiration
Although you can't manually force messages to expire, you can manually remove messages from any queue, except the Submission queue, with or without an NDR.
For more information, see Remove Messages from Queues.