How to Fix “Access to OData is disabled” when Calling Graph API

Microsoft Graph and Office 365 Unified API are widely used to make development based on Office 365, while when calling calendar related API, you may experience “Access to OData is disabled” failure shown below.

client-request-id: 4812d5c0-7a5d-4416-ae8b-5f9cefa873a5
content-type: application/json
cache-control: private
request-id: 4812d5c0-7a5d-4416-ae8b-5f9cefa873a5
Status Code: 403
  "error": {
    "code": "ErrorAccessDenied",
    "message": "Access to OData is disabled.",
    "innerError": {
        "request-id": "4812d5c0-7a5d-4416-ae8b-5f9cefa873a5",
        "date": "2017-03-16T09:28:02"

The error message is showing permission issue while doesn’t show much valuable information. If you experience this, try to check the EWS setting. Firstly, run the below PowerShell code to connect to the office 365 tenant.

$Pwd = ConvertTo-SecureString –String $Password –AsPlainText -Force
$userCredential = New-Object –TypeName "System.Management.Automation.PSCredential" –ArgumentList $Account,$Pwd
$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $userCredential -Authentication Basic –AllowRedirection
Import-PSSession $O365Session –AllowClobber -DisableNameChecking

After connecting to the tenant, run “Get-OrganizationConfig | select EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList”. If you observe the below output, congratulations, you find the root cause.


Basically, for Office 365, the web application to call the Graph API is EWS client application, the office 365 admin can configure access control for clients in the following ways:

  1. By blocking all client applications from connecting.
  2. By allowing specific client applications only to connect.
  3. By allowing any client application to connect except those that are specifically blocked.
  4. By allowing any client application to connect.

In the above output, we can see EwsApplicationAccessPolicy is set to EnforceAllowList which means only the applications (user agent strings) configured in EwsAllowList are able to access EWS. Because the EwsAllowList is empty, that means there is no application which is allowed to access EWS. Certainly, in your environment, the application can also be blocked if EwsApplicationAccessPolicy is EnforceBlockList, and the user agent string is in the EwsBlockList. Now, let’s run the below code to allow “Myoffice365DemoApp*” user agent to access EWS.


Accordingly, we need append the user agent string to the Graph API request. The following is a sample code for .Net

using (HttpClient client = new HttpClient()) 
    var accept = "application/json";
    client.DefaultRequestHeaders.Add("Accept", accept); 
    client.DefaultRequestHeaders.Add("User-Agent", "MyOffice365DemoApp/*"); 
    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
    using (var response = await client.GetAsync(restURL)) 
       if (response.IsSuccessStatusCode)
          var jsonresult = JObject.Parse(await response.Content.ReadAsStringAsync());
          foreach (var item in jsonresult["value"]) 
Now, we can see the API works. Because it will take some time for the above PowerShell command take effect for Office 365, you may wait for a while and try.


Lastly, in the above steps, we have called Get-OrganizationConfig to observe the rule applies to the whole organization. If there is no any finding here, please try Get-CASMailbox which only applies to a particular mailbox.

Comments (1)

  1. Jeff Lawrence says:

    Thanks for the tip – our config was set to only allow certain identifiers used by MS apps – changing my app to use one of these identifiers fixed it as a quick dev test (I realize spoofing another app is not a recommended practice). The MS samples should really include this line with a comment to ensure whatever value is used is allowed as EWS block lists are common in enterprise environments. Seems like there should be an option to “Allow EWS access to any appID which has the send mail graph perm”.. then the SDK could use the appid as the useragent and this would all be transparent.

Skip to main content