Cleanup
To have the best chance at success, you need to clean up your public folder environment before moving any data. Cleanup and reduction in content—for example, consolidation of folders and eliminating aging content—is important for several reasons: First, it's unlikely that this data will be cleaned up once it's on the new system; second, less content means fewer bytes on the network during migration; and third, fewer tools are available for cleaning up the data once it's in SharePoint. One of PFDAVAdmin's features is its ability to create a content report, which displays the number of items in, size of, and most recent modification of any folder. Using this information can help you identify old content or frequently used folders.
If a folder contains a large number of items, it probably isn't being used for collaboration. Consider moving the data to a file share or near-line archival storage. One reason to not use a document library for data storage is that SharePoint's document libraries don't perform effective enumeration beyond a thousand entries per folder. Therefore, if you migrate a public folder containing thousands of items to a single SharePoint list, performance latency will occur when someone navigates to that SharePoint list.
Next, identify folders that applications are using as data stores, for workflows, or for custom forms. No tools will identify such folders, but messaging administrators are likely already aware if any exist. When you identify an application folder, consider using alternative data stores— for example, you can use a database or leave the existing application in place until the environment is fully on Exchange 2007 and Office 2007. (SharePoint has completely different access APIs and object models, so there's no easy way to port existing code or forms.) These folders aren't good candidates for migration to SharePoint, and in general they're probably not a good long-term location for public folders, either.
Finally, to cut down on old content, consider turning on limits and aging, if you aren't already doing so. (See the Microsoft article "HOW TO: Configure Storage Limits on Public Folders in Exchange 2003" at http://support. microsoft.com/?kbid=823144.) You can set limits as a default for all folders, and you can override the limits on a per-folder basis. After you've cleaned up as much as possible and have identified critical folders, you're ready to begin the migration.
Exchange Extraction
Now, you're ready to extract content from Exchange public folders. You can install the Exchange Public Folder Extractor on any client machine that has .NET Framework 1.1 and Outlook configured for Collaboration Data Objects (CDO) 1.2.1. The account running the Extractor must have Read permissions to the Exchange public folders, as well as Write permissions to the output directory. For the purpose of this example, I'll demonstrate the interactive GUI, but you can also run the Extractor from the command line.
After you launch the Extractor, you'll need to fill in all the fields of the Exchange Public Folder Export Wizard's Exchange Settings tab, which Figure 2 shows. You select a folder from which to start the export, and you can either process all its child folders or select the Export only this folder check box to process only that folder. The Add Webpart check box specifies whether the target list will have a Web Part created on the SharePoint home page. If you don't select this check box, the SharePoint list will be available only on the SharePoint site's Quick Launch bar.
After you enter all the necessary information, go to the wizard's Message Settings tab, on which you can filter the source content by attachment extension or by date. Because a public folder that contains Mail and Post Items doesn't have an exact equivalent in SharePoint—unlike the other types of public folders (i.e., calendar equals events, and contacts equals contacts)—you must choose the discussion type. The tool needs to know which type of SharePoint list or library to convert these folders to. As I discussed earlier, SharePoint has document libraries and discussion lists, each with unique features. Discussion lists maintain message threads, and the message text is migrated as the post's text. Any attachments are linked to the post. Subfolders of the parent become new discussion-board lists. If you select mail type instead of discussion type, you lose message threading (i.e., the ability to group messages based on the same conversation). Subfolders are migrated as subfolders in the document list (similar to a file system view, such as Windows Explorer). In the example that Figure 3 shows, you can see how the Quick Launch bar appears in SharePoint depending on the target library type. Mail is selected on the left, and Discussion is selected on the right. The Mail conversion keeps the parent/child relationship between the folders, as it existed in Exchange, but with the Discussion type selected, discussion lists don't support sublists and the folders are migrated into separate, peer-level lists.
The wizard's third tab is SharePoint Settings. Here, you set the name of the SharePoint target site, which can be an existing site or a new site. This tab is also where you set the contact account and email address, which the wizard sets as the site owner property on the target SharePoint site. On the final tab, Export, you can initiate the migration and view the export progress.
SharePoint Importer
After the export is complete, you're ready to finish the migration with the SharePoint Products and Technologies Import Wizard. Unlike the Extractor, the Import Wizard must be installed on a SharePoint Web server. The account that runs the Import Wizard needs permissions to update the registry on the server that it's running on. The account also must have permissions to create sites and areas on the SharePoint site. The SharePoint Products and Technologies Import Wizard requires .NET Framework 1.1.
On the Import Wizard's Settings tab, which Figure 4 shows, enter the location of the exported files in the Source directory field, and enter the URL to the SharePoint server in the Target field. You needn't include the site name in the URL because it was already specified during the extraction and is stored in the struct.xml file, which is in the folder you specified during the public-folder extraction. You have a few other options for altering import behavior—for example, you can allow importing into existing sites or libraries. On the Import tab, you initiate the import process and monitor the progress as it runs.
Register
