If you would like to read the other parts in this article series please go to:
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 1)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 2)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 3)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 4)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 5)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 6)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 7)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 8)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 9)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 10)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 11)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 13)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 14)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 15)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 16)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 17)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 18)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 19)
In the previous part of this series we completed the base configuration of our Exchange 2010 staging server that will serve as the bridge to get us over from Exchange 2003 to Exchange 2013.
Preparing for Exchange 2010 Migration
Removing the Exchange 2010 Public Folder Database
Traditionally when migrating form Exchange 2003 to Exchange 2010, Public Folders have been migrated as part of the move. To keep the migration simple, we’ve decided that our example organization, Lisa Jane Designs doesn’t want to keep Public Folders and therefore we are not going to add unnecessary complexity to the migration.
On installation of Exchange 2010 it creates a new Public Folder database and creates a couple of system public folders. We’ll move these off the server and then remove the database.
To do this we are best using the Exchange Management Shell. After launching it, change directory to the Exchange Scripts directory and then use the MoveAllReplicas.ps1 script to move everything off the Exchange 2010 server:
cd $exscripts .\MoveAllReplicas.ps1 -Server LJD-E1401 -NewServer LJD-E2003BE |
Figure 1: Moving Public Folder replicas away from Exchange 2010
Moving these basic system folders shouldn’t be much trouble, but expect to wait the default 15 minutes for replication. You can check the progress using the Get-PublicFolderStatistics command:
Get-PublicFolderStatistics -Server LJD-E1401 |
Figure 2: Verification that no Public Folder replicas exist on Exchange 2010
As soon as Get-PublicFolderStatistics shows no output we are ready to remove the database. In the Exchange Management Console simply right click the Public Folder Database, and choose Remove:
Figure 3: Removing the Default Public Folder database on Exchange 2010
Mounting Mailbox Databases
Our final configuration task is to mount the new Mailbox Databases. Either use the Exchange Management Console to mount each one individually by right clicking each database and choosing Mount:
Figure 4: Mounting Databases using the EMC
Alternatively if you have quite a few Mailbox Databases to mount, use the Exchange Management Shell:
Get-MailboxDatabase –Server LJD-E1401 | Mount-Database |
Figure 5: Mounting Databases using PowerShell
Updating Email Address Policies
Next, we’ll perform some standard housekeeping common to any Exchange 2003 to 2010 upgrade by updating Exchange objects from Exchange 2003. We’ll start with email address policies. For more complex scenarios, you will have to examine changing from LDAP filters to OPATH filters, but if you are using a single default email address policy you can upgrade it using the following cmdlets:
Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients |
In the example below you will see this is generally very straightforward, but irreversible:
Figure 6: Upgrading Email Address Policies
Updating Address Lists
Next we’ll upgrade our Address List from Exchange 2003. We’ll start by upgrading the Global Address List, which if it’s using the defaults will be upgraded using the following command:
Set-GlobalAddressList “Default Global Address List” -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq ‘user’ -or ObjectClass -eq ‘contact’ -or ObjectClass -eq ‘msExchSystemMailbox’ -or ObjectClass -eq ‘msExchDynamicDistributionList’ -or ObjectClass -eq ‘group’ -or ObjectClass -eq ‘publicFolder’))} |
Figure 7: Upgrading the Global Address List
Next, we’ll upgrade each default address list using the set of commands below. If you’ve added custom address lists to your Exchange 2003 organization, you’ll also need to upgrade those by reconfiguring the scope for each Address List using the Exchange 2010 syntax:
Set-AddressList “Public Folders” -RecipientFilter { RecipientType -eq ‘PublicFolder’ } Set-AddressList “All Contacts” -IncludedRecipients MailContacts Set-AddressList “All Groups” -IncludedRecipients MailGroups Set-AddressList “All Users” -IncludedRecipients MailboxUsers |
Figure 8: Upgrading Address Lists
Updating Distribution Groups
Our final collection of Active Directory objects with Exchange-related attributes to upgrade are Distribution Groups. These gain new features in newer version of Exchange, including message moderation and self-service joining and leaving. We’ll upgrade these simply by stamping the Distribution Groups with a newer object version, using the following command:
Get-DistributionGroup | Set-DistributionGroup |
Figure 9: Upgrading Distribution Groups
After completing upgrading Exchange objects to Exchange 2010, ensure you give the Exchange 2010 server some basic tests, including creating a test mailbox on Exchange 2010 and ensuring client connectivity and mail flow works as expected.
Updating Internal DNS records and external publishing
With our Exchange 2010 server installed and working it is time to move over to client and SMTP connectivity to the Exchange 2010 staging server.
We’ll start by updating the internal name, mail.lisajanedesigns.co.uk, so that it points at the Exchange 2010 server rather than the Exchange 2003 Front-End server. We’ll also add the Autodiscover name, Autodiscover.lisajanedesigns.co.uk:
Figure 10: Creating additional DNS records and switching service names
After updating internal DNS records, re-test client connectivity. If these tests succeed, update external publishing rules for Exchange 2003 so that they are re-pointed at Exchange 2010. Remember, we’re not providing coexistence with Exchange 2003 for services like Outlook Web App, and instead will solely rely on Exchange 2010 proxy functionality for Exchange ActiveSync coexistence.
Updating Inbound Mail Routing
Our Exchange 2010 staging server should be capable of receiving email and delivering it to both Exchange 2003 and Exchange 2010 mailboxes. Before external publishing for SMTP (or a spam filter in-between) can be switched over we’ll need to enable Anonymous connections to the Hub Transport role.
We can accomplish this a few ways; firstly by creating a dedicated receive connector solely for Internet mail. We can instead follow the method used in Exchange 2013 (which is equally valid here) and configure the Default receive connector to allow anonymous connections, in addition to secure connections.
To make this change, navigate to Server Configuration>Hub Transport and select the Exchange 2010 staging server from the list. In the Receive Connectors tab you’ll see the Default receive connector. Select it, then choose Properties:
Figure 11: Selecting the new Default Receive Connector
Next, select the Permission Groups tab from the properties window. Then select the checkbox for Anonymous users within the Specify who is allowed to connect to this receive connector:
Figure 12: Enabling inbound Internet mail by allowing Anonymous mail to be received
After making this change you’ll find inbound mail directed to the Exchange 2010 staging server from external recipients should be received successfully both by Exchange 2010, and by Exchange 2003 mailboxes. After testing, switch your inbound mail flow over to the Exchange 2010 staging server either on your firewall or anti-spam appliance – whichever is most appropriate.
Updating Outbound Mail Routing
With inbound mail now routing via our Exchange 2010 staging sever, our next step is to switch outbound mail flow so it makes its way to the Internet through Exchange 2010 too.
Depending on your configuration, you’ll need to tweak this step slightly (for example, if you have multiple connectors for partners) and ensure any firewall rules or spam relay rules that apply to Exchange 2003 to allow outbound mail on port 25 are configured to allow the Exchange 2010 server to send mail.
After ensuring these rules are in place, we’ll create the replacement Send Connector(s) on our Exchange 2010 staging server. The good news is we’ll only need to do this once, as once we have Exchange 2013 installed we can switch these connectors straight over to the final server.
To begin, navigate to Organization Configuration > Hub Transport and select the Send Connectors tab. You’ll see the Exchange 2003 connectors listed, though you won’t be able to edit them. To create our replacement Second Connector, choose New Send Connector:
Figure 13: Viewing and modifying send connectors
We’ll then follow through the New Send Connector wizard. We’ll give this a name that closely matches the Exchange 2003 connector so its purpose is easily recognizable. For the most basic purposes you can choose an intended use of Internet (which will use the setting we’ll configure manually here) but for most purposes – such as where we relay through an anti-spam provider we’ll choose Custom:
Figure 14: Starting the New Send Connector wizard
We’ll then replicate the address space settings from our Exchange 2003 connector; in this case our simple Internet send connector routes all mail, signified by *:
Figure 15: Adding the address space for the duplicate connector
On the Network Settings page of the wizard we’ll then set the correct method for routing mail. Again, this should match your Exchange 2003 connector and is typically either the IP or DNS name of a smart host, or to deliver mail directly to other Internet email servers by using DNS MX records:
Figure 16: Selecting routing options for the Send Connector
Finally we’ll specify the Exchange 2010 staging server, LJD-E1401 as the source server to signify that it should be responsible for mail that will route via this connector:
Figure 17: Choosing the correct Source Server
After finishing the wizard we’ll then see two connectors listed in Exchange 2003. These will both initially show as Enabled:
Figure 18: Viewing duplicate connectors on Exchange 2003 and 2010
After verification that an Exchange 2010 test mailbox can send mail to the Internet via this Send Connector, we’ll then remove the original connector from the Exchange 2003 server. To do this we’ll connect to one of our Exchange 2003 servers and open the Exchange System Manager, then navigate into the Administrative Group, select Routing Groups and then within Connectors choose the original Exchange 2003 connector. Right click the connector and choose Delete:
Figure 19: Removing the Exchange 2003 connector
After a few minutes we should see that the original connector no longer appears within the Exchange Management Console on the Exchange 2010 staging server:
Figure 20: Verification that only Exchange 2010 connectors are present
Summary
In this part of the series we’ve ensured the server is ready for mailbox moves. In the next part of this series we’ll migrate mailboxes from Exchange 2003 over to Exchange 2010 and begin decommissioning our old Exchange 2003 servers.
If you would like to read the other parts in this article series please go to:
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 1)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 2)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 3)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 4)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 5)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 6)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 7)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 8)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 9)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 10)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 11)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 13)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 14)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 15)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 16)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 17)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 18)
- Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 19)