Outlook Automation is for People, not for Services.
I don't know why we see a lot of customers trying to automate Outlook from a service. It’s pretty well documented that it’s a bad idea. Outlook Object Model (OOM) was written for automating Outlook for a user sitting at the box running it. See, Outlook is very personal and I do mean, it’s very, very personal. Outlook and OOM are as much about being client side as any application with an associated API can be. They will throw-up dialogs for warnings and errors… they will ask you for input based-upon what’s happening... the list goes on... it wants to work with a person sitting at the box when the code runs. It wants human interaction for its responses. Because of this it should never be used for some sort of automation from a web service, com+, IIS, windows service, etc.
If you need to do automation from some sort of service (web service, com+, IIS, windows service, etc.), then you really should look at an API which was written to under such an environment. CDOEX, Exchange Web Service (EWS), WebDAV, REST and even CDO 1.21 can be used for server type processing (i.e. in a service).
Considerations for server-side Automation of Office
https://support.microsoft.com/kb/257757/en-us
The Outlook Object Model is unsuitable to run in a Windows service