DataBus, Volume 41, No. 2-Ten Steps to Exchange 2000 Server: Migrating the Othello, Washington, School District Way

DataBus - Vol 41 No. 2: February-March, 2001

Ten Steps to Exchange 2000 Server: Migrating the Othello, Washington, School District Way

Tuan Nguyen, Microsoft Corporation

So, your school, district or campus has decided to migrate from Microsoft® Exchange Server 5.5 to Exchange 2000 Server. Now, how will you do it?

Microsoft provides extensive documentation to help you make the move from Exchange Server 5.5 to Exchange 2000 Server, including the Microsoft Exchange 2000 Deployment Guide at http://www.microsoft.com/exchange/ and the Microsoft Exchange 2000 Server Upgrade Series at http://www.microsoft.com/technet/exchange/guide/default.asp. These resources detail the steps, tools and considerations you need to know as you plan and implement your migration.

But few migrations follow the "textbook" line by line. Each environment is different. Goals are different. User needs are different. And so deployments, inevitably, are different. To give you greater insight into the migration process, this document follows the actual step-by-step migration process adopted by the Othello, Washington School District in migrating to Exchange 2000 Server last year. The Othello experience can give you insights and inspiration for the customized process of your own deployment.

Background on Othello

The Othello School District in eastern Washington state is typical of many school districts around the country. It is small (population: 5,000), rural, with five schools, two maintenance facilities and an administrative center. Last year, its two-person technology staff was strapped managing the fiber-optic network with nearly 1,000 PCs and seven servers, funded by the federal E-rate program and by the community's 1997 passage of a $3.9 million dollar technology bond levy. As if that wasn't enough, each classroom would be upgraded to support four PCs and eventually include 14 labs. With maintenance issues already taking at least two hours a day, Network specialist Russ Beard knew that a major change was needed to make the management challenge practical.

For Beard and the Othello School District, that change was an upgrade from Windows NT® 4.0 and Exchange Server 5.5 to Windows® 2000 Server and Exchange 2000 Server. The software promised to enable greater centralized management, security, and simplified use, leading to higher productivity and lower total cost of ownership for the district.

"When we were in the planning stages of our migration to Windows 2000, we had discussions with Microsoft about continuing to run Exchange Server 5.5 versus Exchange 2000 Server," recalls Beard. "Compared to Exchange 5.5, Exchange 2000 promised seamless integration with Windows 2000 Active Directory™ service, which is what I was personally looking for to help reduce the management burden. It would be easy to extend the schema to the global catalog and to run Exchange from the snap-in in the management console. This easy use was crucial to freeing up scant staff resources."

Prolog: Testing and Planning for Exchange 2000

But would the reality meet the promise? In spring 2000, Beard took a close look at Exchange Server Release Candidate 1 and built his own test server using RC2.

"I was impressed with the results," says Beard. "The installation in the test lab was very smooth and I was impressed with how easy it was to run and to integrate the Release Candidate into Active Directory. However, I've never found that a test lab experience pans out exactly the same in real life. I did a larger mock environment in which I put everything on a single server, to test DNS, how the global catalog would transmit across multiple servers, and so on. I did the installation twice, reformatted and did it again, then attached a couple of clients."

With this actual hands-on experience with RC2, Beard was comfortable making Exchange 2000 Server a part of his broader migration plan. As a conservative approach to minimize the potential for problems, he decided not to migrate Windows Server 2000 and Exchange 2000 Server at once. Rather, he would complete the operating system upgrade and then, when he was confident that it was operating successfully, he would move the district onto the Exchange Server upgrade as a second step.

Beard continued his testing of Exchange 2000 Server into summer 2000. He put together a plan and budget for the district administration, one that would restructure the network in an important way. Previously, the server for each school hosted all functions for that school -- file storage, applications, data, and so on. To take maximum advantage of Windows 2000 in general and Exchange 2000 Server in particular, Beard would bring the servers offline -- maintaining a skeletal, two-server Windows NT network in the interim -- and restore each in a Windows 2000 domain as a single-function server, including one server dedicated to Exchange 2000 Server, thereby optimizing bandwidth and performance on the network.

One key consideration for Beard was whether or not to preserve the existing mail messages, calendars, address books, and other data of his users contained in the Exchange Server 5.5 information store. Although the "move mailbox" migration method outlines a way to permit this, Beard decided on a clean, out-of-the-box installation of Exchange 2000 Server coupled with specific instructions to his users to enable them to backup and restore important personal information such as addresses and calendars. Beard regarded this as an expedient choice given his limited time and resources.

Beard completed the Windows 2000 migration during summer 2000 (see Othello, Washington School District Migrates to Windows 2000 To Gain Benefits of Manageability, Security on the TechNet for Education web site at http://www.microsoft.com/technet/education/othelfin.asp). As a last step before students and teachers returned in the fall, he completed the Exchange 2000 Server upgrade as well.

Step 1: Backing Up Mailboxes

The migration to Windows 2000 and, subsequently, Exchange 2000 Server, would take place over the summer. However, the first step in the migration to Exchange 2000 Server actually preceded this. To ensure that all users would retain the address book and calendar information in their Outlook® messaging and collaboration client files, Beard gave them instructions on how to preserve this information in June, before many employees left for the summer.

To make this step simple for users, Beard directed them to the "Export to PST File" Wizard in Outlook. Its import/export command allows users to specify the location for backup and provides a local hard drive location as the default. This was ideal for the Othello migration, since users were generally retaining their existing desktop PCs. Beard also directed users to name the file with their own name and the .PST extension -- such as Russ.pst. By clicking on the top of the Outlook tree displayed in the Wizard, users could choose to "include all subfolders" to maintain their full personal contact and calendar data. To streamline the process, Beard also encouraged users to first empty their deleted and sent mail items and to clean out unneeded messages and files prior to the backup.

"I've seen users backing up 40MBs of data or more," says Beard. "With all users doing this at the same time, it can affect network bandwidth. Encouraging users to delete unnecessary files first can help mitigate this concern."

Step Two: Work from a Successful Deployment of Windows 2000 Server

After completing his migration to Windows 2000 -- including creation of a new, single-domain forest -- Beard was ready to begin the migration to Exchange 2000 Server. He was now running a stable Windows 2000 network in native mode.

Earlier, he had upgraded his server hardware from Intel Pentium IIs to AMD/Athlon processors and from an average of 250 MB RAM to full 1GB RAM. The upgrades cost an average of $2,500 per machine -- which Beard considers a "bare bones budget" price for the school district, making the upgrade to Windows 2000 and Exchange 2000 Server both feasible and worthwhile. It was one of these upgraded boxes that Beard used for the Exchange migration.

Beard prepared his proposed mail server by loading it with Windows 2000 Advanced Server SP1. He joined it to the existing Windows 2000 domain by right clicking on My Computer, selecting properties, and then choosing the Network ID tab. On the face of this applet he clicked the button properties, and made sure to have the proper computer name in the appropriate space. In the box for domain, he entered the name of the new domain. Then he entered a user name and password with Administrative privileges. The system welcomed him to the new domain and he rebooted the computer. At this point, the server needed no further configuration.

Step Three: Prepare the Domain Controller

Beard turned his attention back to his existing Windows 2000 domain controller, confirming that both DNS and DHCP were configured and running. To do so, he found it helpful to build a control console. He went to Start/Run, entered "mmc" and hit enter. The Microsoft Management Console opened and he built a console by going to Console and clicking Add/Remove Snap-ins. He clicked the Add button and selected the snap-ins that he needed. With the console built, he saved it to a convenient location. From the console he had two ways to check the DNS and DHCP servers: simply looking at their activity or by going to the Services Module. Some districts may be like those in Othello's Washington state, which generally don't do their own DNS work and rely on the state network for this service. If so, now is the time to begin to manage DNS locally, according to Beard.

The Othello School District management console in Windows 2000

"Windows 2000 relies on DNS for so many things so it's critical to set it up right," says Beard. "DNS is also extremely critical in how Exchange 2000 works because it handles all the name translation. For example, DNS is what identifies to the world that this server works for Othello. It gives an IP number to the domain name, Othello.wednet.edu. DNS has a mystique but it isn't rocket science."

Beard then began populating his user accounts on the Windows 2000 server, a procedure he says is not mandatory, but which he recommends because it then makes it easier to set up the new mailboxes once Exchange 2000 is loaded and extended into the Windows 2000 schema. To do so, he used a third-party "Add Users" Utility from the Windows 2000 Resource Kit, which brought the user accounts in from Windows NT to Windows 2000 in a CSV file. This tool is the same one that can be used in migrating accounts within a Windows NT 4.0 network.

Beard points out that the User Migration Wizard is also an ideal way to accomplish the migration of users from an old Windows NT domain to a new Windows 2000 domain and that this Wizard has worked well for him also. The caveat is that the domain must already be functioning in native mode to use the Wizard, which doesn't function in mixed mode networks.

A crucial, final aspect of preparing the domain controller was to make sure that Internet Information Services built into Windows 2000 (IIS) was set up and running on at least one machine in the domain. To do this, he added the IIS snap-in to the control console and then double-clicked the IIS tree. This was important, says Beard, because SMTP -- a necessary mail protocol -- wouldn't work without IIS being active. Beard also confirmed that another necessary service, the remote procedure service (RPS), was installed and running.

"Exchange 2000 Server requires a number of services to be up and running on the domain, such as DNS, Active Directory, RDS, RPS, IIS," says Beard. "But the neat thing about the installation of Exchange 2000 Server is that you can't make a mistake. As Exchange installs on the server, it will look for these services and, if they're not there, active and configured, Exchange will stop the install process and tell you that it can't continue for this reason. I have to say that this aspect of the installation works very well."

Step Four: Using ForestPrep to Extend the Schema

The Windows 2000 Active Directory service schema must be extended to support the diverse attributes in a messaging application directory. Exchange 2000 extends Active Directory with new Exchange attributes, allowing users, groups and contact objects in Active Directory to become mail recipients. Existing Active Directory attributes are also modified, some of which affect what Outlook users see in the global address list. The schema is extended only once. Beard chose to extend the Othello schema by using the ForestPrep utility located on the Exchange Server CD-ROM. ForestPrep prepares the Windows 2000 forest for Exchange. It prompts for and creates the Exchange organization name and object in Active Directory, building the initial Exchange organization structure. When Exchange is then installed, Setup can then query Active Directory for configuration information. ForestPrep also assigns Exchange full administrator permissions for the specified administrator account.

ForestPrep was separated from Exchange 2000 Setup because Setup must perform operations that require permissions of an Enterprise Administrator and Schema Administrator and -- although this wasn't an issue for the relatively small Othello -- much larger enterprises may not be comfortable providing this level of permissions to Exchange administrators. In other words, the set of permissions required for Exchange installation are of a higher level than the set required in production. So, in enterprises with larger staffs and greater divisions of responsibility, ForestPrep is run by the Windows 2000 Enterprise Administrator as a separate, preliminary setup function.

In Beard's case, because he had responsibility both for deploying Exchange and also for modifying Active Directory schema, and because he had only one Windows 2000 domain, he could have chosen to run ForestPrep (and DomainPrep) as part of Exchange Setup. In fact, when he ran ForestPrep separately, a dialog box told him that, because he had only one forest and one domain, he did not need to run the utility. Nevertheless, Beard chose to run it and says he found it part of a "flawless" installation.

"I found it a good procedure to extend the schema this way prior to loading Exchange," says Beard. "It helped ensure that there were no hiccups in loading files later on in the process. It may not be necessary but it won't hurt anything and I believe it made my installation go smoother."

Step Five: Using DomainPrep

Beard next ran DomainPrep on the server.

DomanPrep is analogous to ForestPrep (see Step Four) and prepares the domain for Exchange 2000 Server much as ForestPrep prepares the forest for the new email software. DomainPrep creates two security groups in each Windows 2000 domain in which it is run. Together, the groups provide permissions to Exchange servers, so that the servers can perform tasks such as modifying Exchange user attributes. A Windows 2000 domain administrator must run DomainPrep in any domain where Universal Security Groups (USGs) will be installed, where mail-enabled users will reside, or where, as in this case, an Exchange Server will be installed.

DomainPrep creates and configures permission for the groups in the following table:

Group	Function	How populated	Permissions
Exchange Domain Servers	A global security group that lists the machine 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 the Exchange System Manager.
All Exchange Servers	A domain local security group that contains all Exchange Domain Servers groups from all domains, used for granting access.	The RUS adds the Exchange Domain Servers groups from all other domains that have an active RUS.	It has Modify permissions on all Active Directory recipient objects.

In addition, Beard specified the Address List Server using DomainPrep. Since Exchange 2000, unlike Exchange Server 5.5, no longer has a directory of its own but uses Active Directory, address book lookups have changed. One ramification of this is the requirement to choose an address list server.

Because Beard was setting up a relatively small forest with a single domain, catalog replication was a concise process; for big forests with multiple domains, catalog replication could be time consuming, he warns.

Step Six: Install Exchange 2000 Server

With the server box now fully prepared and configured with Windows 2000, Beard was ready to install Exchange 2000 Server on it. The process of loading Exchange 2000 Server from the CD-ROM took about an hour for the complete installation that Beard used. Because Beard had used DomainPrep and ForestPrep, the work of loading and configuring the Exchange server itself was relatively straightforward.

"Installing Exchange 2000 Server isn't the same as installing Exchange Server 5.5," says Beard. "With 5.5 you're setting up the server to work with different domains, domain controllers, primary domain controller, and so on. With Exchange 2000 and Windows 2000, it's all one entity. One machine in the forest is the global catalog, where the schema resides and where Active Directory functions take place, regardless of whatever else you're running."

Installing Exchange 2000 Server on a new server, rather than directly upgrading the existing Exchange 5.5 server, had a key benefit for Beard and Othello. Beard could test and confirm the operation of the new server without affecting the older mail server or the users continuing to rely on it during the migration.

Step Seven: Reboot and Confirm DNS Pointing to Exchange

After installing Exchange 2000 Server, Beard rebooted both systems -- the Exchange 2000 Server and the Windows 2000 domain controller -- to confirm their proper operation.

"Microsoft talks about minimizing or eliminating the need to reboot and I don't know that their documentation recommends a reboot at this point, but I'm conservative about these things and it seemed like the right thing to do," says Beard.

Certainly, rebooting gave Beard a chance to see his two new servers come up together properly, giving him added confidence to continue with the installation procedure. His next step was to ensure that there was a DNS MX entry for the new Exchange 2000 Server. The MX (mail exchange unit) entry is the identification in the DNS table that directs mail entering the domain to the domain's mail server. The entry needed to be updated to reflect the Exchange 2000 Server, so that incoming mail could be processed by Exchange 2000 and reach its intended recipients.

To confirm the MX entry update, Beard went to the domain controller's management console, and chose the DNS level from the directory tree. This contains the root DNS records including the MX entry. Beard confirmed that the entry was pointing to the new domain and to the new Exchange 2000 Server.

Step Eight: Install Exchange System Management Tools

Beard now had his Exchange 2000 Server up and running with the DNS aware of the new server and prepared to point incoming mail to it. His next step was to install System Manager, the Exchange system management tools, into the domain controller management console. With System Manager, he would be able to manage the new server fully and effectively from a central location, just as if he were sitting in front of the server. He also chose to install Terminal Services so he could run the management tools remotely from any location -- in the field, at one of the schools, or even from his home.

To install the management tools, Beard chose Auto Run from the Exchange Server CD-ROM. Instead of choosing Typical Install, he changed the default to Install System Manager, responded to a few additional screens, and installed the software.

"With one console, Windows and Exchange allow me access to every management tool, so I can easily manage my entire server array," says Beard. "I even installed Terminal Services on my laptop. I dial-up from my laptop when I'm at home and I can administer the Exchange server from there. I'm using a basic 42K dialup connection and it works fine. I can't say enough about what Microsoft has done with these tools and Terminal Services."

Step Nine: Confirm Settings in the Exchange 2000 Server System Manager

With the Exchange System Manager installed, Beard next reviewed its settings to ensure that they were configured properly for the needs of the Othello domain. For example, System Manager enabled him to put limits on mailboxes, to reclaim deleted items from Outlook and to create tombstones. System Manager also enabled Beard to access the Information Store and Public Folders.

Beard confirmed and configured the System Manager settings by moving through the series of nodes in the directory tree (see Console diagram, above).

The first node, Global Settings, contains Internet message formats and Message delivery containers. It gave Beard the option to filter incoming mail.
The Recipients container node covers recipient policy, address book views, update services, and several templates. It supports separate address book views and policies for specific users.
The Administrative Group node is the heart of Exchange Server. Each server or groups of servers can be assigned administrative groups, for organizing recipients or balancing resources. A Servers node holds the container of each specific server. Under the server is the protocols folder as well as the Storage Groups. Inside Protocols are the specifications of all the protocol settings for the Exchange site. The Storage Group contains both the private information store and the public folder store. It allows the administrator to divide an organization into separate storage groups to impose separate policies and to provide enhanced security. This group also contains the Routing group folder and the folder listing all public folders created on the site.
The Tools node supports the Message Tracking Center, for tracking the use and efficiency of the Exchange site. It also supports the monitoring and status folder, which Beard used to build monitors to alert him to Exchange server problems.
The node for Active Directory, Users and Computers enables the addition or deletion of users to the site.

Step Ten: Restoring Client Data and Creating New Profiles

Now, Beard was ready to guide his end users through the process of removing their old, Exchange 5.5 server-based profiles from Outlook, to create new profiles for Exchange 2000 Server, and to restore the personal address book and calendar information that they backed up to their local hard drives at the start of the process.

To do this, Beard directed users to the Properties section of Outlook to delete the existing Profile. Users were then directed to Add New Profile, and to choose the Exchange 2000 Server for that Profile where the screen asked them for the new server name. Using Outlook, they also chose Import PST File to bring back their previously saved personal address and calendar information.

With the user profiles restored, users could now communicate with the new server, sending and receiving email, files, calendar data and other information. From the user perspective, the migration was complete and successful.

Beard was now able to take the old Exchange 5.5 Server and remaining Windows NT 4.0 domain controller off the skeletal, interim domain. Those machines were then refurbished and brought back into the new domain as Windows 2000 servers, completing the migration.

Tuan Nguyen is K-12 Education Marketing Manager for Microsoft Corporation's Southern California District. He may be reached by telephone at (310) 449-7408 or by e-mail at [email protected]