In my previous two articles (part 1 & part 2) I explained how to integrate Exchange Server 2010 into an existing Exchange Server 2007 environment. The articles dealt with changing the message flow from the Exchange 2007 Hub Servers to the Exchange 2010 Hub Servers, and how the access methods are impacted when transitioning to Exchange 2010.
In this final article, I’ll explain the process of moving all your resources to Exchange Server 2010, and how to decommission the ‘old’ Exchange 2007 environment.
Moving mailboxes from Exchange 2007 to Exchange 2010 is relatively easy, especially in a transition process like our example. I actually explained the internals of moving mailboxes in a blogpost on SysAdmin-Talk some time ago.
As you are presumably aware, Exchange 2007 resources are managed from the Exchange 2007 management tools, i.e. the Exchange Management Console and the Management Shell. Exchange 2010 resources, on the other hand, are managed from the Exchange 2010 management tools, and you cannot manage Exchange 2007 resources from the Exchange 2010 management tools, or vice versa. The good thing is that if you are fortunate enough to have a management server, you can install the management tools of both versions on the same machine, and thereby save yourself some trouble.
To move mailboxes from Exchange 2007 to Exchange 2010, you have to initiate the move from the Exchange 2010 Management Shell or Management Console.
- Logon to the Exchange 2010 Server and open the Exchange Management Console.
- Navigate to the recipient configuration and click Mailbox. In the results pane, a list of mailboxes appear, and if there are a large number of mailboxes, then you can create a filter on the view. For example, you can view only the mailboxes in a particular mailbox database.
- In the results pane, select a mailbox, right-click on it, and select New Local Move Request…
- A wizard appears, pre-loaded with the mailbox you just selected. In the Target mailbox database field, select the Exchange 2010 Mailbox Database and click Next to continue;
- The next step is to specify what Exchange has to do when corrupt messages are found in the source (Exchange 2007) mailbox. It can skip the mailbox, which is the default, causing Exchange will stop moving the mailbox. You can also skip just the corrupted messages, but then you have to enter the maximum number of messages to skip. I usually leave this with its default setting, so when corrupted messages are found, the move process is skipped for that particular mailbox. Click Next to continue;
- A summary is shown and, when all is well, you can click New to actually start the Move Request. After 10 to 20 seconds, the move request is created and submitted, and the wizard is finished. The actual moving of mailbox data still has to start, as it is only the move request that has been initiated (the actual move will take place in the background). To view the status of the move request, select Move Request under recipient configuration in the Exchange Management Console. You can right-click on the move request to see its properties:
- When the mailbox is moved to Exchange 2010 while you (or rather, the user whose mailbox you just moved) have Outlook open, a message is shown when the actual move has finished saying the Outlook client has to be restarted:
- Restart Outlook for the changes to take effect and to continue working. To check if the Outlook client really connects to Exchange 2010, you can right-click on the Outlook icon in the system tray (in the bottom right of the screen) and select Connection Status;
- The client now connects to the Exchange 2010 Client Access Server, and from there to the Exchange 2010 Mailbox Server. Since Public Folder replication was setup earlier, the data is now retrieved from the Exchange 2010 Public Folder;
- Repeat steps 3 to 6 for all mailboxes still on Exchange 2007;
- When all mailboxes are successfully moved to Exchange Server 2010, the move requests need to be removed as well. In the Exchange Management Shell, under Recipient Configuration and Move Request, select all the move requests and click on Clear Move Request. Now all of the mailboxes are on Exchange Server 2010.
Moving other resources
In part II of this series, the Offline Address Book generation server was already moved to the Exchange 2010 Mailbox Server. Given that Address Lists, E-mail Address Policies, Accepted Domains etc are more or less the same in Exchange Server 2010, these do not need any attention at this point.
However, you do have to take care of Transport Rules and Journaling Rules. Normally, these are exported from Exchange 2007 and imported into Exchange 2010 when you install the Hub Transport Server role, but there are circumstances where you have to do this manually. To migrate Transport Rules from Exchange 2007, logon to the Exchange 2007 Hub Transport Server, open an Exchange Management Shell and enter the following command:
Export-TransportRuleCollection -FileName C:\Export_Transport_Rules.xml
Copy the resulting file to the Exchange 2010 Hub Transport Server, open an Exchange Management Shell and enter the following command:
[Byte]$Data = Get-Content -Path " C:\Export_Transport_Rules.xml " -Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data
When you open the Exchange 2010 Management Console, the Transport Rules will now be visible and functional on the Exchange 2010 Hub Transport Servers:
At this stage, you have essentially migrated your entire message environment from Exchange Server 2007 to Exchange Server 2010, so it’s time to look at decommissioning the old environment.
Removing Exchange Server 2007
To start with, since all Public Folders are replicated from Exchange Server 2007 to Exchange Server 2010, it’s time to decommission the Exchange 2007 Public Folder Database. You cannot just delete this Public Folder database since it still contains a replica of this data, and the Exchange 2007 Mailbox Database still has a referral to the Exchange 2007 Public Folder database. To remove the replica, there’s a script in the $exscripts directory on the Mailbox Server:
- Logon to the Exchange 2007 Mailbox Server and open the Exchange Management Console. Navigate to the Server Configuration and select Mailbox Server. In the results pane, select the Mailbox Database on the Exchange 2007 Server and open its properties. In the Client Settings tab, change the default Public Folder database referral to the Exchange 2010 Public Folder database referral.
- Next, logon to the Exchange 2010 Mailbox Server, open the Exchange Management Shell, and change to the scripts directory by entering the CD $exscripts command.
- Enter the following command to start the script which will move all replicas from Exchange 2007 to Exchange 2010:
1.\MoveAllReplicas.ps1 -Server 2007MBX -NewServer 2010MBX
The script will be finished in approximately 20 seconds, but it will only change the replication settings on the Public Folder databases. The actual Public Folder replication will take place when the script has finished, and this replication can take quite some time, depending on the amount of data in the Public Folders of course. I usually leave it running overnight and continue the next morning when everything has replicated out, but there are known scenario’s where replication took about 48 hours to complete.
- Running the MoveAllReplicas.ps1 script from the Exchange Server 2010 server actually touches the 2007 Public Folder database. Therefore, the Public Folder database cannot be removed anymore from within the Exchange Server 2007 Management Console; this process now fails with a “future version of Exchange” error message:
- To remove the Public Folder database from the Exchange 2007 server, logon to the Exchange 2010 Server, open the Management Shell and enter the following command:
1Get-PublicFolderDatabase -Identity "Public Folder Database" | Remove-PublicFolderDatabase
This will check the Public Folder Database for any Public Folder replicas and, if none are found (which should be the case of course since we removed this in step 2), the Public Folder database will be dismounted and removed:
- Now, when you check the Exchange 2007 Management Console, you’ll see that the Public Folder database has been removed;
- Remove the Exchange 2007 Mailbox Database as well.
Now that the Mailbox Database and the Public Folder Database are removed, the Exchange 2007 Mailbox Server can be removed. On the Exchange 2007 Mailbox Server, open the Control Panel and open the Applications option. In the results list, select the Exchange 2007 Server and select Uninstall. The setup application starts in “maintenance mode”, and you can just follow the wizard to uninstall Exchange Server 2007.
Before removing the Exchange 2007 Client Access and Hub Transport Server roles, make sure that no other clients are accessing the Client Access Server (naturally, they shouldn’t be, since we already removed the Exchange 2007 Mailbox Server. However, if clients do access the Exchange 2007 Client Access Server, it will result in an error message) or the Hub Transport Server (which can happen in scenario’s with applications that use SMTP relaying).
Once you’re sure that no clients are trying to access them, the Exchange 2007 Client Access Server and Hub Transport Server can be removed as well. Logon to these servers and open the Control Panel. Just like the Exchange 2007 Mailbox Server, select the Exchange 2007 Server option from the applications menu, and click Uninstall. The setup application will start in “maintenance mode” again, and you can follow the wizard to uninstall Exchange 2007 from these servers.
The only step left is to remove the “legacy publishing rule” from the Forefront TGM Server.
As a side note, it might be a good idea to install a recovery Active Directory and Exchange 2007 in your lab environment. In our sample environment, there’s a couple of years worth of backup database. When you need to restore one of these backups, for legal purposes for example, then it’s a good idea to have an up-and-running Exchange 2007 environment you can use to restore these old backups.
Edge Transport Server
The last server role that needs to be replaced (although this can be done earlier in the process, but preferably after the Exchange 2010 Hub Transport Servers are installed) is the Exchange 2010 Edge Transport Server.
The prerequisites for an Edge Transport Server are almost the same as a Hub Transport Server, except that it’s not normally a member of the (internal) domain. Also, you have to set a Fully Qualified Domain Name on the Edge Transport server before installing it.
Once all prerequisite software has been installed (Windows Server 2008 SP2 X64 or Windows Server 2008 R2, .NET Framework 3.5 SP1, PowerShell 2.0, Active Directory Lightweight Directory Services.), you can install Exchange 2010. Just like a regular Exchange 2010 Server, you can have the prerequisite software automatically install during the Exchange 2010 setup, but I prefer to do it myself in advance. This way, I have full control over the prerequisite installation and control the necessary reboots.
- On the new Exchange 2010 Edge Transport Server (to be), logon as an administrator and navigate to the installation media. Start the graphical setup application, setup.exe;
- Follow the wizard until you reach the Server Role Selection window, where you should select the Edge Transport Role. Note that as soon as you select this role, the other server roles are greyed out. You cannot combine the Edge Transport Server with any other server role;
- Check the Automatically install Windows Server roles and features required for Exchange Server check box, which will install server roles and features needed for Exchange Server. Click Next to continue;
- Follow the wizard and do the prerequisite check. If something is missing, it is reported here, and you can correct them. If needed, reboot the server and continue the wizard to install the Edge Transport Server role.
When the Edge Transport Server role has been installed, the server needs to be rebooted as well (or possibly again, depending on how much trouble you had installing the prerequisites). After rebooting, configure the Edge Transport Server anti-spam functionality as desired.
- When the server is fully operational, open an Exchange Management Shell and enter the following command:
1New-EdgeSubscription -FileName C:\Edge2010.xml
- A new subscription file is created, which you need to copy to the Exchange 2010 Hub Transport Server;
- Logon to the Exchange 2010 Hub Transport Server and open the Exchange Management Console. Navigate to the Organization Configuration and select Hub Transport. Select the Edge Subscription tab and remove the current Edge Subscription (with the Exchange 2007 Edge Transport Server). This will mean you don’t have any inbound or outbound SMTP services!
- In the Actions Pane, click New Edge Subscription and follow the wizard. Bind the Edge Subscription to the Active Directory site you’re using (the Default-First-Site-Name in a default configuration), and select the Edge2010.xml file we created earlier;
- When the Edge Subscription is created, open the Exchange Management Shell and enter the following command:
- The Edge Synchronization will now start. All you have to do now is reconfigure the SMTP mail flow from the external firewall to the Exchange 2010 Edge Transport Server and you’re back in business.
You can now safely remove the Exchange 2007 Edge Transport Server.
Decommission PST files
A typical migration scenario would be a transition from Exchange 2007 to Exchange 2010 (although the same it true of course a transition from Exchange 2003 to Exchange 2010), followed by decommissioning PST files. In the past, Exchange used to have relatively small mailboxes, and users would store data in PST files, which are always difficult from a SysAdmin’s perspective:
- PST files are stored on a local workstation, and are therefore not backed up;
- PST files are stored on a laptops, which can be easily stolen (security breach);
- PST files are stored on a network share, which is slow and not supported.
Exchange Server 2010 now offers the Personal Archive, and in SP1 it is possible to locate the Personal Archive on a different Mailbox database, even on a different Mailbox Server from the users’ primary mailboxes.
In an earlier article I explained how to deal with importing PST files in mailboxes or in the Personal Archive. The only downside of this process is that it’s command line only, which can be difficult for a Windows SysAdmin more used to GUIs. Red Gate now offers the PST Importer, which is a handy graphical tool for importing PST files directly into a mailbox or a mailbox’ Personal Archive.
The PST importer is a 32-bit application, but it can of course run on an X64 Exchange Server. The only thing is that it uses some Outlook DLLs, so your best option is to run it on a management workstation (X64) that has Outlook installed. Using this tool, you can either import the PST files immediately, or you can schedule the import to run off business hours.
There’s one (design) issue that you need to bear in mind in general when dealing with PST files. When designing your Exchange 2010 environment, especially the storage needed for the Mailbox Databases, please take into account the amount of PST data you’re likely to be managing. I am constantly impressed by the number of TB’s currently in use by PST files, and if you don’t design and provision properly, you’ll run out of disk space before your migration has finished!
In this series of three articles, I explained the process of how to transition from Exchange Server 2007 to Exchange Server 2010. Active Directory was changed and the Exchange 2010 Server roles were introduced in the CHUM (CAS, HUB, UM (not used) and Mailbox) order. The Edge can be upgraded anytime, but the best option is to do that after the introduction of the Exchange 2010 Hub Transport Server.
After decommissioning Exchange 2007, quite a lot of customers want to decommission PST files as well. You can use the default built-in functionality of Exchange Server 2010 (which works pretty well, but is PowerShell only) or you can try the Red Gate PST importer, which is much easier to use.