Lesson 4: Exchange 2000 Server in Multi-Forest Environments | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

With Windows 2000 Server, particular Exchange 2000 organization cannot span multiple Active Directory forests, and every mailbox requires a separate user account. These are the facts and essential constraints that your project team needs to keep in mind when dealing with multi-forest environments. Multi-forest environments are not desirable, but you may have to accept them if departments, divisions, or business units refuse to collaborate and opt to deploy Active Directory independently of each other, or if your company acquires another business or merges with a partner. Application Service Providers (ASPs) providing messaging services to independent customers will also have to deal with multi-forest environments. It is seldom feasible to migrate customers to the ASP’s Active Directory forest just to meet the requirements of Exchange 2000.

This lesson explains how to support Exchange 2000 Server in complex network environments with multiple forests or Windows NT domains. First, you can read about options to consolidate domain resources into one forest. You can also learn how to support users from multiple forests in one organization and how to synchronize multiple Exchange 2000 organizations to build a common global address list.

After this lesson, you will be able to

Merge domains from different Active Directory forests and Windows NT domains into a single Active Directory forest to best prepare for the deployment of Exchange 2000 Server
Support users from different Active Directory forests or Windows NT domains in a single Exchange 2000 organization
Synchronize multiple Exchange 2000 organizations with each other to build a common global address list

Estimated time to complete this lesson: 45 minutes

Consolidating Resources into One Forest

Familiarity with Windows 2000 SIDs is a necessity to understand the particulars of Windows 2000 domain upgrade and migration procedures. Recall that Windows 2000 SIDs uniquely identify every user, group, and other security principals in the Active Directory forest, and that the SIDs consist of a domain-specific part and a RID.

Upgrading Windows NT Domains

Windows NT domains do not belong to any Active Directory forest, which means that you cannot mailbox-enable a Windows NT user to let this person participate in your Exchange 2000 organization. The task is to bring the Windows NT user accounts into Active Directory (see Figure 3.27).

Figure 3.27 - Upgrading a Windows NT domain for Exchange 2000 Server

In the simplest case, you can upgrade the PDC of each Windows NT domain to Windows 2000 Server. This will convert these machines to domain controllers running Active Directory in mixed mode. The Active Directory Installation Wizard is launched automatically during the upgrade giving you the choice to create a new forest or join an existing one, which implicitly affects all security principals in the domain. For instance, if you upgrade a Windows NT domain (for example, the PDC) and join an existing forest where Exchange 2000 Server is installed, you can mailbox-enable your users right away because these are now objects in an Active Directory domain in the forest. (You only need to prepare the domain for Exchange 2000 by running the Exchange Setup program in DomainPrep mode.)

Note

To best prepare a Windows NT domain environment for Exchange 2000 Server, upgrade all PDCs to Windows 2000 Server and integrate the domains into the same Active Directory forest. All domains will run in mixed mode by default to support Windows NT backup domain controllers (BDCs). Upgrade the root domain first, then any other account domains, and then the resource domains.

Migrating Windows NT Domains or Domains from Different Forests

It is very desirable to consolidate all domain resources into one forest and fewer domains, if possible, to simplify the environment. This may require you to migrate domain objects instead of upgrading them. For instance, if your Windows NT domain environment consists of account and resource domains, and you want to consolidate all resources in a single Windows 2000 domain, you should not upgrade the PDCs directly. Upgrading multiple PDCs results in a direct upgrade of their domains, which leads to a multi-domain Active Directory forest. Instead, you need to "move" the security principals to your Windows 2000 domain, as shown in Figure 3.28.

The problem is that you cannot move user accounts (or other security principals) between domains because the original SIDs, which are domain-specific, are not valid in the target domain. You can only pretend to move the account. This process is known as cloning. Basically, you create new users and groups and give them exactly the original information (given name, surname, and so on). The accounts will look alike, but Windows NT and Windows 2000 will see separate accounts because the Object-SID attributes are different.

Note

In the context of migrating users between domains, there is no difference between Windows NT domains and Windows 2000 domains from different forests. Neither belongs to the local Active Directory forest, and they both have different SIDs.

Figure 3.28 - Consolidating Windows NT domains into one Windows 2000 domain

Imagine that you cloned your Windows NT user account. You now have the original account in the Windows NT domain plus a Windows 2000 user account. You can then mailbox-enable your Windows 2000 user object and use it to send and receive messages. However, while working with the Windows 2000 account, you cannot access your Windows NT resources (even if a two-way trust relationship exists between the domains). Because of the different SIDs, Windows NT will see that you are not the original Windows NT user. The other way around, if you work with the Windows NT account, you cannot access your mailbox because Windows 2000 will deny you access. To solve this problem, you need to use your Windows 2000 account and outwit the legacy Windows NT domain.

User objects in Active Directory own a special attribute called SID History, which can be used to store your original SIDs. When you log on to the Windows 2000 domain, Active Directory will return your current SID, the old SIDs, and the SIDs for the groups you are a member of. All of these SIDs are included in your access token. When attempting to access a resource, any one of the SIDs in your access token (including the old Windows NT SID), could allow (or deny) you access. In other words, when accessing Windows NT resources, Windows NT will grant you access as if you were working with the original account because the old SID is in your access token. You only need to ensure that the Windows NT domain trusts your Windows 2000 domain. Access control to domain resources was explained earlier in this chapter.

The challenge is to get the original SID into the SID History attribute of your cloned user account. This can be accomplished via an Active Directory Services Interface (ADSI) script or, more conveniently, via professional migration tools from Microsoft, such as the Active Directory Migration Tool (ADMT) or the Exchange 2000 Active Directory Connector (ADC). The ADMT allows you to conveniently copy user accounts from other domains and retain the existing security information (register old SIDs in the SID History). You need administrative rights and must enable auditing in all domains to perform user migration. Migrating users from Windows NT domains or between forests is known as inter-forest migration. Moving users between domains of the same forest is known as intra-forest migration. The difference is that the ADMT purges the original account in intra-forest migration to avoid duplicated accounts in the global catalog. For detailed information about domain migration strategies, consult the Microsoft Domain Migration Cookbook, which is available on the Microsoft Web site (www.microsoft.com ). Search for the phrase, "Domain Migration Cookbook."

Exchange 2000 ADC, on the other hand, gives you the ability to populate Active Directory with information from existing Exchange Directories. If the ADC cannot find a user object with the SID of a mailbox’s primary Windows NT account in Active Directory, it creates a new user object and stores the original SID in the SID History. The "cloned" Windows 2000 users will then be able to access their mailboxes on Exchange Server 5.5. You can read more about the ADC in Chapter 6, "Designing an Upgrade Plan to Microsoft Exchange 2000 Server."

Note

If you clone user accounts from Windows NT domains, do not upgrade these domains afterward and join the same Active Directory forest. Upgrading transfers the user accounts into Active Directory; thus you would end up with duplicate accounts. You can use the Active Directory Cleanup Wizard to merge duplicate accounts into one user object.

More Info: Clearing the SID History Attribute

Whenever you use ADMT to migrate an account, the old SID is added to the user’s SID history. The SID History attribute can hold up to 1023 values. This should give sufficient room to store all old SIDs, even if a user is frequently moved between domains. However, a very large SID History can adversely affect the system performance. It is advisable to clean this attribute after all resources have been migrated and the legacy domains decommissioned.

The following Microsoft Visual Basic Scripting Edition (VBScript) code clears the SID History attribute for a user object in an OU called IT-Department of the domain adventure-works.com:

 Set objUser =GetObject("LDAP://CN=UserX," _      & "OU=IT-Department,DC=Adventure-Works,DC=com") sidHistory =objUser.GetEx("sIDHistory") For each SID in sidHistory  objUser.PutEx ADS_PROPERTY_DELETE,"sIDHistory", _    Array ("sIDHistory")  objUser.SetInfo Next

Implementing a Single Exchange 2000 Organization for Multiple Forests

Cloning of user accounts is of great help when consolidating domain resources. It is not the solution, however, if you need to support users from different forests in your Exchange 2000 organization, because these users will continue to use their old accounts, in which the SID History is not available. For instance, ASPs may need to support users from different environments. The same situation may occur if the network administrators in your company refuse to collaborate in a single forest, while the messaging infrastructure is centrally managed (see Figure 3.29).

Figure 3.29 - The location of the SID History after account cloning

Associated External Contacts

Every Exchange user requires a mailbox, and mailbox information is stored in mailbox-enabled user account objects. Hence, you still need to create a mailbox-enabled user object for each user you intend to support in your Exchange 2000 organization, and you need to configure access rights for the mailboxes. Figure 3.30 illustrates this idea. Here, a separate mailbox-enabled user account was created for Lisa in Forest A. Lisa can now use this account to gain access to her mailbox. Working with two accounts, however, is more than she is willing to tolerate, and it may also represent a security issue because she is actually not a user in the forest of the Exchange 2000 server. Consequently, the administrator of Forest A disables her duplicated account. Yet, Lisa still needs access to her mailbox, but her original account is unknown in the Exchange forest. Hence, if she attempts to connect to her mailbox on the Exchange 2000 server, access will be denied.

Figure 3.30 - One Exchange 2000 organization and multiple forests

The Exchange 2000 server’s domain must trust Lisa’s domain for the purposes of authentication. Because the domains are in different forests, you need to configure the trust relationships manually. The domain in Forest A must trust the domain in Forest B for Lisa to be able to access resources in the domain of Forest A (see Figure 3.30). However, Lisa still does not have the permission to access the desired mailbox. Bear in mind that the SIDs of Lisa’s disabled account in Forest B and the account in Forest B are different, and that Lisa’s account in Forest A does not have the SID of the disabled account in its SID History.

To support Lisa, you need to grant her original account from Forest B mailbox rights for the disabled account in Forest A. Open Active Directory Users and Computers, make sure the Advanced Features are activated (from the View menu), display the properties of the desired account, and then switch to the Exchange Advanced tab. At this property page, you can click on the Mailbox Rights button, add Lisa’s user account to the list of names with Mailbox Rights, and grant her the following Permissions: Full Mailbox Access and Associated External Account. You need to be an Exchange Administrator to modify the mailbox rights. Exchange 2000 server will now recognize Lisa as an external contact and give her access to her mailbox.

Note

Per mailbox-enabled account, you can only grant the Associated External Account right to one user. The user cannot be from the same forest and cannot be granted the Associated External Account right on more than one mailbox.

Disadvantages of Multi-Forest Scenarios

Multi-forest scenarios have several disadvantages that you need to take into consideration when planning the environment. For instance, Kerberos authentication is not supported between Active Directory forests. Your clients can only use NTLM, which is slightly less secure than Kerberos. More importantly, you need to carefully review your global catalog arrangements. The correct global catalog servers are only available in the forest of the Exchange 2000 server. Therefore, you need to prevent your users’ Outlook clients from accessing any GCs in their local environments. You can accomplish this through Registry settings on the server, as discussed in Lesson 2.

Perhaps the most significant disadvantage of multi-forest scenarios is the overhead associated with user administration. You need to manually grant each foreign user account the Associated External Account right, which can be a very puzzling task if you need to support thousands of users. If possible, place all external users in separate organizational units. You may consider delegating the OU management to appropriate external administrators—if you are allowed to have administrators from foreign domains in your environment. You have to grant these administrators the role of an Exchange Administrator if you want them to manage mailbox rights.

Note

Large organizations with numerous users and many forests may find it attractive to synchronize their directories automatically using Microsoft Metadirectory Services (MMS). Yet, because of its complexity, MMS is not publicly available. You can obtain it only through Microsoft Consulting Services or an MMS-certified Microsoft partner.

Synchronizing Multiple Organizations from Multiple Forests

The single-organization/multiple-forest scenario is appropriate for complex environments with consolidated messaging resources. Basically, a separate Active Directory forest is used to contain mailbox user accounts. This is similar to the architecture used with Exchange 5.5, because a separate user namespace is maintained. Similar to previous versions, you create a mailbox object in a directory (such as a disabled, but mailbox-enabled, user object in Active Directory) and associate this object with a primary Windows NT account (such as the account from a different forest). However, this approach is not appropriate if your users are in different organizations that refuse to give up control to their messaging resources. This may apply, for instance, if you plan to collaborate with an otherwise independent business partner.

It is not possible to bring Exchange 2000 servers from different forests into the same environment, but it is possible to build a global address list and synchronize public folder contents across multiple Exchange 2000 organizations. To build a global address list, you need to create contact objects in each forest for all external users. Mail-enabled contacts are a representation for recipients that exist in other organizations. However, manually creating and synchronizing numerous mail-enabled contact objects in multiple forests represents a substantial administrative task. Active Directory utilities, such as LDIFDE.EXE and CSVDE.EXE, can help to facilitate this job. You can read more about the creation of contact objects in Active Directory in Chapter 4, "Assessing the Current Messaging Infrastructure."

Tip

Lesson 2 of Chapter 4 describes how to use Microsoft Excel to process comma-separated value (.CSV) import/export files for a directory import of numerous contact objects using CSVDE.EXE.

To provide the same set of public folders across all organizations, use the InterOrg Replication utility, which you can find on the Exchange 2000 Server CD in the \Support\Exchsync\i386 directory. This tool allows you to automatically synchronize public folders and free/busy information. Free/busy information simplifies the planning of meetings because it allows the organizer to view the availability of all attendees when creating the meeting requests. You can find more information about the InterOrg Replication utility in the Exchange 2000 Server product documentation.

Lesson Summary

A particular Exchange 2000 organization cannot span multiple Active Directory forests, yet this does not imply that this messaging platform is limited in flexibility. You can allow users from Windows NT domains or domains from different forests access to local messaging resources, and it is likewise possible to synchronize address lists and public folder resources between different Exchange 2000 organizations.

The best approach, however, is to merge all user accounts and resources into a single Active Directory forest, ideally a single Active Directory domain. This allows keeping the management overhead at a minimum. Supporting users from different environments requires the creation and management of separate mailbox-enabled user accounts in the forest of Exchange 2000 Server. Microsoft provides powerful migration tools, such as ADMT, to facilitate the creation of user clones that maintain the previous security identifiers in their SID History. Users of cloned accounts can get access to all resources in their previous environments because the old SIDs are part of their access tokens. On the other hand, if your users continue to work with their old accounts in their original environments, the SID History is not available. In this case, it will be necessary to assign the original user accounts the Associated External Account mailbox right. Exchange 2000 Server will then grant the original user accounts access to their mailboxes. The actual mailbox account is not used and can be disabled.