Introducing CDO for Exchange Management Objects

CDOEXM facilitates Exchange 2000 administration

Collaboration Data Objects (CDO) is a generic set of components that you can use to build rich collaborative applications. Administrators have long used this client-side tool to build applications in Exchange Server 5.5. Microsoft has taken CDO one step further in Exchange 2000 Server by introducing three new server-side CDO components:

You can use CDOEX, CDOWF, and CDOEXM only with Exchange 2000 on a Windows 2000 platform. (Although Exchange Server 5.5 supports CDO, you can't use these new CDO components with that version of Exchange.) Although all three CDO components are useful, CDOEXM especially can make your job as an Exchange administrator easier. With CDOEXM, you can easily manage Exchange 2000 mailbox stores and the users who access them. Before I show you how to make your job easier with CDOEXM, let's take a brief look at the management tools you get out of the box with Exchange 2000 and their shortcomings. (For more information about the other two CDO components, see the sidebar "A Bit About CDOEX and CDOWF.")

The Tools and Their Shortcomings
Exchange 2000 doesn't include a Directory Service (DS). Instead, Exchange 2000 stores all directory information, including configuration and user information, in Win2K's AD store. The configuration information includes the names of servers in which you've installed Exchange 2000 and the storage groups (SGs) and databases on each server. AD's User, Group, and Contact objects contain attributes that hold Exchange-specific user information.

From an administration viewpoint, Exchange Server 5.5 and Exchange 2000 differ greatly. With Exchange Server 5.5, you use one tool to administer both configuration and user information, whereas with Exchange 2000, you use two tools:

You use the Active Directory Users and Computers snap-in to manage the Exchange-related attributes of AD's User, Group, and Contact objects. For example, to create a mailbox, you use the Active Directory Users and Computers snap-in to mailbox-enable a User object. (Mailbox-enabling a User object generates an email address for the user and creates an Exchange 2000 mailbox that receives messages that people send to this address.) You use the Exchange System Manager snap-in to manage configuration information. For example, to specify default SMTP addresses, you define recipient policies with Exchange System Manager.

Having Exchange 2000 information in the AD store and having two tools to manage that information begs several important questions that companies must answer: Will AD administrators let Exchange administrators manage Exchange-related user information? If so, will AD administrators let Exchange administrators use the Active Directory Users and Computers snap-in? If Exchange administrators use the Active Directory Users and Computers snap-in, how will AD administrators restrict Exchange administrators to manipulating only Exchange-related information?

Assuming that the AD administrators let the Exchange administrators run the Active Directory Users and Computers and Exchange System Manager snap-ins, having two tools can make management harder, as the following example illustrates. Suppose you use the Exchange System Manager snap-in to drill down to a mailbox store on a particular server to view the store's mailboxes. You see the mailboxes that Figure 1 shows. You decide that you want to move half of these mailboxes to a new mailbox store on the same server. To accomplish this simple task, you must first fire up the Active Directory Users and Computers snap-in. As Figure 2 shows, the information in the Active Directory Users and Computers snap-in bears no resemblance to the information in Exchange System Manager. Thus, you must try to find and identify the appropriate User objects among all the other objects in the Active Directory Users and Computers snap-in. After you've finally found all the User objects (having switched between the two snap-ins many times to make sure you have found the correct users), you can finally invoke the Move Mailbox task. This type of operation will be common in organizations in which people regularly move between departments or locations (e.g., ISPs, large companies).

If you want to avoid using two management tools, you can take advantage of CDOEXM to unify common tasks and present those tasks in one Web-based or MMC-based interface. In addition, you can use CDOEXM to provide the exact AD functionality that Exchange administrators require, without needing to give them access to the Active Directory Users and Computers snap-in.

CDOEXM's Interfaces and Classes
CDOEXM is a collection of interfaces and COM classes aggregated into CDO and Microsoft Active Directory Service Interfaces (ADSI) classes. CDOEXM encapsulates and simplifies many programmatic tasks that are specific to managing Exchange 2000, such as managing Exchange 2000 servers, mailbox stores, public stores, public folder trees, SGs, and Exchange recipients (i.e., users, contacts, and groups).

CDOEXM installs automatically when you install the Exchange System Manager snap-in. You can also install CDOEXM on a separate computer and use that machine to manage your Exchange 2000 servers remotely. For example, if you want to run the Exchange System Manager snap-in on a Win2K Professional machine, you can run the Exchange 2000 setup program and select Server Management Tools from the listed components. This selection installs the Exchange System Manager snap-in and the CDOEXM library.

The interfaces that the various CDOEXM classes implement are Automation-compatible, which means you can use them in programming and scripting languages such as Microsoft Visual Basic (VB), Visual C++ (VC++), VBScript, and JScript. Because you can use the interfaces with VBScript and JScript, you can use CDOEXM inside Windows Management Instrumentation (WMI) scripts and Active Server Pages (ASP), thereby enabling Web-based management.

Two interfaces of particular importance are IMailboxStore and IMailRecipient. You can use these interfaces in conjunction with information in CDOEX and ADSI objects to accomplish tasks such as creating, moving, and deleting mail-enabled and mailbox-enabled objects. In addition, these interfaces let you set mailbox properties that specify size limits, forwarding addresses, and proxy addresses. Similarly, you can use these interfaces to mail-enable Group and Contact objects and set properties that specify such information as whether to hide an object from address lists. Therefore, the IMailboxStore and IMailRecipient interfaces remove the need to use the Active Directory Users and Computers snap-in.

CDOEXM delivers five main COM classes: ExchangeServer, FolderTree, StorageGroup, PublicStoreDB, and MailboxStoreDB. The following descriptions briefly describe these classes. You can obtain the full details of all the CDOEXM, CDOEX, and CDOWF classes and interfaces in the Web Storage System SDK. You can download this software development kit (SDK) from the Microsoft Developer Network (MSDN) Online Web Storage System Web site (http://msdn.microsoft.com/wss).

ExchangeServer. The primary interface for the ExchangeServer COM class is IExchangeServer. This interface lets you access properties of the server running Exchange 2000. These properties contain information such as the server's name, whether it's a front-end or back-end server, the version of Exchange on the server, and the storage groups (SGs) on the server. These properties also let you set server characteristics, such as enabling and disabling message tracking. If you have a mixed-mode environment, some properties (e.g., the properties that specify the server name) are available for Exchange Server 5.5 servers because the AD store holds this information in its Configuration container.

FolderTree. The primary interface for the FolderTree COM class is IFolderTree. A public folder tree maps the contents of a public IS. Because Exchange 2000 can support multiple public ISs, you need multiple public folder trees to map their contents. You can map a public folder tree to only one public store per server. The IFolderTree interface lets you create new trees and read and set tree properties, such as the tree type. Two types of trees exist: Messaging API (MAPI) and general purpose.

StorageGroup. The primary interface for the StorageGroup COM class is IStorageGroup. An SG is a collection of public and private databases. Because all the databases in an SG share a common set of logs, the IStorageGroup interface lets you manipulate log settings. For example, you can set circular logging or set the database pages to zero after backups. In addition, the IStorageGroup interface provides methods to move the storage group's logs and system files.

PublicStoreDB. The primary interface for PublicStoreDB COM class is IPublicStoreDB. You can use this interface to set many properties, such as the age limit for items in the database and the length of time the database retains deleted items. Methods exist to mount and dismount the database as well as move the database files. Programmatically mounting and dismounting databases can be useful for automated backup routines.

MailboxStoreDB. The primary interface for MailboxStorDB COM class is IMailboxStoreDB. This interface has several interesting properties that relate to mailbox limits, such as the size at which sending and receiving mail is prohibited. This interface also has a property that specifies the Offline Address Book (OAB) associated with the database.

Web-Based Management
As I previously mentioned, you can use CDOEXM in .asp files and WMI scripts. WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which provides uniform access to management information. Exchange 2000 is both a provider and a consumer of WMI. The Exchange 2000 WMI providers enable Web-based administration programs to report on the health of message queues and connector states.

The Web Admin Tool is a good example of Web-based administration that uses CDOEXM, WMI, and ADSI. This tool uses CDOEXM's ExchangeServer, StorageGroup, and MailboxStoreDB COM classes to manipulate Exchange 2000 accounts. You can download the Web Admin Tool from the Microsoft Internet Services Network Web site (http://www.microsoft.com/isn).

CDOEXM Knowledge Is Key
Not every Exchange administrator wants to learn how to program, and not every administration task can be performed programmatically. For example, you can't use CDOEXM to support clusters or manage virtual servers, recipient policies, or address lists. However, every Exchange administrator needs to understand CDOEXM's capabilities. With this knowledge, Exchange administrators can find someone with the skills to create an administration environment that suits their needs so that they aren't tied to the standard offerings.