New Office 365 EWS OAuth2 scope related bug "The item is opened in read-only mode"? - exchangewebservices

Hope Office 365 team gets this on their radar,
We provide a sync service for our clients which includes deletion syncing also. About a week ago Office 365 EWS API started rejecting item deletions for users that had been syncing for months without any problems (OAuth2 based connections):
ErrorAccessDenied: Access is denied. Check credentials and try again., The item is opened in read-only mode.
Something has definitely changed in the Office 365 EWS behavior. I have a feeling Microsoft has introduced an OAuth2 scope handling bug recently for EWS that somehow excluded the "delete item" permission.
Our OAuth2 access tokens always had the EWS.AccessAsUser.All scope which is supposed to be giving the read/write/delete permissions.
Thoughts?

Alexey is right. There was a regression in calendar sharing sync code that caused this problem with removing a cancelled occurrence from a recurring meeting. The change is being backed out starting 1800 UTC on 1/3/2019, and is expected to be fully backed out within 3 days.

Related

SSRS 2019 -- subscription email fails ONLY when attaching the report

I have SSRS 2019 in native-mode with SQL Server 2019 standard behind it. To be very clear, email functionality works and outgoing emails from SSRS is being sent and received. The issue is when the option to attached the report (Include Report) is selected in the subscription options, the following error is received at time of execution:
Failure sending mail: The permissions granted to user '' are insufficient for performing this operation.Mail will not be resent.
I've tried different render format (MHTML, PDF, CSV, XML) to no avail. "Include Link" option works without issue. So unless there is a secret permission somewhere for attachments, I'm a bit confused.
SQL Server Database Mail works and shares the same email configuration values as SSRS.
If anyone has faced this issue, I would love to know what caused it and how you solved it in case my situation is the same.
Nevermind everyone. After I posted my question, I realized the service account was still at the default "Virtual Service Account". After I got an actual domain service account and updated it, plus restarted the service, emails with attachments started flowing through without issue.
Note: I had to delete my 1 existing test subscriptions since it no longer was being recognized with the new service account. After creating a new subscription, there were no more issues with attachment-emails. This in itself could be another problem altogether. More testing is required.

Azure - API Management - Management API SAS token expiry

We have an API management instance in azure.We have also enabled the management API. There we have set a SAS token & that has been used in the application. Here, we have to change the SAS token in every 30 days. If the token is expired, that will result into an application outage. Is there any way to get notified via email or any other means about the token expiry (in advance). I did some research on this, but , unfortunately could not find anything useful.
I don't believe there is built-in support for this.
You could instead have a logic app that takes in a SAS Token as input and schedules emails based on the expiry of the token.
TIP Apart from an email, you could do more interesting workflows like sending actionable messages using office 365 outlook or https://learn.microsoft.com/en-us/connectors/teams/#post-an-adaptive-card-to-a-teams-channel-and-wait-for-a-response connectors and even create a work item in Azure Devops or create an issue on GitHub, depending on what you use.
Alternatively you could create Azure AD application with client id and client secret, give it permissions to do what you need to be done in APIM and use its credentials to do all the same operations via ARM.

Fields returned from EWS getItem request on Appointment are incorrect

The add-in I'm working on makes an getItem EWS request using Office.js to get certain fields otherwise unavailable. Mainly recurrence data, the all day flag, and the the body for older Exchange versions.
Depending on the environment the fields are incorrect when composing an appointment. Once the appointment is sent (if it has attendees) or saved (if it does not have attendees) then the fields are correct.
The start date and end date are a year ahead, the subject and body are empty when they shouldn't be, and the item class is always IPM.Appointment or null regardless of whether the it's a recurring appointment. Saving the appointment via Office.js before making the ews request does not make a difference. I even tried making the ews request a few minutes after I saved the appointment.
This seems to occur for some Outlook on the web users, but not for users using the Windows clients. I tried Outlook on the web with an Office 365 account, on-premise 2016, and on-premise 2013. Only the Office 365 account seems to have this issue.
My question is, is there something I can check, like the Exchange Server version, to find out if a user will run into this issue? I want to prevent using incorrect data if possible.
This scenario occurs when calling Office.context.mailbox.item.saveAsync on a new Calendar item that has not been sent yet. We are aware of this issue and are looking into a solution to resolve this so that the API can be used as designed. The API should behave as designed in Mail and on Existing Calendar items. Note that for existing Calendar items, an update may be sent out to attendees depending on the changes that the user or the add-in made in the compose form.

EWS - Office 365 - "One or more subscriptions in the request reside on another Client Access server."

My goal is to subscribe for streaming notifications for multiple users in the same time.
One way to do that is to create multiple StreamingSubscriptionConnections each one should contain one StreamingSubscription for each user. The problem with this method is that in Office 365 the maximum number of connections opened is 20.
Another method to solve this problem is by creating one StreamingSubscriptionConnection and then all StreamingSubscriptions for each user to the connection. This method solves the maximum number of connections problem and it works fine with exchange onPrimises. But when trying it with Office 365 it will result with the SubscriptionError:
"One or more subscriptions in the request reside on another Client
Access server. GetStreamingEvents won't proxy in the event of a batch
request."
Can anyone help me here ?
Update to the latest version of the EWS Managed API, version 2.1. It has GroupingInformation added to the enumeration. http://www.microsoft.com/en-us/download/details.aspx?id=42022

Lotus out of office function doesn't work correctly

after upgrading template from dwa7 to mail85 the out of office function doesn't work anymore, when i send an e-mail to user#domain the message is delivered but the automatic response from out of office doesn't work. The function only works with the agent, but 6 in 6 hours, not immediately. Does anyone know how to solve this problem?
Have a look at this article: The IBM Lotus Notes and Domino Out of Office service: Best practices. The article contains several things to check in order to ensure that you can get the Out of Office Service to run instead of the Out of Office Agent.