EWS, Office 365, An internal server error occurred. The operation failed. RRS feed

  • Question

  • I am using EWS 2.0 to access a users calendar in Office 365. I use AutoDiscover to find the ExchagneService, then bind to the calendar via CalendarFolder.Bind and at the next statement folder.FindAppointments I get the error

    An internal server error occurred. The operation failed.

    I know that the credentials used to access the user are correct - have tested in the webmail and it works just fine.

    If I use my own credentials (after having assigned rights to the user in question) my program does not fail. Only apparent difference is the administrator role.

    Below I have listed the central parts of the code:

    First the AutoDiscover (which work)

    service = new ExchangeService(ExchangeVersion.Exchange2010_SP1,TimeZoneInfo.Local ); // service is a global variable
    service.Credentials = new NetworkCredential(ConfigClass.CalendarReaderName, ConfigClass.CalendarReaderPassword);
    service.AutodiscoverUrl(cal, RedirectionUrlValidationCallback);

    Then the part where I want to get the appointments

    CalendarView view = new CalendarView(_firstdate, _lastdate);
    Mailbox mailbox = new Mailbox(cal); // cal is the e-mail address of the user
    FolderId id = new FolderId(WellKnownFolderName.Calendar, mailbox);
    CalendarFolder folder = CalendarFolder.Bind(service, id);
    FindItemsResults<Appointment> findResults = folder.FindAppointments(view); // This is where the error occurs

    Anybody know what this error actually means and how to solve the situation. I want to run the program using a service account rather than my personal credentials.

    Wednesday, January 15, 2014 1:07 PM

All replies

  •  Could mean a number of things you might want enabled tracing and post the traces with the errors


    Thursday, January 16, 2014 4:56 AM
  • Thanks for the input, Glenn.

    Odd thing - today it worked with the account that failed yesterday ... and I did not change anything ...

    (-> file under "O365 unexplainables"?)

    The trace will be useful in other situations so I have implemented it :-)

    Do you by the way know a way to speed up the AutoDiscovery? It takes about 90 seconds to find the Exchange server. Or is it possible to store the last working instance of ExchangeService - like in XML - Serialization?
    • Edited by Morten Skaarup Thursday, January 16, 2014 12:00 PM Added info
    Thursday, January 16, 2014 11:53 AM
  • the error came back - but the trace revealed the error:

              <m:FindItemResponseMessage ResponseClass="Error">
                <m:MessageText>An internal server error occurred. The operation failed.</m:MessageText>
                  <t:Value Name="InnerErrorMessageText">Too many concurrent connections opened.</t:Value>
                  <t:Value Name="InnerErrorResponseCode">ErrorTooManyObjectsOpened</t:Value>
                  <t:Value Name="InnerErrorDescriptiveLinkKey">0</t:Value>

    The account is used for other purposes as well - looking into other calendars. And I have seen this limitation before and read that it is a timing issue.

    I guess I need to use another account ...

    Thursday, January 16, 2014 2:53 PM
  • The important information in that log is

    Too many concurrent connections opened

    This means you are getting throttled by the Exchange Server. In Office365 you can't adjust the throttle setting so it's important to make your application work within the throttle limits see .

    One user is limited to 10 concurrent connections via EWSMaxConcurrency setting.


    Friday, January 17, 2014 3:10 AM
  • Glenn,

    Thanks for the link to the article - very interesting :-)

    In a similar program I ask 17 meetingrooms for appointments. I got the concurrent connections error there as well.

    However, I still cannot figure out how to work around the limitations in O365. I have tried to make a pause between the requests (up to 60 secs per 3 requests) and it still ends up with an error after 17 meetingrooms:

    Resuested value "ErrorTooManyObjectsOpened" was not found.

    So how do I ensure that the connection is released? - so I can stay within the 10 concurrent.

    Friday, January 17, 2014 1:01 PM
  • I would suggest you try if you not already using the AnchorMailbox header see

    eg make sure you set and change the header so it points to the MeetingRoom Mailbox your trying to access during requests.


                String MeetingRoomEmail = "";
                    service.HttpHeaders["X-AnchorMailbox"] = MeetingRoomEmail;
                    service.HttpHeaders.Add("X-AnchorMailbox", MeetingRoomEmail);

    That should stop or at least limit the servers your request will be relayed through which I've seen cause problem with other things. 


    Sunday, January 19, 2014 10:31 PM
  • We're running into this same issue with our calendar sync process and O365.  Everything works fine with on-prem EWS configurations. We are seeing the "Too many concurrent connections opened" error when using a single delegate account to sync to 30+ conference room calendars.

    We've created a simple single-threaded test app that can reproduce the behavior. Basically, we encounter this error after accessing about 15 calendars. If we then pause for about 4 min then we can start again for another 15 calendars.

    The X-AchorMailbox header seems to have no effect for us.

    We're looking at creating more delegate accounts and rotating through those accounts. But this seems kind of wrong and painful. Any other options to work around this limitation?


    james swanson --- application architect

    Tuesday, March 11, 2014 4:59 PM
  • Have you tried using the Grouping information from Autodiscover in .I know this specifically refers to Streaming notifications but it should also help. You can look at the  X-DiagInfo information returned to see what backend server is processing things . As people are reporting failing after processing different mailbox numbers that maybe contributing to the number of connections being opened.


    Wednesday, March 12, 2014 3:51 AM