The Outlook Object Model is unsuitable to run in a Windows service (237913)


The information in this article applies to:

  • Microsoft Office Outlook 2003
  • Microsoft Outlook 2002
  • Microsoft Outlook 2000
  • Microsoft Outlook 97
  • Microsoft Outlook 98
This article was previously published under Q237913

SUMMARY

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.

MORE INFORMATION

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 profile.
  • 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.

Recommendation

If possible, use CDO or Extended MAPI code in your Windows NT service instead of the Outlook Object Model.

REFERENCES

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

257757 Considerations for server-side automation of Office

Modification Type:MajorLast Reviewed:9/8/2005
Keywords:kbProgramming kbFAQ kbinfo kbMsg kbOutlookObj KB237913 kbAudDeveloper
©2004 Microsoft Corporation. All rights reserved.