Exchange Server Viewing Tools

Before your users can access their email system, you must register them in a directory. Microsoft Exchange Server 5.5 and Exchange Server 4.0 hold information about users in the Directory Store, which Exchange Server uses to validate addresses, ensure message delivery, and check that users aren't exceeding quotas or gaining access to unauthorized information, such as restricted public folders. Administrators also use the Directory Store information to create Address Book Views (ABVs), which can help users manage the Global Address List (GAL) and quickly locate information. Microsoft has implemented extensive changes in Exchange 2000 Server, which discards the Directory Store in favor of Windows 2000 (Win2K) Active Directory (AD). Exchange 2000 registers users in AD, replaces ABVs with Address Lists, and changes the way in which various protocols and clients access the GAL. ABVs and Address Lists can be useful tools—if directory entry information is accurate and if views are well planned.

Directory Basics
Before planning ABVs or Address Lists, you need to establish how your clients access directory information. Exchange 2000 and Exchange Server 5.5 support a variety of protocols and clients. The lineup includes the following:

• Messaging API (MAPI)—All versions of Microsoft Outlook, as well as the Exchange client that ships with Exchange Server 5.0 and Exchange Server 4.0, use this protocol.
• POP3—Internet mail systems extensively use this simple client/server protocol. Corporate messaging environments rarely deploy POP3.
• IMAP4—The latest generation of Web browsers and purpose-designed clients, such as Outlook Express 5.0 and Eudora, uses this comprehensive Internet client/server email protocol. IMAP4 lets users access Exchange Server from UNIX workstations and other platforms that don't support MAPI.
• HTTP and HTTP-DAV—Web browsers use HTTP as a basic protocol. Outlook Web Access (OWA), which is a Web application that connects browsers to Exchange Server mailboxes and public folders, supports this protocol. Exchange 2000 supports HTTP-DAV, which is an extension of HTTP 1.1.

The GAL and Directory Access
The GAL holds entries for every contact, user, group, and public folder in an organization. (Exchange Server 5.5 refers to these objects as custom recipients, mailboxes, distribution lists—DLs, and public folders, respectively.)

MAPI clients access the GAL by using MAPI, which supports browsing, so users can scroll through a list to find specific information. All other clients access the GAL through Lightweight Directory Access Protocol (LDAP), which returns the results of users' directory searches, so users must make a succession of queries to find information. Exchange Server 5.5 derives the GAL from the Directory Store. Each Exchange Server 5.5 machine maintains a copy of the Directory Store, so clients that connect to an Exchange server for directory information also get a local connection to the Directory Store, and the GAL immediately reflects any object attribute changes that users make in the directory. As I mentioned, AD replaces the Directory Store in Win2K. Not every Exchange 2000 server is a Win2K domain controller, so a local copy of AD isn't always available. Therefore, Exchange 2000 must proxy or refer MAPI clients to the nearest Global Catalog (GC) server. Clients use the GC to access the GAL, and basic Exchange 2000 functions such as message routing won't work without a GC. In Win2K, the GC holds user, contact, and group details for the entire forest, so in an Exchange 2000 deployment, you need to place GC servers in network proximity to your Exchange servers.

You don't need to manually redirect MAPI clients that try to access the Directory Store; a service called Dsproxy, which runs on every Exchange 2000 server, automatically proxies or refers these clients to a GC. A slight difference exists between a proxy and a referral. For Outlook 98 and earlier clients, Dsproxy proxies the clients to the nearest GC server each time the clients attempt to connect to the Directory Store. In a referral, Outlook 2000 records in the system Registry the name of the GC with which Outlook 2000 most recently connected and uses that value until a problem, such as an unavailable GC, occurs with a connection. If a problem occurs, Outlook 2000 asks Exchange 2000 to refer the name of another GC. However, Outlook 2000 doesn't support automatic transfer between GCs, so if a GC goes offline, all the clients that were connected must log off and reconnect. The process of contacting a GC incurs a small amount of overhead, but clients usually aren't aware that they aren't connecting locally to the directory unless they're accessing the GC across a slow network connection. Obviously, a big difference exists between local (Directory Store) and remote (GC) access—a difference that underlines the need to position GCs carefully in every Exchange 2000 deployment.

Because both the Directory Store and AD support LDAP access, LDAP clients connect to the Directory Store or AD in the same manner. Of course, in an Exchange 2000 environment, you need to instruct LDAP clients to connect to a GC to access the directory service.

In small Exchange Server deployments, users can easily search the GAL for a particular entry, even when they know only part of the entry name. When the number of entries in the GAL exceeds 10,000, searching becomes increasingly difficult. Compaq's GAL, for example, holds more than 136,000 entries, and trying to find the correct entry among common international surnames (e.g., Smith, Chung, Dubois) can be frustrating. Sending messages to the wrong user—or worse, to the wrong group—is embarrassing and can result in the inappropriate distribution of confidential information. Any tool that helps users manage the GAL and quickly locate correct information is a boon to both users and administrators.

Address Book Views
Exchange Server 5.5 MAPI clients can use ABVs or containers to divide the GAL into logical sections. An ABV is a logical grouping of directory entries that meet a common set of criteria (e.g., all the entries that belong to the sales department). You can base an ABV on any defined attribute of objects in the directory, but ABVs are useful only if administrators populate the directory with a reasonable selection of sortable attributes. If entry data is minimal (for example, only account name, mailbox alias, first name, last name, and display name), users can't create viable ABVs. Directory entries need to include detailed information, such as the names of cities, countries, departments, offices, or other attributes that make sense within your organization. You also need to review processes that feed information into the directory, perhaps as part of external directory synchronization, to ensure that entries contain enough information to make ABVs work properly.

ABVs are great tools when you do the necessary planning. Perform a few tests to ensure that the views deliver value for your enterprise and that the data necessary to make realistic views is present in the directory. Exchange Server 5.5 or Exchange Server 5.0 replicates ABVs across all sites in an organization, so before you create a view, ensure that a similar view doesn't already exist—a complicated process if an ABV's name doesn't convey its purpose. The Microsoft article "XADM: Recurring Address Book Views in Exchange Server" (http://support.microsoft.com/support/kb/articles/q180/1/41.asp) describes additional problems that arise from sharing views between sites.