none
Office 365 Streaming Notifications, "One or more subscriptions in the request reside on another Client Access server." RRS feed

  • Question

  • Hello all,

    I am maintaining a part of our product that requires monitoring mailboxes for events.  This is currently being done by using streaming connections for getting the notifications.  Our solution has been successful for situations with smaller numbers of mailboxes, ~200 or less.  However we are seeing some issues when scaling up to say, 5000 mailboxes.

    The error and the sequence leading up to it are as follows:

    Make an Exchange Service Account.

    exchSvc.ConnectionGroupName = someGroupName;

    add to the httpheaders ("X-AnchorMailbox", userSmtp) and ("X-PreferServerAffinity", "true");

    create a new impersonated UserId for the userSmtp address that is our anchor mailbox.

    set the Exchange Service account ImpersonatedUserID to the one we just made.

    ExchangeServiceAccount.SubscribeToStreamingNotifications(new FolderId[] { WellKnownFolderName.Inbox }, _mailEvents);

    to this point everything was successful, saw no error messages.

    we create a second impersonated UserID for a different mailbox, and repeat the process above from that step forward.  Upon the final step, subscribing to the streaming notifications we get the error:
    Exception: Microsoft.Exchange.WebServices.Data.ServiceResponseException: One or more subscriptions in the request reside on another Client Access server. GetStreamingEvents won't proxy in the event of a batch request.

    This is only the second subscription that we are trying to add to this connection, and it is to a different mailbox than the first.

    Can anyone please help point me to where this is going wrong?



    • Edited by MikeHix Tuesday, October 28, 2014 11:20 PM
    Tuesday, October 28, 2014 10:59 PM

All replies

  • The header that's important in regards to affinity is the X-BackEndOverrideCookie cookie which is described in http://msdn.microsoft.com/en-us/library/office/dn458789(v=exchg.150).aspx.

    The error you getting is indicating that the request is being routed to a CAS server where the subscription doesn't reside and this header should dictate this. The is also a maximum of 200 subscription for each Group are you using Groups ?

    Things you might want to look at are X-BackEndOverrideCookie is being sent when you get the error and what actual Server that Mailbox should be using from the Grouping information in autodiscover. You should also be using a separate Instance of the ExchangeService class for each Group of subscriptions.

    Cheers
    Glen

    Wednesday, October 29, 2014 3:19 AM
  • Hello and thank you for the reply,

    We are using groups and each group does get its own instance of ExchangeService.  The error I am getting is on the second subscription in a new group, just after doing the anchor mailbox so I don't think we are hitting the 200 limit.  Is there a good way to verify the number of subscriptions in a group?

    I checked and the X-BackEndOverrideCookie does get set for the ExchangeService after we get the response from the first subscription.

    Lastly the grouping information retrieved for the second mailbox matches that of the first, as well as the ews URL, which if I'm understanding this correctly means if should be on the same CAS?

    Thank you,
    -Michael

    Wednesday, October 29, 2014 3:58 PM
  • >> Is there a good way to verify the number of subscriptions in a group?

    Not that I know of you should be tracking this in your code there are no server side operations in EWS to even tell you if there are active subscriptions on a mailbox.

    >>The error I am getting is on the second subscription in a new group, just after doing the anchor mailbox so I don't think we are hitting the 200 limit. 

    It's hard to say without seeing your code but it sounds like there is problem with your grouping code. One way to validate this is that with every request you make with the EWS managed API there is a RequestId header http://blogs.msdn.com/b/exchangedev/archive/2012/06/18/exchange-web-services-managed-api-1-2-1-now-released.aspx you should be able to give that RequestId to the Office365 support people and they should be able to check the EWS Log on the server and tell you more about what's happening (it maybe server side bug). Something doesn't quite add up in that the X-BackEndOverrideCookie is what ultimately determines what server the request ends up at and the error is essentially telling you its ending up at the wrong server (have you looked at the headers on the error message?). Is it always one group of users that fails have you tried different groups and different combinations etc.

    Cheers
    Glen


    Thursday, October 30, 2014 4:48 AM
  • >>Not that I know of you should be tracking this in your code there are no server side operations in EWS to even tell you if there are active subscriptions on a mailbox.

    I figured as much, we do track this in the code but having a second source of a count would've been a nice double-check.

    >>Is it always one group of users that fails have you tried different groups and different combinations etc.

    We have seen this in multiple places so I am following your advice on getting the RequestId and the rest of the information from the ExchangeService(headers etc.) and will be continuing along that path of investigation next.  Hopefully something I find there will make this all clear.

    Thank you again for your help,
    -Michael

    Thursday, October 30, 2014 10:57 PM