If you simply want to do an in-place upgrade of Exchange 2000 to Exchange 2003 using the same server, you’ve got it made – Microsoft has explained the process of upgrading and made it pretty simple. Even if you’re still using Exchange v5.5, Microsoft has you covered with a wealth of documentation to peruse. But what if you’re an Exchange 2000 organization that wants to bring in a new Exchange 2003 system alongside your existing machine, move all your content over to it, and decommission the original box?  Then you’re left scratching your head. At the time of this writing, there is no guide I’ve been able to find that explains the process with any detail.

This document will explain the process, combining information from numerous sources as well as my own experience. It’s very easy to bring Exchange Server 2003 into your Exchange 2000 organization, with minimal disruption to your existing server or your users. This document assumes you have an Exchange 2000 organization running in native mode.

Henceforth, the Exchange 2000 system will be referred to as the “old” server, and the Exchange 2003 system will be referred to as the “new” server.

I. Prepare your Network for Windows Server 2003

Regardless of how you intend to get to Exchange 2003, there are some basic steps that must be done.

1. Begin by reviewing Microsoft’s 314649 – “Windows Server 2003 adprep /forestprep Command Causes Mangled Attributes in Windows 2000 Forests That Contain Exchange 2000 Servers” This article explains that if you have Exchange 2000 installed in your organization, and you proceed with installing your first Windows Server 2003 system (and its accompanying schema modifications), you may end up with some mangled attributes in AD. Preventing this from happening is simple enough: a script called Inetorgpersonfix.ldf will do the trick.
2. Run adprep /forestprep from Windows Server 2003 CD on your Windows 2000 server that holds the Schema master FSMO role. (Of course you’ll need to be a member of Schema Admins).  Be sure to replicate the changes throughout the forest before proceeding.
3. Run adprep /domainprep from Windows Server 2003 CD on your Windows 2000 server. I ran it on the system holding the PDC Emulator FSMO role.
4. Before bringing a new Windows Server 2003 system online, it’s a good idea to review your third-party server utilities and upgrade them to the latest versions to ensure compatibility. In my installation, this included the latest versions of BackupExec, Symantec Antivirus Corp. Edition, and Diskeeper.
5. Run setup /forestprep from the Exchange Server 2003 CD on the Windows 2000 server that holds the Schema master FSMO role.  Replicate the changes throughout the forest.
6. Run setup /domainprep from the Exchange Server 2003 CD on a Windows 2000 server. Again, I ran it on the system holding the PDC Emulator role.

II. Install Windows Server 2003

1. Install Windows Server 2003 on the new server, join it to the domain, then apply all hotfixes to the server to bring it up to date.
2. In AD, move the server object to the desired OU.
3. If you’re paranoid like me, you may be tempted to install antivirus (AV) software on your new server at the earliest opportunity. Hold off on that for now.
4. Review Microsoft’s 815372 – “How to optimize memory usage in Exchange Server 2003” which explains a number of settings required for Exchange Server 2003. Specifically, you may need to add the /3GB and /userva=3030 switches to boot.ini, or you will have event 9665 in the event log.  I also had to change the HeapDeCommitFreeBlockThreshold value in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ to 0x00040000 as directed in the article.
5. Review Microsoft’s 831464 – “FIX: IIS 6.0 compression corruption causes access violations”. I obtained the fix from Microsoft, and you should do the same, as it fixes some nasties that may interfere with OWA.

III. Install Exchange Server 2003

1. If you have installed any AV software on the new server, stop all AV-related services now, or you may experience a failed Exchange installation as I did.
2. Download the latest copy of the Exchange Server 2003 Deployment Tools, version 06.05.7226 as of this writing.
3. To begin the Exchange Server 2003 install on your new server, run Exdeploy.hta after extracting the tools.
4. Choose “Deploy the First Exchange 2003 Server”
5. You’ll want to choose the item for your current environment, which in the context of this article is “You are running Exchange 2000 in native mode and you want to upgrade a server or install the first new Exchange 2003 server.” Choose “Upgrade from Exchange 2000 Native Mode”.
6. Run through the entire checklist and perform all the steps and tests. When you get to Step 9 in Exdeploy, you’ll need to specify the path to the Exchange Server 2003 CD since you’re running Exdeploy from a location other than the CD.
7. Install all the Exchange components unless you have a compelling need to do otherwise.
8. When the install is completed, install Exchange Server 2003 Service Pack 1.
9. When SP1 is completed, run the Exchange System Manager from the Windows Server 2003 system, and you will see your new server listed in the Exchange organization, as well as your old server.
10. The POP3 and IMAP4 services aren’t set to start automatically, so configure them for Automatic startup if desired.
11. If you want to install or enable antivirus software, it’s now safe to do so.

IV. Get Familiar with Exchange Server 2003

At this point, you now have an Exchange 2003 system running in your existing Exchange organization.  Microsoft has done a good job of allowing the two versions to coexist.

Before proceeding with your migration, there are a number of important tasks to consider at this stage. For openers, communicate with your users about the migration if you haven’t already, brief them on the new OWA interface, and by all means ask them to go through their mailboxes and delete old, unneeded items. You’ll appreciate this later!

This is a good opportunity to spend some time reviewing your new Exchange server. Even if you spent time learning the new product in a lab environment (as you should have), exploring the system now before proceeding makes sense. Check out the new ESM, move a test mailbox to the new server, and try OWA. Go through your old server and take note of any settings you want to configure on the new system such as size limits on SMTP connectors or incoming/outgoing messages, etc. You’ll find that Exchange Server 2003 is configured to block mail relaying by default.

This is a good time to uninstall the Exchange 2000 version of the ESM remote management tools (using the Exchange 2000 Server CD, run Setup, choose Remove) on any management workstations and install the new Exchange 2003 ESM, which can be used to manage both versions of Exchange server.

As you test message routing, you will find that any email coming into your organization from the outside will be automatically routed to the appropriate Exchange server where the mailbox resides. My test mailbox on the new server could send and receive mail, no problem. I could also access the mailbox with Outlook or OWA from within the organization, no problem. However, I was unable to access mailboxes on the new server from outside the organization.

In my configuration, an ISA Server 2000 system acts as the firewall, where web and server publishing rules exist to redirect incoming traffic to the old mail server. There was no simple way I could find to allow simultaneous access to both the old and the new servers. All incoming mail-related traffic was directed to the old server. This limitation affected the rest of the migration as you will see.

Note:
There is a way to have multiple Exchange servers, both 2000 and 2003, behind a firewall, whereby mail is automatically directed to the appropriate server. This scenario involves installing Exchange Server 2003 on a server and configuring it as a “front end” server, which allows it to act as a proxy. Unfortunately, the front end server cannot hold any mailboxes on its own, so this isn’t an option in the migration scenario in this article.

Note:
For a front end server to make any sense, a minimum of three servers would be needed: the front end server itself, and at least two Exchange servers, to which the front end server would route messages, based on the mailboxes homed on each. In our migration scenario, one could have a front end server routing mail to the old Exchange 2000 server and the new Exchange 2003 server. As mailboxes are moved from the old to the new server, the front end server would route messages to the correct place. This is a nice option for those with the hardware and the desire to do a gradual transition.

V. Configure Exchange Server 2003 to Host Public folders and Other Roles

As you begin moving folders and roles to the new server, one thing I learned the hard way is that you should use the ESM running on the new server. I used the ESM on a Windows XP remote management workstation, and found that things reported on the workstations’s ESM weren’t always the same as the Exchange server’s ESM.

1. Review Microsoft’s 307917 – “XADM: How to Remove the First Exchange 2000 Server Computer from the Site”. This document contains most of what is needed to finish this migration, and explains in detail how to setup replication of Public folders.
2. Using the instructions in 307917 as a guide, setup replication for all public folders that were created by your organization on your old server. Do not setup replication for any folders you didn’t create, as several of these will not be brought over to the new server. When the folders you replicated are in sync, remove the old server from the replication tab. These folders now exist solely on the new server. They are accessible to those within your WAN, but are inaccessible outside your firewall.
3. You should find that the Public folders called default and ExchangeV1 are already replicated to the new server. Using Step 2 and 3 in 307917, setup replication to the new server for the folders Offline Address Book, OAB Version 2, and Schedule+ Free Busy Information. If you have a folder called Internet Newsgroups, you should replicate that also. This folder is created by the Exchange system, though your organization may not use it.
4. If you check the Properties, Replication tab on your administtrative group’s Folders node, you will see the replication interval for the public folders. Unless you specifically changed the interval on any individual public folders, they should follow this schedule. “Always run” means replication will run every 15 minutes. There is no “replicate now” option.

5. Using Step 4 & 5 in 307917, rehome RUS and designate the new server as the routing group master.
6. Step 6 and 7 in 307917 didn’t apply in my configuration; proceed with those as needed.
7. Using Microsoft’s 265293 – “How to Configure the SMTP Connector in Exchange”, add the new server to the SMTP connector, remove the old server, then cycle the MS Exchange Routing Engine service and the SMTP service for these changes to take effect. Send a test message to verify the new server is sending the mail now.
8. There are a number of public folders on the Exchange 2000 server that do not need to be replicated and moved to the new server, including several that are part of the Exchange 2000 version of OWA. On my system these included:

• Controls
• Event Config_<old server name>
• Events Root
• Exchweb
• Img
• Microsoft
• Offline Address Book – First Administrative Group
• Schema-root
• Views

Just leave these folders on the old server.

At this point, with the exception that your public folders are no longer accessible outside your firewall, there shouldn’t be any noticable difference to your users. You can accomplish all of the above during normal working hours without much fuss. However, the next step isn’t as transparent.

VI. Move the Mailboxes to Exchange Server 2003

This is the moment we’ve all been waiting for, and it’s pretty straightforward. In order for this process to go as smoothly as possible, you should make sure that no users inside your organization are accessing the email system. You should also block all external access to your mail servers.

1. You can read a detailed description of moving mailboxes, see Henrik Walther’s “Moving Mailboxes with the Exchange 2003 Move Mailbox Wizard”  article for specifics.
2. Prevent outside access to your mail servers. In my case, this involved disabling the web and server publishing rules for IMAP4, POP3, and SMTP in my ISA Server 2000 system.
3. Make sure no internal users are accessing the mail server.
4. Turn off AV on both the old and the new server. Moving mailboxes is a time-consuming, resource-intensive process. AV scanning will slow this process down, and in some cases can cause problems when large scale data is being moved.
5. The Move Mailbox Wizard will allow you to select many mailboxes at a time, but it will only process four at a time. I chose the “Create a failure report” option, which won’t move the mailbox if there are errors. I moved 75 mailboxes, 1.7GB of data, in 70 minutes, without a single error.
6. The key determining factor in the speed of the mailbox move process isn’t so much size as it is the number of items in a mailbox. If your users deleted a lot of items per your request, the process will go a lot quicker now.
7. If you want to test your new system before moving all the mailboxes, you can move a handful of them, then turn on outside access (I would turn on AV as well). Keep in mind, you’ll need to configure your firewall to point to the new mail server. You should be able to access the new mailboxes with OWA and POP3 mail applications like Outlook. You can also test access to Public folders in OWA if desired. Be sure to disable external access and AV before proceeding.
8. Move all the mailboxes, except SystemMailbox, System Attendant, and SMTP-ServerName, as these should already exist on the new server.
9. When the process is finished, configure your firewall to point to the new mail server, turn on AV, and enable external access. You are now running an Exchange Server 2003 mail system.

VII. Final Cleanup

1. Go through the public folders on the new server and remove the old server from the replication tab for any public folders that are still replicating to it. On my system this included default and ExchangeV1.
2. Have your clients logon to their email clients. Outlook will attempt to connect to the old mail server, but as long as the Exchange services are still running on it, it will automatically redirect Outlook to the new server.
3. Stop all the Exchange services on the old server. Stop IISAdmin, which should stop FTP, NNTP, SMTP, and WWW.
4. Your old server will still appear in the Exchange organization in the ESM, but that’s OK for now.  You may also see an entry in the Queues node on the new server, destined for the old server. You can ignore this also.
5. Allow your new server for run for a few days if desired, keeping the old system in its present state for the time being. You may even want to turn it off.
6. When you’re satisfied that the migration is a success and the old server is no longer needed, insert the Exchange 2000 Server CD into the old server, run setup, and remove/uninstall Exchange 2000. Make sure the server is still connected to the network when you do this, as this process will remove the old server from the ESM.

Congratulations! Because you began with an Exchange 2000 organization in native mode, your Exchange Server 2003 system is in native mode. Your migration is finished.

It is very important for any administrator to know how to backup and restore Exchange correctly.  Backing up your Exchange server using the correct steps not only secures your data but also purges the transaction log files that Exchange uses.

In this article we are going to walk through the steps you would need to take to successfully backup your Exchange databases.  We shall look at how to restore the information from a backup in a separate article.

Microsoft Windows 2000 comes with a utility that enables you to backup data and System State* information on that server.  When you install Exchange 2000 onto the server, the Windows 2000 Backup utility is updated to support backing up and restoring Exchange data.  The backup program now becomes “Exchange aware”.

Before we look at the way in which we backup Exchange, let’s quickly refresh on the architecture.  Within Exchange we have: Storage Groups, inside the Storage Group we have Stores.  Inside the Stores we then have either mailboxes or Public Folders.

Exchange 2000 Standard only has the ability to support one (1) Storage Group which can contain one (1) mailbox store and one (1) Public Folder store.

Exchange 2000 Enterprise can have up to four (4) Storage Groups and each Storage Group can support up to five (5) stores (either mailbox or Public Folder).

For each Storage Group in Exchange we have a corresponding set of Transaction Log files, these log files are extremely important and should never be deleted manually.  The log files are 5Mb in size and your server can generate a large number of log files based on how many transactions it processes.  The log files are used in the event that we need to perform a restore of the databases.

Backing Up Exchange 2000

As I mentioned earlier your server will have the Windows 2000 Backup utility already installed and because you have installed Exchange on the server the backup utility will now be “Exchange aware” and capable of purging the log files and backing up the databases whilst they are in use.  You don’t have to stop any of the Exchange services when you are performing a backup.  If you do stop the services you will be performing an “Offline” backup and this is not recommended because the services need to be running to purge the log files correctly.

1.   Open the Windows 2000 Backup utility, Start > Programs > Accessories > System Tools and select Backup

2.   Select the Backup tab

3.   Open the Microsoft Exchange Server list and expand the server that you want to backup.

If you want to backup the whole of the Information Store on the selected server you can simply check the box next to “Microsoft Information Store” or you can expand the “Microsoft Information Store” and select a particular Storage Group.

It is recommended that you backup a complete Storage Group, rather than the individual Stores, that way all the committed transaction log files will be purged.  In the event that you need to backup an individual store you can simply click on the Storage Group name and select the Store you would like to backup from the right-hand pane.

 4.    Once you have made your selection of what you want to backup the next step is to configure where we want to backup the selection to.  This could be to tape, to another hard disk, to a CD-RW or even to floppy disks if you have about 600 hanging around.  To select the backup location using the “Backup media or file name” option at the bottom of the page.  For this example I have selected to backup to my G: and use a filename of backup.bkf.

5.    When you are ready to start the backup, click on the Start Backup button.  The “Backup Job Information” dialogue box will now be displayed, click on the Advanced button and ensure the Backup type is set to “Normal”.

6.   If we now proceed and click on the Start Backup button, the backup will launch and the information we selected will be backed-up to the location we specified.  Once the backup is complete you will receive the “Backup Progress” dialogue box.

7.   When your backup is complete, it is very important to review the backup report to ensure that everything went through OK - what’s the point of doing a backup only to find its no use when you need it!  To review the backup report, click on the Report button in the “Backup Progress” dialogue box.

The above procedure discusses the way in which you should be backing up your Exchange Information Store using the built-in Windows 2000 Backup program on your Exchange server, but you also need to ensure you backup other critical information as well, backing up the System State and the IIS Metabase is as important as backing up the Information Store data.

You should ensure that you backup the System State on all of your Domain Controllers and your Exchange server regularly, I back mine up nightly as part of my normal backup routine.

Here are a few links to documents that I would recommend you read through to ensure you fully understand the backup/restore procedure for Exchange 2000 and Domain Controllers:

List of Approved Backup and AntiVirus Solutions for Exchange
http://support.microsoft.com/default.aspx?scid=kb;en-us;320724

Backing Up the IIS Metabase
http://support.microsoft.com/default.aspx?scid=kb;en-us;241635

How to Backup and Restore the Windows 2000 System State
http://support.microsoft.com/default.aspx?scid=kb;en-us;240363

How to Backup the System State of a Remote Machine
http://support.microsoft.com/default.aspx?scid=kb;en-us;315412

Disaster Recovery for Exchange 2000 (a MUST read)
http://support.microsoft.com/default.aspx?scid=kb;en-us;326052

Microsoft WebCast: Disaster Recovery for Exchange
http://support.microsoft.com/default.aspx?scid=kb;en-us;325152

So it’s as simple as that!  In my next article we shall look at how to restore data from our backup in different scenario’s, but in the meantime backup, live long and prosper.

* System State data includes the registry, the COM+ Class Registration database and the system boot files.  If the server is a Certificate Server then the Certificate Server database is also included in the System State.  If the server is a Domain Controller then the System State will also include the SYSVOL directory and the Active Directory database.

If you would like us to email you when Mark Fugatt releases another article on MSExchange.org, subscribe to our 'Real-Time Article Update' by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!