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.
Related
I am trying to get all the chat messages for a specific chat id using this graph method - https://learn.microsoft.com/en-us/graph/api/chat-list-message?view=graph-rest-beta&tabs=http
I am able to get top 50 but when i try to use odata.nextlink i am getting Bad Request error.
Tried through Postman and Tried through TypeScript
I have just tested it and it seems like this issue has been resolved. The MS Graph team confirmed that they were able to reproduce the issue and it's working again now for me at least.
Github ticket: https://github.com/microsoftgraph/microsoft-graph-docs/issues/9729
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.
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 have been using Google API Client (gapi.auth.authorize) to handle oAuth and it has been working for months until last night. It started with an error saying something like "_.Uu is not a function" last night, and this morning the api URL becomes inaccessible completely (returning 404):
https://apis.google.com//scs/apps-static//js/k=oz.gapi.en_US.wLUinxMaFvQ.O/m=/exm=client/rt=j/sv=1/d=1/ed=1/am=IQ/rs=AItRSTNDbsyHH46eCqa0_JZmh883Ddz23Q/cb=gapi.loaded_1
Is anyone seeing the same problem? Not sure if Google is making any changes.
I had the same problem.
You need to update the client library and then it will work fine.
The same issue is being discussed on another question. It appears that Google knows about it and is working on it.
While I was following the guide http://msdn.microsoft.com/en-us/library/vstudio/jj920163.aspx to add Bugs to the task board I ran into an unexpected issue.
Adding the fields to the WIT was successful but when I started adding the form fields I received a very strange error:
Failed to save the 'Bug' Work Item Type to the server. Please contact
your administrator. There was an error contacting the server.
Technical information (for administrator): HTTP code 200: OK
Now I played around trying to find what field was causing the error... I tried every field seperatly and when added seperately they worked, then I tried adding them in pairs, this worked as well, then I tried adding all of them and even this worked!
BUT: When I try to add all of them in a clean group and column I get the error!
This leads me to believe there is some sort of maximum amount of elements in the layout form of a WIT? For now we have left all the fields added to another category but I wanted to ask if someone else had run into this issue and if there is a solution for this?
Since these are all stored as columns in a SQL Server table, the maximum you can add is 1024 (less the TFS standard, which might be around 33 columns?)
If you think this is the problem, check the Tfs_Warehouse..DimWorkItem table and see if you exceed the maximum.
Any chance you can get more information from the event viewer log on the app server, or provide more information about your bug? That message isn't very useful.
For reference -
http://blogs.msdn.com/b/eugenez/archive/2009/05/07/work-item-customization-tidbits-limits-of-complexity-part-13-of-x.aspx
Today we figured out what was going on by using fiddler and more closely monitoring the exchange between Visual Studio and our TFS server. Apparently the request was hitting the Application Firewall that was installed on the TFS server. This is the reason why you receive the vague error HTTP code 200: OK. The Application Firewall replies with a plain HTML page containing a blocked request ID (so you can pass it to your system admin). Once we passed this ID on to our networking team and they adapted the rules there was no longer an issue.
I hope this helps anyone who unexpectedly runs into an Application Firewall on your TFS server like I did.