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.