Issues:
email is backing up in the Exchange Submission Queue and the following errors are displayed in Queue Viewer:
432 4.3.2 storedriver component has been retired
432 4.3.2 STOREDRV.Deliver; mailbox database thread limit exceeded
Processor is also pegged at 100% or close to it on the hub transport server
Potential causes of this issue for others but were not the cause in my cause:
-exceeded mailbox size quotas on the database, especially a journal mailbox / database
-under-powered Hub Transport servers
One cause confirmed:
The EMC SAN housing the active database copies had a failed power supply battery and an disabled write-cache, impacting disk I/O performance.
Resolutions Attempted:
— considered reducing max message size from 30MB to 20MB
— Added the following key into EdgeTransport.exe.config file and restarted the transport service on CAS1/CAS2 (may only want to do this temporarily if the HUB transport is not on a separate server):
<add key=”MailboxDeliveryThrottlingEnabled” value=”False” />
location of EdgeTransport.exe.config: C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config
— In a highly utilized environment like my customers Hosted Exchange environment, it may be worth considering having dedicated hub transport servers and dedicated journaling servers if journaling is in use. The following limits can be increased without impacting CAS or DB performance:
<add key=”RecipientThreadLimit” value=”2″ />
<add key=”MaxMailboxDeliveryPerMdbConnections” value=”3″ />
For more information see: https://blogs.technet.com/b/exchange/archive/2011/04/11/store-driver-fault-isolation-improvements-in-exchange-2010-sp1.aspx)
— Increased Processors and RAM in Hub Transport Servers
— Activated database copies on Mailbox server that had fastest disk I/O. Remember, the EMC SAN housing the active database copies had a disabled write-cache, negatively impacting disk I/O performance.
Conclusion: I found that increasing processors and RAM and activating the databases on the Mailbox Server with the fastest disk I/O made the most positive impact on the problem and the queues gradually emptied.