Microsoft's latest efforts to modernize its technology stack across its cloud services will require administrators who use -- or plan to use -- Exchange Online to be aware of the approaching changes and adapt if necessary.
Microsoft's rapid development pace, particularly with its various cloud services, means for every new feature, there are some that will fall by the wayside. These changes affect the administrators and third-party vendors that have developed applications that integrate with Exchange, especially when key components disappear.
Microsoft removed Unified Messaging from its latest Exchange Server release. Now, organizations that require Exchange Web Services in the cloud-based Exchange Online must adjust to the imminent removal of that functionality.
The only constant for Exchange admins is change
It's been a particularly challenging last few years for Exchange administrators. In July 2017, Microsoft announced it would end support for the session border controllers that connected third-party, on-premises private branch exchanges (PBX) to Exchange Online Unified Messaging. This forced many administrators to rush and re-evaluate their existing PBX systems to see if they were compatible with the new APIs.
Customer feedback prompted Microsoft to change the end-of-support date from July 2018 to December 2019. Then, in July 2018, Microsoft dropped Unified Messaging out of Exchange Server 2019 to steer users to Azure Voicemail.
Now there's another significant change on the horizon for Exchange admins that affects the way third-party applications interact with Exchange Online. In July 2018, Microsoft announced it will no longer develop new enhancements for or feature updates to Exchange Web Services.
A blog post from Microsoft said the company wants to move developers from the less-secure basic authentication in Exchange Web Services to the more secure OAuth 2.0 used in Microsoft Graph. Microsoft said users of on-premises Exchange can continue to use the API.
How the Exchange Web Services API change might affect you
Microsoft introduced Exchange Web Services as part of Exchange 2007. Exchange Web Services is a Simple Object Access Protocol-based API that provides access to data within Exchange Online and on-premises Exchange Server.
In-house developers and third-party programmers use Exchange Web Services for read and write permission to Exchange. The API allows applications to integrate and interact with Exchange and its objects and functions, such as tasks, calendars, email and contacts.
As many organizations move to Office 365 and Exchange Online, companies that used Exchange Web Services in the on-premises Exchange system welcomed its availability in Exchange Online. But Microsoft's change means any customized integration used by in-house and third-party apps will be lost.
How Microsoft Graph differs from the Exchange Web Services API
Microsoft wants coders to interact with not only Exchange Online, but all the other workloads in the Office 365 stack and a number of its other offerings. As the name indicates, Exchange Web Services is limited to Exchange.
Microsoft set an Oct. 13, 2020, deadline for those administrators with third-party tools that rely on Exchange Web Services for Office 365 integration to switch to Microsoft Graph.
Microsoft Graph provides developers with a unified programmability model to access data across a number of products, including Office 365 services, Enterprise Mobility + Security, Windows 10 and Azure Active Directory.
While Microsoft Graph significantly expands the possibilities for developers who need integration capabilities with Exchange in the newer API model, the decision might require Exchange administrators to re-evaluate some of the third-party products they use with Office 365.
Depending on a cloud service means pros and cons
Microsoft set an Oct. 13, 2020, deadline for those administrators with third-party tools that rely on Exchange Web Services for Office 365 integration to switch to Microsoft Graph.
Moving to a cloud service like Office 365 offers a few management perks for IT, but one of the challenges is losing the ability to stay with a particular version. Administrators who are using Exchange Online or who plan to move to the Microsoft-hosted email service now have to identify the presence of Exchange Web Services in their customized apps and third-party add-ons.
Exchange administrators will need to gather an inventory of affected integrations that rely on Exchange Web Services for data connectivity. If the organization wants to carry those add-ons over to Exchange Online, then Exchange administrators need to determine if the vendor plans to deliver an upgrade that implements Microsoft Graph.
A cmdlet helps detect Exchange Web Services usage
The PowerShell cmdlet Search-AdminAuditLog can help determine which products use Exchange Web Services. Administrators can set parameters, such as end users and date range, to narrow the results. The resulting log shows the list of events, such as mailbox access by users or services, which can include Exchange Web Services. Administrators can also review the event logs in the EWS folder -- \ExchangeInstallationFolder\V15\Logging\EWS -- which capture all the requests performed against EWS with details on where the calls originated.
Dig Deeper on Microsoft messaging and collaboration
