Whenever I query the Teams endpoint in Microsoft Graph:
GET https://graph.microsoft.com/beta/teams/{id}
I get the following error:
AccessDenied - Failed to execute Skype backend request GetThreadRequest.
The permissions are set according to the documentation. (Group.Read.All - delegated permission)
Querying https://graph.microsoft.com/beta/groups/{id} is working while with the same access token https://graph.microsoft.com/beta/teams/{id} isn't.
I tried it with my own application and in the Graph Explorer. Both ways didnt't work for me. However using Graph Explorer with the sample account is working. Is there maybe another permission needed which is not yet documented?
Currently it's a requirement that the person using the Graph APIs (and the PowerShell cmdlets that use them under the covers) must be a member of the team whose information they are trying to retrieve. This is the second-most popular ask for users of our cmdlets, and we are close to resolving it. We expect this to be fixed by the end of September 2018, with write APIs/commands coming a few weeks later than read APIs/commands.
Related
I'd like to administer different tenants remotely using the Connect-MicrosoftTeams -AccessTokens option. From what I read, one needs to retrieve the token for the tenant through Microsoft Graph. What I do not understand is how and which permission to request.
Is there anyone who has done this and could point me to some documentation or maybe provide an example request? Thanks!
Use Graph Explorer to determine what are the APIs you want to use. On the “Modify Permissions (Preview)” Tab you will be able to see what kind of permissions are needed for that particular API.
https://developer.microsoft.com/en-us/graph/graph-explorer
See Microsoft Graph permissions reference, Authentication and authorization basics for Microsoft Graph, Authorization and the Microsoft Graph Security API
I am trying to get informations about user/mailbox type (regular, distribution list, shared mailbox, alias) using the Microsoft graph API. I tried using the /users endpoint but I see there is no field with such info. Is there any way of doing this?
https://learn.microsoft.com/en-us/graph/api/user-list?view=graph-rest-1.0&tabs=http
Thanks!
That information is only available from Exchange PowerShell (Get-Mailbox), which isn't yet available via Graph. You can get a list of groups (https://learn.microsoft.com/en-us/graph/api/group-list?view=graph-rest-1.0&tabs=http) and a list of users (https://learn.microsoft.com/en-us/graph/api/user-list?view=graph-rest-1.0&tabs=http). I don't know if that will work for your purposes.
I'm trying to extract the share permissions for a Calendar through Microsoft Graph (or even the old Outlook REST API) but it seems that there is no Graph endpoint to get a calendar's sharing permissions.
When fetching a calendar's details, the closest I found was isShared on the Calendar resource - but that doesn't give me the full data I see from the Web UI:
Basically, trying to receive the equivalent of Google Calendar's ACL list.
Am I missing anything?
Since you cannot share the calendar through the graph api, or open a calendar from some other user that they shared with you, there is no point in showing the ACL.
You might have better luck using the Exchange Web Service (or EWS) they do have those properties on folders. https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/folders-and-items-in-ews-in-exchange
Or if you really need it in the graph api (since the EWS is no longer the recommended way to talk to Office 365) you can create a ticket on UserVoice (if it doesn't exist already).
We're building a mashup app that allows you to view data and information from multiple sources in one place.
To do this we need to get all conversations in O365 Groups and have been exploring how to build a daemon job.
According to the documentation this should be supported since we have the permissions Group.Read.All and Group.ReadWrite.All.
However it seems like Groups Conversations is an exception to what you can read with an application permission with Microsoft Graph which is mentioned in a small note on the subscriptions page:
We get permissions errors when calling the API with a application permission using a certificate (fetching groups and other data works fine) so this seems to be a limitation.
This also seems to affect fetching threads which doesn't seem to have any notes regarding application permissions at all since we can't fetch those either.
Does anybody know if there is a workaround or if we're doing something wrong here?
(NOTE: This seems to be a related question: Microsoft Graph API : "403 forbidden" error when getting groups conversations but I'd like to have some input from Microsoft on this)
Microsoft confirmed this as being an issue in the Microsoft Graph through our partner programme.
Until fixed by Microsoft this means that there is no good solution except workarounds as of now.
I'm trying to use delta queries on my AD and it works perfectly when I try them out through Graph Explorer, but doesn't work at all with my app, I'm getting this:
message=Invalid request. Delta query is not supported by this resource.
My app is an 'old' app, meaning it was registered in Azure to work with old WAAD graph api. Is this why it's not working? Or could this be because of my app lacking some permission that Graph Explorer requires? I can read 'users' without any issues, it's only delta queries I'm having issues with.
The application requests the following permissions:
Access the directory as the signed-in user
Read all users' basic profiles
Sign in and read user profile
Token requests are managed by the library, it's asking for the following scopes: openid profile
If you're using Azure AD Graph then you cannot use /delta queries. AAD Graph API and Microsoft Graph API are entirely distinct APIs. Calls to one are not interchangeable with the other.
If you're looking to leverage /delta you'll have to refactor your application to use Microsoft Graph API.
Had to spend the whole day on this issue, here's what was going on. I was adding this HTTP header to the request (per some sample documentation):
Prefer: outlook.timezone="E. Europe Standard Time"
And that's what was breaking the delta queries request, as soon as I've removed the header - request returned delta data instead of an error. I wish the error could be more descriptive, I wouldn't have to spend so much time figuring this out.