Monitoring Benefit
The Queue Status check reports the state and depth of the message queues on the monitored Exchange server.
Queues are the earliest visible symptom of most mail flow problems. Messages accumulate before anyone notices mail is slow, so a rising queue is usually the first warning you get — and a queue that is growing steadily tells you something different from one that spiked and drained.
How do we verify the monitoring test results?
1. List the queues. From the Exchange Management Shell on the affected server:
Get-Queue2. Read which queue is affected, not just the total. The queue identity is the diagnosis. A single remote-delivery queue backing up points at one destination domain or one connector. The Submission queue backing up points at categorisation or at the server itself. Unreachable and Poison queues mean something quite different again.
3. Check whether it is draining. Run Get-Queue a few times a minute apart. A queue that is falling is working through a backlog; one that is flat or rising is blocked. This distinction matters more than the absolute number.
4. Compare against your threshold. This check is threshold-driven, and the threshold is configured in the Admin Console. Confirm what it is set to before treating a warning as unexpected — a busy server can sit legitimately above a threshold that was set for a quiet one.
Common warning or error results, and potential solutions
| Result | Potential solution |
| One remote delivery queue growing | A problem reaching that specific destination. Check the queue's last error, then DNS resolution and connectivity to that domain's mail servers. |
| Submission queue growing | Categorisation or the transport service on this server. Check the Transport services and the server's resource state — back pressure will hold messages in submission. |
| Messages in the Poison queue | Messages the transport service considers harmful to itself. These do not clear on their own and need review before you release or remove them. |
| Unreachable queue growing | Transport has no route for these messages. Check send connectors and their address spaces. |
| Queue spikes that drain on their own | Usually normal — a large distribution send, a backup window, or a brief connectivity blip. Consider whether the threshold is tuned for your actual traffic rather than treating each spike as an incident. |
| Results are stale rather than failing | If several unrelated checks stopped updating at the same moment, look at the ENow SQL database connection rather than at the queues. |
Monitoring page. The detail behind this indicator is served by the ENow web server at:
http://localhost:20080/MailscapeWeb/Queue.aspx?server=<SERVER>Replace localhost with the web server's host name if you are browsing from elsewhere, 20080 with your own port if it was changed at installation, and <SERVER> with the monitored server you are investigating.
Reference. Get-Queue, Email stuck in queues and Emails placed in the poison queue.
Comments
0 comments
Article is closed for comments.