Programming Microsoft Outlook and Microsoft Exchange, Second Edition (DV-MPS Programming)

The easiest way to learn any new object library is to look at the objects in action. For this reason, the rest of this chapter shows you four sample applications that demonstrate different technologies in the CDO library: a Helpdesk application, a Calendar of Events application, an Intranet News application, and a CDO Visual Basic application. From these four samples, you will learn how to use the CDO library in your applications and become aware of the technical considerations encountered when building CDO applications. Before we dive into the details of these four sample applications, we'll first look at the necessary Exchange Server logon step.

Using the CDO Session Object

Whether you build CDO applications by using ASP or by using some other development tool, the most important point to remember is that you cannot create any other objects in the CDO library if you do not successfully create a Session object. Furthermore, you cannot access any data in Exchange Server unless you successfully log on to the server using the Session object. Before we can look at the code in the CDO applications, you need to understand how to log on to an Exchange server by using the Session object.

The Session object is the top-level object in the CDO hierarchy. It contains session-wide settings and properties that return top-level objects. When using the CreateObject method in your applications, you use the ProgID of the Session object—MAPI.Session—to create a CDO object. CDO does not allow you to access any other objects in the library until you have successfully logged on using the Logon method of the Session object. The only exception to this is the SetLocaleIDs method, which sets the Locale and CodePage IDs for the user.

Using the Logon Method

The Logon method takes a number of parameters, as shown in the following code; the parameter you use depends on the needs of your application:

The two common ways to log on to a CDO session are by passing in a MAPI profile name and by passing in the specific information CDO needs to dynamically generate a profile. Dynamically generated profiles are the preferred method when building ASP applications with CDO. Since ASPs cannot access client profiles, CDO has no way to pull information from a profile located on the user's machine.

Authenticated Logon Using a Profile

To log on using a profile, pass the profile name as the first parameter, ProfileName, to the Logon method. If you don't know which profile name to use, set the ShowDialog parameter to True, and CDO will prompt the user to pick a profile. The second parameter, ProfilePassword, specifies the profile password. You could leave this parameter blank and set the ShowDialog parameter to True, and CDO will prompt the user for a password. By setting the NewSession parameter to False, you can have CDO take advantage of an existing MAPI session, eliminating the unnecessary overhead from creating a new MAPI session on the user's machine. The following code snippet shows you how to use the Logon method with a profile named MS Outlook Settings:

Authenticated Logon Using a Dynamically Generated Profile

When your application is running in an environment where profiles or the ability to prompt a user for a profile might not be available, CDO allows you to dynamically generate a profile for the user by passing in the user's server name and mailbox name to the Logon method. To get this information, you can have your application prompt the user for his server name and mailbox name. Alternatively, CDO can pull the default Exchange Server name from the registry by using the ConfigParameter properties in the CDO Rendering library, which you will learn about later in this chapter. For now, the code sample assumes that you know at least one Exchange Server name in your organization. The following code shows you how to log on to CDO using a dynamically generated profile:

NOTE

Anonymous Access

CDO also allows users to anonymously access the Exchange Server public folder store as well as the Exchange Server directory. Anonymous access must be enabled by the administrator of the Exchange Server system. Also, the administrator or developer can control which folders and which directory entries the anonymous user can see by setting some options in the Exchange Administrator program. These options are discussed in more detail throughout this chapter.

To use anonymous access, you must pass in to the ProfileInfo parameter the distinguished name of the Exchange Server and the Anon account. You do this by using the following format:

The server's distinguished name takes the form of:

The enterprise parameter corresponds to the Exchange Server organization, and the site parameter corresponds to the Exchange Server site you want to access. The following code shows you how to log on using anonymous access: