roboticus,
I came to a similar idea based on a question posed by BrowserUk who asked if I was sure if the account the service was running as had sufficient privilages. While I was sure that it did, I wasn't sure it would attempt to access the correct mailbox. I haven't tried it yet, but I do have some updates to share.
The ActiveState PDK includes a tool called PerlSvc that does seem to work. It creates an "exe" and the service wraps around that. The price tag is steep ($195 or $295 for the pro edition). What I am unsure of is if it will work with Outlook when I am not logged in. The code tries to attach to an existing Outlook process before attempting to start a new instance. When I got what I believe to be a successful test run, I was already logged in with Outlook open so it really wasn't a complete test. I am using a 21 day trial for now while I test out a few other ideas.
While I haven't been able to get it to work, example 5 in the Win32::Daemon docs looks to be the simplest complete example that would make converting an existing application fairly trivial. I have gotten example 1 to work (minus Outlook) so it does look very promising assuming I can work out my Outlook issues.
If I find that the only stumbling block preventing my application to work as a service is interfacing Outlook (assuming I can't resolve those issues), then I will leave it up to the person in charge to decide on a solution. (run it as a scheduled task and not as a service, drop Outlook and move to POP/SMTP modules, pay for the PDK assuming a complete test works, fire me, etc).
| [reply] |
Limbic~Region:
Here in the salt mines, our security is tied down pretty tightly, so applications attempting to access an Outlook session from a different process invoke a dialog box for the user to key in their password to give the application access to Outlook. Perhaps you're running into something like that? You might be able to test it by RDPing into your computer with a different account and trying to access the Outlook session you already have running. (IIRC, another way you can see if the service account is opening a dialog box is by looking at the Event Viewer | Applications page.)
Other than that, I can't think of anything.
(I'm quite selfishly hoping you'll be successful, as I tried to get an automatic process to load EMail from Outlook into a database so I could search / archive / categorize / graph it more easily. I got access, but the aforementioned security problem stonewalled me. I'll try to think on it some more and/or dig up my OutlookDB project and see if I can come up with something.)
...roboticus
| [reply] |
roboticus,
You may want to have a look at the Advanced Security add-in for Outlook. This allows you to tell Outlook to trust certain applications for certain activities permanently rather than being annoyed by the pop-ups. It doesn't sound like that is exactly what your problem is though. Read on for ideas on that.
First, you can run a service as any account you want - it doesn't have to be the system account. This means you can have the service running as the owner of the mailbox and that might solve your problems. If you are using Outlook as your client and Exchange as your server, you can also modify the permissions on the mailbox to allow another user to have full access without prompting for passwords. Of course, this all highly depends on your environment and local policies. None of this happens to help me solve my problem but it might help you with yours.
| [reply] |