Tuesday, November 4, 2008

Transitioning from Exchange 2000/2003 to Exchange Server 2007 (Part 3)

Transitioning from Exchange 2000/2003 to Exchange Server 2007 (Part 3)

If you would like to read the other parts in this article series please go to:

Replicating Public Folders

When deploying an Exchange 2007 Server with the Mailbox Server role installed into a legacy Exchange organization, Exchange Setup will create one Mailbox database and one Public Folder database on the respective server by default as can be seen in Figure 3.1 below.

Figure 3.1: Exchange 2007 Mailbox and Public Folder Database

The Public Folder database is created so that you can replicate any Public Folder data stored on your legacy Exchange servers to Exchange 2007. Even though you don’t use Public Folders to store data in your environment, there’s one other reason why you might want to keep the Public Folder database mounted on your Exchange 2007 Server. As some of you may already know, Exchange 2007 no longer uses a Public Folder (or more specifically a System Folder named SCHEDULE+ FREE BUSY in your Public Folder hierarchy) to store free/busy information for the mailbox users in the organization. Instead free/busy information is stored directly in each user’s mailbox, and retrieved using a new web-based service called the Availability service. The advantage of this new approach is that there no longer are any 15 minute delays when free/busy time for a user is updated. Instead the update will happen instantly. So why would I want to keep the Public Folder database on my Exchange 2007 server, if free/busy information is retrieved using this new method? Well if you still have legacy Outlook clients (that is Outlook 2003 and earlier versions) running in your organization, these clients still need to use Public Folder method to retrieve free/busy information, since only Outlook 2007 supports the new Availability service.

If you don’t use Public Folders to store data and only have Outlook 2007 clients deployed in your organization, you can safely remove the Public Folder database, as you don’t have anything to use it for in that case. This also means you can skip the following steps.

Okay let’s get going with setting up a replica for the Public Folders on our Exchange 2003 Server that should be replicated with the new Exchange 2007 Public Folder database. In order to do so we must use either the Exchange 2003 System Manager or the Exchange Management Shell (EMS). For the purpose of this example we’ll use the Exchange 2003 System Manager.

Managing Public Folders using the Exchange Management Console (EMC) is not possible in Exchange 2007 RTM, but will be integrated with Exchange 2007 Service Pack 1.

To add the Exchange 2007 Public Folder database to the replica list on the Exchange 2003 Server, open the Exchange 2003 System Manager, then expand Administrative Groups > First Administrative Group > Folders > Public Folders as shown in Figure 3.2.

Figure 3.2: Public Folders in the Exchange 2003 System Manager

Now open the property page of each public folder, then click the Replication tab and add the Exchange 2007 to the replica list as shown in Figure 3.3.

Figure 3.3: Public Folder Replication Tab

Exchange 2003 Service Pack 2 introduced a new Public Folder Settings Wizard which makes it a breeze to add servers to replica lists. So if you have a lot of Public Folders in your Public Folder tree, I highly recommend you use this wizard, which you can read more about in a previous article of mine. If you have thousands of Public Folders, you might want to use the Public Folder replica scripts located in the Exchange Scripts folder (which can be found under C:\Program Files\Microsoft\Exchange Server).

Even though you still have legacy Outlook clients (Outlook 2003 and earlier) in your organization, you don’t need to set up a replica for the SCHEDULE+ FREE BUSY or the OFFLINE ADDRESS BOOK system folder. This will be done automatically when deploying an Exchange 2007 Server in a legacy Exchange organization.

When all Public Folders have been replicated to the Exchange 2007 Server, you should remove the old Exchange 2000 or 2003 Server(s) from the replica lists. When any Public folder data has been removed from the respective Public folder instances, you can dismount the old Public Folder stores (E2k3 SP2 won’t let you remove the Public Folder store until the data is gone and it won’t get removed while it’s dismounted). You should verify that your clients are still capable of seeing Public Folder data as well as free/busy information and accessing the offline address book before you delete it though. If this is not the case, I recommend you wait a little longer so that you’re sure the replication has occurred properly.

Outlook Web Access (OWA) 2007 doesn’t include a GUI for accessing Public Folders, so in order to access Public Folders using Internet Explorer you must open a separate browser window and type https://FQDN/public. It’s important you’re aware of this missing feature!

Pointing Internet Clients to the Client Access Server

Now would be a good time to point any Internet clients that are OWA, EAS and RPC over HTTP (now called Outlook AnyWhere) in your organization to the Client Access Server running on the Exchange 2007 Server. If you’re using a firewall such as ISA server (which you do, right?), this change is done at your ISA Server firewall. If you for some reason don’t use an ISA Server in your DMZ, but perhaps a Check Point Firewall 1 or a wannabe firewall such as a Cisco PIX, you should do the redirection there. If you don’t have a firewall you should make the change on the external DNS server hosting your Internet domain.

If your ISA Server is configured to pre-authenticate your OWA users, you must change the Authentication method for the OWA virtual directory under Server Configuration > Client Access in the EMC to basic authentication, since it’s configured to use forms-based authentication by default.

So will any users with a mailbox on my Exchange 2000 or 2003 Server still be able to use OWA, Exchange ActiveSync or Outlook AnyWhere (formerly known as RPC over HTTP) to access their mailbox? Yes this will work just fine since the Client Access Server is backward compatible and will redirect the clients to the respective legacy mailboxes on the Exchange 2000 or 2003 server.

When you perform the above changes, your users will no longer be able to access their mailbox using Outlook Mobile Access (OMA), as OMA has been discontinued in Exchange 2007.

Moving Legacy Mailboxes to Exchange 2007

Alright we have reached the part where we’re going to move our legacy mailboxes from Exchange 2000 or 2003 Server to Exchange 2007. Doing so is a straightforward process and can be done using either the Move Mailbox wizard in the Exchange Management Console (EMC) or the Move-Mailbox cmdlet in the Exchange Management Shell (EMS). For the purpose of this article series we’ll use the EMC. So if it’s not already open, launch the EMC, then expand the Recipient Configuration work center and click the Mailbox sub-node. Now highlight all the legacy mailboxes as shown in Figure 3.4, and then click the Move Mailbox task in the Action Pane.

Figure 3.4: Selecting Legacy Mailboxes in the Exchange Management Console

This will launch the Exchange 2007 Move Mailbox wizard, where you need to specify the destination server, storage group and mailbox database. Select the Exchange 2007 Server in the drop down box (Figure 3.5), and then click Next.

Figure 3.5: Specifying the Exchange 2007 Server as the Destination Server

Now specify how you want to manage any corrupted messages found in a mailbox (Figure 3.6), then click Next.

Figure 3.6: Specifying how corrupted messages in mailboxes should be managed

On the Move Schedule screen shown in Figure 3.7, select Immediately (unless you want the mailboxes to be moved automatically at a later time) and click Next.

Figure 3.7: Move Mailbox Scheduling Options

Finally click Move in order to start moving the legacy mailboxes to the Exchange 2007 Server (Figure 3.8).

Figure 3.8: Move Mailboxes Summary Page

As is the case with the Move Mailbox wizard in Exchange 2003, the Exchange 2007 Move Mailbox wizard can move 4 mailboxes at a time, and only one instance of the wizard can run on a server.

When all the mailboxes have been moved to the Exchange 2007 Server click Finish in order to exit the Move Mailbox wizard, and then check that mail flow to/from the Internet to the mailboxes on the Exchange 2007 works as expected.

If you will be running in a co-existence environment for a period of time, it’s important to understand that mailboxes stored on an Exchange 2007 server must not be managed using the Active Directory Users and Computers (ADUC) MMC snap-in, but instead must be managed using the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). However Exchange 2003 mailboxes can still be managed using ADUC.

If you want to move the Mailboxes using the Exchange Management Shell (EMS), you do so using the Move-Mailbox cmdlet. Using the Move-Mailbox cmdlet gives you a set of advanced options, among which the most interesting one is the option of specifying the number of mailboxes to be moved at a time (as you read earlier the Move Mailbox wizard is limited to 4).

Redirecting Inbound Mail to the Exchange 2007 Server

When all legacy mailboxes have been moved to the Exchange 2007 Server, we can point SMTP traffic (port 25/TCP) directly to the Exchange 2007 Server, so that inbound messages are routed directly to this server. It’s recommended to deploy an Edge Transport Server in your perimeter network (aka DMZ), and let this server route inbound messages to the Exchange 2007 server on your internal network. Instructions on how to deploy an Edge Transport server is outside the scope of this article series, but I’ll cover that topic in another article in the near future. If you don’t want to deploy an Edge Transport server, you should bear in mind that you need to change the Permission Groups settings on the Default receive connector under the Server Configuration work center node> Hub Transport sub-node in the EMC so Anonymous users are allowed to connect to the Exchange 2007 Server as shown in Figure 3.9, otherwise you won’t be able to receive e-mail messages from other SMTP servers on the Internet.

Figure 3.9: Permission Groups Settings on the Default Receive Connector

In addition you should make sure that any Send Connectors under Organization Configuration > Hub Transport > Send Connector tab are configured so that they can send outbound mail (either using a smart host or DNS MX) properly (Figure 3.10).

Figure 3.10: Send Connector Settings

When the necessary changes have been made, we can delete the routing group connector which was set up to establish mail flow between the Exchange 2003 and 2007 Routing Groups. In order to do so you should expand Administrative Groups > First Administrative Group > Routing Groups > Connectors and right-click on the respective Routing Group Connector then select Delete in the context menu as shown in Figure 3.11.

Officialy the correct way of deleting the routing group connectors is to use the Remove-RoutingGroupConnector cmdlet, but since Exchange 2003 version blocking doesn’t block deletes, you can also use the Exchange 2003 System Manager as well.

Figure 3.11: Deleting the Routing Groups Connector

Since the Routing Group connector won’t be deleted in both ends, you also need to delete it under the Exchange Administrative Group (FYDIBOHF23SPDLT) > Exchange Routing Group (DWBGZMFD01QNBJR) > Connectors.

Decommissioning Exchange Legacy Servers

The final step is to decommission the Exchange 2000 or 2003 Server and we can consider the transition done. The Exchange 2003 server should be removed using the Exchange 2003 Setup program, which can be launched via Add or Remove Programs (Figure 3.12).

Figure 3.12: Add or Remove Programs

But before you begin uninstalling the Exchange 2003 Server, we first need to assign the Recipient Update Service (RUS) to our Exchange 2007 Server. Not because RUS should be used (in fact Exchange 2007 no longer uses RUS), but because the Exchange 2003 Setup program won’t let us uninstall Exchange 2003, before RUS has been assigned to another server. In order to assign RUS to the Exchange 2007 Server, open the Exchange 2003 System Manager, then expand the Recipients node and select Recipient Update Services. Now open the property page both for Recipient Update Service (Enterprise Configuration) and Recipient Update Service (domain), then click the Browse button under the Exchange Server text box and specify the Exchange 2007 Server instead, then click OK twice and close the System Manager as shown in Figure 3.13.

It's important you don't delete the recipient policies in the Exchange 2003 System Manager, since Exchange 2007 uses them when provisioning users.

Figure 3.13: Assigning the Recipient Update Service to the Exchange 2007 Server

Microsoft will release an Exchange 2003 hotfix, which will prevent one from reassigning the RUS to an Exchange 2007 server some time in the future. The reason being, this really is an invalid setting that should be blocked. Instead the recommendation will be to use ADSIedit to remove the enterprise RUS object.

Now we can continue uninstalling the server, so select Microsoft Exchange then click the Change/Remove button.

The Exchange 2000 or 2003 wizard will appear, click Next then select Remove in the Action dropdown box as shown in Figure 3.14. Click Next.

If your organization relies heavily on Public Folders, you might want to leave the Exchange System Management Tools intact, as you can use them to administer Public folders on your Exchange 2007 server. Remember Exchange 2007 doesn't have a UI for Public Folder Management.

Figure 3.14: Exchange 2003 Installation Wizard Component Selection Page

On the Installation Summary page click Next and wait for the Exchange 2003 uninstallation process to complete (Figure 3.15).

If the Exchange 2000 Setup files aren’t located on an accessible drive, network share, you will be prompted to insert the Exchange 2003 CD media during the uninstallation process.

Figure 3.15: Exchange 2003 Uninstallation Process

When the uninstallation process has completed click Finish to exit the Exchange 2003 Setup wizard (Figure 3.16).

Figure 3.16: Exchange 2003 Successfully Uninstalled

Alright we’re done!

If the Exchange 2003 uninstallation for some reason fails, it may be necessary to remove the Exchange 2003 Server by deleting the Server object in the Exchange System Manager or even via ADSIEdit if this isn’t possible. But please don't delete the respective legacy (Exchange 2003) Administrative Group, as the user's legacyDNs still points there, even though their mailboxes are being moved in a native organization.


Doing a transition from an Exchange 2000 or 2003 Server to an Exchange 2007 in the same Active Directory Forest is a straightforward process, and since Exchange 2007 co-exists just fine with legacy Exchange servers, you can do the transition at your own pace. Co-existence support is laudable as a transition process typically happens in several phases. This is especially true if you’re going to do a transition from multiple legacy Exchange Servers to multiple Exchange 2007 Servers.

I like the fact that the Exchange 2007 Setup wizard knows when Exchange 2007 is deployed in an existing legacy Exchange organization, and in this case prompts you to create a routing group connector so that mail flow is established between the legacy routing group and the Exchange 2007 routing group. It’s also nice to see that Exchange 2007 Setup, in this case, creates a Public Folder database and automatically adds the Exchange 2007 Server to the OFFLINE ADDRESS BOOK and SCHEDULE+ FREE BUSY system folders replica lists, so you only have to concentrate on replicating Public Folders.

Finally it’s a real pleasure working with the Exchange 2007 Move Mailbox wizard (or Move-Mailbox cmdlet) in order to move legacy mailboxes to an Exchange 2007 Mailbox Server, but I must admit, support for Public Folder management in the Exchange 2007 Management Console GUI is missed.

A big thank you to Evan Dodds (Program Manager in the Exchange Admin/SysMgmt team) and Nino Bilic for spending time on reviewing this article.

If you would like to read the other parts in this article series please go to:

No comments: