Exchange Web Services (EWS)
What is Microsoft Exchange Web Services (EWS)?
Microsoft Exchange Web Services (EWS) is an application program interface (API) that lets applications access items in a Microsoft Exchange email mailbox, such as calendars, contacts and messages. With EWS, many types of applications can access any of these items from on-premises versions of Exchange (from Exchange Server 2007 onwards) as well as Exchange Online (including Exchange Online included in Office 365).
EWS first became available in Exchange Server 2007. This cross-platform managed API provides Exchange administrators with the flexibility to store, retrieve, move and modify email and email-related data. This data may belong to a single user, a group of users and even an entire Exchange Server organization on an Exchange server.
EWS is also useful for the following:
- Migrating on-premises Exchange data to a third-party cloud host.
- Performing bulk mail transfers or retrievals.
- Searching through Exchange stores.
- Managing users and messaging records.
The EWS API includes several features that are also available in Exchange Online and Exchange 2013 onwards:
- EDiscovery. A federated query web service that lets external applications perform eDiscovery queries on Exchange data.
- Archiving. Secondary mailboxes for email archiving help manage email storage limits.
- Retention policies. Policies used to group one or more retention tags and apply retention settings to folders, individual items or an entire mailbox.
- Mail apps for Outlook management. Support for managing multiple mail apps for Microsoft Outlook -- to disable them, get app manifests, get app marketplace URLs, get client access tokens, etc.
How applications use Microsoft Exchange Web Services to access mailbox items
EWS lets a host of applications access mailbox items both locally and remotely. The application simply sends a request to the Exchange server in an extensible markup language (XML) message based in Simple Object Access Protocol (SOAP). That means the request message is in XML format but complies with the SOAP standard. The SOAP/XML message is embedded in an HTTP/HTTPS message, so any application that can post XML through HTTP/HTTPS can use EWS to access the required Exchange mailbox items.
Here's what happens once the Exchange server receives a request from an application:
- The server verifies the credentials provided by the client and automatically parses the XML for the requested data.
- It builds a SOAP response containing XML data. The response represents the requested strongly typed objects and their properties.
- The application receives the XML data in an HTTP response and deserializes the XML.
- The application uses the data to reform the strongly typed objects.
Exchange Web Services architecture
EWS applications work with both on-premises and online versions of Microsoft Exchange. These applications can be installed on a client or on an Exchange on-premises Client Access Server (CAS) and are a key part of the EWS architecture.
Other important elements in the architecture include the following:
SOAP/XML message
A SOAP/XML message is required for applications to access information from the Exchange store. This XML message is in a SOAP envelope and embedded in an HTTP/HTTPS message. The latter is required for Exchange Online and must conform to the Services.wsdl file on the CAS.
EWS service
The EWS service is described by three files and EWS Managed API assemblies (EWS on-premises architecture only). Each file has its own function. One describes the contract between the client and server, the second defines the request and response SOAP messages, and the third defines the elements used in the SOAP messages.
These files are not used for schema validation. But the EWS schemas are backward- and forward-compatible, so an application that targets an earlier schema version will also work with a later schema version. The API assemblies are provided for server-side EWS client applications and deployed on all Exchange Server roles.
Load balancer
The load balancer component is only visible in the Exchange on-premises architecture. Its job is to distribute the SOAP/XML message to a CAS in the CAS array.
Authentication
Different EWS applications use different authentication methods as part of the HTTP/HTTPS payload. For example, client applications use New Technology Lan Manager (NTLM) authentication, while portal applications use Open Authorization (OAuth) authentication. Service applications can use either impersonation or OAuth for authentication.
Client Access Servers
Like load balancers, a CAS component is only visible in the Exchange on-premises architecture. It refers to a load-balanced group of CASes. Individual CAS authenticate requests, perform Exchange Autodiscover lookups and proxy received requests to the Mailbox server. However, they are thin and stateless and, therefore, cannot store or queue data or do any data rendering. For all these activities, a CAS server and load balancer are required.
Database Availability Group (DAG)
A DAG is only available in the Exchange on-prem architecture. It refers to a group of mailbox servers that can be deployed in one or more datacenters. A mailbox server handles all activity for its active mailboxes and consists of all the components that process, render, and store data.
What are some Exchange Web Services applications?
Users can create many types of EWS applications by using EWS in Exchange, as EWS and Exchange architecture provide a uniform development model that supports easy and consistent application creation. All applications can use a common code base to retrieve information from Exchange, and there's no need to change the code. The only function that changes between applications is the mechanism used for mailbox access and authentication.
To communicate with an Exchange server, all EWS applications must support protocols like HTTP/HTTPS, SOAP 1.0, Web Services Description Language (WSDL) 1.0, Secure Sockets Layer /Transport Layer Security (SSL/TSS) and XML/XML Schema Definition. The applications must also support these authentication methods: Basic and NTLM authentication over SSL and OAuth 2.0 token authentication for trusted partner applications.
The three most common types of applications created with EWS in Exchange are the following:
Client applications
These standalone applications use EWS to retrieve and access data from Exchange, either via direct client access or by delegating access to retrieve the required data. Users can only access the information in their own mailbox with their own logon credentials due to Basic, NTLM (older Windows) or Kerberos (Windows integrated) authentication. Examples of client applications include Outlook, Outlook on the Web (formerly Outlook Web App) and Microsoft Teams.
Portal applications
Portal applications typically access information from Exchange, such as free/busy times on a calendar or contact information to extend an existing web page or portal and to make it more personalized. One example of a portal application is a SharePoint web part that provides users with personalized experiences as they view pages on a SharePoint portal.
Like client applications, portal applications can also use direct client access or delegate access to information from the Exchange mailbox store. In addition, these applications can use impersonation to retrieve the required data. The authentication method used is OAuth since it provides a seamless and secure method to authenticate data.
Service applications
Service applications are the background jobs built into an existing application to integrate or synchronize data between a system and Microsoft Exchange. For example, an application that synchronizes contact information from Exchange into a CRM application is a service application.
Most service applications do not have a user interface. They also use either impersonation or OAuth for authentication, data access and mailbox operations for multiple (impersonated) accounts.
Follow these 12 Microsoft Exchange Server security best practices.
