Outlook object model evaluation criteria
Published: July 16, 2012
Find evaluation criteria for using the Outlook object model (OOM) to develop messaging and calendaring applications.
Applies to:
In this article
Functional criteria for the Outlook object model
Development criteria for the Outlook object model
Security criteria for the Outlook object model
Deployment criteria for the Outlook object model
Additional resources
Applications that run on the client computer can use the Outlook Object Model (OOM) to programmatically access contacts, messages, calendar items, meeting requests, tasks, and Outlook configuration information from the Exchange store. Before you can take advantage of OOM, you need to ensure that the client computers on which you are running your custom application have Outlook installed.
The following table lists and describes the functional criteria for the Outlook object model. For descriptions of the functional criteria, see Functional criteria in the Exchange development technology evaluation criteria descriptions article.
Criterion | Description |
|---|---|
Application function | Applications that use OOM typically perform user-specific message handling, mailbox cleanup, and so on. In environments where Outlook is consistently available, you can create small custom applications that use OOM, instead of more complex development technologies, to make changes in the user's mailbox. OOM is used for message processing in an ad-hoc workflow process, especially where access to the Exchange server is not permitted. |
Availability | OOM is currently available in all versions of Outlook, and each new version of Outlook includes extensions and improvements to OOM. OOM is not available with Exchange Online. |
Application architectures | OOM is typically used in macros and scripts to extend Outlook and other Office applications. In addition, OOM can be used in Visual Basic and WSH applications. |
Remote usage | OOM can only be used on a computer on which Outlook is installed. OOM can be used to access information stored in Exchange that is available in Outlook. |
Major objects | The top-level OOM objects represent the Outlook application, Inspectors, reminders, and other settings. Messages, tasks, contacts, and other Exchange-related items appear under the Namespace object, which contains AddressLists, SyncObject, and PropertyPages interfaces. The Folders object contains a collection of items, each of which can have other objects as appropriate to the type of item. |
Data access model | OOM represents all data as a hierarchical set of objects and collections. |
Threading models | Application threading is dependent on the client application architecture. |
Transactions | OOM does not support transactions. |
Management capabilities | OOM has no built-in management capabilities. |
The following table lists and describes the development criteria for the Outlook object model. For descriptions of the development criteria, see Development criteria in the Exchange development technology evaluation criteria descriptions article.
Criterion | Description |
|---|---|
Languages and tools | OOM applications can be implemented by using any COM/Automation-compatible language, as well as non-COM languages such as C/C++. |
Managed implementation | OOM contains a primary interoperability assembly that enables you to use the technology in a managed-code environment. |
Scriptable | OOM can be used by scripts such as WSH. |
Test/debug tools | No special debugging tools are required to use OOM. |
Expert availability | Developers who can successfully create scripts and macros that use OOM are easy to find. |
Available information | Information about programming by using OOM is available in both Microsoft and third-party books. For more information about OOM, see Microsoft Outlook Object Model on MSDN. |
Developer/deployment licensing | Refer to your Exchange and MSDN subscription licensing agreements to determine whether additional licenses are required for Outlook and OOM used in your applications. |
The following table lists and describes the security criteria for the Outlook object model. For descriptions of the security criteria, see Security criteria in the Exchange development technology evaluation criteria descriptions article.
Criterion | Description |
|---|---|
Design-time permissions | You do not need any specific permissions to develop applications by using OOM. |
Setup permissions | You do not need any specific permissions to install applications that use OOM. However, you do need local administrator permissions to install Office and Outlook. |
Run-time permissions | You do not need any specific permissions to run applications that use OOM. |
Built-in security features | OOM communicates with Exchange by using MAPI and with Active Directory and Active Directory Domain Services (AD DS) by using ADSI. The current security context of the user running the application determines what resources the script can access. |
Security monitoring features | OOM does not provide any additional security monitoring features. |
The following table lists and describes the deployment criteria for the Outlook object model. For descriptions of the deployment criteria, see Deployment criteria in the Exchange development technology evaluation criteria descriptions article.
Criterion | Description |
|---|---|
Server platform requirements | OOM is a client-side technology. The server requirements are based on the version of Outlook that is installed on the client computer. |
Client platform requirements | Applications that use OOM to access Exchange data require that Outlook be installed on the local computer. |
Deployment methods | Applications that use OOM are frequently distributed as scripts, or by using standard application installation software. |
Deployment notes | Because Outlook should not be installed on the Exchange server, applications that use OOM cannot be run on the Exchange server. |
Date | Description |
|---|---|
July 16, 2012 | Initial publication |
