Hub Transport Server Coexistence
NOTE: If planning to employ the Exchange 2010 Edge Transport please skip this section. The following articles discuss deploying the Edge Transport server role. These were written for Exchange 2007 however they are still largely valid for Exchange 2010 as well:
Installing, Configuring Exchange 2007 Edge Server (Part 1)
Installing, Configuring Exchange 2007 Edge Server (Part 2)
Deploy an Edge Transport Server in an Existing Exchange Server 2003 Organization
Exchange 2010 provides two server roles for handling email transport, the Edge and Hub transport roles. In simple terms we can consider the Hub Transport to be the replacement for the Exchange 2003 transport functionality. Thus here we consider the transition from the Exchange 2003 transport to the Exchange 2010 Hub transport.
After installing Exchange 2010, the mail from/to the internet still flows through the Exchange 2003 bridgehead. In order to reroute the mail transport to go through the new Exchange 2010 Server, the inbound and outbound traffic should be reconfigured, depending on the company messaging infrastructure.
To allow inbound traffic from the internet, the SMTP gateway or firewall should point to the new Exchange 2010 Hub Transport server. In addition the Receive Connector at the Hub Transport should be configured to allow the "Anonymous users" permission group. In this manner the Hub Transport accepts incoming emails from external SMTP servers.
To allow outbound traffic to the Internet, a Send Connector with * namespace should be configured to route outgoing messages directly or using smart host. This can be done from the Exchange Management Console or the Exchange Management Shell using the following command:
new-SendConnector -Name 'Internet Connector' -Usage 'Internet' -AddressSpaces 'SMTP:*;1' -IsScopedConnector $false -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false -SourceTransportServers 'MAIL2010'
Mailbox Server Role Coexistence
At the Exchange 2010 Management Console, mailboxes located on Exchange 2003 Servers are classified as "Legacy Mailbox".
The process of moving mailboxes to Exchange 2010 is called Local Move Request (local is for moving within the same forest). When moving from Exchange 2003, the user is disconnected during the move process. Unfortunately online mailbox moves as discussed in Exchange 2010 Online Mailbox Move, a Deep Dive, are only possible if the source mailbox is located on Exchange 2007/2010.
Mailbox move requests can be performed using both Exchange Management Console and Exchange Management Shell. For example:
New-MoveRequest -Identity 'user@company.com' -TargetDatabase EX2010DB01
Once the mailboxes are moved, we should proceed with moving public folders. To discover public folder replicas, at the shell run the following:
Get-PublicFolder -recurse | FL Name,Replicas
The next step is to open the Exchange 2003 System Manager and to locate the Public Folder store database. Here right-click the database and choose Move All Replicas. When prompted to choose for a destination public folder database, select the one located on Exchange 2010.
The process can be monitored using the same Exchange Management Shell command:
Get-PublicFolder -recurse | FL Name,Replicas
The Exchange 2003 Recipient Update Service should also be reconfigured to use Exchange 2010 Servers. This is done from the Exchange System Manager.
At the end, mailboxes and public folder databases on Exchange 2003 servers should be deleted using the Exchange System Manager. This process does not delete the database files from the file system, so file deletion should be done manually.
When all resources are moved to the Exchange 2010 Servers, the routing group connectors between the Exchange 2003 and 2010 routing groups should be deleted using the Exchange 2003 System Manager.
Finally Exchange 2003 can be removed from Control Panel | Add Remove Programs on Windows 2003.
Conclusion
Upgrading an Exchange Organization from version 2003 to 2010 is a process that requires analyzing the current messaging infrastructure and designing the new one.
The two versions can coexist. If properly planned, keeping in mind legacy applications running on Exchange 2003, we can avoid service interruption.
At the end, introducing Exchange 2010 should allow us to lower costs and at the same time improve productivity.
References
Planning for Exchange 2010
Deploying Exchange 2010