This documentation is archived and is not being maintained.

Extending Microsoft Outlook 2000

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

Jim Groves
Microsoft Corporation

June 1999

Applies To: Microsoft Outlook 2000

Summary: This article introduces enhancements that have been made to Outlook 2000 to make it an even more powerful platform for developing messaging and scheduling solutions. These enhancements include folder home pages, native support for Visual Basic for Applications, and support for COM add-ins. (7 printed pages)


When Microsoft® Outlook® 97 was introduced, it blazed new trails by integrating e-mail with such personal-information manager (PIM) features as scheduling, to-do lists, and contact management. Its easy-to-use interface simplified common tasks such as organizing meetings and assigning work items. It could be customized, giving users the ability to tailor Outlook to their particular needs.

Two generations later, Outlook 2000 has even more features and more flexibility. Its various modules are more tightly integrated than ever, and now even allow easy integration with corporate intranets and the World Wide Web. Still, many organizations want to be able to adapt Outlook so that it more directly supports their business practices.

Fortunately, Outlook has been designed to be highly customizable. Long-time Outlook users know that most Outlook forms can be redesigned to present Outlook data in new ways. In addition, Visual Basic® Scripting Edition (VBScript) can be added to a form to provide additional control over how Outlook works. What makes this possible is the Outlook object model, a powerful interface to Outlook's services that makes it easy to develop programs that can take advantage of Outlook's many talents. As Outlook has evolved, its object model has become ever more versatile, giving developers much greater access to the application and its services. Especially important additions for Outlook 2000 include:

  • Enhanced control over inspector windows, explorer windows, and the Outlook Bar.
  • Numerous events to control navigation, attachments, name resolution, and sending messages.
  • Other events that provide notification when mail is delivered, when data has changed, and when objects have been added or removed.
  • Object model support for new features such as contact linking, distribution lists, and folder home pages.

These items are discussed in the article "What's New for Microsoft Outlook 2000 Developers."

In addition to extensions to its object model, Outlook 2000 adds three major avenues for extending Outlook:

  • Folder home pages, which replace the standard view of a folder with an HTML page. This makes it possible to add HTML and scripted pages of instructions, tips, policies, views or reports to any folder.
  • Native support for Visual Basic for Applications ("VBA in Outlook"). Now users can write macros that automate Outlook and that can respond to Outlook events.
  • Component object model (COM) add-ins. A COM add-in is a dynamic-link library (DLL) that implements a special interface and provides a method of extending Outlook that is simple to develop and yet very powerful.

The remainder of this article explores the benefits and drawbacks of extending Outlook 2000 by using folder home pages, VBA in Outlook, and COM add-ins, and provides a brief overview of what's involved in implementing an extension with these methods.

Folder Home Pages

An exciting new feature in Outlook 2000 is the ability to associate a folder with an HTML home page. The folder home page replaces the default folder view in the Outlook explorer window, allowing you to provide a fully customizable user interface to the folder and its contents. Script in the page can access the Outlook object model to retrieve information about the contents of the folder and open items in the folder, for example. You can combine the returned Outlook information with information from other data sources, such as Microsoft SQL Server™, to provide users with one interface to the different sources of data in their organizations. ActiveX® controls (such as the Outlook View Control discussed later in this section) can provide an even richer user interface.

Perhaps the most important benefit that folder home pages provide is the ability to integrate Outlook 2000 with a corporate intranet and with extranet sites. Through a folder home page, a user can access both Web content and information stored in an Exchange public folder without ever being aware of the source of the information—and without having to learn different user interfaces.

Folder home pages can also give you greater control over how users access the contents of folders. For example, you can filter out items that you do not want certain users to be able to access, and you can ensure that the information provided in a view of the folder contents is what you want users to see.

A carefully designed folder home page can also make it possible to give users access to folder contents through a Web browser without requiring the user to launch Outlook (although Outlook must be installed on the user's computer). This is especially useful for implementing solutions based on Outlook that do not expose all of Outlook's capabilities (such as e-mail). Of course, access by script to the Outlook object model is subject to the browser's security restrictions, so Web pages designed to access Outlook through a browser must be designed to work around this limitation. When a Web page is displayed in Outlook as a folder home page, however, it is not subject to browser security restrictions when the Web page accesses the Outlook object model.

Distributing a solution based on folder home pages could hardly be simpler. In the case of a public folder, all that is necessary is to publish the home page on a Web server and then use the public folder's Properties dialog box to link the folder to the home page. If you want to assign a home page to an individual user's folder, you can send a message containing VBScript that sets the WebViewURL property of the folder to point to the home page. Alternatively, you can add script to the home page that sets this property and mail to the user a link to the home page itself.

Perhaps one of the most important advantages to folder home pages is the broad range of tools that are available for developing Web pages. You can use everything from basic HTML editors to comprehensive environments such as Microsoft Visual InterDev® to produce the Web page. To make things even easier, you can use the Team Folders Wizard ( to create a home page template that you can then modify to meet your particular needs.

The Team Folders Wizard uses the Microsoft Outlook View Control, an ActiveX control that provides standard Outlook views in Web pages and Visual Basic applications. Even if you don't use the Team Folders Wizard as a starting point for your folder home page, you can use the Outlook View Control as an easy way to give your users access to the contents of the folder. You can even use the View Control in forms developed with VBA in Outlook, which is discussed in the next section.

VBA in Outlook

From the very first release, Outlook has supported customization based on Visual Basic in the form of VBScript "behind" forms. That is, developers who want to write code in Outlook to modify Outlook's default behavior can add VBScript to a custom form. Then, whenever an item is opened by using the form, the VBScript code can be executed, in response to either a user action (such as clicking a button on the form) or an item event (such as the item being sent).

Although this gives developers an effective means of customizing Outlook, it also suffers from a number of limitations, not the least of which is the requirement that an item of a particular type be open to make the code available for execution. This makes it difficult to use VBScript to customize the Outlook application itself, for example.

Most of the limitations of VBScript have been overcome through the addition of native support for VBA in Outlook 2000. For the first time, users and developers can use the Visual Basic Editor to write VBA macros and event procedures that are executed by Outlook itself. In addition, new system-level events and other additions to the Outlook object model make VBA in Outlook even more useful by giving the developer greater control over Outlook. (See "What's New for Microsoft Outlook 2000 Developers" for a detailed list of new methods, properties, and events added to the Outlook object model.)

Especially for experienced Visual Basic and VBA developers, VBA in Outlook is very easy to use. You work with the same Visual Basic Editor that is available in other Office 2000 applications. This environment provides a comprehensive set of tools that make it much simpler to create, edit, test, and debug code. The Visual Basic Editor incorporates an Auto List Members feature that speeds up code entry and reduces coding errors. For example, when you enter the name of an object and then a period, the Visual Basic Editor displays a list of the object's properties and methods. Microsoft Outlook Visual Basic Reference Help is context-sensitive; to see information about a keyword or object model element, just select the term in the Code window and press F1. And unlike the Outlook Script Editor with its separate debugger, the Visual Basic Editor has built-in debugging tools that allow you to debug and edit program code in the same window.

Unlike other Office 2000 applications, Outlook does not allow users to record macros by capturing interactions with the user interface and converting those interactions into VBA code. Despite this limitation, however, creating an Outlook macro is not difficult; anyone with a basic knowledge of programming with Visual Basic should be able to begin writing simple macros almost immediately. Because the Outlook 2000 command bar can be customized by the user and buttons can be attached to macros, users can now customize Outlook in much the same way as they can other Office 2000 applications.

In organizations where the network is set up to support roaming users (that is, users who log on at different workstations from time to time), users' VBA code for Outlook will be available wherever they run Outlook on the network. This is because the VBA code is stored in the user's roaming data area rather than on a particular workstation. (If the network is not set up to support roaming users, the VBA code is stored on the user's local computer.)

Although VBA in Outlook provides an excellent solution for customizing and extending Outlook, it does have some restrictions:

  • VBA code can be modified by the user unless the entire project is password-protected. This can create support problems if the user modifies code that has been distributed throughout an organization.
  • There is no simple way to distribute Outlook VBA code to users. Outlook is able to support only one VBA project at a time. Additional code cannot be added simply by attaching another project (as you do when you attach a new template to a document in Microsoft Word, for example). As a result, you must export the code to one or more module files, distribute those files to users, and then depend on the users to open the Visual Basic Editor and import the modules. An alternative would be to distribute an entire project file to users, but that would mean that any previous modifications to a user's project would be lost.
  • Users who write their own code or import code modules written by others will receive a warning message unless they either sign the VBA project or lower their macro security level. Because it is so easy to distribute code "embedded" in documents, VBA code in Office 2000 is treated much like ActiveX and script components. That is, users receive a warning about allowing the components to run unless the components are marked with a digital signature. This restriction holds true in Outlook as well, even though VBA code in Outlook cannot be easily distributed. Users who are annoyed by frequent warning messages may find it difficult to figure out how to obtain a certificate that will allow them to sign their projects, and so they may be tempted to lower their level of macro security, thus exposing themselves to malicious VBScript embedded in messages, for example.

Because of these drawbacks, VBA is not an ideal solution for extending Outlook for a large number of users in an organization. Even so, it provides a powerful tool for advanced users to customize Outlook for their own use, or to develop extensions for use in a small, self-supporting workgroup. The best way to automatically extend Outlook for a large number of users is one that combines the ease of programming available in VBA (and can even use VBA as a starting point) with the automatic installation of a compiled application. That combination is the COM add-in, discussed in the next section.

COM Add-ins

Without a doubt, one of the most powerful weapons in an Outlook 2000 developer's arsenal is the COM add-in. A COM add-in is essentially a dynamic-link library (DLL) that implements a predefined interface and is specially registered so that it can be recognized and loaded by an Office 2000 application. Because all Office 2000 applications support COM add-ins, you can write a single COM add-in that can be used to customize multiple applications. Even if you do not choose to create a single COM add-in to use with more than one application, much of the code written for one application (such as code that manipulates command bars, for example) can be used with other applications. This makes it possible to develop modules that can be shared among COM add-ins that have been designed for different applications.

Before COM add-ins became available, you could extend Outlook by using a Microsoft Exchange Client Extension, a specially designed DLL that allows developers to modify the Outlook user interface and access its object model. Exchange Client Extensions must be written in C or C++, however, and are considerably more difficult to implement than COM add-ins, which can be developed in any language that supports COM, such as Microsoft Visual C++®, Microsoft Visual J++®, and Microsoft Visual Basic. Because Exchange Client Extensions offer fewer benefits than COM add-ins, they are supported in Outlook 2000 mainly for the sake of backward compatibility. Developers creating new extensions for Outlook 2000 are encouraged to use COM add-ins instead.

You can use Visual Basic version 5.0 or later to create a COM add-in. The easiest way to do it, however, is to use Visual Basic version 6.0 and Microsoft Office 2000 Developer. Visual Basic 6.0 supports add-in designers that simplify the task of registering a COM add-in for use by Office 2000 applications. In turn, Office 2000 Developer provides a COM add-in template that includes an Office 2000 add-in designer and a reference to the IDTExtensibility2 library that supplies the events that make up the COM add-in interface. With Office 2000 Developer, you can even use the Visual Basic Editor to write and compile a COM add-in by using VBA in Outlook 2000.

Implementing this interface is a simple matter of adding procedures to handle the five events that constitute the COM add-in interface. Although an add-in module must contain procedures for all five events, the events need not actually do anything; simply putting a single comment in the procedure body is sufficient. However, because the events notify your COM add-in that it is being connected or disconnected or that the application is starting or shutting down, you will probably want to use these procedures to perform the sort of initialization and cleanup functions that you would normally do anyway.

Because a COM add-in is a compiled DLL, it is easy to distribute and install. Both Visual Basic 6.0 and Office 2000 Developer provide the Package and Deployment wizard, which automates the tasks required to prepare your COM add-in for distribution and installation.

Compared to other methods for extending Outlook, COM add-ins present only a few disadvantages. One slight disadvantage is that creating a COM add-in requires special tools (mainly Office 2000 Developer) and somewhat more advanced programming skills than would be required for, say, a VBA-only solution. For this reason, extending Outlook 2000 by using a COM add-in is more likely to be done in large organizations that can provide the necessary resources. As noted previously, small organizations or workgroups will probably find using VBA alone to be a more appropriate method for developing their Outlook extensions.


Outlook 2000 provides developers more options than ever before to help them adapt Outlook to their particular requirements. In addition to the customization options supported in previous releases, you can use folder home pages, VBA in Outlook, and COM add-ins to extend Outlook 2000.

Folder home pages are especially useful for integrating Outlook with the Internet or a corporate intranet. Developers have the flexibility of adding HTML and script to any folder. Users can work in the familiar browser environment, but still take full advantage of Outlook's messaging and scheduling capabilities.

Outlook's support for VBA means that users can customize Outlook to meet their particular needs. With a minimal knowledge of Visual Basic and the Outlook object model, a user can write a macro to automate a common task, for example, and associate that macro with a button on the Outlook command bar. VBA can also be used to respond to Outlook events, allowing users to customize how Outlook behaves.

Finally, COM add-ins combine the ease of development provided by VBA with the benefits of a compiled DLL that can be automatically loaded and run by Outlook. Virtually any solution that could be implemented as an Exchange client extension can be implemented more easily by using a COM add-in. Perhaps more significantly, because all Office 2000 applications support COM add-ins, these add-ins can be written for more than one application -- or at least, code that is written for a COM add-in for one application can often be reused in another application's COM add-in.