Knowledge Base

What is Exchange Web Services (EWS) and Why is it Being Removed?

Exchange Web Services (EWS) is a web service interface used to communicate between Microsoft Exchange Server and other applications. EWS has provided various functions such as calendar management, sending and receiving emails, contact management, and task management. However, Microsoft has decided to replace EWS with Microsoft Graph, a more modern and secure API. The main reasons for this are:

• Security: Microsoft Graph supports more modern security protocols compared to EWS and provides more secure access.
• Performance: Microsoft Graph is a more optimized API and offers better performance than EWS.
• Features: Microsoft Graph offers new features not available in EWS and is better integrated into the Microsoft 365 ecosystem.
• Modernization: Microsoft is prioritizing Microsoft Graph for modern cloud-based applications.

This change requires applications using EWS to be migrated to Microsoft Graph. This migration may involve some challenges, but in the long run, it will provide a more secure, performant, and feature-rich solution.

When Will EWS Be Completely Removed?

Microsoft has not specified a definite date for the complete removal of EWS. However, it has stated that the use of EWS will be gradually reduced and the transition to Microsoft Graph will be encouraged. Users will be given sufficient time before EWS support is discontinued. Microsoft regularly publishes updated information regarding the removal of EWS. Therefore, it is important to follow Microsoft's official announcements.

How Can I Detect Which of My Applications Are Using EWS?

There are several methods to detect applications using EWS:

1. Reviewing Exchange Server Logs: By searching for EWS requests in the Exchange Server logs, you can identify applications using EWS. This will help you understand which applications are accessing EWS and what types of operations they are performing.
2. Reviewing Application Code: By searching for EWS references in the application code, you can verify that the application is using EWS. In particular, you can search for the `ExchangeService` class or EWS methods such as `FindItems`.
3. Monitoring Network Traffic: By monitoring network traffic, you can detect requests made to EWS endpoints. This will help you understand which applications are accessing EWS and which protocols they are using.
4. Microsoft 365 Admin Center: In the Microsoft 365 Admin Center, there are reports and analysis tools to monitor EWS usage. These tools can help you evaluate EWS usage in general and identify potential issues.

Example: Examining Exchange Server Logs

To find EWS requests in Exchange Server logs, you can use the following PowerShell command:

Get-ExchangeServer | Get-Mailbox | Get-MailboxAuditLog -LogonTypes Owner,Admin -StartDate (Get-Date).AddDays(-30) | Where-Object {$_.Operation -like "*EWS*"} | Select-Object Caller,LogonType,Operation,LastAccessed,ClientIPAddress,ClientMachineName | Export-Csv -Path "C:\EWS_Audit_Log.csv" -NoTypeInformation

This command records accesses made via EWS in the last 30 days and exports them to a CSV file. By examining this file, you can identify applications and users using EWS.

How Will the Migration Process to Microsoft Graph Be?

The migration process to Microsoft Graph may vary depending on the complexity of your application and its use of EWS. In general, you can follow these steps:

1. Analyzing EWS Code: Analyze your code that uses EWS to determine which EWS features are used and their equivalents in Microsoft Graph.
2. Installing the Microsoft Graph SDK: Install the appropriate Microsoft Graph SDK for your application. SDKs are available for various platforms such as .NET, Java, Python, JavaScript.
3. Authentication and Authorization: Configure authentication and authorization methods for accessing Microsoft Graph. Using Azure Active Directory (Azure AD), you can ensure that your application securely accesses Microsoft Graph.
4. Converting EWS Code to Microsoft Graph Code: Rewrite your EWS code using the Microsoft Graph APIs. This step is the most time-consuming and requires the most attention.
5. Testing and Debugging: Thoroughly test your application that has been migrated to Microsoft Graph and debug any errors. By testing different scenarios and use cases, ensure that the application is working correctly.
6. Deployment: Publish your application that has been migrated to Microsoft Graph.

Example: Retrieving Email List (EWS vs. Microsoft Graph)

The following table compares retrieving an email list using EWS and Microsoft Graph:

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2013);
service.Credentials = new WebCredentials("[email protected]", "password");
service.Url = new Uri("https://mail.example.com/ews/exchange.asmx");

ItemView view = new ItemView(50);
FindItemsResults<Item> findResults = service.FindItems(WellKnownFolderName.Inbox, view);

foreach (Item item in findResults)
{
  Console.WriteLine(item.Subject);
}

GraphServiceClient graphClient = new GraphServiceClient(
    new DelegateAuthenticationProvider(
        async (requestMessage) => {
            // Authentication logic here (e.g., using MSAL)
            requestMessage.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
        }));

var messages = await graphClient.Me.Messages
    .Request()
    .GetAsync();

foreach (var message in messages)
{
    Console.WriteLine(message.Subject);
}

What are the Challenges of Migrating to Microsoft Graph?

The process of migrating to Microsoft Graph can involve some challenges. Here are some of the most common challenges:

• Learning Curve: Learning the Microsoft Graph APIs and SDKs can take time. Developers familiar with EWS may need to adapt to the different structure and concepts of Microsoft Graph.
• Code Conversion: Converting EWS code to Microsoft Graph code can be a challenging process, especially for complex applications. Some features in EWS may not have a direct equivalent in Microsoft Graph, and alternative solutions may need to be found.
• Authentication and Authorization: Configuring the correct authentication and authorization methods is important for accessing Microsoft Graph. Integration with Azure AD and understanding the OAuth 2.0 protocol may be required.
• Permissions: Microsoft Graph may require more granular permissions than EWS. It is important to correctly identify and configure the permissions your application needs.
• Performance: Although Microsoft Graph offers better performance than EWS, misconfigured queries or excessive requests can negatively impact performance. To optimize performance, it is important to design queries carefully and limit requests.

How to Manage Microsoft Graph Permissions?

Microsoft Graph offers more granular permissions than EWS. This allows your application to access only the data it needs and increases security. Microsoft Graph permissions are divided into two main categories:

• Delegated Permissions: Used for applications acting on behalf of a user. The user grants the application permission to access specific data.
• Application Permissions: Used for applications acting on behalf of the application itself. An administrator grants the application permission to access specific data. These permissions are suitable for background processes or services that can run without user interaction.

You can follow these steps to manage permissions:

1. Application Registration: Register your application in the Azure Portal. During application registration, specify the permissions your application needs.
2. Requesting Permissions: Your application must request the necessary permissions from the user or administrator. For delegated permissions, permission must be requested from the user via a consent screen. For application permissions, consent must be granted by an administrator.
3. Managing Permissions: In the Azure Portal, you can view and manage your application's permissions. You can add or remove permissions as needed.

Example: Managing Permissions in the Azure Portal

1. Go to the Azure Portal (https://portal.azure.com).
2. Search for and select the "Azure Active Directory" service.
3. Go to the "App registrations" section.
4. Select your application from the list.
5. Go to the "API permissions" section.
6. You can add new permissions for your application by clicking the "Add a permission" button.
7. You can grant administrator consent for application permissions by clicking the "Grant admin consent" button.

Tips and Best Practices for Migrating to Microsoft Graph

Consider the following tips and best practices to facilitate the migration process to Microsoft Graph:

• Planning: Plan the migration process carefully. Identify which applications are using EWS, which EWS features are being used, and their equivalents in Microsoft Graph.
• Phased Migration: Perform the migration in phases. First, migrate non-critical applications or features to Microsoft Graph. This will help you identify potential issues and optimize the migration process.
• Testing: Thoroughly test applications migrated to Microsoft Graph. By testing different scenarios and use cases, ensure that the application is working correctly.
• Documentation: Review the official Microsoft Graph documentation and examples. Microsoft provides comprehensive documentation on Microsoft Graph APIs and SDKs.
• Community Support: Get support from the Microsoft Graph community. In Microsoft Graph forums and other online platforms, you can ask for help from other developers and share your experiences.
• Configure Permissions Correctly: Configure the minimum permissions your application needs. Unnecessary permissions can increase security risks.
• Error Handling: Handle errors returned from Microsoft Graph APIs correctly. By analyzing error codes and messages, you can identify and resolve issues.
• Optimize Performance: Use Microsoft Graph APIs efficiently. Optimize queries, limit requests, and use caching.

Real-Life Examples and Case Studies

Case Study 1: A Large Company's Migration from EWS to Microsoft Graph

A large company had various applications that used EWS for email management, calendar synchronization, and contact management. After Microsoft announced plans to remove EWS, the company launched a project to migrate to Microsoft Graph. The project team analyzed all applications using EWS and identified their equivalents in Microsoft Graph. They then migrated the applications to Microsoft Graph in phases. During the migration process, they encountered authentication and authorization issues, but they resolved these issues by configuring integration with Azure AD. After the migration was complete, the performance of the applications increased and new features were added. The company benefited from the security and modernization advantages offered by Microsoft Graph.

Case Study 2: A Small Business's Migration from EWS to Microsoft Graph

A small business had an application using EWS for customer relationship management (CRM). For migration to Microsoft Graph, the business worked with a consulting firm. The consulting firm analyzed the EWS code and rewrote it using Microsoft Graph APIs. During the migration process, they encountered issues with permissions, but they resolved these issues by reviewing Microsoft Graph's documentation and getting support from the community. After the migration was complete, the application's security increased and it became better integrated with the Microsoft 365 ecosystem. The business continued to improve its CRM application by taking advantage of the modern APIs offered by Microsoft Graph.

Summary Table: EWS vs. Microsoft Graph Comparison

The following table provides a comparison of the key features of EWS and Microsoft Graph:

Important Note: This article is intended as a general guide. Depending on the specific requirements and complexity of your application, the migration process may vary. It is important to review Microsoft's official documentation and examples, and to seek support from experts when needed.