I'm writing a console application, which checks the contents of an outlook mailbox, in order to read the contents of specific emails into a database.
This application works fine within Visual studio, whether or not Outlook is open.
If I build the application and run it from the exe it only works when Outlook is open, which isn't really a problem.
However, I need to run it from a scheduled task as it has to run every few minutes. This will not work at all.
I'm using the following code:
System.Diagnostics.Process[] processes = System.Diagnostics.Process.GetProcessesByName("OUTLOOK");
int collCount = processes.Length;
if (collCount != 0)
{
OutlookApp = Marshal.GetActiveObject("Outlook.Application") as Application;
}
else
{
OutlookApp = new Application();
}
The error message I'm getting is:
System.Runtime.InteropServices.COMException (0x800401E3): Operation
unavailable (Exception from HRESULT: 0x800401E3 (MK_E_UNAVAILABLE))
at System.Runtime.InteropServices.Marshal.GetActiveObject(Guid&
rclsid, IntPtr reserved, Object& ppunk) at
System.Runtime.InteropServices.Marshal.GetActiveObject(String progID)
at ImportCruiseEmails.Program.Main()
On the line :
Marshal.GetActiveObject("Outlook.Application") as Application;
Both Outlook and the console application are running under my user account, which has administrator permissions. I've been pulling my hair out with this all afternoon. Can anybody please shed any light on it? Cheers!
Even through the user accounts are the same, security contexts are different since the scheduler runs as a service. And no Office app can be used in a service.
Your options are
In case of an Exchange Server, use EWS to access the mailbox.
Extended MAPI (C++ or Delphi only)
Redemption (I am its author, any language) - it wraps Extended MAPI and its RDO family of objects can be used from a service.
Related
We have a Export Utility which exports all emails from Outlook to local directory. And our tools work perfectly fine. But now we are migrating to O365 and since then we are seeing issues with the tool.
Technically the does all the things like able to read all emails and its properties like Subject, From, To etc and also able to SAVE or MOVE to other folder within Outlook O365.
But I get an error "System.Runtime.InteropServices.COMException (0x80004004): Operation aborted (0x80004004 (E_ABORT))" as soon I execute SAVEAS.
Below is the sample code
public static void ReadEmails()
{
try
{
Outlook.Application oApp = new();
// Get the MAPI namespace.
Outlook.NameSpace oNs = oApp.GetNamespace("MAPI");
oNs.Logon("*****#*****.com", System.Reflection.Missing.Value,
System.Reflection.Missing.Value, System.Reflection.Missing.Value);
Outlook.Folders fols = oNs.Folders;
Outlook.MAPIFolder inboxFolder = fols["****"].Folders["Inbox"];
foreach (Outlook.Folder fol in inboxFolder.Folders)
{
MessageBox.Show(fol.Name);
Outlook.Items items = fol.Items;
foreach(Outlook.MailItem mailItem in items)
{
MessageBox.Show(mailItem.Subject);
try
{
//mailItem.Move(inboxFolder); -- this works
mailItem.SaveAs("test.msg", Outlook.OlSaveAsType.olMSG);
}
catch (System.Exception ex)
{
MessageBox.Show(ex.ToString());
}
}
}
oNs.Logoff();
}
catch (System.Exception e)
{
Console.WriteLine("{0} Exception caught: ", e);
}
}
So do I have to do anything special?
FYI, the tool gets executed on user laptop as a user on his own email account.
The code looks good. I don't see anything strange there. But the following exception may indicate multiple issues:
System.Runtime.InteropServices.COMException (0x80004004): Operation aborted (0x80004004 (E_ABORT))
Most probably you have faced with a security issue in Outlook. "Security" in this context refers to the so-called "object model guard" that triggers security prompts and blocks access to certain features in an effort to prevent malicious programs from harvesting email addresses from Outlook data and using Outlook to propagate viruses and spam. These issues or prompts cannot simply be turned off, except in Outlook 2007 with an anti-virus application running.
The following strategies can be used for avoiding the security prompts/issues in Outlook:
A low-level API on which Outlook is based on - Extended MAPI (or any other third-party wrappers around that API, for example, Redemption).
Outlook Security Manager is a programming tool that allows you to suppress security alerts invoked by the code of your application or add-in that interacts with Microsoft Outlook 2000 - 2013.
In a corporate environment, the administrator may choose to loosen Outlook security for some or all users.
Develop a trusted COM add-in and call it for saving emails instead of using OOM directly. The add-in has access to a secure Application object which doesn't trigger security issues.
Another possible cause is that 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. Here is what MS states for such cases:
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.
Read more about that in the Considerations for server-side Automation of Office article.
I was able to fix the issue by changing following registry value to 2 (make sure to open registry as ADMIN)
HKEY_USERS > S-1-5-21-1132323721-62323254-1511918330-144209 > SOFTWARE > Policies > Microsoft > office > 16.0 > outlook > security
(Computer\HKEY_USERS\S-1-5-21-1132323721-62323254-1511918330-144209\SOFTWARE\Policies\Microsoft\office\16.0\outlook\security)
Dword: PromptOOMSaveAs
Value: 2
Note: Above BOLD value > you can get this by running whoami /user in command prompt
I am trying to get an Outlook Application object in my add-in for Excel.
If there's a running Outlook instance, it should get that, if there isn't any, it should create one, using the Outlook object model.
This is the code I have right now:
public static Outlook.Application GetApplicationObject()
{
Outlook.Application application = null;
if (Process.GetProcessesByName("OUTLOOK").Count() > 0)
{
application = Marshal.GetActiveObject("Outlook.Application") as Outlook.Application;
}
else
{
application = new Outlook.Application();
}
return application;
}
My problem: it finds Outlook processes, but can't get them, throwing the following error message:
Operation unavailable (Exception from HRESULT: 0x800401E3 (MK_E_UNAVAILABLE))
I tried debugging it step by step, and monitored the task manager. I could see that I have an Outlook instance, but it's only an icon in the right side of the taskbar. Does this mean, that the instance is not fully loaded yet, and it can't be accessed, to get the Application object from it?
I ended up modifying my code, and separating the if-else into 2 try-catches, with their own returns, but I still think that the code above should be usable.
Outlook is a singleton, so new Outlook.Application() will always work - if it is already running, you will get that running object.
Make sure both apps (Excel and Outlook) are running in the same security context. Is either app running with elevated privileges (Run As Administrator)?
I am creating a button in asp.net c# that when clicked will open up Outlook window.
I am referencing to the Microsoft.Office.Interop.Outlook dll, and using this in using statement:
using Outlook = Microsoft.Office.Interop.Outlook;
This the code.
private void CreateMailItem()
{
try
{
var outlookApp = new Outlook.Application();
var mailItem = (Outlook.MailItem)outlookApp.CreateItem(Outlook.OlItemType.olMailItem);
//var mailItem = (Outlook.MailItem)
// Application.CreateItem(Outlook.OlItemType.olMailItem);
mailItem.Subject = "This is the subject";
mailItem.To = "someone#example.com";
mailItem.Body = "This is the message.";
mailItem.Importance = Outlook.OlImportance.olImportanceLow;
mailItem.Display(false);
}
catch (Exception)
{
throw;
}
}
I get error on the very first line, var outlookApp = new Outlook.Application();
The exception says:
{"Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))."}
The exception you've posted is thrown when a referenced dll or depencies of this dll are not correctly installed.
In this case, it seems outlook or office is not with the correct version which you referenced, on your test machine?
Can't post this as comment.
I would like to know why you prefer the use of Outlook Interop?
I am using the mailto:// protocol if I wanted my program to send email on the user's current email client, though I use this on WinForms.
like http://www.rapidtables.com/web/html/mailto.htm
Outlook, just like any Office app, cannot be used from a service (such as IIS). Even if you did make it work, the new message window will be displayed on the server where the user will not see it anyway.
You can try to run a client-side JavaScritp code, but then you'd be limited IE only, Outlook would need to be locally installed, and your site must be trusted to be able to create COM objects in a script.
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. Read more about that in the Considerations for server-side Automation of Office article.
Consider using System.Net.Mail namespace for creating and sending emails in ASP.NET.
I am trying to send email from .net windows application using Microsoft.Office.Interop.Outlook. The mail is in html format and has an image embedded to it. Getting the following error when trying to attach the image,
"Cannot create file: XXX.jpg. Right-click the folder you want to create the file in, and then click Properties on the shortcut menu to check your permissions for the folder."
I dont have any issues with folder access. I am running the app on 64 bit computer with 32 bit outlook on it. When i dont embed image, i dont get any errors and it works fine.
string body = string.Empty;
using(StreamReader reader = new StreamReader(Environment.CurrentDirectory + #"/Mail Templates/XXX.txt"))
{
body = reader.ReadToEnd();
}
Outlook.Application oApp = new Outlook.Application();
Outlook._MailItem mailItem = (Outlook._MailItem)oApp.CreateItem(Outlook.OlItemType.olMailItem);
mailItem.To = "XXX";
string filename = Environment.CurrentDirectory + #"/Mail Templates/XXX.jpg";
mailItem.Attachments.Add(filename, (int)Outlook.OlAttachmentType.olEmbeddeditem, 1);
mailItem.HTMLbody = "true"
mailItem.Display(true);
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.
You can read more about that in the Considerations for server-side Automation of Office article.
You may consider using the EWS (Exchange Web Services) or BCL (Base Class Libraries from the .Net framework). See EWS Managed API, EWS, and web services in Exchange for more information.
all,
I have code in C# 2.0 like this:
SHDocVw.ShellWindows shellWindows = new SHDocVw.ShellWindowsClass();
foreach (SHDocVw.InternetExplorer ie in shellWindows)
{
//.........
}
It is console exe for a 64bit Windows Server 2008 R2 Standard with sp1, IE9.
Basically it launches IE and download a file, then process that file.
When I run it manually, such as double click or from Command console, it works just fine. However, when I set up a Scheduled Task through Task Scheduler, it throws the error at the first line above:
Retrieving the COM class factory for component with CLSID {9BA05972-F6A8-11CF-A442-00A0C90A8F39} failed due to the following error: 8000401a.
I think it must be a permission issue,but I couldn't figure out how to fix it. Any ideas?
Thanks.
I suspect this is to do with access to the desktop.
As shdocvw has a UI, it requires permission to get the desktop handle. When it creates a window it must have a parent window and the desktop window handle is king (or Queen).
However, a scheduled task (for any user) cannot get the desktop handle unless the user is already logged-in in the foreground.