Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 13)

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

Migrating Mailboxes to Exchange 2010

Now we’ve successfully implemented our basic coexistence between Exchange 2003 and our Exchange 2010 staging server it’s time to move mailboxes across. Mailbox moves from Exchange 2003 to Exchange 2010 are offline moves, which means for the duration of the mailbox migration, users will not be able to access their mailbox, so consider migrating mailboxes out of working hours.

Migrating Mailboxes

Mailbox moves in Exchange 2010 are performed using Move Requests. This means rather than interactively moving a mailbox and keeping a console open for the duration of the moves, migrations are queued server side and managed by the Mailbox Replication Service.

We’ll move users over to Exchange 2010 in batches. The number of mailboxes you can schedule in one go is generally limited by the amount of log space you have available in between backups. For example, with our Exchange 2010 staging server in our example organization we have five 22GB log disks.

Each mailbox move will consume approximately the same amount of space in the log disk as the mailbox itself. This will be expunged at the next backup but does mean that if, for example, we move 22GB of mailboxes to DB01 the log disk will become full and the database will dismount.

We’ll also need to consider where mailboxes will be moved to. Our design for our example organization deliberately doesn’t assign individuals to databases, and instead assumes people will be split evenly across the infrastructure. Some designs may group users in databases into type, such as VIP or department. However this means the loss of a database will take out all of those users. An even split across databases allows you to reduce the impact of a database corruption or failure.

After deciding on your migration order and destination databases, open the Exchange Management Console and navigate to Recipient Configuration>Mailbox and select the mailboxes from the list. After selecting the mailboxes, choose New Local Move Request from the Actions pane:

Image
Figure 1: Selecting a batch of mailboxes to migrate

The New Local Move Request wizard will open. First, verify the list of mailboxes in your batch is correct, then in the Target Mailbox Database section select Browse to select the correct mailbox database:

Image
Figure 2: Selecting the target Mailbox Database

It’s not uncommon to find mailboxes have the odd corrupt item. However it’s best to know which items are corrupt before deciding to delete them. You can choose to skip mailboxes with corrupted items here, then review the mailbox move request report if any fail to find out how many corrupted messages you’ll need to skip later on:

Image
Figure 3: Choosing to skip corrupted mailboxes

Choose Next to step through the wizard and begin the migrations. After submitting the move requests, we’ll need to navigate to Recipient Configuration>Move Request to view progress. You’ll see the name of each Mailbox listed, along with the Move Request Status:

Image
Figure 4: Monitoring Move Request progress

Repeat this process until all mailboxes are migrated. To ensure log files are expunged between batches of migrations, either wait for the next application aware backup or schedule one manually.

After successfully migrating mailboxes, or before re-scheduling a failed move request remember to select the completed move requests and choose Clear Move Request:

Image
Figure 5: Clearing completed move requests

Decommissioning Exchange 2003

With all mailboxes moved over to Exchange 2010, we are ready to start the steps to decommission the Exchange 2003 servers in the organization. Before we begin we’ll make sure that no Outlook 2003 or earlier client is in use within the organization, as the removal of Public Folder databases will prevent them from connecting.

Migrating Offline Address Books

We’ll start over on the Exchange 2010 staging server, which we will use to move the Offline Address Book. Open the Exchange Management Console and navigate to Organization Configuration>Mailbox and select the Offline Address Book tab. Then right click each Offline Address Book and choose Move:

Image
Figure 6: Moving the Offline Address Book

We will the select the new Offline address book generation server. This will be our Exchange 2010 staging server:

Image
Figure 7: Selecting the Exchange 2010 staging server as the new OAB generation server

After changing the server that the Offline Address Book is generated on, we’ll force an update to generate it from the Exchange 2010 server before making any changes to the way it is distributed. To do this, simply right click the Offline Address Book and choose Update:

Image
Figure 8: Forcing an OAB Update

You’ll be able to monitor progress for the Offline Address Book generated in the Event Viewer, and after it completes right click the Offline Address Book and choose Properties, then choose the Distribution tab.

We’ll then ensure only Version 4 is selected in the Client Support section, and then in the Distribution Points, choose to Enable Web-base distribution, selecting our Exchange 2010 staging server and unselect Enable public folder distribution to remove the dependancy on Public Folders:

Image
Figure 9: Switching to web-based distribution

After making the changes, force a second Update of the Offline Address Book in the Exchange Admin Center:

Image
Figure 10: Forcing a second OAB Update after changing Distribution Settings

As before, examine the Windows Event Viewer to verify that the Offline Address Book build was successful.

Removing Client Access to Public Folder Databases

Although we’ve removed Public Folders from the databases, they still exist and are defined on each Exchange Server 2010 Mailbox Database. Before we remove the Public Folder Databases from the environment, we’ll ensure that Exchange 2010 Mailbox Databases no longer present them to clients.

We’ll need to use the ADSI Edit tool to achieve this. ADSI Edit is installed alongside the Active Directory administration tools in Windows Server 2008 and above, or installed from the support tolls in earlier versions of Windows Server.

Although it’s not a raw LDAP editor, it is similar as it allows us to directly edit attributes in Active Directory, bypassing applications like Exchange. We’ll need to use this tool now to clear the Public Folder database setting on each Database.

Before using ADSI Edit make sure you understand that by making an incorrect change you could break Exchange and other parts of Active Directory. Effectively it’s your AD-wide Registry. Always ensure you have a full and tested set of backups before making any changes.

We’ll launch ADSI Edit from our Exchange 2010 staging server by launching ADSIEdit.msc from the Run dialog box:

Image
Figure 11: Launching ADSIEdit.msc

ADSI Edit will launch, but won’t by default show us any information. We’ll need to right click Action and choose Connect to:

Image
Figure 12: Connecting to Active Directory

The Connection Settings window will open. Within the Select a well known Naming Context option, within Connection Point, select Configuration, then choose OK:

Image
Figure 13: Selecting the Configuration container

We’ll then see a tree-based view of the Configuration container in our Active Directory forest. Expand Configuration>Services>Microsoft Exchange and then expand your organization name, in our case Lisa Jane Designs:

Image
Figure 14: Expanding the Configuration container to find the Exchange org

Within our Exchange organization we’ll then need to expand Administrative Groups and open the Exchange Administrative Group (FYDIBOHF23SPDLT). Within the Exchange 2007+ administrative group, expand Databases and right click the first database and choose Properties:

Image
Figure 15: Selecting the Database properties

The Attribute Editor window will open. Scroll down to msExchHomePublicMDB, the attribute that specifies that the Mailbox Database uses a Public Folder Database, then choose Edit:

Image
Figure 16: Locating the Public Folder database setting

In the String Attribute Editor window that opens, choose Clear, then choose OK.

Image
Figure 17: Clearing the Public Folder database setting

Choose OK again to close the attribute editor, saving changes. Repeat this for each Exchange 2010 database. After you have finished, ensure clients can connect to Exchange without any issues.

Removing Exchange 2003 Mailbox Stores

The Exchange 2003 Mailbox Stores need to be removed from each Exchange 2003 server before it can be decommissioned. So long as you’ve removed the mailboxes from each Mailbox Store (usually accomplished as part of the migration) then removal will be straightforward.

To begin, connect to an Exchange 2003 server or workstation with the Exchange System Manager installed. Launch the ESM and navigate to you administrative group, then expand each relevant server’s storage group. In our case we’ve expanded LJD-E2003BE and LJD-E2003FE and then expanded the storage group. Right click each Mailbox Store, then choose Delete:

Image
Figure 18: Removing a Mailbox Store

Exchange 2003 will now check that the Mailbox Store does not contain mailboxes, and then provide you with an opportunity to confirm you wish to delete. If you are sure, agree to the confirmation. After a few moments you will be notified that the Mailbox Store has been removed:

Image
Figure 19: Verification a Mailbox Store has been successfully removed

Repeat this procedure for each Mailbox Store on Exchange 2003 servers until only the Public Folder Stores remain within Storage Groups.

Removing Public Folder Stores

As we’re ditching Public Folders for good (for simplicity, ironically) the next step is a little more complicated. Because the final replicas of some Public Folders, such as system folders, will remain we can’t just right click the Public Folder store and choose Delete as shown below:

Image
Figure 20: Attempting to delete a Public Folder store

We’ll instead need to remove the Public Folder using the tool used above, ADSI Edit. To ensure Exchange 2003 no longer knows about the Public Folder databases we will first confirm there’s nothing we need and it is fine to delete all remaining content. Then we’ll right click each Public Folder store and choose Dismount Store:

Image
Figure 21: Dismounting the Public Folder stores

Then, we will jump back over to the Exchange 2010 staging server or any other with ADSI Edit installed, and navigate back into the Configuration container and expand Services>Microsoft Exchange and open our Exchange organization.

We’ll then expand our Administrative Group containing Exchange 2003 servers, then navigate into Servers then under each server name expand the InformationStore container and then expand each Storage Group. If you compare the view here to the Exchange System manager you will see a lot of similarities.

After locating the Public Folder store, right click it within ADSI Edit, then choose Delete:

Image
Figure 22: Removing the AD object relating to the Public Folder store

Repeat this for each Public Folder database hosted on Exchange 2003. After removing all Public Folder databases, and waiting for Active Directory replication, restart the Microsoft Exchange Information Store on each server:

Image
Figure 23: Restarting the Exchange Information Store

Finally verify that the Public Folder databases are no longer shown in the Exchange System Manager by right clicking each Storage Group and choosing Refresh:

Image
Figure 24: Refreshing the contents of a Storage Group

If the removal is a success, no Public Folder storages should show and each Storage Group should be empty.

Summary

In this part of this series we’ve moved all mailboxes from Exchange 2003 to our Exchange 2010, moved services that relay on Exchange 2003 and removed old Information Stores. In the next part of this series we’ll complete our Exchange 2003 decommission and get ready to deploy Exchange 2013.

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

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top