When working with pull subscriptions to Office365 calendar folders, I've been getting a lot of ErrorReadEventsFailed messages in the SendNotification request. This error essentially means that the subscription can no longer be found, and the server should no longer expect new notifications.
Checking Microsoft's recommended error handling, the solution is to use Autodiscover to rediscover the ExternalEwsUrl or EwsPartnerUrl, and create a new subscription.
With Office365, the AutoDiscovery service seems near impossible with a combination of OAuth2 service accounts so I've been using https://outlook.office365.com/EWS/Exchange.asmx as the main EWS endpoint.
However, when I try to create a new subscription for the specific calendar folder, I keep getting a generic 500 ErrorNoRespondingCASInDestinationSite error:
Exchange Web Services are not currently available for this request because none of the Client Access Servers in the destination site could process the request.
The strange part is this only happens directly after receiving the initial ErrorReadEventsFailed error. If I try again in, say, 30 seconds, the request goes through without a problem.
After doing some research, it seemed that most users found it helpful to ensure that the X-AnchorMailbox header was set properly for the user that the service account wishes to impersonate. I double-checked this header, and it is indeed being sent along the request to resubscribe.
This problem may be solvable by an exponential back-off solution, or by just retrying X amount of times until the request goes through. It seems to me that when the subscription gets "lost", the O365 service needs time to change the DNS of the Exchange server (it's the only thing I can think of).
Any help would be greatly appreciated!
Given the documentation at: https://msdn.microsoft.com/en-us/library/office/dn458788(v=exchg.150).aspx
When a subscription is lost, or is no longer accessible, it is best to create a new subscription and not include the old watermark in the new subscription. Resubscribing with the old watermark causes a linear scan for events, which is costly.
Instead, create a new subscription and compare folder properties to look for content changes that occurred between the lost subscription and the new subscription. The extended folder properties that we recommend that you check are PR_LOCAL_COMMIT_TIME_MAX (0x670a0040) and PR_DELETED_COUNT_TOTAL (0x670b0003).
You can do this by creating an extended property definition.
I think this may help you!!
Related
I'm trying to create a subscription to receive the contents of all new messages sent within a private Team, and so far it appears I have to configure a bot / webhook within Teams (and only messages #mentioned to that bot / webhook will be sent to me), or otherwise use the Graphs API (I can't determine whether the same caveat exists with #mentions).
The use case is to allow members of the Team to post messages, and for my listening application to consume the message contents and take an action (turn on a light, etc.. but external to Teams). I don't anticipate needing to write anything back into the Team.
I found this link in another post: https://blog.thoughtstuff.co.uk/2020/01/how-to-use-the-new-webhooks-for-microsoft-teams-channel-chat-messages/
Has anyone successfully been able to subscribe to all messages within a private team for a similar use case?
Thank you!
Posting the Answer for better knowledge
Copying from #Sridevi comments
To track messages and replies in a channel, you can create a change notification subscription at a channel level. Please follow this documentation.
When creating Calendar Events via the Graph API, the events are created correctly in the calendar of the organizer but the invites to the participants get bounced. The organizer gets a 'Delivery has failed...' message with the following error message:
Remote Server returned '550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP. For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653 AS(7171)
Sending emails manually through Outlook (web) from the organizer to the participants works fine.
The issue is intermittent. After changing the DNS server, everything worked fine for some time.
I checked https://protection.office.com/restrictedusers as suggested in the answers to similar posts, but this list is empty.
I also tried delisting the IP address (my own?) through https://sender.office.com/, but to no avail.
The tenant is linked to the Microsoft Developer Program and would allegedly have a 'bad reputation'. However, I don't understand how that would explain the fact that it sometimes works and sometimes doesn't when sending exactly the same API request and hence 'triggering' exactly the same emails...
I think the best way to overcome this would be to add a domain to your developer tenant as per the guidance here:
https://learn.microsoft.com/en-us/Exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-5-7-700-through-5-7-750#57750-client-blocked-from-sending-from-unregistered-domain
Add and validate all domains in Office 365 that you use to send email messages. For more information, see Add a domain to Office 365.
I'm not guaranteeing this will resolve it. You have to understand that those developer tenants are only meant for experimentation and so there are checks and balances to ensure they are used in a bad manor.
How many emails are you sending through this tenant?
Calendar events are sent out via email. Add the "Mail.Send" permission to you App Registration.
This solved it for me.
I am trying to use a conversation reference to continue a conversation with a user within my node bot server. This conversation, I assume, is trying to be resumed after the last API token received has expired. When I try to call continueConversation which is defined in botFrameworkAdapter.ts in the botbuilder library (note, that this is not within a turn, so no message has been received from Teams since the API key has expired), with my service URL as https://smba.trafficmanager.net/uk/ which is what I have stored in my conversation reference, I get an unauthorized error.
After digging into the botbuilder library, I have narrowed it down to the shouldSetToken method within microsoftAppCredentials.js. It would seem the issue is that https://smba.trafficmanager.net/uk/ is not a trusted host name, and as a result the connector does not attempt to retrieve a new token for use.
I can verify that changing the shouldSetToken method to always return true solves my issue, but what is the correct approach to do this which does not involve altering the library?
I've managed to get around this for now with MicrosoftAppCredentials.trustServiceUrl(serviceUrl). If there is a better approach it'd be great to hear it.
I'm having an issue with a Skype for Business bot in one of my Office 365 tenants. I have multiple tenants and in the first one I was able to add a Skype for Business bot framework bot with no issues. It took awhile for the bot to show up in the directory but it worked. In my second tenant, when I add the bot and attempt to send messages to it (even after 12ish hours of waiting), Skype for Business shows an error under each message I try to send to it - "The action couldn’t be completed. Please try again later." Any ideas what might be going on? One difference between the tenants is that the tenant that isn't working ha a custom domain name, and is using Azure AD Synchronization. Based on some tips I saw I made the address of my bot sip:username#mytenant.onmicrosoft.com rather than using my custom domain name. That didn't seem to make a difference... anyone else encountered this/have any ideas? I also tried leaving off the [BotAuthentication] tag on my MessagesController and that did not make a difference as well.
EDIT: Could this have something to do with my custom domain being federated? That's why I went with mytenant.onmicrosoft.com for the username of the bot.
I was able to resolve this. It seems like it has something to do with when you add a bot to a federated domain utilizing the custom domain name. This errors out when you use the New-CsOnlineApplicationEndpoint -Uri bot#domain.com. However, it still creates a bad endpoint. The cmdlet does not error out if you use a uri like bot#domain.onmicrosoft.com. However, after I had already added the bad endpoint, it seemed like no endpoints would work after that. To resolve, I removed all endpoints, including the first bad one with the uri bot#domain.com. Waited 8 hours, added a single endpoint using the onmicrosoft.com Office 365 domain, waited probably about 12 hours, and it started working.
I'm using MailChimp v2.0 API at the moment to replicate, update and then send mail campaigns. All so far so good, but occasionally I'm getting this curious error when I call campaigns/send
{
"status": "error",
"code": -99,
"name": "Campaign_EgpPrediction_Exception",
"error": "Campaign_EgpPrediction"
}
If I try again, it may work. Seems sporadic.
Workflow: I replicate one of our standard campaigns then get the new ID, then with this ID I update the title, make it a URL-driven campaign by updating the url value, move it to a folder, then send it.
All the other API calls are successful, just the send sometimes says that.
I can't find reference to the error anywhere in MailChimp docs, I have asked their API support team but whilst I'm waiting...
This is caused by a predicted bounce rate warning. After I went ahead and sent the campaign despite the warning (which doesn't exist in MailChimp's documentation) I got the following from the compliance team shortly afterwards:
This is a note from the MailChimp compliance team. Omnivore, our automated abuse prevention system, detected a recent campaign that generated a bounce rate which exceeded allowable industry thresholds. Noting the account received an above threshold bounce rate, Omnivore has detected that this list requires removal from our system before we would be able to reactivate the account.
As a bulk delivery service we are required to enforce the industry thresholds that ISPs, anti-spam groups and corporate email protection services set regarding spam complaints, bounces and unsubscribe requests. When rates exceed industry thresholds, as your campaign did, Internet Service Providers can block service to the entire MailChimp ecosystem.
Keeping this in mind, the list must be removed from the account before we are able to support further sending. Because a list cannot be deleted for 7 days following a campaign send, we do ask that these contacts be bulk unsubscribed from the list following the instructions provided
So, it looks like the system will warn you with this error message via then API and then let's you send it anyway if you persist!
I hope this helps someone else in the future from sending to a list that may cause you larger problems later.