If you like then share Please So others can also get benefit/knowledge !!!!!
Queues in Exchange 2013
If you look at the set of queues for an Exchange 2013 server (which you can see with a
quick run of the Get-Queue cmdlet), you’ll see that the queues break down into a few welldefined groupings. Each mailbox database has its own destination queue, as does each
DAG and Active Directory site. Somewhat surprisingly, Active Directory forests have their
own queues, as do external SMTP domains; these two groups could be combined because
delivery to a remote forest uses SMTP, but Microsoft evidently sees some advantage in
keeping them separate.
When the Transport service processes messages in a queue, it attempts to deliver the first
message in the queue; if the message delivery succeeds, it updates the transport high availability (HA) system to indicate that delivery
was successful. If not, the message remains queued and is retried at a later time. After a
preset number of retry attempts, or after the retry interval expires, the message is considered undeliverable and returned to the sender with a nondelivery report (NDR).
As mentioned earlier here, there are some important differences between queues
in Exchange 2013 and those in previous versions. The basic behavior of queues remains the
same: messages enter a queue and remain there until they are retrieved and processed by
some other component.
Queue types
Different queues are used for different purposes, so it should come as no surprise that
Exchange supports multiple types of queues, each with its own purpose.
The submission queue holds and organizes messages that are awaiting processing by the
categorizer. All arriving messages on a server are delivered to this queue, and the categorizer processes each of them, redirecting them to other queues as appropriate.
Delivery queues are the most familiar type; they contain messages that are being sent using
SMTP. The destination can be remote or local. There will be one delivery queue for each
destination. For example, if you have messages concurrently flowing to 17 remote SMTP
domains through the Internet, you’ll have at least 17 delivery queues.
Messages that can’t be delivered might end up in two additional, delivery-related queues.
The Unreachable queue contains messages for destinations that cannot be routed to. For
example, if Amy addresses a message to an SMTP domain that has no MX record, that message will eventually end up in the Unreachable queue. Messages with invalid recipients can
end up here, too. Exchange periodically retries messages from this queue, so each message
eventually is either returned with an NDR or delivered. Interestingly, this queue is hidden
in both EMS and EAC unless messages are in it. Likewise, the poison message queue is normally invisible and empty. It receives and holds any message that makes a Transport service
crash; the idea is that such messages can be stuffed into this queue and kept out of the way
before they cause further harm. Poison messages are not automatically resubmitted, and
the poison queue is never automatically cleared.
There are also two sets of queues used for redundancy in the transport system: shadow
redundancy queues and the hidden Safety Net queue.
that We will discuss later.
Queue databases
As in Exchange 2010, all queued messages are stored in an Extensible Storage Engine (ESE)
database, which by default is located at %ExchangeInstallPath%\TransportRoles\data
\Queue. The use of ESE for queuing means that you manage the queue as a database
rather than as a collection of files. The queue database itself (Mail.que) has associated ESE
transaction log files (Trn*.log), a checkpoint file (Trn.chk), and reserved log files (Tnres00001.
jrs and Tnres00002.jrs), just as any other ESE database would have.
One important difference in Exchange 2013 queuing behavior has to do with how messages are stored in the queue database. Exchange 2007 and Exchange 2010 added and
removed individual messages. High message volumes therefore meant high volumes of
table adds and drops in the database. Exchange 2013 aggregates all messages that arrive
each hour into a single table. For example, messages arriving between 9 A.M. and 10 A.M.
local time go into a single table; at 10 A.M., the server opens a new table and puts messages in it, deleting the 9 A.M. table after it has verified that all messages therein have been
delivered.
The location of the mail queue database files is set in the EdgeTransport.exe.config configuration file, and you can move it to a more suitable location if required. Here’s an excerpt
from that file showing the default settings:
Credit Goes to Tony Redmond ..http://windowsitpro.com/blog/tony-redmonds-exchange-unwashed-blog.....Microsoft Exchange Server 2013 Inside Out.
Queues in Exchange 2013
If you look at the set of queues for an Exchange 2013 server (which you can see with a
quick run of the Get-Queue cmdlet), you’ll see that the queues break down into a few welldefined groupings. Each mailbox database has its own destination queue, as does each
DAG and Active Directory site. Somewhat surprisingly, Active Directory forests have their
own queues, as do external SMTP domains; these two groups could be combined because
delivery to a remote forest uses SMTP, but Microsoft evidently sees some advantage in
keeping them separate.
When the Transport service processes messages in a queue, it attempts to deliver the first
message in the queue; if the message delivery succeeds, it updates the transport high availability (HA) system to indicate that delivery
was successful. If not, the message remains queued and is retried at a later time. After a
preset number of retry attempts, or after the retry interval expires, the message is considered undeliverable and returned to the sender with a nondelivery report (NDR).
As mentioned earlier here, there are some important differences between queues
in Exchange 2013 and those in previous versions. The basic behavior of queues remains the
same: messages enter a queue and remain there until they are retrieved and processed by
some other component.
Queue types
Different queues are used for different purposes, so it should come as no surprise that
Exchange supports multiple types of queues, each with its own purpose.
The submission queue holds and organizes messages that are awaiting processing by the
categorizer. All arriving messages on a server are delivered to this queue, and the categorizer processes each of them, redirecting them to other queues as appropriate.
Delivery queues are the most familiar type; they contain messages that are being sent using
SMTP. The destination can be remote or local. There will be one delivery queue for each
destination. For example, if you have messages concurrently flowing to 17 remote SMTP
domains through the Internet, you’ll have at least 17 delivery queues.
Messages that can’t be delivered might end up in two additional, delivery-related queues.
The Unreachable queue contains messages for destinations that cannot be routed to. For
example, if Amy addresses a message to an SMTP domain that has no MX record, that message will eventually end up in the Unreachable queue. Messages with invalid recipients can
end up here, too. Exchange periodically retries messages from this queue, so each message
eventually is either returned with an NDR or delivered. Interestingly, this queue is hidden
in both EMS and EAC unless messages are in it. Likewise, the poison message queue is normally invisible and empty. It receives and holds any message that makes a Transport service
crash; the idea is that such messages can be stuffed into this queue and kept out of the way
before they cause further harm. Poison messages are not automatically resubmitted, and
the poison queue is never automatically cleared.
There are also two sets of queues used for redundancy in the transport system: shadow
redundancy queues and the hidden Safety Net queue.
that We will discuss later.
Queue databases
As in Exchange 2010, all queued messages are stored in an Extensible Storage Engine (ESE)
database, which by default is located at %ExchangeInstallPath%\TransportRoles\data
\Queue. The use of ESE for queuing means that you manage the queue as a database
rather than as a collection of files. The queue database itself (Mail.que) has associated ESE
transaction log files (Trn*.log), a checkpoint file (Trn.chk), and reserved log files (Tnres00001.
jrs and Tnres00002.jrs), just as any other ESE database would have.
One important difference in Exchange 2013 queuing behavior has to do with how messages are stored in the queue database. Exchange 2007 and Exchange 2010 added and
removed individual messages. High message volumes therefore meant high volumes of
table adds and drops in the database. Exchange 2013 aggregates all messages that arrive
each hour into a single table. For example, messages arriving between 9 A.M. and 10 A.M.
local time go into a single table; at 10 A.M., the server opens a new table and puts messages in it, deleting the 9 A.M. table after it has verified that all messages therein have been
delivered.
The location of the mail queue database files is set in the EdgeTransport.exe.config configuration file, and you can move it to a more suitable location if required. Here’s an excerpt
from that file showing the default settings:
Credit Goes to Tony Redmond ..http://windowsitpro.com/blog/tony-redmonds-exchange-unwashed-blog.....Microsoft Exchange Server 2013 Inside Out.
No comments:
Post a Comment