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.
17 thoughts on “Exchange API permissions missing”
thanks for the article and help!
i was just confused why i didnt find any option… oh dear microsoft
Awesome – never would have guessed this !
Great article, great help. This article immediately helped me
Thank you, very lucky I found this! Having to enter the full name into the search box instead of just “exchange”, what a gotcha!
This saved my life. Thanks!
I really thought the EWS API was gone until I found this article, which clearly told me my old EWS app (daemon) had a chance to live futher and do it’s job. Thanks for writing this good and clear article.
Thank you very much. Helped me a lot!
Thanks for this, very helpful!
Still working! Thanks 🙂
Thank you! Veeam Backup for Microsoft Office 365 broke after upgrading to v5 and was asking for “full_access_as_app” which I couldn’t find until I found this article. Thanks again!
THANK YOU! 🙂
Thanks for this article. I’ve been playing with EWS recently and I’ve noticed something odd around the EWS delegated permission – that is, I’m seeing it under the Microsoft Graph API, in the AAD portal. Access tokens that I acquire using the MS Graph scope (just scope=Ews.AccessAsUser.All work just fine (for example with EWS Managed API against EXO). However, if I try to actually proactively add the permission through the portal, it fails with this error:
“Unable to save changes. One or more of the following permission(s) are currently not supported: EWS.AccessAsUser.All. Please remove these permission(s) and retry your request. [WZnij+BFQnQ3ORQ68Zt8Aj]”
If I add it the way you’ve described in this article, works fine. In the end it doesn’t really matter since I have multiple options that work perfectly:
A) App-Only, add the permission using the app’s manifest as described in the article you linked.
B) App-Only/Delegated, add the permissions folllowing the approach you’ve described here.
C) Delegated, request the MS Graph API permission ‘Ews.AccessAsUser.All’ on the fly in the access token request itself.
Just strange that the EWS permissions are scattered all over the place (i.e. delegated permissions in both the MS Graph API and the Office 365 Exchange Online API, and the application permission solely available via the manifest or the way you’ve descbied). Leaves a lot to wonder about.