Not all Outlook functions work from a Windows Service
Calling Outlook from a Windows Service can be problematic. Even though many operations work fine, Microsoft has issued some pointed advice for customers looking to run any Office application in the background in Session 0:
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.
So instead of calling Outlook, which may be unreliable when run in the context of a service, look to one of these alternative solutions instead:
Solution #1: Have your Windows Service call PowerShell to send basic email
If you don’t want to install any third-party utilities, you can leverage Microsoft’s ubiquitous PowerShell utility to deliver your messages. And to help, we’ve created a simple script that, given eight required parameters, will send an email to any address:
You can download the PowerShell script here. Please feel free to adapt it for your needs.
Your email provider will determine the SMTP server and port number you should use. For example, if your provider is Gmail, the SMTP server is “smtp.gmail.com” and the port is 587.
To invoke the script from an application, run the PowerShell executable with the -File option. Specify the full path to the script along with the eight required parameters.
For example, if you’ve saved the script in C:\Utilities and you’re sending via Gmail, your command line will look like this:
Watch out for quotes in the subject and body and escape accordingly!
Solution #2: Use SwithMail to deliver complex messages from your Windows Service
SwithMail is a free, no-nonsense utility that can send very detailed email messages. It supports all the important messaging options, including:
- HTML formatting
- Multiple attachment files
- CC and BCC recipients
- “ReplyTo” configuration
After downloading the SwithMail zip file and extracting its contents to a suitable location, double-click SwithMail.exe to reveal the comprehensive command line:
Simply specify the options you need. For example, here is a sample command line that sends the same message as the PowerShell script above:
If you prefer, you can compose an XML file with all the details and pass to SwithMail instead, like this:
If you’re having trouble configuring SwithMail, add the /Log parameter and a path to a log file. Check the file for error messages after a failed run.
Solution #3: Update your Windows Service code to send email directly
If you have access to the service’s source code, your best option may be to include code to send email using the SMTP classes built into your programming language.
Here is some sample C# code (error handling omitted for clarity):
Get in touch if you need help sending email from your Windows Service
Hopefully one of these three solutions, which don’t involve Outlook, will work from your service. If not — or if you have questions about the methods outlined above — please don’t hesitate to reach out to our support team. We’re here to help!