I want to read an Outlook mailbox using PowerShell. I can access the Outlook mailbox using a MAPI API call, but I can only connect with an existing/preconfigured Outlook ID/profile on the machine. My requirement is, I need to connect to Outlook mailbox during runtime.
I am using PowerShell version 5.
importing assembly files
Add-Type -assembly "Microsoft.Office.Interop.Outlook"
$Outlook = New-Object -comobject Outlook.Application
mapping Namespace
$namespace = $Outlook.GetNameSpace("MAPI")
accessing inbox
$OutlookInbox = $Outlook.Session.GetDefaultFolder(6)
$OutlookFolders = ($Outlook.Session.Folders.Item(1).Folders.Item(2)).FullFolderPath
Firstly, this is not MAPI: you just pass string "MAPI" to the Application.GetNamespace call - this is Outlook Object Model. It only allows you to access a mailbox in a preconfigured local profile. If there are multiple local profiles and Outlook is not running, you can pass the name of the profile (as shown in Control Panel | Mail | Show Profiles) to Namespace.Logon. If Outlook is already running, Namespace.Logon won't do anything. If the primary mailbox in the profile has the right to access other mailboxes in the same Exchange org, you can use Namespace.CreateRecipient / Namespace.GetSharedDefaultFolder to access the default folders of other mailboxes.
If you want truly dynamic access to an arbitrary mailbox without an existing Outlook profile, you can either:
Use EWS library - it is accessible from PS: see https://blogs.msdn.microsoft.com/webdav_101/2018/06/19/about-using-ews-and-powershell/
A temporary profile can be created and configured using Extended MAPI (see https://blogs.msdn.microsoft.com/dvespa/2015/10/28/how-to-configure-an-outlook-2016-profile-using-mfcmapi/), but Extended MAPI can only be accessed from C++ or Delphi.
You can use Redemption (I am its author) - it exposes RDOSession.LogonHostedExchangeMailbox method (RDOSession object roughly corresponds to the Namespace object in the Outlook Object Model). LogonHostedExchangeMailbox creates (and then deletes) a temporary profile that points to the specified mailbox.
Currently, you are dealing with the Outlook object model, not MAPI.
Outlook is a singleton, you can't run two instances on the system at the same time. So, when you create a new Application instance you will be linked to the already running instance. Be aware, you need to run both applications under the same security context.
Note, 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.
As a workaround, you may consider using Open XML SDK if you deal only with Exchange accounts, see Start using web services in Exchange for more information.
Related
I am converting an old Silverlight application into Asp.Net Core, using Blazor and Razor Pages.
The old application is opening Outlook, and creating an email ready to send with a Subject, From etc, plus a series of attachments. It is creating an object to do this using the following code:
Dynamic outlook = AutomationFactory.GetObject(“Outlook.Application”).
In my web-site, I do something similar:
Use a COM reference to the Microsoft Outlook 16.0 object library.
If Outlook is already running, then get a reference to its associated “Outlook.Application” COM object as per https://renenyffenegger.ch/notes/Microsoft/dot-net/namespaces-classes/System/Runtime/InteropServices/Marshal/GetActiveObject.
Otherwise, create an object using Microsoft.Office.Interop.Outlook.Application appOutlook = new Microsoft.Office.Interop.Outlook.Application();
This works when running my web-site locally in Visual Studio, however I cannot deploy it to Azure:
C:\Program Files\dotnet\sdk\6.0.201\Microsoft.Common.CurrentVersion.targets(2926,5): Error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild. See https://aka.ms/msbuild/MSB4803 for further details.
I’m assuming that I won’t be able to use this approach, however I can’t see any alternative. Any suggestions as to how I can do this in an ASP.Net Core Blazor web-site would be greatly appreciated.
You cannot use Outlook, or any other Office app, in a service (such as IIS). Even if you do manage to make it run, it won't help you - your code is running on the server, and the message you populate and display will be on the server, where nobody would ever see it.
You can either use a mailto: link (it supports address, subject, and body) or (if you need HTML and/or attachments), dynamically create an EML (MIME) file - Outlook on the client side will be happy to open it. To make sure the message is editable, add X-Unsent: 1 MIME header.
In my web-site, I do something similar:
Use a COM reference to the Microsoft Outlook 16.0 object library.
The Considerations for server-side Automation of Office states the following:
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.
From a JS code you can automate Outlook from Internet Explorer (only on Windows). Other browsers don't know anything about the COM technology. So, I'd suggest considering other approaches for getting the work done. The easiest way, like Dmitry suggested, is to use the mailto protocol. It opens a client's e-mail system and begins a new email message. The following example shows a link that will prepare an e-mail message:
<a href="mailto:user#example.com?
subject=MessageTitle&
body=Message Content">
Contact Us</a>
You may consider using EWS or Graph API if you need to send email silently.
I've received requirements to upgrade a legacy Outlook addin, which requires an active logged on user, to a standalone microservice (implemented using NServiceBus).
The goal of the addin is to monitor incoming emails (by communicating with the Exchange) that match certain pre-set criteria and do stuff with it.
Is VSTO sufficiently robust to run inside a Windows Service?
Is it sufficiently threadsafe?
Could it lock up the mailbox, making it unreachable via human interaction?
Could VSTO make the service crash?
Even worse, could VSTO cause the Exchange to lock / crash?
If any of these concerns are real, are there alternatives?
I would say that it not advisable to run VSTO within a windows service. Writing something in VSTO is useful for its UI components, presenting something to the user, interacting with the user, and would mean you would need to start an instance of Outlook for your add-in to load. Installing Office on the server is typically frowned upon, create problems when used in a multi-threaded way, and create problems most developers are unprepared to handle.
There are also other avenues you might want to explore, so instead of using the Outlook library directly you can use Exchange Web Services (EWS) via the EWS Managed API, or if you are not on-prem, go with the REST or Graph API.
I have made one web site for configuring time slot for particular date. For example I stored Email id of user, date, Stating time of lecture, Ending time of lecture in database.
I want to display pop up on desktop before 5 minute of starting time.
Suppose I connect my database with outlook calendar.
How can I connect with outlook?
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.
If you deal with Exchange profiles only consider using EWS, see EWS Managed API, EWS, and web services in Exchange for more information. Or just use the System.Net namespace classes for accessing your mailbox.
I need to create an executable that can be called from the command line which will create an e-mail, attach files to the e-mail and show the e-mail to the user so that they can complete the e-mail and send it. This should be done in the e-mail client that the user has configured as their default.
This needs to work for as many e-mail clients as possible. The ones I'm aware of that are used most are Outlook 2007-2010, Outlook Express, Windows Live Mail and Thunderbird. I'll target .NET 2.0 so that it does not require a newer .NET to be installed if the user is using Vista.
Simple MAPI is capable of doing the above, but Outlook 2007+ does not support it. All the other mail clients on the list do support Simple MAPI. I get the impression that Outlook is the only client that uses Extended MAPI and that Extended MAPI is tricky to use, so it's better to just use the Outlook COM API instead of Extended MAPI.
First the program will look for Outlook and use the Outlook COM API to perform the above if Outlook is available. I'll implement this component in VB and use late binding so that I'm not compiling against a specific version of Outlook. Then, if Outlook is not found it will fall back to Simple MAPI and attempt to use it.
Because of all this decision-making in the code I'll make this program log its activity so that we can debug what is happening on the user's machine when it doesn't work.
Will this approach work? Do you know a better approach? My goal is to maximize compatibility.
EDIT
It looks like Outlook 2007+ does support Simple MAPI, but if you're running the 64 bit version then a 32 bit executable can't call it. I'll stick with the above plan for that reason.
Outlook 2007 supports Simple MAPI just fine.
I'm trying to write an asp.net (using c#) app that accesses my Outlook mailbox and display the messages. I searched on google but couldn't find useful info, any help is appreciated?
You must be aware of the fact that outlook is running on user local machine, and your ASP.NET application is running on some server and there is no way that your server side ASP.NET code can use Outlook local data.
AFAIK only way to do something like that would be creating outlook addin that will export all mails to ASP.NET application
If you are using Exchange then you can use Exchange Web Services to read emails.
Please see here
Be very careful that you do not attempt to access Outlook on the server side by using the Automation interfaces. All of the Microsoft Office desktop applications are written to be run by an interactive user in a process with a message pump, with all synchronization happening via the UI. When you run them in a multi-threaded environment like ASP.NET, horrible things will happen. If you're lucky, the application will simply crash.
If you're not lucky, you can suffer from data corruption, random crashes in unrelated code, and all the other things that happen when an application corrupts memory.
You may also violate your license if the people accessing the Office application through your web site are not individually licensed to use the application on their desktop.
You can't connect to Outlook via C# (ASP.NET), but you can connect to your mailserver via POP3/IMAP to read the mail.
IMAP Client library using C#