Exchange API-spotting

What’s new for EWS in Exchange 2010 SP3

Michael Mainer — Tue, 09 Apr 2013 20:57:30 GMT

Exchange 2010 SP3 does not introduce any changes to the EWS schema or WSDL files. This means that you can use the RequestServerVersion element value of Exchange2010_SP2 to target Exchange 2010 SP3. That said, two changes in Exchange 2010 SP3 do affect EWS clients.

First, the throttling budget for Exchange impersonation scenarios uses a clone of the EWSMaxConcurrency throttling budget. This means that a user has a separate throttling budget than an account that is impersonating that user.. For more information, read the Throttling considerations for applications that use EWS impersonation section of the EWS Throttling in Exchange 2013 article.

The second change involves Exchange 2010 and Exchange 2013 coexistence. In versions of Exchange earlier than Exchange 2010 SP3, the Client Access server version has to match the Mailbox server version. Starting with Exchange 2010 SP3, a client that sends EWS requests to an Exchange 2010 Client Access server can target an Exchange 2013 mailbox.

EWS Java API 1.2 – get started!

Michael Mainer — Fri, 04 Jan 2013 05:53:55 GMT

The EWS Java API 1.2 is now available, with added support for functionality in Exchange Server 2010 SP2. It also includes an important update to the license terms that affects what you can do with the source code and the redistribution terms.

Feature-wise, we’ve implemented the following updates to the EWS Java API, which might be of interest to you:

The API now targets the Exchange 2010 SP2 version of the schema.
We've added synchronous request-response pattern implemented for handling communication with the service.
The FullContactData option of the ResolveNames operation now includes new directory properties.
Streaming notifications includes the following updates :

Subscription creation no longer causes a deadlock.
The StreamingSubscription object no longer causes a crash when the Microsoft.Exchange.Data.Storage.MailboxSession object is disposed.

Get password expiration date functionality has been implemented.
Logging capability for the HTTP headers is now included.
The HTTPHeader collection now correctly populates with the response HTTP headers.

For more information about what's new in the EWS Java API 1.2, see the release notes included in the download.

In some ways, the biggest change is that we have updated the license terms to give you a bit more freedom to customize the EWS Java API. The license updates enable you, the licensee, to do the following:

Modify the source code to fix bugs and make improvements in your own private branch of the code.
Redistribute in binary format only, as part of your application, the EWS Java API, with any changes that you have made to the original source code.
Submit bug fixes or source code to Microsoft. We can incorporate the fixes into future API releases, at our discretion.

As always, be sure to review the authoritative license terms for details.

Hopefully, these more flexible terms will open more possibilities for you to incorporate Exchange integration into your products. This update has been a long time coming, so start up your IDE, rev up your (private) code repository, and take off using the latest EWS Java API!

New EWS Managed API 2.0 reference content is now available!

robkni — Thu, 06 Dec 2012 21:57:00 GMT

The new EWS Managed API 2.0 is ready for prime time, and discovering how to use all the new Exchange Server 2013 features just got easier.

The EWS Managed API developer reference content has been updated to include descriptions, summaries, return values, and applicability statements for all new members.
In most cases, the updated member topics are for features that are new in Exchange 2013, but some existing members have been updated to reflect new functionality as well.

For a list of new and updated types and member topics, see New EWS Managed API content. To find the EWS Managed API developer reference content, see EWS Managed API namespaces.

The new and updated EWS Managed API reference content supports the following new Exchange 2013 features:

eDiscovery
Archiving
Retention policies
Mail apps for Outlook

For more information about these features, see the article New features in the EWS Managed API.

For information about the EWS Managed API 2.0, see the Exchange API-spotting post,
EWS Managed API 2.0 – now released!

For a great article that explains how to get conversation items from an Exchange mailbox by using the EWS Managed API,
check out How to: Get conversation items by using the EWS Managed API.

Don’t forget to check out our collection of code samples to help you develop Exchange 2013 applications by
using EWS Managed API. Currently, 38 code samples are available; check back for more. For a list of the current code samples,
see EWS Managed API code samples.

EWS Managed API 2.0 – now released!

Bob Bunn - MSFT — Fri, 19 Oct 2012 21:46:24 GMT

The wait is over. If you have been working with the EWS Managed API 2.0 Technical Preview, you can now get the new 2.0 version and check out the latest updates. You can download the EWS Managed API 2.0 from the Microsoft Download Center.

What's new in the EWS Managed API 2.0

The EWS Managed API has been updated to support some of the latest features that are available in Exchange Web Services (EWS) in Exchange Server 2013, including the following:

eDiscovery
Archiving
Retention policies
Mail apps for Outlook

For more information about these features, see the article New features in the EWS Managed API.

In addition to these features, the EWS Managed API 2.0 introduces the ServerBusyException class. This class represents a server busy exception that can be found in a service response. You can use the BackOffMilliseconds property of this class to set the number of milliseconds to wait before the service attempts a request again, or you can set it to zero if there is no suggested back off time.

If you have been using the EWS Managed API 2.0 Technical Preview, you might have noticed a new requirement. The EWS Managed API 2.0 Technical Preview required the .NET Framework 4, which might not be compatible with applications that you wrote with earlier versions of the EWS Managed API. That requirement has been rolled back in the EWS Managed API 2.0, which requires the .NET Framework 3.5.

The EWS Managed API 2.0 download also includes the Exchange Server 2013 token validation library. You can use the EWS Managed API and the library to build mail apps for Outlook that can be authenticated by the identity tokens issued by Exchange 2013. For more information about the EWS Managed API 2.0 and the token validation library, see Authenticating a mail app by using Exchange 2013 identity tokens.

Don’t forget to check out our collection of code samples that will help you develop Exchange 2013 applications by using EWS Managed API. Currently 38 code samples are available; check back for more. For a list of the current code samples, see EWS Managed API code samples.

New content for Exchange 2013 Preview

Chuck Bigham — Fri, 31 Aug 2012 18:22:52 GMT

Now that Exchange Server 2013 Preview is available, here's a quick summary of what you'll find on MSDN to help you learn more about the latest new features. For a detailed look at what's new in Exchange 2013 Preview, see the Exchange Team Blog.

Developer roadmap for Exchange

We created a new Developer roadmap for Exchange that provides an overview of what's new in Exchange development, and is designed to help you determine the best way to develop your Exchange applications. It covers the technologies that are available in each version of Exchange and the evaluation criteria that you can use to select the right development technology for your application. If you're planning to migrate to Exchange 2013 Preview, you'll find information about migrating your applications from earlier versions of Exchange to the new version in the article Migrate from earlier technologies to Exchange 2013. Feel free to leave us a comment to let us know which migration scenarios are important to you.

Changes to the EWS APIs

Exchange Web Services (EWS) and the EWS Managed API have been updated to provide programmatic access to the new features in Exchange 2013 Preview. We’ve added documentation to support the following new features:

· eDiscovery — Enables you to preserve and discover data across your organization to ensure internal and regulatory compliance.

· Archiving — Enables you to move mail items from a primary mailbox to an archive mailbox for long-term storage.

· Retention policies — Enables you to group retention tags, apply retention settings to folders and individual items, and apply retention settings to a mailbox.

· Block senders and mark email as junk — Enables you to keep junk email messages out of users' Inboxes.

· Getting user photos — Gets the photo that is associated with an email account from an Exchange server by using a simple HTTP GET request.

· Personas (EWS only) — Enables you to link to, search for, and browse for information about a person from multiple sources.

· Unified Contact Store (EWS only) — Enables you to store, manage, and access contact information from any application.

For more information about these new features, see New features in the EWS Managed API and New features in EWS in Exchange 2013.

Mail apps for Outlook

One of the exciting new features of Microsoft Office 2013 Preview is apps for Office. Apps for Office enable you to extend the power of Office applications by using standard web technologies to create individual apps. Exchange server supports mail apps for Outlook and Outlook Web App to add contextual information to email messages and calendar appointments. For information about migrating from a customized Outlook Web App to mail apps for Outlook, see Migrate to mail apps for Outlook Web App customization. For information about how to create mail apps for Outlook and Outlook Web App, see Mail apps for Outlook. See also the new blog dedicated to apps for Office, the Apps for Office and SharePoint blog.

Exchange 2013 101 code samples

Want code samples? New for Exchange 2013 Preview is the Exchange 2013 101 code samples package, which includes code samples that will help you to develop Exchange 2013 Preview applications by using the EWS Managed API. The package currently includes 38 code samples, and we’ll add more. You can download them all, or you can select just the ones that you want and download them individually. For a list of all the code samples that are currently available, see EWS Managed API code samples.

Join the conversation

Finally, we invite you to take advantage of the Community feature to give us feedback on our Exchange 2013 Preview documentation. Let us know how we can improve our content to better meet your needs. We’ll also be updating the documentation periodically, so keep an eye out for new content announcements.

Exchange Web Services Managed API 1.2.1 – now released!

Michael Mainer — Tue, 19 Jun 2012 00:16:00 GMT

The latest release of the EWS Managed API, version 1.2.1, is now available. The EWS Managed API 1.2.1 includes new Exchange Web Services (EWS) client logging features for Exchange Online as part of Office 365, as well as some minor bug fixes. You can download the EWS Managed API 1.2.1 from the Microsoft Download Center.

What’s new in the EWS Managed API 1.2.1

The EWS Managed API 1.2.1 includes new Exchange Online–specific functionality for logging client access and client latencies. This new functionality is implemented by means of two new HTTP headers: RequestId and X-ClientStatistics. Starting with the EWS Managed API 1.2.1, this functionality is enabled by default. You can enable this functionality in previous versions of the EWS Managed API by accessing the HttpHeaders and HttpResponseHeaders collection on the ExchangeService object.

This change allows for the debugging of communication issues that occur between Exchange Online and the EWS Managed API. In fact, this functionality should be implemented by any EWS client that will be targeting Exchange Online.

The new RequestId header is returned in every response from EWS in versions of Exchange starting with Exchange Server 2010 SP2 RU2, and in Exchange Online. While this header is available for both an on-premise Exchange deployment and Exchange Online, it is particularly relevant for Exchange Online. The RequestId header contains a GUID value that uniquely identifies your request in the Office 365 server-side logs across all the Office 365 data centers. Essentially, you should log these requests with the client. If a support incident does occur, you can provide the RequestId to the Office 365 support engineers to help them identify issues related to the request.

You can use the new X-ClientStatistics header to provide additional logging information for Exchange Online. You can enable additional performance logging for Exchange Online by providing the following information in your requests:

The RequestId received from a previous request
The client-logged round trip time between the request and response
The SOAP action

Note that the X-ClientStatistics header can be used to report data back to Office 365 at any time and that it can batch multiple latencies in a single header. This is another useful resource for Office 365 support engineers.

Important: The X-ClientStatistics functionality is not available for on-premise Exchange deployments.

The RequestId and X-ClientStatistics headers are both implemented in the EWS Managed API 1.2.1. The RequestId header is sent by Exchange with every response. You can disable the X-ClientStatistics functionality on the ExchangeService object by setting the new SendClientLatencies properties to false.

If you are using Exchange Online but you are not using the EWS Managed API, we recommend that you capture and log the RequestId header and the send X-ClientStatistics header. The following are the header definitions:

RequestId: <GUID>; where <GUID> is the unique request identifier.
X-ClientStatistics: MessageId=<RequestIdFromPreviousResponse>,ResponseTime=<EndToEndLatencyInMiliseconds>,SoapAction<operation>; where <RequestIdFromPreviousResponse> is a request identifier from a previous response, <EndToEndLatencyInMiliseconds> is the client-logged round trip time between when the request was submitted and when the response was received for the request-response identified by the RequestId, and <operation> identifies the SOAPAction header for the request identified by the RequestId header. If you are sending multiple client latency reports back to the server, you must separate the latencies with a semicolon.

The EWS Managed API 1.2.1 fixes two Autodiscover redirect issues for scenarios in which an Exchange Server 15 user targets a request to an Exchange 2010 server.

While not a large set of changes, they are still interesting. These updates will primarily help Office 365 support engineers help you if your application experiences issues communicating with the server. This should help make our service perform better, and your problems to be solved in a shorter amount of time.

More throttling changes for Exchange Online

Michael Mainer — Thu, 19 Apr 2012 17:21:57 GMT

In my last post, Exchange Online EWSMaxSubscriptions throttling budget calculation has been updated!, I wrote about a recent change to the EWSMaxSubscriptions throttling setting. Although useful, that information is just one part of the story. Now I’m here to fill you in on the rest.

We have made changes to the way that throttling budgets are counted for application impersonation calls. Now, the calls are charged against the target mailbox instead of the service account that makes the application impersonation calls. More specifically, the charges are counted against a copy of the target mailbox quota. This means that the impersonated service account access is not charged against the target mailbox account owner’s throttling budget. It is important to note that the copied budget is shared across all service accounts that are using application impersonation. This information is important when you are enabling many application impersonation scenarios against mailboxes. In summary, each throttling setting represents two budgets: one for the user account, and one for all service applications that use application impersonation against a specific user mailbox.

Here is a complete list of the throttling settings that have been updated with the new budget accounting:

EWSMaxConcurrency
EWSPercentTimeInAD
EWSPercentTimeInCAS
EWSPercentTimeInMailboxRPC
EWSMaxSubscriptions
EWSFastSearchTimeoutInSeconds
EWSFindCountLimit

I’d expect this to be welcome news. With that said, there is one exception to the change. The EWSMaxConcurrency setting limit does have some variation in how it is implemented for different types of connections. EWS streaming notifications have a separate budget from all other EWS client connections. For example, if EWSMaxConcurrency is set to the value of 10, it means that a user account (and all service applications using application impersonation) can have up 10 concurrent streaming notification subscriptions and 10 other concurrent EWS connections while targeting a single mailbox.

What does this mean for Exchange Online and streaming subscriptions? In short, this means that a service account can monitor up to 2000 mailboxes. Allow me to explain how this works. A service account application using application impersonation performs Subscribe operations using impersonation to set up subscriptions for each of the target mailboxes. Then, the service account application would bundle all the SubscriptionIds, up to 200 per GetStreamingEvents request, from all the mailboxes and include them in one GetStreamingEvents request. (NOTE: GetStreamingEvents and GetEvents operations do not have to use the impersonation header to get the notification events for the impersonated email messages. As long as the service account has a valid SubscriptionId, it can access the event notifications.) A service account can have at most 10 open GetStreamingEvents requests open at any one time. We recommend that there are no more than 200 SubscriptionIds in each GetStreamingEvents request. This effectively means that a single service account can monitor up to 2000 subscriptions, or 2000 mailboxes if you assume one subscription per mailbox. We expect that this should scale fairly well.

As with my last post, these changes have taken effect as of service mailbox versions 14.16.0135 and 14.15.0057.000 and later. These are customer-driven changes and we do appreciate the feedback. Code on!

Exchange Online EWSMaxSubscriptions throttling budget calculation has been updated!

Michael Mainer — Wed, 04 Apr 2012 00:20:41 GMT

We have made a change to the way that Exchange Online accounts for the number of subscriptions against the EWSMaxSubscriptions throttling limit.

In earlier versions of Exchange Online, the throttling limit was calculated against the calling account. A calling account, which can be one or many client applications or a service account targeting many mailboxes, was limited to 20 notification subscriptions. This subscription limit restricted Exchange Impersonation scenarios in which a service account accesses a large number of mailboxes. It limited a service account to at most access to 20 different mailboxes, assuming one subscription per mailbox, or 20 subscriptions on one mailbox. This was not very scalable. For example, if a service account had to access 5000 mailboxes, you had to have 250 service accounts to account for this limitation.

Starting with service mailbox versions 14.16.0135 and 14.15.0057.000, this limit has changed. Now, the charges are counted against the target mailbox rather than the calling account. This way, a service account can create subscriptions against many more than 20 mailboxes. One benefit of this change is that you can now design a service application that targets Exchange Online and Exchange on-premises using a similar code base for subscription management. A single service account can now service up to 5000 subscriptions.

Customers, you asked for this change, and now you have it. Subscribe on!

EWS item identifier and your database

Michael Mainer — Tue, 03 Apr 2012 17:02:54 GMT

Several times we’ve heard people ask what the maximum size is for the EWS identifier. This question usually comes up when developers are designing a database schema that will store the EWS identifier in a fixed-width column. Our answer is that the EWS item identifier should be contained in a fixed-width column of 512 characters. So, how confident should you feel about defining your field at 512 characters? Well, of course we reserve the right to change the format, and the resulting maximum length of the EWS identifier. The chances of that occurring, however, are very slim. The EWS identifier format has been changed once between Exchange 2007 and 2007 SP1, early on in the adoption of EWS, but we acknowledge that changing the format at this point would have unwelcome effects on both customer and Microsoft applications that interoperate with Exchange. In short, we do not expect the EWS identifier format to change.

New Exchange Interoperability Content on Open Specifications Developer Center

Thomr — Thu, 26 Jan 2012 00:03:01 GMT

In November and December 2011, Exchange content made its debut on the Learn Open Specifications and Interoperability page in the Open Specifications Developer Center:

The updates include nine new Microsoft Exchange Learning Modules:

While you’re on the Learn tab exploring the new Exchange learning modules, don’t miss the Open Specifications Interactive Pivot, which also includes Exchange open specifications documents. We’re very excited about the Pivot, which makes it easy to find the open specifications documents you need in a visual, intuitive way. The Pivot uses Silverlight Deep zoom technology, which lets you visually search and filter the open specifications documents. Once you use it, you’ll see why we’re excited.