A queue is a temporary holding location for messages that are waiting to enter the next stage of processing or delivery to a destination. each queue represents a logical set of messages that the exchange server processes in a specific order. In exchange 2016 and exchange 2019, queues contain messages before, during, and after delivery. Queues exist in the Transport service on Mailbox servers and Edge Transport servers. Mailbox servers and Edge Transport servers are referred to as Transport servers in this topic.
like all previous versions of exchange, a single extensible storage engine (ese) database is used for queuing.
You can manage queues and messages in queues using the Exchange Management Shell and the Queue Viewer in the Exchange Toolbox. you can use these interfaces to view the status and content of queues and detailed message properties. you can also perform actions that modify the queues or the messages on the queues. for more information, see procedures for queues and procedures for messages on queues.
queue types
The following types of queues are used in exchange 2016 and exchange 2019, which are the same as in exchange 2013:
delivery queues are dynamically created when needed and automatically deleted when the queue is empty and the expiration time has passed. the queue expiration time is controlled by the queuemaxidletime parameter on the set-transportservice cmdlet. the default value is three minutes.
On Edge Transport servers, there is one queue for each single destination smtp domain or smart host.
On Mailbox servers, there is one queue for each unique destination as indicated by the nexthopsolutionkey property. for more information, see the nexthopsolutionkey section later in this topic.
all messages are transmitted between exchange 2016 and exchange 2013 servers using smtp. non-smtp destinations also use delivery queues if the destination is served by a delivery agent connector. for more information, see delivery agents and delivery agent connectors.
the poison message queue is usually empty. if the poison message queue contains no messages, then it does not appear in the queue management tools. messages in the poison queue are never automatically resumed or expired. messages remain in the poison queue until manually resumed or deleted by an administrator.
Each Mailbox server or Edge Transport server has a single poison message queue.
On Mailbox servers, messages are received by using a Receive connector, the Pickup or Replay directories, or the Mailbox Transport Submit service. On Edge Transport servers, messages are typically received by a Receive connector, but the Pickup and Replay directories are also available.
The categorizer retrieves messages from this queue and, among other things, determines the location of the recipient and the path to that location. after categorization, the message is moved to a delivery queue or the unreachable queue. For more information about the categorizer and the transport pipeline, see Mail flow and the transport pipeline.
Each Mailbox server or Edge Transport server has a single Send queue.
Each Mailbox server or Edge Transport server has only one unreachable queue.
queue database files
all the different queues are stored in a single ese database. By default, this queue database is located on the transport server at %exchangeinstallpath%transportrolesdataqueue.
Like any such database, the queue database uses log files to accept, track, and maintain data. To improve performance, all message transactions are written to the log files and memory first, and then to the database file. the checkpoint file keeps track of transaction log entries that have been committed to the database. During a normal shutdown of the Microsoft Exchange Transport service, uncommitted database changes found in the transaction logs are committed to the database.
circular logging is used for the queue database. this means that transaction logs that are older than the current checkpoint are immediately and automatically deleted. therefore, the transaction logs cannot be replayed for queue database recovery from backup.
The following table lists the files that make up the queue database.
trnres00002.jrs
exchange uses generation tables to store and clean messages in the queue database. instead of processing and deleting individual message records from a large table, the queue database stores messages in time-based tables and only deletes the entire table after all messages in the table have been successfully processed . For example, consider the following example:
-
all messages queued from 1:00 p.m. m. until 2:00 p.m. m., regardless of queue or destination, are stored in the 1p-2p_msgs table.
at 2:00 p.m. m., new messages are stored in the 2p-3p_msgs table.
at 4:00 p.m. m., a new table named 4p-5p_msgs is created. the entire 1p-2p_msgs table is deleted, but only if all messages in the table have been processed successfully.
This approach of removing entire message tables instead of individual messages helps improve the I/O performance of the drive that contains the queue database.
options to configure queue database
Configure the queue database by adding or modifying keys in the %exchangeinstallpath%binedgetransport.exe.config xml application configuration file. This file is associated with the Microsoft Exchange Transport Service. Any changes you make to the edgetransport.exe.config file will take effect after you restart the microsoft exchange transport service.
the <application settings> The section of the edgetransport.exe.config file is where you can add new keys or modify existing keys. if a specific key doesn’t exist, you can add it manually to change its value.
The keys for the queue database that are available in the edgetransport.exe.config file are described in the following table.
By default, this key does not exist in the edgetransport.exe.config file.
- The number of database I/O operations specified by the queuedatabasebatchsize key has not been reached.
- The time specified by the queuedatabasebatchtimeout key has elapsed.
By default, this key does not exist in the edgetransport.exe.config file.
By default, this key does not exist in the edgetransport.exe.config file.
queue properties
A queue has many properties that describe the purpose and state of the queue. some queue properties are applied to the queue when it is created and do not change. other properties contain state, size, time, or other flags that are frequently updated.
next solution key
The Categorizer routing component in the Microsoft Exchange Transport service selects the destination of a message, and this destination is used to create the delivery queue. the destination is marked on each recipient as the nexthopsolutionkey property. each unique value of the nexthopsolutionkey property corresponds to a separate delivery queue.
The nexthopsolutionkey property contains the following fields:
-
delivery type: Represents the results of message categorization, and how the transport service intends to deliver the message to the next hop, which could be the final destination of the message, or an intermediate jump along the way. the transport service uses a predefined list of values for deliverytype.
Based on the value of deliverytype, the nexthopcategory property is added to the queue:
-
the external value indicates that the queue’s next hop is outside the exchange organization.
internal value indicates that the queue’s next hop is within the exchange organization.
Note that a message to an external recipient may require one or more internal hops before the message is delivered externally.
nexthopdomain – Uses specific values based on the value of the deliverytype field. for delivery queues, the value of this field is effectively the name of the queue.
The value of nexthopdomain is not always a domain name. for example, the value could be the target active directory site name or database availability group (dag). think of this field as the name of the next hop.
nexthopconnector – Uses specific values based on the value of the deliverytype field. the value is always expressed as a guid. if this field is not used, the value is an all-zero guid.
The value of nexthopconnector is not always the guid of a connector. for example, the value could be the guid of the target active directory site or dag. think of this field as the next hop guid.
The values of deliverytype, nexthopcategory, nexthopdomain and nexthopconnector are described in the following table.
The queue contains messages for delivery by an Exchange 2010 Hub Transport server to a mailbox on an Exchange 2010 Mailbox server in the local Active Directory site.
fqdn: the syntax is <fqdn1,fqdn2,…>. for example, smarthost01.contoso.com or smarthost01.contoso.com,smarthost02.fabrikam.com.
ip address: the syntax is <[ipaddress1],[ipaddress2],…>. for example, [10.10.10.100] or [10.10.10.100], [10.10.10.101].
fqdn and ip address: the syntax is <[ipaddress1],fqdn1,…> and it depends on how the smart hosts are listed in the Send connector. for example, [172.17.17.7],relay.tailspintoys.com or mail.contoso.com,[192.168.1.50].
- the local exchange 2013 or later mailbox server.
- an exchange 2019 mailbox server on the same exchange 2019 dag.
- an exchange 2019 mailbox server exchange 2016 on the same exchange 2016 dag.
- an exchange 2013 mailbox server on the same day as exchange 2013.
- an exchange 2013 or later mailbox server on the same active directory site in non-dag environments.
The remote transport server could be an exchange 2013 or later mailbox server or an exchange 2010 central transport server.
the remote transport server could be located at the local active directory site or at a remote active directory site.
the remote dag could be located on the local active directory site or on a remote active directory site.
The target exchange 2010 hub transport server could be in the local active directory site or in a remote active directory site.
the message must be routed through a hub site.
The message requires delivery through a Send connector that is configured on an Edge Transport server that is subscribed to a remote Active Directory site.
the expansion server could be located on the local active directory site or on a remote active directory site.
The queue contains messages for delivery by an exchange 2010 central transport server to an exchange 2003 routing group.
The queue contains messages for delivery from an exchange 2010 central transport server to another central transport server in the same active directory site.
input rate, output rate and speed
exchange measures the rate of messages entering and leaving a queue and stores these values in the properties of the queue. you can use these rates as an indicator of the status of the queue and the transport server. the properties are described in the following table:
if the value is greater than 0, messages exit the queue faster than they enter the queue.
if the value is equal to 0, messages leave the queue as fast as they enter the queue. this is also the value you will see when the queue is idle.
if the value is less than 0, messages enter the queue faster than they leave the queue.
the value of speed is displayed in the results of get-queue.
At a basic level, a positive speed value indicates a healthy queue that is draining efficiently, and a negative speed value indicates a poor queue. that is not draining efficiently. however, you must also take into account the values of input rate, output rate and number of messages, as well as the magnitude of the speed. strong>.
For example, consider a queue that has the following property values.
- speed: -50
- number of messages: 1000
- output rate: 10
- input index: 60
Based on the property values of this queue, the negative speed value clearly indicates that the queue is not draining properly.
Now consider a queue that has the following property values.
- speed: -0.85
- number of messages: 2
- rate output: 0.15
- input rate: 1
Although the value of velocity is negative, it is very close to zero and the values of the other properties are also very small. therefore, a negative speed value for this queue does not indicate a problem with the queue.
queue status
The current status of a queue is stored in the queue’s status property. a queue can have one of the status values described in the following table:
notes:
can suspend the following queues:
- delivery queues that have any state.
- the unreachable queue. when you suspend this queue, messages are no longer automatically sent back to the categorizer when configuration updates are detected. to automatically resend these messages, you must manually resume the queue.
- the send queue. when you suspend this queue, the categorizer does not select messages until the queue is resumed.
suspending a queue does not change the state of the messages in the queue.
other queue properties
There are other queue properties that are self explanatory. you can use most of the queue properties as filter options. By specifying filter criteria, you can quickly locate queues and take action on them. for a full description of filterable queue properties, see queue properties.
an important queue property also worth mentioning here is the messagecount property which shows how many messages are in a queue. this property is an important indicator of the state of the queue. for example, a delivery queue that contains a large number of messages that continues to grow and never decreases could indicate a transport pipeline or routing problem that requires your attention.
message properties
a message in a queue has many properties. many of the properties reflect the information that was used to create the message. some of the status and information properties of the messages are strongly influenced by the corresponding properties in the queue. however, an individual message can have a different value than the corresponding property on the queue. other properties contain state, time, or other flags that are frequently updated.
message status
The current status of a message is stored in the status property of the message. a message can have one of the status values described in the following table:
any message in the poison queue is in a permanent suspended state.
other message properties
There are other message properties that are self explanatory. you can use most of the message properties as filter options. By specifying filter criteria, you can quickly locate messages and take action on them. For a full description of filterable message properties, see Properties of messages in queues.
manage queues and messages in queues
The queue viewer and the historical queue and message management cmdlets in the exchange management shell are restricted to a single exchange server. you can view or operate on individual queues or messages, or on multiple queues or messages, but only on a specific server.
The get-queuedigest cmdlet was introduced to exchange in 2013 to provide a high-level, aggregated view of the status of queues across all servers within a specific scope. the scope could be a dag, an active directory site, a list of servers, or the entire active directory forest. note that queues on a subscribed Edge Transport server in the perimeter network are not included in the results. additionally, get-queuedigest is available on Edge Transport servers, but the results are restricted to queues on the Edge Transport server.
The following table describes the management tasks you can perform on queues or messages on queues.
Whether the connection attempt is manual or automatic, any connection attempt is reset the next time it is retried. For more information, see retry intervals, resending, and message expiration.
Note that you can use the queue viewer to resend messages, but only from the poison queue. To resend a poison message, you must first resume the message in the queue viewer or by using the resume-message cmdlet.
-