We recently resolved a case where a customer tries accessing Exchange Server 2010 mailboxes (DAG) via their custom Exchange MAPICDO based application. On average 2-3 days once, they're frequently facing an error “The information store could not be opened. [MAPI 1.0 - [MAPI_E_LOGON_FAILED(80040111)]]” while attempting to connect to Exchange server 2010. After some days of normal working, Exchange server starts to refusing their connector to open the users' mailboxes. Whenever they notice this error, the application just fails and they need to restart the app to make it work.
During debugging, we haven’t noticed any issues logged Exchange Server’s event viewer and MPS also looked fine. We took memory dump and analyzed RCA logs, which pointed client throttling policy.
Earlier, Steve had blogged an excellent article on this. So first we need to understand more about Exchange Client throttling, a feature which got introduced in Exchange Server 2007. Exchange server 2007/2010 allows many clients to connect via Outlook, MAPI, ActiveSync, Outlook Anywhere, OWA ,IMAP or POP3, to their Mailboxes through the (CAS) Client Access Server role. Throttling policies are used to restrict clients in the Exchange Server resources they can use. The purpose of these restrictions is to make sure a client can’t bring down an Exchange Server or disrupt services for other clients, intentionally or unintentionally, by exhausting resources. Thus, throttling will also help in lowering the impact of denial-of-service attacks. Because the limit is enforced on clients, and clients can connect to their mailbox simultaneously using different components, throttling policies are applied to mailboxes.
Note: By default the mailbox attribute ThrottlingPolicy is not set, meaning the default throttling policy will be used (refer the below pic):
Once the ThrottlingPolicy is set, it will be shown like the below:
You have to use the exchange shell to manage throttling policies with the New-ThrottlingPolicy, Get-ThrottlingPolicy, Set-ThrottlingPolicy & Remove-ThrottlingPolicy cmdlets. We pointed them to fix it by creating/modifying client throttling policy – it helped them to move ahead.