Don't just guess about your email delivery problems, get a clue
When you suspect that your email system is having message delivery difficulties, you often need to play detective and search for clues to determine the problem. But where do you begin your search for message transport clues, and what tools and techniques are available to help?
The first notification about an email delivery problem often comes from a user who has received a nondelivery report (NDR). If available, an NDR is often the best place to begin your search for clues because it contains information that can help you determine which component or system to investigate.
Consider an Exchange Server 5.5 design that has two sites with two servers at each site. Site 1 has Exchange servers named EX3 and EX4, and Site 2 has Exchange servers named EX5 and EX6. A Site connector connects the two sites, with EX4 and EX5 acting as bridgehead servers; EX4 hosts the Internet Mail Service (IMS). The Site 2 administrator has recently deleted a mailbox for Mosby Jones from EX5. Figure 1, page 2, shows two NDRs that result when someone tries to send a message to Mosby Jones. The first NDR resulted when an external user tried to send an SMTP email message to Mosby Jones, and the second NDR occurred when a user with a mailbox on EX4 tried to send a message to Mosby Jones. The text of both NDRs is similar, but if you look closely, you'll see that not only do the two NDRs have different MTS-IDs (aka Message IDs) but the last lines of these two messages are different and contain clues that will help you answer message delivery—related questions.
Exchange 5.5 Clues
As Figure 2, page 2, shows, each Exchange 5.5 NDR contains information that you can use to determine whether a delivery problem exists: By examining the Message ID string, you can see that the message came from a user on EX4. The Component, Site, and Server elements show that the Message Transfer Agent (MTA) on EX4 successfully sent the original message to the EX5 server at Site 2. However, the MTA on EX5 couldn't complete the delivery, so EX5 is where you need to start looking for more clues about what happened.
The next step is to open a Microsoft Exchange Administrator session on EX5 and look at the Recipients containers to confirm that the Mosby Jones account doesn't exist. You can easily understand how someone could send an SMTP message to Mosby Jones and get an NDR because the mailbox doesn't exist, but how does a user on an Exchange server that shares a common view of the Global Address List (GAL) enter Mosby Jones into the message's To field when the mailbox isn't listed in the GAL? The most common cause for this phenomenon occurs when a user replies to a message for which the deleted account was the sender or an addressee. You might also see this happen immediately after an administrator deletes a mailbox but replication hasn't yet synchronized this change to another server. To determine whether either of these scenarios has occurred, you need to open the original message from the sender's Sent Items folder and examine the message properties.
First, examine the message's addressee information. Right-click the addressee and select Properties. You can determine immediately whether the sender used an address from an old message: If the message recipient is listed in the GAL, Exchange doesn't store complete information about the recipient in each message; instead, Exchange stores a pointer to that information in the Exchange Directory, along with the display name. When you access the properties of a recipient who's no longer listed in the Directory, you'll see the recipient's distinguished directory name (e.g., /o=<Organization>/ou=<Site>/cn=<Recipients>/cn=<DirectoryName>) instead of the expected display name, as Figure 3 shows.
Another way to determine whether the sender replied to an old message is to use the Exchange Message Tracking Center, which is available in all versions of Exchange. (For information about using the Exchange 5.5 Message Tracking Center, see Tony Redmond, "How Message Tracking Works," June 1998, InstantDoc ID 4927.) The Exchange 2000 Server interface is slightly different from previous versions and includes some additional capabilities, such as the ability to save results, but the general functionality is the same.
The Message Tracking Center can locate a message to track by searching for a specified sender or recipient, or the service can begin tracking immediately if you supply a Message ID. (You can copy the Message ID from the delivery report—see Figure 2—and paste it into the Message Tracking Center.) After you generate a tracking history of a specific message, you can examine the message submission event to see a list of recipients.
To generate a tracking history in Exchange 5.5, start the Exchange Administrator program and select Track Message from the Tools menu. Enter the name of the server on which you want to start tracking. (The best server to use is the one on which the sender's mailbox resides.) After you enter the server name, you'll see a Select Message to Track dialog box that lets you enter sender or recipient information so that you can locate the message you want to track. In the Mosby Jones example at the beginning of this article, you already have the Message ID, so you can close this dialog box because the Message ID uniquely identifies which message to track. Open the Message Tracking Center, click the Advanced Search button, and select By Message ID, as Figure 4 shows. Click OK to reopen the Select Message to Track dialog box, and enter the Message ID that you copied from the NDR. Click OK to close the dialog box. In the Message Tracking Center, click the Track button. The Message Tracking Center will search the tracking logs on the server for entries that contain the Message ID. As the tracking center finds message transfer events, it will open logs on other servers and build a start-to-finish tracking history that details the events and message transfers made during delivery.
Prev. page
[1]
2
next page 
