Microsoft
Microsoft Graph
Microsoft
This article describes known issues with Microsoft Graph. For information about the latest updates, see the Microsoft Graph changelog.
Users can be created immediately through a POST on the user entity. An Office 365 license must first be assigned to a user, in order to get access to Office 365 services. Even then, due to the distributed nature of the service, it might take 15 minutes before files, messages and events entities are available for use for this user, through the Microsoft Graph API. During this time, apps will receive a 404 HTTP error response.
Reading and updating a user's profile photo is only possible if the user has a mailbox. Additionally, any photos that may have been previously stored using the thumbnailPhoto property (using the Office 365 unified API preview, or the Azure AD Graph, or through AD Connect synchronization) are no longer accessible through the Microsoft Graph photo property of the user resource. Failure to read or update a photo, in this case, would result in the following error:
{
"error": {
"code": "ErrorNonExistentMailbox",
"message": "The SMTP address has no mailbox associated with it."
}
}
For known issues using delta query, see the delta query section in this article.
Note Microsoft Teams is currently in preview and is available only in the Microsoft Graph beta endpoint.
Using Microsoft Graph to create and name an Office 365 group bypasses any Office 365 group policies that are configured through Outlook Web App.
Microsoft Graph exposes two permission (Group.Read.All and Group.ReadWrite.All) for access to the APIs for groups and Microsoft Teams. These permission must be consented to by an administrator (which is a change from preview). In the future, we plan to add new permissions for groups and teams that users can consent to.
Also, only the API for core group administration and management supports access using delegated or app-only permissions. All other features of the group API support only delegated permissions.
Examples of group features that support delegated and app-only permissions:
Examples of group features that support only delegated permissions:
Microsoft Teams and Office 365 groups share similar functionality. All group APIs can be used with teams, with the exception that the Create group API does not currently allow you to create a team. Future API releases will support this.
Currently, you can read and create channels, but you cannot update or delete them. Future API releases will support this.
Currently, you can create chat threads in channels, but you cannot read existing chat threads or add replies to them. Also, you cannot read or write direct chats between users that are outside the scope of a team or channel. Future API releases will add additional capabilities in this area.
Adding attachments to group posts, listing and
getting attachments of group posts currently return the error message "The OData request is not supported." A fix has been rolled out for both the /v1.0 and /beta versions,
and is expected to be widely available by the end of January 2016.
There is currently an issue that prevents setting the allowExternalSenders property of a group in a POST or PATCH operation, in both /v1.0 and /beta.
For known issues using delta query, see the delta query section in this article.
Currently, there is partial support for a calendar based on an Internet Calendar Subscription (ICS):
When attempting to access events in a calendar that has been shared by another user using the following operation:
GET \users('{id}')\calendars('{id}')\events
You may get HTTP 500 with the error code ErrorInternalServerTransientError.
Historically, there are two ways that calendar sharing has been implemented, which, for the purpose of differentiating them, are referred to as the "old" implementation and "new" implementation. The error occurs because:
To work around this, the calendar owner should re-share the calendar in Outlook on the web, Outlook on iOS, or Outlook on Android, and you should re-accept the calendar using Outlook on the web. After re-accepting, one way to verify if the calendar has been shared using the new model is to successfully view the shared calendar in Outlook on iOS or Outlook on Android.
A calendar shared with you in the new way appears as just another calendar in your mailbox. You can use the calendar REST API to view or edit events in the shared calendar, as if it's your own calendar. As an example:
GET \me\calendars('{id}')\events
Only personal contacts are currently supported. Organizational contacts are not currently supported in /v1.0, but can be found in /beta.
In the /v1.0 version, GET /me/contactFolders does not include the user's default contacts folder.
A fix will be made available. Meanwhile, you can use the following list contacts query and the parentFolderId property as a workaround to get the folder ID of the default contacts folder:
GET https://graph.microsoft.com/v1.0/me/contacts?$top=1&$select=parentFolderId
In the above query:
/me/contacts?$top=1 gets the properties of a contact in the default contacts folder.&$select=parentFolderId returns only the contact's parentFolderId property, which is the ID of the default contacts folder.In the /beta version, there is currently an issue that prevents accessing a contact
by specifying its parent folder in the REST request URL, as shown in the 2 scenarios below.
GET /me/contactfolders/{id}/contacts/{id}
GET /users/{id | userPrincipalName}/contactfolders/{id}/contacts/{id}
GET /me/contactFolder/{id}/childFolders/{id}/.../contacts/{id}
GET /users/{id | userPrincipalName}/contactFolders/{id}/childFolders/{id}/contacts/{id}
As an alternative, you can simply get the contact by specifying its ID as shown below,
since GET /contacts in the /beta version applies to all the contacts in the user's mailbox:
GET /me/contacts/{id}
GET /users/{id | userPrincipalName}/contacts/{id}
The comment parameter for creating a reply or forward draft (createReply, createReplyAll, createForward) does not become part of the body of the resultant message draft.
nextLink$ref and casting is not supported on users, groups, devices, service principals and applications.@odata.bind is not supported. This means that developers won’t be able to properly set the Accepted or RejectedSenders on a group.@odata.id is not present on non-containment navigations (like messages) when using minimal metadataThere are changes to the application and servicePrincipal entities currently in development. The following is a summary of current limitations and in-development API features.
Current limitations:
In development:
Change tracking (delta query) is not supported for open or schema extension properties.
You cannot specify an open extension at the same time you create an instance of administrativeUnit, device, group, organization or user. You must first create the instance and then specify the open extension data in a subsequent POST request on that instance.
Directory resources, such as device, group and user, currently limit the total number of schema extension property values that can be set on a resource instance, to 100.
JSON batch requests must not contain any nested batch requests.
All requests contained in a batch request must be executed synchronously. If present, the respond-async preference will be ignored.
Microsoft Graph does not currently support transactional processing of individual requests. The atomicityGroup property on individual requests will be ignored.
Always specify relative URIs in batch requests. Microsoft Graph then makes these URLs absolute by using the version endpoint included in the batch URL.
JSON batch requests are currently limited to 5 individual requests. As JSON batching matures, this limit will be raised.
Individual requests can depend on other individual requests. Currently, requests can only depend on a single other request, and must follow one of these three patterns:
dependsOn property.dependsOn property, state the same dependency.As JSON batching matures, these limitations will be removed.
Cloud solution provider (CSP) apps must acquire tokens from the Azure AD (v1) endpoints to successfully call Microsoft Graph in their partner-managed customers. Currently, acquiring a token through the newer Azure AD v2.0 endpoint is not supported.
Under certain circumstances, pre-consent for CSP apps may not work for some of your customer tenants.
AADSTS50000: There was an error issuing a token.We are working to fix this issue as soon as possible, so that pre-consent will work for all your customer tenants.
In the meantime, to unblock development and testing you can use the following workaround.
NOTE: This is not a permanent solution and is only intended to unblock development. This workaround will not be required once the aforementioned issue is fixed. This workaround does not need to be undone once the fix is in place.
customer tenant by entering your admin credentials into the sign-in window. You can download and install Azure AD PowerShell V2 from here. Connect-AzureAd -TenantId {customerTenantIdOrDomainName}
New-AzureADServicePrincipal -AppId 00000003-0000-0000-c000-000000000000
Some functionality is not yet available in Microsoft Graph. If you don't see the functionality you're looking for, you can use the endpoint-specific Office 365 REST APIs. For Azure Active Directory, please refer to the Microsoft Graph or Azure AD Graph blog post on the features that are only available through Azure AD Graph API.
Your feedback is important to us. Connect with us on Stack Overflow.