[OT] MAPI.Session and NT Service Accounts

[maa]

Hi,

The question is a bit off topic as it's not Perl that seems to be causing my headache and you guys are a mine of useful nuggets...

I've written a mailbox monitor program in perl but I want to run it as a service. I have run other perl programs as service using Win32::Deamon and they're fine.

As this is email I'm using Win32::OLE to create either a MAPI.Session object or an Outlook.Application object depending on which straw I'm clutching at.

All the variations I've tried which run from the a console under my own context or under the service account's context (interactive) or even remotely using psexec (non-interactive) fail when I try to start them from Server Manager

They fail with 0x80040154 - "class not registered" for Outlook.Application and MAPI.Server

Does anyone know why or any workarounds for connecting to a MAPI store using a Windows NT Service Account? I've searched the web/usenet without much luck (other than install Exchange Sp2 - but I don't need/have Exchange)

Sorry for rambling... any help greatly appreciated.

--
Mark

[FitTrend]

Without seeing any code, I will speculate that the NT Service account is logging on as a user that doesn't have the correct rights to your OLE objects. I've run into these types of problems before using the default login user of LocalSystem. For testing purposes, make the default login a different user (or admin for testing) and see if it works.

LocalSystem, cannot access certain resources like network resource by default.

Hope this helps

[maa]

thanks, FitTrend

I may resort to using LocalSystem then calling Win32::AdminMisc::LogonAsUser although I'm not sure it would make a difference - the account has all the appropriate network access and has local admin rights.

[gellyfish]

Are you using a MAPI profile of another local user on the machine? And when you are getting it work from the Console is that User logged in to the machine? If so then you are possibly experiencing on old COM/DCOM problem whereby the registry hive for the user that the component is run as is not loaded, you can test this by creating another no-op service that runs as the user who owns the profile and running it or running your original service as that user.

Alternatively it could be some problem with the permissions on the MAPI component - you can check these using the dcomcnfg tool (just start it from the command line).

Or you might simply just be experiencing the problem described here

/J\

[NetWallah]

MAPI and OLE-based Mail solutions are difficult to setup, and very error-prone during their life. It is a lot better to use SMTP-based mail, which works well in an Exchange environment.

Here is working code that I wrote for a mail-monitoring situation :

Read more... (10 kB)

[maa]

thanks, NetWallah

I'll have a look at this but I don't think it's suitable due to what I want - I may have to resort to LDAP/SQL queries using ADO records (or just run it interactively and dedicate a workstation :-)

[maa]

Thanks for your wisdon so far... to answer the points raised:

The service account

the service account I got set up is a domain account with access to all the network resouces required including the mailbox I want to monitor - I've even given it local admin rights on the workstation(s) to no avail

MAPI/Exhange Profiles

I'd thought of that... if I actually log on interactively as the service account everything works. I created an Outlook profile in Control Panel but it works without that if I specify a correct connection string ($server . chr(10) . $alias) for Session.Logon

SMTP

this isn't suitable as sending emails isn't what I'm doing. I want to generate a request ID for the email and add it to the subject line and Categories field then ->Move($folder) or ->Save() the item and log some info in a database using Win32::ODBC (which all works fine interactively)...

I knew MAPI was a complete pain but a service account was the sensible option... perhaps I should bite the bullet and install Exchange Administrator to see if that helps (it may be CDO.dll that's missing but the registry tells me that the classes are all defined by OLEMSG32.dll which is there and registered correctly.

Any other suggestions?

[maa]

Thanks for all the suggestions - I've now managed to make it work.

By copying CDO.DLL into C:\WINNT\SYSTEM32 and registering that (from Exchange Admin) the class becomes available (even though it claimed to be there before!).

I needed to set Win32::OLE->Initialize(Win32::OLE::COINIT_OLEINITIALIZE) in a BEGIN block to match up the threading model though.

--
Mark