Article ID: 237913
Article Last Modified on 9/8/2005
APPLIES TO
- Microsoft Office Outlook 2003
- Microsoft Outlook 2002 Standard Edition
- Microsoft Outlook 2000 Standard Edition
- Microsoft Outlook 97 Standard Edition
- Microsoft Outlook 98 Standard Edition
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
Additional query words: OL97 OL98 OL2000
Keywords: kbinfo kboutlookobj kbmsg kbprogramming kbfaq KB237913
