Exchange 2000 Server and Active Directory

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.