GET <https://graph.microsoft.com/v1.0/users?$select=id,mail,displayname>
the above request is working.
but
GET <https://graph.microsoft.com/v1.0/users?$select=id,mail,displayname,onPremisesSyncEnabled>
this request is getting timed out.
Any idea why this is happening?
This is not a question we can answer you because of the differences in the network environment and the operating platform.
I have tested your two request in Microsoft Graph Explorer and both of them work fine.
So I think other people's test results have no reference value to you.
You should open a support ticket to Azure support team and provide your request id for further investigation.
Related
Our setup is an on-premise Exchange Server which is accessible over the graph api. https://learn.microsoft.com/en-us/graph/hybrid-rest-support
We run in the issue, that our token is only "partial" working. And a token created by "Graph-Playground" is fully working. But we can't find any difference.
When I use Graph-Playground or use the token generated by Graph-Playground => all requests are working
When I create a token (over my app registration) => only some requests are working
The token seems to be valid some calls like /me are working, but all calls related to exchange like /me/contacts are failing with this error
Request, they work with token generated by Postman:**
Error:
{ "error": { "code": "MailboxNotEnabledForRESTAPI", "message": "REST API is not yet supported for this mailbox." } }
(that's a very generic error, and mostly don't say anything about the real issue)
Token Generation:
I create my token on the same way as Graph-Playground create the token (OAuth - Implicit flow):
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=token&state=test2&client_id=????&scope=openid%20profile%20User.Read%20email%20Contacts.Read&redirect_uri=????
Token - Analysis:
As a side note, it was working for a few days, nobody changed anything :)
So I have no idea, why the "Graph Playground" can create a working token, and my token only "partially" works. Can you help me?
There is already a thread, but I'm not the owner of it. Also there are no more responses... I can't provide a bounty for a foreign thread, that's why I create a new thread. You can find it here:
MailboxNotEnabledForRESTAPI - Microsoft Graph API integration with HMA Enabled on-premise server
I recognize your error, we see it in several cases (for Office 365):
User has no Exchange license (probably not the case, since it works in the explorer).
Customer tenant has setup additional security.
You can limit applications to certain mailboxes. Maybe there is some kind of setting or policy like this on your local Exchange as well, you have to connect to Exchange Online Powershell to set it, so maybe you can find something there. This is just a wild guess.
To track down this issue I would start checking the local Exchange logs.
Have you tried using the /users/{upn}/calendar endpoint? Maybe it's just that the /me/ part doesn't work.
Using
`https://graph.microsoft.com/beta/users/${email}/photo/$value`
had been working for me last week but now it throws a 400 error
Error Output
"Mailbox is hosted by an on-premise or non-Exchange server, which is not supported."
As far as I know nothing has changed from our end. Using the v1.0 doesn't seem to make any difference. I think the user photos are stored on an on-premise exchange but are then synced up at AAD. This has been working fine for at least a year like this.
Anybody know if anything has changed in the last few days? Any documented solutions to this?
Exchange Online team was trying to clean up some error codes and such they changed MailboxNotEnabledForRestAPI with HttpStatus code 404 to MailboxNotHostedInExchangeOnline with HttpStauts code 400. This was un-intended and such we have since reverted this change, and are rolling out the fixes to prod with urgency.
We have two jira installations at our company. One that we use for our projects and a second one for testing purposes.
I'm working in a project that needs to use the JIRA REST API. For this purpose I'm connecting to our testing instance.
The problem is that while trying out the REST API, I keep getting 400 errors without a single explanation of what went wrong. I just get an HTML with
Your browser sent a request that this server could not understand
I was a bit desperate and decided to try it into our real JIRA. To my surpirse the same request gave me a different response:
{"errorMessages":[],"errors":{"project":"project is required"}}
In this case, I do get a meaningful error!
I replicated this easily. I would never get a meaningful error from the test instance, but the real one will always give me one.
I cannot keep trying out stuff in our productive JIRA, but I cannot easily continue working without getting meaningful errors. So, what could be wrong in the testing instance? I could not find any configuration about the 'verbosity' of the API responses.
I believe that this error is returned not by JIRA but rather by proxy web server that is part of you production configuration.
I suggest you to compare HTTP headers that are sent with working requests from your browser with headers you pass via curl. Googling for the "Your browser sent a request that this server could not understand" helps too
I am trying to create an OData model in SAP UI5 this way:
new sap.ui.model.odata.ODataModel("http://services.odata.org/Northwind/Northwind.svc/");
but I am getting a 501 not implemented error!
could you please check what's wrong?
Thanks
As far as I can see it, the service is not really CORS-enabled. I have the same problem with my own examples here, as soon as I am not using some kind of proxy, I get this error.
The reason behind it is that when you send a complex request to the service, you'll autmatically have a so-called preflight request sent by your browser (before the actual GET) which is not a GET-Request, but an HTTP OPTIONS request.
All the odata.org sample services return a 501 error at the moment for such requests.
You can e.g. use the simpleProxyServlet which is shipped with UI5, or of course any other proxy which would solve this.
You are getting this error as your browser will refuse this request due to same Origin Policy. Here is what you should do:
Deploy the app on the same server or domain as the service that you want to call, so that both resources are in the same origin (if possible)
Disable the same-origin policy in the browser for local testing. Run Chrome by running Chrome with the following command:
[your-path-to-chrome-installation-dir]\chrome.exe
--disable-web-security --user-data-dir. Make sure that all instances of Chrome are closed before you run the command. This allows all web
sites to break out of the same-origin policy and connect to the
remote service directly.
-> Don't do this in your productive app as it imposes a security risk.
Using a proxy
The following documentation should help you understand this more and implement:
Conncting with oData Service
Request failing due to Same-Origin Policy sharing(CORS)
Please use "proxy/http/services.odata.org/Northwind/Northwind.svc", I think it's solve your problem!
Whenever a web request is made by Visual Studio to TFS, Fiddler will show a 401 Unauthorized error. Visual Studio will then try again with a proper Authorization Negotiate header in place with which TFS will respond with the proper data and a 200 status code.
How can I get the correct headers to be sent the first time to stop the 401?
This is how the process of Windows Integrated Authentication (NTLM) works. NTLM is a connection based authentication mechanism and actually involves 3 calls to establish the authenticated session.
The TFS API then goes to extra-ordinary lengths to make sure that this handshake is done in the most efficient way possible. It will keep the authenticated connection open for a period of time to avoid this hand-shake where possible. It will also do the initial authentication using a HTTP payload with minimal content and then send the real message if the message you were going to send is over a certain length. It does a bunch of other tricks as well to optimise the connection to TFS.
Basically, I would just leave it alone as it works well.
You will see that a web browser also does this when communicating with a web site. It will always try to give away the minimum amount of detail with the first call. If this fails, it will reveal a little more about you.
This is by design and for a very good reason.
This is how it's always done - request, get the 401 back, then send the authorization. It's part of the authentication protocol for http.