Introduction
So far in parts one and two of this four-part article we’ve detailed the initial steps required to prepare for the removal of an Exchange 2003 server that is coexisting with an Exchange 2007 server. This has included the re-routing of Internet email, the moving of public folders and also the moving of the Offline Address Book via the Exchange Management Console. Before we move away from the Offline Address Book topic, let’s complete the overall picture by covering how you can move the Offline Address Book via the Exchange Management Shell as some administrators prefer this method.
Moving OAB via Management Shell
If you prefer to use the Exchange Management Shell to move the Offline Address Book, the cmdlet to use is the Move-OfflineAddressBook cmdlet. First you can run the Get-OfflineAddressBook cmdlet to list all OABs and if you pipe the results to the format-list cmdlet you get all the information you need about the various OABs. Take Figure 13 as an example, where you can see that the results of the Get-OfflineAddressBook | fl cmdlet shows that we have just a single OAB called Default Off line Address List as expected.
Figure 13: Offline Address Book List
To move the OAB generation server, note that it’s the Server parameter at the top of the listing in Figure 13 that we’re interested in and not the originating server parameter you see towards the bottom. Our full cmdlet is therefore:
Move-OfflineAddressBook “Default Offline Address List” –Server E2K7
The results of running this cmdlet are shown in Figure 14 where you can see that the only interaction we get is an “are you sure?” prompt and a friendly warning about a possible entire download of the OAB for all users.
Figure 14: Moving the Offline Address Book
Remove Mailbox and Public Folder Databases
Now it’s time to go back to public folders. Once you’ve confirmed that there are no longer any public folder replicas on the Exchange 2003 server, you can then remove the public folder database. If you try and do this with instances still on the database, you’ll receive the following error:
Figure 15: Unable to Remove Public Store
To remove the public folder database, right-click it in Exchange System Manager and choose Delete from the context menu. You will be prompted with a warning that informs you the public store is performing various roles and that these roles must be moved to an alternate public folder store. This warning is shown in Figure 16 below.
Figure 16: Public Store Roles
As you can see there is no choice but to select OK. Once you do this, you’ll be presented with another window that allows you to choose your alternate public store as you can see from Figure 17. In my example scenario, there is only one other server to choose from, the Exchange 2007 server, and therefore this has been selected.
You are then presented with a “Are you sure?” prompt before your public store is deleted from the Exchange 2003 server. A final prompt is then displayed informing you that although the store has been deleted from the Exchange 2003 configuration, the physical database files still reside on the server so it’s obviously a good idea to clean these up especially if the Exchange 2003 server won’t be decommissioned straight away.
Whilst you’re in the mood for database removal, and assuming you have actually moved all users from the Exchange 2003 server to the Exchange 2007 server, you can now remove the mailbox database from the Exchange 2003 server in the same manner if you want to. Of course, Exchange 2003 protects you in the scenario where mailboxes still exist on the server since when you try to delete the mailbox store you will receive the following error.
Figure 18: Unable to Remove Mailbox Store
Assuming that you have no mailboxes left on this mailbox store, you will receive the following warning when you attempt to delete it.
Figure 19: Mailbox Store Removal Warning
Assuming you are comfortable with the fact you have previously migrated the system folders across, proceed with the mailbox store removal. As per the public store removal, you are then presented with an “Are you sure?” prompt followed by the warning that the physical database files need to be manually removed from the server.
Routing Group Connectors
Now here’s a potentially scary part of the process. You’ll remember that when you install your Exchange 2007 servers into an existing Exchange 2003 organization, a new administrative group is created that contains all Exchange 2007 servers. This administrative group is called
Exchange Administrative Group (FYDIBOHF23SPDLT). Furthermore, you’ll also remember that when the first Exchange 2007 Hub Transport server is installed into an existing Exchange 2003 organization, a new two-way Routing Group Connector is created to allow mail flow between the Exchange 2003 and Exchange 2007 servers. These are highlighted in Figure 20 below where they are shown as seen from within the Exchange System Manager.
Figure 20: Two-Way Routing Group Connectors
Well, it’s now time to remove these Routing Group Connectors which you can do either with the legacy Exchange 2003 Exchange System Manager or, of course, the Exchange Management Shell. Since there are no users or public folder databases left on Exchange 2003, there is no need for messages to flow between the two servers. Let’s look at both methods so that you can pick your favorite.
In Exchange System Manager on your Exchange 2003 server, navigate to either one of the Connectors containers and select the Routing Group Connectors as shown above in Figure 20. It doesn’t really matter which side of the Routing Group Connector you delete first. Right-click the Routing Group Connector and choose Delete from the context menu. You will be presented with an “Are you sure?” prompt as normal after which the connector should be deleted. Repeat this process for the other side of the Routing Group Connector.
To do the same thing in the Exchange Management Shell, you need to use the Remove-RoutingGroupConnector cmdlet. There aren’t many parameters to add to this cmdlet but since the –Identity parameter includes the administrative group name as well as the routing group name the cmdlet does get quite long as you can see from the example below. Having said this, in my lab environment I could simply specify the identity as the names of the Routing Group Connectors without the administrative and routing group names and they were successfully deleted. However, I recommend that you use the full name to make sure you are targeting the correct Routing Group Connector. Since there are two sides to delete, the cmdlet must be run twice to specify each side of the Routing Group Connector to delete.
Remove-RoutingGroupConnector –Identity “First Administrative Group\First Routing Group\E2K3-E2K7”
Remove-RoutingGroupConnector –Identity “Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR\E2K7-E2K3”
