The Delivery Reports feature which was introduced in Exchange 2010 enables both Information Workers, and administrators to view delivery status of messages and discover answers to questions such as: why a message was not delivered, where a message is now, who received a message, why a message was delivered to a particular folder, etc. While an earlier post introduced the Delivery Reports feature and provided an overview of its functionality, this post will dive a bit further into their architecture and how administrators can use them.
From an admin perspective the Delivery Reports feature was designed to assist in quickly and easily answering questions users may have around why a message they were supposed to receive (or a message they sent) was not delivered. Unlike previous versions of Exchange which forced administrators to manually examine the Message Tracking logs on multiple servers when troubleshooting missing (or delayed) messages, Message tracking logs in Exchange 2010 are automatically index and by using the Delivery Reports feature admins can quickly view a report which displays the Message Tracking events from all servers a message passed through. There are a number of ways Admins can access the Delivery Reports feature, namely: EMC (from the Toolbox), ECP (from Options -> Reporting), or via PowerShell Tasks.
Using ECP to track a message as an Administrator
Delivery Reports in ECP
If a user complains that a message they sent was not delivered the following steps can be used to track the message:
1. Under "Mailbox to search", select the user's mailbox of the user who reported the issue.
2. Select "Search for messages sent to:", and select the users who were supposed to receive the message. (Hint: If the message was sent to someone an internet recipient you can SMTP addresses under "Message Recipients" )
3. To reduce the number of results, you can also optionally specify keywords for the subject by entering in "Search for these words in the subject line"
4. Click "Search"
5. A list of messages will appear in the Search Results pane. To view the Delivery Report details for a specific message simply double-click on it.
If a user complains that they did not receive a message they were supposed to the following steps can be used to track the message:
1. Under "Mailbox to search", select the user's mailbox of the user who reported the issue.
2. Select "Search for messages received from:", and select the user who sent the message. (Hint: If the message came from an internet sender you can enter their SMTP addresses under "Message Recipients" )
3. To reduce the number of results, you can also optionally specify keywords for the subject by entering in "Search for these words in the subject line"
4. Click "Search"
5. A list of messages will appear in the Search Results pane. To view the Delivery Report details for a specific message simply double-click on it.
Delivery Reports Architecture
The following diagram provides a high-level overview of the architecture for the Delivery Reports feature (a.k.a. tracking). Please click for full size version:
In the above example a user uses ECP to track a message which was sent from a user on Mailbox Server 1 to a recipient on Mailbox Server 2.
1. ECP Calls the Search-MessageTrackingReport task and specifies the parameters of the search.
2. The Search-MessageTrackingReport task finds the senders Mailbox Server.
3. The Log Search Service running on Mailbox Server 1 is queried with the search parameters to determine where the message was sent to next.
Note: The Log Search Service, which provides Delivery Reports with a query-able interface to data in the Message Tracking logs, generally loads about two weeks' worth of data (though this number may vary depending on server configuration, mailflow, etc ).
4. As the message went from Mailbox Server 1 to Hub Server 1, tracking follows the path and queries the Log Search Service on Hub Server 1 to determine what happened to the message next
5. Tracking then discovers that the message went across a boundary (Premise/ Forest/ Site).
6. Tracking makes an EWS request to CAS Server 2 in the remote premise/forest/site.
7. CAS Server 2 Queries the Log Search Service on Hub Server 2
8. The message is followed to Mailbox Server 2
9. Delivery Status information is retrieved and returned to CAS 2
10. CAS 2 returns the delivery status information to CAS 1
11. The task merges all of the results and returns them to the user through ECP.
Tip: Configure the Message Tracking files sizes for each server in such a way that the log data will be persisted for about the same length of time on each server, as tracking depends on the log information being available at each hop.
You Had Me at EHLO.