We have used MS Graph API(MSAL) in one SAP Ui5 Application and have implemented Mail api, Calender api and MailboxSetting apis so far. It was working fine till Nov 2020 (Last checked in Nov 30 2020).
Suddenly this application keeps throwing the error "{"error":{"code":"MailboxNotEnabledForRESTAPI","message":"REST API is not yet supported for this mailbox."}}".
Though we have not changed a single code or any changes has been done in Azure portal or in the envirmental set up.We do have a Hybrid envirment mailbox set up.
The strange thing is the same APIs are working in MS Graph Explorer but not from our custom Apps. But when we use the token generated by Graph Explorer, APIs works from our custom apps also.
We compared the both tokens using jwt.ms. Scopes and other attributes are the same. Only 'wids' attribute is not present in our custom App's Token(We are using Implicit Grant flow).
which flow do MS Graph Explorer use, so it works there ?(If Authorization
flow is the issue).
Is it that only Graph Explorer is allowed to make API calls to On-Premise
Mailbox and the custom applicationa are not?
Is there any other factor, we should consider to solve this ?
Thank You,
Arpita
This error happens when trying to access a mailbox that is not hosted in EXO. Check where your target mailbox is hosted and use auto discover to locate the right endpoint for that environment.
Related
Hi we have a system that already has a large userbase (100k+) of microsoft users which we push updates to, using the refresh token we have saved during their inital signup.
The REST APi will get deprecated on the 30th of November in favour of the Graph API. https://devblogs.microsoft.com/microsoft365dev/outlook-rest-api-v2-0-deprecation-notice
I have upgraded all API calls to the new graph api but am faced with the following error:
CompactToken parsing failed with error code: 8004920A
From further digging it seems like it is caused since the tokens are not interchangable between the two APIs:
https://learn.microsoft.com/en-us/answers/questions/1010061/migration-from-rest-to-graph-refreshed-token-throw.html
So is there a way to port these users into the new API without having them to go through the oauth flow again, since we don't have a functionality to request this from the users?
We were calling the token flow without the scope parameter, which was working fine with the DEPRECATED API. But with the new Graph API, we had to add the relevant scope query param, and the returned token worked with the new API calls. Hope this helps someone.
Also related, the Exchange Team has published on Nov 23, 2022 that the decommissioning has been pushed to 2023, and that they will give a 6 month notice prior to the actual decommission date.
https://techcommunity.microsoft.com/t5/exchange-team-blog/outlook-rest-api-v2-0-and-beta-deprecation-update/ba-p/3682745
I am attempting to use "v1.0/me/joinedTeams" to get all the joined teams for the currently authenticated user in my asp.net service. This works fine for external accounts that use a Microsoft identity (have a live account) but the same call returns a 400 Bad Request when I attempt to use an external account that uses a mail identity (no live account). The request is the same regardless of external account type. The token generated when authenticating as the mail identity external user looks correct when I inspect it.
I have been able to implement a workaround where I instead use the SharePoint REST service to get the groupId for the team site the user is apart of and then use the Graph call "v1.0/teams/{groupId}" to get that team. However, I need to do this for all the teams the external user has access to which slows things down quiet a bit.
I am aware of what looks like a bug in Graph when trying to make any Graph calls with any external user type, described here: https://github.com/OneDrive/onedrive-api-docs/issues/1039. I have also implemented the workaround for this issue which requires first accessing each site the user has access to by making some arbitrary call using the REST service. Then any subsequent calls using Graph should work. I do this for external accounts with a mail identity before trying to make the joinedTeams call but still run into the 400 response.
These workarounds will suffice in the short term but they increase my execution time significantly, especially when there is a large number of teams the external user is apart of. Any insight on a solution is greatly appreciated.
/me/joinedTeams is not available for personal Microsoft accounts. Se the table on this page
We've been trying to download the bytes of hosted content attachments embedded in Team messages using the Microsoft Graph, but we encounter HTTP 403 Forbidden errors. It happens when the authenticated user becomes a member of an existing team using the Graph, then uses the GET chatMessageHostedContent beta API on a hosted content attachment.
These are the reproduction steps:
In the Teams browser or desktop application:
Log in to your Office 365 tenant using a licenced user A,
Create a new public team,
In this team, create a new public channel,
In this channel, create many hosted content attachments in multiple messages: copy-pasted images using the Snipping Tool, code snippets.
In the Microsoft Graph Explorer or any C# application that uses the Microsoft Graph Beta nuget package:
Log in using to the same tenant, but as another user B, who is at least Teams Administrator and SharePoint Administrator
Add this user as a member of new newly created team
Get all the messages
Download the bytes of all hosted content attachments
You will get HTTP 403 Forbidden errors on all hosted content attachments downloads.
There is a way to make it work, but it involves "manual work" that cannot be done programmatically:
As user B, open the channel in the Teams application UI (in Fiddler, we see HTTP 403 but at some point it starts to work)
Or, instead of joining the group using the Graph, still as user B, join the team using the Teams application UI
Each of these two solutions seems to trigger a permission synchronization process that cannot be done using the Graph only. Once they're done, downloading the hosted content bytes using the Graph works.
We also noticed that we don't get HTTP 403 for hosted content embedded in the General primary channel for some reason.
Is there anything we've missed?
My team was facing this same issue and ended up rectifying it by switching from delegated permissions on a service account to using application permissions.
At the time of writing this the Get hosted content api is a protected API and required approval to use. More info: https://learn.microsoft.com/en-us/graph/teams-protected-apis
The new Microsoft Graph Security API should return data from different security providers, for now, Azure AD Identity Protection and Azure Security Center.
But https://graph.microsoft.com/beta/security/alerts is not returning any data (value: []).
We've tested the /security/alerts API from 2 different tenants. In both tenants, we have Azure AD Identity Protection and Azure Security Center Alerts. We can see those alerts from their respective blades in Azure Portal but /beta/security/alerts returns:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#Security/alerts",
"value": []
}
We're authenticated with proper permissions. We've tried it from the Graph Explorer and from both c# samples (desktop and asp.net)
Any ideas?
Graph Explorer will not work at present for the Security API unless you don't login. In that case you will get the demo data. If you do login you should see 'unauthorized' (not and empty set). Graph Explorer currently does not ask for the permissions needed to access the Security API.
That aside, if you are using your own code as you indicated, you should be seeing any alerts you see in the portal, as long as they are newer than 30 days old. The Security API will only return alerts up to 30 days old for these two products right now.
So, if you have alerts newer than 30 days, and still are getting an empty set returned, then there may be an issue we'd like to look into. Please reply with your Directory ID. This GUID can be found looking in the Azure Portal under Active Directory Properties. Using this we can search for any ASC and AADIP alerts for your tenant that should be showing up from the API.
MS got in touch with me and solved the issue:
https://techcommunity.microsoft.com/t5/Using-Microsoft-Graph-Security/https-graph-microsoft-com-beta-security-alerts-Not-returning-any/m-p/191898#M5
Also thanks #jwes (also MS) for your assistance.
We are developing a web application using Microsoft Graph, where the signed in user can, Export all the calendar events to a third party calendar Application. After this initial export, we need to keep the exported data in sync with calendar changes via service app (a scheduled task running on server). This need to be a multi tenant application, as people from different organizations should be able to use this service.
Right now we did the authentication using OAuth 2.0 and OpenID Connect as described in this sample. Later we understood that the access token we get using this method cannot be used in the service app without user interaction. Considering our scenario what is the best way to achieve this?
I have read about App-only authorization method to do this. If we use this authentication method, the app need to be consented by a tenant administrator and the these applications are quite powerful in terms of what data they can access in the Office 365 organization. Considering we are developing a product used by different organizations, will it be feasible to use this method?
To use the client credentials OAuth2.0 flow (aka "App-only" or service account access depending on who's documentation you're reading) the admin for each tenancy will need to specify which scopes your daemon process can have for users in their tenancy. The end users can't give these scoping rights to your code themselves (as far as I know at least).
One thing to watch out for is that currently Graph API doesn't allow you to mess about with calendars that are attached to Office 365 Groups if you're using the client credentials flow. This is a pain for us, so we've raised it as an issue that needs fixing in the Office 365 feedback system. if that's an issue for you or anyone else, please throw a few votes at it so that it gets more attention at Microsoft. :-)