Migrating Exchange 2007 on Windows Server 2003 to Exchange 2007 SP1 on Windows Server 2008

 

By Scott Schnoll

Microsoft Exchange Server 2007 Service Pack 1 (SP1) includes many new features and improvements to the release to manufacturing (RTM) version of Exchange 2007. One new improvement is support for the Windows Server 2008 operating system, which was recently released to manufacturing. Although the RTM version of Exchange 2007 cannot be installed on Windows Server 2008, Exchange 2007 SP1 is supported for installation on Windows Server 2008. The following table summarizes the operating system support for Exchange 2007 RTM and SP1.

Exchange Server 2007 product release	Windows Server 2003 support	Windows Server 2008 support
Exchange 2007 RTM	Windows Server 2003 SP1 or later versions Windows Server 2003 R2	Not Supported
Exchange 2007 SP1	Windows Server 2003 SP2	Windows Server 2008 RTM

For more information about Microsoft Exchange (including earlier versions) and Windows Server 2008, see the Exchange Team blog post, Exchange Server and Windows Server 2008.

Note

The content of each blog and its URL are subject to change without notice. The content within each blog is provided "AS IS" with no warranties, and confers no rights. Use of included script samples or code is subject to the terms specified in the Microsoft Terms of Use.

Migrating a computer that is running Exchange 2007 to the Windows Server 2008 operating system requires careful planning, as you cannot do an in-place upgrade of the operating system from Windows Server 2003 to Windows Server 2008. Instead, you have to either build a new server and migrate your data, or preserve your data and re-build your existing server from scratch.

If your organization creates and maintains server build documentation and change management records and logs, we recommend that you refer to those materials during the procedures detailed in this topic. If your organization does not create and maintain these materials, we strongly recommend that you consider doing this.

Unsupported Migration Processes

As written in the Exchange Team blog post, Mission Impossible: In-Place Upgrading Microsoft Exchange Server 2007 from Windows Server 2003 to Windows Server 2008, when Exchange 2007 (RTM or SP1) is installed on a computer, the operating system cannot be upgraded in place. There are various technical reasons for this. To summarize:

• You cannot take an existing Exchange 2007 server (RTM or SP1) running on Windows Server 2003, and do an in-place upgrade of the operating system to Windows Server 2008.

• Because of the significant changes that are introduced in Windows Server 2008 failover clusters, rolling upgrades of failover clusters with clustered mailbox servers from Windows Server 2003 to Windows Server 2008 are not possible.

• When you upgrade stand-alone servers, it is not supported to upgrade your operating system to Windows Server 2008 and then upgrade Exchange 2007 to SP1. It is also not supported to upgrade Exchange 2007 to SP1 and then upgrade your operating system to Windows Server 2008.

• It is not supported to use either of the server recovery features in Setup across operating systems. You cannot use Setup /m:RecoverServer or Setup /RecoverCMS to change the operating system that is used by an Exchange server. For example, you cannot use Setup /m:RecoverServer on Windows Server 2008 to recover an Exchange server that was running on Windows Server 2003.

Supported Migration Processes

There are two supported processes for migrating a computer that is running Exchange 2007 or Exchange 2007 SP1 on Windows Server 2003 to Windows Server 2008: installing a new server and the migrating the data, or rebuilding the existing server from scratch and migrating or restoring the data.

Installing a New Server or Cluster

This process involves building a new server or cluster and then using data migration mechanisms, such as mailbox moves and public folder replication, to migrate the data from the old server to the new server. Moving mailboxes generally means that the user's desktop messaging profile will not have to be manually modified. However, in some environments, using database portability instead of the Move Mailbox process may reduce the downtime experienced by users. For example, if the storage that contains the databases can be disconnected from the original server and reconnected to the new server, then database portability would likely be much quicker and result in less downtime than a Move Mailbox operation. Ultimately, each organization must determine for itself which data migration process best meets their needs.

Rebuilding the Existing Server or Cluster from Scratch

For a stand-alone server, this process involves preserving existing data, removing any third-party applications, uninstalling Exchange, uninstalling Windows PowerShell, upgrading Windows Server 2003 to Windows Server 2008, installing PowerShell and other prerequisites for Windows Server 2008, installing Exchange 2007 SP1, using database portability or backup and restore to migrate the data, reconfiguring the server, and finally reinstalling third-party applications.

In this process, how you preserve the data depends on the number of servers you have. In a multiple mailbox server environment, you can move all mailboxes and data to another server and then uninstall Exchange. In a single server environment, you can disable all mailboxes and then uninstall Exchange.

For a clustered mailbox server, this process involves uninstalling Exchange and Windows PowerShell from a passive node in the cluster, and then evicting that node from the cluster. When the node has been evicted, you can perform a fresh install of Windows Server 2008, install the prerequisites, and then create a new failover cluster with that node.

Migrating Server Roles from Windows Server 2003 to Windows Server 2008

Moving each server role from Windows Server 2003 to Windows Server 2008 is very similar for all roles, but there are specific tasks that are unique to each server role. The following sections detail the process for moving each server role to Windows Server 2008.

When you migrate individual server roles, the order in which roles are migrated is important, especially because, unless you have already deployed Exchange 2007 SP1 throughout your organization, the migration to Windows Server 2008 always involves the transitioning from Exchange 2007 RTM to Exchange 2007 SP1. Thus, you must migrate the server roles in the same order in which you would deploy SP1 in your environment: Client Access, Hub Transport, Edge Transport, Unified Messaging, and then Mailbox.

Accordingly, you must plan your Windows Server 2008 deployment with Exchange 2007 SP1 requirements in mind. The deployment of Exchange 2007 SP1 with Windows Server 2008 on one computer may affect or drive the deployment of Exchange 2007 SP1 with Windows Server 2008 on other computers. The reasons for this are described in the following sections.

Transport Servers and Edge Synchronization

All transport servers that participate in an EdgeSync process must be running the same version of Exchange 2007 (for example, all RTM or all SP1). Thus, after you migrate your first Hub Transport server to Windows Server 2008, you must upgrade all other Hub Transport servers in the same Active Directory Site, and all Edge Transport servers subscribed to the Active Directory Site, within 15 days of the first upgrade to Exchange 2007 SP1 of any transport server that participates in the EdgeSync process. This does not mean that these servers must also be migrated to Windows Server 2008. However, it does mean that they must be upgraded to Exchange 2007 SP1.

Features without Cross-Operating System Support

Some features of Exchange 2007 do not have cross-operating system support; namely, standby continuous replication (SCR) and the management of failover clusters in both single copy cluster (SCC) and cluster continuous replication (CCR) environments:

• When you use SCR, the SCR source computer and all its SCR target computers must run the same operating system. Thus, before you migrate an existing SCR source or target computer, you must first disable SCR for the computer being migrated.

• Windows Server 2008 represents a clean break from the Cluster APIs included in earlier versions of Windows Server. Because the Cluster service does not allow you to use the cluster management tools for remote administration of failover clusters across different operating systems, you cannot use the Exchange management tools for remote administration of failover clusters across different operating systems. For example, you cannot do the following:

  • Manage a clustered mailbox server that is running on Windows Server 2008 from a computer that is running Windows Server 2003 or Windows XP.

  • Manage a clustered mailbox server that is running on Windows Server 2003 from a computer that is running Windows Server 2008.

  In addition to the previous restrictions, you cannot install different operating system versions of the cluster management tools on the same computer. Thus, if you are running multiple client and server operating systems in your Exchange environment, you may have to use alternative methods, such as the Remote Desktop Protocol tools, to manage some or all Exchange servers.

Note

At the time of this writing, the remote server administration tools for Windows Vista are not yet available. These tools must be installed on Windows Vista to enable the remote management of failover clusters running Windows Server 2008.

Procedures for Individual Server Role Migration

The procedures in this topic discuss how to migrate individual server roles from Exchange 2007 (RTM or SP1) on Windows Server 2003 to Exchange 2007 SP1 on Windows Server 2008. For detailed information about how to migrate a single server environment from Windows Server 2003 to Windows Server 2008, see the section "Procedures for Single Server Environments" later in this topic.

Client Access Server Role

Client Access servers store their configuration data in multiple places.

• Active Directory is used to store configuration information related to the Availability service, Exchange ActiveSync, and Outlook Web Access virtual directories.

• The Internet Information Services (IIS) metabase also stores configuration information for Exchange ActiveSync, and for Autodiscover, and Exchange Web Services.

• Local configuration files, such as Web.config files and the Windows registry are used to store configuration data related to Outlook Web Access, IMAP, POP3, the Availability service, Exchange ActiveSync, and information that is used by Exchange Setup.

The migration process for Client Access servers is primarily a manual process because you cannot programmatically migrate configuration settings from one Client Access server to another. However, to automate a large portion of the configuration setting collection process, you can use an Exchange Management Shell script called ExportCASConfig.ps1. This script can be downloaded from the Exchange Team blog post, Ever wanted to export your CAS role settings?.

Note

The content of each blog and its URL are subject to change without notice. The content within each blog is provided "AS IS" with no warranties, and confers no rights. Use of included script samples or code is subject to the terms specified in the Microsoft Terms of Use.

ExportCASConfig.ps1 can be used to export virtual directory information for Outlook Web Access, Exchange ActiveSync, Unified Messaging, Web services, offline address books, POP3, and IMAP4. It can also export installation and script path settings for a Client Access server. The script exports the collected information to an XML file, which you then use as a reference while manually recreating the captured settings on the newly built Client Access server.

Migrating a Client Access server from a server that is running Windows Server 2003 to a new server that is running Windows Server 2008 can be done by using the following steps.

Note

If the Client Access server being migrated to Windows Server 2008 is part of a Windows Network Load Balancing (NLB) cluster, we recommend that you temporarily remove them from the NLB cluster when you perform the migration process. During your migration, an NLB cluster will simultaneously have Windows Server 2003 and Windows Server 2008 nodes in the same NLB cluster. This mixed-mode deployment is supported only while the upgrade installation is in progress and it should not be used for an extended period of time in deployment. For more information about how to upgrade an NLB cluster from Windows Server 2003 to Windows Server 2008, see Upgrading an existing Network Load Balancing Cluster.

1. Collect and document all custom configuration settings. This is a two-phase process, which is part automatic (phase 1) and part manual (phase 2).

   1. Download and run the ExportCASConfig.ps1 script to collect the configuration information described above in an XML file.

   2. Manually collect remaining configuration settings, which the script does not collect, by examining and documenting information in the Web.config files and in the Windows registry. In addition, you must manually collect and document IIS configurations and settings that are not collected as part of the export process, such as the require SSL setting, Web site bindings, certificates and certificate mappings, and HTTP redirects.

2. Build and configure the new Client Access server that is running Exchange 2007 SP1 and Windows Server 2008. For detailed steps to install the Client Access server role, see Deploying Server Roles. We also recommend that you visit Microsoft Update to download any critical or recommended updates for the new server.

3. Run the ExportCASConfig.ps1 script on the new server to collect its configuration information in a second XML file.

4. Compare the two XML files using Microsoft WinDiff (Windiff.exe), which is included with both Windows Server 2003 and Windows Server 2008. WinDiff compares files or directories and displays the results graphically. For example, information in one file that is missing from the compared file is highlighted in red, and information in one file that is different in the compared file is highlighted in yellow, and so on. For more information about using WinDiff, see Microsoft Knowledge Base article 159214, How to Use the Windiff.exe Utility. By comparing the configuration files captured from each system, you will be able to more readily discern changes and missing settings, which can then be manually reconfigured on the new server.

5. After you have manually reconfigured the settings for the collected configuration information, on the new server, you must manually reconfigure the remaining settings that are not captured by the script, including:

   • Information in the Web.config file

   • SSL settings

   • Web site bindings

   • Certificates and certificate mappings, and

   • HTTP redirects

   You can use Windiff to compare the Web.config files on the original and new server.

   If the private key for the SSL certificates on the original server is marked as exportable, you can export the certificate(s) and then import them into the new server. For detailed steps to export a certificate from IIS 6.0, see Export a Server Certificate (IIS 6.0). For detailed steps to import a certificate into IIS 7.0, see IIS 7.0: Import a Server Certificate.

   Manually collect any remaining custom settings, and then re-create them on the new server.

6. After Active Directory replication has replicated the new server and its configuration settings throughout the organization, you can uninstall the Client Access server role from the original server. For detailed steps to uninstall Exchange 2007, see How to Completely Remove Exchange 2007 from a Server.

Hub Transport Server Role

The migration process for a Hub Transport server role is one of the simplest of the server role migrations. There are two configuration elements that must be manually collected and documented, and then re-created on the new server: Receive connectors and Edge Subscriptions. Receive connectors and Edge Subscriptions cannot be migrated between systems. Therefore, they must be manually re-created. In addition, if the Hub Transport server that you are decommissioning is specified as the source transport server for any Send connectors or any Foreign connectors, you will want to remove the old Hub Transport server name from the connector's Source Servers list, and add the new Hub Transport server to the Source Servers list. You can use the following command to collect Send connector information:

Get-SendConnector |  where { $_.SourceTransportServers -match <NameofHubTransportServer> }

The migration process can be performed by using the following steps:

1. Install a new Exchange 2007 Hub Transport server that is running Exchange 2007 SP1 and Windows Server 2008. We also recommend that you visit Microsoft Update to download any critical or recommended updates for the new server. For detailed steps to install the Hub Transport server role on Windows Server 2008, see Deploying Server Roles.

2. The new Hub Transport server will include two receive connectors: a Client Connector and a Default Connector.

   1. Any custom changes made to the Client Connector and Default Connector on the original Hub Transport server must be manually re-created on the new Hub Transport server.

   2. Any custom connectors created on the original Hub Transport server must also be manually re-created on the new Hub Transport server.

3. Run the EdgeSync process on the new server to subscribe your Edge Transport server(s) to the new Hub Transport server. You must subscribe the Edge Transport server to the same Active Directory site to which it was originally subscribed. You do not have to first remove the original Edge Subscription. The subscription process will overwrite the existing Edge Subscription. To subscribe an Edge Transport server, do the following:

   1. Export a new XML file on the Edge Transport server

   2. Import the XML file on the new Hub Transport server.

   For more information about the EdgeSync process, see Subscribing the Edge Transport Server to the Exchange Organization.

4. Reconfigure any Send connectors as necessary. For detailed steps to reconfigure a Send connector, see How to Modify the Configuration of a Send Connector.

5. When the new Hub Transport server has been configured and subscribed, you can remove the Edge Subscription from the original Hub Transport server, and then uninstall the Hub Transport server role. For detailed steps to remove the Edge Subscription, see How to Remove an Edge Subscription. For detailed steps to uninstall Exchange 2007, see How to Completely Remove Exchange 2007 from a Server.

Mailbox Server Role

The migration process for Mailbox servers involves moving mailboxes or using database portability to move mailbox data, capturing and migrating custom configuration settings, and public folder content, moving the offline address book (OAB) generation process, and removing Exchange 2007 from the original Mailbox server.

Note

Content indexes cannot be migrated between servers. After the migration process has finished, the databases will be re-indexed on the new server.

This migration process can be performed by using the following steps:

1. Install a new Exchange 2007 Mailbox server or clustered mailbox server that is running Exchange 2007 SP1 and Windows Server 2008. We also recommend that you visit Microsoft Update to download any critical or recommended updates for the new server. For detailed steps to install the Mailbox server role or a clustered mailbox server on Windows Server 2008, see the following topics:

   • Deploying Server Roles

   • Installing Cluster Continuous Replication on Windows Server 2008

   • Installing a Single Copy Cluster on Windows Server 2008

2. Configure the new server with any customized settings that were used on the old server. You can use the Exchange Server Best Practices Analyzer tool to collect various configuration settings for the server. In addition, you can use the following commands in the Exchange Management Shell to collect server configuration settings:

   Get-ExchangeAdministrator OriginalServerName | FL
   Get-MailboxServer OriginalServerName | FL
   Get-ExchangeServer OriginalServerName | FL
   Get-StorageGroup -Server OriginalServerName | FL
   Get-MailboxDatabase -Server OriginalServerName | FL
   Get-PublicFolderDatabase -Server OriginalServerName | FL
   

   You can also redirect the output of each of these commands to a single file by running these commands:

   Get-ExchangeAdministrator OriginalServerName | FL > C:\OriginalServerName.txt
   Get-MailboxServer OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-ExchangeServer OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-StorageGroup -Server OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-MailboxDatabase -Server OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-PublicFolderDatabase -Server OriginalServerName | FL >> C:\ OriginalServerName.txt
   

3. If the original server contained a public folder database, you can move public folders to the new server. For more information about moving public folder replicas from one server to another, see How to Move Public Folder Content from one Public Folder Database to Another Public Folder Database.

4. Move the offline address book (OAB) generation process to the new server. For detailed steps to do this, see How to Move the Offline Address Book Generation Process to Another Server.

5. When the public folders and the OAB generation process have been migrated, you can choose a mailbox database migration method.

   1. You can move all mailboxes to the new server by using the Move Mailbox task. For more information about how to move mailboxes, see Moving Mailboxes.

   2. Or, you can use database portability to move mailbox databases from the old server to the new server. For more information about how to use database portability, see Database Portability.

   If any storage groups on the original Mailbox server are enabled for local continuous replication (LCR) or SCR, you should disable LCR/SCR before moving any mailboxes to the new Mailbox server using move mailbox or database portability.

6. After the mailboxes have been moved to the new server, you can enable LCR or SCR for one or more storage groups on the new server. However, be aware that when using SCR, the operating system on all SCR targets must match the operating system on the SCR source. As the new Mailbox server is now running Windows Server 2008, any SCR targets used by storage groups on the new Mailbox server must also be running Windows Server 2008.

7. To retire the original server, first verify that all data, including mailboxes, public folders, OAB generation, and any third-party applications, has been successfully migrated to the new server. When verification is complete, Exchange can be uninstalled. For detailed steps to uninstall Exchange 2007, see How to Completely Remove Exchange 2007 from a Server. For information about uninstalling the first Exchange 2007 server in a mixed organization, see How to Remove the First Exchange 2007 Server in a Coexistence Scenario.

Edge Transport Server Role

The migration process for an Edge Transport server is by far the easiest of the server role migrations. The Edge Transport server role stores its configuration information in Active Directory Application Mode (ADAM) on Windows Server 2003 and in Active Directory Lightweight Directory Services (AD LDS) in Windows Server 2008. Exchange 2007 and Exchange 2007 SP1 include scripts called ExportEdgeConfig.ps1 and ImportEdgeConfig.ps1, which can be used to export Edge Transport server configuration settings from the ADAM instance on one server and then import those settings into the ADAM instance on another Edge Transport server, respectively. These scripts have been fully tested and are supported for use across operating systems. For example, the scripts can be used to migrate from Exchange 2007 on Windows Server 2003 to Exchange 2007 SP1 on Windows Server 2008. For more information about these scripts, see Using Edge Transport Server Cloned Configuration.

The migration process can be performed using the following steps:

1. Install a new Exchange 2007 Edge Transport server that is running Exchange 2007 SP1 and Windows Server 2008. We also recommend that you visit Microsoft Update to download any critical or recommended updates for the new server. For detailed steps to install the Edge Transport server role on Windows Server 2008, see Deploying Server Roles. We also recommend that you visit Microsoft Update to download any critical or recommended updates for the new server.

2. Perform a Cloned Configuration process by using the export and import scripts described earlier. For detailed steps to perform the Cloned Configuration process, see How to Configure the Edge Transport Server Role by Using Cloned Configuration Tasks.

   Important

   The Cloned Configuration process does not check for or migrate any custom permission settings. These settings must be manually collected and re-created on the new Edge Transport server. In addition, the Cloned Configuration process does not duplicate the Edge Subscription settings of a server. The certificates that are used by the Microsoft Exchange EdgeSync service are not cloned. You must run the EdgeSync process separately for each new Edge Transport server. The EdgeSync service overwrites any settings that are included in both cloned configuration information and in EdgeSync replication information.

3. When the configuration information is exported from the original Edge Transport server, the transport configuration object is not written to the intermediate XML file. Therefore, the configuration information for this object is not cloned to the new Edge Transport server. The settings of the transport configuration object define server-wide e-mail transport settings for an Edge Transport server. After you import the intermediate XML file to the target server, the settings of the transport configuration object will have default values. To restore the transport configuration object settings on the new Edge Transport server, after the import process is complete, you must configure the settings by following these steps:

   1. Run the Get-TransportConfig cmdlet against the original server to collect the transport configuration settings.

   2. Run the Set-TransportConfig cmdlet on the new server to re-create the settings from the original server to the new server.

4. Update your Domain Name System (DNS) records, as appropriate. For example, you should remove the IP address for the original Edge Transport server from the Mail Exchanger (MX) record, and add the IP address of the new Edge Transport server to the MX record.

5. Verify that all message queues are empty. If any queues contain messages, the queues should be drained before proceeding with this process. You can use the following command to determine the number of messages in each message queue:

   Get-Queue -Server OriginalServerName | fl Identity,MessageCount
   

   A value of 0 for MessageCount indicates an empty queue. If any queue contains messages that must be delivered, you can drain the queues by disabling all Receive connectors on the server by using the Set-ReceiveConnector cmdlet. This prevents the server from accepting new connections. For detailed steps to disable a Receive connector, see How to Enable or Disable a Receive Connector. After all Receive connectors are disabled, wait for the queues to empty.

6. Remove the Edge Subscription from the Hub Transport server to which it is subscribed by using the Remove-EdgeSubscription cmdlet. For detailed steps to remove an Edge Subscription, see How to Remove an Edge Subscription.

7. Run the EdgeSync process on the new server to establish one-way replication of recipient and configuration information from Active Directory to the Active Directory Lightweight Directory Services instance on the new Edge Transport server. For more information about the EdgeSync process, see Subscribing the Edge Transport Server to the Exchange Organization.

8. When the new Edge Transport server has been configured and subscribed, you can uninstall the Edge Transport server role from the original server. For detailed steps to uninstall Exchange 2007, see How to Completely Remove Exchange 2007 from a Server.

Unified Messaging Server Role

The migration process for a Unified Messaging (UM) server involves moving the prompt publishing point from the original server to the new server. Other UM configuration settings, such as recorded names and personal greetings for UM-enabled users, are stored in Active Directory and user mailboxes respectively. Therefore, you will not need to migrate this data.

Custom greetings for dial plans and automated attendants are published to the UM prompt publishing point and each UM server in a dial plan obtains its own copy from there. By default, the prompt publishing point for a dial plan is on the first UM server to join the dial plan. You can determine the location of the prompt publishing point by using the Exchange Management Shell. For example, if you have a dial plan called DialPlan1, you can run the following commands in the Exchange Management Shell to determine the path for the prompt publishing point:

$dp = Get-UMDialPlan DialPlan1
$dp.PromptPublishingPoint

The output will be a Universal Naming Convention (UNC) path that includes the fully qualified domain name (FQDN) of the first UM server to join DialPlan1. For example, if the first UM server to join DialPlan1 is named UMSVR1 and is located in the fabrikam.com domain, the output will be:

\\umsvr1.fabrikam.com\ExchangeUM

If UMSVR1 will continue to provide UM services after the migration, then you can leave things as they are. However, if you plan on decommissioning UMSVR1 and you have to continue to update custom dial plan and automated attendant prompts, then you must move the prompt publishing point elsewhere. The new location does not have to be a UM server, but it does need to be a computer that will be available every time prompts are published. Let’s suppose you want to move the prompt publishing point to newserv.fabrikam.com. To do this, you would perform the following steps:

1. Build and configure the new Unified Messaging server that is running Exchange 2007 SP1 and Windows Server 2008. For detailed steps to install the Unified Messaging server role, see Deploying Server Roles. We also recommend that you visit Microsoft Update to download any critical or recommended updates for the new server.

2. Configure the new Unified Messaging server to join the Dial Plan(s) to which the existing Unified Messaging server belongs.

3. Copy everything under the old prompt publishing point to the new prompt publishing point by using the following command:

   xcopy \\umsvr1\ExchangeUM \\newserv\ExchangeUM /s /e
   

4. On the new Unified Messaging server, run the Update-FileDistributionService cmdlet, which forces the files to be copied immediately.

5. Update the dial plan configuration to refer to the new publishing point:

   $dp = Get-UMDialPlan MyDP
   $dp.PromptPublishingPoint = \\newserv.fabrikam.com\ExchangeUM
   $dp | Set-UMDialPlan
   

6. After Active Directory replication has replicated this change throughout the organization, you can uninstall the Unified Messaging server role from the original server. For detailed steps to uninstall Exchange 2007, see How to Completely Remove Exchange 2007 from a Server.

Procedures for Single Server Environments

Although the previous procedures for moving the five server roles work well in a multiple server environment, they are, for obvious reasons, not possible in an environment where you have a single computer that is running Exchange 2007 that has the Hub Transport, Client Access, and Mailbox server roles installed and where you do not have hardware to use for building a new server. Thus, in a single server environment, you must preserve existing data and then rebuild the existing server from scratch.

Important

The single server environment in this article refers to a single member server that is running multiple server roles. If your single server environment is a directory server that is running multiple server roles, and if it is the only directory server in your environment, you should not perform a fresh install of Windows Server 2008. Instead, you should perform an in-place upgrade of the operating system, which will preserve your directory server settings and data. For more information about how to upgrade Active Directory from Windows Server 2003 to Windows Server 2008, see Active Directory Domain Services.
If during this process, your user account information is lost, you can re-create accounts in Active Directory based on user information in your mailbox databases. For more information about how to create user accounts based on information in mailbox databases, see How to Generate Active Directory Accounts By Using the Mailbox Information in the Mailbox Database.
In addition, the single server environment in this article does not contain any Edge Transport servers. If your single server environment includes an Edge Transport server, you should migrate the Edge Transport server after migrating the multi-role server. See "Edge Transport Server Role" earlier in this article for the Edge Transport server role migration process.

Migrating a computer that is running Exchange 2007 on Windows Server 2003 to Exchange 2007 SP1 on Windows Server 2008 does require that you basically reconfigure a new server from scratch, but using database portability allows you to easily migrate your mailbox data from the original server to the new, rebuilt server.

The process for migrating a single server environment containing the Client Access, Hub Transport, Mailbox, and Unified Messaging server roles from Windows Server 2003 to Windows Server 2008 is as follows:

1. Make a full backup of the system by using Windows Backup (aka NTBackup.exe). If the server hosts a public folder database, it is especially important to make an offline copy of the public folder database and its log files, as they will be copied to the newly rebuilt server later in this procedure.

2. Collect as much configuration information as possible from the existing server. You can use the following commands in the Exchange Management Shell to collect server configuration settings:

   Get-ExchangeAdministrator OriginalServerName | FL
   Get-MailboxServer OriginalServerName | FL
   Get-ExchangeServer OriginalServerName | FL
   Get-StorageGroup -Server OriginalServerName | FL
   Get-MailboxDatabase -Server OriginalServerName | FL
   Get-PublicFolderDatabase -Server OriginalServerName | FL
   Get-SendConnector |  where { $_.SourceTransportServers -match <NameofHubTransportServer> } | FL
   

   You can also redirect the output of each of these commands to a single file by running these commands:

   Get-ExchangeAdministrator OriginalServerName | FL > C:\OriginalServerName.txt
   Get-MailboxServer OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-ExchangeServer OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-StorageGroup -Server OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-MailboxDatabase -Server OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-PublicFolderDatabase -Server OriginalServerName | FL >> C:\ OriginalServerName.txt
   Get-SendConnector |  where { $_.SourceTransportServers -match <NameofHubTransportServer> } | FL >> C:\ OriginalServerName.txt
   

   To automate a large portion of the configuration setting collection process for the Client Access server role, you can use an Exchange Management Shell script called ExportCASConfig.ps1. This script can be downloaded from the Exchange Team blog post Ever wanted to export your CAS role settings?

   You should also manually collect remaining configuration settings, which ExportCASConfig.ps1 does not collect, by examining and documenting information in the Web.config files and in the Windows registry. In addition, you must manually collect IIS configurations and settings that are not collected, such as the require SSL setting, Web site bindings, certificates and certificate mappings, and HTTP redirects.

   If the server is running the Unified Messaging server role, we recommend that you copy all files under the existing prompt publishing point to a safe location. For example, you would use the following command to copy all files under the existing prompt publishing point on server named Server1 to a share called UMSave on a server named Server2:

   xcopy \\Server1\ExchangeUM \\Server2\UMSave /s /e
   

3. After you have finished collecting configuration information for the server, copy all files that contain the collected configuration settings (for example, OriginalServerName.txt) to a safe location.

4. If LCR is enabled for any storage groups on the server, it must be disabled before rebuilding the server by running the following command:

   Get-StorageGroup -Server <ServerName> | Disable-StorageGroupCopy -Confirm:$False
   

5. Disable all user mailboxes from the Mailbox database(s) on the server. You can do this by running the following command in the Exchange Management Shell:

   Get-Mailbox -Server <ServerName> | Disable-Mailbox -Confirm:$False
   

6. If the server contains a public folder database, remove the public folder database by running the following commands:

   Get-PublicFolder -Server <ServerName> "\" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server <ServerName> -Recurse -ErrorAction:SilentlyContinue
   Get-PublicFolder -Server <ServerName> "\Non_Ipm_Subtree" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server <ServerName> -Recurse -ErrorAction:SilentlyContinue
   

7. Dismount all mailbox databases, and then stop the Microsoft Exchange Information Store service (and any dependency services) by running the following commands:

   Get-MailboxDatabase -Server <ServerName> | Dismount-Database -Confirm:$False
   net stop msexchangeis /y
   

8. When the Microsoft Exchange Information Store service is stopped, copy the storage group folders that contain the mailbox databases and log files to a safe location. Then copy the storage group that contains the public folder database and its log files to a safe location.

9. Uninstall all Exchange-integrated applications according to the application vendor's removal instructions. The Microsoft Exchange Information Store service can be restarted by using net start msexchangeis if this service is required for removal of an Exchange-integrated application.

10. Uninstall Exchange from the server. For detailed steps to uninstall Exchange 2007, see How to Completely Remove Exchange 2007 from a Server.

11. After Exchange Setup has completed the removal process, restart the computer, and then log on to the computer using an account with local administrative permissions.

12. If you plan on performing an in-place upgrade of the operating system, you must first uninstall Windows PowerShell from the server. To do this:

    1. Open the Windows Control Panel and navigate to Add or Remove Programs.

    2. Check the Show updates check box.

    3. Scroll down the list of installed applications and updates, select the update called Update for Windows Server 2003 (KB926139), and then click Remove.

    Note

    If the entry for Update for Windows Server 2003 (KB926139) is not present, it likely indicates that Service Pack 2 for Windows Server 2003 was installed after Windows PowerShell was installed. In this event, you must first uninstall Service Pack 2 for Windows Server 2003 before you can uninstall Windows PowerShell.

    Note

    There may be other applications or Windows components that must be installed before you can upgrade Windows Server 2003 in-place to Windows Server 2008. A compatibility check will be performed during the installation of Windows Server 2008 which will advise you if additional applications or components must be removed.

13. At this point, you can continue with an in-place upgrade of the operating system, or you can reformat the drive and perform a fresh install of Windows Server 2008. We recommend a fresh install of Windows Server 2008 instead of an in-place upgrade. However, both scenarios are supported.

    Note

    If you are performing a fresh install, we recommend that you use the original server name for the new server. In addition, if the original server has a public folder database that will be restored to the new server, you must build the new server by using the original server name, or you will be unable to re-provision your public folder database on the new server.

14. After Windows Server 2008 has been installed, you can install the necessary prerequisites for running Exchange 2007 SP1 on Windows Server 2008. For detailed steps to install the prerequisites for each server role, see How to Install Exchange 2007 SP1 and SP2 Prerequisites on Windows Server 2008 or Windows Vista.

15. When the prerequisites for running Exchange 2007 SP1 on Windows Server 2008 have been installed, you can install the Exchange 2007 server roles. For detailed steps to install one or more server roles, see Deploying Server Roles. We also recommend that you visit Microsoft Update to download any critical or recommended updates for the new server.

16. After the required server roles have been installed, and after the system has been restarted, you can continue with the reconfiguration of settings for each of the server roles, and with putting your databases back into production. When recreating configuration settings, make sure that you refer to the OriginalServerName.txt file which was created in step 2 of this procedure.

    Client Access server role:

    1. Run the ExportCASConfig.ps1 script on the new server to collect its configuration information in a second XML file.

    2. Compare the two XML files by using Microsoft WinDiff (Windiff.exe), which is included with both Windows Server 2003 and Windows Server 2008. For more information about how to use WinDiff, see Microsoft Knowledge Base article 159214, How to Use the Windiff.exe Utility. By comparing the configuration files captured from each system, you will be able to more readily discern changes and missing settings, which can then be manually reconfigured on the new server.

    3. After you have manually reconfigured the settings for the collected configuration information, on the new server, you must manually reconfigure the remaining settings that are not captured by the script, including information in the Web.config file, SSL settings, Web site bindings, certificates and certificate mappings, and HTTP redirects.

    4. If the private key for the SSL certificates on the original server is marked as exportable, you can export the certificate(s) and then import them into the new server. For detailed steps to export a certificate from IIS 6.0, see Export a Server Certificate (IIS 6.0). For detailed steps to import a certificate into IIS 7.0, see IIS 7.0: Import a Server Certificate.

    Hub Transport server role:

    1. Any custom changes made to the Client Connector and Default Connector on the original Hub Transport server must be manually re-created on the new Hub Transport server.

    2. Any custom connectors created on the original Hub Transport server must also be manually re-created on the new Hub Transport server.

    3. Reconfigure any Send connectors as necessary. For detailed steps to reconfigure a Send connector, see How to Modify the Configuration of a Send Connector.

    Mailbox server role:

    1. Reconfigure the storage groups as necessary so that they match the storage groups used by the original server.

    2. Use database portability to migrate the mailbox databases into the new production environment. For more information about database portability, see Database Portability.

    3. When all mailbox databases have been migrated using database portability, they should be mounted so that you can reconnect users to their mailboxes. You can use the Mount-Database cmdlet to mount the mailbox databases. For more information about the Mount-Database cmdlet, see Mount-Database.

    4. Re-connect all mailboxes on each mailbox database. You can use the Exchange Management Shell to get disconnection statistics for a specific database and then pipeline those results to the Connect-Mailbox cmdlet. For example, to re-connect all mailboxes that are stored in mailbox database MBX1 in storage group SG1 on server Server01:

       Get-MailboxStatistics | Where {$_.DisconnectDate -ne $null} | Connect-Mailbox -Database "Server01\SG1\MBX1"
       

    5. Create a new storage group and public folder database by using the same storage group and database names and paths that were used on the original Mailbox server. After the new public folder database has been created, dismount it, and then delete all the files in the public folder storage group and database folders. Copy your original public folder database and log files to the appropriate storage group and database locations for the public folder database.

    6. After the public folder database and log files have been copied to the appropriate destination folders, the database can be mounted using the Mount-Database cmdlet.

    Unified Messaging server role:

    1. Re-create any Dial Plans as necessary, and configure the server to join the new Dial Plan.

    2. Copy all files for the prompt publishing point from the safe location to the ExchangeUM share on the UM server. For example, you would use the following command to copy all files for the existing prompt publishing point from UMSave on Server2 to the newly rebuilt Server1:

       xcopy \\Server2\UMSave \\Server1\ExchangeUM /s /e
       

    3. On the new Unified Messaging server, run the Update-FileDistributionService cmdlet, which forces the files to be copied immediately.

    4. Update the dial plan configuration to refer to the new publishing point. For example, if Server1 in domain.com contains the prompt publishing point, you would run the following command:

       $dp = Get-UMDialPlan MyDP
       $dp.PromptPublishingPoint = \\server1.domain.com\ExchangeUM
       $dp | Set-UMDialPlan
       

17. After each server role has been re-created on the new server, but before the server is put back into production, we recommend that you do the following:

    1. Run the Exchange Server Best Practices Analyzer tool and check for any configuration warnings or errors

    2. Take a full and complete backup of the server.

    Note

    Windows Server Backup in Windows Server 2008 no longer supports Exchange-aware backups or restores. Unlike earlier versions of Windows Backup, you cannot make or restore streaming backups of Exchange by using Windows Server Backup. To back up and restore Exchange 2007 SP1 on Windows Server 2008 you must use an Exchange-aware application that supports the Volume Shadow Copy Service (VSS) writer for Exchange 2007, such as Microsoft System Center Data Protection Manager, a third-party Exchange-aware VSS-based application, or a third-party Exchange-aware application that uses the streaming backup APIs locally on the Exchange server to make a backup locally on the Exchange server.

For More Information

For more information about Exchange 2007 SP1 and Windows Server 2008, see the following links and resources:

• Exchange Server and Windows Server 2008

• Mission Impossible: In-Place Upgrading Microsoft Exchange Server 2007 from Windows Server 2003 to Windows Server 2008

• What's New in Exchange Server 2007 SP1

• How to Install Exchange 2007 SP1 Prerequisites on Windows Server 2008 and Windows Vista

• Installing Cluster Continuous Replication on Windows Server 2008

• Installing Single Copy Clusters on Windows Server 2008

• IPv6 Support in Exchange 2007 SP1

• New High Availability Features in Exchange 2007 SP1

• Windows Server 2008 TechCenter

• Windows Server 2008 Webcasts & Chats

Scott Schnoll - Principal Technical Writer, Microsoft Exchange Server