So you’re standing there in your machine room, staring at all the old machines you’d just love to retire. There’s all this new hot hardware, with a whole lot more storage. You just don’t need all those Public Folder servers any more.
So? Why not just run setup and uninstall the server? Well, setup’s uninstall process makes no attempt to insure data preservation as it does for mailbox stores. The same goes for Exchange System Manager if you just remove the public store. It’s up to you to make sure everything’s been replicated off the database before it’s removed from the world.
That may seem easy enough (and it actually is), but most people assume certain activity which doesn’t happen and they end up losing data. The problem is if the server is a replica for any folders, there exists the potential that a client is connected to this server publishing new data right as you’re trying to decommission it. Also, if this server holds the only replica for some folders, all of that data will be plain lost.
Your first step is to insure no mailbox stores are set to use the aging server for their default public store. This will ensure nobody creates new folders on the server just as you’re trying to decommission it. Changing the setting in ESM by itself is insufficient – you may need clients to log off of Outlook and log back in.
The next step is to use PFDavAdmin (see http://hellomate.typepad.com/exchange/2003/10/the_pfdavadmin_.html) to simultaneously remove the aging server and add another existing server in the replica sets of all folders. You could do this from within ESM, but ESM doesn’t have any facility for doing this selectively. You could use ESM to broad-scale replace the replica sets of all folders, but that may not be what you want to do. PFDavAdmin will let you replace one replica with another, which will only affect those folders which have replicas on the server being replaced. Note that the tool only works against Exchange 2000 and 2003 servers, so you need to have one of those in your org. Of course, it’s not necessary to run the tool against the server you want to retire – any public folder server in the org will do.
After having done this, view the Public Folder Instances page in ESM for that store. Once the list of folders no longer contains any folders you’re interested in keeping data for, you may safely decommission the database (or the whole server). Note that the process may take a long time – be prepared for it to take a few days, at the least. Also, you will need to dismount and remount the store (after it knows about the replica list changes). This is because the server won’t actually force already connected clients from disconnecting and possibly publishing more data.