Does anybody know how to programmatically enable/disable the actual state of the out-of-office auto-responder in Outlook 2007?
Already searched the object browser in VS 2008 and found the enumeration Microsoft.Office.Interop.Outlook.OlBusyStatus but i didn't find any class or anything else using this.
Any idea is appreciated, thanks and regards
UPDATE: Updated the code below using sample code adapted from this blog post which will work better in a wider variety of Outlook installations (e.g. ones using both Exchange and PST or accessing multiple Exchange mailboxes).
Here's code which worked for me on Outlook 2007, to set the OOF status from an external (to Outlook) EXE:
Microsoft.Office.Interop.Outlook.Application app = new Microsoft.Office.Interop.Outlook.ApplicationClass();
Microsoft.Office.Interop.Outlook.NameSpace ns = app.Session;
foreach (Microsoft.Office.Interop.Outlook.Store store in ns.Stores)
{
if (store.ExchangeStoreType == Microsoft.Office.Interop.Outlook.OlExchangeStoreType.olPrimaryExchangeMailbox)
{
store.PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/proptag/0x661D000B", true); // false to turn off OOF
break;
}
}
Make sure you're not running that code as Administrator and outlook as non-Administrator-- otherwise you may get a security-related error on Vista.
Note that it will pop up security dialogs inside Outlook to ensure the user is OK with you accessing the Outlook object model. This is normal when outlook object model is accessed from an external EXE.
If, however, you're accessing the object model from an add-in, the code above isn't fully correct: instead of creating a new Outlook.Application object via the constructor, you you need to get a reference to the trusted Outlook.Application object from inside your add-in, like this:
Microsoft.Office.Interop.Outlook.NameSpace ns = this.Application.Session;
foreach (Microsoft.Office.Interop.Outlook.Store store in ns.Stores)
{
if (store.ExchangeStoreType == Microsoft.Office.Interop.Outlook.OlExchangeStoreType.olPrimaryExchangeMailbox)
{
store.PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/proptag/0x661D000B", true); // false to turn off OOF
break;
}
}
BTW, there's a good MSDN article on security for add-ins, which may be useful if you run into security dialogs or errors.
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 attempting to utilize Office interop with C#, but I'm having some difficulties. Executing a test like the one I included below seems to work insofar as it launches Outlook and seems to connect with it. The issue is that if I then try to open the Outlook window (it starts hidden in the tray) I get an error message from Outlook saying The application was unable to start correctly (0xc0000142). I do not get this error if Outlook was already running before I started my application. Am I doing something incorrectly or is something broken?
using System;
using Outlook = Microsoft.Office.Interop.Outlook;
namespace OutlookInteropTest1
{
class Program
{
static void Main(string[] args)
{
var app = new Outlook.Application();
Console.ReadKey();
}
}
}
Visual Studio Community 2017 Version 15.2
Office 360 - Outlook Version 1804 Build 9226.2156
Windows 10 Build 17115.1
EDIT: Tested this on Windows 7 and could not reproduce crash. I know that I had this working in Windows 10 at some point. I reinstalled my OS and it still crashes. I'm chocking this up to the typical Microsoft user experience unless anyone has any ideas on how to fix it.
Outlook is a singleton, so creating a new object will return the existing object if Outlook is already running.
In your case you also need to provide namespace to it
olApp = new Outlook.Application();
Outlook.Namespace ns = olApp.GetNamespace("MAPI");
ns.Logon();
I know this is old, but I was having the same issue and perhaps it will help someone in the future:
As IAmRajshah mentioned, only one istance of outlook can run, so, if Outlook is open your code olApp = new Outlook.Application();will crash, you need to "connect" to the active instance of outlook with somenthing like this Oulook.Application olApp = Marshal.GetActiveObject("Outlook.Application") as Outlook.Application; The link below has a good example of this:
Get and sign in to an instance of Outlook
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 have a requirement where I need to get the data from a folder called "Public folder" which contains global information like book rooms for discussions / meetings etc and this folder is in server and I am able to access this through outlook. How do I access the same programmatically, C# ?
If you're solely on the client use COM via Outlook.
Or use WebDav against Exchange 2003, or check out the new webservices for Exchange 2007.
It all depends where your code will execute and/or the version of Exchange running before deciding the way to go.
You just have to make sure the application is running as a user with permissions to Exchange.
I know you said C#, but if you're willing to experiment a bit, here's a Perl solution I've used successfully in the past:
http://rasterweb.net/raster/code/src/vcalxical_pl.txt
You need IMAP enabled on the Exchange server and this will only work with 2003. In Exchange 2007 calendar information is no longer stored in folders, so this will break. You also said you just needed to get the data, not modify it.
This solution will work with Exchange 2007:
http://blogs.msdn.com/exchangedev/archive/2009/02/05/quick-and-dirty-unix-shell-scripting-with-ews.aspx
Ksempac, look here for a way forward:
http://msdn.microsoft.com/en-us/library/ms268893(VS.80).aspx
The Microsoft.Office.Interop.Outlook namespace is horrible to work with, but with a bit of Googling you can do some cool stuff.
In the past we used Outlook Redemption. It works through extended MAPI so it has more features then Outlook provides with Microsoft.Office.Interop.Outlook
There is also another useful tool - Outlook Spy that allow you to discover Outlook object model in run time.
I modified the code to loop through sub folders, sorry for the delayed response
using System;
using OutLook = Microsoft.Office.Interop.Outlook;
class OutlookFolders
{
static void Main(string[] args)
{
OutLook.Application outlookObj = new OutLook.Application();
GetSubFolders(outlookObj.Session.Folders);
}
private static void GetSubFolders(OutLook.Folders folders)
{
foreach (OutLook.MAPIFolder f in folders)
{
Console.WriteLine(f.Name);
GetSubFolders(f.Folders);
}
}
}