none
EWS 2010 > GetFolder > ErrorInternalServerTransientError / FindItem > ErrorInternalServerTransientError RRS feed

  • Question

  • Hi,

    We have a Java application which is checking room's account's calendar folder.

    First the app try to get room's folder id. Then it is searching the calendar folder with FindItems method.

    If account's count over 16, comes this error (There is 35 room account on the Exchange Server):

    <m:GetFolderResponseMessage ResponseClass="Error">
          <m:MessageText>An internal server error occurred. Try again later.</m:MessageText>
          <m:ResponseCode>ErrorInternalServerTransientError</m:ResponseCode>
          <m:DescriptiveLinkKey>0</m:DescriptiveLinkKey>
          <m:Folders/>
        </m:GetFolderResponseMessage>
        
     <m:FindItemResponseMessage ResponseClass="Error">
          <m:MessageText>An internal server error occurred. Try again later.</m:MessageText>
          <m:ResponseCode>ErrorInternalServerTransientError</m:ResponseCode>
          <m:DescriptiveLinkKey>0</m:DescriptiveLinkKey>
        </m:FindItemResponseMessage>

    It sounds like throttling policy problem, but I have no information about error details and how to solve it.

    The Exchange Server version is 2010 and I bet it has the default settings for Throttling Policy:

    EWSFastSearchTimeoutInSeconds:

    60
    EWSFindCountLimit:

    1000

    First I asked the Exchange Admin, if he could disable Throttling Policy, find out it is really the problem.

    Do you have any idea, where to start solve this problem?

    Thanks in advance!

    Béla

    Tuesday, June 18, 2013 6:19 AM

All replies

  • Are you making concurrent requests to these mailboxes ? if so the default throttling policy will stop you making anymore the 10 concurrent connections.

    To see if it is throttling you can look at the EWS log on the server generally located in "C:\Program Files\Microsoft\Exchange Server\V14\Logging\Ews " or whatever your install path is.

    Some things you can do to work around this is to use Impersonation instead (this will mean the throttling budget is charged against the Destination mailbox rather then the caller) http://blogs.msdn.com/b/exchangedev/archive/2013/04/09/what-s-new-for-ews-in-exchange-2010-sp3.aspx (not needs SP3 on the server). The other thing is to make sure you code is as efficient as possible and is putting the least amount of load on the server to get whatever your trying done. I'd recommend watching http://channel9.msdn.com/Events/Open-Specifications-Plugfests/Windows-Identity-and-Exchange-Protocols-Plugfest-2012/Exchange-Web-Services-Affinity-and-Throttling

    Cheers
    Glen

    Tuesday, June 18, 2013 6:49 AM
  • Thank you Glenn for your fast answer!

    I got some Exchange log from the Admin:

    Process w3wp.exe () (PID=xxxx). User 'Sid~xxxxxxx~EWS~true' has gone over budget '107' times for component 'EWS' within a one minute period. Info: 'Policy:DefaultThrottlingPolicy_xxxxxxxx, Parts:RPC:106;'. Threshold value: '100'.

    Which settings is connected to this problem I can't found any 100 default value.

    The Exchange server is 2010 SP2. The admin will install SP3 and with this patch: http://support.microsoft.com/kb/2668900 .

    The application / users make concurrent connection.

    What could be a good value for a production server? I think 100 concurrent connection / users could be a value, but what it requires from the hardware / IIS?

    Is there a specific error for this case or can it be this ErrorInternalTransientError?

    The account is used is a normal mailbox account. Impersonisation cannot be used, because of a Company level policy. So this throttling budget can be a user specific setting?

    Thanks,

    Béla



    • Edited by Bela Borbely Wednesday, June 19, 2013 6:36 AM update
    Wednesday, June 19, 2013 6:33 AM
  • Its hard to tell just from one line of the log but i would say "Parts:RPC" means you exceeding the PercentTimeInMailboxRPC which is "The EWSPercentTimeInMailboxRPC parameter specifies the percentage of a minute that an Exchange Web Services user can spend executing mailbox RPC requests (PercentTimeInMailboxRPC). A value of 100 indicates that for every one-minute window, the user can spend 60 seconds of that time consuming the resource in question."

    which means that for one thread your never going to have a problem the more threads your running then the potential is that you'll overrun this value increases.

    If you not running impesonation every call will be charged against the service accounts budget your using not the mailbox your running it aginst. So what you can do is

    Remove thottling on the Service Account or give it a seperate policy (these can be set per user) see http://blogs.technet.com/b/exchange/archive/2010/08/27/3410837.aspx

    Cheers
    Gllen

    Wednesday, June 19, 2013 11:27 AM
  • Hello,

    I have some more log, about the problem:

    Mapi session "xxxxx-xxx-xxx-xxx-xxxxx: /o=xxxxx/ou=Exchange Administrative Group (xxxxxx)/cn=Recipients/cn=xxxxxx" exceeded the maximum of 50 objects of type "session".

    This belongs to this settings: Maximum Allowed Service Sessions Per User.

    If there is a FindItem request for 35 from room calendar / account and this request made 5-10 per minute, why it goes over the limit?

    Is there one session per room calendar? How to count this? We fetch an extended property, the uid, can it be the reason for this amount of session started?

    Thanks in advance!

    Béla


    Tuesday, September 3, 2013 8:37 AM
  • The only thing you can adjust from the Exchange\EWS side are the throttle settings. You might want to look at using Exmon to see what Mapi sessions are in use on your server http://www.microsoft.com/en-au/download/details.aspx?id=11461 . Eg you maybe have blackberry devices or other apps that are hitting the server. The only other thing would be make sure you have the server fully patched as it could just be a bug that has been fixed in a rollup.

    You can also tweak the Mapi session limits with the reg entries described in http://support.microsoft.com/kb/830829/en-au these shouldn't affect EWS requests.

    Cheers
    Glen

    Thursday, September 5, 2013 5:27 AM