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.
Screen 1 shows the process for defining an ABV. This view will sort the directory by company, then by country. If I correctly populate the attributes, the view will separate external contacts from company employees. However, ABVs aren't intelligent. A view can't distinguish between United States and UNITED STATES and doesn't understand that USA and US mean the same thing. The first time you browse an ABV, you'll probably find that you need to clean up data to make the view truly accurate and easy to use.
As I mentioned, the GAL in Exchange Server 5.5 immediately reflects attribute changes that users make to objects in the Directory Store. For example, when you change an object's country attribute from US to USA, the object will appear under USA the next time someone uses an ABV to browse the directory. Additionally, if someone creates a new value under which to group objects, a service called the View Consistency Checker (VCC) automatically creates a new child view. For example, suppose you add a new mailbox with the country property Uganda, and that this object is the first with that value. The VCC will create a new child view for all objects with the country property Uganda. The VCC runs every 5 minutes.
Different values or misspellings in important properties result in additional child views for many ABVs. For example, many companies employ a general rule to use the International Organization for Standardization (ISO) code (e.g., DK for Denmark, GB for Great Britain, IE for Ireland) as a mailbox's country attribute. Approximately 90 percent of Compaq's entries use the ISO code, but the remaining entries use different versions (e.g., Denmark instead of DK, UK instead of GB). Each variation creates an additional child view and increases the amount of data that Exchange Server 5.5 must download to clients when they connect. This download isn't a problem when users connect through a LAN, but it certainly becomes a problem across extended WAN links or dial-up connections, especially for companies with large GALs. Compaq's Directory Store, for example, is well populated, but each time a user created an ABV, the number of bytes that Exchange Server 5.5 transmitted to Outlook 2000 during the initial logon process grew from 85,000 to more than 1 million. The net result was that instead of sending messages within 15 seconds of connection across a 28.8Kbps link, Outlook was too busy to do anything but download view data for as long as 3 minutes. (These figures are nonscientific measurements that I took by observing Dial-Up Networking applet data, but the results were consistent each time an administrator added a new ABV. Compaq has a large community that depends on dial-up connections, so after testing and realizing the impact on dial-up links, the company decided not to use ABVs.)
Address Lists
Exchange 2000 doesn't use ABVs but provides similar functionality through Address Lists, which are predefined LDAP queries. A special service called the Address List Service, which runs in the Exchange 2000 System Attendant process, executes these queries on a regular basis. Screen 2 shows the LDAP query that the System Attendant uses to build the GAL. Don't worry: To create Address Lists, you don't need to learn how to put LDAP queries together. The user interface (UI) is adept at creating the necessary LDAP code.
Not every Exchange 2000 server is a domain controller or GC, so a different mechanism than Exchange 5.5 uses is necessary to access the directory and build the lists. Exchange 2000 automatically installs a set of default Address Lists, and you can use the Exchange System Manager Microsoft Management Console (MMC) snap-in to build other lists and add them to AD, which then replicates the definitions throughout the forest. (I discuss the process for building new Address Lists in "Switching from ABVs to Address Lists.") For example, Screen 3 shows the default Address Lists plus one (Country=France) that an administrator added. Note the node for Address List Services, which holds configuration information that controls Address List generation. When you expand this node, as Screen 4 shows, you can see that Exchange 2000 creates a separate service for each domain in the forest, plus one domain for the forest's enterprise configuration. By default, Exchange 2000 nominates the first server installed in the local domain to create Address Lists for each domain. (You can redefine this server at any time.) In my example, Screen 4 shows that the server QEMEA-DC17 is the server for all domains, which indicates that QEMEA-DC17 was the first Exchange 2000 server that the administrator installed. Exchange 2000's Help recommends that you use a domain controller as the list-generation server, but you need a GC to generate information for other domains. Running Exchange 2000 and the GC on the same computer isn't a good idea because of the load that this combination generates. (Exchange 2000 generates extra load after bulk creating or deleting or when creating new Address Lists.) However, every Exchange 2000 server needs to be close in network terms to a GC, so select as the list generator the server that is most lightly loaded.
During a migration or other deployment, a domain might be without an Exchange 2000 server (temporarily or by design). In the meantime, you can assign a server from another domain to act as the list generator. However, Exchange 2000's setup procedure won't automatically switch this role to the first Exchange 2000 server that you install in the new domain, so you'll need to manually switch after the installation is complete and the new server is active.
Each Address List Service generates its list according to an update interval that you can set in the Address List Service Properties, as Screen 5 shows. The interval ranges from Never to Always, with the option to operate on a customized schedule. Never means that the Address List Service never generates the list, implying that a domain's entries won't be available to other domains. Always means that the Address List Service generates the list every 10 minutes. To maintain Address List membership, Exchange 2000 updates an object's ShowInAddressBook attribute, which is a multivalued attribute that AD publishes to all GCs, with the names of the Address Lists in which that object appears. AD contains many other objects than those that might appear in the GAL, so the ShowInAddressBook attribute also serves to mark Exchange Server-related objects.
After generating the Address Lists, Exchange 2000 depends on regular AD replication to share the lists with other domains. If you select an Address List Service in the Exchange System Manager MMC snap-in and then right-click, you access a context-sensitive menu that contains options to update a domain's objects or recreate the complete list. Rebuilding a list can take a long time if the domain holds thousands of objects, so choose to recreate only when you absolutely need to do so (for example, after you use the Ldifde command-line utility to import details of thousands of new user objects).
Obviously, objects' properties don't change at precisely scheduled intervals. Therefore, Exchange 2000 needs a mechanism to track changes that occur between update intervals so that users don't see outdated information when they browse the GAL. The Automatic Recipient Updater Service monitors the lists to which AD objects belong (e.g., the GAL, All Users, All Groups) and updates the lists as necessary. For example, when you add a new user, the service automatically inserts an entry for the new user into the GAL, the All Users list, and any other lists that the user belongs to (based on the user object's properties). The service polls for changes every 60 seconds. You can't change this interval.
You can use Win2K ACLs to restrict access to an Address List. For example, you can define an Address List as the GAL for a specific group of users. This feature is useful when you want to host users from several different companies on the same server but want each company's GAL to show users from only that company. Exchange 2000 can build a MAPI Offline Address Book (OAB) from AD, so the migration won't affect users working offline and using the OAB to address messages.
Switching from ABVs to Address Lists
Existing Exchange Server 5.5 ABVs won't migrate to Exchange 2000 Address Lists. If you've created several customized views for Exchange Server 5.5, you'll need to review why you created the views and how (or whether) you use them before deciding whether to create equivalent Address Lists. Screen 6 shows the creation of a new list called Administrators. After you name a new list, you define the criteria or filter that Exchange 2000 will use to select objects to appear in the list. The General tab, which Screen 6 shows, lets you choose the type of objects that will appear; the Advanced tab, which Screen 7 shows, gives you precise control over the properties that Exchange 2000 will examine when it builds the list. I built the list that Screen 7 shows from objects with a Department property value of AMTG. You can combine different criteria to create complex finds. A good idea is to use the Advanced tab's Find Now button to test whether the stated criteria will find the correct objects. If you don't get the correct results, neither will users.
Only MAPI clients can view and browse Address Lists; other clients can execute only simple LDAP queries against AD. Screen 8 shows an Outlook 2000 view of the new Address List.
Like ABVs, Address Lists need meaningful names to be truly useful. Try to create clear and simple names. Users shouldn't need an astrophysics degree to understand the reason for a list and the objects they can expect to find in the list. The Country=France list, which Screen 3 shows, has a poor name because Country=France doesn't tell us what aspect of France determines list membership. For all we know, the list could contain details about groups whose maintainers live in France. Users in France is a much better name.
Planning Is Everything
Administrators need to try anything that makes life easier for users. ABVs and Address Lists fall into this category, but only if you use careful planning and implementation. Take time to consider the ways in which you can logically and usefully partition your address book, then decide whether you can create the right view or list. And remember that these tools, like many other directory features, fail utterly if the directory doesn't contain enough information to precisely divide entries. I suspect that this lack of information is the hurdle that will trip up most enterprises.
