One of Microsoft's newest introductions for 2007 is Exchange Server 2007. If you currently have Exchange Server 2003 running on your network, you might be in for some surprises when you upgrade to the latest version. In this article, I will explain what's involved in making the move from Exchange Server 2003 to Exchange Server 2007.
Plan on buying new hardware
If you're making the move to Exchange Server 2007, plan on purchasing new server hardware. Exchange Server 2007 does not support in-place upgrades. You can't just insert an Exchange 2007 installation CD into an Exchange 2003 server and expect it to install. Instead, you will have to install Exchange Server 2007 on a brand new server, and then migrate mailboxes and public folders to it.
You can't perform an in-place upgrade because Exchange Server 2007 will only run on a server that has a 64-bit processor and a 64-bit operating system. Exchange Server 2003 will run on 64-bit hardware, but only if it is running a 32-bit operating system. This difference in required operating systems makes an in-place upgrade impossible.
In case you are wondering, Microsoft's decision to require a 64-bit operating system for Exchange Server 2007 has to do with memory. Over the last few years, the average size of an Exchange database has grown exponentially. In fact, Exchange Server 2003 standard edition used to have a maximum database size of 16 GB; but Microsoft increased the size limit to 75 GB in one of the service packs because of the way that database sizes were growing.
This rapid database growth has been fueled by several factors. One factor is e-mail retention legislation. Many companies are now required to keep e-mail messages that would previously have been deleted. Another factor is the widespread availability of high-speed Internet connections. Suddenly, it isn't a big deal to send an e-mail message containing a 10 MB attachment. Of course spam also contributes to Exchange Server database growth.
Whatever the reason, there's no arguing that on average, Exchange databases have been growing exponentially. The problem is that the larger an Exchange database, the more memory required to keep the database performing well. 32-bit operating systems are limited to a maximum address space size of 4 GB. The Windows operating system claims 2 GB of address space, leaving 2 GB for user mode processes (in this case, Exchange Server).
Many large companies have been struggling with the 4-GB address space limit for some time. You can use the /3GB switch in the Boot.ini file to allocate more memory to user mode processes; but doing so decreases the number of available Page Table Entries, and that can cause problems of its own. Making the move to a 64-bit environment makes perfect sense for Exchange Server, because 64-bit operating systems are not subject to the 4-GB address space limit.
As you ponder a migration to Exchange Server 2007, keep in mind that you may not have to replace all of your server hardware. Most new servers include 64-bit processors that are capable of running 32-bit code. If you have these types of servers running Exchange Server 2003, then you can perform a rolling migration.
Imagine you had three servers running Exchange Server 2003, and each of those servers met the recommended hardware requirements for Exchange Server 2007. Rather than buying three new servers, you could get away with buying one new server. You would install Exchange Server 2007 onto the new server and then migrate the contents of one of your Exchange 2003 servers to it. When the migration is complete, you can reformat the Exchange 2003 server that has been migrated. You would then install a 64-bit Windows Server operating system and Exchange Server 2007 onto that server, and migrate the contents of your next Exchange 2003 server. When you finish migrating all three servers, you will be left with one remaining server that you can use for whatever you want.
Earlier I mentioned that 64-bit operating systems have a much larger memory address space than their 32-bit counterparts, and that this larger address space facilitates the creation of larger Exchange databases. Exchange Server 2003 Enterprise Edition did not impose a database size limit, but there was a practical limit to the size to which a database could grow that was based on hardware constraints. These constraints have all but vanished from Exchange in Exchange Server 2007, allowing you the freedom to create some truly massive databases.
Assuming that you have the disk infrastructure and backup hardware to support such a database, then one option is to consolidate all of your Exchange 2003 servers onto one or two Exchange 2007 servers. You will still have to purchase a new server, but consolidating all of your Exchange 2003 servers could save you a small fortune in Windows and Exchange license fees. Before you attempt a server consolidation, I would recommend that you use Microsoft's System Center Capacity Planner to test the impact that the planned consolidation would have on performance.
Preparing for a migration
I cannot possibly do any justice to the topic of planning an Exchange Server 2007 deployment in this article. I'll cover most of that in a completely separate article on the subject. What I will tell you is that before you install Exchange Server 2007, I recommend planning how the new server will fit into your existing Exchange infrastructure. You also need to have a rollback strategy in place in case something goes wrong during the deployment.
The biggest thing to keep in mind is that Exchange Server 2007 modifies the Active Directory schema during installation. Therefore, I recommend making a full system backup of your domain controllers prior to installing Exchange. Then you have something to fall back on if the schema update should crash and corrupt your Active Directory.
Now that the preparation work is complete, it's time to begin migrating user mailboxes from the Exchange 2003 server to your new Exchange 2007 server. Migrating mailboxes is simple: go to your Exchange 2007 server and open the Exchange Management Console. When the console opens, navigate through the console tree to Recipient Configuration | Mailbox. When you do, the console's detail pane will display a list of every mailbox in the entire Exchange Server organization.
In larger organizations with multiple mailbox servers, you probably don't want to see a unified view of all of the mailboxes across all of the servers. You can create a filtered view that will display only the mailboxes residing on the server you want to migrate.
Select Create Filter from the top of the screen. A series of drop-down lists will appear at the top of the console; these lists allow you to enter a condition for which you want the list of recipients to be sorted. Since our goal is to migrate all of the mailboxes from a specific server, let's filter the recipient list so that only recipients with mailboxes on that server are shown. Select the Server option from the first drop-down list and leave the second drop-down list set to Equals. Select Browse; you should see a list of all of your organization's Exchange servers. Choose the server that you want to migrate and press OK. Select Apply Filter and the list will be filtered to display only recipients with mailboxes on the selected server.
Now that the list has been filtered, it's time to move the mailboxes. You can move all of the mailboxes at once, but I recommend moving a couple of mailboxes individually first so you can make sure that the migration process is working correctly. If you are concerned about the integrity of your user's mailboxes, you could always create a few sample mailboxes and fill them up with junk mail as a way of testing the migration process before you attempt to migrate live data.
To migrate a mailbox, right-click on the mailbox and select the Move Mailbox command from the resulting shortcut menu. Exchange will launch the Move Mailbox wizard; its initial screen prompts you to select a server, storage group, and database as the destination that you want to move the mailbox to.
Select Next and you will see a screen asking you what you want to do if corrupt messages are found within the mailbox. You have the option of either skipping the mailbox or skipping the corrupt messages. If you choose to skip the corrupt messages, then you have the option of specifying the maximum number of messages to skip before the migration is aborted.
Select Next and you will see a screen asking you when you would like for the mailbox to be moved. The default option is to move the mailbox immediately, but you can schedule the move for another time. Scheduling the migration is useful if you are afraid of disrupting user productivity or disrupting the nightly backup.
In regards to scheduling, it may be impractical to try to move all of the mailboxes at once. For example, if you try to migrate all of the messages at once, the migration process might take too long and would be disruptive to the users. If you are worried about the amount of time that the migration will take to complete, you can schedule the migration so only a few mailboxes are migrated at a time. You don't have to set the schedule individually for each mailbox; select multiple mailboxes by pressing [Ctrl] and clicking on the mailboxes you want to move. When you right-click on the selected mailboxes, you will have the option of moving the selected mailboxes collectively as a group.
After setting the migration schedule, click Next and you will see a summary of the migration options that you have chosen. As you look over the summary, pay particular attention to the number of mailboxes to be moved. Otherwise you could be in for a nasty surprise if you accidentally selected the wrong mailboxes.
If the summary looks good, select Move to move the mailboxes. When the move completes, select Finish to close the wizard.
Linking users to their mailboxes
If you have ever installed Microsoft Outlook for your users, then you know the initial setup process requires you to tell Outlook the user is connecting to an Exchange mailbox. After doing so, you must enter the user's name and the name of the Exchange server containing the user's mailbox.
The problem with this is that after you move a user's mailbox to a different server, Outlook will be pointed to an incorrect mailbox location. To get around this problem, I recommend deploying Outlook 2007 to all of your users prior to deploying Exchange Server 2007. My primary reason for making this recommendation is that Outlook 2007 is self-configuring when installed in an Exchange Server environment. Rather than requiring you to manually enter the user's name and the name of the Exchange Server containing the user's mailbox, Outlook 2007 automatically extracts the necessary information from Active Directory. If you deploy Outlook 2007 in advance, mailbox migrations should be semi-transparent to your users.
As you can see, deploying Exchange Server