Throttling Exchange 2010

re: Throttling Exchange 2010

Oliver Seaman — Thu, 04 Nov 2010 12:45:50 GMT

Hi Steve, FYI your newly released 8190 of MAPI has fixed our customer issue - thanks :)

re: Throttling Exchange 2010

Stephen Griffin - MSFT — Mon, 04 Oct 2010 13:55:59 GMT

Oliver - nothing's public yet. It'll be available to everyone at the same time, through an update on the Download site.

re: Throttling Exchange 2010

Oliver Seaman — Mon, 04 Oct 2010 10:20:32 GMT

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

re: Throttling Exchange 2010

Oliver Seaman — Fri, 16 Jul 2010 14:40:37 GMT

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

re: Throttling Exchange 2010

Stephen Griffin - MSFT — Wed, 14 Jul 2010 15:16:49 GMT

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.

re: Throttling Exchange 2010

Oliver Seaman — Wed, 14 Jul 2010 14:22:24 GMT

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

re: Throttling Exchange 2010

Eriq VanBibber — Thu, 01 Apr 2010 02:07:22 GMT

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.

re: Throttling Exchange 2010

k.dzenisevich — Tue, 26 Jan 2010 14:06:51 GMT

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:

IMsgStore store1;

HRESULT r = IMAPISession->OpenMsgStore(..., &store1);

ATLASSERT(r == 0);

store1->Release();

IMsgStore store2;

r = IMAPISession->OpenMsgStore(..., &store2);

ATLASSERT(r == 0x8004011D);

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.