One of the biggest mistakes I see in Microsoft Exchange 2000 Server deployments is a migration plan that fails to take into account Exchange's interaction with Windows 2000. The most successful implementations of both Exchange 2000 and Win2K occur when you understand and plan for the products' mutual requirements.
You probably know by now that Exchange 2000 is completely dependent on Win2K Active Directory (AD) and extends the AD schema during installation. The extent of these schema updates—and the steps you must take to implement them—depend on whether you plan to migrate to Exchange 2000 from Exchange Server 5.5, or whether you're starting your Exchange 2000 organization from scratch. However, you might not realize that the use of permissions in Exchange 2000 is different from Exchange 5.5. Also, Exchange 2000 relies on several other Win2K components, such as File Replication Service (FRS), DNS, and Microsoft IIS.
If you're gearing up for Exchange 2000, you first need to review the Win2K components that will affect (or be affected by) your Exchange deployment. The information in this two-part series will help you develop a complete and successful Exchange 2000, Exchange 2000 Service Pack 1 (SP1), or Exchange 2000 SP2 migration plan. Knowing how Win2K interacts with Exchange (and, by extension, with other Microsoft server products) can also be useful when you're planning a Win2K rollout. (For an overview of the interaction between Exchange 2000 and Win2K, see Dung Hoang Khac, "6 Steps to Prepare Win2K for Exchange 2000," http://www.exchangeadmin.com, InstantDoc ID 20018.)
Updates, Replication, and Setup
The AD schema defines the directory's structure, including classes and attributes for each type of object (e.g., a user account). The basic Win2K AD schema doesn't incorporate Exchange-specific attributes such as the name of the storage group (SG) in which a user's mailbox resides, a user's legacy Exchange 5.5 distinguished name (DN), or any attributes that Exchange needs to maintain configuration details about servers or routing and administrative topologies. These attributes must be added to the AD schema and replicated around the AD forest before you can install any Exchange 2000 servers.
AD, however, isn't the sole replication agent in a Win2K environment. Microsoft hasn't yet incorporated into AD many of the components that the OS uses (e.g., system security policies). Instead, Win2K uses FRS to replicate such objects to domain controllers (DCs) throughout a domain.
The ADC
The Active Directory Connector (ADC) synchronizes data between the Exchange 5.5 Directory Service (DS) and AD—populating AD with data about the mailboxes, accounts, and groups in the DS. Two versions of the ADC—one on the Win2K Server CD-ROM and one on the Exchange 2000 CD-ROM—are available. The Exchange 2000 version, which is the most recent, deals with Exchange 2000 and introduces required attributes such as those for server configurations and topologies.
After you install the ADC, you need to establish one or more connection agreements (CAs) to tell it where to extract information from the DS and where to put it in AD. (You must use an Exchange 5.5 SP3 or later server as the DS synchronization partner; these versions facilitate Lightweight Directory Access Protocol—LDAP—based replication.) This step can be complicated and time consuming. For example, creating a CA to take mailbox information from the default recipients container in an Exchange 5.5 site and put that information in an organizational unit (OU) in AD is fairly straightforward, but such a simple scenario exists only for small Exchange organizations. When you need to deal with multiple recipients containers, multiple sites, different types of objects (e.g., mailboxes, custom recipients, distribution lists—DLs), and the desire for more complex mapping, creating the necessary CAs becomes more challenging. (For detailed information about the ADC and related planning considerations, see Kieran McCorry, "Real-Life ADC Deployment, Part 1," May 2001, and "Real-Life ADC Deployment, Part 2," June 2001.)
To install the ADC, you must be a member of the Enterprise Admins and Schema Admins security groups. Because you don't want to give a lot of people permission to modify the schema, I suggest you limit membership in the Schema Admins group as much as possible. If you don't want your Exchange administrators to be members of Schema Admins, a schema administrator can run the ADC Setup program with the /schemaonly command-line switch to perform only the schema upgrade. After the schema changes have propagated around the forest, an Exchange administrator can rerun the ADC Setup program to complete the installation.
Using /Forestprep
You use Exchange 2000's setup /forestprep switch to create a new Exchange 2000 organization within an AD forest. This option makes necessary AD schema changes and creates the Exchange organization into which you'll install your Exchange 2000 servers. This switch also adds the Exchange container to AD's Configuration naming context (NC) and creates the Exchange Admins and All Exchange Servers universal groups, which the installation procedure subsequently uses when you install Exchange servers. The switch also permits the installer to specify the first Exchange administrator account or group to which to allocate the important Exchange Full Administrator role.
Because of the extent of the changes that /forestprep makes to AD, you must use an account that's a member of the Enterprise Admins and Schema Admins security groups. In addition, if you're going to run a mixed-mode organization, you must use an account that can connect to and read the Exchange 5.5 DS. Keep these requirements in mind during the planning process as you choose an account to run /forestprep.
Using /Domainprep
You use the setup /domainprep switch to prepare a Win2K domain before you introduce an Exchange 2000 server into that domain. To run /domainprep, you must be a member of the appropriate Domain Admins group. To let the Enterprise Exchange Servers local security group access system auditing and the Security log, /domainprep updates the security policy on the local DC that the Setup process connects to during installation. Win2K then uses FRS to replicate the change to the other DCs in the domain. (For more information about FRS replication, see the Microsoft article "FRS Replication Protocol and Topology for SYSVOL Content" at http://support.microsoft.com/support/kb/articles/q220/1/40.asp.)
In some situations, FRS fails to replicate the updated security policy to one or more DCs after you run /domainprep. If FRS fails in this way and an Exchange 2000 server selects one of those DCs as the configuration DC, the Information Store service will start correctly but Exchange 2000 won't be able to mount any databases. (To discover which DC Exchange 2000 is using as the configuration DC on Exchange 2000 and Exchange 2000 SP1 servers, you can use the Dsadiag utility. This tool is available in the Microsoft Exchange 2000 Server Resource Kit. To view these details for servers that run Exchange 2000 SP2, open the Microsoft Management Console—MMC—Exchange System Manager—ESM—console, select the server, open its Properties dialog box, and go to the Directory Access tab.) This fault is annoying and can be difficult to track down because all the obvious signs show that everything is working perfectly.
If you suspect that FRS has failed, you can review the Local Security Settings on the Exchange 2000 server that's experiencing the problem to determine whether replication occurred. To open the Local Security Settings dialog box, select Administrative Tools, Local Security Policy. In the left-hand pane, expand the Local Policies object, then expand the User Rights Assignment object. Look for the Manage auditing and security log policy in the right-hand pane. In theory, if FRS replication worked correctly, the Exchange Enterprise Servers local security group will be included in the set of accounts and groups in the Local Setting column.
In the example that Figure 1, page 61, shows, the Exchange Domain Servers global security group is listed instead—a situation that occurred after an administrator repaired FRS replication by forcing the Sysvol folder to replicate to all DCs in the domain. However, because the Exchange Enterprise Servers group includes all the Exchange Domain Servers groups from every domain in the forest, the necessary access is in place to let the policy function and to let Exchange 2000 mount the databases. Running /domainprep again won't add the Exchange Enterprise Servers group to the policy; you need to do so manually. Because the group's absence from the policy doesn't cause any problems in this situation, whether you take the time to do so is a decision that you might need to revisit as future Exchange versions and service packs appear.
Before you make policy changes on a DC, you should confirm that FRS replication has copied the necessary policy to that DC. Manually checking every DC in a large domain would be time consuming, but Microsoft provides a utility called Policytest (policytest.exe in the Exchange 2000 CD-ROM's \i386\support folder) that can do the job for you. This tool connects to every DC in the domain and verifies that the Exchange Enterprise Servers group has the privilege to manage the security and auditing log, either directly or through inheritance (as in my example). You must have Domain Admin rights to run Policytest successfully. (If you see an error that says !! LsaEnumerateAccountRights returned error 5 !!, you don't have permission to open the Local Security Authority—LSA—on the DC.) I suggest you run Policytest a day or so after you run /domainprep.
Choosing a Server
The schema master—the server that holds the Flexible Single-Master Operation (FSMO) role for the forest—must apply schema updates, then replicate the changes to DCs throughout the forest. Therefore, you should install the ADC and first Exchange 2000 server on the schema master or on a server that's in close network proximity to the schema master. You could install the ADC and Exchange 2000 on any server in the forest, but doing so slows the installation process significantly if the schema updates must take place over an extended network connection.
AD must then replicate the schema updates throughout the forest before subsequent Exchange 2000 installations can proceed. If reliable network links connect your DCs, replication will proceed rapidly and will be completed within a few hours. However, you'd be wise to anticipate some network glitches and interruptions and allow at least a day for full replication. You then can use the MMC ADSI Edit snap-in to connect to a Global Catalog (GC) server, expand the AD Configuration container, then expand the Services container and verify that the Microsoft Exchange container exists. You can also use ADSI Edit to browse the schema to verify that the Exchange attributes (e.g., ms-Exch-Facsimile-Address) are present. To ensure that synchronization is proceeding correctly, you can also use the Replmon tool (available in the Microsoft Windows 2000 Server Resource Kit) to check the update sequence numbers (USNs) that track AD replication on the DCs in the domain. (For information about Replmon, see Kieran McCorry, "20 Tips for Exchange 2000 Migration," October 2001.)
More Considerations
Any plan to install Exchange 2000 must take into consideration ADC installation, AD schema updates, and AD and FRS replication. A worthy plan also accounts for other aspects of Exchange and Win2K interaction, such as permissions, the organization of the AD forest, DNS, and IIS. I'll discuss those topics in an upcoming article.
