The Outlook Object Model (OOM) is unsuitable for use from an application that is designed to be run as, or spawned by, a Windows Service application. This includes Active Server Page (ASP) applications that run under Internet Information Service (IIS), and applications that run together with the AT Scheduler or Task Scheduler services.
OOM is an automation model for Outlook that is designed to run in a logged-on users session in which a user can respond to dialog boxes.
This is a design limitation of Outlook.
OOM has four major limitations that make it unsuitable for use in a Windows Service applications, as follows:
- MAPI stores profiles for each user under the HKEY_CURRENT_USER hive of the registry. This registry hive is not loaded when a Windows Service application runs. This particular issue can be quite deceptive because, during a development cycle, the developer is usually logged on to the system interactively. This causes the HKEY_CURRENT_USER hive to be loaded so that everything works as expected. After the service is tested without the owner of the profile logged on interactively, the service fails 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 by using a single profile. If the same user tries to log on by using a second profile, this attempt joins the user to the existing Outlook session. If the user tries to start another copy of Outlook (or OOM) from a different user context, the attempt fails. For example, if an application impersonates a different user, such as a Windows Service application, the attempt fails. This failure has unpredictable results, such as a modal dialog box or an application error that causes Outlook to stop responding to the system.
- OOM always starts the MAPI spooler during logon. MAPI client applications that run as Windows Service applications must follow several limitations when they logging on to the MAPI subsystem. Because Outlook was not designed to run as a Windows Service application, these conventions are not followed.
For more information, see the following Docs article:
- Some actions that use the OOM raise modal dialog boxes that cannot be prevented and that require user intervention. This would cause the application to seem to hang.
We recommend that you use Extended MAPI code instead of the OOM in your Windows Service applications. If the code does not have to work with Outlook directly and can, instead, run against the mailbox in Exchange, you should consider using Exchange APIs, such as Graph, Exchange REST, and Exchange Web Services (EWS).