WinDeveloper O365 Mailer FREE for 1 Year

WinDeveloper IMF Tune
WinDeveloper IMF Tune

Upgrading from Exchange 2007 to 2010

Vladimir Meloski [MCSE, MCITP, MCT, MVP]

Vladimir Meloski [MCSE, MCITP, MCT, MVP] Photo

Vladimir Meloski is a Microsoft Certified Trainer and Most Valuable Professional on Exchange Server. He is a consultant, providing unified communications and infrastructure solutions based on Exchange Server and System Center. Vladimir has been involved in Microsoft Conferences in Europe and US as a Speaker, Proctor for Hands on Labs and Expert.

Cast your Vote
Poor Excellent

In this article we will describe the process of upgrading an Exchange organization from version 2007 to 2010. We start from the introduction of the first Exchange 2010 server and complete it with the decommissioning of the last Exchange 2007 server.

Microsoft Exchange Server 2010 brings a new set of great technologies. No surprise many are excited and looking forward to plan and deploy this new messaging infrastructure. Today we cover the basic steps that should be performed in organizations currently running Exchange 2007.

Prerequisites

Prerequisites that must be met before we start the deployment:

  • Windows Server 2003 SP2 or later, Global Catalog servers in each site where Exchange Servers are located and Windows Server 2003 forest functional level.

  • Exchange Organization must consist of servers running Exchange 2007 SP2

  • In place upgrade is not supported, thus new hardware should be installed for the Exchange 2010 Servers. Hardware requirements may be found at the following link:
    http://technet.microsoft.com/en-us/library/aa996719.aspx

  • Operating Systems supported are Windows Server 2008 SP2 64-bit and Windows Server 2008 R2 Standard or Enterprise. Please note that Exchange Server 2010 is 64-bit only, i.e. there is no 32-bit version available for testing purposes and there are no 32-bit management tools. Management tools should be installed on a 64-bit operating system too.

  • If the organization has multiple sites, the first site to introduce Exchange 2010 should be the internet facing site. The upgrade then continues with non-internet facing sites.

  • If the solution design requires installing Exchange 2010 roles on multiple servers, then these should be installed in the following order:

    1. Client Access Server role
    2. Hub Transport Server role
    3. Unified Messaging Server role (optional, may be deployed later)
    4. Mailbox Server role
    5. Edge Server role (optional, may be deployed later)

The Installation Process

The installation process requires Active Directory to be prepared. In order to do that, the user should be member of the Schema Admins and Enterprise Admins security groups.

We already explained Active Directory preparation process in our article Upgrading from Exchange 2003 to 2010, with one exception, the fact that we do not prepare Exchange legacy permissions (setup /PrepareLegacyExchangePermissions or setup /pl), so this command is not executed.

Note for detailed Active Directory preparation steps please check:
Prepare Active Directory and Domains

The Exchange 2010 installation steps were discussed in Installing Exchange 2010 Beta. Thus we proceed with the so called coexistence scenario i.e. the moment when there are both Exchange 2007 and 2010 versions present in our organization. During the coexistence, you should manage each version of Exchange Server with its own Exchange Management Console.

Client Access Server Role Coexistence

So far we completed the Exchange 2010 setup. We now configure the server roles.

During the coexistence phase, we should change some DNS settings to provide a seamless transition. Let's assume our current Exchange 2007 server is accessed by name mail.company.com. After installing Exchange 2010, a legacy name should be assigned to identify the Exchange 2007 infrastructure, for example we use legacyname.company.com. This is done both at the internal and external DNS namespaces. In addition, the current DNS host name (mail.company.com) is assigned to the new Exchange 2010 server. Thus clients won't use the legacy name, they still continue to access their mailboxes without changing settings.

A new certificate should be issued because of Exchange 2007 and Exchange 2010 coexistence. Wildcard certificates and certificates that support Subject Alternative Names may be used.

We will assume that the primary external namespace for virtual directories is configured during the setup (for example mail.company.com). Clients will use this name to connect from the Internet.

If our company uses Outlook Anywhere, it should be enabled from the Exchange Management Console or Exchange Management Shell using:
Enable-OutlookAnywhere -Server:MAIL2010 -ExternalHostName:mail.company.com -SSLOffloading $false

The Offline Address Book generation service should also be moved to Exchange 2010, and the distribution set to web-based on the CAS Role for clients running Outlook versions 2007 and above. From the Exchange Management Shell use the command that follows:
Move-OfflineAddressBook "Default Offline Address List" -Server MAIL2010

At this point in time, all clients are connecting to the new Exchange 2010 Client Access Server using the name mail.company.com. The mailboxes are still on Exchange 2007, so the Outlook Web Access experience is actually version 2007. They will connect to the new version of Outlook Web Access once their mailboxes are moved to Exchange 2010.

Hub Transport Server Coexistence

Same as Exchange 2007, Exchange 2010 provides two server roles for handling email transport, the Edge and Hub transport roles. Here we will consider the transition from the Exchange 2007 Hub Transport to the Exchange 2010 Hub Transport.

If planning to employ the Exchange 2010 Edge Transport please check the following article series. 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)

After installing Exchange 2010, the mail from/to the internet still flows through the Exchange 2007 Hub Transport server. 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 (possibly the Exchange Edge Transport) or firewall should point to the new Exchange 2010 Hub Transport server.

If no Exchange Edge server/SMTP Gateway is in place, the Hub transport must be configured to handle internet email directly from anonymous connections. Thus we allow the "Anonymous users" permission group. In this manner the Hub Transport accepts incoming emails from external SMTP servers.

Connector Permissions

Likewise if no outbound Edge server/Gateway is in place, we direct outbound traffic to the Internet from the Exchange 2010 Hub Transport. The Send Connector with * namespace should be modified such that the source server for the connector is the Exchange 2010 Hub Transport, instead of the current Exchange 2007 Hub Transport. This can be done from the Exchange Management Console or the Exchange Management Shell using the following command:
Set-SendConnector -Identity 'Internet Connector' -SourceTransportServers 'MAIL2010'

Mailbox Server Role Coexistence

At the Exchange 2010 Management Console, to identify mailboxes located on Exchange 2007, sort the console view by Database Name by adding the Database column.

Mailbox Database

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 2007, the user is not disconnected during the process. Online mailbox moves are discussed in Exchange 2010 Online Mailbox Move, a Deep Dive.

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 -Server MAIL2007 -Recurse | FL Name,Replicas

Here MAIL2007 is the Exchange 2007 Mailbox server.

The result of this cmdlet will display the public folder replicas that are currently located on Exchange 2007 server.

Next step is to move all replicas to Exchange 2010 server by running:
Moveallreplicas.ps1 -Server MAIL2007 -NewServer MAIL2010

MAIL2010 is the target Exchange 2010 Mailbox server.

The process can be monitored using the Exchange Management Shell command:
Get-PublicFolder -recurse | FL Name,Replicas

At the end, mailboxes and public folder databases on Exchange 2007 servers should be deleted using the Exchange Management Console, or Exchange Management Shell. 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, Exchange 2007 can be removed from Control Panel.

Uninstall Exchange 2007

Conclusion

Upgrading an Exchange Organization from version 2007 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 2007, 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

Microsoft Exchange Deployment Assistant

User Comments - Page 1 of 1

Lower costs?? Haha...uhm....ok...I found that comment rather amusing. Thanks for the article 13 Apr 2015 07:18
Microsoft pushing out the forced upgrades to lower people's operating costs. Comedic gold.
FDN 17 Oct 2012 22:06
Excellent article. Thanks for sharing!!!

Hope I can get your feedback with a couple of questions

We are in the process of transitioning our existing Exchange 2007 email system to Exchange 2010.
• Currently in our Exchange 2007 infrastructure we have 2 HUB-CAS 2007 Servers (both roles co-located) running in Windows NLB
 Our External Namespace: mail.domain.com
 NLB Cluster FQDN: mail.domain.com
 NLB VIP: 192.168.100.70
• We recently introduced 2 HUB-CAS 2010 Servers (both roles co-located) and the plan is also to set these servers up with Windows NLB. NOTE: During setup, we provided our existing external namespace (mail.domain.com) so the Exch 2010 external URLs are already populated with mail.domain.com
• We will also setup a new CAS Array with the 2 HUB-CAS 2010 Servers
• We will be using Slit DNS in order to use the same namespace (mail.domain.com) on both Internal and External URLs for OWA, ActiveSync, etc
• We will leverage a new namespace (legacy.domain.com) in order to support the co-existence between Exch 2007 and Exch 2010 while we move mailboxes and services from 2007 to 2010 as indicated here: http://blogs.technet.com/b/exchange/archive/2009/11/20/3408856.aspx
Our Goal: to use the same external namespace (mail.domain.com) for the Exchange 2010 Organization which is the namespace currently used by the existing Exchange 2007
I’m trying to figure out how to deal with the CAS 2007 NLB and the new CAS 2010 NLB during and after the co-existence period.
If I setup a new NLB with the 2 HUB-CAS 2010 Servers (since the Exch 2007 NLB needs to be kept during co-existence), I will have to come up with a new NLB FQDN, new NLB Cluster VIP and obviously new DNS entry for the new NLB FQDN. For example, the new NLB FQDN would be something like: webmail.domain.com
Questions:
1. What would be the best way to deal with these 2 NLBs (Exch 2007 CAS NLB and Exch 2010 CAS NLB) so I can keep the same namespace we are currently with existing Exchange 2007?
a. After performing the switchover from Exch 2007 to Exch 2010, can I replace the NLB FQDNs as follows:

i. Change the Exchange 2007 NLB FQDN from mail.domain.com to legacy.domain.com
ii. Change the Exchange 2010 NLB FQDN from webmail.domain.com to mail.domain.com

Is this supported?

2. If the above scenario is not supported, how can I deal with this so we keep the namespace mail.domain.com for our new Exch 2010 Org?
Please advice
Thanks in advance!

Copyright © 2005 - 2024 All rights reserved. ExchangeInbox.com is not affiliated with Microsoft Corporation