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.
When you perform an in-place upgrade of the FLINT domain to Win2K, Exchange Server 5.5 mailboxes are still accessible because SID values for objects remain unchanged during an in-place domain upgrade. The next step in the migration process is to install an ADC server and configure CAs. Define the CAs as 2-way CAs between each Exchange Server 5.5 site and the Users organizational unit (OU) in AD. As Figure 2 shows, direct the Exchange Server 5.5 endpoint of a CA to the Recipients container in the Exchange Server 5.5 site and the Win2K AD endpoint to the Users OU. Alternatively, you could direct the Exchange Server 5.5 CA endpoint to the site container of the Exchange Server 5.5 site. In this setup, the ADC synchronizes objects from all containers within the site to AD.
When the ADC runs, it will match the Assoc-Nt-Account attribute value from each Exchange Server 5.5 mailbox with the SID of the corresponding AD user object. Thus, the ADC creates no new AD user objects and merges mailbox attribute information from the Exchange Server 5.5 DS into each AD user object.
As you introduce Exchange 2000 servers into the Exchange Server 5.5 environment and move user mailboxes from Exchange Server 5.5 stores to Exchange 2000 stores, the ADC updates the attributes of existing user objects to reflect the new mailbox location. Again, the ADC creates no new user objects in AD for the new Exchange 2000 mailboxes.
Introduce the ADC, Then Upgrade Complex Domain Environments
Although many smaller organizations face the migration of only one domain, larger organizations usually have more complex environments. For example, consider an environment with a reliable hub-based network infrastructure that can support Win2K and Exchange 2000. Figure 3 shows this network's backbone topology, which consists of six core network locations connected by high-speed links on an asynchronous transfer mode (ATM) backbone. Each core network location acts as a hub for outlying locations that use low-speed lines (e.g., 64Kbps to 512Kbps) to connect to the network backbone. Figure 4 shows the Win2K domain model, in which Win2K sites are defined in line with the network model. Four domains—flint.com, americas.flint.com, emea.flint.com, and asiapacific.flint.com—center on each network core location.
The domain model in Figure 4 is typical of domains that many large organizations deploy. In this environment, the bulk of user accounts, computer accounts, and group objects are in the child domains of americas.flint.com, emea.flint.com, and asiapacific.flint.com. The root domain, flint.com, holds little and serves primarily as a placeholder for the domain tree. However, you commonly find a few administrator accounts or groups held in the root domain.
Layered on top of this network and Win2K environment is the Exchange Server 5.5 infrastructure. For this discussion, let's assume that every core and outlying network location has one Exchange Server 5.5 system. (Thus, the network contains a total of 17 Exchange Server 5.5 sites: 1 at each of the 6 core locations and 1 at each of the 11 outlying locations.) You must set up a CA from each Exchange Server 5.5 site to a GC in each Win2K site. (Figure 3 shows the site boundaries.) At each core location, place an ADC that hosts CAs for all the Exchange Server 5.5 sites at outlying locations connected to the core location so that each Exchange Server 5.5 site is one hop away from its local network hub. Therefore, you'll have six ADC servers each hosting several CAs—one CA for each Exchange Server 5.5 site within the bounds of each Win2K site.
In this environment, a high degree of synergy exists between the Exchange Server 5.5 sites and how they map to the geographical Win2K domain structure. You can associate each Exchange Server 5.5 site with one of the Win2K domains, and one CA for each Exchange Server 5.5 site will map the Exchange recipients to the Users OU in each of the domains. For example, the americas.flint.com domain will have seven CAs to its Users OU, emea.flint.com will have six CAs, and asiapacific.flint.com will have four CAs. If the outlying locations Kuala Lumpur and Melbourne are directly connected to the core locations Singapore and Sydney, respectively, you would map the Exchange Server 5.5 sites through CAs to the Users OU in the asiapacific.flint.com domain.
The configured ADCs and CAs will then match mailboxes from each of the Exchange Server 5.5 sites to the already upgraded or migrated user objects in each of the Win2K domains. This matching process will proceed in one of two ways. If you created the Win2K domains by upgrading NT 4.0 domains in-place, the ADCs will match mailboxes by using the Exchange Server 5.5 mailbox Assoc-Nt-Account attribute against the AD object's SID because SIDs are maintained during a domain upgrade.
If you restructured rather than upgraded your old NT 4.0 domains (i.e., the Win2K topology bears little resemblance to the NT 4.0 topology), you would have created the new Win2K domains and objects by using a ClonePrincipal tool such as the ADMT. Win2K objects that have been cloned from NT 4.0 have a completely different SID from their NT 4.0 counterparts; thus, ADC can't perform a match by using the Assoc-Nt-Account attribute with the SID of the Win2K object. However, the new Win2K object maintains the SID of the old NT 4.0 object in the SIDHistory attribute. ADC is just as capable of matching the Assoc-Nt-Account attribute of the Exchange Server 5.5 mailbox with the SIDHistory attribute of the new Win2K object.
You can have ClonePrincipal-based migration tools change the value of the Exchange Server 5.5 mailbox Assoc-Nt-Account attribute as they clone NT 4.0 user accounts. During this optional process, the tool changes the Assoc-Nt-Account attribute value from the SID of the NT 4.0 object to the SID of the new Win2K object. Because the Assoc-Nt-Account attribute is identical to the SID of the new Win2K object, these values will let the ADC match an Exchange Server 5.5 mailbox directly with the SID of the Win2K object.
Whatever Win2K upgrade approach you take, the ADC will be able to match the Exchange Server 5.5 mailbox with an existing Win2K account and merge information from the Exchange Server 5.5 DS into AD. The ADC won't create any new objects.
Little difference exists between setting up ADCs and CAs in a network that has three child domains versus a network that has just one domain and two Exchange Server 5.5 sites: Each scenario requires one CA per Exchange Server 5.5 site. For a network that has multiple domains, you'll benefit greatly from mapping complete Exchange Server 5.5 sites to any given domain because this setup greatly simplifies the CA topology. If your topology dictates that objects from a given Exchange Server 5.5 site must be split across multiple Win2K domains, you'll need at least one CA per Win2K domain for each Exchange Server 5.5 site. Furthermore, unless your Exchange Server 5.5 objects are in containers that map directly to each of the target Win2K domains, you'll need to use a Lightweight Directory Access Protocol (LDAP) search filter or an object-matching rule on each CA so that a CA processes only objects to be synchronized into the specific domain.
Introduce the ADC, Deploy Win2K
Many organizations want to deploy Exchange 2000 before they migrate their entire NT 4.0 environment to Win2K. When you've upgraded or migrated all NT 4.0 objects to Win2K objects, the ADC merely matches Exchange Server 5.5 mailboxes with Win2K user accounts. However, if you haven't moved any NT 4.0 objects to Win2K, AD isn't useful as a Global Address List (GAL) for Exchange 2000.
In a mixed environment in which Exchange 2000 users function alongside Exchange Server 5.5 users, the ADC must create objects in AD to represent the Exchange Server 5.5 mailboxes and provide a complete and consistent GAL. Many organizations use a temporary OU structure in AD to hold the ADC-created objects. Separating the ADC-created objects, which are usually disabled user objects, from real Win2K user objects that you've migrated from NT 4.0 has several benefits. This separation lets systems managers easily differentiate between user accounts that they've migrated and those that the ADC created. In addition, the real Win2K user accounts usually reside in an OU structure that has specific access control and Group Policy Object (GPO) settings; having these settings apply to the temporary ADC-created objects isn't desirable. From a CA perspective, using the temporary structure lets you define the minimum number of CAs (one per site) to represent all Exchange Server 5.5 mailboxes. Using just one CA per site means that you recreate the container hierarchy from the Exchange Server 5.5 site, and you probably don't want to maintain this structure in the final AD model. If you map directly to the final AD hierarchy and don't use the temporary OU structure, you'd need one CA per container for every Exchange Server 5.5 site. In a large environment, this requirement might result in hundreds of CAs.
In the network model, Win2K model, and ADC-placement strategy I discussed in the previous section, you'd expect a Win2K domain structure similar to the one that Figure 5 shows. The OU hierarchy in this figure relates to only the asiapacific.flint.com domain, but the same OU hierarchy would exist in the other child domains for this AD forest. In Figure 5, user objects will ultimately live in a specially created Users OU under an Accounts OU. Using the Accounts OU lets you define a specific structural model for AD that separates user objects, groups, resource objects, and administrative roles.
Let's step through the process for migrating users into this domain (assuming no native Win2K objects exist, so you effectively have an empty AD). Use the ADC to create disabled user objects in the Temp OU. A 2-way CA from each Exchange Server 5.5 site (i.e., Singapore, Kuala Lumpur, Sydney, and Melbourne), yielding four CAs in total, creates sub-OUs in the Temp OU that reflect the Exchange Server 5.5 site structure. The mail-enabled objects created provide a complete GAL for any Exchange 2000 users. As you migrate NT 4.0 accounts to Win2K accounts, the migration tool should detect the matching ADC-created object already present in the Temp OU and merge the objects. This merge results in one object in its final location in the Users sub-OU of the Accounts OU.
Third-party migration tools from BindView, NetIQ, and FastLane all support this ability to detect matching objects and perform merge operations. However, the free ADMT doesn't support this functionality. If you use the ADMT to migrate the account, you'll create a duplicate object in AD, and you must use the AD Cleanup Wizard to resolve this problem. (For information about the AD Cleanup Wizard, see "Related Articles.")
This migration model requires some sophistication with CAs. Figure 6 shows the required CA configuration for the Singapore Exchange Server 5.5 site. The 2-way CA between the Exchange Server 5.5 site and the Singapore OU in the Temp OU is sufficient to synchronize objects bidirectionally between Exchange Server 5.5 and AD for as long as the ADC-created object exists. As you migrate the NT 4.0 account to Win2K, the migration tool (or the AD Cleanup Wizard) will merge the ADC-created object with the migrated object; the newly merged object will be in the Accounts OU. The migration tool (or AD Cleanup Wizard) also merges attributes, so ADC information associated with the ADC-created object will be associated with the newly merged object in the Accounts OU. The 2-way CA between the Exchange Server 5.5 site and the Temp OU ensures that the ADC still replicates any changes made to the Exchange Server 5.5 mailbox to the newly merged object, even though the object is now in a different AD location. (The CA uses the ADCGlobalNames attribute and the Win2K globally unique ID—GUID—to track the object.) However, the 2-way CA is capable of replicating changes only from Exchange Server 5.5 to AD; it can't replicate changes from AD to Exchange Server 5.5. Replicating changes made directly to the AD object requires another CA: a 1-way CA from the Accounts OU to the Exchange Server 5.5 site.
You should apply this CA topology to every Exchange Server 5.5 site in your organization. Every Exchange Server 5.5 site will require a 2-way CA to the Temp OU and a 1-way CA from the Accounts OU to the Exchange Server 5.5 site. For the scenario I've described, the 17 Exchange Server 5.5 sites would require a total of 34 CAs (i.e., 17 two-way and 17 one-way CAs).
Closing Thoughts
In this short series, my intent was to build on fundamental knowledge about the ADC and describe how you can put the ADC to work in real-life environments. Although discussing every deployment possibility is impossible in two articles, I've described two scenarios that are based on real working environments in use by two large multinational organizations. Each organization has taken a significantly different approach to interoperability and migration. One company had the luxury of waiting until its Win2K deployment was complete, which results in a fairly straightforward ADC and CA configuration. The second organization had to aggressively deploy Exchange 2000 before the Win2K deployment was complete. This task results in a more sophisticated AD model and a more intricate ADC and CA implementation. Both approaches are valid and provide the same level of interoperability and high-fidelity directory synchronization between Exchange 2000, AD, and Exchange Server 5.5. You simply need to decide which approach is most appropriate for your organization and implement it.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com. KIERAN MCCORRY "Real-Life ADC Deployment, Part 1," May 2001, InstantDoc ID 20395 EXCHANGE ADMINISTRATOR ARTICLES You can obtain the following articles from Exchange Administrator's Web site at http://www.exchangeadmin.com. KIERAN MCCORRY "ADC Filtering and Object-Matching," January 2001, InstantDoc ID 16139 "The Active Directory Connector Account Cleanup Wizard," November 2000, InstantDoc ID 15767 |
