Lesson 2: CDO for Exchange Management

CDO for Exchange Management offers exciting opportunities for custom management solutions. Similar to Active Directory Services Interface (ADSI), CDOEXM enables you to access and manipulate Active Directory objects. Through Exchange 2000 Server management functionality, collaborative applications can mailbox-enable user accounts, define mailbox properties, create and delete mailbox and public stores, build public folder hierarchies, and configure Exchange 2000 Server as a front end or back end system.

This lesson introduces the main features of CDO for Exchange Management. As in Lesson 1, small VBScript code examples are provided to illustrate the management of Exchange 2000 Server resources via CDOEXM.

---

At the end of this lesson, you will be able to:

• Decide when to use CDOEXM and ADSI in a business solution.
• Handle the management of mailbox and public stores.
• Mailbox-enable user accounts.

Estimated time to complete this lesson: 35 minutes

---

Collaboration Data Objects Versus Active Directory Services Interfaces

CDO for Exchange Management is implemented in CDOEXM.DLL, which resides in the \Program Files\Exchsrvr\Bin directory. CDOEXM is based on ADSI to access Exchange 2000 Server-related resources in Active Directory via LDAP. It aggregates the COM interfaces of ADSI to simplify programmatic tasks that are specific to Exchange 2000 Server administration (see Figure 24.3).

CDOEXM extends the ADSI interfaces and simplifies the management of Exchange 2000 Server resources that reside in Active Directory. When working with resources in the Web Storage System, CDOEXM communicates with the Information Store service through the Exadmin virtual directory. The purpose and administration of HTTP virtual directories is discussed in Chapter 22, "Microsoft Outlook Web Access."

You should use CDOEXM, for instance, if you need to create mailboxes for new users, set mailbox properties, or mail-enable contacts or public folders programmatically. ADSI, on the other hand, allows you to develop powerful directory applications that can be used to administer the entire Active Directory environment. However, ADSI is unable to work with Web Storage System resources. You cannot use ADSI to mount or dismount mailbox or public stores, for instance.

Figure 24.3 Using CDOEXM and ADSI for Exchange 2000 Server management

CDO for Exchange Management Security Issues

Basically, CDOEXM allows you to create management applications similar to Exchange System Manager. You can use CDOEXM remotely to build administrative components and snap-ins that run on separate computers and access Active Directory over the network. However, to manage Exchange 2000 Server, appropriate permissions are required in the organization. There is no difference from Exchange System Manager. You need to have Exchange Administrator permissions if you want to manage an organization, as discussed in Chapter 19, "Implementing Advanced Security."

NOTE

---

CDOEXM applications require the same level of permissions as Exchange System Manager.

CDO for Exchange Management Object Model

The CDOEXM object model clearly reflects the structure of Exchange 2000 Server resources in Active Directory (see Figure 24.4). Every Exchange 2000 server can have mailbox and public stores, which are grouped together by means of storage groups. The purpose of storage groups and information stores was discussed in detail in Chapter 20, "Microsoft Exchange 2000 Server Maintenance and Troubleshooting."

Figure 24.4 The CDO for Exchange Management object model

Working with Information Stores and Public Folder Hierarchies

In addition to interfaces for server, storage group, mailbox, and public stores, CDOEXM also provides a FolderTree object. This object can be used to manage public folder hierarchies, which need to be associated with public stores. Keep in mind that public folder hierarchies can only be associated with one public store on a given Exchange 2000 server. It is also important to note that you cannot create public stores if all existing public folder hierarchies are already associated with existing stores. You can read more about the management of public folder hierarchies in Chapter 17, "Public Folder Management."

The following VBScript example creates a new alternate public folder hierarchy and then associates the hierarchy with a new public store (SCRIPT6CH24.VBS):

 '*-*-* Creating the required CDOEXM objects *-*-* Set oHierarchy = CreateObject("CDOEXM.FolderTree") Set oPubStoreDB = CreateObject("CDOEXM.PublicStoreDB") '*-*-* Creating the new PF hierarchy *-*-* strHierarchyURL = "LDAP://bluesky-srv1.BlueSky-inc-10.com/" _    & "CN=New Hierarchy,CN=Folder Hierarchies," _    & "CN=First Administrative Group,CN=Administrative Groups," _    & "CN=  Blue Sky Airlines,CN=MicrosoftExchange,"_    &"CN=Services,CN=Configuration,DC=BlueSky-inc-10,DC=com" oHierarchy.Name = "New Hierarchy" oHierarchy.DataSource.SaveTo strHierarchyURL     '*-*-* Creating the new public store *-*-* oPubStoreDB.Name = "New Hierarchy Store" oPubStoreDB.FolderTree = strHierarchyURL oPubStoreDB.DataSource.SaveTo _     "cn=New Hierarchy Store," _    & "cn=First Storage Group,cn=InformationStore,"_    &"cn=BLUESKY-SRV1,cn=Servers,cn=First Administrative Group," _    & "cn=Administrative Groups,cn=Blue Sky Airlines," _    & "cn= MicrosoftExchange,cn=Services,cn=Configuration," _    &"dc=BlueSky-inc-10,dc=com" '*-*-* Mounting the new public store *-*-* oPubStoreDB.Mount 

TIP

---

Further samples are available in the Exchange 2000 Server Platform SDK. They demonstrate how to simplify the creation of LDAP URLs based on the CDO.Server object.

Mailbox and Public Folder Management

When you examine the CDOEXM object model, you will find that explicit COM classes for recipient management are not exposed. Instead, the required CDOEXM interfaces are aggregated into existing CDO and ADSI CoClasses, such as CDO.Person, CDO.Folder, and ADSI.User. The CDOEXM recipient interfaces are IMailRecipient and IMailboxStore, which you can retrieve from CDO and ADSI objects by using the GetInterface method.

The following VBScript example demonstrates how to use a CDO.Person object to create a user account in Active Directory and mailbox-enable it using the CDOEXM IMailboxStore interface (SCRIPT7CH24.VBS):

 '*-*-* Creating a new user account *-*-* Set oPerson = CreateObject("CDO.Person")   oPerson.FirstName = "Geraldine" oPerson.LastName = "Goose"  oPerson.DataSource.SaveTo"LDAP://bluesky-srv1.BlueSky-inc-10.com/"_    &"CN=GeraldineGoose,CN=Users,DC=BlueSky-inc-10,DC=com" '*-*-* Mailbox-enabling the user account *-*-* Set oMailbox = oPerson.GetInterface("IMailboxStore") oMailbox.CreateMailbox _      "CN=Mailbox Store (BLUESKY-SRV1),cn=First StorageGroup,"_    & "cn=InformationStore,cn=BLUESKY-SRV1,cn=Servers," _    & "cn=First Administrative Group," _    & "cn=Administrative Groups,cn=Blue Sky Airlines," _    & "cn= MicrosoftExchange,cn=Services,cn=Configuration," _    & "dc=BlueSky-inc-10,dc=com" oPerson.DataSource.Save 

Of course, you can also mailbox-disable a user account by deleting its mailbox using the CDOEXM IMailboxStore interface (such as oMailbox.DeleteMailbox). It is likewise possible to set mailbox storage limits, set the deleted items retention time, specify additional proxy e-mail addresses, or move mailboxes between information stores programmatically. You can read more about recipient management in Chapter 13, "Creating and Managing Recipients."

To demonstrate the purpose of the IMailRecipient interface, let's show the public folder called Job Applicants in the Global Address List (SCRIPT8CH24.VBS):

 Set objFolder = CreateObject("CDO.Folder") objFolder.DataSource.Open _ "file://./BackOfficeStorage/bluesky-inc-10.com" _    & "/Public Folders/Job Applicants"     Set objPFRecip = objFolder.GetInterface("IMailRecipient") objPFRecip.HideFromAddressBook = False objFolder.DataSource.Save 

NOTE

---

Detailed sample code to manage mailboxes and public folders using CDOEXM is available in the Exchange 2000 Server Platform SDK.