6 Steps to Prepare Win2K for Exchange 2000

Upfront work smooths the process

Before the release of Exchange 2000 Server, you could deploy Exchange Server on top of any Windows NT domain model in the enterprise. Exchange Server 5.x contains a Directory Service (DS) and a security subsystem and relies on the NT SAM and domain relationships to secure mailbox accounts. This model changes in Exchange 2000. Windows 2000 provides the directory services for Exchange 2000 and thus, mailbox information is no longer stored under objects unique to Exchange's DS. Instead, Exchange 2000 stores mailbox information as part of users' objects in Active Directory (AD). Exchange 2000 also stores its topology in the Configuration Naming Context, which makes it available throughout the forest. In addition, Exchange 2000 abandons the separate security subsystem and integrates with the existing security model in Win2K's AD. Administrators can therefore use the same security group model to control access to system resources and Exchange public folders.

This new model implies that you need to prepare the Win2K infrastructure to host the Exchange 2000 environment. This preliminary work will help you avoid potential problems when you install Exchange 2000 servers in an enterprise. To make your deployment easier, follow these six steps:

Let's look at each of these steps.

Step 1: Deploy Win2K
Because Exchange 2000 relies on AD for most of its operations, make sure that AD replication is functioning correctly before you install Exchange and that the systems administrators and the support group understand the replication process. At a minimum, you need the root domain of Win2K in place and the Global Catalog (GC) servers fully deployed in the same locations as the Exchange users.

To migrate NT accounts to AD, you need a detailed procedure for performing the migration and the migration tools to execute the operation. Microsoft provides some planning documents in the Microsoft Windows 2000 Server Resource Kit. Some migration tools are Aelita's Domain Migration Wizard, FastLane Technologies' DM/Manager, the Microsoft Active Directory Migration Tool (ADMT), and NetIQ's Domain Migration Administrator.

Win2K preparation for Exchange 2000 requires several schema updates and changes to the Configuration Naming Context. These naming contexts are crucial for AD operations and must be fully replicated to each domain controller (DC) inside the forest before the first deployment of Exchange 2000.

Step 2: Set Up Native-Mode Domains
Exchange Server 5.x implements its own security model and lets users control access to top public folders and to their mailboxes. Exchange Server 5.x maintains permissions granted to Exchange objects within the Exchange DS. In Exchange 2000, the AD and Win2K security subsystem replace Exchange Server 5.x's internal security model. Exchange 2000 controls public folders through the Win2K account, security groups, and the Win2K ACL instead of through mailboxes, distribution lists (DLs), and Exchange permissions. When migrating to Exchange 2000, you use the ADC to synchronize the Exchange DS with Win2K AD. This process migrates mailboxes to Win2K accounts and DLs to Universal Distribution Groups (UDGs).

This migration process works perfectly in most cases. However, when you've used DLs to set permissions on public folders in Exchange Server 5.x and you want to use the same technique in Exchange 2000, Exchange migration can affect your Win2K deployment strategy. A DL migrated to Win2K maps to a UDG. Because UDGs are essentially mail-oriented, their universal scope lets them contain any member of any domain inside the forest and lets you nest UDGs. So, although a UDG in Win2K provides the same functionality as a DL in Exchange Server 5.x, UDGs have some restrictions.

To maintain backward compatibility with Exchange Server 5.x with regard to how users use DLs to set permissions, Exchange 2000 provides an automatic process to convert a UDG to a Universal Security Group (USG) after the DL has become a UDG during the migration. The conversion occurs in the background, and only the following events trigger the conversion:

You can trace this operation by looking at the event log when the conversion process is triggered. Figure 1 shows an example of a logged event.

However, the converter doesn't promote a UDG to a USG when the domain that owns the accounts and groups is in mixed mode. As I mentioned previously, a security group can't have universal scope in mixed mode, and so the conversion can't take place. Members of these groups that had been able to access public folders in Exchange Server 5.5 will be denied access to the same documents after the migration because the system can't validate access to a UDG.

For this reason, I strongly recommend that you assess your existing messaging environment and have a clear understanding of DL use in Exchange Server 5.x. If you use many DLs to control access to public folders, plan to migrate your NT domains. When the new infrastructure has one domain and you upgrade NT in place, make sure that the Win2K domain is in native mode before you attempt to migrate DLs. In a complex environment in which you design a tree of domains, you can create a temporary child domain, switch it to native mode, and home all the migrated DLs. After you migrate the public folders and the main account domain is in native mode, you can collapse this child domain with your main account domain.

You can use the tools I mentioned earlier to move accounts and groups between Win2K domains. Having a native-mode domain to contain migrated DLs ensures that the conversion to security groups occurs properly. You can have multiple migration threads running in parallel; no dependency exists between NT and Exchange migration.

Step 3: Install the ADC
The ADC is a mechanism for synchronizing the Exchange Server 5.5 directory with AD. If you've deployed other messaging systems that don't rely on Exchange technologies, you don't need to use the ADC. Otherwise, the ADC is your best friend when migrating your Exchange Server 5.5 environment to Exchange 2000.

The ADC is an NT service that hosts connection agreements (CAs) that synchronize Exchange information with AD information. The ADC intervenes in two places during the migration from Exchange Server 5.5. First, during the Forestprep operation, the ADC brings the organization name and the site configuration of your existing Exchange environment into the Configuration Naming Context. Second, the ADC synchronizes the Exchange Directory with AD. For further details about the ADC, see "Related Articles."

Installing the ADC component requires two distinct processes. The first process is forestwide configuration, and the second is installation of the component. Each process requires specific rights.

In the first phase of ADC installation, the ADC extends the AD schema to add new classes of objects and new attributes. Then, it writes ADC information in the Configuration Naming Context to publish Exchange services, as Figure 2, page 12, shows. The account that performs both operations must be a member of the Schema Admins and Enterprise Admins groups. The Schema Admins group gives you the right to update the schema; the Enterprise Admins group gives you write access to the Configuration Naming Context. Only highly privileged administrators who are responsible for all forestwide operations usually have access to these groups. You don't want to give away these special rights to just anyone who is deploying the ADC. I strongly recommend performing this operation centrally—preferably on the DC that owns the Schema Master role—and using an administrative account that belongs only to these security groups. That way, you have full control over the execution of these operations. The ADC setup program provides the /SchemaOnly switch specifically to perform this operation.

After you install the ADC, you can force replication of the new Schema naming context throughout the forest and ensure that Win2K propagates updates to every DC or GC server in your enterprise. You can use the Replmon tool from the resource kit to trigger AD replication for the Schema and Configuration Naming Contexts. To verify that replication is complete throughout the forest, you can check for the existence of the Active Directory Connections service on each DC. Figure 2 shows the Active Directory Connections service as it appears in the ADSI Edit utility.

Next, the ADC setup installs the system files for the ADC and the Active Directory Connections service. You can install the ADC on any Win2K server in the forest. A good candidate is a member server deployed in the same physical location as the Exchange Server 5.5 server and the Win2K DC that will own the users' accounts. As I explain in the next section, the installation process still requires a service account to run the ADC. It also creates a global security group in AD to contain these service accounts. In terms of user rights, the logged account must be a member of the Administrator group to create an NT service and a security group.

Step 4: Use the Exchange Server 5.5 Service Account
Exchange Server 5.5 uses the site service account to run the NT services required for Exchange operations. Usually, the accounts hold Exchange service account permission in the Exchange sites. However, Win2K uses the LocalSystem account instead of the service account to run NT services. (Tony Redmond, "Running Exchange Services from LocalSystem," February 2001, explains this change.) Therefore, when deploying Exchange 2000, you don't need to create a specific service account for Exchange. This change greatly reduces the burden of managing service accounts, especially for managing password changes. However, during the migration process, you still must define and use the service account to access the Exchange Server 5.5 environment. Defining the service account in AD greatly depends on your Win2K migration strategy for the NT domains.

Why do you need the Exchange service account during the Exchange installation? If you migrate from Exchange Server 5.5, you need to use the Forestprep operation to inform Exchange 2000 about the existing messaging environment. The Forestprep process requires a binding to an Exchange Server 5.5 server so that the process can read the organization name and the site configurations. The Exchange Server 5.5 account that runs the operation must have full administrative rights to the Exchange site that you're joining. This account must also be a member of the Schema Admins group and the Enterprise Admins group for the reasons I described in Step 3.

Therefore, if you perform an in-place upgrade of the NT account domains that own the Exchange Server 5.5 service account, you simply need to add these accounts as members of the two new security groups in Win2K. Because the upgrade preserves the SID, the migrated Exchange service account still provides full administrative rights to Exchange Server 5.5.

The situation is more complex if you're restructuring. In this case, you build a new pristine forest and Win2K domains in parallel with the existing domains and gradually migrate NT 4.0 accounts to AD. Restructuring implies the creation of new objects in the destination domain and therefore a new SID for these objects. To preserve the SID from the NT 4.0 domains, you need to use the cloning technique, which preserves the SID from the source domain and stores it in a new User object attribute called SIDHistory. When the account needs to access resources in the NT environment, it uses the old SID stored in this attribute for access validation. The Web-exclusive sidebar "Alternatives to Cloning Accounts," http://www.exchangeadmin.com, InstantDoc ID 20022, explains two popular workarounds that don't work for the Forestprep operation.

By cloning the service account, you create a new object in AD and carry over the SID of the old account, storing it in the SIDHistory attribute of the new object. Adding this object to the two security groups under Win2K will then give sufficient rights to execute the Forestprep operation. And thanks to the SIDHistory, the cloned account still has full administrative rights to access the Exchange Server 5.5 DS.

Step 5: Run the Forestprep Utility
The Exchange setup program provides the /forestprep switch to perform several tasks to prepare the Win2K AD to host the new Exchange 2000 organization. Forestprep doesn't install any Exchange components but it

Because Forestprep extends the AD schema, I strongly recommend that you follow the guidelines I described in Step 2 to prepare for the schema-extension operation.

Now, let's look at the user rights required to run Forestprep. If your plan is to create a new Exchange 2000 organization, you can use an account that has rights to modify the schema and to write information to the Configuration Naming Context. A member of the Schema Admins and Enterprise Admins security groups has these rights.

However, if you choose the migration approach, you need to go through the previous step by cloning the service account from NT to Win2K and making this cloned account a member of the same two security groups. Then, you must use this service account to log on to run Forestprep to get sufficient rights to execute the operation. When you're joining the Exchange Server 5.5 organization, you provide the name of an Exchange Server 5.5 server to let the setup program bind to it. The Exchange setup program then reads its configuration data (i.e., Organization and Site names) and copies this information to AD's Configuration Naming Context. The name of the Exchange site you're joining becomes the first administrative group in Exchange 2000.

Figure 3 shows the information stored in AD after the Forestprep operation. The figure shows the Exchange Server 5.5 organization Starcor, which the Forestprep operation fetched from the Exchange Server 5.5 server.

Although Exchange 2000 services use the LocalSystem account to start up, Forestprep still prompts you for a service account name and password. Site Replication Services (SRS) uses these credentials when it accesses the Exchange Server 5.5 environment. The setup utility uses the service account that already exists in Exchange Server 5.5; you just need to provide a password for the account. Also, you must establish a trust relationship between the Win2K domain and the NT account domain that homes the service account for the setup program to validate the account. For more information about SRS, see Kieran McCorry, "The Site Replication Service," October 2000.

The next stage of Forestprep asks you to nominate the first Exchange administrator account. The object you specify here receives full organizationwide permissions to Exchange. This account serves two purposes:

Step 6: Run the Domainprep Utility
The Domainprep utility performs the Exchange setup tasks that require only Domain Admins rights. You need to run Domainprep once in each domain that homes users' mailboxes or that contains mailbox-enabled accounts. Although the operation runs quickly, Domainprep performs some crucial tasks. Domainprep

The global and local security groups provide the basis for permissions in Exchange 2000. When you're installing Exchange 2000 servers, the Exchange setup program adds the computer account into the Exchange Domain Servers group, which in turn is a member of the Exchange Enterprise Servers group. Because the Exchange Enterprise Servers group has administrative rights on the domain objects, the computer account inherits the same rights.

Now, when an administrator creates a mailbox-enabled user, the Recipient Update Service (RUS) needs to update attributes on the account. Because the RUS runs in the context of the LocalSystem account, which is the computer account, the RUS has administrative rights to perform the operation.

After the operation is complete, allow time for domain changes to replicate to all DCs. You can use the Replmon tool to trigger domain replication. To apply the Security policy on the servers, run the command

secedit /refreshpolicy machine_policy

on each DC.

Ready, Set, Go
Now, you're ready to deploy Exchange 2000 in your enterprise and start the migration of user mailboxes to the new environment. The installation of Exchange components requires fewer privileges; you don't need to have full administrative rights to perform this operation. You can delegate the task to remote administrators or operators without running the risk of corrupting your AD.