Most Exchange administrators don't think much about public folders. In most sites, public folders are an afterthought: They tend to be used for low-priority tasks, if they're used at all. However, the sites that do use public folders tend to use them heavily. I know of several sites with public folder trees that contain more than 200GB of data, with tens or hundreds of thousands of posted items. For these sites, public-folder management is vital.
The administrative tools available for public-folder management might seem limited at first glance, especially for such large sites. However, the Exchange Server development team has been trying for a while to ship tools that ease the burden. The "Microsoft Exchange 2000 Server Resource Kit" includes the Pfadmin command-line tool, which is useful for setting or querying permissions. Exchange System Manager (ESM) lets us inspect the properties of folders and replicas. However, the one big piece that's been missing has been an automated way to create and move folder replicas. Why are these abilities necessary? Consider a company that's migrating to Exchange Server 2003. Because Exchange 2003 offers such great potential for consolidation (as I discuss in past Commentaries), this company wants to consolidate some public folders onto one server while simultaneously adding more replicas of the most crucial folders. For large public-folder deployments, this task would be unpalatable (read: mind-numbingly tedious).
Exchange 2003 includes a new tool to ease the pain: the Public Folder Migration Tool (pfMigrate.wsf) in Exchange 2003's Support Tools directory. Interestingly, pfMigrate is a Windows Script Host (WSH) script, not a standalone executable. The tool can handle a few simple functions: It can add or remove replicas of folders on specified servers, and it can produce reports that illustrate which servers have replicas of which folders. You must run pfMigrate against an Exchange 2003 server, although the tool can add or remove replicas from any Exchange Server 5.5 Service Pack 3 (SP3) or later server, and it works only on servers in the same routing group. And pfMigrate can modify only the Messaging API (MAPI) top-level hierarchy; if you've created separate top-level hierarchies for your applications, you'll need to manage those hierarchies' replicas manually.
Under the stated conditions, you can use pfMigrate to add or remove replicas. The first step is to use the tool's /s and /t parameters to specify the source and target servers, respectively. Savvy readers might wonder why the first step isn't to specify the list of folders to migrate. The answer is that pfMigrate doesn't let you specify individual folders. The /s and /t parameters work together following two simple rules. First, if you also run pfMigrate with the /a switch, which adds replicas, any folder that has a replica on the source but not on the target will be added to the target's replica list. Second, if you run pfMigrate with the /d switch, which removes replicas, any folder that has replicas on both the source and target will be removed from the source server's replica list.
You can use the /n switch to limit the number of replicas that pfMigrate examines, and by default the tool won't try to migrate system folders. Other than that, the tool efficiently clones folder replicas from the source to the target. Of course, just modifying the replica list isn't enough to actually replicate the folder data; for that you must let the normal public-folder replication process take place. As you might expect, this process can take a while for large sets of folders.
The tool also offers online Help: Run pfMigrate with the /? switch to get a complete list of options. If you want to move a lot of folders from your existing Exchange servers to new ones, this tool is for you.
