Achieve the highest level of Exchange 2000 and Exchange Server 5.5 interoperability
In "Real Life ADC Deployment, Part 1," May 2001, I discussed some key functionality of the Active Directory Connector (ADC): recipient and configuration connection agreements (CAs), schema extensions, and object-matching behavior. Knowledge of these elements is crucial to using the ADC in a real-world environment.
The following scenarios, based on customer deployments, show how various organizations have deployed the ADC and implemented CAs. Although deployment possibilities are infinite, a few select approaches help you achieve the highest level of interoperability between Microsoft Exchange 2000 Server and Exchange Server 5.5 systems.
Understand What You Have
There's no better plan for a failed migration than neglecting to plan for a successful one. All Exchange Server 5.5 to Exchange 2000 migration projects should commence with a thorough examination of the existing environment so that you can gauge exactly what you need to do and how best to deploy the new system. Understanding the network topology and infrastructure is crucial. Line speeds and the network model, whether it's hub-and-spoke or fully meshed, will help determine the topology of your Exchange 2000 Routing Group (RG) design. And understanding the network infrastructure lets you make key decisions about the placement of ADCs and CAs.
A CA will synchronize information from the Exchange Server 5.5 Directory Service (DS) to an Active Directory (AD) Global Catalog (GC) server. Although a few simple mouse clicks represent the configuration of this synchronization in the virtual world, in reality, you're looking at synchronizing a large amount of data between two servers that might be in different locations. Knowledge of the network will let you work closely with your Windows 2000 architects to place GCs at convenient locations (i.e., close to user populations for logon services and close to Exchange Server 5.5 systems for ADC-induced traffic).
Understanding the Win2K and Windows NT 4.0 domain models is also important when planning your migration from Exchange Server 5.5 to Exchange 2000. The current trend is to move away from a domain model that includes several NT 4.0 domains to a much simpler and more elegant Win2K model that uses fewer domains.
In addition, don't forget to consider the Exchange Server 5.5 site model. In Part 1, I outlined the requirement for at least one CA per Exchange Server 5.5 site because the Exchange Server 5.5 Site Recipients container is read-only outside the site. Therefore, the number of sites that your organization has will directly influence the number of CAs that you'll need to configure. Although no hard-coded limit exists for the number of CAs that you can create on one ADC, the best practice is to configure no more than 75 CAs. However, consider using multiple ADCs at strategic network locations to reduce the number of CAs. This setup will cut down on WAN traffic and directory-latency effects within the Exchange Server 5.5 DS and AD.
Before introducing any ADCs, identify any resource mailboxes (aka process mailboxes) that share one NT 4.0 account. Exchange 2000 requires every mailbox to have its own Win2K account.
Finally, audit NT 4.0 username and Exchange Server 5.5 site names to confirm that you have unique usernames and aliases. If you have multiple NT 4.0 domains, you might have uniqueness conflicts between domains, and Exchange Server 5.5 enforces unique aliases only within a site container. You can perform a manual audit if you have few users to deal with. For large numbers of users, a manual audit isn't feasible. In such cases, you need to write audit scripts or use a premigration audit utility from a third-party vendor such as NetIQ, FastLane Technologies, or BindView.
Put the Horse Before the Cart
If you're searching for the most straightforward approach to moving to Exchange 2000, the migration experience doesn't get much simpler than completely implementing Win2K before deploying any Exchange 2000 mailboxes. This approach does have a potential drawback: time. If your organization is small, upgrading an existing NT 4.0 PDC to Win2K (i.e., performing an in-place upgrade) might not be a difficult task. If you decide not to perform in-place NT 4.0 upgrades, your alternative is to use a migration tool such as the Microsoft Active Directory Migration Tool (ADMT). This tool uses the ClonePrincipal API to create a new Win2K account in a new Win2K domain, but the new account retains knowledge of the old NT 4.0 SID.
Larger organizations that include many domains might not be able to quickly perform an upgrade. Although a migration is simpler if you already have your Win2K infrastructure in place, wanting to get Exchange 2000 into operation might take precedence over deploying that infrastructure. In such circumstances, organizations deploy Exchange 2000 alongside Win2K and have working Exchange 2000 mailboxes long before all NT 4.0 accounts have been migrated to Win2K. This approach to Exchange 2000 deployment is popular with large organizations but is more complicated and results in a more sophisticated management environment. Let's look at some sample migration scenarios, starting with the simplest.
Upgrade One Domain, Then Introduce the ADC
Let's begin by looking at a fairly straightforward environment that comprises one NT 4.0 domain, FLINT, and two Exchange Server 5.5 sites, USA and Europe, in an organization named SPECTRE, as Figure 1 shows. This figure also shows the relationship between the NT 4.0 account for the user laahs and his Exchange Server 5.5 mailbox. These two entities are bound together because the primary NT account attribute (known in Exchange Server 5.5 as the Assoc-Nt-Account attribute) of Kevin Laahs's mailbox references the NT 4.0 account laahs's SID (i.e., 12345). Figure 1 shows an NT 4.0 and Exchange Server 5.5 operating environment in which no ADC or Exchange 2000 servers are in place.