It's my first question/post :-/
Background to question:-
I have an ongoing project which is an Azure hosted ASP.NET solution. Its a generic ERP and is intended for small enterprise businesses. An additional requirement came up and I'd like it to be part of the Azure solution (previous attempt to create a VSTO add-in went bad).
I've been asked to automate this process:- Users spend a long time (daily basis) manually saving emails into network shared directories according to what company project the emails relate to. E.g. everytime Sally sends or receives an email, she copies and renames the .msg file from outlook into her "G:/" drive (which is just a network share on the enterprise LAN). Someone else in the enterprise has the job of creating a specific directory structure for sally (and her co-workers) to save the emails in (e.g. Correspondance-In, Correspondance-Out etc..). Staff need to be able to search the directories for messages based on some scraped meta data.
I'm considering an exchange web service managed API application in Azure which has a service that polls the Exchange Server (for every user) with a pull subscription to identify new/changed mails. Each identified mail will be then assessed against a rule that the user has pre registered in my application (i.e. from person x with project ID in the subject field). The application will then rename the email and put it in the network share (also scrape metadata to provide search functionality).
Question:-
a) How do I get my remote application to request the Exchange Server or CAS to export the MailItem to a local network share using exchange web services in the most efficient way? Preferably without having to deploy something into the enterprise.
b) is this a ridiculous solution?
Additional Info:
I expect the typical environment to be quite old. However, I can assume Exchange Server 2007+ and Outlook Clients 2007+ on Win7 (no Office365 though and no sharepoint). I decided to use a pull subscription as it will be a loosely coupled environment and therefore assumed streaming to be not the best fit.
MailItems are likely to contain large attachments (CAD drawings etc) so for obvious reasons, I would like to avoid pulling these across the WAN.
I have investigated the potential to create server side mailbox rules with EWS therefore allowing this exchange server to manage the export - however if I understand correctly, rules don't support exporting MailItems to the filesystem.
I want to collect weekly feedback from my peers about their workload (numbers 0-9 for every workday). At the moment, they just send me a blank email with the subject line "5,8,6,2,9" and I have to put this information manually into a spreadsheet. This is too much work so I would like to automate the process.
Outlook in combination with Access has the nice feature to create emails and process the responses automatically: http://office.microsoft.com/en-us/access-help/collect-data-by-using-e-mail-messages-HA010015427.aspx
Unfortunately, this does not seem to support "who" (put the sender of the response into the database) sent the email.
This is why I was thinking about creating a small add-in to read the subject of incomming emails and extract the "3,9,..." automatically and put it to a Access database.
Only question if this is the right approach for this task or if I am overdoing it.
Please note: External Websites (like surveymonkey are not an option).
In my opinion it's one of the right approachs. It's very easy to write an Outlook Add-In which iterates through all mails with a specific subject and saves Sender and Mail-Body to a file.
I need to avoid forwarding in the emails that I'm sending using .NET. I'm using Outlook and Exchange server and I read tha IRM can help me. Does anyone have any code example or know if it's possible?
It looks like you might be able to use the Microsoft Outlook 2010 Primary Interop assembly and set the PermissionTemplateGuid property of the MailItem you're sending.
Note that you'll have to know the Guid of an IRM policy that prevents forwarding of the email.
You cannot send IRM mail programmatically in Outlook 2010. IRM mail is actually a regular mail message with an encrypted attachment, and Outlook does not expose the right API to craft the encrypted attachment and change the mail type.
The only way to do it from C# code is to use ActiveSync and send the mail in Exchange directly. Unfortunately, as of Exchange 2010, only licensed vendors can use ActiveSync.
See http://www.microsoft.com/about/legal/en/us/intellectualproperty/iplicensing/programs/exchangeactivesyncprotocol.aspx for more information.
Also, if you go down the path of setting the template guid, know that the DoNotForward template guid is hard-coded -- if it actually works (this is untested and unsupported, so you're mileage will vary) then you don't need to bother looking up the RMS template.
I want to write C# application which will remotely connect to exchange server and read my inbox! I want to use MAPI for that.
So I got two questions:
Can it be done remotely, and is there any requirements(e.g. install outlook client,etc? )
I was not able to find any code example in C# which uses MAPI to connect to inbox?
1) If I remember correctly Outlook must be installed and a profile must be set up. (In short; you are reading Outlooks data, not Exchange).
2) There are samples for this:
http://bytes.com/topic/net/insights/795371-accessing-inbox-through-mapi-using-c-net
http://g8.cx/mapi/ (See 4.7)
Note that MAPI/CDO is not supported in .Net.
Other options is to communicate directly using WebDAV, IMAP, POP3 or WebServices. All will work to retrieve emails. I recommend you try the webservice.
You can access the mailbox of a user from a remote machine.The email account should be configured on that machine and then you can read the mailbox using Microsoft.Office.Interop.Outlook and this link will provide you more info.
http://msdn.microsoft.com/en-us/library/ff870566.aspx
Why do you want to use MAPI so badly ?
Just use EWS:
http://www.codeproject.com/Articles/399015/Exchange-Web-Services
I’m using .NET 3.5, and I want to automatically send a mail. I’m currently using the following:
Microsoft.Office.Interop.Outlook.MailItem mailMsg =
(Microsoft.Office.Interop.Outlook.MailItem)outlookApplication.CreateItem(
Microsoft.Office.Interop.Outlook.OlItemType.olMailItem);
mailMsg.To = recipient;
mailMsg.Subject = subject;
mailMsg.Body = body;
mailMsg.Send();
However, I’ve found several articles that seem to imply I should be using the following method:
System.Net.Mail.MailMessage mailMsg = new System.Net.Mail.MailMessage();
mailmsg.To = recipient;
mailmsg.Subject = subject;
mailmsg.Body = body;
Can anyone tell me what the difference between the two namespaces if, and why you might want to use one over the other?
The first one, I assume, required Outlook to be installed in the machine so that the Office Interop assemblies are installed. The second one is pure .Net framework.
The second example needs a SMTP server, to make a direct connection, and uses this SMTP server to send the email. It has low overhead, will normally work.
If you need to compose & send an email on behalve of the current user, you could use outlook.
So far I have only seen answers with disadvantages for outlook. But it has a few advantages:
You do not have to ask the user for any configuration.
Outlook already knows the Exchange / SMTP server,
and the email address of the user
Email you send will be stored in the sent-items list of the user. So the user can see wat is sent in his name.
Add-ons that sign / encrypt outgoing email, or add a standard company disclaimer will be used, so you will follow company policies
Can prompt the user if it is allowed to send email (yes, this can be an advantage to)
You can choose to only compose the mail, present it to the user. The user can edit and choose to send it or not.
Edit:
I use the SMTP method for sending technical emails (like log files & error messages) to our support unit, these mails go out fast and unnoticed.
The Outlook method I use for sending mails on behalve of my user to other humans. These mails are slow, but are trackable, etc.
The first method is using interop by creating an instance of Outlook (outlookApplication) and having that instance of Outlook send the e-mail.
The second is used for sending e-mail over regular old SMTP and doesn't require outlook at all.
Unless you have specific needs for interop there's no need to send an e-mail using outlook (and your code won't work on any machine that doesn't have outlook installed).
First one uses COM interop, which is unneeded overhead. Second is pure .net with all it's features. Plus it is more flexible.
As other have mentioned, the first one uses outlook to send email. The disadvantage is that the user has to have outlook installed; the advantage is that it will look like outlook is sending it.
The second method will try to send mail directly. The advantage is that it doesn't require outlook to be installed, and is a lot less overhead. The disadvantage with this option is that most enterprises these days block port 25, so when you try to send the message, it will fail.
They are different.
MailItem represents message item in Outlook.
MailMessage represents an e-mail message that can be sent using the SmtpClient class.
Check MailItem and MailMessage.
First one is using COM Interop and uses Outlook as its base. It needs outlook configured. The second is using SMTP Client. The interop could run you into issues related to outlook, but will allow for some cool features like Opening a Mail Window (but its generally not worth it). The second one will send silent mail, though you can show some window of your own, but still it wont allow flexibility of Outlook Automation. My choice is System.Net.Mail.*.
The first one is using MS Office which you don't want to publish while System.Net.Mail is available when .Net framework is installed.
The first example uses libraries installed by the Office Interop Assemblies download.
The second example uses libraries installed by default with the .NET framework, System.Net.
The first example uses Microsoft Interop Libraries. I would go with your second example, since it's part of the default .NET install. The Interop libraries will have more overhead that isn't required as well.
The Microsoft.Office uses Microsoft Outlook to send the email. It requires Outlook to be installed, and is (at least the last time I tried sending mail this way) more prone to difficulties. (For example, it prompts the user to let them know that a program is attempting to send mail on their behalf, etc.)
The System.Net.Mail just uses pure .NET, and the specified SMTP server to send mail.
Trust me.. Avoid using the Office unless there's a need.
You need to use the second option any day. It's pure .NET.
If you use first option, i guess Outlook should have been installed in that machine. When you deploy, you will have problems if you don't have MS Office installed in the server.