Moving public folder replicas from Exchange 2000 to Exchange 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


Share this post :


Comments (22)
  1. Bernd Kruczek says:

    Good article! But would be nice to have a similar article about PF on a E2K7 CCR which describes what exactly happens with a PF store on a CCR.

    tia

    Bernd

  2. Marc says:

    Greate article! In the last Script "RemoveReplicaFromPFRecursive.ps1" the parameter will be "-ServerToRemove" and not "-ServerToAdd", right?

    regards

    Marc

  3. paul says:

    Hi guys. Fantastic article. Thank you.

    I have two very important questions:

    1) If I’ve already manually enabled replication for most (but not all) of my Exchange 2000 Public Folders, there’s no harm in running the moveallreplicas.ps1 script, right?

    2) Does using the moveallreplicas.ps1 script eliminate the need to worry about syncing the folders? Since I do have a lot of replication going right now, I have noticed that the number of items is close, but NOT 100% in sync for many of the folders. If I run the moveallreplicas.ps1 script when I notice that the existing replication seems to have trouble getting a 100% perfect sync, should I be particularly concerned that I’ll loose some items?

    Cheers

    Paul

  4. Lou Mandich says:

    Awesome article, wish I had it 6 months ago.

    One minor point, you will need Patience with this procedure.

  5. Paul,

    Here are the answers to your questions:

    1)  The moveallreplicas.ps1 script is going to add the replica to the destination server, move the data and then remove the replica from the source server in one step.  As long as you are ready to to this then you can run the script, even if you have already added some replicas to the destination server.

    2) The moveallreplicas.ps1 is going to move the replica and data to the second server and so the step of syncing the folder is not needed.  The source replica will not be removed until all data has been replicated over.  You may have to dismount and remount the database on the source server once the hierarchy on the destination server knows about the replica list change.  Clients that are still connected to the source public folder store are not automatically redirected so you want to force them to connect to the destination server so that they don’t publish more source data delaying the sync.  Please see: http://msexchangeteam.com/archive/2004/05/04/126015.aspx

    Regards,

    Charlotte

  6. Ilantz says:

    Thanks for the info.. i did it with move all replicas.

    all went smooth just that one folder just disapeared (was deleted in the process) , could’t find how or why, i’ve just manually added it from backup.

    is there a release date for sp1 ?

  7. Dave Whitney says:

    Bernd- The PF replication engine isn’t safely compatible with CCR. You should NOT have CCR enabled on any PF Database in your org if there is more than one PF Database in your org. The reasons are rather complex, but we realize there’s a reason to have both enabled: when you’re transitioning (ie, you’ve got 1 PFDB using CCR, but now you want to add another PFDB). In this case, the config is allowed, but for proper reliability, you shouldn’t leave things configured this way for any longer than is physically required.

    Marc- Yes.

    Paul- 1) correct. 2) no. Charlotte’s response is misleading. The script only changes replica lists. You absolutely need to wait for the whole replication process to finish. See the revised article to see how to know when it’s done.

    ilantz- Yes, there is. :-)

  8. Chad says:

    Hope it’s not too late to post on here!  :)

    We’re currently in the process of migrating to 2k7.  One thing I’ve been trying to figure out, and based on what I’ve seen my guess is an unconfidant ‘no’, is this: Does the "Move replicas" option or moveallreplicas.ps1 script move the EFORMS registry and subfolders as well?  Or is that something we would have to manually migrate over via the "Add new replica server / remove old replica server" process?

    And if we aren’t actually using it, is there any need to even migrate it over?  I’ve read elsewhere that Exchange 2007 doesn’t require an EFORMS directory.  I know it’s impossible to remove Exchange from a server if any folders are still residing in the mailbox and public folders stores, but just curious.

    Thanks!

  9. Exchange says:

    Chad,

    Yes – EFORMS is indeed taken care of as other folders – by the scripts, yes. You do not need this folder unless you have custom forms published to it. In most organizations it is not doing anything but you would know best about your specific environment.

  10. Chad says:

    Thank you for the response!  One last question, if I may: is there a way to leave that folder out of the migration then?  We don’t use it, and in truth- we are getting replication warnings on it: we decommissioned one of our two Exchange 2k3 servers this past weekend and migrated all the public folders over to the remaining Exchange 2k3 server.  Everything went fine except the EFORMSOrganization(409) folder, which is now giving a 1129 replication error.  The final move to a pure 2k7 Exchange system will be in a week or so.

    Any help would be greatly appreciated, and I also want to thank you retro-actively for all the great articles you guys put up!  Especially in regards to Exchange 2007!

  11. Exchange says:

    Chad,

    Well, if you are not using that folder – you could just delete it alltogether so you don’t have to worry about replication? I will say though – make sure that you do not need it really as – once you delete it – it is gone, and will delete any replicas that might be sprinkled on various servers (if there are additional replicas already).

  12. Chad says:

    Yeah- that’s what we ended up doing last night.  Actually- we had tried doing that previously but kept getting an error message saying it was forbidden within ESM.  Finally, I used the MfcMapi tool last night to go in and delete it manually.

    That did the trick.  Of course, I was fully confidant we had nothing in there and that it wasn’t actively being used.

    Thanks again for your input; it is greatly appreciated and I’m looking forward to future articles!

  13. SonnyK says:

    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?

  14. Dave Whitney says:

    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).

  15. Anand says:

    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.

  16. Marty says:

    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

  17. mkieff says:

    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?

  18. Exchange says:

    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

  19. guy says:

    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

  20. ccrAlltheWay says:

    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!!

  21. Exchange says:

    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

  22. joycat says:

    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.

Comments are closed.