共用方式為


Example: Exchange Server Site Consolidation - Proseware, Inc.

 

This topic illustrates an example Exchange Server site consolidation project for Proseware, Inc., a fictitious company. Proseware, Inc. employs over 500 people in five offices nationwide. The corporate headquarters in Seattle is the largest office with over 200 employees. The company has four regional offices with high-bandwidth connections in Denver, Phoenix, Los Angeles, and Miami.

Exchange services are distributed as follows:

  • The corporate headquarters in Seattle has one Exchange 5.5 server that hosts public folders and mailboxes for 200 users.

  • Each regional office has one Exchange 5.5 server that hosts public folders and mailboxes for 50 to 100 users.

Each regional office has a dedicated IT administrator to manage the local servers. The majority of the servers, however, are located and administered by the Seattle IT organization. Proseware, Inc. plans to upgrade to Exchange 2003, and in the process, consolidate their Exchange sites. They have recently centralized their support and monitoring operations, and they would like to do the same with their Exchange administration. In addition, the user base continues to grow, mailbox data and public folder usage continue to increase, and the Exchange servers are reaching the end of their lifespan.

To address these concerns, Proseware, Inc. plans to establish a datacenter in Seattle that will provide Exchange services to the sites. Proseware, Inc. will upgrade to Outlook 2003 and use Cached Exchange Mode. To maximize availability and scalability, the datacenter will take advantage of clustering and Volume Shadow Copy service backups in Microsoft Windows Server™ 2003.

Although the general recommendation is to switch to Exchange native mode before consolidating sites, Proseware, Inc. decides not to follow this path because of the cost associated with upgrading all Exchange 5.5 servers to Exchange 2003. Instead, they will use the site consolidation tools provided with Exchange 2003 SP1 to move Exchange data to the central site and retire their Exchange 5.5 servers.

The remainder of this topic describes the site consolidation process of Proseware, Inc.

Creating a Site Consolidation Plan

First, Proseware, Inc. studies the site consolidation tools, issues, and requirements. They determine whether they have enough server resources in the Seattle datacenter to support all of the Exchange services for all regional offices.

During their investigation into users' e-mail requirements, they find that, in the Denver regional office, engineers frequently use e-mail to exchange very large files. Because this site requires the ability to transfer large file over the WAN, moving the Exchange server out of the Denver site and into a central site is not feasible. Therefore, Proseware, Inc. decides to retain an Exchange server in the Denver office. They will upgrade the server from Exchange 5.5 to Exchange 2003.

After they determine which sites to consolidate, Proseware, Inc. creates a site consolidation plan. They determine the timing of the transition for each regional office. Because of the network latency that replication causes, they decide to schedule their public folder and mailbox moves for the weekends, when network activity is at its lowest.

Before they begin the site consolidation process, Proseware, Inc. deploys Exchange 2003 in the Seattle datacenter to ensure that Exchange is running in mixed mode. Specifically, they use the steps and tools in the Exchange Server Deployment Tools to deploy the first Exchange 2003 server and establish coexistence between Exchange 5.5 and Exchange 2003.

Because they want to use Cached Exchange Mode, Proseware, Inc. also upgrades all client computers in all four regional offices to Outlook 2003. They turn on Cached Exchange Mode to create a local copy of each user's mailbox. By creating the local copy before moving mailboxes, Proseware, Inc. avoids the heavy download traffic that would have occurred after moving mailboxes out of the local site.

Finally, before they begin the actual site consolidation process, Proseware, Inc. runs through the process with test mailboxes. The test allows them to validate the process and gather data about network impact and replication duration.

Phase 1: Preparing for Site Consolidation

Proseware, Inc. begins the site consolidation process for the Phoenix office, which is the first to be consolidated. They perform the following steps, as outlined in the Exchange Server Deployment Tools:

  1. Proseware, Inc. ensures that all ADC servers are updated to the Exchange 2003 SP1 version of ADC. Then they use ADCTools to validate that all ADC connection agreements are correctly configured.

  2. Proseware, Inc. updates all Exchange 5.5 public folder servers in all four regional offices with the DS/IS consistency adjuster hotfix.

  3. On Friday evening, Proseware, Inc. uses PFMigrate to add public folder replicas to the Exchange 2003 server in Seattle. They allow replication to continue over the weekend.

Phase 2: Consolidating Sites in Exchange Mixed Mode

After Proseware, Inc. confirms that public folder replication is complete, they continue consolidating the Phoenix site. Because moving mailboxes and using the Object Rehome tool can result in lengthy waiting periods, they decide to run this phase over the weekend. They use the Exchange Server Deployment Tools to perform the following steps:

  1. Proseware, Inc. uses the Move Mailbox Wizard to move mailboxes from Phoenix to the central site.

  2. Proseware, Inc. creates a logon script that will run Exprofre.exe when users log on Monday morning. This script will update users' Outlook profiles so that they reflect the new site.

  3. Proseware, Inc. runs ADC Tools again to verify that the proper connection agreements are set up. They ensure that directory replication is complete.

  4. They use the Object Rehome tool to update the custom recipients and distribution lists in Phoenix to reflect the Seattle site.

  5. After the Object Rehome tool finishes, they run ADC Tools again to verify that the proper connection agreements are set up. They ensure that directory replication is complete.

  6. On the Exchange 5.5 server in Phoenix, they run the DS/IS consistency adjuster to clean up public folder ACLs.

Phase 3: Removing the Remote Site

After Phase 2 is complete, Proseware, Inc. ensures that all Exchange data is represented on the Exchange 2003 server in Seattle. Then they retire the Exchange server in Phoenix. They use the Exchange Server Deployment Tools to perform the following steps:

  1. Proseware, Inc. runs PFMigrate to remove public folder replicas from the Phoenix site.

  2. Proseware, Inc. uses ADC Tools to verify that the proper connection agreements are set up. They ensure that public folder replication is complete.

  3. Proseware, Inc. uses the Object Rehome tool to generate a report to ensure that the distribution lists and custom recipients were successfully removed from the server in Phoenix.

  4. Proseware, Inc. follows the steps for removing the Exchange 5.5 server from the Phoenix regional office.

Proseware, Inc. repeats the same process for the Los Angeles and Miami regional offices. After they finish, Proseware, Inc. has an Exchange 2003 server in Seattle that hosts users in Phoenix, Los Angeles, and Miami, and they have an Exchange 2003 server in Denver that hosts those users locally. Finally, because they are no longer running Exchange 5.5, Proseware, Inc. switches to native mode.