Exchange 2010 - Production : Public Folder replication messages stuck in the queue
Context :
You noticed more than 300 system messages stuck in some HUB transport servers queues with error code : 432 4.3.2 STOREDRV.Deliver ;Recipient thread limit exceeded
This is a known issue from Exchange 2010 SP1, which implements a default limitation on delivery threads, to avoid mail storms or Public Folder replication storms that could take Hub servers down (note that Public Folders are used by Outlook 2003 clients for system messages).
The solution is to slightly increase this default limitation to stay away from this issue with Public Folders replication. Below is the procedure to do this (EdgeTransport.exe.config is located on your ExchangeV14Bin folder on your servers)
Hub transport queue building up due to public folder replication messages.
Symptoms
Hub transport queue building up due to public folder replication messages.
Last Error: 432 4.3.2 STOREDRV.Deliver; recipient thread limit exceeded
Cause
Exchange 2010 SP1 implements delivery thread limits so a hand full of recipients does not cause a disruption on the hub server. Example given, Journal mailbox or public folders.
Resolution
To resolve the issue we added the following settings to edgetransport.exe.config.
<add key="RecipientThreadLimit" value="2" />
<add key="MaxMailboxDeliveryPerMdbConnections" value="3" />
The above information is explained in details in the following article as well:
And confirming the action plan above, here is the relevant part of the article:
- There are two scenarios after applying SP1 where we are seeing customers with messages backing up in the queue. The temporary error message is:
432 4.3.2 STOREDRV.Deliver; recipient thread limit exceeded
The two scenarios are:
- Journaling
- Public Folders replication
In both cases, the deliveries are occurring to a single recipient (or very small number of recipients). But it can be enough to paralyze or slow down the HUB servers.
Like every other throttling & performance related feature that has ever been in Exchange, the solution isn’t exactly straight forward. The solution is to incrementing both values up one, as follows:
<add key="RecipientThreadLimit" value="2" />
<add key="MaxMailboxDeliveryPerMdbConnections" value="3" />
=> In general, Microsoft recommends to stay below 3 for RecipientThreadLimit and below 4 for MaxMAilboxDeliveryPerMdbConnections to avoid performance issues, but you may go upper depending on your hardware performance.