About: Outlook Object Model (OOM)

API Type: Mailbox Accessor
API Interface: COM Library
Business Logic: Richest Outlook item support (Mail, Tasks, Calendar, etc.).
Language Support: All COM compatible languages including .NET.
Direct Property Access: Only available in OOM for Outlook 2007 and later.
Outlook Object Model (OOM) is a COM library which automates Outlook.EXE.  While it doesn't provide every configuration option and feature of the Outlook UI, it does provide a rich object model for working with Outlook IPM types.   OOM objects can be use by outlooks in-application VBA, under managed cod (.NET) code and also under unmanaged code (C++, etc).
Points of Interest:
  • OOM is built on top of Extended MAPI and is a part of Outlook.EXE.
  • A full install of Outlook needs to be installed on the machine OOM is used.  Installing Outlook components only is not supported.  Also see your Outlook EULA about distributing unlicensed Outlook components.
  • Even though it is build on top of Extended MAPI, it is still supported under managed code (.NET) process.
  • Because OOM is automating Outlook.EXE which is a desktop application it is not supported in a service (web service, windows service, ASP.NET, ASP, COM+, etc). An interactive user who can respond to visual UI prompts is required when OOM code is running.
  • Beware of known when using OOM in a .NET application be it a VSTO add-in, COM add-in, or standalone application.  Because of the way Outlook attempts to reuse item references in the UI, there are many issues that can come up in .NET solutions that use OOM if items are not explicitly released when a reference is created.
  • Outlook 2007's object model added support for working with Rules and even adds the PropertyAccessor for working directly with MAPI properties.
  • An application automating OOM needs to run at the same integrity/elevation level as Outlook. Outlook runs at medium IL.  Process Explorer can show you the elevation levels.
  • In an add-in OOM is only supported on the main thread.
  • its possible to mix the usage of OOM and Exchange Web Services in an application since EWS can convert item identifiers used by different APIs.  I've seen this mixture occasionally in Outlook add-ins.
  • You need to understand the issues with bitness when building applications using Outlook Object Model (OOM).  If you do not then you may likely run into issues during deployment.
  • Outlook PIA's (Primary Interop Assemblies) are overall forward compatible.  However, you may have issues if you build an application for one version of Outlook but use it with an older version.

More Information:

Office Developer Documentation

Office client development

Welcome to the Outlook 2013 developer reference

Outlook 2007 Developer Reference

How Do I ... in Outlook (2007)

Microsoft Office Outlook 2003 Visual Basic Reference

Outlook Automation is for People, not for Services.

Known issues in Outlook 2010 when you use the object model
This article covers a very common scenerio which developes run into - their application and Outlook running at different elevation/integrity levels.  See the section "Cannot create Outlook.Application object from an elevated process" which states "You cannot automate Outlook by using a process that is running with elevated permissions in Windows Vista, in Windows 7, or in any other operating system that allows for running processes with elevated permissions. This is an underlying limitation of the COM. Both Outlook and custom programs that automate Outlook must be running at the same integrity level."

OOM.NET - issues with releasing memory under .NET

Why is OOM code leaking items????

Development : Threading with Outlook Object Model?

Outlook Crashes When Using Outlook Object Model in Multiple Threads

HOWTO: VB/OOM - Display a message using Store ID and item ID

How to convert Exchange Item’s EntryID to EWS unique ItemId via EWS Managed API ConvertId call?

EWS Identifiers in Exchange

Code running against Outlook is very slow when PST or OST is on a network folder or non-physical/VHD drive

Selecting an API or Technology for Developing Outlook Solutions

Exchange and Outlook Development Help


Any CPU is best to ONLY be use pure .NET code applications and not when you have .NET code using COM objects. If you use COM components in your add-in then you need to be sure that you have builds targeted for the platform you are targeting. Not targeting for x86 or x64 may get you into trouble at deployment time. As an example if you use a 32bit COM component on a 32bit version of Windows and 32bit version of outlook while developing you will find that the code may not work on a 64bit system running 32bit version of Outlook if you compile as Any and don’t release with 64bit versions of those COM components. Any CPU will be handled as 64bit on a 64bit system and since you cannot mix 32bit COM objects in a 64bit process (or 64bit COM components in a 32bit process) the code will fail. Likewise, if you target your project as x86 and try to use it on a 64bit version of Outlook then it won’t work either.

Bitness : How to identify Outlook 2010 installation is a 32-bit or 64-bit?

Example: Outlook 14.0 32bit under 64bit Windows 10 the bitness flag is x86 here:

  • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\14.0\Outlook

Example: Outlook 14.0 32bit under 64bit Windows 10 the bitness flag is x86 here:

  • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\Outlook

64-bit editions of Office 2010

How to: Check the Version of Outlook

How to: Determine Whether Outlook Is a Click-to-Run Application on a Computer

Developing Outlook 2010 Solutions for 32-Bit and 64-Bit Systems

Large Examples:

Introducing OOMExplore



Also see:

About: Mailbox Accessing APIs

About: VSTO for Outlook

Exchange and Outlook Development Help


Comments (0)

Skip to main content