SQL Server Magazine

Chalking up more than 5 million new seats every quarter, Microsoft Exchange Server is on a roll. Today, more than 30 million people use Exchange Server for their email system. Exchange 2000 Server (formerly code-named Platinum) represents a fundamental shift in Microsoft messaging technology because it depends on Windows 2000's (Win2K's) Active Directory (AD), which usurps the role of Exchange Server 5.5's Directory Store. Users, contacts, and groups become mail-enabled AD objects that take the place of the Directory Store's mailboxes, custom recipients, and distribution lists (DLs). Whereas the Directory Store today holds information about servers and sites, AD holds all configuration data about Exchange servers, routing groups, and administrative groups.

An important technical fact to remember in your Exchange 2000 design phase is that Exchange Server places all its configuration data in AD's configuration naming context (NC). You can replicate this configuration data only inside a forest, so an Exchange 2000 organization can span only one Win2K forest. If you want to operate multiple Exchange 2000 organizations (each with its own set of servers), you'll need multiple Win2K forests. Today, some companies operate multiple organizations when no trust relationship exists between two user communities and their technical staffs. You can run two Exchange Server organizations within one Windows NT 4.0 domain, but this capability won't be possible in an Exchange 2000 environment.

Major upgrades require comprehensive planning. You can't deploy Exchange 2000 without a solid Win2K infrastructure—particularly AD—already in place. Some companies will deploy Exchange 2000 immediately after they stabilize Win2K. Other companies will be content to run Exchange Server 5.5 (with Service Pack 2—SP2—or later) on Win2K and assess Exchange 2000's performance in other environments. However, these companies need to remember that they can upgrade from Exchange Server 5.5 SP2 or later to Exchange 2000 only after they've upgraded their servers from NT to Win2K. No upgrade paths to Exchange 2000 exist for Exchange Server 5.0 or 4.0 servers in NT.

Your Exchange 2000 deployment requires a link between the Exchange Server 5.5 Directory Store and AD. This link, the Active Directory Connector (ADC), lets users attached to different versions of Exchange Server communicate with one another. The ADC is an important tool for any Exchange Server administrator because it will be necessary in all but green-field deployments (i.e., deployments of new servers with no migration requirement). To begin a successful implementation of the ADC, you need to understand the basics of Lightweight Directory Access Protocol (LDAP), the reason for synchronization, the importance of connection agreements (CAs), and the role of replication.

LDAP Provides the Base
LDAP is the Internet protocol for directory access. Exchange Server 5.0 was the first version of the messaging software to support LDAP. Initially, Exchange Server supported just the read-only mode, which was sufficient to let POP3 and Web browser clients consult the Directory Store to check email addresses. Exchange Server 5.5 enhanced LDAP support to allow read-write access through LDAP 3.0. Exchange Server 5.5 also introduced performance enhancements that let the server process large queries efficiently. These collective LDAP enhancements let Exchange Server 5.5 support bidirectional synchronization between the Directory Store and other LDAP-compliant directories, such as AD. Finally, Exchange Server 5.5 SP2 applied some schema extensions to the Directory Store that let the Directory Store hold AD attributes for objects and that can track whether the ADC has synchronized an object.

Win2K relies heavily on LDAP, which is the basic protocol clients use to query AD and retrieve information. LDAP is also the protocol that the ADC uses to read and write data from the Directory Store and AD. Directory synchronization requires read-write access—otherwise, you could never update a directory. Therefore, you must run Exchange Server 5.5 before you can use the ADC. This requirement doesn't mean that you must immediately upgrade every Exchange Server 5.0 and 4.0 server to version 5.5. You need only one Exchange Server 5.5 machine in each site that you want to connect. This server is similar to bridgehead servers that connect Exchange Server sites by means of directory replication connectors (DRCs). However, given that you can upgrade to Exchange 2000 only from Exchange Server 5.5, plan to move all your organization's Exchange servers to version 5.5 as soon as possible—ideally to the latest service pack.

LDAP lets clients access the contents of a directory, but the DirSync control establishes a method to compare directory contents and decide what data requires synchronization. In the Internet-draft Microsoft LDAP Control for Directory Synchronization, Microsoft describes the DirSync control as a potential solution to the problem of synchronizing different directories according to a common standard. You can find the draft, which might become an Internet Engineering Task Force (IETF) Request for Comments (RFC), at http://www.ietf.org/internet-drafts/draft-armijo-ldap-dirsync-00.txt. Over the next few years, Microsoft will probably use DirSync extensively to synchronize AD and other directories, such as the Lotus Notes address book, Novell GroupWise, and Internet Yellow Pages.

Why Synchronize?
Clients depend on a Global Address List (GAL) to address and route email correctly. Exchange Server 5.5 derives the GAL from the Directory Store; the GAL contains entries for every object (e.g., mailbox, custom recipient, DL, public folder) that has an email address and that the administrator hasn't hidden. Every Exchange server holds a copy of the Directory Store that contains information from all the organization's servers. AD takes the place of the Directory Store when you install Exchange 2000, which derives the GAL from the complete copy of user information that resides on an AD Global Catalog (GC). Exchange 2000 stores configuration information in AD's configuration NC, and this data replicates across the forest so that all the organization's servers have access to it. In addition to server details, the configuration data includes such data as Exchange 2000 administration and routing topologies and connectors. The GC holds copies of every mail-enabled object in a Win2K forest, so Exchange 2000 uses the GC to create a GAL that clients can access. The Exchange 2000 System Attendant service automatically executes an LDAP query every 10 minutes to create the GAL.

Migration from Exchange Server 5.5 to Exchange 2000 won't happen overnight. You need to provide users with a unified directory during the migration period. Because Exchange 2000 builds the GAL from a GC (which depends on AD), synchronization must occur between the Exchange Server 5.5 Directory Store and AD. This synchronization creates a complete picture of all the users in an Exchange Server organization during the migration period. The ADC is the simplest and best way to accomplish the synchronization.

The Active Directory Connector
Two versions of the ADC are available. Win2K provides one version (in the Windows 2000 Server—Win2K Server—CD-ROM's valueadd\adc directory), and Exchange 2000 provides an enhanced version (in the Exchange 2000 CD-ROM's \adc directory). The Win2K version supports only replication of objects from the Directory Store site NC (e.g., the contents of Recipients containers), whereas the Exchange 2000 version can also process configuration data. Both versions can provide a synchronized GAL that includes full details about Exchange Server 5.5 mailboxes, custom recipients, and DLs. However, you need the Exchange 2000 version if you have a mixed-mode Exchange Server organization (i.e., an organization that includes Exchange 2000 servers and earlier-version Exchange Server computers). To support mixed-mode organizations, the Exchange 2000 ADC version lets configuration data (e.g., site topology, information about servers) replicate between the Directory Store and AD. The Exchange 2000 ADC also supports downstream routing (i.e., the ability to use messaging connectors attached to Exchange Server 5.5, 5.0, or 4.0 servers).

You can start using the Win2K version of the ADC, then upgrade to the Exchange 2000 version after Exchange 2000 ships. This strategy lets you start populating AD with Exchange Server user data so that a GAL is ready for your first Exchange 2000 server (which will probably be a test server so that you can become accustomed to the new software). Later, when you're ready to begin your migration, you can upgrade the ADC to allow configuration data sharing. Deploying the ADC twice is hard work, so the best strategy is to deploy the Exchange 2000 version first.

As Screen 1, page 150 shows, the ADC process runs as a service, as do all the other services that constitute Exchange 2000. You can see some of the new services that Exchange 2000 introduces, such as the new SMTP-based routing service and the IMAP4 protocol stub, in Screen 1.

Connection Agreements
Although the ADC controls synchronization, one or more CAs tell the ADC how synchronization needs to occur. To fine-tune synchronization and accommodate the needs of even the most complex Exchange Server deployments, one ADC can support many CAs. An ADC that must manage more CAs will consume more system resources and create a more complex overall synchronization environment.

According to Microsoft, even though no architectural restrictions exist for the number of CAs that one ADC can support, system resources become a practical constraint after you establish about 50 CAs. If you need to run more than 10 CAs, consider allocating a dedicated server for ADC operation. Best practice in this area will evolve over the next couple of years. Today, you need to approach ADC projects with the goal of restricting the number of CAs.

To host the ADC, distributed Exchange Server organizations with large numbers of sites might require multiple servers with CAs shared among the servers. Organizations that already operate central Exchange Server routing sites (typically around a hub-and-spoke network) will likely find that the central site is a good location for synchronization. Because an Exchange server can make changes only to objects that belong to its site, you need a separate CA for bidirectional synchronization between AD and each site. Following the same logic, if you want to apply updates from the Directory Store to Win2K domains, you need a separate CA for each domain. Companies that run large multisite Exchange Server organizations will therefore find that they require multiple CAs, even if they want to synchronize with only one Win2K domain.

The ADC supports full bidirectional connections—changes synchronize from AD to the Directory Store, and vice versa. However, you can decide to use a one-way CA. For example, if you want to populate AD based on the Directory Store and establish a test environment for Win2K, use a one-way connection from the Directory Store.

Each CA specifies several important parameters, including

• The names of the Win2K and Exchange servers on each side of the connection, and the account names to use and the passwords of those accounts. You enter this information on the CA's Connections tab, which Screen 2 shows.
• The LDAP port that the system uses to connect the two directories. For LDAP connections, Exchange Server 5.5 typically uses port 389. However, if the server is running Win2K, the OS takes port 389 for base LDAP connectivity. Therefore, you must allocate another port for Exchange Server's LDAP use (most people opt to use port 390). To choose a different port, select LDAP from the server's Protocols container and update the number.
• The schedule by which the system establishes connections.
• How you create new objects in AD for Exchange Server mailboxes. Your choices are new user objects, disabled user objects, or mail-enabled contacts.

   Prev. page   [1] 2     next page