The Outlook Object Model is unsuitable for use from an
application designed to be run as, or spawned by, a Windows NT service. This
includes Active Server Page (ASP) applications running under Internet
Information Service (IIS), and applications being run with the AT Scheduler or
Task Scheduler services.
This is a design limitation of Outlook.
The Outlook Object Model has four major limitations that
make it unsuitable for use in a Windows NT service. These limitations are:
- MAPI stores profiles for each user under the
HKEY_CURRENT_USER hive of the registry, this registry hive is not loaded when
a Windows NT service runs. This particular issue can be quite deceptive,
because during a development cycle, the developer is usually logged onto the
system interactively cause the HKEY_CURRENT_USER hive to be loaded, so
everything works as expected. Once the service is tested without the owner of
the profile logged on interactively the service will fail to locate the
- Only one instance of Outlook (the application that exports
the Outlook Object Model) can run at a time in one user context using a single
profile. Any attempts by the same user to logon using a second profile results
in joining the existing Outlook session. Attempts to start another copy of
Outlook (or the Outlook Object Model) from a different user context (for
instance, an application that impersonates a different user, such as a Windows
NT service) fails with unpredictable results ranging from; a modal dialog box
to an application error causing Outlook to stop responding to the system.
- The Outlook Object Model always starts the MAPI spooler
when logging on. MAPI client applications implemented as Windows NT services
must follow several limitations when logging onto the MAPI subsystem. As
Outlook was not designed to run as a Windows NT service, these conventions
were not followed.
For more information regarding this point, see the
MSDN topic "Windows NT Service Client Applications."
- It is possible to perform some actions using the Outlook
Object Model that raise modal dialog boxes that cannot be prevented and require
user intervention. This would have the affect of causing the Windows NT service
application to appear to hang.
If possible, use CDO or Extended MAPI code in your Windows NT
service instead of the Outlook Object Model.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
Considerations for server-side automation of Office