Exchange 5.5
The first version of Microsoft Exchange, version 4.0, was an X.400-focused messaging system. Exchange was based on the X.400 architecture with a message store, a message transfer agent, gateway services, clients, and a directory. The Exchange directory is an X.500-based directory that embraces many of the principals and functionality of X.500.
The Exchange directory is the focal point of communications between Exchange components, as shown in Figure 18.1. Before any Exchange component can communicate with another Exchange server in the organization, the component contacts the directory to obtain the component's address.
Figure 18.1. Exchange 5.5 core component communication.
The Exchange directory is a critical component of the Exchange messaging system. However, the Exchange directory is not a security sub-system. Rather, Exchange relies on Windows NT for its security services. Typically, a Windows NT user can only access Exchange objects for which the user has been granted the permissions. This creates an association between the Exchange directory and the Windows NT directory. The mailbox/NT-account association added complexity to the scalability of Exchange because two directories, each with their own requirements, are required to support the system across the enterprise.
As Windows NT evolved, it became apparent that the NT directory would have to be greatly enhanced to make Windows NT a contender in the data-center. Microsoft needed a directory service that could compete with the likes of Novell's Directory Service (NDS), another X.500-based directory service. The Exchange directory, already proven scalable, was chosen as the prototype for the Windows NT 5.0 directory. Hence, the Exchange directory evolved into Windows 2000 Active Directory. This means that Exchange administrators and implementers are going to see familiarities between the Exchange directory and Active Directory.
This also means that when you use Exchange 4.0 or 5.x with Active Directory, you are supporting two X.500-like directories in the same environment. Both directories employ a multi-master directory that replicates all the changes between Domain Controllers (DCs) or Exchange servers.
Fortunately, Microsoft provides an efficient tool to synchronize these two directories. This enables organizations to continue with the investment made in maintaining the rich data found in the Exchange directory. This also means that Active Directory can be populated with data from the Exchange directory.
Supporting Two Directories
Many organizations are going to migrate from Windows NT to Windows 2000 for the added value it brings to their organizations. Those organizations that also support Microsoft Exchange 4.0 or 5.x have the opportunity to upgrade to Exchange 2000, Active Directory-integrated version of Microsoft Exchange. However, after energy and budget has been spent on the migration to Windows 2000, it is likely that the upgrade to Exchange 2000 will take place sometime after the Windows 2000 migration project is complete.
This means that Windows 2000 Active Directory and Exchange 4.0 or 5.x will have to coexist. Two directories need to be maintained, supported, and synchronized. Users have access to two X.500-like directories and should be able to find the information they are looking for in either. This means that if a change is made to a user's phone number in the Exchange directory, the change should be synchronized as soon as possible to Active Directory. A user should not see two different phone numbers for the same user, depending on the directory the user queries.
Synchronization adds some complexity to supporting two directories. Before, when there was just Windows NT and Exchange, the information contained in each was mutually exclusive. For example, there was no phone number attribute in the Windows NT directory. Hence, synchronization between the directories was not an issue. However, with the Exchange and Active Directory directories, synchronization is necessary because your organization's directory data is duplicated across two directories and must be synchronized.
Active Directory Connector and Windows 2000
Microsoft provides the Active Directory Connector (ADC) with Windows 2000 as a means of synchronizing the Exchange 5.5 directory and Active Directory, see Figure 18.2. There are two versions of the ADCs. One that ships with Windows 2000, and one that ships with Exchange 2000. The Windows 2000 version synchronizes mail-enable objects between Exchange 5.5 and Active Directory. The Exchange 2000 version of the ADC not only synchronizes mail-enabled objects between the two directories, but it also synchronizes the configuration between the Exchange site and the Active Directory configuration partition. If Exchange 5.5 is to be supported by Windows 2000 and Active Directory and synchronization is required between Exchange 5.5 and Active Directory, the ADC that ships with Windows 2000 is one required. The version of ADC that ships with Exchange 2000 is discussed later in this chapter.
The ADC uses Lightweight Directory Access Protocol (LDAP) 3.0 to access and update each directory as changes are made. Currently, the ADC only synchronizes Active Directory with Exchange 5.5.
Connection Agreements
On the ADC, connection agreements are configured between each directory. These connection agreements define which objects are synchronized between each directory. Connection agreements also define which Exchange recipient containers synchronize with which Active Directory organizational units (OUs).
Connection agreements are configured with such parameters as
Synchronization directory, which defines the direction synchronization in which occurs.
Which containers in each directory are synchronized.
A synchronization schedule, which defines the times at which synchronization occurs.
What happens to deleted objects in each directory, and whether they are deleted in the synchronized directory or whether the deletion is logged.
Whether the connection agreement is considered a primary connection agreement, which is the connection agreement that synchronizes new objects created in a directory. There is a primary connection agreement parameter for each synchronization direction. This parameter should only be specified on one connection agreement per Active Directory domain and on one connection agreement per Exchange site.
The configuration of connection agreements is simple and works well. However, there are instances in which the ADC design can be tricky. For example, an Exchange multi-site design might have been based on the top-level Windows NT domain topology of an organization, as seen in Figure 18.3.
Figure 18.3. Typical multi-site Exchange organization.
If this organization upgrades from Windows NT to Windows 2000 and Active Directory, the three Windows NT domains are collapsed into two splitting the users of Domain 2 between Active Directory Domains X and Y, as in Figure 18.4.
Now that the Windows NT Domain 2 no longer exists, its users have been split between the two Active Directory domains, X and Y (assuming Domain 2 was not absorbed by a single domain). In this situation, you only want to synchronize the domain objects with the site that hosts those objects. In addition, you need to decide as to where new objects in each domain and site are synchronized.
New objects created in Site A synchronize to Domain X. Also, new objects created in Domain X synchronize with Site A. Hence, the connection agreement between Site A and Domain X is configured as the primary connection agreement for the both the Exchange site and Active Directory domain.
New objects created in Site B synchronize to Domain X. Therefore, the connection agreement between Site B and Domain X is configured as the primary connection agreement for the Exchange site.
The connection agreement between Site B and Domain Y only synchronize objects that already exist in both Site B and Domain Y. This connection agreement is not configured as a primary connection agreement.
New objects created in Site C synchronize to Domain Y. Also, new objects created in Domain Y synchronize with Site C. Hence, the connection agreement between Site C and Domain Y are configured as the primary connection agreement for both the Exchange site and the Active Directory domain.
Figure 18.4. A typical multi-site Exchange organization after domain upgrade and consolidation.
With this configuration, connection agreements need to be defined between sites and domain that meet these requirements (see Figure 18.5). It is important to make sure all objects can synchronize with the corresponding directory container in which they belong. In addition, each site and directory must have a corresponding directory container in which new objects are created.
Figure 18.5. Connection agreements.
In this example, the primary connection agreements are configured so that new objects created in Site B synchronize with Domain X. The other connection agreements have been defined to meet the requirements previously defined.
ADC in the Lab
The ADC can also be used in your Active Directory lab. After you have designed one or more Active Directory domain topologies, you can use the ADC to import production data from your Exchange organization into the lab to test your Active Directory design(s).
This is done with one-way connection agreements from the production Exchange environment to the lab, as shown in Figure 18.6. After the directory data has been brought into the lab, you can test your Active Directory design. In addition, as changes are made to the Exchange directory, they are synchronized to the lab. After they are synchronized into the lab to the server defined in the Connection Agreement, they are replicated around the lab domain. This gives you the opportunity to see how Active Directory handles replication in your organization.
Figure 18.6. A lab using an ADC with one-way connection agreement.
Deploying the ADC
How the ADC is deployed also has to be planned and should be included in your implementation plan. This is important because the ADC changes the Exchange directory schema. If a connection agreement is created for a site for the first time, several attributes are changed and added to the Exchange schema. These schema changes to the Exchange directory are replicated to every Exchange server in the organization. Therefore, if you were to implement the ADC and its connection agreements to several sites at the same time, a considerable amount of Exchange replication traffic would occur across your organization. Hence, it is prudent to rollout the ADC in stages, allowing each site to replicate its schema changes before the next connection agreement is created. Create an ADC implementation schedule as part of your implementation plan, which addresses replication at a pace your infrastructure can withstand.
It is possible to install the ADC on an Active Directory DC. After this is done, the ADC does not need to communicate with the DC across the network for those connection agreements to the DCs domain. Rather, the ADC can open the LDAP session with the local DC. This reduces network bandwidth consumption by the ADC, but consumes DC resources. Whether this is prudent depends on the complexity of your environment, the number of changes made to your directories, and the size of your DCs.
Administration
Your Active Directory design should also define the way that your two directories are administered after synchronization is established using the ADC. If two-way connection agreements are created between the directories, changes can be made to either Active Directory or the Exchange directory. You might decide that all changes to mail-enabled objects, such as users with mailboxes, distribution lists, or custom recipients (Active Directory mail-enabled contacts), are done from the Windows 2000 Users and Computers management tool. The only thing that the Exchange administrator is used for is to change Exchange site configuration. Another option is for Exchange administration to take place as before, with all mail-enabled object changes made using the Exchange administrator. These changes would be reflected in Active Directory after it is synchronized.
The administration method you choose depends on the administration model that you currently have. If you plan to consolidate administrative tasks to groups of administrators who administer both users and mailboxes, then using users and computers to administer all mail-enabled objects is the best choice. If you plan to keep your current messaging system administration model, even at the mail-enabled-object level, separate from Active Directory administration, then segregating administration between users and computers, and the Exchange administrator is the best choice.
It is important to understand how the ADC works and how it is used in your environment. If your organization uses Microsoft Exchange, create a section in your Active Directory design for the ADC. This section should include how the ADC are deployed, what connection agreements exist, the frequency of synchronization, a way to monitor synchronization, and how the ADC is supported.
Competing Services
Windows 2000 and Microsoft Exchange can offer similar services. Another complication of supporting Exchange on Windows 2000 is deciding which services to offer on which system.
LDAP
If you host Microsoft Exchange on an Active Directory DC, two systems on the same computer are trying to use LDAP over Transmission Control Protocol (TCP) port 389. This causes TCP port contention and both services to fail. To avoid this, you should change the Exchange LDAP port to something other than TCP port 389.
After this change is made, everything should work fine; however, all LDAP clients that try to contact the Exchange server need to reference the new LDAP TCP port. For example, if you install Exchange on an Active Directory DC, change the Exchange LDAP TCP port to 390, configure an ADC connection agreement to the Exchange server, and then also specify the LDAP port on the connection agreement port 390.
SMTP
Windows 2000 comes with an SMTP host that can be used for several things, such as Active Directory replication between Active Directory DCs. Microsoft Exchange also has an SMTP host that can be used to connect Exchange sites or to communicate with foreign SMTP hosts, such as those on the Internet. If a Windows 2000 server supports an Exchange server, make sure that SMTP is only required by one of these systems. If the Exchange server running on Windows 2000 has the Internet Mail Service (IMS) configured, make sure the Windows 2000 SMTP host is not required.
Both a Windows 2000 Server and an Exchange server SMTP host can be supported on the same computer, as in Figure 18.7. This is made possible by changing the TCP port of one of the SMTP host from port 25 to another available TCP port. However, this means that the other SMTP hosts in this environment have to use that same SMTP port for communications.
Figure 18.7. Two SMTP hosts on the same computer.
Although this is possible, it adds complexity to the configuration of your environment, and it should be avoided if possible.
Network News Transport Protocol (NNTP)
NNTP is another protocol that can exist on both Windows 2000 and Microsoft Exchange. To avoid port contention, as with SMTP, make sure that both Windows 2000 and Exchange are not both trying to use NNTP port 119.
It is also possible to change the TCP port associated with NNTP. The same rules and complexities apply that applied to SMTP.
Exchange 5.5 During the Upgrade
If upgrading from Windows NT to Windows 2000 Active Directory, special attention needs to be paid to user accounts and service accounts with regards to Exchange.
As you upgrade your NT domains, you want to make sure the association between the user's mailbox and NT account remains intact during the upgrade. This might influence the NT upgrade method you choose (see Chapter 22, "Upgrading from Windows NT 4.0," for more details).
If you upgrade your NT domain in place, the Exchange mailbox association should remain in place. If you intend to consolidate domains, which is likely, you need to consider whether it is possible to consolidate your NT 4.0 domains before the upgrade without breaking this mailbox/NT account association. If you are going to consolidate your domains after the upgrade, it is possible to upgrade your NT domains in place, to change your Active Directory to Native Mode, and then to use tools, such as MoveTree, to consolidate Active Directory domains. This should also keep your mailbox associations in place.
Whichever route you choose, lab testing plays an important roll in determining whether your Exchange mailboxes will maintain their associations with the proper Active Directory user accounts during the upgrade. This is yet another example of why lab testing is paramount to planning your Active Directory and to its implementation.