In Exchange Server, Microsoft has always upheld the concept of an integrated directory that stores details about messaging data, such as mailboxes and distribution lists, and details about the configuration of servers and the organization as a whole. This directory ensures that data flows to all servers in a consistent, up-to-date manner. Users access the directory to validate email addresses or search for correspondents in the Global Address List (GAL).
In Windows 2000 (Win2K), however, Exchange 2000 Server (previously code-named Platinum) integrates with Active Directory. AD replaces the functionality that the Exchange Server 5.5 Directory Store provides. Exchange 2000 is the first major Microsoft BackOffice application to exploit AD features and will serve as the initial standard for directory integration. In this article, I look at Exchange 2000's new architecture and terminology, and review some configuration tips.
A Different Level of Integration
Every version of Exchange Server integrates with its underlying OS. Exchange Server 5.5 and its predecessors interact with Windows NT in many ways, including basic system administration, authentication, and event logging. Exchange 2000 interacts with Win2K, but the integration occurs at a much deeper level because Exchange 2000 depends on a solid AD implementation as its foundation. Such a dependency didn't exist in previous Exchange Server releases; in fact, Exchange Server 5.5 and earlier can work over an extremely fragmented NT deployment.
AD provides the directory service for Win2K and applications. Integrating the OS and applications into the same directory service means that, before you deploy Exchange 2000, you must achieve a solid design for the underlying Win2K domain infrastructure and its associated namespace. You implement the namespace with DNS. As with any new technology, determining the best way to deploy AD and DNS inside an enterprise will take time. Exchange 2000 offers many great new features that enterprises will want to take advantage of right away. However, the integration of Exchange 2000 and AD adds more complexity to the design work you need to do before you commence your deployment.
Directory Architecture and Databases
Broadly speaking, the Exchange Server Directory Store and AD share a common architecture. Figure 1 shows the AD architecture in a manner that could also illustrate the Directory Store. Both directories support multiple access protocols (e.g., the Directory Store supports Messaging API—MAPI—and Lightweight Directory Access Protocol—LDAP), and Microsoft has built both on top of the Extensible Storage Engine (ESE). The ESE is a variant of the generalized Jet database engine that Microsoft uses in other products. Both directories use the same transactional logging model to capture data and ensure that it gets into the database. As Figure 2 shows, AD writes transactions into the log buffer, then records them to the current transaction log and a cache that resides in memory. If the transaction is complete, the database engine commits the transaction to the database when system load allows or when AD flushes its buffers (e.g., as in a full online backup). To mark the most recent successful write, the database engine advances the checkpoint file as it commits transactions to the database.
Figure 2 illustrates the methods the database engine uses to commit transactions to both AD and the Directory Store. Minor filename differences exist: In AD, the lsass.exe file, rather than the dsamain.exe file, manages transactions, and the directory writes data to the AD database, ntds.dit, instead of Exchange Server 5.5's dir.edb. Microsoft has also introduced minor implementation changes—for example, transaction logs hold 10MB of data instead of 5MB. However, Exchange systems administrators need to be familiar with Figure 2's transactional logging model because it's the same model that the Information Store (IS) uses.
When you move to Win2K and Exchange 2000, you need to remember some hard-learned Exchange Server lessons. The most obvious lesson is to protect the Directory Store as comprehensively as possible because recovering from a corrupted Directory Store isn't easy. AD isn't like the NT SAM. The database is more complex and can scale to store millions of objects. The best practice inherited from Exchange Server calls for administrators to place the AD database on a volume that RAID 5 or RAID 0+1 protects and put the transaction logs on a separate physical volume that RAID 1 protects. You need to perform daily backups, and you need a disaster recovery plan that describes how to restore a broken AD database. If a failed server is a domain controller or Global Catalog (GC), you must understand how to get the server back online as quickly as possible.
Microsoft has gone to great lengths to understand the problems that the Directory Store encounters in production and to make the necessary alterations for AD. Replication is one area in which you can appreciate the company's efforts. The Directory Store replicates on a per-object basis, so if you change one attribute of a mailbox (e.g., telephone number, display name), the entire object replicates. Therefore, any time you change an object (no matter how insignificantly), 3.5KB to 4.5KB of data must replicate. By contrast, AD replication occurs on a per-attribute basis. If you change one attribute of a Win2K mailbox-enabled user object, only the data for the changed attribute replicates to other servers. The exact amount of data depends on the attribute type that you modify, but for a simple string attribute, such as the display name, approximately 100 bytes replicate.
Per-attribute replication is necessary when the Directory Service (DS) handles objects for both the OS and applications. A user object can hold many more attributes than an Exchange Server 5.5 mailbox and therefore occupies more space per object within the directory—probably about 6KB per mailbox-enabled user object. You can extend the attributes associated with an object by modifying the AD schema. For example, Exchange 2000 modifies the AD schema to add support for email addresses. Additional attributes mean more data to replicate, and the extensible nature of the directory means that each application you install might increase the system load so much that the whole replication model collapses. Per-attribute replication solves such problems, but it doesn't solve all the other problems that replication systems encounter.
Evolving Sites
Some of the terms that have described the internal layout and architecture of Exchange Server organizations remain in Win2K, and some of the terminology has evolved to reflect Exchange 2000's use of AD instead of the Directory Store. Microsoft has based AD on a multimaster model. Unlike NT, which uses one writable copy of the SAM on the PDC to perform all updates (e.g., password changes), AD lets you make changes to objects at any domain controller. All domain controllers have write access to any object that belongs to the domain, in the same way that all Exchange Server 5.5 servers have write access to any object that belongs to their site. Win2K has adopted the term site, which no longer describes a major building block of the Exchange Server organization. An Exchange Server 5.5 site isn't the same as a Win2K site or a Win2K domain.
An Exchange Server 5.5 site represents a boundary for administrative operations, message routing, and the network topology. All the servers within a site automatically share a common directory and can send messages point-to-point. Through the directory, the servers know of all available connectors on servers within the site so that they can perform common routing operations. Win2K uses a common service account to start and stop the set of Exchange services on all servers within the site, and often uses a set of other permissioned accounts to perform administrative operations. Exchange Server sites can span multiple NT domains, but I don't recommend this configuration. Using multiple NT domains is an uncommon configuration that depends on trust relationships. Most major implementations opt for the easy-to-manage option of placing all a site's servers into a common domain.
In most instances, the fact that an Exchange Server 5.5 site acts as the boundary for network, routing, and administrative operations isn't a problem—in fact, it's an integrated approach to management that people find fairly easy to grasp. However, the integrated approach is inflexible for organizations that want to separate responsibility for the network, routing, and administrative operations to different groups. Exchange 2000 doesn't use the single administration program that Exchange Server 5.5 uses. Instead, sets of Microsoft Management Console (MMC) snap-ins let you give different administrators responsibility for different tasks.
Deciding where to draw site boundaries has become an art form. Network availability is the major influence on determining a site boundary, and most designers won't include a server in a site unless 64Kbps of network bandwidth is available for the connection. All communication between servers in a site is via remote procedure calls (RPCs). You can't schedule the communication because the servers form an automatic full-mesh network to transfer messages between one another. The availability of the Move Server Wizard (since Exchange Server 5.5 Service Pack 2—SP2), which lets you move a server between sites, can mitigate the consequences of incorrectly setting a site boundary.
A Win2K site is effectively a network boundary that one or more IP subnets determine, so it's closely associated with the underlying network topology. As in an Exchange Server site, all the domain controllers within a Win2K site communicate via RPCs for AD replication. The Knowledge Consistency Checker (KCC) automatically connects domain controllers into intrasite AD replication after they join the site. The KCC is an Exchange Server concept. Every 15 minutes, the KCC monitors a site's domain controllers and ensures that the necessary connections exist to replicate data between the controllers. Inside a site, connection objects link domain controllers to form a replication topology, which the KCC manages. Details of the connection objects reside in AD. Unlike the full-mesh network replication that the Exchange Server Directory Store uses, the KCC minimizes replication activity and ensures that replication occurs along the most effective network path. For example, the KCC ensures that domain controllers link together via connection objects that use no more than three hops. Optimizing replication is important for any messaging system, but it's crucial for an OS that depends on fast data replication to let the directory achieve a stable and consistent state across the network. Users become annoyed when password changes don't happen quickly. Just as an Exchange Server 5.5 organization can have many sites, each of which represents an island of high-quality network bandwidth, a Win2K domain can have many sites characterized by the same type of network availability.
AD uses Win2K sites to determine how to direct client connections to the nearest domain controller for authentication. Authentication needs to occur as quickly as possible, so directing a client to a remote domain controller for authentication doesn't make sense. Win2K-aware clients can query DNS to determine the closest domain controller or GC to use, then connect to it. Clients discover the site they belong to by first querying DNS to obtain a list of domain controllers. Then, by comparing the client's IP address to Win2K sites' IP subsets, clients connect to the first controller on the list. The domain controller informs the client about the site information, which the client then inserts into the Registry. Thereafter, when the client starts up and wants to authenticate, it can query DNS for a list of domain controllers for only that site, then proceed to authenticate locally. DNS recognizes domain controllers via special service records that Win2K adds to the DNS database when a domain controller starts up.
Windows 2000 Domains
A Win2K domain defines a part of the corporate namespace and can span multiple sites. Connectors link sites together, just as in Exchange Server. Win2K doesn't support X.400 connections between sites, so you're limited to RPCs (similar to the Exchange Server 5.5 Site connector) or SMTP (similar to the Exchange Server 5.5 Internet Mail Service—IMS). SMTP is the only mechanism for replication between sites and to GCs. The KCC also monitors site links and automatically builds a replication topology from information about sites and the links that connect them.
The namespace and network topology are distinct entities within Win2K. The servers in an Exchange Server 5.5 site share a common namespace, but only for messaging purposes. Applications share the Win2K namespace, which the system also uses for authentication and message routing, among other purposes (e.g., AD replication).
In some respects, the optimum scenario is for Exchange 2000 and Win2K to share a common namespace. For example, because my email address is tony.redmond@compaq.com, I need to log on and authenticate myself to a compaq.com domain controller as the user tony.redmond, using this email address as an alias. In the first iterations of Win2K deployments, you probably won't see many enterprises with a truly unified namespace. Because of factors such as migrating from existing domain names or email addresses and needing to manage servers on an organizational or geographical basis, large enterprises will probably have a hierarchical namespace with several levels. For example, a company might decide to divide its namespace on a geographical basis, with separate domains for each region, such as europe.acme.com or asia.acme.com. By default, AD lets each user object have one email address, but an Exchange 2000 installation extends the schema to permit multiple email addresses of different types (e.g., SMTP, X.400)—just as Exchange Server 5.5 does.
Unlike the Exchange Server 5.5 Directory Store, in which the site is one of the namespace's most important components, Win2K domains define the namespace; sites no longer determine naming. Every object in the Directory Store has a unique distinguished name (DN) that includes the site name. However, Win2K domains can include multiple sites, and the Win2K site name isn't in the DN that AD uses to identify objects. Unlike Exchange Server 5.5, Win2K creates a situation in which the logical design of the directory doesn't depend on the network topology. You can approach directory and network design separately.
Exchange 2000's Route to AD
All connections from Exchange 2000 to AD use a software layer called the Directory Store Access API (DS API), which is on top of LDAP. DS API's role is to provide a general-purpose API for all the Exchange 2000 services to query AD for information about users and contacts, and general configuration data. On each server, Exchange 2000 maintains a cache called the Directory Access Cache, which contains results of recent GC queries. Retrieving data from the cache is much quicker than executing a call to a GC, especially for processes like the IS or the new SMTP Routing Engine; therefore, Exchange Server always queries the cache first.
You can configure the cache through Registry settings to determine how often Exchange Server flushes the cache and how much data the cache holds. By default, the cache can hold 4MB of information for up to 10 minutes. For example, to adjust the cache to hold 8MB of information for 30 minutes, you would make changes to two Registry keys. First, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ MSExchangeDSAccess\Instance0\CacheTTL key. To hold information for 30 minutes, set the REG_DWORD cache time setting to 0x1800. Then, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeDSAccess\Instance0\MaxMemory key. To store 8MB of information, insert the value 8192 (for kilobytes) into the REG_DWORD cache-size setting.
As Exchange Server 5.5 does, Exchange 2000 consults the directory to access two major categories of information: address lookups and configuration data. Exchange 2000 always attempts to make an intelligent decision about the controller that can best satisfy a query. A domain controller can always satisfy queries about local users, whereas only a GC can search for a contact's email address. DNS retrieves information about the local site's domain controllers and GCs just as clients discover local controllers for authentication. Exchange 2000 uses GCs on a round-robin basis if it finds more than one GC in a site. You can also use Windows NT Load Balancing Service (WLBS) to distribute load across available GCs.
The GC
The GC is a domain controller that maintains a copy of AD that is similar in some respects to a fully populated Exchange Server 5.5 Directory Store. You can turn any domain controller into a GC by enabling a listener thread on port 3268. After you enable the listener thread, changes will begin replicating into the GC through this port from every other domain in the forest. A forest encompasses trees of domains that share a common configuration and schema.
The GC holds writable copies of all objects that belong to its domain, and read-only replicas of all objects that belong to other domains in the forest. Therefore, the GC is the only controller that contains details about universal groups (which can contain objects from any domain). So, during authentication, Win2K performs a lookup against the GC to build a complete security ticket for a client. Of course, if you operate only one domain, all domain controllers are GCs, and you can perform the lookup for universal group membership against the same controller.
The GC doesn't replicate every attribute of objects from other domains. Instead, the AD schema—which a special server called the schema master controls—determines the details of the attributes that AD replicates to the GC. From a messaging perspective, the attributes that AD replicates by default include all the information you'd expect to see in the GAL today. This inclusion is important because the GC provides the GAL to clients that connect to Exchange 2000 servers. You can throttle back the amount of bandwidth AD uses for GC replication by reducing the number of attributes that AD replicates. I don't recommend this course of action unless you have no other way to replicate data across a low-bandwidth link.
Only one Exchange Server organization can exist in a Win2K forest. For example, compaq.com and all its subsidiary domains make up a forest. AD replicates configuration data (e.g., information about servers) across the entire forest. Objects from all the forest's domains populate the GC, but the GC contains no information about objects that belong to other forests—even if trust relationships link the forests together. If you want to run two or more Exchange Server organizations, you need to set up an equal number of forests and create the necessary domains to support the desired infrastructure. No functionality currently exists to split or merge forests, so you must ensure that each forest can support your desired Exchange Server organization before you implement it.
Directory synchronization doesn't occur automatically between forests, so to synchronize forest directories, you need an external mechanism such as Compaq's LDAP Directory Synchronizer Utility (LDSU), or you need to write some bespoke code (i.e., purpose-built, not off-the-shelf) using Active Directory Services Interface (ADSI) or LDAP Directory Interchange Format (LDIF). You can use LDIF to import and export information to and from AD just as you use Comma Separated Values (CSV) files today with the Directory Store. Win2K provides the LDIF Bulk Import/Export tool, ldifde.exe, which you can use to synchronize changes to and from other LDAP-compliant directories.
Client Access
Clients can access the GAL via LDAP or the Name Service Provider Interface (NSPI—the interface that lets MAPI clients access the directory). MAPI clients such as Microsoft Outlook 98 or earlier will look for a Directory Store on all Exchange servers. When these clients connect to an Exchange 2000 server, the Directory Store proxy service (which runs on every Exchange 2000 server) intercepts the RPC requests that the clients send to the Directory Store and forwards the RPC packets to the nearest GC. The system performs no processing on the packets; the Directory Store proxy service simply forwards the packets to the directory. This work, which is invisible to the client, happens every time a client connects to Exchange 2000.
Outlook 2000 provides a slightly different solution. Outlook 2000 writes the name of the most recently accessed GC into the system Registry, where the name resides with the other information the Registry holds for the MAPI profile. The Outlook 2000 client can then connect to that GC without needing to go to an Exchange 2000 machine for an explicit referral to a GC. If the registered GC is unavailable when Outlook 2000 starts up, the client issues another query to Exchange 2000 to find another GC name. LDAP clients such as Outlook Express can make direct connections to a GC to access the GAL.
Typically, Exchange 2000 servers conduct a discovery process to identify the nearest GC to use for client proxies and referrals. However, you can tweak Registry settings to instruct Exchange 2000 to use a specific GC for proxies and referrals. Go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeSA\Parameters\NSPI Target Server and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeSA\Parameters\RFR Target Server Registry keys. You use the first key to proxy clients such as Outlook 98, and you use the second key to proxy GC-aware clients such as Outlook 2000. In both cases, the Registry value is a string that provides the name of the GC server (e.g., GC-SERVER1). You can also force Outlook 2000 clients to always use the Directory Store Proxy process to find a GC by disabling referrals on the Exchange 2000 server. You disable referrals on an Exchange 2000 server by placing a DWORD value of 0x1 into the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters\No RFR Service Registry key.
The DNs for recipients that messages contain in their headers change as mailboxes migrate from Exchange Server 5.5 to Exchange 2000. AD can track the changes and resolve old Exchange Server DNs—a capability that lets users reply to old messages. This feature is important because the format for DNs has changed between the Directory Store and AD. Exchange Server 5.5 uses the following format:
For example, the DN for my Exchange Server 5.5 mailbox is
AD uses a different format:
So, my mailbox on an Exchange 2000 server might have the following DN:
As Screen 1, page 86, shows, you can use the Microsoft Windows 2000 Resource Kit's AdsiEdit utility to view an AD user object's DN property. You can also use AdsiEdit to edit AD objects' properties. Editing properties with AdsiEdit is similar to using the Exchange Server 5.5 Exchange Administrator program in raw mode to edit Directory Store objects' properties. The familiar caveat applies: Be sure you know what you're doing when you change any value because you can corrupt the directory if you make a mistake.
Exchange Server 5.5 sites often use Address Book Views (ABVs) or containers to divide the GAL into sections. AD supports similar functionality with Address Lists, which are predefined LDAP queries that the Exchange System Attendant process executes regularly. Screen 2 shows the LDAP query that the System Attendant uses to build the GAL. Exchange 2000 installs a set of default Address Lists, and you can use the Exchange System Manager to build additional lists and add them to AD, which then replicates the definitions throughout the forest. You can use Win2K ACLs to restrict access to an Address List. For example, you can require that a specific group of users use a specific list as their GAL. This feature is useful when you want to host users from several different companies on the same server and don't want the users to see users from the other companies that appear in their GAL. In fact, the GAL is an Address List that Exchange Server creates as a result of an LDAP query to find all objects that can receive email. Finally, Exchange 2000 can build a MAPI Offline Address Book (OAB) from AD, so users who use the OAB to address messages when working offline will see no change after the migration.
Administration and Routing
Win2K sites define the network topology. Exchange Server 5.5 combines administration and routing, but Exchange 2000 splits these tasks into administrative groups and routing groups, which complete the separation of administrative tasks into convenient building blocks. You can still delegate one person or group to perform all administrative tasks for an Exchange server. However, you can now assign responsibility for different tasks at a more granular level.
Administrative groups let a set of administrators manage one or more servers. You can define special policies that instruct the administrators to manage the servers in a particular way, or you can let the administrators have full control over the servers. Routing groups define the message topology and the way messages move between Exchange servers. As in an Exchange Server 5.5 site, all servers within a routing group automatically connect point-to-point and can send messages to one another directly. You can then use routing group connectors, SMTP connectors, or X.400 connectors to link routing groups. Routing group connectors also use SMTP, and the difference between these connectors and regular SMTP connectors is the way they use AD. Routing group connectors route messages based on the Exchange Server configuration data stored in AD, whereas SMTP connectors use DNS to locate SMTP servers. The DNS record might be in AD but could also be in a DNS server on a UNIX system.
Exchange 2000 creates default administrative and routing groups in AD when you install the first Exchange 2000 server; all your servers join these default groups until you create new groups. Screen 3, page 88, shows the Exchange System Manager MMC. Exchange Server defines routing groups (which contain details of the connectors that the routing group manages) within an administrative group. This structure lets a set of administrators work with many routing groups according to one set of policies. The approach is more flexible and more powerful than the equivalent scenario in Exchange Server 5.5, which requires administrators to manage sites individually. In Exchange 2000, a server can belong to a routing group that is outside the server's administrative group. Therefore, routing groups can span multiple administrative groups, thus providing another level of flexibility in terms of management granularity.
If you want to, you can place every Exchange server in your organization into one routing group and one administrative group, which would be the equivalent of installing all the servers into one Exchange Server 5.5 site. This scenario is unlikely except in small deployments because few Exchange Server 5.5 implementations have the network bandwidth available to build such a site. More often, you'll find Exchange 2000 organizations that encompass multiple routing groups and administrative groups. Logically, you would first create a routing group and an administration group for each existing Exchange Server 5.5 site, then evolve your design as you gain Exchange 2000 experience.
Indeed, unless you build a new Exchange 2000 infrastructure, you need to migrate existing Exchange Server 5.5 servers to Exchange 2000 by building a mixed-mode infrastructure. Like a mixed-mode Win2K deployment, a mixed-mode Exchange Server implementation presents restrictions. The most obvious restriction is that you can't create multiple administrative or routing groups until you migrate your final Exchange Server 5.5 server and form a native Exchange 2000 organization.
Splitting Up Work
Microsoft wants you to be able to partition different messaging components across separate physical computers. Exchange 2000 supports the concept of a virtual server composed of front-end systems that control protocol access for clients and back-end storage systems. The virtual server is key to scaling Exchange Server to support tens of thousands of mailboxes on one server, but don't underestimate the change that AD introduces. AD doesn't require the DS to run on every Exchange server; instead, multiple Exchange 2000 email servers can share a domain controller's AD or a GC's AD.
This change saves time and effort. Many Exchange servers today perform redundant work to replicate directory information between servers. You can now centralize all the replication workload on a smaller number of dedicated systems—a step that will also reduce the amount of network traffic that the Directory Store generates. For example, an Exchange Server 5.5 site composed of six large mailbox servers and two bridgehead servers has eight copies of the Directory Store. Intrasite replication automatically updates each copy. In an Exchange 2000 environment, one or two domain controllers (or GCs) can assume the workload and provide the same level of response to clients and Exchange services. Eliminating six copies of the Directory Store takes a huge amount of replication traffic off the network and reduces the amount of disk space that the Directory Store requires.
Deciding how many GCs to use, and where to place them in relation to your email servers, will be an essential part of your Exchange 2000 design. Based on current experience, at least one GC must reside at every physical location where you deploy Exchange 2000 servers. Deploying two GCs provides extra resilience—if you can afford the network overhead for the extra replication activity. Exchange 2000 can use an extended WAN link to access a GC, but MAPI clients are typically in proximity to Exchange servers and expect fast local access to the GAL. Other Exchange Server components, such as the Routing Engine, need to consult the GC to validate email addresses, so the GC is obviously a crucial component in Exchange 2000. Your mileage might vary across different types and speeds of network links (and will probably improve as your experience with Exchange 2000 and AD develops). Too many GCs, like too many Exchange servers in one site, is just as bad as too few, because of the replication traffic between the servers.
Extending the Schema
Exchange 2000 is the first application to extend the AD schema by adding new attributes that you can associate with recipients (i.e., users, contacts, and groups), and configuration information about Exchange Server (e.g., administrative and routing groups). For example, Exchange 2000 extends the user object with storage attributes that let you associate users with the IS where their mailbox resides, and any quotas placed on the mailbox. Exchange 2000 extends the schema when you install the first server in a forest. The Exchange 2000 installation process makes adjustments at the schema master and inserts them into AD's configuration container. The adjustments then replicate to the domain's other controllers. Exchange 2000 beta 3 makes more than 800 changes to the schema, so performing your first installation on or close to the schema master is probably a good idea.
Screen 4 shows the properties of the AD container you added to hold Exchange Server configuration details. Every object in AD has a DN. The container, named domain/configuration/services/microsoft exchange, holds several other containers that store details of entities such as routing groups and administrative groups, address lists, and connectors. The container replicates through the forest to let all the organization's Exchange 2000 servers access information about other servers. This information is similar to the data that the Exchange Server 5.5 Directory Store's Site Configuration container maintains.
Connecting Exchange Server 5.5 to AD
You can connect Exchange Server 5.5 to AD via the Active Directory Connector (ADC). The ADC is a unidirectional or bidirectional connector that uses LDAP to synchronize the Exchange Server 5.5 Directory Store with AD. Each Exchange Server 5.5 site connects to AD via a separate connection agreement. A connection agreement defines details about the objects that will replicate across a particular link, the type of connection, the method by which servers will authenticate to each other, and the servers that will participate in the link.
Screen 5 shows that the LDAP connection uses port 389. This port works as long as the ADC and Exchange Server 5.5 are on separate servers. However, if the ADC and Exchange Server 5.5 reside on the same server, you need to change the LDAP port number. When Win2K starts up, the OS takes port 389 as its default LDAP service, so Exchange Server 5.5 needs to use a different port number. In the Exchange Server 5.5 administration program, on the Protocols property page for the server, you can change the port that Win2K assigns to LDAP (e.g., 390).
The ADC typically runs on a schedule—perhaps once a day. After synchronization, Exchange Server 5.5 mailboxes appear as mail-enabled objects in AD, and custom recipients appear as contacts. In the Directory Store, Win2K users appear as custom recipients. In Exchange 2000, Microsoft also includes a connector based on the same LDAP engine, so you can synchronize with the Lotus Notes address book. (This simplification is merely an overview of what the ADC can do; in a future article, I'll provide more detail about the processing.)
The ADC works with only Exchange Server 5.5 because the connector relies on writable LDAP to make changes to the Directory Store. Exchange Server 5.0 supports only LDAP 1.0, which doesn't support write access. Exchange Server 4.0 offers no LDAP support. However, you don't need to upgrade all servers to version 5.5 before you can use the ADC. You need only one version-5.5 server to act as a bridgehead in every Exchange Server site that will synchronize with AD.
If you're running Exchange Server 4.0 or 5.0 servers, you must upgrade to version 5.5 (including the latest service pack) as soon as possible as part of your preparation for a migration to Win2K and Exchange 2000. Indeed, you can upgrade a server to Exchange 2000 only if you've installed Exchange Server 5.5 and upgraded the computer to Win2K.
Moving Forward
If you've used Exchange Server and know the concepts behind the Directory Store, you'll know how to approach AD. In fact, you can think of the Directory Store as version 0.9 of AD. AD is certainly better, faster, and more comprehensive than the Directory Store. Microsoft has firmly based AD on the experience the company has gained from operating a distributed multimaster directory in Exchange Server since 1996.
Even if you have Exchange Server experience, the combination of Exchange 2000 and AD gives you many new concepts to think about. Switching terminology, connecting Exchange Server 5.5 to Exchange 2000, mastering the new administrative model, and optimizing the Exchange 2000 environment before and after initial deployment hold enough challenges for even the most gung-ho administrator. To accommodate all the new concepts, you need to increase your knowledge. Training is the best way to gain knowledge, but if you can't find formal training, take the time to understand Win2K, AD, and Exchange 2000's integration with both before you plunge into a deployment project.
