I have an application which writes lots (millions) of calendar entries to mailboxes for large organisations. Occasionally, Office 365 EWS API will accept a batch of entries, return success (not error) codes, and the entries fail to make into mailboxes.
Microsoft support don't (appear to) have a public-facing API support team so the usual Microsoft support routes just say either "third-party application" or "we don't have a support team you can speak to" ... so I'm a bit stuck. This does not appear to be a failure of the app, as I can see from the trace that it writes successfully and is given a change key back. And this only happens over a short period of time (say, all writes in a 30 min window have this problem).
I'm a bit stuck as to where to go here, as there's no error, just occasional and undesirable behaviour. It could even not be the API that's at fault, and could be just a sync error between EWS and mailbox stores. But, as it's Office 365, I can't see this.
Application is .Net 3.5 if it helps; very stable installs, runs fine for years, just occasionally has this problem... with just one customer...
I'm a bit stuck as to where to go here, as there's no error, just occasional and undesirable behaviour. It could even not be the API that's at fault, and could be just a sync error between EWS and mailbox stores. But, as it's Office 365, I can't see this.
EWS is just an API to access the Mail Store there is no sync involved and no cache, if your getting an ItemId returned then it must at some point have been written to the Exchange Store. DAG's https://learn.microsoft.com/en-us/exchange/high-availability/database-availability-groups/database-availability-groups?view=exchserver-2019#:~:text=A%20DAG%20is%20a%20group,affect%20individual%20servers%20or%20databases.&text=For%20example%2C%20you%20can't,servers%20in%20the%20same%20DAG. are Exchanges way of ensuring redundancy.
How are you determining that the appointments aren't in the Mailbox (or haven't been deleted or modified by another mail client). Most likely it will be another mail client (eg the IOS client has been cause of many issue of the past years). I would suggest calendar logging or auditing maybe be useful to see what might be happening if you can reproduce the issue.
Related
I have a small website running on the "always free" tier. It's perfect for my needs. After my trial period ended (and I hadn't used any fee-based resoures), I reverted back to "always free." This is fine. This morning, I received an email which read, in part:
Your Always Free resources will remain available to you as long as you
actively use your account.
but doesn't define the meaning of "actively use your account." I would just chat online with someone, but that's not available to me. I tried to use their community forums, but their login seems busted, so I landed here. (No offense, but I was under the impression this is mostly for development questions.)
Is having a website running sufficient to qualify as "active use?" Do I need to login to the console periodically? No matter the use, what constitutes "active?" For example, if I am required to login the the console periodically, how often to I have to do that? Weekly? Monthly?
Based on the "Inactivity Monitoring and Database Stoppage" sections of the documentation, Always Free account activity works like this:
Oracle Autonomous Database: "Successfully making a SQL*Net or HTTPS connection resets these measurements to zero"
APEX: "Successfully making a HTTPS connection resets these measurements to zero."
COMPUTE and others: Unknown - I can't find the relevant documentation
Per the documentation, you get 7 days before the resource is automatically stopped, and then 90 days before the resource is permanently deleted.
Based on my experience with the database, you get a warning email after 7 days, and then 2 days later the resource is stopped. You get a warning email about permanent deletion after 60 days, and luckily I don't have experience with how long it takes for a resource to be permanently deleted.
We have a web application that occasionally receives web request that we detect as attempts to inject SQL code, from Google virtual servers (Compute Engine).
I was asked to find a way to identify who is responsible for said machines, so that we can take the corresponding legal actions on our part, or at least, confirm that Google shut down those servers.
What I need is to find a way to communicate with Google, by email or chat, but I haven't found information about it.
EDIT 1:
I have tried to communicate with Google to indicate the information I am looking for, but the only contact available in my case is with the billing department, which could not confirm that they will give me that information if I buy a technical assistance package. On the other hand, I understand that this package is to review requirements of the applications that you own, but in my case I am looking for legal information.
What was recommended to me was to enter the corresponding application in
https://support.google.com/code/contact/cloud_platform_report?hl=en
but I have not received a response for weeks.
I am disappointed in Google, especially because of the importance of computer security.
I will keep searching information.
You can find all information concerning Tech support, phone support and Chat support in your Google Cloud console. Also, this doc shows different supports based on your support role or package.
I am trying to download/access on daily basis, all the emails exchanged over outlook365 by employees of an organization, who obviously uses outlook365. After download finishes I'll be running some background jobs on these emails.
I've option of doing this via EWS APIs, but the throttling policies are turning out to be pain and affecting the predictability of the system, because of throttling policies. Daily no of emails to be accessed could range from 0.1- 1 million or above.
I am exploring upcoming graph as of now, to see if it helps solving this. I also have another way out by routing these emails to lets say AWS SES or apache james and accessing/downloading from there, thus avoiding throttling all together. But I am trying to avoid additional servers in deployment as of now.
My question -
Has anybody experienced this issue and what was if at all any reliable way around while using outlook supported email APIs?
I've option of doing this via EWS APIs, but the throttling policies are turning out to be pain and affecting the predictability of the system, because of throttling policies. Daily no of emails to be accessed could range from 0.1- 1 million or above.
Inefficiency code is more likely the cause of the throttling then blaming the API (eg if your not using batching, requesting more properties then you need etc) so the first thing you should do make sure you optimize the code as all the client based API's are throttling similarly. 0.1- 1 million over the time-span of day isn't that many emails to process in my experience with EWS especially if your using Impersonation where throttling cost would be dispersed across the mailboxes your accessing.
I am encountering some very long response times from Exchange Online called via the EWS Managed API 2.0 in C#. I suspect I am being throttled, but I cannot find anything that lets me prove this in the Admin portal for my O365 account. I have seen in some search results that using PowerShell you can see messages indicating "micro delays" have been applied, but I'm stuck in C#/EWS, so my question is: is there anything I can look at coming back in the responses to my EWS calls that can identify if these micro delays have been applied? BTW, response times are very close to the 100 second timeout time, which is killing my code.
Thx,
Paul
100 Seconds ins't a micro delay, micro-delays are milliseconds(capped at 500 ms) and are more aimed at delaying a large volume of requests. (eg if an app is going to may 100 sequential requests a microdelay would spread the load of those request out over a greater time by punishing the app more and more and that would lower the resource load on the server). One request taking 100 seconds to fulfill is probably more to do with the request itself. Eg overuse of search filters or overcomplex search etc which my also impact throttling or if your using batching each request withing the batch could have a micro-delay applied.
EWS doesn't return metrics of throttle usage (the new REST API does give a little more information back in this regards). What you need is access to the EWS logs which has that information. Each Exchange request the EWS Managed API makes has and Client Requestid to help correlate the request to log entry there more detail in https://msdn.microsoft.com/en-us/library/office/dn720380(v=exchg.150).aspx
We have received mail from Google mentioned that "It appears that your project is performing intrusion attempts against a third-party. We will suspend your project in 3 days unless you correct the problem by ensuring your project traffic directed at third-parties is expected, and that your project has not been compromised."
I have cross checked all my access/error log, Firewall ports,DDoS log, etc. I've not found any problem from server end. Has anyone faced same issue?. It's critical for my client project.pls help