Blog Post

Exchange Team Blog

5 MIN READ

Moving public folder replicas from Exchange 2000 to Exchange 2007

Platinum Contributor

Oct 30, 2007

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

Published Oct 30, 2007

Version 1.0

The_Exchange_Team

Platinum Contributor

Joined April 19, 2019

View Profile

Exchange Team Blog

You Had Me at EHLO.

22 Comments

Anonymous
Aug 07, 2008
We have serveral 2-node clustered mailbox servers ; and a dedicated stand-alone public folder server in an Ex2007 environment. I inherited this Ex2007 network. The stand-alone public folder server has a mailbox store in the same storage group as the public folder store. Is the mailbox store still needed in Ex2007??? Any input will be greatly appreciated. Thanks.
Anonymous
Jan 24, 2008
ccrAlltheWay,

Yes you should replicate the PFs to E2007 and not delete the original admin group when you migrate from E2003 completely. Essentially, follow this on how to decommission the E2003 server:

http://technet.microsoft.com/en-us/library/bb288905.aspx
Anonymous
Jan 23, 2008
If I'm moving 2003 users to a puure 2007 ccr setup, what happens to free busy for those users who still use outlook 2003 and want to see the free busy time of ex2003 users and vice versa? They will have the x500 of the 2003 AG, so will the PF holding the F/B need to be replicated all around, and new users will get the x500 of the 2007 AG, so if thats sitting on a ccr box can we replicate back to the 2003 servers. There's also a pure PF server in the setup too..

Thanks!!
Anonymous
Jan 20, 2008
Hi,
I've run the addReplicaToPFRecursive.ps1 and it didn't add any replicas to system folders. Is there another script to run for this or a command line switch? I'm migrating from 2003 to 2007.

Thx.
Guy
Anonymous
Jan 16, 2008
mkieff,

Between orgs, you can use the Interorg Replication Tool to replicate public folders. Works with Exchange 2007 too:

http://www.microsoft.com/downloads/details.aspx?FamilyId=E7A951D7-1559-4F8F-B400-488B0C52430E&displaylang=en
Anonymous
Jan 16, 2008
Can anyone point me in the right direction for this question? We are moving from 2003 to 2007, but in the process we are also moving all the mailboxes to a different Forest, and a different Administrative group. I need to know what the best way would be to move the Public Folders from the 2003 org to the 2007 servers. Any ideas?
Anonymous
Jan 09, 2008
Hi Dave,
Re: *Moving Public Folders from a Ex2007 CCR cluster to a stand-alone Public Folders server*

We executed the prescribed process. All ran smoothly and we finished off with a get-PublicFolderStatistics on the source server that returned an empty database. So we deleted the database from the Storage Group, and then removed the Storage Group. We haven't yet deleted the actual database file from the file system.

We are now getting MSExchangeSA 9386 Warnings and OAB Generation and Access Issues.

Another one that stands out is the MSExchangeFBPublish 8197 Error, occurring because a member of the CCR cluster is no longer able to see a valid PF DBase on the virtual machine (for the cluster). Which we removed.

What did we do wrong? Your post stated that "Once empty, the process is done". Is there some way we could have discovered that the OAB hadn't been transferred properly - or the site role.

TIA for your advice.

Best regards
Anonymous
Dec 13, 2007
I have a scenario, where Public folder replication in between the Exchange 2000 and Exchange 2007 is fine. My customer has started the replication such that it has been set to Urgent and replicate always.
The version for store.exe on Exchange is 6.0.6603.0
This obviously has choked the network. Now due to this the mail flow has been stopped. We have removed the replica's from Exchange 2000 for Exchange 2007 and set all the PF's such that there is no replication.
However I still see lots of PF messages in the Messages pending submission and messages awaiting directory lookups.

How would i remove these messages and start the mailflow back to normal on the Exchange 2000 server.
Anonymous
Nov 16, 2007
SonnyK - if it's a public folder, the described process will take care of it. There are no exceptional PFs that somehow dodge the efforts of the script.

Note that there are some PFs which do not have a replica list (and hence no content themselves). Given this, the script makes no changes and there's nothing you need to worry about.

The bottom line is you need to look in Public Folder Instances (or on Ex2007 servers, get-publicfolderstatistics) and that list will slowly empty out. Once empty, the process is done. No other manual effort on your part should be required, outside the possibility that you've got a persistent replication problem which needs diagnosing (see Bill Long's extensive blog entries on diagnosing such problems).
Anonymous
Nov 15, 2007
What about OAB and 'SCHEDULE+ FREE BUSY" replication server? Do we need to right click OAB Version 4 click properties and select replication and add new Exchange 2007 server? If so, then is this performed before 'Move All Replicas' or after?