How to create a trusted Outlook Component Object Model (COM) add-in in Outlook 2002

This article describes how to create a trusted Outlook 2002 Component Object Model (COM) add-in.

Note This article uses the term trusted to mean that an Outlook COM add-in is registered in the Outlook 10 Security Settings folder. This article does not use trusted to mean digitally signing a COM add-in. This is how the term is typically used for other Microsoft Office programs.

Outlook 2002 includes a new feature that permits Outlook COM add-ins to be trusted in the Outlook 10 Security Settings folder.

Note This option is not available for Microsoft Outlook 2000. Even if you configure an Outlook 2000 computer to use the custom settings on the Outlook 2002 security form in the Outlook 10 Security Settings folder, the option is not available. Note that Outlook 2000 is not designed to retrieve or to implement the custom security settings for COM add-ins.

To create a custom setting that operates on a per-solution basis in Outlook 2002, you must register a COM add-in in the Outlook 10 Security Settings folder. All the other settings (mostly available on the Programmatic Settings tab of the form) apply to all solutions. Therefore, if you lower the security setting on the Programmatic Settings tab, this inherently increases the risk of exposure to malicious code. Microsoft recommends that (if at all possible) you create a trusted Outlook solution by creating an Outlook COM add-in and then registering it in the Outlook 10 Security Settings folder.

For additional information about how to create an Outlook COM add-in, click the article number below to view the article in the Microsoft Knowledge Base: For additional information about how to implement the custom security settings for Outlook, including the Outlook 10 Security Settings folder, click the article number below to view the article in the Microsoft Knowledge Base:

Limitations of Trusted Outlook COM Add-Ins

When you develop a COM add-in that will ultimately be trusted, there are some key limitations that you must consider when you design either your solution or the COM add-in.

Only Outlook COM Add-Ins Can Be Trusted

You cannot trust COM add-ins that will be used in other Office programs. COM add-ins run in the host program's process. For the trust to work, a COM add-in must be running in the Outlook process.

Only the Main Application Object Is Trusted

When you use the Outlook object model in the COM add-in, only the main Application object that is passed to the OnConnection event is trusted. If you create a new Application object, by using the CreateObject method that object and any of its subordinate objects, properties, and methods are not trusted.

This objTrustedItem object is trusted because it is referenced by using the trusted Application object.

Additionally, if you implement an event in the Outlook object model, and an object is passed to that event (typically an Item object), that object is not trusted. This is a limitation of the implementation by Outlook of events in trusted COM add-ins. However, to work around this limitation you can reference the item from the trusted Application object. For example, from the NewInspector event, the following code references the new inspector by using the trusted Application object.

This code must follow the new text: Note The common workaround of saving the new item so you can retrieve its EntryID property can cause unintended side effects, including, but not limited to, crashes. Therefore, Microsoft strongly discourages you from using this workaround.

Collaboration Data Objects (CDO) Cannot Be Trusted

Outlook does not provide a means to the CDO object library if you use the CDO object library in an Outlook COM add-in. If you want to trust the CDO object library, you must enable the user-level custom security settings on the Programmatic Settings tab of the security form in the Outlook Security Settings folder. However, this permits CDO to be trusted for any code that may use that object library.

Microsoft ActiveSync and Other Applications May Affect COM Add-Ins

If you re-enable the add-ins in the scenarios that are described in this article, these add-ins are not trusted. The add-ins are not trusted because the add-in was not started through the standard process.

For additional information about this issue, click the article number below to view the article in the Microsoft Knowledge Base:

Troubleshooting Trusted COM Add-Ins

If you register your COM add-in in the Outlook 10 Security Settings folder, but the add-in does not appear to be trusted, make sure that you consider the following issues:

• The COM add-in that is registered in the public folder must exactly match the add-in that is installed in Outlook. You cannot recompile the add-in without registering the new version in the public folder.
• Make sure that Outlook is actually retrieving custom settings from the Outlook 10 Security Settings folder. One way to do this is to change an attachment extension setting, and then make sure that the attachment extension is trusted or not trusted. If Outlook does not appear to be retrieving custom settings at all, use one or more of the following methods, depending on your circumstances:
  • Make sure that the CheckAdminSettings registry key is set on the client. For Outlook 2002, this value must typically be set to 2. This corresponds to the Outlook 10 Security Settings folder. You can use a registry key tracking tool such as RegMon to make sure that Outlook is accessing the registry key when Outlook starts. To obtain RegMon, visit the following Sysinternals Web site:
    http://technet.microsoft.com/en-us/sysinternals/default.aspx (http://technet.microsoft.com/en-us/sysinternals/default.aspx)
  • Quit Outlook, and then make sure that the Outlook.exe process is not running when you restart Outlook. You can use the Windows Task Manager to do this. If Outlook is still running in the background, it will not retrieve the CheckAdminSettings registry key, and therefore it will not retrieve custom settings from the public folder.
  • Note that Outlook always uses the last security settings item that was created for the user. The timeframe when an item is modified is not a factor. For example, if you create an exception item before a default item, the default item always wins, even if the user in question is on the exception item. The Default Security Settings item must always be created first.
• If you are using Microsoft Visual Studio .NET to create the COM add-in, note that you must take some extra steps for these add-ins to work with Office programs. Office add-ins use a COM architecture, whereas Visual Studio .NET add-ins use a managed code architecture. Architectural changes in Visual Studio .NET also affect the ability to trust Outlook COM add-ins. For additional information about how to create a trusted Outlook COM add-in with Visual Studio .NET, click the article number below to view the article in the Microsoft Knowledge Base:
  322027  (http://support.microsoft.com/kb/322027/EN-US/ ) OL2002: COM Add-Ins Are Not Trusted If They Are Created with Visual Studio .NET

For additional information about available resources and answers to frequently asked questions about Microsoft Outlook solutions, click the following article number to view the article in the Microsoft Knowledge Base: