Few days back, Microsoft announced deprecation of v2.0 Outlook REST API. Important detail was omitted from that article though, and only added to the republished post over at the EHLO blog. Here is the changed paragraph:
Going forward, we will not be making any further investments in the capabilities or capacity of the Outlook REST API beta or Outlook REST API v2.0. This will result in two changes for developers. First, we will retire the OAuth Sandbox by December 31, 2020. Additionally, we have removed the “Exchange” app permission from the Azure portal. We have updated our documentation with additional information regarding creation of EWS apps.
The bolded part in particular is what’s most relevant to the Exchange crowd out there, as it relates to the way we grant permissions for any EWS OAuth-based app, as well as for enabling certificate-based authentication for the Exchange Online V2 PowerShell module.
Note that this doesn’t mean that the aforementioned functionalities are no longer available. It simply makes the process of adding the necessary permissions a bit more convoluted. And as the relevant documentation articles still use the “old” instructions (at least the V2 PowerShell module ones do), I figured it might be beneficial to publish a quick “how to”, reflecting these recent changes. So here goes.
Follow the instructions up to the point where you need to add the necessary API permissions, all the earlier steps should be the same. Once you end up on the API permissions page in the Azure AD blade, you will notice that at the bottom of the Request API permissions pane you will only see a single entry under Supported Legacy APIs. Where previously you would find both Azure AD Graph API and Exchange (as depicted on the top section below), now only the former is visible (bottom):
Instead, to add the relevant permissions you now need to go back to the top of the Request API permissions pane, click the APIs my organization uses tab and search for Office 365 Exchange Online. Note that searching for just Exchange will not yield any results, as the search functionality in Azure AD blade remains quite poor.
Once you locate the Office 365 Exchange Online entry, click on it and proceed with adding the necessary permissions. The steps from here on remain the same, so in most cases you would need the Application permissions entry, and the relevant set of permissions therein (such as full_access_as_app for EWS OAuth, Exchange.ManageAsApp for CBA). Select the relevant entries, hit the Add permissions button and consent to the changes as needed, and you’re good to go. The mystery of the missing Exchange API permissions is solved!
An alternative approach to achieve the same task is outlined in the documentation article cited in the blog post above. This involves modifying the manifest of your Azure AD application, which can be a bit of annoyance thanks to the JSON format used. Personally, I’d stick to using the UI method outlined in this article, unless Microsoft decides to totally disable this approach.