Coexisting with the Exchange 5.x Directory

As we discussed in Chapter 4, “Understanding Windows Server 2003 Integration,” Active Directory has three naming partitions: configuration, schema, and domain. In this section, we will primarily be concerned with the configuration and domain naming partitions of Active Directory and how SRS and the ADC service allow the Exchange 5.x directory and the configuration and domain partitions of Active Directory to coexist. (The authors recognize that Exchange 4.x is built on directory services as well. However, for the sake of this discussion, we will use the phrase “Exchange 5.x” to refer to all previous Exchange systems, including both the 4.x and 5.x platforms.) Let’s spend some time looking at each of these services.

Site Replication Service

Site Replication Service is responsible for replicating Exchange 5.x site and configuration information to the configuration naming partition of Active Directory when an Exchange 2003 server belongs to an existing Exchange 5.5 site. This allows the Exchange 2003 server to be represented in the Exchange site server list so that earlier versions of Exchange Server can send messages to and receive messages from the Exchange 2003 server.

SRS consists of a service that is activated and a database that is initialized when the first Exchange 2003 server is introduced into a legacy Exchange site. Activation can also occur when an Exchange 5.5 directory replication bridgehead server is upgraded to Exchange Server 2003. If you install additional Exchange 2003 servers into the Exchange 5.5 organization, these servers will include SRS, but SRS will be disabled. The components of SRS are as follows:

• Site Replication Service application (Srsmain.exe)

• Site Consistency Checker (runs as part of Srs.exe)

• SRS database (Srs.edb) and transaction logs (ESE98 format)

Even though SRS is similar to the Exchange 5.5 directory service, its Name Service Provider Interface (NSPI) is disabled to prevent Microsoft Outlook clients from connecting to and using the Exchange 2003 directory for name resolution. If the NSPI were activated, Outlook clients could attempt name resolution in the wrong directory, leading to name resolution errors.

SRS must also run LDAP in order to communicate with Active Directory. Because the Microsoft Windows Server 2003 operating system also uses LDAP and locks the well-known port 389 for its own use, SRS defaults to using port 379 for its LDAP communications. No special configuration is needed for SRS to communicate with Active Directory using LDAP.

Unlike the ADC service, which we will discuss in a moment, SRS automatically installs its own connection agreement (Config CA). The agreement is between SRS and Active Directory rather than between Active Directory and the Exchange 5.5 directory. Config CA is the pathway through which SRS on the Exchange 2003 server passes configuration-naming data to Active Directory. This is a read-only agreement, and it can be seen in the Active Directory Connector Management snap-in, shown in Figure 16 2. (Read-only and other types of agreements are discussed more fully later in this chapter in the section “Active Directory Connector.”)

Figure 16-2: Read-only connection agreement in the Active Directory Connector Management snap-in.

To communicate with Exchange 5.x servers, SRS uses RPCs. Thus, to the Exchange 5.x servers, Exchange Server 2003, via SRS, looks like another Exchange 5.x server. If an Exchange 5.x bridgehead server is upgraded to Exchange Server 2003, SRS will notice this and communicate with that bridgehead server using SMTP.

Since SRS is a read-only service, meaning that it can’t be configured, there isn’t a great deal to manage. However, a couple of points are worth noting. First, this is a two-way connection agreement that cannot be modified. Second, recall that the agreement is between Active Directory and SRS. This can look confusing when you first encounter the interface because the agreement reports the Exchange server and the Windows Server 2003 server as the same server. You’ll be creating a connection “between” the same server because the server hosting the Exchange 2003 server that is installed into your Exchange 5.5 site is also a domain controller in the Windows Server 2003 Active Directory. This is most clearly seen on the Connections tab of the property sheet for the connection agreement, as illustrated in Figure 16-3.

Figure 16-3: Connection agreement “between” the same server.

Site Consistency Checker

The Site Consistency Checker (SCC) is an updated version of the Knowledge Consistency Checker from Exchange Server 5.5 and runs inside SRS. It ensures that knowledge consistency is maintained for sites and administrative groups when interoperating between Exchange Server 5.5 and Exchange Server 2003. In addition, in a large organization with many Exchange 5.5 sites, a triangulation of replication links, which would create duplicate replication paths, could be created as sites are migrated from Exchange Server 5.5 to Exchange Server 2003. The SCC ensures that as new replication links are created, triangulation is avoided in the link topology.

SRS Database

SRS uses the Extensible Storage Engine (ESE) database technology. You’ll find that it installs the same set of databases and transaction logs as a storage group. By default, these files are stored in the Exchsrv\srsdata folder. Unlike the stores in a storage group, the SRS database cannot be mounted or dismounted, but you can start and stop SRS in the Services utility.

Active Directory Connector

The Active Directory Connector is a service that runs on your Windows Server 2003 domain controller and allows you to synchronize your Exchange Server 5.5 and Windows Server 2003 directories. Unlike SRS, which replicates information between an Exchange 5.x organization and the configuration naming partition in Active Directory, the ADC service replicates information between the Exchange 5.x directory and the domain partition in Active Directory.

The ADC service comes in two versions: one ships with Windows Server 2003, and the other ships with Exchange Server 2003. The Windows Server 2003 version of the ADC service allows directory information in your Exchange Server 5.5 organization to be replicated to the Windows Server 2003 Active Directory. The Exchange 2003 version of the ADC service lets you synchronize Exchange Server 5.5 directory information with Windows Server 2003. It also works with SRS. If you’ve installed the Active Directory Connector in Windows Server 2003, Exchange Server automatically updates it to the Exchange 2003 version when you install Exchange Server 2003.

After you’ve synchronized the directories, as described in the sections that follow, Windows Server 2003 Active Directory generates the Global Address List of mail-enabled users for those users who connect to the Exchange 2003 server. Users connecting to the Exchange Server 5.5 directory will continue to access the Global Address List from the Exchange Directory Store.

Planning Connection Agreements in Active Directory Connector Service

You configure synchronization between your two directories by defining connection agreements that the ADC service manages. A connection agreement is just that—an agreement that you manually instantiate to define how directory information is synchronized between the two directories. You will define at least one primary connection agreement and one or more nonprimary connection agreements. The agreements must contain server names, objects to synchronize, target containers, and a synchronization schedule.

Connection agreements are either one-way or two-way. As the name implies, a one-way connection agreement allows directory information to flow in only one direction—from the directory you specify to the directory to which the connection agreement connects. For example, if a connection agreement is configured as one-way from directory D1 to directory D2, any changes made to objects in the D1 directory will be replicated to the D2 directory. However, changes made to objects in the D2 directory will not be replicated to the D1 directory. A two- way connection agreement allows replication to flow in both directions. Hence, changes made to objects in either directory are replicated.

When setting up your connection agreements, strive to match one or more containers in one directory with one or more containers in the other directory. Your environment, future plans, and network administrative model will all affect your choice. For instance, you can synchronize the default Recipients container in your Exchange 5.5 site with one Active Directory container—perhaps the Users organizational unit (OU). In this scenario, any subcontainers in the Recipients container will be created automatically under the Users OU, as shown in Figure 16-4.

Figure 16-4: Container synchronization.

You can also synchronize from one Exchange container to multiple Active Directory containers by choosing to replicate one object class to one Active Directory OU and another object class to another Active Directory OU. For instance, if all your Exchange 5.5 recipients were created in the default Recipients container, you could choose to replicate your user objects to a Users OU in Active Directory and your custom recipients to a Contacts OU, as shown in Figure 16-5.

Figure 16-5: Object class synchronization.

By the same token, you can synchronize multiple Exchange containers with multiple Active Directory containers or synchronize multiple Active Directory containers with multiple Exchange containers. Moreover, you can configure each connection agreement to synchronize single or multiple object types. This service gives you the opportunity to rearrange your object hierarchy in Active Directory.

Installing the ADC Service

You install the ADC service from the ADC folder on the Exchange 2003 companion CD-ROM. During the installation, the installation wizard prompts you to choose the Microsoft Active Directory Connector Service Component, the Microsoft Active Directory Connector Management Components, or both (Figure 16-6). Selecting Microsoft Active Directory Connector Service Component installs the ADC service (Adc.exe). Selecting Microsoft Active Directory Connector Management Components installs the Active Directory Connector Management snap-in into a separate Microsoft Management Console (MMC).

Figure 16-6: ADC service installation choices.

The user account that you log on with to install the ADC service must have the ability to modify the schema; otherwise, you’ll receive an error message. However, if Exchange Server 2003 is already installed somewhere in your Windows Server 2003 forest, schema modifications are not necessary when installing the ADC service, since the schema has already been extended.

Next, the installation wizard asks for a location for the installation files and for the administrator name and password in the Windows Server 2003 domain. The final installation screen asks you to finish the installation.

Tip

After you’ve migrated all of your directory information to Windows Server 2003 and fully implemented Exchange Server 2003, you’ll no longer need the Active Directory Connector service because you’ll no longer have any Exchange 5.5 servers. If you choose to uninstall the ADC service, you must first delete all the connection agreements you defined on the local server. Best practice would be to do this after you have switched your Exchange 2003 organization to native mode.

Configuring the Active Directory Connector Service

Once you’ve installed the ADC service, you’ll need to create the primary connection agreement. To do so, launch the ADC service snap-in by choosing Active Directory Connector from the Microsoft Exchange menu. Right-click the server name, point to New, and choose either Recipient Connection Agreement or Public Folder Connection Agreement. For our discussion in this chapter, we’ll use Recipient Connection Agreement. You’ll need to give your connection agreement a name that describes the function it will serve. Figure 16-7 illustrates how to name a two-way agreement.

Figure 16-7: Naming a two-way connection agreement.

Connections Tab On the Connections tab shown in Figure 16-8, we’ve configured the Connect As values for each server because these two servers are in different domains and we are writing from each directory to each directory. If you have different domains, which will usually be the case when migrating from Exchange Server 5.x to Exchange 2003, you will need to enter Connect As values for each directory to which you would like to write information that is generated in the other directory.

You can also specify the port number that will be used by Exchange Server 5.5. You’ll need to change this port number if your Exchange 5.5 server is running on a Windows Server 2003 domain controller. When Windows Server 2003 boots up, the Active Directory LDAP services start before any Exchange services, and the LDAP service locks port 389 (the default LDAP port) for its own use. If you leave the port number at 389 for the ADC service to use in this scenario, the ADC will fail to bind to the Exchange directory because of a port number conflict. Most administrators choose port 390 in this situation.

Figure 16-8: Connections tab of the ADC service property sheet.

Tip

If you’re running Exchange Server 5.5 on a Microsoft Windows NT 4 server, be sure to specify the domain name in front of the Windows NT 4 user name that you use to log on to the domain (for example, domain name\username). If you don’t specify the domain name, you’ll receive an 8026 error message in the Event Viewer application log informing you that the bind was unsuccessful.

Schedule Tab You configure the replication interval for the connection agreement on the Schedule tab (Figure 16-9). Setting the replication interval to Always will cause the connection agreement to replicate every 15 minutes. You can force the entire directory to replicate the next time the software runs the agreement, whether it runs on a predetermined schedule or not, by selecting the Replicate The Entire Directory The Next Time The Agreement Is Run check box. Selecting this option sets the msExchServerXHighestUSN attribute to 0 and the msExchDoFullReplication attribute to True for the connection agreement.

Figure 16-9: Schedule tab of the ADC service property sheet.

From Exchange and From Windows Tabs The From Exchange tab (Figure 16-10) and the From Windows tab (Figure 16-11) let you set which containers and objects in your Exchange 5.5 site will replicate to Windows Server 2003 Active Directory and vice versa.

Figure 16-10: From Exchange tab of the ADC service property sheet.

Figure 16-11: From Windows tab of the ADC service property sheet.

By default, each Exchange site has one Recipients container. If you’ve created multiple subcontainers under the Recipients container, you have several options for replicating your objects to Windows Server 2003. If you want to retain the same container structure in Active Directory, create one connection agreement and choose the Exchange site as the source container. Active Directory will automatically create the same container structure in its directory and populate it accordingly. If you want to consolidate several Exchange containers into one container in Active Directory, create one connection agreement and individually choose each of the containers as the source, pointing them to the same container in Active Directory.

If you want to have complete control over each container (for example, if you want to have the mailbox container replicate every 30 minutes but have the custom recipient container replicate every 12 hours), create a separate connection agreement for each container, specifying your source and target containers.

If you want to change your recipient structure entirely in Active Directory from what it was in Exchange 5.x, you have two options:

• You can choose one connection agreement, replicate your Exchange containers to one Active Directory container, and then manually move the objects within the Windows Server 2003 containers after they exist in the Active Directory.

• You can create multiple connection agreements and have each connection agreement process one Recipients container (or object type) and point it to a specific OU in Active Directory. Generally speaking, unless you have a specific reason to choose the previous option, it’s best to use this technique, since it is both easier and limits the possibility of human error when moving objects from one container to another.

On the From Windows tab, you can select the Replicate Secured Active Directory Objects To The Exchange Directory check box. Normally, any object with any Deny access control entry (ACE) set would not be replicated to your Exchange 5.5 directory. Selecting this check box disables the filtering of objects based on the specified Deny ACE so that those objects are replicated from Windows to your Exchange 5.5 directory. Deny ACEs can be set on the Security tab of the object in question.

Deletion Tab The Deletion tab (Figure 16-12) lets you specify how you want the target directory to manage deleted objects in the source directory. You can either have the deleted object replicated to the target directory or have it cataloged in the appropriate import file format. If you choose to delete the objects, the target directory’s tombstone setting will determine when the object will be deleted. If you choose to catalog the deletion list, you’ll need to manually perform a directory import and choose to have all the objects being imported deleted during the import process.

Figure 16-12: Deletion tab of the ADC service property sheet.

Note

Tombstoning affixes a future date and time to an object after deletion so that all copies of the object in the directory will be deleted at the same time. This practice prevents replication services from backfilling a deleted object into the directory and presenting it as though it had never been deleted.

Remember that Windows Server 2003 strips an object of its permissions after you delete it. If you think you might want to use a deleted object again, keep it in the deletion list and then import it again when you need the object.

Advanced Tab On the Advanced tab (Figure 16-13), you need to configure several important values. First, in the Paged Results area, you can change the number of entries per LDAP page. Increase this value if your Exchange 5.5 server is running on a Windows Server 2003 domain controller. You want to do this because both Active Directory and the ADC service will be using LDAP to send and receive queries. Paging improves performance by grouping together objects to be replicated before each replication request. Larger page sizes (containing more objects per page) require fewer LDAP requests to complete replication of all objects, but they also require more memory to operate. Setting the page size to 0 results in no replication; do this only if you want to disable the connection agreement.

Figure 16-13: Advanced tab of the ADC service property sheet.

Be sure to give careful attention to the check boxes for configuring primary agreements. The This Is A Primary Connection Agreement For The Connected Exchange Organization option is the default. A primary connection agreement will attempt to create new objects in the target directory when synchronizing objects from one directory to another. Furthermore, if a mailbox in Exchange Server 5.5 has no primary user account, and no corresponding Windows Server 2003 user account exists in Active Directory, a primary connection agreement will create a new user account as part of the replication of the mailbox.

A nonprimary connection agreement doesn’t create new objects in the Exchange Server 5.5 directory and instead replicates only attributes between the Exchange Server 5.5 mailbox and its corresponding Windows Server 2003 user object. Furthermore, if the connection agreement is nonprimary, the ADC service establishes replication only if you’ve designated a primary user account on the mailbox’s General tab. If no primary user account is designated for the Exchange 5.5 mailbox and no corresponding Windows Server 2003 user object exists, a nonprimary connection agreement won’t attempt to create the user object in Active Directory.

Having multiple two-way, primary connection agreements to multiple Exchange Server 5.5 sites from one Active Directory container means that each new object you create in the Active Directory container will replicate to each Exchange Server 5.5 site directory. This scenario will create multiple instances of the same object in your Exchange Server 5.5 organization. The Exchange 5.5 Directory Service will then replicate these objects throughout the organization. If you need to synchronize multiple Exchange sites with one container in Active Directory, configure your connection agreements as one-way from Exchange, with only one two-way connection agreement. This configuration will allow newly created objects in Active Directory to be replicated to your Exchange 5.5 directory without incurring multiple instances of that object.

If you want to create multiple connection agreements from the Active Directory to the Exchange Server 5.5 directory, it’s best to set only one connection agreement as primary and the rest as nonprimary. Do this by clearing the This Is A Primary Connection Agreement For The Connected Windows Domain check box on all but one of your connection agreements. The overall effect will be that an object created in Active Directory will be created only once in the Exchange 5.5 directory. You’ll need to consider which Exchange 5.5 sites should receive the newly created Active Directory objects.

The most complicated scenario is one in which you need to have certain objects that are created in Active Directory replicated to certain Exchange 5.5 sites and other objects created in Active Directory replicated to other Exchange 5.5 sites. If this is your situation, consider creating separate primary connection agreements from different Active Directory containers to each Exchange 5.5 site. Although doing so will increase the complexity of your ADC service administration, it will allow you to specify which Active Directory objects are replicated to which Exchange 5.5 site.

Associated with the This Is A Primary Connection Agreement For The Connected Windows Domain check box is the setting This Is The Primary Connection Agreement For The Connected Exchange Organization check box, used for replicating a mailbox object that has no corresponding primary user account in Active Directory. This check box controls whether an object is created in the Windows Server 2003 domain if no user account match exists between the two directories. The When Replicating A Mailbox Whose Primary Windows Account Does Not Exist In The Domain drop-down list becomes unavailable if you clear the check box. Use this setting if you need to migrate several mailboxes and you’re sure that some of the mailboxes don’t have user accounts in Active Directory.

The This Is An Inter-Organizational Connection Agreement check box should be selected if the connection agreement is being made between two Exchange organizations, which would be the case when uploading directory information from an Exchange 5.x organization to a Windows Server 2003 Active Directory whose schema has already been extended with an Exchange 2003 directory. It is also selected when you are replicating your 5.x information to an Active Directory that has no Exchange 2003 organization defined, and thus whose schema has not been extended to include Exchange 2003 objects.

You would not want to select this option if you have installed an Exchange 2003 server into an existing Exchange 5.5 organization. In this case, the Exchange 2003 organization and the Exchange 5.5 organization are the same.

When replication is scheduled to occur within a two-way connection agreement, you can choose the direction in which replication will occur first in the Initial Replication Direction For Two-Way Connection Agreements check box.

Summary of ADC Options

Because this can be a bit confusing, we thought we’d make a quick reference list available to you as you think through your CA options:

• If you’re coming from a single Exchange 5.5 site, create one connection agreement to retain the same container structure in Active Directory.

• To consolidate multiple Exchange Server 5.5 containers into one container in Active Directory, create one connection agreement and choose each of the Exchange containers individually as a source.

• To have complete control over the synchronization of each Exchange 5.5 container as it replicates to Windows Server 2003 Active Directory, create a connection agreement for each source container.

• To substantially change your container model, either configure one connection agreement, move all your source objects into one Windows Server 2003 container, and then manually move the objects within the Active Directory; or set up multiple connection agreements that specify each source and destination container.

Setting the Default Policy for the ADC Service

By right-clicking the Active Directory Connector Management snap-in in the MMC, you can configure which attributes of each object you want to replicate to the other directory. As was mentioned previously, a nonprimary connection agreement replicates only the attributes of an object to the other directory. This property sheet lets you choose the attributes you want to replicate.