I have a SendEmail method developed with System.Net.Mail that works fine. Calling it from my VSTO Outlook Addin, I get an error: A call to SSPI failed. The inner error contains "Function not supported".
I tried to send the same email from a regular c# environment (that worked), and from my Outlook VSTO add-in that did not.
Is there a reason why the smtp email cannot be sent from the Addin?
Solution (thanks to Eugene), I added
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
to the SendEmail method and now the Emails are sent.
Given the nature of the exception, it seems like you're more likely to have an email server problem than anything else.
Also it makes sense to check what TLS version is used in the code. SSPI stands for Security Support Provider Interface, so it makes sense try to find the difference between two .net applications. TLS is a starting point, see How to enable TLS 1.2 for more information.
You may consider your Outlook VSTO add-in as a regular .net application. There are minor differences like availability of configurations files and etc. If you need to put something into a config file you need to create a config for the host application which is Outlook in your case. Keep that in mind when developing VSTO add-ins.
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 developed an office.js add-in using the ItemSend event. Everything works fine if external service available. But when i was testing send email operation for "unavailable service scenario" get an error like bellow:
"We're sorry, we couldn't access [Add-in Name]. Make sure you have a network connection. If the problem continues, please try again later."
and
"The add-in [Add-in Name] has prevented this item from being sent."
So the question is how to ignore add-in for this situation?
I am testing on web browser.
Thanks.
The group policy Disable send when web extensions can't load must be set to Disable on each applicable machine if you want to let users send emails if the add-in is not available. Read more about that in the Install Outlook add-ins that use on-send section of MSDN.
This is not possible at this time. The Item Send Add-ins are currently meant for mission critical and compliance apps, and if your add-in is not available then mail can not be sent. We are aware of the demand for a "softer" Item Send add-in that will allow for send to occur if your add-in is not available, but we do not have anything to announce at this time.
Note that the Group Policy "Disable send when web extensions can't load" does not affect this scenario, and is actually even stricter. If Outlook cannot retrieve manifests from the Exchange server, then all send will be disabled. That GPO is also meant for deploying compliance Item Send Add-ins and to ensure all your users have the latest manifests that you have uploaded.
I have a business requirement where there is a need to extend the functionality of outlook.
I am exploring Office Web Addins for this requirement.I have following queries.
I need to automatically move all incoming email to an external location.Does Office JS API provide handlers to incoming email event?
If it possible to define an action with Office JS API , which when triggered can loop through all the current unread emails and perform some action on each email (like move certain emails to a certain external location )
Is it possible to append custom headers to a email being composed using Outlook web add-in?
No
You can use EWS for that
No.
If your code only needs to run under the Windows version of Outlook, a COM addin might be a better option.
Unfortunately, it seems not possible to meet your requirements using Outlook Web Addin.
For more information, please review the following link: Outlook Add-ins overview
I am trying to send an outlook appointment through code. My code is posted below. When I run it on the server with IIS 6 and an app pool under a domain account identity, it throws this error. I have tried changing various settings on the server and none worked. Outlook 2007 is installed. I have even made the domain account a local admin. Please help!
Description: An unhandled exception
occurred during the execution of the
current web request. Please review the
stack trace for more information about
the error and where it originated in
the code.
Exception Details:
System.Runtime.InteropServices.COMException:
Operation aborted (Exception from
HRESULT: 0x80004004 (E_ABORT))
Line 201: objAppt.Send();
Code below:
Microsoft.Office.Interop.Outlook.Application objOL
= new Microsoft.Office.Interop.Outlook.Application();
Microsoft.Office.Interop.Outlook.AppointmentItem objAppt
= (Microsoft.Office.Interop.Outlook.AppointmentItem)objOL
.CreateItem
(Microsoft.Office.Interop.Outlook.OlItemType.olAppointmentItem);
objAppt.Start = startTime;//datetime
objAppt.End = endTime;//datetime
objAppt.Subject = subject;
objAppt.Body = body;
objAppt.Location = location;
objAppt.MeetingStatus
= Microsoft.Office.Interop.Outlook.OlMeetingStatus.olMeeting;
objAppt.RequiredAttendees = "test#test.com";
objAppt.Send();
objAppt = null;
objOL = null;
Yes as casperOne said I wouldn't use outlook on the server. I would use CDO or RDO(redemeption) for this. or even use vcal and send the vcal on a system.Net.Mail.
Update:
Take a look at http://www.dimastr.com/redemption/rdo/RDOAppointmenItem.htm
Show you how to do excatly what you want to do using RDO. You can do the same with CDO as well. Check out CDOLive.com
You will have to construct a teh login details as you are on a server that has no Outlook profile (thats if you remove the one that you allready have on there)
Quite simply, you shouldn't be doing this. It is not recommended that you run Office in a server environment because of the threading (and desktop session) requirements that Office has.
Are you trying to do this on an Exchange server? If so, then I would interact directly with the Exchange server (using WebDAV perhaps?).
If not connecting with Exchange, then take a look at the headers for an invitation to the event. The invitations should be nothing more than regular emails with custom header information.
I guess the reason you cannot use Outlook from an IIS application is because the current user the IIS app is running under does not have an Outlook profile associated.
Therefore you can instantiate Outlook objects and set their properties, until profile-specific functionality is required, such as the Send() command, which would store the outgoing mail in the user's/profile's (non-existing) pst file.
Don't do this using Outlook automation.
Straight from the horse's mouth:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
http://support.microsoft.com/kb/257757
Examine email headers sent by Outlook when it's doing this job to work out how this is done, and emulate it using the standard .NET SmtpClient stuff.