Note: This particular issue has significant impact on our customers, which translates to high business impact with direct consequences on revenue.
TL;DR.
How can our Office add-in for Outlook, when a user interacts with our add-in while composing an email draft, minimize the amount of time it takes before the EWS GetItem API will return an OK response for the itemId we receive from Office.context.mailbox.item.saveAsync()?
If it turns out that our add-in has no control over when the item will be persisted to EWS, then what could an end-user do to speed this up?
We are looking for either (a) a technical solution, or (b) messaging to instruct our customers on how to mitigate/fix/work around this issue.
End-User Impact
Some of our customers are unable to send emails using our Office add-in for Outlook, or have to wait an exceedingly long time (> 2 minutes) before their email will send.
Our Goal
We want all of our customers to be able to send emails using our add-in, without having to wait for an unreasonable amount of time.
Additional Context
Based on our logs and customer reports, this issue only exists in the Outlook 2016 for Windows desktop application. We have no evidence to suggest the issue is present in any other version of Outlook, including Outlook 2013 or Outlook for Mac, however it is possible that the issue may be present in those clients as well.
Overview of our add-in
Our add-in integrates with Compose mode to provide additional functionality while composing email messages, such as templates, follow-ups, open and click tracking, and scheduling.
Our add-in works in tandem with our SaaS product like this:
Our add-in sets EWS extended properties on the email message with metadata indicating which features are enabled on that message.
Our SaaS product, out of band, is configured to read from the customer's mailbox via the EWS API. When it encounters EWS extended properties our Office add-in has written, it triggers the code paths to satisfy the desired behavior.
Root Cause Analysis
The root cause of our problem is our interaction with EWS in Outlook 2016 for Windows. In order to successfully interact with EWS to read/write to a mailbox item, it must be aware of that item.
The documentation for Office.context.mailbox.item.saveAsync() says:
In Outlook Web App or Outlook in online mode, the item is saved to the server. In Outlook in cached mode, the item is saved to the local cache.
It goes on further to say:
Note: If your add-in calls saveAsync on an item in compose mode in order to get an itemId to use with EWS or the REST API, be aware that when Outlook is in cached mode, it may take some time before the item is actually synced to the server. Until the item is synced, using the itemId will return an error.
Thus, we have concluded that Office.context.mailbox.item.saveAsync(), although it does indeed return an eventually valid itemId, does not guarantee that any subsequent EWS interaction will succeed. So far, we have found no way to accelerate the process of the Outlook client actually making EWS aware of the mailbox item.
Mitigation
We have attempted to mitigate this problem by polling EWS GetItem to attempt to obtain a ChangeKey for the item with the itemId we receive from Office.context.mailbox.item.saveAsync(). While we have seen that this does eventually succeed, it may take a minute or longer before this occurs. That is simply far too much time for our customers to have to wait.
Understanding "online mode" vs "cached mode"
If the Outlook 2016 for Windows desktop client is in "cached mode", is there anything the user can do to:
…know whether the client is in "cached mode" or "online mode"?
…attempt to force the client into "online mode"?
There is no way to speed this up in cached mode. Unfortunately this is a limitation of saveAsync in compose mode. Some things of note:
1) The EWSId is only valid while the item is a draft. After it is sent, when the item is in sent items, it will have a new EWSId which is not obtainable from the Office.js
2) Could you save your information into the custom properties, instead of the EWS Extended Properties. (Office.context.mailbox.item.customProperties) https://dev.office.com/reference/add-ins/outlook/1.5/CustomProperties?product=outlook
These properties will be saved to the mail in the sent item, but will NOT be transmitted. Then could you find those properties
These are stored as a JSON dictionary on the item in Key/Value pairs. The name of the mapi property is "cecp-[extension id from manifest]" (in PS_PUBLIC_STRINGS)
https://msdn.microsoft.com/en-us/library/office/cc842512.aspx
3) It does kind of sound like a better way to solve this would be an Office.js function that gives write access to this? (though we don't completely understand your scenario). Request for new features should go through UserVoice:
https://officespdev.uservoice.com/forums/224641-general/category/131778-outlook-add-ins.
4) Being in Online Mode would greatly mitigate the time. A User can know whether or not he or she is in online mode, but an Add-in cannot.
https://support.office.com/en-us/article/Turn-on-Cached-Exchange-Mode-7885af08-9a60-4ec3-850a-e221c1ed0c1c
Additionally, the status bar will say "Connected to Microsoft Exchange" in cached mode, and "Online with Microsoft Exchange" in online mode.
Switching to Online mode, removes a lot of the benefits that cached mode has. Cached mode is default in Outlook 2016.
Related
I have a scenario where a "compose mode" add-in for Outlook makes a subject line update to the draft email, then sends the email. The send action is currently carried out using either the EWS or REST APIs.
The issue occurs when a "override" policy tip is configured by the Exchange admin. The policy tip in question requires the user to choose override, in certain cases, to send an email (e.g external communication).
During message composition, if the appropriate trigger for the policy tip occurs, the policy tip appears and offers the user the option to override (as expected). When the add-in action is called, via ribbon button, the email appears to be sent. However, moments later an automated message from the Exchange indicates that the email has not been sent due to not adhering to the policy rule.
I believe this occurs because the send API, for both EWS and REST, does not call a local function in the Outlook client. Rather these API actually perform the send event on an email item syncedto and stored on the server. The Exchange server has no knowledge of the user's selection to override the policy tip at the client, so the issue occurs.
This happens in both Outlook on Desktop and Outlook Web Access.
I have searched through the EWS and REST APIs and cannot find any way to share/indicate the policy tip override when using these API.
I have searched the add-ins developer documentation and can find no mention of policy tips at all.
I have searched the Exchange admin policy tips documentation and can find no mention of add-ins compatibility or add-in related behavior.
So, can Microsoft Outlook Policy Tips be used in conjunction with add-ins REST/EWS send API?
I am working on an Outlook addin to make sure confidential information is not leaked using mail.
Using the on-send feature using ItemSend, we were able to get the email fields and block the sendmail, if required
https://github.com/OfficeDev/Outlook-Add-in-On-Send/tree/master/outlook-add-in-on-send
But there is an use case
User composes the mail and saves it to draft (without clicking on Send)
In outlook on web, composing a mail saves to draft automatically.
How can the add-in get a callback when draft is synced to Outlook server ?
How can the add-in get a callback when draft is synced to Outlook server ?
There is no such callback available for web add-ins. You may post a feature request or suggest a feature on the Tech Community site where community members get to share ideas on ways MS can make Microsoft Graph and Office Platform better by sharing feature requests and ideas.
Nothing like that for the JS-based addins.
For the COM addins, OOM exposes MailItem.Write event - your event handler can cancel the operation.
I have a working VSTO COM based Outlook add-in that intercepts all incoming/outgoing emails on a desktop outlook which is then used to save the details of the email into a SQL database. Below is a brief description of the steps I take using the add-in:
Intercept an incoming/outgoing email and adds a custom GUID as a user property on the email
Calls an end-point to my custom Web API on the cloud and sends an XML with details like the GUID (saved above) and other mail related ids and details
The API end-point saved the details into a SQL database and returns the response back to Outlook so that Outlook doesn't freeze up
A windows service runs in the background and monitors this SQL database for email items and makes a Web API call to Exchange or Office 365 to find the email using the GUID user property and then save it where needed.
I cannot save the email directly via the API call from VSTO add-in since there is some custom time-consuming logic that happens in the API so I cannot keep Outlook frozen for that time.
Is it possible to create something similar using the newer Outlook Web Add-in?
Kind of - you can intercept outgoing messages, but if you do, your addin won't be eligible to be published in the store.
It is still much easier in a VSTO addin. You cannot access Outlook Object Model from a secondary thread, but you can still run your code that does other things. Once you are done, you can access OOM on the main thread by opening message that you need to process by its entry id saved before you started the secondary thread. Note that the inability to access various objects from a secondary thread is OOM specific - Extended MAPI objects can be accessed from secondary threads, but Extended MAPI requires C++ or Delphi. In other languages (including all .Net languages), you can use Redemption (I am its author) and its RDO family of objects - all you need to do is save the value of the Application.Session.MAPIOBJECT property in a dedicated variable, then on a secondary thread create an instance of the RDOSession object and set its MAPIOBJECT property to the variable you saved on the main thread (see http://www.dimastr.com/redemption/faq.htm#Threads for more details).
Is ist possible for a user connected to Exchange Server via a client (Outlook Web App) to tamper with the e-mails in his mailbox (inbox, drafts, sent items ect.)?
Like modifying e-mail content (text, subject...) or properties (date, time, recipient...).
The core of the question is: If there is an e-mail in the user's sent items folder and this user did not have access to the Exchange Server (neither physically nor remotely, except for his standard user access), how sure (or probable) ist it, that this e-mail has really been sent on that date and time with exactly that text to exactly those recipients and that it had not been planted there at a later date?
Does it make a difference if that user only has access to his account via Outlook Web App or if he also has access via MS Outlook?
Outlook Web App is just a client so it won't allow you to modify a sent email or fake/import one as that is not a valid task for that client. You could do this at the API level using something like EWS or MAPI but that would require knowledge that most users won't have (but most likly they would have access to do it though). The Mitigation to this is if you have Litigation hold enabled https://technet.microsoft.com/en-us/library/ee861123%28v=exchg.141%29.aspx on the mailbox then any changes they did make to a message would be tracked and you would always be able to see the original version. Also if you looked at the message with a MAPI editor like MFCMapi or OutlookSpy there would be tell tails of somebody trying to fake a message like the Creation time not matching the sent time etc and other properties would most likly give it away.
One thing i would suggest is look at your Message Tracking log as they will tell you exactly what was sent and who is was sent to and the time https://technet.microsoft.com/en-us/library/bb124375%28v=exchg.160%29.aspx while these also aren't immutable it would take an administrative access to the server to modify.
I am specifically interested in the OUTLOOK Meeting information and
NOT ONLINE MEETING.
Can I GET the outlook calendar meetings (along with its details: time, subject, location, attendees, etc) using UCWA.
I asked about the same on UCWA forum of MSDN, and came to know that it isn't possible via UCWA.
However, this raises another question:
As a Lync user, if I hover my mouse over a contact who's busy in a meeting, then it shows the time until when he/she is busy, for example "Busy until 2 p.m.".
How is Lync fetching this outlook meetings information and displaying the output as per the meeting time. How does this mechanism work?
Lync/Skype for Business clients are making requests via Outlook APIs to grab non-online-meeting events to display that data. You would need to design your application to sign-in to their Outlook account and make use the available Outlook APIs to get all the meetings/appointments that are not present in Lync/Skype.