Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

XCON: Err Msg: The Recipient could not be Processed due to Congestion in the Message Transfer Service


View products that this article applies to.

This article was previously published under Q170478

↑ Back to the top


Symptoms

If a Microsoft Exchange Server is removed from a Microsoft Exchange Site and Organization and then re-installed using a different Organization and Site name, messages sent to that Server may appear to loop or stick in the Microsoft Exchange Server Message Transfer Agent (MTA) for a long period of time. Eventually, they are returned to their originators with a Non-Delivery Report (NDR) that includes the following text:
   The recipient could not be processed due to congestion in the message
   transfer service.
				

↑ Back to the top


Resolution

There are two scenarios that can cause this type of behavior:

1.Once a Microsoft Exchange Server is removed from the Site and Organization that it was replicating with, the other Servers in the Site will not instantly know that the Server was removed. Users will be able to send messages to recipients on the old Server and the messages will be routed to the proper queue. They will wait there until their internal 512 hop count is exceeded and then NDR with the above error message. To prevent this, once a Server is removed from the Organization or Site, force a replication session among all of the remaining Servers so that users from the old Server will no longer appear in the Global Address List (GAL).
2.Another scenario is when a Server is removed from a Site, the sitename is changed, and then the Server is re-added to the Organization. Messages that are pending to go to the old Site will see that the Site is back, based on the MTA name. The MTA has no method of detecting that the messages are invalid since the old MTA name still exists as a valid route. Again, the messages will loop until their 512 hop limit is exceeded and they NDR. This problem is also easily avoidable. Once the Server is removed from the Site, delete any messages pending for users on the old Server. This can be done by going to each Server in the Site and looking at its pending queue to the old Server. When the messages are deleted from the queue, they will NDR back to the originators. This behavior is by product design.

↑ Back to the top


Keywords: KB170478, kbprb, kbinfo

↑ Back to the top

Article Info
Article ID : 170478
Revision : 6
Created on : 10/28/2006
Published on : 10/28/2006
Exists online : False
Views : 347