This came up in a case and the cause wasn’t immediately obvious. The customer used MAPI to open a number of mailboxes using OpenMsgStore. They found that if they tried to multithread their code, they’d open a few mailboxes, then they’d start getting MAPI_E_FAILONEPROVIDER. The odd thing was the same code running against Exchange 2007 did not experience this problem.
It turns out what they were running in to was Exchange 2010’s new client throttling feature. The purpose of this feature is to prevent a single client from causing a Denial of Service on the Exchange server by throwing commands at it and dominating it’s time. You may find that for certain applications, the default throttling policy isn’t appropriate. You can build a new policy using New-ThrottlingPolicy. For MAPI applications (whether they use Outlook or Exchange’s MAPI), the settings starting with RCA (RPC Client Access) are the ones you want to set, particularly RCAMaxConcurrency. Once you’ve created a policy, you can apply it to a user using Set-Mailbox.
An important note: In the policy, you’ll see a CPUStartPercent setting. This setting only applies to EWS, as confirmed by David Sterling in his comment to this post.
May be I have a similar problem:
Environment:
MS-Windows: Microsoft Windows Server 2008 Enterprise Edition 64-bit Service Pack 2 (build 6002) (6.0.6002)
MS-ExchangeServer: Microsoft Exchange Server 2010 (14.0.682.1)
MAPICDO: Messaging API and Collaboration Data Objects 1.2.1 v6.5.8131.0
Reproduced with code:
IMsgStore store1;
HRESULT r = IMAPISession->OpenMsgStore(..., &store1);
ATLASSERT(r == 0);
IMsgStore store2;
r = IMAPISession->OpenMsgStore(..., &store2);
ATLASSERT(r == 0x8004011D);
Works ok with:
store1->Release();
Why IMsgStore must be released before IMAPISession->OpenMsgStore call via MAPI on Exchange 2010?
On my side I have been met with a case that cannot support IMsgStore->Release workaround.
It works without any problem under Exchange 2003 & 2007.
Steve,
Can you provide details on the following?
In some cases, the user token used to do mapi work may not have a mailbox (it could be a plain user account); what/how do you set a policy using set-mailbox if the user doesn't have one?
Also, how do you handle this for Resource Forest style (linked Mailbox)? Does remote user need the policy or the disabled user with the mailbox in the exchange forest? If the remote user needs the policy, how would you assign such?
Should we also assume that the concurrency limit applies regardless of whether you 'jump' (using CreateStoreEntryID) or directly? I sure hope that a 'jump' does not count as 2 sessions!
Also, does RPC-over-HTTPS have different behavior with regards to these limits?
Look forward to the replies.
Hi Steve, I'm interested in the Client Throttling feature of Ex2010, and specifically what my MAPI application is going to see. I sometimes see MAPI_E_NETWORK_ERROR failures from (random) MAPI calls a while after MAPI has successfully made a logon to a mailbox and wondering if this could this be related.
I haven't seen any mention in the documentation on Client Throttling what it does if it decides a client is too busy - will it just delay returning the response to the client's call or will it return something specific which the MAPI client end handles? If it's a delay, is it possible/likely that the delay might cause a timeout at the network layer causing MAPI to return something like MAPI_E_NETWORK_ERROR back to the caller?
Thanks,
Oliver Seaman,
C2C Systems
Oliver - if you're seeing that error using the latest MAPICDO download, it may not be throttling. We're tracking an issue that might be related to a recent change in the MAPICDO download. If you do a netmon of your application talking to Exchange and see a number of RPC Orphan frames followed shortly by an RPC Fault you might be seeing that issue. I don't have an ETA on a fix yet.
Hi, thanks very much Steve - yes, we are seeing that behaviour from Netmon. Do you have a reference number for the issue you're tracking that we can quote to the Exchange Support team? We have ticket 110071446516092 currently open with them on this issue.
Regards,
Oliver
Hi Steve, can you let me know if the fix for the issue you were looking at is available yet? I've not seen any update to the released version beyond 8165, is it available through direct request?
Thanks, Oliver
Oliver - nothing's public yet. It'll be available to everyone at the same time, through an update on the Download site.
Hi Steve, FYI your newly released 8190 of MAPI has fixed our customer issue - thanks :)