Migrating from Exchange Server 2003 to Exchange Server 2010: A Small Organization Perspective

In this article, you'll learn how to migrate your Exchange Server 2003 infrastructure (both  your front-end and back-end servers) to Exchange Server 2010. I'll focus on the requirements of smaller organizations, because the needs of larger organizations typically just scale up from there.

I was lucky enough that one of my partner companies, Clark Systems Support, allowed me to do their migration, and I based this article on my experience there.

Exchange Deployment Assistant
Microsoft has recently made a new tool, the Exchange Server Deployment Assistant, available at technet.microsoft.com/exdeploy2010. Using a series of simple questions, the EDA prepares a customized set of instructions for a given scenario. As a broad overview of the steps to be accomplished for an Exchange migration, it's a good start. However, because the tool is designed to be generic, it tends to make some things that can be accomplished in a single step take three or more steps (such as a typical single-server installation of Exchange Server). It also completely misses some things, such as the requirement for installing the newly created legacy SSL certificate on legacy Exchange 2003 servers.

As you begin to do your own upgrades (hopefully in a test environment before your production environment), keep Microsoft's definitions in mind. Microsoft defines an upgrade as an increase in product version that can happen in place (that is, on the same server or workstation). A migration is when the new product is installed on another computer and information is moved to the new computer, with little or no impact to users. A transition occurs when information is exported from one version of a product and then imported into another installation of the product (whether it be the same or a later version).

Exchange Server hasn't provided an upgrade since Exchange 2003 (which could be installed on top of Exchange 2000). For both Exchange 2007 and Exchange 2010, the new version has to be installed and then configured, with user mailboxes (and other configuration items) then moved from the old servers to the new servers. This is a considered a migration in Microsoft-speak.

Background
My partner company has the following configuration:

As is very common in smaller organizations, CLARK2K3 is the only server in the clarksupport-hq.com domain, and while it's not running Small Business Server (SBS), it's also a DC.

Step One: Exchange Prerequisites
Before you can install Exchange 2010, there are certain things that you must verify about your existing Exchange environment. The Exchange setup process checks these things too, but it's best that you verify them for yourself, so that when setup throws an error it doesn't come as a surprise.

Exchange must be in Native mode. You can't have any Exchange 2000 servers and all Exchange 2003 servers must be at SP2. You must also have KB937031 installed. To verify whether Exchange is in Native Mode, open the Exchange System Manager (ESM), right-click the Exchange Organization name in the selection pane, and select properties. You should get a dialog similar to Figure 1, with the Operation mode displayed as Native Mode. If the organization weren't native mode, I'd have a choice to change the mode of the organization in this dialog. There are a number of prerequisites for upgrading an organization to native mode, but they're outside the scope of this article. Refer to Microsoft Knowledge Base article 272314, XADM: Preparing a Mixed Mode Organization for Conversion to Native Mode.

You can also use ESM to see the versions of the Exchange servers you have in your organization, as Figure 2 shows. If your ESM is configured to display Administrative Groups (like in Figure 1), you'll need to expand the Administrative Groups node, then expand the node containing your historical administrative group (AG). Once you've prepared your environment to install either Exchange 2007 or Exchange 2010, you'll find a new AG named Exchange Administrative Group (FYDIBOHF23SPDLT). (For more information about FYDIBOHF23SPDLT and other special character sequences in Exchange 2007 and Exchange 2010, refer to bit.ly/cdpRM2.) After you've expanded the proper AG, click the Servers node beneath it. All the Exchange 2000 and Exchange 2003 servers will be displayed in the results pane, including their versions. Version 6.0 is Exchange 2000 and version 6.5 is Exchange 2003.

As I mentioned before, you can't install Exchange 2010 if you have any Exchange 2000 servers remaining. If this display shows any, you'll need to get them removed. Similarly, if you have any Exchange 2003 servers that aren't at SP2, you'll need to rectify that.

Finally, on all your Exchange 2003 servers, install the hotfix from Microsoft KB article 937031, Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server. Following the instructions in the KB, enable Integrated Windows Authentication on the Microsoft-Exchange-ActiveSync directory.

Step 2: Active Directory Prerequisites
Exchange Server 2010 will make some fairly major changes to your AD during the installation process. But before that can be done, Exchange has certain requirements that must be met:

To check the DFL, open Active Directory Domains and Trusts, right-click the AD domain, and select Raise Domain Functional Level (don't worry; this is non-destructive at this time). If the dialog that appears looks like Figure 3, you'll need to raise the DFL to at least Windows Server 2003. To view the current FFL, right-click the line above the domain, which starts with Active Directory Domains and Trusts, and select Raise Forest Functional Level.

Exchange 2003 and Exchange 2010 both support you raising the DFL and FFL all the way up to Server 2008 R2. However, as long as you have Windows 2000 DCs in your environment, you won't be able to update the functional levels higher than Windows 2000. This necessitates you removing all Windows 2000 DCs from your environment prior to the installation of Exchange Server 2010. Similarly, as long as you have Server 2003 DCs in your environment, you won't be able to raise the levels beyond Server 2003. However, because that's what Exchange 2010 requires as a minimum, it will be sufficient for this need.

The specific considerations for upgrading your functional levels are beyond the scope of this article. Suffice it to say that for most small and medium businesses, there are few problems. For more information, refer to this Microsoft TechNet article at bit.ly/bWO6Y8.

The final AD prerequisite to consider is whether this Exchange server will be a DC (remembering the caveats expressed earlier). If so, now is the time to add the Active Directory Domain Controller Server Role to the computer and then execute dcpromo.exe.

Step 3: Preparing to Install Exchange
Now that the infrastructure has been prepared, you can get on with the actual work involved in installing Exchange 2010. There are many paths to success, but the one I present here is tested and known to work. As a reminder, Exchange 2010 must be installed on 64-bit hardware. There is no 32-bit version of the software available.

You can install Exchange 2010 on either Server 2008 SP 2 or Server 2008 R2. If you have a choice, I recommend you use Server 2008 R2. It will not only have a longer lifetime (per Microsoft's standard lifecycle policies), it also has one less piece of software to download and install. If you're running Server 2008 SP2, you need to download and install Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0).

If you have Exchange 2010 on a DVD, I recommend you create a location on disk and copy the DVD there. I'll use D:Exchange2010 as the target for this purpose. If you downloaded Exchange in an executable or ISO format, extract the contents of the archive to that location.

Next, determine the most recent rollup available for Exchange, and place it into the Updates folder (D:Exchange2010Updates). The Exchange setup process will automatically apply the rollup during installation. At this writing, Rollup 1 is current and can be downloaded at Microsoft KB 976573, Description of Update Rollup 1 for Exchange Server 2010, but by the time you read this, additional rollups should be available. The name of my rollup is Exchange2010-KB976573-x64-en.msp. You can determine the most recent here.

Next, open a command prompt (or a PowerShell session) and enter the following commands:

D:Cd Exchange2010scriptsServerManagerCmd –ip Exchange-Typical.xml –restart

This command will cause the various server roles and server features that Exchange requires to be installed and then execute a reboot. If you use ServerManagerCmd on Server 2008 R2, it will warn you that it is "deprecated and not guaranteed to be supported in future releases of Windows." That's fine, it will work just fine for your needs. The other mechanisms for installing Exchange prerequisites (DISM and Add-WindowsFeature) are much more complicated and confusing to use.

Download the 2007 Office System Converter: Microsoft Filter Pack, ensuring that you retrieve the x64 version—the name of the file is FilterPackx64.exe. Once downloaded, install the filter pack. This is used by the Exchange full-text search engine to search Office format documents (such as those produced by Word, Excel, and PowerPoint).

The final preparation steps are somewhat dependent on how you've installed your Windows server and what other server roles and/or features have been installed. Therefore, if you get errors indicating that a step has already been completed, that's OK. Open a command prompt and execute the commands

sc config NetTcpPortSharing start= autonet start NetTopPortSharing

For the "sc config" command, the space following "start=" is required.

Step 4: Beginning the Installation
Exchange maintains extensive log files that record the steps taken during the installation process,  located in C:ExchangeSetupLogs. You'll be able to find a number of scripts and XML files that are created during installation, but the most important single file is named ExchangeSetup.log.

In larger environments, Exchange Administrators, Domain Administrators, Enterprise Administrators, and Schema Administrators are often different people. In small or medium-sized environments, it's common for these administrative permissions to be held by the same (small) groups of people. Each step in the installation of Exchange requires a slightly different set of permissions for a company to be able to separate the administrative roles, should they desire to do so. If you have a single domain in your forest, to cover all the permissions, you should just assign a single account to Schema Admins, Enterprise Admins, and Domain Admins. If you use the GUI setup to skip all of the individual steps below, you'll need to have a user with all of those permissions.

The first step of the installation is to prepare AD with the permissions that Exchange will require. To execute this step requires that the user have Enterprise Admin and Domain Admin privileges in the domain where the command is executed. In the D:Exchange2010 directory, execute the command

setup.com /PrepareLegacyExchangePermissions

This will execute fairly quickly. The next step is for Exchange setup to make required changes to the AD schema. These changes require Enterprise Admin and Schema Admin privileges for the user executing the command. Execute

setup.com /PrepareSchema

This command will take quite a while to execute.

The final preparation steps involve creating the required domain local groups for Exchange and setting up a variety of AD objects. The user executing the command must be a member of Enterprise Admins. Execute

setup.com /PrepareAD

If you have more than one AD domain, an Enterprise Admin should now execute

setup.com /PrepareAllDomains

Step 5: Installing Exchange Server 2010
To continue with the installation of Exchange, the user executing the installation must be a member of the (local) Administrators group on the Exchange-server-to-be and a member of the Organization Management group (which was created during the PrepareAD step above, and the user who executed that step is already a member of the group).

At this point, continuing with the command-line neither simplifies nor complicates life. To install the various server roles using the command-line, use the command

Setup.com /mode:install /roles:ca,ht,mb

If you're using a PowerShell session, you'll need to quote the entirety of the /roles parameter.

To use the GUI, double-click on the Setup application in D:Exchange2010. Figure 4 shows the opening dialog of the setup wizard. Click Step 3: Choose Exchange language option. You can choose to Install all languages from the language bundle, which will require you to download the language bundles over the Internet, or you can Install only languages from the DVD, which will install the 11 languages that Exchange 2010 supports for server installations. (The language pack bundle adds translations for client OSs). Select to install only the languages from the DVD. Now Step 3 will gray out, and you can select Step 4: Install Microsoft Exchange.

The first dialog of the wizard is simply boilerplate. Click Next. The next dialog requires you to say that you accept Microsoft's license terms to continue. If you accept those terms (which you must in order to continue), click I accept then Next. The next dialog invites you to join the Error Reporting program. Make your decision and click Next.

The next dialog finally asks something of substance, as shown in Figure 5. For this installation, I'll be doing a typical installation, so click Typical Exchange Server Installation. If required, select an alternate path for the Exchange program files.

The next dialog is designed to save you lots of configuration, and I recommend you use it. Here, you'll specify what the external name of the Exchange server will be for Outlook Web Access (OWA), Exchange ActiveSync, and Outlook Anywhere (which was known as RPC/HTTP in Exchange Server 2003). For my customer upgrade, see the information in Figure 6. Enter the value and click Next.

When specifying this during installation of a CAS, there should be no need to configure the OAB virtual directory or the EWS virtual directory. However, you can review most settings for these virtual directories (and the other virtual directories, such as ECP) from within Server Configuration, Client Access. However, there are some capabilities that can only be configured from the Exchange Management Shell using various PowerShell cmdlets, such as Set-WebServicesVirtualDirectory or Set-OABVirtualDirectory. I won't cover them here, but be aware that the capability exists.

The next dialog requires you to select a particular Exchange 2003 server that will be connecting to the Exchange 2010 hub transport server. Based on my scenario, you probably have only a single choice. Click Browse, select the proper Exchange 2003 server, and click OK to return to the wizard. Click Next. The next dialog, similar to the Error Reporting dialog, asks whether you want to join the Customer Experience Improvement Program. Your choice has no real effect on the installation.

With the next dialog, the setup process will evaluate whether the server meets all the prerequisites for installing Exchange, as Figure 7 illustrates. If all the readiness checks pass, you're ready to actually, finally, install Exchange. Click Install.

Even on a fast server, installing Exchange takes quite some time—you can expect it to take at least 20 minutes, and on slower hardware it could take as much as an hour. When it's done, you'll get a dialog similar to the one Figure 8 shows. Click Finish to continue. The setup GUI will return to the dialog in Figure 4. Close the Setup GUI application and move to the Exchange Management Console (EMC).

Step 6: Configuring Exchange Server 2010
The EMC will take a while to initialize, especially the first time you use it. Once the primary initialization is complete, expand Microsoft Exchange On-Premises and click Server Configuration. Because you've just installed the first Exchange 2010 server in your organization, there should only be a single server, as Figure 9 shows. In the Action pane (the rightmost pane of the MMC), click New Exchange Certificate. In the first dialog of the wizard, enter a friendly name for the certificate, such as All-purpose Exchange certificate.

The next dialog asks whether you're going to use a wildcard certificate with Exchange. You could do so, but it would require special configuration later. It can also cause security problems. (See this article from SSL Shopper for information about potential security problems with wildcard certificates.) I won't cover using a wildcard certificate here.

In the Exchange configuration dialog, select and configure all the required services you want your Exchange 2010 server to provide. Figure 10 shows part of this. Your choices will include Client Access Server configuration, including Outlook Web App on the internet, Exchange ActiveSync, Exchange Web Services, Outlook Anywhere (called RPC/HTTPS in Exchange 2003), Autodiscover, and a legacy domain name that will be used on the Exchange 2003 server while both servers are online at the same time. The names that will be placed on the SSL certificate request in this example will be mail.clarksupport.com, autodiscover.clarksupport.com, legacy.clarksupport.com, and clarksupport.com.

I won't cover using Federated Sharing services, Unified Messaging services, or assigning a certificate to POP-3 and or IMAP. However, if you choose to use any of the above domain names for POP-3 and/or IMAP, it's a simple matter of checking the box for those services.

The next dialog shows the above list of domain names. You have the option of adding or subtracting any additional domain names that you want to be included in the certificate request and selecting the domain name that will be the first domain name on the certificate—this is called the common name. Note that the wizard automatically chooses the base domain name as the common name (in this example, clarksupport.com)—that's sufficient for most purposes. You should note the common name for future use.

The final dialog requiring input is for specifying the organization and location of the company requesting the certificate. Realize that the information contained on this dialog should match closely with the information your domain registrar has on file for your domain. Figure 11 shows an example dialog filled out.

The next dialog allows you to confirm your choices. If you need to change or correct any information, do so now. When you're satisfied with the information displayed here, click New.

Presuming there are no errors, the certificate request is created and stored on your server in the location you indicated. Now you should submit the certificate request to the provider of your choice (such as DigiCert, GoDaddy, or many others). Once you've received the returned certificate, it's time to install the certificate on the Exchange server. 

In EMC, click Server Configuration. Then, in the results pane, click the friendly name you gave to the certificate request. Click Complete Pending Request, which Figure 12 shows, in the Action pane. In the wizard that opens, select the resulting file from your certificate provider (it should end in either a CER or CRT suffix) then click Complete. The certificate should be imported. Click Finish to close the wizard.

Again within the EMC, click Server Configuration and then click on the friendly name of the certificate in the results pane. In the Actions pane, click Assign Services to Certificate. The new server will be selected in the first dialog of the wizard. The next dialog is titled Assign Services to Certificate—check the box for Internet Information Services. In the next dialog, confirm your prior choice by clicking Assign, and then click Finish.

Now it's time to enable Outlook Anywhere. In EMC, expand Microsoft Exchange On-Premises then expand Server Configuration and then select Client Access. Click the server you've just installed In the Results pane, then click Enable Outlook Anywhere in the Action pane.

In the wizard, enter the external domain name you'll be using for Outlook Anywhere (OA). I used mail.clarksupport.com in this example . The selection of Basic Authentication vs. NTLM Authentication controls the security used for client access. Because you'll be using SSL with Outlook Anywhere, the default of Basic authentication will work fine. Click Enable, then review the results of the wizard and click Finish.

If the common name of the new SSL certificate is different than the external domain name you'll be using for OA, you need to further configure an Outlook Provider. Open an Exchange Management Shell (EMS) session, and enter the command

Set-OutlookProvider EXPR `  –CertPrincipalName msstd:

Now you need to modify the Default Offline Address List. You'll change the server responsible for creating and maintaining it from your legacy server to the new Exchange 2010 server. In the EMC, expand Microsoft Exchange On-Premises then Organization Configuration. Click Mailbox underneath Organization Configuration and select the Offline Address Book tab. There's usually only a single entry in the results pane—Default Offline Address List—so click it. Then click Move in the action pane, shown in Figure 13. In the Move Offline Address Book dialog that opens, click Browse. In the resulting dialog, click the new Exchange server and then OK. Click Move and the move will be executed. Click Finish.

Next, it's time to create a Send Connector so that the new server can send email to the Internet (which isn't possible by default). For this discussion, the send connector will either send email to the Internet or forward email to a third party for message hygiene and final delivery (this is typically called a gateway or edge email server). Within EMC, expand Organizational Configuration and click Hub Transport. Click the Send Connectors tab then New Send Connector in the Action pane. This will start the New Send Connector wizard. In the first dialog, enter a name for the send connector, such as Outgoing E-mail, and select Internet as the intended use of the send connector. Click Next.

The next dialog is for configuring the address space handled by this send connector. That is you specify the set of Internet domains to which the connector will send. Because you'll have only a single connector, configure it to handle all Internet domains. Click Add and, in the SMTP Address Space dialog, enter an asterisk (*) for the Address field and leave the Cost field at the default of 1, as shown in Figure 14.  

Back in the Address Space dialog, the new address space is visible. The next dialog, Network settings, allows you to configure how the Send Connector will deliver email. If your Exchange Server is going to deliver email directly to destination servers, leave everything on this window at the default of Use domain name system (DNS). If you need email to be routed through another computer for final delivery, click the button for Route mail through the following smart hosts then click Add. On the Add smart host dialog that opens, enter the proper IP address or Fully Qualified Domain Name for the smart host then click OK. You can enter as many smart host entries as you need. When you've completed any changes to this dialog, click Next.

The next dialog, Source Server, should have the name of the new Exchange 2010 server and no other entries. Don't make any changes, just click Next. The New Connector dialog summarizes the configuration choices you've made throughout the wizard. Review the display, and if any of the settings need changing, click Back and make them. When you're satisfied with the results, click New, then Finish to close the wizard.

Next you must ensure that your new server can receive email from the Internet. By default, an Exchange 2010 server is installed with two Receive connectors, but neither of them can receive anonymous email—which is most email from the Internet. Therefore, you'll change the security on one of those Receive connectors.

Receive connectors are configured on a per-server basis. In the EMC, expand Server Configuration and click Hub Transport. In the Results pane, click the Exchange 2010 server, shown in Figure 15. Click the Receive connector with a name that begins with Default then click Properties. Click the Permission Groups tab then check Anonymous users, as shown in Figure 16, then click OK.

Now you'll make sure that all public folder information from the Exchange 2003 server is replicated to the Exchange 2010 server. This happens in two pieces, with the first piece easiest to do from EMS. Open an EMS session and enter

cd $exscripts.AddReplicaToPFRecursive.ps1 –TopPublicFolder  `  -ServerToAdd $env:computername

The second piece is easiest to do from an EMC Toolbox application. In EMC, click Toolbox then double-click Public Folder Management Console. Expand System Public Folders. You can ignore the folders with names that start with OWAScratchPad and StoreEvents. For EFORMS REGISTRY, OFFLINE ADDRESS BOOK, and SCHEDULE+ FREE BUSY, you must ensure that each of their subfolders has a replica on the new server. (The EFORMS REGISTRY folder may have zero, one, or two subfolders.)

You're only interested in changing the replicas for the subfolders that only exist on the Exchange 2003 server. As an example of checking which subfolders are only on the Exchange 2003 server, click on SCHEDULE+ FREE BUSY, as shown in Figure 17. The subfolder with a name that begins EX:/o=Clark/ou=Exchange Administrative… is selected in the Results pane. Click Properties in the Action pane, then click the Replication tab. Note that the only server mentioned for this subfolder is the new server. Therefore, you won't need to add a replica for this subfolder. Click Cancel.

Now select the second subfolder, which is named EX:/o=Clark/ou=HQ in this example. Click Properties in the Active pane and then click on the Replication tab. You'll receive a display similar to Figure 18. In this case, the only server listed is the legacy Exchange 2003 server, so the Exchange 2008 server needs to be added. Click Add. In the Select Public Folder Database dialog that opens, click the name of the new Exchange 2010 server and then OK. Now the Replication tab will contain both the old and the new server and should resemble Figure 19, with the replication list including both the legacy Exchange 2003 server and the new Exchange 2010 server. Click OK to close the dialog box.

To complete updating public folders, repeat this process with each subfolder in the OFFLINE ADDRESS BOOK folder and the EFORMS REGISTRY folder. When you've updated them all, close the Public Folder Management Console. Next, configure the Exchange 2003 OWA URL that Exchange 2010 will use to refer OWA clients whose mailboxes are hosted on the Exchange 2003 server. For this example, open an EMS session and enter

Set-OWAVirtualDirectory Clark2008OWA* `  -Exchange2003URL "https://legacy.clarksupport.com"

A very common request is that when a user accesses the root of an Exchange server, that the user be automatically redirected to OWA. This is easily done by placing the lines below into a file on the CAS named C:InetpubwwwrootDefault.htm:

You'll need to update the name of the website (mail.clarksupport.com) to match the external name that you specified when you installed the CAS. If you wonder why I didn't use Default.asp and have this URL automatically generated, it's because the ASP module isn't installed into IIS by Exchange-Typical.xml, as Exchange itself does not require it.

Step 7: Configuring Exchange Server 2003
Forms-Based Authentication (FBA) must be set on the Exchange 2003 server for OWA to allow for seamless transfers from the Exchange 2010 server. Using the Certificates MMC or the Exchange 2010 EMC, you should now export the SSL certificate that you created earlier to a PFX file (making sure to export the private key). Copy the PFX file to the Exchange 2003 server and import the key there, also using the Certificates MMC.

Using the IIS Management Console, modify the properties of the Default Web Site to use the new SSL key. This will allow the old Exchange to accept both the legacy name (legacy.clarksupport.com in this example) and the current name (mail.clarksupport.com) until DNS is updated. Once the update has happened, execute iisreset or reboot the old server to begin using the new certificate.

Once you've made this certificate change, Outlook configurations using RPC/HTTP on the Exchange 2003 server will no longer work. You have two options: create a new Outlook MAPI profile using the new parameters, or modify the existing profile for those users. To make the modification requires you to be aware of the legacy name that will be used for the old Exchange 2003 server (egacy.clarksupport.com in this example) and the common name of the SSL certificate that was created and loaded (clarksupport.com).

How you access the Connection properties varies between versions of Outlook. In Outlook 2007 and above, you can click on the account properties, then More Settings, then the Connection tab. Figure 20 shows the bottom of that dialog. If the Connect to Microsoft Exchange Using HTTP box isn't checked, this profile isn't using RPC/HTTP. If it is, click the Exchange Proxy Settings button. Prior to correction, in this example, the dialog looks like Figure 21. To continue to allow RPC/HTTP to work for mailboxes hosted on the old server, you'll need to make the changes shown in Figure 22.

You only have to make these changes if you're using Outlook 2003 or if the mailbox is going to stay on the old server for some time. If you're using Outlook 2007 or above and you've configured autodiscover, when you move the mailbox to the new server, the Outlook profile will be automatically reconfigured. If you have more than one Exchange 2003 server, you'll need to suppress Link State Updates, as described a TechNet article at bit.ly/aICc3q.

Configuring DNS
At this point, you're ready for the rubber to meet the road. It's time to update your internal and external DNS so that the legacy name properly points to the Exchange 2003 server (legacy.clarksupport.com) and the external name you used to configure the CAS points to the new Exchange 2010 server (mail.clarksupport.com).

For Outlook redirects and Autodiscover to work properly, the external name for the CAS on your internal LAN must resolve internally to an IP address which can be accessed internally. The same is true for the legacy Exchange server name. Make the DNS updates and test. If you've followed all the steps, dotted all the i's and crossed all the t's, both servers should seamlessly work together.

Moving Mailboxes
Moving mailboxes from the old server to the new server is required for users to have access to the new OWA and ECP, and for the system administrator to be able to use the new administrative features of Exchange Server 2010 on those users. There are, however, a few things that should be verified prior to beginning this process.

First, be aware that mailbox databases in Exchange 2010 have a default mailbox size limit set, at creation, of 2 GB. If you have users with mailboxes larger than that, you'll need to update the mailbox database limits on Exchange 2010 or set individual limits for those user's mailboxes. Moving a mailbox will fail if it's larger than the pre-defined mailbox database limit and the user doesn't have an exception configured. To change the default for the mailbox database, edit the Limits tab on the mailbox database property sheet, which you access from the Mailbox node of the Organizational Configuration in the EMC.

Second, it is very likely that you want your mailbox database and its log files to be located on some disk volume other than the one on which Exchange was installed (C: by default). To move the mailbox database and/or log files, you must first identify the desired volume and create directories to move the files to. You can put the database and the log files in the same directory. However, you can't share directories between multiples databases or multiple sets of log files. If you try, you'll get an error—and it isn't an obvious error. To move the database and/or log files to another location, access the mailbox database from the Mailbox node of the Organizational Configuration in the EMC and then click Move Database Path in the Action pane.

Finally, once all your mailboxes are on Exchange 2010, you can invisibly and seamlessly move mailboxes between mailbox databases and Exchange mailbox servers. This isn't true when moving mailboxes from Exchange 2003 to Exchange 2010. Now, Outlook 2007 and above will usually correctly update the user's profile (using Exchange 2010's Autodiscover feature), even if the user is connected via Outlook when the move-mailbox process has begun. However, it doesn't always work. I recommend that you have users close Outlook when you're moving their mailbox from the old server to the new server. With Outlook 2003, if you're using RPC/HTTP, you can manually update those. The above set of warnings is based on me making these exact errors more than once. I invite you to learn from my mistakes and not repeat them!

The process of moving mailboxes is called creating a move request, which is a change from all prior versions of Exchange. From within the EMC, click Recipient Management. Select (multi-select is fully support) the mailboxes that you want to be moved. All mailboxes on the Exchange 2003 server will have Legacy Mailbox under Recipient Type, as you can see in Figure 23. Click New Local Move Request. (A local move request is one that is executed on the current Exchange server. A remote move request is executed on a different Exchange server.)

The first dialog in the wizard displays the mailboxes you've selected for movement. Click the Browse button and select the target mailbox databases to which you want the mailboxes moved, then click Next.

In the next dialog, Move Options, you indicate what's to happen with the move request for a particular mailbox should a corrupt message be found in that mailbox. Skip the mailbox is the default selection, but the truth of the matter is that if a corrupt message is found, there isn't much you can do about it. Typically, I select Skip the corrupted messages and enter a relatively large value for the skip count, such as 999. Make your choice (and enter a value if necessary), then click Next.

The next dialog presents a summary of the choices you've made—a list of the mailboxes to be moved, the destination mailbox database, and, if you selected Skip the corrupted messages, the number of items to be skipped per mailbox. To initiate the mailbox moves, click New. Finally, click Finish to close the wizard.

Note that the mailboxes aren't moved by the time you have closed the wizard. Instead, the move requests have begun. To see the status of your current move requests, expand Recipient Management in the EMC, and click the node named Move Requests. The requests and their statuses are displayed. Each mailbox move consumes resources on both the source and the target Exchange servers, so you may want to schedule moving a few at a time to reduce the system impact of the moves.

A Job Well Done
You should now be up and operating in a coexistence environment, running both Exchange Server 2010 and Exchange Server 2003. Once all your mailboxes are moved, you can begin the process of decommissioning the Exchange Server 2003 environment. However, don't just cut off that server! While you're now operating in a coexistence environment, there are a number of items, such as offline address books and email address policies, that must be transferred from the old Exchange environment to the new one. Please consider referring to my blog for further information.

Enjoy using Exchange Server 2010 and the many enhancements it offers for you and your users over Exchange Server 2003.