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.

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.

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

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.

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.
   

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.
   

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.
   

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.
   

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.