Exchange 2000 in Six Steps

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : August 4, 2001

Upgrading from Microsoft Exchange Server 5.5 to Microsoft Exchange 2000 Server: A Six-Step Case Scenario

For the latest information, please see https://www.microsoft.com/exchange/

On This Page

Introduction
Step 1: Create a Detailed Deployment Plan
Step 2: Begin Successful Deployment of Windows 2000
Step 3: Prepare the Directories
Step 4: Install Your first Exchange 2000 Server
Step 5: Upgrade the Information Stores and Other Exchange Components
Step 6: Switch to Native Mode
Appendix: Exchange 2000 Upgrade Checklist

Introduction

This article provides a tour of the Microsoft® Exchange 2000 deployment of an imaginary company called The Milk Company. You'll be guided through the following six core steps in an Exchange deployment:

  1. Create a detailed deployment plan.

  2. Begin a successful deployment of Windows 2000.

  3. Prepare Microsoft Windows® 2000 Active Directory™ and Exchange directories.

  4. Install your first Exchange 2000 server.

  5. Upgrade the information stores and other Exchange components.

  6. Switch to native mode.

The purpose of this article is to provide you with a clear picture of the deployment process, which you can use as a basis for your own deployment.

The discussion in this article provides a broad overview of the process for upgrading a Windows NT 4.0 and Exchange 5.5 environment to a Windows 2000 and Exchange 2000 environment. This article is intended to help managers and the IT deployment teams understand the workload and other key factors involved in the upgrade before the deployment process begins. This discussion focuses on the procedural order in which to carry out your deployment—what to do when and why. It provides useful tips gleaned from the Microsoft Early Adopter beta-testing program.

For more detailed information on each step of the process, see the Guide to Upgrading from Exchange 5.5 to Exchange 2000 Server at https://www.microsoft.com/exchange/productinfo/E2Kguide.htm. This white paper walks you through the entire upgrade process, focusing on implementation details for each step. You can also read about other deployment scenarios in Microsoft Exchange 2000 Server Resource Kit.

Questions and Answers

This document answers some of the following questions:

  • How can I prepare my Windows 2000 organization for the installation of my first Exchange 2000 server?

  • How do Windows and Exchange interoperate?

  • How do I upgrade an Exchange 5.5 organization to an Exchange 2000 organization?

  • What exactly is the relationship between Windows 2000 user accounts and Exchange mailboxes?

  • What are the security settings needed to deploy and administrate Exchange 2000 Server?

  • How can I migrate my Exchange 5.5 directory information to Windows 2000?

  • What are the roles of Windows 2000 domain controllers and global catalog servers in an Exchange 2000 organization?

  • What type of Windows 2000 groups should I use?

  • How do I upgrade my public folder hierarchy and my connectors?

What Active Directory Means to Exchange

Perhaps the key difference between Exchange 5.5 and Exchange 2000 is that Exchange 2000 relies entirely on Windows 2000 Active Directory for all directory and security information. There is no separate Exchange directory, and this integration between Exchange and Windows creates the following far-reaching effects:

  • It allows for dramatic improvements in flexible administration brought about when network security and messaging share the same directory.

  • It creates a stronger link, and dependence, between Exchange and Windows administrators, who now have to work together more than ever before.

  • It provides a new user model, which has expanded to include attributes for mail delivery and storage, as well as a new Windows 2000 group model—which supports the functionality of both Exchange 5.5 distribution lists and Microsoft Windows NT® 4.0 groups.

  • Because Exchange 2000 uses Active Directory as its only directory, several new components exist, such as the Active Directory Connector (ADC), Site Replication Service (SRS), and Recipient Update Service, all of which are discussed later in this article.

If you can develop a clear and deep understanding of Active Directory, you will understand most of the differences between Exchange 5.5 and Exchange 2000, and will have a foundation for understanding how Exchange 2000 works.

From Mailboxes to Accounts

One major difference between Exchange 5.5 and Exchange 2000 is the relationship between user mailboxes and Windows accounts, as shown in Figure 1. In the Exchange 5.5 directory, a mailbox is an object. One of the attributes of the mailbox object is a reference to a primary Windows NT account, an object in the Windows NT directory. This Windows NT account owns the mailbox. However, Windows NT accounts have no mailbox-related attributes.

With Exchange 2000, the Exchange directory has been integrated into Windows 2000 Active Directory. To an Exchange administrator accustomed to mailbox objects, the relationship between mailboxes and security accounts seems reversed; a mailbox has become an attribute of a Windows account object. A more accurate understanding of this is that the two objects have merged. Instead of having two objects from separate directories linked together, one object in Active Directory contains both security and mailbox attributes.

Figure 1: The Relationship Between Exchange Information and Windows Account Information

Figure 1: The Relationship Between Exchange Information and Windows Account Information

In Exchange 5.5, the same Windows account could "own" several mailboxes without creating a conflict for the directory. The mailbox was unique in the Exchange directory namespace, and the Windows account was unique in the Windows NT security namespace. So, although the relationship between the two was flexible, the dual directory system duplicated administrative requirements and increased replication overhead. Now, however, the Exchange mailbox and Windows account have merged into essentially the same object: a Windows 2000 account that can have only one mailbox attribute (it can only own one Exchange mailbox). Now both account and mailbox are managed together.

Active Directory from an Exchange Perspective

From the perspective of Exchange 2000, Active Directory provides both network security services and all the services provided by a messaging directory—for example, routing, address lookup, and the maintenance and replication of all Exchange attributes.

From a client's perspective, Active Directory provides the following:

  • Global address list

  • Address book views

  • Offline address books

These three Active Directory features are discussed in more detail in Step 2 of this article (see the "Changes in Client Access: Address Book Lookups" section in Step 2).

The Case Scenario

Now that you have a little background on Windows 2000 Active Directory and the essential differences between Exchange 5.5 and Exchange 2000, let's consider a fictitious Exchange 5.5 organization called The Milk Company.

The Milk Company is a multi-domain organization that is currently running Exchange 5.5 on Windows NT 4.0. The rest of this article describes the six steps The Milk Company takes to ultimately upgrade to Windows 2000 and Exchange 2000 Server.

Step 1: Create a Detailed Deployment Plan

Your Exchange 2000 deployment plan should reflect your understanding of how Exchange and Windows interoperate and should encompass the relationships between Windows 2000 sites and domains, domain controllers, global catalog servers, and Exchange 2000 administrative and routing groups. Your plan also should include the new components that directly connect Exchange 5.5 to Windows 2000—Active Directory Connector, Site Replication Service, and Recipient Update Service. The Step 1 section provides a basic outline of the Windows 2000 and Exchange 2000 deployment goals for an imaginary company called The Milk Company; the Step 2 section that follows explores the issues that you must understand to realize your deployment goals.

Deployment Scenarios

You can use many methods to deploy Exchange 2000, but each method requires a single Active Directory user account for each mailbox, with all the correct Exchange attributes populated. For example, using one method, you upgrade to Windows 2000 completely before you begin installing Exchange 2000. In this scenario, every domain that contains accounts used to access Exchange mailboxes is upgraded to Windows 2000 first. Then you use Active Directory Connector (ADC) to match the Exchange 5.5 mailbox's primary Windows NT 4.0 account with the new Windows 2000 account, merging accounts as you proceed.

However, upgrading completely to Windows 2000 before Exchange deployment is unrealistic for many companies—as it is for The Milk Company—and it is not necessary. Microsoft supports coexistence between Windows NT 4.0 and Windows 2000, and between Exchange 5.5 and Exchange 2000, so you can gradually upgrade both to Windows 2000 and to Exchange 2000.

Note: For a broad discussion of a variety of deployment scenarios, see Microsoft Exchange 2000 Server Resource Kit.

Where Are You Now? A First Glance at The Milk Company

The Milk Company is a purveyor of fine milk products over the Internet, with more than 6,500 employees who together fill the following functions: management, development, marketing, administration, sales, production, and distribution. The Milk Company is an Exchange 5.5 organization with the following four sites:

  • New York City—Headquarters: management, development, marketing, administration, and distribution—2,000 employees

  • Los Angeles—North American management, administration, sales, production, and distribution—2,000 employees

  • London—European management, administration, sales, production, and distribution—2,000 employees

  • Paris—Development (just acquired and currently running Lotus Notes)—500 employees

Cc723569.sixstp01(en-us,TechNet.10).gif

Figure 2: The Milk Company Exchange 5.5 Organization

Although the New York and Los Angeles sites are both part of The Milk Company, they operate almost as separate companies as far as security and messaging are concerned, with different administrative teams. Part of the mandate for the upgrade to Windows 2000 and Exchange 2000 is to centralize administration in New York.

A Paris firm, currently running Lotus Notes on a Windows NT 4.0 domain, has recently been acquired. For the time being, an Exchange 5.5 Lotus Notes connector is used to connect Paris to London. The mandate is to join Paris to the Exchange organization as quickly as possible, but not before establishing the best way to integrate it into the new topology. Thorough planning for Windows 2000 has already taken place; so Paris will be added after Windows 2000 deployment has begun for the other domains.

Cc723569.sixstp02(en-us,TechNet.10).gif

Figure 3: The Milk Company Windows NT 4.0 Deployment

In The Milk Company Windows 4.0 deployment, trusts are established between existing domains. Because Paris has just joined the organization, a trust will soon be established with London, which will link it to the rest of The Milk Company.

Where Do You Want to Be?

Although The Milk Company begins deploying Windows 2000 first, they must keep their anticipated Exchange 2000 deployment in mind, because the two systems are so closely integrated. The Milk Company's deployment plan needs to reflect requirements for both account security and mail system efficiency.

Windows 2000 Deployment

For The Milk Company, Windows 2000 deployment is occurring in two major cycles. The first cycle, completed before Exchange 2000 deployment begins, is to create a mixed-mode Windows 2000 forest. A trust is established with the London domain. Because of a production strike in London, administrators decide to delay upgrading that site for the time being. The basic steps of this first cycle are as follows:

  1. Create a new root Windows 2000 domain with recently purchased hardware. The first domain is created as a placeholder for the rest of the forest; this domain will contain only domain controller computer accounts.

  2. Upgrade a Primary Domain Controller (PDC) and Backup Domain Controller (BDC) Windows NT 4.0 server in the New York City site/domain to create a mixed-mode Windows 2000 child domain called NA.TheMilkCompany—The North American (NA) Milk Company domain. All North American users will be hosted in this domain.

  3. Upgrade all Windows NT 4.0 servers in New York and switch NA.TheMilkCompany to native-mode so that it can be used for group management (more on this topic later).

  4. Use Active Directory Migration Tool to migrate users on the Los Angeles Windows NT 4.0 domain to NA.TheMilkCompany. (For more information on this tool, see your Windows 2000 documentation.)

  5. Create a trust between the London domain and the new Windows 2000 forest.

Eventually, during the Exchange 2000 deployment (and in preparation for converting to native mode), the London Windows NT 4.0 domain will upgrade to a Windows 2000 domain called EUR.TheMilkCompany. The end result is the following Windows 2000 forest.

Cc723569.sixstp03(en-us,TechNet.10).gif

Figure 4: The Milk Company Windows 2000 Forest: Root, North American (NA), and European (EUR) Domains

For more information about upgrading Windows 2000, see your Windows 2000 documentation.

Exchange 2000 Deployment

The company's goals include the following:

  • Consolidate New York City development and Los Angeles sales into one administration and routing group. Because a high-bandwidth connection now exists between the two geographic sites, and for purposes of mail and account administration the two groups are very similar, it doesn't make sense for The Milk Company to maintain a the groups separately. Yet, on an Exchange 5.5 organization, users could not move between existing sites.

  • Consolidate Paris and London into one routing group (the two cities have a high-bandwidth connection), but keep them in separate administrative groups, to allow for separate administrative teams. It's worth noting that this option was not available with Exchange 5.5. Because routing groups were, by design, administrative groups as well, the two could not be separated.

The resulting topology when these goals are achieved is shown in Figure 5. The Milk Company wants both of its North American Exchange 5.5 sites to be combined into one Exchange 2000 routing group (for messaging purposes) and one Exchange 2000 administrative group (for account management purposes). The Milk Company's European offices will also become one routing group, but within the European routing group there will be two administrative groups. This means that message flow between London and Paris will behave the same as it does between New York and Los Angeles. However, London and Paris Exchange 2000 servers will be managed separately.

Cc723569.sixstp04(en-us,TechNet.10).gif

Figure 5: The Milk Company's Planned Exchange 2000 Deployment

Before Moving On

The significance of carefully planning your upgrade cannot be understated. It's extremely important to know what your upgrade goals are before you begin. Exchange 2000 Server is an enterprise-wide application and introducing it to your organization is a serious undertaking.

The following items are required before moving on to Step 2:

  • Understand your existing organization and where data is located.

  • Map out the existing network infrastructure.

  • Identify the existing messaging and directory structures.

  • Determine the functional requirements to be met after the upgrade.

  • Determine the order in which domains and servers will be upgraded.

  • Identify resources and obtain any necessary new hardware.

Step 2: Begin Successful Deployment of Windows 2000

The key to a successful deployment of Exchange 2000 is a successful deployment of Windows 2000. Your Windows 2000 installation, whether in mixed or native mode, should be stable and working as expected before you begin to deploy Exchange 2000.

Note: In a Windows 2000 deployment, a native-mode domain is one in which all servers are Windows 2000 servers. Additionally, an administrator must manually switch the domain mode to native through Windows 2000 Domains and Trusts. A mixed-mode domain can contain both computers running Windows 2000 and computers running Windows NT 4.0.

Windows 2000 deployment and Exchange 2000 deployment carry separate challenges. The person who designed your Windows 2000 deployment may be far less familiar with Exchange 2000. You will need to fine-tune Windows 2000 for the new messaging system.

Note: Deployment planning is covered more fully in Microsoft Exchange 2000 Server Resource Kit.

Forest Design

A Windows 2000 forest cannot support more than one Exchange organization. That is, you cannot have two Exchange organizations in the same forest. The opposite is also true: An Exchange 2000 organization cannot span more than one Windows 2000 forest. You cannot have some Exchange servers in one forest, and some in another. All mailboxes, servers, public folders, and so forth—all Exchange resources—must be in the same forest.

Although one can design a topology that creates mailboxes in one forest and Windows 2000 user accounts in another, for most enterprises, Exchange mailboxes and user accounts are in the same forest. This means that these two related but separate information systems must be considered equally: How can the structure of the forest optimize both security and messaging—both administration of user accounts, and also message routing and directory replication?

Domain Design for The Milk Company

The Milk Company has three separate Windows NT 4.0 domains (four, with the addition of Paris), and it is moving to a forest with three domains. The company could have achieved similar results by using a single domain model with offices organized by organizational unit. However, from the perspective of a Windows 2000 administrator, the decision to create separate domains makes sense because of language and geographical considerations. In addition, familiarity with the existing domain structure makes the upgrade path fairly straightforward.

From the perspective of an Exchange administrator, the multiple-domain design makes sense because there must be a coexistence period while the entire company migrates to both Windows 2000 and Exchange 2000. This period will require at least one Windows 2000 domain in native mode to support universal security groups (more on this later).

Extending the Schema

The Windows 2000 Active Directory schema must be extended to support the diverse attributes in a messaging application directory. Exchange 2000 extends Active Directory with new Exchange classes and attributes. Existing Active Directory attributes are also modified, and some of these modifications affect what Microsoft Outlook® users see in the global address list.

The schema is extended when the following occurs:

  • You install the Exchange version of Active Directory Connector.

  • You first run the ForestPrep mode of setup.

    Note: ForestPrep is a setup mode that is designed to be run by a high-level network administrator in your organization. It prepares your organization for Exchange 2000 installation by extending your Active Directory schema to accommodate Exchange-specific information. ForestPrep is discussed in full in the article "ForestPrep and DomainPrep," available elsewhere on this Web site.

ForestPrep provides full schema extensions, meaning that all Exchange-specific information that Active Directory needs to accommodate Exchange 2000 will be added when you run it. Active Directory Connector, on the other hand, provides some, but not all, of these schema extensions. Therefore, if you install ADC first and ForestPrep second, ADC partially extends your schema and ForestPrep then provides the remaining schema extensions. In reverse order, however, ForestPrep fully extends your schema and ADC does not extend your schema at all.

Important: In order to have coexistence with Exchange 5.5 in your organization, you must install ADC before running ForestPrep.

It is also important to note that each time your schema is extended, your global catalog is rebuilt. In rebuilding, the global catalog rewrites its entire database to assimilate the new attributes that the extensions have added. In a large organization with many global catalog servers, this is a very expensive and time-consuming process.

Note: The schema is partially extended with Exchange attributes if you install the Windows 2000 version of Active Directory Connector; you must install the Exchange version of Active Directory Connector to obtain all required Exchange attributes. If you have already installed the Windows 2000 version of ADC, you must still install the Exchange ADC in order to appropriately extend your schema.

The Exchange 2000 extensions are represented in Figure 6. An organizational unit is an Active Directory container object used within domains.

Cc723569.sxstep02(en-us,TechNet.10).gif

Figure 6: Mail-related Schema Extensions Added to Active Directory

New Attributes

Exchange adds a variety of messaging-related attributes to the user, group, and contact objects in Active Directory—which causes these security accounts to become mail-enabled. In addition, the user object can "own" a mailbox and so receives mailbox-related attributes.

Domain Controllers and Global Catalog Servers

The Windows 2000 domain and site structure has a greater impact on your Exchange 2000 deployment than Windows NT 4.0 had on Exchange 5.5. The flexible relationship between Windows 2000 domains and Windows 2000 sites calls for very careful planning, especially around the area of global catalog servers.

A Windows 2000 domain controller holds user-authentication data related to its domain. A global catalog server is a domain controller, but it also holds a replica of selected attributes from all objects from the entire forest. Exchange uses both domain controllers and global catalogs in its normal operation.

Important: As a general rule, at least one global catalog server should exist per Windows 2000 site (in which Exchange 2000 users reside). Additional global catalogs may be required for added redundancy or if you are load balancing.

Domain vs. Site Design

A Windows 2000 site may span multiple domains, and a domain may contain multiple sites. This gives you the means to design a topology that most efficiently routes directory and security information throughout your system. A clear understanding of the Windows 2000 site and domain topology, along with the domain controller and global catalog server placement, will help you construct a successful Exchange 2000 deployment plan.

Active Directory uses site design to determine how best to use available network resources. This makes the following types of operations more efficient:

  • Service requests When a client requests a directory service from a global catalog server, the client is directed to a global catalog in the same domain and site as the Exchange server to which the client is connecting, if such a global catalog is available.

  • Replication Sites streamline replication of directory information. Directory schema and configuration information is distributed throughout the forest, and domain data is distributed among all domain controllers in the domain. By strategically reducing replication, the strain on your network is similarly reduced. Active Directory replicates directory information within a site more frequently than between sites. In this way, the best connected domain controllers, those most likely to need particular directory information, receive replications first. The domain controllers in other sites receive all changes to the directory, but less frequently, reducing network bandwidth consumption.

User Management and Resource Domains

To support management of groups (distribution lists) by users, the Exchange server should be installed in the same domain as the group, because of the particular relationship between mail clients, Exchange servers, and global catalog servers.

Mail clients (Outlook and other MAPI-based clients) modify Active Directory by accessing a global catalog server through their Exchange server: Exchange either refers the client to a global catalog server or relays the request. In either case, an Exchange server typically refers or connects to a global catalog server in the same domain as the Exchange server.

To modify Active Directory objects such as groups, users must access a global catalog in the domain containing the group. This means that to allow users to modify groups in Active Directory, the group must exist in the same domain as the Exchange server that the users connect to. All other mail functionality is unaffected by server placement; if management of groups by users is unimportant, it does not matter in which domain Exchange servers are located.

Changes in Client Access: Address Book Lookups

The services provided by the Exchange 5.5 directory—global address list (GAL), address book views, and offline address books—are provided in a different way by Active Directory.

It is important to keep in mind that, although your servers will be upgraded from Exchange 5.5 to Exchange 2000, your clients will remain the same. Previously, clients have queried the Exchange 5.5 directory, which is nonexistent in Exchange 2000. Instead, a service called DSProxy provides referrals to global catalog servers, so that all clients can access Active Directory.

More recent clients can access Active Directory directly. Earlier clients query Exchange when they need directory information.

Global Address List

When Outlook users want to find a person within the organization, they generally search the global address list (GAL). Because Exchange 2000 servers no longer host their own directory services, all data is retrieved from Active Directory through global catalog servers. Because a global catalog server can support the MAPI protocol as well as Lightweight Directory Access Protocol (LDAP), Outlook clients can communicate with Active Directory by using the same protocol employed by Exchange Server 5.5 Directory Service.

Users running Outlook 98 SR2 and later begin a session by requesting an available global catalog server from their Exchange 2000 server (represented by line 1 in Figure 7). The Exchange server has a list of global catalogs and tells the client which one to connect to.

Note: By default, the Exchange server first looks for global catalog servers in its own Windows 2000 site. The Exchange server then filters those global catalogs by domain on the site.

The client then talks to that global catalog directly for the remainder of the session (represented by line 2 in Figure 7). If the connection to the global catalog is lost during the session, the user must exit and restart the client.

Users running Outlook 98 SR1 and earlier relay all requests to a global catalog through their Exchange 2000 server. Older clients speak directly only to the Exchange 2000 server, which relays all information between the global catalog and the client.

Cc723569.sxstep03(en-us,TechNet.10).gif

Figure 7: Two Methods for Exchange 2000 Clients to Access a Global Catalog Server

Address Book Views vs. Address Lists

A key administrative difference between Exchange 5.5 and Exchange 2000 is the method of grouping users in the directory for searches and other purposes. The Exchange 5.5 concept of address book views enables the administrator to provide views to Outlook users based on field groupings. Outlook users can see each site, its containers, and the aggregated global address list when they look in the server-based address lists. For example, to create a virtual container of all employees in a worldwide company, an administrator can set up a view grouped by country/region. This creates a virtual container for every entry found in the Exchange 5.5 address book's country field. All salespeople in the United States are included in a virtual container called "USA."

Containers may also be created for "U.S." or "United States," however, if even one user has such an errant entry in their country field. In other words, for every unique instance of data, a container is created. In this example, there could be hundreds of employees in the USA container and only one person in the U.S. container. Similarly, you could have containers for both "UK" and "United Kingdom," depending on how the data was entered by the administrator.

In Exchange 2000 however, address book views have been replaced with address lists, which act as filters. This means that the same administrator can now use Exchange System Manager to display all salespeople whose country equals "USA," or "U.S.," or "U.S.A.," within the same search filter. A filter-based approach allows for more complex searches.

Offline Address Lists

To support mobile users, the offline address list allows users to copy the contents of a server-based address book into a set of offline address book files (files with an .oab extension) on the local client's hard disk. The global address list is usually selected as the source for offline address list generation.

The first Exchange 2000 server that you install calculates the offline address book.

Changes in Group Design

In Exchange 2000 deployment, Windows 2000 groups reflect the particular requirements of your Exchange organization. In Windows 2000, domain local and domain global groups have the same scope as their Windows NT 4.0 counterparts, and when implemented as security groups, they can be used in access control lists (ACLs) on network resources—just as they were in Windows NT 4.0.

Note: For more information about using groups in Exchange 2000, see the article "The Role of Groups and ACLs in Exchange 2000 Deployment," available elsewhere on this Web site.

A new group scope, universal, is similar in scope to the Exchange 5.5 distribution list (universal groups can have members from any domain). Because Windows 2000 groups can be mail-enabled, a universal mail-enabled or "distribution" group can be used just like an Exchange 5.5 distribution list . The ADC by default converts Exchange 5.5 distribution lists into universal distribution groups (UDGs).

Universal security groups (USGs) can be granted permissions on any domain in the forest. These groups, like UDGs, are particularly useful for Exchange, because they can contain members from any domain. To set permissions on public folders in Exchange, you must use a group type that allows you to view and modify group membership on local or global domains. For this purpose, Exchange 2000 Web Storage System automatically converts UDGs into USGs as needed. Note that if all your Exchange 2000 servers are going to be on one domain, USGs are not necessary. You can still use domain global and domain local group for distribution lists; however, domain local groups cannot be nested.

The following table compares the groups used in Exchange 5.5 and Windows NT 4.0 with groups used in Exchange 2000 and Windows 2000.

Table 1 Old vs. New Group Model

Exchange 5.5 or Windows NT 4.0 Group Type

Function in Exchange 5.5 or Windows NT 4.0

Membership

Windows 2000 Analog

Exchange 5.5 distribution list

(1) E-mail distribution lists
(2) Used in ACLs on public folders

A distribution list can have any site in the organization and/or another distribution list as a member. Nesting of distribution lists is not limited.

(1) Universal distribution group (for distribution lists)
(2) Universal security group (used in ACLs on public folders)

Domain local

Used in ACLs for resources that exist in the same domain as the group itself

Membership from any trusted domain. The scope of the group is restricted to only the local domain. Domain local groups cannot be nested.

Domain local security group

Domain global

Used in ACLs for resources in any domain

Membership from only the local domain, but it has a global scope. Global groups can have one level of nesting.

Global security group

Before Moving On

When you have a clear understanding of how Windows 2000 and Exchange 2000 interoperate and you have planned accordingly, you are ready to begin the migration to Exchange 2000. This process officially begins when you run Active Directory Connector (ADC). After you begin, you can operate in a mixed-mode Exchange and mixed-mode Windows environment indefinitely; but you won't gain the full administrative benefits of Exchange 2000 until you switch to a native Exchange 2000 environment.

By the conclusion of Step 2, The Milk Company has created a root Windows 2000 domain and upgraded their New York Windows NT 4.0 domain controllers to Windows 2000, thus creating a mixed-mode Windows 2000 child domain (named NA.TheMilkCompany). They then upgraded the rest of their New York Windows NT 4.0 servers, making NA.TheMilkCompany a native-mode Windows 2000 domain. Next, with the Active Directory Migration Tool, they brought users on the Los Angeles Windows NT 4.0 domain to NA.TheMilkCompany. All North American accounts are now hosted in the same native-mode domain. A trust has also been created between this new Windows 2000 forest and the London Windows NT 4.0 domain.

The following items are required before moving on to Step 3:

  1. Set up a Windows 2000 forest for Exchange 2000 to use.

    • Determine if an existing Windows 2000 forest can be used.

    • If an existing Windows 2000 forest does not exist, install a new forest root.

  2. Ensure that one domain in the forest is a Windows 2000 native-mode domain. This domain will support universal groups.

  3. Set up appropriate trusts between forests and external domains.

    Install the domain controllers and global catalog servers that will be initially used by Exchange. You can add more as Exchange 2000 is deployed.

    • If users will manage distribution lists in Outlook, you must ensure that the domain controllers and global catalogs to be used by Exchange 2000 are in the same domain on which universal groups are managed.

    • If you will use Exchange Key Management Service (KMS), ensure that the domain controllers and global catalogs to be used by Exchange 2000 are in the same domain as users who will update keys on the domain controllers and global catalogs.

  4. Install Windows 2000 Service Pack 1 (SP1) on all domain controllers and global catalogs to be used by Exchange 2000.

Validate your configuration by creating a test account. Log on to the forest, check replication on the server, and check Windows 2000 version numbers on the domain controllers and global catalogs.

Step 3: Prepare the Directories

Before you install your first Exchange 2000 server, you have to prepare both the Exchange 5.5 directory and Active Directory.

Prepare the Exchange 5.5 Directory

In Exchange 5.5, a Windows NT 4.0 user can have permissions on multiple mailboxes. For example, John Q, who works for The Milk Company, has his own mailbox but also uses his Windows NT 4.0 user account credentials to access the Sales mailbox, to which distribution personnel write for sales support.

In Active Directory, however, a user object can have only a single mailbox attribute.

When you prepare the Exchange 5.5 directory, you must ensure a one-to-one relationship between mailboxes and Windows NT accounts. When two mailboxes are associated with the same Windows account, usually one of them is a "resource mailbox," a mailbox for a resource such as a conference room. It may also represent a mailbox with revolving ownership.

You should mark resource mailboxes in your Exchange 5.5 directory, using a method described later in Step 3 (see "Mark the Resource Mailboxes in the Exchange 5.5 Directory"). When resource mailboxes are manually marked with a certain attribute, new accounts will be created for them in Active Directory, after the Active Directory Connector (ADC) replicates the information. The ADC is discussed later in Step 3.

If you populate Active Directory with a user account that has permissions on two different Exchange 5.5 mailboxes, Active Directory Connector (ADC) can associate the account with only one of the mailboxes. (This happens only if you haven't cleaned up your Exchange 5.5 directory.) Thus, during replication, the logon ID JohnQ may be associated with the Sales mailbox. Then, when ADC attempts to find an owner for John Q's personal mailbox, it finds that John Q already has a mailbox, Sales. The link between John Q and his personal mailbox is broken, and he isn't able to access his mail after he has moved to Exchange 2000.

Cc723569.sixstp06(en-us,TechNet.10).gif

Figure 8: The Exchange 5.5 Store, Windows NT 4.0 Directory, and Exchange 5.5 Directory Service Compared to the Exchange 2000 Store and Active Directory

Cleaning Up the Directory

When you run Active Directory Connector, a one-to-one relationship must exist between Windows NT 4.0 user accounts and Exchange 5.5 mailboxes. There are several methods you can use to accomplish this, including using the ADC.

Mark the Resource Mailboxes in the Exchange 5.5 Directory

In this manual method, you specify which mailbox should be linked to the Windows account, and then populate the Custom Attribute 10 attribute (through an LDAP query, this is the Extension-Attribute-10 attribute) of the other mailboxes with the value "NTDSNoMatch." In other words, for any mailbox that is not the account's primary mailbox, you populate the Extension-attribute-10 attribute with NTDSNoMatch. For example, the Sales mailbox in the previous example would be populated with this value. To accomplish this, run the MultiMb tool, which lists all mailboxes that are linked to the same Windows NT account.

When the Sales mailbox is imported into Active Directory, it is not matched with John Q's account. Instead, a new user account—a disabled user account—is created.

Clean Up Afterward

If you don't clean up the Exchange 5.5 directory before you run Active Directory Connector, you may have to clean up Active Directory afterward because Windows 2000 accounts may be associated with the wrong mailboxes. For example, John Q may own the Sales mailbox rather than his own, and a new account created by the ADC—Sales—may own John Q's mailbox.

When you create a one-way connection agreement (from Exchange to Active Directory), you can use the following steps to remove the mismatched accounts (you must do this before you install Exchange 2000):

  1. Stop Active Directory Connector.

  2. Populate the Extension-Attribute-10 attribute with NTDSNoMatch as described previously.

  3. Delete all user objects created by ADC for the mismatched mailboxes.

  4. In the Active Directory Users and Computers snap-in to Microsoft Management Console (MMC), disable the mailbox of the user account that was mismatched.

  5. On the connection agreement Schedule tab, select the Replicate the Entire Agreement the Next Time the Agreement is On check box.

  6. Start Active Directory Connector.

Use Only Supported Characters in Your Organization Name

If your Exchange 5.5 organization and site names contain characters that are not supported by Exchange 2000, you will have to rename those objects.

Organization and site display names can contain only the following characters (all other characters are invalid):

  • A-Z

  • a-z

  • 0-9

  • - (hyphen)

Spaces are also valid. However, remember that parentheses, "()," and brackets, "[]," cannot be used.

Run Move Server Wizard

If you want to move servers between sites, now is the time to do it. After you install your first Exchange 2000 server, and thus create a mixed-mode Exchange organization, you cannot move servers between sites in the same organization.

After you move servers, allow the Exchange 5.5 directory time to update.

Prepare Active Directory

You prepare Active Directory for Exchange 2000 after you have developed some confidence in the stability of your Windows 2000 topology.

Important: Make sure all the appropriate fixes have been made to Windows 2000 by installing Windows 2000 SP1. You need to install Windows 2000 SP1 on the domain controllers and global catalog servers, and on the server on which you are installing Exchange 2000. For more information, see the Windows 2000 Web site.

Prepare Active Directory before you install or upgrade your first Exchange 2000 server, as follows:

  • Evaluate your automation tools.

  • Populate Active Directory with Exchange 5.5 information by running Active Directory Connector.

  • Prepare your organization with the appropriate Active Directory schema extensions, and create the necessary permissions and Exchange-specific security groups by running ForestPrep and DomainPrep.

Evaluate Your Automation Tools

Before you run the Active Directory Connector, you should evaluate your existing automation tools. Be aware of account creation tools that may put some accounts in a suspended state.

Make sure that your tools are having no adverse affect on Active Directory behavior and are performing as expected. Most important, make sure your tools are modifying the correct Active Directory attributes. If you're creating errors in Active Directory, fix them before running the ADC.

Populate Active Directory with Exchange 5.5 Directory Information

Before you upgrade to Exchange 2000, the ADC provides a vital link between the Exchange 5.5 directory and Active Directory—in particular, ADC connects to the global catalog.

Active Directory Connector (ADC) synchronizes Active Directory with an Exchange 5.5 directory. However, it is best to understand ADC not as a replication or synchronization tool, but as a step in upgrading to Exchange 2000.

The ADC populates Active Directory with additional, mail-related attributes. If necessary (that is, if you haven't run ForestPrep yet), during setup the ADC will extend the schema to contain these attributes. The ADC adds Exchange directory information to existing Windows 2000 security accounts, which you may have created when you upgraded Windows NT 4.0. If no accounts exist, it creates them for you, in the manner you choose—as enabled or non-enabled user accounts, or as contacts.

When you add new information to Active Directory it becomes part of the Active Directory replication load. Replication may take some time, depending on the number of servers in your topology.

What Objects Are Synchronized?

Objects are synchronized using connection agreements. A connection agreement is used to specify what is replicated between Active Directory and the Exchange 5.5 directory, and into which containers the information is replicated.

The ADC synchronizes three distinct types of information, using one of the following connection agreements:

  • Recipient Connection Agreement Mailboxes, distribution lists, and custom recipients

  • Public Folder Connection Agreement Information required for mailing purposes, such as public folder name and e-mail address

  • Configuration Connection Agreement Connectors, monitors, protocols, topology information, and other configuration information (for example, administrative and routing groups are created that match Exchange 5.5 site names)

    Note: If you plan to upgrade to Exchange 2000, always use the Exchange version of the ADC, rather than the Windows 2000 version. The Exchange ADC is a superset of the Windows 2000 ADC; whereas the Windows 2000 ADC synchronizes objects in the Exchange 5.5 site (for example, the Recipients containers) to Active Directory, the Exchange 2000 ADC also replicates configuration data, such as protocol and connector data, and thus allows Exchange 5.5 and Exchange 2000 servers to coexist. Because the Exchange 2000 ADC adds functionality beyond the Windows 2000 ADC, you can replace the Windows 2000 version with the Exchange 2000 version.

For more information about the types and uses of connection agreements, see your Exchange documentation.

Synchronization Tip

Synchronization is simplified if you synchronize the entire Exchange 5.5 site instead of synchronizing individual recipient containers. Choosing the entire Exchange 5.5 site as the source and target of the connection agreement on the Exchange Server, and the Active Directory domain as the source and target on the Active Directory side of a two-way connection agreement, effectively synchronizes the Exchange 5.5 recipient container hierarchy with the organizational unit hierarchy in Windows 2000. The organizational unit hierarchy or the location of individual recipients created in the Active Directory by the ADC can be changed later. Remember that if you try this approach, the container and organizational unit for the Active Directory domain can be created on the Exchange 5.5 side.

The ADC at The Milk Company

At The Milk Company, the explicit goal of installing ADC is to replicate all information on users in the Exchange 5.5 directory to Windows 2000 as quickly as possible, before installing Exchange 2000. If Exchange 2000 is installed before this process is complete, those users whose mailbox information has not been synchronized will not be viewable by those whose mailboxes have been upgraded. Mail will not be able to reach those unsynchronized Exchange 5.5 mailboxes.

Because the goal is to upgrade to Exchange 2000 relatively quickly, rather than coexist for a lengthy period, The Milk Company is defining connection agreements to every site. Following are the steps they take:

  1. Install ADC on a member server running Windows 2000 in the New York City site (the ADC can consume a lot of processor time; so it is generally best to install it on a member server rather than on a domain controller or global catalog).

    This is the result: Exchange 5.5 directory information was synchronized with Active Directory, and the global catalog was rebuilt.

  2. Create a connection agreement to synchronize Exchange 5.5 users and distribution lists in New York City with the native-mode Windows 2000 domain (NA.TheMilkCompany).

    This is the result: This populated Active Directory with user objects and group objects that correspond to the New York Exchange 5.5 site.

    Note: If an Exchange 5.5 object already exists in Active Directory, the connection agreement links them and thereafter synchronizes information between them. If an Exchange 5.5 object does not exist in Active Directory, the object is created and thereafter linked and synchronized with its counterpart on the Exchange 5.5 side.

  3. Create a connection agreement to synchronize Exchange 5.5 users and distribution lists in Los Angeles with the native-mode Windows 2000 domain (NA.TheMilkCompany).

    The result is the same as in New York: Los Angeles users and groups populated Active Directory.

  4. Create a connection agreement for London. Select the "custom recipients" check box in the connection agreement in order to replicate Paris recipients to Active Directory. (Using the Notes connector, these recipients were added to the Exchange directory earlier as custom recipients.)

    This is the result: Because the Windows NT 4.0 domain hasn't been upgraded yet, this connection agreement creates Windows users and groups in the root domain. Later they will be moved to the EUR domain by the Active Directory Account Cleanup Wizard (ADClean.exe).

  5. Later, another connection agreement is created to synchronize the public folders with the native-mode domain, NA.TheMilkCompany (this happens in Step 5).

    This is the result: Public folder objects in the Exchange 5.5 directory are created in Active Directory and linked to the Exchange 5.5 object. Information between them will be synchonized.

    Note: The Milk Company has employed a dedicated native-mode domain (NA.TheMilkCompany) to be used as the target of ADC connection agreements. This is for ease of administration, but more importantly, a native-mode domain supports universal groups, which are needed to represent distribution lists and ACLs on public folders. For more information, see the article on this Web site titled "Upgrading Public Folders from Microsoft Exchange Server 5.5 to Microsoft Exchange 2000 Server."

After the root and EUR.TheMilkCompany domains have been upgraded to native mode, individual groups can be moved into the domains best suited for them, and the current native-mode domain, NA.TheMilkCompany, no longer needs to assume a special "group management" function.

Cc723569.sxstep04(en-us,TechNet.10).gif

Figure 9: Connection Agreements to the Native-Mode North American Domain

Connection Agreements to Every Site

Before upgrading an Exchange 5.5 site, you must define a user connection agreement to that site (and, if necessary, a public folder connection agreement). Upgrading to Exchange 2000 modifies users' directory information, and one restriction of Exchange 5.5 is that you cannot modify users that are on other sites. Therefore, you need a direct, physical connection to the site (a connection agreement to each site that you will be upgrading). This is demonstrated in Figure 9.

Initially, you may not be able to define a connection agreement to every site, in which case you can perform an Exchange 5.5 directory data upload to Active Directory by configuring a one-way connection agreement from Exchange. Because the ADC does not need to write information back to the Exchange 5.5 directory, recipient containers from multiple Exchange sites can be exported through a single connection agreement that is connected to the entire Exchange organization. This is useful when you have many earlier Exchange sites in the organization or when there is a distributed security model in place.

Note: When you are defining a connection agreement to an Exchange site, the target directory bridgehead should be Exchange Server 5.5 Service Pack 3 (SP3) or later, even if you are defining a one-way connection agreement. Exchange 5.5 SP3 includes a modified schema, performance enhancements, and the ability to page LDAP results. Other Exchange servers on the site are not required to run Exchange Server 5.5 SP3.

The ADC with Windows 2000 Accounts

At The Milk Company, all the Windows NT 4.0 accounts in New York City and Los Angeles have been upgraded to Windows 2000. Because these New York and Los Angeles accounts are already in Active Directory, ADC matches each Exchange 5.5 mailbox with the existing account in Active Directory, based on the Primary Windows NT Account setting on the Exchange 5.5 mailbox. If the user does not exist, a new account is created. The account can be an enabled or disabled user, or a contact, depending on which you specify in the connection agreement.

Important: The ADC does not create an object in Active Directory unless the object does not exist. Nor does the ADC move objects from one domain to another. For example, if your connection agreement targets domain A, but the users you're attempting to replicate already exist in domain B, the users will not be moved to domain A. Instead, Exchange directory information is added to the users in domain B.

The ADC with Windows NT 4.0 Accounts

Next, the Exchange administrator creates another connection agreement to London. Because users in London haven't been upgraded to Windows 2000, they don't exist in Active Directory. So ADC creates a Windows 2000 user account for each Exchange 5.5 mailbox. However, because their Windows NT 4.0 user accounts currently remain on the London Windows NT 4.0 domain, the administrator specifies that user accounts that are not enabled be created. At this time, they are used only for mail routing, not for security. Each user account that is not enabled contains all the Exchange directory information.

Mailbox permissions are transferred as follows: First ADC copies the Windows NT 4.0 security identifier (SID) into the msExchMasterAccountSid attribute. Later, during the upgrade to Exchange 2000, permissions are set using this attribute, so that users can access their mail using their Windows NT 4.0 security credentials.

When the London Windows NT 4.0 account domain is finally upgraded to Windows 2000, the domain joins the forest as a child domain, called EUR.TheMilkCompany, of the existing root domain, TheMilkCompany. When London is upgraded, there are two accounts in Active Directory for each Exchange user: the original disabled user account created by ADC and the newly upgraded Windows 2000 account.

Note: After the upgrade to Exchange 2000, any Exchange mailbox that is "owned" by duplicate accounts cannot be used until the accounts are merged.

When to Run the Active Directory Account Cleanup Wizard

The Active Directory Account Cleanup Wizard, included with Exchange 2000, walks through Active Directory to match and merge duplicate accounts. The wizard matches the msExchMasterAccountSid attribute of a disabled user account with the primary SID of an upgraded user account. Duplicate accounts match because, when the Windows NT account is upgraded, its primary SID remains the same—and this same SID was copied to the msExchMasterAccountSid attribute of the disabled user account when it was created by ADC.

The Active Directory Account Cleanup Wizard merges all the attributes of the disabled user account into the upgraded user account. As part of the process, the disabled user account is deleted, leaving a single mailbox-enabled user account in Active Directory for each Exchange user. The wizard needs to be run only when the domain is upgraded. For more information about the wizard, see Step 5 in this article.

Cc723569.sxstep05(en-us,TechNet.10).gif

Figure 10: Active Directory Account Cleanup Wizard

When to Move On

Before running ForestPrep or DomainPrep, you should test the new addition to your Windows 2000 topology. You can configure one or more connection agreements to replicate any container or set of containers. Make sure that when you change an attribute, it is replicated properly. Create and delete accounts, create distribution groups, and in general, assess the stability, accuracy, and reliability of your Windows topology. When you're confident that replication is proceeding properly, move on.

Preparing the Forest and Domains by Running ForestPrep and DomainPrep

Now that Active Directory Connector is installed and you have set up connection agreements to replicate users and distribution lists, you need to prepare the forest and each domain for Exchange 2000.

ForestPrep and DomainPrep are both run from the command line. Before running them, you should have a clear understanding of the permissions required by members of the administrative team.

Note: For a full discussion of ForestPrep and DomainPrep, see the article "ForestPrep and DomainPrep," available on this Web site.

Running ForestPrep and DomainPrep should be considered a preliminary step to running Exchange Setup, but properly understood, it is part of a single setup procedure that is divided into three parts:

  • ForestPrep, forest-wide configuration requiring Enterprise Administrator permissions (including Schema Admin permissions and, if joining an existing Exchange 5.5 site, Exchange 5.5 administrative permissions)

  • DomainPrep, domain-wide configuration requiring Domain Administrator permissions

  • Exchange Setup

One Setup, Three Parts

The first part, ForestPrep, prepares the entire Windows 2000 forest for Exchange, and therefore needs to be run in the same domain as the schema master (usually the root domain). ForestPrep can be separated from Exchange 2000 Setup, because Setup must perform operations that require permissions of Enterprise Admins and Schema Admins—and some organizations may not be comfortable providing this level of permissions to Exchange administrators. In other words, the permissions required for Exchange installation are at a much higher security level than those required to administrate an Exchange server. So, ForestPrep is run by the Windows 2000 Enterprise Administrator as a separate, preliminary setup function. For the same reason, DomainPrep is separated from Exchange Setup because many organizations do not want Exchange administration to have Domain Admins rights.

Note: If a single person or group that is responsible for deploying Exchange also has permissions to modify the Active Directory schema and control domains, there are fewer preparation tasks. If the account that you use to install the first instance of Exchange belongs to the Schema Admins, Enterprise Admins, and Administrators (for the first server) security groups, and you only have one domain, ForestPrep and DomainPrep can be run as part of Exchange Setup.

What ForestPrep Does

Depending on whether you are installing a new Exchange organization or joining an existing Exchange 5.5 organization, ForestPrep presents slightly different options. In general, ForestPrep:

  • Extends the Active Directory schema to include Exchange-specific information. This affects the entire forest and may take a long time to replicate changes to every domain and domain controller.

    Note: If you run Active Directory Connector setup first, as The Milk Company did, the schema is already partially extended.

  • Prompts for and creates the Exchange organization name and object in Active Directory, and it builds the initial Exchange organization structure in Active Directory. (For The Milk Company, the organization name is The Milk Company.) When Exchange is installed, Setup queries Active Directory for configuration information.

  • Assigns Exchange Full Administrator permissions to the account that you specify. This account has the authority to install Exchange throughout the forest. After the first installation of Exchange 2000, this is also the account you will use to run Exchange Administration Delegation Wizard, which configures Exchange-specific roles for administrators throughout the forest. This wizard is discussed in Step 4.

    Note: After the schema is extended by using ForestPrep, it is not easy to undo those changes.

  • Updates the display specifiers. These are the Exchange-specific tabs that are visible on the Properties page of users and groups in Active Directory Users and Computers. The tabs added by Exchange include Exchange General, Exchange Features, and Exchange Advanced.

What DomainPrep Does

DomainPrep creates two security groups in each Windows 2000 domain in which it is run. Together, the groups are used to provide permissions to Exchange servers, so that the servers can perform tasks such as modifying Exchange user attributes. Windows 2000 domain administrators must run DomainPrep in any domain where:

  • Universal security groups will be installed.

  • Mail-enabled objects, such as users, will reside.

  • An Exchange server will be installed.

DomainPrep creates and configures permissions for the groups in the following table.

Table 2 Groups Created by DomainPrep

Group

Function

How Populated

Permissions

Exchange Domain Servers

A global security group that lists the computer accounts of all servers running Exchange 2000 in each domain

It's populated by Exchange setup when you install a server.

It has read-only permissions to Exchange System Manager.

Exchange Enterprise Servers

A domain local security group that contains all Exchange Domain Servers groups from all domains, used for granting access

The Recipient Update Service adds the Exchange Domain Servers groups from all other domains that have an active Recipient. Update Service.

It has modify permissions on all Active Directory recipient objects.

Before Moving On

After running ForestPrep and DomainPrep, The Milk Company's networking and Exchange administrators waited until the next morning before beginning Exchange 2000 installation. They did this to ensure that all the setup tasks they had performed to this point had taken effect.

This is a highly recommended approach, because up until now none of The Milk Company's employees has been affected by the preparatory work performed in Steps 1 through 3. After the first Exchange 2000 server is installed, however, this changes. It is crucial first to verify that the schema has been extended and that all necessary replication has occurred properly.

You must do the following before moving on to Step 4:

  • Clean up Exchange 5.5.

    • Any users with multiple mailboxes must be identified.
  • Migrate Exchange 5.5 mailbox information into Active Directory.

    If you are planning to install Exchange 2000 immediately after installing Windows 2000, extend the Acitve Directory schema with Exchange attributes now.

    • Run ForestPrep.

    If you are planning to deploy Windows 2000 for a while before installing Exchange 2000, install ADC in the forest that Exchange will eventually use.

    • Run ADC Setup.

    Set up a recipient connection agreement to Exchange 5.5 sites to prepopulate Active Directory with all Exchange 5.5 user account information. (A two-way connection agreement is required to upgrade a 5.5 site.)

    • If you are not immediately upgrading a site, create a one-way recipient connection agreement.

    • If you are immediately upgrading a site, create a two-way recipient connection agreement that will allow the site to be upgraded to Exchange 2000.

    If all associated Windows NT accounts are already in the Windows 2000 forest that the ADC is using, verify that:

    • ADC mail-enables and replicates 5.5 directory information into existing accounts or into disabled accounts created by ADC.

    • ADC created universal distribution groups for Exchange 5.5 distribution lists.

  • If all associated Windows NT accounts are not already in the Windows 2000 forest that the ADC is using, verify that:

    ADC created a disabled user account for each mailbox for which ADC did not find an associated Windows NT account in the current forest.

  • If you are ready to upgrade all Windows NT 4.0 accounts when Exchange is deployed, run Active Directory Account Cleanup Wizard.

  • Set up an ADC public folder connection agreement to replicate the public folder directory structure in Active Directory.

    Prepare forest and domains for initial Exchange 2000 installation.

    • If you have a single account that has all the permissions necessary to run ForestPrep, DomainPrep, and Exchange 2000 Setup, ForestPrep and DomainPrep automatically run with the installation of the first Exchange 2000 server.

    Otherwise…

    • If you do not have a single account that has all permissions necessary to run ForestPrep, DomainPrep, and Exchange 2000 Setup, you must:

      • Run ForestPrep now, if you did not already run it to extend the Active Directory schema.

      • Run DomainPrep for each domain needed.

Step 4: Install Your first Exchange 2000 Server

You can either install a new Exchange 2000 server or upgrade an existing Exchange 5.5 server. There is, however, an important benefit in installing a new server: If there is a problem during installation, none of your users will be affected, because initially none of your user accounts are enabled on the new server.

When you Install

The Milk Company decides to install its first new server in the New York City site. The administrator runs the installation wizard and chooses an Exchange server in the Exchange 5.5 site that he or she wants to join. Exchange collects the information it needs to create connection agreements. The server joins the New York City site.

Cc723569.sxstep06(en-us,TechNet.10).gif

Figure 11: Exchange Setup Page and Joining Site

The following are automatically created:

  • Configuration Connection Agreement The Exchange 2000 Setup wizard analyzes your Exchange organization and builds the configuration connection agreements (which are like the connection agreements in ADC). These connection agreements are required to replicate Exchange-specific configuration information between Exchange 5.5 and Active Directory. Specifically, the agreements are replicated between Active Directory and the Site Replication Service (SRS). The new connection agreement will turn on automatically five minutes after the server is installed.

  • Recipient Update Service The Recipient Update Service runs as part of the system attendant service on the Exchange server; the first Exchange server becomes the default recipient update server for the domain on which it is installed. Recipient Update Service is responsible for updating domain groups and recipient objects, which it does by propagating changes you specify on the user interface (UI) throughout the Exchange system. Recipient Update Service adds the new server to the Exchange Domain Servers group (on the Windows 2000 native domain, NA.TheMilkCompany). For every additional domain, you need to configure the Recipient Update Service for that domain.

  • Site Replication Service (SRS) SRS provides information about the entire Exchange 2000 configuration to Exchange 5.5 servers. It does this through the configuration connection agreement in ADC. Other Exchange 5.5 servers will interact with the SRS the same way they interact with Exchange 5.5 Directory Service.

Cc723569.sxstep07(en-us,TechNet.10).gif

Figure 12: Install the First Exchange 2000 Server

The Interface Between Active Directory and Exchange 5.5

ADC and SRS are the components that enable mixed-mode operation of Exchange. Together they manage the correspondence between the Exchange 5.5 directory and Active Directory.

SRS is installed automatically on the first Exchange 2000 server that you install on an Exchange 5.5 site, or on the first server on a site to be upgraded. (SRS is also installed automatically when you upgrade an Exchange 5.5 server that is a Directory Replication Bridgehead server.) To existing Exchange 5.5 servers, SRS functions like an Exchange 5.5 directory service; it participates in directory replication just as any Exchange 5.5 server does and displays in the Exchange 5.5 Administrator program as an Exchange 5.5 directory service. (No directory service is listed for those Exchange 2000 servers that do not host an SRS.)

SRS uses a directory database that is compatible with the Exchange 5.5 Dir.edb file. Because it mimics an Exchange 5.5 directory, SRS can be configured to provide Active Directory information to all Exchange 5.5 servers in its site.

Similarly, ADC imports the Exchange 5.5 organizational structure into Active Directory. When the first Exchange 2000 server is installed, a special connection agreement called a configuration connection agreement is created automatically. The configuration connection agreement replicates the topology of the Exchange 5.5 organization to Active Directory, where it is maintained in the configuration naming context. The configuration connection agreement also replicates Active Directory changes to SRS.

Run Exchange 2000 Delegation Wizard

After you install your first server, you can run the Exchange 2000 Administration Delegation wizard. The wizard simplifies the process of delegating the appropriate permissions to Exchange administrators. The Administration Delegation wizard is installed with Exchange and cannot be run until the first instance of Exchange 2000 is installed in the organization. The Administration Delegation wizard is the preferred means for designating administrators in your Exchange 2000 organization.

When you start the Administration Delegation wizard, you can assign the roles in the following table to groups and users:

Table 3 Exchange Administrative Roles

Role

Capabilities

Exchange Full Administrator

Administer all Exchange system information and modify permissions on Exchange objects

Exchange Administrator

Administer all Exchange system information

Exchange View Only Administrator

View Exchange configuration information

These three roles can be assigned at both the organization level and the administrative group level. This affords you flexibility in the level of control granted to new Exchange administrators. Organization-level administrators should assign one of the roles to new administrators only at the level needed to perform their specific tasks.

Note: Only a user with Exchange Full Administrator rights at the organization level can delegate roles to other users.

For administrative ease, you should create security groups and assign Exchange administrative roles to these groups, rather than assigning them to individuals.

Create a Bridgehead Server

After The Milk Company installs its first Exchange 2000 server, the administrator reconfigures the following connectors so that they connect to the new server:

  • Active Directory Connector Change the connection agreements so that directory data is routed through the new server.

  • Directory Replication Connectors (DRCs) Exchange 5.5 DRCs can be reconfigured to point to the new server. They do not need to be deleted and added.

    Note: Pointing a DRC to a new server means that the entire Exchange 5.5 site must be re-replicated to that new server. While this happens, your Exchange 5.5 site could temporarily suffer bandwidth and other resource depletion.

Before upgrading an Exchange 5.5 server that is running ADC, you should move ADC to another server in the Exchange site. Because the first Exchange 2000 server in an Exchange 5.5 site contains SRS, it makes sense to move ADC to the Exchange 2000 server. This creates a bridgehead server between Exchange 5.5 and Exchange 2000. The primary benefit of creating such a bridgehead is ease of administration. Although it is possible to move the ADC to another Exchange 5.5 server, you would have to move it again when it is time to upgrade that Exchange 5.5 server. By connecting ADC to the Exchange 2000 server running SRS, you can use SRS on the bridgehead server between Exchange 5.5 and Exchange 2000, and not worry about re-pointing connection agreements in the future.

Cc723569.sxstep08(en-us,TechNet.10).gif

Figure 13: Create a Bridgehead Server

Now You're Co-existing

After you introduce the first Exchange 2000 server to an Exchange 5.5 organization through an upgrade or a fresh installation, the Exchange organization is in mixed mode. The organization stays in mixed mode until all the Exchange 5.5 servers have been upgraded or decommissioned.

Operating in mixed mode affects administrators far more than users. As soon as a user's server is upgraded to Exchange 2000, the user can access the full range of new features. The following restrictions affect how the administrator manages the upgraded server:

  • Routing group membership is limited to the membership of the administrative group In mixed mode, routing groups must correspond to administrative groups. This restriction exists because, in mixed mode, there are two versions of the Exchange directory—the Exchange 5.5 directory service and Active Directory. The Exchange 5.5 directory does not distinguish an administrative group from a routing group; both are merged in the site concept. So, for message routing and related operations to work, the version of the directory maintained in Active Directory must reflect Exchange 5.5 directory concepts.

    Notes: You can have multiple routing groups, but the union of their membership must be equal to the membership of the administrative group. For example, an administrative group with eight servers could be split into three routing groups. It doesn't matter how many servers are in each routing group, only that the total membership of all three routing groups equals the eight servers in the administrative group.

    Although you can create multiple routing groups in a mixed-mode administrative group, only Exchange 2000 servers can recognize them.

    When all the servers in an administrative group have been upgraded to Exchange 2000, they will all recognize additional routing groups in the administrative group; however, they cannot cross the boundary of the administrative group.

  • You can't move users between sites In mixed mode, you cannot move Exchange 5.5 users between Exchange sites, or, in Exchange 2000 terms, between administrative groups. (An Exchange 5.5 site corresponds to an Exchange 2000 administrative group.) When all servers are upgraded and your organization switches to native mode (described in Step 6), mailboxes can be moved between adminstrative groups.

After the organization is switched to native mode, routing groups are defined independently of administrative groups, and users can be moved freely between administrative groups.

Before Moving On

After introducing Exchange 2000 into their organization, The Milk Company's Exchange administrators verify each item in the following list before moving on to Step 5:

  • The SRS, ADC configuration connection agreement, and Recipient Update Service are present and working properly.

  • If the ADC was moved prior to Exchange 2000 installation, it is functioning on the new server.

  • You can see your entire Exchange 5.5 organization through Exchange 2000 System Manager. This indicates that your Exchange 5.5 structure is in Active Directory.

  • All services have started on the Exchange 2000 server.

  • New users can be added to the Exchange 2000 server.

  • Message flow is working properly.

  • Directory changes are being synchronized.

  • Folder content is being replicated between appropriate locations in your public folder hierarchy.

Step 5: Upgrade the Information Stores and Other Exchange Components

When you install Exchange 2000 on a single server and begin directory replication, you create a mixed-mode Exchange organization.

You've already used ADC to populate Active Directory accounts with Exchange 5.5 directory information; now you must upgrade the mailbox store, the public folder store, and a variety of connectors.

In addition, The Milk Company needs to migrate the Paris site to Windows 2000 and Exchange 2000, and upgrade the London domain to Windows 2000 before upgrading the London site to Exchange 2000.

Recap

Up to this point, The Milk Company has:

Step 1

  • Planned both Windows 2000 and Exchange 2000 deployments.

Step 2

  • Upgraded New York City and Los Angeles Windows NT 4.0 domains to Windows 2000 by creating a root domain and child native-mode Windows 2000 domain.

Step 3

  • Prepared the Exchange 5.5 directory for import to Active Directory by cleaning up resource mailboxes.

  • Assessed the Windows 2000 environment and evaluated account creation tools.

  • Applied Windows 2000 SP1.

  • Installed Active Directory Connector and created connection agreements to New York City, Los Angeles, and London, in order to synchronize both users and distribution lists.

  • Run ForestPrep.

  • Run DomainPrep on the root and NA.TheMilkCompany domains.

Step 4

  • Run Exchange Setup and installed a new Exchange 2000 server.

  • Reconfigured the ADC and the DRCs to the new bridgehead server.

What's Next

Step 5

  • Upgrade the mailbox store: For the New York City domain, move mailbox data to the new Exchange server, and upgrade the other Exchange 5.5 mailbox server.

  • Upgrade the public store: Replicate all public folders in the organization to Active Directory.

  • Upgrade connectors.

  • Repeat for each server in the New York City and Los Angeles sites.

  • Migrate the Paris site to Exchange 2000.

  • Upgrade the London Windows NT 4.0 domain.

  • Run Active Directory Account Cleanup Wizard.

  • Upgrade London servers.

Step 6

  • Switch to a native-mode Exchange 2000 organization.

A Note on Upgrading Exchange Components

The following pages describe upgrading Exchange server components. Some or all of these components can be upgraded concurrently, but for the purposes of this article, the specifics are discussed individually.

Upgrade the Mailbox Store

You can use one of two basic methods to upgrade mailbox data: Either move mailboxes from an Exchange 5.5 server to a target Exchange 2000 server, or do an in-place upgrade. An in-place upgrade may involve downtime for users whose mailboxes are hosted on the server; however, an in-place upgrade can be economical, especially in large distributed networks where small sites support single servers.

For The Milk Company, both methods are used at the New York City site, because one of the two computers running Exchange 5.5 must be decommissioned to upgrade the hardware.

Move Mailboxes

First, you install Exchange 2000 on a new computer. Then, mailboxes from an Exchange 5.5 server are moved manually to the Exchange 2000 server, using Active Directory Users and Computers MMC. Then, you decommission the Exchange computer and upgrade the hardware before re-employing it as another mailbox server for new employees.

Notes: Exchange 5.5 servers should stay in the topology long enough for user profiles to be automatically retargeted to the appropriate server.

In mixed mode, you can move mailboxes only to another server in the same administrative group (Exchange 2000) or the same site (Exchange 5.5).

In-Place Upgrade: Deferred Upgrade Process

To do an in-place upgrade, The Milk Company administrator installs Exchange 2000 on a second computer, which is running both Windows 2000 Server and Exchange 5.5 SP3, and follows the Setup Wizard's instructions.

Note: You cannot add components that are not already installed on the server during the upgrade. However, you can run Setup after the upgrade to add components such as connectors and real-time collaboration services. If Exchange 2000 does not include connectors that are running on your existing server, those connectors will not be available after you upgrade.

The actual upgrade of the mailbox store happens online, using a process that runs in the background. The process moves from mailbox to mailbox, upgrading as it goes—or, if a user attempts to access his or her mailbox, it is upgraded at that time. For this reason, it's best to start the upgrade at a time when you expect that few users will access their mailboxes. This enables the Exchange 2000 server to be available as quickly as possible.

Note: It's very important that the Exchange 5.5 directory is completely current before you move any mailboxes, and that any new information is replicated to Active Directory before migration. Ensuring directory integrity reduces complications during upgrade.

For more information on upgrade methods, see Exchange 2000 Planning and Installation, available on the product CD.

Upgrade the Public Folder Store

Before upgrading the public folder store, you should have an understanding of Windows 2000 groups.

Groups and Public Folders

As discussed earlier, when ADC is run, it converts Exchange 5.5 distribution lists to universal distribution groups (UDGs). In special cases, after a distribution list is converted to a UDG, the UDG is then converted to a universal security group (USG). Because Exchange 5.5 public folder ACLs may contain distribution lists from any domain, whenever a public folder is upgraded, any distribution lists used in an ACL must be represented as a USG.

Because not all Exchange distribution lists are used for setting permissions on public folders (only a subset are used in this way), Exchange is selective about converting UDGs to USGs. Conversion occurs only on those groups that are being used for permissions.

Note: Any UDG that has been used for permissions is converted; however, the most common instance is in public folders.

The conversion process could occur at one of four points:

  • During upgrade from Exchange 5.5

  • During public folder replication with Exchange 5.5

  • Whenever a user defines permissions on an Exchange public folder and specifies a distribution group

  • When the folder is accessed

The process of converting a UDG to a USG occurs at the earliest opportunity, that is, as soon as one of the above four conditions occurs. Until that happens, however, conversion is deferred.

Upgrading Public Folders

You upgrade the public folder store in four basic steps, and the steps must be in order:

  1. Remove obselete users from ACLs.

  2. Replicate public folder directory information by creating a public folder connection agreement.

  3. Replicate the public folder hierarchy.

  4. Replicate or upgrade the messages into the Exchange 2000 public folder store.

These steps are covered in more detail in the article on this Web site titled "Upgrading Public Folders from Exchange 5.5 to Exchange 2000." However, the following paragraphs provide a summary.

1. Remove Obsolete Users from ACLs

The first step in upgrading the public folder store is to clean the store. You have to clear the public folder ACLs of obsolete users—those users who have left the organization, but whose names remain in ACLs on public folder objects.

When users leave a company, they typically leave behind a trail of obsolete permissions on store folders. Usually this does not present a problem; the list will simply contain some obsolete users. But for ACLs on public folders, these users need to be deleted before you can upgrade to Exchange 2000.

When public folders are replicated to Windows 2000, Active Directory must translate Exchange 5.5 public folder ACLs, which were based on distinguished names, into Windows 2000 ACLs, which use the Windows 2000 primary account SID. Active Directory locates the user associated with the old Exchange 5.5 credentials (the distinguished name), and stamps the user's new Windows 2000 credentials (the SID) onto the public folder. If Active Directory cannot find the user (because the user is obsolete), the distinguished name remains in the ACL. However, while the distinguished name is in the ACL, the public folder cannot be accessed, because Active Directory cannot assess the validity of the credentials and the user is treated as a security risk. Thus, it is very important to delete obsolete entries.

Use the Directory Service Information Store (DS/IS) consistency adjuster to find and delete obsolete entries in ACLs in the Exchange 5.5 directory. The tool is part of Exchange 5.5 and is available through the Exchange 5.5 Administrator.

2. Replicate Public Folder Directory Information

This is done through public folder connection agreements, which replicate public folder names between Exchange Server 5.5 directory and Active Directory. Public folder connection agreements can only replicate public folders, and they always use two-way replication.

3. Replicate the Public Folder Hierarchy

New Exchange 2000 servers have a public folder database by default, and this database automatically creates the same hierarchy used by the Exchange 5.5 servers in the site. Be sure to allow time for the hierarchy to replicate. When upgrading an Exchange 5.5 server, keep in mind that it already contains the hierarchy (provided it was originally configured to replicate with other Exchange 5.5 servers).

4. Replicate or Upgrade the Messages into the Exchange 2000 Public Folder Store

A new public folder hierarchy on an Exchange 2000 server will not have any content until you configure it to replicate with Exchange 5.5 servers. This can be done through Exchange 2000 System Manager.

Upgrading Connectors

When you upgrade an Exchange 5.5 server, you can upgrade the connectors at the same time. If Exchange 2000 does not include a connector that is running on your existing server, for example, the Exchange Connector for SNADS, that connector will not be available after you upgrade. In addition, you cannot add Exchange 2000 connectors that are not already installed on the server during the upgrade. After the upgrade, you must run Setup and add those connectors.

The following table lists the Exchange 2000 connectors:

Table 4 Exchange 2000 Connectors

Connector

Description

Routing Group connector

This connector provides the simplest method for connecting two Exchange routing groups. The Routing Group connector communicates over an SMTP connection; however, a Routing Group connector is much simpler to configure than an SMTP connector, because you need to configure only one set of properties to connect two routing groups.

SMTP connector

This connector provides connectivity to Exchange 2000 routing groups within an administrative group and to foreign messaging systems. The SMTP connector conforms to the standards published in Request for Comments (RFC) 821.

X.400 connector

This connector can be configured to connect routing groups within an administrative group or to route messages to foreign X.400 systems. The X.400 connector conforms to the 1984 and 1988 International Telegraph and Telephone Consultative Committee (CCITT) X.400 standards.

Lotus Notes connector

This connector provides message delivery and directory synchronization between Windows 2000 and Exchange 2000, and Lotus Notes.

Lotus cc:Mail connector

This connector provides message delivery and directory synchronization between Windows 2000 and Exchange 2000, and Lotus cc:Mail.

Novell GroupWise connector

This connector provides message delivery and directory synchronization between Windows 2000 and Exchange 2000, and Novell GroupWise.

Microsoft Mail connector for PC Networks and Microsoft Schedule+ Free/Busy connector

These connectors provide message delivery and directory synchronization, respectively, between Windows 2000 and Exchange 2000, and Microsoft Mail.

Note: If an Exchange 2000 connector does not exist for a messaging system, you may be able to use a third-party gateway or use an Exchange 5.5 connector in a mixed-mode environment.

The Routing Group, Simple Mail Transfer Protocol (SMTP), and X.400 connectors are installed automatically when you install Exchange 2000; the other connectors are listed under Microsoft Exchange Messaging and Collaboration Services in Exchange Setup. During a fresh installation of Exchange 2000, simply choose Install next to the connector you want to install. When you are upgrading a server, setup will only upgrade whatever components are currently installed on the Exchange 5.5 server. However, after the upgrade, you can go back and install additional Exchange 2000 components.

Reconfiguring the Connectors

When you upgrade the connectors, it is likely you will have to reconfigure them. You can also migrate connectors rather than upgrade them. That is, on a new Exchange 2000 server, you install a connector that matches an existing connector, and recreate the original connection information in the new connector.

Routing Group, SMTP, and X.400 Connectors

When you upgrade an Exchange 5.5 server to Exchange 2000, the connection information for the Exchange 5.5 X.400 connectors is preserved. Connection information for site connectors is also preserved in the equivalent Routing Group connectors. The setup log file will contain details about any connection information that is lost.

Note: Message formats in SMTP connectors are upgraded to a global SMTP message format in Exchange 2000. This can be found under Global Settings in System Manager. However, Exchange 5.5 per-domain routing configurations are not upgraded. You will have to set up an SMTP connector to each domain that had per-domain configurations and recreate those settings.

Directory Replication Connectors

When you upgrade a server that hosts a Directory Replication connector, Site Replication Service (SRS) is installed on the upgraded server. You do not need to upgrade Directory Replication connectors (DCRs), because they're not needed in Exchange 2000 (although if you still have Exchange 5.5 servers in your organization, you'll need DCRs for directory replication). You delete the connectors in order to switch to Exchange 2000 native mode (more on this later).

Foreign Connectors

When you upgrade from Exchange 5.5 to Exchange 2000, you must reconfigure the foreign connectors. Although the connection settings are saved, you need to reconfigure the following:

  • Directory synchronization schedule

  • Address space used for message routing

  • Import container and export containers

    Note: Trust-level information on Exchange 5.5 import and export containers is obsolete in Exchange 2000 and is deleted during upgrade.

  • Delivery restrictions such as message size

Transfer of Ownership of Directory Entries

In Exchange 5.5, a foreign connector can be said to own the directory entries that it imports from another messaging system. When you populate Active Directory, the new contact objects are still owned by the Exchange 5.5 connector. The msExchImportedFrom attribute on these entries is populated by the globally unique identifier (GUID) of the original Exchange 5.5 connector.

The Exchange 2000 connector assumes ownership of these former custom recipients as follows: After the upgrade to Exchange 2000, on each inbound directory synchronization cycle, the Exchange 2000 connector checks the value of the msExchImportedFrom attribute. If the value is a close match to an Exchange 5.5 connector GUID, the new connector stamps the attribute with its own GUID, thus replacing the original GUID.

Effects of Ownership on Import and Export

You should always let a connector populate Active Directory with foreign users rather than create them manually. Changes made in a foreign directory are not imported to Active Directory unless the connector has imported, and therefore owns, the associated entries. (This is true even if the entry is in the designated import container.)

On export, the situation is reversed. When a connector exports directory entries from Active Directory, the connector propagates changes to any entries within its export containers that it does not own. Specifically, these entries do not contain the connector's GUID in their msExchImportedFrom attribute. This includes manually created entries that represent foreign users and users native to Exchange.

Foreign Connectors at The Milk Company

The only foreign connector used by The Milk Company is an Exchange 5.5 Lotus Notes connector, which connects the new Paris Lotus Notes installation to the London site/domain. After Paris users are migrated to Exchange 2000, the connector will no longer be needed in London. However, many organizations will need to upgrade their connectors.

Foreign Connectors in a Mixed-Mode Environment

In a mixed-mode environment, you can connect to a partner messaging system using either an Exchange 5.5 connector or an Exchange 2000 connector. In general, you should establish a single point of connection for mail between the partner system and the mixed-mode Exchange environment. Regardless of which Exchange server is connected to the partner system, the ADC can replicate the foreign directory entries to the other server.

Keep the two following considerations in mind when using foreign connectors in a mixed-mode Exchange organization:

  • If the partner messaging system connects directly to both Exchange 5.5 and Exchange 2000 for messaging and directory synchronization, the address spaces must be carefully segmented and mutually exclusive to ensure there are no loops in either message delivery or directory synchronization. You must carefully select import and export containers in both environments and configure mutually exclusive address spaces on the connector tabs.

  • The import container holding users from the partner messaging system must be included in an ADC connection agreement to ensure these users are propagated to each half of the mixed-mode Exchange system.

Creating a New Administrative Group

An administrative group is a collection of Exchange objects that is grouped together to simplify management of permissions. Objects in administrative groups inherit the permissions you set for the group. For example, if you have ten Exchange servers, it is simpler to define a set of permissions for an administrative group than it is to define the same set of permissions separately for each server.

After creating an administrative group and setting permissions for it, you can add objects to the group. This is the reverse of an analogous procedure in Exchange 5.5, in which you add a new Exchange 5.5 server as its own site, and then join it to an existing organization.

When the Paris Lotus Notes organization was first acquired by The Milk Company, an Exchange 5.5 Notes connector was immediately installed to connect Paris to London. Lotus Notes users were added to the London domain as custom recipients. Because of the trust established between the Windows 2000 forest and the London Windows NT 4.0 domain, these users now exist in Active Directory as contacts.

Now the time has come to join Paris to the organization. Migration Wizard will migrate Paris users to Windows 2000, creating fully populated user objects in Active Directory and deleting the associated contact objects.

After this is accomplished, The Milk Company decides that the best way to join Paris users to the Exchange 2000 organization is to create a new administrative group for them.

The following steps must be taken in order to create a new administrative group in Exchange 2000:

  1. Create a new native-mode Exchange 2000 administrative group, prior to adding a new server. (This is exactly the reverse of an analogous procedure in Exchange 5.5).

    The Milk Company names their new group "Paris administrative group." To find out how to create administrative groups, see your Exchange online documentation.

  2. Add a new Exchange 2000 server.

    When The Milk Company administrator runs the installation wizard, on the Administrative Groups and Routing Groups pages she selects the Paris groups that were created automatically by the ADC configuration connection agreement.

  3. Replicate directory information to the new Exchange 2000 server.

    Information about remaining Exchange 5.5 servers is replicated using the existing SRS (an additional SRS is not created). The ADC synchronizes this information with Active Directory.

Exchange 2000 Migration Wizard

This tool has two components: the source extractor and the migration file importer. The source extractor copies directory information, messages, calendar information, and collaboration data from Lotus Notes and saves the information to a file. The migration file importer imports the created file to Exchange. You can run both of these tools in one step, or separate each function. For more information on using Migration Wizard, see your Exchange documentation.

The Milk Company: Upgrade Final Windows NT 4.0 Domains

If you have a user domain (a domain with Exchange users but no Exchange servers), you do not have to upgrade the domain before installing Exchange 2000. You can install an Exchange 2000 server in a separate Windows 2000 domain and keep your users in a Windows NT 4.0 domain until you are ready to upgrade the user domain as well. Once the user domain is upgraded, you can move the Exchange 2000 server into that domain.

The Milk Company upgrades the London Windows NT 4.0 domain to a domain called EUR.TheMilkCompany (the domain topology was depicted earlier in Figure 3). The London users have already been imported to Active Directory by using ADC. After the domain is upgraded, Active Directory must be cleaned up. At that point, London Exchange servers can be upgraded in the same way as previously outlined for the New York site.

Cleaning Up Active Directory

Active Directory needs cleanup because the process of upgrading a Windows NT 4.0 domain does not include a built-in method to merge upgraded accounts with existing Windows 2000 accounts. These procedures create a security account, regardless of whether an account already exists for the user or object. While these two accounts exist, Exchange 2000 users cannot access their accounts.

When to Use Active Directory Account Cleanup Wizard

Use Active Directory Account Cleanup Wizard to clean up Active Directory in the following situation: You have used ADC to populate Active Directory with user accounts from Exchange 5.5 that are not enabled, and then you upgrade the Windows NT 4.0 domain that contains security accounts for those users.

You must use the wizard immediately after upgrading the domain. For information on how Active Directory Account Cleanup Wizard works, see your Exchange documentation.

Note: If you use connectors to coexist with a foreign messaging system, and then use Migration Wizard, Migration Wizard will merge accounts in Active Directory and there will be no need to run Active Directory Account Cleanup Wizard.

A Quick Look Back

Before going on to Step 6, Switch to Native Mode, it may be helpful to examine what has been done to The Milk Company's servers over the course of their enterprise-wide upgrade in Step 5.

  • In the New York City site, the mailboxes from one Exchange 5.5 server were moved to a new server running Exchange 2000. After all user profiles were retargeted to the new Exchange 2000 server, the Exchange 5.5 server was decomissioned. Meanwhile, an in-place upgrade was performed on the other Exchange 5.5 server in New York.

  • The Milk Company's entire public folder store was upgraded. After administrators cleaned up public folder ACLs, a public folder connection agreement was created to replicate the Exchange 5.5 hierarchy to Active Directory. Administrators waited until the hierarchy was replicated to all servers and then, in System Manager, configured their Exchange 2000 public folder servers to replicate specific information with Exchange 5.5 servers.

  • Routing group, X.400, and SMTP connectors were installed automatically; administrators made sure they were configured properly.

  • If the Paris site was not being upgraded to Exchange 2000 (see below), The Milk Company would have upgraded the Lotus Notes connector in London. Once they do upgrade, this particular connector will no longer be needed.

  • The Paris site was upgraded to Exchange 2000. Paris users already existed in Active Directory as contacts. After users were converted to Windows 2000 as fully populated user objects in Active Directory, and the contact objects were then deleted. In order to join Paris to The Milk Company's Exchange 2000 organization, a new "Paris administrative group" was created in System Manager. The first Exchange 2000 server in Paris was joined to this administrative group. Then administrators ran the Exchange 2000 Migration Wizard.

  • The London Windows NT 4.0 domain was upgraded to a domain called EUR.TheMilkCompany. After Active Directory Account Cleanup Wizard was run, London Exchange 5.5 servers could be upgraded.

Step 6: Switch to Native Mode

Switching to native mode is an easy step with many benefits. When you switch to native mode, you can completely reorganize the organization to match your true mail routing and administrative needs. You can create administrative groups within routing groups, move mailboxes between administrative groups, and more. At this point, Exchange 2000 no longer adheres to Exchange 5.5 site restrictions and earlier distinguished name rules.

Note: No direct relationship exists between the mode of the Windows 2000 domain and the mode of an Exchange organization; so you don't have to wait until Windows 2000 is in native mode before switching the Exchange organization to native mode.

You can use System Manager to switch Exchange 2000 to native mode when the following apply:

  • You no longer have Exchange 5.5 servers in your organization.

  • You have no plans to add Exchange 5.5 servers to your organization in the future.

Before Switching to Native Mode

Before you switch to native mode, you need to uninstall any Exchange 5.5 servers that you will not upgrade, and you must delete connection agreements, Directory Replication connectors, and remaining Site Replication Services.

You must uninstall the servers first, because you will use the SRSs to replicate the deletions to Active Directory.

Uninstalling Exchange 5.5 Servers

You can follow the Exchange 5.5 documentation to uninstall servers. However, after you uninstall the last Exchange 5.5 server from a mixed-mode topology, the server still appears in Active Directory. To remove it, you need to delete it from the SRS and replicate the change. You must use Exchange 5.5 Administrator to delete the uninstalled server from the SRS.

To install Exchange 5.5 Administrator, use Exchange 2000 Setup, click Custom, and then click Install for Exchange 5.5 Administrator. Use a Site Replication Service (SRS) on an Exchange 2000 server on the same site as the uninstalled server. Delete the entry for the uninstalled server from the list of site servers. After it is removed from the SRS, Active Directory Connector (ADC) replicates the change to Active Directory. Verify that this change has replicated to Active Directory before making topology changes.

Deleting Connection Agreements, DRCs, and SRSs

Before you switch to native mode, you also need to delete connection agreements, Directory Replication connectors, and Site Replication Services. The following steps must be completed in this order before you delete any SRSs in the organization. Once you begin the process of deleting the SRSs, you must delete them all.

  1. In the ADC, delete all recipient connection agreements. If you don't delete connection agreements before you begin deleting Site Replication Services, then you may lose data, such as the membership of distribution lists.

  2. Using System Manager, connect to each SRS in the organization and delete all Directory Replication connectors (DRC). To delete the DRCs, expand the Tools node to view Site Replication Service. On the View menu, click Directory Replication Connector View. Click on the DRCs, and then press Delete.

  3. In the ADC, manually replicate the deletion of the DRCs to Active Directory. To verify that deletion of the DRCs has been replicated to Active Directory, in System Manager, expand the Tools node to view Site Replication Service. On the View menu, click Directory Replication Connector View. If they have been deleted properly, DRCs will no longer be visible.

  4. Delete Site Replication Services. To delete SRSs, select the SRS in Exchange 2000 System Manager and, on the Edit menu, click Delete.

Switching to Native Mode

After you have finished the preparatory tasks, you're ready to switch to native mode. Switching is relatively easy. In System Manager, right-click your organization, click Properties, and then under Change Operations Mode, click Change Mode.

Reorganize the Organization

Before switching to native mode, the Exchange topology of The Milk Company still reflects the Exchange 5.5 topology: New York, Los Angeles, London, and Paris each exist as separate administrative/routing groups.

Now The Milk Company can:

  • Merge the New York City routing group/administrative group with the Los Angeles routing group/administrative group to create a single North American routing group/administrative group.

  • Keep the Paris and London administrative groups separate, but merge the Paris and London routing groups into one Europe routing group.

Create Administrative Groups Within (or Encompassing) a Routing Group

In Exchange 2000 native mode, routing groups exist within administrative groups, and administrative groups can span routing groups; in other words, it is possible to place a server in a routing group even if that server does not belong to the administrative group to which the routing group belongs. This permits delegation of control, so that one set of administrators can manage message routing while another administrator manages other aspects of the servers.

Servers can be assigned to administrative groups without consideration for message routing. This gives administrators great flexibility in managing servers, regardless of a server's physical location.

Move Mailboxes Between Administrative Groups

You can move mailboxes between mailbox stores in an Exchange organization. When operating in mixed mode, mailbox moves are restricted to mailbox stores within the same administrative group.

For The Milk Company, a team of North American milk salespeople can be moved to the new Paris administrative group to support the new operation. The administrator selects the users in Active Directory Users and Computers and moves them to the new administrative group.

Note: It is not possible to move a server to another administrative group.

Rename Objects

When you install Active Directory Connector, you must create a configuration connection agreement that creates an Exchange topology in Active Directory to match your existing Exchange 5.5 system. This is necessary for message transfer. However, after you switch to native mode, you can change any or all names of routing groups, administrative groups, or other organizational units.

For example, The Milk Company changes the name of its first administrative group from "New York City," which was the name of the first site to be upgraded, to "North America."

Important: When you rename objects in Exchange, you must stop and restart all services.

For more information about additional configuration and optimization tasks, consult your Exchange documentation, Microsoft Exchange 2000 Server Planning and Installation, and Microsoft Exchange 2000 Server Resource Kit.

Appendix: Exchange 2000 Upgrade Checklist

Use the following checklist to ensure that you are taking all necessary steps to deploy Exchange 2000.

  • Ensure you have a Windows 2000 forest.

    • Windows 2000 site and domain controllers available.
  • Ensure that you have a native Windows 2000 domain for replicating Exchange 5.5 distribution lists as UDGs.

  • Prepare all resource mailboxes and multiple-owner mailboxes with NTDSNoMatch.

    Install Exchange 2000 version of ADC.

    • You must syncronize Exchange 5.5 mailboxes.

    Ensure that the person running ForestPrep has appropriate permissions in the Exchange 5.5 organization.

    • You need View Only permissions on Site and Configuration containers in the Exchange 5.5 Administrator.

    Run ForestPrep.

    • You must have Enterprise Admins and Schema Admins permissions.

    Run DomainPrep.

    • You must have Domain Admins permissions.

    Setup or upgrade first server.

    • You should stop any Exchange 5.5 monitors that may attempt to restart services.
  • Switch to native mode.