Common Non-Delivery Report Scenarios

This topic covers the following common scenarios that can cause NDRs to be generated:

• Issues with Active Directory.

• Delayed message delivery because of global catalog server issues.

• Sending messages to recipients in personal address books or contact lists.

• Sending messages to a public folder.

Issues with Active Directory

Non-delivery reports can occur because of issues with Active Directory. The following categories of NDRs are related to Active Directory issues:

• Recipients were moved to Active Directory by using Active Directory Connector (ADC).

• Recipients were moved to Active Directory by using the Move Mailbox tool.

• Attributes are missing.

Recipients Were Moved to Active Directory by Using Active Directory Connector

If some of your users are experiencing NDRs and you have moved recipients using the Active Directory Connector, determine the following:

• What type of recipient is generating the NDR (for example, a mailbox, a distribution group, or a contact).

• How the recipient was moved to Active Directory. If the recipient was replicated to Active Directory by the ADC, use the ADCDump tool to obtain an ADC dump file, and then compare the attributes that exist in both directories for the recipient that is experiencing the issue. The ADC dump file shows the missing attributes between the Exchange 2003 object and the Exchange Server 5.5 object. To obtain the ADCDump tool, contact Microsoft Product Support Services.

If the users were moved by using the ADC, the users must exist in Active Directory, at least as disabled users. Replicating users to Active Directory as contacts (custom recipients) from the Exchange  5.5 directory results in NDRs. If the Exchange  5.5 and Microsoft Windows NT® Server version 4.0 recipients were replicated to Active Directory as contacts, Exchange 2003 no longer sends e-mail messages to Windows NT Server 4.0 recipients that are represented as contacts in Active Directory. In this scenario, the following NDR is returned:

A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator. <servername.contoso.com #5.4.6>

For additional information, see Microsoft Knowledge Base article 272593, "XCON: Message Generates NDR When Sent to a Windows NT Server 4.0 Recipient Represented as Contact in Active Directory." Although this article was written for Exchange 2000, the same principles apply to Exchange 2003.

This behavior does not occur with contacts that are created in Exchange 2003; this behavior occurs only with Windows NT Server 4.0 users that are replicated to Active Directory as contacts through the ADC. Messages can be sent to native Exchange 2003 contacts without issues.

Recipients Were Moved to Active Directory by Using the Move Mailbox Tool

Make sure that all mail-enabled attributes exist if a recipient, distribution group, or user exists as a native Exchange 2003 object or was moved from Exchange 5.5 by using the Move Mailbox tool. The following steps are useful:

• Determine the Exchange server that the sender physically resides on. If the recipient is a distribution group, find the distribution group expansion server.

• Determine which global catalog server that the sender's Exchange server or the distribution group expansion server contacts for name resolution. (See the procedure later in this section for detailed steps.)

• Run the Nltest tool, available on Windows 2000 and Windows Server 2003, to determine which global catalog server is being contacted by the sender's server or the distribution group expansion server. Make sure that you run Nltest from the sender's Exchange server or from the distribution group expansion server. If the distribution group expansion is set to any server in the organization, run Nltest from the sending server.

For detailed instructions, see How to Determine the Expansion Server for a Distribution Group.

After you know which global catalog is being used, obtain a dump file of the recipient user distribution group. For additional information about how to obtain a dump file, see the following Microsoft Knowledge Base articles:

• 255253,"XADM: How to Perform a Dump of a Container or Object in Exchange 2000"

• 271201,"XADM: Alternative Methods to Obtain a Dump of an Object"

You can also use the LDP tool to obtain the LDP dump file of the recipient object. If you use the LDP tool, make sure that port 3268 is used when connecting to the global catalog server. This is the port that Message Categorizer uses to query global catalog servers for name resolution.

Missing Attributes

Attributes may be missing from an object for a variety of reasons that range from attributes that were manually deleted to global catalog synchronization issues. However, if any attributes are missing, it is most commonly because Recipient Update Service did not write these attributes correctly or because of ADC replication issues.

For detailed information, see How to Correct Missing Attribute Issues.

Delayed Message Delivery Due to Global Catalog Server Issues

Problems with a global catalog can cause delays in message delivery. In this case, NDRs are generated to notify the sender of the delay. You can use Message Tracking Center to diagnose these problems. The following example shows data gathered from Message Tracking Center:

6/22/2001 3:54 PM Tracked message history on server CONTOSO-MSG-01

6/22/2001 3:54 PM SMTP Store Driver: Message Submitted from Store

6/22/2001 3:54 PM SMTP: Message Submitted to Advanced Queuing

6/22/2001 3:54 PM SMTP: Started Message Submission to Advanced Queue

6/22/2001 3:54 PM SMTP: Message Submitted to Categorizer

6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message

6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP

6/22/2001 4:24 PM SMTP: Message Submitted to Advanced Queuing

6/22/2001 4:24 PM SMTP: Started Message Submission to Advanced Queue

6/22/2001 4:24 PM SMTP: Message Submitted to Categorizer

6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message

6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP

6/22/2001 4:24 PM SMTP Store Driver: Message Delivered Locally to Store

In this example, notice that the message was delayed in message categorizer for 30 minutes before outbound transfer started and the message was eventually delivered. In these situations, determine which global catalog server Exchange is using by running the Nltest tool as described in "Recipients Were Moved to Active Directory by Using the Move Mailbox Tool" earlier in this topic. Then, investigate the global catalog servers that are involved. The following are common causes of global catalog issues:

• Overloaded or overworked global catalog servers.

• Performance issues with global catalog servers.

• Low memory.

• Low hard disk space.

• Intermittent network issues between Exchange 2000 and global catalog servers.

• Too many Exchange servers using the same global catalog server (the recommended ratio of Exchange processors to global catalog server processors is four to one).

Use a System Monitor log from a global catalog server while you reproduce the issue. It can help you diagnose these issues. Recycling the global catalog servers may resolve these issues. To troubleshoot these issues, you can specify a global catalog server for each Exchange server.

For detailed information, see How to Specify a Global Catalog Server.

For additional information about DSAccess, see Microsoft Knowledge Base article 250570, "XCON: Directory Service Server Detection and DSAccess Usage."

Non-Delivery Reports When Sending to Personal Address Book and Contact List

If a user is moved from an Exchange Server 5.5 computer by using the Exchange 2003 Move Mailbox tool, and the moved mailbox has a personal address book or contact list in the Exchange 5.5 mailbox, the personal address book and contact list becomes invalid on an Exchange 2003 mailbox. Any addresses that are resolved against the personal address book or contact list generate an NDR that is similar to:

Your message did not reach some or all of the intended recipients.

Subject: Test

Sent: 8/3/2000 5:24 PM

The following recipient(s) could not be reached:

CN=\ Network,OU=United States,OU=Distribution Lists,DC=Contoso,DC=com on 8/3/2000 5:24 PM

The e-mail address could not be found. Perhaps the recipient moved to a different e-mail organization, or there was a mistake in the address. Check the address and try again.

<CONTOSO-MSG-01.Contoso.com #5.1.0>

Because the Move Mailbox tool does not move personal address books and contact lists, all addressing information in personal address books and contact lists becomes invalid.

To resolve this issue, on your Outlook client, ensure that the global address list is selected as the source for the address book. Ideally, your users that have been moved from an Exchange 5.5 server should delete personal address books and contact lists, and then re-create them.

Sending Messages to a Public Folder

Sending an e-mail message to a public folder in Exchange is more complicated than sending an e-mail message to a mailbox. A mailbox can only exist on one server and therefore belongs to a particular mailbox store. Active Directory attributes for a mailbox point to a specific server. Therefore, after the entry is resolved, Exchange can use routing to determine which mailbox store to deliver the message to.

A public folder in Active Directory has no home server. A public folder can exist on multiple servers, and no information is held in Active Directory to indicate which servers hold replicas of the folder. The Exchange store handles this information.

When Exchange delivers a message to a public folder, the first task it performs is to deliver the message to an Exchange store that points to the location of the public folder replicas. The Exchange store looks up the ptagReplicaList entry, which lists the Exchange servers with replicas of the folder, and then resubmits the message readdressed to an Exchange store that holds a replica of the folder.

The categorizer is responsible for correctly resolving the address of a message. In the case of public folders, it is also responsible for:

• Determining which top-level hierarchy the folder belongs to.

• Addressing the message correctly to be submitted to a store in that top-level hierarchy.

• Rewriting the address of the message to a store that holds a replica of that public folder, after the replica list is obtained.

When an e-mail message is sent to a public folder, the categorizer performs the following steps to deliver the message:

1. Initial public folder lookup

2. Top-level hierarchy server lookup

Initial Public Folder Lookup

When an e-mail message is submitted, Exchange resolves the address to an entry in Active Directory. If that entry is a public folder rather than a mailbox, the categorizer attempts to obtain the homeMDB attribute of the public folder:

homeMDB: CN=Public Folders,CN=Folder Hierarchies,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=MicrosoftExchange,CN=Services,CN=Configuration,DC=contoso-msg-01,DC=contoso,DC=com;

A folder's homeMDB attribute contains the distinguished name of the top-level hierarchy to which the folder belongs.

Top-level Hierarchy Server Lookup

Next, the categorizer looks up the top-level hierarchy that is retrieved from the folder's homeMDB attribute to obtain a list of all the servers in that folder's top-level hierarchy. The categorizer is unable to determine the location of the replica, but it can submit the message to an Exchange store that does have the location information. The top-level hierarchy distinguished name contains a link to all the servers in that top-level hierarchy.

To determine which public folder store or server the categorizer picks from the top-level hierarchy, Exchange uses the following criteria:

• Does one of the public folder stores exist on the local server? If so, Exchange uses that store.

• Does one of the public folder stores exist on an Exchange server in the local routing group? If so, Exchange uses that store.

• Does one of the public folder stores exist on any Exchange server? If so, Exchange uses that store. Otherwise, Exchange uses the first store in the list.

The first server on the list is contained in the msExchOwningPFTreeBL attribute. This attribute is located on the public folder tree under folder hierarchies. The categorizer then chooses a server from the msExchOwningPFTreeBL attribute to which it sends the message.

The following example shows the contents of the msExchOwningPFTreeBL attribute, as obtained from LDP output:

msExchOwningPFTreeBL: CN=Public Information Store (PFREP55),CN=First Storage Group,CN=InformationStore,CN=PFREP55,CN=Servers,CN=FourthCoffee,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=cumbria,DC=extest,DC=microsoft, DC=com;

CN=Public Folder Store (PFREP57),CN=First Storage Group,CN=InformationStore, CN=PFREP57,CN=Servers,CN=Coniston,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;

CN=Public Information Store (PFREP56),CN=First Storage Group,CN=InformationStore,CN=PFREP56,CN=Servers,CN=Coniston,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;