Exchange 2000 Server and Active Directory

Tony Redmond
Article from Windows 2000 Magazine

Microsoft Shifts Directory Store Responsibilities to Win2K

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 provides a replicated, multimaster model
to ensure 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 codenamed
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 earlier 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

Figure 1 AD Architecture
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
corrupt 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 try to ensure that the AD can continue to work.
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. So, 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 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. 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.

Figure 2 Transaction Logging for AD

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. 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 like Exchange Server 5.5.
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 holds as much as 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 cachesize
setting.
Like Exchange Server 5.5, 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 the 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 readonly
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 Global Address List (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 using Active Directory Services Interface (ADSI) or LDAP
Directory Interchange Format (LDIF). You can use LDIF to import and export
information to and from the AD just as you use Comma Separated Values (CSV)
files today with the Exchange Server 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
that use Microsoft Outlook 98 or earlier will search for a Directory Store on all
Exchange servers. When these clients connect to a 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. The
Directory Store proxy service 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 situation. Outlook 2000 can query
Exchange 2000 for the name of a GC to use, then write its name 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 connect 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
a 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:
/o=<organization name>/cn=<site name>/cn=<recipients container>
/cn=<unique alias within container>
For example, the DN for my Exchange Server 5.5 mailbox is
/o=Compaq/cn=Dublin/cn=Recipients/cn=TonyR
AD uses a different format:
cn=<name>, cn=<container>, dc=<domain name>, dc=<domain>
So, my mailbox on an Exchange 2000 server might have the following DN:
cn=Tony Redmond; cn= Users, dc= Compaq, dc= com

Screen 1 Using AdsiEdit to view an AD user object's properties
As Screen 1 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.

Screen 2 Using an LDAP query to build the GAL
Exchange Server 5.5 sites often use Address Book Views (ABVs) or containers to
divide the GAL into sections. The 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 Exchange
Server 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 the 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 the 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 Exchange 2000's 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.

Screen 3 Viewing the Exchange System Manager MMC
Exchange 2000 creates default administrative and routing groups in the AD
when you install the first Exchange 2000 server; all your servers join these
default groups until you create new groups. Screen 3 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 mixedmode
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 2000environment, 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 before the system
begins routing messages, 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 Viewing the AD container's properties
Screen 4 shows the properties of the AD container you added to hold Exchange
Server configuration details. Every object in the 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 Configuring an ADC
Screen 5 shows that the LDAP connection uses port 389. This port is OK if 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 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 an eventual 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. However, 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.

We at Microsoft Corporation hope that the information in this work is valuable to
you. Your use of the information contained in this work, however, is at your sole
risk. All information in this work is provided "as -is", without any warranty,
whether express or implied, of its accuracy, completeness, fitness for a
particular purpose, title or non-infringement, and none of the third-party
products or information mentioned in the work are authored, recommended,
supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall
not be liable for any damages you may sustain by using this information,
whether direct, indirect, special, incidental or consequential, even if it has been
advised of the possibility of such damages.

© 2003 Microsoft Corporation. All rights reserved. Terms of Use Privacy Statement Accessibility