https://blogs.msdn.com/b/webdav_101/archive/2014/02/05/february-release-of-ewseditor-1-8-0-32423.aspx

To read more about the December 2013 update for EWSEditor check out Dan's post: https://blogs.msdn.com/b/webdav_101/archive/2013/12/31/december-2013-releases-of-ewseditor-1-7-3-27070-and-1-7-4-31181.aspx

To get your hands on the new build go to: https://ewseditor.codeplex.com

https://channel9.msdn.com/Events/Open-Specifications-Plugfests/Redmond-Interoperability-Protocols-Plugfest-2013/Exchange-Office-365-Dedicated

I’ve been working with Kostya on a number of partner engagements lately.  This is a great depth understanding of Exchange Online in Office 365 Dedicated, how it is delivered to customers, and what that means for partner solutions. Dedicated is a very unique beast as compared to Exchange on-premises or even Exchange Online as part of Office 365 Multitenant/Shared. If this is a target environment for your solution, you should watch this presentation.

Consider the following scenario…

You have an Exchange Web Services based application or service that uses a service account which has been granted the ApplicationImpersonation role and makes EWS requests with the ExchangeImpersonation SOAP header to access target mailboxes. As the frequency of basic EWS requests (GetItem, FindItem, GetFolder, etc.) made by the application or service to different mailboxes increases, the round trip times decrease or in some cases the requests fail with 500/503 HTTP error responses from Exchange 2013 or Exchange Online (W15).

To get the best throughput for EWS requests using impersonation and avoid 500/503 errors use the following solution…

A high scale EWS-based application/service that uses impersonation needs to manage affinity with the backend Exchange server by adding an HTTP header called "X-AnchorMailbox" to requests with the ExchangeImpersonation SOAP header. The values of the X-AnchorMailbox HTTP header and the ExchangeImpesonation SOAP header on the request should match.

In April, I wrote a post about EWS subscriptions in Exchange 2013 and Exchange Online (W15) which detailed the new rules for managing affinity. I concluded that post by saying…

"…[In W15] the only time affinity really should be managed by the client is subscription related requests like Subscribe, GetStreamingEvents, GetEvents, and Unsubscribe. Other requests like SyncFolderItems, FindItem, GetItem, etc. should not set X-PreferServerAffinity or return the X-BackEndOverrideCookie…"

The statement above is mostly correct for simple EWS applications that aren't using impersonation. For migration applications, services monitoring and reacting to changes across organization-wide mailboxes, etc. that use impersonation to access target mailboxes this statement is false - these applications and services should manage affinity for any request made with the ExchangeImpersonation SOAP header.

…Why? What's going on here?..

Like the subscription scenario, the need to manage affinity with impersonation goes back to changes in the CAS and MBX server roles between W14 and W15. As often explained, the CAS role is now just a smart proxy. Greg Taylor explained this most recently at TechEd. Specifically, slide #4 shares "the key to enlightenment" as follows…

When it comes to ApplicationImpersonation with EWS, we have to look at the assumption made in the Greg's second statement - "Each CAS determines the right end point for the traffic…" How does the CAS determine the right MBX server to send the traffic to? Well, for EWS at least, it is primarily based on the authenticating user. The CAS is not smart enough try and peel apart the EWS request

As we know about impersonation in EWS, the service account authenticates and the EWS request has a SOAP header which notes the mailbox to be impersonated. What this means is that in W15 the CAS server is going to send your request to the MBX server where the service account's mailbox lives. If the target mailbox the service account is trying to impersonate does not reside on the same MBX server then the request is proxied to the right MBX. If the EWS application is a high scale service, sending many requests at a time that's a lot of proxying for one MBX to do. There are at least two possible outcomes: 1) At best, you'll notice your throughput drop off due to the proxying overhead. 2) At worst, if the MBX gets overwhelmed by all the proxying, your requests might start failing with 500 or 503 HTTP errors.

The solution is to set an HTTP header called X-AnchorMailbox to the same value that you set the ExchangeImpersonation SOAP header's ConnectingSID element value. The EWS Managed API and EWS Java API will not do this automatically. However they both allow you to manually set X-AnchroMailbox using the HttpHeaders object which is a child of the ExchangeService object. You can use the HttpHeaders object's Add method to add the header name "X-AnchorMailbox" and set the value of that header to the same string used in ExchangeImpersonation. So in the example from this blog post, the value of X-AnchorMailbox would be "someone@contoso.com".

Here is an example of setting X-AnchorMailbox using the EWS Managed API, this is very similar to the EWS Java API…

 1: static void GetInbox_EWSAPI(string serviceSmtp, string servicePass, 

 2:     string targetSmtp)

 3: {

 4:     // NOTE: Even though we're using the Exchange2010 schema, we have 

 5:     // to set the HTTP headers. The HTTP header is related to request 

 6:     // routing at the CAS layer, outside the EWS schema

 7:     ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010);

 8:     service.Credentials = new NetworkCredential(serviceSmtp, servicePass);

 9:  

 10:     service.TraceEnabled = true;

 11:     service.TraceEnablePrettyPrinting = true;

 12:  

 13:     // Speed up the AutodiscoverUrl() method response time by skipping 

 14:     // a lookup for an SCP record in local AD since we know in this case 

 15:     // we're accessing O365

 16:     service.EnableScpLookup = false;

 17:           

 18:     // NOTE: Use Autodiscover to get the EWS URL for the *target* mailbox,

 19:     // not the service account. This recommendation is the same for W14 

 20:     // and W15

 21:     service.AutodiscoverUrl(targetSmtp, delegate { return true; });

 22:  

 23:     // NOTE: Both the SOAP header "ExchangeImpersonation" and the HTTP header

 24:     // "X-AnchorMailbox" are set to the SMTP of the target mailbox

 25:     service.ImpersonatedUserId = new ImpersonatedUserId(

 26:         ConnectingIdType.SmtpAddress, targetSmtp);

 27:  

 28:     service.HttpHeaders.Add("X-AnchorMailbox", targetSmtp);

 29:  

 30:     Folder inbox = Folder.Bind(service, WellKnownFolderName.Inbox);

 31: }

You can see the effect of the X-AnchorMailbox  by testing this code against Exchange Online W15 and comparing the response headers returned with the GetFolder response – assuming that the service account and target account mailboxes are on different MBX servers. You’ll notice in this test that the value of X-DiagInfo differs when this header is used. This is response header indicates which MBX server received the request.

STEP 1: Log into Outlook Web App and select “See All Options…” from the “Options” drop down on the upper right portion of the screen. In Exchange 2013, click the gear in the upper right than click on “Options”.

Exchange 2010	Exchange 2013

STEP 2: Select “Phone” from the menu at the left of the Options page. Select “Start Logging”.

Exchange 2010	Exchange 2013

STEP 3: Now let the logging run and reproduce the behavior that you are trying to understand. After reproducing the behavior, let the logs settle for a minute and click “Retrieve Log” in OWA.

Exchange 2010	Exchange 2013

STEP 4: This will create a new item in your Inbox with the mailbox logs attached in a TXT file. The TXT file contains a log of all the Exchange ActiveSync captured between the device and the server while logging has been enabled. Forward this mail to the support or help desk person or use it to do your own analysis of the given issue.

Exchange 2010	Exchange 2013

In Exchange 2010 (and W14 of Exchange Online) when an EWS client subscribed for notifications from a given mailbox folder it was the Client Access Server (CAS) that kept track of the active subscriptions. Office 365 and any substantial deployment of Exchange 2010 involved an array of CAS servers front-ended by a load balancer. This meant the EWS app only knew the URL of the load balancer and knew nothing of the servers behind it.

The EWS app used cookies to ensure subscription-related requests went back to the same CAS through the load balancer. The cookie, provided on the first request to a CAS, was sent with subsequent Subscribe and GetStreamingEvents (streaming notifications) or GetEvents (pull notifications) requests and the load balancer was configured to create affinity between the cookie and a given CAS.

The pseudo-code for an EWS app subscribing and getting events from multiple mailboxes looked like this:

1. Perform Autodiscover for each mailbox requesting the ExternalEwsUrl (mailbox1, mailbox2, mailbox3, etc.)
2. Group the mailboxes by the ExternalEwsUrl
3. For each group:
   1. Send a Subscribe request for each mailbox in group to get a SubscriptionId (using ApplicationImpersonation)
   2. The first Subscribe response will contain a cookie called "exchangecookie", resend this cookie with all subsequent requests in this group.
   3. Group the SubscriptionIds (breaking down further into groups of 200 ids if needed)
   4. Send a GetStreamingEvents or GetEvents request for each group of SubscriptionIds (not using ApplicationImpersonation)
4. Pass events returned by GetStreamingEvents or GetEvents to a separate thread for processing

With Office 365 W15 and Exchange 2013, changes to the server roles require some additional steps for the EWS app. The key change is that the CAS no longer manages the subscriptions, they are now managed by the Mailbox (MBX) server role. Now the load balancer and the CAS sit between the EWS app and the table of active subscriptions on the MBX server. The CAS does no processing of the EWS requests and just forwards them to the MBX for processing. The load balancer address in Office 365 is also simplified (https://outlook.office365.com/ews/exchange.asmx) and not specific to any site other group boundary in the datacenter. The EWS app now needs to do some work to achieve the same basic objectives: (1) group the mailboxes by site and (2) make sure requests within a group find their way to the server behind the load balancer which knows about the subscription.

To do this given the changes in W15, the EWS app must implement the following logic:

1.      Call Autodiscover for each mailbox requesting the ExternalEwsUrl and a new setting called "GroupingInformation" (mailbox1, mailbox2, mailbox3, etc.)

2.      Group the mailboxes by a concatenation of ExternalEwsUrl + GroupingInformation

3.      For each group:

a.      Send a Subscribe request for each mailbox in group to get a SubscriptionId (using ApplicationImpersonation)

                                                               i.     Add a header to this request called "X-AnchorMailbox" with a value set the SMTP address of the first mailbox in the group

                                                             ii.     Add a header to this request called "X-PreferServerAffinity" with a value set to "true"

                                                            iii.     The first Subscribe response will contain a cookie called "X-BackEndOverrideCookie", resend this cookie with all subsequent requests in this group

b.     Group the SubscriptionIds (breaking down further into groups of 200 ids if needed)

c.      Send a GetStreamingEvents or GetEvents request for each group of SubscriptionIds (not using ApplicationImpersonation)

                                                               i.     Add the "X-PreferServerAffinity" header set to "true" and the " X-BackEndOverrideCookie" to these requests as well

4.      Pass events returned by GetStreamingEvents or GetEvents to a separate thread for processing

Initially, the X-AnchorMailbox header is what directs the CAS to send the request to a specific MBX server. The response to that initial request has a cookie called "X-BackEndOverrideCookie", this cookie works similar to the "exchangecookie" in W14 in that it can be used on subsequent requests to ensure they find their way back to the same MBX server. However, it also requires at the X-PreferServerAffinity HTTP header. This forces the client to be very intentional about creating affinity to a particular MBX server. That is because (unlike in W14) the only time affinity really should be managed by the client is subscription related requests like Subscribe, GetStreamingEvents, GetEvents, and Unsubscribe. Other requests like SyncFolderItems, FindItem, GetItem, etc. should not set X-PreferServerAffinity or return the X-BackEndOverrideCookie.***

• Fixed: Unhandled exception from certificate status "unknown"
• Fixed: Minor spelling mistake on main context menu
• Fixed: typo 'LastResponseTiem' in property editor
• Fixed: Sorting item views by date/time fields sorts lexically, not by date value
• Fixed: Folder permissions dialog bugs
• Changed: Update to EWS Managed API 1.2.1
• Changed: Allow Autodiscover redirects by default
• Added: RequestId and X-DiagInfo Logging
• Added: Streaming Notifications dialog

The most significant new feature is the streaming notification dialog which Rick Hallihan added.  Thanks, Rick!  Another new feature - EWSEditor will now pull out the RequestId and X-DiagInfo headers from responses and write them to the log.

https://www.microsoft.com/en-us/download/details.aspx?id=30391

What's new in the EWS Managed API?

https://msdn.microsoft.com/en-us/library/jj220500(EXCHG.80).aspx

101 EWS Managed API 2.0 Code Samples

https://code.msdn.microsoft.com/Exchange-2013-101-Code-3c38582c

Exchange 2013 Preview SDK

https://msdn.microsoft.com/en-us/library/jj162981(office.15).aspx

What's new in EWS in Exchange 2013 Preview?

https://msdn.microsoft.com/en-us/library/jj190903(EXCHG.150).aspx

https://msdn.microsoft.com/en-US/lync/jj543530

https://msdn.microsoft.com/en-US/office/apps/fp123626

Also, code.msdn.Microsoft.com has an "office" section with tons of sample apps and projects to look at for different versions of Exchange, SharePoint, etc.

https://code.msdn.microsoft.com/office