EDIT: This post has been edited on 5/19/2008 to add a note about pointing Exchange 2003 mailbox stores to Exchange 2007.
We have heard from you that there hasn't been enough information on moving of public folder replicas from Exchange 2000 to Exchange 2007 so I wanted to provide some information to fill in the gaps.
The process for moving replicas from one public folder database to another is generally the same no matter what your source and destination server versions are. They are:
- Commission a new public folder database and wait for the hierarchy to replicate to it.
- Change any mailbox database configurations which have the to-be-decommissioned public folder database as its "Default" public folder database to use some other database. Preferably it will be a public folder database that resides on a server you're going to keep long-term. If you're migrating to Exchange 2007, there are a variety of reasons you should first configure all your mailbox databases to use an Exchange 2007 public folder database as the default. NOTE: If you have Exchange 2003 users that use OWA, you should not point the Exchange 2003 mailbox database to an Exchange 2007 public folder database, until you move all users that need OWA public folder access to Exchange 2007. To read more about this scenario, please see this blog post.
- Change the replica list for all public folders which have a replica on the to-be-decommissioned public folder database to instead have some other public folder database in the replica list. You may be performing a hardware upgrade, or a version upgrade, in which case you most likely want the set of folders on the "old" server to exist on the "new" server, but otherwise make no changes.
- Wait for the replicas to be removed from the to-be-decommissioned public folder database.
- Once empty, remove the old database.
Exchange 2003 (Service Pack 2 and later) and Exchange 2007 both make the overall process easy, and they even enforce the requirement that the database have no content before you can delete it. Exchange 2000 doesn't itself have an easy method to perform the above, nor does it even force you to wait for replication to finish which opens the door to data loss. Finally, there are bugs in Exchange 2000 where the process apparently never completes (it does, actually, but you'll have no reliable feedback that it's done). You should first ensure you have the latest hotfix rollup package installed (specifically, the version of store.exe on your Exchange 2000 server should be greater than 6.0.6617.87).
When moving data from Exchange 2000 to Exchange 2003 or Exchange 2007, you can use the tools available in either of those versions to quickly update replica lists to point to the new server. You do not need to use Exchange 2000's System Manager to administer Exchange 2000 (well, in terms of modifying replica lists, anyway). Exchange 2003 offers GUI on the public folder database object. Simply right-click on a database you want to decommission, select "Move All Replicas" and choose a replacement server. Exchange 2007 provides a PowerShell script called MoveAllReplicas.ps1 which takes as arguments the old and new servers. Go here for more information on how to run it. Wait for the process to complete and you can then repeat it for another database. Microsoft recommends you wait for the entire process (see below) to complete for a database before commencing the process on another database.
Exchange 2003 and Exchange 2007 will not let you delete a database that still has data within, but Exchange 2000 will. The only way to tell that the database is empty is to use Exchange 2000's System Manager and inspect the Public Folder Instances node under the public folder database object itself. When the right-hand side of the window lists no folders present (occasionally hit F5 to refresh), the database is empty and it's safe to remove it. NOTE: do not look in the "Public Folders" node, but only the "Public Folders Instances" node. The former only shows folders for which a client may get a referral (ie, folders which have an "active" replica on this server) while the latter shows all public folders which are still replicated to this server (ie, those that are still in the process of removing themselves from the replica list are included).
Note that the Exchange 2003 GUI and the Exchange 2007 script both only modify the replica lists for the relevant folders. You still need to wait for an awful lot of replication to take place. The folder (hierarchy) changes indicating the new replica sets need to replicate to all the other public folder databases, and then the content that needs shifting needs to be shifted. This can take a significant amount of time. Be prepared to wait days before it completes. It all depends on how many folders were previously replicated to the old server and how much data was there and not anywhere else.
The replication engine should begin taking care of things on its own and in pretty short order. You can prod things along a little bit and it might give you some satisfaction to do so, but more often than not it doesn't contribute to the overall efficiency of the system. It doesn't hurt either, so if it makes you feel good, go for it. Read this for more information.
During the transition, users may experience an unfortunate client referral to the database which doesn't yet have any data. Client referrals are computed based on the active replica list and therefore (depending on how many replicas a specific folder has) they may get a referral to the new database. The odds are inversely proportional to how many active replicas the folder has. There's little to be done about this except "wait for it." The content will arrive eventually. For this reason, it's best to start the process of decommissioning when there's going to be a significant amount of time without user interaction (say, Friday evening so it has all weekend to finish). If you do indeed have a public folder replication problem, read this.
The bottom line is moving replicas off of Exchange 2000 doesn't need to be complicated unless you're trying to move to another Exchange 2000 server. In that event you either need to undertake an awful lot of manual labor which we won't get into here, or use the PFDavAdmin tool to help you out.
- Dave Whitney, Charlotte Raymundo
